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

8.1 Objectives

The objectives of Phase B are:

• To describe the Baseline Business Architecture
• To develop a Target Business Architecture, describing the product and/or service strategy, and the organizational, functional, process, information, and geographic aspects of the business environment, based on the business principles, business goals, and strategic drivers
• To analyze the gaps between the Baseline and Target Business Architectures
• To select and develop the relevant architecture viewpoints that will enable the architect to demonstrate how the stakeholder concerns are addressed in the Business Architecture
• To select the relevant tools and techniques to be used in association with the selected viewpoints

8.2 Approach

8.2.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 the work in Phase B 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. The business strategy typically defines what to achieve - the goals and drivers, and the metrics for success - but not how to get there. That is role of the Business Architecture.

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 scenario technique (see Part III, 26. Business Scenarios) of the TOGAF ADM, 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 Part V, 39.4.1 Architecture Continuum .

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.

8.2.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 an Architecture Vision, and may even be sufficient in itself for the Baseline Description.

Where no such descriptions exist, information will have to be gathered in whatever format comes to hand.

The normal approach to Target Architecture development is top-down. In the Baseline Description, however, the analysis of the current state often has to be done bottom-up, particularly where little or no architecture assets exist. In such a case, the architect simply has to document the working assumptions about high-level architectures, and the process is one of gathering evidence to turn the working assumptions into fact, until the law of diminishing returns sets in.

Business processes that are not to be carried forward have no intrinsic value. However, when developing Baseline Descriptions in other architecture domains, architectural components (principles, models, standards, and current inventory) that are not to be carried forward may still have an intrinsic value, and an inventory may be needed in order to understand the residual value (if any) of those components.

Whatever the approach, the goal should be to re-use existing material as much as possible, and to gather and analyze only that information that allows informed decisions to be made regarding the Target Business Architecture. It is important to build a complete picture without going into unnecessary detail.

8.2.3 Business Modeling

Business models should be logical extensions of the business scenarios from the Architecture Vision, so that the architecture can be mapped from the high-level business requirements down to the more detailed ones.

A variety of modeling tools and techniques may be employed, if deemed appropriate (bearing in mind the above caution not to go into unnecessary detail). For example:

• Activity Models (also called Business Process Models) describe the functions associated with the enterprise's business activities, the data and/or information exchanged between activities (internal exchanges), and the data and/or information exchanged with other activities that are outside the scope of the model (external exchanges). Activity models are hierarchical in nature. They capture the activities performed in a business process, and the ICOMs (inputs, controls, outputs, and mechanisms/resources used) of those activities. Activity models can be annotated with explicit statements of business rules, which represent relationships among the ICOMs. For example, a business rule can specify who can do what under specified conditions, the combination of inputs and controls needed, and the resulting outputs. One technique for creating activity models is the IDEF (Integrated Computer Aided Manufacturing (ICAM) DEFinition) modeling technique.

  The Object Management Group (OMG) has developed the Business Process Modeling Notation (BPMN), a standard for business process modeling that includes a language with which to specify business processes, their tasks/steps, and the documents produced.

• Use-Case Models can describe either business processes or systems functions, depending on the focus of the modeling effort. A use-case model describes the business processes of an enterprise in terms of use-cases and actors corresponding to business processes and organizational participants (people, organizations, etc.). The use-case model is described in use-case diagrams and use-case specifications.
• Class Models are similar to logical data models. A class model describes static information and relationships between information. A class model also describes informational behaviors. Like many of the other models, it can also be used to model various levels of granularity. Depending on the intent of the model, a class model can represent business domain entities or systems implementation classes. A business domain model represents key business information (domain classes), their characteristics (attributes), their behaviors (methods or operations), and relationships (often referred to as multiplicity, describing how many classes typically participate in the relationship), and cardinality (describes required or optional participation in the relationship). Specifications further elaborate and detail information that cannot be represented in the class diagram.

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

Certain industry sectors have modeling techniques specific to the sector concerned. For example, the Defense sector uses the following models. These models have to be used carefully, especially if the location and conduct of business processes will be altered in the visionary Business Architecture.

• The Node Connectivity Diagram describes the business locations (nodes), the "needlines" between them, and the characteristics of the information exchanged. Node connectivity can be described at three levels: conceptual, logical, and physical. Each needline indicates the need for some kind of information transfer between the two connected nodes. A node can represent a role (e.g., a CIO), an organizational unit, a business location or facility, and so on. An arrow indicating the direction of information flow is annotated to describe the characteristics of the data or information - for example, its content, media, security or classification level, timeliness, and requirements for information system interoperability.
• The Information Exchange Matrix documents the information exchange requirements for an enterprise architecture. Information exchange requirements express the relationships across three basic entities (activities, business nodes and their elements, and information flow), and focus on characteristics of the information exchange, such as performance and security. They identify who exchanges what information with whom, why the information is necessary, and in what manner.

