Phase B: Business Architecture

Objectives    Approach     Inputs     Steps    Outputs

architecture development - initiationObjectives

Approach

General

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 RoI to those stakeholders from supporting and participating in the subsequent work.

The extent of the work in this phase will depend to a large extent on the enterprise environment. In some case, 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 life-cycle 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 the ADM Architecture Vision (Phase A).

In both of these cases, the Business Scenario technique 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 reuse 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 Architecture Continuum, below.)

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 this Phase 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 this Phase 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 these 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 existing 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 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 reuse 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.

Business Modeling

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:

Figure 1: UML Business Class Diagram, Trade Class Model (Commercial View) (taken from "A Practical Guide to Federal Enterprise Architecture", CIO Council, February 2001)

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

Certain industry sectors have modeling techniques specific to that sector concerned. For example, the Defense sector uses the following models:

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

Enterprise Continuum

As part of this Phase, the architecture team will need to consider what relevant Business Architecture resources are available from the Enterprise Continuum: in particular,

Gap Analysis

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:

Gap analysis highlights services and/or functions that have been accidentally left out, deliberately eliminated, or are yet to be developed or procured. Table 1 in Phase D illustrates an example of a gap analysis matrix. The suggested steps are as follows:

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.

Inputs

The inputs to this phase are:

Steps

The level of detail addressed in this phase 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 this phase. 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 this phase.

Key steps in this phase include the following:

Note: 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 the ADM Introduction.

  1. Business Baseline 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 describe under Approach, above. To the extent possible, identify the relevant business architecture building blocks, drawing on the Architecture Continuum.
  2. Reference Models, Viewpoints and Tools:
    1. 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.
    2. 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.
    3. 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.
  3. Architecture Model(s).
    1. For each viewpoint, create the model for the specific view required, using the selected tool or method.
    2. Assure that all stakeholder concerns are covered. If they are not, create new models to address concerns not covered, or augment existing models (see above). 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 of TOGAF. Other techniques may be used, if required. Create models of the following:
      1. Organization structure. Document the organization structure, identifying business locations and relating them to organizational units.
      2. Business goals and objectives. Document business goals and objectives for each organizational unit.
      3. Business functions. Identify and define business functions. This is a detailed, recursive step involving successive decomposition of major functional areas into sub-functions.
      4. Business Services - the services that each of the enterprise units provides to its customers, both internally and externally.
      5. Business processes, including measures and deliverables.
      6. Business roles, including development and modification of skills requirements.
      7. Correlation of organization and functions. Relate business functions to organizational units in the form of a matrix report.
    3. 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 current architecture effort, as describe under Approach, above. Focus on what will be worthwhile collecting for the purpose at hand.
    4. Perform trade-off analysis to resolve conflicts (if any) among the different views.
    5. Validate that the models support the principles, objectives and constraints.
    6. Note changes to the viewpoint represented in the selected models from the Architecture Continuum, and document.
    7. Test architecture models for completeness against requirements.
  4. Select business architecture building blocks (e.g., business services)
    1. Identify required building blocks and check against existing library of building blocks, re-using as appropriate.
    2. Where necessary, define new business architecture building blocks.
  5. Conduct formal checkpoint review of the architecture model and building blocks with stakeholders.
  6. Review non-functional (qualitative) criteria (e.g., performance, costs, volumes). Use to specify required service levels (for example, via formal Service Level Agreements).
  7. Complete the business architecture.
    1. Select standards for each of the architecture building blocks, reusing as much as possible from the reference models selected from the Architecture Continuum. 
    2. Fully document each architecture building block.
    3. Final cross check of overall architecture against business goals. Document rationale for building block decisions in architecture document.
    4. Document final requirements traceability report.
    5. Document final mapping of the architecture within the Architecture Continuum. From the selected architecture building blocks, identify those that might be reused (working practices, roles, business relationships, job descriptions, etc.), and publish via the architecture repository.
    6. Document rationale for building block decisions in architecture document.
    7. Prepare Business Architecture Report. Generate the Business Architecture document, comprising some or all of:
      • a business footprint (a high-level description of the people and locations involving 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.; and
      • 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.

    8. 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. 
  8. Gap analysis (see under Approach, above) and report
    1. Create gap matrix as described above.
    2. Identify building blocks to be carried over, classifying as either changed or unchanged.
    3. Identify eliminated building blocks.
    4. Identify new building blocks.
    5. Identify gaps and classify as those that should be developed and those that should be procured.

Outputs

The outputs of this phase are:

Copyright © The Open Group, 2002