TOGAF架构内容框架之架构交付物

TOGAF架构内容框架之架构交付物

3. 架构交付物（Architecture Deliverables）

      架构交付物是在整个架构开发方法循环过程中所产生或被使用的契约性且正规化的企业架构内容，因而其与企业架构开发方法有着紧密的联系。本章将针对这些架构交付物以及他们与架构开发方法各阶段之间的关系进行阐述，不过需要注意的是，本章节的内容只是为了提供一个关于架构交付物的内容概括，由于企业中可能存在着符合其自身需要的项目和过程管理方法，因而企业也可以根据自己的实际情况对这些交付物进行改造和定制。首先，我们先来审视一下架构交付物与企业架构开发方法各阶段之间的对应关系（注意，下表采用了简称来标示各企业架构开发方法阶段，具体的对应关系请参照前面企业架构开发方法部分的内容和图示）：

架构交付物	作为输出的阶段	作为输入的阶段
架构构建块 （Architecture Building Blocks）	F，H	A，B，C，D
架构合同 （Architecture Contract）	F	G
架构定义文档 （Architecture Definition Document）	B，C，D	C，D，E，F，G，H
架构原则 （Architecture Principles）	预备阶段，A， B，C，D	预备阶段，A，B，C，D，E，F，G，H
架构资源库 （Architecture Repository）	预备阶段	预备阶段，A， B，C，D，E，F，G，H， 需求管理
架构需求 （Architecture Requirements）	B，C，D，E，F，需求管理	C，D，需求管理
架构路线图 （Architecture Roadmap）	B，C，D，E，F	C，D，E，F，G，H
架构愿景 （Architecture Vision）	A	B，C，D，E，F，G，H，需求管理
业务原则、目标和驱动力 （Business Principles,Business Goals,and Business Drivers）	预备阶段，A，B	A，B
能力评估 （Capability Assessment）	A，E	B，C，D，E，F
变更请求 （Change Request）	H
沟通计划 （Communications Plan）	A	B，C，D，E，F
合规评估 （Compliance Assessment）	G	H
实施和迁移计划 （Implementation and Migration Plan）	E，F	F
实施治理模型 （Implementation Governance Model）	F	G，H
企业组织架构模型 （Organizational Model for Enterprise Architecture）	预备阶段	预备阶段，A， B，C，D，E，F，G，H，需求管理
架构工作要求书 （Request for Architecture Wor k）	预备阶段，F	A，G
需求影响评估 （Requirements Impact Assessment）	H，需求管理	需求管理
解决方案构建块 （Solution Building Blocks）	G	A，B，C，D
架构工作说明书 （Statement of Architecture Work）	A，B，C，D	B，C，D，E，F，G，H，需求管理
定制的企业架构框架 （Tailored Architecture Framework）	预备阶段，A	预备阶段， A， B，C，D，E，F，G，H，需求管理
过渡架构 （Transition Architecture）	E，F	G，H

3.1 架构构建块

      构建块是企业架构过程的最终目标之一，它是企业对于各个层面上（业务、应用、数据以及技术等）的可重用部件的抽象。对于架构构建块来说，它的内容侧重于对构建块的需求进行描述，就像软件开发中的接口一样，架构构建块并不涉及具体的实现方式，而只是描述了构建块所需要达成的功能。用于描述架构构建块的文档和模型存储在企业架构资源库之中，而企业架构开发过程正是对企业中各种客观存在的或计划中的可重用模块进行抽象建模，并最终将这些内容存储到企业架构资源库之中（或对其内容进行更新）。关于架构构建块的具体内容在后面将会有更加详细的描述。

3.2 架构合同

3.2.1 目标

      架构合同是企业架构开发团队与赞助团队之间关于架构的交付、质量和适用性的联合协定，而为了成功实现这一协定则需要企业进行有效的架构治理。通过实现一个用于合同管理的治理方法，企业将会确保：

