业务层元素用于以与技术无关的方式对企业的运营组织进行建模，而战略元素（第 7 章）用于对企业的战略方向和选择进行建模。

8.1 业务层元模型

图52 概述了业务层元素及其关系。“业务内部主动结构元素”，“业务内部行为元素”和“业务被动结构元素”是抽象元素；只有它们的专业化(在下面的部分中定义)才在模型中实例化。

图 52 ：业务层元模型

注意：此图未显示所有允许的关系；语言中的每个元素都可以与相同类型的元素具有组成，聚合和专业化关系。此外，还有一些间接关系可以导出，如第5.7 节所述。

8.2 主动结构元素

业务层的主动结构方面是指组织的静态结构，即组成组织的实体及其关系。该活动的实体为对象（例如，业务参与者或业务角色）执行行为，如业务流程或功能（功能）。业务参与者可以是个人（例如，客户或雇员），也可以是在组织中具有永久（或至少长期）地位的人员（组织单位）和资源组。后者的典型示例是部门和业务部门。

架构描述着重于结构，这意味着组织内实体之间的相互关系起着重要的作用。为了使这一点明确，已经引入了业务接口的元素。

引入业务接口的元素是为了建模可以访问角色为环境提供的服务的（逻辑或物理）位置或渠道。可以在许多不同的接口上提供相同的服务。例如，通过邮件，电话或互联网。与应用程序建模相比，在当前的业务层建模方法中识别业务接口元素并不常见。

在业务层中，定义了三种类型的内部主动结构元素：业务参与者，业务角色和业务协作。

图 53 ：业务内部主动结构元素

注意：此图未显示所有允许的关系；语言中的每个元素都可以与相同类型的元素具有组成，聚合和专业化关系。此外，还有一些间接关系可以导出，如第5.7 节所述。允许的关系的完整规范可以在附录B中找到。

8.2.1 业务主角

业务主角 表示能够执行行为的业务实体。

业务主角是执行特定行为的职责体，业务主角可以被分配多个业务角色；即，它属于业务层。参与者可能包括实际组织之外的实体；例如，客户和合作伙伴。业务主角可以在不同的详细程度上代表此类业务实体，并且可以与TOGAF框架[ 4 ] 中的参与者和组织单位相对应。业务主角的示例包括人员，部门和业务部门。

可以将一个业务主角分配给一个或多个业务角色。然后，它可以执行将这些业务角色分配给的行为。业务参与者可以聚集在一个位置。业务主角的名字最好是一个名词。业务主角可以是特定的个人或组织；例如“ John Smith”或“ ABC Corporation”，或者它们可能是通用的；例如“客户”或“供应商”。

图 54 ：业务主角符号

8.2.2 业务角色

业务角色 代表执行特定行为的责任，可以将角色分配给该角色，或者角色在特定动作或事件中扮演的角色。

具有特定职责或技能的业务角色被分配给业务流程或业务功能。分配给业务角色的业务参与者负责通过执行行为或委派和管理其绩效来确保执行相应的行为。除了业务角色与行为的关系之外，业务角色在（结构）组织意义上也是有用的。例如，在组织内部的分工中。

可以将一个业务角色分配给一个或多个业务流程或业务功能，而可以将一个业务参与者分配给一个或多个业务角色。业务接口或应用程序接口可以充当业务角色，而业务接口可以是业务角色的一部分。业务角色的名称最好应为名词。

图 55 ：业务角色符号

ArchiMate建模者可以代表作为业务主角或业务角色执行行为的通用组织实体。例如，业务主角“供应商”描述了一个组织实体，而业务角色“供应商”则描述了一个责任。可以分配特定或通用的业务角色来承担描绘为业务主角的职责。例如，可以将特定业务角色“ ABC Corporation”或通用业务角色“ Business Partner”分配给“供应商”业务角色。

8.2.3 业务协作

业务协作 表示两个或多个业务内部主动结构元素的集合，这些元素一起工作以执行集体行为。

业务流程或功能可以解释为单个业务角色的内部行为。在某些情况下，行为是一个以上业务角色的集体努力。实际上，两个或多个业务角色的协作会导致集体行为，这可能不仅仅是单独角色的行为之和。业务合作代表了这种集体努力。业务交互可用于描述在业务协作中发生的内部行为。业务协作是组织中执行协作行为（交互）的业务角色，参与者或其他协作的（可能是临时的）集合。与部门不同，业务协作不需要在组织内具有正式（永久）身份；它专门针对角色之间的特定交互或一组交互。在建模不同组织（例如提供商网络）之间的企业对企业（B2B）交互以及描述社交网络时，此功能特别有用。

