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

7.1 Objectives

The objectives of Phase B are to:

• Develop the Target Business Architecture that describes how the enterprise needs to operate to achieve the business goals, and respond to the strategic drivers set out in the Architecture Vision, in a way that addresses the Statement of Architecture Work and stakeholder concerns
• Identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Business Architectures

7.2 Inputs

This section defines the inputs to Phase B.

7.2.1 Reference Materials External to the Enterprise

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

7.2.2 Non-Architectural Inputs

• Request for Architecture Work (see Part IV, 32.2.17 Request for Architecture Work)
• Business principles, business goals, and business drivers (see Part IV, 32.2.9 Business Principles, Business Goals, and Business Drivers)
• Capability Assessment (see Part IV, 32.2.10 Capability Assessment)
• Communications Plan (see Part IV, 32.2.12 Communications Plan)

7.2.3 Architectural Inputs

• Organizational Model for Enterprise Architecture (see Part IV, 32.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, 32.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, 32.2.20 Statement of Architecture Work)
• Architecture Principles (see Part IV, 32.2.4 Architecture Principles), including business principles, when pre-existing
• Enterprise Continuum (see Part V, 35. Enterprise Continuum )
• Architecture Repository (see Part IV, 32.2.5 Architecture Repository), including:
  • Re-usable building blocks
  • Publicly available reference models
  • Organization-specific reference models
  • Organization standards
• Architecture Vision (see Part IV, 32.2.8 Architecture Vision), including:
  • Problem description
  • Objective of the Statement of Architecture Work
  • Summary views
  • Business Scenario (optional)
  • Refined key high-level stakeholder requirements
• Draft Architecture Definition Document, including (when in scope):
  • 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

7.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 Part III, 18. Applying Iteration to the ADM .

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

The steps in Phase B are as follows:

• 7.3.1 Select Reference Models, Viewpoints, and Tools
• 7.3.2 Develop Baseline Business Architecture Description
• 7.3.3 Develop Target Business Architecture Description
• 7.3.4 Perform Gap Analysis
• 7.3.5 Define Candidate Roadmap Components
• 7.3.6 Resolve Impacts Across the Architecture Landscape
• 7.3.7 Conduct Formal Stakeholder Review
• 7.3.8 Finalize the Business Architecture
• 7.3.9 Create the Architecture Definition Document

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

7.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 6.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 6.5 Approach , the frameworks for these maps may already exist and should be leveraged, now using them to characterize gaps and better mapping of 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 7.5.6 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 7.5 Approach can be utilized to progressively decompose a business:

• Business Capability Mapping: identifies, categorizes, and decomposes the business capabilities required for the business to have the ability to deliver value to one or more stakeholders
• Organization Mapping: a representation of the organizational structure of the business (including third-party domains), depicting business units, the decomposition of those units into lower-level functions, and organizational relationships (unit-to-unit and mapping to business capabilities, locations, and other attributes)
• Value Stream Mapping: the breakdown of activities that an organization performs to create the value being exchanged with stakeholders

  Value stream maps illustrate how an organization delivers value and are in the context of a specific set of stakeholders, and leverage business capabilities in order to create stakeholder value and align to other aspects of the Target Business Architecture.

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

7.3.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. The 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 the TOGAF® Series Guide: Using the TOGAF® Framework to Define and Govern Service-Oriented Architectures.

7.3.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 managing the business and IT capability.

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

• Value Stream catalog
• Business Capabilities catalog
• Value Stream Stages catalog
• 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, 30. Content Metamodel .

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

• Value Stream/Capability matrix (displays the capabilities required to support each stage of a value stream)
• Strategy/Capability matrix (displays the capabilities required to support specific strategy statements)
• Capability/Organization matrix (displays organization elements that implement each capability)
• 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, 30. Content Metamodel .

7.3.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 Model diagram
• Business Capability Map
• Value Stream Map
• Organization Map
• Business Footprint diagram
• Business Service/Information diagram
• Functional Decomposition diagram
• Goal/Objective/Service diagram
• Business Use-Case diagram
• Organization Decomposition diagram
• Process Flow diagram
• Event diagram

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

7.3.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
• Provide requirements input into the Data, Application, and Technology Architectures
• Provide detailed guidance to be reflected during design and implementation to ensure that the solution addresses the original architecture requirements

Within this step, the architect should identify requirements that should be met by the architecture (see 16.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.

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

7.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 Part V, 37. 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.

7.3.4 Perform Gap Analysis

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, using the gap analysis technique as described in Part III, 23. Gap Analysis .

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

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

• 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)?

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

7.3.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 a final cross-check of overall architecture against business goals; document the rationale for building block decisions in the architecture document
• Document the final requirements traceability report
• Document the 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

7.3.9 Create the Architecture Definition Document

• Document the 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.

7.4 Outputs

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

• Refined and updated versions of the Architecture Vision phase deliverables, where applicable, including:
  • Statement of Architecture Work (see Part IV, 32.2.20 Statement of Architecture Work), updated if necessary
  • Validated business principles, business goals, and business drivers (see Part IV, 32.2.9 Business Principles, Business Goals, and Business Drivers), updated if necessary
  • Architecture Principles (see Part IV, 32.2.4 Architecture Principles)
• Draft Architecture Definition Document (see Part IV, 32.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, 32.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, 32.2.7 Architecture Roadmap)

The outputs may include some or all of the following:

• Catalogs:
  • Value Stream catalog
  • Business Capabilities catalog
  • Value Stream Stages catalog
  • Organization/Actor catalog
  • Driver/Goal/Objective catalog
  • Role catalog
  • Business Service/Function catalog
  • Location catalog
  • Process/Event/Control/Product catalog
  • Contract/Measure catalog
• Matrices:
  • Value Stream/Capability matrix
  • Strategy/Capability matrix
  • Capability/Organization matrix
  • Business Interaction matrix
  • Actor/Role matrix
• Diagrams:
  • Business Model diagram
  • Business Capability Map
  • Value Stream Map
  • Organization Map
  • Business Footprint diagram
  • Business Service/Information diagram
  • Functional Decomposition diagram
  • Product Lifecycle diagram
  • Goal/Objective/Service diagram
  • Business Use-Case diagram
  • Organization Decomposition diagram
    
  • Process Flow diagram
  • Event diagram

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

7.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 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. 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 the 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 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 Part V, 35.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.

7.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 6.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. 7.5.3 Applying Business Capabilities to 7.5.5 Applying the Organization Map 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 the fundamental frameworks from Phase A, such as a common enterprise business capability map, 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.

7.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 The Open Group Guide to 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 The Open Group Guide to 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.

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

7.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 7.5.3 Applying Business Capabilities , 7.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.

7.5.6 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 function (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:

• 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^TM (BPMN^TM), 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.

7.5.7 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, 37. Architecture Repository ), in particular:

• Industry reference 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, 37.3 Reference Library). For example:

  • The Object Management Group (OMG) - www.omg.org - has a number of vertical Domain Task Forces developing industry reference models relevant to specific vertical domains such as Healthcare, Transportation, Finance, etc.
  • The TM Forum - www.tmforum.org - has developed detailed reference 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.

  • The IT4IT Reference Architecture provides a high-level IT Value Chain that can be used within the IT segment of your architecture

    The IT4IT Level 1 Reference Architecture can be used to guide the creation of a Business Capability Map for the IT segment.

• Enterprise-specific Business Architecture views (capability maps, value stream maps, organization maps, etc.)
• Enterprise-specific building blocks (process components, business rules, job descriptions, etc.)
• Applicable standards

return to top of page