Top-20 Frequently Asked Business Architecture Questions (FABAQ)

Officially defined according to the Federation of Enterprise Architecture Professional Organizations (FEAPO), business architecture “represents holistic, multidimensional business views of: capabilities, end-to-end value delivery, information, and organizational structure; and the relationships among these business views and strategies, products, policies, initiatives, and stakeholders.”

Business architecture is a comprehensive documentation of an organization which:

• Describes the entire scope of its ecosystem
• Represents that ecosystem at a high level of detail
• Is shareable and reusable

A business architecture is to an organization as a blueprint is to a building.

The scope of business architecture is comprised of multiple domains (shown as the ten small boxes in the diagram below) and their relationships to each other, with capabilities and value streams as the foundation. All organizations have a business architecture—it just may not be written down at an enterprise level or according to industry standard practices. However, once an organization’s business architecture is documented in a knowledgebase, then blueprints and reports can be generated from it, to be used in support of a wide range of business scenarios. This Business Architecture Framework^TM concept is shown below.

What is more important, however, is the unique value business architecture can provide, as described in FABAQ #2 and FABAQ #3

Note: When responding to someone who asks “what is business architecture?” try not to define it word for word, but instead make it conversational and put it within their context.

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

These categories of business architecture value are detailed in the diagram below along with typical scenarios and results.

However, the best way to answer this question is highly personal and depends on who you are talking to. 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 essential now, which can help to provide context and diffuse any concerns (e.g., “if this is such an important thing, why don’t I know about it?”).

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 essential 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 collaborate across business units effectively 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 to survive and thrive.

Represented below is the progression and the current state of many of today’s organizations.

No. While we see the greatest concentration of business architecture practices among large corporations currently, business architecture is beneficial to any size of organization—from a sole proprietor to a large global organization. It is also beneficial to any organization, be it 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

Business architecture helps with all three.

The need for business architecture 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. This concept is illustrated in the diagram below.

This FABAQ is based on many 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 FABAQ #8).

The power of business architecture lies in the business architecture knowledgebase which:

• Describes the entire 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 (allowing us to see the forest for the trees for new insights and targeted focus)
• Is shareable and reusable (giving everyone the same mental model about what the organization does)

Here’s how it works:

1. Document your organization’s business architecture in a knowledgebase (ideally in an automated tool).
2. Generate any type of blueprint or report you want from that knowledgebase.
3. Apply those blueprints and reports to various scenarios in 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) 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.

Neither! Review FABAQ #5 for clarification. In short, 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.

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 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 with 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.

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 solid collaboration between the business architecture and business process communities and will continue to evolve.

Below is a perspective on how customer journeys, value streams, value chains, and processes apply within a strategy execution context.

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.

A practical approach for building an organization’s business architecture leveraging the industry-specific and common reference model content available from the BIZBOK^® Guide is below.

No. 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 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). Also, 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 idea is especially important in today’s world where the lines between business and technology are blending, even within the business model.

Business architecture is shown within the context of enterprise architecture below.

*Enterprise Architecture = Business Architecture + IT Architecture (where IT Architecture = Application Architecture + Data Architecture + Technical Architecture)

Actually, the right question to ask is, “how can an organization successfully do digital transformation without business architecture?” An organization with an established business architecture practice can greatly accelerate and improve the results of their digital transformation both because of the enterprise framework and cohesive strategy execution approach that are inherent to business architecture.

Many organizations struggle with knowing where to start and how to organize themselves for a digital transformation. The pure scope of change can be overwhelming and it requires organizations to work differently than they have before, not only due to scale but because it almost always entails needing to work across business units in order to achieve the integration and transparency required to shift towards customer centricity.

