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

4.1 目标

B阶段的目标是：

• 制定目标业务架构，描述企业需要如何运营以实现业务目标，并以解决架构工作声明和利益相关者关切的方式响应架构愿景中规定的战略驱动因素
• 根据基线和目标业务架构之间的差距确定候选架构路线图组件

4.2 输入

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

4.2.1 企业外部参考资料

■ 架构参考资料（见TOGAF标准——架构内容）

4.2.2 非架构输入

■ 架构工作请求（见TOGAF标准——架构内容）
■ 业务原则、业务目标和业务驱动因素（参见TOGAF标准——架构内容）
■ 能力评估（见TOGAF标准——架构内容）
■ 通信计划（见TOGAF标准——架构内容）

4.2.3 架构输入

■ 企业架构的组织模型（见TOGAF标准——架构内容），包括：
— 受影响组织的范围
— 成熟度评估、差距和解决方法
— 架构团队的角色和职责
— 建筑工作的限制
— 所需预算
— 治理和支持战略
■ 定制的架构框架（见TOGAF标准——架构内容），包括：
— 量身定制的架构方法

— 量身定制的架构内容（可交付成果和工件）
— 已配置和部署的工具
■ 批准的架构工作说明书（见TOGAF标准——架构内容）
■ 架构原则（参见TOGAF标准——架构内容），包括预先存在的业务原则
■ 企业连续体（见TOGAF标准——架构内容）
■ 架构库（见TOGAF标准——架构内容），包括：
— 可重复使用的构建块
— 公开可用的参考模型
— 特定组织的参考模型
— 组织标准
■ 架构愿景（见TOGAF标准——架构内容），包括：
— 问题描述
— 建筑工作说明书的目标
— 摘要视图
— 业务场景（可选）
— 细化关键高层利益相关者要求
■ 架构定义文件草案，其中可能包括任何架构域的基线和/或目标架构

4.3 步骤

B阶段所涉及的详细程度将取决于整体架构工作的范围和目标。

在B阶段，需要详细定义表征业务需求的新模型。在目标环境中继承和支持的现有业务工件可能已
经在之前的架构工作中得到了充分定义；但是，如果没有，它们也需要在阶段B中定义。

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

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

B阶段的步骤如下：

• 选择参考模型、视点和工具（见第4.3.1节）
• 制定基线业务架构描述（见第4.3.2节）
• 制定目标业务架构描述（见第4.3.3节）
• 进行差距分析（见第4.3.4节）
• 定义候选路线图组件（见第4.3.5节）
• 解决整个架构景观的影响（见第4.3.6节）
• 进行正式的利益相关者审查（见第4.3.7节）
• 最终确定业务架构（见第4.3.8节）
• 创建/更新架构定义文档（见第4.3.9节）

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

根据业务驱动因素和利益相关者的关注点，从架构存储库中选择相关的业务架构资源（参考模型、
模式等）。

选择相关的业务架构观点（例如，运营、管理、财务）；即，那些将使架构师能够演示如何在业
务架构中解决利益相关者关注的问题。

确定与所选视点相关的用于捕获、建模和分析的适当工具和技术。根据所保证的复杂程度，这些可能包括简单的文档或电子表格，或更复杂的建模工具和技术，如活动模型、业务流程模型、用例模型等。

4.3.1.1 确定总体建模过程

业务建模和战略评估是构建组织业务架构目标状态的有效技术（见第3.3.4节）。然后，该活动的
输出用于阐明缩小当前状态和目标状态之间差距所需的业务能力、组织结构和价值流。如第3.5节
所述，这些映射的框架可能已经存在，应该加以利用，现在使用它们来表征差距，更好地映射业
务价值，以实现目标业务架构。

对于每个视点，使用所选工具或方法选择支持所需特定视图所需的模型。

确保涵盖所有利益相关者的关切。如果没有，则创建新模型来解决未涵盖的问题，或增强现有模
型（见第4.5.7节）。业务场景是一种发现和记录业务需求的有用技术，可以在业务架构的层次分
解中以不同的细节级别迭代使用。TOGAF®系列指南：业务场景中描述了业务场景。

