【TOGAF系列】架构开发方法（ADF）第八章

第8章：D阶段：技术架构

8.1 目标

D阶段的目标是：

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

8.2 输入

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

8.2.1 企业外部参考资料

• 架构参考资料（见TOGAF标准——架构内容）
• 候选产品的产品信息

8.2.2 非架构输入

• 架构工作请求（见TOGAF标准——架构内容）
• 能力评估（见TOGAF标准——架构内容）
• 通信计划（见TOGAF标准——架构内容）

8.2.3 架构输入

■ 企业架构的组织模型（见TOGAF标准——架构内容），包括：
— 受影响组织的范围
— 成熟度评估、差距和解决方法
— 架构团队的角色和职责
— 建筑工作的限制
— 所需预算
— 治理和支持战略
■ 定制的架构框架（见TOGAF标准——架构内容），包括：
— 量身定制的架构方法
— 量身定制的架构内容（可交付成果和工件）
— 已配置和部署的工具
■ 技术原则（见TOGAF标准-ADM技术）（如果存在）
■ 架构工作说明书（见TOGAF标准——架构内容）
■ 架构愿景（见TOGAF标准——架构内容）
■ 架构库（见TOGAF标准——架构内容），包括：
— 可重复使用的构建块
— 公开可用的参考模型
— 特定组织的参考模型
— 组织标准
■ 架构定义文件草案，其中可能包括任何架构域的基线和/或目标架构
■ 架构需求规范草案（见TOGAF标准——架构内容），包括：
— 差距分析结果（来自业务、数据和应用程序架构）
— 前期相关技术要求
■ 架构路线图中的业务、数据和应用程序架构组件（请参阅TOGAF标准——架构内容）

8.3 步骤

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

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

阶段D中的步骤顺序以及正式开始和完成的时间应根据既定的架构治理适应当前的情况。特别是，确定在这种情况下，是否适合首先进行基线描述或目标架构开发，如TOGAF标准——应用ADM中所述。

在完成技术架构步骤期间，应关闭在这些步骤中启动的所有活动（见第8.3.8节）。这些步骤生成的文档必须在创建/更新架构定义文档步骤中正式发布（见第8.3.9节）。

D阶段的步骤如下：

• 选择参考模型、视点和工具（见第8.3.1节）
• 制定基线技术架构描述（见第8.3.2节）
• 制定目标技术架构描述（见第8.3.3节）
• 进行差距分析（见第8.3.4节）
• 定义候选路线图组件（见第8.3.5节）
• 解决整个建筑景观的影响（见第8.3.6节）
• 进行正式的利益相关者审查（见第8.3.7节）
• 最终确定技术架构（见第8.3.8节）
• 创建/更新架构定义文档（见第8.3.9节）

8.3.1 选择参考模型、视点和工具

审查并验证这套技术原则。这些通常会构成一套总体架构原则的一部分。TOGAF标准-ADM技术中给出了开发和应用原则的指南以及一组技术原则示例。

根据业务驱动因素、利益相关者及其关注点，从架构库（参见TOGAF标准——架构内容）中选择相关的技术架构资源（参考模型、模式等）。

选择相关的技术架构观点，使架构师能够演示如何在技术架构中解决利益相关者的问题。确定与所选视点相关的用于捕获、建模和分析的适当工具和技术。根据所需的复杂程度，这些可能包括简单的文档和电子表格，或更复杂的建模工具和技术。

8.3.1.1 确定总体建模过程

对于每个视点，使用所选工具或方法选择支持所需特定视图所需的模型。确保涵盖所有利益相关
者的关切。如果不是，则创建新模型来解决这些问题，或增强现有模型（见上文）。
开发技术架构的过程包括以下步骤：
■ 定义技术服务和逻辑技术组件（包括标准）的分类
■ 确定部署技术的相关位置
■ 对已部署的技术进行实地盘点，并进行抽象以符合分类
■ 查看技术的应用程序和业务需求
■ 现有技术是否适合满足新要求（即，它是否满足功能和非功能要求）？

— 细化分类
— 产品选择（包括相关产品）
■ 确定所选技术的配置
■ 确定影响：
— 规模和成本
— 容量规划
— 安装/治理/迁移影响