Although originally developed for use in the Defense sector, these models are finding increasing use in other sectors of government, and may also be considered for use in non-government environments.

8.2.4 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 Part V, 41. Architecture Repository ), in particular:

• Generic business models relevant to the organization's industry sector. These are "Industry Architectures", in terms of the Enterprise Continuum. They are held in the Reference Library of the Architecture Repository (see Part V, 41.3 Reference Library). For example:
  • The Object Management Group (OMG) - www.omg.org - has a number of vertical Domain Task Forces developing business models relevant to specific vertical domains such as Healthcare, Transportation, Finance, etc.
  • The TeleManagement Forum (TMF) - www.tmforum.org - has developed detailed business models relevant to the Telecommunications industry.
  • Government departments and agencies in different countries have reference models and frameworks mandated for use, intended to promote cross-departmental integration and interoperability. An example is the Federal Enterprise Architecture Business Reference Model, which is a function-driven framework for describing the business operations of the Federal Government independent of the agencies that perform them.
• Business models relevant to common high-level business domains - such as electronic commerce, supply chain management, etc. - that are published within the IT industry. (These are "Common Systems Architectures", in terms of the Enterprise Continuum.) For example:
  • The Resource-Event-Agent (REA) business model was originally created by William E. McCarthy (refer to www.msu.edu/user/mccarth4) of Michigan State University, mainly for modeling of accounting systems. It has proved so useful for better understanding of business processes that it has become one of the major modeling frameworks for both traditional enterprises and e-Commerce systems. In particular, it has been extended by Robert Haugen and McCarthy for supply chain management (refer to www.jeffsutherland.org/oopsla2000/mccarthy/mccarthy.htm).
  • The STEP Framework (STandard for the Exchange of Product model data) is concerned with product design and supply chain interworking. STEP is an ISO standard (ISO 10303). Implementation of the STEP standard has been led by some large aerospace manufacturers, and has also been taken up in other industries that have a need for complex graphic and process data, such as the construction industry.
  • The Open Applications Group (OAG) - www.openapplications.org - is focused on defining a framework for allowing heterogeneous business applications to communicate together. Its OAGIS integration model and specification address the needs of traditional Enterprise Resource Planning (ERP) integration, as well as supply chain management and electronic commerce.
  • RosettaNet - www.rosettanet.org - is a consortium created by leading companies in the computer, electronic component, and semiconductor manufacturing supply chains. Its mission is to develop a complete set of standard e-Business processes for these supply chains, and to promote and support their adoption and use.
• Enterprise-specific building blocks (process components, business rules, job descriptions, etc.).
• Applicable standards.

8.3 Inputs

This section defines the inputs to Phase B.

8.3.1 Reference Materials External to the Enterprise

• Architecture reference materials (see Part IV, 36.2.5 Architecture Repository)

8.3.2 Non-Architectural Inputs

• Request for Architecture Work (see Part IV, 36.2.17 Request for Architecture Work)
• Business principles, business goals, and business drivers (see Part IV, 36.2.9 Business Principles, Business Goals, and Business Drivers)
• Capability Assessment (see Part IV, 36.2.10 Capability Assessment)
• Communications Plan (see Part IV, 36.2.12 Communications Plan)

8.3.3 Architectural Inputs

• Organizational Model for Enterprise Architecture (see Part IV, 36.2.16 Organizational Model for Enterprise Architecture), including:
  • Scope of organizations impacted
  • Maturity assessment, gaps, and resolution approach
  • Roles and responsibilities for architecture team(s)
  • Constraints on architecture work
  • Budget requirements
  • Governance and support strategy
• Tailored Architecture Framework (see Part IV, 36.2.21 Tailored Architecture Framework), including:
  • Tailored architecture method
  • Tailored architecture content (deliverables and artifacts)
  • Configured and deployed tools
• Approved Statement of Architecture Work (see Part IV, 36.2.20 Statement of Architecture Work)
• Architecture principles (see Part IV, 36.2.4 Architecture Principles), including business principles, when pre-existing
• Enterprise Continuum (see Part V, 39. Enterprise Continuum )
• Architecture Repository (see Part IV, 36.2.5 Architecture Repository), including:
  • Re-usable building blocks
  • Publicly available reference models
  • Organization-specific reference models
  • Organization standards
