StraightTalk Post No. 29 is all about answers to everyone’s FABAQ (Frequently Asked Business Architecture Questions) and there are lots of them. Why are we doing this? First, because we’re here to help you understand. That is what StraightTalk is all about. Second, because we want to help you help others by arming you with some straightforward answers to these questions—making you an even better leader, practitioner and advocate for the discipline.
Of course, we can’t select all of the FABAQ, but between this post and the next one in the series, we will cover the top 20 biggies.
1. Numero Uno. The most common FABAQ. What is business architecture?
We highly encourage you to craft your own answer to this one. And how you answer will likely depend on who you are talking to. Post No. 1 can give you some answers and inspiration.
Hint: Don’t explain the definition word for word; make it conversational. And quickly get to talking about the value of business architecture and how it is used. See #2.
2. The second most common FABAQ. What is the value of business architecture?
In the broadest and most generic sense, we like to focus on how business architecture:
- Bridges strategy and execution
- Simplifies a complex environment
- Creates a shared language and visibility
However, this is highly personal and depends on who you are talking to. We highly encourage you to craft your own answer to this one as well. Adapt your answer to the person you are talking to and what they care about. Succinctly describe the value of business architecture and then describe a usage scenario or two which may be relevant to them. You may also want to describe why business architecture is important now, which can help to provide context and diffuse any concerns (ones like: “if this is such an important thing, why don’t I know about it?”). Posts No. 2 and No. 3 can help.
3. Why is business architecture so important now?
The bottom line is that we work in complex organizations that are colliding with a world where constant change is the new normal. Organizations have finite resources, including time, people and funding, and the key is to focus those resources on the most important things in the most effective way—and to have a way to move ideas into action quickly and effectively.
Having an enterprise mindset and the ability to effectively collaborate across business units is now essential to achieve all of these things, and business architecture is a critical enabler. It allows us to find and simplify complexity, architect enterprise-wide transformations, execute change faster from end-to-end, and objectively prioritize investments. It also provides a rationalized view of an organization necessary to leverage future investments like cognitive computing.
Business architecture helps organizations to achieve the new mindset they need in order to survive and thrive.
Check out Post No. 2 for more on this, with pictures.
4. Business architecture is only used by large businesses, right?
No. While we see the greatest concentration of business architecture practices among large corporations, business architecture is beneficial to any size of organization—from a sole proprietor to a large global organization. It is also beneficial to any type of organization: for-profit, non-profit and governmental institutions.
No matter what an organization’s type or size, it has the best chance of success with:
- A viable and competitive business model
- An intentionally designed organization
- A way to set and execute direction
And business architecture helps with all of these.
The need for business architecture though is driven more by an organization’s size than by its type. Small organizations can leverage business architecture right from the beginning, but the need for the discipline grows as it eventually scales and transforms.
Check out the handy diagram below for more on that.
Check out Posts No. 17 and No. 18 on how business architecture is used for small businesses and non-profit organizations.
5. Shouldn’t we skip documenting “current state” and go right to “future state?”
This FABAQ is based on a number of misconceptions. The first is that business architecture is just a set of standalone techniques and tools that can be applied in various situations (not exactly true). The second is that documenting business architecture requires a lot of time and detail (also not true and usually because there is also confusion with #8).
The power of business architecture lies in the business architecture knowledgebase, which:
- Encompasses the whole scope of an organization’s ecosystem (it is created top-down—not bottom-up by individual business units or projects)
- Represents that ecosystem at a high level of detail (finally, we can see the forest for the trees)
- Is reusable (i.e. no more archeology digs to remember what your organization does)
Here’s how it works:
- Document your organization’s business architecture in a knowledgebase (ideally in an automated tool).
- Generate any type of blueprint (diagram) or report you want from that knowledgebase.
- Apply those blueprints and reports to various business scenarios. (This is the most important part.)
The answer to the question then is no—when building a business architecture
knowledgebase, we must document the current state (though you can capture some future state where applicable) in order for us to have a baseline to work from. That’s the whole point of business architecture, otherwise, we are just creating more fragmented deliverables. However, business architecture is documented at a high level and there are ways to quickly get to the minimum baseline of capabilities and value streams, so documenting this “current state“ is not time-consuming as people usually think. Once we have a baseline in place we can expand upon it and can create “target state business architectures“ as part of the strategy execution life cycle.
Posts No. 1, No. 12, No. 13, No. 22 and No. 23 provide more helpful background on building the business architecture knowledgebase.
6. Is business architecture created on a project-by-project basis? Or do we have our own business architecture for our area of the organization?
Neither. This goes back to what we discussed in #5. We create business architecture top-down for the entire scope of an organization’s ecosystem and then we can use it for many different scenarios at a business unit, product, program or project level. The sky is the limit for usage.
Business architecture (with capabilities and value streams as the foundation) gives us a way to look at our organizations differently, so that we can see what is common versus what is different—and it gives us a way to work as a cohesive enterprise like never before.
7. How is business architecture different from business analysis?
Business architecture and business analysis are two separate but mutually beneficial disciplines. The intentions, deliverables and corresponding roles (business architect and business analyst) are different.
Business architects work at the enterprise level and upstream in the strategy execution life cycle, while business analysts work on a more focused scope downstream. Both are critical and work together.
Business architecture provides scoped initiatives, vocabulary and a framework to tie requirements to so that they can actually be reused. Business analysts consume the business architecture changes related to their specific initiative(s) as well as the overall vocabulary and mental model which business architecture defines. Business analysts, in collaboration with business architects, translate business architecture changes into a set of requirements for their initiative(s) and align them to the business architecture capabilities and stakeholders.
This perspective has been informed by years of collaboration between the business architecture and business analysis communities and will continue to evolve. (See Business Architecture Guild® white papers in Public Resources and check out Section 3.8 of the BIZBOK® Guide.)
8. Is process part of business architecture?
No. You will not see process as part of the scope of business architecture, per the domains listed in BIZBOK® Guide Figure 1.1. Business architecture and business process are two separate but mutually beneficial disciplines. The intentions, deliverables and corresponding roles (business architect and process analyst or equivalent) are different. Both are critical and work together.
Business architecture enables an organization to realize its business model. Processes enable an organization to realize its operating model (inclusive of people, process and technology). There is a many-to-many relationship between processes and capabilities (the formal link to processes), and a many-to-many relationship between processes and value streams. This traceability is very useful for bi-directional impact analysis.
In addition, business architecture can provide an enterprise-wide framework for processes (e.g. to organize them, to identify redundancy, to identify areas for best practice sharing) and help to establish priorities for process-related work.
This perspective has been informed by years of admirable collaboration between the business architecture and business process communities and will continue to evolve. (See Business Architecture Guild® white paper in Public Resources and check out Section 3.4 of the BIZBOK® Guide.)
9. Can we purchase a business architecture? Or are there any reference models we can leverage?
You cannot really purchase an entire business architecture and you shouldn’t try to. However, there are a number of reference models out there that may be used to accelerate the development of your business architecture knowledgebase, but they should be used as input to the process of creating your own business architecture (e.g. capability map, information map and value streams) with a cross-functional group of business experts.
Pre-packaged perspectives such as these rarely, if ever, exactly match your organization’s vocabulary and business model nuances. In addition, creating your own business architecture in-house will create much stronger buy-in and advocacy by the business.
Check out Post No. 22 for more on using reference models to accelerate the development of your knowledgebase. Also, see Part 8 of the BIZBOK® Guide for industry reference models and a common reference model that applies to all organizations.
10. Business architecture is an IT thing, right?
Nope. Business architecture represents the business, not solution, application, data or technical architectures. As a result, the business has to participate in, understand, and leverage business architecture in order to capitalize on the discipline.
However, an organization’s business architecture should be connected to its IT architecture (e.g. capabilities are cross-mapped to system applications for traceability). In addition, business and IT architects work closely together not only to build the knowledgebase, but also to architect together within the context of the strategy execution life cycle (e.g. picture architecting the future organization during a major transformation).
Since business architecture is one of the domains within enterprise architecture*, business architects must always have a foot in two worlds: one as part of the business and one as part of enterprise architecture.
But should business architects have a strong working knowledge of technology?
Absolutely. This is especially important in today’s world where the lines between business and technology are blending, even within the business model.
More on business architecture and IT architecture in Posts No. 14 and No. 15. And Part 6 of the BIZBOK® Guide.
* Enterprise Architecture = Business Architecture + IT Architecture (where IT Architecture = Application Architecture + Data Architecture + Technical Architecture)
More Good Stuff…
Check out the full set of FABAQs (Frequently Asked Business Architecture Questions)
Where else do you find answers to FABAQ?
- The Business Architecture Quick Guide (Business Architecture Guild®): Available on Amazon and Barnes and Noble.
- The BIZBOK® Guide (Business Architecture Guild®): Of course. (Guild membership required).
Business Architecture: Dispelling Twelve Common Myths (S2E and TSG – Revised January 2019): A white paper on some common misconceptions about business architecture. The answer to more FABAQs lie within these.
What is Business Architecture? (S2E): A white paper on what business architecture is and is not. Great for FABAQs on the basics of what the discipline is all about.
The Value of Business Architecture: New Mindset, New Results (S2E): A white paper on the value of business architecture and some key usage scenarios. Great for FABAQs on the “why” of business architecture as well as the “why now.”
The Strategy Execution Metanoia: A New Approach for Translating Strategy Into Action With Business Architecture (S2E): A white paper on the important role of business architecture in enabling a new and crucial vision for strategy execution. Also great for FABAQs on the “why” of business architecture as well as the “why now.” Helps to put FABAQs #5 and #6 into context too.
Business Architecture Integration: Integrating Business Architecture Into the Enterprise (S2E): A white paper on how business architecture interacts with and benefits other teams and disciplines. Great for FABAQs on how business architecture fits with things like strategy, planning, customer experience, business analysis, business process and more.
Business Architecture: Putting Business into Enterprise Architecture (Ulrich and Soley): A white paper on the role of business architecture within enterprise architecture. Great for FABAQs on how business architecture fits within the larger architecture context.
Initiating Action (TED Talk): Just for fun. A TED Talk by Dawa Steven Sherpa on getting out of your comfort zone. “In mountaineering, we have a saying: You don’t summit in your sleeping bag.”