The Business Architecture

Metamodel Guide
Defining a business architecture knowledgebase founded
on formal principles

Authors Thomas Bata, Paul Lyndon, Hermann Schlamann, William Ulrich

Contributors Business Architecture Guild Metamodel Team

Reviewers Bert Hooyman, Stephen Marshall, Jim Rhyne

August 2020 1 Copyright ©2020 Business Architecture Guild®

The Business Architecture Metamodel Guide

CONTENTS
1. Abstract .......................................................................................................................................... 4
2. Introduction.................................................................................................................................... 6
3. Business Architecture Overview ..................................................................................................... 8
4. The Business Architecture Framework ......................................................................................... 10
4.1 The Business Architecture Knowledgebase .......................................................................... 10
4.2 Business Architecture Blueprints .......................................................................................... 11
4.3 Business Architecture Scenarios ........................................................................................... 11
5. Business Architecture Domain Associations ................................................................................. 13
5.1 Introducing the Business Architecture Metamodel .............................................................. 13
5.2 Value Stream ........................................................................................................................ 14
5.2.1 Value Stream Cross-mapping ........................................................................................15
5.2.2 Value Stream Example ..................................................................................................15
5.3 Capability .............................................................................................................................. 17
5.3.1 Capability Cross-mapping .............................................................................................18
5.3.2 Capability Example........................................................................................................19
5.4 Information........................................................................................................................... 20
5.4.1 Information Cross-mapping ..........................................................................................21
5.4.2 Information Concept Example ......................................................................................21
5.5 Organization ......................................................................................................................... 23
5.5.1 Organization Cross-mapping.........................................................................................24
5.5.2 Organization Example ...................................................................................................24
5.6 Stakeholder .......................................................................................................................... 25
5.6.1 Stakeholder Cross-mapping ..........................................................................................26
5.6.2 Stakeholder Example ....................................................................................................27
5.7 Strategy ................................................................................................................................ 27
5.7.1 Strategy Cross-mapping ................................................................................................28
5.7.2 Strategy Example ..........................................................................................................28
5.8 Initiatives .............................................................................................................................. 29
5.8.1 Initiative Cross-mapping ...............................................................................................30
5.8.2 Initiative Example .........................................................................................................31
5.9 Policy .................................................................................................................................... 31
5.9.1 Policy Cross-mapping ....................................................................................................32
5.9.2 Policy Example ..............................................................................................................32

August 2020 2 Copyright ©2020 Business Architecture Guild®

The Business Architecture Metamodel Guide

5.10 Product ................................................................................................................................. 33

5.10.1 Product Cross-mapping.................................................................................................35
5.10.2 Product Example ...........................................................................................................35
6. Summary ...................................................................................................................................... 37
Glossary of Terms ................................................................................................................................. 39
About the Business Architecture Guild®............................................................................................... 41
References............................................................................................................................................ 41

August 2020 3 Copyright ©2020 Business Architecture Guild®

The Business Architecture Metamodel Guide

1. ABSTRACT
Businesses are faced with a myriad of threats to manage, weaknesses to improve, strengths to
leverage, and opportunities to pursue. As organizations seek to address these issues, one finds a major
common obstacle:

A commonly cited reason for failing to execute on strategy is an inability to act in a coordinated
fashion, with a widely understood set of objectives, across multiple business units and levels of
management, toward a common goal and an integrated solution.

Executives seeking to address this challenge must define and execute coordinated cross-business
strategies based on clear, consistent business perspectives that scale across teams, projects, business
units, and partners. This whitepaper outlines how to leverage business architecture to identify and
capture unique organizational perspectives, and the relationships among those perspectives.

This whitepaper provides an essential guide to organizations seeking to formalize and scale business
architecture as a basis for executing complex strategies, performing root cause analysis, responding to
business challenges, and delivering more effective solutions in less time and for less money.

This whitepaper introduces the business architecture knowledgebase, which allows organizations to
establish multidimensional views of what it does and how it delivers customer and related stakeholder
value. In order for a business architecture knowledgebase to accurately represent an organization and
scale effectively, it must base its knowledgebase upon a formally defined “metamodel”.

For readers new to the metamodel concept, one can think of it as a model describing a model used to
make abstract concepts into something concrete within a specific context. Specifically, a metamodel is
defined as an “abstract syntax of a class of models.” Therefore, a metamodel enabling implementation
of a business architecture knowledgebase sets out the rules of how to define "things" within a business.
This whitepaper provides a simplified, practitioner-friendly view of the business architecture
metamodel. Through its ongoing work with a professional standards organization, the Business
Architecture Guild® and its partners are formalizing this metamodel in more detail, using standard
modeling techniques.

The whitepaper discusses how to get started modeling an organization from a variety of vantage points
without having to expose readers to the finer details commonly found in an actual metamodel. The
resulting business architecture knowledgebase enables an organization to create a foundation from
which to decouple and clarify entangled terms and concepts that can overwhelm planning, design,
operations management, program management, and technology deployment. The clarified
perspectives that result help further clear-minded analysis, business planning, and strategy execution.

The reader would greatly benefit from studying the concepts and principles behind business
architecture and corresponding metamodel, which can be found in A Guide to the Business Architecture
Body of Knowledge® (“BIZBOK® Guide”). i

This paper does not represent a formal metamodel. The Business Architecture Guild® is maturing a
formal, business architecture metamodel and readying it for submission to an international standards
organization for adoption. The discussion and related figures presented in this whitepaper depict

August 2020 4 Copyright ©2020 Business Architecture Guild®

The Business Architecture Metamodel Guide

conceptual models of various associations among business architecture domains and certain detailed
elements within those domains.

The intent of these representations is to provide practitioners and infrastructure support teams a basis
for associating business architecture domains to support a viable practice. The examples provided for
each domain category also allow the practitioner to envision how to apply business architecture in a
live context.

Finally, the whitepaper establishes a basis for associating business architecture domains with related
disciplines. These disciplines include, for example, strategic planning, operating model optimization,
program management, customer journey mapping, IT architecture, and related practices. Future white
papers will explore these extended perspectives and their associations with business architecture.

August 2020 5 Copyright ©2020 Business Architecture Guild®

The Business Architecture Metamodel Guide

2. INTRODUCTION
Philosophers have since pre-history struggled with the dilemma of appearance and reality. Modeling
is an ancient technique supporting the act of analysis. The 20th century analytical philosophers together
understand the term analysis to mean "the decomposition of something into its constituents". ii
Modelers take something from the real world and represent it with a symbol. This simple act can
quickly become very complicated when one refers to an abstract 'thing' like a 'business'.

In the physical world, a ‘business’ is not a real thing; it is an abstract concept. The problem with such a
concept is that it is rare for two individuals to share the same mental picture or meaning of the term.
Figure 1 depicts how an object such as an apple can trigger two very different mental abstractions.

Figure 1: The Philosopher's Dilemma: Appearance and Reality

Outside of the real world, we need to make the abstract into something concrete, something for which
we can share a mental picture. One such popular technique is through describing things in terms of
business objects. The context, scope, or thing we intend to describe is an organization, framed by the
business ecosystem iii in which it exists. Business object definition, along with the ability to represent
actions performed against those business objects, is foundational to understanding and representing
a business ecosystem. Business objects play a critical role in value delivery.

A model of a business ecosystem describes the rationale of how an organization creates, delivers, and
captures value. Two critical aspects of a business that should be represented in a business ecosystem
include:

1. The act of "producing" (value creation and deployment).

2. The act of "consumption" (customer consumption of the value created by the organization).

The key players behind a business are the producer (provider) and the consumer (customer, partner,
and internal stakeholders).

One way of looking at this value exchange concept is that customers have some need which they seek
to fulfill, while the provider provides a need fulfillment to satisfy the customer's wants or needs with
an offer that will alleviate that need. If the fulfillment offered – the provider's value proposition –
meets the customer's wants or needs, there will be an exchange of value (often money for goods and
services). Figure 2 highlights these value creation consumption perspectives.

August 2020 6 Copyright ©2020 Business Architecture Guild®

The Business Architecture Metamodel Guide

Figure 2: Business Architecture’s Primary Focus: Stakeholder Value Delivery

The value concept is central to business architecture. The business architecture practitioner takes great
interest in what is necessary to create and provide a value proposition for the customer. Business
architecture modeling focuses on the provider side of the value proposition equation. This focus is an
outside-in perspective and is the opposite view of the perspective taken by many organizations today.

The business architecture practitioner uses the business architecture knowledgebase to articulate and
leverage a wide variety of organizational perspectives, including value creation and value consumption,
to enable visual thinking and storytelling as a means of defining challenges and framing shared
solutions.

While a heavy emphasis is placed on value creation and consumption, the knowledgebase must also
incorporate views of the business capabilities, information, business units, strategies, policies,
products, and initiatives. Capabilities and information concepts are the primary vehicle for
representing the collective set of business objects that represent a business ecosystem. Collectively,
these business views or business architecture “domains” enable the practitioner to clearly articulate
the impacts of business objectives, perform root cause analysis, define cross-organizational solutions,
and successfully and confidently execute a wide range of business strategies.

