基于EA的 ArchiMate® 简介

作者： SPARX SYSTEMS；翻译：李澎涛（火龙果软件工程）

ArchiMate ® 是一种用于描述企业架构的图形语言和开放标准，由 The Open Group ® 开发和维护。 它可用于创建广泛的视点，每个视点都与不同的项目和业务利益相关者相关。 这些支持业务架构师、数据架构师、解决方案架构师、基础架构师和企业架构师的活动。

它有什么作用？

ArchiMate 用于描述组织的架构——特别是他们的业务流程、组织结构、信息流、IT 系统和技术基础设施。

它有什么好处？

• ArchiMate 被设计为简便的、明确的和适用的。
• 帮助澄清和可视化领域之间的关系 - 业务、应用程序和技术。
• 帮助设计、评估和交流领域之间的决策和变更的结果。
• 鼓励跨架构模型领域的一致性。
• 允许架构师确定和规划变更的潜在影响。

它是如何做到的？

ArchiMate 框架的核心维度分为层和方面。

ArchiMate 核心框架的三层代表了企业可以描述的层次：

核心框架层

ArchiMate 中的各个方面对这些层中存在的人员、流程和事物进行了广泛的建模。

完整的 ArchiMate 框架

自 ArchiMate 1.0 版发布以来，The Open Group 扩展了其框架以提供企业架构和业务战略之间的额外关联。

完整的 ArchiMate 框架添加了额外的层，以及动机方面：

颜色的使用

ArchiMate 元模型使用颜色来区分层和方面。 可以在整个模型中自由使用相关的颜色来区分和强调某些元素。 ArchiMate 模型中颜色的使用完全由建模者自行决定。

图层

黄色：业务层元素

蓝色：应用层元素

绿色：技术层元素

方面

白色：抽象（不可实例化）

概念 浅灰色：被动结构

中灰色：行为

深灰色：活动结构

与其他标准的关系

ArchiMate 补充了其他建模标准，可与 ArchiMate 结合使用以帮助构建您的企业的整体视图。 复合元素可用于链接和单击建模域。 例如，ArchiMate 业务层中的业务流程可以链接到 BPMN 业务流程图，显示流程的详细信息，包括流程中的事件、活动和决策。 同样，内部设计和构建的应用程序组件可以链接到 UML 模型以定义应用程序支持的用例和 UML 类图来建模内部设计以及动态模型（例如序列图）以了解类集成。

TOGAF

ArchiMate 语言与 TOGAF 框架有共同的视点。 虽然视点不是一对一的映射，但核心语言与 TOGAF 的架构开发方法 (ADM) 密切相关。 这个共同的基础使 TOGAF 和 ArchiMate 在描绘架构和与利益相关者沟通时成为有效的组合。

Sparx Systems Enterprise Architect 已通过 TOGAF 9.1 认证。 阅读有关 TOGAF 支持的更多信息

BPMN

ArchiMate 支持在更广泛的环境中对高级内部流程和工作流进行建模。 更具体的业务流程建模语言（如 BPMN）可用于提供详细的子流程和任务建模，直至可执行级别。 Enterprise Architect 为业务流程建模和 BPMN 标准提供了广泛的功能。 在连接 ArchiMate 和 BPMN 概念时，Enterprise Architect 提供了复合元素，这些元素使用点击功能将 ArchiMate 元素与更细粒度的工作流（如 BPMN）连接起来。 这向模型消费者表明存在包含其他元素的基础模型结构。

UML

Enterprise Architect 在 UML 2 规范中有坚实的基础。 Enterprise Architect 使用配置文件来支持 ArchiMate 和 UML 的可视化建模语言。 由于这种底层模型结构，UML 和像 ArchiMate 这样的建模语言可以在同一个企业模型中紧密且无缝地共存。 在同一建模环境中使用 ArchiMate 和 UML 提供了一种使用 ArchiMate 记录更高级别架构的方法，以及用于创建详细设计组件的 UML。 熟悉 UML 的开发人员会发现 ArchiMate 的技术模型直观易懂。

Enterprise Architect 中的建模

Enterprise Architect 支持 ArchiMate，具有集成的、可追溯的图表。 ArchiMate 标准中的层有一个单独的工具箱 - 业务、应用程序、技术、动机和实施。 此外，每个工具箱都针对语言的不同方面显示单独的页面 - 主动结构、行为和被动结构。 这为不同层中不同类型的元素提供了清晰的区分，例如业务服务、应用程序服务、技术服务。

使用模型模式

