100% found this document useful (1 vote)
142 views43 pages

TOGAF - Open Business Architecture (O-BA) - Part II

Uploaded by

vincentB
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
100% found this document useful (1 vote)
142 views43 pages

TOGAF - Open Business Architecture (O-BA) - Part II

Uploaded by

vincentB
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 43

Open Group Preliminary Standard

Open Business Architecture (O-BA) – Part II

Business Architecture Capabilities, Value Stages, and


Activities
Copyright © 2017, The Open Group. All rights reserved.
No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic,
mechanical, photocopying, recording, or otherwise, without the prior permission of the copyright owner.
This specification has not been verified for avoidance of possible third-party proprietary rights. In implementing this specification,
usual procedures to ensure the respect of possible third-party intellectual property rights should be followed.

Open Group Preliminary Standard


Open Business Architecture (O-BA) – Part II
Business Architecture Capabilities, Value Stages, and Activities
Document Number: P171

Published by The Open Group, April 2017.


Comments relating to the material contained in this document may be submitted to:
The Open Group, Apex Plaza, Forbury Road, Reading, Berkshire, RG1 1AX, United Kingdom
or by electronic mail to:
[email protected]

ii Open Group Preliminary Standard (2017)


Contents
1 Introduction ............................................................................................................... 1
1.1 Objective ......................................................................................................... 1
1.2 Overview......................................................................................................... 1
1.3 Conformance................................................................................................... 2
1.4 Normative References..................................................................................... 2
1.5 Terminology ................................................................................................... 2
1.6 Future Directions ............................................................................................ 2
2 Definitions................................................................................................................. 3
2.1 Business Reference Architecture .................................................................... 3
2.2 Business Capability (O-BA Part I) ................................................................. 3
2.3 Business Service (O-BA Part I) ...................................................................... 3
2.4 Business Structure (O-BA Part I) ................................................................... 3
2.5 Common Vocabulary (O-BA Part I) ............................................................... 3
2.6 Outcome .......................................................................................................... 4
2.7 Output ............................................................................................................. 4
2.8 Process ............................................................................................................ 4
2.9 Value Activity ................................................................................................. 4
2.10 Value Stream (O-BA Part I) ........................................................................... 4
3 The Business Architecture Practice .......................................................................... 5
3.1 Introduction..................................................................................................... 5
3.2 Way of Thinking ............................................................................................. 6
3.3 Way of Working ............................................................................................. 7
3.4 Way of Modeling ............................................................................................ 8
3.5 Way of Organizing........................................................................................ 10
3.6 Way of Supporting ........................................................................................ 11
3.7 The TOGAF Framework and Business Architecture.................................... 11
4 Metamodel – Competence, Capability, and Value Stream ..................................... 13
5 Business Architecture Capabilities ......................................................................... 15
5.1 Business Architecture Knowledge Management .......................................... 16
5.1.1 Business Architecture Requirements Management ....................... 16
5.1.2 Business Reference Architecture Management ............................. 17
5.1.3 Business Architecture Knowledge Repository
Management .................................................................................. 18
5.2 Business Architecture Delivery .................................................................... 18
5.2.1 Business Architecture Development ............................................. 19
5.2.2 Business Architecture Advisory .................................................... 19
6 Business Architecture Techniques .......................................................................... 20
7 Transformation Value Stages and Business Architecture Activities....................... 21
7.1 Introduction................................................................................................... 21
7.2 Manage Business Architecture Knowledge .................................................. 23

Open Business Architecture (O-BA) – Part II iii


7.3 Manage Transformation Portfolio................................................................. 24
7.4 Create Transformation Vision ...................................................................... 24
7.5 Develop Transformation Strategy and Implementation Plan ........................ 25
7.6 Execute Transformation ................................................................................ 26
7.7 Optimize and Learn ...................................................................................... 27
8 Epilogue (Informative) ............................................................................................ 29

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

iv Open Group Preliminary Standard (2017)


Preface
The Open Group

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

Further information on The Open Group is available at www.opengroup.org.

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 being published initially as a Preliminary Standard since it addresses an


emerging area of best practice; therefore, it may change before being published as a full Open
Group Standard. In such a case it will be made as upwards-compatible as possible with the
corresponding Preliminary Standard, but complete upwards-compatibility is not guaranteed.

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.

Open Business Architecture (O-BA) – Part II v


Part I describes the practice through a Business Architecture framework, the five ways
framework, the structural challenges in transformations it tries to resolve, and how these are
resolved by applying the standard. The perspective of Part I covers the end-to-end
transformation cycle, but is more focused on decision-making and direction-setting.

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.