The following sections of this whitepaper provide an overview of business architecture and introduces
the business architecture framework, which includes the business architecture knowledgebase,
business blueprints derived from the knowledgebase, and the scenarios that frame business-specific
contexts for using business architecture in practice. The main body of the whitepaper provides a
detailed breakdown of each business architecture domain, relationships with other domains, and real-
world examples.

August 2020 7 Copyright ©2020 Business Architecture Guild®

The Business Architecture Metamodel Guide

3. BUSINESS ARCHITECTURE OVERVIEW

In the past, business architecture was defined as “a blueprint of the enterprise that provides a common
understanding of the organization, and is used to align strategic objectives and tactical demands”. In
collaboration with various industry associations, this definition matured into the following:
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. iv

The Business Architecture Guild® has formalized the business architecture discipline, defined sets of
guiding principles, documented best practices, formalized techniques, and established an execution
framework. The BIZBOK® Guide, an industry body of knowledge, formalizes the business architecture
discipline for practitioners. This whitepaper provides a guide to the underlying metamodel that forms
the foundation for the business architecture knowledgebase that enables a practice.

Business architecture is framed around the ten formally defined domains as shown in figure 3. These
domains represent business ecosystem abstractions, which are formalized and realized in practice in
the Guild metamodel.

Figure 3: Business Architecture Domains

The ten domains shown in figure 3 form the basis for the establishing, applying, and managing business
architecture. This paper provides details on each domain, related sub-elements, and relationships to
other domains.

Figure 3 shows four core domains in the center circle. The reason behind these four domains being
called out from the other domains is that they provide the foundation for a business architecture. The
outer circle depicts the extended domains, which play a role in the practice of business architecture.
For example, strategy is engaged during strategy planning, while initiative would be used in program
and project planning and execution.

August 2020 8 Copyright ©2020 Business Architecture Guild®

The Business Architecture Metamodel Guide

Figure 4 depicts the concept of capability playing a central role in business architecture.

Figure 4: Capability: Business Architecture Focal Point

Figure 4 highlights the important perspective of capability being the central focal point of business
architecture. For example, capability provides the link between the other core domains of value
stream, information, and organization. If one wanted to understand the information relevant to
customer value delivery in a value stream, those views would be derived from the association between
the capabilities and information they require and modify, and the capabilities and value streams they
enable. The following sections provide more details on the relationships among these core domains,
and between these core domains and the extended domains.

August 2020 9 Copyright ©2020 Business Architecture Guild®

The Business Architecture Metamodel Guide

4. THE BUSINESS ARCHITECTURE FRAMEWORK

The business architecture framework provides the basis for practitioners of all types to leverage
business architecture. The framework, shown in figure 5, is comprised of the business architecture
knowledgebase, business blueprints or visualizations extracted from the knowledgebase, and the
business scenarios that determine the type and scope of those blueprints.

Figure 5: Business Architecture Framework & Knowledgebase

4.1 THE BUSINESS ARCHITECTURE KNOWLEDGEBASE

Whether formalized or not, most practicing organizations have a mechanism in place for capturing and
managing their business architecture. However, not all organizations have captured their business
architecture in a formal business architecture knowledgebase, explicitly using principle-based, highly
actionable definitions of their business.

To realize the value of business architecture, an organization must deploy a formal framework v for
capturing, managing, and leveraging its business architecture. This framework rests upon a
knowledgebase and metamodel that formalizes common perspectives in a way that is readily
applicable to planning, analysis, design, operational improvment, and deployment.

The business architecture metamodel introduced herein is based on the framework illustrated in figure
5. While the overall framework is defined and detailed in the BIZBOK® Guide (including details on
principles, guidelines, best practices, and usage scenarios), this whitepaper provides the formal
metamodel perspective for defining the underlying mechanics needed to establish and manage the
knowledgebase. Before delving into the knowledgebase and underlying metamodel, the following
sections summarize the blueprint and scenario concepts.

The bulk of the remainder of this whitepaper details the metamodel-derived domains and relationships
that comprise the overall business architecture knowledgebase. These detailed perspectives serve as
both a practical guide to deploying a knowledgebase as well as insights into how the various elements
of business architecture interconnect and may be applied in practice.

August 2020 10 Copyright ©2020 Business Architecture Guild®

The Business Architecture Metamodel Guide

4.2 BUSINESS ARCHITECTURE BLUEPRINTS

The BIZBOK® Guide is a principle-based body of knowledge and, while providing useful blueprint
examples, it offers the business architect a foundation for developing their own blueprints and related
scenarios. One can think of the BIZBOK® Guide as a cookbook containing recipes and detailed
instructions on how to prepare a dish, rather than prescribing a predefined menu. As such, the BIZBOK®
Guide may be applied to an ever-growing list of business scenarios that range from strategic planning
through solution deployment.

Business planners and executives create blueprints to answer a wide variety of questions and address
a multitude of challenges. The business architect requires blueprints or maps to represent core
capability, value stream, information, and organization domains, relationships across these core
domains, and a wider set of associations between core and extended domains.

A blueprint showing associations between two or more business architecture domains is called a
“cross-mapping”. Cross-mapping is the technique of relating multiple business architecture domains
to each other or to related business and IT disciplines. This technique, which is represented in the
metamodel via associations, allows the practitioner to connect multiple artifacts in a way that more
effectively represents real-world relationships. Cross-mapping is always between domains and not
terminology used to associate elements within a domain. For example, capability instance relationship
to capability behavior is an intradomain association, not highlighted in cross-mapping.

The recommended minimum starting point for a business architecture baseline includes commonly
engaged and customer-initiated value streams, a capability map, and an information map.
Organizations will prioritize extending these perspectives based on specific business scenarios as the
use of business architecture begins to scale.

Experience has found that specific industries share value streams and capabilities to a great extent.
The Guild provides industry reference models to accelerate efforts to establish a baseline business
architecture. These reference models are specialized for various industries including financial services,
insurance, transportation, government, manufacturing, and healthcare, as well as a common or
generic business architecture baseline. Industry-specific business architecture mappings are formed
around the same principles applied to defining the business architecture metamodel. As a result,
organizations seeking to apply and benefit from these reference models should establish a
knowledgebase that aligns to the metamodel defined in this whitepaper.

4.3 BUSINESS ARCHITECTURE SCENARIOS

A business architecture knowledgebase and its associated blueprints can be used to consider and
understand a range of different business scenarios. The knowledgebase cannot be restricted to single-
use situations, meaning that the knowledgebase must not only be principle-based but intentionally
architected to enable a wide range of known and unknown business scenarios. Populating core and
extended business architecture domains, cross-mapping the captured knowledge, representing those
views in various blueprints, and applying those blueprints to a given business scenario, turns the
captured knowledge into wisdom and insights needed to improve strategy execution.

August 2020 11 Copyright ©2020 Business Architecture Guild®

The Business Architecture Metamodel Guide

For example, understanding the capabilities that a business has is a single dimension of knowledge.
Understanding the business units within a business ecosystem, including those of partners, creates
more knowledge. Cross-mapping capability and organizational domains provides insights into how best
to address a specific business issue or scenario. Imagine a scenario where a business has outsourced
certain capabilities to a supplier and that supplier is the victim of a ransomware attack. Knowing which
business units relied on the capabilities provided by the supplier would allow the organization to
quickly assess the impact of that event and to respond accordingly. The same multi-dimensional view
could be used for other business scenarios too, such as business unit consolidation or even divestiture
when an outsourced capability no longer adds value.

One of the most important cross-mapping blueprints is the value stream/capability cross-mapping.
This blueprint pinpoints the specific capabilities that enable value delivery at each stage of a value
stream. If a value stream that delivers customer value is underperforming, the value stream/capability
cross-mapping enables analysts to rapidly decipher the underlying capabilities responsible. While
providing a rapid means of targeting weaknesses in one specific, value-delivery situation, the cross-
mapping perspective also allows a rapid “fanning out” of how this same underperforming capability
may be impacting customer value within other value streams.

By cross-mapping different core domains, combining two or more dimensions into a new combined
blueprint, a host of complex questions can be answered confidently and quickly. By using these cross-
dimensional views of the business architecture, organizations can shine light on a range of scenarios
that might be encountered, including but not limited to, business model realignment, digital
transformation, globalization, and merger and acquisition analysis.

The remainder of this paper will present the domains defined by the Guild metamodel, showing how
to attain the above-described features.

August 2020 12 Copyright ©2020 Business Architecture Guild®

The Business Architecture Metamodel Guide

5. BUSINESS ARCHITECTURE DOMAIN ASSOCIATIONS

The ten domains in our knowledgebase are related to each other. The metamodel elements and
relationships are defined in the metamodel to represent the knowledge stored in the knowledgebase.
This section explains the domains and the connections between those domains.

5.1 INTRODUCING THE BUSINESS ARCHITECTURE METAMODEL

Figure 6 provides a high-level overview of the relationships among nine of the ten business architecture
domains: capability, value stream, information, organization, stakeholder, initiative, product, strategy,
and policy.

Figure 6: Overview of Business Architecture Metamodel