• 对组织中所有架构相关活动的完整性检查、变更、决策和审计进行持续监督的系统。
• 现存或正在开发的架构得以贯彻组织的原则、标准和需求。
• 明确架构在开发和实现的各个方面中的风险，这些方面涵盖了关于可接受的标准、策略、技术和产品的内部开发，以及架构的运营层面，从而使得组织可以在一个具有弹性的环境中继续其业务。
• 一系列流程和实践，用于确定关于所有架构制品的开发和使用的责任和规则。
• 对于为合同负责的治理组织、他们的权限级别以及在其治理之下的架构范围有一个正式的理解。

3.2.2 内容

• 架构设计和开发合同的内容一般包括：
• 介绍和背景
• 协议性质
• 架构范围
• 架构以及战略原则和需求
• 一致性需求
• 架构开发和管理流程，以及相关角色
• 目标架构评测标准
• 定义的交付阶段
• 按照优先级排序的联合工作计划
• 时间窗口（Time windows）
• 架构交付和业务指标
• 业务用户的架构合同一般包括：
• 介绍和背景
• 协议性质
• 范围
• 战略需求
• 一致性需求
• 架构采用者
• 时间窗口
• 架构业务指标
• 服务架构（包括服务水平协议（SLA：Service Level Agreement））

3.3 架构定义文档

3.3.1 目标

      架构定义文档是一个包含在整个项目中所产生的各种制品的可交付容器。它跨越所有的架构领域（业务、数据、应用和技术），并可用于检阅架构的所有相关状态（当前态、中间态和目标态）。架构定义文档对架构需求文档在如下方面进行互补：

• 架构定义文档提供了一个解决方案的定性视图，用于沟通架构师的意图。
• 架构需求说明提供了一个解决方案的定量视图，用于声明在架构实现过程中必须遵守的可测量的标准。

3.3.2 内容

      架构定义文档内容一般包括：

• 范围
• 目标、阶段目标和约束
• 架构原则
• 基线架构
• 架构模型（针对每个被建模的状态）：
• 业务架构模型
• 数据架构模型
• 应用架构模型
• 技术架构模型
• 架构方法的基本原理和理由
• 架构资源库内容映射：
• 架构情景映射
• 参考模型映射
• 标准映射
• 重用评估
• 差距分析结果
• 影响评估

3.4 架构原则

3.4.1 目标

      是通用的规则和指南，一般是不会进行更改的。这些原则知会并支持一个组织用以实现其任务的方法。它是用于定义和指导组织从价值到行为和结果的一系列结构化思路中的一员。

3.4.2 内容

     架构原则一般包括如下几个层面的内容（其具体内容请参看TOGAF标准相关内容）：

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

3.5 架构资源库

3.5.1 目标

      架构资源库在企业中充当了对于所有架构相关项目进行存储的区域。它允许各个项目管理他们的交付物，定位可重用资产，并对干系人以及其他有兴趣者进行信息发布。

3.5.2 内容

      架构资源库的内容包括如下几个方面（其具体内容请参看TOGAF标准相关内容）：

• 架构框架
• 标准信息库
• 架构情景
• 参考架构
• 治理日志

3.6 架构需求说明

3.6.1 目标

      架构需求说明提供了一组量化的描述，用于概括为了使一个项目的实现与架构相符合所必须做的事情。架构需求说明一般会形成一个实施契约，或是更详细的架构定义契约中的主要组件。

3.6.2 内容

      架构需求说明的内容通常包括：

• 成功评测标准
• 架构需求描述
• 业务服务契约
• 应用服务契约
• 实施导则
• 实施说明
• 实施标准
• 互操作需求
• 约束
• 假设

3.7 架构路线图

3.7.1 目标

      架构路线图列举出各个变化增量，并把他们放到时间轴之上，从而展示了从当前架构到目标架构的演进过程。架构路线图是迁移架构的重要组件，并在架构开发方法的B、C、D、E、F阶段中以增量的方式开发出来。

3.7.2 内容

      架构路线图的内容包括：

• 项目列表：
• 每个涉及到的项目的名称、描述和目标
• 用于实现所建议的架构的项目列表，并按照优先级进行了排序
• 基于时间的迁移规划：
• 迁移的效益
• 针对各种迁移选择的成本估算
• 实施建议：
• 用于衡量项目有效性的评估准则
• 风险和问题
• 解决方案构建块的描述和模型

3.8  架构愿景

