The Open Group

The Open Group is a global consortium that enables the achievement of business objectives through technology standards. With more than 900 member organizations, we have a diverse membership that spans all sectors of the technology community – customers, systems and solutions suppliers, tool vendors, integrators and consultants, as well as academics and researchers.

The mission of The Open Group is to drive the creation of Boundaryless Information Flow™ achieved by:

  • Working with customers to capture, understand, and address current and emerging requirements, establish policies, and share best practices
  • Working with suppliers, consortia, and standards bodies to develop consensus and facilitate interoperability, to evolve and integrate specifications and open source technologies
  • Offering a comprehensive set of services to enhance the operational efficiency of consortia
  • Developing and operating the industry’s premier certification service and encouraging procurement of certified products

Further information on The Open Group is available at

The Open Group publishes a wide range of technical documentation, most of which is focused on development of 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

The TOGAF® Standard, a Standard of The Open Group

The TOGAF Standard is a proven enterprise methodology and framework used by the world’s leading organizations to improve business efficiency.

This Document

This document is a TOGAF® Series Guide to Business Capability Planning. It has been developed and approved by The Open Group.

This document shows how an organization can introduce business capability planning or revise or refine existing efforts. It provides techniques, recommends tools, and provides references to other methods useful for business capability planning.

This document supersedes:

  • Capability-Based Planning: The Link between Strategy and Enterprise Architecture, White Paper (W16C)

This document complements and supports the following TOGAF® Series Guides:

More information is available, along with tools, guides, and other resources, at

About the TOGAF® Series Guides

The TOGAF® Series Guides contain guidance on how to use the TOGAF Standard and how to adapt it to fulfill specific needs.

The TOGAF® Series Guides are expected to be the most rapidly developing part of the TOGAF Standard and are positioned as the guidance part of the standard. While the TOGAF Fundamental Content is expected to be long-lived and stable, guidance on the use of the TOGAF Standard can be industry, architectural style, purpose, and problem-specific. For example, the stakeholders, concerns, views, and supporting models required to support the transformation of an extended enterprise may be significantly different than those used to support the transition of an in-house IT environment to the cloud; both will use the Architecture Development Method (ADM), start with an Architecture Vision, and develop a Target Architecture on the way to an Implementation and Migration Plan. The TOGAF Fundamental Content remains the essential scaffolding across industry, domain, and style.

Intended Audience

This document is intended to show how an organization can look to introduce business capability planning or to revise or refine existing efforts. There are many roles that will find this document useful, with a few common roles listed below. There is no prerequisite knowledge required.

  • Business Planners and Managers

  • Business capability planning provides a common view of steps to deliver value for stakeholders with the necessary detail to fulfill each step. This provides focus for investment and improvement for success.

  • Enterprise Architects

  • Business capability planning provides a holistic view that allows for planning across all aspects of the enterprise by identifying opportunities for optimization, consolidation, creation, and removal of organizational capabilities.

  • Business Architects

  • For Architects who are focussed specifically on Business Architecture, business capability planning provides a straightforward way to articulate requirements to other areas of the business.

  • Business Analysts

  • Business capability planning provides a vehicle for developing more detailed deliverables that can be aligned to the models developed through business capability planning. Appendix B describes how business capability planning enables other techniques like business process modeling, lean value streams, and journey maps.

  • System Analysts

  • Business capability planning provides the insight into which enhancements will deliver the best value to the organization through the applications that are used to enable business capability instances. Having the ability to see how applications support the generation of value to the organization provides context that will support developing and prioritizing an application’s enhancement backlog.


ArchiMate, DirecNet, Making Standards Work, Open O logo, Open O and Check Certification logo, Platform 3.0, The Open Group, TOGAF, UNIX, UNIXWARE, and the Open Brand X logo are registered trademarks and Boundaryless Information Flow, Build with Integrity Buy with Confidence, Commercial Aviation Reference Architecture, Dependability Through Assuredness, Digital Practitioner Body of Knowledge, DPBoK, EMMM, FACE, the FACE logo, FHIM Profile Builder, the FHIM logo, FPB, Future Airborne Capability Environment, IT4IT, the IT4IT logo, O-AA, O-DEF, O-HERA, O-PAS, Open Agile Architecture, Open FAIR, Open Footprint, Open Process Automation, Open Subsurface Data Universe, Open Trusted Technology Provider, OSDU, Sensor Integration Simplified, SOSA, and the SOSA logo are trademarks of The Open Group.

BPMN and Business Process Modeling Notation are trademarks of Object Management Group, Inc.

Business Model Canvas is a trademark of Alexander Osterwalder.

CBA and Certified Business Architect are registered trademarks of the Business Architecture Guild.

Fujitsu is a registered trademark of Fujitsu Limited.

IBM is a registered trademark of International Business Machines Corporation in the United States, other countries, or both.

Microsoft is a registered trademark of Microsoft Corporation in the United States and/or other countries.

Raytheon is a trademark of Raytheon Company.

SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.

Toyota is a registered trademark of Toyota Motor Corporation.

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.

About the Authors

Alec Blair – Enterprise Architect, Alberta Health Services

Alec is an Enterprise Architect who has been practicing all forms of Enterprise Architecture for over two decades. He is currently working as an Enterprise Architect with Alberta Health Services. This is his fourth opportunity to co-author a guide for The Open Group Architecture Forum Business Architecture Working Group.

Bryan Lail – Enterprise Architect, Raytheon™

J. Bryan Lail is a Master Certified Architect with The Open Group, a Certified Business Architect® (CBA®) with the Business Architecture Guild, and a Raytheon Certified Architect applying strategic Business Architecture methods in the defense industry. His career has spanned physics research, engineering for the Navy and Raytheon, chief architect roles, and multiple publications in the application of architecture to business strategy.

Stephen Marshall – Strategy Consultant

Stephen Marshall is a Certified Master Architect with The Open Group (Open CA), a Certified Business Architect® (CBA®), and an IBM® Certified Architect. He is currently a Senior Research Analyst at BuddeComm. Stephen is a highly experienced strategy consultant, business researcher, and market analyst with deep global experience, particularly across Asia and the Middle East.

Chalon Mullins – Retired from Kaiser Permanente

For many years Chalon used his full range of architecture expertise to ensure the agile implementation of technology. Through this expertise he helped organizations adopt and adapt IT to solve business problems. He is currently Chair of The Open Group Architecture Forum Business Architecture Working Group.

Magaly Perez – Enterprise Architect, Intel Corporation

Magaly is currently implementing Business Architecture and business capability planning within her Information Security and Infrastructure organization. Her passion is to produce more business-focused investment strategies to transform value delivery through connection of cybersecurity and technology.

Peter Ridgway – Digital Business Advisor, Fujitsu®

Peter has worked in the UK and Australia with government, private, and academic sectors as a business and ICT mediator. From Business and Operating Models, Risk & Security, to Information and Technology, the identification of value and objectives, building strategy, and delivering outcomes is his primary focus.


(Please note affiliations were current at the time of approval.)

The Open Group gratefully acknowledges the authors and past and present members of The Open Group Architecture Forum for their contribution in the development of this document. This specifically includes:

  • Daniel Hutley – Forum Director, The Open Group Architecture Forum

The Open Group gratefully acknowledges the following reviewers who participated in the Company Review of this document:

  • Etienne Terpstra-Hollander – OpenText
  • Alec Blair – Alberta Health Services

Referenced Documents

