TOGAF架构内容框架之内容元模型（下）

2.2 治理扩展（Governance Extensions）

治理扩展元模型内容

治理扩展部分的意图在于引入额外的，并且与支持运营治理的目标和业务服务相关的结构化数据。

2.2.1 关注范围

为目标制定评测标准以及将这些评测与服务相联系的能力。
为服务沟通或外界用户与系统之间的服务交付提供契约的能力。
定义可重用的服务质量的能力。
创建额外的图形来展示系统的归属和管理。

2.2.2 适用场景

当一个组织认为在IT方面的变更将会对其当前的运营治理模型产生非常重大的影响时。
当一个组织针对服务水平有着不同粒度的需求时，并且这些服务水平将因为不同的服务而有所不同。
当一个组织正在寻求转变其运营治理实践时。
当一个组织着重关注于业务驱动力和目标，以及如何将这些内容追溯到服务水平时。

2.2.3 使用效益

可以通过一种更加结构化的方式来定义服务水平：
- 描述更加详尽。
- 在交互契约之间重用服务配置。
- 加强针对业务目标的跟踪。
能够以一种更加结构化的方式来考虑对于组织运营和运营治理模型的影响：
- 对于系统和数据的归属有着额外的图形表述。
- 对于系统运营和运营流程之间的依赖性有着额外的图形表述。

2.3 服务扩展（Services Extensions）

服务扩展元模型内容

通过引入信息系统服务（IS Services）的概念，服务扩展部分使得组织可以采用一种更加精细的方式来对服务组合进行建模。信息系统服务由各个应用直接支持，并成为了一个用于减轻针对业务服务约束的抽象层，同时也使得各技术干系人可以在信息系统服务目录之中增添更多的形式。

2.3.1 关注范围

针对作为业务服务扩展的信息系统服务的创建。

2.3.2 适用场景

业务对于其服务具有一个预设的定义，但这些服务与技术和架构方面的需求并不吻合。
业务和信息技术分别采用不同语言来描述相似的能力。
信息技术服务不符合业务需求，特别是在服务质量、性能能见度和管理粒度这些领域。
刚开始将业务纳入到有关信息技术架构的讨论当中。

2.3.3 使用效益

业务服务可以在核心内容元模型的约束范围之外进行定义，从而使得业务干系人的参与更加自然。
信息系统服务可以根据一个与实现紧密相关的模型而进行定义，从而提供了一个更加现实的解决方案抽象来支持信息技术方面决策。
业务和信息系统服务之间的关系揭示了业务视图与信息系统视图相吻合以及有偏差的地方。

2.4 流程建模扩展（Process Modeling Extensions）

流程建模扩展元模型内容

流程建模扩展通过为内容元模型引入事件、产品和控制的概念来为流程进行更加详尽的建模。一般来讲，企业架构并不深入到流程的层面，但是对于以流程或事件为中心的组织来说，通过针对此扩展部分的使用，组织可以通过一种更加正规化的方式来描述流程，这也是非常必要的。

2.4.1 关注范围

用作流程触发的事件的创建。
用作流程执行的业务逻辑和流转管理的各种控制的创建。
用作流程输出代表的各种产品的创建。
有关事件图的创建。事件图用于跟踪组织中的各个触发器以及他们的状态变化。

2.4.2 适用场景

架构必须着重关注于状态和事件。
架构需要显式地对流程控制的各步骤进行识别和储存。
架构具有关键或者复杂的流程。

2.4.3 使用效益

此扩展使得详尽的流程建模和流程制品分类成为可能。
可用于支持合规性活动。
可用于对进行重新调整的遗留流程或非架构流程进行解构分析。

2.5 数据扩展（Data Extensions）

数据扩展元模型内容

数据扩展部分的内容使得企业可以通过一种更加成熟的方法对数据进行建模，并提高数据的封装性。在核心模型中，内容元模型通过对数据实体概念的引入建立起了数据建模的初步概念，而在数据扩展部分加入的数据组件概念对数据建模作了进一步的延展。数据组件形成了针对抽象数据实体的逻辑或物理封装，同时这些封装也可以成为治理以及部署到应用中的数据单元。

