【TOGAF系列】架构内容第三章：架构制品（或工件）

本章讨论了围绕架构工件的概念，然后描述了建议为ADM中的每个阶段创建的工件。

3.1 基本概念

创建架构工件是为了描述系统、解决方案或企业状态。本节讨论的概念改编自ISO/IEC/IEEE
42010:2011和ISO/IEC/IEE 15288:2015中包含的更正式的定义。如下图所示。

系统的“环境”是决定系统所有影响的设置和环境的上下文。系统的环境包括发展、技术、商业、
运营、组织、政治、经济、法律、监管、生态和社会影响。

“系统”是为实现一个或多个既定目的而组织的相互作用元素的组合。

系统的“架构”是系统在其环境中的基本概念或属性，体现在其元素、关系以及设计和演化的原
则中。

“架构描述”是一种用于表达架构的工作产品；一组共同记录架构的架构视图和模型。

“利益相关者”是指对系统感兴趣的个人、团队、组织或其类别。

“关注点”是指与一个或多个利益相关者相关的系统中的利益。关注点可能涉及系统功能、开发或运行的任何方面，包括性能、可靠性、安全性、分布和可演化性等考虑因素，并可能决定系统的可接受性。

“架构视图”是从一组相关关注点的角度对系统的表示。它由系统的一个或多个架构模型组成。

“架构模型”是对感兴趣主题的表示。模型提供了主题的较小规模、简化和/或抽象表示。

在捕获或表示系统架构的设计时，架构师通常会使用不同的工具创建一个或多个架构模型。架构视图将包括一个或多个模型的选定部分，选择这些部分是为了向特定的利益相关者或利益相关者群体证明，他们的担忧在系统架构的设计中得到了充分的解决。

“架构观点”是对特定类型架构视图的约定的规范。它也可以被称为这种架构视图的定义或模式。它建立了构建、解释和使用架构视图的惯例，以解决有关感兴趣系统的特定问题（或一组问题）。“模型类型”为一种建模建立了约定。

架构视角引用一种或多种模型类型；架构视图包含一个或多个模型。

“视点库”是体系结构存储库的参考库部分中包含的体系结构视点规范的集合。

• 架构视图就是你所看到的；架构视角是你观察的地方——决定你所看到的东西的有利位置或视角
• 架构视角是通用的，可以存储在库中以供重用；架构视图总是特定于为其创建的架构
• 每个架构视图都有一个相关的架构视点来描述它，至少是隐式的

ISO/IEC/IEEE 42010:2011鼓励架构师明确定义架构观点。在视图的内容和模式之间进行这种区分起初可能看起来是不必要的开销，但它提供了一种在不同架构之间重用架构视角的机制。

总之，架构视图是对利益相关者有意义的整体架构的表示。它们使架构能够传达给利益相关者并
被其理解，因此他们可以验证系统是否会解决他们的问题。

担忧往往与需求有关。关注点可以是一般需求类型，例如可用性。这可能会导致几个特定要求的定义。这可能是与利益相关者的某个目标相关的利益。识别问题有助于确保利益相关者的利益得到解决，并确定要求。将关注点与一般工件类型相关联有助于架构师选择和开发特定的工件，以呈现给利益相关者。

3.1.1 架构视点和架构视点的简单示例

对于许多架构来说，一个有用的架构观点是业务领域，这可以通过The Open Group本身的一个例
子来说明。

架构观点如下：

The Open Group相应的架构视点如下图所示：

3.2 在ADM中开发架构视图

3.2.1 一般准则

选择开发哪些特定的架构视图是架构师必须做出的关键决策之一。

架构师有责任确保架构的完整性（适用性），充分解决其利益相关者的所有相关问题；以及架构的完整性，即将所有不同的视图相互连接，令人满意地调和不同利益相关者的冲突关切，并显示在这样做时所做的权衡（例如安全和性能之间）。

选择必须受到实用性考虑和适用性原则的约束（即，建筑应该只发展到适合目的的程度，而不是作为学术练习无限重复）。

正如TOGAF标准——架构开发方法中所解释的那样，架构视图的开发是一个迭代过程。典型的进展是从业务到技术，使用业务场景等技术（请参阅TOGAF®系列指南：业务场景），以正确识别所有相关问题；从高级概述到低级细节，在整个过程中不断回顾利益相关者的关注点和要求。

此外，这些进展中的每一个都必须针对两个不同的环境：现有环境（在ADM中称为基线）和目标环境。架构师必须开发基线架构和目标架构的相关架构视图。这为ADM阶段B、C和D结束时的差距分析提供了背景，该分析确定了要继续推进的基线架构的元素以及要添加、删除或替换的元素。
TOGAF标准-ADM技术中解释了整个过程。

3.2.2 架构视图创建过程

如上所述，TOGAF框架鼓励但不强制使用ISO/IEC/IEEE 42010:2011。因此，以下描述涵盖了采用ISO/IEC/IEEE 42010:2011和未采用ISO/IEC 42010:2011的情况。

ISO/IEC/IEEE 42010:2011本身不需要任何特定的过程来开发架构观点或从中创建视图。如果ISO/IEC/IEEE 42010:2011已被采用并成为组织内公认的做法，通常可以通过以下步骤为特定架构
创建所需的视图：

1. 参考现有的架构视图库
2. 选择适当的架构（architecture）视点（基于视图需要涵盖的利益相关者和关注点）
3. 通过使用选定的架构视点作为模板生成系统视图。这种方法有望带来以下好处：

• 架构师的工作量更少（因为架构视点已经定义，因此可以更快地创建视图）
• 利益相关者可以更好地理解（因为架构观点已经很熟悉了）
• 对视图的有效性更有信心（因为它们的架构观点有已知的跟踪记录）

