2.4 技术层模型元素--企业架构(TOGAF认证)
技术层模型元素包括了企业在信息基础设施方面(企业中基本的软硬件环境,包括物理设备、系统软件等为信息化提供基本支持的设施)的各种概念元素,以及他们之间的关系。与应用层模型元素相类似,技术层模型元素中的大部分概念元素也来源于UML 2.0,这同样也是因为UML 2.0在这一领域已经成为被广泛接受的事实标准。在ArchiMate 2.0中,对企业技术层进行建模的各种概念元素以及他们之间的主要关系(元模型)被定义如下:
2.4.1 结构元素
2.4.1.1 节点(Node)
-
定义:用于表示存储或部署执行各种制品的计算资源的主动性概念元素。这一概念与UML 2.0中的节点概念是相同的,是构成技术层结构方面的基本单元,也是此领域建模中的核心元素。节点可以用来对应用服务器、数据服务器或客户工作站来进行建模,概括来讲,其所描述的内容是组合了硬件资源以及系统软件并对外提供计算资源的逻辑单元。节点所涉及到的主要关系可归纳为:
-
节点元素之间通过通信路径进行互联。
-
制品可以被分配给节点,用于表示该制品被存储或部署在此节点之上。
-
表示图符:
2.4.1.2 设备(Device)
-
定义:用于表示存储或部署执行各种制品的硬件资源。设备概念元素是节点元素的特化,他代表了具有处理能力的各种物理资源,例如大型机、个人计算机或路由器等。设备所涉及到的主要关系可归纳为:
-
设备可以组合或聚合其他的子设备。
-
设备之间通过网络进行互联。
-
制品可以被分配给设备,用以表示制品被存储或部署到此设备之上。
-
系统软件可以被分配给设备,用以表示系统软件的安装或部署位置。
-
一个节点可以包含一个或多个设备。
-
表示图符:
2.4.1.3 系统软件(System Software)
-
定义:用于表示一种软件环境,使得各种特定类型的软件组件和对象能以制品的形式部署于其中。系统软件概念元素也是节点的特化,专门用于对各种制品所处的软件环境进行建模。系统软件和设备通常组合在一起来形成一个节点。系统软件所涉及到的主要关系可归纳为:
-
系统软件可被分配给设备。
-
制品可被分配给系统软件。
-
节点可以组合或聚合系统软件。
-
表示图符:
2.4.1.4 基础设施接口(Infrastructure Interface)
-
定义:表示用于获取由节点提供的基础设施服务访问点。与前面介绍过的接口概念相仿,基础设施接口也具有双向性,一个用于表示节点通过此基础设施接口对外提供服务,另外一个则用于表示节点需要从外界获取何种基础设施服务。不同的基础设施接口可以提供相同的基础设施服务。基础设施接口所涉及到的主要关系可归纳为:
-
基础设施接口可以通过组合关系而作为节点的一个组成部分。
-
基础设施接口可以被其他节点所使用。
-
基础设施服务可以被分配给基础设施接口,用于表示该服务是通过此接口而被提供给外界环境的。
-
表示图符:
2.4.1.5 网络(Network)
-
定义:用于表示在两个或两个以上设备之间进行通信的媒介,同时它也是不同节点之间各种通信路径的物理实现。网络元素一般具有诸如带宽、延迟之类的属性。网络所涉及到的主要关系可归纳为:
-
网络连接两个或两个以上的设备。
-
网络实现了一个或多个通信路径。
-
网络可以包含其他子网络。
-
表示图符:
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)
-
定义:用于表示在软件开发过程或系统的部署和运行过程中使用和产生的数据的物理表现。制品通常被用来描述诸如源文件、可执行文件、脚本、数据库表、消息、文档、规范说明,以及模型文件这样的软件产品。制品所涉及到的主要关系可归纳为:
-
一个应用组件或系统软件可以被一个或多个制品所实现,即可执行组件类型的制品。
-
一个数据对象可以被一个或多个制品所实现,即数据文件类型的制品。
-
制品可以被分配到节点之上,用于表示该制品被部署到此节点之上。
-
表示图符:
2.5 模型元素扩展——动机--企业架构(TOGAF认证)
动机模型元素扩展是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)
-
定义:用于代表对于架构产生的结果具有利益关系,或对其进行关注的个人、团队或组织的类别。干系人涉及到的主要关系可归纳为:
-
干系人之间通过聚合关系来表现他们之间的组织结构。
-
干系人与其他动机概念元素之间通过关联关系来表示对其他各种动机概念具有的利益关系或关注点。
-
表示图符:
2.5.1.2 驱动力(Driver)
-
定义:用于表示引起或驱动组织发生变化的事物。驱动力涉及到的主要关系可归纳为:
-
来源于组织内部的驱动力需要通过关联干系人来表示其具体来源,以及涉及到了谁的利益和关注。
-
驱动力之间可以通过聚合关系来表示其层级结构。
-
驱动力和评估之间通过关联关系来描述评估所对应的驱动力。
-
驱动力和目标之间通过关联关系来描述两者之间的相关性。
-
表示图符:
2.5.1.3 评估(Assessment)
-
定义:用于表示对于驱动力进行分析的结果。针对驱动力进行分析而获取的评估将会揭示企业的优势、缺陷、机会和风险,而这些内容将会直接引起现有目标的变化或新目标的设立,并触及到企业架构的变化。评估涉及到的主要关系可归纳为:
-
评估可以与一个或多个驱动力进行关联,而一个驱动力亦可以关联一个或多个评估。
-
评估之间可以通过聚合来表现其层次关系。
-
评估与目标之间通过关联关系来体现他们之间的相关性。
-
表示图符:
2.5.1.4 目标(Goal)
-
定义:用于表示干系人所期望达到的最终状态。对于目标的描述通常采用定性的词语,例如“增加”、“改善”等,并且一个目标可以被进一步解构为更详尽的子目标,例如“增加利润”目标可以被细分为“节省开支”和“增加销售”这两个目标。目标涉及到的主要关系可归纳为:
-
目标之间可以通过聚合关系来体现其层次关系。
-
目标与评估之间通过关联关系来体现两者之间的相关性。
-
目标与驱动力之间通过关联关系来体现两者之间的相关性。
-
原则、需求和约束可以用来实现目标。
-
表示图符:
2.5.1.5 需求(Requirement)
-
定义:用于表示系统为了达成目标所必须做的实现。需求涉及到的主要关系可归纳为:
-
一个需求可以实现一个或多个目标,且一个目标可以被一个或多个需求所实现。
-
一个需求可以实现一个或多个原则,且一个原则可以被一个或多个需求所实现。
-
表示图符:
2.5.1.6 约束(Constraint)
-
定义:用于表示针对系统实现方式的限制。约束概念元素是需求概念元素的特化,因而他继承了需求的属性和关系,但约束并不描述系统需要实现什么,而是界定了系统实现所不能触及的领域。
-
表示图符:
2.5.1.7 原则(Principle)
-
定义:用于表示在给定的上下文环境下所有系统的共通性质或实现方式。原则与需求相类似,他们都描述了为了达成目标而必须遵循的规则,但从适用范围来讲,原则比需求具有更广泛的适用性,它所描述的是确定的环境下所有系统必须遵循的通用规则,而需求则是针对特定系统而制定的。原则所涉及到的主要关系可归纳为:
-
一个原则可以实现一个或多个目标,而一个目标可以被一个或多个原则所实现。
-
一个原则可以被一个或多个需求所实现。
-
表示图符:
2.6 模型元素扩展——实施和迁移--企业架构(TOGAF认证)
与动机扩展一样,实施和迁移扩展模型元素也是ArchiMate 2.0中依照ArchiMate扩展规则而新加入的内容。通过对各种项目管理领域中的标准和最佳实践进行抽象和概括,这些新的概念元素以及他们之间的关系能够用来支持TOGAF后期的几个将企业架构付诸实现的阶段(“机会与解决方案阶段”、“迁移规划阶段”和“实施治理阶段”)。不过作为高层次的抽象,这些概念元素并不能涵盖某一具体项目管理方法(例如PMBok, PRINCE2等)中的具体细节,但是在实际应用中建模者可以通过“特化”来进一步丰富这一扩展中的内容,从而达成与实际环境的无缝连接。ArchiMate 2.0对于实施和迁移扩展所引入的新概念元素以及他们之间的主要关系归纳如下:
2.6.1 实施和迁移概念元素--企业架构(TOGAF认证)
2.6.1.1 工作包(Work Package)
-
定义:用于表示为了在指定时间内完成某一特定目标的一系列行为。由此可见,一个工作包具有明确的起止时间,并应具备清晰的目标,它既可以对各个项目进行建模,也可以用来描述方案、项目或项目组合中的子项目或任务。工作包所涉及到的主要关系可归纳为:
-
一个工作包可以被一个或多个交付物所实现。
-
业务角色可以被指派给工作包。
-
工作包可以被指派到某个位置之上。
-
表示图符:
2.6.1.2 交付物(Deliverable)
-
定义:用于表示经过精确定义的工作包的输出产物。工作包执行的最终结果是产生一系列的交付物,这些交付物既可以用来描述报告、服务、软件和硬件产品等有形事物,可以对诸如组织架构变动等无形事物进行建模。交付物所涉及到的主要关系可归纳为:
-
交付物之间通过聚合关系来体现其层次结构。
-
交付物可以被工作包所实现。
-
交付物可以被指派到某个位置之上。
-
交付物可以实现架构或架构的一个部分,因而交付物和各个核心元素(应用组件、业务流程或服务等)之间可以通过实现关系进行关联。并且由于工作包与交付物之间具有实现关系,工作包与核心元素之间也具有着间接的实现关系。
-
表示图符:
2.6.1.3 稳定阶段(Plateau)
-
定义:用于表示在一个有限的时间区间内架构所处的相对稳定的状态。从前面关于TOGAF的介绍中我们可以知道,在“业务架构”、“信息系统架构”和“技术架构”这三个阶段中,企业可以制定出基线架构以及目标架构,由于这两个架构可能差距很大,且这一从“基线”到“目标”的转变会持续很长一段时间,因而在接下来的“机会与解决方案”阶段中,企业可以制定一系列过渡架构,将原本冗长繁复的变革过程细化为一系列的过渡阶段,并且以此为基础将一个个独立的工作包和项目组织为受管控的项目组合和方案。为了对这些中间过渡状态进行描述,实施和迁移扩展便引入了“稳定阶段”这一概念元素。稳定阶段所涉及到的主要关系可归纳为:
-
稳定阶段可以聚合一系列核心元素,从而体现了稳定阶段对应的是哪些架构元素(应用组件、业务流程或服务等)。
-
表示图符:
2.6.1.4 差距(Gap)
-
定义:用于表示在两个稳定阶段之间进行差距分析的结果。差距可以通过关联关系与稳定阶段相关的各个核心概念元素相联系,用以表示在两个稳定阶段之间是哪些元素形成了“差距”。
-
表示图符:
参加培训请联系:倪老师 手机(微信):1871378400 QQ:1658122838
[1] |