Phase B: Business Architecture
This chapter describes the development of a Business Architecture.
Figure: Phase B: Business Architecture
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
- To analyze the gaps between the Baseline and Target Business Architectures
- To select 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
A knowledge of the Business Architecture is a prerequisite for architecture work in any other domain (Data, Applications,
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 Technical Architecture work to key stakeholders, and the return on investment to those stakeholders from supporting and
participating in the subsequent work.
The extent 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
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 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
existing architectural descriptions exist, these can be used as a starting point, and verified and updated if necessary; see The 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.
Developing the Baseline Description
In architecturally more mature environments, there will be existing architecture definitions, which (hopefully) will have been
maintained since the last architecture development cycle. Where existing architectural descriptions exist, they can be used as a
starting point, and verified and updated if necessary. Any such existing descriptions will already have been used in Phase A in
developing an Architecture Vision, and this work should provide a sound basis for the Baseline Description, and may even be
sufficient in itself.
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 existing 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.
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 Business Process Management Initiative (www.bpmi.org) is an organization that is defining
standards for business process modeling, including a language with which to specify business processes, their tasks/steps, and the
- Use-Case Models can describe either business processes or systems functions, depending on the focus of the modeling
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.
Figure: UML Business Class Diagram, Trade Class Model (Commercial View)
(UML Business Class Diagram, Trade Class Model (Commercial View) is taken from the Practical Guide to
Federal Enterprise Architecture.)
All three types of model types above can be represented in 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
- 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.
As part of Phase B, the architecture team will need to consider what relevant Business Architecture resources are available from
the Enterprise Continuum, in particular:
- Generic business models relevant to the organization's industry sector. (These are "Industry Architectures", in terms of the
Enterprise Continuum.) 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 (www.feapmo.gov/feaBrm.htm), 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
- The Resource-Event-Agent (REA) business model was originally created by William E. McCarthy (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
- 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.).
A key step in validating an architecture is to consider what may have been forgotten. The architecture must support all of the
essential information processing needs of the organization. The most critical source of gaps that should be considered is
stakeholder concerns that have not been addressed in prior architectural work.
Other potential sources of gaps:
- People gaps (e.g., cross-training requirements)
- Process gaps (e.g., process inefficiencies)
- Tools gaps (e.g., duplicate or missing tool functionality)
- Information gaps
- Measurement gaps
- Financial gaps
- Facilities gaps (buildings, office space, etc.)
Gap analysis highlights services and/or functions that have been accidentally left out, deliberately eliminated, or are yet to
be developed or procured. Gap Analysis Matrix in Phase D illustrates an example of a gap
analysis matrix. The suggested steps are as follows:
- Draw up a matrix with all the Business Architecture Building Blocks of the Baseline Architecture on the vertical axis, and all
the Business Architecture Building Blocks of the Target Business Architecture on the horizontal axis. In creating the matrix it is
imperative to use terminology that is accurate and consistent.
- Add to the Baseline Architecture axis a final row labeled "New Business Architecture Building Blocks", and to the Target
Architecture axis a final column labeled "Eliminated Business Architecture Building Blocks".
- Where a Business Architecture Building Block is available in both the Baseline and Target Architectures, record this with
"Included" at the intersecting cell.
- Where a Business Architecture Building Block from the Baseline Architecture is missing in the Target Architecture, each must be
reviewed. If it was correctly eliminated, mark it as such in the appropriate "Eliminated" cell. If it was not, you have uncovered
an accidental omission in your new architecture that must be addressed by reinstating the Business Architecture Building Block in
the next iteration of the architecture design - mark it as such in the appropriate "Eliminated" cell.
- Where a Business Architecture Building Block from the Target Architecture cannot be found in the Baseline Architecture, mark it
at the intersection with the "New" row, as a gap that needs to be filled, either by developing or procuring the building
When the exercise is complete, anything under "Eliminated Services" or "New Services" is a gap, which should either be
explained as correctly eliminated, or marked as to be addressed by reinstating or developing/procuring the function.
The inputs to Phase B are:
- Request for Architecture Work (Request for Architecture Work)
- Approved Statement of Architecture Work (Major Output Descriptions)
- Refined statements of business goals and strategic drivers
- Architecture principles (Architecture Principles), including business
principles, when pre-existing
- Enterprise Continuum (as described in Enterprise Continuum)
- Architecture Vision (see Business Scenario/Architecture Vision), including:
- Baseline Business Architecture, Version 0.1
- Baseline Technology Architecture, Version 0.1
- Baseline Data Architecture, Version 0.1
- Baseline Applications Architecture, Version 0.1
- Target Business Architecture, Version 0.1
- Target Technology Architecture, Version 0.1
- Target Data Architecture, Version 0.1
- Target Applications Architecture, Version 0.1
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.
Key steps in Phase B include the following:
- The order of the following steps should be adapted to the situation at hand: in particular, determine whether in this situation
it is appropriate to do Baseline Description or Target Architecture development first, as described in Introduction to the ADM .
- 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 existing architectural descriptions exist, as described in
Approach . To the extent possible, identify the relevant Business Architecture building blocks, drawing on
the Architecture Continuum.
- Identify Reference Models, Viewpoints, and Tools
- Select relevant Business Architecture resources (reference models, patterns, etc.) from the Architecture Continuum, 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.
- Create Architecture Model(s)
- For each viewpoint, create the model for the specific view required, using the selected tool or method.
- Assure that all stakeholder concerns are covered. If they are not, create new models to address concerns not covered, or
augment existing models (see 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 IV: Resource Base, Business Scenarios . Other techniques may be used, if required. Create models of the following:
- Organization structure: document the organization structure, identifying business locations and relating them to organizational
- Business goals and objectives: document business goals and objectives for each organizational unit.
- Business functions: identify and define business functions. This is a detailed, recursive step involving successive
decomposition of major functional areas into sub-functions.
- Business services: the services that 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
- Information requirements: identify for each business function when, where, how often, and by whom the function is performed;
what information is used to perform it, and its source(s); and what opportunities exist for improvements. Include information that
needs to be created, retrieved, updated, and deleted. The level of detail to be defined will depend on the scope and focus of the
Baseline Architecture effort, as described in Approach . Focus on what will be worthwhile collecting for
the purpose at hand.
- Perform trade-off analysis to resolve conflicts (if any) among the different views.
One method of doing this is CMU/SEI's Architecture Trade-off Analysis (ATA) Method (www.sei.cmu.edu/ata/ata_method.html.
- Validate that the models support the principles, objectives, and constraints.
- Note changes to the viewpoint represented in the selected models from the Architecture Continuum, and document.
- Test architecture models for completeness against requirements.
- Select Business Architecture Building Blocks (e.g., business services)
- Identify required building blocks and check against existing library of building blocks, re-using as appropriate.
- Where necessary, define new Business Architecture Building Blocks.
- Conduct Formal Checkpoint Review of Architecture Model and Building Blocks with Stakeholders
- Review Non-Functional (Qualitative) Criteria (e.g., performance, costs, volumes)
Use to specify required service levels (for example, via formal Service Level Agreements (SLAs)).
- Complete Business Architecture
- Select standards for each of the Architecture Building Blocks, re-using as much as possible from the reference models selected
from the Architecture Continuum.
- Fully document each Architecture Building Block.
- Final cross-check of overall architecture against business goals. Document rationale for building block decisions in the
- Document final requirements traceability report.
- Document final mapping of the architecture within the Architecture Continuum. From the selected Architecture Building Blocks,
identify those that might be re-used (working practices, roles, business relationships, job descriptions, etc.), and publish via
the architecture repository.
- Document rationale for building block decisions in the Business Architecture description document.
- Prepare the Business Architecture Report, 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
Business Architecture document for review by relevant stakeholders, and incorporate feedback.
- Checkpoint: 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.
- Perform Gap Analysis (see Approach) and Create Report
- Create gap matrix, as described in 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.
The outputs of Phase B are:
- Statement of Architecture Work (Major Output Descriptions), updated if
- Validated business principles (Architecture Principles), business goals, and
- Target Business Architecture (Business Architecture), Version 1.0 (detailed),
- 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
- Business services - the services that the enterprise and each enterprise unit provides to its customers, both internally and
- 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
- Baseline Business Architecture, Version 1.0 (detailed), if appropriate
- Views corresponding to the selected viewpoints addressing key stakeholder concerns
- 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
- Business Architecture Report
- Updated business requirements
return to top of page
The TOGAF document set is designed for use with frames. To navigate around the document:
- In the main Contents frame at the top of the page, click the relevant hyperlink (Part I, Part II, etc.) to load the Contents
List for that Part of the TOGAF document into the Secondary Index frame in the left margin.
- Then click in that Contents List to load a page into this main frame.
return to top of page
Downloads of the TOGAF documentation, are available under license from the TOGAF information web site. The license is free to any
organization wishing to use TOGAF entirely for internal purposes (for example, to develop an information system architecture for
use within that organization). A hardcopy book is also available from The Open Group Bookstore as document G063.
Copyright © 1999-2006 The Open Group, All Rights Reserved
TOGAF is a trademark of The Open Group