然而，总是会出现这样的情况，即需要一个没有预定义适当架构视角的架构视图。当然，当一个
组织尚未将ISO/IEC/IEEE 42010:2011纳入其架构实践并建立架构观点库时，情况也是如此。在每种情况下，架构师都可以选择开发一个新的架构观点，以满足突出的需求，然后从中生成架构视图。（这是ISO/IEC/IEEE 42010:2011推荐的做法。）或者，一种更实用的方法也可以同样成功：架构师可以为特定系统创建一个特设架构视图，然后考虑是否应该显式定义隐式架构观点的通用形式并将其保存在库中，以便可以重复使用。（这是最初建立架构观点库的一种方法。）无论上下文如何，架构师都应该意识到，每个架构视图都有一个架构观点，至少是隐含的，以系统的方式定义架构观点（如ISO/IEC/IEEE 42010:2011所建议的）将有助于评估其有效性；即，架构观点是否涵盖了相关利益相关者的关注点？

3.3 视图、工具和语言

上面解释了对架构视图的需求，以及在ADM之后开发它们的过程。本节描述了架构视图之间的关系、用于开发和分析它们的工具以及实现工具之间互操作性的标准语言。

3.3.1 概述

为了在架构中实现完整性和完整性的目标，架构视图通常使用工具进行开发、可视化、通信和管理。在当前的市场状态下，通常必须使用不同的工具来开发和分析架构的不同视图。非常希望用标准语言对架构描述进行编码，以实现架构语义描述的标准方法及其在不同工具之间的重用。架构观点通常也使用工具进行开发、可视化、传达和管理，并且非常希望开发标准架构观点（即模板或模式），以便处理相同视图的不同工具可以互操作，架构的基本元素可以重复使用，架构描述可以在工具之间共享。

TOGAF标准——架构开发方法中详细讨论了与架构工作工具评估相关的问题。

3.4 架构视图与架构视点

3.4.1 架构视图和架构观点示例

为了说明架构视图和架构观点的概念，考虑一个非常简单的机场系统的例子，该系统有两个不同
的利益相关者：飞行员和空中交通管制员。可以从飞行员的架构角度开发一个架构视图，以解决飞行员的担忧。同样，可以从空中交通管制员的架构角度开发另一种架构视图。两种架构视图都不能完全描述整个系统，因为每个利益相关者的架构观点限制（并减少）了每个人对整个系统的看法。

飞行员的架构观点包括一些与管制员不相关的问题，如乘客和燃料，而管制员的架构观点则包括一些与飞行员不相关的因素，如其他飞机。两种架构观点之间也有共享的元素，例如飞行员和管制员之间的通信模型，以及飞机本身的重要信息。

架构视点是视图中包含的信息的模型（或描述）。在我们的例子中，一个架构观点是飞行员如何看待系统的描述，另一个架构视角是控制器如何看待系统。

飞行员从他们的角度描述系统，使用他们朝向或远离跑道的位置和矢量模型。所有飞行员都使用这个模型，该模型有一种特定的语言，用于捕获信息并填充模型。

管制员使用空域模型以及空域内飞机的位置和矢量对系统进行不同的描述。同样，所有管制员都使用从公共模型导出的公共语言，以捕获和传达与其架构观点相关的信息。

幸运的是，当管制员与飞行员交谈时，他们使用共同的沟通语言。（换句话说，代表其各自架构观点的模型部分相交。）这种共同语言的一部分是关于飞机的位置和矢量，对安全至关重要。因此，本质上讲，每个架构观点都是一个抽象模型，描述了特定类型的所有利益相关者——所有飞行员或所有管制员——如何看待机场系统。

有工具可以帮助利益相关者，特别是当他们与复杂的模型（如空域模型或空中飞行模型）交互时。工具的人类用户界面通常接近与架构观点相关的模型和语言。飞行员的独特工具是燃料、高度、速度和位置指示器。管制员的主要工具是雷达。常用的工具是收音机。

从上述示例中总结，我们可以看到，架构视图可以通过利益相关者的角度对系统进行子集划分，例如飞行员与控管制员。这个子集可以用一个称为架构视点的抽象模型来描述，例如空中飞行与空域模型。架构视图的这种描述是用一种部分专业化的语言记录的，例如“飞行员讲话”与“管制员讲话”。工具用于协助利益相关者，它们根据从架构角度衍生的语言（“飞行员说话”与“管制员说话”）相互交互。

当利益相关者使用通用工具时，例如飞行员和管制员之间的无线电联系，通用语言至关重要。

3.4.2 企业架构中的架构视图和架构视点

现在，让我们将此示例映射到企业架构。考虑一个新的小型计算系统中的两个利益相关者：用户
和开发人员。

系统的用户有一个架构视点，反映了他们在与系统交互时的关注点，而系统的开发人员有不同的架构视点。为解决这两个架构视点中的任何一个而开发的架构视图都不太可能详尽地描述整个系统，因为每个视角都减少了每个视角对系统的看法。

用户的体系结构视点由用户与系统交互的所有方式组成，看不到任何细节，如应用程序或数据库
管理系统（DBMS）。

开发人员的架构视点是生产力和工具，不包括实际的实时数据和与消费者的连接等。然而，有些东西是共享的，比如对流程的描述通过为用户设置的系统和/或通信协议，可以将问题直接传达给开发人员。

在这个例子中，一个架构视点是用户如何看待系统的描述，另一个架构视角是开发人员如何看待系统。用户使用可用性、响应时间和信息访问模型从他们的角度描述系统。系统的所有用户都使用此模型，并且该模型具有特定的语言。

开发人员对系统的描述与用户不同，他们使用连接到网络上分布的硬件的软件模型等。然而，系统的开发人员有很多类型（数据库、安全等），他们没有从模型中衍生出来的通用语言。

3.4.3 架构描述需要通用语言和互操作工具