模型模式是构建新模型的一种简单方法，它涵盖了构建 ArchiMate 模型所需的各种架构视图。 Enterprise Architect 模型向导中提供的 ArchiMate 模式如下...

基本视点

组织视点

组织视点（Organization Viewpoint）模式创建元素和图表来描述组织或实体或组织的一部分（如部门）的角色和参与者 。 元素以嵌套结构表示。

讨论

为企业、流程和领域架构师、经理、员工、股东和其他关注能力、权限和责任识别等方面的人提供设计、决策和通知视图

它通常在定义企业架构的初始阶段创建（或导入），随后可以被任何努力使用。 许多其他视点和模型将使用此视图中的元素。

以下是使用此模式时您可能想要做的一些事情的列表。

• 更改图表的名称以适应计划。
• 更改业务参与者的名称以适应计划。
• 创建其他业务参与者并根据需要添加其他关系。

以下是使用此模式后您可能希望执行的后续步骤的列表。

• 将业务参与者与模型中的其他元素相关联，例如能力或业务流程，以显示责任、治理或其他关系。
• 使用关系矩阵来可视化关系。
• 使用讨论、聊天和评论等协作工具来吸引其他建模者。
• 使用自动文档生成器生成模型和图表的文档。
• 根据需要创建问题、决策、变更和任务等维护项目。

业务流程合作视点

业务流程合作视点（Business Process Cooperation Viewpoint）模式创建描述 业务流程的元素和图表，显示它们如何相互关联以及如何与环境关联。 这包括与业务服务和业务对象以及执行流程或受其影响的角色和参与者的关系。

图 2： 业务流程合作视点

讨论

为流程和领域架构师、运营经理和其他关注业务流程之间的依赖关系、一致性和完整性、职责等方面的人员提供设计视图。

它可用于在其上下文中可视化业务流程的高级设计，并提供流程依赖关系的视图以及与其他元素的关系，这将有助于利益相关者，如运营经理和流程分析团队。

以下是使用此模式时您可能想要做的一些事情的列表。

• 更改图表的名称以适应计划。
• 更改流程、业务对象、业务事件、业务服务和其他元素的名称以适应计划。
• 创建其他流程、业务对象、业务事件、业务服务和其他元素以适应计划。
• 根据需要创建其他关系。

以下是使用此模式后您可能希望执行的后续步骤的列表。

• 将流程与模型中的其他元素相关联，包括：能力和应用层元素。
• 使用关系矩阵来可视化关系。
• 使用讨论、聊天和评论等协作工具来吸引其他建模者。
• 使用自动文档生成器生成模型和图表的文档。
• 根据需要创建问题、决策、变更和任务等维护项目。

产品视点

产品 视点（Product Viewpoint）模式创建元素和图表来描述产品为外部各方（如客户或其他利益相关者）提供的价值任何数量的合同或其他协议。 提供该产品的渠道（接口）以及与该产品相关的事件也可以在该视点中表示。

图 1. 显示了一个业务层图，其中包含一个位于中心的产品，这些产品与以下各项相关：价值、合同、业务接口。

讨论

为产品开发人员、产品经理、流程和领域架构师以及其他关注产品开发或企业产品提供的价值等方面的人员提供设计视图。

它通常用于产品开发，以设计和指定满足客户或其他利益相关者期望的产品。 这通常通过分析可以组合在一起的现有服务或通过创建产品所需的附加服务来完成。 它将为业务流程架构师和其他需要为要实现的产品设计和提供业务流程和技术能力的人形成一个有价值的定义和规范。

以下是使用此模式时您可能想要做的一些事情的列表。

• 更改图表的名称以适应计划。
• 更改产品名称和其他元素以适应倡议。
• 创建附加值、合同、业务接口、业务角色和应用程序服务，并根据需要添加其他关系。
• 根据需要创建其他关系。

以下是使用此模式后您可能希望执行的后续步骤的列表。

• 将产品元素与模型中的其他元素相关联，包括和能力。
• 使用关系矩阵来可视化关系。
• 使用讨论、聊天和评论等协作工具来吸引其他建模者。
• 使用自动文档生成器生成模型和图表的文档。
• 根据需要创建问题、决策、变更和任务等维护项目。

应用合作视点

应用程序合作视点（Application Cooperation Viewpoint）模式创建元素图 ，描述应用程序组件及其位置、它们提供或使用的服务以及它们之间流动的信息之间的关系。

图 1. 显示了一个应用层图，其中包含许多位置，这些位置包含通过依赖关系连接的应用程序组件。