第4.5节中描述的技术可用于逐步分解业务：

• 业务能力映射：识别、分类和分解业务向一个或多个利益相关者交付价值所需的业务能力
• 信息映射：收集对业务最重要的信息概念及其关系
• 组织映射：表示业务的组织结构（包括第三方域），描述业务单元，将这些单元分解为较低级别的功能，以及组织关系（单元到单元以及映射到业务能力、位置和其他属性）
• 流程建模：阐明企业业务流程的活动，以进行分析和改进
• 结构化分析：确定架构范围内的关键业务能力，并将这些能力映射到业务中的业务职能和组织单位上
• 用例分析：一种从用户的角度识别要完成的系统或任务的需求的技术
• 价值流图：组织为创造与利益相关者交换的价值而进行的活动的端到端细分价值流图说明了组织如何在特定利益相关者的背景下交付价值，并利用业务能力创造利益相关者价值，并与目标业务架构的其他方面保持一致。

所需的分解级别和严格程度因企业而异，也因企业而异。架构师应考虑企业的目标、目的、范围
和企业架构工作的目的，以确定分解级别。

4.3.1.2 确定所需的业务构建块目录 

目录记录了企业核心资产的库存。目录本质上是分层的，它捕获了构建块的分解，也捕获了相关
构建块（例如组织/参与者）之间的分解。

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

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

4.3.1.3 确定所需矩阵

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

矩阵是形成观点的原材料，也是作为差距分析的一部分进行影响评估的关键资源。

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

4.3.1.4 确定所需图表

图表根据利益相关者的要求，从一组不同的角度（视点）呈现业务架构信息。
TOGAF标准——架构内容详细描述了在业务架构中开发时应考虑的图表，详细描述了它们，并将其与TOGAF企业元模型中的实体、属性和关系联系起来。

4.3.1.5 确定要收集的需求类型

一旦开发了业务架构目录、矩阵和图表，就可以通过形式化实现目标架构的以业务为中心的需求
来完成架构建模。

这些要求可能：

• 与业务领域相关
• 为数据、应用程序和技术架构提供需求输入
• 在设计和实施过程中提供详细的指导，以确保解决方案满足原始架构要求、

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

在许多情况下，架构定义的目的不是为解决方案提供详细或全面的要求（因为这些要求可以通过
一般的需求管理规程更好地解决）。应在架构（Architecture）愿景阶段确定需求内容的预期范
围，并将其记录在批准的架构（architectural）工作说明书中。

任何超出架构工作说明书定义范围的要求或要求变更都必须通过受控的需求管理流程提交给需求
库进行管理。

4.3.2 制定基线业务架构描述

制定现有业务架构的基线描述，以支持目标业务架构。定义的范围和详细程度将取决于现有业务
元素在多大程度上可能被转移到目标业务架构中，以及是否存在架构描述，如第4.5节所述。在可
能的情况下，利用架构库（参见TOGAF标准——架构内容）确定相关的业务架构构建块。

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

4.3.3 制定目标业务架构描述

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

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

4.3.4 执行差距分析

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

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

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

4.3.5 定义候选路线图组件

在创建基线架构、目标架构和差距分析结果后，需要一个业务路线图来确定未来阶段活动的优先级。此初始业务架构路线图将用作原材料，以支持在机会和解决方案阶段更详细地定义整合的跨学科路线图。

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

一旦业务架构最终确定，就有必要了解任何更广泛的影响或含义。在此阶段，应检查建筑景观中的其他建筑构件，以确定：

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

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

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

4.3.8 最终确定业务架构

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

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

• 在架构定义文档中记录构建块决策的基本原理
• 准备架构定义文档中与架构的预期范围和使用相关的适当业务部分

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

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

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

4.3.8 最终确定业务架构

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

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

• 在架构定义文档中记录构建块决策的基本原理
• 准备架构定义文档中与架构的预期范围和使用相关的适当业务部分

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

4.4 输出

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

