TOGAF D阶段：技术架构

11. Phase D: Technology Architecture (opengroup.org)

11. Phase D: Technology Architecture

12. D阶段：技术架构

11.1 Objectives | 11.2 Inputs | 11.3 Steps | 11.4 Outputs | 11.5 Approach

11.1 目标 | 11.2 输入 | 11.3 步骤 | 11.4 输出 | 11.5 方法

Figure 11-1: Phase D: Technology Architecture
图 11-1: 阶段D：技术架构

11.1 Objectives

11.1 目标

The objectives of Phase D are to:

• Develop the Target Technology Architecture that enables the Architecture Vision, target business, data, and application building blocks to be delivered through technology components and technology services, in a way that addresses the Statement of Architecture Work and stakeholder concerns
• Identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Technology Architectures

D阶段的目标是：

• 开发目标技术架构，使架构愿景、目标业务、数据和应用程序构建块能够通过技术组件和技术服务交付，以解决架构工作声明和干系人关注的问题
• 根据基线和目标技术架构之间的差距，确定候选架构路线图组件

11.2 Inputs

This section defines the inputs to Phase D.

11.2 输入

本节定义了阶段D的输入。

11.2.1 Reference Materials External to the Enterprise

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

11.2.1 企业外部参考资料

• 架构参考资料（见第四部分，32.2.5架构知识库）
• 候选产品的产品信息

11.2.2 Non-Architectural Inputs

• Request for Architecture Work (see Part IV, 32.2.17 Request for Architecture Work)
• Capability Assessment (see Part IV, 32.2.10 Capability Assessment)
• Communications Plan (see Part IV, 32.2.12 Communications Plan)

11.2.2 非架构输入

• 架构工作请求（见第四部分，32.2.17架构工作请求）
• 能力评估（见第四部分，32.2.10能力评估）
• 沟通计划（见第四部分，32.2.12沟通计划）

11.2.3 Architectural Inputs

11.2.3 架构输入