Figure 6 depicts high-level domain relationships. The individual domain perspectives that follow later
in this section provide more details for each domain and across domains. For example, capability
domain details include instance, behavior, and outcome. These details are essential to be able to apply
business architecture to a wide variety of business scenarios.

Figure 6 applies a color-coding scheme to group elements associated with a given domain. For example,
capability and outcome share one color, while value stream, value proposition, value stream stage,
and value item share another. This color-coding scheme, which includes elements unaffiliated with a
given domain such as business object, is shown in figure 7.

August 2020 13 Copyright ©2020 Business Architecture Guild®

The Business Architecture Metamodel Guide

Information
Value Capability Organization
Concept

Stakeholder Product Strategy Initiative

Business
Policy
Object

Figure 7: Metamodel Domain Color-coding Scheme

The following sections and corresponding figures apply this color-coding scheme to ensure proper
associations within and among domains. Business object is used in various other domains and has a
neutral color of white.

As shown in figure 3, metrics is a business architecture domain. The Guild’s business architecture
metamodel does not specify or require any business metrics, although examples are provided in the
BIZBOK® Guide. Rather, it allows organizations to define a wide range of metrics that may be derived
from the rich tapestry of information collected in a given knowledgebase. For example, the BIZBOK®
Guide discusses metrics such as effectiveness, impact, and breadth of coverage ratings.

The metamodel provides a mechanism to use those libraries, including upcoming and not yet
established measurement libraries for business architecture. We will not discuss metrics as a domain
any further in this whitepaper.

5.2 VALUE S TREAM

Organizations exist to provide value to customers and other external and internal stakeholders, making
value an important focal point for business architecture. Value streams provide end-to-end
stakeholder value delivery perspectives, with one value proposition per value stream (refer to the
sidebar that discusses differences between value streams and value chains). Figure 8 breaks down the
value stream domain and various relationships.

Value Stream
Value Stream contains enables Capability
Stage

triggers participates in

experienced
delivers achieves
Stakeholder through

desires

Value accrues is assigned

into
Value item Outcome
Proposition to

Figure 8: Value Stream Associations

August 2020 14 Copyright ©2020 Business Architecture Guild®

The Business Architecture Metamodel Guide

The triggering stakeholder triggers the value stream to obtain a value proposition. Capabilities enable
the value stream stages found within a value stream. Capabilities deliver outcomes that contribute to
the value item(s) delivered by each stage. Value items are observable by the participating stakeholders.
Value items contribute to or accrue towards the value proposition desired by the triggering
stakeholder. A value item is a connecting element between two or more stages in the value delivery
process. A value stream stage's entrance criterion is defined by requiring a value item before it can
start and by not finishing until the value stream stage has delivered another value item (the exit
criterion).
In a world of limited resources, a business needs to ensure that the resources assigned to achieve a
specific outcome add value to the triggering stakeholder. It follows that resources allocated to
capabilities which are not enabling a value stream stage are, per definition, not adding value. In the
words of Peter Drucker:

"There is nothing so useless as doing efficiently that which should not be done at all."

5.2.1 VALUE STREAM CROSS-MAPPING

Value stream cross-mapping establishes a basis for strategy impact analysis, initiative and investment
scope determination, business design efforts, and requirements definition and solution deployment.

• Cross-mapping between value stream stage and

capability is one of the most useful cross-mappings. It Value Streams and Value Chains
highlights which capabilities enable a value stream
For readers not familiar with the principles
stage to deliver a value item(s).
of business architecture as laid out in the
BIZBOK® Guide, it is essential to
• Cross-mapping capability outcome to value item differentiate between the "business
highlights the capabilities that play a role in delivering architecture value stream" and a "value
stakeholder value and subsequently become a target chain". A value chain is concerned with how
for capability-based planning and investment? a specific organization obtains the highest
profit and how it uses resources in
transforming inputs to outputs.
• Cross-mapping between stakeholder, value stream,
and value proposition highlights which stakeholder The business architecture value stream also
differs from the "Lean value stream". Lean
desires a given value proposition and triggered the
value streams provide a means to analyze
value stream to deliver that value proposition. waste in existing operations and focus less
on providing actual stakeholder value.
• Cross-mapping between stakeholder and value
It also differs from a “Scaled Agile
stream stage identifies the stakeholders who Framework (SAFe) value stream” which is
participate in that value stream stage and contribute concerned with operational or the
to the delivery of value item(s) for the stakeholder development value stream employed on
who triggered that value stream. projects.

Business architecture value streams are

5.2.2 VALUE STREAM EXAMPLE goal-oriented, targeting the end objective
of delivering the value proposition from the
Value streams provide a comprehensive view of end-to-end
perspective of the ecosystem. The ordering
value delivery to customers, partners, and internal of value stream stages is guarded by
stakeholders. Figure 9 depicts three value streams for a defined entry and exit criteria for each
commercial airline: Take a Trip, Send Shipment, and Execute value stream stage.
Route.

August 2020 15 Copyright ©2020 Business Architecture Guild®

The Business Architecture Metamodel Guide

Take a Trip encapsulates the end-to-end experience of a customer completing a journey, including
multiple stopovers and route changes. Send Shipment encapsulates the journey of a shipment, which
can be a package, freight, or luggage, bundled collectively or shipped individually along different routes
as a single shipment. The airline, which in this example moves people, packages, and freight, would
use these value streams to examine and improve customer satisfaction.

Figure 9: Example Transportation Value Streams vi

These value streams, which appear as simple pictures, represent a formal description of how
stakeholder value is delivered. They include the value stream stages, triggering stakeholder, and value
proposition, as well as value stream stage entrance and exit criteria, value items that accrue to achieve
the value propositions, and the stakeholders that contribute to value at each stage. Not shown are the
many capabilities that enable value accrual at each stage of the value stream.

Consider the first example of a customer taking a trip. The customer would plan the trip in stage 1,
acquire a ticket in stage 2, which equates to ensuring the ability to travel, and then travel to multiple
destinations through multiple iterations of departures and arrivals. Upon arriving at the final
destination, the customer’s trip would terminate.

If the customer checks luggage, it initiates the Send Shipment value stream, which is the end-to-end
journey of the luggage, independently traveling to its own destination. A separate value stream is used
for the luggage because the value proposition differs and the luggage is on a unique trip that differs
from that of the customer. While the customer and their luggage are on their journeys, the airline
would be moving multiple conveyors (e.g., planes, shuttles, trams) across multiple routes, with each
conveyor traveling through a unique instance of the Execute Route value stream. Capabilities would
match the customer and the luggage (i.e., shipment) to various conveyors; as the conveyors change
locations, the customer and the luggage simultaneously change locations by virtue of these matching
capabilities.

The value streams shown in figure 9 work for commercial airlines, shipping companies, railroads, urban
transport operators, and cruise lines. When a company seeks to improve the customer experience, or
increase the operational efficiencies of that experience, the value stream provides the lens into the
capabilities requiring analysis, improvement, and investment.

August 2020 16 Copyright ©2020 Business Architecture Guild®

The Business Architecture Metamodel Guide

5.3 CAPABILITY
Capabilities represent the basic building blocks of the business. These building blocks can be used,
improved, rearranged, and leveraged in a variety of ways to achieve an infinite range of business
objectives. To do that, a business must first define those building blocks.

A capability is what the business does. The business architecture practitioner is advised to take
particular care to define this concept. The BIZBOK® Guide gives the practitioner guiding principles,
tools, and techniques to identify these critical architectural building blocks. Crucially, capabilities are
identified through a business's value streams, and there is only one set of capabilities for each
organization.

Capabilities are identified with a business object in focus. For example, if there is a capability such as
"Customer Management", this capability has the business object "customer" in focus. Any
decomposition of this capability will not change the focus on customer. For example, child capabilities
under Customer Management may include the ability to "define a customer", “determine customer
related risks”, or "capture customer preferences". In no case would a child capability of Customer
Management veer outside customer scope. For example, Customer Management child capabilities
would not manage agreements, products, financial accounts, or other business objects.

Each business ecosystem has one, and only one, set of capabilities. In other words, one capability map
crosses all business units and, where applicable, partners that deliver outsourced capabilities. In most
organizations with multiple business units, each business unit will have or plan to have various
implementations of a capability. For example, a business with two business units, with different
numbers and types of customers, will most likely have implemented the capability of "Customer
Information Management" differently. Therefore, a capability must be connected to the specific
activities of the business to support problem analysis and solution formulation. This connection is
made through three perspectives:

• Capability Instance: An occurrence of where business units or partners implement a capability

in the real world

• Capability Behavior: How a capability instance works in context

• Outcome: The end result that is produced by a capability

Figure 10 breaks down the capability domain. The capability instance inherits the properties of the
capability so it can produce and consume outcomes from other capabilities. In other words, an instance
realizes the capability in practice. A business unit delivers its instance of a capability. It follows that an
organization with many business units may have many instances of an implemented capability. So, the
effectiveness and efficiency (use of resources) for each capability instance can be analyzed. The
capability map captures organizational capabilities and is an important blueprint that is derivable from
the knowledgebase. Capability definition and decomposition, starting at level 1, is enabled by the
capability “decomposes into” capability relationship in figure 10.

