企业架构研究总结（41）——企业架构与建模之ArchiMate的由来和详述（上）

终于完成了关于企业架构框架理论的总结，谢谢各位看官的支持，能挺过之前过于理论化的叙述而坚持到现在着实不易，笔者也自愧没有实践经验可以分享，希望日后有兴趣的看官能够不吝赐教。在本系列后面的也是最后一个大部分中，笔者将以ArchiMate语言为核心，尽力描述企业架构和建模之间的关系，以及基于企业架构模型的分析，其内容大多来源于ArchiMate 2.0标准以及《Enterprise Architecture at Work》这两部资料，有兴趣的看客可以对其进行参考比照。在此，再一次感谢支持本系列的各位看客，另外这一部分的内容应该不会想之前那么理论化，这也算是个好消息吧 ^_^。那么我们就开始吧：

通过在前几章中对当前在业界比较知名的几种企业架构和企业架构框架的介绍，我们可以将企业架构的内容看为由若干企业架构元素以及他们之间的关系组合而成。这些企业架构元素以及他们之间的关系覆盖范围广阔，纵贯了企业战略、原则、目标、需求、业务、信息系统以及基础设施这些层面。正因为需要照顾到如此广泛的范围，企业架构必将不可避免地面对企业内外各具有不同背景、关注点和利益的干系人（Stakeholder），而他们也正是企业架构的终极用户。所以，如何在这些干系人之间建立针对企业状况的无障碍的沟通是企业架构的最终目标，而在此基础之上才有可能实现诸如业务-IT相协调（Business-IT Alignment）、企业从单一领域优化到全局范围优化的演进等目标。为了达到这一目标，我们便需要对“企业”这一客观对象进行描述，并在各干系人之间获得一致性的认同，而这一过程也正是采用各种企业架构框架来进行企业架构建设过程的核心。如果用IT方面的词汇来描述，我们可以将其称为对企业进行“建模”。

虽则可以将如此复杂之事用“建模”这两个字来概括，但是如果要实现它，我们还需要面对如下几个问题：

• 如何进行建模？
• 针对什么进行建模？
• 采用何种方式来进行表述？

对于如何进行建模，在一些著名的企业架构框架（例如TOGAF）中已经有了相关阐述，罗列出了企业架构建设的各个实施、维护阶段以及相关的输入、输出和目标，因而在这里就不再赘述。

对于针对什么进行建模，这涉及到企业架构的内容范畴。从前面各章可知，各种企业架构框架对于企业架构内容都有着不同程度的分类和概括，而通过将它们归纳起来，我可以把企业架构的内容范畴界定为：企业架构的内容应表述企业的当前以及期望的状态，而这些内容应该以企业的战略、原则和目标为起点，以企业的文化和现有管理方法为背景，在纵向结合并贯穿业务、信息系统和基础设施这三个层面，而在横向则应反映各干系人的关注点和利益。

对于采用何种方式进行表述是本章的叙述重点。由于“企业”这一客观对象非常复杂，它既包含实实在在的信息系统和基础设施，又包括虚无缥缈的企业战略、企业文化等方面，因而如何将这一既实又虚的对象描述出来的确不容易。此外，由于企业中各个干系人的背景不同，因而其看问题的角度、深度和广度也不尽相同，所以他们都倾向于采用自己认知范围内的方式来对企业进行描述，而怎样弥合这些不同就成为了一个莫大的挑战。为了解决这些问题，企业架构描述语言应运而生，这其中就包括了诸如ArchiMate、ARIS（ARIS框架不单单是一种表述方式，它本身是一个被广泛使用的企业架构框架）等描述方式。本章的后面将针对ArchiMate进行详细地描述。需要注意的是，使用企业架构描述语言所产生的企业架构描述只是企业架构内容的重要组成部分，而采用自然语言的描述内容是永远不会被替代的，并且由于企业架构的高层次抽象性，各种采用专门语言进行表述的详细设计内容也永远不会被替代。

不论是采用架构描述语言还是使用自然语言对企业进行建模，都是对企业这一客观对象进行描述，从理论上讲，只要描述得当针对企业进行无障碍的一致性沟通这一目标均可达成。不过两种描述方式相比，企业架构描述语言更加“正式”，因为它采用统一的方式为“企业”建立数学模型，而这正是将“企业”进行信息化的基础，也为各种分析方法提供了良好的铺垫。

建立企业架构模型并不是最终目的，建而不用反而是最大的浪费，除了记录企业架构真实情况、描述目标状态和过渡状态、对实施和迁移过程进行指导，并在各干系人中对以上行为产生共识和建立沟通基础之外，在日常运营中，企业架构模型也能产生非常大的帮助，从而为干系人的决策提供依据，而这就是基于企业架构模型的分析。在本章的最后一个部分，笔者将以采用ArchiMate语言所描述的企业架构模型为基础介绍一些分析方法。

