| 编辑推荐: |
本文主要介绍技术层模型元素、模型元素扩展——动机、模型元素扩展——实施和迁移等相关内容。
本文来自于闹市闲云，由火龙果软件Alice编辑、推荐。
|
|
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）
定义：用于表示在两个稳定阶段之间进行差距分析的结果。差距可以通过关联关系与稳定阶段相关的各个核心概念元素相联系，用以表示在两个稳定阶段之间是哪些元素形成了“差距”。
表示图符：
实例：本案例展示了基线架构与目标架构之间在基础设施方面的差距：增加“后 台应用服务器”；删除“车辆保险应用服务器”和“法律援助后台服务器”。
|