在ADM的早期阶段，围绕服务粒度和服务边界做出的某些决策将对技术组件和技术服务产生影响。

技术架构可能受到影响的领域包括：

■ 性能：服务的粒度将影响技术服务需求
粗粒度服务包含多个功能单元，这些功能单元可能具有不同的非功能需求，因此应考虑平台
性能。此外，粗粒度服务有时可能包含比请求系统实际所需更多的信息。
■ 可维护性：如果服务粒度太粗，那么对该服务进行更改就会变得困难，并影响服务及其交付
平台的维护
■ 位置和延迟：服务可能通过远程链路相互交互，服务间通信将具有内置延迟
绘制服务边界和设置服务粒度应考虑这些服务间通信的平台/位置影响。
■ 可用性：服务调用受网络和/或服务故障的影响
在服务分解和定义服务粒度时，高通信可用性是一个重要的考虑因素。

产品选择过程可能发生在技术架构阶段，在该阶段，现有产品被重复使用，增量容量被添加，或者产品选择决策在项目启动过程中成为约束。

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

8.3.1.2 确定所需的技术构建块目录

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

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

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

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

TOGAF标准——架构内容详细描述了技术架构中应考虑开发的目录，详细描述了它们，并将其与TOGAF企业元模型中的实体、属性和关系联系起来。

8.3.1.3 确定所需矩阵

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

矩阵是绘制图表的原材料，也是影响评估的关键资源。

TOGAF标准——架构内容详细描述了技术架构中应考虑开发的矩阵，详细描述了它们，并将其与TOGAF企业元模型中的实体、属性和关系联系起来。

8.3.1.4 确定所需图表

图表根据利益相关者的要求，从一组不同的角度（视点）呈现技术架构信息。

此活动提供了平台要求和托管要求之间的联系，因为单个应用程序可能需要物理上位于多个环境中，以支持本地访问、开发生命周期和托管要求。

对于主要的基线应用程序或应用程序平台（多个应用程序托管在同一基础架构堆栈上），生成一个堆栈图，显示硬件、操作系统、软件基础架构和打包应用程序是如何组合的。

如果合适，扩展软件分发的应用程序架构图，以显示应用程序如何映射到技术平台上。

对于每种环境，制作一个硬件和软件基础设施的逻辑图，显示环境的内容和组件之间的逻辑通信。在可用的情况下，收集已部署基础设施的容量信息。

对于每种环境，绘制通信基础设施的物理图，如路由器、交换机、防火墙和网络链接。在可能的情况下，收集通信基础设施的容量信息。

TOGAF标准——架构内容包含对图表的详细描述应考虑在技术架构内进行开发，详细描述它们，并将其与TOGAF企业元模型中的实体、属性和关系联系起来。

8.3.1.5确定要收集的需求类型

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

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

在此步骤中，架构师应确定架构应满足的要求（见第13.5.2节）。

8.3.1.6选择服务

服务组合是定义的分类法中服务类别中不冲突的基本服务的组合。再次测试服务组合，以确保对应用程序的支持。这是完整定义架构的后续步骤的先决条件。

之前确定的要求可以提供有关以下方面的更详细信息：

• 对组织特定要素或预先存在的决策的要求（如适用）
• 现有和不变的组织要素（如适用）
• 继承的外部环境约束

如果需求要求定义TOGAF标准中未确定的专业服务，则应考虑如果未来标准化服务可用，如何替换这些服务。对于每个构建块，将服务描述组合构建为一组不冲突的服务。必须对服务集进行测试，以确保提供的功能满足应用程序要求。

8.3.2 制定基线技术架构描述

制定现有技术架构的基线描述，以支持目标技术架构。定义的范围和详细程度将取决于现有技术组件在多大程度上可能被转移到目标技术架构中，以及是否存在架构描述，如第8.5节所述。利用架构库中保存的任何工件，确定相关的技术架构构建块。如果架构库中不存在任何内容，请根据技术组合目录定义每个应用程序（请参阅TOGAF标准——架构内容）。

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

如果需要开发新的架构（architecture）模型来满足利益相关者的担忧，请使用步骤1中确定的模型 作 为 创 建 新 架 构 （ architectural ） 内 容 的 指 导 方 针 ， 以 描 述 基 线 架 构 （ Baseline architecture）。