讨论

为企业、流程、应用程序和领域架构师以及其他关注应用程序之间的关系和依赖关系、服务的编排/编排、一致性和完整性、降低复杂性等方面的人员提供设计视图。

它通常用于创建组织的应用程序环境的概述。 该视点还用于表达服务的（内部）合作或编排，这些服务共同支持业务流程的执行。

以下是使用此模式时您可能想要做的一些事情的列表。

• 更改图表的名称以适应计划。
• 更改位置和应用程序组件的名称以适应计划。
• 创建其他位置和应用程序组件并根据需要添加其他关系。

以下是使用此模式后您可能希望执行的后续步骤的列表。

• 将位置和应用程序组件与模型中的其他元素相关联。
• 使用关系矩阵来可视化关系。
• 使用讨论、聊天和评论等协作工具来吸引其他建模者。
• 使用自动文档生成器生成模型和图表的文档。
• 根据需要创建问题、决策、变更和任务等维护项目。

应用使用视点

应用程序使用视点（Application Usage Viewpoint ）模式创建元素和图表，描述应用程序服务和实现它们的应用程序如何用于支持任意数量的业务流程 。 它还可以显示实现服务的应用程序之间的关系。

图 1.显示一个应用层图，其中包含一个业务流程，其中包含子流程和相关的业务对象、应用程序服务和实现这些服务的应用程序组件。

讨论

为企业、流程和应用程序架构师、运营经理和其他关注一致性和完整性、降低复杂性等方面的人员提供设计和决策视图。

在应用程序设计学科中识别或指定业务流程和其他应用程序所需的服务很有用。 或者，它可以在通过识别可用的应用程序服务来设计业务流程时使用。 负责流程的运营经理也可以使用它来识别和了解流程所需的应用程序服务和应用程序。

以下是使用此模式时您可能想要做的一些事情的列表。

• 更改图表的名称以适应计划。
• 更改业务流程、业务对象、应用程序服务和应用程序组件的名称以适应计划。
• 创建其他业务流程、业务对象、应用程序服务和应用程序组件，并根据需要添加其他关系。

以下是使用此模式后您可能希望执行的后续步骤的列表。

• 将流程与模型中的其他元素相关联，包括：能力和应用层元素。
• 将应用程序组件与其他技术层元素相关联。
• 使用关系矩阵来可视化关系。
• 使用讨论、聊天和评论等协作工具来吸引其他建模者。
• 使用自动文档生成器生成模型和图表的文档。
• 根据需要创建问题、决策、变更和任务等维护项目。

实施和部署视点

实施和部署视点（Implementation and Deployment Viewpoint）模式创建元素和图表，将 程序和项目与它们实施的架构部分相关联。 该视图允许根据已实现的高原或受影响的单个架构元素对计划、项目、项目活动的范围进行建模。 此外，可以通过注释关系来指示元素受到影响的方式。

图 1. 显示部署视图，其中节点和网络的转换拓扑在不同高原的上下文中描述。

讨论

为应用程序架构师和领域架构师以及其他关注应用程序平台结构及其与支持技术的关系等方面的人提供设计视图。

以下是使用此模式时您可能想要做的一些事情的列表。

• 更改包和图表的名称以适应计划。
• 更改高原的名称以适应倡议。
• 更改节点和通信网络的名称。
• 创建额外的 Plateaus 并根据需要添加其他关系。

以下是使用此模式后您可能希望执行的后续步骤的列表。

• 创建与此视点中的元素最终追溯到的上游模型元素的跟踪关系。
• 创建有助于将图表中包含的信息传播给其他团队成员的文档。

技术视点

技术视点模式（Technology Viewpoint）创建元素和图表来描述支持应用层的 软件和硬件技术元素，例如物理设备、网络或系统软件，例如中间件操作系统、数据库和其他容器。

图 1. 显示了描述两个不同位置的技术的技术层图。 由通信网络连接并最终共同提供技术服务所描述的服务的节点和设备的区域数量。

讨论

为基础架构架构师、运营经理和其他关注基础架构稳定性、安全性、依赖性、成本等方面的人员提供设计视图。

它通常在设计阶段使用，但也可以在任何时候用于描述或记录支持应用层的软件和硬件技术元素之间的关系。

以下是使用此模式时您可能想要做的一些事情的列表。

• 更改包和图表的名称以适应计划。
• 更改地点的名称以适应倡议。
• 更改节点和通信网络的名称。
• 创建其他位置、节点、设备、工件和通信网络，并根据需要添加其他关系。

