4.1 引言

本章定义了通常在 TOGAF ADM 周期中使用和生成的可交付成果。作为可交付成果 通常是架构项目的合同或正式工作产品，这些可交付成果很可能是 受企业的任何总体项目或流程管理（如CMMI，® PRINCE2®，PMBOK®或）的约束或更改 MSP®）。

因此，本章旨在提供架构可交付成果的典型基线，以便更好地定义 ADM 中所需的活动，并作为特定组织内定制工作的起点。

TOGAF 内容框架标识可交付成果 作为执行 ADM 周期的输出生成，并可能作为 ADM 中其他点的输入使用。其他可交付成果 可在其他地方生产并由 ADM 消费。

通过执行 ADM 产生的可交付成果如下表所示：

4.2 可交付成果描述

以下各节提供了 ADM 中引用的可交付成果的示例描述。

请注意，并非此处描述的所有内容都需要包含在特定的可交付成果中。相反，它是 建议尽可能使用外部参考;例如，不应复制企业的战略计划 进入架构工作请求，但应参考战略计划的标题。

此外，不建议一字不提地遵循这些描述。但是，每个元素都应该是 仔细考虑;忽略任何输入或输出项可能会导致下游出现问题。

4.2.1 架构构建块

来自企业架构存储库的架构文档和模型。

构建基块具有以下通用特征：

• 构建基块是为满足整个组织的业务需求而定义的功能包
• 构建基块通常具有与元模型对应的类型（例如参与者、业务服务、应用程序或数据） 实体）
• 构建块具有定义的边界，通常可被领域专家识别为“事物”
• 构建基块可以与其他相互依赖的构建基块互操作。
• 一个好的构建块具有以下特征：
  • 它考虑实施和使用，并不断发展以利用技术和标准
  • 它可以由其他构建块组装而成
  • 它可能是其他构建块的子组件
  • 理想情况下，构建块是可重用和可替换的，并且指定良好

构建块的边界和规范应该与其实现松散地耦合；即应该能够以几种不同的方式实现构建块而不影响构建块的边界或规格。资产和功能组装成构建块的方式在各个体系结构之间会有很大差异。每个组织都必须自己决定什么样的构建块安排最适合自己。选择好的构建块可以改善遗留系统的集成、互操作性以及创建新系统和应用程序的灵活性。
系统是由构建块集合构建的，因此大多数构建块必须与其他构建块进行互操作。无论在什么情况下，发布构建块的接口并保持合理的稳定是很重要的。
构建块可以在不同的细节级别进行定义，这取决于已经达到的体系结构开发阶段。
例如，在早期阶段，构建块可以简单地由名称或大纲描述组成。稍后，一个构建块可以分解为多个支撑构建块，并可以附带完整的规范。
应指定构建块的详细程度取决于体系结构的目标，在某些情况下，较少的细节可能具有更大的价值（例如，当展示企业的能力时，一张清晰简洁的图片比密集的100页规范更有价值）。

4.2.2 架构契约

目的

架构合同是开发合作伙伴和赞助商之间关于可交付成果的联合协议， 建筑的质量和适用性。这些协议的成功实施将通过 有效的架构治理。通过实施受管理的合同管理方法，将确保以下内容：

• 一个持续监控系统，以检查完整性、变更、决策和审计 组织内与架构相关的活动
• 遵守现有或开发中的体系结构的原则、标准和要求
• 识别架构开发和实施各个方面的风险，涵盖 根据公认的标准、政策、技术和产品以及 体系结构，使组织可以在弹性环境中继续其业务
• 一套流程和实践，确保问责制、责任感和纪律 所有建筑工件的开发和使用
• 正式了解负责合同的治理组织、其权限级别，以及 本机构治理下的架构范围

内容

架构设计和开发合同的典型内容是：

• 导言和背景
• 协议的性质
• 体系结构的范围
• 体系结构和战略原则和要求
• 一致性要求
• 架构开发和管理流程和角色
• 目标体系结构度量值
• 可交付成果的定义阶段
• 按优先次序排列的联合工作计划
• 时间窗口
• 架构交付和业务指标

业务用户架构合同的典型内容是：

• 导言和背景
• 协议的性质
• 范围
• 战略要求
• 一致性要求
• 架构采用者
• 时间窗口
• 架构业务指标
• 服务体系结构（包括服务级别协议 （SLA））

4.2.3 架构定义文档

目的

体系结构定义文档是创建的核心体系结构工件的可交付结果容器 在项目期间和重要的相关信息。架构定义文档涵盖所有架构领域 （业务、数据、应用程序和技术），并检查体系结构的所有相关状态（基线、转换和 目标）。

过渡体系结构显示企业在基线和基线之间具有体系结构重要性的状态 目标体系结构。过渡体系结构用于描述有效所需的过渡目标体系结构 实现目标架构。