工具既适用于用户，也适用于开发人员。在线帮助等工具是专门为用户提供的，并试图使用用户的语言。不同类型的开发人员有许多不同的工具，但他们缺乏将系统整合在一起所需的通用语言。在工具市场的当前状态下，很难（如果不是不可能的话）让一个工具与另一个工具互操作。TOGAF标准——架构开发方法中详细讨论了与架构工作工具评估相关的问题。

3.5 结论

本节试图以结构化的方式处理观点，但这绝不是一篇关于观点的完整论文。

一般来说，TOGAF框架包含ISO/IEC/IEEE 42010:2011中提出的概念和定义，特别是有助于指导架构视图开发并使架构视图可操作的概念。这些概念可以概括为：

选择关键利益相关者

• 了解他们的担忧，并概括/记录这些担忧
• 了解如何建模和处理这些问题

3.6 ADM阶段的架构工件

目录、矩阵和图表概念

企业元模型被用作一种以有序的方式构建架构信息的技术，以便对其进行处理以满足利益相关者的需求。大多数架构利益相关者实际上不需要知道架构元模型是什么，只关心特定的问题，例如“此应用程序支持什么功能？”、“哪些流程将受到此项目的影响？”等。为了满足这些利益相关者的需求，使用了TOGAF的构建块、目录、矩阵和图表概念。

构建块是元模型中特定类型的实体（例如，称为“采购订单”的业务服务）。构建块根据元模型携带元数据，元模型支持查询和分析。例如，业务服务具有所有者的元数据属性，这允许利益相关者查询特定组织拥有的所有业务服务。

构建块还可以根据架构的上下文包括依赖或包含的实体（例如，称为“采购订单”的业务服务可能隐式地包括多个流程、数据实体、应用程序组件等）。目录是用于治理或参考目的的特定类型或相关类型的构建块列表（例如，显示位置和参与者的组织结构图）。

与构建块一样，目录根据元模型携带元数据，元模型支持查询和分析。矩阵是显示两个或多个模型实体之间关系的网格。矩阵用于表示基于列表而非图形的关系（例如，显示哪些应用程序创建、读取、更新和删除特定类型数据的CRUD矩阵很难直观地表示）。图表是以图形格式呈现的架构内容，允许利益相关者检索所需的信息。图表也可以用作以图形方式填充架构内容或检查所收集信息完整性的技术。

TOGAF内容框架定义了一组要创建的架构图（例如组织结构图）。这些图中的每一个都可以为具有不同风格或内容覆盖的架构创建多次，以满足利益相关者的关注。构建块、目录、矩阵和图表都是领先的企业架构工具所支持的概念。在使用工具对架构进行建模的环境中，这些工具通常支持搜索、过滤和查询架构存储库的机制。体系结构存储库的按需查询（如上面提到的业务服务所有权示例）可用于生成体系结构的即席目录、矩阵和图表。由于这种类型的查询本质上需要灵活性，因此它不受企业元模型的限制或定义。元模型、构建块、图表和利益相关者之间的交互如图下图所示。显示了与TOGAF企业元模型相关的工件。

每个ADM阶段推荐的生产工件如上图。

3.6.1 初步阶段

下面描述了可以在初步阶段创建的目录、矩阵和图表，如TOGAF标准——架构开发方法中所述。原理目录原则目录包含了业务和架构原则的原则，这些原则描述了“好”的解决方案或架构应该是什么样子。原则用于评估和商定架构决策点的结果。原则也被用作协助变革举措的架构治理的工具。
Principles目录包含以下元模型实体：

• 原理

3.6.2 A阶段：架构愿景

下面描述了可以在阶段A（架构愿景）中创建的目录、矩阵和图表，如TOGAF标准——架构开发方
法中所述。利益相关者目录的目的是确定架构参与的利益相关者、他们对参与的影响，以及他们必须由架构框架解决的关键问题、议题或关注点。

了解利益相关者及其需求使架构师能够将精力集中在满足利益相关者需求的领域（参见TOGAF标准-ADM技术）。由于利益相关者映射信息的潜在敏感性，以及架构愿景阶段打算使用非正式建模技术进行的事实，因此不会使用特定的元模型实体来生成利益相关者目录。

价值链图

价值链图提供了企业及其与外部世界互动的高级方向视图。与B阶段（业务架构）中开发的更正式的组织图相比，价值链图侧重于表现力的影响。

此图的目的是快速将利益相关者纳入并协调到特定的变革计划中，以便所有参与者了解架构参与
的高级职能和组织背景。

解决方案概念图

解决方案概念图提供了所设想的解决方案的高级方向，以满足架构参与的目标。与以下阶段开发
的更正式和详细的架构图相比，解决方案概念代表了参与开始时预期解决方案的“铅笔草图”。

该图可能体现了参与的关键目标、要求和约束，也突出了需要通过正式架构建模进行更详细调查
的工作领域。其目的是快速将利益相关者纳入并协调到特定的变革计划中，以便所有参与者都了解架构参与所要实现的目标，以及如何期望特定的解决方案方法满足企业的需求。

商业模式图

描述企业如何创造、交付和获取价值的基本原理的模型。

业务能力图

显示企业实现其目标所需的业务能力的图表。

价值流图

一个图表，表示为客户、利益相关者或最终用户创建整体结果的端到端增值活动集合。

3.6.3 B阶段：业务架构

下面描述了可以在阶段B（业务架构）中创建的目录、矩阵和图表，如TOGAF标准——架构开发方
法中所述。

组织/施动者目录

组织/施动者目录的目的是捕获与IT交互的所有参与者的明确列表，包括IT系统的用户和所有者。
在开发需求时可以参考组织/参与者目录，以测试其完整性。例如，通过验证需要支持哪些客户类型以及用户类型是否有任何特定要求或限制，可以测试为客户提供服务的应用程序的需求的完整性。

