面向服务架构（SOA）可以将组织性的机构转化为功能性的团队，因此来增加生产效率。目前，开放组织架构框架（Open Group Architecture Framework，TOGAF）和 SOA 都是难以实施和理解的。为了获取成功，一项技术必须最少提供两件事情：一个参考拓扑结构（定义架构）以及一个参考实施工作流程（定义序列），在项目开始、期间以及过后，都必须一直获得这些工件，因为它们提供了规划、设计、实现、维护和优化方法参考的要点。由三篇文章组成的本系列专题的第 1 部分与第 2 部分，分别想要重建 TOGAF 和 SOA 的显著架构。第 3 部分接下来会研究两个框架中的敏捷过程，并提供了一种方法以探讨 TOGAF 和 SOA 提供的独特特性。

面向服务架构（SOA）是一个企业化的概念。在部门界面的基础之上，它能支持从一个模型到中央组织模型的转变。SOA 支持您将组织性的机构转化为一个功能性的团队，因此显著地增加生产效率。在经过一段时间或者一阵讨论及试用之后，企业架构就开始实行了。首先，要有一个企业概念，统一建模语言（Unified Modeling Language ，UML），它提供了所需的其他形式。第二，有一个广阔的工业意识，那就是部门化的信息技术（IT）系统并不是一个孤岛，必须最好与商业价值看齐。最后，有一个 SOA，也就是一个能够支持日益加快变更的商业技术的框架，而不用产生一些阵疼。

目前，对 TOGAF（也就是开发组织架构框架）与 SOA 的理解仍然只停留在表面上，为了获取成功，它们中的每一个方法必须至少提供两件事：

1.一个参考拓扑结构（定义的架构）

2.一个参考实施工作流程（定义的序列）

在项目开始之前、进行期间以及结束之后，这些工件必须始终记在心里，因为它们提供了规划、设计、实施、维护及优化方法参考的要点。本文与本系列专题的第 2 部分分别想要呈现 TOGAF 与 SOA 的概述。

关于 TOGAF 的大量讨论关注于架构开放方法（Architecture Development Method，ADM），其观点是 ADM 基本上要与 TOGAF 保持同步化。是什么将 TOGAF 与其他的框架，例如 Zachman 框架（Zachman Framework，ZF）和 SOA 分隔开来，是它为构建企业架构（也就是架构开发方法【ADM】）提供一种方法。ADM 与其他的框架差别如此之大，所以大多数关于 TOGAF 的讨论大多集中于此。对于 ADM 同类的关注则很少：企业架构的构建块或者企业统一体（Enterprise Continuum，EC）。为了对企业架构与 TOGAF 有一个大致的了解，请阅读前期的文章：“TOGAF 或者非 TOGAF：扩展企业架构以超越 RUP”（参见参考资料）。

TOGAF 企业统一体（TOGAF Enterprise Continuum）

TOGAF 包含了两个原则部分：

1.ADM，它包含了机构开发的程序性指导，这些机构关注于企业架构

2.企业统一体（Enterprise Continuum，EC）包含了一个过程模型，以及与企业架构相关构建块的分类，包括可以用于与 ADM 相连的标准、方案、服务、模式、框架以及技术

一个机构应该使用 TOGAF ADM 以考虑企业架构实施的关键原因，在于提供一个业界达成共识的开发路线图。开发组织框架推荐提供了目前架构与未来想要结果的赋值，以及传统的状态、一系列的建模工件和相关的规格文件。这些模型可能来自于不同的架构域，在微观架构与目的上可能有所不同。但是，它们必须使用独特的构建模块来进行构造。

关注一下 EC 资源中的条目，我们在这里讨论的商业功能，应达到合同管理那样的广度，通过使用像文件处理、报告生成以及文件管理之类的平台服务来实施。反过来，这些可以通过使用统一资源定位器（Universal Resource Locator，URL）或者可移植文件格式（Portable Document Format，PDF）技术来进行实施，这些技术是更深层次上 EC 的可再用资源。

为了处理围绕商业到技术分别之间存在的模糊性，TOGAF 采用了一种方法，将企业架构实施与规格过程分隔为两个单独但是相互依赖的模型层和三个潜在不同的工作流程，这三个工作流程分别处理架构需求、商业协议以及架构性方案（见于图 1）。其中两个工作流程呈现了大多数公司的自然不同点，这些公司中同时存在企业规划小组与方案实施小组：

架构统一体（Architecture Continuum，AC）工作流程提供了一个框架，以分析内容及范围中的企业架构，定义商业协议，并根据所谓的 应用构建模块（Application Building Block，ABB）来为可再用的资源分类。

解决方案统一体（Solutions Continuum，SC）工作流程提供了一种方式，来描述 AC 与 解决方案构建模块（Solution Building Block，SBB）的实施。