The following documents are referenced in this TOGAF® Series Guide:

  • A Business-Oriented Foundation for Service-Orientation, Ulrich Homann, Microsoft® Corporation, Seattle, Washington, USA, 2006
  • ArchiMate® 3.2 Specification, a standard of The Open Group (C226), published by The Open Group, October 2022; refer to:
  • Capability-Based Planning: The Link between Strategy and Enterprise Architecture, White Paper (W16C), published by The Open Group, November 2016; refer to:
  • Competitive Advantage: Creating and Sustaining Superior Performance, Michael E. Porter, Free Press, 2004
  • Great Transition: Using the Seven Disciplines of Enterprise Engineering, James Martin, AMACOM, 1995
  • Handbook on Long-Term Defence Planning, NATO Research and Technology Organization, Neuilly-Sur-Seine, Cedex, France, 2003
  • The Machine that Changed the World, James D.J. Womack, Harper Perennial, 1991
  • The TOGAF® Standard, 10th Edition, a standard of The Open Group (C220), published by The Open Group, April 2022; refer to:
  • TOGAF® Series Guide: Business Capabilities, Version 2 (G211), published by The Open Group, April 2022; refer to:
  • TOGAF® Series Guide: Integrating Risk and Security within a TOGAF® Enterprise Architecture (G152), published by The Open Group, April 2022; refer to:
  • TOGAF® Series Guide: Value Streams (G178), published by The Open Group, April 2022; refer to:

1 Introduction

Many organizations struggle with managing the complexity of their business. They want to answer questions about their progress toward realizing their strategic aims. Are their investments targeted appropriately? Are there areas of redundancy or duplication that are suitable for rationalization? Does the business have what is necessary, or too much of something to succeed?

To be able to answer these questions, practitioners need to start by doing their homework:

  • Understanding the organization’s mission, vision, and values
  • Reviewing the organizational chart, financials, and available business plans
  • Cataloging their IT at a logical level

These resources will be required to perform business capability planning.

The concepts of capabilities and value streams for planning purposes have been around for many decades. The North Atlantic Treaty Organization (NATO) used capabilities for scenario planning and trying to abstract the military units being supplied by member nations. The lean discipline uses detailed value stream maps to wring out efficiency in material usage and information flows. The Open Group has added the concepts of capabilities, value streams, and capability-based planning into the TOGAF® Architecture Development Method (ADM), the ArchiMate® Specification, and many guides.

Value streams provide a visual means of communicating how an organization delivers value to customers and other stakeholders. Breaking the value stream into logical stages with exit criteria and outcomes provides a way to understand the key aspects of value that is generated along the way for the customer. Value stream stages can be then mapped to business capabilities to better understand what is required to implement the value stream.

A business capability catalog is a great resource for many audiences within an organization. The catalog provides definitions for each business capability usually combined with a model that allows people to find the business capability they are looking for. Creating and maintaining a business capability catalog is a significant amount of work.

Business capabilities are instantiated using people, processes, and tools like applications. Modeling value streams down to the business capability level provides insights into how the value stream or value stream stages can be made more efficient or effective. It is highly recommended that practitioners use a shared architecture modeling tool for this level of analysis.

Value streams that are modeled down to the business capability instance level can be assessed to see if there is room for that instance to be optimized, consolidated, created, or retired. New value streams can be created when looking to re-use business capability instances to make that value stream operational as soon as possible.

Business capability planning uses the power of abstracted business capabilities to bring together multiple perspectives. Business capabilities are not an end in themselves. They are building blocks for an organization’s value streams. The ability to continually optimize current value streams and create new ones is the key to success of any organization.

This document provides techniques, recommends tools, and provides references to other methods useful for business capability planning.

2 The History of Capability-Based Planning

Capability-based planning was introduced by the Research and Technology Organization (RTO) Studies, Analysis, and Simulation (SAS) panel for NATO. Multiple nations’ military organizations needed the ability to jointly plan based on scenarios of expected future operations. “(The) … description of the task force structure units should be able to perform expressed in capability terms. Once the capability inventory is defined, the most cost-effective and efficient physical force unit options to implement these capabilities are derived.” (Source: Handbook on Long-Term Defence Planning; see Referenced Documents)

The recommendation made by the military planners was to move away from threat-based planning and explore several potential scenarios. Capabilities and capability “segments” are mapped against multiple scenarios to see how well the capabilities fulfill the objectives of each scenario. This assessment then supports which capabilities need investment over time based on the ones that allowed the response to the most scenarios.

Ulrich Homann authored a paper entitled: “A Business-Oriented Foundation for Service-Orientation” (see Referenced Documents) while working for Microsoft® Corporation. In that paper he defined a business capability as: “… a particular ability or capacity that a business may possess or exchange to achieve a specific purpose or outcome … A business capability abstracts and encapsulates people, process/procedures, technology, and information into the essential building blocks needed to facilitate performance improvement and redesign analysis.” (Source: Homann 2006)

Within this framework for service-orientation, the abstraction to a business capability allowed for the ability to expose “capability connectors” that provide “rich, semantic information”. Modeling a business using capabilities provides a business context for Service-Oriented Architectures (SOAs). With that additional context it was hoped to future-proof IT designs. It was also seen as enabling a more agile way to meet business requirements.

In 1990 the term “value stream” appeared in the book “The Machine that Changed the World” by James Womack (see Referenced Documents). The value stream assesses the efficiency of the sequence of activities or processes to deliver on a customer request. Value stream mapping allows lean practitioners to identify waste that leads to reduced efficiency. The value stream map is based on the visualization technique used at Toyota® called “material and information flows”.

Capabilities and value streams have been added to the TOGAF ADM, various guides, and the ArchiMate modeling language, adding capabilities and value stream elements over the past decade or so.

3 Business Capability Planning Modeling

To effectively execute business capability planning, using the ArchiMate modeling language is recommended. The express purpose of the ArchiMate language is to provide a unifying view for the diagrams that describe the entire enterprise. It is also useful to have precise definitions of key elements of a particular view and the types of relationships that are allowable between the elements.

The ArchiMate language and architecture modeling tools are useful for practitioners. However, they may not be as consumable to a general or senior executive audience. Later in this document an abstraction of a detailed value stream model will be provided with capability instances to show how a practitioner can bridge the gap between the different audiences.

3.1 Key ArchiMate Elements

The ArchiMate language is capable of modeling across all architecture domains, layers, and aspects. For business capability planning, only a subset of the ArchiMate elements is needed to support the models that will be developed. Figure 1 and Table 1 contain the elements that have been used to develop the models that will follow through the rest of this document. There are other ArchiMate elements that could be useful when developing business capability planning models, but starting with this subset is recommended.

Figure 1: ArchiMate Business Capability Elements and Relationships

The business capability elements have clear relationships (Figure 1) which help in understanding their role in the delivery of the capability and value. These elements and relationships are intended for use in the viewpoint expressed in the value stream model. Table 1 shows how these elements and relationships are used in the context of business capability planning.

Table 1: Use of ArchiMate Business Capability Elements and Relationships

ArchiMate[1] Symbol

Object Name

Use in Business Capability Planning


Application Component

An application component represents an encapsulation of application functionality aligned to a specific business capability. Application components can also encapsulate other application components.


Application Process

An application process represents a sequence of application behaviors that achieves a specific result within the context of a business capability instance.


Business Capability

A capability represents an ability that an active structure element, such as an organization, person, or system, possesses.

Key to the evaluation is the business capability drawn from the business capability catalog and assigned to value stream stages within a value stream. A business capability is “instantiated” by adding business roles, application components, business objects, business processes, and resources that are required for that business capability to produce an outcome.


Business Event

A business event represents a business-related state change.

At a minimum, a business event triggers the value stream but can also trigger value stream stages.



Business Object/
Data Object

A business object represents a concept used within a particular business domain.

A data object represents data structured for automated processing.

A business object for business capability planning is usually information that represents a conceptual object that can be assigned to one or more business capabilities. It can also be represented as a data object within an application component.


Business Process

A business process represents a sequence of business behaviors that achieves a specific result such as a defined set of products or business services within the context of a business capability instance.


Business Role

A business role represents the responsibility for performing specific behavior within a business capability instance’s business process or participating in all business capabilities within an overall value stage, to which an actor can be assigned, or the part an actor plays in a particular action or event.