August 2020 17 Copyright ©2020 Business Architecture Guild®

The Business Architecture Metamodel Guide

Business Object

decomposes
into based on

Capability
characterizes Capability needs
Behavior

staffs characterizes realizes achieves

Capability
Organization staffs Outcome
Instance

Figure 10: Capability Associations

The capability instance represents a bundle of real-world implementations of that capability. The
behavior describes how that capability acts from a procedural, process definition, policy, and norm-
based standpoint.

Capability is based on a business object. A single piece of behavior will rarely coincide with the life cycle
of a business object. For example, the outcome of the “Customer State Management” capability might
express the state of the business object “Customer” to be “Active”. Another capability outcome might
express a state on the same business object to be “Rejected”. The concern of capabilities and capability
behavior is the creation of value and resources needed to enable value delivery. For example, the
action of sending out a welcome letter to new customers can be triggered by the business object
“Customer” being in the state “Approved.” Approval or rejection across different business units may
be achieved in different ways for the same capabilities, and this is represented by the association
between capability instance and capability behavior.

Capability is an abstraction of the ability to produce an outcome. It aggregates all the specific activities
that provide the same outcome. It does not specify behavior and does not determine resources. It
allows the business executive to summarize all of the specific activities that produce an outcome, to
identify systemic problems in these activities, such as insufficient staffing, poor support from IT, or lack
of experience, and formulate general approaches to solving systemic issues. One common technique
employed by the business architecture practitioner is to create effectiveness ratings or metrics to
indicate the performance of a capability instance or differentiate between as-is and to-be versions,
where a behavior is improved to achieve a business objective.

Viewing a business through a capability perspective involves looking at the business at rest, while
looking at the business from the value stream perspective involves looking at the business in motion.
One or more capabilities enable the value stream stages to provide value items, which in turn connect
the value stream stages to the end-to-end delivery of the value proposition.

5.3.1 CAPABILITY CROSS-MAPPING

August 2020 18 Copyright ©2020 Business Architecture Guild®

The Business Architecture Metamodel Guide

• Cross-mapping between capability and organization highlights which business units or partners
deliver the capability. When expanded to capability instances, it identifies how many different
implementations of the same capability exist in an organization.

5.3.2 CAPABILITY EXAMPLE

The transportation example discussed in section 5.2.2 highlighted a traveler scenario in which a
customer took a holiday with multiple stopovers involving multiple modes of transport or conveyors,
and checked luggage at various intervals. A number of capabilities are required to plan, contract, and
complete the customer’s journey. A key subset of these capabilities is shown in figure 11.

Customer Trip
Management Management

Plan Route Shipment

Management Management Management

Agreement Conveyor Shipment Item

Management Management Management

Figure 11: Sample Transportation Capabilities vii

Consider the end-to-end perspective depicted in the Take a Trip value stream introduced in figure 9.
Capabilities are required to enable the customer to take the trip and manage every aspect of the
customer experience along the way. Figure 11 highlights seven level 1 capabilities and one level 2
capability called Shipment Item Management, where this capability is a child of the level 1 Shipment
Management capability. The roles of the subset of capabilities required to enable such a journey are
highlighted in figure 12.

Capability Role in Transportation Scenario

Customer Management Establishes the customer; validates eligibility; determines and sets preferences; recognizes
the customer going forward; and maintains profile, type, state, and history.
Plan Management Establishes and tracks a formal plan for the trip.
Agreement Management Establishes, provides access to, prices, sets terms, and enables a customer to travel based on
a formal contract.
Trip Management Established upon customer engagement, the Trip Management capability manages risk,
preferences, access, profile, and state transitions through the journey until the trip is
terminated.
Route Management The trip, customer, luggage (shipment), and conveyor all travel along routes. This capability
sets beginning and endpoint locations, tracks risks, and can change dynamically.
Conveyor Management Conveyor is the mode of transport where the company may move the customer in planes,
trams, buses, or rental cars. Each conveyor trip travels a path through the instance of the
Execute Route value stream, often on a fixed schedule. The customer is matched to a given
conveyor in advance or as required based on shifting conveyor schedules.
Shipment Management Shipment in this example would be the customer’s luggage, which may be formally shipped in
advance or ad hoc at check-in. A shipment goes on a different trip than the customer, on the
same or a different conveyor, with its trip being completed in the Send Shipment value
stream.

August 2020 19 Copyright ©2020 Business Architecture Guild®

The Business Architecture Metamodel Guide

Capability Role in Transportation Scenario

Shipment Item Where a customer checks multiple pieces of luggage, each piece is tracked independently in
Management (child of case they are separated, with each taking unique routes on unique conveyors.
Shipment Management)

Figure 12: Sample Transportation Capabilities and Usage Context

The transportation capabilities in figure 12 enable the three value streams previously shown in figure
9. Additional capabilities associated with partners, transportation networks, messaging, work items,
decisions, and events would augment the work being performed by the capabilities in figure 12. In
order to represent the value stream-enabling relationship, organizations cross-map the collection of
enabling capabilities to each stage of each value stream required to complete the trip, receive the
shipment (e.g., luggage), and execute a given route.

5.4 INFORMATION
The information concept is an umbrella business term that represents the foundational concepts of
several modeling approaches. Some methods use entities, domains, and relations. Other methods use
individuals, classes, and properties. Regardless of the approach, the information concept forms the
business vocabulary, making concepts tangible. This creates consensus and a shared understanding of
what an organization is all about.

To understand the value proposition, we need to understand what information is used to construct
the value proposition. Business value is when information is associated with experience. Information
interpreted by an experienced analyst or algorithm delivers knowledge. While data is often considered
an IT domain concern, business information is the baseline from which business knowledge can evolve.
Business information is transformed into business knowledge when organizations use that information
in context to improve business decision making and respond to challenges. This transformation is
enabled in two ways: training and automation.

An information map can be created and represented in the metamodel and associated with other
business architecture domains. For organizations that strive to become data-driven, it is essential that
the resources employed to deliver value to stakeholders understand the role of information and how
to improve it from a business perspective, particularly the capabilities that impact and deliver
information. Figure 13 highlights relationships between information and related domains.

relates to

Information uses,
Stakeholder defines modifies Capability
Concept

makes explicit achieves

expresses
Business Object state of Outcome

Figure 13: Information Concept Associations

August 2020 20 Copyright ©2020 Business Architecture Guild®

The Business Architecture Metamodel Guide

The information concept is based on a business object, just as capability is based on a business object.
There is a one-for-one relationship between the business objects that form a set of information
concepts within a business ecosystem and the business objects that form the corresponding
capabilities in the capability map. Figure 13 depicts this business object-to-information relationship.

An information map would include relationships among information concepts. This is represented in
figure 13 as an information concept “relates to” information concept relationship. Information
concepts also include the valid information types and information states associated with the concept.

Information concepts cover a wide range of business perspectives, many of which are not represented
in the data associated with IT systems. An example would involve a “decision”; a decision is
represented as an information concept but organizations would be unlikely to record and track every
decision made as IT data. On the other hand, the information map does expose the need in this
example to capture and record substantive decisions made in the course of strategic planning or in
customer or partner dealings. In other words, in business architecture, information has human
knowledge associated with it.

The information concept is the focal point for the capabilities in a capability map. The users of this map
must share the human knowledge (e.g., decision-making skills) of what is being discussed or
considered. The information concept is a passive element of the business that will be affected by
capability behavior through the outcomes of the capability instance.

A common mistake is to use data model(s) typically found in IT departments as a substitute for an
information map. As the previous example highlights, taking a data-oriented approach would omit
critical information from being mapped within a business ecosystem. Lineage between the IT data
architecture and the business information map is part of the business architecture and IT alignment.

5.4.1 INFORMATION CROSS-MAPPING

• Information concepts are cross-mapped to the capabilities that use and modify those
information concepts. The modify/use relationships would be shown in a capability-to-
information concept cross-mapping.

• Information concept is cross-mapped to stakeholder. For stakeholder-oriented information

concepts, such as customer, partner, or human resource, stakeholder categories associated
with those information concepts become information concept types. For example, a customer
may breakdown into customer segments that include retail customers and wholesale
customers. Information concept types align to the stakeholders defined in the stakeholder
map, which are in turn cross-mapped to value stream stages. The important point is that
stakeholders are managed as information within a business architecture.

5.4.2 INFORMATION CONCEPT EXAMPLE

Information is required and modified by various capabilities in order for those capabilities to do their
job. Prior to defining capability dependencies, a business architecture practitioner would incorporate
a formal mapping of information concepts relationships. Figure 14 depicts the relationships among the
subset of transportation information concepts required by the aforementioned transportation
capabilities.

August 2020 21 Copyright ©2020 Business Architecture Guild®

The Business Architecture Metamodel Guide

Figure 14: Transportation Information Concepts viii

The relationships among the information concepts shown in figure 14 align to a cross-section of
transformation scenarios for a given organization, across multiple business models. For example, the
information concept relationships in figure 14 enable a passenger travel scenario and a package
shipping scenario for a commercial airline. A summary of these information concepts is highlighted in
figure 15.

Information Relationship Context

