Home The TOGAF® Standard
Search
Word Search | Search Index


Advanced Search
Provide feedback on this page
TOGAF® Fundamental Content
Extended Guidance
General How-To
Establishing an EA Team
Domains
Agile Methods
Business Architecture
Data/Information Architecture
Sustainability
Security Architecture
Reference Models & Method

4. Phase B: Business Architecture

Chapter Contents: 4.1 Objectives | 4.2 Inputs | 4.3 Steps | 4.4 Outputs | 4.5 Approach

This chapter describes the development of a Business Architecture to support an agreed Architecture Vision.

Figure 4-1: Phase B: Business Architecture

4.1 Objectives

The objectives of Phase B are to:

4.2 Inputs

This section defines the inputs to Phase B.

4.2.1 Reference Materials External to the Enterprise

4.2.2 Non-Architectural Inputs

4.2.3 Architectural Inputs

4.3 Steps

The level of detail addressed in Phase B will depend on the scope and goals of the overall architecture effort.

New models characterizing the needs of the business will need to be defined in detail during Phase B. Existing business artifacts to be carried over and supported in the target environment may already have been adequately defined in previous architectural work; but, if not, they too will need to be defined in Phase B.

The order of the steps in Phase B as well as the time at which they are formally started and completed should be adapted to the situation at hand, in accordance with the established Architecture Governance. In particular, determine whether in this situation it is appropriate to conduct Baseline or Target Architecture development first, as described in the TOGAF Standard — Applying the ADM.

All activities that have been initiated in these steps should be closed during the Finalize the Business Architecture step (see 4.3.8 Finalize the Business Architecture). The documentation generated from these steps must be formally published in the Create/Update the Architecture Definition Document step (see 4.3.9 Create/Update the Architecture Definition Document).

The steps in Phase B are as follows:

4.3.1 Select Reference Models, Viewpoints, and Tools

Select relevant Business Architecture resources (reference models, patterns, etc.) from the Architecture Repository, on the basis of the business drivers and stakeholder concerns.

Select relevant Business Architecture viewpoints (e.g., operations, management, financial); i.e., those that will enable the architect to demonstrate how the stakeholder concerns are being addressed in the Business Architecture.

Identify appropriate tools and techniques to be used for capture, modeling, and analysis, in association with the selected viewpoints. Depending on the degree of sophistication warranted, these may comprise simple documents or spreadsheets, or more sophisticated modeling tools and techniques, such as activity models, business process models, use-case models, etc.

4.3.1.1 Determine Overall Modeling Process

Business modeling and strategy assessments are effective techniques for framing the target state of an organization's Business Architecture (see 3.3.4 Evaluate Capabilities). The output from that activity is then used to articulate the business capabilities, organizational structure, and value streams required to close gaps between the current and target state. As addressed in 3.5 Approach , the frameworks for these maps may already exist and should be leveraged, now using them to characterize gaps and better map business value to achieve the Target Business Architecture.

For each viewpoint, select the models needed to support the specific view required, using the selected tool or method.

Ensure that all stakeholder concerns are covered. If they are not, create new models to address concerns not covered, or augment existing models (see 4.5.7 Applying Modeling Techniques). Business scenarios are a useful technique to discover and document business requirements, and may be used iteratively, at different levels of detail in the hierarchical decomposition of the Business Architecture. Business scenarios are described in the TOGAF® Series Guide: Business Scenarios.

The techniques described in 4.5 Approach can be utilized to progressively decompose a business:

The level and rigor of decomposition needed varies from enterprise to enterprise, as well as within an enterprise, and the architect should consider the enterprise's goals, objectives, scope, and purpose of the Enterprise Architecture effort to determine the level of decomposition.

4.3.1.2 Identify Required Catalogs of Business Building Blocks

Catalogs capture inventories of the core assets of the business. Catalogs are hierarchical in nature and capture the decomposition of a building block and also decompositions across related building blocks (e.g., organization/actor).

Catalogs form the raw material for development of matrices and views and also act as a key resource for managing the business and IT capability.

The TOGAF Standard — Architecture Content contains a detailed description of catalogs which should be considered for development within a Business Architecture, describing them in detail and relating them to entities, attributes, and relationships in the TOGAF Enterprise Metamodel.

4.3.1.3 Identify Required Matrices

Matrices show the core relationships between related model entities.

Matrices form the raw material for development of views and also act as a key resource for impact assessment, carried out as a part of gap analysis.