组织/施动者目录包含以下元模型实体：

• 组织单位
• 施动者
• 位置（如果不维护独立的位置目录，则可能包含在此目录中）

驱动因素/目标/目的目录

驱动因素/目标/目的目录的目的是提供一个跨组织的参考，说明一个组织如何通过目标、目的和（可选）措施在实践中满足其驱动因素。

发布驱动因素、目标和目的的明确细分，使企业内部的变革举措能够确定整个组织的协同作用（例如，多个组织试图实现类似的目标），这反过来又使利益相关者得以确定，相关的变革举措得以协调或整合。

驱动程序/目标/目的目录包含以下元模型实体：

• 组织单位
• 司机
• 目标Goal
• 目标Objective
• 测量（可选择包括在内）

角色目录

角色目录的目的是提供企业内所有授权级别或区域的列表。通常，应用程序安全或行为是根据本地理解的授权概念定义的，这些概念在用户桌面上结合时会产生复杂和意外的后果。

如果跨组织和应用程序定义、理解和协调角色，这将允许更无缝的用户体验和更安全的应用程序，因为管理员不需要采取变通方法来使用户能够完成工作。

除了支持企业的安全定义外，角色目录还构成了识别组织变革管理影响、定义工作职能和执行最终用户培训的关键输入。

由于每个角色都意味着可以访问许多业务功能，如果这些业务功能中的任何一个受到影响，则需要进行变更管理，可能需要重新定义组织职责，并可能需要重新培训。

角色目录包含以下元模型实体：

• 角色

业务服务/功能目录

业务服务/功能目录的目的是以可过滤、报告和查询的形式提供功能分解，作为图形功能分解图的补充。

业务服务/功能目录可用于识别组织的能力，并了解治理应用于组织功能的级别。这种功能分解可用于确定支持业务变更所需的新功能，也可用于确定变更计划、应用程序或技术组件的范围。

业务服务/功能目录包含以下元模型实体：

• 组织单位
• 业务职能
• 商务服务
• 应用服务（此处可选择包含）

位置目录

位置目录列出了企业开展业务运营或存放架构相关资产（如数据中心或最终用户计算设备）的所有位置。

维护一份明确的位置列表，可以让变更举措快速确定位置范围，并在评估当前景观或拟议的目标解决方案时测试其完整性。例如，升级桌面操作系统的项目将需要确定部署桌面操作系统所在的所有位置。

同样，在实施新系统时，位置图也是必不可少的

制定适当的部署策略，了解用户和应用程序的位置，并确定与位置相关的问题，如国际化、本地
化、时区对可用性的影响、距离对延迟的影响、网络对带宽的影响和访问。
位置目录包含以下元模型实体：

• 地点

过程/事件/控制/产品目录

流程/事件/控制/产品目录提供了流程、触发流程的事件、流程的输出以及应用于流程执行的控制的层次结构。此目录为创建的任何流程图提供了补充，并允许企业跨组织和流程进行过滤、报告和查询，以确定范围、共性或影响。

例如，过程/事件/控制/产品目录允许企业查看过程与子过程的关系，以确定更改高级过程所产生的完整影响链。

过程/事件/控制/产品目录包含以下元模型实体：

• 流程
• 活动
• 控制
• 产品中心

合同/措施目录

合同/措施目录列出了所有商定的服务合同以及这些合同所附的措施。它形成了整个企业商定的服务级别的主列表。

合同/度量目录包含以下元模型实体：

• 商务服务
• 应用服务（可选）
• 合同
• 测量

业务能力目录

一个企业可能具备的实现特定目的的能力列表。

价值流目录

为客户、利益相关者或最终用户创建整体结果的端到端增值活动集合列表。

价值流阶段目录

为客户、利益相关者或最终用户创建总体结果的增值活动的不同阶段的端到端集合列表。价值流阶段目录包括以下元模型实体：

• 业务能力
• 价值流

商业术语目录

此目录包含企业体系结构中包含的或与之交互的所有元素的名称和明确描述。选信息可能包括元素企业同义词、缩写/首字母缩略词以及与其他元素的关系。该目录提供了所有分析师（如业务、信息和系统）为其架构产品（包括信息/数据模型）使用的语义，并在整个ADM中不断发展。

业务互动矩阵

该矩阵的目的是描述整个企业中组织和业务职能之间的关系互动。

了解企业的业务交互非常重要，因为它有助于突出价值链和跨组织的依赖关系。

业务交互矩阵显示了以下元模型实体和关系：

• 组织机构
• 业务职能
• 商务服务
• 业务服务

与业务服务关系进行通信

• 业务服务依赖于业务服务关系

施动者/角色矩阵

该矩阵的目的是显示哪些参与者扮演哪些角色，支持安全和技能要求的定义。

理解参与者与角色的关系是定义培训需求、用户安全设置和组织变革管理的关键支持工具。

施动者/角色矩阵显示了以下元模型实体和关系：

• 施动者
• 角色
• 施动者执行角色关系

价值流/能力矩阵

此矩阵的目的是显示支持价值流每个阶段所需的能力。

战略/能力矩阵

此矩阵的目的是显示支持特定战略声明所需的能力。

能力/组织矩阵

此矩阵的目的是显示实现每种能力的组织要素。能力/组织矩阵包括以下元模型实体：

• 业务能力
• 价值流
• 组织单位

业务足迹图

业务足迹图描述了业务目标、组织单位、业务功能和服务之间的联系，并将这些功能映射到提供所需功能的技术组件。

业务足迹图在技术组件和它所满足的业务目标之间提供了清晰的可追溯性，同时也展示了所识别服务的所有权。

业务足迹图仅展示了将组织单位职能与交付服务联系起来的关键事实，并被用作高级（CxO）利益相关者的沟通平台。