3.8.1 目标

      架构愿景是在项目生命周期早期创建的，它提供了一个高阶的对于最终架构产品的期望视图，目的是为了在一开始就对架构应该达到的期望结果形成一致意见，从而使得在之后的过程中架构师能够关注于切实可行的关键领域。通过提供一份关于整体架构定义的内容摘要，架构愿景对于干系人之间按沟通也提供了一定的支持。

3.8.2 内容

      架构愿景的内容通常包括：

• 问题描述：
• 干系人以及他们的关注点
• 需要解决的问题/场景列表
• 详细目标描述
• 环境和流程模型：
• 流程描述
• 涉及到环境的流程步骤
• 涉及到人员的流程步骤
• 信息流
• 执行者以及他们担当的角色和责任：
• 人员方面的执行者和角色
• 计算机方面的执行者和角色
• 需求
• 所产生的架构模型：
• 约束
• IT原则
• 支持流程的架构
• 映射到架构之上的需求

3.9 业务原则、目标和驱动力

3.9.1 目标

      业务原则、目标和驱动力通过描述企业的需要和工作方式为架构工作提供了背景。此外，许多处于架构原则考虑之外的因素对架构的开发也有着重要的影响。

3.9.2 内容

      由于不同的组织有着不同的特性，因而关于架构业务背景的内容将会各不相同，企业应该根据各自的情况定义这部分内容。

3.10 能力评估

3.10.1 目标

      在做一份详细的架构定义之前，对企业的当前和目标的能力水平有一个清晰的认识是非常有价值的。对于能力评估，我们可以在如下几个层面进行考虑：

• 企业整体的能力水平是什么？企业希望在何处增强或优化其能力？用于支持企业期望发展的架构关注领域是什么？
• 企业中的IT功能的能力或成熟度水平是什么？就设计管理、操作管理、技术和组织架构而言，进行架构项目最可能的影响都有哪些？为了与企业文化和IT部门的能力相适应，架构项目所需的正规化和详细度的最适宜水平是什么？
• 企业架构功能的能力和成熟度是什么？当前存在的架构资产有哪些？这些资产是否被一直维护，并且是否还准确？什么样的标准和参考模型需要被考虑进去？是否在这些在架构项目中有可能创建可重用资产？
• 能力欠缺存在于何处？为了达成目标能力而需要进行转型的业务范围是什么？在对基本能力欠缺考虑之上的转换风险、文化壁垒以及其他方面考虑都有哪些？

3.10.2 内容

      能力评估的内容通常包括：

• 业务能力评估：
• 业务能力
• 针对每项能力性能水平的基线状态评估
• 针对每项能力性能水平的未来状态期望
• 针对每项能力如何实现的基线状态评估
• 针对每项能力将会被如何实现的期望
• IT能力评估：
• 变更流程的基线和目标成熟度水平
• 运营流程的基线和目标成熟度水平
• 基线能力以及容量评估
• 针对由于架构项目的执行而对IT组织所可能产生的影响的评估
• 架构成熟度评估：
• 架构治理流程、组织、角色和责任
• 架构技能评估
• 架构资源库中的情景定义的深度、广度和质量
• 架构资源库中的标准定义的深度、广度和质量
• 架构资源库中的参考模型的深度、广度和质量
• 针对可重用潜力的评估
• 业务转型准备度评估：
• 准备度因素
• 对于每个准备度因素的愿景
• 针对当前和目标准备度的评级
• 与准备度相关的风险

3.11 变更请求

3.11.1 目标

      在架构的实现过程中，在一切清晰之前，原来的架构定义和需求很可能不适合或不足以达成解决方案的实现。在这种情况下，对实施项目进行调整使之与建议的架构方法发生偏离，或请求架构范围扩展是必需的行为。另外，很多外部因素（例如，市场因素、业务策略变化以及新技术机会）也会为扩展及优化架构提供新的机会。在以上这些环境下，一个变更请求可以被提出，用以开始一个新的架构工作周期。

 

3.11.2 内容

      变更请求的内容通常包括：