A goal represents a high-level statement of intent, direction, or desired end state for an organization and its stakeholders.

For business capability planning, this is usually the high-level intent of a particular value stream or value stream stage.



An outcome represents an end result, effect, or consequence of a certain state of affairs.

For business capability planning, the result of a value stream or value stream stage and the way to tell that a particular value stream or value stream stage has been completed successfully.



A resource represents an asset owned or controlled by an individual or organization.



A stakeholder represents the role of an individual, team, or organization (or classes thereof) that represents their interests in the effects of the architecture.



Value represents the relative worth, utility, or importance of a concept.

For business capability planning, represents the relative worth of the value stream (value proposition) or value stream stage (value item) for one or more of the value stream’s stakeholders.


Value Stream/
Value Stream Stage

A value stream represents a sequence of activities that create an overall result for a customer, stakeholder, or end user.

The value stream object is used to model both the overall value stream and the value stream stages.

3.2 ArchiMate Relationships

In the examples provided, most of the relationships are implied by having elements nested within other elements. The relationships are still there, just not as explicit. Mapping the relationships between elements is of great importance and the reason it is almost mandatory that a modeling tool is used. The catalog of models is essential to trace interdependency to be able to perform the analysis for business capability planning.

3.3 Architecture Modeling Tools

To properly execute business capability planning, an architecture modeling tool is essential. The relationships and interdependencies between business goals and outcomes, capability instances, and the resources of the organization needed to successfully deliver value to customers become overwhelming quite rapidly without a method to track and maintain them.

Of larger benefit is the overall element catalog and model library. Being able to use a curated catalog of elements and being able to see the other architecture views in how these interconnected models are expressed, allows for insight across all Enterprise Architecture domains.

For this example, the authors used the open source Archi tool with the Co-Archi extension.[2] The model repository with all the views used in this document is available from The Open Group Library.

4 Doing Your Homework

Any business capability planning activity needs to start by understanding how the business operates. Having a good understanding of the following aspects of your organization will help to facilitate business capability planning. In many organizations, these artifacts may not exist as formal documents and may need to be created by the practitioner to complete the analysis. The following are key for the overall organization, or for some larger organizations a set for each distinct business area:

  • The organizational structure
  • The business model and associated business objects
  • Current strategic, business, and financial plans
  • Applications and information objects

The following sections will look at how this information can support various aspects of the business capability planning approach, and also explain limitations and provide examples that will be expanded through the example retail organization.

4.1 Organizational Structure

Organizations are often structured in ways that are closely aligned to business capabilities. People execute processes and allocate resources or tools like money, IT, or other company assets. The organizational structure of a business can thus be used to inform the capability catalog. While there is alignment, it is not complete alignment.

For example, multiple business units are involved in creating or delivering business capabilities through business capability instances. Sometimes organizational units are aligned by geography or customer segment. Organizational structures are naturally also far more transient than business capabilities. Where possible, a tight alignment between the functional names that denote business units and business capabilities should be avoided.

The example retail organization has four main functional areas, each with smaller departments that report up to the parent business unit, as shown in Figure 2. In the model each of the functional areas is represented as a stakeholder in the ArchiMate language, and in the modeling tool with a hierarchy represented by the nesting of each stakeholder within the area to which they report organizationally.

Figure 2: Retail Company Organization Chart

At this level, the organization chart is not at the detail required to really inform the overall capability catalog, but at a lower level it may be. It does indicate where there may be business capabilities. For example, within Finance there are three functions for Cash Management, Accounts Receivable, and Accounts Payable which for most organizations will be business capabilities. In areas like Warehouse Management and Retail Stores, the organizational hierarchy does not inform the business capability catalog due to them being geographically or, in this example, product-oriented.

4.2 Business Model

A common and simple business model is the Business Model Canvas™. By keeping the business model at an abstract level, it allows for a macro-level view that is both easy to communicate and usually provides insight that may not be as easily seen at the more detailed level.

The Business Model Canvas is available in Archi as a canvas. A version for the fictitious retail organization is shown in Figure 3. For Key Activities use the value streams that you will see later in this document.

Graphical user interface, application

Description automatically generated

Figure 3: Retail Organization Business Model Canvas

There are usually many tangible business objects that are core to the way a business operates. Many of these business objects are also manifested in one or more applications as key data elements. Here is a sample of retail-oriented business objects:

  • Bill of sale: a list of items sold in a particular transaction
  • Financial receipt: a record of the transfer of funds between the retailer and customer
  • Catalog: a listing of available items for sale by the retail organization
  • Advertising flyer: a subset of the catalog to highlight specific items where the organization is offering incentives using coupons to increase sales of products

For the retail organization the following measures apply:

  • Website conversion rate: percentage of visitors to the website that complete a purchase
  • Sales of incentivized products: percentage of customers who make a purchase using a coupon
  • Order to ship time: time it takes once an order is placed to be ready to be picked up by the shipper
  • Recruit position time: time it takes to hire a new employee from when the position has been approved

These key indicators are important in that they will usually determine the motivation of different stakeholders or roles that may or may not be clearly articulated anywhere else. In and of themselves, Key Performance Indicators (KPIs) are not useful for business capability planning unless there are measurable objectives that can be associated with them that can also be applied to the value stream models.

4.3 Financial, Business, and Strategic Plans

The three items below are often readily available in financial plans, but there may be a need for more explicit business and strategic plans.

4.3.1 Financial Statement

Following how money flows within an organization provides insight into which aspects of a particular business are relatively more or less important than others. The way the financial statements are structured also provides insight into the motivations and outcomes that are expected by various stakeholders. Finally, financial statements typically provide insight into areas where some value streams may not be operating as effectively as needed by the organization.

4.3.2 Business and/or Strategic Plans

A business plan provides a narrative of what a business is intending to do based on some explanation of the marketplace in which the business operates. It is usually a companion to the financial statements. A strategic plan is typically created in response to a particular internal or external stimulus and represents either an incremental or shift of resources to change an organization’s direction. Any stated goals or objectives available help to both determine areas of focus as well as to become part of any business capability planning models.

4.3.3 Balanced Scorecard

The most leveraged tool for measuring business performance is the balanced scorecard. There are many resources available to explain how to create a balanced scorecard. For the purposes of business capability planning, it is usually a source of objectives and measurable goals.

In Figure 4, objectives have been aligned to each of the balanced scorecard dimensions. Goals that are realized by a particular objective have also been linked.

Figure 4: Balanced Scorecard

4.4 Application Catalog, Information Objects, and Exchanges

Understanding your organization’s application catalog and how information objects are or are not exchanged between applications is a key piece of homework that will help during the analysis stage of business capability planning.

4.4.1 Retail Organization Application Catalog

The following applications are used in this retail organization to instantiate the business capabilities required for the Acquire Retail Product Online value stream:

  • Customer Relationship Management (CRM): the CRM application provides the functionality for the retainer to manage the list of customers, their identities, as well as purchase history and any other interactions they have had with the organization
  • Supply Chain Management (SCM): the SCM application supports the logistics of distributing products to bricks and mortar stores as well as fulfilling online orders
  • Legacy Warehouse Management: recently the retail organization acquired an electronics distributor who had their own Inventory Management application which is almost ten years old and has limited integration functionality
  • Modern Warehouse Management: this application currently only manages the clothing inventory; it can be extended to handle electronics and has some existing APIs that have not been configured to integrate with other applications
  • Online Store: this application provides the browser and mobile application user experiences; this requires interfaces with the other applications to maintain a great customer experience
  • Accounting: this application manages all the finances of the organization including accounts receivable and accounts payable
  • Human Resources (HR): the HR application manages all aspects of hiring and managing employees
  • Commercial Banking: this application provides the gateway to support online and in-store payments
  • Identity and Access Management (IAM): the organization has an enterprise IAM application that currently supports employee identities, but not customers’ identities