Concept
Customer Customer establishes a plan, executes an agreement to travel, and is associated with multiple conveyors
for each leg of the trip. There may be multiple customers per agreement.
Plan The plan simply reflects the formal or informal trip plan a customer might have and is associated with the
customer and the trip. A conveyor may also have a plan, such as the case with a flight plan.
Agreement The agreement is the contract that tickets the trip for the customer and is associated with the actual trip.
Trip The trip remains active until it is terminated at the end of a journey, has an overall route (including all
destinations), and may be associated with transient artifacts such as a trip itinerary.
Route Routes maybe complex, multi-stop, or non-stop. Routes are associated with anything that travels including
the customer, luggage (i.e., shipment), and the conveyor.
Conveyor Conveyors, based on a given business model, may include planes, trams, buses, or other means of
transport, and represent the main business object transitioning through the Execute Route value stream.
The customer and the luggage are associated directly with a conveyor on which they may travel. Schedule
changes, cancellations, or other situations may require re-matching a customer or their luggage to another
conveyor.
Shipment Shipment is the collective set of items being shipped, which in this scenario is a set of luggage. A shipment
is associated with the same agreement the passenger is traveling on, but may require a second payment.
Shipment A shipment is composed of one or more shipment items, where each one is assigned to a conveyor in case
Item a multi-piece set of luggage is separated. The shipment item travels the route on a given conveyor. When
all shipment items are delivered, the shipment is considered delivered.

Figure 15: Transportation Information Concepts for a Travel Scenario

Information maps depict additional information but concept-to-concept relationships are an important
aspect of defining the information required to ensure capability effectiveness. For example,
organizations and customers have a strong vested interest in knowing which plane a piece of luggage

August 2020 22 Copyright ©2020 Business Architecture Guild®

The Business Architecture Metamodel Guide

(i.e., a shipment item) is traveling on or the corresponding route on which it traveled. The ability to
clearly and consistently identify, track, and relate information across business units, partners, and a
variety of real-world scenarios is essential for organizations to ensure customer satisfaction.

5.5 ORGANIZATION
The organization in today's modern business environment is no longer easily described by hierarchical
models that represent purely internal structures. The businesses that operate today are increasingly
cross-border and leverage strategic partnerships that can cross geographical, corporate, and legal
boundaries.

Organizations bringing together producers and consumers to gain market share. These so-called
platform businesses have changed the competitive landscape. In traditional organizations, the focus
has been on owning and protecting the resources of the organization. For platform businesses, the
critical resource is the community and the resources owned by the community — the focus shifts from
owning the resource to orchestrating the resources amongst platform participants. Platform
businesses create an ecosystem where participants organize themselves for the good of the
community. In a platform economy, companies need to organize in a manner where they can thrive in
a collaborative value-sharing ecosystem.

Management methodologies have shaped the traditional organization, the main objective being to
acquire and protect its resources. Organizations failing to change their management approach to a
‘sharing-is-caring-for-customers’ methodology will struggle to participate in the new paradigm of
collaboration. Organization is one of the core business concepts in business architecture, providing the
Who and What view of a business.

An organization map is used to describe an ecosystem-wide perspective of business units, which can
be internal business units, partners or external units, and collaborations that are often not represented
in hierarchical models. By considering all the business units within the boundaries of the business
activity, the organization map provides visibility into the business and its organizational context. The
map can then provide clarity about the structure of the entire business ecosystem rather than a siloed
view of a business.

The organization map brings similar value to the business architecture practitioner as other mappings
discussed in this paper. The approach considers the whole of the business ecosystem. Strategic
partners, outsourcing arrangements, collaborative teams, and others may all provide business
capabilities that need to be understood. Being able to view an organization map and the relationship
of business units to other core business concepts such as capabilities paints a picture of how an
organization works, rather than how an executive might think it works.

Understanding the structure of your organization from a value delivery perspective, beyond the
confines of your company’s organization chart, is fundamental. Without this whole organizational view
and the ability to cross-reference it to other core business concepts, it will be difficult to see the real
impact of a given course of action. That clearer picture of the organization and its relationships with
other business concepts can then facilitate:

• Issue analysis

August 2020 23 Copyright ©2020 Business Architecture Guild®

The Business Architecture Metamodel Guide

• Business planning
• Solution deployment
• Transformation planning

Organization mapping is not constrained to a specific format. A business unit is considered to be a sub-
type of organization. With the right level of decomposition of business units and consideration given
to horizontal and external relationships (including partnerships and outsourced capabilities), an
organization map is a powerful tool that provides a useful visualization of the organization.
Organizations will need to maintain this map to keep it accurate and applicable across a wide range of
business scenarios. Figure 16 depicts adjacent relationships among an organization, objective, business
unit, and capability.

Owns
decomposes into

Business Unit belongs to Organization pursues Objective

implements
delivers

Capability
realizes Capability
Instance

Figure 16: Organization Associations

Note that a business unit can decompose into more business units, enabling the creation of
organizational hierarchies. The relationship structure in figure 16 is simple, yet coupling the structural
view of an organization with capabilities enables planning teams to view where functional
redundancies exist and may be detrimental to the organization. This view also streamlines rapid impact
analysis during strategic planning exercises.

5.5.1 ORGANIZATION CROSS-MAPPING

• Cross-mapping between organization and objective highlights which objective(s) an
organization seeks to fulfill.

• Cross-mapping between business unit and capability creates a capability instance, highlighting
which business units or partners implement a capability in practice.

5.5.2 ORGANIZATION EXAMPLE

The abbreviated extraction of a transportation organization map shown in figure 17 highlights selected
business units and partners with certain capabilities.

Business Business Unit Business Definition Key Capabilities Associated with Business
Unit Level Unit Type Units
0 Transport Enterprise Global shipping service provider. All
Company

August 2020 24 Copyright ©2020 Business Architecture Guild®

The Business Architecture Metamodel Guide

Business Business Unit Business Definition Key Capabilities Associated with Business
Unit Level Unit Type Units
1 Retail Facility Business Handles the decisioning of credit product Customer Management, Agreement
unit offerings to an organization's client. Management, Shipment Management,
Payment Management, Financial Account
Management
1 Shipping Business Manages shipping and receiving, sort Shipment Management, Asset Management,
Distribution unit center, and logistics control. Human Resource Management
Center
2 Dispatch Center Business Coordinates ground transport, operator Conveyor Management, Route Management,
unit assignments, conveyor assignments, and Human Resource Management, Asset
fleet maintenance. Management
2 Customs Partner Handles the development and Partner Management, Policy Management,
Clearance enhancement of the channel's product Agreement Management, Shipment
Service, Ltd. offerings. Management
2 Network Control Business Controls network design, optimization, Network Management, Route Management,
unit route definition, and incident rerouting. Incident Management

Figure 17: Sample Extract of Transportation Business-to-Capability Cross-mappings

Figure 17 highlights where business units and business partners share capabilities that collectively
contribute to customer and stakeholder value delivery. For example, if there was an objective driving
a planned investment in improving the Shipment Management capability, the scope of consideration
should investigate the use of those capability instances within each business unit depicted in figure 17.
The knowledgebase would quickly highlight the business units that need to be engage in order to
ensure that planning is complete, comprehensive, and scoped effectively.

5.6 STAKEHOLDER
The stakeholders of an organization (this includes commercial business, government, and non-profit
organizations) are the very reason to be in business, so they should be top of mind when thinking about
ways to leverage business architecture.

A key objective of business architecture is to represent the stakeholders within a business. Business
objects such as Customer, Employee, and Partner are usually viewed as stakeholders. But in business
architecture, the concept of stakeholder has a more specific meaning. Stakeholders are either
triggering or participating stakeholders in the context of value streams, as defined in whitepaper
section 5.2, as well as being those who affect or are affected by an aspect of the architecture, e.g., an
initiative.

Stakeholders are identified when defining value streams in terms of:

• Triggering stakeholders of the value stream who desire the value proposition of the value
stream
• Participating stakeholders in the value stream stage who participate in achieving the value item

Note that the concept of being a triggering or participating stakeholder is value stream context
dependent. A given stakeholder may trigger a value stream and participate in that value stream, simply
participate in that value stream, or be absent from the value stream altogether. A major emphasis is

August 2020 25 Copyright ©2020 Business Architecture Guild®

The Business Architecture Metamodel Guide

on identifying stakeholders as individuals as opposed to business units, e.g., a Compliance Officer as

opposed to a Compliance Office.

A stakeholder is further classified by its type – External or Internal. Stakeholders are organized by
category, or according to an information concept, e.g., customer, partner, or human resource. It is
essential to maintain the distinction between the information concept and the stakeholder when
classifying stakeholders. For example, if you have a Customer Management and a Partner Management
capability, we would identify stakeholders to be either customers or partners.

A value stream begins with a stakeholder triggering the first stage of the value stream and ends when
a product or service, notification, a degree of satisfaction, or other communication is delivered back to
that stakeholder. A triggering stakeholder is a category of stakeholder that initiates a value stream to
achieve a stated value proposition. Figure 18 highlights adjacent relationships between stakeholder
and other business architecture domains. It shows where a stakeholder belongs to a business unit,
defines a type of information concept, triggers and participates in a value stream, is impacted by
strategy, or contributes to a capability outcome.