以下是使用此模式后您可能希望执行的后续步骤的列表。

• 创建与此视点中的元素最终追溯到的上游模型元素的跟踪关系。
• 创建有助于将图表中包含的信息传播给其他团队成员的文档。

技术使用视点

技术使用视点（Technology Usage Viewpoint）模式创建的 元素显示了软件和硬件技术如何支持应用程序：技术服务由设备提供； 系统软件和网络被提供给应用程序。 该视点在性能和可扩展性分析中起着重要作用，因为它将物理基础设施与应用程序的逻辑世界联系起来。

图 1. 显示将应用程序组件与技术服务相关联的技术层图，并最终与实现服务的节点和系统软件相关联。

讨论

为应用程序架构师、基础架构架构师、运营经理和其他关注依赖关系、性能和可伸缩性等方面的人员提供设计视图。 当架构师需要分析和指定使用它的应用程序的基于基础架构的的性能和质量要求时，它将提供帮助。

它通常在设计阶段使用，但也可以在任何时候用于描述或记录软件和硬件技术如何支持应用程序：技术服务由设备提供； 系统软件和网络被提供给应用程序。

它通常在设计阶段使用，但也可以在任何时候用于描述或记录支持应用层的软件和硬件技术元素之间的关系。

以下是使用此模式时您可能想要做的一些事情的列表。

• 更改包和图表的名称以适应计划。
• 更改节点、系统软件、技术服务和应用程序组件的名称以适应计划。
• 创建额外的节点、系统软件、技术服务和应用程序组件，并根据需要添加其他关系。

以下是使用此模式后您可能希望执行的后续步骤的列表。

• 创建与此视点中的元素最终追溯到的上游模型元素的跟踪关系。
• 创建有助于将图表中包含的信息传播给其他团队成员的文档。

信息结构视点

信息结构视点（Information Structure Viewpoint）模式创建元素，这些 元素根据数据类型或信息元素显示企业或特定业务流程或应用程序中使用的信息结构。 它将帮助可视化从业务级别到应用程序级别的信息，再到实现数据库和其他持久存储的基础架构元素。

图 1. 此业务层图对含义和所使用的业务对象、数据对象和工件的关系进行建模。

讨论

为领域和信息架构师以及其他关注所用数据和信息的结构和依赖关系、一致性和完整性等方面的人员提供设计视图。

它通常在设计阶段使用，但也可以在任何时候用于描述或记录各种形式的信息之间的关系，从业务对象、数据对象到存在于物理模式级别的工件。

以下是使用此模式时您可能想要做的一些事情的列表。

• 更改包和图表的名称以适应计划。
• 更改含义和表示元素的名称以适应倡议。
• 更改业务对象、数据对象和工件的名称以适应计划。
• 创建其他业务对象、数据对象和工件，并根据需要添加其他关系。

以下是使用此模式后您可能希望执行的后续步骤的列表。

• 创建与此视点中的元素最终追溯到的上游模型元素的跟踪关系。
• 创建有助于将图表中包含的信息传播给其他团队成员的文档。

服务实现视点

服务实现视点（Service Realization Viewpoint）模式创建的 元素显示了一个或多个业务服务是如何由底层流程（有时是应用程序组件）实现的。 因此，它在业务产品视图和业务流程视图之间架起了一座桥梁。 它提供了一个或多个业务流程的“外部视图”。

图 1. 显示了一个业务层图，描述了业务服务和实现它们的业务流程之间的关系，包括最终实现流程的应用程序服务。

讨论

为流程和领域架构师、产品和运营经理以及其他关注业务流程的附加值、一致性和完整性、责任等方面的人提供设计视图。

它通常在设计阶段用于显示业务流程上下文的视图，但也可以在任何时候用于描述或记录业务流程和实现它们的应用程序服务之间的关系。

以下是使用此模式时您可能想要做的一些事情的列表。

• 更改包和图表的名称以适应计划。
• 更改角色和业务服务元素的名称以适应计划。
• 更改业务流程和应用程序服务的名称以适应计划。

以下是使用此模式后您可能希望执行的后续步骤的列表。

• 创建与此视点中的元素最终追溯到的上游模型元素的跟踪关系。
• 创建有助于将图表中包含的信息传播给其他团队成员的文档。

物理视点

物理视点（Physical Viewpoint）模式创建包含可以创建、使用、存储、移动或转换材料的设备（一个或多个物理机器、工具或仪器）的元素和图表 。 它还描述了设备如何通过配电网络连接，并允许可视化分配给设备的其他活动元素。

