ArchiMate 2.0规范（二）

本文主要是介绍ArchiMate 2.0规范（二），希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

2.5 分层（Layering）

ArchiMate语言定义了三个主要的层（在接下来章节中的例子以不同的颜色描述），基于2.2和2.3节中所描述的专业化核心概念：

1。业务层( Business Layer )向外部客户提供产品和服务，实现该组织中业务参与者运作的业务流程。

2。应用层( Application Layer )以被（软件）应用实现的应用服务(application services )支持业务层。

3。技术层(Technology Layer )提供运行应用程序所需的基础设施服务（例如：处理，存储和通信服务），由计算机和通信硬件和系统软件来实现。

不同层的模型其总体结构是相似的。虽然他们的确切性质和粒度不同，但却使用了同一类型的概念和关系。我们将在第3，4，5章节进一步开拓这些概念，以获得具体到某一特定层的概念。图2显示了在每一层中的中央结构。

在服务的方向线上，最重要的关系是层间的关系，它被形式化为“used by”，它表明，较高层如何使用较低层的服务。（但请注意，该服务需要不仅可以用于一个较高层元素，也可用于同一层中的元素）链接的第二种类型形式化为实现关系（realization relationships ）：在较低层的元素可实现较高层的可比性元素，例如，“数据对象”（应用层），可以实现“业务对象”（业务层）;或“制品”（技术层），可以实现“数据对象”或“应用程序组件“（应用层）。

2.6 ArchiMate框架（The ArchiMate Framework）

上一节中确定的切面和层可被归纳入九宫格内，如图4所示。

Figure 4: Architectural Framework

重要的是要明白基于切面和层次概念分类，仅仅是一个全局性的。要在切面和层之间定义一个严格的边界是不可能的，因为链接不同切面和层间的概念，在一个连贯的体系结构描述扮演着中间角色。例如，运行后概念性讨论，（业务）功能和（业务）角色有所提前，作为“纯粹行为”和“纯粹结构”之间的中介概念。

除了图4中的核心切面（被动结构，行为和活动结构），其实质是主要操作，企业架构师的工作涉及到许多其他切面，并未明确涵盖于ArchiMate框架，其中一些可能跨越几个（或全部）概念域;例如：

•目标，原则和需求 Goals, principles, and requirements

•风险与安全 Risk and security

•治理 Governance

•策略和业务规则 Policies and business rules

•成本 Costs

•性能 Performance

•定时 Timing

•规划和进化 Planning and evolution

并非所有这些切面都可以使用标准语言扩展机制来完全覆盖，在第9章中所述。 ArchiMate语言整体上对这些切面提供支持，以便于工具提供商和方法论专家，可以添加特定的扩展。这些模块化的扩展，添加新概念，关系或属性，同时遵循ArchiMate明确的限制（设计尽可能的小）。

此外，它可能是有用于添加概念或属性到相关的设计过程，而非对系统或组织加以描述或设计。这些概念或属性的例子是需求和设计决策。

这种规范的新发布，解决了两个这样的扩展：动机扩展（Motivation extension ），实现和迁移扩展（ Implementation and Migration extension ）。在下一节中介绍了动机扩展，并在第10章更详细的阐述。 2.8节介绍了在实现和迁移扩展，并在第11章更详细的阐述。其他方面可能会在未来语言的扩展中处理（见第12章，会做一个更深入的讨论）。

2.7 动机扩展（Motivation Extension）

ArchiMate的核心概念聚焦于描述支持企业的系统架构。不包括的元素，以不同的方式，激发企业的设计和操作。这些动机方面对应于Zachman框架的“why”列[8]，这是在ArchiMate1.0设计中故意留下的范围。

ArchiMate动机扩展增加了动机概念，如目标，原则和要求。它解决了企业架构与其动机元素所描述上下文一致性。

动机元素被定义为一个提供了上下文或栖身于企业架构背后原因的元素。

此外，动机扩展确认比肩（StakeHolder，源自命理术语），驱动和评估的概念。比肩代表影响，指导或约束企业的人（群）或机构。驱动代表内部或外部影响企业计划和目标的因素。这些驱动的优势，劣势，机会和威胁的理解将有助于妥善解决这些问题的计划和目标的形成。

图5演示：架构描述的核心元素通过需求与动机元素相关联。在核心元素，如服务，流程和应用程序被分配实现之前，目标和原则都必须翻译成需求。在第10章会解释动机元素之间可能存在的关系。

另一个核心元模型和动机扩展之间的关系是一个business actor 可能被分配成一个stakeholder ，一个参与者可能满足而被视为一个动机角色（相对于操作业务角色）。

Figure 5: Relationship between Core and Motivational Elements in ArchiMate

ArchiMate中引入动机概念的主要原因是，用以支持需求管理和支持TOGAF ADM的初步阶段，第一阶段（架构愿景），建立高层次的业务目标、架构原则、最初的业务需求。