通过观察一个实例，可以更轻松地理解构建模块（ABBey 与 SBB），笔者将会在本文稍后部分中展现这个实例。同时，您可以将它们当做可再用的、逻辑性的企业 IT 架构定义构件。

图 1. TOGAF Enterprise Continuum 中的架构流程

架构统一体（Architecture Continuum，AC）

AC 由四个状态组成，如图 2 所示。接下来的过程是发现架构性的需求并分析和理解在机构中已经就绪的架构，从像 TOGAF 这样的基层架构到普通的系统架构、工业化标准的架构（例如 SOA 和支付卡行业【PCI】标准），到公司自己的可应用的架构，都要有所考虑。图 2 中的图表，显示了基于四个状态的推论架构性过程：

1.基础架构（Foundation Architecture）

2.公共系统架构（Common System Architecture）

3.行业架构（Industry Architecture）

4.组织架构（Organization Architecture）

图 2. Architecture Continuum

从左至右的方向，说明了一家公司内企业架构实施的逻辑进展。但是，在这个过程中并没有单个合适的路径，并且所有的状态都是自发的。跳过早期状态的公司，例如基础架构和公共系统架构，以缩短他们实施所需的周期时间，抑或节省实施的成本，最终可能花费大量的精力时间资源，去维护、集成系统乃至最后的替换。一般来说，进展应该从左至右发生，并且以这种方式发生：

1.从概念性到逻辑性再到物理性

2.从技术方案到商业技术系统

3.从以行业为中心到垂直的业务领域一致架构

4.从通用的分类到物理架构规划

结果，在左边对状态所做的架构性更改，将会转移到右边的状态。这种转化后的模型支持架构性的变更管理，这样对系统所做的重大性变更，还可以通过系统来传播，而且不会对业务造成较大的影响。

模型中的各种状态呈现了核心的架构性分析与规划点。每一种状态都得到了一些架构性构建模块（ABB）的支持，它可以位于 AC 分类的内部及外部。AC 方法可以在大多数的行业之间应用，并且可以适应几乎所有已知的信息技术标准。因为 AC 可以在多个垂直的和水平的业务域或者通用的机构性业务架构之间转移，所以架构必须共享一个普遍的再现语言。大多数人，包括笔者，相信统一建模语言（UML）可以符合这个标准（查看参考资源中列出的“UML，RUP 以及 Zachman 框架，放在一起会更好”）。

除了普通的建模规则与可评价的概念，方法必须基于中央的分类以及模型架构的知识。TOGAF 包含了三个分类；两个支持基础架构（Foundation Architecture）而另一个支持公共系统架构（Common System Architecture）。除了标准的外部收集物，这三项和模式包含了以前提到过的 架构构建模块（Architecture Building Block，ABB）的功能性包。

TOGAF 向四个状态中的每一个分配了相应系列的 ABB。与来自另一个状态的不同 ABB 相比，让 ABB 系列属于一个状态的是一个独特的视角，那就是系列基于并是抽象代表的一个层次。

但是，组成它们的项目是一个普通的定义模型，由主要的功能性程序、界面与其他 ABB 之上的附件组成。一个普通的 ABB 定义模型，使得在需求规划、逻辑架构蓝图以及商业协议之间企业架构比较、选择和再使用 ABB 变得可能，它轻松地转化为 SC 方案架构。这就将 AC 的特定角色强化为架构需求与分析的工厂。

架构状态

EC 状态的存在组成了基础性转变的基础，这种转变在架构开发阶段发生。

基础架构（Foundation Architecture）阶段从您考虑技术标准与可用或者可访问产品及服务，乃至它们与业务需求和战略一致性方面的通用计算环境时开始。技术性参考模型 （TRM）与标准信息基础（SIB）分类支持架构性开发的这个阶段。TRM 组成了“通用平台服务”的类别，这些服务包括传真或者文件管理，SIB 是工业标准的数据库，可以用于定义计算环境。

公共系统架构（Common System Architecture）就是您创建一系列规划 IT 需求的状态。通过创建 ABB 以描述企业关键系统组成与行为性的模式，您可以为域架构视图建模，例如应用、基础设施（Infrastructure）、网络和安全。 支持这个阶段 EC 内的分类是集成信息基础参考模型（Integrated Information Infrastructure Reference model，IIIRM）。IIIRM 由集成信息架构与所有它的层与关键构件的描述组成。

行业架构（Industry Architecture）阶段指导了垂直工业域内（例如保险、政府服务，或者银行）标准与构建模块的采用与集成。这些工作由特定域 ABB 与技术标准的分析、选择与架构集成所组成。特定工业标准的一些范例，就是 ACORD XML 模型，它代表了保险公司与交换电子记录信息的 HL7 之间共享信息的公告数据与过程架构（参见参考资料）。在这个阶段，ABB 可以代表标准的实施或者它的逻辑通用实施。