业务服务/信息图

业务服务/信息图显示了支持一个或多个业务服务所需的信息。业务服务/信息图显示了业务服务消耗或产生的数据，也可能显示信息的来源。

业务服务/信息图显示了架构中存在的信息的初始表示，因此构成了阶段C（数据架构）中详细阐述和细化的基础。

功能分解图

功能分解图的目的是在一个页面上显示与架构考虑相关的组织能力。通过从功能角度考察一个组织的能力，可以快速开发该组织所做工作的模型，而不会陷入关于该组织如何做的长期争论。一旦开发出基本的功能分解图，就可以在该图上叠加热图，以显示范围和决策。例如，在变更计划的不同阶段要实现的功能。

产品生命周期图

此图显示了业务产品从创建或接收到销售、处置或销毁的可能状态转换。产品可以是任何类型的产品（物理、软件或服务）。

目标/目的/业务服务图

目标/目的/业务服务图的目的是定义业务服务为实现业务愿景或战略做出贡献的方式。业务服务与其支持的驱动因素、目标、目的和度量相关联，使企业能够了解哪些业务服务对业务绩效的相似方面做出了贡献。目标/目的/业务服务图还提供了关于特定业务服务的高性能构成的定性输入。

业务用例图

业务用例图显示了业务服务的消费者和提供者之间的关系。业务服务由参与者或其他业务服务使用，业务用例图通过说明如何以及何时使用业务能力，在描述业务能力方面提供了更丰富的内容。业务用例图的目的是帮助描述和验证参与者及其角色与流程和功能之间的交互。随着架构的发展，用例可以从业务层面发展到包括数据、应用程序和技术细节。架构业务用例也可以在系统设计工作中重复使用。

组织分解图

组织分解图描述了组织树中参与者、角色和位置之间的链接。

组织图应提供组织中所有者和决策者的指挥链。虽然组织分解图的目的不是将目标与组织联系起来，但应该可以从组织分解图中直观地将目标与利益相关者联系起来。

工艺流程图

流程图的目的是描述与流程元模型实体相关的所有模型和映射。

流程图显示了活动之间的顺序控制流，并可能利用泳道技术来表示流程步骤的所有权和实现。例如，支持流程步骤的应用程序可以显示为泳道。

除了显示活动序列外，流程流还可以用于详细说明应用于流程的控制、触发或完成流程的事件，以及流程执行生成的产品。

流程图在与主题专家一起阐述架构时很有用，因为它们允许专家描述特定功能的“工作是如何完
成的”。通过这个过程，每个过程步骤都可以成为一个更细粒度的函数，然后可以作为一个过程
进行详细阐述。

业务事件图

业务事件图的目的是描述事件和流程之间的关系。

某些事件，如某些信息的到达（例如，客户提交销售订单）或某个时间点（例如，财政季度末），导致需要在业务范围内开展工作和采取某些行动。这些通常被称为“业务事件”或简称为“事件”，被视为流程的触发器。值得注意的是，事件必须触发一个流程并生成业务响应或结果。业务能力图
显示企业实现其目标所需的业务能力的图表。业务能力可以分解为子能力。

价值流图

一个图表，表示为客户、利益相关者或最终用户创建整体结果的端到端增值活动集合。

价值流图包括以下元模型实体：

• 业务能力
• 价值流

组织架构图

显示构成企业的主要实体、合作伙伴和利益相关者之间关系的图表。

信息地图

信息概念及其相互关系的集合。信息概念实际上反映了商业词汇；例如，客户、账户或产品。在业务架构中映射信息首先要列出对业务最重要的元素，以及如何用业务术语描述它们。

3.6.4 C阶段：数据架构

下面描述了可以在阶段C（数据架构）中创建的目录、矩阵和图表，如TOGAF标准——架构开发方法中所述。

数据实体/数据组件目录

此目录标识并维护整个企业中使用的数据列表，将数据实体与数据组件相关联，显示数据实体的结构。

其目的是：

• 识别企业中使用的所有数据
• 鼓励有效使用数据

数据实体/数据组件目录包含以下元模型实体：

• 数据实体
• 逻辑数据组件
• 物理数据组件

数据实体/业务功能矩阵

数据实体/业务功能矩阵的目的是描述企业内数据实体和业务功能之间的关系。业务功能由具有明确定义边界的业务服务支持，并将由业务流程支持和实现。数据实体业务功能关系的映射可以实现以下操作：

• 将数据实体的所有权分配给组织
• 了解业务服务的数据和信息交换要求
• 支持差距分析，确定是否缺少任何数据实体并需要创建
• 定义数据实体的来源应用、记录应用和引用应用
• 在整个企业内开发数据治理程序（建立数据管理员，制定与业务职能相关的数据标准等）数据实体/业务功能矩阵显示了以下实体和关系：
• 数据实体
• 业务职能
• 数据实体与所属组织单位的关系

应用程序/数据矩阵

应用程序/数据矩阵的目的是描述应用程序（即应用程序组件）与其访问和更新的数据实体之间的关系。应用程序将创建、读取、更新和删除与其关联的特定数据实体。例如，客户关系管理（CRM）应用程序将创建、读取、更新和删除客户实体信息。

包/打包服务环境中的数据实体可分为主数据、参考数据、事务数据、内容数据和历史数据。在数据实体上运行的应用程序包括事务应用程序、信息管理应用程序和业务仓库应用程序。

应用程序组件数据实体关系的映射是一个重要步骤，因为它可以实现以下操作：

• 将数据访问权限分配给组织中的特定应用程序
• 了解不同应用程序中的数据重复程度以及数据生命周期的规模
• 了解不同应用程序更新相同数据的位置
• 支持差距分析，确定是否缺少任何应用程序，从而需要创建应用程序

应用程序/数据矩阵是一个二维表，一个轴上是逻辑应用程序组件，另一个轴是数据实体。