Figure 18: Stakeholder Associations

5.6.1 STAKEHOLDER CROSS-MAPPING

• Stakeholder defines information concept types linked to objects such as customer, partner, or
human resource.

• Cross-mapping between stakeholder and outcome defines who contributes to which outcome.

• Cross-mapping between stakeholder and value stream highlights who triggers that value
stream.

• Cross-mapping between stakeholder and value stream stage highlights who participates and
contributes value within a value stream stage.

• Cross-mapping between stakeholder and business unit defines where stakeholders exist across
an organization or partner organization.

August 2020 26 Copyright ©2020 Business Architecture Guild®

The Business Architecture Metamodel Guide

• Cross-mapping between stakeholder and strategy highlights who is impacted by a strategic

change.

5.6.2 STAKEHOLDER EXAMPLE

Figure 19 depicts an example of stakeholders engaged in the Take a Trip value stream. The customer
triggers the value stream when they engage an organization with an interest in taking a trip. The
customer is also involved in each stage of the value stream as a participant. The customer transitions
through the value stream as their journey progresses and ultimately terminates. Figure 19 also
identifies the other participating stakeholders, each of whom contributes to value accrued as the trip
progresses.
Customer/Travel Agent/Gate Agent/Club Agents/Flight Attendant/Online Agent/Flight Crew

Take a Trip
Ensure Arrive at Terminate
Plan Trip Depart
Permission Destination Trip
Customer

Figure 19: Triggering Stakeholder and Participating Stakeholders in a Value Stream

For example, an airline customer might want to be moved to an earlier flight and approaches a gate
agent with this request. The gate agent would, in a best-case scenario, be able to move the customer
to another flight. In this example, the gate agent would play a role in the Customer/Conveyor Matching
capability that would switch that person to a new flight. The agent would additionally play a role in the
Customer Authorization and Authentication Management capability, allowing the customer to access
a different flight. Other stakeholders, which may be proxied by technology in some cases, would
similarly contribute to value along a journey.

5.7 STRATEGY
The strategy domain encompasses the processes of creation, execution, monitoring, and supervising a
strategic change to aspects of the business. The BIZBOK® Guide and other modern strategic practices
consider strategy creation, initiative planning, and initiative execution and tracking to be of equal
importance. Strategy mapping in the business architecture metamodel focuses on strategy creation
and formulation, whereas initiative mapping addresses initiative planning and execution.

There are two popular techniques in place for execution and monitoring initiatives. One popular
method is the Balanced Scorecard, whereby a business implements a monitoring and measurement
system for strategic initiatives by defining Key Performance Indicators (KPIs). Another popular method
is Hoshin Kanri, a management technique to ensure that there is a shared understanding and
coordination of the strategy execution across the business.

As shown in figure 20, strategy is comprised of objectives, each of which requires and realizes courses
of action. Change, which is the rationale for a given objective, affects a capability, which in turn would
be the target of a strategy.

August 2020 27 Copyright ©2020 Business Architecture Guild®

The Business Architecture Metamodel Guide

Value Stream targets Strategy achieves Objective

targets rationale for needs realizes

Course
Capability Change
affects of Action

Figure 20: Strategy Associations

One or more objectives relate to a strategy. To create strategies, organizations identify strategic
objectives that are decomposed into lower-level objectives and put into the objective map — a tree-
like hierarchy illustrating their relationship and contribution to strategy execution.

A course of action implements a strategy resulting in reaching the objectives associated with the
strategy. In some circumstances, objectives have pre- and post-conditions that need to be satisfied
before starting another course of action. Objectives can depend on each other. The business
architecture practitioner documents the rationale behind changes made to a capability in the course
of action chain, including the justification for the change.

A summary of the figure 20 strategy domain details are as follows.

• Strategy’s association with objective highlights whether the objectives linked to one or more
strategies, where there is no freestanding objective.

• Change is associated with and objective to highlight the rationale and related change impact
of that objective.

• Connecting the course of action with objective identifies the actions to be taken to achieve
that objective as well as the course of action that may be a prerequisite to that objective.

5.7.1 STRATEGY CROSS-MAPPING

• Cross-mapping strategy to capability identifies the capabilities impacted by strategy, which
could be further decomposed by the objectives associated with that strategy.

• Cross-mapping change to capability highlights the behavioral impacts or improvements to be

associated with one or more capability instances.

• Cross-mapping strategy and a value stream identifies the value-related impacts or

improvements that this strategy will deliver within a value stream.

5.7.2 STRATEGY EXAMPLE

Figure 21 provides an example of the relationships between an objective and its impact points, and
includes the goal as well as the corresponding course of action, KPI, and the value stream and capability
impact points.

August 2020 28 Copyright ©2020 Business Architecture Guild®

The Business Architecture Metamodel Guide

Strategy Impact Analysis Template

Value Stream
Goal Objective KPI Metric Course of Action Impacts Capability Impacts
Consolidate Shipment Item Definition
Reduce lost shipment shipment item Shipment Item Access Management
Ensure that items when shipments tracking across Shipment Item/Location Matching
shipments break apart in transit Lost Shipment business units and Shipment Item/Conveyor Matching
arrive intact to .05% Item Percentage partners Send Shipment Shipment Item/Partner Matching

Figure 21: Strategy to Value Stream and Capability Impact Tracking

This example highlights where a goal of ensuring that shipments arrive intact is realized by a clearly
stated objective and a KPI stating that lost shipment items (in scenarios where a shipment is
inadvertently separated) is reduced to .05% of the time. The course of action, to consolidate shipment
item tracking across business units and partners, points to the capabilities that focus on shipment item
tracking (shown on the far right of the table) along with the targeted value stream.

Organizations would, based on this analysis, examine the effectiveness and related metrics associated
with each of these capabilities across every business unit and partner instance. The metamodel
provides the underlying tracking mechanism for many such business scenarios, and allows
organizations to scale this analysis to fully define the scope and related investment impacts of various
business goals and objectives.

5.8 INITIATIVES
Initiatives represent the execution of strategy. Initiatives are the choices an organization has made to
achieve the objectives of a strategy.

An initiative is often known as a program, project, or portfolio, and responsibility for execution often
lies with a Project Management Office (PMO). The PMO typically has the responsibility for coordinating
program and project planning, prioritization, implementation, and tracking. Monitoring includes
assessing how well an organization is delivering its milestones across the initiatives in a portfolio.
Organizations often track performance against plan using tools like the Balance Scorecard. ix

The operational role of the PMO is an essential function, but only one piece of the process of governing
initiatives. Though doing things right by being efficient is crucial, what if the initiative fails to do the
right thing? It will not be effective. Only effective initiatives will deliver the strategy. Measuring
efficiency, the focus of agile development methods, is relatively easy. Measuring effectiveness, the
focus of business architecture, is much tougher.

The strategy defines the objective to be achieved by initiatives, and initiative is a type of course of
action. Initiatives will deliver a value item and impact or require one or more capability outcomes. A
business unit has different roles in relationship to initiatives. A business unit executes and/or funds an
initiative; an initiative can impact a business unit.

August 2020 29 Copyright ©2020 Business Architecture Guild®

The Business Architecture Metamodel Guide

Initiatives impact a value stream stage because the value item is a logical focal point for initiative
investments. Initiatives also target value stream stages as a way of rapidly filtering the initiative-
impacted capabilities that enable that value stream stage and contribute to the value item. Finally,
highlighting the value stream stage impacts of an initiative shows which participating stakeholders may
be impacted by an initiative; where those stakeholders become targets for improving how they engage;
the roles that they play; the automation they require; and the requirements they communicate to
deployment teams.

Figure 22 summarizes the direct impacts between business unit, objective, course of action, capability,
and value stream stage and the initiative. As with other domain associations, only the initial point of
impact is represented in figure 22. Expanded associations would be represented in the other domain
models.

Figure 22: Initiative Associations

In practice, a business unit with a set of objectives would target a given initiative. The initiative in turn
would effect changes to behaviors associated with capability instances for that business unit. Initial
impact assessments typically target the value stream stages, which would then be used to highlight
relevant enabling capabilities for those value stream stages.

5.8.1 INITIATIVE CROSS-MAPPING

• Cross-mapping between initiative and value stream stage highlights which value stream stage
is impacted by an initiative and indirectly which initiative delivers the value item.
• Cross-mapping between initiative and objective highlights which objective is realized by which
initiatives and, as initiative is a type of course of action, which initiative groups the course of
action.
• Cross-mapping between initiative and capability highlights which capability is impacted by the
initiative and which initiative requires which capability.
• Cross-mapping between initiative and business unit highlights which business unit sponsors or
executes which initiative and which initiative impacts which business unit.

August 2020 30 Copyright ©2020 Business Architecture Guild®

The Business Architecture Metamodel Guide

5.8.2 INITIATIVE EXAMPLE

Initiatives are aligned to deliver one or more business objectives, often funded by a particular business
unit. The objective or objectives to be realized by an initiative would target the impacted value stream
stages and capabilities necessary to impact change. Figure 23 depicts an example of a transportation
company initiative along with related business impacts.

