2. 内容元模型（Content Metamodel）

在TOGAF的眼中，企业架构是以一系列架构构建块为基础的，并将目录、矩阵和图形作为其具体展现方式。如果我们把这些表述方式看作为构建块的语法，那么在其语义层面又该如何定义呢？为了解答这一问题，TOGAF制定了内容元模型。这一元模型对各个架构构建块的类型以及他们之间的关系进行了明确的定义，而且为了体现与架构开发方法之间的联系，内容元模型中相关内容是比照着架构开发方法各阶段来进行组织的，阐明了架构开发方法各个阶段所涉及到的构建块类型，以及他们之间的关系。除了这些特点之外，内容元模型最特别之处还在于，它通过一种非常灵活的插件式的方法对其内容进行了归纳：

内容元模型核心内容及其扩展

作为一个通用且开放式的标准，TOGAF需要采用一种非常灵活的方式来对其内容元模型进行定义，从而使得不同的企业可以根据自身需要对其进行裁剪和改造。为了达到这一目标，TOGAF中的内容元模型将所需构建块类型的最小集合定义为核心内容元模型（Core Content Metamodel），并在此基础之上使得整个元模型体系能够支持后续扩展内容的插入。除此之外，内容元模型还根据各个特定领域，在更具深度的层次上定义了若干元模型扩展，包括：

治理扩展（Governance Extensions）

服务扩展（Services Extensions）

流程建模扩展（Process Modeling Extensions）

数据扩展（Data Extensions）

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

动机扩展（Motivation Extensions）

需要重申的是，TOGAF是一个开放的通用标准，因而其使用者完全可以将这一内容框架为基础，按照各自的需要对其进行改造。上面所述的各个扩展并非牢不可破，甚至用户可以根据需要制定属于自己的新扩展。下图展示了内容元模型中所包含的各个实体（构建块类型，其具体定义请参看附录中的相关内容）以及他们之间的关系，并通过图例标明了每个实体所隶属的扩展部分：

内容元模型各实体及其关系

如前所述，内容元模型的组织划分与企业架构开发方法有着密不可分的关系。在企业架构开发方法的进行过程中，各个阶段都会涉及到一些相关的构建块，而下图展示了他们之间的关系：

企业架构开发方法各阶段中的内容元模型实体

2.1 核心内容元模型（Core Content Metamodel）

核心内容元模型包含了企业架构内容所需要的构建块类型的最小集合，以及他们之间的关系。此核心内容元模型构成了内容元模型的基础，他体现了TOGAF所认为的一个企业架构至少应该涵盖的内容，相对于其他扩展部分，该部分的内容具有着更强的通用性和可适用性：

核心内容元模型各元素及其关系

虽然从名称和定义来看，只有符合核心内容元模型的企业架构才是符合TOGAF标准的，不过从TOGAF 9的内容等级划定来看，此部分内容为推荐性内容而不是强制性的（其实强制性内容基本集中在架构开发方法方面，内容框架中只有各阶段的交付物定义才是强制性内容），因而TOGAF的使用者完全可以针对这一部分内容进行定制。作为TOGAF所认定的内容元模型的核心，这一部分的内容与企业架构开发方法各阶段有着非常紧密的联系，下面的列表便针对这一点总结了在企业架构开发过程中所涉及到的用于描述此核心内容的各种目录、矩阵和图形：

在一个特定的架构实践过程中，架构的建设者需要在架构愿景阶段根据此次实践的范围来对架构内容元模型所需要的各种扩展进行选择，从而充分满足架构的需要。在后面的章节中，我们将针对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 使用效益

标明整个企业中各项优先级次序错乱的行为，并阐明这些行为如何与共享服务发生交互。（例如，有些组织希望能够节省开支，而其他组织则需要增加容量）

可以通过一种更加结构化的方式对业务服务的竞争性需求进行展现，从而使得折中性服务层次得以被定义。