This document is structured as follows:


 Chapter 1 (Introduction) is an introduction to this standard.
 Chapter 2 (Definitions) defines the general terms used.
 Chapter 3 (The Business Architecture Practice) describes the Business Architecture
practice.
 Chapter 4 (Metamodel – Competence, Capability, and Value Stream) defines the key
concepts of the Business Architecture.
 Chapter 5 (Business Architecture Capabilities) provides an overview of the Business
Architecture capabilities.
 Chapter 6 (Business Architecture Techniques) provides an overview of the key techniques
of the Business Architecture capability.
 Chapter 7 (Transformation Value Stages and Business Architecture Activities) describes
the major value streams of Business Architecture.
 Chapter 8 (Epilogue) describes what has been addressed in Part I, Part II, and what can be
expected to be dealt with in Part III.

vi Open Group Preliminary Standard (2017)


Trademarks
APQC Process Classification Framework® is a registered trademark of American Productivity &
Quality Center.

ArchiMate®, DirecNet®, Making Standards Work®, OpenPegasus®, The Open Group®,


TOGAF®, UNIX®, UNIXWARE®, X/Open®, and the Open Brand X® logo are registered
trademarks and Boundaryless Information Flow™, Build with Integrity Buy with Confidence™,
Dependability Through Assuredness™, EMMM™, FACE™, the FACE™ logo, IT4IT™, the
IT4IT™ logo, O-DEF™, O-PAS™, Open FAIR™, Open Platform 3.0™, Open Process
Automation™, Open Trusted Technology Provider™, Platform 3.0™, SOSA™, the Open O™
logo, and The Open Group Certification logo (Open O and check™) are trademarks of The Open
Group.

BIZBOK® and Business Architecture Body of Knowledge® are registered trademarks owned by
the Business Architecture Guild.

Frameworx™ is a trademark of the TM Forum.

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.

Open Business Architecture (O-BA) – Part II vii


Acknowledgements
The Open Group gratefully acknowledges the contribution of the following organizations and
people in the development of this document:
 Capgemini: Patrice Duboe (Chair/Co-initiator), Joel Courquet
 Hewlett Packard Enterprise: Harry Hendrickx (Co-chair/Co-initiator), Peter Kuppen
 Huawei: Giovanni Traverso, Sarina Viljoen
 IBM: S. Kevin Daley (Co-initiator), Stephen Marshall
 Oracle: Venkat Nambiyur
 Philips: Paulo Pereira Filho (Co-initiator)
 Mike Lambert, Open Group Fellow (Architecture Forum Liaison)
 Alec Blair, Alberta Health Services (Architecture Forum Liaison)
 Bill Ulrich, Business Architecture Guild (Liaison)

viii Open Group Preliminary Standard (2017)


Referenced Documents
The following documents are referenced in this standard.

(Please note that the links below are good at the time of writing but cannot be guaranteed for the
future.)

Normative References

Normative references for this standard are defined in Section 1.4.

Informative References

 A Business-Oriented Foundation for Service Orientation, Ulrich Homann, Microsoft


Corporation, February 2006; refer to: http://msdn.microsoft.com/en-
us/library/aa479368.aspx.
 A Guide to the Business Architecture Body of Knowledge® (BIZBOK® Guide), Business
Architecture Guild; refer to: www.businessarchitectureguild.org/page/About.
 Actionable Business Architecture: IBM’s Approach, White Paper, IBM Global Business
Services (2010).
 Analyzing the Structure of IS Methodologies, P.S. Seligmann, G.M. Wijers, H.G. Sol,
Proceedings of the First Dutch Conference on Information Systems, The Netherlands:
Delft University of Technology (1989).
 An Assessment of Critical Success Factors, Andrew C. Boynton, Robert W. Zmud, Sloan
Management Review, Summer 1984, Vol. 25, No. 4; ABI/INFORM Global, p.17. This
document references the first time this issue was addressed in Management Information
Crisis, Ronald D. Daniel, Harvard Business Review, September-October 1961, p.111.
 ArchiMate® 3.0 Specification, an Open Group Standard (C162), June 2016, published by
The Open Group; refer to: www.opengroup.org/bookstore/catalog/c162.htm.
 Architect Your Business – Not Just IT!, J.W. Ross, M. Mocker, I. Sebastian, MIT Center
for Information Systems Research, Volume XIV, Number 12, December 2014.
 Business Architect: Critical Role for Enterprise Transformation, H.H.M. Hendrickx,
Journal of Enterprise Transformation, Vol. 5, 1:1-29, Taylor & Francis (2015).
 Business Capabilities, an Open Group Guide (G161), March 2016, published by The Open
