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等人的《确定流程重用机会以增强运营模式的方法》）。

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

1. 活动模型（也称为业务流程模型）描述企业的业务活动、活动之间交换的数据和/或信息（内部交换），以及与模型范围之外的其他活动交换的数据和/或信息（外部交换）

活动模型本质上是分层的。它们捕获业务流程中执行的活动，以及这些活动的输入、控制、输出和机制/资源 (ICOM)。活动模型可以用业务规则的明确声明进行注释，这些声明表示 ICOM 之间的关系。例如，业务规则可以指定在指定条件下谁可以做什么、所需的输入和控制的组合以及结果输出。创建活动模型的一种技术是集成计算机辅助制造 (ICAM) 定义 (IDEF) 建模技术。

对象管理组 (OMG) 开发了业务流程建模表示法TM (BPMN TM )，这是一种业务流程建模标准，包括一种用于指定业务流程、它们的任务/步骤和生成的文档的语言。

1. 用例模型根据用例和对应于业务流程和组织施动者（人员、组织等）的施动者来描述企业的业务流程。

用例图和用例规范中描述了用例模型。

1. 逻辑数据模型（或类模型）

逻辑数据模型描述实体、它们的属性、这些属性的可接受值以及各种实体之间的关系。特别有用的是用于分析的“is-a”关系。例如，如果轿车是一种汽车，它是一种车辆，那么所有车辆的通用业务规则可以编写一次，并自动为所有类型的汽车和卡车提取。

类模型通过包含实体（现在称为类）独有的服务（方法）来扩展逻辑数据模型以包含行为。通常应用和信息架构师将使用类图，而业务架构师将使用逻辑数据模型。