4.4.2 Conceptual Data Model

With the advent of Enterprise Resource Planning (ERP) and data warehouses, there are many industry standard data or information models that are available that could be useful in creating your business capability catalog. Most conceptual data models are a collection of business objects with relationships between them. The following view of business objects (Figure 5) provides the basis for a simplified retail conceptual data model.

Figure 5: Business Objects View

The conceptual data model is developed or configured as par for many applications deployed by an organization. This is how a business object becomes one of many data objects required for applications to operate successfully. Understanding the application catalog and which information objects they have will be useful when looking at business capability instances.

4.4.3 Application Information Exchange Catalog

Armed with an application catalog and the conceptual data model, the assessment of how information is exchanged both transactionally and operationally can be completed. It is important to look at all forms of information exchange. At this level of analysis the mechanism by which the data is moved between applications is not as relevant.

The following provides a few examples of what this catalog might look like.

Table 2: Application Information Exchange Catalog (Examples)

Source Application

Information Object(s)

Destination Application

HR Application


Identity and Access Management

Online Store Application

Retail Purchase

Modern Warehouse Management

Online Store Application



Commercial Banking

5 Value Streams

The word “value” originates from the Old French valoir: “to be worth”. It is the regard that something is held to deserve; the importance, worth, or usefulness of something. Within the context of Business Architecture, it is important to think of value in the most general sense of usefulness, advantage, benefit, or desirability, rather than the narrow accounting or financial perspective that defines value as being the material or monetary worth of something. Non-monetary examples of value in the business world include such things as the successful delivery of a requested product or service, resolving a client’s problem in a timely manner, or gaining access to up-to-date information to make better business decisions.

Value is fundamental to everything that an organization does. The primary reason that an organization exists is to provide value to one or more stakeholders. It is the foundation of a firm’s business model, which describes the rationale for how a business creates, delivers, and captures value. The Business or Enterprise Architect should be able to model, measure, and analyze the many ways that the enterprise achieves value for a given stakeholder. This includes the ability to decompose the creation, capture, and delivery of value into discrete stages of value- producing activities, each of which is enabled by the effective application of business capabilities.

5.1 Value Streams in Business Capability Planning

The approach to value analysis that is used in Business Architecture is derived from “Great Transition” by James Martin (see Referenced Documents). The value stream is depicted as an end-to-end collection of value-adding activities that create an overall result for a customer, stakeholder, or end user. In modeling terms, those value-adding activities are represented by value stream stages, each of which creates and adds incremental stakeholder value from one stage to the next.

Value streams may be externally triggered, such as a retail customer acquiring some merchandise as shown in the example below. Value streams may also be internally triggered, such as a manager obtaining a new hire as shown above. Value streams may be defined at an enterprise level or at a business unit level. Either way, the complete set of value streams denotes an organization’s primary set of business activities. It is an aggregation of the multiple ways in which the enterprise creates value for its various stakeholders.

A key principle of value streams is that value is always defined from the perspective of the stakeholder – the customer, end user, or recipient of the product, service, or deliverable produced by the work. The value obtained is in the eye of the beholder; it depends more on the stakeholder’s perception of the worth of the product, service, outcome, or deliverable than on its intrinsic value; i.e., the cost to produce.

5.1.1 Describing a Value Stream

Value streams are usually represented in a model that has the following elements:

  • Name: the value stream name must be clearly understandable from the initiating stakeholder’s perspective

  • In contrast to the way that business capabilities are named, value streams use an active rather than passive tense. That usually means a verb-noun construct. For example, the two value streams used throughout this document are “Acquire Retail Product Online” and “Recruit Employee”.

  • Description: while the value stream name should be self-explanatory, a short, precise description can provide additional clarity on the scope of activities with which the value stream deals
  • Trigger: what is the business event that causes this value stream to start?
  • Stakeholder: the person or role that receives the value delivered by the value stream
  • Value Item: the value (expressed in stakeholder terms) that the stakeholder expects to receive upon successful completion of the value stream

The following is derived from the example:


Acquire Retail Product Online (at Online Store)


The activities involved in looking for, selecting, purchasing, and obtaining a desired retail product.


The customer visits the website.


A retail shopper (customer) wishing to purchase a product.

Value Generated

Customers can locate desired products and obtain them in a timely manner.

5.1.2 Describing Value Stream Stages

Stakeholder value is rarely produced as the result of a single step or activity. More often, value is achieved through a series of sequential and/or parallel actions, or value stream stages, that incrementally create and add stakeholder value from one stage to the next.

Each value stream stage comprises the following elements:

  • Name: two to three words identifying what is (or will be) achieved by this stage
  • Description: a few sentences explaining the purpose and the activities performed during the value stream stage
  • Entrance Criteria: the starting condition or state change that either triggers the value stream stage or enables it to be activated; in practice this is usually the existing condition from the prior stage or for the first stage the actual trigger for the value stream to start
  • Exit Criteria: the end state condition that denotes the completion of the value stream stage (i.e., when the required value has been created or delivered to the stakeholders); in many instances the stage name and the exit criteria are almost identical
  • Value Item: the incremental value that is created or delivered to the participating stakeholder(s) by the value stream stage

A value stream does not necessarily flow continuously and uninterrupted from initiation through to conclusion. There is an opportunity to stop the value stream at any given stage if the desired value has not been created or delivered. This could be at the request of the triggering stakeholder. For example, the Acquire Retail Product Online value stream may stop because the customer decides that they no longer want to purchase the merchandise after they see the price. It may also be the stakeholder who is executing the value stream.

Figure 6: Example Value Stream Stage

6 Business Capabilities

Within The Open Group, a capability is defined as “an ability to do something”. A business capability represents the ability for a business to do something. A more formal definition is as follows:

An ability that an organization possesses. Capabilities are typically expressed in general and high-level terms and require a combination of people, processes, and tools to achieve.

Critically, a business capability delineates what a business does without attempting to explain how, why, or where the business uses the capability. Those details surface once the business capability is mapped to one or more value streams or value stream stages and modeled in how the business capability has been instantiated. This business capability instance will be key when looking to assess how well one or more value streams are performing against the performance metrics that have been defined by the organization.

A business capability can be something that exists today or something that is required to enable a new value stream or strategy. It can also be something that the organization decides to eliminate as business conditions change. When compiled into a catalog, business capabilities represent all the abilities that an enterprise has at its disposal to run its business.

6.1 Defining a Business Capability

Defining a business capability involves identifying and describing what needs to be done by the business in support of its overall mission. A business capability description does not imply how something needs to be done, simply that it needs to exist. To describe how a business capability is instantiated will be demonstrated in Section 6.4. The following guidelines explain how to define an individual business capability.

6.1.1 Naming Convention

Naming the business capability is the first step in the capability definition process. It shows a clear need for the existence of the business capability and helps to ensure it is clearly distinguishable from other business capabilities.

The naming convention involves expressing the business capability in a noun-verb format, whereby each outcome (input, output, or deliverable) is described as a noun and each activity that is associated with producing, controlling, or monitoring the outcome is described as a verb; e.g., “Catalog Products” or “Payment Processing”. The noun part of the business capability is a unique business object – a single, persistent thing that is of interest to the business. The advantage of making a business object the focal point of the business capability is that it simplifies the process of identifying the information objects that are tied to it and used by the business capability.

A business object is typically tangible – e.g., “Customer” or “Loan” – but it can also be more conceptual and intangible such as “Research”. The most important consideration is to use names that resonate with business leaders and stakeholders. Commonly understood names enable better understanding and improve communication across different stakeholder groups. However, simply repeating the organizational department names is not recommended. Unlike business capabilities (which are inherently stable), organizational structures are not enduring and frequently change in most organizations.

6.1.2 Description

