This chapter describes the development of a Technology Architecture for an architecture project.

12.1 Objectives

The Technology Architecture phase seeks to map application components defined in the Application Architecture phase into a set of technology components, which represent software and hardware components, available from the market or configured within the organization into technology platforms.

As Technology Architecture defines the physical realization of an architectural solution, it has strong links to implementation and migration planning.

Technology Architecture will define baseline (i.e., current) and target views of the technology portfolio, detailing the roadmap towards the Target Architecture, and to identify key work packages in the roadmap. Technology Architecture completes the set of architectural information and therefore supports cost assessment for particular migration scenarios.

12.2 Approach

12.2.1 Architecture Repository

As part of Phase D, the architecture team will need to consider what relevant Technology Architecture resources are available in the Architecture Repository (see Part V, 41. Architecture Repository ).

In particular:

• Existing IT services as documented in the IT repository or IT service catalog
• 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 Part VI, 44. Integrated Information Infrastructure Reference Model - that focuses on the application-level components and underlying services necessary to provide an integrated information infrastructure.

12.3 Inputs

This section defines the inputs to Phase D.

12.3.1 Reference Materials External to the Enterprise

• Architecture reference materials (see Part IV, 36.2.5 Architecture Repository)
• Product information on candidate products

12.3.2 Non-Architectural Inputs

• Request for Architecture Work (see Part IV, 36.2.17 Request for Architecture Work)
• Capability Assessment (see Part IV, 36.2.10 Capability Assessment)
• Communications Plan (see Part IV, 36.2.12 Communications Plan)

12.3.3 Architectural Inputs

• Organizational Model for Enterprise Architecture (see Part IV, 36.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, 36.2.21 Tailored Architecture Framework), including:
  • Tailored architecture method
  • Tailored architecture content (deliverables and artifacts)
  • Configured and deployed tools
• Technology principles (see Part III, 23.6.4 Technology Principles), if existing
• Statement of Architecture Work (see Part IV, 36.2.20 Statement of Architecture Work)
• Architecture Vision (see Part IV, 36.2.8 Architecture Vision)
• Architecture Repository (see Part IV, 36.2.5 Architecture Repository), including:
  • Re-usable building blocks
  • Publicly available reference models
  • Organization-specific reference models
  • Organization standards
• Draft Architecture Definition Document (see Part IV, 36.2.3 Architecture Definition Document), including:
  • Baseline Business Architecture, Version 1.0 (detailed)
  • Target Business Architecture Version 1.0 (detailed)
  • Baseline Data Architecture, Version 1.0 (detailed)
  • Target Data Architecture, Version 1.0 (detailed)
  • Baseline Application Architecture, Version 1.0 (detailed)
  • Target Application Architecture, Version 1.0 (detailed)
  • Baseline Technology Architecture, Version 0.1 (vision)
  • Target Technology Architecture, Version 0.1 (vision)
• Draft Architecture Requirements Specification (see Part IV, 36.2.6 Architecture Requirements Specification), including:
  • Gap analysis results (from Business, Data, and Application Architectures)
  • Relevant technical requirements from previous phases
• Business, Data, and Application Architecture components of an Architecture Roadmap (see Part IV, 36.2.7 Architecture Roadmap)

12.4 Steps

The level of detail addressed in Phase D will depend on the scope and goals of the overall architecture effort.

New technology building blocks being introduced as part of this effort will need to be defined in detail during Phase D. Existing technology building blocks to be supported in the target environment may need to be redefined in Phase D to ensure interoperability and fit-for-purpose within this specific Technology Architecture.

The order of the steps in Phase D (see below) 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 Description or Target Architecture development first, as described in Part III, 19. Applying Iteration to the ADM .

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

The steps in Phase D are as follows:

• 12.4.1 Select Reference Models, Viewpoints, and Tools
• 12.4.2 Develop Baseline Technology Architecture Description
• 12.4.3 Develop Target Technology Architecture Description
• 12.4.4 Perform Gap Analysis
• 12.4.5 Define Roadmap Components
• 12.4.6 Resolve Impacts Across the Architecture Landscape
• 12.4.7 Conduct Formal Stakeholder Review
• 12.4.8 Finalize the Technology Architecture
• 12.4.9 Create Architecture Definition Document

12.4.1 Select Reference Models, Viewpoints, and Tools

Review and validate the set of technology principles. These will normally form part of an overarching set of architecture principles. Guidelines for developing and applying principles, and a sample set of application principles, are given in Part III, 23. Architecture Principles .

Select relevant Technology Architecture resources (reference models, patterns, etc.) from the Architecture Repository (see Part V, 41. Architecture Repository), on the basis of the business drivers, stakeholders, and their concerns.