• Organizational Model for Enterprise Architecture (see Part IV, 32.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
• 企业架构组织模型（见第四部分，32.2.16企业架构组织模型），包括：
  • 受影响组织的范围
  • 成熟度评估、差距和解决方法
  • 架构团队的角色和职责
  • 架构工作的制约因素
  • 预算需求
  • 治理和支持战略
• Tailored Architecture Framework (see Part IV, 32.2.21 Tailored Architecture Framework), including:
  • Tailored architecture method
  • Tailored architecture content (deliverables and artifacts)
  • Configured and deployed tools
• 裁剪的架构框架（见第四部分，32.2.21裁剪的架构框架），包括：
  • 裁剪的架构方法
  • 裁剪的架构内容（交付物和工件）
  • 可配置和部署的工具
• Technology principles (see Part III, 20.6.4 Technology Principles), if existing
• Statement of Architecture Work (see Part IV, 32.2.20 Statement of Architecture Work)
• Architecture Vision (see Part IV, 32.2.8 Architecture Vision)
• Architecture Repository (see Part IV, 32.2.5 Architecture Repository), including:
  • Re-usable building blocks
  • Publicly available reference models
  • Organization-specific reference models
  • Organization standards
• 技术原则（见第三部分，20.6.4技术原则）（如有）
• 架构工作说明（见第四部分，32.2.20架构工作说明）
• 架构愿景（见第四部分，32.2.8架构愿景）
• 架构存储库（见第四部分，32.2.5架构存储库），包括：
  • 可重复使用的构建块
  • 公开可用的参考模型
  • 组织特定的参考模型
  • 组织标准
• Draft Architecture Definition Document (see Part IV, 32.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)
• 架构定义文件草案（见第四部分，32.2.3架构定义文件），包括：
  • 基线业务架构，版本1.0（详细）
  • 目标业务架构1.0版（详细）
  • 基线数据架构，版本1.0（详细）
  • 目标数据架构，版本1.0（详细）
  • 基线应用架构，版本1.0（详细）
  • 目标应用架构，版本1.0（详细）
  • 基线技术架构，版本0.1（愿景）
  • 目标技术架构，版本0.1（愿景）
• Draft Architecture Requirements Specification (see Part IV, 32.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, 32.2.7 Architecture Roadmap)
• 架构需求规范草案（见第四部分，32.2.6架构需求规范），包括：
  • 差距分析结果（来自业务、数据和应用架构）
  • 以往阶段相关技术需求
• 架构路线图的业务、数据和应用架构组件（参见第四部分，32.2.7架构路线图）

11.3 Steps

11.3 步骤

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.

阶段D中讨论的详细程度将取决于总体架构工作的范围和目标。

作为这项工作的一部分引入的新技术构建块需要在阶段D中详细定义。在阶段D中可能需要重新定义目标环境中支持的现有技术构建块，以确保互操作性并适合此特定技术架构中的用途。

The order of the steps in Phase D 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, 18. Applying Iteration to the ADM .

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

阶段D中步骤的顺序以及它们正式开始和完成的时间应该根据已建立的架构治理来适应当前的情况。特别是，确定在这种情况下，是否适合首先进行基线描述或目标架构开发，如第三部分中所述，18 将迭代应用于ADM。

这些步骤中启动的所有活动应在最终确定技术架构步骤期间结束（见11.3.8最终确定技术架构）。从这些步骤生成的文档必须在创建架构定义文档步骤中正式发布（见11.3.9创建架构定义文档）。

The steps in Phase D are as follows:

11.3.1 Select Reference Models, Viewpoints, and Tools
11.3.2 Develop Baseline Technology Architecture Description
11.3.3 Develop Target Technology Architecture Description
11.3.4 Perform Gap Analysis
11.3.5 Define Candidate Roadmap Components
11.3.6 Resolve Impacts Across the Architecture Landscape
11.3.7 Conduct Formal Stakeholder Review
11.3.8 Finalize the Technology Architecture
11.3.9 Create the Architecture Definition Document

D阶段的步骤如下：

11.3.1 选择参考模型、视点和工具
11.3.2 开发基线技术架构描述
11.3.3 开发目标技术架构描述
11.3.4 进行差距分析
11.3.5 定义候选路线图组件
11.3.6 解决整个架构远景的影响
11.3.7 进行正式的利益相关者审查
11.3.8 最终确定技术架构
11.3.9 创建架构定义文档

11.3.1 Select Reference Models, Viewpoints, and Tools
11.3.1 选择参考模型、视点和工具

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 technology principles, are given in Part III, 20. Architecture Principles .

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

评审并验证技术原则集合。这些通常将构成一套总体架构原则的一部分。第三部分 20 架构原则给出了开发和应用原则的指南以及一组技术原则示例。

根据业务驱动因素、利益相关者及其关注点，从架构存储库（见第五部分，37.架构存储库）中选择相关的技术架构资源（参考模型、模式等）。

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.

选择相关的技术架构观点，使架构师能够演示技术架构中如何解决干系人的问题。

确定与所选视点相关的用于捕获、建模和分析的适当工具和技术。根据所需的复杂程度，这些可能包括简单的文档和电子表格，或更复杂的建模工具和技术。

11.3.1.1 Determine Overall Modeling Process
11.3.1.1 确定整体建模过程

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 technology 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 technology service. The areas where the Technology Architecture may be impacted will include the following:

在ADM的早期阶段，围绕服务粒度和服务边界做出的某些决策将对技术组件和技术服务产生影响。技术架构可能受到影响的领域包括：

• Performance: the granularity of the service will impact on technology 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.

产品选择过程可能发生在技术架构阶段，在该阶段，重复使用现有产品，增加 增量容量，或者产品选择决策是项目启动期间的一个约束。

如果产品选择偏离现有标准、涉及重大努力或具有广泛影响，则应将此活动标记为机会，并通过机会与解决方案阶段解决。

11.3.1.2 Identify Required Catalogs of Technology Building Blocks
11.3.1.2 确定所需的技术构建块目录

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., technology 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 managing the business and IT capability.

目录是企业核心资产的清单。目录本质上是分层的，它捕获元模型实体的分解，以及相关模型实体之间的分解（例如，技术服务->逻辑技术组件->物理技术组件）。

目录是开发矩阵和图表的原材料，也是管理业务和IT能力的关键资源。

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 selected taxonomy 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, 30. Content Metamodel .

技术架构应创建如下技术目录：

• 根据现有技术目录和在应用架构阶段执行的应用分析，收集正在使用的产品列表
• 如果现有产品无法满足应用架构中确定的需求，请通过检查市场上提供功能并满足所需标准的产品来扩展产品列表
• 根据所选分类法（如果适用）对产品进行分类，根据需要扩展模型以适合所用技术产品的分类
• 如果当前有技术标准，请将这些标准应用于技术组件目录，以获得符合技术标准的基线视图

在技术架构内开发时应考虑以下目录：

• 技术标准
• 技术组合

目录的结构基于第四部分 30 内容元模型 中定义的元模型实体的属性。

11.3.1.3 Identify Required Matrices
11.3.1.3 确定所需矩阵

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:

• Application/Technology matrix

矩阵显示了相关模型实体之间的核心关系。

矩阵构成了图表开发的原材料，也是影响评估的关键资源。

在技术架构内开发时应考虑以下矩阵：

• 应用/技术矩阵

11.3.1.4 Identify Required Diagrams

11.3.1.4 确定所需的图表

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
• Network and Communications diagram

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

在技术架构内开发时，应考虑以下图表：

• 环境和位置图
• 平台分解图
• 流程图
• 网络计算/硬件图
• 网络和通信图

图的结构基于第四部分 30 内容元模型 中定义的元模型实体的属性。

11.3.1.5 Identify Types of Requirement to be Collected
11.3.1.5 确定需要收集的需求类型

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

一旦开发了技术架构目录、矩阵和图表，就可以通过形式化以技术为中心的需求来完成架构建模，以实现目标架构。

These requirements may:

• Relate to the technology domain
• Provide detailed guidance to be reflected during design and implementation to ensure that the solution addresses the original architecture requirements

这些要求可以：

• 与技术领域相关
• 提供在设计和实施期间反映的详细指导，以确保解决方案满足原始架构需求

Within this step, the architect should identify requirements that should be met by the architecture (see 16.5.2 Requirements Development).

在此步骤中，架构师应确定架构应满足的需求（参见16.5.2 需求开发）。

11.3.1.6 Select Services
11.3.1.6 选择服务

The services portfolios are combinations of basic services from the service categories in the defined taxonomy that do not conflict. The combination of services are again tested to ensure support for the applications. This is a prerequisite 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 the TOGAF standard, consideration should be given to how these might be replaced if standardized services become available in the future.

如果需求要求定义TOGAF标准中未确定的专门服务，则应考虑如果将来标准化服务可用，如何替换这些服务。

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.

对于每个构建块，将服务描述组合构建为一组无冲突的服务。必须对服务集进行测试，以确保提供的功能满足应用程序要求。

11.3.2 Develop Baseline Technology Architecture Description
11.3.2 开发基线技术架构描述

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 11.5 Approach .

开发现有技术架构的基线描述，以支持目标技术架构。待定义的范围和详细程度将取决于现有技术组件可能带入目标技术架构的程度，以及架构描述是否存在，如11.5方法所述。

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, 30. Content Metamodel).

