You are here: TOGAF 8.1.1 Online > Part II: Architecture Development Method (ADM) > Phase D: Technology Architecture
<<< Previous Home Next >>>

Phase D: Technology Architecture


Objective | Approach | Inputs | Steps | Outputs | Target Technology Architecture - Detail

This chapter describes the development of a Technology Architecture.



Figure: Phase D: 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:

Inputs

Inputs to Phase D are:

Steps

Key steps in Phase D include:

  1. Develop Baseline Technology Architecture Baseline Description: 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 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 Baseline Descriptions as Annexes.
    5. Route the Technology Architecture Baseline report for review by relevant stakeholders, and incorporate feedback. Refine the Baseline Description only if necessary.
  2. Develop Target Technology Architecture; see detailed steps. 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:

Target Technology Architecture - Detail

Introduction

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

Overview

The steps involved in development of the Target Technology Architecture are illustrated in Technology Architecture Development .

(figure deleted)


Figure: Technology Architecture Development

The boxes and ovals in Technology Architecture Development are color-coded as follows:

It is possible that an An organization creating or adapting a Technology Architecture may already mandates mandate the use of a list of approved suppliers/products for that organization. Such a The list would will be an input to the definition of the organization-specific architecture framework, as shown in Technology Architecture Development . framework. The architectures can then be used as procurement tools to govern the future growth and the development of the organization's IT infrastructure.

The key steps outlined in Technology Architecture Development 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.

(figure deleted)


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:

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:

Step 2

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

(figure deleted)


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:

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

The outputs of Step 2 are:

Step 3

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

(figure deleted)


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:

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

Step 4

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

(figure deleted)


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:

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:

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:

Step 5

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

(figure deleted)


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:

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:

Step 6

Step 6 is to determine criteria for specification selection.

(figure deleted)


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:

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:

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:

Step 7

Step 7 is to complete the architecture definition.

(figure deleted)


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. Technology Architecture Development shows this as two boxes, captioned as Steps 7a and 7b, but in reality the process is more complicated. 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:

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:

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

Step 8

Step 8 is to conduct a gap analysis.

(figure deleted)


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:

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 current architecture Baseline Architecture are missing from the Target Architecture.



Table: Gap Analysis Matrix
Inputs

The inputs to Step 8 are:

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:

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


Navigation

The TOGAF document set is designed for use with frames. To navigate around the document:



return to top of page

Downloads

Downloads of the TOGAF documentation, are available under license from the TOGAF information web site . The license is free to any organization wishing to use TOGAF entirely for internal purposes (for example, to develop an information system architecture for use within that organization). A hardcopy book is also available from The Open Group Bookstore as document G063 .

Copyright © 1999-2006 The Open Group, All Rights Reserved
TOGAF is a trademark of The Open Group
<<< Previous Home Next >>>