Select relevant Technology Architecture viewpoints that will enable the architect to demonstrate how the stakeholder concerns are being addressed in the Technology 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 required, these may comprise simple documents and spreadsheets, or more sophisticated modeling tools and techniques.

12.4.1.1 Determine Overall Modeling Process

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 them, or augment existing models (see above).

The process to develop a Technology Architecture incorporates the following steps:

• Define a taxonomy of platform services and logical technology components (including standards)
• Identify relevant locations where technology is deployed
• Carry out a physical inventory of deployed technology and abstract up to fit into the taxonomy
• Look at application and business requirements for technology
• Is the technology in place fit-for-purpose to meet new requirements (i.e., does it meet functional and non-functional requirements)?
  • Refine the taxonomy
  • Product selection (including dependent products)
• Determine configuration of the selected technology
• Determine impact:
  • Sizing and costing
  • Capacity planning
  • Installation/governance/migration impacts

In the earlier phases of the ADM, certain decisions made around service granularity and service boundaries will have implications on the technology component and the platform service. The areas where the Technology Architecture may be impacted will include the following:

• Performance: The granularity of the service will impact on platform service requirements. Coarse-grained services contain several units of functionality with potentially varying non-functional requirements, so platform performance should be considered. In addition, coarse-grained services can sometimes contain more information than actually required by the requesting system.
• Maintainability: If service granularity is too coarse, then introducing changes to that service becomes difficult and impacts the maintenance of the service and the platform on which it is delivered.
• Location and Latency: Services might interact with each other over remote links and inter-service communication will have in-built latency. Drawing service boundaries and setting the service granularity should consider platform/location impact of these inter-service communications.
• Availability: Service invocation is subject to network and/or service failure. So high communication availability is an important consideration during service decomposition and defining service granularity

Product selection processes may occur within the Technology Architecture phase where existing products are re-used, incremental capacity is being added, or product selection decisions are a constraint during project initiation.

Where product selection deviates from existing standards, involves significant effort, or has wide-ranging impact, this activity should be flagged as an opportunity and addressed through the Opportunities & Solutions phase.

12.4.1.2 Identify Required Catalogs of Technology Building Blocks

Catalogs are inventories of the core assets of the business. Catalogs are hierarchical in nature and capture a decomposition of a metamodel entity and also decompositions across related model entities (e.g., platform service -> logical technology component -> physical technology component).

Catalogs form the raw material for development of matrices and diagrams and also act as a key resource for portfolio managing business and IT capability.

The Technology Architecture should create technology catalogs as follows:

• Based on existing technology catalogs and analysis of applications carried out in the Application Architecture phase, collect a list of products in use.
• If the requirements identified in the Application Architecture are not met by existing products, extend the product list by examining products available on the market that provide the functionality and meet the required standards.
• Classify products against the TOGAF TRM if appropriate, extending the model as necessary to fit the classification of technology products in use.
• If technology standards are currently in place, apply these to the technology component catalog to gain a baseline view of compliance with technology standards.

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

• Technology standards
• Technology portfolio

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

12.4.1.3 Identify Required Matrices

Matrices show the core relationships between related model entities.

Matrices form the raw material for development of diagrams and also act as a key resource for impact assessment.

The following matrix should be considered for development within a Technology Architecture:

• System/Technology matrix

12.4.1.4 Identify Required Diagrams

Diagrams present the Technology Architecture information from a set of different perspectives (viewpoints) according to the requirements of the stakeholders.

This activity provides a link between platform requirements and hosting requirements, as a single application may need to be physically located in several environments to support local access, development lifecycles, and hosting requirements.

For major baseline applications or application platforms (where multiple applications are hosted on the same infrastructure stack), produce a stack diagram showing how hardware, operating system, software infrastructure, and packaged applications combine.

If appropriate, extend the Application Architecture diagrams of software distribution to show how applications map onto the technology platform.

For each environment, produce a logical diagram of hardware and software infrastructure showing the contents of the environment and logical communications between components. Where available, collect capacity information on the deployed infrastructure.

For each environment, produce a physical diagram of communications infrastructure, such as routers, switches, firewalls, and network links. Where available, collect capacity information on the communications infrastructure.

The following diagrams should be considered for development within a Technology Architecture:

• Environments and Locations diagram
• Platform Decomposition diagram
• Processing diagram
• Networked Computing/Hardware diagram
• Communications Engineering diagram

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

12.4.1.5 Identify Types of Requirement to be Collected

Once the Technology Architecture catalogs, matrices, and diagrams have been developed, architecture modeling is completed by formalizing the data-focused requirements for implementing the Target Architecture.

Within this step, the architecture engagement should identify types of requirement that must be met by the architecture implementation, including:

• Functional requirements
• Non-functional requirements
• Assumptions
• Constraints
• Domain-specific Technology Architecture principles
• Policies
• Standards
• Guidelines
• Specifications

