Phase A-D: Develop the Technology Architecture V2

Introduction

Purpose

The purpose of Phase A-D is to develop a Technology Architecture.

Objectives

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

Approach

Detailed guidelines for Phase A-D, including Inputs, Steps, and Outputs, are given below.

Architecture Continuum

As part of this phase, 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) (see Book 3: Technical Reference Model)

• Generic technology models relevant to the organization's industry "vertical" sector (for example, the TeleManagement Forum (TMF) 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 Book 3: Integrated Information Infrastructure Reference Model) that focuses on the application-level components and underlying services necessary to provide an integrated information infrastructure)

Graphic

INSERT NEW GRAPHIC HERE

Process

The process steps for Phase A-D are:

1. Technology Architecture Baseline 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 Baseline Technology Architecture Report: Summarize key findings and conclusions, developing suitable graphics and schematics to illustrate baseline configuration(s). If warranted, provide individual Technology Architecture Baseline Descriptions as Annexes.

   5. Route the Baseline Technology Architecture Report for review by relevant stakeholders, and incorporate feedback. Refine the Baseline Description only if necessary.

2. Target Technology Architecture: Detailed activities for this step, including Inputs, Activities, and Outputs, are as follows:

• Step 1: Create a Baseline Description.

• Step 2: Consider architecture reference models, viewpoints, and tools.

• Step 3: Create an architectural model of building blocks.

• Step 4: Select the services portfolio required per building block.

• Step 5: Confirm that business goals and objectives are met.

• Step 6: Determine criteria for specification selection.

• Step 7: Complete the architecture definition.

• Step 8: Conduct a Gap Analysis.

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

Statement on SOA

Add Technology Architecture process model here - new material.

Roles

• Prime Technology Architect
  • Enterprise Architects (see Enterprise Architect)
  • Solution Architects
• Chief Architect
• Business Stakeholders
• Enterprise Stakeholders
• Program and Project Managers

Inputs

• Technology Principles (see Architecture Principles)
• Request for Architecture Work (see Request for Architecture Work)
• Statement of Architecture Work (see Statement of Architecture Work)
• Architecture Vision (see Architecture Vision)
• Technical Requirements (see Technical Requirements)
• Gap Analysis (from Data Architecture) (see Gap Analysis)
• Gap Analysis (from Applications Architecture)
• Baseline Business Architecture V2
• Baseline Data Architecture V2
• Baseline Applications Architecture V2
• Target Business Architecture V2
• Re-Usable Architecture Building Blocks from the Enterprise Continuum (see Re-Usable Architecture Building Blocks)
• Target Data Architecture V2, including:
  • Conceptual Data Model
  • Logical Data Model
  • Data Management Process Model
  • Data Entity/Business Function Matrix
  • Data Interoperability Requirements
• Target Applications Architecture V2, including:
  • Process Systems Model
  • Place Systems Model
  • Time Systems Model
  • People Systems Model
  • Applications Interoperability Requirements

Outputs

• Technology Architecture Description
• Statement of Architecture Work (updated if necessary) (see Statement of Architecture Work)
• Baseline Technology Architecture V2
• Technology Principles (see Architecture Principles):
  • Validated
  • New
• Technology Architecture Report (see Architecture Report)
• Target Technology Architecture V2, including:
  • Constraints
  • Architecture Principles
  • Target services
  • Change requests and/or amendments to be incorporated in an organization-specific Architecture Continuum
  • Architecture specification
  • Requirements traceability, including:
    • Key questions list
    • Criteria for selection of service portfolio
    • Business objectives criteria
    • Standards selection criteria
  • Mapping of architectures in the Architecture Continuum
  • Technology Architecture models V0.1 to V0.7
• Technology Architecture Gap Report
• Viewpoints (see Viewpoint)
• Views (see Views)
• Technology Measures (see Enterprise Architecture Measures)