■ 架构愿景阶段交付成果的改进和更新版本（如适用），包括：
— 架构工作说明书（见TOGAF标准——架构内容），必要时进行更新
— 经过验证的业务原则、业务目标和业务驱动因素（参见TOGAF标准——架构内容），必
要时进行更新
— 架构原则（见TOGAF标准——架构内容）
■ 架构定义文档草案（见TOGAF标准——架构内容），包括：
— 批准的基线业务架构（如适用）
— 已批准的目标业务架构，包括：
— 组织结构——确定业务地点并将其与组织单位联系起来
— 企业和每个组织单位的业务目标
— 业务功能——一个详细的递归步骤，涉及将主要功能区域连续分解为子功能
— 业务能力——企业为实现其目标和目的而需要拥有或交换的能力
— 业务服务——通过封装独特的“业务行为元素”来支持业务的服务；企业外部提
供的服务可能得到业务服务的支持
— 产品——企业向客户提供的产出；产品包括材料和/或服务
— 业务流程，包括措施和可交付成果
— 业务角色，包括技能要求的开发和修改
— 业务数据模型
— 组织/业务职能与业务能力的相关性——以矩阵报告的形式将业务能力与组织单位联系起来
— 与解决关键利益相关者问题的选定观点相对应的观点
■ 架构需求规范草案（见TOGAF标准——架构内容），包括以下业务架构需求：
— 差距分析结果
— 技术要求——识别、分类和优先考虑对剩余架构领域工作的影响；例如，通过依赖性/优先级矩阵（例如，指导事务处理速度和安全性之间的权衡）；列出预计生产的具体型号（例如，表示为Zachman框架的原语）
— 更新的业务需求
■ 架构路线图的业务架构组件（参见TOGAF标准— 架构内容）
TOGAF标准——架构内容包含了这个阶段可能产生的架构工件的详细描述。

4.5 方法

业务架构是对能力、端到端价值交付、信息和组织结构的整体、多维业务视图的表示；以及这些
业务观点和战略、产品、政策、举措和利益相关者之间的关系。

业务架构将业务元素与业务目标和其他领域的元素联系起来。

4.5.1 概述

了解业务架构是任何其他领域（数据、应用程序、技术）架构工作的先决条件，因此，如果其他
组织流程（企业规划、战略业务规划、业务流程再造等）中没有考虑到这一点，那么这也是需要
开展的第一项架构活动。

在实际操作中，业务架构通常也是必要的，它可以向关键利益相关者展示后续架构工作的业务价
值，以及支持和参与后续工作对这些利益相关者的投资回报。

B阶段的工作范围主要由A阶段提出的架构愿景决定。业务战略定义了目标、驱动因素和成功指标，但不一定是如何实现的。这就是在阶段B中详细定义的业务架构的作用。

这在很大程度上取决于企业环境。在某些情况下，业务架构的关键要素可以在其他活动中完成；
例如，企业使命、愿景、战略和目标可能被记录为一些更广泛的业务战略或企业规划活动的一部
分，这些活动在企业内有自己的生命周期。

在这种情况下，可能需要验证和更新当前记录的业务战略和计划，和/或在高级业务驱动因素、业
务战略和目标与与此架构开发工作相关的具体业务需求之间架起桥梁。

在其他情况下，迄今为止可能很少或根本没有做业务架构工作。在这种情况下，架构团队需要研
究、验证和认可架构要支持的关键业务目标和流程。这可以作为独立的练习来完成，可以在架构
开发之前完成，也可以作为a阶段的一部分。

在这两种情况下，业务场景技术（请参阅TOGAF®系列指南：业务场景），或阐明关键业务需求和表示IT架构的隐含技术要求。

一个关键目标是尽可能多地重复使用现有材料。在架构更成熟的环境中，将有现有的架构定义，
这些定义（希望）自上一个架构开发周期以来一直得到维护。如果存在架构描述，则可以将其用
作起点，并在必要时进行验证和更新；请参阅TOGAF标准——架构内容。