A brief description helps to clarify the scope and purpose of the business capability and to differentiate it from other business capabilities. A useful syntax is to phrase the description of each business capability as “the ability [or capacity] to ...”. For example, a business capability named “Catalog Products” might be described as: “The ability to maintain an organized list of products or services cross-referenced with metadata”.

As with the business capability name, write all descriptions using language that is relevant and appropriate to the business stakeholders. Two important considerations are to:

  • Be concise: provide just enough detail over one or two sentences to enable greater understanding than can be gained from the business capability name alone
  • Be precise: do not simply repeat the name of the business capability in the description

  • For example, do not use “the ability to manage programs” when describing “Program Management”. Instead, Program Management is: “The ability to initiate, plan, execute, control, and complete work as part of a team to achieve specific goals and success criteria”.

6.2 Business Capability Catalog

A goal of creating the business capability catalog is to capture and document the business capabilities that enable the value streams executed by the business today (irrespective of how well it does it) or value streams they hope to implement in the future.

The second step is to organize that information in a logical manner. There are three approaches for identifying a starter set of business capabilities: top-down, bottom-up, and incremental:

  • Top-down: a top-down business capability mapping approach starts by identifying (from an enterprise-level perspective) the 20 to 30 highest-level business capabilities

  • Senior business leaders can help to develop the top-level business capabilities in the first instance. In practice, developing a draft business capability map from the top down is a more efficient use of time, but is usually only successful if there is meaningful involvement from senior leaders within the organization. Events that impact the entire organization like a merger or wholesale transformational initiative will be a suitable time to start implementing business capability planning if not done already done.

  • Bottom-up: when more time is available, business capabilities can be defined from within various parts of the business and built from the bottom up

  • This approach can be more difficult to reconcile across the business without strong governance and senior leadership support toward developing an enterprise-wide business capability catalog.

  • Incremental: invariably when Business Architecture practitioners get down to applying what is in the business capability catalog there will be evolution of the catalog

  • Mapping business capabilities to value stream stages or elaborating into business capability instances will show where there may be business capabilities missing, and redundancies or additions required to the business capability catalog.

A business capability catalog represents the complete, stable set of business capabilities that covers the business, enterprise, or organizational unit in question. The end product of the analysis or consultation process is typically a business capability catalog with definitions. A business capability catalog view is useful to develop a visual depiction of all the business capabilities necessary for a particular organization to operate. For navigation purposes, the capability catalog is logically grouped into categories or perspectives to enable effective analysis and planning.

The capability catalog needs to be large enough to be inclusive, but small enough to be effectively navigated and applied to map to value streams and value stream stages as well as described as business capability instances. In general, when a capability catalog exceeds 100 items, there is a high probability that business capabilities are describing either business capability instances, components of a capability instance, or in some situations value stream stages.

Once defined, the business capability catalog provides a self-contained view of the business that is independent of the current organizational structure, business processes, IT systems and applications, and the product or service portfolio. A holistic view is useful from a planning perspective when the specifics of how value streams and the associated business capabilities have been instantiated is not present.

Curation of the business capability catalog is something that will require a reasonable amount of work, especially in the beginning. Usually, a small group of two to four people to start with will be effective as more people may slow the process down. Establishing a change management process to review proposed additional creations, revisions, and deletions of business capabilities would be useful from the start of the creation process and will need to continue into operations.

6.2.1 Business Capability Catalog Model

The following business capability catalog model (Figure 7) shows a visual representation of the overall business capability catalog based on the business capabilities that have been illustrated in this document.

Figure 7: Business Capability Catalog Model (Example)

6.3 Mapping Business Capabilities to Value Stream Stages

Using value streams, as defined in Chapter 5, the next step is to identify which business capabilities are required to enable each value stream stage (Figure 8). This is done by reviewing the business capability map and linking (i.e., cross-mapping) the relevant business capabilities to each value stream stage.

The purpose of this activity is to identify which business capabilities (out of the total set of capabilities) are critical to delivering stakeholder value, and therefore which ones need to be instantiated to a sufficient standard of quality to meet stakeholder expectations.

Figure 8: Mapping Business Capabilities to Value Stream Stages

6.4 Business Capability Instances

The business capabilities captured in the value stream are defined as instances. This allows the correct capture of capabilities used in different areas of the organization which would otherwise conflict or create duplicates in the capability catalog.

Modeling a value stream’s business capability instances provides the insight required to create, enhance, or merge business capabilities to improve value stream execution. With the gaps identified for actors, stakeholders, resources, applications, or processes documented, an investment plan needed to deliver those capability increments can be planned for implementation.

For Enterprise Architects, capability instances provides the linkage between the TOGAF domains, with the value stream providing the business context and requirements. Understanding how capability instances are enabled by information systems and technologies that enable those capabilities provides the thread to connect the subsequent phases of the TOGAF ADM.

6.4.1 Business Capability Instance Guidance

There is now an inventory of components of the organization in the form of catalogs of various concepts, including:

  • Business capability catalog
  • Application catalog
  • Value stream catalog
  • Organization strategic goals and outcomes

To complete the analysis, it is necessary to model the capability instances for the affected value streams. A capability instance is the mapping of a business capability to the resources, applications, and processes that are required for that capability instance. Using the various catalogs maintained in the modeling tool (such as Archi) makes the modeling process much easier and faster.

Modeling business capability instances is not intended to be an exhaustive decomposition for each capability instance. The selection of components should be to tell a story of what is required as a minimum to allow the value stream to execute from beginning to end successfully. It is also expected that within the Enterprise Architecture repository there will be other models available for analysis. This will include views specifically for applications, technology environments, and detailed technology nodes that go into much more detail on the function for which an application is designed and distributed to execute.

Leveraging the business capability catalog that was identified above, components of people, processes, and resources can be added within the business capability. Using nesting versus arrows makes for model readability and clarity. As components are added, additional business capability instances will naturally become evident either as multiple instances of the same business capability, or a missing business capability that was not evident before going to the next level of detail.

Modeling value streams using business capability instances prevents the bloat of the business capability catalog. Many organizations create specializations of business capabilities within their catalog that really reflect how some business capabilities have been instantiated. At times this is obvious as the business capability catalog gets more elements, but it is usually where a business capability is decomposed into more business capabilities in the hierarchy.

Finally, there is the concept of business capability interactions. Use of this component should be limited to ArchiMate information flow relationships. An information flow that can be contained within one application, and crosses many business capability instances, does not need to be identified. An information flow could be programmatic data exchange between two applications, a swivel chair interface where someone transcribes data from one application to another (expressed in the ArchiMate language as a data object[3]), or there is a person-to-person interaction verbally or through the exchange of a paper or paper-like artifact (expressed as a business object).

6.4.2 Acquire Retail Product Online Value Stream

It is now time to move to an example to illustrate what has been presented so far. This example shows how a retail purchase through an Online Store would be handled. To perform the analysis, many catalogs are essential for rapid analysis. This includes the business capability catalog, application catalog, and enterprise data model to represent both business and data objects. Finally, the organizational strategy with related goals and objectives will direct how the selected value stream needs to change to achieve the desired business results.

Before looking at the model itself, the following narrative describes the value stream stages in more detail.    Browse Online Store

To navigate any retail store, there is a layout that is part of the whole buying experience. The store entrance and layout are planned, as are the products associated with that layout. If the customer’s identity is known, the layout can be adjusted to their preferences. Available incentives are usually also presented at this stage. Success is that the customer has been able to find a product they are looking for.    Select Product(s) for Purchase

Now that the customer has found a product they are looking for, they can go to the next level of detail depending on the attributes of the product they have selected. That could be size, color, or other attributes. They may also be interested at this time if the product is in the warehouse or not. When they have finished configuring the product, they can add it to the basket which marks the completion of this value stream stage.