识别相关的技术架构构建块，利用架构存储库中保存的任何工件。如果架构存储库中不存在任何内容，请根据技术组合目录定义每个应用（请参阅第四部分，30.内容元模型）。

Begin by converting the description of the existing environment into the terms of the organization's taxonomy of technology services and technology components (e.g., the TOGAF TRM). This will allow the team developing the architecture to gain experience and understanding of the taxonomy. 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.

首先，将现有环境的描述转换为组织的技术服务和技术组件分类术语（例如，TOGAF TRM）。这将允许开发架构的团队获得经验和对分类法的理解。团队可能能够利用以前的架构定义，但假设可能需要进行一些调整，以匹配作为此过程一部分描述的架构定义技术。另一项重要任务是制定一系列关键问题，这些问题可在开发过程的后期用于衡量新架构的有效性。

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.

如果需要开发新的架构模型以满足干系人的关注，请使用步骤1中确定的模型作为创建新架构内容的指南，以描述基线架构。

11.3.3 Develop Target Technology Architecture Description
11.3.3 开发目标技术架构描述

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, 37. Architecture Repository).

为技术架构制定目标描述，以支持架构愿景、目标业务架构和目标信息系统架构。要定义的范围和详细程度将取决于技术元素与实现目标架构的相关性，以及架构描述是否存在。尽可能在架构存储库（见第五部分，37.架构存储库）上确定相关的技术架构构建块。

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, 33.3 Building Blocks and the ADM .

创建目标系统的广泛架构模型的一个关键过程是构建块的概念化。架构构建块（ABB）描述了功能以及如何在没有配置或详细设计引入细节的情况下实现这些功能。第四部分33.3构建块和ADM中描述了定义构建块的方法，以及在创建架构模型时使用构建块的一些一般准则。

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.