1. ArchiMate的由来

ArchiMate起源于本世纪初的荷兰，是由荷兰在信息技术领域的研究组织Telematica Instituut（2009年重组并重命名为Novay）组建的开发团队定制而成，并且其建设过程受到了荷兰政府以及各工业和学院的支持和合作。这一建设过程开始于2002年7月，并于2004年12月截止，这期间消耗了35人年以及将近400万欧元的资金。2008年，ArchiMate的主导权被转移到了Open Group的手中。2009年2月，Open Group将ArchiMate 1.0版作为正式的技术标准进行了发布，而截止到目前最新的版本是2012年1月发布的ArchiMate 2.0版。作为最新的ArchiMate 2.0版，相对于1.0版本，Open Group不仅在多个方面对原来的内容进行了修订，并将ArchiMate与其手中的TOGAF标准进行了很好的整合，从而使ArchiMate不仅仅可以在企业的业务、信息系统（数据和应用）和技术层面进行描述，还通过了扩展对企业战略和迁移与实现进行了描述，并与前面所说的三个层面相结合。下图展示了ArchiMate 2.0版与TOGAF之间的契合关系：

ArchiMate的基础是IEEE 1471标准，该标准定义了一系列用于描述系统架构的基本概念元素以及他们之间的关系，从而为系统的定义、分析和描述提供了坚实的理论基础。IEEE 1471以民用建筑为类比来对软件系统架构进行描述，在这一点上它与Zachman框架有着异曲同工之妙，不过与之不同的是，IEEE 1471并不是通过一系列固定的视角和视图来对系统架构进行标准化，而是采用了架构描述实践中能够被广泛接受的各种有价值的概念和关系：

2. ArchiMate建模详述

ArchiMate语言为企业架构的描述提供了一种图形化的表述方式，尤其是在2.0版本发布之后，ArchiMate具有了时间这一维度，从而使其可以对企业随着时间推移而演进的过程中所涉及到的转化和迁移情况进行建模。作为一种企业架构建模语言，ArchiMate所描述的范围需要涵盖企业的各个领域，并能够体现出各干系人的关注点，因而与各个领域的专用建模语言相比，ArchiMate具备如下特点：

• ArchiMate能够跨越企业中的各个领域，这至少包括业务、应用、数据和技术基础设施层面。
• ArchiMate不仅能对企业中的各个领域进行描述，还可将这些领域关联在一起，从而使得各干系人能够获得一个完整且完备的企业模型，而这也是业务与IT相校准（Business-IT Alignment）的重要基础。当前各个企业和组织中都不乏采用了各个领域建模语言而进行描述的各种模型，由于这些模型采用的描述方式不同，且往往采用多人分别负责的方式进行建模，所以这些模型很难在各个领域之间保持一致性（更何况每个模型还有着由于版本演进而带来的不一致性问题），从而也无法时时保证模型与客观对象的一致性。虽然以UML 2.0为代表的建模语言可以涵盖当前所能够遇到的所有领域，不过他们也还是没有能够完全打通各个领域之间的描述壁垒，各个领域之间的模型依然是相对隔绝的。
• 由于是企业架构建模语言，ArchiMate描述所采用的抽象层级和描述粒度应该是全局级别的，因而其描述不能像各领域的专用建模语言那样详细。不过在实践过程中，基于ArchiMate的扩展规则，ArchiMate也可以对其描述粒度和抽象程度进行扩展，从而获得为各干系人提供多抽象层次和描述粒度的企业架构。
• 虽然ArchiMate可以被用来描述一个完整且完备的企业架构，但对于某一具体干系人来说，如此庞大且面面俱到的企业模型的确是过于繁杂了。由于每个干系人都有着自己的关注点和利益关系，因而其所在乎的往往只是企业模型的某一个方面的内容，而为了使各个干系人能够获得反映其关注点的企业模型的侧面，ArchiMate通过定制各种典型的视角与视图来对企业模型的创建和使用进行了归纳。

2.1 ArchiMate语言基本结构

ArchiMate语言的建设初衷并不是要重新建立一种全新的建模语言，因为这样做只会带来新的学习挑战，并且还会陷入到与其他建模语言的竞争和兼容陷阱之中，因而从其开发初期开始，开发团队就着眼于提供一套能够尽量兼容和重用当前各领域中的建模语言元素的方式，而不是替代他们。而也正是因为这种指导思想，ArchiMate才得以能够将原本隔绝的各个建模领域联系起来。虽然说起来简单，但真要建设这样一种语言其实是一项巨大的挑战，因为这语言需要在如下两个层面获取良好的平衡：