最终的状态，组织架构（Organization Architecture）是最低抽象级别的。它为方案架构与系统分析员之类的人提供了一个参考，这些人参入了项目的实施与交付过程。从项目的完成角度来看，这个状态代表了一个组织所谓的 企业架构。它包含了一个逻辑层次上具体组织性开发、过程与系统集成、标准支持包与域层次上架构，并由内部业务数据、过程、系统与规则的模型所组成。作为一条推荐性的参考规则，IEEE Std 1003.23，“对机构开发系统环境（OSE）概述开发用户的指导”包含了识别及记录操作性需求加 IT 和 IS 服务的方法，以支持这些需求，以及标准、战略和所需服务的内部方案。

解决方案统一体（Solution Continuum）

拥有两个单独架构性代表联系与工作流程（SC 与 AC）的 rationale ，拥有企业与方案架构之间的关系层。一般来说，这将会有效地转化为提高的企业变更效率，并增加 ROI。当业务过程需要得到变更时，一个两级的方法通过支持企业架构，以选择企业架构更改的最佳点，可以限制降低企业架构和项目分析所需的工作量和风险，因此通过强制实行架构性的标准限制了方案架构的不确定因素。

从 TOGAF 的视角来看，SC 状态模仿了 AC 状态。精简了 ABB 的 SBB（构建模块），可以获得或者开发。有了 ABB，SBB 的微观架构在状态之间是不同的，从左至右得到增加，因为获得了方案状态。包含产品与服务、系统解决方案、行业解决方案以及组织解决方案的 SC 状态可以通过项目架构获得，并作为一系列的项目来交付，这些项目可能会使用 RUP、瀑布模型，或者敏捷开发方法、它们之间的组合或者任意其他的方案交付方法。一个 ADM 过程可以适应不同类型的项目选项，查看“TOGAF 或者非 TOGAF：扩展企业架构以超越 RUP”（参见参考资料）。

图 3 显示了一家虚拟的保险公司中 SC 与 AC 之间的关系。

图 3. Solution Continuum 与构建模块

AC 与 SC 之间的关系

TOGAF 将 AC 与 SC 之间的关系引申为“指导、方向与支持中的一种”，我将其理解为 AC 基础架构指导了产品与服务的选择，系统方案是在 AC 公共系统架构指导下实施的，工业方案是根据 AC 行业架构推荐方案进行集成的，而组织方案与组织企业架构一起进行交付。

与 RUP 一致

项目专家可能喜欢这样一个事实，那就是这个过程与 IBM? Rational? Unified Process（RUP?）具有很多共同点：它在本质上是需求驱动的（AC 是架构需求层），本质上是重复的（状态之间的过渡可能意味着架构精化以及部分实施的构件），显著的以架构为中心的（方案与协同的架构一起交付），以及一个基于重要时刻的生命周期（架构状态）。状态同样类似于 RUP 重要时刻；尽管如此，SC 与 AC 分别对应于 Requirements 加 Business Analysis 与 Design 加 Construction 原则。

TOGAF 推荐，AC 与 SC 同时使用，在这些运行阶段有一步的延迟，尽管这并不是给出的。AC 作为 SC 的架构层使用，在处理并整合来自 SC 过程的回馈的过程中不断地进行发展。含有的观点是通过让企业架构通过四个状态，来完成企业架构。在来到最后的状态时，就意味着架构循环已经完成了；但是，按照 ADM 推荐的那样，方案项目分析活动可以在最终的企业架构完成之前或者完全达到之前开始。

通过达到代表企业架构与方案交付项目共同重要时刻的“模型目标”，来获得 ADM 一个流行和强大的实施方案。我曾经遇到了这个方法的一些实施情况；“探路过程”就是其中的一种。为了通过两个状态之间的“大门”，开发中的架构必须得到一致性方面的验证，并在架构团队的外部进行交流。一个架构“评审委员会”可能由业务、企业架构、方案架构以及项目方面的专家组成，以确保委员会的一致性与连续性。

回页首

TOGAF 引用图

图 4 中的图表显示了 TOGAF 的高层次拓扑结构，如期所述。本系列专题的第 2 部分将会按照相同的格式，来重构 SOA 框架的拓扑结构。第 3 部分将会试着联系两个框架，并将这些表格作为生命周期图表使用，以创建一个统一的情形，可以作为 SOA 企业架构实施与 SOA 实施的指导，这两种实施可以影响企业架构框架。

图 4. TOGAF 引用图

使用 TOGAF 框架的参考图