架构定义文档是架构需求规范的配套文档，具有 互补目标：

• 体系结构定义文档提供了解决方案的定性视图，旨在传达 建筑师的意图
• 体系结构需求规范提供了解决方案的定量视图，指出可衡量 在体系结构实施过程中必须满足的标准

内容

体系结构定义文档的典型内容包括：

• 范围
• 目标、目的和约束
• 架构原则
• 基线体系结构
• 架构模型（对于要建模的每个状态）：
  • 业务架构模型
  • 数据架构模型
  • 应用程序架构模型
  • 技术架构模型
• 架构方法的基本原理和理由
• 映射到架构存储库：
  • 映射到建筑景观
  • 映射到参考模型
  • 映射到标准
  • 再利用评估
• 差距分析
• 影响评估
• 过渡架构：
  • 过渡态的定义
  • 每个转换状态的业务架构
  • 每个转换状态的数据体系结构
  • 每个转换状态的应用程序体系结构
  • 每个转换状态的技术体系结构

4.2.4 架构原理

目的

原则是一般规则和准则，旨在持久且很少修订，提供信息和支持 一个组织着手完成其使命的方式。

反过来，原则可能只是共同定义和指导的一套结构化思想中的一个要素。 组织，从价值观到行动和结果。

通用架构原则，包括：

• 业务原则
• 数据原则
• 应用原则
• 技术原则

4.2.5 架构存储库

目的

架构存储库充当企业内所有与架构相关的项目的存放区域。这 存储库允许项目管理其可交付成果，定位可重用资产，并将输出发布给项目相关者和其他 有意。

4.2.6 架构需求规范

目的

架构需求规范提供了一组定量陈述，概述了什么是 实施项目必须做到符合架构。架构需求规范通常会 形成实施协定或协定的主要组件，以获得更详细的体系结构定义。

如上所述，架构需求规范是架构定义的配套产品 文件，具有补充目标：

• 体系结构定义文档提供了解决方案的定性视图，旨在传达 建筑师的意图
• 体系结构需求规范提供了解决方案的定量视图，指出可衡量 在体系结构实施过程中必须满足的标准

内容

架构需求规范的典型内容是：

• 成功措施
• 体系结构要求
• 业务服务合同
• 应用程序服务合同
• 实施准则
• 实施规范
• 实施标准
• 互操作性要求
• IT 服务管理要求
• 约束
• 假设

4.2.7 架构路线图

目的

架构路线图列出了将实现目标架构的各个工作包并对其进行布局 以显示从基线体系结构到目标体系结构的进度。架构路线图亮点 每个阶段的单个工作包的业务价值。有效实现目标所需的过渡架构 体系结构被标识为中间步骤。架构路线图在整个阶段 E 和 F 中逐步开发， 并通过 ADM 中阶段 B、C 和 D 中易于识别的路线图组件提供信息。

内容

架构路线图的典型内容是：

• 工作包组合：
  • 工作包描述（名称、描述、目标、可交付成果）
  • 功能要求
  • 依赖
  • 与机会的关系
  • 与体系结构定义文档和体系结构需求规范的关系
  • 商业价值
• 实施因素目录，包括：
  • 风险
  • 问题
  • 假设
  • 依赖
  • 行动
  • 输入
• 合并的差距、解决方案和依赖关系矩阵，包括：
  • 架构领域
  • 差距
  • 潜在解决方案
  • 依赖
• 任何过渡体系结构
• 实施建议：
  • 衡量项目有效性的标准
  • 风险和问题
  • 解决方案构建基块

4.2.8 架构愿景

目的

架构愿景是在 ADM 周期的早期创建的。它提供了对 成功部署目标体系结构后将产生的企业。架构愿景的目的是 为关键利益相关者提供正式商定的结果。尽早就结果达成一致，使建筑师能够专注于 验证可行性所需的详细信息。提供架构愿景还通过提供 完整体系结构定义的摘要版本。

内容

架构愿景的典型内容是：

• 问题描述：
  • 利益相关者及其关注的问题
  • 要解决的问题/方案列表
• 建筑工作声明的目标
• 架构工作请求和业务、数据、应用程序草案和 创建技术架构;通常包括：
  • 价值链图
  • 解决方案概念图
• 映射要求
• 参考体系结构定义文档草案

4.2.9 业务原则、业务目标和业务驱动因素

目的

业务原则、业务目标和业务驱动因素通过描述 企业采用的需求和工作方式。许多不在架构学科考虑范围的因素 然而，可能对建筑的发展方式产生重大影响。

内容

体系结构的业务上下文的内容和结构可能因一个组织而异 到下一个。

4.2.10 能力评估

目的

在开始详细的体系结构定义之前，了解基线和目标很有价值 企业的能力水平。这种能力评估可以在几个层面上进行检查：