However, business architecture provides a foundation for digital transformation in two key ways. The first is that business architecture provides an agreed upon, business-focused framework, encompassing everything that an organization does, described at a high level. Business architecture also connects to all other aspects of the organization, including the operating model level of detail made up of people, process and technology. As a result, business architecture provides the fundamental structure for digital transformation, which allows people to readily view what the organization does from a business perspective (without spending time rediscovering it). Then, by methodically assessing and redesigning how it will change as a result of a digital transformation. This is true no matter if it entails digitalizing existing capabilities and offering them in different channels or completely reinventing the organization’s business model.

The second way in which business architecture provides a foundation for digital transformation is through its role in translating strategy into a coordinated set of actions for execution. With a documented enterprise-level business architecture (and IT architecture) in place, the business and IT impacts of the digital strategy and defined future customer experience can be cataloged and assessed and then collectively architected across products and business units. The resulting target architecture(s) can then be scoped into a set of transformation initiatives in the most effective way across business units—without redundancy, conflicts or dependency issues. The traceability from strategy and objectives through the business architecture to initiatives also allows for measurement to ensure the efforts deliver on the expected results. This top-down, cross-business unit approach to strategy execution is essential to any business transformation—and to an organization’s ability to continually adapt to change. While it requires more than just business architecture to achieve, an established business architecture practice will help to drive much of this approach within the context of a transformation.

The diagram below shows key ways in which business architecture can help organizations to strategize, start, and scale digital transformation:

In its simplest form, agile is about getting things done—and business architecture helps us get the right things done. While business architecture focuses on the business and translating business direction, agile teams are the mechanism that take that direction and deliver the results.

Within the Scaled Agile Framework^® (SAFe), business architects work at the portfolio level and focus on:

• Informing prioritization
• Providing business context and framing for work
• Providing a common vocabulary and mental model
• Connecting the dots across the organization related to business direction and initiatives

Business architecture is shown within the context of the Scaled Agile Framework^® (SAFe) below.

If applied correctly, business architecture should not slow down agile teams. Business architecture works alongside the teams to help them be focused and prepared—which speeds things up rather than slowing them down. And, it ensures that the agility and the success of the team is applied to the highest value parts of the business.

There are three focus areas of the business architect role in any organization:

1. Applying business architecture to various scenarios (a.k.a. “architecting”)
2. Building the business architecture knowledgebase
3. Creating the business architecture practice infrastructure

A business architect may focus on one, two or all three of these, depending on how the role is defined in their organization. But make no mistake, #1 is the most important thing that business architects do. Business architects architect and provide insights to support decision-making. The role has never been more important than it is today because our organizations are constantly changing, especially due to external factors like new customer expectations, the shifting competitive landscape, digital technology and regulation.

There is not yet an industry standard business architect job description in place yet, so if you are looking to hire a business architect or join an organization as a business architect, keep in mind that the understanding of the role can vary.

Additional responsibilities performed by business architects “outside of the job description” are shown below:

Business architects can and often do inform strategy formulation (and business model evolution), but they are not ultimately responsible for it. Business architects may also map strategies (i.e. document it using formal techniques), especially if it was not written down to the extent needed for communication throughout the organization. Business architects certainly use the business architecture to translate strategies (and business model changes) into the set of coordinated actions necessary to make them real.

If you are a business architect who is heavily involved in strategy formulation and business model design for your organization, that might be more related to your personal skills and experience versus the intention of the role, which is one focused on translation.

The role of business architecture across the strategy execution life cycle is shown below:

Drill down into the graphic recording illustration (by Sarah Greer), based on the Cutter Consortium webinar, Leveraging Business Architecture: Translate Strategy into Action, by Whynde Kuehn:

For years, there has been a trend of business architecture teams reporting to the business—and with success—for a number of reasons including more access to decision-makers, more knowledge of business direction, and more buy-in. So the answer is: ideally the business architecture team should report within the business.

Business architecture teams often report to business leaders such as those responsible for strategy, planning, transformation, innovation (or any combination of these), though there are many other examples, such as teams who report to different C level executives. Business leaders who have responsibilities that cross business units and care about the business direction being executed well are good candidates for the business architecture leader role.

