TOGAF 架构内容框架

一、概述

在执行ADM的过程中，会产生很多输出，比如流程图、架构需求、项目计划、项目一致性评估等等。为了能以一种一致的、结构化的方式来对照和展现这些主要的工作产品，用一个架构内容框架 (Architecture Content Framework )来放置它们就变得很有必要。这样就提供了更方便的引用方式和标准的分类方法，也有助于将不同工 作产品要素之间的关系结构化，而这些工作产品要素就构成了我们通常所说的 “企业架构”。

TOGAF 9中介绍的架构内容框架确保了可以将TOGAF作为一个 独立的架构框架在企业内使用。当然，也存在一些其他的内容框架 (比如ArchiMate和Zachman框架)，有些企业也可能会选择把一个外部的框架和ADM联合起来使用。在这些情况下，TOGAF架构内容框 架就提供了一个有用的参考和出发点，将TOGAF内容映射到这些框架的元模型上。

为了帮助对新的工作产品进行分类，并考虑到与其他内容框架 (包括任何现有的已分类的架构工作产品)进行对照的潜在需求， TOGAF架构内容框架使用了下列三个分类来在其被使用的上下文中描述架构工作产品的类型：

• 交付物(deliverable)：是以契约方式详细说明的正式架构 工作产品，一般会由其利益相关者审查、同意并签署。交付物通常代表了项目的输出。

• 制品（Artifact）：是从某个特定视点描述架构的、更细粒度 的架构工作产品。制品会包括如用例规约、架构需求列表或网络图 这样的工作产品。制品通常可分为目录（事物的列表）、矩阵（用 来展现事物之间的关系）或图（事物的图形展现）。一个架构交付 物可包含多个制品。

• 构建块（Building Block ）：表示了业务、IT或架构能力的 （潜在可重用的）构件，它可以和其他构建块组合起来共同交付架构或解决方案。构建块（building blocks ）可以在不同细节级别上被定义，并且 既可以与“架构”相关，也可以与“解决方案”相关，通常用架构 构建块（Architecture Building Block, ABB ）来描述所需的能力，并决 定解决方案构建块（Solution Building Block, SBB ）的内容，解决方案构建块表示用于实施所需能力的构件。

二、内容元模型

架构内容框架建立在标准内容元模型的基础上，标准内容元模型对架构中存在的所有类型的构建块进行了定义。

在创建和管理架构时，有必要考虑如业务服务、施动者、应 用、数据实体和技术这样一些不同的关注点。内容元模型强调了这些关注点，展示它们之间的关系，并确定了一些制品，可以以一种 一致的、结构化的方式来表现它们。

另外，对于希望使用架构工具来实施其架构的组织，内容元模 型还可以用来为其提供指导。

目录、矩阵、图

虽然内容元模型支持了架构信息的结构化，但是大部分利益相关者都不需要或不希望以这种方式去了解包含在架构内容框架中的 细节。因此，就需要引入对目录、矩阵和图的使用，来促进对架构 信息的更好展现，以方便参考和治理。

目录是某个具体类型或相关类型的构建块的列表，矩阵是展现 两个或更多实体之间关系的表格，而图是架构内容的图形化表现。

一个由ADM开发的架构会包含多个定义好的ABBs （架构 构建块），这些架构构建块会被填入到架构目录中去，用架构矩阵 来展现这些构建块之间定义好的关系，然后以沟通图的形式精确、 简洁地展示出架构的样子。

三、架构制品

TOGAF 9描述了一套在遵循ADM开发架构时创建的原子工作产 品。这些原子工作产品就叫做制品，它们表现了系统、解决方案或 企业状态的某个独立的模型，这些模型有可能会在不同的上下文中 被重复地使用。

制品有别于交付物，后者是项目的契约规定的输出。在大部分情况下，交付物会包含多个制品，一个制品有可能存在于多个交付物中。

四、构建快

“构建块”是TOGAF和ADM中大量用到的一个术语。构建块就 是被定义用来满足业务需求的一个功能包。如何将功能、产品和自 定义开发组装成构建块，在不同的架构中千差万别。每个组织必须决定，如何对构建块进行组装对它自身来说才是最合适的。好的决策会大大提升遗留系统集成的效率，并在创建新的系统和应用时带 来互操作性和灵活性。

系统是从构建块的集合中构建出来的，因此大部分构建块不得不和其他构建块交互。不管怎么说，将构建块的接口发布出来并保持合理的稳定是非常重要的。

根据架构开发到达的阶段，构建块可以在不同细节级别上被定义。

例如，在早期阶段，构建块可以仅仅包含一组功能，如一个客户数据库和一组数据检索工具。在这种功能级别上定义的构建块在 TOGAF中叫作架构构建块（ABBs）。在后续阶段，真正的产品或定制开发会替代这些简单的功能定义，这时的构建块就 叫作解决方案构建块（SBBs）。


在阶段A中，最早的构建块定义从架构愿景中相对抽象的实体开始。

在阶段B、C和D中，业务、数据、应用和技术架构中的构建块根据一套共同的步骤模式被不断修订。

最后，在阶段E中，构建块变得更加与具体实现相关，最后解决方案构建块（SBBs）被识别出以解决差距,。