如果需要开发新的架构模型以满足干系人的关注，请使用步骤1中确定的模型作为创建新架构内容的指南，以描述目标架构。

11.3.4 Perform Gap Analysis
11.3.4 进行差距分析

Verify the architecture models for internal consistency and accuracy:

• Perform trade-off analysis to resolve conflicts (if any) among the different views
• Validate that the models support the principles, objectives, and constraints
• 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, using the gap analysis technique as described in Part III, 23. Gap Analysis .

使用第三部分23 差距分析中所述的差距分析技术，确定基线和目标之间的差距。

11.3.5 Define Candidate Roadmap Components
11.3.5 定义候选路线图组件

Following the 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.

此初始技术架构路线图将用作原材料，以支持机会与解决方案阶段中整合的跨学科路线图的更详细定义。

11.3.6 Resolve Impacts Across the Architecture Landscape
11.3.6 解决整个架构景观的影响

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)?

在此阶段，应检查架构景观中的其他架构工件，以确定：

• 此技术架构是否会对任何现有架构产生影响？
• 最近是否进行了影响技术架构的更改？
• 是否有机会在组织的其他领域利用此技术架构的工作？
• 该技术架构是否会影响其他项目（包括计划中的项目和当前正在进行的项目）？
• 该技术架构是否会受到其他项目（包括计划中的项目和当前正在进行的项目）的影响？

11.3.7 Conduct Formal Stakeholder Review
11.3.7 进行正式的利益相关者评审

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.

对照提议的技术架构检查架构项目的原始动机和架构工作声明，询问其是否适合支持其他架构领域的后续工作。仅在必要时完善建议的技术架构。

11.3.8 Finalize the Technology Architecture
11.3.8 最终确定技术架构

• 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 a final cross-check of overall architecture against business goals; document the rationale for building block decisions in the architecture document

• Document the final requirements traceability report

• Document the 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

• 为每个构建块选择标准，尽可能地重复使用从架构存储库中选择的参考模型

• 完整记录每个构建块

• 根据业务目标对总体架构进行最终交叉检查；在架构文档中记录构建块决策的基本原理

• 记录最终需求可追溯性报告

• 在架构存储库中记录架构的最终映射；从选定的构建块中，确定可能重复使用的构建块（工作实践、角色、业务关系、工作描述等），并通过架构存储库发布

• 最终确定所有工作产品，如差距分析

11.3.9 Create the Architecture Definition Document
11.3.9 创建架构定义文档

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

准备架构定义文件的技术部分，包括以下部分或全部内容：

• 基本功能和属性-语义明确，包括安全功能和可管理性
• 具有所需功能和命名接口的相关构建块
• 接口-选择集，提供（API、数据格式、协议、硬件接口、标准）
• 映射到业务/组织实体和策略

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.

如果合适，使用建模工具生成的报告和/或图形来演示架构的关键视图。将文件发送给相关利益相关者审查，并纳入反馈。

11.4 Outputs
11.4 输出

The outputs of Phase D may include, but are not restricted to:
阶段D的输出可能包括但不限于：

• Refined and updated versions of the Architecture Vision phase deliverables, where applicable:

  • Statement of Architecture Work (see Part IV, 32.2.20 Statement of Architecture Work), updated if necessary
  • Validated technology principles, or new technology principles (if generated here)

• 架构愿景阶段交付物的改进和更新版本（如适用）：

  • 架构工作说明书（见第四部分，32.2.20架构工作说明书），必要时更新
  • 经验证的技术原则或新技术原则（如果在此处生成）