需求管理是在企业架构设计和管理过程中的一项重要活动。来自各利益相关者的目标，形成了应对任何组织变化的基础。这些目标，需要译为组织架构的需求。此架构要能反映日复一日的(业务)操作中，需求如何被服务，流程和应用软件实现。因此，架构质量在很大程度上取决于：

捕捉、分析相关目标和需求的能力；

它们可以通过架构实现的程度；

减缓目标和需求的变更。

原则和需求是密切相关[3]。原则是一般性规则和指导，是帮助通告和支持机构(organization )着手履行其任务的方式。与此相反，需求约束和塑造企业架构的一些具体设计。此对应的是两种常用的诠释企业架构之间的区别：

（i）作为一些组织机构的结构，依据其组件和它们之间的关系，

（ii）作为一套原则，应适用于任何此类结构。 [2]

第一种解释的范围涉及该组织的一个单一的设计，而第二个涉及任何可能的设计。需求与第一种解释相关。相反，原则是独立的一个具体的设计，必须在设计组织机构架构的过程中，专业化形成需求。这使得应用程序的原则成为需求管理的重要部分。

不当的需求管理是受损或失败的IT项目[21]的主要原因之一，因为超过预算或期限，或不能提供预期的结果。这是下面引用由[22] Brooks措辞：“如果做错了，没有其他部分的工作可以削弱(负面）结果中的系统。”因此，需求管理流程和架构开发流程，需要具备良好的对齐，并且需求和实现这些需求的架构元素之间保持可追溯性。

在TOGAF架构开发方法（ADM）中[4]，需求管理是中央的流程，适用于所有的ADM周期阶段。虽然TOGAF在“需求管理”上提出需求，但并未从需求工程领域现有的语言，方法和工具上做强制或建议。 ArchiMate通过动机概念支持需求管理流程。

2.8 实现和迁移扩展（Implementation and Migration Extension）

ArchiMate的实施和迁移扩展，增加了概念以支持ADM的后期阶段，涉及到架构的实施和迁移：

阶段E（机会和解决办法）；

阶段F（迁徙计划）；

阶段G（实现治理）。

这个扩展包括建模实施方案和项目支持，投资组合，计划和项目管理，和高原的概念，以支持迁移规划的概念。被提议的扩展旨在涵盖方案和项目管理标准以及最佳实践的主要概念，如MSP[23]，PRINCE2[24]，PMBOK[25]。对于其中方法之一的具体概念并非扩展的一部分，但可作为泛型概念的专业化界定。以此方式，扩展中定义的概念和关系的集合保持在最低限度。

此外，源自ArchiMate核心或动机扩展的概念或关系尽可能被重用。图6描述了源自实现和迁移扩展的概念与源自ArchiMate核心和动机扩展概念之间的关系。可交付可以实现的架构内的核心要素。一定的差距，可与任意数量的核心要素。一个位置可能会被分配到工作包和交付。一个工作包的实现要求间接通过实现（例如，应用程序组件，业务流程或服务）的核心要素。此外，核心要素与动机扩展的其他概念派生关系的手段。在第10和第11章更详细的解释可能实施和迁移之间的关系，核心，和激励元素。

【Deliverable】是架构内可实现的核心元素。【gap】可与任意数量的核心元素关联。【location】可能会被分配到【work packages】和【deliverables】。【work packages】的实现要求间接通过核心元素的实现（例如，应用程序组件，业务流程或服务）。同时，核心元素通过派生关系的方式链接到其他动机扩展的概念。在第10和第11章更详细的解释在实现和迁移，核心，和动机元素当中可能的关系。

Figure 6: Relationships between Motivational, Core, and Implementation and Migration Elements

2.9 ArchiMate and TOGAF

本技术标准中所述的ArchiMate语言，补充了TOGAF[4]，它提供了一套独立于供应商的概念，包括图形表示，这有助于建立一致性，完整模型“水线以下”，它能以TOGAF视图形式描述。

ArchiMate语言的核心结构紧密对应于在TOGAF ADM中所解决的三个主要架构。图7说明了这一点。这种对应关系，使得确立TOGAF视图和ArchiMate视点之间的映射相当容易。

Figure7: Correspondence between ArchiMate and TOGAF

但是一些TOGAF视图并不与ArchiMate核心相匹配。乃是由于TOGAF的所涉范围较广，尤其着重于更多高层次的战略问题和较低层次的系统开发工程方面，而ArchiMate的核心只局限于抽象的企业架构层次。然而，两种语言的扩展（在第10和第11章中所述），解决了这些额外的问题。它们定义了诸如目标，原则和要求，以及规划和迁移导向的概念。图8说明了这一点。

Figure 8: Correspondence between ArchiMate (including extensions) and TOGAF

虽然TOGAF的定义的一些视点，不能很容易地映射到ArchiMate视点，ArchiMate语言和分析技术，支持这些视点所涉及的概念。虽然它们之间并非一个一对一的映射，仍然有相当数量的ArchiMate视点和TOGAF所定义的视点有对应关系。虽然源自ArchiMate，TOGAF的相应视点不一定具有相同的覆盖，但我们可以看到，这两种方法的许多视点在很大程度上解决了同样的问题。