The TOGAF Standard — Architecture Content contains a detailed description of matrices which should be considered for development within a Business Architecture, describing them in detail and relating them to entities, attributes, and relationships in the TOGAF Enterprise Metamodel.

4.3.1.4 Identify Required Diagrams

Diagrams present the Business Architecture information from a set of different perspectives (viewpoints) according to the requirements of the stakeholders.

The TOGAF Standard — Architecture Content contains a detailed description of diagrams which should be considered for development within a Business Architecture, describing them in detail and relating them to entities, attributes, and relationships in the TOGAF Enterprise Metamodel.

4.3.1.5 Identify Types of Requirement to be Collected

Once the Business Architecture catalogs, matrices, and diagrams have been developed, architecture modeling is completed by formalizing the business-focused requirements for implementing the Target Architecture.

These requirements may:

Within this step, the architect should identify requirements that should be met by the architecture (see 13.5.2 Requirements Development).

In many cases, the Architecture Definition will not be intended to give detailed or comprehensive requirements for a solution (as these can be better addressed through general requirements management discipline). The expected scope of requirements content should be established during the Architecture Vision phase and documented in the approved Statement of Architecture Work.

Any requirement, or change in requirement, that is outside of the scope defined in the Statement of Architecture Work must be submitted to the Requirements Repository for management through the governed Requirements Management process.

4.3.2 Develop Baseline Business Architecture Description

Develop a Baseline Description of the existing Business Architecture, to the extent necessary to support the Target Business Architecture. The scope and level of detail to be defined will depend on the extent to which existing business elements are likely to be carried over into the Target Business Architecture, and on whether Architecture Descriptions exist, as described in 4.5 Approach . To the extent possible, identify the relevant Business Architecture building blocks, drawing on the Architecture Repository (see the TOGAF Standard — Architecture Content).

Where new architecture models need to be developed to satisfy stakeholder concerns, use the models identified within Step 1 as a guideline for creating new architecture content to describe the Baseline Architecture.

4.3.3 Develop Target Business Architecture Description

Develop a Target Description for the Business Architecture, to the extent necessary to support the Architecture Vision. The scope and level of detail to be defined will depend on the relevance of the business elements to attaining the Target Architecture Vision, and on whether architectural descriptions exist. To the extent possible, identify the relevant Business Architecture building blocks, drawing on the Architecture Repository (see the TOGAF Standard — Architecture Content).

Where new architecture models need to be developed to satisfy stakeholder concerns, use the models identified within Step 1 as a guideline for creating new architecture content to describe the Target Architecture.

If appropriate, investigate different Target Architecture alternatives and discuss these with stakeholders using the Architecture Alternatives and Trade-offs technique (see the TOGAF Standard — ADM Techniques).

4.3.4 Perform Gap Analysis

Verify the architecture models for internal consistency and accuracy:

Identify gaps between the baseline and target, using the gap analysis technique, as described in the TOGAF Standard — Applying the ADM.

4.3.5 Define Candidate Roadmap Components

Following the creation of a Baseline Architecture, Target Architecture, and gap analysis results, a business roadmap is required to prioritize activities over the coming phases.

This initial Business Architecture Roadmap will be used as raw material to support more detailed definition of a consolidated, cross-discipline roadmap within the Opportunities & Solutions phase.

4.3.6 Resolve Impacts Across the Architecture Landscape

Once the Business Architecture is finalized, it is necessary to understand any wider impacts or implications.

At this stage, other architecture artifacts in the Architecture Landscape should be examined to identify:

4.3.7 Conduct Formal Stakeholder Review

Check the original motivation for the architecture project and the Statement of Architecture Work against the proposed Business Architecture, asking if it is fit for the purpose of supporting subsequent work in the other architecture domains. Refine the proposed Business Architecture only if necessary.

4.3.8 Finalize the Business Architecture

4.3.9 Create/Update the Architecture Definition Document

If appropriate, use reports and/or graphics generated by modeling tools to demonstrate key views of the architecture. Route the document for review by relevant stakeholders, and incorporate feedback.

4.4 Outputs

The outputs of Phase B may include, but are not restricted to:

The TOGAF Standard — Architecture Content contains a detailed description of architectural artifacts which might be produced in this phase.

4.5 Approach

Business Architecture is a representation of holistic, multi-dimensional business views of capabilities, end-to-end value delivery, information, and organizational structure; and the relationships among these business views and strategies, products, policies, initiatives, and stakeholders.

Business Architecture relates business elements to business goals and elements of other domains.

4.5.1 General