• 如果要兼容各领域的专有建模语言，最容易想到的方式就是对这些语言中的建模元素和关系进行抽象，从而获得个语言的共通之处，并以此来对企业架构进行描述。虽然这的确是一个兼容各方不同的办法，但是由于各领域建模方法的差异太大，抽象到最后的结果只能剩下“实体”和“关联”这两个基础建模元素，而企业架构的领域特色则无从着落，因而ArchiMate的抽象层级也不能如此之高。
• 无论如何，ArchiMate的终极目标还是要在各领域模型之间建立联系，因而其抽象层次又不能像各领域建模语言那样事无巨细，必要的抽象还是需要的。

因此，正如ArchiMate 2.0规范中图示那样，ArchiMate语言中的建模元素及其之间关系的定义层级应在上述两个层次之间取得平衡：

虽然ArchiMate语言跨越多个领域，其所包含的建模元素种类以及他们之间关系的种类也较为繁杂，但综合来讲，ArchiMate语言的基本结构和特点可总结如下：

• ArchiMate的建模概念元素虽然种类繁多，但究其性质而言不外乎结构元素（Structure Element）和行为元素（Behavior Element）两种（也可称为静态元素和动态元素），前者代表了各种结构化的实体（如参与者、应用组件以及数据等），而后者则用来描述结构化元素所能执行的各种行为（如业务活动、应用功能以及服务等）。此外，根据与行为元素之间的关系进一步划分，结构元素又可被分为主动性结构元素（Active Structure Element）和被动性结构元素（Passive Structure Element），前者表示发起动作的结构元素（例如参与者、应用组件等），而后者则被用来描述行为元素的各种目标（例如业务数据、信息数据等）。由此可见，ArchiMate所使用的描述方式与很多标准化的描述方式（例如RDF语言）有着异曲同工之妙，他们都符合人们日常所用的自然语言的“主-谓-宾”方式，亦即主动性结构元素类比于主语、行为元素类比于谓语，而被动性结构元素类比于宾语。
• ArchiMate中的行为元素还可以从内与外两个维度进行进一步区分，前者用于描述某种功能的内部实现方式，而后者则用于表述系统对于外界所能提供的（抑或外界需要系统能够提供）对外界具有价值且隐藏了内部实现的功能单元。通过借鉴面向服务架构（SOA）中的概念，ArchiMate用“服务（Service）”这一行为概念元素来代表这种功能的外部表现形式，而对于用于实现服务的内部行为元素则包括了业务流程、业务功能、应用功能等多种行为概念元素。
• ArchiMate采用分层的方式对企业架构进行描述，这主要包括了（自上而下）业务、应用和技术三个层面。每个层次中包含了该领域中的各种概念元素和他们之间的关系，而不同层面之间的关联则是通过前面提到过的“服务”行为元素来进行关联，亦即上面层次（如业务层）中的概念元素使用下面层次（如应用层）中概念元素所实现并通过接口对外提供的服务。
• 由于在实践过程中，一个行为元素往往是由多个结构元素共同执行，并且这里所说的“共同执行”并不仅仅是将这些参与的架构元素的努力进行简单地加合，而是有着更加复杂的“合作”意义。为了对这种集合性质的情形进行描述，ArchiMate中引入了合作集合（Collaboration）和交互（Interaction）这两个概念，前者是结构元素的特化，用于表述包含多个结构元素的协同集合，而后者则是行为元素的特化，用于表述一个合作集合所执行的行为。
• ArchiMate通过各种关系来联接不同的概念元素，这些关系中的大多数来源于当前已经存在的建模语言中的关系。
• ArchiMate中相同种类的不同概念元素实例之间都有着默认的组合、聚合和特化关系。
• ArchiMate中定义的各种结构化关系都有着各自的优先级，并且由结构化关系间接相连的概念元素之间可以等效为一条直接的结构化连接，且此等效的直接连接将等同于这一系列实际关系链中具有最低优先级的关系连接。这一原则对于基于企业架构模型的定性分析（如影响分析）有着重要的意义。
• ArchiMate中对于大多数概念元素都定义了两种表示图符，在实际应用中可以根据需要进行选择。这符合ArchiMate的模型、视图（反映某一视角的模型子集）与展现方式相分离的设计思想。一般来讲，采用矩形轮廓的表示图符给人感觉更加正式，往往用在企业架构建设的中后期，或面对更加关注于实现细节干系人，而采用更加具有表现力的后者给读者的感觉不如前者正式，因而通常用在企业架构建设初期，或面对不太关注于细节的干系人以及面对大范围的具有不同背景和关注点的干系人群体。