However, this does not at all mean that business architecture teams who report within IT will not be successful. In fact, many business architecture teams incubate in IT since there may be the initial buy-in and skills there to help get the practice off the ground. Many teams will then shift to report to a business leader later on.

The bottom line is that having the business architecture team report to the business is ideal, but you start where you can start, and ultimately the best answer is: where it works best for your organization based on its needs and dynamics.

Remember that business architects have a foot in two different worlds, one in the business and one as part of the enterprise architecture team, so no matter where the business architecture team reports, they will always need to maintain a close partnership with the other.

A common best practice structure for a mature business architecture team is shown below.

It depends, but generally speaking here is the formula:

Business Architecture Team Size = Number of Business Architects to Cover Demand + Number of People to Support the Practice

A couple of key drivers of team size are:

• Size of your organization
• Number and size of change initiatives within your organization (e.g., enterprise transformations or acquisitions)

The business architect role opens up many different opportunities. Not only is the business architect role in high demand right now (in many different countries), but the experience it provides can position practitioners well with the broad knowledge of their organization, deep relationships and a foundation of structured thinking.

Once a business architect has truly mastered the role and reached a high level of competency, there are many possible career path options they can pursue. A successful business architect can shift their career in the direction they desire, either making the business architect role a long-term career or a step in a larger journey.

Here are a few career path options:

• Specialize In Business Architecture – A business architect may continue to advance their business architecture career within their own organization or move to another one. Some business architects shift focus to leading the practice, while others choose to continue architecting increasingly complex and large change initiatives.
• Move Into a Business or Technology Role (Within the Organization) – A business architect can pursue a business (e.g., product manager or department leader) or a technology leadership role. They can also move into (or even lead) another function or practice such as strategy, innovation, planning, customer experience design or IT architecture.
• Transition to a Different Career (Outside of the Organization) – A business architect can take their skills and experience and apply them in a completely different realm such as management consulting or working with a startup organization.

The typical career path options for an experienced business architect are illustrated below.

Starting business architecture within an organization can be a fairly organic process, but there are a proven set of practical steps which work. First, build a solid understanding of what business architecture is, including its scope, role in strategy execution, integration with other teams, and the value it can provide. Then, define business architecture’s value for your organization and establish a team (which could be a team of one to start).

Once the case for business architecture has been established and a team has been formed, work along two parallel tracks: one for developing the business architecture knowledgebase and applying business architecture for value, and the other for maturing the business architecture practice. Develop just enough practice infrastructure (e.g., methodology, tools, etc.) just in time to support the relevant business architecture scenarios.

A practical approach for establishing and maturing a business architecture practice is shown below.

We generally focus on two categories of results:

• Value business architecture provides to the organization – An assessment of the overall impact business architecture is making in the organization (e.g., on customer satisfaction, revenue, cost savings, quality, etc.), how it improves planning and solution development, and generally how valuable it is to the people who consume it.
• Maturity of the business architecture practice – An assessment of how mature an organization’s business architecture practice is as well as how embedded and how well-scaled it is across the organization.

A few example metrics are shown in the diagram below for these two categories of results.

While the journey may not always be easy, based on current trends and evidence, here are some predictions for the future of business architecture. (Note: Some of these predictions are a number of years out and all are subject to change based on ongoing evolution.)

• Business architecture adoption and advancement will continue at an increased pace globally.
• Organizations will increasingly leverage business architecture for strategic purposes and position business architecture teams to work upfront in the strategy execution lifecycle.
• The focus of the business architect role will continue to shift from developing the business architecture knowledgebase to “architecting the business.”
• The business architect role will continue to elevate.
• Business architecture will be deployed in new ways across organizations.
• Business architects will architect across organizational boundaries.
• Business architecture will become a true profession.
• Architects will use their talents for “good.”

These business architecture predictions are summarized below.

#20