Group; refer to: www.opengroup.org/bookstore/catalog/g161.htm.
 Capability-Based Planning: The Link Between Strategy and Enterprise Architecture,
White Paper (W16C), November 2016, published by The Open Group; refer to:
www.opengroup.org/bookstore/catalog/w16c.htm.

Open Business Architecture (O-BA) – Part II ix


 Conceptualizing Business Models: Definitions, Frameworks, and Classifications, E. Fielt,
Journal of Business Models, Vol. 1, No. 1, pp.85-105 (2013); refer to:
https://journals.aau.dk/index.php/JOBM/article/view/706.
 Defining the Business Architecture Profession, H.H.M. Hendrickx, S. Kevin Daley, M.
Mahakena, M. von Rosing, IEEE Conference Paper, Luxembourg (September 2011).
 Department of Defense Architecture Framework (DoDAF); refer to:
http://dodcio.defense.gov/Library/DoD-Architecture-Framework/.
 Enterprise Transformation: Why are we Interested, What is it, and What are the
Challenges?, V. Purchase, G. Parry, R. Valerdi, D. Nightingale, J. Mills, Journal of
Enterprise Transformation, 1:14-33, Taylor & Francis (2011).
 Exploration & Mining Business Reference Model, an Open Group Standard (C135),
February 2013, published by The Open Group; refer to:
www.opengroup.org/bookstore/catalog/c135.htm.
 Frameworx™, TM Forum; refer to: www.tmforum.org/tm-forum-frameworx. (Best
practices and standards providing a blueprint for effective, efficient business operations
for the telecommunications industry.)
 How Much Does Industry Matter, Really?, A.M. McGahan, M.E. Porter, Strategic
Management Journal, 18 (Summer Special Issue), pp.15-30 (1997).
 IEEE Std. 1471-2000: IEEE Recommended Practice for Architectural Description for
Software-Intensive Systems, IEEE Standards Association; refer to:
https://standards.ieee.org/findstds/standard/1471-2000.html.
 Integration Definition for Function Modeling (IDEF0), Draft Federal Information
Processing Standards Publication 183 (FIPS-183), December 1993; refer to:
www.idef.com/IDEF0.htm.
 Lay the Foundation: Five Guiding Principles to Make Business Architecture Effective,
H.H.M. Hendrickx, Hewlett-Packard (2013).
 Nobel Prize Case Results: Pilot to Apply Controlled Language in Architecture Practice,
H.H.M. Hendrickx, Plenary Presentation at The Open Group Architecture Practitioners
Conference, Amsterdam, Netherlands (October 2010).
 Representational Scheme for Analyzing Information Technology and Organizational
Dependency, J. Tillquist, J. King, C. Woo, MIS Quarterly, Vol. 26 No. 2, pp.99-118,
June 2002.
 Systems Thinking: Managing Chaos and Complexity – A Platform for Designing Business
Architecture, Jamshid Gharajedaghi, Morgan Kaufmann (2011).
 The Core Competence of the Corporation, C.K. Prahalad, Gary Hamel, Harvard Business
Review, 68(3), 79-91, p.84 (1990).
 The Integrated Architecture Framework Explained, Capgemini, Springer (2010).
 Value Stream Mapping: How to Visualize Work and Align Leadership for Organizational
Transformation, Karen Martin and Mike Osterling, McGraw Hill (2013).

x Open Group Preliminary Standard (2017)


 Value Streams, an Open Group Guide (G170), January 2017, published by The Open
Group; refer to: www.opengroup.org/bookstore/catalog/g170.htm.
 What is Strategy?, Michael E. Porter, Harvard Business Review, November, 1996.

Open Business Architecture (O-BA) – Part II xi


1 Introduction

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.

Open Business Architecture (O-BA) – Part II 1


1.3 Conformance
Readers are advised to check The Open Group website for any conformance and certification
requirements referencing this standard.

1.4 Normative References


The following standards contain provisions which, through references in this standard, constitute
provisions of the O-BA Standard. At the time of publication, the edition indicated was valid. All
standards are subject to revision, and parties to agreements based on this standard are
encouraged to investigate the possibility of applying the most recent edition of the standard
listed below.
 TOGAF® Version 9.1, an Open Group Standard (G116), December 2011, published by
The Open Group; refer to: www.opengroup.org/bookstore/catalog/g116.htm.
 Open Business Architecture (O-BA) – Part I, an Open Group Standard (P161), July 2016,
published by The Open Group; refer to: www.opengroup.org/bookstore/catalog/p161.htm.
 The Open Group Certified Architect (Open CA) Program: Conformance Requirements
Level 1 and Level 2 (X1605), June 2016, published by The Open Group; refer to:
www.opengroup.org/bookstore/catalog/x1605.htm.

