本章提供了ADM中引用的可交付成果的描述。
4.1 介绍
本章定义了在TOGAF ADM周期中通常会消耗和产生的可交付成果。由于可交付成果通常是架构项目的合同或正式工作产品，因此这些可交付成果很可能会受到企业任何总体项目或过程管理（如CMMI®、PRINCE2®、PMBOK®或MSP®）的限制或改变。
因此，本章旨在提供架构交付成果的典型基线，以便更好地定义ADM中所需的活动，并作为在特定组织内进行定制的起点。TOGAF内容框架（见第1章）确定了作为执行ADM周期的输出而产生的可交付成果，并可能在ADM的其他点作为输入而消耗。其他可交付成果可能在其他地方产生并由ADM消耗。执行ADM产生的可交付成果如下表所示。
4.2 可交付成果描述
以下部分提供了ADM中引用的可交付成果的示例描述。
请注意，并非这里描述的所有内容都需要包含在特定的可交付成果中。相反，建议在可能的情况下使用外部参考；例如，不应将业务的战略计划复制到架构工作请求中，而应引用战略计划的标题。
此外，不建议严格遵守这些描述。然而，每个要素都应该仔细考虑；忽略任何输入或输出项都可能导致下游出现问题。
4.2.1 架构构建块
4.2.2 架构合同
目的，架构合同是开发合作伙伴和赞助商之间就架构的可交付成果、质量和适用性达成的联合协议。这些协议的成功实施将通过有效的架构治理来实现（见TOGAF标准——企业架构能力和治理）。通过实施受控的合同管理方法，将确保以下内容：
- 一个持续监控系统，用于检查组织内所有架构相关活动的完整性、变更、决策和审计
- 遵守现有或正在开发的架构的原则、标准和要求
- 识别架构开发和实施的各个方面的风险，包括根据公认的标准、政策、技术和产品进行内部开发，以及架构的运营方面，以便组织能够在有弹性的环境中继续开展业务
- 一套流程和实践，确保所有架构工件的开发和使用的问责制、责任和纪律
- 对负责合同的治理组织、其权限级别以及该机构治理下的架构范围的正式理解内容
架构设计和开发合同的典型内容包括：
业务用户架构合同的典型内容包括：
有关架构契约使用的更多详细信息，请参阅TOGAF标准——企业架构能力和治理。
4.2.3 架构定义文档
目的，架构定义文档是项目期间创建的核心架构工件和重要相关信息的可交付容器。架构定义文档涵盖了所有架构领域（业务、数据、应用程序和技术），并检查了架构的所有相关状态（基线、过渡和目标）。
过渡架构显示了企业处于基线架构和目标架构之间的架构重要状态。过渡架构用于描述有效实现目标架构所需的过渡目标架构。
架构定义文档的典型内容包括：
4.2.4 架构原理
目的，原则是一般规则和指导方针，旨在持久且很少修改，为组织履行使命的方式提供信息和支持。反过来，原则可能只是一套结构化思想中的一个要素，这些思想共同定义和指导着组织，从价值观到行动和结果。
内容，有关指南和一套详细的通用架构原则，请参阅TOGAF标准-ADM技术，包括：
- 业务原则（见TOGAF标准-ADM技术）
- 数据原则（见TOGAF标准-ADM技术）
- 应用原则（见TOGAF标准-ADM技术）
- 技术原理（见TOGAF标准-ADM技术）
4.2.5 架构存储库
目的，架构存储库充当企业内所有架构相关项目的存储区。该存储库允许项目管理其可交付成果，定位可重用资产，并将输出发布给利益相关者和其他利益相关方。
内容，有关架构存储库内容的详细说明，请参阅第7章。
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。为架构制定沟通计划，允许在计划和管理的过程中进行沟通。
内容，沟通计划的典型内容包括：
- 确定利益相关者并按沟通要求分组
- 识别通信需求、与架构愿景相关的关键信息、通信风险和CSF
- 确定将用于与利益相关者沟通并允许访问架构信息的机制，如会议、通讯、存储库等。
- 确定沟通时间表，显示将在何时何地与哪些利益相关者群体进行哪些沟通
4.2.13 合规性评估
目的，一旦定义了架构，就有必要通过实施来管理该架构，以确保适当实现原始架构愿景，并将任何实施学习反馈到架构过程中。对实施项目的定期合规性审查提供了一种审查项目进度的机制，并确保设计和实施符合战略和架构目标。
内容，合规性评估的典型内容包括：
■ 项目进展和状态概述
■ 项目架构/设计概述
■ 已完成的架构检查表：
— 硬件和操作系统检查表
— 软件服务和中间件检查表
— 应用程序检查表
— 信息管理检查表
— 安全检查表
— 系统管理检查表
— 系统工程检查表
— 方法和工具清单
4.2.14 实施和迁移计划
目的，实施和迁移计划提供了实现目标架构的项目时间表。实施和迁移计划包括可执行项目，这些项目分为受管理的项目组合和项目群。确定变革方法的实施和迁移战略是实施和迁移计划的关键要素。
内容，实施和迁移计划的典型内容包括：
■ 实施和迁移策略：
— 战略实施方向
— 实施排序方法
■ 项目和项目组合实施细分：
— 将工作包分配给项目和项目组合
— 项目交付的能力
— 里程碑和时间安排
— 工作分解结构
— 可能包括对现有投资组合、计划和项目的影响。它可能包括：
■ 项目章程：
— 包括工作包
— 商业价值
— 风险、问题、假设、依赖关系
— 所需资源和费用
— 确定迁移的好处（包括映射到业务需求）
— 迁移方案的估计成本
4.2.15 实施治理模型
目的，一旦定义了架构，就有必要计划如何通过实现来管理实现该架构的过渡架构。在已经建立架构功能的组织中，可能已经有了一个治理框架，但可能需要逐个项目地定义具体的流程、组织、角色、职责和措施。实施治理模型确保过渡到实施的项目也能顺利过渡到适当的架构治理。
内容，实施治理模型的典型内容包括：
- 治理流程
- 治理组织结构
- 治理角色和责任
- 治理检查点和成功/失败标准
4.2.16 企业架构的组织模型
目的，为了成功使用架构框架，它必须得到企业内正确的组织、角色和职责的支持。特别重要的是定义不同企业架构从业者之间的界限以及跨越这些界限的治理关系。
内容，企业架构组织模型的典型内容包括：
■ 受影响组织的范围
■ 成熟度评估、差距和解决方法
■ 架构团队的角色和职责
■ 建筑工作的限制
■ 所需预算
■ 治理和支持战略
4.2.17 架构工程申请
目的，这是一份从赞助组织发送给架构组织的文档，用于触发架构开发周期的开始。架构工作请求可以，作为初步阶段的输出、批准的架构变更请求的结果或源于迁移规划的架构工作的职权范围而创建。一般来说，本文档中的所有信息都应该是高层次的。
内容，建筑工作请求通常包括：
- 组织赞助商
- 组织的使命宣言
- 业务目标（和变化）
- 企业战略计划
- 时间限制
- 商业环境的变化
- 组织约束
- 预算信息、财务限制
- 外部约束、业务约束
- 当前业务系统描述
- 当前架构/IT系统描述
- 开发组织描述
- 开发组织可用资源的描述
4.2.18 需求影响评估
目的，在整个ADM中，收集与架构相关的新信息。随着这些信息的收集，可能会发现新的事实，使架构的现有方面无效。需求影响评估评估当前的架构需求和规范，以确定应进行的更改以及这些更改的影响。
内容，需求影响评估的典型内容包括：
- 参考具体要求
- 迄今为止，利益相关者对需求的优先级
- 需重新审视的阶段
需求优先级领导阶段
- 阶段调查结果和修订后的优先事项
- 需求管理建议
- 存储库参考号
4.2.19 解决方案构建块
来自企业架构库的特定于实施的构建块；见第5章。
4.2.20 架构工程说明书
目的，架构工作说明书定义了用于完成架构开发周期的范围和方法。架构工作说明书通常是衡量架构项目成功执行的文件，可能构成架构服务供应商和消费者之间合同协议的基础。
内容，架构工作说明书的典型内容包括：
4.2.21 量身定制的架构框架
目的，TOGAF框架为架构提供了一个行业标准，可用于各种组织。然而，在TOGAF框架在架构项目中有效使用之前，有必要在两个层面进行定制。
首先，有必要定制TOGAF模型以集成到企业中。这种定制将包括与管理框架的集成、术语的定制、表示风格的开发、架构工具的选择、配置和部署等。所采用的任何框架的形式和细节也应与企业的其他背景因素保持一致，如文化、利益相关者、企业架构的商业模式以及现有的架构能力水平。
一旦框架针对企业量身定制，就需要进一步定制，以便为特定的架构项目量身定制框架。在此级
别进行定制将选择适当的可交付成果和工件，以满足项目和利益相关者的需求。
有关选择和定制架构框架时的进一步考虑，请参阅TOGAF标准——架构开发方法。
内容，定制架构框架的典型内容包括：
■ 量身定制的架构方法
■ 量身定制的架构内容（可交付成果和工件）
■ 已配置和部署的工具
■ 与治理模型和其他框架的接口：
— 企业业务规划
— 企业架构
— 投资组合、项目群、项目管理
— 系统开发/工程
— 运营（服务）