业务协作可以聚合许多业务角色，主角或其他协作，并且可以分配给一个或多个业务交互或其他业务内部行为元素。业务接口或应用程序接口可以为业务协作提供服务，而业务协作可以具有业务接口（通过组合以及通过派生关系的聚合）。业务合作的名称最好应为名词。保持业务协作不命名的情况也很普遍。

图 56 ：业务协作符号

8.2.4 业务接口

业务接口表示向外部提供业务服务的访问点。

业务接口将业务服务的功能向其他业务角色或主角公开。它通常称为频道（电话，Internet，本地办公室等）。相同的业务服务可能通过不同的接口公开。

业务接口可以通过组成关系成为业务角色或参与者的一部分，并且业务接口可以充当业务角色。可以将一个业务接口分配给一个或多个业务服务，这意味着这些服务由该接口公开。业务接口的名称最好应为名词。

图 57 ：业务接口符号

8.2.5 示例

建模为业务主角的“ ArchiSurance联络中心”由三名员工（也称为业务主角）组成：“ Greg”，“ Joan”和“ Larry”。“ ArchiSurance联络中心”具有三个服务于客户的业务界面：“电话”，“电子邮件”和“网络聊天”。格雷格（Greg）担任“旅行保险理赔分析师”的业务角色，琼（Joan）担任“家庭保险产品专家”的业务角色，拉里（Larry）担任“客户服务代表”的业务角色。前两个业务角色是业务角色“专家”的专业化。“高风险索赔裁决”是具有两个业务角色的业务协作：“专家”和“客户服务代表”。

示例 23 ：业务主动结构元素

8.3 行为元素

基于服务导向，ArchiMate元模型的行为部分的关键设计决策是组织的“外部”和“内部”行为之间的区别。

外部可见的行为由元素业务服务建模。业务服务代表了一项连贯的功能，可以为环境提供增值，而与内部实现此功能的方式无关。可以区分提供给外部客户的“外部”业务服务和提供组织内流程或功能的支持功能的“内部”业务服务。

区分可以实现服务的几种内部行为元素。尽管两者之间的区分并不总是很明显，但区分行为的过程视图 和功能视图通常很有用。定义了与这些视图相关的两个元素，即业务流程和业务功能。这两个元素都可以用于对更详细的业务流程/功能进行分组，但是可以基于不同的分组标准。一个业务流程表示一个由较小的流程/功能组成的工作流程，具有一个或多个清晰的起点并带来一定的结果。有时将其描述为“客户的客户”，在组织内的子流程中，该客户也可能是内部客户。这种业务流程的目标是“使客户满意或满意” [ 10 ]。一个业务功能提供的功能，可为一个或多个业务流程的有用。它根据例如所需的技能，资源，（应用程序）支持等对行为进行分组。通常，组织的业务流程是根据产品和服务定义的组织提供的功能，而业务功能是例如将资源分配给任务和应用程序支持的基础。

一个业务交互类似于业务流程或功能行为的单位，但其在组织中的两个或多个角色的协作进行。不像在AMBER [相互作用概念9 ]，它是一个原子 的协作行为单位，ArchiMate业务交互可以被分解为更小的相互作用。尽管从参与协作的角色的角度来看，交互是外部行为，但该行为是整个协作的内部行为。与流程或功能相似，可以通过业务服务使业务交互的结果对环境可用。

一个业务事件是发生的事情（外部），并可能影响业务流程，功能，或相互作用。业务事件元素类似于BPMN事件元素，类似于AMBER [ 9 ]中的触发元素，以及UML活动图中的初始状态和最终状态元素。但是，ArchiMate业务事件在某种意义上更适用，因为它除了触发器之外还可以用于建模其他类型的事件。

在业务层中，定义了三种内部行为元素：业务流程，业务功能和业务交互。

图 58 ：业务内部行为要素

注意：此图未显示所有允许的关系；语言中的每个元素都可以与相同类型的元素具有组成，聚合和专业化关系。此外，还有一些间接关系可以导出，如第5.7 节所述。允许的关系的完整规范可以在附录B中找到。

8.3.1 业务流程

业务流程 表示实现特定结果（例如一组定义的产品或业务服务）的一系列业务行为。

业务流程描述了生产一组产品和服务所需的业务角色执行的内部行为。对于消费者而言，产品和服务是相关的，所需的行为仅仅是一个黑匣子，因此称为“内部”。

复杂的业务流程可能是其他更细粒度的流程的集合。可以为每个角色分配更精细的角色。

业务流程和业务功能之间存在潜在的多对多关系。非正式地讲，流程描述了某种活动的“流程”，而职能则根据所需的技能，知识，资源等对活动进行分组。

业务流程可以由任何其他业务行为元素（例如，业务事件，业务流程，业务功能或业务交互）触发或触发。业务流程可以访问业务对象。业务流程可以实现一个或多个业务服务，并且可以使用（内部）业务服务或应用程序服务。可以将业务角色分配给业务流程以手动执行此流程。自动化的业务流程可以通过应用程序流程来实现。业务流程的名称应使用动词或动词-名词组合清楚地指示预定义的操作序列，并且可以包括单词“ process”。例如“裁决要求”，“雇员入职”，“批准程序”或“财务报告”。