在本章的后面部分，笔者将以各领域层次为单位对其中的概念元素进行详细描述，对元素之间的关系进行集中阐述，并在最后对ArchiMate的扩展规则进行描述。这些内容来源于《ArchiMate 2.0 Specification》中第三至七章（对各领域中的建模概念元素和关系进行了定义和描述）和第九章（ArchiMate扩展规则），笔者以这些章节中关于建模概念元素的定义、表示图符和示例为蓝本，以个人理解为出发点对其进行了翻译和适当修改（如业务接口的示例与规范中的对应示例就略有不同，笔者根据个人理解对其进行了适当的修改）。

2.2 业务层模型元素

业务层模型元素包括了业务领域中的各种概念元素以及他们之间的关系，除此之外还包括了一些与业务领域相关的信息概念（Informational Concept）元素：产品、与产品关联的合同、业务对象的意义，以及产品或业务服务的价值。这些概念元素及其之间的主要关系如下图所示：

2.2.1 结构元素

2.2.1.1 业务参与者（Business Actor）

• 定义：业务参与者被定义为能够执行某种行为的组织单元。与各种技术实体不同，业务参与者是业务领域的概念，他包括了实际企业内外的各种组织单元，例如人员、部门、客户以及第三方合作者等。一个业务参与者可以被指派担当一个或多个业务角色。
• 表示图符：

• 实例：某保险公司被建模为包含了“行李保险部”和“旅游保险部”两个部门，其中旅游保险部在“获取旅游保险”这一业务流程中担当了“旅游保险销售”的角色。“获取旅游保险”业务流程对外提供了“提供旅游保险”服务，而这一服务被公司的“客户”这一业务参与者而使用。

2.2.1.2 业务角色（Business Role）

• 定义：能够赋予业务参与者的执行某一特定行为的责任。业务角色所涉及到的主要关系可归纳为：
• 一个业务角色可以被指派给一个或多个业务流程或业务功能。
• 一个业务角色可以被分配给一个业务参与者。
• 一个业务接口或应用接口可以被一个业务角色所使用。
• 一个业务接口可以通过组合关系而作为一个业务角色的一个组成部分。
• 表示图符：

• 实例：“旅游保险部”在这一案例中充当了“旅游保险销售”这一角色，并且此角色通过一个“电话”业务接口来对外提供服务。“客户”在此案例中充当了“保险购买者”角色，并且此角色具有一个“电话”接口来表示此角色对外需要通过一个“电话”业务接口来获取服务。

2.2.1.3 业务合作集合（Business Collaboration）

• 定义：两个或两个以上共同执行某种协作和交互的角色的集合。业务合作集合所涉及到的主要关系可归纳为：
• 业务合作集合包括多个业务角色。
• 业务合作集合可以被指派给一个或多个业务交互。
• 业务合作集合可以使用业务接口或应用接口。
• 业务合作集合可以通过组合关系而具有业务接口。
• 表示图符：

• 实例：从此案例可以看出，销售一个保险产品（例如行李保险）需要“行李保险销售者”和“销售支持者”这两个角色共同协作而成。

2.2.1.4 业务接口（Business Interface）

• 定义：外部环境获取业务服务的访问点。业务接口可以分为提供性接口和需求性接口两种，前者表示结构元素对外通过何种接口提供服务，而后者则用来表述结构元素需要何种接口来获取服务。业务接口所涉及到的主要关系可归纳为：
• 业务接口可以通过组合关系成为业务角色的一个组成部分。
• 业务角色可以使用业务接口。
• 业务接口可以被分配给一个或多个业务服务，即业务服务可以通过分配到其上的业务接口而得到。
• 表示图符：右边的两个图符中：位于左边的图符用于表述提供性接口，而位于右边的则用来表示需求性接口。

• 实例：此案例中“联合保险销售服务”和“行李保险销售服务”这两个业务服务分别被分配到业务接口“呼叫中心”和“Web表单”之上，并被“客户”所使用。

2.2.1.5 位置（Location）

• 定义：代表空间上的一个点或范围。位置所涉及到的主要关系可归纳为：
• 位置概念元素可以通过分配关系指派到结构元素之上，用以表述结构元素所处的空间位置。
• 由于结构元素与行为元素相互关联，因而位置概念元素也可以间接的关联到行为元素之上用以表述行为发生的空间位置。
• 表示图符：

• 实例：保险公司的各个部门分布在不同的位置，其中法律部和财务部位于总公司，而索赔处理部则位于本地办事处之中。

2.2.1.6 业务对象（Business Object）