1.5 Terminology
For the purposes of this standard, the following terminology definitions apply:

Can Describes a possible feature or behavior available to the user or application.

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

Shall Describes a feature or behavior that is a requirement. To avoid ambiguity, do not


use “must” as an alternative to “shall”.

Shall not Describes a feature or behavior that is an absolute prohibition.

Should Describes a feature or behavior that is recommended but not required.

Will Same meaning as “shall”; “shall” is the preferred term.

1.6 Future Directions


Part III of this standard will address guides and techniques relevant for the five ways elaborated
in Part I and Part II: way of thinking, way of modeling, way of working, way of supporting, and
way of organizing.

The three Parts of this standard will be integrated and further alignment with other Open Group
standards and other related standards is anticipated.

2 Open Group Preliminary Standard (2017)


2 Definitions

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.

2.1 Business Reference Architecture


An authoritative source of information about a specific subject area that guides and constrains
the instantiations of multiple architectures and solutions. (Source: DoDAF)

2.2 Business Capability (O-BA Part I)


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

Note: A capability is a fundamental and unique contribution to the business mission,


independent of any kind of organization.

(Source: A Business-Oriented Foundation for Service Orientation, by Ulrich Homann.)

2.3 Business Service (O-BA Part I)


The valued attribute of a capability as perceived by the stakeholder.

2.4 Business Structure (O-BA Part I)


A set of business capabilities and their inter-relationships that contribute to accomplishing a
higher-level goal.

2.5 Common Vocabulary (O-BA Part I)


A set of definitions of concepts that are essential to the Business Architecture practice.

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.

Open Business Architecture (O-BA) – Part II 3


2.6 Outcome
An end result that has been achieved.

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.

2.9 Value Activity


A stage within a value stream that is a recognizable phase in the transformation lifecycle.

Also known as a value stage within the BIZBOK® Guide.

2.10 Value Stream (O-BA Part I)


A sequence of activities an enterprise undertakes to deliver on a customer request. More broadly,
the sequence of activities required to design, produce, and deliver a good or service to a
customer, and it includes the dual flows of information and material.

(Source: Value Stream Mapping, by Karen Martin and Mike Osterling.)

4 Open Group Preliminary Standard (2017)


3 The Business Architecture Practice

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

Assures leadership Way of Way of Assures alignment and


communication Working Modeling integration of strategy,
structure, and operations

Way of Way of
Common language and Assures the Business
Supporting Organizing
techniques enable the role Architect acts at the right time

Figure 1: Five Ways Framework

Open Business Architecture (O-BA) – Part II 5


The Business Architecture practice has been recognized as a distinct capability that contributes
to resolve these issues, and with the O-BA Standard it is described in a more formalized way.

3.2 Way of Thinking


In the way of thinking the major beliefs and assumptions are described for the Business
Architecture practice. Organizations are in a continuous flux of transformations. The standard
focuses on transformations, which are considered as a lifecycle as well as a learning loop. Three
levels can be distinguished: the organization as a whole, the transformation program level, and
the capability/value stream or project level. At each level a lifecycle has similar value activities
in order to progress from Idea, to Vision, to Strategy & Implementation Plan, to Execute, and
eventually to Optimize & Learn.

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.

Figure 2: End-2-End Transformation Cycles at Three Levels in a Business

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

6 Open Group Preliminary Standard (2017)


5. Integration of the transformation process and the approach to assure that content
preparation and decision-making are just enough and just in time

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?

3.3 Way of Working


The way of working refers to the operational level of how to create, handle, and use the Business
Architecture concepts and models. In particular, the way of working focuses on understanding
processes and approaches followed by actors performing roles for the Business Architecture
practice.

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?

Business capabilities are a critical concept to generate an understanding of implications. First,


the impacted capabilities can be identified, and then the required change of each capability can
be analyzed by integrating the different aspects of that capability; e.g., people, process,
technology, and management.

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.

Open Business Architecture (O-BA) – Part II 7


Value streams are another critical concept for shaping the transformation. Value streams are
focused on the fulfillment of a customer request. By means of the value stream concept,
capabilities and their change requirements can be grouped in a client-focused way and thus
provide the ingredients for elaborating the process flows that are required to fulfill the customer
request.

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.

3.4 Way of Modeling


The way of modeling describes the network of models, their inter-relationships, and a detailed
description of the model components and formal rules to check them. It deals with the
conceptual aspects of the model.

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

Figure 3: Overview of Concepts in the Business Reference Architecture

8 Open Group Preliminary Standard (2017)


