企业架构研究总结（42）——企业架构与建模之ArchiMate详述（中）

时间 2019-11-17

原文原文链接

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建模基本原则也不容许这种领域隔离的状况存在，于是他与前述三个领域有着紧密的关系。在后面的跨领域关联章节中，笔者将会对此进行更加详细的阐述。ui

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对于实施和迁移扩展所引入的新概念元素以及他们之间的主要关系概括以下：3d

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）

定义：用于表示在两个稳定阶段之间进行差距分析的结果。差距能够经过关联关系与稳定阶段相关的各个核心概念元素相联系，用以表示在两个稳定阶段之间是哪些元素造成了“差距”。
表示图符：

实例：本案例展现了基线架构与目标架构之间在基础设施方面的差距：增长“后台应用服务器”；删除“车辆保险应用服务器”和“法律援助后台服务器”。