• 对于所建议的变更的描述
• 对于所建议的变更的理由
• 对于所建议的变更的影响评估
• 针对相关特定需求的引用
• 迄今需求所涉及的干系人的优先级
• 重新审视这些需求的各阶段描述
• 对需求优先级进行排序的阶段
• 调查和修正需求的优先级阶段的结果
• 对于需求管理的建议
• 资源库引用编号

3.12 沟通计划

3.12.1 目标

      企业架构包含大量的复杂且相互关联的信息。有效地与适当的人在适当的时间针对目标信息进行交流是成功建设企业架构的重要因素。开发沟通计划可以使这些交流通过一种可计划、可管理的方式进行。

3.12.2 内容

      沟通计划的内容通常包括：

• 针对干系人的识别，并根据沟通需求进行分组
• 明确沟通需求、与架构愿景相关的关键消息、沟通风险和关键成功因素（CSFs：Critical Success Factors）
• 明确用来与干系人进行沟通的机制，并允许其对架构信息的访问
• 制定沟通时间表。该时间表展示了沟通将在何时何地进行，以及在何种干系人组之间进行

3.13 合规评估

3.13.1 目标

      一旦一个架构被定义了出来，就必须在整个实施过程中对其进行治理，从而保证原先的架构愿景可以被适当的实现，并且实现中的经验教训也可以反馈到架构过程中。针对实施项目进行周期性的合规检查为重新审核项目过程，并保证设计和实施符合企业策略和架构目标，提供了一种有益的机制。

3.13.2 内容

      合规评估的内容通常包括：

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

3.14 实施和迁移计划

3.14.1 目标

      通过过渡框架的描述为解决方案的实施提供一个日程表，包括实施的时间、成本、资源、收益和里程碑。

3.14.2 内容

      实施和迁移计划的内容通常包括：

• 实施和迁移战略：
• 战略实施方向
• 实施排序方法
• 与其他管理框架的交互：
• 架构与业务规划相协调的方法
• 整合架构的方法
• 架构与项目管理相协调的方法
• 架构与运营管理相协调的方法
• 项目章程：
• 项目所能交付的能力
• 所包含的工作包
• 业务价值
• 风险、问题、假设和依赖关系
• 实施规划：
• 由实施分解出来的各个阶段和工作流
• 为各阶段和工作流进行工作包分配
• 里程碑和时间要求
• 工作分解结构
• 资源需求和成本

3.15 实施治理模型

3.15.1 目标

      一旦一个架构被定义，在整个实施过程中就需要对用于实现架构的过渡框架进行治理。在已经建立了架构功能的组织中可能已经存在了一个治理框架，但是对于特定的过程、组织、角色、责任和度量来说，需要根据项目进行具体的定义。

3.15.2 内容

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

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

3.16 企业组织架构模型

3.16.1 目标

      为了一个架构框架能够被成功地使用，它必须在企业中获得正确的组织、角色和责任的支持。特别重要的是，对不同企业架构参与者之间边界的定义，以及针对跨边界关系的治理。

3.16.2 内容

      企业组织架构模型的内容通常包括：

• 受影响的组织的范围
• 成熟度评估、差距和决议方法
• 架构团队的角色和责任
• 针对架构工作的约束
• 资金预算需求
• 治理和支持策略

3.17 架构工作要求书

3.17.1 目标

      由赞助组织交付给架构组织的用于启动架构开发工作的文档。架构工作要求书可以产生于预备阶段，可以是经过批准的架构变化请求的结果，或者是源于迁移计划对架构工作的参考。

3.17.2 内容

      架构工作要求书的内容通常包括：

• 组织赞助者
• 组织的任务说明
• 业务目标（以及变更）
• 业务的战略规划
• 时间限制
• 业务环境的变化
• 组织方面的约束
• 预算信息以及财务约束
• 外部约束以及业务约束
• 当前业务系统描述
• 当前架构/IT系统描述
• 开发组织的描述
• 开发组织可用资源的描述

3.18 需求影响评估

3.18.1 目标

      在整个架构开发方法过程中，总会有新的与架构相关的信息被收集起来。当这些信息被收集后，对架构在当前某方面有影响的新因素也经常会显现出来。需求影响评估就是用来对当前架构需求进行评估，阐明需要进行的变更以及这些变更所带来的影响。