在ArchiMate模型中，描述了业务流程的存在。可以使用ArchiMate语言中的同一业务流程元素来表达高级业务，端到端流程，宏流和工作流。但是，它没有详细列出活动流程。这通常是在业务流程建模期间完成的，在该流程中，可以使用业务流程设计语言来扩展业务流程。例如BPMN [ 12 ]。

图 59 ：业务流程符号

8.3.2 业务功能

业务功能 表示基于一组选定的标准（通常是所需的业务资源和/或能力）的业务行为的集合，这些标准与组织紧密相关，但不一定由组织明确管理。

就像业务流程一样，业务功能也描述了业务角色执行的内部行为。但是，虽然业务流程根据实现产品或服务所需的活动的顺序或流程对行为进行分组，但是业务功能通常会根据所需的业务资源，技能，能力，知识等对行为进行分组。

业务流程和业务功能之间存在潜在的多对多关系。通常，复杂的过程涉及提供各种功能的活动。从这个意义上讲，业务流程形成了一系列业务功能。通常，业务功能从业务角度提供附加值。组织单位或应用程序由于其特定的业务活动分组而可能与业务功能一致。

业务功能可以由任何其他业务行为元素（业务事件，业务流程，业务功能或业务交互）触发或触发。业务功能可以访问业务对象。业务功能可以实现一项或多项业务服务，并且可以由业务，应用程序或技术服务来提供服务。可以将业务角色分配给业务功能。业务职能的名称应清楚表明行为明确。例如客户管理，索赔管理，会员服务，回收或付款处理。

图 60 ：业务功能符号

8.3.3 业务交互

业务交互 表示由两个或多个业务主角，业务角色或业务协作（的协作）执行的集体业务行为的单位。

业务交互类似于业务流程/功能，但是虽然流程/功能可以由单个角色执行，但交互是由多个角色协作来执行。协作中的角色分担执行交互的责任。

业务交互可以由任何其他业务行为元素（业务事件，业务流程，业务功能或业务交互）触发或触发。业务交互可以访问业务对象。业务交互可以实现一个或多个业务服务，并且可以使用（内部）业务服务或应用程序服务。可以将业务协作或两个或多个业务参与者或角色分配给业务交互。业务交互的名称最好是简单现在时的动词。

图 61 ：业务交互符号

8.3.4 业务事件

业务事件 代表组织状态的变化。

业务流程可能触发或中断业务流程和其他业务行为。同样，业务流程可能引发触发其他业务流程，功能或交互的事件。与业务流程，功能和交互不同，业务事件是瞬时的：它没有持续时间。事件可以源自组织的环境（例如，来自客户），但是内部事件也可以发生，例如由组织内的其他过程生成。

业务事件可能具有时间属性，该时间属性表示事件发生的时刻。例如，它可以用于对时间表进行建模。例如，对触发循环业务流程以在该月的每个第一个星期一执行的事件进行建模。

业务事件可能由业务流程，业务功能或业务交互触发或触发（引发）。业务事件可以访问业务对象，并且可以由其他业务事件组成。业务事件的名称最好是完整时态的动词。例如“收到索赔”。

图 62 ：业务事件符号

8.3.5 业务服务

业务服务 表示显式定义的行为，业务角色，业务主角或业务协作将其暴露给其环境。

业务服务向其环境公开业务角色或协作的功能。可通过一个或多个业务界面访问此功能。

从环境的角度来看，业务服务应提供有意义的行为单元。它有一个目的，指出了该实用程序。该环境包括来自组织内部和外部的（行为）用户。业务服务可以是外部的，面向客户的服务（例如，旅行保险服务）或内部支持服务（例如，资源管理服务）。

业务服务与价值相关联。业务服务可以为业务流程，业务功能或业务交互提供服务。业务流程，业务功能或业务交互可以实现业务服务。可以将业务接口分配给业务服务。业务服务可以访问业务对象。业务服务的名称最好是以“ -ing”结尾的动词；例如交易处理。另外，可以使用明确包含单词“ service”的名称。

图 63 ：业务服务符号

8.3.6 示例

“索赔管理”是一项业务功能，由许多业务流程和业务交互组成。该业务功能实现了“索赔处理”业务服务。业务事件“索赔申请”触发了第一个业务流程“接受索赔”，而后者又触发了业务流程“分配索赔”。根据索赔的类型，执行业务流程“裁决标准索赔”或业务交互“裁决高风险索赔”。裁决高风险索赔是一项业务互动，因为根据公司政策，应始终由两个人参与此活动，以最大程度地降低欺诈风险。裁定后，“通知客户”和“付款索赔”业务流程是并行执行的，当两者都完成后，