2.5.1 关注范围

创建用于将数据实体分组为若干模块的逻辑数据组件。这些封装模块的产生是以治理、安全和部署为目标的。
创建用于实现逻辑数据组件的物理数据组件，一般来讲类似于数据库、注册表、资源库、模式以及其他用于数据分割的技术。
创建数据生命周期、数据安全以及架构的数据迁移图，从而在更深的层次上展现关于数据的关注点。

2.5.2 适用场景

当数据的位置、封装、管理和访问对于架构的复杂度和风险有着很大的影响时。

2.5.3 使用效益

针对数据结构的建模与数据的位置相互独立，从而使得数据模型可以跨越多个系统而不用关注于其物理实现。
针对数据的逻辑分组可以被用来设置治理、安全或数据的部署边界，为围绕架构而产生的数据提供了全面的价值提升。

2.6 基础设施整合扩展（Infrastructure Consolidation Extensions）

基础设施整合扩展元模型内容

基础设施整合扩展部分适用于如下的情景之下：在企业中的应用和技术组合已被细分为粒度细小的模块，以及企业正在寻求将日常业务能力整合为由更少的位置、应用或技术组件所组成。

2.6.1 关注范围

创建一个位置实体来代表IT资产和服务的外部用户所处的地点。
创建逻辑和物理的应用组件来对应用的能力进行抽象，从而使应用的能力与真实存在的应用相分离。
创建逻辑和物理的应用组件来对产品类型进行抽象，从而使其与真实存在的技术产品相分离。
创建额外的针对资产位置、标准兼容性、应用结构、应用迁移和基础设施配置的图形表述。

2.6.2 适用场景

当存在很多具有重复或交叠功能的技术产品时。
当存在很多具有重复或交叠功能的应用时。
当各个应用分散地分布在不同的地理位置上，并且针对应用位置的决策逻辑并没有被相关干系人理解清楚时。
当应用将要被移植到综合性平台之上时。
当应用功能将要被移植到一个综合性应用之中时。

2.6.3 使用效益

使得在应用和技术领域中的功能冗余性得以被发现，并能够辅助有关此方面的分析。
支持标准兼容性的分析。
支持关于应用和技术整合方面迁移影响的分析。
支持更加详细的有关应用结构的架构性定义。

2.7 动机扩展（Motivation Extensions）

动机扩展元模型内容

驱动力、最终目标和阶段目标将会对组织为其客户提供业务服务产生影响，而动机扩展部分的内容使得企业可以针对这些内容进行更加结构化的建模。为此，在这一部分内容允许对服务契约（Service Contracts）进行更加有效地定义，以及更好的对于业务效能进行评测。

2.7.1 关注范围

为驱动力（Driver）创建了一个新的元模型实体，用以展现驱动或制约一个组织的各个因素。
为最终目标（Goal）创建了一个新的元模型实体，用以展现组织的战略目标和任务。
为阶段目标（Objective）创建了一个新的元模型实体，用以展现组织计划需要在中近期获得的成果。
创建“目标/阶段目标/服务”图，用以展现从驱动力、目标和阶段目标与各个服务的可追溯性。

2.7.2 适用场景

架构需要在更加详细的层面上理解组织的动机，而不仅仅是针对标准的业务或参与原则，以及通过核心元模型中以不太正规的方式定义各个目标。
组织具有相互冲突的驱动力和目标，并且这些冲突需要通过一种结构化的方式进行理解和解决。
服务层级（Service Levels）不被人所知或不清晰。

2.7.3 使用效益

标明整个企业中各项优先级次序错乱的行为，并阐明这些行为如何与共享服务发生交互。（例如，有些组织希望能够节省开支，而其他组织则需要增加容量）
可以通过一种更加结构化的方式对业务服务的竞争性需求进行展现，从而使得折中性服务层次得以被定义。