图 1. 显示了一个技术层图，该图显示了具有两个设施的位置，其中一个节点和一个设备通过通信网络连接。

讨论

该模式的目的是允许基础架构架构师、运营经理或其他利益相关者创建或查看包含可以创建、利用、存储、重新定位或转换材料的设备（一个或多个物理机器、工具或仪器）的模型. 它还描述了设备如何通过配电网络连接，以及为设备分配了哪些其他有源元件。

它通常在企业架构被阐明时构建，可以帮助规划业务架构和实施的许多方面，包括用作识别投资领域的热图。

以下是使用此模式时您可能想要做的一些事情的列表。

• 更改包和图表的名称以适应计划。
• 更改位置和设施的名称以适应倡议。
• 更改节点、设备设备和材料的名称以适应倡议。
• 更改通信网络和配电网络的名称以适应该倡议。

以下是使用此模式后您可能希望执行的后续步骤的列表。

• 创建与此视点中的元素最终追溯到的上游模型元素的跟踪关系。
• 创建有助于将图表中包含的信息传播给其他团队成员的文档。

分层视点

分层视图（Layered Viewpoint）模式创建了许多元素和图表，允许在单个图表中可视化企业架构的多个层 。 使用 Grouping 元素的分区允许在专用层中表示诸如业务流程之类的元素，并在服务层中表示诸如应用程序服务之类的元素。 可以包含任意数量的层，但是当专用层和服务层交错时，该图最具表现力。

图 1. 显示使用 Grouping 元素将元素放入有意义的组的业务层图。

讨论

为企业架构师、流程架构师、应用程序架构师、基础架构架构师和领域架构师以及其他关注一致性、复杂性降低、变更影响、灵活性等方面的人提供设计视图。

该视点的主要用途是在单个图中提供架构的概述。 它在需要对所有模型或多个模型进行完整或整体视图的任何情况下都很有用，例如在变更分析、性能分析的影响或试图理解各个层中概念之间的关系时。

以下是使用此模式时您可能想要做的一些事情的列表。

• 更改包和图表的名称以适应计划。
• 更改分组元素的名称以适应计划。
• 更改图表中所有元素的名称以适应计划。
• 根据需要创建其他元素并添加其他关系。

以下是使用此模式后您可能希望执行的后续步骤的列表。

• 创建与此视点中的元素最终追溯到的上游模型元素的跟踪关系。
• 创建有助于将图表中包含的信息传播给其他团队成员的文档。

动机视点

利益相关者视点

利益相关 者视点模式（Stakeholder Viewpoint）创建利益相关者、变革的内部和外部驱动因素，以及对这些驱动因素的评估（根据优势、劣势、机会和威胁）。 此外，可以描述与解决这些问题和评估的初始（高级）目标的链接。 这些目标构成了工程过程的基础，包括目标细化、贡献和冲突分析，以及实现目标的的推导。

图 1. 显示通过评估将目标和驱动因素与利益相关者相关的动机图。

讨论

该模式的目的是允许建模者创建利益相关者、变革驱动因素（内部和外部）的表示，以及驱动因素和解决目标的评估（根据优势、劣势、机会和威胁）关注和评估。

该模式通常在企业架构的早期计划或定义中使用，以确保为管理规程奠定正确的基础。

以下是应用模式时可用的一些后续步骤的列表。

• 更改利益相关者、驱动因素、评估和目标的名称以适应倡议。
• 根据需要添加额外的利益相关者、驱动因素、评估和目标。

目标实现视点

目标实现视点（Goal Realization Viewpoint）模式创建元素和图表，对 目标之间的关系进行建模，包括分解为子目标。 目标是通过一个结果来实现的，该结果是由一个表现得像一个更抽象和更广泛的要求的原则实现的。 最后，原则是通过指示系统必须表现出的特定属性的要求来实现的。

图 1. 显示目标的分解及其与原则和要求的关系。

讨论

为业务经理、企业和技术架构师、业务分析师、经理和其他利益相关者提供设计和决策视图，他们关心目标（及其子目标）之间的关系以及通过和约束实现这些目标的方式定义系统必须展示的属性。

该模式通常用于计划的战略和业务设计阶段。 目标及其分解以及与原则的关系可以在早期建模，并且随着计划的进展，对的实现更常见地建模。

以下是使用此模式时您可能想要做的一些事情的列表。

