本章描述识别有效交付的交付工具（项目、项目群或项目组合）的过程在前面阶段确定的目标体系结构。

一、目标

E阶段的目标是：

根据差距分析和候选架构生成架构路线图的初始完整版本阶段 B、C 和 D 的路线图组件
确定是否需要增量方法，如果需要，确定将提供连续的过渡体系结构商业价值
定义整体解决方案构建块（SBB）以最终确定基于 ABB 的目标体系结构

二、输入

本节定义阶段 E 的输入。

1 企业外部参考物质

架构参考资料
产品信息

2 非架构输入

架构工作请求
能力评估
沟通计划
规划方法

3 架构输入

企业架构的组织模型（请参阅 TOGAF 标准 — 架构内容），包括：

受影响的组织范围
成熟度评估、差距和解决方法
架构团队的角色和职责
体系结构工作的约束
预算需求
治理和支持战略

治理模型和框架：

企业业务规划
企业架构
项目组合、项目群、项目管理
系统开发/工程
运营（服务）

定制架构框架（请参阅 TOGAF 标准 — 架构内容），包括：

量身定制的架构方法
定制的架构内容（可交付成果和工件）
已配置和部署的工具

架构工作声明

架构愿景

架构存储库

可重复使用的构建块
公开可用的参考模型
组织特定的参考模型
组织标准

架构定义文档草案，其中可能包括任何架构领域的基线和/或目标架构

架构需求规范草案，包括：

体系结构要求
差距分析结果（来自业务、数据、应用程序和技术架构）
IT 服务管理要求

现有业务计划和项目的变更请求

阶段 B、C 和 D 的候选架构路线图组件

三、步骤

阶段 E 中涉及的详细程度将取决于整体架构工作的范围和目标。
阶段E中步骤的顺序以及正式开始和完成的时间应适应根据既定的架构治理情况。
在这些步骤中启动的所有活动必须在创建架构路线图和实施和迁移计划步骤

阶段E的步骤如下：

确定/确认关键公司变更属性
确定实现的业务约束
审查并合并从阶段B到D的差距分析结果
查看相关业务职能的合并需求
合并和协调互操作性要求
优化和验证依赖项
确认业务转型的准备情况和风险
制定实施和迁移策略
标识和分组主要工作包
识别转换体系结构
创建架构路线图、实现和迁移计划

1、确定/确认关键企业变更属性

此步骤确定如何最好地实施企业架构以利用组织的业务文化。这应该包括创建实施因素目录作为架构实施和迁移决策的存储库。该步骤还包括对所涉组织单位的过渡能力（包括文化和能力）的评估，以及对企业的评估（包括文化和技能组合）。

评估产生的因素应记录在实施因素目录中。适用于以下组织：企业架构已经建立起来，这一步可能很简单，但必须建立矩阵才能使用它作为所做决定的档案和记录。

2 、确定实现的业务约束

确定任何会限制实施顺序的业务驱动因素。这应该包括对业务的审查和战略计划，在公司和业务线级别，以及对企业架构成熟度的审查评估。

3、审查和巩固B至D阶段的差距分析结果

整合和集成来自业务、信息系统和技术架构（已创建）的差距分析结果在阶段B至D）中，并评估其对潜在解决方案和相互依存关系的影响。这应该由创建一个合并的差距、解决方案和依赖关系矩阵，它将能够识别可能解决一个或多个差距的 SBB，以及他们相关的ABB。

SBB 是根据阶段 B、C 和 D 中的候选路线图组件创建的。

如果适用，调查不同的目标体系结构替代方案，并使用架构替代方案和权衡技术

查看 B、C 和 D 阶段差距分析结果，并将其合并到单个列表中。差距应沿与差距和依赖关系的潜在解决方案。确定依赖关系的推荐方法是使用视图，例如业务交互矩阵、数据实体/业务功能矩阵和应用程序/功能矩阵完全关联来自不同架构域的元素。

合理化合并的差距、解决方案和依赖关系矩阵。记录所有差距后，重新组织差距列表并将类似的项目放在一起。对差距进行分组时，请参阅实施因素目录并查看实施因素。任何其他因素都应添加到实施因素目录中。

4、审查相关业务职能的合并需求

评估需求、差距、解决方案和因素，以确定将其集成到工作中的最低需求集包将导致跨业务功能更高效、更有效地实施目标体系结构，从而正在参与架构。这种功能视角导致通过提供共享解决方案和服务。这种合并要求对建筑的影响在提供资源方面，组件可能很重要。例如，几行提出的几个要求的业务可以通过在工作中提供一组共享的业务服务和应用程序服务来解决包或项目。

5、整合和协调互操作性需求

整合前面阶段确定的互操作性要求。架构愿景和目标架构，以及实施因素目录和综合差距、解决方案和依赖关系矩阵，应予以合并，并且审查以确定潜在解决方案集所需的互操作性的任何限制。

关键结果是最大程度地减少互操作性冲突，或确保在体系结构中解决此类冲突。重复使用 SBB、商用现货（COTS）产品和第三方服务提供商通常会提出互操作性要求那个冲突。任何此类冲突都必须在体系结构中解决，并且必须在所有体系结构中考虑冲突领域（业务、数据、应用程序、技术）。

互操作性冲突有两种基本方法;创建转换或转换的构建基块在冲突的构建基块之间，或更改冲突的构建基块的规范。

6、优化和验证依赖关系

优化初始依赖项，确保确定对实施和迁移计划的任何约束。那里是应该考虑的几个关键依赖关系，例如对现有业务实现的依赖关系服务和应用程序服务或对它们的更改。应使用依赖项来确定实现顺序并确定所需的协调。对依赖关系的研究应将活动分组在一起，为以下方面奠定基础：待建立的项目。检查相关项目，看看是否可以识别可交付成果的逻辑增量。这依赖关系还有助于确定何时可以交付已识别的增量。完成后，对这些进行评估依赖项应记录为体系结构路线图和任何必要的过渡体系结构的一部分。