例子 24 ：业务行为元素

8.4 被动结构元素

业务层的被动结构方面包含由行为（例如业务流程或功能）操纵的被动结构元素（业务对象）。被动实体代表企业思考领域的重要概念。

在业务层中，有两种主要类型的被动结构元素：业务对象和业务表象。此外，在产品上下文中使用的契约是业务对象的专门化。

图 64 ：业务被动结构元素

8.4.1 业务对象

业务对象 表示在特定业务域内使用的概念。

如3.6 节所述，ArchiMate语言通常侧重于类型的建模，而不是实例的建模，因为这与描述的企业体系结构级别最相关。因此，业务对象通常会对操作中可能存在多个实例的对象类型（参见 UML类）进行建模。仅偶尔地，业务对象表示由行为元素（例如业务流程）产生和使用的信息的实际实例。对于单例类型尤其如此。即，只有一个实例的类型。

可以定义多种类型的业务对象。业务对象在不触发或执行流程的意义上是被动的。一个业务对象可以用来表示从业务角度来看相关的信息资产，并且可以通过数据对象来实现。

可以通过业务流程，功能，业务交互，业务事件或业务服务来访问业务对象（例如，在信息对象的情况下，可以创建，读取或编写它们）。业务对象可能与其他业务对象具有关联，专业化，聚合或组合关系。业务对象可以通过表示或数据对象（或两者）来实现。业务对象的名称最好应为名词。

图 65 ：业务对象符号

8.4.2 契约

契约 代表提供者和消费者之间协议的正式或非正式规范，该规范指定与产品相关的权利和义务，并建立交互作用的功能和非功能参数。

契约要素可用于在法律意义上为契约建模，也可用于与产品相关的更为非正式的协议。它也可以是SLA，也可以是SLA，其中描述了有关作为产品一部分的服务的功能和质量的协议。契约是业务对象的专门化。

适用于业务对象的关系也适用于契约。另外，契约可能与产品具有聚合关系。合同的名称最好是名词。

图 66 ：契约符号

8.4.3 表示

表示 表示业务对象承载的信息的可感知对象。

表示（例如，消息或文档）是与业务对象相关的可感知信息载体。如果相关，可以用多种方式对表示进行分类；例如，就媒体（电子，纸张，音频等）或格式（HTML，ASCII，PDF，RTF等）而言。单个业务对象可以具有许多不同的表示形式。同样，单个表示可以实现一个或多个特定的业务对象。

含义可以与带有此含义的表示形式相关联。表示的名称最好是名词。

图 67 ：表示符号

8.4.4 例子

业务对象“声明”可以通过以下三个物理表示中的任意一个（在索赔管理过程的不同阶段）来实现：“提交表格”，“声明文件摘要”或“声明信”。所有这些表示都是指“政策摘要”表示，它实现了契约“保险单”。

示例 25 ：业务被动结构元素

8.5 复合元素

业务层包含一个复合元素：product。这将跨ArchiMate核心语言的各层汇总或组成服务和被动结构元素。

图68 显示了元模型的适用部分。这可以跨层，如第12 章所述。

图 68 ：产品元模型

8.5.1 产品

产品 代表服务和/或被动结构元素的连贯集合，并附带合同/协议集，这些契约/协议整体上提供给（内部或外部）客户。

此定义涵盖了信息密集型组织中常见的基于服务的无形或信息产品，以及有形的物理产品。金融或信息产品由一系列服务和契约组成，契约规定了与产品相关的特征，权利和要求。“购买”产品赋予客户使用相关服务的权利。

通常，product元素用于指定产品类型。与例如实现或支持产品的过程相比，组织中产品类型的数量通常相对稳定。“购买”通常是与产品相关的服务之一，这会导致该产品的新实例（属于特定客户）。同样，可能会有修改或销毁产品的服务。

产品可以聚合或组成业务服务，应用程序服务和技术服务，业务对象，数据对象和技术对象以及合同。因此，产品可以聚合或构成业务层以外的其他层的元素。

值可以与产品关联。产品的名称通常是与客户沟通时使用的名称，或者可能是更通用的名词（例如，“旅行保险”）。

图 69 ：产品符号

8.5.2 示例

产品“保险”由契约“保险政策”和业务服务“客户服务”组成，后者汇总了其他四个业务服务：“应用程序”，“续订”，“索赔处理”和“上诉”。“汽车保险”产品是通用“保险”产品的专业化产品，带有附加的“服务好省钱”业务服务以及随附的契约“服务好省钱协议”。

示例 26 ：业务复合元素：产品

8.6 业务层元素摘要

表6 概述了业务层元素及其定义。

表 6 ：业务层元素