Site icon Aragon Research

How to Develop Valuable Business Architecture Deliverables?

By Betsy Burton

How to Develop Valuable Business Architecture Deliverables?

Since the inception of the EA discipline, architects have been documenting the output of their work.

They refer to these work products as “artifacts” and keep these work products in a repository of some form or another (an EA tool, a content management tool, etc.). Their goal is to create this collection of future and current state road maps, decision frameworks and policies, and guidance that IT and business people can use to help make investment decisions. 

I will be honest, most business and IT people find the work products in EA repositories pretty boring.

Yes, it can be a collection of documented artifacts that could be helpful if they’re actually used. The problem is that these work products are often not put in context of where the business is trying to go. In addition, they are typically not designed to address specific and real questions. Further, the effort it takes to use them to answer a question is often substantial.

The core problem is that most business architects and EA leaders are creating artifacts, not deliverables. 

To be highly effective EA and business architects need to focus on making sure they’re creating deliverables that someone can really use.

What Is the Difference Between an Artifact and a Deliverable?

An artifact is a work product that is the documentation of the future or current state of the business or IT.

Examples of artifacts might include current state business process models, future state business capability models, a standard for integrating specific applications, or a generic road map. They are certainly important. But if they don’t have meaning in the context of something someone is working on or guide a decision, then they may be more confusing than valuable.

A deliverable is a work product that is the documentation of guidance that is specifically created to answer a specific question for a specific person or group of people. The big difference is that a deliverable is created to address a specific person’s real-life question or issue.

What Makes a Deliverable Effective?

What makes a deliverable more effective than an artifact is that it is targeted to address the specific questions of a specific group of people.

For example, a senior executive might want to know how current investments are or are not helping to achieve a specific strategic objective.

A business leader might be seeking to understand how a business process needs to change or be transformed to support a new business venture. An IT developer might need to know when, how and why they should utilize a specific standard.

An effective deliverable includes specific components, including: a target audience, a specific question they are or should be asking, and a time frame. In addition, an effective deliverable provides a clear answer to the question being asked in the form of a road map, model, policy, principle, decision framework, etc.

It doesn’t matter if you don’t get the question that you think your business and technology leaders are completely correct. It is better to create deliverables based on what you think they are asking or should be asking. Bring these to them and offer them. If you didn’t get the question correct, it’s okay.

The key is that you have opened the door for them to let you know what the real question they have. In either case you’re going to learn what they need, so you can create an effective deliverable in your next iteration. 

Also, by taking this approach, you will be illustrating to your business and IT leaders that you can address their issues and questions. This in turn will inspire them to ask you for more information.

Bottom Line 

Nine times out of ten, when I speak to a client about their issues and challenges garnering support and traction for business architecture and enterprise architecture, it is because they are creating generic artifacts not answering business and technology leaders’ real-life questions.

They are pulling out artifacts in the hopes that someone will put them together to answer some questions. And the reality is it just doesn’t gain traction.

To be highly effective it’s critical that business architects, especially supporting business transformation, focus on creating deliverables that guide investment decisions. 

 


Upcoming Webinar

Using Business Capability Modeling to Guide Business Transformation

A big challenge for organizations going through business transformation is understanding and exploring their future-state business model. Business capability modeling can provide a powerful technique for exploring and communicating your future state in a way that is unencumbered by political issues related to domains, organizational structure, processes, or functions.

In this webinar, Aragon’s VP of Research, Betsy Burton, will be reviewing how business capability models can be used to guide strategic and operational investments. Webinar topics:

Register Here

 


 

 

 

This blog is a part of the Business Transformation blog series by Aragon Research’s VP of Research, Betsy Burton.

Missed the previous installments? Catch up here:

 

Blog 1: Betsy Burton Brings You a New Blog Series on Business Transformation

Blog 6: Product Managers Can Make Great Business Architects

Blog 2: What Are the Benefits of Supporting Business Architecture?

Blog 7: 4 Necessary Steps to Successfully Start a Business Transformation Effort

Blog 3: How Do Business Architects Gain and Retain Management Support?

Blog 8: 5 Best Practices: Developing an Executive Business Case Presentation for Business Transformation

Blog 4: How Do We Find and Recruit Great Business Architects?

Blog 9: How Do You Model Business Transformation?

Blog 5: Is a Charter Necessary to Start a Business Architecture Discipline?

Blog 10: What Is a Business Capability Model?

Stay tuned! We publish a new blog every week.

 

Exit mobile version