Figure 23: Initiative Mapping to Business Unit, Objective, Value Stream Stage, and Capability
In this example, the Customer Service business unit is seeking to expedite and simplify the ability to
change a trip route and flight through any channel, at any point in a trip. Based on this objective, the
value stream provides an insight into the two value stages, Depart and Arrive at Destination, where
the customer engages throughout the life of one-way, multi-stopover, or multi-destination trip. A
program planning team would then identify the enabling capabilities for these value stream stages to
highlight the capability-related investments for that initiative. These capabilities include Agreement
Management, Trip Management, Customer Management, and Route Management. The capabilities
will rematch the customer to a conveyor, meaning that conveyor information is used to reroute the
customer to an alternative route and flight.

5.9 POLICY
Policy plays a vital role in doing business in many organizations, especially in highly regulated areas like
banking or the public sector.

Policy categorizes into internal and external policies.

• Internal policies are set and maintained by an enterprise’s internal organizational structures.
These are usually not dependent on sources outside an enterprise.

August 2020 31 Copyright ©2020 Business Architecture Guild®

The Business Architecture Metamodel Guide

• External policies are mostly edicts that must be implemented and complied to, such as a
regulation, an industry praxis, or a commercial agreement. Non-compliance is usually
associated with some damage to the reputation or finances of the business.

Conformance to external and internal policies is controlled by a governance process.

Figure 24 highlights the relationships between policy and stakeholder, capability, objective, and
business unit.

associated to

decides/ Business
Stakeholder determines Policy adopts
Unit

influences guides

Capability Objective

Figure 24: Policy Associations

The relationship showing that a policy is associated with a policy depicts a derivative relationship. For
example, an organization may establish a set of internal policies associated with federal regulations,
treaties, or statutes, each of which is also a policy. The internal rule may be associated to these external
policies to identify the lineage between, for example, a statute and the internal rules meant to comply
with that statute.

5.9.1 POLICY CROSS-MAPPING

• Cross-mapping between policy and business unit highlights which business unit adopts which
policy.

• Cross-mapping between policy and capability highlights which policy influences which
capability.

• Cross-mapping of policy and stakeholder highlights which stakeholder decides/determines

which policy.

• Cross-mapping policy and objective highlights which policy guides which objective.

5.9.2 POLICY EXAMPLE

Policy mapping connects legal, regulatory, or corporate policies with potential commitments and
liabilities that organizations must incorporate into their investment model. The example in figure 25
depicts three internal policies concerned with changes to travel industry regulations.

August 2020 32 Copyright ©2020 Business Architecture Guild®

The Business Architecture Metamodel Guide

Policies Capabilities Shipment Item /

Conveyor Matching
Realtime tracking of Shipment
shipped items, luggage Management
Shipment Item /
Route Matching
Realtime tracking by
location, route, flight Shipment Item Shipment Item /
Management Location Matching

Increased reimbursement Shipment Item

amounts for lost luggage Risk Management
Agreement
Management Shipment Item
History
Management

Information Concepts

Agreement Shipment Shipment Item Route

Policy Location Conveyor Trip

Figure 25: Policy Mapping Scenario Example

Using policy mapping, an organization can target the capabilities impacted by those policies as well as
the impacted information concepts used and modified by those capabilities. For example, a policy
associated with tracking individual pieces of luggage impacts the Shipment Item Management
capability and the information used by that capability. Capabilities directly impacted include Shipment
Item Management, Shipment Item/Conveyor Matching, Shipment Item/Route Matching, Shipment
Item/Location Matching, and Shipment Item History Management. The policy may also call for
resetting acceptable levels of risk for a shipment item, impacting Shipment Item Risk Management. A
second policy increasing reimbursement amount exposure to the company for lost luggage would
directly impact the Agreement Management capability to address agreement terms.

Once a set of policies are traced to the impacted capabilities and information concepts, impact
assessment teams can trace the impacts on value streams enabled by those capabilities; business units
associated with instances of these capabilities; and impacted stakeholders associated with those value
streams and business units, systems that automate those capabilities, and data representing the
impacted information concepts.

5.10 PRODUCT
From the customer perspective, product is the overall experience provided by the combination of
goods and services to satisfy that customer's needs.

In business architecture, a customer is the external recipient of a product rather than an internal
stakeholder. A product may be accompanied by entitlements, such as installation, warranties, or other

August 2020 33 Copyright ©2020 Business Architecture Guild®

The Business Architecture Metamodel Guide

services provided through a product lifecycle – reaching many years beyond the purchase date. An
organization must, therefore, have specific capabilities to provide the product and then capabilities to
offer those after-sales entitlements.

Products may belong to a product line with similar characteristics or that target a particular buyer. But,
in the same way that companies may outsource some of their capabilities, so too can they outsource
the supply of products, with companies increasingly selling products that they don't manufacture
themselves.

For example, many consumers purchasing a product over the Internet see the ability to deliver a
shipment as an entitlement. The customer's experience will be defined by the sum of the organization’s
capability outcomes. It answers the question of how well they work individually and together in an
orchestrated delivery of value.

By incorporating these product concepts into business architecture through product mapping, there
are several benefits for a business, particularly for companies that are product-focused. Visibility of the
product ecosystem provides clarity when considering how well supported, delivered, or aligned the
products and product lines are.

Product maps provide the basis for further cross-mapping with other business architecture domains.
For example, product mapping allows the business to investigate not only the relationships between
products and product lines, but also to see which products are delivering the most value to customers.
Understanding these relationships can support businesses in making the right investment decisions
when targeting new markets and segments. Product mapping provides a focus for reviewing and
optimizing sales and service value streams such as product design and creation.

Business architecture provides a framework for formalizing product management and provides
visibility into complex products and product lines, as well as critical capability dependencies and an
organizational perspective. This increased visibility also offers a view of value, initiative, and strategy
mapping that may not otherwise exist.

Product Line Business Unit Entitlement

delivers
may contain enables
Is part of

Value relates to Capability

delivers Product
Proposition Instance

impacts
impacts enables realizes

Initiative Strategy Capability

Figure 26: Product Associations

August 2020 34 Copyright ©2020 Business Architecture Guild®

The Business Architecture Metamodel Guide

The product mappings shown in figure 26 enable an organization to validate the ability to roll out a
new product based on existing capabilities, highlight underperforming products and related
underperforming capabilities, and target investments for improving existing products and deploying
new products.

Two product mapping relationships are of particular importance when defining a product mapping.
The “relates to” association between product and product indicates which product complements, is
similar to, or bundles another product. The association between product and entitlement highlights
the specific customer commitments that a customer is entitled to under the terms of a given product.
A product can be grouped into a product line, which may be added to a metamodel. Product line is a
standard organizing structure for products.

5.10.1 PRODUCT CROSS-MAPPING

The following product domain cross-mapping provides insight and context for product-based
investments, targeted at improving the customer experience while streamlining product delivery and
performance.

• Cross-mapping between product and capability highlights which capability enables which
product.
• Cross-mapping between product and organization highlights which organization is responsible
for providing and delivering a given product.
• Cross-mapping between product and strategy highlights which strategy impacts a given
product.
• Cross-mapping between product and initiative highlights which initiative impacts a given
product or products.
• Cross-mapping between capability and entitlement clarifies the capability needed in order to
deliver on a given product entitlement.

5.10.2 PRODUCT EXAMPLE

Product mapping has many uses, one of which is new product planning. When a new product is
proposed by Marketing or the Product Management team, a rapid assessment of the impacts, viability,
costs, risks, and other considerations associated with that product is warranted. Figure 27 highlights
an example of product to capability mapping.

August 2020 35 Copyright ©2020 Business Architecture Guild®

The Business Architecture Metamodel Guide

Capabilities Agreement/
Conveyor Matching
Partner
Management Agreement/Route
Matching
Product
Management Agreement/
Facility Matching

Product Channel
Management Agreement/
Partner Matching
Air, Hotel, Rental Facility
Management Agreement/Trip
Car Package Agreement
Matching

Management Partner/Location
Matching
Conveyor
Management Partner/Conveyor
Matching
Route
Management Partner/Facility
Matching
Trip
Management Trip/Route
Matching
Location
Management

Figure 27: Product Mapping Scenario Example

This example considers an airline that, working with its partners, is seeking to offer its customers a full-
service travel package. The package would include airfare, hotel reservations, and a car rental. While
the hotel and car rental would be provided through partners, the airline must still accommodate the
full-service package: packaging pricing; flight, hotel, and vehicle reservations; and other options
through its portal. This is a new offering for the airline, and they want to perform an impact analysis
for what it would take to launch this package.

Figure 27 highlights some of the capabilities involved in the assessment. An agreement would need to
reference the flights, routes, hotel reservations, and car rental times, locations, and commitments.
These are addressed via Agreement Matching capabilities. In addition, the airline would require
Conveyor Management to be expanded to vehicle tracking, and Facility Management to be expanded
to hotel properties. Partner relationships via Partner Management would also be required.

