| 编辑推荐: |
本文主要以采用ArchiMate语言所描述的企业架构模型为基础介绍一些分析方法。，希望对您的学习有所帮助。
本文来自于闹市闲云，由火龙果软件Alice编辑、推荐。
|
|
通过在前几章中对当前在业界比较知名的几种企业架构和企业架构框架的介绍，我们可以将企业架构的内容看为由若干企业架构元素以及他们之间的关系组合而成。这些企业架构元素以及他们之间的关系覆盖范围广阔，纵贯了企业战略、原则、目标、需求、业务、信息系统以及基础设施这些层面。正因为需要照顾到如此广泛的范围，企业架构必将不可避免地面对企业内外各具有不同背景、关注点和利益的干系人（Stakeholder），而他们也正是企业架构的终极用户。所以，如何在这些干系人之间建立针对企业状况的无障碍的沟通是企业架构的最终目标，而在此基础之上才有可能实现诸如业务-IT相协调（Business-IT
Alignment）、企业从单一领域优化到全局范围优化的演进等目标。为了达到这一目标，我们便需要对“企业”这一客观对象进行描述，并在各干系人之间获得一致性的认同，而这一过程也正是采用各种企业架构框架来进行企业架构建设过程的核心。如果用IT方面的词汇来描述，我们可以将其称为对企业进行“建模”。
虽则可以将如此复杂之事用“建模”这两个字来概括，但是如果要实现它，我们还需要面对如下几个问题：
1.如何进行建模？
2.针对什么进行建模？
3.采用何种方式来进行表述？
对于如何进行建模，在一些著名的企业架构框架（例如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）
定义：对外提供自动化行为的服务。站在外部环境的角度来看，应用服务必须对外界具有意义，即他必须对他的用户提供有价值的功能。对于企业来说，其外部环境总离不来业务层面，因而应用服务也应该是业务相关的。应用服务所涉及到的主要关系可归纳为：
应用服务可以被业务流程、业务功能、业务交互或应用功能所使用。
应用功能或应用交互可以实现应用服务。
应用接口可以被指派给应用服务。
应用服务可以访问数据对象。
表示图符：
实例：在本案例中，名为“财务组件”的应用组件具有“财务功能”这一应用功能，且此应用功能对外提供了名为“交易处理服务”的应用服务。“交易处理”应用服务被指派给“交易处理接口”这一应用接口，而此应用接口属于“财务组件”，即对于“交易处理服务”的访问需要通过“交易处理接口”；与之相似，“计费组件”、“计费功能”、“单据创建服务”和“单据界面”之间也具有一样的关联；在上述两组内容之间，“计费功能”使用着“交易处理服务”，而这一“使用”关系也体现在“计费组件”对作为“财务组件”组成部分的“交易处理接口”使用之上。
2.4 技术层模型元素
技术层模型元素包括了企业在信息基础设施方面（企业中基本的软硬件环境，包括物理设备、系统软件等为信息化提供基本支持的设施）的各种概念元素，以及他们之间的关系。与应用层模型元素相类似，技术层模型元素中的大部分概念元素也来源于UML
2.0，这同样也是因为UML 2.0在这一领域已经成为被广泛接受的事实标准。在ArchiMate 2.0中，对企业技术层进行建模的各种概念元素以及他们之间的主要关系（元模型）被定义如下：
2.4.1 结构元素
2.4.1.1 节点（Node）
定义：用于表示存储或部署执行各种制品的计算资源的主动性概念元素。这一概念与UML 2.0中的节点概念是相同的，是构成技术层结构方面的基本单元，也是此领域建模中的核心元素。节点可以用来对应用服务器、数据服务器或客户工作站来进行建模，概括来讲，其所描述的内容是组合了硬件资源以及系统软件并对外提供计算资源的逻辑单元。节点所涉及到的主要关系可归纳为：
节点元素之间通过通信路径进行互联。
制品可以被分配给节点，用于表示该制品被存储或部署在此节点之上。
表示图符：
实例：在本案例中，“应用服务器”节点包含了“刀片服务器设备”这一硬件资源，以及“J2EE服务器”这一系统软件资源。
2.4.1.2 设备（Device）
定义：用于表示存储或部署执行各种制品的硬件资源。设备概念元素是节点元素的特化，他代表了具有处理能力的各种物理资源，例如大型机、个人计算机或路由器等。设备所涉及到的主要关系可归纳为：
设备可以组合或聚合其他的子设备。
设备之间通过网络进行互联。
制品可以被分配给设备，用以表示制品被存储或部署到此设备之上。
系统软件可以被分配给设备，用以表示系统软件的安装或部署位置。
一个节点可以包含一个或多个设备。
表示图符：
实例：本案例展示了三种设备，分别为：“前台应用服务器”、“后台应用服务器”和“Web服务器”，并且他们之间通过“局域网”这一网络概念元素进行互联。
2.4.1.3 系统软件（System Software）
定义：用于表示一种软件环境，使得各种特定类型的软件组件和对象能以制品的形式部署于其中。系统软件概念元素也是节点的特化，专门用于对各种制品所处的软件环境进行建模。系统软件和设备通常组合在一起来形成一个节点。系统软件所涉及到的主要关系可归纳为：
系统软件可被分配给设备。
制品可被分配给系统软件。
节点可以组合或聚合系统软件。
表示图符：
实例：在本案例中，“大型机”这一设备之上部署了两个系统软件，他们分别是：“客户交易服务器”和“数据库管理系统”。
2.4.1.4 基础设施接口（Infrastructure Interface）
定义：表示用于获取由节点提供的基础设施服务访问点。与前面介绍过的接口概念相仿，基础设施接口也具有双向性，一个用于表示节点通过此基础设施接口对外提供服务，另外一个则用于表示节点需要从外界获取何种基础设施服务。不同的基础设施接口可以提供相同的基础设施服务。基础设施接口所涉及到的主要关系可归纳为：
基础设施接口可以通过组合关系而作为节点的一个组成部分。
基础设施接口可以被其他节点所使用。
基础设施服务可以被分配给基础设施接口，用于表示该服务是通过此接口而被提供给外界环境的。
表示图符：
实例：在本案例中，名为“数据库管理系统”的系统软件具有“数据访问接口”这一基础设施接口，因而外界对数据的操作都可以通过此接口来实现。
2.4.1.5 网络（Network）
定义：用于表示在两个或两个以上设备之间进行通信的媒介，同时它也是不同节点之间各种通信路径的物理实现。网络元素一般具有诸如带宽、延迟之类的属性。网络所涉及到的主要关系可归纳为：
网络连接两个或两个以上的设备。
网络实现了一个或多个通信路径。
网络可以包含其他子网络。
表示图符：
实例：在本案例中，“大型机”和“终端机”这两台设备之间通过带宽为100Mbits/s的局域网进行互联。
2.4.1.6 通信路径（Communication Path）
定义：用于表示多个节点之间的逻辑连接，并且通过这些链接节点才可以进行节点之间的数据交换。通信路径所涉及到的主要关系可归纳为：
通信路径连接两个或两个以上的节点。
一条通信路径可由一个或多个网络所实现。
表示图符：
实例：在本案例中，节点“应用服务器”和节点“客户端”之间通过“消息队列”这一通信路径进行数据交互。
2.4.2 行为元素
2.4.2.1 基础设施功能（Infrastructure Function）
定义：用于对节点所执行的基础设施行为进行组织的行为元素，他描述了节点的内部功能。基础设施功能所涉及到的主要关系可归纳为：
基础设施功能可以实现基础设施服务。
基础设施功能可以使用由其他基础设施功能所实现的基础设施服务。
基础设施功能可以访问制品。
基础设施功能可被分配给节点，用于表示该节点所能够执行的行为。
表示图符：
实例：在本案例中，“数据库管理系统”节点具有（需要注意是，这里虽然采用嵌套的表述方式，但节点与基础设施功能之间是通过指派关系来联系的）“提供数据访问功能”和“管理数据功能”这两个基础设施功能，并且前者实现了名为“数据访问服务”的基础设施服务，而后者则实现了“数据管理服务”。
2.4.2.2 基础设施服务（Infrastructure Service）
定义：用于表示由一个或多个节点通过基础设施接口对外提供的对外界具有意义的功能单元。基础设施服务所涉及到的主要关系可归纳为：
基础设施服务可以被应用组件或节点所使用。
基础设施服务可以被节点所实现。
基础设施服务可以被基础设施功能所实现。
基础设施服务可以被分配到基础设施接口之上。
基础设施服务可以访问制品。
表示图符：
实例：在本案例中，“面向消息中间件”系统软件实现了“消息服务”这一基础设施服务。
2.4.3 信息元素
2.4.3.1 制品（Artifact）
定义：用于表示在软件开发过程或系统的部署和运行过程中使用和产生的数据的物理表现。制品通常被用来描述诸如源文件、可执行文件、脚本、数据库表、消息、文档、规范说明，以及模型文件这样的软件产品。制品所涉及到的主要关系可归纳为：
一个应用组件或系统软件可以被一个或多个制品所实现，即可执行组件类型的制品。
一个数据对象可以被一个或多个制品所实现，即数据文件类型的制品。
制品可以被分配到节点之上，用于表示该制品被部署到此节点之上。
表示图符：
实例：在本案例中，“风险管理EJB”这一制品被指派给（部署到）了系统软件“J2EE应用服务器”之上，而这其中“风险管理EJB”代表了一个可部署的代码单元。
2.5 模型元素扩展——动机
动机模型元素扩展是ArchiMate 2.0版本中依照ArchiMate扩展规则而新加入的内容。ArchiMate之前的版本从操作角度对企业的运行情况进行了描述和建模，但这些内容并不能说明采用当前方式进行建模的缘由。缺失了如此重要的一环，我们无法回答建模的合理性，因而更无法促使企业的战略目标与战术实现相协调。通过结合TOGAF标准，我们可以看出：这些缺失的内容实际上就是TOGAF中“预备阶段”、“架构愿景阶段”、“架构变更阶段”，以及充当各阶段运行引擎的“需求管理阶段”所要建立或维护的核心。为了填补这一空白，ArchiMate
2.0引入了新的概念元素、关系和视角。本章将详细描述其新加入的概念元素，而对于新加入的关系和视角将分别在后面的部分中进行描述。ArchiMate
2.0对于动机扩展所引入的新概念元素，以及他们之间的主要关系归纳如下：
由于动机扩展的目标是解释为何建模，以及建模与具体原因之间的关系，因而动机扩展中新加入的概念元素都是用来叙述缘由的描述性概念，他们既不具备结构化的实体，亦不会执行什么样的“行为”，同时在意义上还有着“信息元素”的影子，并且从上面的元模型图示中我们可以看到，动机元素（Motivational
Element）并不继承于结构元素（Structure Element），所以不同于业务、应用和技术层面中对概念元素所采用的“结构元素”、“行为元素”和“信息元素”分类归纳方法，在ArchiMate中，动机扩展的概念元素被统一概括为“动机概念元素（Motivational
Concepts）”。
2.5.1 动机概念元素
动机概念元素对企业架构建设的缘由进行了描述，并将这些元素与前面所说的企业三层领域建模元素联系了起来。从比较高的抽象层次来看，动机概念元素包括
“干系人（Stakeholder）”和“动机元素（Motivational Element）”这两个概念元素，他们之间的关联关系体现了：建立企业架构的每个动机都应该反映某干系人的意图。如果把抽象层次降低，我们会发现“动机元素”被特化成了六个更为具体的“动机”概念，他们分别是：“驱动力（Driver）”、“评估（Assessment）”、“目标（Goal）”、“原则（Principle）”、“需求（Requirement）”和“约束（Constraint）”。这六个概念元素以及他们之间的关系以一种从抽象到具体的顺序描述了建立企业架构的缘由：
“驱动力”描述了企业架构建立的根本缘由，他既可以是由于外部环境的变化而引起，也可能是源自企业内部，而这种内部驱动力往往也反映了某个干系人的关注点，因而该元素通常与一个“干系人”元素相关联。
要想将“驱动力”做进一步的落实，企业需要对其进行分析和评估，而这正是“评估”概念元素所描述的目标。
“驱动力”经过评估后，企业可由此分析出企业的优势、弱点、机会和风险，而这些内容可以转化为各个具体的企业战略“目标”。
为了将确立后的“目标”付诸实现，企业需要将其细化为若干“原则”和“需求”。这两者均是为了实现“目标”而建，但“原则”具有更加广阔的范围，它是在一定上下文环境之下针对若干具体需求共性的抽象，所以在元模型中我们可以发现：“需求”实现了“目标”，同时也实现了“原则”，而“需求”和“原则”都是为了实现“目标”而生的。
“需求”不仅仅是对需要做什么所进行的描述，还可能是对不能做什么而进行的界定。对于后一种情况，ArchiMate采用特化了的“需求”概念元素，亦即“约束”概念元素，来进行描述。
动机概念元素并不是一套密闭的元模型，况且ArchiMate建模基本原则也不允许这种领域隔离的情况存在，因而他与前述三个领域有着紧密的关系。在后面的跨领域关联章节中，笔者将会对此进行更加详细的阐述。
2.5.1.1 干系人（Stakeholder）
定义：用于代表对于架构产生的结果具有利益关系，或对其进行关注的个人、团队或组织的类别。干系人涉及到的主要关系可归纳为：
干系人之间通过聚合关系来表现他们之间的组织结构。
干系人与其他动机概念元素之间通过关联关系来表示对其他各种动机概念具有的利益关系或关注点。
表示图符：
实例：在本案例中，名为“董事会”的干系人包含了三个子干系人，分别是：“CEO”、“CIO”和“CFO”。
2.5.1.2 驱动力（Driver）
定义：用于表示引起或驱动组织发生变化的事物。驱动力涉及到的主要关系可归纳为：
来源于组织内部的驱动力需要通过关联干系人来表示其具体来源，以及涉及到了谁的利益和关注。
驱动力之间可以通过聚合关系来表示其层级结构。
驱动力和评估之间通过关联关系来描述评估所对应的驱动力。
驱动力和目标之间通过关联关系来描述两者之间的相关性。
表示图符：
实例：在本案例中，“经济环境变化”是一个外部驱动力，而“股东满意”和“客户满意”则是两个内部驱动力，因而他们有相关干系人与之关联。“客户满意”这一内部驱动力涉及到了干系人“CEO”和“客户”的利益和关注，而“股东满意”这一内部驱动力仅与干系人“CEO”相关。驱动力“股东满意”还包含了两个子驱动力，分别为“股价”和“利润”，而且前者受外部驱动力“经济环境变化”所影响（两者之间通过“影响”关系相连，这是动机扩展新加入的关系，在后面章节将会对其进行详细描述）。
2.5.1.3 评估（Assessment）
定义：用于表示对于驱动力进行分析的结果。针对驱动力进行分析而获取的评估将会揭示企业的优势、缺陷、机会和风险，而这些内容将会直接引起现有目标的变化或新目标的设立，并触及到企业架构的变化。评估涉及到的主要关系可归纳为：
评估可以与一个或多个驱动力进行关联，而一个驱动力亦可以关联一个或多个评估。
评估之间可以通过聚合来表现其层次关系。
评估与目标之间通过关联关系来体现他们之间的相关性。
表示图符：
实例：本案例列举了两个驱动力，分别为“客户满意”和“技术支持”。对于驱动力“客户满意”来说，它具有两个评估结果：“客户流失”和“客户投诉”，而后者还可细分为“缺乏对索赔状况认识”、“索赔提交不便”、“缺乏对产品组合的认识”和“信息不完整或不一致”这四个评估元素；对于“技术支持”驱动力来说，其评估结果为“等待队列漫长”和“长服务时间”。
2.5.1.4 目标（Goal）
定义：用于表示干系人所期望达到的最终状态。对于目标的描述通常采用定性的词语，例如“增加”、“改善”等，并且一个目标可以被进一步解构为更详尽的子目标，例如“增加利润”目标可以被细分为“节省开支”和“增加销售”这两个目标。目标涉及到的主要关系可归纳为：
目标之间可以通过聚合关系来体现其层次关系。
目标与评估之间通过关联关系来体现两者之间的相关性。
目标与驱动力之间通过关联关系来体现两者之间的相关性。
原则、需求和约束可以用来实现目标。
表示图符：
实例：在本案例中，驱动力“利润”包含两个方面的驱动力，分别为“销售”和“成本”，而通过对驱动力“成本”的分析，我们得到了两个评估结果：“应用成本过高”和“人员成本过高”。针对两个评估做进一步分析后我们可以得出：“应用成本过高”可以通过实现“降低维护成本”和“降低应用的直接成本”这两个目标来解决，而“人员成本过高”则可以通过实现“降低人员工作量”来解决；“降低人员工作量”这一目标又可以被进一步细分为“减少人工工作”和“减少与客户交互”这两个子目标。
2.5.1.5 需求（Requirement）
定义：用于表示系统为了达成目标所必须做的实现。需求涉及到的主要关系可归纳为：
一个需求可以实现一个或多个目标，且一个目标可以被一个或多个需求所实现。
一个需求可以实现一个或多个原则，且一个原则可以被一个或多个需求所实现。
表示图符：
实例：在本案例中，为了改善“缺乏对产品组合的认识”这一评估结果，企业制定了“提高产品组合管理”的目标，而这一目标可以通过实现“指派个人助理”和/或“提供在线产品组合服务”这两个需求来达成。在这两个需求中，前者可以通过一个人工服务来实现（通过参与者“助理”提供的名为“个人产品组合服务”的业务服务），而后者则可以通过一个自动化服务来实现（通过应用组件“产品组合管理应用”实现的名为“在线产品组合服务”的应用服务）。
2.5.1.6 约束（Constraint）
定义：用于表示针对系统实现方式的限制。约束概念元素是需求概念元素的特化，因而他继承了需求的属性和关系，但约束并不描述系统需要实现什么，而是界定了系统实现所不能触及的领域。
表示图符：
实例：本案例展示了实现一个“产品组合管理应用”受制于两个约束：其一是“需要采用Java实现应用”，而另外一个是“软件实现项目”的预算被限制于“500k欧元”之内。
2.5.1.7 原则（Principle）
定义：用于表示在给定的上下文环境下所有系统的共通性质或实现方式。原则与需求相类似，他们都描述了为了达成目标而必须遵循的规则，但从适用范围来讲，原则比需求具有更广泛的适用性，它所描述的是确定的环境下所有系统必须遵循的通用规则，而需求则是针对特定系统而制定的。原则所涉及到的主要关系可归纳为：
一个原则可以实现一个或多个目标，而一个目标可以被一个或多个原则所实现。
一个原则可以被一个或多个需求所实现。
表示图符：
实例：在本案例中，为了实现“减少与客户交互”和“较少人工工作”这两个目标，系统需要遵循“系统必须面向客户”这一原则，而此原则可以通过实现“提供在线产品组合服务”和“提供在线信息服务”这两个需求来达成。
2.6 模型元素扩展——实施和迁移
与动机扩展一样，实施和迁移扩展模型元素也是ArchiMate 2.0中依照ArchiMate扩展规则而新加入的内容。通过对各种项目管理领域中的标准和最佳实践进行抽象和概括，这些新的概念元素以及他们之间的关系能够用来支持TOGAF后期的几个将企业架构付诸实现的阶段（“机会与解决方案阶段”、“迁移规划阶段”和“实施治理阶段”）。不过作为高层次的抽象，这些概念元素并不能涵盖某一具体项目管理方法（例如PMBok,
PRINCE2等）中的具体细节，但是在实际应用中建模者可以通过“特化”来进一步丰富这一扩展中的内容，从而达成与实际环境的无缝连接。ArchiMate
2.0对于实施和迁移扩展所引入的新概念元素以及他们之间的主要关系归纳如下：
2.6.1 实施和迁移概念元素
2.6.1.1 工作包（Work Package）
定义：用于表示为了在指定时间内完成某一特定目标的一系列行为。由此可见，一个工作包具有明确的起止时间，并应具备清晰的目标，它既可以对各个项目进行建模，也可以用来描述方案、项目或项目组合中的子项目或任务。工作包所涉及到的主要关系可归纳为：
一个工作包可以被一个或多个交付物所实现。
业务角色可以被指派给工作包。
工作包可以被指派到某个位置之上。
表示图符：
实例：在本案例中，为了将应用组合进行合理化建设，公司启动了“应用组合合理化方案”，并通过工作包概念元素对其进行建模。该方案包含两个前后衔接的项目（均用工作包概念元素进行描述）：首先是通过“后台系统集成项目”对除了客户关系管理系统之外的各个后台系统进行集成，然后通过“客户关系管理系统集成项目”来对客户关系管理系统进行整合。
2.6.1.2 交付物（Deliverable）
定义：用于表示经过精确定义的工作包的输出产物。工作包执行的最终结果是产生一系列的交付物，这些交付物既可以用来描述报告、服务、软件和硬件产品等有形事物，可以对诸如组织架构变动等无形事物进行建模。交付物所涉及到的主要关系可归纳为：
交付物之间通过聚合关系来体现其层次结构。
交付物可以被工作包所实现。
交付物可以被指派到某个位置之上。
交付物可以实现架构或架构的一个部分，因而交付物和各个核心元素（应用组件、业务流程或服务等）之间可以通过实现关系进行关联。并且由于工作包与交付物之间具有实现关系，工作包与核心元素之间也具有着间接的实现关系。
表示图符：
实例：在本案例中，“集成的后台系统”这一交付物所包含的子交付物体系被解构为下图：
2.6.1.3 稳定阶段（Plateau）
定义：用于表示在一个有限的时间区间内架构所处的相对稳定的状态。从前面关于TOGAF的介绍中我们可以知道，在“业务架构”、“信息系统架构”和“技术架构”这三个阶段中，企业可以制定出基线架构以及目标架构，由于这两个架构可能差距很大，且这一从“基线”到“目标”的转变会持续很长一段时间，因而在接下来的“机会与解决方案”阶段中，企业可以制定一系列过渡架构，将原本冗长繁复的变革过程细化为一系列的过渡阶段，并且以此为基础将一个个独立的工作包和项目组织为受管控的项目组合和方案。为了对这些中间过渡状态进行描述，实施和迁移扩展便引入了“稳定阶段”这一概念元素。稳定阶段所涉及到的主要关系可归纳为：
稳定阶段可以聚合一系列核心元素，从而体现了稳定阶段对应的是哪些架构元素（应用组件、业务流程或服务等）。
表示图符：
实例：本案例描述了从基线架构到目标架构的迁移过程，以及在此期间所需经历的几个过渡状态。
2.6.1.4 差距（Gap）
定义：用于表示在两个稳定阶段之间进行差距分析的结果。差距可以通过关联关系与稳定阶段相关的各个核心概念元素相联系，用以表示在两个稳定阶段之间是哪些元素形成了“差距”。
表示图符：
实例：本案例展示了基线架构与目标架构之间在基础设施方面的差距：增加“后 台应用服务器”；删除“车辆保险应用服务器”和“法律援助后台服务器”。
2.7 关系模型元素
企业架构模型包括了各种概念元素以及他们之间的关系，这其中的概念元素已经在前面几节中进行了阐述，而这些概念元素之间的关系则是本节的叙述重点。虽然ArchiMate中具有种类繁多的概念元素，并且横跨企业中的多个领域，但是这些元素之间的关系经过抽象后却并不像想象中那么多，并且其中的大部分关系来源于诸如UML、BPMN等在业界被广泛使用的标准，因而掌握起来并不难。总体来说，ArchiMate中的关系元素可概括为如下三类：
结构关系：用于表示相同或不同类型的概念元素间结构的关系。
行为关系：用于表示行为元素之间的依赖关系。
其他类型关系：不属于以上两种类型的关系。
2.7.1 结构关系
结构关系有着强弱之分，这一点在通过关系链合并（即两个概念元素间如果没有直接关系连接，但是却可以通过一系列结构关系而间接相连，则他们之间可看作为具有一条间接结构关系，且此间接关系与关系链中关系强度最弱的结构关系相同）而获取概念元素之间的间接关系时尤为重要。本节将按照从强到弱的顺序对这些结构关系一一进行描述。
2.7.1.1 组合关系（Composition Relationship）
定义：用于表示一个对象是由其他若干组件组合而成。组合关系来源于UML，因而与同样来源于UML的聚合关系（Aggregation）相比，虽然两者都表示了包含与被包含的关系，但具有组合关系的容器对象和组件对象具有更强的联系：一个对象能且只能作为一个组成部分而被组合到一个容器对象之中。
实例：在本案例中，“财务应用”包含了三个子组件，分别为：“会计组件”、“计费组件”和“支付组件”。
2.7.1.2 聚合关系（Aggregation Relationship）
定义：用于表示一个对象组织包含了其他若干对象。与组合关系类似，聚合关系也来源于UML。不过与组合关系不同的是，聚合关系没有那么强的约束关系，即一个对象可以通过聚合关系而从属于两个或两个以上的容器对象。
实例：在本案例中，“车辆保险”这一产品包含了“更改条件”和“提交索赔”这两个业务服务，但这两个业务服务并不会因为该产品的退出而消失，亦即具有不同的生命周期。
2.7.1.3 分配关系（Assignment Relationship）
定义：分配关系用于在主动性结构元素（业务角色或应用组件等）和表示其行为的行为元素之间，或在业务参与者与其所扮演的业务角色之间创建联系。
表示图符：
实例：本案例描述了两种分配关系：其一是“支付接口”与“支付服务”之间的支配关系，他表示了需要通过“支付接口”来获取“支付服务”；另外一个是“财务应用”与“支付功能”之间的支配关系，他表示了“财务应用”这一主动性结构元素能够执行“支付功能”这一行为。
2.7.1.4 实现关系（Realization Relationship）
定义：实现关系用于将逻辑实体与用于实现他的更加具体的实体连接在一起，从而体现两者之间的实现与被实现关系。实现关系可以存在于运行的情景之下（例如，业务流程或业务功能实现业务服务），也可以存在于设计-实现这一情景中（例如，数据对象实现业务对象，或制品实现应用组件）。在ArchiMate
2.0的动机扩展中，实现关系的意义有所拓宽，因为在此扩展中仅有逻辑概念，而并不像核心元素中那样具有从逻辑到现实的跨越，所以在这一扩展中，实现关系除了具有原来的逻辑到现实这一方向外，还具备了仅在逻辑维度上逐步细化方向。动机扩展为实现关系的使用增加了如下三个方面的情境：
目标可被原则、需求或约束所实现。
原则可被需求或约束所实现。
需求可被用于表示具体系统的概念元素所实现。
表示图符：
实例：本案例展示了实现关系所适用的两种情景：从运行角度来说，“财务应用”这一应用组件实现了“计费服务”；从设计-实现这个角度来说，数据对象“计费数据”实现了业务数据“单据”。
2.7.1.5 使用关系（Use by Relationship）
定义：使用关系被用来描述流程、功能或交互对于服务的使用，以及业务角色、应用组件或合作集合对各类接口的访问。从其表示图符来看，使用关系借用了UML中依赖关系的表示图符，不过两者的含义却不尽相同。
表示图符：
实例：在本案例中，名为“更新客户信息服务”的应用服务被“变更地址流程”这一业务流程所使用，而隶属于“客户关系管理系统”的“客户关系管理接口”则被业务角色“前台职员”所使用。
2.7.1.6 访问关系（Access Relationship）
定义：用于描述行为元素对业务或数据对象的访问。访问关系具有方向性，其图符连线上的箭头指示了信息流动的方向（如果箭头指向业务或数据对象，则表示行为元素对其执行写操作，反之则表示行为元素对业务或数据对象执行读操作），而如果图符没有箭头指向则表示行为元素与业务或数据对象之间同时具有读和写的关系。
表示图符：
实例：在本案例中，“创建发票”业务流程创建了业务对象“发票”，而业务流程“发送发票”则对此业务对象执行了读取操作。
2.7.1.7 影响关系（Influence Relationship）
定义：影响关系描述了某些动机元素对其他动机元素具有正面或负面的影响。影响关系反映了现实中在决策阶段需要进行权衡利弊的情景，处在这条关系两端的元素并没有很强的依赖或实现关系，因而并不能因为影响源元素对受影响的元素有正面影响就把其当作实现受影响元素的必要条件，同样也不能因为影响源元素对受影响的元素有负面影响就在受影响元素的实现之中将其排除。
表示图符：
实例：本案例展示了用来实现“提高产品组合管理”这一目标的两个需求所产生的利弊权衡情形。对于“指派个人助理”这一需求来说，他对“降低人员工作量”这一目标有着负面影响（两者之间的影响关系标注了两个“-”），但他对“改善客户满意度”却有着非常正面的影响（影响关系被标注了两个“+”），同理可知，此需求对于“系统必须面客户”这一原则也有着非常负面的影响。
2.7.1.8 关联关系（Association Relationship）
定义：用于描述对象之间不同于以上各种特定关系的联系。关联关系来源于UML，因而与其所定义的一样，主要用来描述业务或数据对象之间不属于组合、聚合以及特化（继承）的关系。除此之外，在ArchiMate中关联关系还主要用来联系信息元素与其他种类的元素，例如业务对象与表现方式、表现方式与含义等。
表示图符：
实例：在本案例中，业务对象“保险政策”在“客户”和“参保对象”这两个业务对象之间具有关联关系，并且“保险销售服务”与“受保”这一价值元素之间也有着关联关系。
2.7.2 行为关系
2.7.2.1 触发关系（Triggering Relationship）
定义：用于表示流程、功能、交互或事件之间的时序或因果关系。
表示图符：
实例：本案例描述了从“保险申请”事件触发“接收申请”业务流程开始到“申请批准”事件的产生为结束的整个过程。
2.7.2.2 流动关系（Flow Relationship）
定义：用于描述流程、功能、交互或事件之间对信息或价值的交换或转移。
表示图符：
实例：在本案例中，业务功能“日程安排”将索赔诉求的处理安排信息传递给业务功能“索赔评估”，而后者最后会将评估结果转移给“理赔”这一业务功能，从而进行对于索赔诉求的最终处理。
2.7.3 其他类型关系
2.7.3.1 分组关系（Grouping）
定义：用于根据一系列对象的通用性质来对他们进行分类组织。分组关系与UML中的“包”概念相类似，他们都可用来对各种对象进行分类组织。与组合和聚合关系不同，分组关系中并没有一个容器性对象，所有对象都被平等地组织在一起。
表示图符：
实例：在本来中，“财务管理”分组中包含了此领域中的相关业务对象：“单据数据”、“账户信息”和“债务信息”。
2.7.3.2 连接关系（Junction）
定义：用于连接相同类型的行为关系。
表示图符：
实例：在本案例中，“访问申请”业务流程之后通过连接关系对该业务流程之后可能出现的两种情况进行了描述：如果申请被接受，则进入“通知接受申请”业务流程；如果申请被否决，则进入“通知拒绝申请”业务流程。由此可见，本案例中的连接关系描述了流程之间逻辑或的关系，但这并不代表连接关系只能表示这一种逻辑关系，建模人员甚至可以通过ArchiMate扩展规则对连接关系进行特化，从而能够清楚地表达各种逻辑关系。
2.7.3.3 特化关系（Specialization Relationship）
定义：用于表示一个对象是另外一个对象的特殊化对象。此关系来源于UML的特化（继承）关系，但在ArchiMate中此关系所涉及的概念元素却不仅仅是业务或数据对象。任何一个概念元素的实例均可为同类型概念元素的其他实例的特化。
表示图符：
实例：从本案例中可以看出，业务流程“处理旅游保险”和“处理行李保险”都是业务流程“处理保险”的具体特化。
2.8 ArchiMate扩展机制
通过前面几节的介绍，我们对ArchiMate 2.0中定义的概念元素以及他们之间的关系有了应该有了一定的了解，但这并不代表这些元素和关系就足够应对一切情况，因而基于如下的原因，ArchiMate需要有一定的扩展机制来应对现实使用过程所面对的具体问题：
由于ArchiMate面向的是企业架构模型，且此种模型的抽象层次较高，因而在实际使用过程中一定会遇到ArchiMate标准所没有精确定义的情况。所以ArchiMate需要通过扩展来应对具体领域中的问题。
企业中可能已经存在了大量的具体领域内的模型，而企业架构模型也只是在抽象层次上与这些具体领域模型的描述内容有所区别，但由于他们都是对“企业”这一客观对象进行建模，所以他们之间应该是相互融合，而不是相互割裂的。为了达到这种融合，采用ArchiMate所建立的模型需要经过扩展来兼容各具体领域模型。
模型的重要目标之一就是辅助分析决策，虽然ArchiMate在不同领域之间建立了联系，但缺乏足够的细节来支持针对具体领域模型的分析方法。
模型的重要目标还包括促成干系人之间的无障碍沟通，但由于不同领域、不同背景的干系人其使用的沟通语言也不尽相同，因而只有通过扩展ArchiMate才能帮助干系人之间的沟通。
由此可见，ArchiMate语言是一种核心语言，需要通过扩展来联系原本分离的具体领域内的模型，因而我们不能把他看成诸如UML这样的包罗万象的语言。实际上，ArchiMate的初衷也并不是要从头建立一种新的语言（那样只会带来新的学习曲线以及由此产生的抵制），而是对各种领域标准和最佳实践进行抽象后得到共通的部分，并以面向服务架构（SOA）概念为基础，将抽象出的各领域的通用联系起来，最后辅以扩展机制来适应各种具体情况。这一语言扩展规则可以总结为如下两点：
增加属性：前面介绍的各种概念元素只给出其定义而并没有设置其属性，因而建模人员可以根据需要为各种概念元素添加适当的属性。例如，如果要对企业进行性能分析，就需要为各个概念元素添加诸如服务时间、吞吐量这样的属性。由于属性的添加具有一定的背景性，即为了不同的目的所添加的属性也不尽相同，而概念元素却具有更强的稳定性，因而保证概念元素与属性的独立性是必要的。为了解决这一问题，ArchiMate扩展规则建议采用属性配置的方式来记录概念元素和特定属性的对应关系，并且这一映射配置的存储将独立于模型的存储。
进行特化：由于ArchiMate中的概念元素都是由各领域建模语言以及最佳实践抽象而来，因而也可以通过特化（继承）的方式将其转换回去，从而将各领域内特有的概念元素添加到ArchiMate之中。ArchiMate
2.0中列举了如下实例：
2.9 跨领域关联
通过前面对于概念元素以及他们之间的关系的介绍，我们可以在高抽象层次上创建企业架构模型，并可以通过扩展机制来适应实际应用过程中遇到的各种问题，不过ArchiMate所不同于具体领域内建模语言的根本还是在于它能将各个分立的领域联系起来，从而建立具有一致性的模型。前面已经提到过，在ArchiMate中跨领域的联系的基础是面向服务架构（SOA），不过为了达成业务与信息技术之间的协调整合，通常来讲，还需要注意其他的概念元素间关系，而本节将针对这些跨领域关联的常用模式进行归纳总结。
2.9.1 业务-信息技术协调整合
在上图中，包含在“业务层”分组之内的是具有跨领域关联关系的各个业务领域概念元素，而分组之外的则是与之相关的信息技术领域（应用层和技术层）内的概念元素。如图所示，业务与信息技术之间的跨领域关联关系主要包括了如下几个方面的内容：
使用关系：业务行为元素（业务流程、功能、交互）可以使用应用服务，而业务参与者和业务角色除了可以使用应用服务外还可以对应用接口进行使用。
实现关系：数据对象与业务对象之间具有实现关系，而这条关系说明了数据对象是相关业务对象的一个电子化表现方式。
分配关系：
应用组件与业务流程、功能、交互和服务之间具有分配关系，用以体现业务行为元素是在应用组件支持下的自动化行为，而对于非自动化行为来说，各行为元素和应用组件之间应该采用使用关系。需要注意的是，ArchiMate
2.0中对于涉及到分配关系的跨领域关联的描述中还包括了应用接口和业务服务之间的关系，不过就笔者的理解来说这条关系应该不是一条直接关系，而是将相关关系链（应用接口与应用组件之间具有组合关系，而应用组件可以通过分配关系关联到业务服务，而在这条关系链中由于分配关系优先级最低，因而应用组件和业务服务之间具有间接的分配关系）进行转换而得的间接关系，因为应用接口是应用组件对外提供服务的渠道，同时也是应用组件的一个组成部分，因而对于通过应用接口使用应用服务的业务服务或其他业务行为元素来说，将应用接口直接“分配”给他们是有待商榷的。
应用组件与位置之间的分配关系指明了应用组件的空间位置。
与前一点相类似，数据对象与位置之间的分配关系亦指明了数据对象，这个业务对象的电子化表现方式，在空间中的位置。
技术层各概念元素中的节点、网络、通信路径和制品与位置之间也具有分配关系，分别用以表示他们在空间中的位置。
聚合关系：产品和应用服务之间具有聚合关系，这说明应用服务可以作为产品的一个部分而直接提供给客户。同理，处于技术层中的基础设施服务也可以通过聚合关系而成为产品的一个组成部分。
2.9.2 应用-技术协调整合
上图展示了应用层和技术层之间发生跨领域关联的各种概念元素，以及他们之间的关系。这些关系主要包括如下几个方面的内容：
使用关系：
应用组件和应用功能可以使用技术层面的基础设施服务。
应用组件可以使用技术层面的基础设施接口。
实现关系：
数据对象与制品之间的实现关系体现了逻辑上的数据对象与物理上的存储或部署对象之间的关系。例如，数据对象可以存储在一份数据文件之中。
同理，应用组件和制品之间的实现关系也体现了逻辑上的应用或应用组件与物理上的可执行程序文件之间的关系。
2.9.3 动机扩展-核心协调整合
动机扩展的目标是对采用核心概念元素所建模型的原因进行描述，因而这一扩展所包含的各个概念元素与核心概念元素之间有着密不可分的关联。需要注意的是，ArchiMate
2.0（第10.4节Cross-Aspect Dependencies）已经明确指出：动机扩展中仅有需求和约束元素可以通过实现关系与核心概念元素发生直接关联，不过在其中的图72（本文中的图
203）中又为动机扩展元素与价值概念元素之间添加了一条影响关系，由于影响关系的定义只涉及到在动机概念元素之间描述权衡利弊的情况，因而其图72种所描绘的动机扩展元素与价值概念元素之间的影响关系不应该是一条间接关系（虽然两者之间可以通过关系链相连，不过按照合并规则最后获得的应该是关联关系而不是影响关系），而应该是一条直接关系。此外，
干系人与业务参与者之间的分配关系也应该是直接关系。因此，笔者认为上图中所表示的各条关系中，直接关系包括了需求、约束和核心概念元素之间实现关系、各动机扩展概念元素与价值之间的影响关系，以及干系人与业务参与者之间的分配关系。动机扩展与核心元素之间的关联关系主要包括如下内容：
影响关系：各个主要的动机概念元素（驱动力、评估、目标、原则、需求和约束）与业务层的概念元素“价值”之间具有影响关系，亦即这些表述建模动机的概念元素对于业务价值有着正面的或负面的影响，从而体现了不同动机之间的权衡关系。
实现关系：绝大部分核心概念元素（除了含义和价值等概念元素）可以实现动机扩展中的需求和约束这两个概念元素。需要注意的是，由于需求概念元素与价值概念元素之间有着影响关系，因而根据关系合并规则，那些用来实现需求和约束的核心概念元素与价值概念元素之间有着间接的影响关系。
分配关系：干系人概念元素所指代的是对架构产生的结果具有利益关系或对其进行关注的个人、团队或组织的类别，其并不特指某个特定的参与者个体或组织，所以为了体现他们之间的关联就需要通过分配关系将他们联系起来，而这与业务角色和业务参与者之间的分配关系也是相似的。
关联关系：干系人与价值和含义之间分别具有一条关联关系，不过从前面的叙述中我们可知，这两条关联关系应该是通过合并关系链而得的间接关系，而不是直接关系。不过从关联关系的定义来看，他们之间建立直接的关联关系也无不可，因而需要根据建模实际情况来进行判别。
2.9.4 实施和迁移扩展-核心协调整合
实施和迁移扩展的目标是对企业架构从设计走向实现的这一过程进行建模，因而其所包含的各种概念元素与核心概念元素之间也有着密不可分的关系，这些关系的主要内容包括：
分配关系：
业务角色与工作包之间具有分配关系，用以表示参与到工作包实施中的个人或团队所担负的职责。
位置与交付物、工作包之间具有分配关系，用以表示他们在空间中的位置。
聚合关系：稳定阶段描述了架构在一定期间内的状态，而为了对此稳定阶段包括了哪些架构的部分进行描述，我们需要通过聚合关系来联系稳定阶段与相关的核心概念元素。
关联关系：差距用于描述两个稳定阶段之间发生变化的架构部分，因而需要通过关联关系来对差距和代表了发生变化的架构部分的核心概念元素创建联系。
实现关系：交付物与绝大部分概念元素之间具有实现关系。
2.9.5 实施和迁移扩展-动机扩展协调整合
严格来说，实施和迁移扩展与动机扩展之间并没有直接的关联，而都是通过经由核心概念元素的关系链而进行关联。例如，交付物可以实现诸如应用组件、业务流程这样的核心元素，而后者又可以用来对动机扩展中的目标或需求进行实现。不过在实际建模过程中，在这两个扩展之间创建直接关联也有助于更加清晰地体现企业架构实现与动机之间的关系，且也符合ArchiMate的基本语法。这两种扩展之间的关系可总结如下：
聚合关系：由于对于架构的需求或目标都有其自身的生命周期，因而某一个具体需求或目标可能仅适用于某个稳定阶段，而另外的需求或目标则属于其他的稳定阶段。为了体现这种关系，稳定阶段概念元素可以聚合相关的需求或目标概念元素。
实现关系：从前面的例子可以看出，交付物概念元素与需求概念元素之间有着实现与被实现的关系，因而他们之间可以通过实现关系相联系。
|