• 定义：代表从业务的视角来进行考虑的重要的信息化或概念化的元素，属于被动性概念元素。业务对象所涉及到的主要关系可归纳为：
• 业务对象可被业务流程、业务功能、业务交互、业务事件或业务服务所访问。
• 不同的业务对象之间可以具有关联、特化、组合及聚合关系。
• 业务对象可以由表达方式或数据对象所实现（或由两者共同实现）。
• 表示图符：

• 实例：业务流程“创建发票”在收到事件“请求发票”后创建了“发票项”和“发票”这两个业务对象，其中“发票”业务对象聚合了若干“发票项”对象。随后“发送发票”业务流程对“发票”业务对象进行读取，并执行后面的发送行为。从此案例中我们还可以看出，“发票”这一业务对象包含了两种具体实现，其中一个是“电子发票”这一数据对象，另外一个是“纸质发票”这一表现形式。

2.2.2 行为元素

2.2.2.1 业务流程（Business Process）

• 定义：业务元素被定义为一种基于活动顺序来对各种行为进行组织的行为概念元素，其目的在于产生一系列经过定义的产品或业务服务。与为外界提供有意义的行为的业务服务不同，一个业务流程描述了由某业务角色执行的内部行为，因而对于外界来讲，业务流程只是一只“黑盒子”。在ArchiMate中虽然对业务流程进行了定义，不过它并不能对其进行详细定义，用户可以通过使用诸如BPMN这样的流程建模语言对其ArchiMate中的流程定义进行扩展。业务流程所涉及到的主要关系可归纳为：
• 业务流程和业务功能之间具有潜在的多对多关系。
• 业务流程可以被其他行为元素（例如业务事件、业务流程、业务功能或业务交互）所触发，也可以触发其他行为元素。
• 业务流程可以访问业务对象。
• 业务流程可以实现一个或多个业务服务。
• 业务流程可以使用其他的一个或多个业务服务和应用服务。
• 业务角色或应用组件可以被指派给业务流程，分别用以表示该业务流程是人工流程或自动化流程。
• 表示图符：

• 实例：在此案例中，“处理保险申请”业务流程包含了三个子流程，并且当“保险申请”这一业务事件发生后，这三个子流程将依次进行。“处理保险申请”被指派给“保险销售人”这一业务角色，即由其负责该内部行为的实施。有两个业务接口（“电话”和“Web”）被分配给了“保险销售人”，因而他将通过这两个接口来对外提供“处理保险服务”这一业务服务，并且此业务服务的内部实现就是“处理保险申请”这一业务流程。

2.2.2.2 业务功能（Business Function）

• 定义：业务功能被定义为一种根据某选定标准来对各种行为进行组织的行为概念元素。与业务流程一样，业务功能也被用来描述某角色的内部实现行为，并且也被用来对各种行为元素进行组织。而与之不同的是，业务流程将为了实现业务服务或产品而需要的各行为的发生时序作为组织原则，而业务功能对行为元素的组织方式却更加多样化，例如根据行为所需的资源、技能或竞争力等方面。业务流程所涉及到的主要关系可归纳为：
• 业务功能和业务流程之间具有潜在的多对多关系。
• 业务功能可以被其他行为元素（例如业务事件、业务流程、业务功能或业务交互）所触发，也可以触发其他行为元素。
• 业务功能可以访问业务对象。
• 业务功能可以实现一个或多个业务服务。
• 业务功能可以使用其他的一个或多个业务服务和应用服务。
• 业务角色或应用组件可以被指派给业务功能。
• 表示图符：

• 实例：在此案例中，不同的业务流程元素按照其所使用的信息资源被分配到三个业务功能之中，其中“顾客接待”业务功能包括“接受保险申请”和“提交索赔”两个业务流程，而且此业务功能需要读取“客户信息”这一业务对象，即其中的两个业务流程均需要对此业务对象进行访问；“基本管理”业务功能包括了“处理申请”业务流程；“财务处理”业务功能包括了“收取保费”业务流程，并且此业务功能使用了由“金融支持系统”应用组件所实现的“计费服务”这一应用服务，这表示“收取保费”业务流程中使用了“计费服务”这一应用服务才得以实现“保费收取服务”这一业务服务。

2.2.2.3 业务交互（Business Interaction）

• 定义：用于描述业务合作集合的行为，即处在业务合作集合中的各个业务角色将对业务交互所表述的行为共同负责。业务交互所涉及到的主要关系可归纳为：
• 业务交互可以被其他行为元素（例如业务事件、业务流程、业务功能或业务交互）所触发，也可以触发其他行为元素。
• 业务交互可以访问业务对象。
• 业务交互可以实现一个或多个业务服务。
• 业务交互可以使用其他的一个或多个业务服务和应用服务。
• 一个业务合作组合或应用合作组合可以被指派给一个业务交互。
• 表示图符：