12.4.1.6 Select Services

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 previously identified requirements 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 building block, 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.

12.4.2 Develop Baseline Technology Architecture Description

Develop a Baseline Description of the existing Technology Architecture, 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 architectural descriptions exist, as described in 12.2 Approach .

Identify the relevant Technology Architecture building blocks, drawing on any artifacts held in the Architecture Repository. If nothing exists within the Architecture Repository, define each application in line with the Technology Portfolio catalog (see Part IV, 34. Content Metamodel).

Begin by converting the description of the existing environment into the terms of the 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.

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.

12.4.3 Develop Target Technology Architecture Description

Develop a Target Description for the Technology Architecture, to the extent necessary to support the Architecture Vision, Target Business Architecture, and Target Information Systems Architecture. The scope and level of detail to be defined will depend on the relevance of the technology elements to attaining the Target Architecture, and on whether architectural descriptions exist. To the extent possible, identify the relevant Technology Architecture building blocks, drawing on the Architecture Repository (see Part V, 41. Architecture Repository).

A key process in the creation of a broad architectural model of the target system is the conceptualization of building blocks. Architecture Building Blocks (ABBs) describe the functionality and how they may be implemented without the detail introduced by configuration or detailed design. The method of defining building blocks, along with some general guidelines for their use in creating an architectural model, is described in Part IV, 37.3 Building Blocks and the ADM , and illustrated in detail in 37.4 Building Blocks Example ).

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.

12.4.4 Perform Gap Analysis

First, verify the architecture models for internal consistency and accuracy.

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:

• Create gap matrix, as described in Part III, 27. Gap Analysis
• Identify building blocks to be carried over, classifying as either changed or unchanged
• Identify eliminated building blocks
• Identify new building blocks
• Identify gaps and classify as those that should be developed and those that should be procured

12.4.5 Define Roadmap Components

Following creation of a Baseline Architecture, Target Architecture, and gap analysis, a Technology Roadmap is required to prioritize activities over the coming phases.

This initial Technology Architecture roadmap will be used as raw material to support more detailed definition of a consolidated, cross-discipline roadmap within the Opportunities & Solutions phase.

12.4.6 Resolve Impacts Across the Architecture Landscape

Once the Technology 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 Technology Architecture create an impact on any pre-existing architectures?
• Have recent changes been made that impact the Technology Architecture?
• Are there any opportunities to leverage work from this Technology Architecture in other areas of the organization?
• Does this Technology Architecture impact other projects (including those planned as well as those currently in progress)?
• Will this Technology Architecture be impacted by other projects (including those planned as well as those currently in progress)?

12.4.7 Conduct Formal Stakeholder Review

Check the original motivation for the architecture project and the Statement of Architecture Work against the proposed Technology Architecture, asking if it is fit for the purpose of supporting subsequent work in the other architecture domains. Refine the proposed Technology Architecture only if necessary.

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

12.4.9 Create Architecture Definition Document

Document the rationale for building block decisions in the Architecture Definition Document.

Prepare the technology sections of the Architecture Definition Document, comprising some or all of:

• Fundamental functionality and attributes - semantic, unambiguous including security capability and manageability
• Dependent building blocks with required functionality and named interfaces
• Interfaces - chosen set, supplied (APIs, data formats, protocols, hardware interfaces, standards)
• Map to business/organizational entities and policies

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.

12.5 Outputs

The outputs of Phase D are:

• Refined and updated versions of the Architecture Vision phase deliverables, where applicable:
  • Statement of Architecture Work (see Part IV, 36.2.20 Statement of Architecture Work), updated if necessary
  • Validated technology principles, or new technology principles (if generated here)
• Draft Architecture Definition Document (see Part IV, 36.2.3 Architecture Definition Document), including:
  • Target Technology Architecture, Version 1.0 (detailed), including:
    • Technology Components and their relationships to information systems
    • Technology platforms and their decomposition, showing the combinations of technology required to realize a particular technology "stack"
    • Environments and locations - a grouping of the required technology into computing environments (e.g., development, production)
    • Expected processing load and distribution of load across technology components
    • Physical (network) communications
    • Hardware and network specifications
  • Baseline Technology Architecture, Version 1.0 (detailed), if appropriate
  • Views corresponding to the selected viewpoints addressing key stakeholder concerns
• Draft Architecture Requirements Specification (see Part IV, 36.2.6 Architecture Requirements Specification), including such Technology Architecture requirements as:
  • Gap analysis results
  • Requirements output from Phases B and C
  • Updated technology requirements
• Technology Architecture components of an Architecture Roadmap (see Part IV, 36.2.7 Architecture Roadmap)

12.6 Postscript

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.

return to top of page