It is worth noting at this time that value streams do not have to be executed in sequence. The customer could choose to go back to the beginning of the value stream and loop a few times. Similarly, the customer could skip a step and not review their basket if they want to check out.    Review Basket

At this stage, the customer can review the items they have placed in their basket. They can decide to change quantities and see what incentives could be applied based on what is in their basket. This stage concludes by having the customer choosing to move to pay for the products.    Purchase Products

With the desired product selected, it is now time to confirm delivery options and payment details. At this point the customer will have to provide identity details either one time or register for future re-use including functionality such as join the retailer’s loyalty program. The shipping choice will usually affect the overall purchase total cost so precedes the final entry of payment information for processing the transaction. At the end of this stage, the customer is provided with both an invoice for the products purchased as well as a receipt for the payment.    Deliver Products

Now that the purchase has been finalized, the last value stream stage can be executed. In this stage the products are picked from the warehouse and packed for shipping. A shipping tracking number is generated once the package is picked up by the delivery organization. This value stream stage and the entire value stream ends once the shipper confirms delivery of the package to the customer.

Figure 9 shows what the narrative looks like when modeled as business capability instances within the value stream.

Figure 9: Acquire Retail Product Online Value Stream

The business capability instances in the model allow for analysis to see how to improve the way the value stream executes. This is where an architecture modeling tool that spans architecture domains really proves its worth. As the inventory of models across domains becomes more complete, there is the ability to either drill down into a component of the business capability instance or see inter-dependencies with other value streams.

7 Business Capability Planning

This document was written during the COVID pandemic.[4] The innovation that occurred and continues to occur based on the pandemic is one of the largest step changes in the world in many years. The world of retail was no exception. Organizations that did not have an online fulfillment mechanism either created that new value stream or they perished. Physical retail stores have added customer pickup and other mechanisms to reduce physical interactions as a new option.

Enterprise Architects at organizations can use the techniques described in this document to imagine new value streams that leverage existing business capability instances where they are available and facilitate the development of new or improved business capability instances where needed to allow for the new value stream to execute successfully.

During the pandemic these new value streams were put in place quite rapidly and usually with business capability instances that had low maturity and value streams that executed with a lot of manual intervention. By using the techniques and models explained in this document organizations can take these value streams and iterate to improve the maturity of the business capability instances to optimize the new value streams or choose to retire the value streams and associated capability instances if the business conditions no longer require that value stream to be in place.

7.1 Business Capability Instance Analysis Approach

Improving business capability instances is not an end in itself. Assessing business capability instances in any of the following planning scenarios needs to be grounded in improving the value streams the business capabilities instantiate. Priority should be given to business capability instance enhancements leading to value stream improvement that achieves the goals and objectives the organization has established.

In looking at the organization’s balanced scorecard, the one outcome directly aligned to the Acquire Retail Product Online value stream is to increase the number of people using coupons by 1%. The outcome of having more repeat customers will rely on a different marketing value stream to drive traffic that triggers this value stream.

  • Optimize: this is the most common scenario for planning business capabilities where one or more of the components of a capability instance is changed

  • Consolidate: the next most common scenario is where capability instances are consolidated

  • The usual means is through application rationalization and/or reorganization. This approach can be used during post-merger or reorganization scenarios.

  • Create: changing business landscapes can lead to the creation of entire new value streams and/or new business capability and business capability instances that can extend the reach or velocity of a value stream

  • Care needs to be taken to ensure that duplicate business capability instances are not created, or at least done with intent.

  • Retire: there are rare situations where all business capability instances are retired

  • When this occurs, the overall business capability is removed from the organization’s capability catalog. Care needs to be taken in these situations to ensure that unidentified value streams that leverage this business capability instance are not impacted.

7.1.1 Optimize a Business Capability Instance

Identify distinct parts of each business capability that need to be enhanced or deprecated; those components should be identified within the model as “gaps” to provide the opportunity for further analysis. A consistent set of gaps that can be applied based on the component of the business capability that is affected will make planning easier. The following gap types are provided as examples:

  • Application Enhancement: this could be both a completely new application or additional or deprecated functionality within an existing application

  • Business Process Change: a modification to an existing or creation of a new business process

  • Resource Change: the addition or removal of a “tangible” resource needed for the capability instance

  • Role/Stakeholder Change: sometimes it may make sense for reorganization of who supports various business capability instances

  • This could either be for increasing the responsibility within one part of the organization or reallocating responsibilities for business capability instances to an area of the organization with more expertise.

  • Information/Data Object: in today’s information age information is king

  • The root of a particular value stream’s execution is where there is little to no transfer of data between business capability instances or worse where the data is incomplete or incorrect.

For the retail organization, they have decided to optimize the Delivery Management business capability instance by having the delivery drivers use a Signature Pad to confirm the order.

7.1.2 Consolidate Business Capability Instances

The act of consolidating business capability instances is a common occurrence, especially after mergers and acquisitions. From an IT perspective, this manifests itself as an application and/or technology rationalization process that often occurs in the absence of the perspectives value streams provide. There are many situations where consolidating capability instances makes sense to support organizational goals. Retiring one of the instances to realize savings is one of the biggest drivers for rationalizing business capability instances.

By using business capability planning that includes value stream analysis, the potential risks of consolidating capability instances may impact other value streams that leverage that capability instance. This could be either at the value stream level where two value streams are intertwined or just at the business capability instance level.

For the retail organization there are two Inventory Management applications. This is because of a merger that results in two different warehouses that use two different Inventory Management applications. To streamline the ordering process, the company has decided to consolidate the Modern Warehouse Management application versus the Legacy Warehouse Management application since the Legacy Warehouse Management application would be more difficult to integrate into the CRM application.

7.1.3 Create a Business Capability Instance

An organization’s ability to enhance or create new value streams by re-using the business capabilities they already have is key to overall success. Invariably all organizations need to evolve for all kinds of reasons. Business capability planning ensures that business capability instances are only created when they are required within the context of a value stream.

While re-using business capability instances is usually a best practice, there are times when creating new business capability instances is beneficial. Many mature business capability instances are mission-critical to one or more value streams or may be instantiated in a way that is difficult to enhance that instance rapidly. Finally, there may be a situation where a particular value stream and/or business capability instance is only required for a brief time.

In the retail organization, they would like to add incentives to the website to try and drive additional purchases. This requires a new business capability instance as the organization has already implemented Incentive Management. The current incentives are coupons for the bricks and mortar stores that are sent using the CRM application as emails to customers who have registered to be on the organization’s mailing list. This new instance will need an interface to the Online Store application to display generic incentives for any website visitor and personalized ones for those who authenticate.

7.1.4 Retire a Business Capability Instance

The last option for business capabilities is to retire them, either as part of optimizing a value stream or when an organization decides to stop executing a particular value stream. This is a scenario where understanding all the value streams that utilize a particular capability is important for risk mitigation.

7.1.5 Updated Acquire Retail Product Online Value Stream – Abstracted

For the next iteration of the value stream, a view of the model that may be more consumable by both the average user and senior leadership is demonstrated. The ArchiMate language allows for more precision within one view and the ability to create a connected set of models over time. For the uninitiated, the ArchiMate language may be daunting to consume. A model that is more narrative of the business capability instances within a particular value stream can be easier to understand.

Layer the model with the assessment performed in the previous section for the analysis of business capability instances. Using a traffic light color scheme of Red, Yellow, and Green draws attention to the business capability instances that the analysis shows need attention. No real criteria were applied except the judgment of the team for the coloring.

Figure 10: Abstracted Acquire Retail Product Online Value Stream

7.2 Planning Business Capability Instance Increments

Many times, business capabilities cannot move to the final desired state in one step. There may also be dependencies that mean sequencing of capability increments needs to be coordinated. Depending on the gap that needs to be addressed, there could be sequencing where a business process change needs to occur ahead of an application enhancement. No matter the dependencies that would provide some form of stepwise change, one or more gaps being addressed together would be identified as a plateau; i.e., where the collection of enhancements to address the gaps preserve a functional value stream.