• 更改目标、原则和要求的名称以适应倡议。
• 添加其他目标、原则和要求，并根据需要添加其他关系。

以下是使用此模式后您可能希望执行的后续步骤的列表。

• 进一步将分解为更详细的表达式，为进一步分析做准备。
• 与适当的利益相关者解决目标之间的冲突或重叠，确保任何更改都满足整个利益相关者群体的。

目标贡献视点

目标贡献视点（Goal Contribution Viewpoint）模式从 动机方面创建元素和图表，模拟目标、要求、原则和约束对彼此的影响。

图 1. 显示了一个动机图，显示了目标、要求和原则之间的许多影响关系。

讨论

该模式的目的是允许业务经理、业务和分析、架构师和其他利益相关者对目标、和原则之间的影响关系进行建模和可视化。

该模式通常在分析阶段使用，一旦目标至少被定义并部分细化为子目标并且已经开始定义。 它还可用于分析目标对彼此的影响或检测利益相关者目标之间的冲突，从而使它们得到解决和管理。

以下是使用此模式时您可能想要做的一些事情的列表。

• 更改目标、要求和原则的名称以适应倡议。
• 根据需要添加其他目标、要求和原则。
• 添加影响关系并通过更改关系名称更改现有关系以反映影响程度（+，-）。

以下是使用此模式后您可能希望执行的后续步骤的列表。

• 将能力与驱动因素和目标联系起来，以确保能力具有业务目的。
• 根据需要将功能与应用程序和业务服务、功能或流程相关联。

原则的视点

原则视点（Principles Viewpoint）模式创建元素和图表来模拟目标和原则之间的 关系。 聚合关系对目标的分解进行建模，实现关系对原则如何与一个或多个目标相关联进行建模。

图 1. 显示了与原则及其实施目标相关的动机图。 颜色已应用于元素以使图表更具吸引力。

讨论

该模式的目的是允许企业和信息技术架构师以及其他利益相关者将原则与目标联系起来。 然后，这些原则将构成阐明要求的基础。

该模式通常用于计划的早期阶段，并且通常会构成被许多计划重用的企业架构的一部分。

以下是使用此模式时您可能想要做的一些事情的列表。

• 更改目标和原则的名称以适应倡议。
• 根据需要添加其他目标和原则。

以下是应用模式时可用的一些后续步骤的列表。

• 目标可以相互关联，以显示利益相关者之间的竞争力量。
• 原则可以相互关联以显示架构的冲突。
• 目标可以与利益相关者相关，以显示其出处。
• 原则可能与它们概括的要求相关。

需求实现的视点

需求实现视点（Requirements Realization Viewpoint）模式创建元素和图表，将目标的 实现建模为和约束，然后这些如何由业务和应用程序服务等核心元素实现。 引入了颜色以增加图表的吸引力并区分元素类型。

图 1. 显示目标、与业务和应用程序服务的核心元素之间的关系。

讨论

该模式的目的是允许企业和业务和技术架构师、业务分析师、经理对表示服务的元素和实现这些服务的元素分解和实现的方式进行建模和可视化。

该模式通常在分析阶段使用，此时目标已经定义，和约束已经明确，业务服务和流程以及应用程序服务和组件已经设计。 它也可以在应用程序或过程重新评估阶段使用。

以下是使用此模式时您可能想要做的一些事情的列表。

• 更改目标、约束和要求、业务角色以及业务和应用程序服务的名称以适应计划。
• 添加其他目标、约束和要求、业务角色以及业务和应用程序服务，并根据需要添加其他关系。

以下是使用此模式后您可能希望执行的后续步骤的列表。

• 将驱动因素和目标与其他利益相关者的驱动因素和目标联系起来，以确定需要解决的任何冲突或重叠。
• 根据需要将要求与应用程序和业务服务、功能或流程相关联。

动机视点

动机视点（Motivation Viewpoint ）模式创建元素和图表， 从给定利益相关者的角度完全涵盖动机方面，定义驱动因素、评估、许多目标和应用的原则以及限定原则所需的要求和约束。

图 1. 显示了一个动机图，其中包含从利益相关者和定义其目标的元素到指定系统必须表现出的行为的的细分。

讨论

该模式的目的是提供一个关于计划的激励方面的丰富视图，显示从高层利益相关者到的细分。 它为企业和业务以及技术架构师、业务分析师、经理和其他关注架构战略、策略和动机的利益相关者提供了一个视图。

该模式通常用于计划的分析阶段，以获得对和约束如何与利益相关者以及定义其目标的其他事物相关联的概览和洞察力。

