This chapter describes the development of a Technology Architecture.

The detailed description of the process to develop the Target Technology Architecture is given in Target Technology Architecture - Detail .

Objective

The objective of Phase D is to develop a Technology Architecture that will form the basis of the following implementation work.

Approach

General

Detailed guidelines for Phase D, including Inputs, Steps, and Outputs, are given in Target Technology Architecture - Detail .

Architecture Continuum

As part of Phase D, the architecture team will need to consider what relevant Technology Architecture resources are available in the Architecture Continuum.

In particular:

• The TOGAF Technical Reference Model (TRM)
• Generic technology models relevant to the organization's industry "vertical" sector.

  For example, the TeleManagement Forum (TMF - www.tmforum.org) has developed detailed technology models relevant to the Telecommunications industry.

• Technology models relevant to Common Systems Architectures.

  For example, The Open Group has a Reference Model for Integrated Information Infrastructure (III-RM: see Integrated Information Infrastructure Reference Model) that focuses on the application-level components and underlying services necessary to provide an integrated information infrastructure.

Inputs

Inputs to Phase D are:

• Technology principles (Technology Principles), if existing
• Request for Architecture Work (Request for Architecture Work)
• Statement of Architecture Work (Major Output Descriptions)
• Architecture Vision (Business Scenario/Architecture Vision)
• Baseline Technology Architecture, Version 0.1 (from Phase A)
• Target Technology Architecture, Version 0.1 (from Phase A)
• Relevant technical requirements from previous phases
• Gap analysis results (from Data Architecture)
• Gap analysis results (from Applications Architecture)
• Baseline Business Architecture, Version 1.0 (detailed), if appropriate
• Baseline Data Architecture, Version 1.0, if appropriate
• Baseline Applications Architecture, Version 1.0, if appropriate
• Target Business Architecture (Business Architecture), Version 1.0 (detailed)
• Re-usable building blocks, from organization's Enterprise Continuum (Introduction to the Enterprise Continuum), if available
• Target Data Architecture, Version 1.0
• Target Applications Architecture, Version 1.0

Steps

Key steps in Phase D include:

1. Develop Baseline Technology Architecture Description
   1. Review Baseline Business Architecture, Baseline Data Architecture, and Baseline Applications Architecture, to the degree necessary to inform decisions and subsequent work.
   2. Develop a Baseline Description of the existing Technology Architecture, to the extent necessary to support the Target Technology Architecture. The scope and level of detail to be defined will depend on the extent to which existing technology components are likely to be carried over into the Target Technology Architecture, and on whether existing architectural descriptions exist, as described in Approach . Define for each major hardware or software platform type:
      • Name (short and long)
      • Physical location
      • Owner(s)
      • Other users
      • Plain language description of what the hardware/software platform is and what it is used for
      • Business functions supported
      • Organizational units supported
      • Networks accessed
      • Applications and data supported
      • System inter-dependencies (for example, fall-back configurations)
   3. To the extent possible, identify and document candidate Technology Architecture Building Blocks (potential re-usable assets).
   4. Draft the Technology Architecture Baseline report: summarize key findings and conclusions, developing suitable graphics and schematics to illustrate baseline configuration(s). If warranted, provide individual Baseline Technology Architecture Descriptions as Annexes.
2. Develop Target Technology Architecture; see detailed steps

   Detailed activities for this step, including Inputs, Activities, and Outputs, are given in Target Technology Architecture - Detail .

Outputs

The outputs of Phase D are:

• Statement of Architecture Work (Major Output Descriptions), updated if necessary
• Baseline Technology Architecture, Version 1.0, if appropriate
• Validated technology principles, or new technology principles (if generated here)
• Technology Architecture Report, summarizing what was done and the key findings
• Target Technology Architecture (Technology Architecture), Version 1.0
• Technology Architecture, gap report
• Viewpoints addressing key stakeholder concerns
• Views corresponding to the selected viewpoints

Target Technology Architecture - Detail