The focus of modeling lies in an accurate and relevant representation of the business using the
specific components that are of value to the stakeholder. The five modeling domains in Figure 3
provide the information to compose a holistic view. For each modeling domain the standard
gives guidance on what needs to be included.

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.

Products & Business Strategy Value


Services

External Strategic Strategic


Vision Intent Priorities

Competencies
(Also: key mechanism; critical success factor)

Capability Value Stream

Principles/Gaps/Requirements

Figure 4: Way of Modeling

The modeling is based on the following elements:


 Statements at a strategic level that can be transposed to specific business capabilities
 Capability map for analyzing the business capability in an integrated way
 Capability map for showing cross-domain dependencies
 Value streams for combining the target capabilities into customer-focused fulfillment
 Capability concept for methodical and integrated identification of changes for different
aspects in operations

Open Business Architecture (O-BA) – Part II 9


Capability mapping is a strong aid for creating strategic fit and transparency of how aspects
depend on each other. It is a key enabler for making a strategy tangible and developing the
implementation plan.

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.

3.5 Way of Organizing


Effectiveness requires that the Business Architecture practice is well established and integrated
in transformation processes. The focus of Business Architecture is capturing insights, alignment,
and governance and assuring business knowledge is applied and consistently communicated
during transformation processes. This can be done by adopting different roles and
responsibilities, but always using the same Business Architecture skills. How Business
Architecture capability will be established depends on the specific situation. Elaboration of a
guide is planned in Part III.

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

10 Open Group Preliminary Standard (2017)


3.6 Way of Supporting
The way of supporting aims to provide Business Architecture with the means for operating the
practice. The Business Reference Architecture2 is a foundational part of the practice. In addition
to this, the following three mechanisms are included to support the practice: consistent
communication, transparent integration, and continuous optimization.

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.

Transparent integration is accomplished through the modeling conventions. The modeling


conventions have been included to assure that dependencies can always be traced in a vertical
(strategy to operations) and horizontal direction (cross-domain). These allow both a top-down as
well as a more emergent approach to Business Architecture transformation. The five models that
compose the Business Reference Architecture (see Figure 3) have the conventions that assure the
traceability requirements.

Continuous optimization of the Business Architecture is accomplished because traceability


enables assessment of the impact of small changes across the business. And once the business
has defined external vision and the ambition in rising trends such as, for instance, Industry 4.0,
that same traceability accelerates, creating awareness of the Industry 4.0 implications at an early
stage.

3.7 The TOGAF Framework and Business Architecture


Business Architecture contributes to all levels of transformation, but also to all architecture
cycles. In fact, the TOGAF ADM cycle is part of the approach at each value stage. Since the

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

Open Business Architecture (O-BA) – Part II 11


approach is holistic, Business Architecture always keeps the full ADM cycle in mind. The
TOGAF standard is the foundation for the key skill of “Architecting”.

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.

Figure 5: The TOGAF ADM

12 Open Group Preliminary Standard (2017)


4 Metamodel – Competence, Capability, and Value Stream

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.

Competencies can be discovered from leadership communication and industry analysis


expressed in a vision and mission statement, or strategic principles. Strategic principles at least
relate to the organization’s view on value creation, revenue generation, competition, and
operational excellence. They provide the lens for identification of competencies. Industry points
of view, strategy explanation in annual reports, and investor relation communications are also
rich sources for finding answers to the question: in what should my organization excel to
accomplish the mission statement and the leadership’s ambition? Competencies show the
features of the business system and usually require a provision in different business areas. It is
an excellent concept to distribute business needs and priorities to specific business capabilities
and value streams.

Open Business Architecture (O-BA) – Part II 13


Is a part of
Organization

has
Strategic Intent Value receives

Is expressed by Delivers value via creates Stakeholder

Competence Value Stream triggers

Provides measure for


Contributes to Actor

Business
Capability enables Value Activity Participates in

decomposes

Note: For interpretation, follow the arrows; for example: strategic intent is expressed
by competence.

Figure 6: Metamodel: Key Business Architecture Concepts and Inter-relationships

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.

14 Open Group Preliminary Standard (2017)


5 Business Architecture Capabilities

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

Figure 7: Overview of the Business Architecture Capabilities

In Figure 7 an overview of the Business Architecture capabilities is given. If capabilities are


grouped together, the higher-level capability provides an extra value to the sub-capabilities it
contains. The added value of several capabilities jointly is achieved through integration,
interpretation, and alignment. The Business Architecture capabilities are grouped into three
domains:
 Business Architecture Practice Management: the ability to manage Business Architecture
as a professional service to the business
 Business Architecture Knowledge Management: the ability to manage the creation,
sharing, and effective use of Business Architecture-related information and knowledge
 Business Architecture Delivery:
— Business Architecture Development: the ability to analyze, describe, and communicate
the implications of and develop the Target Business Architecture in compliance with
the business strategy
— Business Architecture Advisory: the ability to deliver an advisory service to internal
and external customers with respect to changes and transformations of the Business
Architecture

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.

Open Business Architecture (O-BA) – Part II 15


Eventually, the different parts are planned to be integrated. The two capabilities – Knowledge
Management and Delivery – will be elaborated in this chapter.

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.

5.1 Business Architecture Knowledge Management

Name Business Architecture Knowledge Management

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.

Purpose To assure that learning translates into long-term value.

Input As sub-capabilities

Techniques As sub-capabilities

Outcome Optimal business performance

Sub-capabilities Business Architecture Requirements Management


Business Reference Architecture
(see the O-BA Standard, Part I, Chapter 7 for its components)
Business Architecture Knowledge Repository Management

5.1.1 Business Architecture Requirements Management

Name Business Architecture Requirements Management

Description The ability to create, handle, and manage Business Architecture requirements from
inception to completion.

Purpose To provide transparency on the Business Architecture requirements at strategy,


structure, and operational level.

16 Open Group Preliminary Standard (2017)


Name Business Architecture Requirements Management

Input Industry view


Strategic intent view
Strategic priorities view
Business structure view
Operational context – implications
Transformation Strategy and Implementation Plan

Techniques Modeling techniques for five domains (see Figure 3)


Operational context analysis (e.g., IDEF0)
Dependency network diagrams (horizontal traceability)

Outcome Requirements traceability


Strategic requirements
Target capability requirements
Target value stream requirements

5.1.2 Business Reference Architecture Management

Name Business Reference Architecture Management

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.

Input Industry view


Strategic intent view
Strategic priorities view
Business structure view
Operational context – implications
Transformation Strategy and Implementation Plan

Techniques Holistic view composition


Business Architecture integration
Business Architecture optimization
Business Architecture communication

Outcome Integrated holistic view of the business


Repository of configuration of elements of a business
Consistency in the use of Business Architecture Knowledge and Information

Open Business Architecture (O-BA) – Part II 17


5.1.3 Business Architecture Knowledge Repository Management

Name Business Architecture Knowledge Repository Management

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.

Purpose To assure an up-to-date Reference Architecture repository and its accessibility.


To assure compliance of the architecture with security policy and government
regulations.
To assure compliance of the Reference Architecture with the five requirements of the
Business Architecture practice (Section 3.2).

Input Business Reference Architecture

Techniques Quality assurance techniques


Content management techniques
Modeling
Optimal repository structure techniques
Integration and reporting

Outcome Business Architecture content, aligned with O-BA standard requirements


Up-to-date Business Architecture
Repository according to security and industry regulations

5.2 Business Architecture Delivery

Name Business Architecture Delivery

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

Outcome Transformation accomplished


Transformation optimized

18 Open Group Preliminary Standard (2017)


5.2.1 Business Architecture Development

Name Business Architecture Development

Description The ability to analyze, develop, describe, and communicate the implications and
required change of the Business Architecture.

Purpose To create a Transformation Vision.


To develop a Target Business Architecture Strategy and Implementation Plan.
To create a reference for evaluation of the accomplishment of the target state during
transformation.
To assure transformation execution complies with the target.

Input Business Reference Architecture


Investment idea

Techniques Analysis and representation of implications of investment ideas, business insights,


beliefs, and assumptions
Apply vertical traceability
Apply horizontal traceability
Analysis of operational context

Outcome Integrated view of the Business Architecture required changes

5.2.2 Business Architecture Advisory

Name Business Architecture Advisory

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.

Input Business Reference Architecture


Transformation views
Transformation issues and resolutions
Monitoring and evaluation results

Techniques Business Architecture integration


Business Architecture communication
Business Architecture optimization
Other techniques on an as-needed basis

Outcome Transformation issues resolved


Identification of unexpected results
Business capabilities implemented according to plan
Innovative ideas generated

Open Business Architecture (O-BA) – Part II 19


6 Business Architecture Techniques

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

Business Architecture Integration

Business Architecture Communication

Business Architecture Optimization

Note: Techniques may be used throughout the transformation cycle. They may be applied at different levels of detail from exploring to detailed
elaboration.

Figure 8: Business Architecture Key Techniques

20 Open Group Preliminary Standard (2017)


7 Transformation Value Stages and Business Architecture
Activities

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.

Business Architecture is applied in transformation teams – usually as a separate stream – to