• 整个企业的能力水平如何？企业希望在哪里增加或优化 能力？哪些架构重点领域将支持企业的期望发展？
• 企业内 IT 职能的能力或成熟度如何？可能有哪些 在设计治理、运营治理、技能和组织方面开展架构项目的影响 结构？什么是适合架构项目的风格、形式水平和细节量，以适应 IT 组织的文化和能力？
• 企业内架构功能的能力和成熟度如何？哪些建筑资产 目前存在吗？它们是否得到维护和准确？需要考虑哪些标准和参考模型？有吗 可能是在架构项目期间创建可重用资产的机会？
• 如果存在能力差距，企业准备在多大程度上进行转型以实现目标 能力？转型面临哪些风险、文化障碍以及除基本内容之外需要解决的其他考虑因素 能力差距？

内容

能力评估的典型内容是：

• 业务能力评估，包括：
  • 业务能力
  • 每个功能的性能级别的基线状态评估
  • 每个功能的性能级别的未来状态期望
  • 如何实现每种功能的基线状态评估
  • 未来状态对如何实现每种能力的期望
  • 评估成功部署目标对业务组织可能产生的影响 建筑
• IT 能力评估，包括：
  • 变更过程的基线和目标成熟度级别
  • 操作流程的基线和目标成熟度级别
  • 基线能力和能力评估
  • 评估成功部署目标对 IT 组织可能产生的影响 建筑
• 架构成熟度评估，包括：
  • 架构 治理流程、组织、角色和职责
  • 架构技能评估
  • 使用架构存储库确定景观定义的广度、深度和质量
  • 使用架构存储库定义标准的广度、深度和质量
  • 使用架构存储库定义参考模型的广度、深度和质量
  • 再利用潜力评估
• 业务转型准备情况评估，包括：
  • 准备因素
  • 每个就绪因素的愿景
  • 当前和目标就绪评级
  • 准备风险

4.2.11 变更请求

目的

在架构的实现过程中，随着更多事实的了解，原始架构可能会 定义和要求不适合或不足以完成解决方案的实现。在这些 在这种情况下，实施项目必须偏离建议的体系结构方法或 请求范围扩展。此外，外部因素 - 如市场因素，业务战略的变化和新技术 机会 — 可能为扩展和完善体系结构提供机会。

在这些情况下，可以提交变更请求，以启动进一步的架构周期 工作。

内容

变更请求的典型内容包括：

• 拟议更改的说明
• 拟议修改的理由
• 对拟议变更的影响评估，包括：
  • 参考具体要求
  • 迄今为止各项要求的利益攸关方优先次序
  • 需要重新审视的阶段
  • 引导需求优先级的阶段
  • 阶段调查的结果和订正的优先事项
  • 关于所需资源管理的建议
• 存储库参考编号

4.2.12 沟通计划

目的

企业架构包含大量复杂且相互依赖的信息。有效沟通 在正确的时间向正确的利益相关者提供有针对性的信息是企业架构的 CSF。开发 体系结构的通信计划允许在规划和管理的过程中执行此通信。

内容

沟通计划的典型内容是：

• 确定利益相关者并按通信要求进行分组
• 识别沟通需求，与架构愿景有关的关键信息，沟通风险， 和脑脊液
• 确定将用于与利益相关者沟通并允许访问架构的机制 信息，例如会议、新闻稿、存储库等。
• 确定沟通时间表，显示将与哪些利益相关者进行哪些沟通 在什么时间和什么位置分组

4.2.13 合规性评估

目的

一旦定义了架构，就必须通过实现来管理该架构，以确保 原始架构愿景得到适当实现，并且任何实施学习都反馈到 架构过程。对实施项目的定期遵守情况审查提供了一种机制来审查项目进度和 确保设计和实施符合战略和架构目标。

内容

合规性评估的典型内容是：

• 项目进度和状态概述
• 项目架构/设计概述
• 已完成的架构清单：
  • 硬件和操作系统清单
  • 软件服务和中间件清单
  • 应用清单
  • 信息管理清单
  • 安全检查表
  • 系统管理清单
  • 系统工程清单
  • 方法和工具清单

4.2.14 实施和迁移计划

目的

实施和迁移计划提供了将实现目标的项目时间表 建筑。实施和迁移计划包括分组到托管项目组合和计划的可执行项目。这 实施和迁移策略 确定变革方法是实施和迁移的关键要素 计划。

内容

实施和迁移计划的典型内容包括：

• 实施和迁移策略：
  • 战略执行方向
  • 实施排序方法
• 实施的项目和项目组合细分：
  • 将工作包分配给项目和项目组合
  • 项目交付的功能
  • 里程碑和时间安排
  • 工作分解结构
  • 可能包括对现有项目组合、计划和项目的影响

它可能包含：