The impact analysis is the first step in pointing to the work to be done to deploy such a product offering
to the airline’s customers. Secondary analysis would look at specific instances, partner relationships,
policy impacts, information impacts, and technology impacts associated with these capabilities. In this
way, product mapping provides a way to quickly incorporate business architecture into marketing,
product planning, and related activities at a company.

August 2020 36 Copyright ©2020 Business Architecture Guild®

The Business Architecture Metamodel Guide

6. SUMMARY
Business architecture is an abstraction of real-world things described in a business model. To ensure
that all participants understand and share the same mental model of that business requires a
rationalized, clearly-defined vocabulary, value delivery model, and related perspectives. A metamodel,
or model of a model, which is the main topic of this paper, defines the comprehensive set of domains,
the underlying domain relationships, and usage rules for defining the model of a business.

There is more to the practice of business architecture than providing this model of the business;
modeling results must be made accessible and framed by specific business scenarios to solve the
challenges at hand. Meeting this overall goal requires storing the business domains and associations
into a readily accessible business architecture knowledgebase while maintaining the integrity of
modeled domains and relationships. To organize the business architecture knowledgebase, a
comprehensive representation of an organization is separated into ten domains: four core domains
and six extended domains. Information about the business is modeled along these domains into
blueprints or maps. Relationships among these domains are organized in cross-mappings in order to
answer multidimensional questions of business professionals ranging from strategic planners to
designer and solution deployment teams.

Business architecture focuses on the value for a consumer or customer from an outside-in perspective
of the value provider. This unique perspective enables the viewing of consumer value delivery and all
work associated with improving upon that value delivery to be viewed from an ecosystem-wide
perspective across business units, partners, and related perspectives.

Value, capability, information, and organizational domains work in lockstep to deliver consumer value.
Value streams define what stages are necessary to achieve the consumer value proposition. Value
stream stages are enabled by capabilities, which in turn are delivered by business units, which are part
of an organization, i.e., the value provider. Information is closely aligned to capabilities that require
and effect that information. Cross-mapping capabilities to value streams and business units is a
powerful means for targeting and improving organizational weaknesses, capitalizing on opportunities,
dealing with threats, and maximizing organizational strengths.

The remaining business architecture domains organize around stakeholder, strategy, initiative, policy,
and product. Metrics, while not covered in this whitepaper, are integral to the use of business
architecture and are context-dependent. Stakeholders are differentiated into triggering and
participating stakeholders, serving as a focal point for connecting value delivery, strategy, business
unit, capability via outcomes, and information.

Strategy mapping enables business objectives to target one or more business units, impacted
capabilities, or one or more value streams. The ability to view strategic impacts across these domains
broadens the focus of strategic planning and impact analysis, shifting the focus from a single business
unit onto the organization as a whole, ensuring that the scope of any investment is clearly defined and
attainable. Once a strategy is defined and validated for impacts, the scope of initiatives (programs and
projects) may be established with clarity and confidence.

Policy mapping ensures that the impacts of legislation, statutes, treaties, and regulations are
considered at every stage of strategic planning and execution. Finally, product is the overall experience

August 2020 37 Copyright ©2020 Business Architecture Guild®

The Business Architecture Metamodel Guide

from the customer’s perspective, and is defined as a combination of goods and services provided to
that customer to deliver value. Cross-mapping product to business unit, capability, strategy, and
initiative opens up interesting options to identify new business opportunities.

Modeling an organization using business architecture is a multidimensional, multidisciplined effort that

evolves over time based on the priorities of a given organization, ensuring that tools, techniques, and
human skills are maximized for success. Although it is possible to set up the knowledgebase with
spreadsheets, scaling such a knowledgebase for anything other than a simple and very small enterprise
is impractical. The use of a modeling tool that can capture, store, cross-map, and provide access to the
business architecture is highly recommended in order to support scalability. A variety of tool vendors
have the ability to enable the knowledgebase views defined in this whitepaper.

Organizations can jumpstart their business architecture mapping efforts using industry reference
models available from the Business Architecture Guild®. Using the reference models as a baseline or
starting point enables organizations to move through the startup phase of business architecture in a
very short period of time. All reference models are designed and mapped to align to the formal cross-
mapping domain structures described herein. Using the formally defined business architecture
framework, business architecture knowledgebase, and accompanying metamodel defined in this
whitepaper will allow organizations to quickly and effectively launch and maximize the value of a
business architecture practice.

August 2020 38 Copyright ©2020 Business Architecture Guild®

The Business Architecture Metamodel Guide

Glossary of Terms
The following glossary provides definitions for certain terms used in the Metamodel Guide. The terms
are drawn from the BIZBOK® Guide, Appendix A: Glossary. x
Business Ecosystem
One or more legal entities, in whole or in part, that exist as an integrated community of individuals and
assets, or aggregations thereof, interacting as a cohesive whole toward a common mission or purpose.

Business Object
A representation of a thing, including at least its business name and definition, attributes, behavior,
relationships and constraints, which may represent, for example, a person, place, or concept.

Business Unit
A logical element or segment of a company (such as Accounting, Production, or Marketing)
representing a specific business function and a definite place on the organizational chart under the
domain of a manager. Also called Department, Division, or Functional Area.

Capability
A particular ability or capacity that a business may possess or exchange to achieve a specific purpose
or outcome.

Information Concept
The way to represent business terms and semantics within the context of business architecture.

Initiative
A course of action that is being executed or has been selected for execution.

Knowledgebase
A combination of process, structure, and a logical warehouse for capturing, assimilating, viewing,
and sharing a wide range of information that can be used to inform business strategy, optimize
business planning through execution, and guide transformation efforts.

Model
A visual and/or data representation of a real-world thing or category of real-world things.

Metamodel
The abstract syntax of a class of models.

Organization
A social unit of people, systematically structured and managed to meet a need or to pursue
collective goals on a continuing basis.

Objective
A quantitative, measurable result that defines strategy.

August 2020 39 Copyright ©2020 Business Architecture Guild®

The Business Architecture Metamodel Guide

Outcome
An end-result or final product that is a consequence of an event, action, or a series of events and
actions.

Policy
A course or principle of action adopted or proposed by a government, party, business, or individual.

Product
The overall experience provided by the combination of goods and services to satisfy the customer's
needs.

Stakeholder
An internal or external individual or organization with a vested interest in achieving value through a
particular outcome.

Strategy
The pattern or plan that integrates an organization's major goals, policies, and action sequences into
a cohesive whole.

Value Item
The judgment of worth, made by an individual or organization, attached to something tangible or
intangible and attained in the course of a particular interaction with one or more parties.

Value Proposition
An innovation, service, or feature intended to make a company, product, or service attractive to
customers or related stakeholders.

Value Stream
An end-to-end collection of activities that create a result for a customer, who may be the ultimate
customer or an internal end-user of the value stream.

Value Stream Stage

A distinct, identifiable phase or step within a value stream that has a unique name, entrance criteria,
exit criteria, and identifiable participating stakeholder(s).

August 2020 40 Copyright ©2020 Business Architecture Guild®

The Business Architecture Metamodel Guide

About the Business Architecture Guild®

The Business Architecture Guild® is an international, not-for-profit, and member-driven professional
association that provides valuable resources to business architecture practitioners and others
interested in the profession. Formed in 2010, the Guild’s primary purpose is to promote best practices
and expand the knowledgebase of the business architecture discipline. The Guild is the source for A
Guide to Business Architecture Body of Knowledge® (BIZBOK® Guide), the go-to guide for business
architecture practitioners and other professionals seeking to leverage the discipline.

The Guild is active in industry standards programs and partners with related professional associations
to further its purpose. In addition to the BIZBOK® Guide, the Guild offers a Business Architecture
Maturity Model® (BAMM®), Business Architecture Tool Evaluator™, and business architecture
reference models for various industry sectors including financial services, healthcare, insurance,
government, manufacturing, transportation, and a common industry reference model. All Guild-
produced content, including the industry reference models, is developed by its members. In addition
to these resources, the Guild has a vendor partnering program, a Guild Accredited Training Partner®
(GATP®) program, and an academic program.

For more information and more details, visit: www.businessarchitectureguild.org.

References

i
A Guide to the Business Architecture Body of Knowledge® (BIZBOK® Guide), Business Architecture Guild®.

ii
P. M. Hacker, Wittgenstein's place in twentieth century analytic philosphy. (Oxford: Blackwell Publisher Inc.,
1996)

iii
Business Ecosystem: See Glossary. BIZBOK® Guide, Part 1: Introduction, www.businessarchitectureguild.org.

iv
Federation of Enterprise Architecture Professional Organizations (FEAPO), www.feapo.org

v
“BA next level foundation for success”; whitepaper available to members on the Guild website.

vi
Business Architecture Guild, Transportation Reference Model v2.0

vii
Business Architecture Guild, Transportation Reference Model v2.0

viii
Business Architecture Guild, Transportation Reference Model v2.0

ix
David P. Nolan and Robert S. Kaplan, “The Balanced Scorecard—Measures that Drive Performance”, Harvard
Business Review, (January-February 1992)

x
BIZBOK® Guide, Appendix A: Glossary, www.businessarchitectureguild.org.

August 2020 41 Copyright ©2020 Business Architecture Guild®