Introduction

This is the detailed description of the process to develop the Target Technology Architecture.

Overview

An organization creating or adapting a Technology Architecture may already mandate the use of a list of approved suppliers/products for that organization. The list will be an input to the definition of the organization-specific architecture framework. The architectures can then be used as procurement tools to govern the future growth and development of the organization's IT infrastructure. The key steps are expanded in the following subsections.

Note:

The order of the following steps should be adapted to the situation as described in Introduction to the ADM .

Step 1

Step 1 is to create a Baseline Description in the TOGAF format.

Objective

The objective of this step is to convert the description of the existing system into services terminology using the organization's Foundation Architecture (e.g., the TOGAF Foundation Architecture's TRM). The rationale behind this is to structure the existing system description in a way which makes it compatible with the breakdown of standards and the descriptions used within your Foundation Architecture.

Approach

This step is intended to facilitate moving from product documentation to a service-oriented description. The step will aid in specifying standards for the Target Architecture in Step 4. An additional step, Step 3, oriented to defining building blocks, provides the means to cross-check the architectural definition process in the form of implementation-related decisions.

Additionally, this step captures relevant parts of the existing architecture (using the scope definition established in Phase A) as candidates for re-usable building blocks, along with inhibitors to meeting business requirements using the existing system. The existing architecture is assessed against the Business Architecture, identifying the key inhibitors and opportunities for re-use. Finally, the existing architecture assessment ends with the capture of implied or explicit architecture principles that should be carried forward and imposed on this architecture exercise.

Begin by converting the description of the existing environment into the terms of your organization's Foundation Architecture (e.g., the TOGAF Foundation Architecture's TRM). This will allow the team developing the architecture to gain experience with the model and to understand its component parts. The team may be able to take advantage of a previous architectural definition, but it is assumed that some adaptation may be required to match the architectural definition techniques described as part of this process. Another important task is to set down a list of key questions which can be used later in the development process to measure the effectiveness of the new architecture.

A key process in the creation of a broad architectural model of the target system is the conceptualization of Architecture Building Blocks (ABBs). ABBs are not intended to be solutions, but depictions of how the architecture might be looked on in implementable terms. Their functionality is clearly defined, but without the detail introduced by specific products. The method of defining ABBs, along with some general guidelines for their use in creating an architectural model, is described in Part IV: Resource Base, Building Blocks and the ADM , and illustrated in detail in Building Blocks .

It is recommended that Architecture Building Blocks be documented (e.g., with an architecture description language) and stored (e.g., in a repository or information base), in order to maximize re-use potential.

Applying the ABB method introduces application space into the architectural process. This is the means of linking services, which address functionality that must be considered on an enterprise basis, with applications, which may or may not address global functionality. The building blocks example in Part IV: Resource Base, Building Blocks , provides insight into both application-specific and more global considerations in defining building blocks in order to illustrate this.

Inputs

The inputs to Step 1 are:

• Technology principles (Technology Principles), if existing
• Request for Architecture Work (Request for Architecture Work)
• Statement of Architecture Work (Major Output Descriptions)
• Architecture Vision (Business Scenario/Architecture Vision)
• Baseline Technology Architecture, Version 0.1
• Target Technology Architecture, Version 0.1
• Relevant technical requirements from previous phases
• Gap analysis results (from Data Architecture)
• Gap analysis results (from Applications Architecture)
• Baseline Business Architecture, Version 1.0 (detailed), if appropriate
• Baseline Data Architecture, Version 1.0, if appropriate
• Baseline Applications Architecture, Version 1.0, if appropriate
• Target Business Architecture (Business Architecture), Version 1.0 (detailed)
• Re-usable building blocks, from organization's Enterprise Continuum (Introduction to the Enterprise Continuum), if available
• Target Data Architecture, Version 1.0
• Target Applications Architecture, Version 1.0
• Re-usable Architecture Building Blocks, from organization's Architecture Continuum (The Architecture Continuum), if available
• Re-usable Solution Building Blocks, from organization's Solutions Continuum (The Solutions Continuum), if available

