TOGAF - Open Business Architecture (O-BA) - Part II
TOGAF - Open Business Architecture (O-BA) - Part II
List of Figures
Figure 1: Five Ways Framework ......................................................................................... 5
Figure 2: End-2-End Transformation Cycles at Three Levels in a Business ...................... 6
Figure 3: Overview of Concepts in the Business Reference Architecture .......................... 8
Figure 4: Way of Modeling ................................................................................................. 9
Figure 5: The TOGAF ADM............................................................................................. 12
Figure 6: Metamodel: Key Business Architecture Concepts and Inter-relationships........ 14
Figure 7: Overview of the Business Architecture Capabilities ......................................... 15
Figure 8: Business Architecture Key Techniques ............................................................. 20
The Open Group is a global consortium that enables the achievement of business objectives
through IT standards. With more than 500 member organizations, The Open Group has a diverse
membership that spans all sectors of the IT community – customers, systems and solutions
suppliers, tool vendors, integrators, and consultants, as well as academics and researchers – to:
Capture, understand, and address current and emerging requirements, and establish
policies and share best practices
Facilitate interoperability, develop consensus, and evolve and integrate specifications and
open source technologies
Offer a comprehensive set of services to enhance the operational efficiency of consortia
Operate the industry’s premier certification service
The Open Group publishes a wide range of technical documentation, most of which is focused
on development of Open Group Standards and Guides, but which also includes white papers,
technical studies, certification and testing documentation, and business titles. Full details and a
catalog are available at www.opengroup.org/bookstore.
Readers should note that updates – in the form of Corrigenda – may apply to any publication.
This information is published at www.opengroup.org/corrigenda.
This Document
This document is Part II of the Open Business Architecture (O-BA) Standard, a standard of The
Open Group. It has been developed and approved by The Open Group as a Preliminary
Standard.
This standard is focused on transformations to the enterprise or organization, but also includes
management of the continuous flux of change both of the organization at large and at a more
contained level. This standard defines an approach to ensure a clear understanding of business
vision and strategy by all stakeholders throughout the transformation and change cycles.
The three parts of the standard, when taken together, will address all aspects of a Business
Architecture practice explicitly; not only the holistic approach in modeling, but also the way of
working and thinking, and the way of organizing and supporting.
Part II describes the Business Architecture practice through all phases of the transformation
cycle including the feedback loop in the lifecycle. It describes the lifecycle value stage, the
Business Architecture capabilities required, the Business Architecture value streams, the
contribution of Business Architecture to transformations, and the related techniques, views, and
viewpoints. The same concepts and techniques apply as in Part I, but they are elaborated at
another level of detail. Part I and Part II are complementary to each other. However, the two may
also be used independently.
Part III will elaborate on the specific techniques and guidelines for Business Architecture. It will
include, for instance, guides for establishing a Business Architecture practice, examples of key
Business Architecture activities, and more detailed elaboration of specific techniques for
preparation of output. Currently three Open Group publications are available (see Referenced
Documents): the Business Capabilities Guide, the Value Streams Guide, and the Capability-
Based Planning White Paper.
BIZBOK® and Business Architecture Body of Knowledge® are registered trademarks owned by
the Business Architecture Guild.
All other brands, company, and product names are used for identification purposes only and may
be trademarks that are the sole property of their respective owners.
(Please note that the links below are good at the time of writing but cannot be guaranteed for the
future.)
Normative References
Informative References
This document is Part II of the Open Business Architecture (O-BA) Standard, a standard of The
Open Group. It is being published as an Open Group Preliminary Standard. Part I describes the
framework of the standard. Part II elaborates on Part I with Business Architecture Capabilities
and Processes, and Part III will elaborate on Business Architecture techniques and guides.
1.1 Objective
This document describes the context in which the practice of Business Architecture is applied,
the Business Architecture capabilities and processes, and the views and viewpoints needed to
accomplish the expectation. The same concepts and techniques apply as in the O-BA Standard,
Part I, but the focus of Part II is the way of working.
In this document, the way of working refers to the operational level of how to create, handle, and
use the concepts and models. This is a more detailed description of the approach described in
Part I: capturing insights, alignment and governance, communicating and setting direction, and
enabling means.
The way of working is explained by taking the common vocabulary and the modeling in Part I as
a starting point, and subsequently explaining the required Business Architecture capabilities and
the related processes to produce the required “outcome” and “output”.
An overview of the key techniques is also included. For the key skills and techniques that
Business Architects should possess, readers should refer to The Open Group Certified Architect
(Open CA) Program: Conformance Requirements (see Section 1.4). Processes are described to
the level that an architect knows what information to gather, which activities to conduct, and
what type of output to produce.
1.2 Overview
First of all, a recap of the Business Architecture practice is described in Chapter 3, including the
different levels at which transformation cycles occur. Then, in Chapter 4, the key concepts of the
Business Architecture practice and their inter-relationships are explained. These are key
concepts because they assure traceability in the Business Architecture. In Chapter 5, the
Business Architecture capabilities required to accomplish the transformation vision and strategy
are described. Chapter 6 gives an overview of key techniques of the practice, and how these
enable Business Architecture activities is described in Chapter 7. In Chapter 8 an epilogue is
included on why the O-BA standard is needed, what its features should be, and how it is
practiced.
1.5 Terminology
For the purposes of this standard, the following terminology definitions apply:
May Describes a feature or behavior that is optional. To avoid ambiguity, the opposite of
“may” is expressed as “need not”, instead of “may not”.
The three Parts of this standard will be integrated and further alignment with other Open Group
standards and other related standards is anticipated.
For the purposes of this standard, the following terms and definitions apply.1 Merriam-Webster's
Collegiate Dictionary should be referenced for terms not defined in this section.
Note: In order to facilitate integration of the common vocabulary with the way of modeling
and way of working, it is preferably controlled to a certain extent. Control in this
standard is conducted through clearly stating to which concepts certain terms refer. By
adhering to these concepts, the practice enables consistent description of a holistic
view, integrated analysis of operational implications, and to trace validity of the
structure and operations against the assumed business strategy.
1
Where a term is included that is defined in the O-BA Standard, Part I it is denoted (O-BA Part I) in the title.
Note: Outcomes are the product of interactions among several elements. The quality level is
derived from the ambition level and competencies that are defined by the business
strategy. In this context, outcome refers to the contribution of the Business
Architecture capabilities to the Business Architecture practice.
2.7 Output
A quantifiable delivery of goods or services in time and space. It is produced by a process flow
and measured in three dimensions: price, quality, and availability.
2.8 Process
A flow of activities that receives input and transforms it into output – either a product or service.
This chapter gives an overview of the Business Architecture practice and the context in which
the practice is applied. The lens of the five ways framework will be followed to explain the
practice from several perspectives, as in the O-BA Standard, Part I.
3.1 Introduction
Organizations have to adapt continuously to new developments in society and technology. Three
levels of change may be recognized:
The business as a whole has to maintain continuous change or sometimes a full change of
structure and operations
Enterprise transformations have a beginning and an end, but fit in the continuous change
of the organization and span several business domains
Change initiatives are within a limited scope either by project or by continuous
improvement efforts
Whether change occurs in the business model or business capabilities, it is always a challenge to
be successful in a world where everything is connected. Research has shown that many
organizations find it difficult not only to scope and shape transformations, but also to perform
them successfully. Three structural issues occur during transformations: a lack of systemic view
to deal with dependencies between different parts of the business; alignment of stakeholders
with varying goals and interests; consistent communication of business needs and priorities
during the full lifecycle. These issues may vary in degree of severity at the three levels, but they
certainly have to be dealt with (see also the O-BA Standard, Part I).
Resolves challenges
Way of of continuous change
Thinking
Way of Way of
Common language and Assures the Business
Supporting Organizing
techniques enable the role Architect acts at the right time
Although the value activities may be similar, different delivery models can be distinguished:
from conventional to agile and emergent to top-down. The feedback loops from each level
interlock with the other levels of change. The O-BA standard provides guidance through the
description of its capabilities, processes, and techniques for each level and the end-to-end
lifecycle.
The Business Architecture practice is elaborated and formalized with focus on resolving the
three structural challenges during transformations already mentioned in Part I: lack of a systemic
view, difficulty to align stakeholders with varying interests and goals, and consistent
communication of the strategic intent and priorities during the transformation.
To resolve these structural challenges, the standard has defined five requirements which clarify
what the other four ways should accomplish. The five requirements are:
1. Common vocabulary to discuss, share, and communicate consistently the holistic view
and business strategy (optional)
2. Vertical traceability between business strategy, business structure, and operations
3. Horizontal traceability between different parts of a business
4. Holistic view to assure alignment of all relevant factors
At a high level, the following phases of organizational change can be distinguished: business
planning and portfolio management-focused, investment decision-making, transformation
execution, transformation optimization/learning/feedback loop. The first and last have a
continuous character, and the other phases are discrete.
Business Architecture differs slightly per phase because different goals have to be accomplished.
Moreover, the different delivery models have implications for how Business Architecture is
applied.
For the key skills and techniques that Business Architects should possess, readers should refer to
The Open Group Certified Architect (Open CA) Program: Conformance Requirements (see
Section 1.4).
This is a summary of the way of thinking for the Business Architecture practice. How does this
influence the other four ways?
In Part I the following models were adopted for the standard: external vision, strategic intent,
strategic priorities, business structure, and operational context. The inter-relationship between
those models have also been defined to assure the holistic view and the traceability between the
different abstraction levels. Key concepts for accomplishing this are: (organizational)
competence, capability, and value stream.
The Business Architecture starts with developing an understanding of the business and the intent
of the leadership of the organization. This is expressed in three models: external vision, strategic
intent, and strategic priorities.
After developing this understanding, the interpretation and implications have to be assessed.
What are the implications of external developments and how should the organization respond to
these? What are the implications of the strategic intent for the structure and operations?
A decomposition of the mission statement into business capabilities is a critical aid to conduct
this analysis. Several industry frameworks have been developed over the past two decades by
industry associations. These may be positioned in the enterprise continuum as Industry
Architecture. However, sometimes the Business Architect may have to use a proprietary one. In
general, industry frameworks (such as APQC Process Classification Framework® (PCF) and
Frameworx™) are foundational to their practice and will accelerate their work.
Since the Business Architecture practice develops a thorough understanding of how the business
is expected to work, it is also well positioned to articulate the value of a transformation as well
as the first steps in developing the transformation roadmap. Hence the techniques to represent
these insights are included in the overview of techniques in Chapter 6.
The formalized way in which the practice is conducted assures transparency for stakeholders,
facilitates more effective conversations, as well as communication of the results throughout the
lifecycle. The next section explains the key aspects of the modeling. It is also a recap of the O-
BA Standard, Part I.
The modeling is related to all levels: external, strategic, structure, and operational context. At
each level a common vocabulary has been defined. The concepts in this common vocabulary are
explicitly related to each other. An overview of the concepts that are included is shown in Figure
3, and a more detailed definition can be found in the O-BA Standard, Part I, Appendix E
(Definition of Concepts in Common Language).
External Vision
Vision External Factor
Strategic Belief Constraint Strategic
Intent Principle Opportunity Priorities
Brand External Challenge
Mission Statement Assumption Objective
Strategic Principle Customer Segment
Competence Marketing Mix
Ambition Position
Internal Challenge
Strategy Timing
Domain Customer Approach
Strategic Capability
Business Architecture Artifacts Partner
Structure Operational
Domain Domain
Business Operational
Structure Context
Capability Map Business Outcome
Value Stream Enabling Means
Organization Resource
Input
Implication
Once strategic insights are captured in the proposed formalized way, they can be transposed to
the relevant business capabilities and set direction for how target capabilities should look. The
strategic statements inform about the desired outcome of capabilities as well as the means that
are critical to include in the business capability. They inform top-down; for instance, on how
value is created or how operational excellence is expected to be achieved. They shape
operations. Or they may refer to applying specific technological means in order to accomplish
the ambition in a bottom-up approach. In both approaches, the implications can be derived and
change requirements for the operational level can be identified.
In turn, the change requirements and the target capabilities provide the ingredients to shape the
value stream and underlying processes to produce the work products that provide the basis for
the Business Architecture practice.
Competencies
(Also: key mechanism; critical success factor)
Principles/Gaps/Requirements
In order to address the lack of a systemic view, the Business Architecture practice applies the
holistic view. This view assures that at each level an overview and alignment are created. At the
strategic level, it is the formalized syntax to formulate the external vision and business strategy.
At the structure level, it is the capability map that allows for showing cross-domain
dependencies and that facilitates vertical traceability. In the operational context, the capability
allows for the integration of all relevant aspects.
The holistic view is thus provided by linking external vision, strategic intent, strategic priorities,
competence, capability, and value stream components, showing horizontal and vertical fit, and
implications in the operational context.
The authority of the Business Architect is derived from his expertise which can be exercised
during the process. However, authority may also be derived from the role they can be given
during the transformation process. They may become the driver of a transformation initiative,
the business design authority, or participating as an expert.
As shown already, assigning a Business Architect during the different stages of the
transformation cycle is one of the first ways leadership can organize for success. The Business
Architect may be assigned, amongst others, in the following situations:
During the annually returning business planning process
In the event that business managers have an idea for change, but do not know how to
proceed
Planning and shaping initiatives
Preparation of investment decisions
Steering committees
Optimizing newly deployed business capabilities
Making strategy implementation more tangible
The content of the Business Reference Architecture is explicitly defined. It contains all the
insights and knowledge that can be captured through modeling the concepts, as shown in Figure
3. The common vocabulary is an essential aid to compose the Business Reference Architecture.
Once the Business Reference Architecture is captured, it will be relatively stable and not change
very quickly as long as the strategy is valid. Thus a stable reference for stakeholders during
transformation has been created to match with new ideas. It also provides a common and
accessible shared reference due to the use of the agreed vocabulary. Communication based on
the reference will thus inherently have legitimacy.
Consistent communication is not only accomplished through a common vocabulary. The value is
also enhanced because the practice strives for maximum alignment with other standards like The
Open Group ArchiMate® and TOGAF® standards, as well as bodies of knowledge, such as the
BIZBOK Guide. Although alignment has not yet been completed fully, the major concepts
currently are. The next phase of the O-BA standardization process includes further alignment.
Let’s not forget the individual Business Architect as a mechanism for consistent communication.
The individual is the communicator of both tangible and tacit knowledge. Especially the tacit
knowledge will increase substantially over time due to involvement in activities cross-domain
and at all levels. The architect has the overview of business insights, and can assure just in time,
just enough application of the business knowledge. The architect also has the overview on cross-
dependencies for strategic fit.
2
DoDAF and OASIS have Reference Models and architectures well defined. Based on these definitions, an important component of
the knowledge base is the Business Reference Architectures. The DoD definition for Reference Architecture is: “… an authoritative
source of information about a specific subject area that guides and constrains the instantiations of multiple architectures and
solutions”.
The O-BA is positioned in the TOGAF framework as a specialized view during the Preliminary
Phase and Phase A. At Phase A (Architecture Vision) – what is the ambition, what needs to
change, and what is a direction for solution – is elaborated. At Phase B (Business Architecture),
the O-BA elaborates the implications of the Architecture Vision and the direction of solution by
developing in more detail the target capabilities, capability roadmap, and value streams. During
these three phases, the O-BA contributes by creating a good understanding of the industry,
clarifying the strategy, and analysis of the implications of the change for the business structure
and operations. As such, the results set direction for the other phases in the ADM cycle.
The purpose of Part II is to show the Business Architecture viewpoints and the views that have
to be produced to accomplish the value proposition of alignment, governance, integration, and
consistent communication of business knowledge. In the common vocabulary, concepts and
inter-relationships are explicitly defined and enable vertical and horizontal traceability from any
level or position in the business system: top-down, bottom-up, and middle-out. Thus, transparent
views can be created for each stakeholder, systemic views can be communicated to show
dependencies, and consistency in communication can be assured.
The following concepts are critical to make this work: competence, capability, and value stream.
The standard assumes that an organizational entity has a strategic intent, and delivers value via
value streams.
Competencies are the result of the leadership’s interpretation of the industry dynamics, the
strategic intent, and how that can be accomplished. Competencies show what the organization
should do well to accomplish its strategy. Thus competencies provide the measures for shaping
the capabilities.
has
Strategic Intent Value receives
Business
Capability enables Value Activity Participates in
decomposes
Note: For interpretation, follow the arrows; for example: strategic intent is expressed
by competence.
Capability is the capacity an organization possesses and the level at which the different aspects
of a business can be analyzed against a common goal. The capability concept enables alignment,
integration and configuration of roles and skills, process requirements, technology aspects, and
management to provide the required services and products and accomplish the strategic intent.
Capabilities are unique parts of the business that enable the transformation of input into
something valuable for the organization. Each capability has its own specific and unique goal.
Capabilities contribute to higher-level capabilities and may have dependencies with other
capabilities for strategic fit. The goal is to ultimately accomplish the highest-level goal and
ambition expressed in the mission statement and strategic intent.
The value stream is composed of a sequence of value activities that are enabled by capabilities.
A value stream shows the steps along which value and output are produced. A value stream
always has a consumer of its output. Consumer is a specialization of stakeholder. A value stream
is a mechanism to reflect on the way the business intends to respond to value demands, and
therefore represents an inside-out perspective of the business. Considering the business from the
outside-in (how the consumer chooses to engage/journey with the business), is fundamental to
success in transformations. The “customer journey” is an example of an extension concept to the
metamodel above, enabling the business to think through the customer engagement fundamental
to the way in which business is conducted digitally.
Stakeholders may be internal or external. In the case of the transformation cycle, they will be the
internal receivers of the transformation results. Actors participate in the transformation cycle
value activities. The Business Architect is one of the actors in the transformation cycle.
In Chapter 5 the capabilities relevant for the Business Architecture practice are summarized.
Then the techniques will be discussed in Chapter 6. Subsequently, Chapter 7 will describe how
these capabilities enable Business Architecture value activities.
The viewpoint in this chapter is “Business Architecture Practice as a Business”. This chapter
explains which capabilities and techniques are needed to accomplish the Business Architecture
value proposition. Business Architecture capabilities enable value activities and contribute to the
subsequent value stages in the transformation cycle.
For the key skills and techniques that Business Architects should possess, readers should refer to
The Open Group Certified Architect (Open CA) Program: Conformance Requirements (see
Section 1.4).
Business Architecture
Business Architecture Practice Management Business Architecture Knowledge Management Business Architecture Delivery
Business
Business Business
Business Business Architecture Business Business
Enterprise Change Architecture Reference
Architecture Architecture Knowledge Architecture Architecture
Engagement Management Requirements Architecture
Governance Operationalization Repository Development Advisory
Management Management
Management
Business Architecture Practice Management has not been fully elaborated in Part II since this
Part is limited to aspects related to “Business Architecture Knowledge and Information” and
“Business Architecture Delivery”. Practice Management, on the other hand, is a managerial
capability for establishing practice in its operating model. It will be elaborated in Part III. This
overview includes it only to assure consistency between Part II and III of the standard.
Capabilities are described with the following aspects: name, description, purpose, input,
techniques, and outcome. Each Business Architecture capability is elaborated and described with
the following aspects:
1. Name – A stateless expression of a capacity an organization or individual possesses.
2. Description – The transformation process the capability accomplishes.
3. Purpose – The value the capability provides for receiving stakeholders.
4. Input – The specific input that is transformed by the capability.
5. Techniques – A procedure to complete a task that contributes to the capability purpose.
6. Outcome – An end result that has been achieved.
Description The ability to manage the creation, sharing, and effective use of Business
Architecture-related information and knowledge.
Knowledge management enables the achievement of optimal business performance
through facilitating the composition and use of holistic view of the business.
Input As sub-capabilities
Techniques As sub-capabilities
Description The ability to create, handle, and manage Business Architecture requirements from
inception to completion.
Description The ability to manage the creation and use of reference architectures for the
organization.
Purpose To provide transparency on the imperatives of a business, their parts, and their inter-
relationships.
Description The ability to manage the knowledge repository, including the security of
information, privileges of users, regulatory compliance, quality of models and
deliverables, and the ready availability of information for decision-making.
Description The ability to deliver Business Architecture services during the Transformation
Execution and Transformation Optimize and Learn stage.
Purpose To assure that the transformation vision is well embedded in the Target Business
Architecture.
To assure alignment of the transformation Target Architecture with the strategic
intent.
To assure that operations are in line with the Business Architecture requirements.
To provide a feedback loop on the effectiveness of the Business Architecture.
Input As sub-capabilities
Techniques As sub-capabilities
Description The ability to analyze, develop, describe, and communicate the implications and
required change of the Business Architecture.
Description The ability to deliver an advisory service to internal and external customers.
Purpose To assure that during the continuous change lifecycle of investment decision-
making, transformation execution, transformation optimization, and learning the
Business Architecture is in accordance with the business strategy.
The O-BA strives for resolving the structural issues (Section 3.2) through techniques with
specific characteristics. These are aligned and comply with the five requirements listed in the
same chapter. Their focus lies in generating the five models as shown in the overview (Figure 3):
external vision, strategic intent, strategic priorities, business structure, and operational context.
Techniques may be applied at each value stage in the transformation cycle. For an overview of
techniques, see Figure 8.
The common vocabulary is critical when practicing Business Architecture since it defines the
key concepts to be used in these techniques. They have been defined not only in an isolated
fashion, but also to reflect the inter-relationship of concepts. The common vocabulary guides
development of these models, enables alignment between them, and assures traceability and
consistency throughout.
Three techniques have been called out as more generic techniques. These differentiate from the
others because they do not specifically result in one view, but convey how Business Architecture
Knowledge and Information is integrated, communicated, or applied to understand how
operations can be optimized.
In Part III techniques will be elaborated and published as either a Guide or White Paper.
Business
Industry Strategy Holistic View Capability Idea Value Business Case
Analysis Impact Composition Analysis Articulation Modeling
Analysis
Business
Business Performance Vertical Capability-
Value Stream Architecture
Strategy Feedback Traceability Based
Analysis Roadmap
Clarification Analysis Analysis Planning
Elaboration
Horizontal
Traceability
Analysis
Note: Techniques may be used throughout the transformation cycle. They may be applied at different levels of detail from exploring to detailed
elaboration.
7.1 Introduction
This chapter defines the transformation value stages and identifies the activities performed by
the Business Architecture practice in their context. The Business Architecture has a role during
the entire transformation lifecycle. It touches on planning to execution and has a strong
contribution to governance.
This standard indicates how to synchronize the Business Architecture activities into the
transformation value stages. The coherence of the outputs and the purpose of the transformation
value stages define the value delivered by the Business Architecture. Recognizing that each
enterprise transformation may be carried out in variations of the one presented here, the Business
Architect must be able to adapt the sequence and structure of the activities accordingly.
Available insights, scope, ambition, governance requirements, number of stakeholders, and
disciplines are key considerations for determining time schedule, work breakdown, and process
flows.
The structure used in this chapter works as follows. The enterprise transformation cycle breaks
down into transformation value stages (see Figure 2). Each value stage has a purpose and
produces some of the transformation outputs. The Business Architecture practice takes over with
activities which typically interlock or belong to the transformation value stages. These activities
create the Business Architecture outputs. The development of a Business Reference Architecture
that shows the structure and operational implications of the business strategy is recommended as
a foundation Business Architecture capability.
The next table shows the transformation value stages (see Figure 4) and related Business
Architecture activities. Value activities are described as a flow to the level that an architect
knows what information to gather, which activities to conduct, and what type of output to
produce. In the course of this chapter, all value activities will be further described.
3
A systemic view considers the business system in interaction with its environment; the holistic view is defined as the formalized
description of the business strategy, structure, and operational context and their inter-relationships; see the O-BA Standard, Part I,
Section 6.1.3 (Way of Modeling); the formalized description is based on the common vocabulary defined in Part I, Appendix E
(Definition of Concepts in Common Language); the Reference is the holistic view plus additional descriptions of the industry
environment, its state-of-the-art technology, strategy implementation achievements, and governance processes.
The Business Architecture practice analyzes the industry developments, practices, standards, and
trends. It keeps the organization up-to-date in this way. It captures the business strategy with the
rigor required to manage the business and its related Business Architecture. The identification of
organizational competencies aims at activating the strategy. Finally, in this value stage, the
Business Reference Architecture is created to include amongst others the business capabilities
and value streams. For details of aspects that need to be included, see Figure 3.
The following table summarizes the value stages, activities, and outputs.
Business Architecture
Transformation Value Stage Business Architecture Activity Activity Output
4
The O-BA Standard, Part I includes the definition of the holistic view. It is the integrated view of the business strategy, structure,
and operational impact including the traceability of strategy to operations and including strategic fit that shows the cross-domain
dependencies that arise from organizational competencies.
The Business Reference Architecture is composed of the holistic view and additional chapters on
the industry characteristics, governance aspects of the organization, and progress on the strategy
implementation. The holistic view is represented as a formalized description of the external
vision, strategic intent, strategic priorities, business structure, and operational context and its
inter-relationships. The inter-relationships in the Reference Architecture are assessed by
explicitly including vertical traceability of requirements top-down from strategy to operations
and horizontal traceability explaining the requirements in several domains. See Figure 3 for
those aspects that are included in the different areas of the formalized description.
The organization’s effort must be directed to where most value is created, including the
development of business capabilities that are going to sustain performance in the long run. First
it makes sure that all investment ideas are properly captured, classified, and assessed with
similar comparable criteria. In the sequence the ideas are enriched with estimation of value
creation and execution viability, subsequently transformed into a list of investment priorities.
Finally, the investment is chartered into a portfolio of business programs which are sized and
scoped for efficient realization of the ideas.
The following table summarizes the value stages, activities, and outputs.
During this stage the transformation stakeholders – meaning all who lead, execute, and receive
the change – visualize what the enterprise looks like at the end of the transformation. Each
person understands the ultimate goal, has a view of the path to get there, and more importantly
understands their role in it. Major internal and external challenges have been defined and show
which capabilities and business aspects during the transformation cycle need to be addressed.
Also in this stage the transformation leaders can get feedback to assess whether the
transformation can succeed in terms of the value it is expected to create and of the ability to
execute it.
The Business Architect focuses on alignment of strategy, structure, and operations as well as on
the impact of the investments on the performance. At this stage, this will be limited to
assumptions which need to be tested during the next stage of the transformation cycle:
Define Business Architecture Vision: As a next step during this stage, experts are
assigned to assess the viability for the organization to address these challenges or whether
showstoppers arise during the investment cycle. Once this insight has been acquired, a
recommendation will follow for further elaboration of the strategy and the implementation
plan. In these, specific and explicit responses to the challenges will be addressed. These
are usually small teams of experts that can handle most of the critical questions that arise.
The investment in time and money is limited.
The following table summarizes the value stages, activities, and outputs.
During this stage, a feasibility analysis is conducted on the strategic, commercial, technological,
operational, and financial aspects of the transformation. Subsequently, scenarios for
implementation can be developed and the best strategy for executing the transformation is
elaborated. With the implementation strategy defined, a more detailed business case is
elaborated. Finally, a roadmap explains in which sequence the transformation is planned to be
carried out. That is a trade between early realization of the business case and the ability to
change capabilities and value streams.
The participation of the Business Architect is extensive in this value stage. Three activities are
conducted, as follows:
Create Target Business Architecture: The Business Architecture practice uses the
Business Reference Architecture to explain required changes of capabilities and value
stream to realize the strategic intent and objectives. The Target Business Architecture
The following table summarizes the value stages, activities, and outputs.
During the Execute Transformation phase – Design, Develop, and Implement – the operational
domain views are elaborated and tested. The teams work to change processes, IT systems, and
organizational structure, to deploy new competencies, and all-in-all to transform the operating
model. Transformation leadership makes sure that capabilities and value streams are developed
as planned. Finally, there is monitoring to assure that value is realized, and that the transformed
organization can operate and grow after the transformation mechanism is dismissed.
Business Architecture still plays a significant role at this value stage, not related to creation and
design, but related to communication, guidance, and validation. There are two activities, as
follows:
Communicate and Validate Business Architecture: The Business Architect takes the
role of on-boarding the transformation teams, facilitating them during the transformation
execution, and validating the design and implementation against the transformation vision,
strategy, and plan. A relevant role is related to clarifying and resolving dependencies with
situations in and out of scope of the transformation.
The following table summarizes the value stages, activities, and outputs.
This value stage for the Business Architect marks the feedback loop to update the knowledge
base; as such a main mechanism for learning as a practice and as an organization. The other
activity takes care that the Reference and Business Architecture are updated. And that the
necessary adjustments are made to the transformation implementation strategy, plan, and
therefore execution.
Update Business Architecture Knowledge Base: The Business Architecture structure
provides the enterprise with the perfect way to collect, classify, and publish knowledge. In
this activity business solutions (globally or locally-relevant) and other types of knowledge
are captured, ordered in a formalized way, and linked to capabilities and value streams.
Update the Business Architecture Reference and Target Business Architectures: The
ideas, innovation, and improvement opportunities that are brought up during the
transformation are translated into changes to the Reference and Target Business
Architecture in this transformation stage. The changes to the Business Reference
Architecture may trigger all-new transformation in the future. The changes to the Target
Business Architecture, at the level of capabilities and value stream impact, are discussed
The following table summarizes the value stages, activities, and outputs.
Part II has elaborated the Business Architecture capabilities – what value is expected from them,
and how these are applied in transformation cycles. Also, the specific techniques have been
highlighted in Chapter 5. Capabilities, value stages/activities, and techniques have been defined
through the lens of the five requirements for effective transformation and change:
1. Common vocabulary to discuss, share, and communicate consistently the holistic view
and business strategy (optional)
2. Vertical traceability between business strategy, business structure, and operations
3. Horizontal traceability between different parts of a business
4. Holistic view to assure alignment of all relevant factors
5. Integration of the transformation process and the approach to assure that content
preparation and decision-making are just enough and just in time
The O-BA Standard, Part I explains why these requirements are the right response to three
structural issues in larger and small change cycles:
1. Alignment of stakeholders with varying goals and interests
2. Lack of systemic view in change cycles
3. Lack of consistency in communication of business needs and priorities and the envisioned
response
To make this work, the techniques of the Business Architect have been defined to accomplish
the expected capabilities and execute the required value streams. The techniques will be
subsequently elaborated in Part III.
As a starter, one may consider the different roles the Business Architect can play during change
cycles at the different levels. In practice, the roles may be conducted in combination or
specialized. This depends on the scale and the capacity of the Business Architecture capability
the organization can bear.
As a stake in the ground, the following roles seem to resonate with different phases during the
transformation cycle: the Business Architect as:
Business innovator: value articulation, mobilization transformation ideas/innovative ideas,
alignment, and governance
Strategy implementer: value articulation, integration, alignment, governance, and
communication
Transformation assurance: value assurance, governance, communication, and integration
Continuous improvement: value evaluation, continuous improvement, governance, and
communication