当运用
IBM Rational 统一过程?(RUP?)的项目团队拥有了问题陈述，或者确定了具体的用户需求时，团队会创建业务案例、愿景描述(Vision
statement)，以及其他工件中的软件需求规格(Software Requirements Specification)来生成解决方案。技术和业务团体对这些工作产品以及生成它们的活动有很好的了解。然而，我们概念化、划分优先级，并且选择哪些业务问题和用户需求需要在软件中实现所采取的方法在我们的行业中仍旧是非常有价值的过程。
本文探究对于当今软件开发组织来说成熟且日益重要的角色，企业架构(enterprise architecture，EA)框架。开始，我们将企业架构规程与解决方案架构和业务架构规程进行对比，在这期间将它们与
RUP 进行联系。然后，我们将解释 Open Group Architecture Framework
(TOGAF) 如何利用 RUP 有利地扩展企业架构集的边界，从而包含企业业务和 IT 计划、实现治理，以及其他活动。最后，我们将提出把
TOGAF 与一些其他 EA 框架结合的方法。
对比不同的架构框架
就企业、解决方案和业务架构框架的范围而言，就像大家普遍了解的那样，在它们之间有很多重叠。那么，它们是如何相关联的呢?
解决方案架构
解决方案架构框架有各种各样的形式。IT 专家们已经习惯于在信息系统开发和维护项目中处理应用、数据、技术和其他解决方案架构形式(这些常称为领域)。新的(以及全部更加专门的)解决方案架构形式，例如安全及测试，也快速地成为主流。图
1 中展示了最为广泛公认的解决方案架构领域、其主要主题和它们之间的依赖性。
图 1：解决方案架构规程的领域及主题
图 1 中展示的所有解决方案架构领域被看作是“技术性的”，因为它们的范围内包括各种技术元素，例如，软件、数据和
IT 基础架构。这些领域都是由技术人员来处理 —— 也就是那些具有系统工程、软件工程或 IT 管理背景的人。
业务架构
业务架构在 90 年代作为单独的领域出现了，当时许多组织接受了业务架构师角色，因为它们试图优化它们的业务过程。
业务架构规程是关于业务的“工作范围”，并且描述它是如何运作的。虽然不是每个人都赞成在业务架构框架中应该包含的组件的内容，但是一般的共识是，过程及信息、组织和性能方面是相关联的。实质上，每个组件都相当重要，并且结合了多个主题领域，如图
2 所示。
图 2：业务架构领域的组件及主题
可以证明过程及信息组件是业务架构活动的焦点，因为(其中)它定义、描述并且把业务过程和组成组织业务模型的支持结构进行分类。该组件还包含了大量相关的主题，例如，可用性和可访问性。当然，每个组织都有不同的业务过程、结构和工作流，等等。同样的，一个组织可能在其业务过程模型中会拥有使其在竞争中具有优势的“额外内容”，而另一个组织将在此领域内挣扎。
组织组件是关于工作实践的结构和设计，以及组织的运作风格。该组件所处理的主题包括组织结构、业务产生的产品和服务，业务单元及其位置，等等。
业务性能是拥有定义并量化组织效率和有效性的主题的面向管理的组件。它关系到生产力、业务风险，及属于此处的其他相关的主题。
企业架构领域
在我讨论企业架构之前，我想要大致描绘一下该规程要解决的问题。大部分现有的实现方法包括创建针对明确的业务需求的解决方案所用的技术。然而，这些方法与业务需求为什么及怎样出现不是直接相关的。相反，相对于组织可能拥有的其他需求，它们关注于对已知需求的响应的相对重要性。举例来说，让我们考虑
RUP。RUP 交付过程想当然地做出开始实施的决策，但没有一个 RUP 工件与评估解决方案的实现是否满足业务需求的紧急性直接相关。
对比 RUP 和其他主要关注于实现的规程，企业架构领域原则上的关注点是企业范围内的业务需求的识别、规范，及优先级划分。企业架构框架环境内所讨论的观点和所绘制的模型解决了大量当前及潜在的问题。
EA 路线图可能比单路线解决方案包含更多内容(如图 3 所示)，这可能会形成多个、同时的实现。
图 3：企业架构路线图示例
展望企业的未来
可见，企业架构开发协会(Institute for Enterprise Architecture Development
，IFEAD)概括出了企业架构规程的重要指导原则：“没有战略眼光，就没有 EA。”换句话说，今天的企业架构关系着明天的业务系统。此原则的一个重要方面是企业架构是根据一个战略性的企业眼光结合业务和技术要素的整体规程(参见图
4)。
图 4：企业架构领域的要素
现在正是时候
尽管企业架构概念已经出现了二十多年，但是 EA 规程最近刚获得动力。这可以归因于大多数行业中各种规模的组织中环境变更的加剧。业务灵活性，特别是技术基础架构及时响应变更的能力已经达到决定性的重要程度。
导致人们对企业架构规程更加欣赏的另一个因素是，在美国及其他地方，近年来政府对企业更加严格的遵守某些规章制度的气候，这不仅推动组织提高它们的责任心及报告实践，还适度使组织中的每个业务过程更好的符合遵从性。
作为对 EA 原则更高关注的结果，许多健壮的企业架构框架最近出现了，例如 TOGAF。
相同的主题，不同的观点
企业架构规程实际上与解决方案架构规程涉及同样的主题，但是视点不同，并且所处环境明显不同。EA 环境是全局性的，其视点是组织化的，而解决方案架构是具体到实现的。
同理，企业架构规程大于解决方案架构领域的超集。解决方案架构主题(参见图 1)要应用于解决方案的实现，但
EA 主题(如图 5 所示)主要用于企业分析、计划和架构治理。举例来说，对于解决方案架构师来说，“Applications”主题域涉及到一组链接的组件和类，然而，对于企业架构师来说，就需要一个运行一组业务过程或提供大量服务的节点。
注意，来自解决方案架构规程中的一些主题(低层次的)不含在 EA 的范围内，而许多附加的(大部分是更高层次的)主题加入了。还要注意的是关键的业务架构主题完整地包含于
EA 规程之中了。
图 5：企业架构规程的组件及主题
企业架构的范围
企业架构活动的开始远远早于解决方案架构所推动的项目，并且在企业的生命周期中持续进行。作为连续运行的过程，企业架构生命周期拥有一个与实践的创建一致的单独入口点，以及分散在企业架构时间轴上的多个过程输入。如下面图
10 所描述的，一些 EA 框架引入了循环或迭代，这必须结合组织的业务开发中的主要阶段。在这些框架中，循环包括伴随对
EA 活动多个输入的多个阶段，特别是在循环的初始阶段。
企业架构输入在企业转型思想是如何生成并验证方面是有差别的，这些输入的分类提供了一种度量组织的 EA 实践成熟度的方法(参见图
6)。在一些情况下，一个想法是 CTO 和架构师之间商讨的副产品。在其他情况下，一个想法是对业务计划者、最终用户，或其他涉众逐渐增加的请求的响应。就最成熟的组织来说，一个想法是战略架构分析和包含了来自于类似刚刚提到的那些来源的输入的计划过程的输出。
图 6：企业架构过程的输入
只要企业是运作的，且拥有远景，企业架构活动就持续着。但这总是需要企业具有 EA 观点，并且 EA 活动绝不能停止。
新兴的企业架构师角色
企业架构师是思想带头人、幻想家和行业专家。在大多数公司里，这是个新的角色，它将项目经理、解决方案架构师和业务分析人员的技能与执行的直觉联合起来。
许多 IT 架构师视角的普遍局限是他们是成熟的程序设计人员，并且目光易于局限于内部。虽然，这不完全是架构并设计“全局性”解决方案的障碍，但是，它是“构架”企业环境中不那么理想的特征。企业架构师可能更加外向，并且善于利用专业的、工作的，甚至与业务所有者、业务领导、同事和客户之间的关系来说明、从架构地角度描述，并且帮助执行企业远景(参见图
7)。
图 7：企业架构师角色
企业架构师的职责常常与城市规划者对比，而建筑架构师的职责更容易与 IT 架构师角色联系起来。建筑架构师强调其推理的技能，而企业架构师角色常常强调类似于侦探的感应技能。
然而，高层次的企业架构师视角不意味着该角色脱离用户群体。反之，企业架构师必须帮助客户了解他们真正的需求(对照想要的)，并且在解决方案的实现过程中与客户合作。与此同时，企业架构师必须能够在直接参与实现的实践方面之前的抽象层次上观察他或她的领域。如
IBM 的 David Jackson 所认为的，企业架构师应该“能够了解业务问题及业务领域，并且向技术人员说明，还能够了解技术领域并向业务人员说明技术可能性”。
很重要的是，企业架构师扮演架构治理(常常在分类的业务和技术角色之间共享的功能，或者更糟，仅仅被忽略)中的关键角色。架构治理是为所有企业和项目架构活动提供环境和框架的粘合剂。
企业架构与 RUP
尽管核心的 RUP 不包含企业架构规程，但是 RUP 的确会得益于拥有带有 EA 的定义明确的接口。图
8 中说明了这一点，其中强调了解决方案实现项目的一系列特性。如图所示，典型的组织拥有一个连续运行的企业架构过程实例，以及任意个连续的解决方案实现。
图 8：RUP 与企业架构生命周期
值得提到的是，将 RUP 的范围扩展到整个企业的尝试已经进行了许多了。最近的是企业统一过程(Enterprise
Unified Process，或称 EUP)。 2 EUP 不只关注企业架构功能，相反，它为大量企业活动的执行提供框架。EUP
引入多达七个新的规程，包括企业架构规程，以及超过二十五个新角色，并且还为他们的适应提供指导。现在正进行着将各种
EUP 规程集成到核心 RUP 中的工作。
期间，RUP 本身从初始阶段已经有相当大的演进，且当前在其核心规程中包括许多企业过程，包括业务建模和变更管理。
实现企业架构程序
企业架构程序实现的相对复杂度依赖于组织的授权级别、资源和指导的可用性、组织业务模型的规模和复杂性，以及组织灵活性等因素。事实上是，许多组织并没有能力同时实现并维护企业架构程序，更好的方法是首先从实现起来比较容易且能带来较好效果的过程改进技术着手。
存在两种实现企业架构的一般方法，它们大致符合可用的两种不同的框架。
第一种方法将组织工件和过程映射到框架元结构上。该方法对精通建模的组织有效。喜欢此方法的组织通常选择 Zachman
或等价的框架。该方法的一个缺点是框架结构会抑制创造力，并且向 EA 实现过程中增加官僚主义。伴随该类型框架的另一个问题源于实现指导的严重短缺。
第二种方法是基于一种信念，即企业架构程序是过程驱动的。由于该方法主要针对于活动而不是工件，所以可能更容易理解，并且更容易与现有的企业及解决方案方法和技术联系起来。
尽管两种方法都有赞成和反对它们的理由，但是可以将它们进行折中，整体使用活动驱动的过程，而将元框架应用为支持结构或用于分析过程。
企业架构实现的示例清单
这里有一些必须作为任何 EA 实现一部分的基本活动。该列表会让您了解到企业架构工作是真正关于什么的：
了解您组织的业务模型，至少其高层次的业务过程是开始企业架构实现的预先条件。
显然，高级管理层掌握着解释战略目标的关键。了解远景对绘制企业架构路线图来说非常关键，因为此工件将推动架构工作的“未来”部分实现(下面对此进行更多介绍)。
虽然高级管理层可能会展望组织的未来状态，但是业务团队掌握着其当前状态的更多答案。您的目标就是提取那些事实，并用战略目标所形成的期望集来平衡它们。
技术是业务过程的主要启动者(另一个是人)，这暗示着不对您主要的工具进行适当的了解，您不会成功。
从各种来源收集数据之后，创建路线图来告知奉献承担者 —— 包括高级管理层、业务，和技术领导者 ——
您打算如何针对他们告诉您的需求采取行动。
不用说，当您创建了企业架构路线图，并且得到了风险承担者的赞成之后，您应该努力让其随时更新。
对于刚才介绍要发生的活动来说，强大的方法指导是必不可少的。现今存在的企业方法和框架在它们解决的问题，和它们所采取的方法范围内发生重大的变化。一些最著名的框架是
TOGAF、EUP、Federal Enterprise Architectural Framework
(FEAF)、Gartner EA Framework、 4 Department of Defense
Architecture Framework (DoDAF)、Spewak EA Planning Methodology
和 Zachman Framework。
如果您相信您所工作的组织在本文中讨论的一些领域内有所缺乏，或者您想要提高其有效性，或者您个人拥有与其企业架构相关的职责，那么我推荐您更进一步了解这些企业架构方法。
EA 框架选择
当开始选择企业架构方法/框架的时候时，大多数可用的选择都采取了可以适用于具体组织需求的部分构建好的“解决方案”的形式。实际上，这些“半成品的解决方案”中大部分不是实际可复用的，或者它们需要很大程度的裁减，才能具有价值。进一步说，关于裁减这些框架的严重问题是所提供的指导量少得可怜，而理解得详细层次要求得非常高。
大多数情况下，不是所有的，现有的框架既扩展了其他框架，又为特定的应用概括论述了其他框架。举例来说，EUP
是 RUP 的扩展，它模仿 RUP 的方法，描述过程工作流和活动，而 FEAF 和 Spewak 都继承于
Zachman Framework。TOGAF 起源于早期的专有 EA 技术框架，像 Technical
Architecture Framework for Information Management (TAFIM)，并构建在企业架构
ANSI 推荐之上(IEEE 1471-2000)。
介绍 TOGAF
TOGAF 5 是在过去二十年间出现的企业架构框架，其目标是成为 EA 开发的标准。TOGAF 是由
Open Group consortium 成员创建的， TOGAF 不是一开始就体现整体的 EA 焦点。最初，TOGAF
只包括技术架构(版本 1 到 7)，然而，最近该框架中加入了业务架构领域(版本 8，Enterprise
Edition)，这快速地将 TOGAF 推向当今 EA 框架选择的第一把交椅(参见图 9)。
图 9：TOGAF 架构领域
到添加了业务架构领域为止，TOGAF 已经利用应用、数据和技术架构领域构建了坚固的技术基础。业务架构领域的加入进一步推动了
TOGAF 不断增长的名望，而其他从技术架构开始的框架在它周围度过困难的时期。举例来说，EUP 不得不利用
RUP 的方法、技术和标记符(UML)，而 Zachman、Spewak，和一些其他的框架有意地使它们的指导在高抽象层上，这负面地影响了人们对它们的接受，因为它们没有赢得技术团队的支持。
TOGAF 组件
TOGAF 的一个关键组件是架构开发方法(Architecture Development Method，ADM)，是用于具体到组织的企业架构实现和裁减的过程。除了
ADM，TOGAF 包括一个通称为“Enterprise Continuum”的参考资产集合。TOGAF
预想，Enterprise Continuum 成为一组可复用的构建块(模式)集合，向企业架构团队提供可以像乐高玩具那样使用的参考架构、模型和过程。
TOGAF ADM
TOGAF 架构开发方法为实现和执行组织的企业架构提供完整的指导。该过程包括闭合循环中的多个，连续的阶段(参见图
10)。
图 10：TOGAF 架构开发方法(Architecture Development Method，ADM)
初期的目标是确定实现过程涉众，并且让它们面对企业架构工作的内容。该阶段交付基于组织业务法则的架构指导方针(Architecture
Guiding Principles)，并且描述用于监控 EA 实现进展的过程和标准。
过程的阶段 A 用于明确 EA 远景。架构远景(Architecture Vision )工件利用业务推动者明确企业架构工作的目的，并且创建基线和目标环境的粗略描述。如果业务目标不清楚，那么该阶段中的一部分工作是来帮助业务人员确定其关键的目标和相应的过程，这些企业架构都必须支持。同样是该阶段中生成的架构工作描述(Statement
of Architectural Work)，勾勒出 EA 的范围及约束，并且表示出架构工作的计划。
阶段 B 用于详述关于业务领域架构的工作。架构远景(Architecture Vision) 中概括的基线和目标架构在此被详细说明，从而使它们作为技术分析的有用输入。业务过程建模、业务目标建模和用例建模是用于生成业务架构的一些技术，这又包含了所期望状态的间隙分析。
阶段 C 涉及应用和数据(信息)架构的交付。该阶段利用基线和阶段 A(Architecture Vision)中开始的目标架构，以及业务间隙分析(业务架构的一部分)的结果，在范围内，并根据架构工作描述(Statement
of Architectural Work )中所概括的计划，为目前和展望的环境交付应用及数据架构。
阶段 D 利用技术架构的交付完成了 TOGAF ADM 循环的详细架构工作。如前面的阶段里，间隙分析和草案架构用作基线，由于初期对架构指导原则达成一致。建模标记，例如
UML，在此阶段中被积极地使用，从而生成各种观点。
阶段 E 的目的是阐明目标架构所表现出的机会，并概述可能的解决方案。此阶段中的工作围绕着实现方案的可行性和实用性。此处生成的工件包括实现与移植策略(Implementation
and Migration Strategy)、高层次实现计划(High-level Implementation
Plan)，以及项目列表(Project List)，还有作为实现项目所使用的蓝图的已更新的应用架构。
阶段 F 将所提议的实现项目划分优先级，并且执行移植过程的详细计划和间隙分析。该工作包括评估项目之间的依赖性，并且最小化它们对企业运作的整个影响。在此阶段中，更新了项目列表(Project
List)，详述了实现计划(Implementation Plan)，并且将蓝图传递给了实现团队。
随着项目列表的稳定，重点就移动到为每个实现项目明确更具体的目标和推荐。在阶段 G 中，建立起了治理架构(TOGAF)和开发组织之间的关系(例如，可能由
RUP 和项目管理知识体系((Project Management Body of Knowledge，PMBOK)
的组合，或其他项目管理方法所规定)，并且在正式的架构治理下实现所选的项目。阶段的交付内容是开发组织所接受的架构契约(Architecture
Contracts)。阶段 G 最终的输出是符合架构的解决方案。
阶段 H 中的重点转移到实现的解决方案的交付所达到的架构基线的变更管理。该阶段可能会生成为企业架构工作的后继循环设置目标的
架构工作请求(Request for Architecture Work)。
TOGAF Enterprise Continuum
Enterprise Continuum 是资源库，例如，模型、解决方案模式，和其他可以在企业架构实现和裁减过程中用作构建块的资产。实质上，Enterprise
Continuum 类似于 EA 专业人员和涉众的资料库。
除了 ADM 和 Enterprise Continuum，TOGAF 还提供关于用于计划并实现企业架构的技术、方法和解决方案的附加资料和参考。
TOGAF 是迭代的吗?
如图 10 所示，TOGAF 是迭代的过程。TOGAF 迭代(常称为循环)通常比 RUP 迭代要长，并且跨越企业架构实现及维护的多个阶段。这并不奇怪，因为
EA 的范围比单个的 RUP 项目大得多。
需求管理和 TOGAF
如图 10 所示，TOGAF —— 照字面意义 —— 是以需求为中心的过程。ADM 需求管理处理所有类型的需求，包括显著的业务推动者、关系，及新的功能和变更请求。最后但并非不重要的是，由于架构需求从属于持续的变更，所以需求管理在整个
EA 实现生命周期中都会发生。
TOGAF 和其他方法
在现代组织中，TOGAF 必须与其他方法、过程和框架共存。它们中的一些，像 RUP，不共享公共的范围，而其他的，像
EUP 和 Zachman 框架，在 EA 生命周期上有一部分重叠。
TOGAF 与 RUP 的交汇点
TOGAF 有时候看上去像 RUP 的替代，但其实不是。虽然两个框架之间有许多共同的模型和主题，但是它们有不同的推动者和目的。
TOGAF 和 RUP 之间的原则差别是 RUP 是技术架构驱动的，然而，TOGAF 是业务架构驱动的。在
RUP 中，收集业务需求，来设计并交付基于软件的系统，而在 TOGAF 中技术被视为实现业务远景的方法。
作为软件开发生命周期(Software Development Life Cycle，SDLC)方法的
RUP 的目的是支持及时且有效的应用程序交付。对比 TOGAF 的目的，TOGAF 支持企业架构实现和维护。图
11 展示了 RUP 和 TOGAF 生命周期重叠的程度。
图 11：RUP 和 TOGAF 的生命周期
在 TOGAF 实现过程中有一个与 RUP 交叉的明确定义的点。交集的起始点在阶段 F 的开始处，此时，架构蓝图(应用程序模型)、业务架构、和高层实现移交给了实现团队。当两边都同意实现的范围时，移交视为完成。与此同时，签署了详述小组职责及架构实现治理原则的架构契约(Architecture
Contracts)。图 12 中提供了关于 TOGAF 和 RUP 之间工件流的细节。
图 12：TOGAF 与 RUP 之间的工件流
TOGAF 和 Zachman Framework
虽然 TOGAF 和 Zachman Framework (ZF) 属于一类“企业框架”，但是它们在方法、组成，和工作范围上都有差别。
ZF 是结构化的(静态的)框架，当用作方法及框架的工件和元分析的分析和分类的模型时最有效，而 TOGAF
是过程(动态)框架，还包括使用它们的参考过程模型指导。尽管有这些基本的差别，我们还是有很大可能一起应用这两种框架：
- 利用 ZF 作为工件的字典和交付结构，将 TOGAF 用作工件交付过程
- 用 ZF 设置转换 TOGAF 和其他解决方案方法之间的工件，例如，RUP 和/或 IT Infrastructure
Library (ITIL) ，的结构
- 在实现 TOGAF 过程中或之前，利用 ZF 进行现有企业过程和业务模型的间隙分析
- 利用 ZF 进行 TOGAF 的元分析，这可能导致对其弱点的确定，以及与其他方法的可能接口。
- 将 ZF 用作设计 TOGAF 企业架构模型的助手(TOGAF 阶段 B-D)
TOGAF 和 EUP
虽然 EUP 和 TOGAF 都工作于组织层面上，但是它们的范围不同。EUP，将 RUP 扩展到企业级，引入了七个新的规程
—— 企业架构是其中一个 —— 并对它们的应用提供指导。虽然大多数 EUP 规程工作于组织层，并且作为企业架构过程的输入，但是
EUP 本质上不是企业架构开发框架。(尽管 EUP 可能在 RUP 的未来实现方面进行变更。)
对比 EUP，TOGAF 只关注企业架构规程。从一开始就期望，并将其创建为企业架构实现的框架。
尽管 EUP 和 TOGAF 在视角上有差别，但是 EUP 所引入的规程对企业架构实现非常重要。举例来说，企业业务建模(Enterprise
Business Modeling)对于对现有业务过程的“构架”变更来说是有帮助的，而投资组合管理(Portfolio
Management)是企业架构师分析潜能，并监控(或 EA 术语中的治理)正在进行的实现的“必用”工具。
可能出现的 TOGAF 实现障碍
TOGAF ADM 不是端到端的过程，它是框架，且同样需要具体到组织的裁减。裁减采用强大的方法，及丰富的商业模型知识
—— 不容易找到的质量。情况因 TOGAF v 8.0，Enterprise Edition 是相对新的过程，拥有有限的上路经验这一事实而变得复杂了。
它可能很难让涉众使用 TOGAF。通常要利用有影响的雇员让高级管理层和职员相信，TOGAF 过程和模型应该弥补并替代那些他们熟悉的内容。
尽管 TOGAF 最近有了一些增强，它仍不像其他方法那样详细，特别是在其业务和技术联络的核心领域。例如，TOGAF
不包含像 Rational Method Composer 或 MyRUP 的东西，它也没有全面的周期库可用。
成熟的组织，特别是那些常规地使用项目管理和软件生命周期方法的，例如 PMBOK、RUP、Scrum，和
ITIL，在企业架构的实现上更加容易成功。我推荐组织在引入 TOGAF 之前先适应几个技术、标记，和 SDLC
方法，如图 13 所例举。
图 13：TOGAF 实现路线图
对成功的 EA 实现的其他潜在威胁包括缺乏用于获取并管理 EA 工件的标准工具，并且缺乏标准标记符。
TOGAF 或非 TOGAF?
组织要做出的最初选择是是否实现企业架构，而 TOGAF 是演进中的下一个逻辑阶段。通常，成功且一贯使用解决方案生命周期方法，如
RUP 的组织将 EA 的实现视为演进的下一个里程碑。
很关键的是，在组织中不用强迫实行企业架构。对企业架构实践的需求应该是人们了解了业务过程和结构的管理与支持技术基础框架的结合的不断发展的复杂性的结果。
如果您不确定 TOGAF 是否适合您，那么在您的组织中试用一下是个好主意。试验可能要包含一组热情且值得信任的解决方案及业务架构师。重要的是要加入业务和技术角色，以确保利益均衡。还要注意，要想成功，EA
实现必须保障组织中的支持。要确保支持，可以加入一名执行团队的成员，作为 EA 团队的代理，或者让企业架构师进入组织的领导委员会。
| 