Activities

Key activities in Step 1 include:

1. Collect data on current system
2. Document all constraints
3. Review and validate (or generate, if necessary) the set of Technology Architecture principles

   These will normally form part of an overarching set of architecture principles. Guidelines for developing and applying principles, and a sample set of Technology Architecture principles, are given in Part IV: Resource Base, Architecture Principles .

4. List distinct functionality
5. Produce affinity groupings of functionality using TOGAF TRM service groupings (or your business' Foundation Architecture)
6. Analyze relationships between groupings
7. Sanity check functionality to assure all of current system is considered
8. Identify interfaces
9. Produce Technology Architecture model
10. Verify Technology Architecture model
11. Document key questions to test merits of Technology Architecture
12. Document criteria for selection of service portfolio architecture

Outputs

The outputs of Step 1 are:

• Technology principles (Technology Principles), if not existing
• Baseline Technology Architecture (Technology Architecture), Version 1.0
• Target Technology Architecture, Version 0.2:
  • Technology Architecture - constraints
  • Technology Architecture - architecture principles
  • Technology Architecture - requirements traceability, key questions list
  • Technology Architecture - requirements traceability, criteria for selection of service portfolio
  • Technology Architecture Model, Version 0.1

Step 2

Step 2 is to consider different architecture reference models, viewpoints, and tools.

Objective

The objective of this step is to perform an analysis of the Technology Architecture from a number of different concerns (requirements) or viewpoints and to document each relevant viewpoint. The purpose of considering these viewpoints is to ensure that all relevant stakeholder concerns will have been considered in the final Technology Architecture, so ensuring that the target system will meet all the requirements put on it.

Approach

The Business Architecture is used to select the most relevant viewpoints for the project. It is important to recognize that in practice it will be rarely possible to reach 100% coverage of stakeholder concerns.

Pertinent viewpoints are created first from the existing system to identify the salient elements of the current systems requirements that the stakeholders confirm must also be satisfied in the target system. A comprehensive set of stakeholder viewpoints must also be created for the target system. The corresponding views of the existing system will be compared with the views of the target system to identify elements of the existing system that are intended for replacement or improvement.

If a set of viewpoints is carefully chosen, it will expose the most important aspects of the existing architecture and the requirements of the target system.

Several different viewpoints may be useful. Architecture viewpoints and views are described in greater detail in Part IV: Resource Base, Developing Architecture Views . The viewpoints presented there should not be considered an exhaustive set, but simply a starting point. In developing a Technology Architecture, it is very likely that some of the viewpoints given there will not be useful, while others not given there will be essential. Again, use the Business Architecture as a guide in selecting the pertinent viewpoints.

Inputs

The inputs to Step 2 are:

• Request for Architecture Work (Request for Architecture Work)
• Statement of Architecture Work (Major Output Descriptions)
• Target Business Architecture (Business Architecture), Version 1.0
• Target Technology Architecture (Technology Architecture), Version 0.2

Activities

Key activities in Step 2 include:

1. Select relevant Technology 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 Technology Architecture viewpoints; i.e., those that will enable the architect to demonstrate how the stakeholder concerns are being addressed in the Technology Architecture. (See Part IV: Resource Base, Developing Architecture Views for examples).
   • Document the selected viewpoints, if not already documented.
     • Consider using ANSI/IEEE Std 1471-2000 as a guide for documenting a viewpoint.
   • A primary reference model will be the TOGAF TRM. Other reference models will be taken from the Architecture Continuum.
   • Consider developing at least the following views:
     • Networked Computing/Hardware view
     • Communications view
     • Processing view
     • Cost view
     • Standards view
   • Brainstorm and document technical constraints deriving from analysis of the concerns, and ensure they are covered by the viewpoints.
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.
4. Perform trade-off analysis to resolve conflicts (if any) among the different viewpoints.
   • One method of doing this is CMU/SEI's Architecture Trade-off Analysis (ATA) Method (refer to www.sei.cmu.edu/ata/ata_method.html).

Outputs

The outputs of Step 2 are:

• Target Technology Architecture, Version 0.3:
  • Technology Architecture (Technology Architecture) - architecture viewpoints
    • Networked Computing/Hardware view
    • Communications view
    • Processing view
    • Cost view
    • Standards view
  • Technology Architecture - constraints

Step 3

Step 3 is to create an architectural model of building blocks.

Objective

The reason for selecting viewpoints in Step 2 is to be able to develop views for each of those viewpoints in Step 3. The architectural model created in Step 3 comprises those several views.

The objective of this step is to broadly determine how the services required in the target system will be grouped after considering all pertinent viewpoints of the architecture's use. This differs from Step 1 in that Step 1 dealt mainly with the required functionality of the system, whereas here we are considering many viewpoints that are not expressed explicitly as required functionality.

The rationale behind this is to enable the services required within the system to be selected during the next step, through the creation of an architecture model that clearly depicts the required services.

Approach

At Step 3, the purpose of examining different viewpoints in Step 2 becomes clear. The constraints defined and the unique system insights gained through an examination of the viewpoints pertinent to the current system and the target system can be used to validate the ability of the broad architectural model to accommodate the system requirements.

The broad architectural model starts as a TOGAF TRM-based model (or a model based upon the organization's Foundation Architecture), derived from the service-to-function mapping carried out as part of the service examination in Step 1. An architecture based exactly on the TOGAF TRM may not be able to accommodate the stakeholder needs of all organizations. If the examination of different viewpoints identifies architectural features that cannot be expressed in terms of the TOGAF TRM, changes and amendments to the TOGAF TRM should be made to create an organization-specific TRM.

Once the Baseline Description has been established and appropriate views described, it is possible to make decisions about how the various elements of system functionality should be implemented. This should only be in broad terms, to a level of detail which establishes how the major business functions will be implemented; for example, as a transaction processing application or using a client/server model.

Therefore this step defines the future model of building blocks (e.g., collections of functions and services generated from previous steps). It is here that re-use of building blocks from your business' Architecture Continuum is examined carefully, assuring that maximum re-use of existing material is realized.

Once the architecture model of building blocks is created, the model must be tested for coverage and completeness of the required technical functions and services. For each building block decision, completely follow through its impact and note the rationale for decisions, including the rationale for decisions not to do something.

Inputs

The inputs to Step 3 are:

• Target Business Architecture (Business Architecture), Version 1.0
• Target Technology Architecture (Technology Architecture), Version 0.3:
  • Technology Architecture - viewpoints
  • Technology Architecture - constraints
• Re-usable Architecture Building Blocks, from organization's Architecture Continuum (The Architecture Continuum), if available

Activities

Key activities in Step 3 include:

1. To the extent possible, identify the relevant Technology Architecture building blocks, drawing on the Architecture Continuum.
2. For each viewpoint, create the model for the specific view required, using the selected tool or method. Consider developing at least the following views:
   • Networked Computing/Hardware view
   • Communications view
   • Processing view
   • Cost view
   • Standards view
3. Assure that all stakeholder concerns are covered. If they are not, create new models to address concerns not covered, or augment existing models.
4. Ensure that all information requirements in the Business Architecture, Data Architecture, and Applications Architecture are met.
5. 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 (refer to www.sei.cmu.edu/ata/ata_method.html).

6. Validate that the models support the principles, objectives, and constraints.
7. Note changes to the viewpoint represented in the selected models from the Architecture Continuum, and document.
8. Identify Solution Building Blocks that would be used to implement the system, and create a model of building blocks.
9. Check building blocks against existing library of building blocks and re-use as appropriate.
10. Test architecture models for completeness against requirements.
11. Document rationale for building block decisions in the architecture document.

Outputs

The outputs of Step 3 are:

• Target Technology Architecture (Technology Architecture), Version 0.4:
  • Technology Architecture Model
    • Networked Computing/Hardware view
    • Communications view
    • Processing view
    • Cost view
    • Standards view
  • Technology Architecture - change requests and/or extensions or amendments to be incorporated in an organization-specific Architecture Continuum

Step 4

Step 4 is to select the services portfolio required per building block.

Objective

The objective of this step is to select services portfolios for each building block generated in Step 3.

Approach

The services portfolios are combinations of basic services from the service categories in the TOGAF TRM that do not conflict. The combination of services are again tested to ensure support for the applications. This is a pre-requisite to the later step of defining the architecture fully.

The constraints output from Step 2 can provide more detailed information about:

• Requirements for organization-specific elements or pre-existing decisions (as applicable)
• Pre-existing and unchanging organizational elements (as applicable)
• Inherited external environment constraints

Where requirements demand definition of specialized services that are not identified in TOGAF, consideration should be given to how these might be replaced if standardized services become available in the future.

For each Architecture Building Block (ABB), build up a service description portfolio as a set of non-conflicting services. The set of services must be tested to ensure that the functionality provided meets application requirements.

Inputs

The inputs to Step 4 are:

• Target Business Architecture (Business Architecture), Version 1.0
• Target Technology Architecture (Technology Architecture), Version 0.4
• Technical Reference Model (TRM)
• Standards Information Base (SIB)

Activities

Key activities in Step 4 include:

1. Produce affinity grouping of services
2. Cross-check affinity groups against needs
3. Document service description portfolio for each ABB, cross-checking for non-conflicting services
4. Document change requests to architectures in the Architecture Continuum

Outputs

The outputs of Step 4 are:

• Target Technology Architecture (Technology Architecture), Version 0.5:
  • Technology Architecture - target services (a description of the service portfolios required also known as an Organization-Specific Framework)
  • Technology Architecture - change requests and/or extensions or amendments to be incorporated in an organization-specific Architecture Continuum

Step 5

Step 5 is to confirm that the business goals and objectives are met.

Objective

The objective of this step is to clarify and check the business goals and other objectives of implementing the architecture. This is required as a cross-check that the Technology Architecture meets these objectives.

Approach

The key question list is used to pose questions against the architecture model and service description portfolio to test its merit and completeness.

Inputs

The inputs to Step 5 are:

• Target Business Architecture (Business Architecture), Version 1.0 (business goals)
• Target Technology Architecture (Technology Architecture), Version 0.5

Activities

Key activities in Step 5 include:

1. Conduct a formal checkpoint review of the architecture model and building blocks with stakeholders, validating that business goals are met. Utilizing the key questions list, ensure that the architecture addresses each question.
2. Document findings.

Outputs

The outputs of Step 5 are:

• Target Technology Architecture (Technology Architecture), Version 0.6:
  • Technology Architecture - requirements traceability (business objectives criteria)

Step 6

Step 6 is to determine criteria for specification selection.

Objective

The objective of this step is to develop a set of criteria for choosing specifications and portfolios of specifications.

Approach

Choosing the right criteria is vital if the final architecture is to meet its objectives. These criteria will depend on the existing system and the overall objectives for the new architecture. The overall objectives should be developed from the organization's business goals, so it is hard to give specific advice here, but some example objectives are listed in Part IV: Resource Base, Business Scenarios .

Here are some example criteria, selected by a large government organization with the intention of building a stable and widely applicable architecture:

"A standard or specification:

• Must meet the organization's requirements
• Must meet legal requirements
• Should be a publicly available specification
• Should have been developed by a process which sought a high level of consensus from a wide variety of sources
• Should be supported by a range of readily available products
• Should be complete
• Should be well understood, mature technology
• Should be testable, so that components or products can be checked for conformance
• Should support internationalization
• Should have no serious implications for ongoing support of legacy systems
• Should be stable
• Should be in wide use
• Should have few, if any problems or limitations"

A high level of consensus is often considered the most important factor by large organizations because standards and specifications chosen have to accommodate a wide range of user needs. For example, in determining the level of consensus for standards in their architecture, the Application Portability Profile (APP), the US National Institute for Standards and Technology (NIST) prefers to use international standards for the basis of specifications. The process through which these international standards have evolved requires a very high level of consensus. A number of US Federal Information Processing Standards (FIPS) specified in the APP are based on approved international standards. The use of international standards has significant benefits for any organization which works or trades with organizations in other countries.

Inputs

The inputs to Step 6 are:

• Target Business Architecture (Business Architecture), Version 1.0
• Target Technology Architecture (Technology Architecture), Version 0.6
• Standards Information Base (SIB)

Activities

Key activities in Step 6 include:

1. Brainstorm criteria for choosing specifications and portfolios of specifications relying on previously used criteria for existing system and extrapolating for new architectural elements.
2. Meet with sponsors and present current state to negotiate a continue request from sponsors.

Outputs

The outputs of Step 6 are:

• Target Technology Architecture (Technology Architecture), Version 0.7:
  • Technology Architecture - requirements traceability (standards selection criteria)

Step 7

Step 7 is to complete the architecture definition.

Objective

The objective of this step is to fully specify the Technology Architecture. This is a complex and iterative process in which the selection of building blocks and interfaces has a big impact on how the original requirements are met. See Part IV: Resource Base, Building Blocks for further details.

Approach

Completion of the architecture definition may be achieved in two steps, by defining an intermediate Transitional Architecture in addition to the final Target Architecture, if complexity of migration requires it.

The specification of building blocks as a portfolio of services is an evolutionary process:

• The earliest building block definitions start as relatively abstract ones, defined by standards and services that map most easily to the architecture framework. These building blocks are most probably ABBs.
• At this stage a model and a portfolio of services have been established. The next step is to select the set of specifications that provide the services and that can be combined as required to create the building blocks.
• During this final step in the development of building blocks it must be verified that the organization-specific requirements will be met. The development process must include recognition of dependencies and boundaries for functions and should take account of what products are available in the marketplace. There are architectural and related solution-oriented building blocks.
• An example of how this might be expressed can be seen in the building blocks example (Part IV: Resource Base, Building Blocks). Building blocks can be defined at a number of levels matching the degree of integration that best defines the architecture of the system at any stage.
  • Fundamental functionality and attributes - semantic, unambiguous including security capability and manageability
  • Interfaces - chosen set, supplied (APIs, data formats, protocols, hardware interfaces, standards)
  • Dependent building blocks with required functionality and named used interfaces
  • Map to business/organizational entities and policies
• Finally the building blocks become more implementation-specific as Solution Building Blocks (SBBs) and their interfaces become the detailed architecture specification. SBBs are a means to determine how portions of the Target Architecture might be procured, developed, or re-used. The SBBs architecture should have separate elements for developed, re-used, and procured building blocks, each described in terms of their minimum specification.

A full list of standards and specifications recommended by The Open Group can be found in Part III: Enterprise Continuum, Foundation Architecture: Standards Information Base .

Inputs

The inputs to Step 7 are:

• Target Business Architecture (Business Architecture), Version 1.0
• Target Technology Architecture (Technology Architecture), Version 0.7
• Re-usable Architecture Building Blocks, from organization's Architecture Continuum (The Architecture Continuum), if available
• Standards Information Base (SIB)

Activities

Key activities in Step 7 include:

1. Ensure clear documentation of all interfaces for each building block (APIs, data formats, protocols, hardware interfaces).
2. Select standards for each of the Architecture Building Blocks, re-using as much as possible from the reference models selected from the Architecture Continuum.
3. Fully document each Architecture Building Block.
4. Final cross-check of overall architecture against business requirements. Document rationale for building block decisions in the architecture document.
5. Document final requirements traceability reports.
6. Document final mapping of the architecture within the Architecture Continuum. From the selected Architecture Building Blocks, identify those that might be re-used, and publish via the architecture repository.
7. Document rationale for building block decisions in the architecture document.
8. Generate the Technology Architecture document.
9. Prepare the Technology Architecture Report. If appropriate, use reports and/or graphics generated by modeling tools to demonstrate key views of the architecture. Route the Technology Architecture document for review by relevant stakeholders, and incorporate feedback.
10. Checkpoint/Impact Analysis: Check the original motivation for the architecture project and the Statement of Architecture Work against the proposed Technology Architecture. Conduct an Impact Analysis, to:
    1. Identify any areas where the Business Architecture (e.g., business practices) may need to change to cater for changes in the Technology Architecture.

       If the impact is significant, this may warrant the Business Architecture being revisited.

    2. Identify any areas where the Data Architecture may need to change to cater for changes in the Technology Architecture.

       If the impact is significant, this may warrant the Data Architecture being revisited.

    3. Identify any areas where the Applications Architecture may need to change to cater for changes in the Technology Architecture.

       If the impact is significant, this may warrant the Applications Architecture being revisited.

    4. Refine the proposed Technology Architecture only if necessary.

Outputs

The outputs of Step 7 are:

• Target Technology Architecture (Technology Architecture), Version 0.8
  • Technology Architecture - architecture specification
  • Technology Architecture - requirements traceability
  • Technology Architecture - mapping of the architectures in the Architecture Continuum
  • Technology Architecture Report

Step 8

Step 8 is to conduct a gap analysis.

Objective

The objective of this step is to identify areas of the current and target system for which provision has not been made in the Technology Architecture. This is required in order to identify projects to be undertaken as part of the implementation of the target system.

Approach

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, as driven by the required applications. The most critical source of gaps that should be considered is stakeholder concerns that have not been addressed in subsequent architectural work.

Gap analysis highlights services and/or functions that have been accidentally left out, deliberately eliminated, or are yet to be developed or procured:

• Draw up a matrix with all the business functions of the Baseline Architecture on the vertical axis, and all the business functions of the Target Technology 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 Services", and to the Target Architecture axis a final column labeled "Eliminated Services".
• Where a function is available in both the Baseline and Target Architectures, record this with "Included" at the intersecting cell.
• Where a function from the Baseline Architecture is missing in the Target Architecture (in the example, "broadcast services" and "shared screen services"), each must be reviewed. If it was correctly eliminated, mark it as such in the appropriate "Eliminated Services" cell. If it was not, you have uncovered an accidental omission in your new architecture that must be addressed by reinstating the function in the next iteration of the design - mark it as such in the appropriate "Eliminated Services" cell.
• Where a function from the Target Architecture cannot be found in the Baseline Architecture (in the example, "mailing list services"), mark it at the intersection with the "New" row, as a gap that needs to be filled, either by developing or procuring the function.

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.

Gap Analysis Matrix shows an example from the Network Services category when functions from the Baseline Architecture are missing from the Target Architecture.

Inputs

The inputs to Step 8 are:

• Target Business Architecture (Business Architecture), Version 1.0
• Target Technology Architecture (Technology Architecture), Version 0.8
• Target Data Architecture, Version 1.0
• Target Applications Architecture, Version 1.0

Activities

Key activities in Step 8 include:

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, those that should be procured, and those inherited.

Outputs

The output of Step 8 is:

• Target Technology Architecture (Technology Architecture), Version 1.0:
  • Technology Architecture - gap report

Postscript

The Technology Architecture development process described above includes iterations. Financial and timing constraints should explicitly limit the number of iterations within Steps 1 through 8, and drive to implementation. After that, a new cycle of architecture evolution may ensue.

Choosing the scope of an architecture development cycle carefully will accelerate the pay-back. In contrast, an excessively large scope is unlikely to lead to successful implementation.

"How do you eat an elephant? - One bite at a time."
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.
  
  

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.