deliver outputs which are either wrapped up into the transformation deliverables or added to the
Business Architecture Knowledge. For example, capability transformation impact as an output
of Business Architecture is part-and-parcel of the business portfolio of programs – a
transformation deliverable. Furthermore, the development of the Business Architecture from
Reference through Target, and finally optimized, is an enrichment to the knowledge base, which
will inform the transformation, but also builds into organizational learning.

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.

Open Business Architecture (O-BA) – Part II 21


Business Architecture
Transformation Transformation Business Architecture Activity Output/
Value Stage Value Stage Output Activity Value Activity

Manage Business Industry analysis Capture business strategy Industry analysis


Architecture Knowledge
Business strategy Business strategy
formalized description formalized description

Organizational Identify organizational Organizational


competencies competencies competencies

Business Architecture Develop holistic view of Business Architecture


3
holistic view business formalized description

Business Reference Create Business Business Reference


Architecture Reference Architecture Architecture

Manage Transformation Investment ideas Define capability and Capability


Portfolio value stream transformation impact
Investment priorities transformation impact
Define capability and
Business portfolio of value stream Value stream
programs transformation scope transformation impact

Create Transformation Transformation vision Define Business Business Architecture


Vision Architecture Vision Vision

Develop Transformation Transformation Create Target Business Target Business


Strategy and implementation strategy Architecture Architecture
Implementation Plan
Transformation business Develop benefits logic Business case model
case

Transformation roadmap Create Business Business Architecture


and plan Architecture Roadmap Roadmap

Execute Transformation Transformation Communicate and Business Architecture


realization tracking validate Business communication material
Architecture
Business Architecture
design validation

Transformation handover Assess Business Business Architecture


Architecture realization report
transformation
realization

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.

22 Open Group Preliminary Standard (2017)


Business Architecture
Transformation Transformation Business Architecture Activity Output/
Value Stage Value Stage Output Activity Value Activity

Optimize and Learn Business knowledge Update Business Business Architecture


Architecture Knowledge Knowledge base

Business innovation Update the Business Business Reference


opportunities Architecture Reference Architecture
and Target Business
Transformation lessons Architectures Target Business
learned Architecture

7.2 Manage Business Architecture Knowledge


This is a Business Architecture value stage. Its purpose is to prepare for practicing Business
Architecture and enable accomplishment of its value proposition of alignment, governance,
integration, and consistent communication through providing the enterprise with business
insights and transparency during investment decision-making, transformation execution, and
optimization.

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

Manage Business Architecture Capture business strategy Industry analysis


Knowledge
Business strategy formalized
description

Identify organizational Organizational competencies


competencies

Develop holistic view of business Business Architecture holistic


4
view

Create Business Reference Business Reference Architecture


Architecture

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.

Open Business Architecture (O-BA) – Part II 23


Business Reference Architecture

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.

7.3 Manage Transformation Portfolio


The purpose of managing the transformation portfolio is to optimize the allocation of investment
of finite organizational resources.

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.

Business Architecture is applied to focus on developing a good understanding of the


implications of the ideas and the risks and potential to realize them. The following activity is
conducted:
 Define Capability and Value Stream Transformation Impact; The Business
Architecture practice assesses the capability and value stream changes and their impact on
value creation. Capability impact and value stream impact are typically expressed in
maturity-level development and performance-level increase. At this stage, the impact is
assessed at a high level and key internal and external challenges are identified.

The following table summarizes the value stages, activities, and outputs.

Transformation Transformation Business Architecture Business Architecture


Value Stage Value Stage Output Activity Activity Output

Manage Transformation Investment ideas Define capability and Capability


Portfolio value stream transformation impact
Investment priorities transformation impact

Business portfolio of Value stream


programs transformation impact

7.4 Create Transformation Vision


The purpose of creating a transformation vision is to set direction and enable all the stakeholders
to contribute their best during the transformation journey. The direction will include at least the

24 Open Group Preliminary Standard (2017)


intent and strategic priorities that guide executives when developing the transformation strategy
and implementation plan.

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.

Transformation Transformation Business Architecture Business Architecture


Value Stage Value Stage Output Activity Activity Output

Create transformation Transformation vision Define Business Business Architecture


vision Architecture Vision Vision

7.5 Develop Transformation Strategy and Implementation Plan


The purpose of developing a strategy and a plan to implement the transformation is to speed up
the transformation, while reducing risks and realizing (parts of) expected value earlier.

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

Open Business Architecture (O-BA) – Part II 25


articulates the aspired changes to business processes, organization structure, IT systems,
business technology, people competencies, and other aspects of the operating model.
 Develop Benefits Logic: The Business Architecture holistic view provides insights into