概念数据图

概念数据图的主要目的是描述企业内关键数据实体之间的关系。此图旨在解决业务利益相关者的担忧。

使用的技术包括：

• 实体关系模型
• 简化的UML类图

逻辑数据图

逻辑数据图的主要目的是显示企业内关键数据实体之间关系的逻辑视图。此图旨在解决以下问题：

• 应用程序开发人员
• 数据库设计者

数据传播图

数据传播图的目的是显示数据实体、业务服务和应用程序组件之间的关系。该图显示了应用程序组件如何物理实现逻辑实体。这允许进行有效的规模调整，并优化IT足迹。此外，通过为数据分配业务价值，可以获得应用程序组件业务关键性的指示。

此外，该图可能显示数据复制和数据主引用的应用程序所有权。在这种情况下，它可以显示两个副本以及它们之间的主副本关系。此图可以包括服务；也就是说，服务封装数据并驻留在应用程序中，或者驻留在应用上并访问封装在应用程序内的数据的服务。

数据安全图

此图显示了哪些角色、组织单位和应用程序访问哪些数据。它可以显示为图表或以矩阵形式呈现。

其目的是：

• 证明遵守数据隐私法律法规
• 显示因数据访问而产生的安全威胁
• 显示组织外部的哪些方可以访问数据
• 显示应用于数据访问的安全措施

数据迁移图

此图显示了如何从基线或源位置提取数据并将其加载到目标位置。它可能会显示数据在途中被转换和/或清理的位置。在ADM的C阶段，该图可能处于概览级别。稍后，可以详细说明哪些源数据项映射到哪些目标数据项。

数据生命周期图

数据生命周期图是在业务流程的约束下管理业务数据从概念到处置的整个生命周期的重要组成部分。

数据本身被视为一个实体，与业务流程和活动解耦。状态的每个变化都在图上表示，图中可能包括触发状态变化的事件或规则。

数据与流程的分离允许识别共同的数据要求，从而更有效地实现资源共享。

3.6.5 C阶段：应用架构

下面描述了可以在阶段C（应用程序体系结构）中创建的目录、矩阵和图表，如TOGAF标准——体系结构开发方法中所述。

应用程序组合目录

此目录的目的是识别和维护企业中所有应用程序的列表。此列表有助于定义可能影响特定类型应用程序的变更计划的横向范围。一个商定的应用程序组合允许定义和管理一组标准的应用程序。

应用程序组合目录为剩余的矩阵和图表提供了基础。它通常是应用程序架构阶段的起点。应用程序组合目录包含以下元模型实体：

• 应用服务
• 逻辑应用程序组件
• 物理应用组件

接口目录

接口目录的目的是确定应用程序之间的接口范围并记录它们，以便尽早确定应用程序间的整体依赖关系范围。

应用程序将在其他应用程序中创建、读取、更新和删除数据；这将通过某种接口实现，无论是通过定期加载的批处理文件、到另一个应用程序数据库的直接连接，还是通过某种形式的API或web服务。

应用程序组件应用程序组件实体关系的映射是一个重要步骤，因为它可以实现以下操作：

• 了解应用程序之间的交互程度，确定那些在依赖其他应用程序方面处于核心地位的应用程序
• 了解应用程序之间接口的数量和类型
• 了解应用程序之间接口的重复程度
• 在考虑目标应用程序组合时，确定简化接口的潜力
• 支持差距分析，确定是否缺少任何应用程序，从而需要创建应用程序

接口目录包含以下元模型实体：

• 逻辑应用程序组件
• 物理应用组件
• 应用程序与应用程序关系通信

应用程序/组织矩阵

此矩阵的目的是描述企业内应用程序和组织单位之间的关系。

业务操作由组织单位执行。这些组织单位执行的一些操作和服务将得到应用程序的支持。应用程序组件组织单元关系的映射是一个重要步骤，因为它可以实现以下操作：

• 将应用程序的使用分配给执行业务操作的组织单位
• 了解组织单位执行的业务服务和流程的应用程序支持要求
• 支持差距分析，确定是否缺少任何应用程序，从而需要创建应用程序
• 定义特定组织单位使用的应用程序集

应用程序/组织矩阵是一个二维表，一个轴上是逻辑/物理应用程序组件，另一个轴是组织单元。这两个实体之间的关系是许多需要验证的元模型关系的组合：

• 组织单位自身服务
• 属于组织单位的参与者使用服务
• 服务由逻辑/物理应用程序组件实现

角色/应用程序矩阵

角色/应用程序矩阵的目的是描述应用程序与企业内使用它们的业务角色之间的关系。组织中的人员与应用程序进行交互。在这种互动中，这些人承担着执行任务的特定角色；例如，产品购买者。
应用程序组件角色关系的映射是一个重要步骤，因为它可以实现以下操作：

• 将应用程序的使用分配给组织中的特定角色
• 了解支持该功能的业务服务和流程的应用程序安全要求，并检查这些要求是否符合当前政策
• 支持差距分析，确定是否缺少任何应用程序，从而需要创建应用程序
• 定义特定业务角色使用的应用程序集；在任何向基于角色的计算转变的过程中都是必不可少的角色/应用程序矩阵是一个二维表，一个轴上是逻辑应用程序组件，另一个轴是角色。

应用/功能矩阵

应用程序/功能矩阵的目的是描述企业内应用程序和业务功能之间的关系。业务职能由组织单位执行。一些业务功能和服务将由应用程序支持。应用程序组件功能关系的映射是一个重要步骤，因为它可以实现以下操作：

• 将应用程序的使用分配给它们支持的业务功能
• 了解所执行的业务服务和流程的应用程序支持要求
• 支持差距分析，确定是否缺少任何应用程序，从而需要创建应用程序
• 定义特定业务功能使用的应用程序集