• Architecture Vision (see Part IV, 36.2.8 Architecture Vision), including:
  • Refined key high-level stakeholder requirements
  • Baseline Business Architecture, Version 0.1
  • Baseline Technology Architecture, Version 0.1
  • Baseline Data Architecture, Version 0.1
  • Baseline Application Architecture, Version 0.1
  • Target Business Architecture, Version 0.1
  • Target Technology Architecture, Version 0.1
  • Target Data Architecture, Version 0.1
  • Target Application Architecture, Version 0.1

8.4 Steps

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

New business processes being introduced as part of this effort will need to be defined in detail during Phase B. Existing business processes 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 (see below) 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 Part III, 19. Applying Iteration to the ADM .

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

The steps in Phase B are as follows:

• 8.4.1 Select Reference Models, Viewpoints, and Tools
• 8.4.2 Develop Baseline Business Architecture Description
• 8.4.3 Develop Target Business Architecture Description
• 8.4.4 Perform Gap Analysis
• 8.4.5 Define Roadmap Components
• 8.4.6 Resolve Impacts Across the Architecture Landscape
• 8.4.7 Conduct Formal Stakeholder Review
• 8.4.8 Finalize the Business Architecture
• 8.4.9 Create Architecture Definition Document

8.4.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 the stakeholders and 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.

8.4.1.1 Determine Overall Modeling Process

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 8.2.3 Business Modeling). 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 Part III, 26. Business Scenarios .

Activity models, use-case models, and class models are mentioned earlier as techniques to enable the definition of an organization's business architecture. In many cases, all three approaches can be utilized in sequence to progressively decompose a business.

• Structured Analysis: Identifies the key business functions within the scope of the architecture, and maps those functions onto the organizational units within the business.
• Use-case Analysis: The breakdown of business-level functions across actors and organizations allows the actors in a function to be identified and permits a breakdown into services supporting/delivering that functional capability.
• Process Modeling: The breakdown of a function or business service through process modeling allows the elements of the process to be identified, and permits the identification of lower-level business services or functions.

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.

8.4.1.2 Identify Required Service Granularity Level, Boundaries, and Contracts

The TOGAF content framework differentiates between the functions of a business and the services of a business. Business services are specific functions that have explicit, defined boundaries that are explicitly governed. In order to allow the architect flexibility to define business services at a level of granularity that is appropriate for and manageable by the business, the functions are split as follows: micro-level functions will have explicit, defined boundaries, but may not be explicitly governed. Likewise, macro business functions may be explicitly governed, but may not have explicit, defined boundaries.

The Business Architecture phase therefore needs to identify which components of the architecture are functions and which are services. Services are distinguished from functions through the explicit definition of a service contract. When Baseline Architectures are being developed, it may be the case that explicit contracts do not exist and it would therefore be at the discretion of the architect to determine whether there is merit in developing such contracts before examining any Target Architectures.

A service contract covers the business/functional interface and also the technology/data interface. Business Architecture will define the service contract at the business/functional level, which will be expanded on in the Application and Technology Architecture phases.

The granularity of business services should be determined according to the business drivers, goals, objectives, and measures for this area of the business. Finer-grained services permit closer management and measurement (and can be combined to create coarser-grained services), but require greater effort to govern. Guidelines for identification of services and definition of their contracts can be found in Part III, 22. Using TOGAF to Define & Govern SOAs .

8.4.1.3 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 portfolio managing business and IT capability.

The following catalogs should be considered for development within a Business Architecture:

• Organization/Actor catalog
• Driver/Goal/Objective catalog
• Role catalog
• Business Service/Function catalog
• Location catalog
• Process/Event/Control/Product catalog
• Contract/Measure catalog

The structure of catalogs is based on the attributes of metamodel entities, as defined in Part IV, 34. Content Metamodel .

8.4.1.4 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 following matrices should be considered for development within a Business Architecture:

• Business interaction matrix (showing dependency and communication between organizations and actors)
• Actor/role matrix (showing the roles undertaken by each actor)

The structure of matrices is based on the attributes of metamodel entities, as defined in Part IV, 34. Content Metamodel .

8.4.1.5 Identify Required Diagrams

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

The following Diagrams should be considered for development within a Business Architecture:

• Business Footprint diagram
• Business Service/Information diagram
• Functional Decomposition diagram
• Goal/Objective/Service diagram
• Use-case diagram
• Organization Decomposition diagram
• Process Flow diagram
• Events diagram

The structure of diagrams is based on the attributes of metamodel entities, as defined in Part IV, 34. Content Metamodel .

8.4.1.6 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 relate to the business domain, or may provide requirements input into the Data, Application, and Technology Architectures.