• 实例：在此案例中由“旅游保险销售者”和“行李保险销售者”这两个业务角色组成了“联合保险销售”这一业务合作集合，并且该合作集合负责执行“处理联合保险”这一业务交互，同时该业务交互对外提供了“联合保险销售服务”这一业务服务，并在交互过程中对“政策信息”业务对象进行了访问。

2.2.2.4 业务事件（Business Event）

• 定义：业务事件代表了企业或系统内外所发生的瞬时的并对其他行为元素具有影响的事物。业务事件所涉及到的主要关系可归纳为：
• 业务流程、业务功能或业务交互可以产生业务事件。
• 业务事件可以触发业务流程、业务功能或业务交互。
• 业务事件可以对业务对象进行访问。
• 业务事件可以包含其他业务事件。
• 表示图符：

• 实例：在此案例中，“保险申请”业务事件触发了“接受保险申请”这一业务流程，而为了使客户能够更加了解保险公司的产品从而购买更多的保险产品，在“接受保险申请”业务流程之后触发了“发送产品组合”这一业务事件，而后者接着启动了“为客户发送产品组合”这一业务流程。此外，“保险申请”和“发送产品组合”这两个业务事件对于“客户信息”业务对象均有访问，前者修改对客户信息进行了修改（例如，记录客户此次所申请的保险产品信息），而后者则对此业务对象进行读取。

2.2.2.5 业务服务（Business Service）

• 定义：代表了用于实现组织内外客户需求的服务。业务服务将业务角色或业务合作集合的功能提供给外界，并且对于这些功能的访问需要通过各种业务接口，而这些功能的实现则是由各业务角色或业务合作集合所执行的一个或多个业务流程、业务功能或业务协作来落实。由于业务服务的客户存在于组织内外，因而其既包含了面向外部客户的服务，也包括了对于内部客户的支持性服务。业务服务所涉及到的主要关系可归纳为：
• 由于业务服务需要对外界环境具有价值，因而业务服务概念元素需要关联价值概念元素。
• 业务服务可以被业务流程、业务功能和业务交互所使用。
• 业务流程、业务功能和业务交互可以实现业务服务。
• 业务接口或应用接口可以被指派给业务服务，用于表示业务服务的访问方式。
• 业务服务可以访问业务对象。
• 表示图符：

• 实例：在此案例中，“基本管理”业务功能提供了两个支持性内部服务：“客户信息处理”和“客户保险检索”。这两个内部业务服务均被业务流程“处理旅游保险”和“处理行李保险”所分别使用，并且这两个业务流程分别对组织外部客户提供了两个外部业务服务：“旅游保险销售服务”和“行李保险销售服务”。这两个外部业务服务组合而成“保险销售服务”，并且处于组织外部的“保险购买者”业务角色可以通过“电话”这一业务接口从“保险销售人”角色那里访问到这一业务服务。由于业务服务需要对外界具有价值，这表现在本案例中即是：“保险销售服务”对其使用者“保险购买者”业务角色应具有价值，而这一价值则被“受保”这一价值概念元素所表示，即对于使用“保险销售服务”的“保险购买者”来说，该业务服务可使其处于“受保”的状态之下。

2.2.3 信息元素

业务结构元素和行为元素中所包含的种种概念元素关注于描述企业的运行方面，而与之相比，业务信息元素则站在“主观意识”的角度对上述两种元素进行进一步的阐述。例如，对于业务服务来说，除了要从企业的运行层面来描述实现和负责业务服务的各个元素，我们还需要阐述业务服务对其外部环境的意义和价值。由此我们也可以看出，信息元素是一条将企业的业务目标和产品与其运行方面关联起来的路径。

2.2.3.1 表现方式（Representation）

• 定义：用于表示业务对象所具备的信息的认知形式。一个业务对象可以同时具备多种认知形式，并且这些认知形式可以按照其特性被分为多个种类。例如，从信息载体方面区分可以包括电子、纸质等，而从信息格式方面又可以包含HTML、XML等。表现方式所涉及到的主要关系可归纳为：
• 一个表现方式可以实现一个或多个业务对象。
• 一个业务对象可以由一个或多个表现方式所实现。
• 一个意义元素可以关联一个表现方式，用以表示该表现方式具备某种意义。
• 表示图符：

• 实例：在此案例中，“接受保险申请”业务流程所读取的“申请”这一业务对象在物理层面上是由“申请表单”所实现的；“收取保费”这一业务流程所产生的“单据”业务对象则表现为实际中的“纸质账单”。

2.2.3.2 含义（Meaning）

• 定义：用于表示在特定上下文环境中业务对象或其表现方式所具有的知识或专业含义。表现方式所涉及到的主要关系可归纳为：
• 含义元素可以关联到业务对象之上。
• 含义元素可以关联到业务对象的表现方式之上。
• 表示图符：