以下是使用此模式时您可能想要做的一些事情的列表。

• 更改利益相关者、驱动程序、评估、目标、原则、约束和要求的名称以适应计划。
• 添加额外的利益相关者、驱动因素、评估、目标、原则、约束和要求，并根据需要添加其他关系。

以下是使用此模式后您可能希望执行的后续步骤的列表。

• 将驱动因素和目标与其他利益相关者的驱动因素和目标联系起来，以确定需要解决的任何冲突或重叠。
• 根据需要将要求与应用程序和业务服务、功能或流程相关联。

战略视点

战略视点

战略视点（Strategy Viewpoint）模式创建元素和图表，通过阐明行动过程以及实现它所需的能力和资源来模拟组织的战略意图，并提供建模的 结果

图 1. 显示了将若干资源分配给能力的图表，该能力实现了与行动过程相关的结果。

讨论

该模式的目的是允许业务和企业架构师通过将组织的战略方向与提供可证明结果的能力和资源相关联来从高层次建模组织的战略方向。

该模式通常在制定策略时使用，以确定它们将如何实现。 它可用于组织或其架构发展过程中的战略、行动方案和结果正在审查或修订的阶段。

以下是使用此模式时您可能想要做的一些事情的列表。

• 更改行动方案、成果能力和资源的名称以适应倡议。
• 根据需要添加额外的成果、能力和资源。

以下是使用此模式后您可能希望执行的后续步骤的列表。

• 将行动过程与目标联系起来。
• 根据需要将功能与应用程序和业务服务、功能或流程相关联。

能力地图视点

能力地图视点（Capability Map Viewpoint）模式创建元素和图表，允许 Capabilities 在嵌套层次结构中可视化 。 功能也嵌套在项目浏览器的层次结构中，允许它们的组轻松地从一个位置移动到另一个位置。 颜色已用于传达层次结构的级别。

图 1. 显示以嵌套层次结构表示的能力图，将颜色应用于三个级别以使图表更具吸引力。

讨论

该模式的目的是允许业务经理、企业和业务架构师以及其他战略利益相关者可视化和分类企业或其部分中存在或渴望的能力。 它构成了几乎所有其他建筑追求的基础。

该模式通常是在企业架构定义的早期创建的，并且构成了其他架构师进行的许多更详细工作的基础。 它也可以在组织或其架构发展的战略点上得到增强或改变。

以下是使用此模式时您可能想要做的一些事情的列表。

• 更改功能的名称以适应计划。
• 添加其他功能并根据需要重新分类。

以下是使用此模式后您可能希望执行的后续步骤的列表。

• 将能力与驱动因素和目标联系起来，以确保能力具有业务目的。
• 根据需要将功能与应用程序和业务服务、功能或流程相关联。

资源地图视点

资源地图视点（Resource Map Viewpoint）模式创建 了许多嵌套在三层中的 Resource元素 。 它允许业务架构师或其他利益相关者创建企业可用资源的结构化概览。 该地图通常显示整个企业的两个或三个级别的资源。

图 1. 显示了一个动机图，该图显示了许多嵌套资源，分为三个级别。

讨论

该模式的目的是允许业务架构师或其他利益相关者创建或查看资源的企业范围图以及它们在层次结构中如何相互关联。

它通常在企业架构被阐明时构建，可以帮助规划业务架构和实施的许多方面，包括用作识别投资领域的热图。

以下是使用此模式时您可能想要做的一些事情的列表。

• 更改包和图表的名称以适应计划。
• 更改资源的名称以适应计划。
• 根据需要更改嵌套级别。

以下是使用此模式后您可能希望执行的后续步骤的列表。

• 创建与此视点中的元素最终追溯到的上游模型元素的跟踪关系。
• 创建有助于将图表中包含的信息传播给其他团队成员的文档。

结果实现视点

结果实现视点（Outcome Realization Viewpoint ）模式创建元素和图表，这些元素和图表对核心元素如何交付高级业务价值进行建模。 该图有助于显示战略级别的业务元素（如价值和结果）如何通过交付该价值的基础元素（如能力、服务和组件）来实现。

图 1. 显示核心元素传递价值元素所表达的价值的方式，并表示为结果和由能力实现的行动过程，而能力又由应用程序服务和组件实现。

讨论

该模式的目的是允许业务经理、企业和业务架构师或其他利益相关者创建或查看一个模型，该模型显示了底层元素如何实现高级业务成果。