只收集和分析那些能够做出与此架构工作范围相关的明智决策的信息。如果这项工作的重点是定
义（可能是新的）业务流程，那么阶段B必然会涉及大量的详细工作。如果重点更多地放在其他领
域（数据/信息、应用系统、基础设施）的目标架构上，以支持基本上存在的业务架构，那么在阶
段B中构建一个完整的图景而不涉及不必要的细节就很重要。

4.5.2 制定基线描述

如果企业有现有的体系结构描述，则应将其用作基线描述的基础。该输入可能已在开发架构愿景
的A阶段使用，例如第3.5.2节中介绍的业务能力图或核心价值流集，并且本身可能足以满足该基
线。

更新这些材料的原因包括缺少业务能力、新的价值流或之前未在企业架构项目范围内进行评估的
组织单位变更。第4.5.3节至第4.5.6节介绍了使用核心业务架构方法对A阶段战略范围驱动的业务
架构进行建模。请注意，将这些方法付诸行动，以推动后期架构工作的重点和目标状态，并不意
味着A阶段的基本框架，如通用企业业务能力图，必然会发生变化，而是以特定企业架构项目的范
围和需求驱动的方式应用。

如果不存在架构描述，则应收集信息并开发业务架构模型。

无论具体项目的范围如何，重要的是要确定是业务的基本视图正在发生变化，还是使用这些视图
来确定特定项目与企业其他部分的范围、优先级和关系。

4.5.3 应用业务能力

在架构愿景阶段发现或开发的业务能力图提供了一个独立于当前组织结构、业务流程、信息系统
和应用程序以及产品或服务组合其余部分的业务自包含视图。这些业务能力应映射回企业架构项
目范围内的组织单位、价值流、信息系统和战略计划。这种关系映射提供了对每个领域的对齐和
优化的更深入了解（请参阅TOGAF®系列指南：业务能力中的关系映射）。

另一种常见的分析技术涉及热图，可用于显示同一组核心业务能力的一系列不同视角。这些包括
成熟度，有效性、性能以及每种能力对企业的价值或成本。不同的属性决定了业务能力图上每个能力的颜色（请参阅TOGAF®系列指南：业务能力中的热图）。

例如，业务能力成熟度热图将特定能力的期望成熟度显示为绿色，一个级别为黄色，两个或多个级
别为红色。其他颜色可能表示状态，例如紫色表示公司中尚不存在但需要的能力，或者可能是资金
过多、资源过多的能力。这种差距分析与正在进行的企业架构项目直接相关；差距仅在业务需求的
背景下相关，并为本阶段的更多映射或后续架构阶段的优先级提供了重点。

4.5.4 应用价值流

价值流提供了有价值的利益相关者背景，说明组织为什么需要业务能力，而业务能力提供了组织
在特定价值阶段取得成功所需的内容。

从架构愿景阶段记录的业务的初始价值流模型开始。在特定的企业架构项目范围内，如果广度足
够大，可能需要存储库中尚未包含的新价值流。

可以通过热图（按价值流阶段）或围绕价值流的完整定义开发用例（见TOGAF®系列指南中的基线示例：价值流）在项目范围内分析新的或现有的价值流。一个项目可能会关注特定的利益相关者，这是业务价值的一个要素，或者强调某些阶段而不是其他阶段，以便在以后的阶段为解决方案制定更好的要求。

最实质性的好处来自将价值流中的阶段之间的关系映射到业务能力，然后在特定利益相关者的价
值流所实现的业务价值的背景下对能力进行差距分析（如热图）（请参阅TOGAF®系列指南中的
“将价值流映射到业务功能：价值流”）。

4.5.5 应用组织结构图

组织图显示了构成企业生态系统的关键组织单位、合作伙伴和利益相关者群体。该图还应描绘这
些实体之间的工作关系，与仅显示分层报告关系的组织结构图不同。该地图通常被描绘为各种商
业实体之间关系和互动的网络或网络（见Mintzberg和Van der Heyden的《组织结构图：绘制公司
如何真正运作》，1999）。

业务单元是用于建立组织图的主要概念。根据对企业构成的相对不受约束的观点，企业可能是正
在进行的项目的一个业务部门，可能包括所有业务部门，也可能包括第三方或其他利益相关者群
体。解释取决于架构工作的范围。