• 实例：在此案例中，“保险政策”业务对象表现为“保险政策文档”，而与此文档相关的含义是“保险政策通知”，并且该含义元素还包括了“覆盖范围描述”、“政策解读”和“保险登记”这三个含义，他们组织在一起阐述了“保险政策文档”的“主观意图”。

2.2.3.3 价值（Value）

• 定义：用于表示业务服务或产品的相对价值、用途或重要性。价值所涉及到的主要关系可归纳为：
• 价值元素可以关联到业务服务之上，并由此间接关联到包含该业务服务的产品以及使用该服务的业务角色和业务参与者之上。
• 价值元素可以关联到产品之上。
• 表示图符：

• 实例：从此案例中我们可以看到：“保险销售服务”可以对外提供“受保”这一价值，而此价值还可以进一步细分为 “保护免受损失”、“降低风险”和“安全性”这三个更加具体的价值。

2.2.3.4 产品（Product）

• 定义：一个产品被定义为具备一份合同或协议的一系列服务的组合，并且这些内容将被作为一个整体提供给内部或外部的客户。这一针对产品的定义主要是针对金融的、基于服务的或信息化的产品，而不是物理化产品，因而对于信息密集型企业来讲是适用的。产品所涉及到的主要关系可归纳为：
• 产品可以聚合业务服务和/或应用服务，以及一个合同元素。
• 价值元素可以关联到产品元素之上。
• 表示图符：

• 实例：在此案例中，某银行为其客户提供了“电话银行”产品，该产品包括了由客户关系部门实现的“开户”和“应用支持”这两个业务服务，以及一个由“电话银行应用”这一应用组件所实现的名为“银行服务”的业务服务（该服务使用了“账户状态查询服务”和“汇款服务”这两个应用服务，而他们均由“电话银行应用”实现）。

2.2.3.5 合同（Contract）

• 定义：合同被定义为一份关于双方协议的正式或非正式的规范说明，他描述了与产品相关的各项权利和义务。合同元素既可以表述具有法律意义的合同，也可以描述与产品相关的非正式协议。合同元素是业务对象的一个特化，他继承了业务对象的各种属性和关系。合同所涉及到的主要关系可归纳为：
• 业务对象可以具备的关系都可以应用在合同元素之上。
• 产品元素可以聚合合同元素。
• 表示图符：

• 实例：在此案例中，“电话银行”产品包含了“电话银行合同”，并且此合同还包括了“服务条件”和“服务水平协议”这两个子合同。

2.3 应用层模型元素

应用层模型元素包括了企业在应用层面的各种概念元素以及他们之间的关系。由于该层次的目标是描述企业中的各种信息/软件系统，所以这其中大部分概念元素都来源于UML 2.0，因为在这一领域中UML 2.0无疑是受众最广的事实标准。在ArchiMate 2.0中，对企业应用层进行建模的各种概念元素以及他们之间的主要关系（元模型）被定义如下：

2.3.1 结构元素

2.3.1.1 应用组件（Application Component）

• 定义：用于表示一个模块化、可部署且可替代的软件系统的一个组成部分，他对软件系统的行为和数据进行了封装，并通过接口对外提供被封装的内容。由此可见，应用组件是一个自包含的功能单元，虽然被定义为软件系统的一个组成部分，但此概念元素也可以被用来对一个完整的软件应用、子软件应用或信息系统进行建模。应用组件所涉及到的主要关系可归纳为：
• 一个应用组件可以被指派给一个或多个应用功能、业务流程或业务功能。
• 一个应用组件可以具有一个或多个应用接口。
• 应用组件可以使用其他应用组件的接口。
• 表示图符：

• 实例：在此案例中，“金融应用”软件被建模为一个应用组件，他包含了两个子应用组件，分别为“财务组件”和“计费组件”，并且前者对外提供了“财务服务”这一应用服务，而后者则提供了“计费服务”。这两个应用服务可通过一个名为“财务及计费接口”的共享应用接口来进行访问，而此应用接口也是“金融应用”软件的一个组成部分。

2.3.1.2 应用合作集合（Application Collaboration）

• 定义：两个或两个以上共同执行某种行为的应用组件的集合。应用合作集合通常用来对逻辑的或临时性的应用组件组合进行建模，在实际中并不作为一个独立的实体而存在。应用合作集合是应用组件的特化，因而他本身也是一个主动性的结构元素，其所涉及的主要关系可归纳为：
• 一个应用合作集合可以被分配给一个或多个应用交互或业务交互之上。
• 应用合作集合可以使用应用接口。
• 应用合作集合可以包含应用接口。
• 表示图符：