vertical and horizontal dependencies. The benefits logic shows the assumptions for the
initiative, the needed investments, the expected impact of investment, and ultimately the
change in cost or revenues these drive. Financial experts need the input of the Business
Architect and other experts to assess the impact level and calculate the financial
consequences.
 Create Business Architecture Roadmap: A number of factors impact the optimal
sequence to execute towards the Target Business Architecture, amongst them: budget,
change readiness, business strategic milestones, and inter-dependencies between
programs. At this stage, Business Architects create a roadmap to explain what and when
to build with respect to capabilities and value streams, which informs the transformation
overall implementation plan.

The following table summarizes the value stages, activities, and outputs.

Transformation Transformation Business Architecture Business Architecture


Value Stage Value Stage Output Activity Activity Output

Develop Transformation Transformation Create Target Business Target Business


Strategy and implementation strategy Architecture Architecture
Implementation Plan
Transformation business Develop benefits logic Business case model
case

Transformation roadmap Create Business Business Architecture


and plan Architecture Roadmap Roadmap

7.6 Execute Transformation


The purpose at this stage is to deliver a transformation that the receiving organizations can
sustain and optimize.

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.

26 Open Group Preliminary Standard (2017)


 Assess Business Architecture Transformation Realization: The Business Architect
tracks that the transformation requirements – capabilities and value stream developments
– are being transformed into implemented solutions. Furthermore, the Business Architect
evaluates that the receiving organizations receive the benefits and equipment to sustain the
transformation. In this evaluation process against the Business Reference Architecture,
improvement ideas will be identified and fed into the optimization process.

The following table summarizes the value stages, activities, and outputs.

Transformation Transformation Business Architecture Business Architecture


Value Stage Value Stage Output Activity Activity Output

Execute Transformation Transformation Communicate and Business Architecture


realization tracking validate Business communication material
Architecture
Business Architecture
design validation

Transformation handover Assess Business Business Architecture


Architecture realization report
transformation
realization

7.7 Optimize and Learn


One purpose of optimizing and learning during a transformation is to work out to transform
better. The other purpose is to realize new insights and innovative ideas.

The end of the transformation cycle is marked by concluding on business optimization


opportunities and learning for growing the impact of the Business Architecture. There is a
mechanism for capturing ideas, insights, learning, and future actions during the transformation.
This process triggers changes – minor, major, critical, innovative – to the transformation and to
the Business Architecture. Changes which are picked up in the process may alter the
transformation course or even launch new transformation efforts.

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

Open Business Architecture (O-BA) – Part II 27


with the transformation leadership for updating the roadmap and plan. The Business
Architect value is the accumulation of the insights from across the business to assess the
implications of change ideas at three different levels: operational level, structure level, and
strategic level. Small changes may have strategic impact which would otherwise be
hidden due to lack of overview.

The following table summarizes the value stages, activities, and outputs.

Transformation Transformation Business Architecture Business Architecture


Value Stage Value Stage Output Activity Activity Output

Optimize and Learn Business knowledge Update Business Business Architecture


Architecture Knowledge Knowledge base

Business innovation Update the Business Business Reference


opportunities Architecture Reference Architecture
and Target Business
Transformation lessons Architectures Target Business
learned Architecture

28 Open Group Preliminary Standard (2017)


8 Epilogue (Informative)

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

Open Business Architecture (O-BA) – Part II 29


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

30 Open Group Preliminary Standard (2017)


Index
APQC ............................................... 8 outcome ............................................ 4
Business Architecture ....................... 1 output ......................................... 4, 22
Business Architecture activities . 1, 22 Practice Management ..................... 16
Business Architecture capabilities.... 1 process .............................................. 4
Business Architecture practice ......... 5 roadmap .......................................... 26
business capability........................ 3, 7 stakeholder ..................................... 15
business case................................... 26 techniques....................................... 21
business knowledge ........................ 14 TOGAF ADM ................................ 12
Business Reference Architecture... 11, TOGAF Version 9.1 ......................... 2
25 traceability ........................ 1, 6, 10, 14
business service ................................ 3 transformation ................ 5, 12, 26, 27
business structure ............................. 3 transformation value stages ............ 22
capability .................................. 14, 15 transparency ..................................... 8
common vocabulary ............... 3, 6, 21 value activity .................................... 4
competence ..................................... 14 value stages .................................... 22
competencies .................................. 14 value stream ..................... 4, 8, 14, 15
Delivery .......................................... 16 way of modeling............................... 8
five ways framework ........................ 5 way of organizing........................... 11
Frameworx ....................................... 8 way of supporting........................... 11
holistic view ............................. 10, 25 way of thinking ................................ 6
Knowledge Management ................ 16 way of working ............................ 1, 7

Open Business Architecture (O-BA) – Part II 31

You might also like