此映射是业务架构的关键元素，因为它为整个企业架构工作提供了组织背景。能力映射揭示了业
务的功能，价值流映射揭示了它如何向特定的利益相关者提供价值，组织图标识了拥有或使用这些能力并参与价值流的业务部门或第三方。

结合第4.5.3节、第4.5.4节和相关指南中的方法，组织图提供了对哪些业务部门参与架构工作、
谁和何时讨论给定需求以及如何衡量各种决策影响的理解。

有关组织图的更多指导，请参阅TOGAF®系列指南：组织图。

4.5.6 应用信息地图

在业务架构阶段，对信息进行特征化从对业务最重要的元素开始，如产品、客户、工厂等。有了
这些关键元素的列表，跨学科团队可以列出并映射最重要的信息，以及如何使用业务术语对其进
行描述。信息域可以从业务术语逻辑上归属的分组或类别中得出。这些域是开始信息映射的好地
方，以确保完整性和最高价值，然后再继续处理数据类型的细节。

然后，可以将信息域之间的关系添加到地图中，作为对良好基线信息地图的下一个理解层次。最
显著的好处是在信息和业务能力之间构建矩阵。对业务最重要的信息与描述应用该信息创造价值
的能力的业务能力之间的联系是业务架构的一个关键方面。这些信息映射和与业务能力的关系将
应用于数据特征、应用程序和基础设施的后续架构阶段。

有关信息映射的更多指导，请参阅TOGAF®系列指南：信息映射。

4.5.7 应用建模技术

这里提供的建模和映射技术是将上述阶段B中描述的业务能力、价值流和组织映射实现到业务实践
中的扩展。它们扩展了运营模型，该模型表示组织如何在一系列领域内运营以实现其目的（见
M.de Vries等人的《识别流程重复使用机会以增强运营模型的方法》）。

除了上述技术（能力图、价值流和组织图）外，如果认为合适，还可以采用各种其他建模技术。
例如：

• 活动模型（也称为业务流程模型）描述了企业的业务活动、活动之间交换的数据和/或信息（内部交换），以及与模型范围之外的其他活动交换的数据或信息（外部交换）活动模型本质上是分层的。它们捕获了业务流程中执行的活动，以及这些活动的输入、控制、输出和机制/资源（ICOM）。活动模型可以用业务规则的显式语句进行注释，这些语句表示ICOM之间的关系。例如，业务规则可以指定在指定条件下谁可以做什么，所需的输入和控制的组合，以及由此产生的输出。创建活动模型的一种技术是集成计算机辅助制造（ICAM）DEFinition（IDEF）建模技术。
• 对象管理组织（OMG）开发了业务流程建模符号™（BPMN™），这是一种业务流程建模标准，包括一种用于指定业务流程、其任务/步骤和生成的文档的语言。
• 用例模型根据与业务流程和组织参与者（人、组织等）对应的用例和参与者来描述企业的业务流程用例模型在用例图和用例规范中进行了描述。
• 逻辑数据模型（或类模型）逻辑数据模型描述了实体、它们的属性、这些属性的可接受值以及各种实体之间的关系。特别有用的是用于分析的“is-a”关系。例如，如果轿车是一种汽车，即一种车辆，那么所有车辆的通用业务规则可以编写一次，并自动为所有类型的汽车和卡车提取。类模型通过包含实体（现在称为类）特有的服务（方法）来扩展逻辑数据模型，以包括行为。通常，应用程序和信息架构师将使用类图，业务架构师将使用逻辑数据模型。

上述三种类型的模型都可以用统一建模语言™（UML®）表示，并且有各种工具可以生成此类模型。某些行业具有特定于该行业的建模技术。

4.5.8 架构存储库

作为B阶段的一部分，架构团队需要考虑架构库中有哪些相关的业务架构资源可用（参见TOGAF标准— 架构内容），特别是：

• 与组织行业部门相关的行业参考模型
• 企业特定的业务架构视图（能力图、价值流图、组织图等）
• 企业特定的构建块（流程组件、业务规则、职位描述等）
• 适用标准