解决依赖项是大多数迁移规划的基础。

7、确认业务转型的准备情况和风险

查看之前在 A 阶段进行的业务转型准备评估的结果，并确定其对架构路线图以及实施和迁移策略的影响。识别、分类和降低与转型工作相关的风险。风险应记录在综合差距、解决方案和依赖项矩阵。

8、制定实施和迁移策略

创建指导目标体系结构实施的整体实施和迁移策略，以及构建任何过渡架构。第一项活动是确定执行《公约》的总体战略办法。解决方案和/或利用机会。有三种基本方法如下：

绿地：全新的实现
革命性：彻底的改变（即打开，关闭）
渐进式：融合策略，例如并行运行或引入新功能的分阶段方法

接下来，确定总体战略方向的方法，以解决和减轻合并的差距、解决方案和依赖关系矩阵。最常见的实施方法是：

速赢（快照）
可实现的目标
价值链方法

这些方法和确定的依赖关系应成为创建工作包的基础。此活动在就企业的实施和迁移策略达成一致后终止。

9、识别和分组主要工作包

关键利益相关者、规划人员和企业架构师应评估架构愿景和目标架构。

将“合并差距、解决方案和依赖关系”矩阵与“实施因素”目录一起使用，对逻辑进行分组将各种活动纳入工作包。

填写“合并差距、解决方案和依赖关系”矩阵中的“解决方案”列，以推荐建议的解决方案机制。为每个差距/活动指出解决方案是应面向新的发展，还是基于一个现有产品和/或使用可以购买的解决方案。现有系统可以通过次要解决要求增强。对于新的开发项目，现在是确定工作应该在内部进行还是通过合同。

将正在考虑的每个当前系统分类为：

主流：未来信息系统的一部分
包含：预计在规划范围内将被替换或修改（未来三年）
替换：在计划区间内替换

然后，应将支持顶级工作包分解为增量，以提供功能增量。分析和完善这些工作包或增量，以解决其业务转型问题和战略问题实施方法。最后，将工作包分组到项目组合和项目组合中的项目组合中，包括考虑依赖关系和战略实施方法。

10 、识别转换架构

如果实现目标体系结构的更改范围需要增量方法，则一个或多个转换架构可能是必要的。这些提供了沿着路线图确定明确目标的能力，以实现目标建筑。过渡架构应提供可衡量的业务价值。连续转换之间的时间跨度体系结构不必具有统一的持续时间。

过渡架构的开发必须基于首选的实施方法，即综合差距，解决方案和依赖关系矩阵，项目和项目组合的列表，以及企业的创建和能力吸收变化。

确定困难的活动在哪里，除非有令人信服的理由，否则在其他活动之后实施它们最容易提供缺失的功能。

11、创建架构路线图、实现和迁移计划

将工作包和过渡架构整合到架构路线图草案中，该路线图描述了从基线体系结构到目标体系结构的进度。时间表通知实施和迁移计划。架构路线图在阶段 F 中构建了迁移规划。确定的过渡架构和工作包应该有一套明确的结果。架构路线图必须展示过渡的选择和时间表架构和工作包实现了目标架构。

架构路线图草案的细节应以与架构定义类似的详细程度表达在阶段 B、C 和 D 中开发的文档。如果在实施之前需要重要的额外细节，则体系结构是可能过渡到不同的水平。以获取管理迭代和不同细节级别的技术。

实施和迁移计划必须展示实现架构路线图所需的活动。这实施和迁移计划构成了阶段 F 中迁移计划的基础。实施的细节和迁移计划、草稿必须与架构路线图的细节保持一致，并足以确定必要的实现路线图的项目和资源需求。

创建实施和迁移计划时，需要考虑许多方法，例如数据驱动的序列，其中首先实现创建数据的应用程序系统，然后实现处理数据的应用程序。清楚地了解就地 SBB 的依赖项和生命周期是有效的实施和迁移计划所必需的。

最后，使用任何更新架构愿景、架构定义文档和架构需求规范此阶段的其他相关结果。

四、输出

阶段E的输出可能包括但不限于：

架构愿景阶段可交付成果的改进和更新版本（如适用），包括：
- 架构愿景，包括类型和互操作性程度的定义
- 架构工作声明，必要时更新
架构定义文档草案，包括：
- 基线业务架构，已批准，必要时更新
- 目标业务架构，已批准，必要时更新
- 基线数据体系结构，已批准，必要时更新
- 目标数据体系结构，已批准，必要时更新
- 基线应用程序体系结构，已批准，必要时更新
- 目标应用程序体系结构，已批准，必要时更新
- 基线技术体系结构，已批准，必要时更新
- 目标技术体系结构，已批准，必要时更新
- 根据需要过渡架构、数量和范围
- 与解决主要利益攸关方关切的选定观点相对应的观点
架构需求规范草案，包括：
- 合并差距、解决方案和依赖关系评估
能力评估，包括：
- 业务能力评估
- 资讯科技能力评估
架构路线图，包括：
- 工作包组合：
  - 工作包描述（名称、描述、目标）
  - 功能要求
  - 依赖
  - 与机会的关系
  - 与体系结构定义文档和体系结构需求规范的关系
  - 与任何功能增量的关系
  - 商业价值
  - 实施因素目录
  - 冲击
- 识别过渡架构（如果有），包括：
  - 与体系结构定义文档的关系
- 实施建议：
  - 有效性的标准衡量标准
  - 风险和问题
  - 解决方案构建基块（SBB）
实施和迁移计划，草案，包括：
- 实施和迁移策略