• 实例：在此案例中，“财务组件”和“计费组件”这两个应用组件组成了“交易管理”这一应用合作集合，并参与到了名为“交易管理”的应用交互之中。

2.3.1.3 应用接口（Application Interface）

• 定义：应用接口被定义为应用服务的访问点，用户或其他应用组件可以通过应用接口来获取各应用服务。应用接口具有方向性，他定义了应用组件功能如何能够被外界获取，或应用组件需要从外界环境获取什么样的功能。应用接口所涉及到的主要关系可归纳为：
• 一个应用接口可以作为一个应用组件的组成部分（通过组合关系）。
• 应用组件可以使用其他组件的应用接口。
• 应用接口可以被分配到一个或多个应用服务或业务服务之上，用于表示外界可以通过该应用接口获取这些服务。并且，相同的服务（应用服务或业务服务）也可以被分配到不同的应用接口之上。
• 表示图符：与业务接口类似，由于应用接口也有着方向性，因而其图符有着两种表现形式。以下图为例，在处于右边的两个图符中，左手边的图符表示应用接口将功能提供给外界，而后手边的图符则表示应用接口需要从外界获取何种功能。

• 实例：在此案例中，“财务组件”对外提供了“交易数据交换”应用接口，而这正是“计费组件”所需要的，因而在这两个应用组件的应用接口之间有着使用和被使用的关系。

2.3.1.4 数据对象（Data Object）

• 定义：用于表示适合于自动化处理的被动性结构元素。数据对象应该是一份自包含的信息体，并且对于业务领域应该具有清晰的含义，而不是仅仅局限于应用层面。数据对象所涉及到的主要关系可以归纳为：
• 应用功能、应用交互或应用服务可以访问数据对象。
• 数据对象可以实现业务对象。
• 数据对象可以被制品（技术层模型元素之一）所实现。
• 数据对象之间可以具有关联、继承、聚合及组合关系。
• 表示图符：

• 实例：在此案例中，“计费”业务功能使用了由“财务”业务功能所提供的“交易处理”应用服务，而在此应用服务执行过程中，名为“交易数据”的数据对象被用来进行信息交换。

2.3.2 行为元素

2.3.2.1 应用功能（Application Function）

• 用于对应用组件所执行的各自动化行为进行组织的行为元素。应用功能描述了应用组件的内部功能，而这些功能需要通过应用接口提供给外界。应用功能所涉及到的主要关系可以归纳为：
• 一个应用功能可以实现一个或多个应用服务。
• 应用功能可以使用由其他应用组件实现的应用服务或位于技术层的基础设施服务。
• 应用功能可以访问数据对象。
• 应用功能可以被分配给应用组件，用以表示该应用组件执行了此应用功能。
• 表示图符：

• 实例：在本案例中，名为“财务应用”的应用组件的行为被建模为“财务管理功能”这一业务功能，而此业务功能包含“财务功能”和“计费功能”这两个子应用功能，并且前者对外提供了“显示账户状态”应用服务，而后者则提供了“创建单据”和“发送单据”这两个应用服务。

2.3.2.2 应用交互（Application Interaction）

• 定义：用于描述应用合作集合行为的行为元素。应用交互所涉及到的主要关系可以归纳为：
• 一个应用合作集合可以被指派给一个应用交互。
• 应用交互可以实现应用服务。
• 应用交互可以使用应用服务或位于技术层的基础设施服务。
• 应用交互可以访问数据对象。
• 表示图符：

• 见“应用合作集合示例”。

2.3.2.3 应用服务（Application Service）

• 定义：对外提供自动化行为的服务。站在外部环境的角度来看，应用服务必须对外界具有意义，即他必须对他的用户提供有价值的功能。对于企业来说，其外部环境总离不来业务层面，因而应用服务也应该是业务相关的。应用服务所涉及到的主要关系可归纳为：
• 应用服务可以被业务流程、业务功能、业务交互或应用功能所使用。
• 应用功能或应用交互可以实现应用服务。
• 应用接口可以被指派给应用服务。
• 应用服务可以访问数据对象。
• 表示图符：

实例：在本案例中，名为“财务组件”的应用组件具有“财务功能”这一应用功能，且此应用功能对外提供了名为“交易处理服务”的应用服务。“交易处理”应用服务被指派给“交易处理接口”这一应用接口，而此应用接口属于“财务组件”，即对于“交易处理服务”的访问需要通过“交易处理接口”；与之相似，“计费组件”、“计费功能”、“单据创建服务”和“单据界面”之间也具有一样的关联；在上述两组内容之间，“计费功能”使用着“交易处理服务”，而这一“使用”关系也体现在“计费组件”对作为“财务组件”组成部分的“交易处理接口”使用之上。