A knowledge of the Business Architecture is a prerequisite for architecture work in any other domain (Data, Application, Technology), and is therefore the first architecture activity that needs to be undertaken, if not catered for already in other organizational processes (enterprise planning, strategic business planning, business process re-engineering, etc.).

In practical terms, the Business Architecture is also often necessary as a means of demonstrating the business value of subsequent architecture work to key stakeholders, and the return on investment to those stakeholders from supporting and participating in the subsequent work.

The scope of work in Phase B is primarily determined by the Architecture Vision as set out in Phase A. The business strategy defines the goals and drivers and the metrics for success, but not necessarily how to get there. That is the role of the Business Architecture, defined in detail in Phase B.

This will depend to a large extent on the enterprise environment. In some cases, key elements of the Business Architecture may be done in other activities; for example, the enterprise mission, vision, strategy, and goals may be documented as part of some wider business strategy or enterprise planning activity that has its own lifecycle within the enterprise.

In such cases, there may be a need to verify and update the currently documented business strategy and plans, and/or to bridge between high-level business drivers, business strategy, and goals on the one hand, and the specific business requirements that are relevant to this architecture development effort.

In other cases, little or no Business Architecture work may have been done to date. In such cases, there will be a need for the architecture team to research, verify, and gain buy-in to the key business objectives and processes that the architecture is to support. This may be done as a free-standing exercise, either preceding architecture development, or as part of Phase A.

In both of these cases, the business scenarios technique (see the TOGAF® Series Guide: Business Scenarios), or any other method that illuminates the key business requirements and indicates the implied technical requirements for IT architecture, may be used.

A key objective is to re-use existing material as much as possible. In architecturally more mature environments, there will be existing Architecture Definitions, which (hopefully) will have been maintained since the last architecture development cycle. Where Architecture Descriptions exist, these can be used as a starting point, and verified and updated if necessary; see the TOGAF Standard — Architecture Content.

Gather and analyze only that information that allows informed decisions to be made relevant to the scope of this architecture effort. If this effort is focused on the definition of (possibly new) business processes, then Phase B will necessarily involve a lot of detailed work. If the focus is more on the Target Architectures in other domains (data/information, application systems, infrastructure) to support an essentially existing Business Architecture, then it is important to build a complete picture in Phase B without going into unnecessary detail.

4.5.2 Developing the Baseline Description

If an enterprise has existing Architecture Descriptions, they should be used as the basis for the Baseline Description. This input may have been used already in Phase A in developing the Architecture Vision, such as the business capability map or a core set of value streams as introduced in 3.5.2 Creating the Architecture Vision , and may be sufficient in itself for this baseline.

The reasons to update these materials include having a missing business capability, a new value stream, or changed organizational unit that has not previously been assessed within the scope of the Enterprise Architecture project. 4.5.3 Applying Business Capabilities through 4.5.6 Applying Information Maps address the use of core Business Architecture methods to model the Business Architecture driven by the strategy scope from Phase A. Note that putting these methods into action to drive a focus and target state for later architecture work does not mean that the fundamental frameworks from Phase A, such as a common enterprise business capability map, will necessarily change but rather that they are applied in a manner driven by the scope and needs of the specific Enterprise Architecture project.

If no Architecture Descriptions exist, information should be gathered and Business Architecture models developed.

Whatever the scope of the specific project, it is important to determine whether it is the fundamental view of the business that is changing or the usage of those views to determine scope, priorities, and relationships for the specific project in relation to the rest of the enterprise.

4.5.3 Applying Business Capabilities

The business capability map found or developed in the Architecture Vision phase provides a self-contained view of the business that is independent of the current organizational structure, business processes, information systems and applications, and the rest of the product or service portfolio. Those business capabilities should be mapped back to the organizational units, value streams, information systems, and strategic plans within the scope of the Enterprise Architecture project. This relationship mapping provides greater insight into the alignment and optimization of each of those domains (see Relationship Mapping in TOGAF® Series Guide: Business Capabilities).

Another common analysis technique involves heat mapping, which can be used to show a range of different perspectives on the same set of core business capabilities. These include maturity, effectiveness, performance, and the value or cost of each capability to the business. Different attributes determine the colors of each capability on the business capability map (see Heat Mapping in TOGAF® Series Guide: Business Capabilities).