The architecture model will be able to identify the business capabilities that have gaps and where those gaps may have dependencies. The management of the resources and the timing of who will deliver the business capability enhancements through work packages is left to the project or program. A gap is indicated using the ArchiMate gap element, where the same gap assigned to multiple business capabilities shows a potential grouping.

Looking at the business capability improvements from the previous section, they would be modeled as follows:

  • Optimize: the Delivery Management business capability instance will be enhanced by providing delivery drivers with a Signature Pad that sends the signature back to the shipping application; this gap at the business capability level seems small in the model but will take some time to design and implement

  • Consolidate: the Modern Warehouse Management instance is upgraded to include Electronics Warehouse products

  • These have been modeled as gaps at the application level. Once the Modern Warehouse Management application has been enhanced, the Inventory Management instance using the Legacy Inventory Management application can be retired.

  • Create: a new Incentive Management capability instance is going to be added to the first value stream, as shown below (Figure 11)

  • Retire: this is illustrated in Figure 11, again at the application level

  • There are many business capabilities and associated value streams that depend on the Legacy Warehouse Management application. Since there is no real “gap” for the Legacy Warehouse Management application, mark that application with an event: “Retire Application”.

Figure 11: Addition of the Incentive Management Application

With the identified gaps a project manager or the operations teams can use the model to confirm timing based on team capacity and, where necessary, highlight dependencies that would affect the order in which these gaps would be addressed.

The gaps in the example are independent of each other except for retiring the Warehouse Management business capability that is instantiated using the Legacy Warehouse Management application. There will be situations where a series of gaps are identified that are all required to make the value stream execute effectively. This means that many teams will have to work together to coordinate their efforts using standard project management practices or more coordinated operational release management.[5]

7.3 Digital Transformation and Business Capability Planning

Digital Transformation is held at times to be a specialized form of innovation that is disproportionate to other forms of innovation. This perception is due to many factors including the pace of technology change, the inability of organizations to adapt at the same pace, and a fear of change that hinders the adoption of most innovation.

Business capability planning has the potential to make Digital Transformation less daunting and more achievable. While entire new value streams may be developed, they usually enhance or create new business capability instances that are combined with existing business capability instances that can be more rapidly implemented. When put in the light of value streams and business capabilities, new technologies can be seen better in the context of the stakeholders utilizing the organization’s value streams versus the innovative technology being the focal point with little to no context.

The use of technology – like any other resource leveraged to create or enhance a business capability instance – is really a component of an existing business capability instance. Using business capability planning models and techniques Enterprise and Business Architects can more effectively demonstrate how to best leverage these new technologies.

8 Conclusion

Business capability planning can be a powerful tool for Business and Enterprise Architects. Understanding value streams is a critical first step in being able to perform business capability planning. Creating and curating a business capability catalog provides a dictionary of terms to support dialog between different stakeholders.

Associating business capabilities to value streams and then modeling how those business capabilities have been instantiated provides the basis for further analysis. Value streams can be optimized by changing the business capability instances.

Appendix A: Business Capability Catalog

The following definitions are provided for the business capabilities that were used in the examples within this document.

Business Capability


Accounts Payable

The ability to manage payment for the receipt of goods or services.

Basket Management

The ability to select products or services to check out and pay.

Benefits Management

The ability to provide non-payroll benefits for employees.

Business Planning

The ability to define a direction to focus resources and assess progress in achieving defined goals and objectives.

Catalog Products

The ability to maintain a categorized list of products or services.

Compensation Management

The ability to provide a person with money or other economic value in exchange for goods or labor.

Contract Management

The ability to negotiate, monitor, renew, and end contracts with vendors and suppliers.

Customer Relationship Management

The ability to monitor and initiate interactions with customers across multiple contact channels and methods.

Delivery Management

The ability to track the geographic location of goods and/or people from the origin to the ultimate destination.

Finance Management

The ability to manage funding, investments, assets, and liabilities in a way that meets legal and regulatory requirements.

Human Resources Management

The ability to recruit, hire, develop, compensate, and assign people to perform activities for the organization.

Identity Management

The ability to resolve the identity of a person or thing.

Incentive Management

The ability to manage financial or other rewards to influence the behavior of employees, suppliers, or customers.

Inventory Management

The ability to plan and manage the flow of goods from suppliers to storage locations and from these locations to the point of use or disposal.

Job Posting

The ability to advertise an available position within the organization.

Market Research

The ability to assess the competitive landscape across organizations and product and service offerings that may impact the organization’s business plan.

Payment Processing

The ability to manage the transfer of funds to payees.

Payroll Management

The ability to compensate employees on a regular basis, adhering to the laws and regulations of the jurisdiction within which that employee resides.

Position Management

The ability to maintain a catalog of positions that includes the skills, experience, and certifications required to be an appropriate candidate for a particular job.

Product Development

The ability to research, design, and source products or services for sale to other organizations or people.

Program Management

The ability to initiate, plan, execute, control, and compete work as part of a team to achieve specific goals and success criteria.

Risk Management

The ability to identify, access, and prioritize uncertainty and then apply resources to minimize, monitor, and control the probability and/or impact of unfortunate events.

Schedule Management

The ability to coordinate the timing of people and resources to be available at a specific time and place.

Skills Assessment

The ability to determine the maturity of a person’s skills and abilities.

Store Layout Management

The ability to design the way a customer navigates a store for the purpose of discovering, selecting, and then purchasing products.

Appendix B: Other Frameworks

Business capability planning can form the basis to derive other models and fit with other frameworks. This appendix documents how business capability planning using value streams can inform these. Some sections highlight where there is usage of similar terms and describes the differences between them.

B.1 Business Process Modeling

Business process models have fewer formal boundaries or conditions than value streams and business capabilities. Business process models can be tightly or loosely aligned to value streams or the underlying business capabilities. Using business capability instances can provide the actors and many of the coarse-grained steps that can then be drilled down to a level deeper to provide more detailed dependencies and specifications.

A business or application process is one of the components of a business capability instance. While a system analyst may model at this level to build the specific business logic required in the application, business analysts rarely model a process at the business capability instance level.

What is more common is to create a business process at the value stream stage level. The actors and application interactions can be detailed in a sequence and swim-lane diagram by using Business Process Modeling Notation™ (BPMN™) or a business process modeling language of choice. Here is where more detailed business process modeling will both be informed by and inform the value stream.

Some business processes will span value stream stages. Many business processes are written from only the human actor perspective; some are written for each actor in isolation to support training. Harmonizing the processes that are described in the business capability instances is not worth the effort. Having analysts working with architects to review their models is most certainly worth the effort.

B.2 Scaled Agile Framework Enterprise Value Streams

The Scaled Agile Framework® enterprise (SAFe®) looks to help organizations who are interested in “… achieving business agility using Lean, Agile, and DevOps”.[6] If you are one of those organizations, business capability planning may be a valuable addition to create Operational value streams (see below) as well as defining an Agile Release Train.

SAFe Operational Value Streams[7]

Within SAFe, the concept of value stream has many of the same aspects as described in this document. SAFe describes two classes of value stream: Operational and Development. The Operational value streams are in essence what has been described in this document. The Development value stream would describe the value stream and supporting business capability instances that allow for the development of enhancements or new IT assets that would improve individual business capability instances with an aim to streamline and optimize Operational value streams.

As noted on the SAFe website: “… most SAFe guidance focuses on helping the systems and software developers, product managers, engineers, scientists, IT practitioners, and others who work in Development value streams … However, the customers they serve live either in the company or at the end of the Operational value streams.”

Organizations who are using agile or SAFe practices will be able to link between Operational and Development value streams using business capability planning at the business capability instance level.

Agile Release Trains[8] and Operational Value Streams

