| 编辑推荐: |
| 原文来自hosiaisluoma.fi，由火龙果软件王玉翻译，文章以ArchiMate（3.x）的相关示例视图介绍了如何使用ArchiMate，，以帮助更好的理解ArchiMate的概念。 |
|
本文介绍的ArchiMate（3.x）示例视图是根据ArchiMate标准构建的一个分层框架（请参阅此处的
ArchiMate 3.0.1版）。这些示例视图说明了如何使用ArchiMate概念。一些示例可以用作设计模式。
ArchiMate示例视图
框架视图
这个视图代表了构建所有开发方面和相关图表的框架。视图可以根据具体情况进行修改。因此，该视图可以用于图表之间的导航。这个版本的视图是从ArchiMate
(3)框架中应用的。在这里引入动机是作为“层”而不是“方面”。
动机视图
动机视图
该视图可用于分析指导组织及其企业架构的设计或变更的动机或原因。这些动机分析是组织中所有变革活动或业务转型的起点。这种观点代表了发展努力的愿景——无论规模和范围是包括整个组织，还是仅仅是组织的一部分(如业务线)，还是单个计划或项目(解决方案级别)。注意:可以添加一个值，例如添加到结果(或任何其他归档元素)，以指示什么是真正的添加值！
动机元素基于商业动机模型（BMM）
使命 - 价值观 - 愿景观
该视图可用于表示组织的使命，愿景和核心价值观。使命表达了例如“组织的目的是什么，它实际上在做什么或打算做什么，它存在的主要原因是什么？”愿景是组织意图发展的未来状态。核心价值观支持愿景，塑造文化，反映组织的价值观。需要实现战略目标，以实现组织的愿景。
战略价值地图视图
此视图可用于组织策略的可视化。该观点包含战略价值要素，所有发展活动都必须直接或间接地从中得出。通过可视化战略价值，可以跟踪与实际战略执行相关的所有其他要素。通过这种观点，可以提供战略：可视化，传达和与现实相关联。
利益相关者分析视图
此视图可用于业务开发目的的利益相关者分析：变更的驱动因素是什么。首先确定相关的利益相关者，然后确定符合他们利益的变革驱动因素。“评估”概念可用于详细分析驾驶员，例如根据SWOT（优势，劣势，机会，威胁）方法。通常，可以从不同的视点创建不同的利益相关者视图。将大图拆分成较小图形的另一个原因是为了简化起见，使图表保持紧凑和可读性。
利益相关者观点
此视图可用于将利益相关方的驱动程序与业务目标相关联。目标是组织发展的关键要素。所有后续元素都应该追溯到所有变更活动的主要原因。
原则观点
风险与安全观
风险和安全视图。将风险和安全概念映射到归档。安全和数据保护事项是风险管理的一部分。这种建模方法涵盖了两者。
SWOT分析视图
目标视图
战略视图
战略视图
ArchiMate版本3现在支持与业务战略相关的概念，例如“行动过程”，“能力”和“资源”，可用于对组织的业务战略进行建模。这种观点的价值和重要性在于，组织的目标可以与战略相关联，以及如何通过能力将它们链接到企业架构中。该视图可用于应用“基于目标的战略模型”，其中目标构成层次结构，以便可以将更高级别的目标分解为更低级别的目标。
业务战略视图
商业动机模型（BMM）视图
需求视图
该视图可用于根据战略目标收集需求。这是将策略与实现联系起来：可以跟踪执行策略。
战略能力试图
此视图可用于基于 功能的规划（CBP）目的，以及其他ArchiMate概念，如“驱动程序”和“目标”，如下图所示。此视图可用于支持 策略规划（和执行）目的。因此，这种观点可以用于战略到能力阶段，可以包含在IT4IT的“战略到资产组合”中。
能力地图视图
此视图可用于概述组织功能：组织执行或可以执行的操作。
能力规划视图
该视图可用于例如基于能力的规划（CBP） 目的，即“战略与企业架构之间的联系”。此视图可用于例如将策略映射到所需功能，以及将功能映射到资源和其他构建块。
能力实现视图
价值流视图
价值流 - 能力交叉映射视图
价值链。这是一个扩展的例子，说明了能力如何支持(服务)价值流。这个视图可以用来定义为什么需要能力，它们与价值创造的联系是什么。
该视图包含在精益环境分析框架(LEAF)参考实现(链接)中。导航至“价值流”、“价值交付链”。
商业模式画布视图
这是A. Osterwalder 的商业模型画布（BMC）的基本形式，但它可以根据适当的情况进行变化。还有版本化方法，例如“服务模型画布”或“精益画布”。BMC可用于例如商业模型设计和创新。
使用ArchiMate建模BMC“有助于跟踪从业务需求到设计规范的需求。这有助于发现商业模式变化对建筑设计的影响。“[LO
Meertens et al。]
整体开发包括内置架构——对策略和业务模型分析的支持。这使得业务分析师和开发人员能够观察到，例如，业务模型支持策略的程度，以及业务模型如何适合组织，反之亦然。
如果BMC是在建模工具中建模的，这种方法的一个优点是BMC的所有元素都可以用在同一个模型库的其他视图中。当商业模式旋转时，所有的变化都是显而易见的。业务建模人员可以创建新的元素，如服务，或者利用存储库中所有现有的元素，如组织单元或资源。
概念画布视图
概念画布。BMC可以有不同的变化，如下所示。这个概念画布的布局与归档的分层方法相一致。
业务视图
业务架构层视图
在每一层中，都有几个元素的“映射”，这些元素在环境分析工具中进行管理，例如业务服务映射、流程映射等。在识别和引入地图后，这些元素可以用于其他图表(如分层视图)。地图的目的是将“企业资产”目录管理为“投资组合”(类似于想法、服务和项目等的投资组合)。)。电子分析工具通常为每个元素提供其他特性，例如属性或属性。这些可用于为每个元素提供附加信息。这种额外的信息也可以用于不同的分析目的。
每层可以有多个地图，例如如下：
业务层：业务服务，业务参与者，业务流程
应用层：应用服务，应用
技术层：技术服务，平台，技术等
此处介绍了一些示例业务层映射。
商业服务地图视图
此视图概述了组织的业务服务。这种视图可以用作“服务目录”或“服务组合”管理目的。确定组织为其客户提供的业务服务非常重要。此外，业务服务是建模所有底层组织流程和结构的起点。因此，业务服务是企业架构中最重要的元素。
业务流程地图视图
此视图可用作“流程图”，其中概述了组织的业务流程。
业务流程合作视图
该视图可用于例如对操作模型进行建模。
业务参与者地图视图
业务参与者可以是a)内部的，也可以是b)外部的。内部业务行为者是例如组织单位，外部业务行为者是例如客户、业务伙伴或与组织合作的其他利益相关方团体(例如公共部门组织或其他治理机构)。
业务参与者合作视图
两种使用场景如下：
1.企业内部视图：业务角色合作视角，描述内部业务角色如何合作，如何切换信息。
2.企业间视图：生态系统观点，描述组织运营的运营环境。生态系统是一个由组织和业务合作伙伴组成的网络，它们通过协作的互动进行合作。有供应商，分包商和其他B2B合作伙伴，客户等。
业务流程视图
该业务流程视图提供了“业务流程(或多个流程)的高级结构和组成、所提供的服务、参与者的指定角色以及业务流程所使用的信息”ArchiMate
2.1规范。该流程图包含“连接”元素，用于对流程中的“fork”和“join”进行建模。。
业务流程视图与业务角色作为流程的“Swimlanes” - 分层方法
注意！流程步骤（活动）嵌套在业务角色中（可视化为“泳道”），这意味着：这些业务角色分配给这些业务流程/流程步骤。因此，此视图是业务流程视图和分层视图的组合。
客户旅程地图视图
这种以客户为中心的观点专注于客户体验。这种“服务设计”相关的方法集中在要设计的服务的“从外到内”开发。这突出了服务和产品作为为客户创造价值的重要方面
- 并间接地为组织本身。客户旅程路径可用于客户价值流的可视化，其跨越多个应用服务和应用。
服务蓝图视图
这种观点以客户和服务为中心，但它也强调服务的“由内而外”部分。借助这种方法，服务驱动的开发可以识别将要设计的服务的潜在行为和结构影响。因此，这一观点补充了客户体验驱动的方法，包括流程和功能方面。
这种观点有几种变体。上面的这个例子侧重于层和元素之间的信息流。
用户故事视图
此视图可用于用户故事的可视化。
云服务模型视图
信息查看
信息可以在不同的抽象级别上建模如下：a）概念，b）逻辑和c）物理级别。上图说明了这些抽象级别。
概念数据模型视图
概念数据模型视图。
EA的信息体系结构包含业务对象，即业务流程中使用的概念。这些概念及其关系可以在概念数据模型中表示。
“服务”的概念
服务理念。
服务概念是存在一定的质疑的，因为它可以通过许多不同的方式理解。为明确区分哪种服务类型存在问题，良好做法是提及前缀：业务，应用程序或技术服务。根据ITIL，IT服务与生产服务相关。因此。IT服务最多映射到应用程序服务。
服务和产品
Product -concept可用作分组服务的复合元素。根据ArchiMate -specification：
“产品代表了一系列连贯的服务和/或被动结构元素，并附有一份合同/一套协议，作为一个整体提供给（内部或外部）客户。”
“产品可能聚合或组合业务服务，应用程序服务和技术服务，业务对象，数据对象和技术对象，以及合同。因此，产品可以聚合或组合来自除业务层之外的其他层的元素。“
“值可能与产品相关联。产品名称通常是与客户沟通时使用的名称，或者可能是更通用的名词（例如“旅行保险”）。“
应用视图
应用架构层视图。
应用服务地图视图
应用程序Map View
应用程序组合，其中应用程序可以分组，例如基于业务单位。
应用程序协作视图（数据流）
应用程序集成视图（动态关系）
在下面的示例（1到10）中示出了在应用之间建模数据切换的几种替代方法。
“应用程序A”拥有数据对象“A-1”，由“应用程序B”请求。
数据从“应用程序A”流向“应用程序B”。
“应用程序A”实现“应用程序B”使用的服务“A-1”。
实际上，“应用程序B”请求应用程序接口“A-1”并获得响应......
应用结构视图
此视图在设计或理解应用程序及其子组件的主要结构和相关数据时非常有用。该图可用于例如分解正在构建的应用系统的结构，以说明模块化/分解：子系统/子组件是什么，它们提供的应用服务（或应用程序接口）是什么。
请注意，应用程序服务（如上图所示）是结构接口（下图中的GUI和/或API）提供的行为功能。应用服务和应用程序接口是“同一枚硬币的不同方面”。
应用架构视图
此视图混合了EA级别和解决方案级别方法，因为同一视图中同时存在应用程序和应用程序模块。
应用程序组件模型（CM）
应用程序组件模型0-n是一种应用程序体系结构建模方法，它由不同抽象级别的图表组成，如下所示：
在CM-0级，该图描述了应用程序如何与其环境交互，与相邻应用程序和用户的交互是什么。目标应用程序被描绘为黑盒子。
在CM-1级别，目标应用程序被分解为模块（主要组件），以及这些模块提供和需要的应用程序服务（或应用程序接口）。目标应用程序被描绘为白盒子。
在CM-2级，模块被分解为子组件。（必要水平的数量取决于案件的适用程度）
下面的应用组件模型图由应用组件和应用服务组成。或者，根据情况，可以使用应用程序接口来代替应用程序服务。像往常一样，重要的是利用这种适合目的的建模风格，并且只对那些信息足够丰富并提供一定附加值的元素建模。无论建模者喜欢强调功能方面，还是更加具体，建模者都可以决定，例如，用精确的命名来建模实际的接口。
下面的组件模型图包括应用程序组件和应用程序服务。或者，可以使用应用程序接口代替应用程序服务。
应用程序组件模型 - 0（CM-0）
组件模型 - 0（CM-0）级别（上图）说明了目标应用程序与相邻应用程序之间的交互。引入了所有相关的应用程序服务（或应用程序接口）。0层图由企业架构级组件及其服务组成，目标应用程序位于中间。
应用程序组件模型 - 1（CM-1）
组件模型-1（CM-1）级别（上面）说明了如何将目标应用程序分解为模块（或主要组件），以及哪个模块实现哪些应用程序服务（或应用程序接口）。注意！外部应用程序可以从此级别中省略，但会显示其服务（或接口）。当显示更多低级元素时，可以/必须省略更多高级元素
- 为了简单起见：保持图表可读。
应用程序组件模型 - 2（CM-2）
组件模型-2（CM-2）级别（上图）说明了目标应用程序的模块如何由子组件组成，以及它们如何交互。
应用功能视图
应用程序功能分解：系统包含哪些功能，以及它们提供哪些应用程序服务？
申请流程视图
应用程序组件序列图视图
序列图不完全在ArchiMate的范围内，而是在UML的范围内。但是，我们可以使用ArchiMate对应用程序组件所采取的操作序列进行建模，如下所示。
动态关系“触发”和“流”可用于建模应用程序组件之间的动态。该视图的布局可以与UML序列图类似地定位。
应用程序组件序列图视图2
此版本（下图）说明了ArchiMate如何用于建模应用程序组件内部部分所采取的操作序列。内部部分是诸如a）行为过程或功能和b）结构子组件。它们使用Application
Process-，Application Function-和Application Component
-elements建模。这里显示的只是替代品。
此序列图中的动作流程（上图）：
1.应用程序组件“A”的子进程“X”向应用程序B发送带有参数“A”的请求消息。
2.应用程序组件“B”子进程“B-1”接收传入请求，然后（同步）调用应用程序组件C，其中应用程序功能“Y”接收请求，执行某些操作并作出响应。
3.应用程序组件“B”的其他子进程“B-2”将带有参数的消息发送到应用程序组件D，并接收确认。应用程序组件“D”包含执行处理的子组件。
4.应用程序组件“A”从应用程序组件B接收响应消息。
如图所示，我们可以用这些元素(应用程序组件、应用程序流程和应用程序功能和关系(触发器、流程))的组合来建模非常复杂的集成案例。UML序列图在软件设计中有它自己的特殊目的，但是ArchiMate可以用于相当多的建模目的——也可以用于应用程序设计。
应用程序集成是企业架构（EA）中最重要的部分之一。这就是为什么我们可以更详细地建模应用程序如何切换数据以及使用的交互机制是有利的。
ETL过程视图
分层视图
分层视图可用作目标区域的概述上下文关系图。此视图的主要优点是说明应用程序在它们提供的业务流程和服务中的用法。上图使用ArchiMate
Grouping -element对不同的图层进行建模，而下图使用工具（Archi）提供的可视Group元素。
ArchiMate基本上有三（3）层如下：1）业务层，2）应用层和3）技术层。它们的颜色通常如下：黄色的业务层，绿松石的应用层和绿色的技术层（参见ArchiMate核心框架）。
应用和数据库视图
数据库是组织整体企业架构中的一个有意义的单元。例如“客户数据库”或“客户数据库”，“产品数据库”等。或者，数据库可以是应用程序的所有表的逻辑（和物理）组合（例如“客户表”，“订单表”，“发票表“等等”，它们共同构建了一个数据库。根据ArchiMate规范，数据对象可用于建模逻辑数据库（如下图所示），第9.4.1节“数据对象”说：“数据对象的典型示例是客户记录，客户数据库或保险索赔msgstr“”“一个重要的例外是数据对象用于建模数据集合，例如数据库，其中只存在一个实例。”
ArchiMate拥有优雅的内置机制，这使得能够利用某些概念来实现不同的抽象级别（以及细节级别）。因此，例如数据对象可用于建模，例如逻辑数据库，数据库表，消息结构（在应用程序之间切换）等。
技术观点
技术架构层视图。
基础架构视图
此视图表示应用程序的平台。此模式可用于模拟运行时环境的配置，业务应用程序的部署。
实现和迁移层/转换架构层视图
实施路线图视图
看板视图
看板可以用于工作和工作流的可视化。看板显示了开发需求、EPIC、用户故事等如何从积压状态流到就绪状态（完成）。看板可以根据开发案例的规模和范围应用于不同的目的。例如，在EA级别使用“epics”或在项目级别使用“用户故事”或“需求”作为工作项。工作项的粒度可能因情况而异。
通用视图
这种简化视图可以用到如特定服务，程序或项目的上下文图。
附加功能
协作视图
可以混合各层，如下面的数据流图示例所示。
元模型
|