For example, a business capability maturity heat map shows the desired maturity as green for a specific capability, one level down as yellow, and two or more levels down as red. Other colors may indicate status, such as purple denoting a capability that does not exist yet in the company but is desired, or perhaps as a capability that is over-funded and has more resources than necessary. This gap analysis is directly tied to the Enterprise Architecture project underway; a gap is only relevant in the context of the business need and provides focus for more mapping in this phase or priorities for later architecture phases.

4.5.4 Applying Value Streams

Value streams provide valuable stakeholder context into why the organization needs business capabilities, while business capabilities provide what the organization needs for a particular value stage to be successful.

Start with the initial set of value stream models for the business documented in the Architecture Vision phase. Within the scope of the specific Enterprise Architecture project, if sufficiently larger in breadth, there may be a need for new value streams not already in the repository.

A new or existing value stream can be analyzed within the scope of the project through heat mapping (by value stream stage) or by developing use-cases around a complete definition of the value stream (see Baseline Example in the TOGAF® Series Guide: Value Streams). A project might focus on specific stakeholders, one element of business value, or stress some stages over others to develop better requirements for solutions in later phases.

The most substantive benefits come from mapping relationships between the stages in a value stream to business capabilities, then performing a gap analysis for capabilities (such as heat mapping) in the context of the business value achieved by the value stream for a specific stakeholder (see Mapping Value Streams to Business Capabilities in the TOGAF® Series Guide: Value Streams).

4.5.5 Applying the Organization Map

An organization map shows the key organizational units, partners, and stakeholder groups that make up the enterprise ecosystem. The map should also depict the working relationship between those entities, as distinct from an organizational chart that only shows hierarchical reporting relationships. The map is typically depicted as a network or web of relationships and interactions between the various business entities (see Organigraphs: Drawing How Companies Really Work, by Mintzberg and Van der Heyden, 1999).

The business unit is the main concept used to establish organization maps. In keeping with the relatively unconstrained view of what constitutes as enterprise, the enterprise may be one business unit for the project underway, may include all business units, or also include third parties or other stakeholder groups. The interpretation depends on the scope of the architecture effort.

This map is a key element of Business Architecture because it provides the organizational context for the whole Enterprise Architecture effort. While capability mapping exposes what a business does and value stream mapping exposes how it delivers value to specific stakeholders, the organization map identities the business units or third parties that possess or use those capabilities and which participate in the value streams.

Taken together with the methods in 4.5.3 Applying Business Capabilities , 4.5.4 Applying Value Streams , and the associated Guides, the organization map provides an understanding of which business units to involve in the architecture effort, who and when to talk about a given requirement, and how to measure the impact of various decisions.

For further guidance on organization maps, see the TOGAF® Series Guide: Organization Mapping.

4.5.6 Applying Information Maps

Characterizing information in the Business Architecture phase starts with the elements that matter most to the business, such as product, customer, factory, etc. With a list of these key elements, a cross-discipline team can list and map the information that matters most and how it is described using business terms. Domains of information can be derived from groupings or categories that the business terms fall into logically. These domains are a good place to start the information map for completeness and highest value before proceeding later to the details of data types.

Relationships among the information domains can then be added to the map as the next level of understanding for a good baseline information map. The most significant benefit then comes with building matrices between information and business capabilities. The linkage between the information that matters most to the business and the business capabilities that describe the ability to apply that information to create value is a key aspect of Business Architecture. These information maps and relationships to business capabilities will then apply in later architecture phases on data characterization, applications, and infrastructure.

For further guidance on information maps, see the TOGAF® Series Guide: Information Mapping.

4.5.7 Applying Modeling Techniques

The modeling and mapping techniques provided here are extensions that implement the business capabilities, value streams, and organization maps described above in Phase B into the practices of the business. They expand the operating model, which is a representation for how an organization operates across a range of domains in order to accomplish its purpose (see A Method for Identifying Process Re-Use Opportunities to Enhance the Operating Model, M. de Vries et al.).

In addition to the techniques described above (capability maps, value streams, and organization maps), a variety of other modeling techniques may be employed, if deemed appropriate. For example:

Figure 4-2: UML Business Class Diagram

All three types of model above can be represented in the Unified Modeling LanguageTM (UML®), and a variety of tools exist for generating such models.

Certain industry sectors have modeling techniques specific to the sector concerned.

4.5.8 Architecture Repository

As part of Phase B, the architecture team will need to consider what relevant Business Architecture resources are available from the Architecture Repository (see the TOGAF Standard — Architecture Content), in particular:

return to top of page
Copyright © 1999-2022 The Open Group, All Rights Reserved.
TOGAF is a registered trademark of The Open Group
<<< Previous Home Next >>>