• Draft Architecture Definition Document (see Part IV, 32.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

• 架构定义文件草案（见第四部分，32.2.3架构定义文件），包括：

  • 目标技术架构，版本1.0（详细），包括：
    • 技术组件及其与信息系统的关系
    • 技术平台及其分解，显示实现特定技术“堆栈”所需的技术组合
    • 环境和位置-将所需技术分组到计算环境中（例如，开发、生产）
    • 预期处理负载和跨技术组件的负载分布
    • 物理（网络）通信
    • 硬件和网络规范
  • 基线技术架构，1.0版（详细），如适用
  • 与解决关键利益相关者问题的选定视点相对应的视图

• Draft Architecture Requirements Specification (see Part IV, 32.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, 32.2.7 Architecture Roadmap)

• 架构需求规范草案（见第四部分，32.2.6架构需求规范），包括以下技术架构需求：

  • 差距分析结果
  • B和C阶段的需求输出
  • 更新的技术要求

• 架构路线图的技术架构组件（见第四部分，32.2.7架构路线图）

The outputs may include some or all of the following:

• Catalogs:
  • Technology Standards catalog
  • Technology Portfolio catalog
• Matrices:
  • Application/Technology matrix
• Diagrams:
  • Environments and Locations diagram
  • Platform Decomposition diagram
  • Processing diagram
  • Networked Computing/Hardware diagram
  • Network and Communications diagram

输出可能包括以下部分或全部：

• 目录：
  • 技术标准目录
  • 技术组合目录
• 矩阵：
  • 应用/技术矩阵
• 图表：
  • 环境和位置图
  • 平台分解图
  • 流程图
  • 网络计算/硬件图
  • 网络和通信图

11.5 Approach
11.5 方法

11.5.1 Emerging Technologies
11.5.1 新兴技术

The evolution of new technologies is a major driver for change in enterprises looking for new innovative ways of operating and improving their business. The Technology Architecture needs to capture the transformation opportunities available to the enterprise through the adoption of new technology.

新技术的发展是企业寻求新的创新经营方式和改进业务的主要推动力。技术架构需要通过采用新技术来捕获企业可用的转型机会。

While the Enterprise Architecture is led by the business concerns, drivers for change are often found within evolving technology capabilities. As more digital innovations reach the market, stakeholders need to both anticipate and be open to technology-driven change. Part of Digital Transformation has arisen due to the convergence of telecommunications and computer capabilities which have opened up new ways of implementing infrastructures.

虽然企业体系结构由业务关注点主导，但变化的驱动因素通常存在于不断发展的技术能力中。随着越来越多的数字创新进入市场，利益相关者需要预测并接受技术驱动的变革。数字转型的一部分是由于电信和计算机能力的融合，这为基础设施的实施开辟了新的途径。

Solution development methods are also evolving to challenge traditional development methods and putting pressure on the shared services and common use benefits of the traditional Enterprise Architecture approach. Yet without a strong Enterprise Architecture approach, the rapid adoption of changing technologies will cause discontinuities across the enterprise.

解决方案开发方法也在不断演变，以挑战传统的开发方法，并对共享服务和传统企业架构方法的通用性带来压力。然而，如果没有强大的企业架构方法，快速采用不断变化的技术将导致整个企业的不连续性。

The flexibility of the TOGAF ADM enables technology change to become a driver and strategic resource rather than a recipient of Change Requests. As a result, the Technology Architecture may both drive business capabilities and respond to information system requirements at the same time.

TOGAF ADM的灵活性使技术变革成为推动因素和战略资源，而不是变革请求的接受者。因此，技术架构可能同时驱动业务能力和响应信息系统需求。

11.5.2 Architecture Repository
11.5.2 架构存储库

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, 37. Architecture Repository ).

作为阶段D的一部分，架构团队需要考虑架构存储库中可用的相关技术架构资源（参见第37部分，架构存储库）。

In particular:

• Existing IT services as documented in the IT repository or IT service catalog
• The adopted technical reference model, if applicable
• Generic technology models relevant to the organization's industry "vertical" sector; for example:
  • The TM Forum - www.tmforum.org - has developed detailed technology models relevant to the Telecommunications industry
• Technology models relevant to Common Systems Architectures
  • The Open Group has a Reference Model for Integrated Information Infrastructure (III-RM) - see the TOGAF® Series Guide: The TOGAF Integrated Information Infrastructure Reference Model (III-RM) - that focuses on the application-level components and underlying services necessary to provide an integrated information infrastructure

特别地：

• IT存储库或IT服务目录中记录的现有IT服务
• 采用的技术参考模型（如适用）
• 与组织行业“垂直”部门相关的通用技术模型；例如：
  • TM论坛-www.tmforum。org-开发了与电信行业相关的详细技术模型
• 与通用系统架构相关的技术模型
  • Open Group有一个集成信息基础架构（III-RM）参考模型—请参阅TOGAF®系列指南：TOGAF集成信息基础架构参考模型（III-RM）—该模型侧重于提供集成信息基础设施所需的应用级组件和基础服务