应用程序/功能矩阵是一个二维表，一个轴上有逻辑应用程序组件，另一个轴是功能。这两个实体之间的关系是许多需要验证的元模型关系的组合：

• 功能受服务约束
• 服务由逻辑/物理应用程序组件实现

应用程序交互矩阵

应用程序交互矩阵的目的是描述应用程序之间的通信关系。应用程序交互的映射以矩阵形式显示，相当于接口目录或应用程序通信图。应用程序交互矩阵是一个二维表，表的行和列上都有应用程序服务、逻辑应用程序组件和物理应用程序组件。

该矩阵所描述的关系包括：

• ■ 应用程序服务消耗应用程序服务
• ■ 逻辑应用组件与逻辑应用组件通信
• ■ 物理应用组件与物理应用组件通信

应用程序通信图

应用程序通信图的目的是描述与元模型实体中应用程序之间的通信相关的所有模型和映射。它显示了应用程序组件和组件之间的接口。在适当的情况下，接口可以与数据实体相关联。在适当的情况下，应用程序可以与业务服务相关联。通信应该是合乎逻辑的，只应在架构相关的地方显示中间技术。

应用程序和用户位置图

应用程序和用户位置图显示了应用程序的地理分布。它可用于显示最终用户在哪里使用应用程序；在瘦客户端场景中执行和/或交付主机应用程序的位置分布；应用程序开发、测试和发布的位置分布等。

分析可以揭示合理化的机会，以及重复和/或差距。此图的目的是清楚地描绘业务用户通常与应用程序交互的业务位置，以及应用程序基础设施的托管位置。

该图允许：

• 确定充分支持可能在地理上分散的用户群体所需的包实例数量
• 估算软件包或其他软件的用户许可证的数量和类型
• 估算用户所需的支持水平和支持中心的位置
• 选择本地和远程支持企业用户/客户/合作伙伴所需的系统管理工具、结构和管理系统
• 对业务的技术组件进行适当的规划，即服务器规模和网络带宽等。
• 实施应用程序和技术架构解决方案时的性能考虑用户通常以各种方式与应用程序交互；例如：
• 支持日常业务运营
• 参与业务流程的执行
• 访问信息（查找、读取）
• 开发应用程序
• 管理和维护应用程序

应用程序用例图

应用程序用例图显示了应用程序服务的消费者和提供者之间的关系。应用程序服务由参与者或其他应用程序服务使用，应用程序用例图通过说明如何以及何时使用该功能，在描述应用程序功能方面提供了更丰富的内容。

应用程序用例图的目的是帮助描述和验证参与者及其角色与应用程序之间的交互。随着架构的发展，用例可以从功能信息演变为包括技术实现细节。

应用程序用例也可以在更详细的系统设计工作中重复使用。

企业可管理性图

企业可管理性图显示了一个或多个应用程序如何与支持解决方案运营管理的应用程序和技术组件交互。

此图实际上是应用程序通信图上的过滤器，专门用于企业管理类软件。

分析可以揭示组织IT服务管理运营中的重复和差距以及机会。

流程/应用实现图

流程/应用程序实现图的目的是清楚地描述当多个应用程序参与执行业务流程时的事件顺序。它通过添加任何排序约束以及批处理和实时处理之间的切换点来增强应用程序通信图。

它将确定可以简化的复杂序列，并确定架构中可能的合理化点，以便为业务用户提供更及时的信息。它还可以识别可以减少应用程序之间交互流量的流程效率改进。

软件工程图

软件工程图从开发的角度将应用程序分解为包、模块、服务和操作。在规划迁移阶段以及分析机会和解决方案时，它可以进行更详细的影响分析。它非常适合管理复杂开发环境的应用程序开发团队和应用程序管理团队。

应用程序迁移图

应用程序迁移图标识了从基线到目标应用程序组件的应用程序迁移。它通过精确显示迁移阶段之间需要映射的应用程序和接口，可以更准确地估计迁移成本。

它将确定临时应用程序、临时区域和支持迁移所需的基础设施（例如，并行运行环境等）。

软件分布图

软件分布图显示了应用软件的结构和分布方式。它在系统升级或应用程序整合项目中很有用。此图显示了物理应用程序如何跨物理技术分布以及该技术的位置。

这使我们能够清楚地了解软件是如何托管的，同时也使托管操作人员能够了解应用程序软件在安装后是如何维护的。

3.6.6 D阶段：技术架构

以下部分描述了可以在阶段D（技术架构）中创建的目录、矩阵和图表，如TOGAF标准——架构开发方法中所述。

技术标准目录

技术标准目录记录了整个企业商定的技术标准，包括技术、版本、技术生命周期和技术更新周期。根据组织的不同，这可能还包括位置或业务领域特定的标准信息。

此目录提供了正在部署或可以部署的企业标准技术的快照，也有助于识别整个企业中的差异。技术标准目录包含以下元模型实体：

• 技术服务
• 逻辑技术组件
• 物理技术组件

如果目前有技术标准，请将其应用于技术组合目录，以获得技术标准合规性的基线视图。

技术组合目录

本目录的目的是识别和维护整个企业中使用的所有技术的列表，包括硬件、基础设施软件和应用软件。商定的技术组合支持技术产品和版本的生命周期管理，也构成了技术标准定义的基础。

技术组合目录为其余矩阵和图表提供了基础。它通常是技术架构阶段的起点。

技术注册和存储库也从基线和目标的角度为该目录提供输入。

目录中的技术应按照企业中使用的定义分类法进行分类，例如TOGAF TRM——见TOGAF®系列指南：

TOGAF™技术参考模型（TRM）——必要时进行调整，以适应使用中的技术产品的分类。
技术组合目录包含以下元模型实体：

• 技术服务
• 逻辑技术组件
• 物理技术组件