8.3.3 制定目标技术架构描述

为技术架构制定目标描述，以支持架构愿景、目标业务架构和目标信息系统架构。定义的范围和详细程度将取决于技术元素与实现目标架构的相关性，以及是否存在架构描述。在可能的情况下，利用架构库（见TOGAF标准——架构内容）确定相关的技术架构构建块。

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

如果需要开发新的架构（architecture）模型来满足利益相关者的关注，请使用步骤1中确定的模型作为创建新架构（architectural）内容的指导方针，以描述目标架构（architectures）。如果合适，调查不同的目标架构备选方案，并使用架构备选方案和权衡技术与利益相关者讨论这些方案（见TOGAF标准-ADM技术）。

8.3.4 执行差距分析

验证架构模型的内部一致性和准确性：

• 执行权衡分析以解决不同视图之间的冲突（如果有的话）
• 验证模型是否支持原则、目标和约束
• 注意对架构存储库中选定模型中表示的视点的更改，并记录
• 根据需求测试架构模型的完整性

使用TOGAF标准-ADM技术中描述的差距分析技术，确定基线和目标之间的差距。

8.3.5 定义候选路线图组件

在创建基线架构、目标架构和差距分析后，需要一份技术路线图来确定未来阶段活动的优先级。该初始技术架构路线图将用作原材料，以支持在机会和解决方案阶段对综合跨学科路线图进行更详细的定义。

8.3.6 解决整个架构景观的影响

一旦技术架构最终确定，就有必要了解任何更广泛的影响或含义。

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

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

8.3.7 进行正式的利益相关者审查

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

8.3.8 最终确定技术架构

• 为每个构建块选择标准，尽可能多地重复使用从架构库中选择的参考模型
• 完整记录每个构建块
• 根据业务目标对整体架构进行最终的交叉检查；在架构文档中记录构建块决策的基本原理
• 记录最终需求可追溯性报告
• 在架构库中记录架构的最终映射；从选定的构建块中，确定可能重复使用的构建块（工作实践、角色、业务关系、职位描述等），并通过架构存储库发布

■ 最终确定所有工作成果，如差距分析

8.3.9 创建/更新架构定义文档

在架构定义文档中记录构建块决策的基本原理。

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

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

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

8.4 输出

阶段D的输出可能包括但不限于：
■ 架构愿景阶段交付成果的改进和更新版本（如适用）：
— 架构工作说明书（见TOGAF标准——架构内容），必要时进行更新
— 经过验证的技术原理或新技术原理（如果在此处生成）
■ 架构定义文档草案（见TOGAF标准——架构内容），包括：
— 批准的基线技术架构（如适用）
— 已批准的目标技术架构，包括：
— 技术组件及其与信息系统的关系
— 技术平台及其分解，显示实现特定技术“堆栈”所需的技术组合
— 环境和位置——将所需技术分组到计算环境中（例如开发、生产）
— 预期的处理负载和跨技术组件的负载分布
— 物理（网络）通信
— 硬件和网络规格

--与解决关键利益相关者问题的选定观点相对应的观点
■ 架构需求规范草案（见TOGAF标准——架构内容），包括以下技术架构需求：
— 差距分析结果
— B和C阶段输出的需求
— 更新的技术要求
■ 架构路线图的技术架构组件（见TOGAF标准——架构内容）

TOGAF标准——架构内容包含了这个阶段可能产生的架构工件的详细描述。

8.5 方法

8.5.1 新兴技术

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

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

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

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

8.5.2 架构存储库

作为阶段D的一部分，架构团队需要考虑架构库中可用的相关技术架构资源（见TOGAF标准——架构内容）。

特别地：

• IT存储库或IT服务目录中记录的现有IT服务
• 采用的技术参考模型（如适用）
• 与组织行业部门相关的通用技术模型
• 与通用系统架构相关的技术模型

--开放组织有一个集成信息基础架构参考模型（III-RM）——见TOGAF®系列指南：TOGAF集成信息基础设施参考模型（II-RM）——它侧重于提供集成信息基础结构所需的应用程序级组件和底层服务