• 项目章程：
  • 包含的工作包
  • 商业价值
  • 风险、问题、假设、依赖关系
  • 所需资源和费用
  • 确定迁移的好处（包括映射到业务需求）
  • 迁移选项的估计成本

4.2.15 实施治理模型

目的

定义架构后，有必要规划如何实现 架构将通过实施进行管理。在已建立架构功能的组织中，有 可能是已经到位的治理框架，但特定的流程、组织、角色、责任和措施 可能需要逐个项目进行定义。

实施治理模型确保项目过渡到实施也顺利进行 过渡到适当的架构治理。

内容

实施治理模型的典型内容包括：

• 治理流程
• 治理组织结构
• 治理角色和职责
• 治理检查点和成功/失败标准

4.2.16 企业架构的组织模型

目的

为了使架构框架成功使用，它必须得到正确的组织的支持， 企业内的角色和职责。特别重要的是定义不同之间的边界 企业架构从业者和跨越这些边界的治理关系。

内容

企业架构组织模型的典型内容是：

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

4.2.17 建筑工作请求

目的

这是从赞助组织发送到架构组织以触发 开始架构开发周期。架构工作请求可以创建为初步阶段的输出，即 批准的体系结构更改请求的结果，或源自迁移的体系结构工作的职权范围 规划。

通常，本文档中的所有信息都应处于高级别。

内容

对架构工作的要求通常包括：

• 组织赞助商
• 组织的使命宣言
• 业务目标（和变更）
• 业务战略计划
• 时间限制
• 商业环境的变化
• 组织约束
• 预算信息，财务限制
• 外部约束、业务约束
• 当前业务系统说明
• 当前架构/IT 系统说明
• 发展组织描述
• 开发中组织可用的资源描述

4.2.18 需求影响评估

目的

在整个 ADM 中，收集与体系结构相关的新信息。随着此信息的收集，新的 事实可能会暴露出来，使体系结构的现有方面无效。需求影响评估评估当前 体系结构要求和规范，用于标识应进行的更改以及这些更改的含义。

内容

需求影响评估的典型内容是：

• 参考具体要求
• 迄今为止各项要求的利益攸关方优先次序
• 需要重新审视的阶段
• 引导需求优先级的阶段
• 阶段调查的结果和订正的优先事项
• 关于所需资源管理的建议
• 存储库参考编号

4.2.19 解决方案构建块

来自企业架构存储库的特定于实施的构建块;

识别构建基块的过程包括查找与构建基块交互的功能或资产的集合 另一个，然后将它们拉在一起或使它们不同：

• 考虑三类构建基块：
  • 可重复使用的构建基块，例如旧项
  • 构建块作为开发主题，例如新应用程序
  • 作为购买标的的积木;即商业现货 （COTS） 应用
• 使用所需的集成级别将功能绑定或组合到构建块中;例如，遗留元素可以是 被视为大型构建块，以避免将它们分开

在最高级别企业的早期阶段和视图期间，构建块通常保持广泛集成 定义。正是在这些练习中，通常可以最好地查看服务定义。作为实现注意事项 得到解决，构建块的更详细视图通常可用于解决实施决策，重点关注关键 战略决策，或帮助评估通用性和可重用性的价值和未来影响。

4.2.20 建筑工作说明

目的

架构工作声明定义了用于完成架构的范围和方法 开发周期。架构工作声明通常是成功执行 建筑项目将被测量，并可能构成供应商和消费者之间合同协议的基础 架构服务。

内容

建筑工作声明的典型内容是：

• 标题
• 架构项目请求和背景
• 架构项目描述和范围
• 架构愿景概述
• 具体范围变更程序
• 角色、职责和可交付成果
• 验收标准和程序
• 建筑项目计划和时间表
• 批准

4.2.21 定制架构框架

目的

TOGAF 框架为架构提供了一个行业标准，可用于各种 组织。但是，在 TOGAF 框架可以在架构项目中有效使用之前，在两个级别进行定制 是必要的。

首先，有必要定制 TOGAF 模型以集成到企业中。此剪裁将包括 与管理框架集成，术语定制，表现风格的开发，选择， 架构工具的配置和部署等。所采用的任何框架的形式和细节也应符合 企业的其他背景因素，例如文化、利益相关者、企业架构的商业模式以及 现有级别的架构能力。

一旦框架为企业量身定制，就需要进一步定制以定制 特定体系结构项目的框架。此级别的定制将选择适当的可交付成果和工件来满足 项目和利益相关者的需求。

内容

定制架构框架的典型内容是：

• 量身定制的架构方法
• 定制的架构内容（可交付成果和工件）
• 已配置和部署的工具
• 与治理模型和其他框架的接口：
  • 企业业务规划
  • 企业架构
  • 项目组合、项目群、项目管理
  • 系统开发/工程
  • 运营（服务）