应用/技术矩阵

应用程序/技术矩阵记录了应用程序到技术平台的映射。

该矩阵应与一个或多个平台分解图对齐并互补。

应用/技术矩阵显示：

• 逻辑/物理应用程序组件
• 服务、逻辑技术组件和物理技术组件
• 物理技术组件

实现物理应用组件关系

环境和位置图

环境和位置图描述了哪些位置承载哪些应用程序，标识了在哪些位置使用哪些技术和/或应用程序，并最终标识了业务用户通常与应用程序交互的位置。

此图还应显示不同部署环境的存在和位置，包括非生产环境，如开发和预生产环境。

平台分解图

平台分解图描述了支持信息系统架构操作的技术平台。该图涵盖了基础设施平台的各个方面，并概述了企业的技术平台。该图可以扩展，将技术平台映射到特定功能或流程区域内的适当应用程序组件。此图可能显示规格细节，如产品版本、CPU数量等，也可能只是提供技术环境概述的非正式“眼图”。

该图应清楚地显示企业应用程序。每个应用领域的技术平台可以进一步分解如下：

■ 硬件：
— 逻辑技术组件（带属性）
— 物理技术组件（带属性）
■ 软件：
— 逻辑技术组件（带属性）
— 物理技术组件（带属性）

根据企业架构工作的范围，可能会涉及其他技术跨平台信息（例如通信、电信和视频信息）。

工艺流程图

处理图侧重于可部署的代码/配置单元以及如何将这些单元部署到技术平台上。部署单元表示业务能力、服务或应用程序组件的分组。处理图解决了以下问题：

• 哪些应用程序组件需要分组以形成部署单元
• 一个部署单元如何与另一个（局域网、广域网和适用协议）连接/交互
• 应用程序配置和使用模式如何为不同的技术组件生成负载或容量要求部署单元

组织和分组取决于表示层、业务逻辑和数据存储层的分离问题以及组件的服务级别要求。例如，表示层部署单元根据以下内容进行分组：

• 提供用户界面或用户访问功能的应用程序组件
• 按位置和用户角色区分的应用程序组件

确定如何将应用程序组件组合在一起需要考虑几个因素。每个部署单位由子单位组成，例如：

• 安装：包含可执行代码或包配置的部分（如果是包）
• 执行：应用程序组件及其在运行时的关联状态
• 持久性：表示应用程序组件持久状态的数据

最后，这些部署单元部署在专用或共享技术组件（工作站、web服务器、应用服务器或数据库服务器等）上。值得注意的是，技术处理会影响服务定义和粒度，并对其产生影响。

网络计算/硬件图

从大型机向客户端-服务器系统的转型开始，后来随着电子商务和J2EE的出现，大型企业主要转向具有防火墙和非军事区的高度基于网络的分布式网络计算环境。目前，大多数应用程序都有一个web前端，查看这些应用程序的部署架构，在网络环境中发现三个不同的层是很常见的；即web表示层、业务逻辑或应用层和后端数据存储层。在共享和公共基础设施环境中部署和托管应用程序是一种常见的做法。

因此，在开发和生产环境中记录逻辑应用程序和支持应用程序的技术组件（如服务器）之间的映射变得非常关键。此图的目的是显示分布式网络计算环境中逻辑应用程序组件的“部署”逻辑视图。由于以下原因，该图很有用：

• 了解在分布式网络计算环境中部署了哪个应用程序
• 建立对这些技术组件的授权、安全性和访问权限
• 了解在问题解决和故障排除过程中支持应用程序的技术架构
• 隔离应用程序遇到的性能问题，确定是与应用程序代码相关还是与技术平台相关，并对特定的物理技术组件进行必要的升级
• 当新技术可用时，确定优化领域，最终降低成本
• 启用应用程序/技术审计，并证明符合企业技术标准
• 作为引入技术架构变更的重要工具，从而支持有效的变更管理
• 建立可追溯性并更改应用程序端点地址，同时将应用程序从共享环境移动到专用环境，反之亦然

可以适当地定义图表的范围，以覆盖特定的应用程序、业务功能或整个企业。如果选择在企业级开发，那么网络计算环境也可以以与应用程序无关的方式进行描述。

网络和通信图

网络和通信图描述了技术架构中这些资产之间的通信方式——发送和接收信息的方法；只要在前面的架构中选择包解决方案对应用程序之间的通信提出了具体要求。

网络和通信图将采用客户端和服务器组件之间的逻辑连接，并确定物理实现这些连接所需的网络边界和网络基础设施。它不描述信息格式或内容，但将解决协议和容量问题。

3.6.7 E阶段：机遇与解决方案

以下部分描述了在TOGAF标准——架构开发方法中描述的E阶段（机会和解决方案）中可能创建的
目录、矩阵和图表。

项目上下文图

项目上下文图显示了作为更广泛的转型路线图的一部分要实现的工作包的范围。项目上下文图将工作包链接到将被添加、删除或受项目影响的组织、功能、服务、流程、应用程序、数据和技术。项目上下文图也是项目组合管理和项目动员的宝贵工具。

效益图

效益图显示了架构定义中确定的机会，根据其相对规模、效益和复杂性进行分类。利益相关者可以使用此图对已识别的机会进行选择、优先级排序和排序决策。

3.6.8 需求管理

以下部分描述了可以在TOGAF标准——架构开发方法中描述的需求管理阶段创建的目录、矩阵和图表。

需求目录

需求目录记录了企业为实现其目标需要做的事情。架构（architecture）项目产生的需求通常通过在E阶段（机会和解决方案）确定和范围的变更计划来实现。需求也可以用作质量保证工具，以确保特定的架构适合目的（即架构可以满足所有确定的需求）。

需求目录包含以下元模型实体：

• 需求
• 假设
• 约束条件
• 差距