3.18.2 内容

      需求影响评估的内容通常包括：

• 对于具体需求的引用
• 迄今需求的相关干系人优先级
• 进行重审的各个阶段
• 进行需求优先级排序的阶段
• 调查和修正需求的优先级阶段的结果
• 关于需求管理的建议
• 资源库引用编号

3.19 解决方案构建块

      与架构构建块相类似，解决方案构建块也是存储于架构资源库中的构建块的一种，不过它的内容更倾向于在实现层面对企业中的可重用构建块进行描述。可以说，架构构建块定义了构建块的需求，而解决方案构建块则是此需求在具体实现技术层面的映射。关于解决方案构建块的具体内容请参阅后面的内容。

3.20 架构工作说明书

3.20.1 目标

      架构工作说明书定义了用于完成一个架构项目的方法和范围，它也是用于评测架构项目是否被成功执行的典型文档，并且它也形成了架构服务提供者和使用者之间的合同协议的基础。

3.20.2 内容

      架构工作说明书的内容通常包括：

• 架构工作标题说明
• 项目申请和背景
• 项目描述和范围
• 架构愿景的概括
• 管理办法
• 范围变更程序
• 角色、责任和交付物
• 验收标准和程序
• 项目计划和日程安排
• 针对架构连续体的支持
• 签字批准

3.21 定制的架构框架

3.21.1 目标

      TOGAF提供了一个行业的标准架构框架，但是要在一个架构项目中对其进行有效地使用，则必须在两个层面上进行定制。首先，需要对TOGAF模型进行定制，使得它可以融入到企业之中。此种定制包括将TOGAF模型整合入企业的项目和过程管理框架、术语定制、展示方式开发、架构工具的选择、配置和部署等方面之中。任何被采用的框架的形式和详细程度应该与企业的其他背景元素相适应，例如文化、干系人、企业架构的商业模型以及当前架构能力的水平。一旦针对框架完成了上面的定制，企业就需要为具体的架构项目做进一步的框架定制，而在这一层面的定制中，企业需要选择适当的架构交付物和架构制品来满足项目和干系人的需要。

3.21.2 内容

      定制的架构框架的内容通常包括：

• 定制架构的方法
• 定制架构的内容（架构交付物和架构制品）
• 配置和部署工具
• 治理模型和其他框架的接口：
• 企业架构管理框架
• 能力管理框架
• 项目组合管理框架
• 项目管理框架
• 运营管理框架

3.22 过渡架构

3.22.1 目标

      过渡架构展示了企业的增量状态，并反映从当前架构到目标架构的过渡过程。过渡架构被用来将单独的工作包和项目组合为可管理的项目组合和程序，用于描述每个阶段的业务价值。

3.22.2 内容

      过渡架构的内容通常包括：

• 机会组合描述：
• 综合的差距、解决方案和依赖关系评估
• 机会描述
• 收益评估
• 能力和能力增量
• 互操作性和共存的需求
• 工作包组合描述：
• 工作包描述（名称、描述、目标和交付物）
• 功能性需求
• 依赖关系
• 与机会之间的关系
• 与架构定义文档和架构需求说明之间的关系
• 里程碑和里程碑过渡架构：
• 过渡状态描述
• 每个过渡状态的业务架构
• 每个过渡状态的数据架构
• 每个过渡状态的应用架构
• 每个过渡状态的技术架构
• 实施因素评估和推导矩阵（ImplementationFactor Assessment and Deduction Matrix：用于记录将会影响架构实施和迁移计划的各个因素。此矩阵包括在制定迁移计划时需要考虑的各个因素、它们的描述，以及由此而推断出的在制定计划时需要考虑的行动或约束）：
• 风险
• 问题
• 假设
• 依赖
• 行动
• 综合差距、解决方案和依赖矩阵（Consolidated Gaps，Solutions，and Dependencies matrix：此矩阵使架构师可以对在各领域架构差距分析结果中明确的差距进行分组，并评估潜在的解决方案，以及这些方案与差距之间的依赖关系）：
• 架构领域
• 差距
• 潜在解决方案
• 依赖关系