Within this step, the architect should identify types of requirement that must be met by the architecture implementation, including:

• Functional requirements
• Non-functional requirements
• Assumptions
• Constraints
• Domain-specific Business Architecture principles
• Policies
• Standards
• Guidelines
• Specifications

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 coverage of requirements content should be established during the Architecture Vision phase.

8.4.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 8.2 Approach . To the extent possible, identify the relevant Business Architecture building blocks, drawing on the Architecture Repository (see Part V, 41. Architecture Repository ).

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.

8.4.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 Part V, 41. Architecture Repository).

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.

8.4.4 Perform Gap Analysis

First, verify the architecture models for internal consistency and accuracy:

• Perform trade-off analysis to resolve conflicts (if any) among the different views
• Validate that the models support the principles, objectives, and constraints
• Note changes to the viewpoint represented in the selected models from the Architecture Repository, and document
• Test architecture models for completeness against requirements
• Identify gaps between the baseline and target:
  • Create gap matrix, as described in Part III, 27. Gap Analysis
  • Identify building blocks to be carried over, classifying as either changed or unchanged
  • Identify eliminated building blocks
  • Identify new building blocks
  • Identify gaps and classify as those that should be developed and those that should be procured

8.4.5 Define Roadmap Components

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

8.4.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:

• Does this Business Architecture create an impact on any pre-existing architectures?
• Have recent changes been made that impact on the Business Architecture?
• Are there any opportunities to leverage work from this Business Architecture in other areas of the organization?
• Does this Business Architecture impact other projects (including those planned as well as those currently in progress)?
• Will this Business Architecture be impacted by other projects (including those planned as well as those currently in progress)?

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

8.4.8 Finalize the Business Architecture

• Select standards for each of the building blocks, re-using as much as possible from the reference models selected from the Architecture Repository
• Fully document each building block
• Conduct final cross-check of overall architecture against business goals; document rationale for building block decisions in the architecture document
• Document final requirements traceability report
• Document final mapping of the architecture within the Architecture Repository; from the selected building blocks, identify those that might be re-used (working practices, roles, business relationships, job descriptions, etc.), and publish via the Architecture Repository
• Finalize all the work products, such as gap analysis results

8.4.9 Create Architecture Definition Document

• Document rationale for building block decisions in the Architecture Definition Document
• Prepare the business sections of the Architecture Definition Document, comprising some or all of:
  • A business footprint (a high-level description of the people and locations involved with key business functions)
  • A detailed description of business functions and their information needs
  • A management footprint (showing span of control and accountability)
  • Standards, rules, and guidelines showing working practices, legislation, financial measures, etc.
  • A skills matrix and set of job descriptions

  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.

8.5 Outputs

The outputs of Phase B are:

• Refined and updated versions of the Architecture Vision phase deliverables, where applicable, including:
  • Statement of Architecture Work (see Part IV, 36.2.20 Statement of Architecture Work), updated if necessary
  • Validated business principles, business goals, and business drivers (see Part IV, 36.2.9 Business Principles, Business Goals, and Business Drivers), updated if necessary
  • Architecture principles (see Part IV, 36.2.4 Architecture Principles)
• Draft Architecture Definition Document (see Part IV, 36.2.3 Architecture Definition Document), including:
  • Baseline Business Architecture, Version 1.0 (detailed), if appropriate
  • Target Business Architecture, Version 1.0 (detailed), including:
    • Organization structure - identifying business locations and relating them to organizational units
    • Business goals and objectives - for the enterprise and each organizational unit
    • Business functions - a detailed, recursive step involving successive decomposition of major functional areas into sub-functions
    • Business services - the services that the enterprise and each enterprise unit provides to its customers, both internally and externally
    • Business processes, including measures and deliverables
    • Business roles, including development and modification of skills requirements
    • Business data model
    • Correlation of organization and functions - relate business functions to organizational units in the form of a matrix report
  • Views corresponding to the selected viewpoints addressing key stakeholder concerns
• Draft Architecture Requirements Specification (see Part IV, 36.2.6 Architecture Requirements Specification), including such Business Architecture requirements as:
  • Gap analysis results
  • Technical requirements - identifying, categorizing, and prioritizing the implications for work in the remaining architecture domains; for example, by a dependency/priority matrix (for example, guiding trade-off between speed of transaction processing and security); list the specific models that are expected to be produced (for example, expressed as primitives of the Zachman Framework)
  • Updated business requirements
• Business Architecture components of an Architecture Roadmap (see Part IV, 36.2.7 Architecture Roadmap)

return to top of page