它通常在企业架构被阐明时构建，可以帮助规划业务架构和实施的许多方面，包括用作识别投资领域的热图。

以下是使用此模式时您可能想要做的一些事情的列表。

• 更改包和图表的名称以适应计划。
• 更改业务级别元素的名称以适应计划，包括：资源、价值、结果。
• 更改基础元素的名称以适应计划，包括应用程序服务和其他元素。

以下是使用此模式后您可能希望执行的后续步骤的列表。

• 创建与此视点中的元素最终追溯到的上游模型元素的跟踪关系。
• 创建有助于将图表中包含的信息传播给其他团队成员的文档。

实施和迁移视点

项目视点

项目视点（Project Viewpoint）模式创建元素和图表，其中包含对架构变更管理建模的元素。 这包括从基线到目标企业架构的过渡是复杂的，并且可能受到项目组合管理、项目管理和许多其他学科的限制。

图 1. 显示描述项目视点的实施和迁移图。

讨论

该模式的目的是允许运营经理、企业和 ICT 架构师、员工或其他利益相关者创建或查看描述从基线（当前状态）到目标（未来状态）转换的各个方面的模型。 这些元素包括：目标、工作包、实施事件、可交付成果、业务参与者、业务角色。

它通常在企业架构变更需要细化时构建，具有以下用途：

• 让战略团队提前了解企业变化。
• 为最终将引发更改的实施团队提供详细信息。
• 为需要了解更改将对资源产生的影响的运营经理提供详细信息。

以下是使用此模式时您可能想要做的一些事情的列表。

• 更改包和图表的名称以适应计划。
• 更改工作包、角色和实施事件的名称以适应计划。
• 根据需要创建其他元素。

以下是使用此模式后您可能希望执行的后续步骤的列表。

• 创建与此视点中的元素最终追溯到的上游模型元素的跟踪关系。
• 创建有助于将图表中包含的信息传播给其他团队成员的文档。

迁移视点

迁移视点（Migration Viewpoint）模式创建元素和图表，对从基线到目标企业架构的转换进行建模 。 高原代表了建筑在有限时间内存在的相对稳定的状态，而差距代表了两种状态之间差异的陈述。

图 1. 显示使用两个高原来描述架构的两种状态的实现和迁移图，其中差异由 Gap 元素描述。

讨论

该模式的目的是允许企业架构师、流程架构师、应用程序架构师、基础架构架构师和领域架构师、员工和其他利益相关者使用 Plateaus 和 Gap 元素对企业架构不同状态之间的转换进行建模。

它通常在企业架构发生变化时构建，可以帮助规划业务架构和实施的许多方面，包括用作识别投资领域的热图。

以下是使用此模式时您可能想要做的一些事情的列表。

• 更改包和图表的名称以适应计划。
• 更改 Plateaux 和 Gap 元素的名称以适应计划。
• 向元素添加属性和注释以更详细地描述更改。
• 根据需要创建其他元素，例如 Plateaus 和 Gap 元素。

以下是使用此模式后您可能希望执行的后续步骤的列表。

• 创建与此视点中的元素最终追溯到的上游模型元素的跟踪关系。
• 创建有助于将图表中包含的信息传播给其他团队成员的文档。

实施和迁移视点

实施和迁移视点（Implementation and Migration Viewpoint）模式创建元素和图表，这些元素和图表将程序和项目与它们实施的架构部分进行建模 。 该视图允许根据已实现的高原或受影响的单个架构元素对计划、项目、项目活动的范围进行建模。

图 1. 显示使用两个高原来描述架构的三种状态的实现和迁移图，其中差异由 Gap 元素描述。 可交付成果将高原与建筑元素联系起来。

讨论

该模式的目的是允许运营经理、企业和 ICT 架构师、员工或其他利益相关者创建或查看一个模型，该模型描述了转换与受影响或构成架构一部分的底层架构元素之间的关系。

它通常是在企业架构发生变化时构建的，可以帮助规划业务架构和实施的许多方面。

以下是使用此模式时您可能想要做的一些事情的列表。

• 更改包和图表的名称以适应计划。
• 更改 Plateaux Gap 和 Deliverable 元素的名称以适应该计划。
• 向元素添加属性和注释以更详细地描述更改。
• 根据需要创建其他元素，例如可交付成果和其他高原和差距元素。

以下是使用此模式后您可能希望执行的后续步骤的列表。

• 创建与此视点中的元素最终追溯到的上游模型元素的跟踪关系。
• 创建有助于将图表中包含的信息传播给其他团队成员的文档。