An Agile Release Train looks to align agile product management teams’ backlog and enhancements by either the Operational or Development value streams they share or support. For a business capability planning Operational value stream, all the enhancements proposed for the Acquire Retail Product Online value stream would be added to the backlog for each of the affected product teams.

In the retail organization the CRM, Online Store, and the Modern Warehouse Management and Legacy Warehouse Management application teams are all different agile teams. The enhancements proposed would result in two release trains that require coordination between two teams each.

The first release train would be the enhancement that bridges the Online Store Incentive Management integration with the CRM gap. The agile teams can further break down the high-level business capability instance improvements recommended into the appropriate product enhancements and into the product backlog. From there, the proposed product release schedule can be determined and communicated to the appropriate stakeholders. The Agile Release Train will iterate until the enhancements required to support the business capability instances for this value stream are completed and the value those enhancements achieve can be measured.

The second release train would be when the Electronics Warehouse is able to move to use the Modern Warehouse Management application and the Legacy Warehouse Management application team can retire that application. This release train would be more complicated since both applications support many more Operational value streams than just the Acquire Retail Product Online value stream. This is again where business capability planning can help organizations that use SAFe to have inter-dependent roadmaps based on each portfolio.

B.3 Journey Maps

Value streams are usually triggered by stakeholders who derive value from them. A journey map is an analysis of the experience of a stakeholder through a series of touch points to understand how that experience can be improved. A journey map can be aligned to the value stream stages and the underlying business capability instances for analysis and improvement of the value stream.

Table 3 shows a journey map based on the Acquire Retail Product Online value stream. The journey map extends the value stream by examining the customer experience for the stages that are under investigation. In this situation it is only for the online purchase and not the final value stream stage. The relevant touch points are added and assessed. The areas for improvement could then be mapped back to the capability instances that need to be modified following the business capability planning framework.

Table 3: Acquire Retail Product Online Value Stream Journey Map

Customer Persona: New Customer

Scenario: Searching for an advertised product to get a discount and set up an account for the first time.

Touch point

Arrive at Website

Browse for Products

Select Products

Review Basket

Pay for Purchase

User thoughts or feelings

Opportunity for improvement

Affected business capability instance component

B.4 Lean Value Stream

Lean value streams came out of the Lean Thinking movement, which originated in the automotive industry in Japan (at Toyota, the process is known as “material and information flow mapping”). The core premise of Lean Thinking is to identify and eliminate waste from a firm’s processes, with the goal of only retaining those activities that create or increase value for the end user. The lean value stream is a diagrammatic representation of the sequence of activities required to design, produce, and deliver a good or service to a customer (see Figure 12). By adding performance metrics around each process (such as Processing Time, Response Time, and Percent Complete & Accurate), it becomes possible to use lean value streams to identify opportunities for waste reduction.

The lean value stream’s primary purpose is to document, analyze, and improve the flow of information or materials required to produce a product or service for a customer. This would seem to align to the business capability planning rationale as well. This invariably leads to the question: if the purposes are aligned, could the techniques also align?

There is a key abbreviation in the Lean Six Sigma[9] world called SIPOC (Suppliers, Inputs, Processes, Outputs, and Customers). Looking at a business capability planning value stream, it would cover the stakeholder, goals, and outcomes. Looking at the model above, processes and functions are combined to enable some form of analysis.

Using business capability planning techniques, lean concepts around waste through lead time and processing time could be used to see how efficiently each business capability instance is performing in support of a particular value stream stage or entire value stream.

B.5 Porter Value Chain

Value chains were introduced by Michael Porter in his book Competitive Advantage (see Referenced Documents):

“The value chain disaggregates a firm into its strategically-relevant activities in order to understand the behavior of costs and the existing potential sources of (competitive) differentiation.”


Figure 12: Michael Porter’s Value Chain (Source: Competitive Advantage)

With its primary focus on activity costs and margins, the value chain perspective is concerned with understanding how economic value is created. Value chains provide a macro-level view of how a business produces economic value (i.e., money). Value chains, like the Business Model Canvas, usually model an entire organization or business unit. The value chain from that perspective can be informative as a basis to decide which value streams need to be modeled to ensure that the value chain operates.

B.6 Risk and Security Perspectives

Risk and security perspectives are pervasive throughout the organization. There may be some business capabilities specific to security such as Identity Management. There may also be processes that make a business capability instance, or goals or outcomes of the execution of a value stream. It also may be a value stream itself, such as when an investigation into theft within the retail organization has occurred.

The TOGAF® Series Guide: Integrating Risk and Security within a TOGAF Enterprise (see Referenced Documents) provides a guide to security controls and a linkage together with other standards.

Appendix C: Recruit Employee Value Stream

The Recruit Employee value stream was developed early in the process of writing this document. The authors decided to focus on a more customer-centric value stream for the examples. That said, with the work done, it would be useful to include this more back-office example.

As seen in the organization’s strategy, they are looking for revenue growth. That means that the ability to attract and hire new employees is key to the overall organization’s success. Currently, the value stream takes over twice as long to execute than the organization requires. Additionally, when the final candidate became an employee some skills gaps resulted. This value stream needs to reduce the current time to execute and improve the skills and experience alignment between the position that is posted and the eventual successful candidate.

The value stream has been broken down into the following five value stream stages that are also illustrated in Figure 13. The value stream is initiated when a vacant position is created either as a new position or when an employee has left the organization:

  • Define Position: the hiring manager reviews the required role for their team within the program for which they have responsibility

  • The HR advisor reviews the available role catalog and position descriptions to leverage one or more to adapt a position description. Finally, the finance analyst confirms that there is a sufficient compensation budget for the position.

  • Communicate Open Position: based on the position description, the recruiter creates the position in the recruiting application and then subsequently the company website and a contracted job posting website

  • Candidates respond through either channel by submitting a resumé and cover letter which is then migrated to a document repository. The HR advisor manually reviews each resumé to reject unqualified candidates to get to a “manageable” list of candidates.

  • Select Final Candidates: the team of the hiring manager and the HR advisor review the shortlist of candidates to score the candidates to select a shortlist to interview

  • The shortlisted candidates are scheduled and interviewed. The scores are then adjusted to produce a ranked list of candidates to whom an offer will be extended.

  • Offer Position: a review of the available salary bands provides the input required to create the employment contract that is sent to the candidate along with the pre-employment information documents

  • A final police check is required along with the signed contract to complete this value stream stage.

  • Onboard Candidates: when the candidate presents for employment, they are provided with office space, credentials, as well as finalizing payroll and benefits information

  • At this point, the employee is not ready to be able to perform the role for which they have been hired.

An initial analysis of the value stream stages suggests the following business capabilities are required for each of the value stream stages. Also added are stage end points as well as the key stakeholders, trigger for the value stream, and goal for improving the value stream.

Figure 13 models the value stream as well as business capability instances.

Figure 13: Recruit Employee Value Stream with Business Capability Instances

Acronyms & Abbreviations

ADM        Architecture Development Method

API        Application Program Interface

BPMN       Business Process Modeling Notation

CBA        Certified Business Architect

CRM        Customer Relationship Management

ERP        Enterprise Resource Planning

HR         Human Resources

IAM        Identity and Access Management

KPI        Key Performance Indicator

NATO       North Atlantic Treaty Organization

RTO        Research and Technology Organization

SAFe       Scaled Agile Framework (enterprise)

SAS        Studies, Analysis, and Simulation

SCM        Supply Chain Management

SIPOC      Suppliers, Inputs, Processes, Outputs, and Customers

SOA        Service-Oriented Architecture


[1] Visit for the full ArchiMate 3.2 Specification and other related documents.

[2] Visit to download the Archi tool and plugins.

[3] Refer to the ArchiMate Specification, §9.4.1 (Data Object) – see Referenced Documents.

[5] See Section B.2 and the notes on Agile Release Trains.

return to top of page