Zachman企业架构框架简介

摘要： 企业架构（Enterprise Architecture, EA）或企业体系结构，是渐趋活跃的一个重要概念。这里简单探讨了它的信息技术背景和与之关联的一些问题。谈了巴比伦塔困境这一经典比拟不同的理解。提出 在企业工程立场将企业架构（或改为企业建构学）定位在更纯粹的结构原理与建构准则、方法学方面。

引言

“企业架构”一词，是对英文  Enterprise Architecture, EA 的翻译。老一些的习惯也译为“企业体系结构”。在企业工程之屋0.92版我 将其列为企业工程的五大支柱之一。国外IT行业巨头例如IBM，近些年似乎开始真正拣起、重视这个概念，在企业应用战略性框架的描述中，EA与BPM、 SOA一起，成为并列的三大要素。国内企业应用领域的一些大企业，也开始运用这个概念。对这个概念的基本背景和内容，网络能找到不错的介绍[注1]，这里就不赘述了。

一个信息系统或IT应用的概念

一般认为，企业架构的概念还没有大家公认的、一致的定义。可以留意，John A. Zachman 1987年的开创性工作，题目是“企业及信息系统架构的框架”（the Framework for Enterprise Architecture and Information Systems Architecture）。1997年，Zachman总结了十年间的研究和实践，提出了扩充的、更完整的框架，并改称为“企业架构框架”（Framework for Enterprise Architecture）。这是一个十分重要的改变，但可以说其目的迄今仍未达成，类似的意见，也来自Zachman自己。之前发出的《IT语境中企业图景背后的某些问题》一文中，曾经引述了他在EA又一个十年（2007）时一次专访中的回顾。这里继续引述这位权威的观点[注2]。他指出，EA领域20年来最重要的变化就是其主题合理性的认识。他还认为，信息产业仍然聚焦在创建运行的系统，也就是说，我们“制造”自动化的片段、孤岛、企业的烟筒[注3]。信息产业当前并没有考虑整个企业（Enterprise）的设计规划实施工程（engineering）。

换言之，信息产业依然缺乏对“企业工程”（EE） 的整体考虑和理解。无疑，明确企业架构是关于“企业”的概念而非信息系统或IT的概念，是对这个课题合理性的一个根本性修正。虽然在用语上，大家已经习惯 了EA，但 Zcchman 所希望的那种真正的转变，看起来还没有大的进展。尽管一些咨询机构、顾问会大谈企业战略、业务规划、管理，但它们的对象，真正的实施者，却是IT部门。在 更近一些的讨论中，Richard Veryard曾指出“企业架构”（ Enterprise Architecture）的两种观点[注4]： 一种是传统的观点“EA即IT规划 ”（EA-as-IT-planning），一种所谓浮现中的观点是“将EA看作业务战略”（(EA-as-business-strategy）。实际 上，这里举出的后一种观点，仍然是不足够或清晰的。虽然，作为业务战略似乎是企业经营管理最高层面，但更重要的是战略的内容是什么。毕竟，对IT应用（信 息化）的一种高级认识，就是要将IT作为企业经营的战略工具。换言之，EA萌发时期的所谓ITA（信息技术架构）本身，同样可以处于战略管理的层面。

进一步分析

Zachman的工作从开始，就是集中在框架（framework）上，而不是更笼统和经常有些暧昧的“架构”。在前面提到的专访中，他曾指 出，“EA就是企业的描述性表达，以及企业创建后进行改变的基线”。按照我的理解，对企业的描述性表达，基本等同于企业建模，从这个角度看，Zachman的这个界定是比较狭窄的；但这个界定里没有IT的影子，从这方面，又是比较一般化的。

不妨对比一下这个领域的似乎已经广泛认同的，所谓商业领域EA的代表性规范，Open Group的 TOGAF（The Open Group Arcuitecture Framework）。根据其官方文档中关于架构概念的解释[注5]，TOGAF对架构的理解，是在ISO/IEC 42010:2007 [注6]的“架构”（architecture）定义基础上进一步补充。ISO/IEC 42010的架构定义为：“系统的基础性组织，具体包括其构成、构成间的相互关系及与环境的关系、治理其设计及演化的原则。”在上述定义基础上，TOGAF补充、强调了以下两个方面：

∙系统在组件（component）水平上的规范化描述或细节的规划，可指导他们的实施。

∙组件的结构、其内部联系，以及对它们的设计和未来演化进行治理的指南。

组件，是应用系统（软件）的基本构成要素。无论怎么理解或引申，“组件”的规划，也不像是“企业”描述或规划合适的起点或基础。TOGAF被“公 认”为商业领域的企业架构规范，这很明显地印证了前面提到的 Zachman 的看法。真正意义上的“企业架构”，也许还没有出现，目前活跃的，仍然是扩展的IT架构而已（诚然，IT架构也好，企业架构也好，都是各有其用的）。这是一种“世界观”的差别，企业架构根本目的与观点的差别。另一方面，正如我们在过去的研究中所渐渐发现的，完全从企业经营管理者、业务人员立场上进行的企业 建模，不仅需要计算机建模软件的支持，还需要新的企业应用系统技术架构的配合与支持，但这种配合与支持，不仅从应用软件功能需求或功能模式层面，从系统架 构（技术架构）层面，都有本质区别，这也是我们所发现的，填补IT与业务的鸿沟的真实途径。

在学习了多种关于企业架构的解释或定义后，我曾将一些共性同的东西做了如下归纳（这段文字我曾发布在维基百科的企业架构条目，这里重新做了修改和补充）：

∙从最广的范围上说，它是关于广义的企业（enterprise）或组织（organization）的建构学，但目前实际的应用，IT架构上的扩展；

∙在具体运用时它体现为一个持续的战略管理级业务和具体的框架（文档和模型等）；

∙可包含企业综合描述——企业建模（enterprise modeling）基本要素及其相互关系或结构、结构准则；

∙可包含企业模型或企业参考模型（enterprise refrence model），至少是模型的“框架”部分；

∙应用、实施涉及或包括整个企业生命周期（enterprise life cycle）及治理（governance）；

∙目前主要实践都是与IT应用（信息化）结合，典型地，成为CIO的基本职责，成为企业IT应用最高级别的工作与内容；

∙基本目标通常是企业内IT应用与业务的一致性；更深入的目标是建立和维护基于IT基础设施、充分发挥IT作用的信息化企业，例如所谓电子（E-government）。

需要特别指出的就是，上述理解是概念性的，可以说是理想化的。

巴比伦塔的困境

布鲁格尔绘制的巴比伦塔（取自维基共享资源）

插图描绘的是圣经里叙述的巴比伦塔，是这个领域研究与实践者爱用的一个比喻。这个故事是说，人类曾聚集在一起，想建造一座通天巨塔，上帝不喜欢这个 项目，于是就让人们说不同的语言。如其所愿，由于缺乏有效的沟通，这个项目失败了。它最直接的启示就是，建造复杂的系统，需要有效的规划与沟通。规划与沟 通是相辅相成的。而对复杂系统的沟通，必定基于有效的描述（建模）。企业架构最重要的内容与表现，就是企业建模与模型。这是大家就目标系统（即企业）进行 讨论或沟通基础（从工具，到方法）。

失败的巴比伦塔，常被作为缺乏企业架构或企业工程的象征。然而，也有人把这个比喻用到企业架构本身，说明现在一些企业架构自身高度复杂、难以实施维 护的情形，这一点，我个人认为，与更具体的问题：企业模型与建模有关。无论其它方面如何，对企业本身的建模（注意：不是信息系统）的水平，将制约企业架构 的应用。例如，TOGAF无疑不是一般企业建模的框架。这也是我本人虽然很早就看到了这个东西，却比较“忽视”它的原因。许多这个领域的实践者可能都同 意，目前真正的企业架构应用，主要适合有足够复杂的大型企业，作为IT应用领域的一种策略或工具。这也是迄今有关实践的现状。

企业工程的观点

上升到一般企业立场，暂时抛开IT的直接需求与视角（正如Zachman所提倡的），讨论企业的完整描述、企业建立与变革中的步骤、方法和准则问 题，这几乎已经就是我们所理解的企业工程（enterprise engineering）了。在这里可以品味一下 architecture 这个词，在建筑领域，这个词的基本意思常常就被翻译成“建筑学”。从这些角度看，一般化的企业架构，与企业工程，是很重叠的，就好象“建筑学”和“建筑工 程学”一样。正因为这种理解，我在企业工程之屋中， 建议将“企业建构学”作为企业工程的支柱之一，并用这个名字来对应英文的“Enterprise Architecture”。在这样定位中的企业建构学（架构），是更纯粹的结构原理与建构准则、方法学，与企业理念与文化、企业建模理论与方法、企业建 模与分析工具、企业信息系统（企业应用）一起，支撑起整个企业工程的应用与实践。

事实上，enterprise engineering这个词组，在Zachman和其他一些“经典”EA领域实践、研究者的文献中，也经常出现，而在相关领域的另一些代表性工作，比如相关领域的代表性工作GERAM/ISO15704[注7]， 则是以企业工程、企业建模、模型、框架、企业参考架构（Enterprsie-Refrence Architecture）等为基础概念。企业工程的基本立场，是把关于企业整体的、一般性的表示（描述，即建模）和方法学、建设/改变的准则等，综合归 纳起来，作为一个系统化、知识化的，以企业为目标的实践、研究、技术应用的领域，现有的企业架构方面的实践、认识，是目前企业工程可以包括的实质性内容中 最重要的方面之一。

结语

企业架构（EA）是一个正在活跃的概念，虽然已经有20多年可追溯的历史，依然不是一个成熟的概念。但它同时是一个在实践中提出、演化着的概念，所以，这个领域始终与应用紧密结合，也不乏应用实践。

从企业工程的立场所看到的问题，与 Zachman 的看法在方向上是一致的。真正的企业架构，不应该是IT架构的扩展。从企业工程的视角，可以将企业架构（最好叫企业建构学）定位在更纯粹的结构原理与建构 准则、方法学方面，它的应用，伴随着完整的企业工程，IT无论多么重要，也是完整的企业工程的一种支持、使能手段。

对于那些组织机构庞大，有多种多样的IT应用需要集成，更新、持续改善与治理的企业，应当认真考虑这个课题，例如信息化（或电子政务），大型企 业。应该由CIO（或类似职能）直接领导专门团队或部门，学习和研究这个领域已有的知识和实践，将其应用作为一种长期的企业战略决策对待。

而对于那些规模较小，基本处于初级应用水准（也许上了一两套业务支持或协同办公系统）的企业，目前的企业架构领域的技术和实践，基本不能为你提供什么直接帮助。应该专注于那些最基础的东西，比如数据的准确性、共享与深度利用，基本工作流程的疏导、改善与规划，等等。

注释

[注1] 赵刚博士2006年3月发的《企业架构的发展历史与概念》是一篇比较全面的入门介绍，不熟悉的读者可先参考此文

[注2]来自国际软件架构师协会特别专辑（2007）

[注3]烟筒，或筒仓，是过去三十年以BPR为代表的企业管理新思潮中最常使用的比喻之一，主要形容传统面向控制与职能分工的金字塔型组织的特征。与此相对的，就是所谓打破筒仓的流程型组织或网络型组织。

[注4]十分遗憾，Richard Veryard的博客也是“被墙”的众多优秀纯技术内容站点之一，目前无法直接访问

[注5]来自Open Group TOGAF9官方文档

[注6]ISO/IEC 42010:2007 Systems and software engineering — Recommended practice for architectural description of software-intensive systems，系统和软件工程-对于软件密集型系统体系结构描述的指南

[注7]ISO 15704:2000 Industrial automation systems — Requirements for enterprise-reference architectures and methodologies 对应国标为GB/T 18757-2002 工业自动化系统企业参考体系结构与方法的需求

补充说明：相关领域关于“巴比伦塔困境”比喻比较有影响的例子，是用来说明企业建模领域存在许多不同的企业建模语言和工具，相互之间却很难沟通，缺 乏互操作性的问题。这是欧洲企业建模学术研究领域的关注点之一。近年的一个重要项目统一企业建模语言（UEML）的主要目的之一，就是针对这个问题。 （2010-1-23，作者补充）

企业架构 二

企业架构(Enterprise Architecture) 

[隐藏]

∙1 什么是企业架构

∙2 企业架构中的不同角色

∙3 企业架构的信息类别

∙4 企业架构理论术语

∙5 企业架构的组成[1]

∙6 为什么需要企业架构[1]

∙7 企业架构－架构原则[2]

∙8 解决方案架构、业务架构和企业架构的对比[3]

∙9 

什么是企业架构 

　　早在1987年，John Zachman就 提出： “为了避免企业分崩离析，信息系统架构已经不再是一个可有可无的选择，而是企业的必需”。 从那时起，Zachman的企业架构理论就开始逐渐发展起来， 它现已成为许多大公司用来理解、表述企业信息基础设施的一个直观模型， 为企业现在的以及未来的信息基础设施建设提供了蓝图和架构。 

　　Zachman的企业架构是一个全新的模型，为企业信息基础设施提供一种可以理解的信息表述。 

　　Zachman没有把企业的流程简单视作一系列步骤，而是综合考虑不同角色的不同观点，提出了一个多视角、度的企业架构。 

[编辑]

企业架构中的不同角色 

　　1.企业拥有者。 

　　2.业务管理者。 

　　3.系统分析者。 

　　4.系统设计者。 

　　5.系统建设者。 

　　6.系统本身。 

　　下表的各行内容即反映了不同角色的不同关注点（角度）。 

　　Zachman同时承认每个角色均关注相同的信息类别（维度），即下表各列内容。 

企业架构的信息类别 

∙数据（什么？） 

∙功能（怎样？） 

∙网络（哪里？） 

∙时间（何时？） 

∙角色（谁？） 

∙动机（为何？） 

[编辑]

企业架构理论术语 

∙“企业”（Enterprise） 是指由一整套可识别的、互为作用的业务功能构成的商业组织。 它有能力作为实体经营运作。 根据这一定义，就应该存在企业内的企业。 只要企业内部的事业部门能够运作，它或许就可以被当作一个企业。 在这里，这一企业概念也可以被看作为“扩展企业”（Extended Enterprise），它意味着企业架构框架也包括了企业与外部实体的相互关系。 例如： 供应商、商业伙伴和客户。 

∙“架构”（Architecture）提供基础框架， 它定义和描述了企业实现经营目的和商业愿景的平台。 “架构”可以被具体定义为： 与企业经营战略、信息需求紧密相连的一整套原则、方针、、模型、标准以及流程，它结合企业未来发展方向，为企业各项解决方案的设计、选择和执行提供指导。 

[编辑]

企业架构的组成[1]

　　企业架构可以分为两大部分：业务架构和IT架构，大部分企业架构方法都是从IT架构发展而来的。 

∙业务架构：是把企业的业务战略转化为日常运作的渠道，业务战略决定业务架构，它包括业务的运营模式、流程体系、组织结构、地域分布等内容 

∙IT架构：指导IT投资和设计决策的IT框架，是建立企业信息系统的综合蓝图，包括数据架构、应用架构和技术架构三部分。 

　　对比 RUP 和其他主要关注于实现的规程，企业架构领域原则上的关注点是企业范围内的业务需求的识别、规范，及优先级划分，感觉它也是一个做企业信息化规划的方法。我认为，做工具型产品和企业级产品有个差别，那就是做企业级产品需要由工具型产品的产品型公司向咨询类的服务型公司转型。 

　　1. 业务流程的组织逻辑(包含所有信息和技术服务，流程)和IT基础设施，反映了该公司运作模式的整合和标准化的需求 (MIT Center for Information Systems Research) 

　　2. 概念蓝图，定义了一个组织的结构和运作。企业架构的意图是确定组织如何能够最有效的实现其当前和未来的目的 (SearchCIO.com) 

　　企业架构如同战略规划，可以帮助企业执行业务战略规划及IT战略规划。在业务战略方面，可使用TOGAF及其架构开发方（ArchitectureDevelopmentMethod/ADM）来定义企业愿景/使命，目标/目的/驱动力，组织架构，职能及角色。在IT战略方面，TOGAF及ADM详细描述了如何定义业务架构，数据架构，应用架构，和技术架构，是IT战略规划的最佳实践指引。企业架构是承接企业业务战略与 IT战略之间的桥梁与标准接口，是企业信息化规划的核心。 

　　源于90年代美国的企业架构框架，到目前已经衍生出多种企业架构框架，如DoDAF（美国国防部体系架构框架 The Department of Defense Architecture Framework）、TOGAF等。 

[编辑]

为什么需要企业架构[1]

　　有些人可能会问为什么要做要做架构，直接拿来需求就做不就行了，以前做些小任务都是这样的。就像搭个简易狗窝不需要请设计师来专门做个设计，但 是建个大厦必须设计一样，我想对于不复杂的东西，你怎么做我都觉得很正常，但是一旦业务复杂、处理麻烦时，必须有一个清晰的架构才能保证做出来的东西是正 确的。 

　　中国的大多数企业在进行IT投资时都会跳过企业架构这个环节而直接进入了IT项目的建设，这样就会导致重复投资、信息孤岛等必然现象的出现。有时缺少规划，也会发现很多开发的功能被打入冷宫，这里列一个简单例子：如hr系统中的HR服务台的一个功能，我填写了一个问题，但是没有回复，估计这个功能就被打入冷宫了，这样满意度也就会下降了。 

　　通过企业架构，我们可以达到： 

∙企业内不同的人要对企业现状（as－is）和企业愿景（to-be)有一个整体的的理解 

∙业务、信息、技术人员的共同愿景，是理解、沟通的基础 

∙如果没有一个清晰的架构，就不能保证争取的决策和好的实现，EA是理解和实现企业IT建设的保障 

　　TOGAF在国外的认知度很高，目前企业架构方法有很多，但TOGAF是最主流的，已经有超过15年的历史。不仅有80％的福布斯( Forbes)全球排名前50的公司在使用，而且支持开放、标准的SOA参考架构。目前已得到国际主流厂商的推动，德国有SAP在推动，美国IBM、 HP、SUN等公司在推动，中国在企业架构方面并不是很成熟，以前讨论多半集中在软件架构或是单独的系统架构，在02年才有一个企业架构出现。金蝶在TOGAF 8.1成熟之后，引进9.0，因为它包含对SOA的支持，所以这个也是金蝶选择在这个时期把它导入的原因之一。金蝶加入The Open Group，希望能够提升中国企业信息系统及业务架构的水平，并率领国内软件产业参与国际标准的制定。对金蝶而言，引进TOGAF和Open Group的SOA参考架构及治理原则，将推动金蝶集团产品，开发过程及治理的国际化与标准化。未来金蝶ERP产品EAS、BOS及金蝶中间件等产品都将遵循TOGAF企业架构框架，架构开发方及SOA参考架构，以提升产品质量及全面SOA服务化。在金蝶产品获得成功后，将建议金蝶用户采Open Group的TOGAF及SOA标准。在2009年11月份上海的金蝶年度客户大会及中国管理模式杰出奖颁奖典礼中，金蝶发布了EAS 7.0新版本，这是中国第一款使用TOGAF企业架构框架规划及SOA的ERP产品。 

[编辑]

企业架构－架构原则[2]

∙架构原则 

o基于标准方法来做架构，如使用TOGAF架构方法 

o说不清的不做 

o没人上层持久推动的不做 

o达不成一致意见的不做 

∙业务原则 

o业务持续性（对业务发展有长远计划，不能只考虑近期实现范围） 

o业务通用性（业务是否可以作为一个公用业务架构） 

o业务一致性 

o合法 

∙数据原则 

o数据价值性>数据正确性>数据完整性 

o数据积累分析需要规范化数据 

o数据是安全的 

o数据不只是可以共享的数据，还包含业务规则和策略 

∙应用原则 

o技术性，不绑定到特定厂商 

o易用 

o模块化设计 

∙技术原则 

o响应变化 

o可扩展 

[编辑]

解决方案架构、业务架构和企业架构的对比[3]

　　 开发人员对于架构这个词一定不陌生，但是我们说的架构只是产品开发中的技术相关架构，真正要做好一个产品，在技术架构之上还有其他一些架构，本篇介绍一下三类主要的架构：解决方案架构、业务架构和企业架构。有时候我们把视野拓宽一些，多锻炼自己的大局观，对自己的思维和技能都会有很大的提高。在《TOGAF 或非 TOGAF：在 RUP 之上扩展企业架构》中对比几个不同的架构框架，让我对什么是架构更清晰了。我觉得不错，所以给大家分享一下。 

∙解决方案架构 

　　解决方案架构是“技术性的”，它们的范围内包括各种技术元素，如软件、数据和 IT 基础架构，这些领域都是由技术人员来处理 。 

∙业务架构 

　　业务架构在 90 年代作为单独的领域出现了，业务架构包含过程及信息、组织和绩效等方面内容 

∙企业架构领域 

　　企业架构领域原则上的关注点是企业范围内的业务需求的识别、规范，及优先级划分，EA 路线图可能比单路线解决方案包含更多内容（如上图所示），这可能会形成多个、同时的实现。 

　　EA 环境是全局性的，其视点是组织化的，而解决方案架构是具体到实现的。EA 主要用于企业分析、计划和架构治理。 

　　注意：来自解决方案架构规程中的一些主题（低层次的）不含在 EA 的范围内，而许多附加的（大部分是更高层次的）主题加入了。还要注意的是关键的业务架构主题完整地包含于 EA 规程之中了。 

[编辑]

参考文献

1.↑ 1.0 1.1 周金银.企业架构 － 开篇：TOGAF介绍

2.↑ 周金银.企业架构－架构原则

3.↑ 周金银.企业架构－对比解决方案架构、业务架构和企业架构

Zachman企业架构框架简介

引言

随着企业架构（EA）的发展，Zachman 框架[1]的地位显得愈加重要。根据资料介绍，重要的企业架构成果如FEA、TOGAF等，都是在这一框架基础上发展而来的。企业工程论坛一般不介绍或涉及商业性企业或其产品，但由于Zachman在国外EA领域的独特地位，EA和企业建模等话题稍微深入，就不能不讨论它。

发展

在《谈谈企业架构（EA）》等文中曾经初步介绍，Zachman框架，是从信息系统框架发展而来的。我们看到，他在1987年初次正式发表的工作为“The original Framework for Information Systems Architecture”，表现为一个3×5的矩阵。1992年，他与John F. Sowa合作发表了扩展的框架方案，名称没有变，但将涉及范围推广到所谓“工程化的企业范围”（”engineered” enterprise-wide），引入了6个基本疑问词（5W1H）作为横向展开的依据，整个框架表现为6×5的矩阵。这期间人们也开始用“Zachman框架”这个名字直接称呼它。

1997年，初次发表10年之时，Zachman再次发表新的论文“Concepts of the Framework for Enterprise Architecture”，在概念上，完成了由信息系统架构框架向“企业架构框架”的正式转变。在随后几年，在框架的细节、单元内容细节等方面持续有改进，矩阵图也变化了好几个版本，但主体结构和内容基本稳定。2008年推出了正式简明定义和框架标准。后面的介绍主要基于这些信息。

正式简明定义

下面是Johan A. Zachman对的正式简明定义：

Zachman框架（Zachman Framework™）是一个纲目（schema）——两种有几千年历史的分类法的交集。第一种是建立在原始疑问词上的沟通基础要素：什么、如何、何时、何人、何地以及为何。这些问题答案的集成，能够对复杂的想法形成全面、综合的描述。第二种来自具体化，即古希腊哲学中假定的抽象观念到实例的转换，在Zachman框架中记为：辨别、定义、表达、规定、配置和实例化。

Zachman说，框架分类的最初启发是来自对建筑、飞机和其它复杂的工业产品的观察经验。对于上述定义，他还强调，Zachman框架是一种描述企业的本体，是元模型，而不是关于创建对象的最终实现（实例）的方法学。它是关于结构的，而不是过程。它是企业架构（EA）的基础。

基本结构

Zachman框架是一个综合性分类系统。它相当于通过6×6的分类矩阵，把企业架构涉及的基本要素（而不是企业本身）划分成36种单元（Cells），并清楚地定义了每个单元中的内容（组件、模型等）性质、语义、使用方法等。从相关介绍可以知道，在找到现在这种二维矩阵的划分方式之后，对每个单元的内容也在逐步认识、实践和总结。考察现在的标准叙述，仍可以感觉到，单元的内容和单元间的关系，远不像架构的整体方案所暗示的那样明确、直观。标准中对多单元上用法说明，有些也并非显而易见。这一方面体现在这个表面简单的结构中，还蕴藏着不少“道理”，同时可能也说明，这里还有不少可以探讨的空间和不同的可能性。

详细的分类矩阵，可以由其网站上看到。5W1H的描述展开，看来“非常基本”，似乎只有用或不用的选择，但并非没有讨论余地，特别是，如果站在企业规划、建模、模型工作机制这样一些角度上，会更有多的讨论空间——不仅是关于5W1H这一方案的选择，而是在更深的层面上（参见后续的分析文章）。相对于行的展开，按照“具体化”层次展开的列，则更需要仔细考察。下表将Zachman提示的具体化标志与实际矩阵上的标签对应起来，以便于观察。同时，对照列出了“Who”这一列单元格里的基本提示。单元格里放的东西，前五层都表现为模型（或文档），而最底层是实例。

从现有的单元格内容和关联的解释看，这个表面简单的“正交”二维分类矩阵，每一个交点（单元）上对应的到底应该是什么，并非显而易见，或许有许多值得探讨的可能性。而从现在所给出的方案看，这两个维度也许并非如矩阵图所暗示的那样，完全是简单正交的。纵向的具体化层次划分，表面上看似乎经验性的色彩较为浓厚，但结合其所给的各列内容方案，能够体会到，其中的蕴含还是相当深的，正如它十几年发展已经体现的，一方面有很多经验性的、实践的支持，一方面也是得来不易，很有参考价值。这个分类矩阵的行、列选择，的确相当基本，显示出某种“本质划分”的特点，但也并非没有争议。以后我们将对此进行讨论。

如果我们按照这个框架本来的定位——作为一种企业架构/工程的描述性逻辑结构、分析框架去使用，它无疑是非常有启发性的一种基础性工具，一旦超出这个范围——例如，用来指导实际企业的企业“架构”开发，甚至企业建模，就可能会遇到很多具体的问题。

结语

本来准备从以前的笔记中摘录做一个浅析，到Zachman网站上查看一下，与几年前相比，又有一些变化或更新。核对新资料重新整理一下，不知不觉大半天时间就去了。最初计划还有一个分析部分，干脆另文发出。

注释

[1] Zachman Framework TM是私有性质的，商业和机构使用及一些资料需要授权或购买。本文主要参考Zachman International网站上公开的或个人免费注册可读资料，以及wikipedia条目。

Zachman企业架构框架若干分析

摘要： 关于“Zachman企业架构框架”（The Zachman Framework For Enterprise Architecture）的介绍很多，本文在前一篇基本介绍的基础上，尽量从不同的立场做了一些分析，内容包括：对象与内容、是什么、知识分析的框架和 组织的框架、基本的分析-叙述要素都有哪些、作为本体、ZF与企业工程、框架的实现与信息系统（IT应用）的关系等。

1   对象与内容

北京：鸟巢，复杂的建筑（取自维基共享资源）

Zachman本人和提倡者都十分强调其企业架构框架的“基本性”，并指出这个分类体系实际可以用于任何事物。在他的网站上，除了企业框架，现在还 推出了产品框架等另外三种框架。然而，也有一种基本的观念：适用于任何事情就等于没有用途。所以，我们还是集中在特定的话题，企业架构（EA）框架。

对于“企业架构框架”这个名称，仍然有被其分类的对象（内容）是什么的问题。以“建筑”来比拟，对于一幢实际的建筑，例如鸟巢，会有大量的工程资 料，其中，一部分直接描绘了这个建筑本身，而数量上更多的资料，是关于如何施工、如何管理、维护它的。哪些是建筑本身，哪些是对建筑的描绘（蓝图），哪些 是实现建筑的过程的规划，是很清楚的。而企业的情形则不同。几乎所有企业架构框架的应用，都是针对已经存在的企业，“企业工程”的过程与企业的“运作管 理”过程完全是交织的（在大部分企业实践和传统管理学中，基本上不会去考虑这种区分），对资料以及角色——组织与人也同样如此。企业工程与运作管理的“经 纬之别”，并不是那么显而易见、自然存在的。

2   是什么

正如Zachman本人所强调，ZF是一个分类框架：由“疑问词”（观察或焦点）和“具体化标志”（由一般到具体的几种典型认知水平，另一种类型的 观察视角）两个“维度”构成的正交表，是组织关于企业的知识的二维分类矩阵。在实际应用中，ZF大部分的格子里，所装的都将是关于某个特定企业的描述：书 面叙述、各式的模型。

Zachman框架虽然可以“容纳”各种企业模型，即将所有的企业模型组成部分或字模型“放进”框架的某个特定的单元格，但它不是关于企业本身的 “企业模型框架”（framework for enterprise model），正如其现在的完整名称，“企业架构框架”（The Zachman Framework For Enterprise Architecture），其中的架构（architecture）一词是不应省略的。

虽然他强调，这个框架是一个结构而不是关于企业的具体建构实现过程，不是方法学，但其纵轴（列）的“具体化”层次的展开，自然地对应着企业工程（建构或改造）的基本步骤，与ZF应用关联的，合适的方法学，将不能无视或背离这一点。

3   知识分析的框架和组织的框架

首先我强调，“分析知识的框架”和“组织知识的框架”是两个不同的概念。我 们从小就学习过记叙文的基本要素，包含时间、地点、人物、事件等等基本要素，但文章（内容）的组织结构是千变万化的，很少有文章会按照这些基本要素来决定 内容的组织结构。然而，在所见有关Zachman框架的基本信息中，并没有明确强调这一点，反而显示出把它作为组织知识的框架推荐的倾向。

我认为，Zachman框架首先是一种分析的框架，当然它“可以作为”组织、归拢分析结果的框架来用。越是从普遍性、根本性角度看，这种区分越是重要和明显：它的根本性、经典性或不可忽略的方面（这是提倡者努力强调的），在作为“分析框架”时，更明显和有说服力；而作为“组织框架”，则未必如此。

例如，许多重要框架，比如FEAF或TOGAF，都与ZF有某种继承关系，但它们的内容都不是按照ZF组织的。理解了以上的区别，才能更好地理解实际框架的这种发展和选择。

Zachman还喜欢将其框架与元素周期表比较，说明它的根本性、必然性。但我们也可借这个比较得出其它的理解。化学元素是可以被单独提取出来、真 实的存在的物质类型，是宏观物质的构成要素，基于化学元素的分解、合成，基本上是与观察者无关的，可重复的。对于Zachman框架，如前面分析所指出 的，它的根本性主要体现在分析的方式，分析的要点或着眼点方面，它本身基本不反映企业特有的一般性结构（或者说只反映了很少的方面，例如把Who解释为组 织等）。它划分的36种基本单元，只有严格在分析文档（或模型）的分类时，基于人工的理解，才能说是相对的。即使不针对企业本身，而是对企业的 “描述”，它们也不具备化学元素那样的客观性和严格、可不断精确复现的特性。它不仅是一种分析的框架，其内容划分的方式，也是与观察者的立场有关的分 析与描述原则，而不是组织、构成的原则。这层理解对于正确地运用是重要的。

4   基本的分析-叙述要素都有哪些

从分析的角度，Zachman框架是很基本的，但是否就已经是“完备”的？对此也不是没有质疑。5W1H的确是很基本的要素。还记得小学语文老师教 的“记叙文”的基本要素，包括时间、地点、人物等，似乎还有更多的要素，但到底是事件、过程还有结果、原因？细究却会发现，许多答案是相似的，但并没有绝 对标准的答案。

同样，对于企业架构，5W1H是一些非常基本的问题或着眼点，这应该没有什么疑问，但是否足够？具体含义或内容是什么？实际上很难有标准答案。例如，Graeme Simsion关于Zachman框架的质疑（2005）中就提出了这个问题[1]， 并指出可以增加第六、第七列：how many, how mach (volume, financial)。无疑，你可以认为，how many就可以被概括在其它列中，例如What，其中包含着数量，也可以包括金钱。但在许多场合，人也是一种“what”。既然What可以包含how many, how mach, 同样可以把when都包含到与之相关的事物中，而无需单独分解出来。另一方面，对这些疑问词本身如何解释（或展开），同样可以见仁见智。例如When，在 Zachman不同阶段的框架版本中，其诠释就有所不同。而在如此基本的要素上，理解稍有不同，在实际应用中就可能有巨大差异。再回顾与元素周期表比较， 可以体会到它们的差距是非常巨大的。

上述例子只说明，5W1H的确很基本，但其基本性、完备性并非绝对，按照这种方式刻板地分解、组织关于企业或企业架构的知识，并非我们唯一的选择，也很难证明这总是最佳的选择。

5   作为本体

Zachman指出ZF是一种本体（ontonlogy）。我个人认为，Zachman框架的确可以看作一种本体，但从应用意义上看，其所包含的信 息量非常少——因为它太“一般化”了。另一方面，作为一个本体框架，我们可以看到，如果比这36种关注焦点再进一步，ZF本身几乎没有提供任何反应了某种 企业特有（而不是“事物”特有）的要素或基础结构。

个人以为，在应用“本体”或本体工程的立场上去考察，它是一种非常弱的本体。从具体操作的角度看，如果要作为某种企业或企业架构的本体使用，还需要补充很多内容，而这些需要补充的内容，仍然可能是相当通用的（即可能需要或适于作为本体的一部分提供的）。

6   ZF与企业工程

我一直强调目前流行的“架构”（architecture）一词常常显得暧昧和误导（英文中也有这个问题，但流行的中文翻译则更显偏颇），我宁愿使 用企业工程、企业模型与建模、企业工程规划、建模方法、实现方法等直接、明确的概念，在这样构造的概念集合中，并不一定需要“架构” （architecture）这个概念[2]，但现实是，后者历史地，流行了。无论用语如何，企业架构（EA）与企业工程都是相当密切（或相当重合）的概念。

如其从信息系统框架转向企业框架的基本解释：要上升到整个企业范围上的工程（to be “engineered” enterprise-wide）立场上。这种站在企业整体视角，针对企业中“可工程化”的事情的立场，正是我们提出企业工程的基本立场。（所谓工程化， 可理解为有明确的规划、方法学、以及对其背后的知识与技术的系统开发、整理、传授）。

现有的企业架构框架也就是企业工程的一种参考框架。如果将Zachman企业架构框架比作一个货架，那么，这个货架上摆放的，并非企业的零件，而是 企业零件的设计文档、模型。如果从企业工程立场看，再增添或明确一些东西（比如，关于企业工程的过程框架、企业生命周期、相关的方法学等），就构成完整的 企业工程的框架。

这并非我的牵强。Zachman在许多场合，也喜欢使用Enterprise Engineering这一词组。它与企业工程的关系，在Zachman的基本著作标题里也清楚地指明了：“Zachman企业架构框架：企业工程与建造 的入门读物”（The Zachman Framework For Enterprise Architecture: Primer for Enterprise Engineering and Manufacturing）。

7   框架的实现与信息系统（IT应用）的关系

Zachman早已将框架的目标范围扩展到了整个企业，并强调它与信息系统/IT架构的区别。我们也可以用这个框架去为企业的其他技术基础设施建 模：例如，在第一列“什么”（What），去定义流水线范围、类型，在第二行用执行/管理者的语言去描述它（概念设计）……第四行定义工程蓝图（零件图、 装配图），第五行定义配置方案……但仔细对照Zachman框架标准对各单元格的界定，也许应该承认，目前这个框架的基本用法，不是这个样子（我相信大多 数人也不会这样去用）——“适当的”用法大致会是，在第二行定义了流水线的信息模型（例如，相当于ERP中的工作中心），第三行就是所定义的不同类型的工 作重心的数据模型，第四行的所谓“蓝图”，不会是机电设备的工程蓝图，而是在电脑上实际记录流水线（作为“信息实体”）的数据物理模型……第六行的所谓实 现，就是具体完成的某个软件（或其部分）。

换言之，对应已经完成的具体“框架”（即，按照框架的36个单元完成了对应的文档或建模），其最直接的“实现”，就是信息系统的实现，或者说，是支 持所定义的所有综合性业务、业务资源的IT基础设施的实现。当然，企业框架对于IT的这种“亲和性”，并不能简单归结于“人择”结果。

8   小结

Zachman企业架构框架是一种分析框架，包括了一些最基本的分析要点或关注点、视角，它也是关于企业架构的一种简单本体（通用概念及语义）。它 是一个分类调查表，是展开分析，并组织分析所得到结果的一种基本结构。它不是一种企业模型框架，并没有包含多少比“普通事物”更多的“企业”独有的构成要 素或结构特征。

虽然它的关注范围是整个企业，但从应用和实现的角度看，它至少是更适合于IT应用领域。它可以用于这样的场景：在清晰地界定企业战略的前提下，清 晰、完整地描述企业（业务及资源等），作为“输入”，与企业（业务）IT应用与IT治理的良好地对接（这是随企业发展的持续、动态的过程）。从企业工程立 场上看，它是一种初步的、基础性的框架，可以作为完整企业工程框架的基础部分或基础工具。

注释

[1] Simsion (2005) 主要提出了三个方面的质疑，其一是5W1H六个疑问词是否最合适或唯一的选择，指出在法语中how many, how mach也是基本的疑问单词而非复合词。其二是对“建筑”这个隐喻的质疑，指出具有自适应演化特征的“城市”是比建筑更贴切的隐喻。其三涉及 Zachman框架是否一种信息系统建构性方法的基本选择，是否有足够的证据或使用效果的评估。他的讨论主要站在信息系统建构方法的角度。

[2] 这里主要是从基本的知识或研究、技术、实践领域划分或构造的角度上看。也许有人会说，存在的就是有道理的。我认为从实践的角度看，一个较为狭义的 architecture概念更有操作意义，这个狭义，若偏重实践与技术方面，可以引用中国古代文化中的“营造法式”；偏重知识的方面，“建构学”或许更 清楚明了。参见《谈谈企业架构（EA）》、《企业工程的内容与企业架构的定位》等文的讨论。

黄莺：企业架构面面观

企业架构的发展、概念与定位

2010年08月17日

摘要：正如企业信息化领域出现过的其他方 法概念一样，企业架构也是这个领域发展到一定阶段的产物。本文尝试借助一些已有的概念来理解企业架构，并从其应用发展的历史来预见其未来的应用前景；对于 概念本身，本文试图从架构一词引伸出它与系统论的关系，给出自己对这个概念的理解，并在与相关概念的比较中进一步澄清概念；最后，作为对企业架构目标的进 一步解释，本文又在一个具体企业的信息环境中去观察它与其他管理框架间的交互。通过企业架构的历史发展、被应用的环境这些方方面面，尝试揭示出这个概念的 内涵。

关键词：企业架构、信息规划、TOGAF

引言

随着企业架构与TOGAF越来越多地为大家知晓，大家对这套概念方法也产生出越来越多的困惑，到底什么是企业架构，它和我们传统的企业建模、信息规划有什么不一样，它在整个企业信息环境中处于什么样的位置，使用它究竟能产生出什么不一样的效应？

其实，“企业架构”并非横空出世，TOGAF也并非空穴来风，它们都是企业信息化实践发展到一定阶段的产物，下面我们就从企业架构的起源、它的应用发展历史、它的内涵和目标，以及它在企业信息化中的位置等这些方方面面去探一探企业架构的究竟。

1.企业架构的产生与发展

1.1企业架构的产生与企业建模

谈到企业架构，就不能不提到ohn Zachman。他是企业架构领域的开创性人物。在他任职于IBM的26年中，曾涉及过战略信息规划方、业务系统规划、信息系统规划和架构等多个领 域。他于1987年提出的“信息系统架构的框架”（Framework for Information Systems Architecture），即俗称的Zachman框架 ，被认为是企业架构领域的开创性工作。在此基础之上，经与他人的合作和自己的改进，他于1997年又提出了更完整的框架，并改称为“企业架构框架” （Framework for Enterprise Architecture）【1】。

Zachman框架通过一个二维矩阵，分别从利益相关者和架构的不同角度这两个维度对企业进行了抽象，如图1 所示。尽管从方的角度，它缺乏可操作的方法和流程，但它成为了后续若干其他企业架构框架的基础，包括下面提到的FEAF、TEAF、DoDAF等。

图1 Zachman框架

从另一个角度，Zachman框架又通常被业界认为是一种企业建模的方法，并与其他的企业建模方法，如CIMOSA、PERA、GERAM、 ARIS、DEM 等进行比较，因此把企业架构领域看成是企业建模的范畴也不为过。最初接触企业架构的人总对这个新概念望而生畏，殊不知它正是企业建模领域的新的发展；不 过，从下面分析中可以看出，企业架构又不同于传统的企业建模，它具有更明确的目标，更强调与整个企业信息环境的融合。

1.2 企业架构框架的发展与应用

企业架构框架的早期应用和发展得益于美国部门的信息化标准和实践。1996年，美国颁布了Clinger-Cohen 法案，对机构内开发、实施、维护一个合理、集成的IT架构提出了要求【1】，这一方案催生出很多企业架构方法框架，也使企业架构最初开始运用于各类的 机构和军事部门。企业架构领域也伴随着这些方法框架，开始走向成熟。

对于这些早期被应用的企业架构框架，笔者大致把它们分为三种类型：

第一类是美国联邦、财政部提出的架构框架系列【1】，这其中有代表性的包括FEAF、TEAF。以Zachman框架为基础的 美国联邦企业框架（Federal Enterprise Architecture Framework，FEAF）是由美国联邦CIO委员会于1999年发布的，其目的主要是为了响应Clinger-Cohen 法案，促进联邦对信息技术的统一采购；以FEAF为基础，美国财政部又于2000年提出了财政部企业架构框架（Treasure Enterprise Architecture Framework，TEAF），以对其下属的各财政机关的业务流程改进、信息系统开发和维护提供指导。

第二类是美国国防部的架构框架系列及其派生框架【1】，其中有代表性的包括C4ISR、DoDAF等。C4ISR 架构框架是90年代应用于美国一些重点军事部门的架构框架，其目的是实现这些C4ISR部门间的信息共享，以满足战争的需要；后于2003年8月被 DoDAFV1.0取代，应用范围也扩展到所有的军事部门。其他的派生框架还包括NAF（北约架构框架）、MODAF（英国国防部的架构框架）。

第三类与上述由部门发布的框架不同，是由民间组织——开放群组（The Open Group）于1995年提出的开发群组架构框架，即TOGAF（The Open Group Architecture Framework），其最初的版本是建立在DoDAF中一个技术参考模型TAFIM 基础之上的。这套方法框架目前一般被应用于商业企业，主要解决这些企业信息架构的设计、规划、实施和治理等问题。因为它可被免费下载和使用，除了开发群组 的架构论坛，一些志愿者架构师们也在实践中对其进行着更新和维护。到2009年2月，TOGAF已推出了第9版。

从企业架构的发展过程来看，它最初是应用于机关和军事部门，这些组织往往涉及众多的下属机构、统一的组织目标和类似的流程职能，但同时又需要进行统一 的管理和信息的共享。随着中国国力的强大和国库的充实，部门的信息化投资和标准化、集中化有可能会成为趋势；而另一方面，随着企业规模的扩大，上述这 些组织的特征也会成为或已成为很多企业的特点，TOGAF在越来越多的企业中应用，也在印证这一点，随着中国经济的崛起和企业的壮大，我们也可以预见到这 种方法框架在中国的应用前景。

2.企业架构的内涵

要应用企业架构，还是首先要搞清楚企业架构到底是什么，特别是它和我们了解的企业建模、企业信息规划有什么不一样。

2.1 企业架构与系统论

根据TOGAF的解释【2】，这里的“企业”与传统意义上的企业有所差异，它既可以是以营利为目的的商业企业，也可以是、研究机构等非营利组织；它小 可以到组织内的一个部门，大可以到集成了客户、供应商的扩展性企业；总之，只要是有着共同目标的组织集合就可以认为是企业。对企业概念的扩展意味着我们可 以把这套方应用在更加广阔的领域。

而“架构”是指“一个系统基本的组织，体现在它的各个构件、构件间的相互关系、构件与环境间的关系，以及治理其设计和演进的原则上”【3】。如果把它用在 企业上，那么就意味着我们首先要把企业当成一个系统。从这个意义上讲，“企业架构”也可认为是系统论在企业信息化这一领域的应用。

如果我们把企业看成一个系统，它的架构就是指：

这个系统的各个组成部分：比如它的业务愿景、中长期的业务战略、短期的业务策略、它的组织结构、物理分布、业务职能与流程、KPI、支撑业务的信息系统、数据资产、网络平台、通信设施等等；

各组成部分之间的关系——比如一个新的业务战略需要采取什么样的业务策略、流程去支持，组织结构需要发生什么样的调整、进而需要有什么样的IT系统去支持、对网络平台、硬件的投资会是怎样等等；

上述这些企业系统的要素与企业环境间的关系——比如，企业外部环境是怎样的、是否有和/或行业法规的、企业当前的能力和企业文化是否会其对IT的投资等等；

以及如何设计这个系统、维护这个系统等等的原则——比如按照什么样的步骤方法能够去描述这样一个庞大的系统；如果描述出来，随着企业其他管理活动的进行，比如新的项目、日常运维，怎么确保这些描述能够与时俱进？

这就是最直接意义上的企业架构。

有人喜欢把架构比作盖房子的蓝图，那么“企业架构”就适合用城市建筑群规划这样的宏观课题来比喻：这所城市的定位是怎样的，是新兴的经济城市、还是历史文 化名城；它希望往哪个方向去发展，会受到哪些方面的制约；它的关键职能和支撑职能有哪些，如教育、医疗、公共安全、税收分配等等；为了支撑这些职能，它的 城市布局应该是怎样的，如建筑效果图、市政规划效果图、园林景观效果图、道路桥梁立交桥效果图等；需要有哪些关键建筑物，比如市政大厦、医院、学校、警 局；那么这些关键的建筑物之间的方位、距离需要有什么样的考虑，能否确保这个城市能最有效地行使它的关键职能；它的建筑群是否需要有统一的建筑标准，整个 城市是否有统一的供暖、排水、通信等基础设施；如何确保后续新的施工项目、楼宇的维修能够严格按照这个标准进行管理等等。

TOGAF第9版通过一个元模型完整地诠释了企业系统的各个组成要素【4】间的关系以及它的实现和维护框架，如图2所示：

图2：企业系统的抽象描述（TOGAF元模型）

从系统论的角度来看，企业架构强调的是企业这个系统组成的有机性——即各个部分之间相互关联、牵一发而动全身；和目标的一致性——即所有部分都为了共同实现企业的业务目标。

2.2 企业架构的定义与目标

对于企业架构的明确定义，在业界尚未达成一致意见。不同的组织也有不同的理解：

 MIT的信息系统研究中心的定义【5】是：“业务流程的组织逻辑和IT基础设施，反映了该公司运营模式的整合和标准化的需求。”这里就把企业系统的基本组 成——即业务流程的组织逻辑和IT基础设施，和系统的基本目标或者说趋势——即运营模式的整合和标准化，阐述得更加清晰了。

 来自SearchCIO.com的定义是【6】：“一个定义组织结构和运营的概念蓝图。企业架构的目的是用来决定组织能够如何最有效地实现它当前和未来的目标”。这个定义强调了企业架构的最大目标在于帮助组织“最有效地实现其当前和未来的目标”。

不管从哪些角度去描述它，总之，“企业架构”应不离对企业这个系统的架构描述这个宗旨；而正是通过这种抽象，特别是建立了从业务要素到技术要素间的追溯关 系，企业的业务运营模型得以结构化，业务战略的达成路径、业务策略的可行性分析得以直接的支持，并且，企业IT项目的开发、运营可以参考一个较为长远的业 务背景和规划，这些“创新”得以被有序“管理”【2】，如图3所示：

图3：企业架构的目标

3. 企业架构在企业信息环境中的定位

正如我们从上文中看到，企业架构与企业建模、信息规划的最大区别就在于是用联系的观点——即关注企业模型与企业环境之间的关系、和发展的观点——即不仅关注如何抽象，还关注怎么去维护这个模型，来重新审视企业抽象建模的问题。

那么当它被应用于具体企业环境中的时候时，它会和哪些具体的管理框架发生关系，又会起到什么样的作用呢？对于这套企业模型，我们又该如何去维护呢？

3.1 企业信息环境的抽象描述

TOGAF第9版给出了一个企业各类管理框架与企业架构之间的关系，如图3所示【7】。它把一个企业的信息环境划分为成了业务规划、企业架构、项目管理、运营管理、方案开发这样几个领域：

图4：企业信息环境中的各个管理框架

这个图较为完整地描述了企业信息环境所涉及到的各个方面，正如我们提到过的城市规划建筑一样，企业的各个管理框架都是为了确保这所城市的建筑景观的有序开发：

业务规划决定了企业这所城市具备哪些职能的方向性问题，比如这所城市的定位如果是经济新兴城市，它就需要大力发展特色产业、金融、服务业这些职能，对应于企业，就是支撑企业战略需要的关键企业能力、业务职能、流程和系统等；

而企业架构则把这些能力的方向转化成了城市未来的景观，比如如果要大力发展特色产业、金融、服务业这些职能，那么就需要有专门的工业园区、金融中心区、商 业步行街等这样的景观，它们的位置、外观、建筑风格、基础设施、周边环境乃至与整个城市配套设施的关系等等，都必须有一个完整的考虑，而这就是企业的远景 架构；企业架构与业务规划一起决定了企业的能力方向和远景架构，共同形成了对企业至关重要的“能力规划”；

而项目管理就是负责交付这些景观的各个施工单位，他们拿着企业架构交给他们的施工指导图纸，按期、保质的来交付这些景观，并把完成的项目成果移交给运营管理；

运营管理则像一个大的物业公司，它们维护着这些业务和IT的资产，支撑其企业日常的业务运营；

至于方案管理，它们则像专业的建筑公司，在项目管理、运营管理中提供着专业的指导，同时也必须接受着企业架构——这个远景规划的约束。

3.2 企业架构在企业信息环境中的作用

现在再让我们把目光聚焦在企业架构身上，看看它在其中所承担的关键职责：

企业架构与业务规划

对于企业架构与业务规划间的密切关系，JEANNE ROSS 的《企业架构如同战略》甚至认为，企业架构是“企业运营模型的一部分”【8】。业务规划明确的业务能力如果要落地，必须通过企业架构来转换为一系列“执行 的基础”【8】，即下面所说的开发项目；而缺乏了企业架构，业务愿景、业务战略只能停留在关键人物的大脑里，被模糊地描述在PPT、报告里，被不同角色的 人理解成不同的东西，而企业架构正是把这些最关键的业务要素结构化、明晰化的转换器；

企业架构与项目管理

具备了企业架构的企业，其项目的进行不再是杂乱和无序的，而是按照企业架构要求的能力增量按优先级、有计划地开展，企业架构对其提供的是长远的路线图和过程中的治理。

企业架构与运营管理

同样，企业架构描述的企业模型描述了一个业务流程、IT资产的全貌，使日常的维护有了一个可供参考的背景，而不再“按下葫芦浮起瓢”。

不过，这也提醒我们，治理对于企业架构尤为重要。否则随着业务运营、项目管理的进行，它所描述的企业模型也会变得不合时宜。

企业架构与方案开发

对于方案开发，企业架构提供的则是业务背景和具体架构领域的指导。如TOGAF把企业架构划分为业务架构、数据架构、应用架构和技术架构，在开发某个项目 的方案，或维护某个方案时，其方案架构的各个方面就必须符合企业架构的整体描述；企业架构使专业方案开发人员在一个业务背景下去开展工作，而不再一味去追 求技术上的领先。

结束语

任何的概念方法都是伴随着其具体的实践，包括一些具体的应用模式框架，而走向成熟的，企业架构领域也正是这样。从Zachman框架到FEAF、DoDAF、TOGAF，这个概念出现以来近三十年中的这些框架模式，都越来越清晰地揭示出其核心和内涵。

脱离应用环境去理解企业架构，或是单纯去比较这些框架模式并没有什么实在的价值，结合企业环境加以实践才能真正领悟其内涵，发挥它的作用；而适合企业的、或者更确定地说，企业能将其融合到运营环境中，有效地使用的才是最好的方法框架。

而对于企业架构实施，需要我们在理解这个概念的基础上，在一种具体方的指导下，结合企业的实践去开展。企业架构在国外的应用已有近三十年的历史，相信随着中国国力的强大和企业的日益强盛，它也必将在国内大展它的用武之地，为我国、企业的信息化建设做出贡献。

注解

【1】俗称的Zachman框架其实包括由Zachman提出的框架的多个版本，如1987年的最初的“信息系统架构的框架”、90年 代更新的“Zachman企业架构框架”和目前由Zachman国际公司拥有的行业标准框架，这里指的是1987年最初的“信息系统架构的框架”。

【2】图1中的Zachman框架是1992年的框架版本，不是最初的“信息系统架构的框架”。

【3】CIMOSA指计算机集成制造开放系统体系结构，PERA指普渡企业参考体系及方法学、GERAM指通用企业参考体系结构与方法学、ARIS指集成信息系统的体系结构、DEM指动态企业建模方法。

【4】FEAF同时参考了NIST EA Model，这是由美国标准研究院（NIST）研究。

【5】C4ISR全称为指挥（Command）、控制（Control）、通信（Communications）、计算机（Computers）、情报（Intelligence）、监视（Surveillance）和侦察（Reconnaissance）。

【6】TAFIM即信息管理的技术参考框架，Technical Architecture Framework for Information Management，是DoDAF中信息技术基础设施方面的一个参考模型，经美国国防部授权给TOG使用。

【7】MIT信息研究中心的主任，著有《企业架构如同战略》，阐述了企业架构在企业倡议和执行基础间的关键作用。

The Open Group的权威贡献：TOGAF

The Open Group于1993年开始应客户要求制定系统架构的标准，在1995年发表The Open Group Architecture Framework (TOGAF) 架构框架。历经15年9个版本发展，支持开放、标准的SOA参考架构，已被80％的福布斯( Forbes)全球排名前50的公司使用。ING保险公司、MIT麻省理工学院、英国工作养老金部门、SHELL石油公司、BP石油公司、 Kynetia保险公司、洛克希德马丁 (Lockheed Martin)、TESCO大型零售超市、Volvo汽车公司、CMU卡内基梅隆大学 、NEC等均在使用TOGAF。

附录

1．引自http://en.wikipedia.org/wiki/Main_Page中对于Zachman框架、企业架构框架、FEAF、TEAF、DoDAF的搜索

2．引自TOGAF 9，The Open Group，2009中Section 1.2，对于企业架构必要性的论述

3．引自《TOGAF口袋书V1.0》中对“架构”一词从《ISO/IEC 42010:2007，系统和软件工程-软件密集系统的架构描述的推荐做法，第一版》中的引用，《TOGAF口袋书V1.0》是TOG中国分会引进的TOGAF出版物，在国内尚未正式出版

4．引自TOGAF 9，The Open Group，2009中Section 34.2.2，企业架构元模型概览

5．MIT Center for Information Systems Research

6．SearchCIO.com

7．引自TOGAF 9，The Open Group，2009中Section 6.2，关于预备阶段使用的方法“关联各类管理框架”的介绍

8．Jeanne W. Ross，Enterprise Architecture as Strategy，Chief Architects Forum，January 8, 2007

UML、RUP和Zachman框架：完美结合（一）

在过去的十年，使用统一建模语言(UML)为软件应用程序进行建模的优势已变得日益明显。与此同时，RUP已经是一种经证明的软件开发过 程，Zachman 框架 1 是一种被证明的构架工件组织和通信的框架。在众多交叠的方法中，UML、RUP 和 Zachman 分别作为现代信息系统构架的三个重要支柱。这篇文章通过检验它们的元特性并提出一些将它们与组织结合的方法来考虑这些方法组合使用。

　　UML、RUP 和 Zachman 概要

　　根据定义，UML是一个建模语言。它试图将软件密集型建模系统的图形语言元素标准化。它的最新版本UML 2.0由用于结构建模、行为建模和交互建模的十三个图类型组成。毫无意义的是，虽然主要是为了面向对象(OO)的分析和设计，但UML可以在许多其他条件 下使用。例如，UML用例方法(如图1所示)本身不是一个OO过程，但它却已被证实为进行一般功能需求分析的最佳技术。其他UML图，例如交互作用、状态 和活动图同样也是我们经常用户描述真实世界项目情况的可用工具。

　　图1：UML用例图

　　关于 Zachman

　　构架框架是一种用来开发和维护较广范围构架的工具。当涉及支持企业里的定制企业构架(EA)功能时，Zachman 框架可以提供很多帮助。 2 它将企业主题分级成一个6x6的单元格矩阵，每个单元格代表每个组织的一个唯一视图(见图2)。

　　图2：Zachman 框架。    

   Zachman 里的列代表企业最重要的方面(数据、功能、网络、人、时间、动机)，而行不同，按照不同角度(规模、业务、系统、技术、细节、资产)和与一个方面相关的涉 众(计划者、业务所有者、设计者、实施者、子承接者)来划分。此外，行也因细节级别 3 而不同，因为它们是企业的抽象表达 4 (环境中的、概念上的、逻辑的、物理的、详细的和实际的)，这反过来可能与涉众和角度相连接来形成企业模型和职责的单元格。实例是：“一个系统模型(角 度)是一个 设计者(群体)职责范围一部分的合乎逻辑(抽象)的实体。”

　　三十六个框架单元格可以通过根据选择元特性描述企业的模型和工件来划分，例如方面、细节级别或者兴趣种类。框架并不规定要填充的单元格的符号或顺序，因为这一知识点已经超出了参考结构目标的范围。(后面的假设为创建使用 UML 和 RUP 框架的案例提供支持。

　　关于 RUP

　　过程可以被定义为“产生结果的一系列动作、变更或功能 ”。RUP 是一个过程框架(见图3)，它允许项目工作流程和任务被组织成为为最终目标为交付软件产品或解决方案的一系列动作。RUP 应该被裁剪以创建满足特定组织或者项目需要的过程实例和方法。

　　图3：Rational 统一过程    

    RUP 思想源于一个统一的系统的实现，这个系统通过使用 UML 符号来描述交付工件 6 。重要的是新的过程具有迭代的、以构架为中心的，以及需求驱动的特征，而这些特性是已有系统所不具备的。

　　自出现以来，RUP 已经从源于 Objectory 方法的软件工程过程发展为一个基于 UML 2.0 并由 Rational Method Composer (RMC)支持的用于裁剪过程的灵活的、可完全定制的平台。 7 例如，使用 RMC，一个熟练的过程工程师可以创建一个系统工程过程的实例， 8 定制其结构，从其他行业标准方法和最佳实践中添加需要的内容并且以超链接文本的形式产生一个备用的、适应组织或项目的过程实例。

UML、RUP和Zachman框架：完美结合（二）

集成的驱动力

　　根据前面的讨论，这三个系统中的每一个都被创建来服务特定的需求， 同时他们也都有缺乏对他们侧重领域之外的更广适应性的缺点。在许多组织里，关于 Zachman 框架我所注意到的一点是，表面上它是一个每个人都称好的巨大海报，但是没有人使用它。我将这一点归结于这样一个事实：与其它任何静态框架一 样，Zachman没有说明如何处理工件引入。另一个实用方面的缺点，通常被认为是优点，是框架缺少标准的符号。

　　更普遍的是，应用 RUP 的问题在于它作为软件开发过程的主要优势，然而这一点对构架师和开发人员等人是有吸引力的，但来自其他领域的人不会购买它作为主要技术。例如，项目经理会 选择其他的方法(比如，RUP 项目管理规程基于的项目管理知识体系(PMBOK))，并将 RUP 作为这些更有利的方法的一个附属物。相反，企业架构师通常选择 Zachman。

　　UML 在角色依赖关系上的问题稍微少一些，因为与 RUP 不同，它并不提出角色，因此没有方法映射的需要。尽管如此，过程和框架的也了UML的有效性。对UML来说幸运的是，尽管许多组织使用其他像实体 关系图(ERD)和业务进程建模符号(BPMN) 这样的结构方法和符号，但UML仍得到了普遍认可。

　　在尝试表达这些局限性以及为三种方法找到的共同的应用的过程中，要再一次注意的是它们被创建以表示同一个领域的不同的问题(信息系统构架)，而且它们 之前的目标设置实际上没有功能重迭(见图4)。对企业和项目构架师来说这都是好消息，因为那意味着 UML、Zachman 和 RUP 可以共同使用以产生更全面的企业价值。

　　图4：UML、RUP 和 Zachman 框架的功能重迭    

    关于交叉功能适用性的思考

　　RUP已经使用UML和其他像ERD这样的可视化建模语言以及像用例、业务角色和验收测试这样的非可视化建模产品。Zachman 框架并不与一个符号或一个过程结合，也不他们的选择加以。两种技术可以最佳使用的情况也是不同的。例如，由于其固有的不适应性，在开发环境中使用 Zachman 是值得置疑的。同样地，使用 RUP 作为一个企业信息构架的基础也未被证明是合理的。

　　在各自的生命周期定义之间的相似之处(比较上面的图2和图3十分明显)有助于解释这样一事实：RUP 和 Zachman 都是受工件驱动的并继承源于以构架为中心的设计原理的结构。明显的相似之处意味着假定企业系统和项目的复杂性不断增加，两个过程可能会互相强化。

　　这样已经在指出三种方法的不同之处方面进行了相当多的阐述，我将考虑正在探讨的方法在什么地方可以互相补充。

　　应用1：要为企业提供通用的符号，可以考虑 UML

　　通常情况下，为响应在管理上的“call for action”，组织直接将注意力投向 Zachman 来为企业的IT系统驱动“未来的”模型，或者针对一个非同小可的业务转型项目。在类似这样的场景中，架构师们将分散在跨越储存库的系统知识资产汇集起来 (这实际上是件正确的事情)只是为了了解到他们的前辈们生产出的工件并不能很好的适合 Zachman 结构。不适合的普遍原因是大多数现有的工件是至少几个不同方面的混合(还记得 Zachman 的列吗?)，另外一个原因是工件总是被使用不同的符号进行创建。而在大多数情况下，对工件进行式样翻新是不可行的，这些“经验教训”是与通用符号的重要性 相关的。您是否也正在思考我所考虑的事情?那好—— UML 也许能够帮助您解决这一难题。

　　Zachman 不限定也不推荐使用 UML 或者其他任何符号。然而， RUP 要求使用 UML。既然应该避免使用多样的符号，那么后面的论述将着重展示一个利用 UML 作为企业和项目架构的通用符号的情况。

　　应用2：使用 UML 将 Zachman 和 RUP 结合起来

　　在大多数组织里，当系统可能以某种形式存在很长时间的时候，例如 UML 起码已经有大约十年的时间，缺少标准的符号是可以理解的。即使在相对现代化的系统环境里，UML 也可能由于文档设计的时间和缺少必要的技巧设置等 原因没有被使用。

　　除了对于分析和设计需要良好的建模语言外，两个因素中任何一个都可能引发组织——一个RUP项目或者企业架构现代化成果——对 UML 的需要。任何一个理由都很好，因为它允许组织启用 UML。尽管如此，RUP 项目产生的结果可能要比从未来重用的角度而由构架现代化工作产生的结果更重要，因为RUP项目趋向于产生更加细化而且更加容易跟踪的工件。RUP方法的另 一个优点是，通常只生产真正有价值的工件。从另一方面来看，构架现代化成果可能会产生很多实用价值很小，而且带有不确定性的UML图。事实上，这种情况可 能会影响组织对UML的认可以及它在组织中的未来。

　　通过RUP驱动系统交付项目将UML应用到组织之后，它的用途可以扩展到以 Zachman 为基础的企业构架，没有减少它的需求的风险(见图5)。

　　图5：UML 连接 RUP 和 Zachman 框架

　　这一应用在过去已经尝试过很多次，而近期大多是在企业统一过程(EUP)环境中实现的。

　　应用3：从一开始就使用 UML

　　以我的经验来看，无论是为组织引入 RUP 还是 Zachman ，如果 UML 已经在组织中被使用，成功的可能性更大。图6 试图通过描述三个技术之间的依赖关系解释这一点。

　　图6：UML、RUP 和 Zachman 框架之间的依赖关系   

    正如我上面所陈述的，Zachman 和 RUP 都依赖 UML。RUP 专门由 UML 驱动，而符号未知的 Zachman 依赖其实现符号。UML可被证明是 Zachman 使用的最好符号，因为它不依赖其他方法，因此可以作为 RUP 和 Zachman 的出发点。此外，即使以后您决定不使用 RUP 或者 Zachman，UML 仍是一个十分有用而且易于理解的可视化语言，可用于全面分析、解决方案的分析和设计以及提高团队交流。

　　应用4：和 Zachman 一起学习 RUP(或者相反)可能更加容易

　　学习RUP需要理解它的结构和规程是如何服务于管理项目团队的。因此，学习RUP最好的办法是通过相关的项目经验或在有指导的环境中进行。为了获得这一经验，有必要在贯穿RUP生命周期的活动中扮演一定的角色。

　　正如在 RUP 实践中可以有许多 Zachman 方面可以与之并行，这样一个方法也的确帮助 Zachman 增加价值。例如，用RUP业务过程建模、用例和序列图来表示 Zachman“功能”，同样地，使用用例和UI设计来处理“人机交互”，使用类和对象图来处理“数据”。Zachman 结构的某些行与RUP 的需求驱动、递增和以构架为中心的原则是相通的，而列相当于一些UML模型和最佳实践的目标设置。例如，“如何实现”这一列重点强调处理过程，并可以与 UML活动图相比较。

　　可以证明，了解 Zachman 比了解 RUP 和 UML 更简单，因为 Zachman 处理的是企业系统构架的静态视图，而不是动态模型和过程。尽管如此，学习 Zachman 的方法可能主要受益于一些 RUP 主要原则——例如，“需求驱动”、“以构架为中心”、“模型驱动”和“迭代”——的应用。我的看法是当这些原则加入到学习过程和它的实际应用 时，Zachman 框架更容易掌握。

UML、RUP和Zachman框架：完美结合（三）

应用5：在 RUP 裁剪过程中，Zachman 作为辅助

　　在 RUP 裁剪过程中，工作的重点是在开发组织的结构上。角色、时间和职能是每一个这样的活动中要考虑的重要方面，要提出的问题包括：“在这个过程中谁来做构架建 模?”“过程建模何时发生?”“什么技术应该用于用途建模?”以及“应该如何基于详细级别划分职责?”。Zachman 具有固定的结构，可能恰恰是回答像这样问题的合适的信息来源。 10

　　尽管 RUP 中带有对工作流程的指导，但是它可能在真实的项目里并不适用或者只是部分适用。为了帮助过程工程师处理方法上的变化，IBM Rational 已经对 RUP 做了一些专门的扩展，例如“RUP for COTS”(商业现货软件)和“RUP for Systems Engineering”。为了在裁剪工作期间挑选一个合适的 RUP 变量作为基线，过程构架师必须了解组织的企业构架的现有的和未来状态。如果组织已经为企业构架分析/计划使用 Zachman，那么产生的框架可以提供有用的线索来选择正确的 RUP 变量。例如，相应的 Zachman 结构的业务模型(第二行)里的工件集合可能意味着重点是在业务建模上(见图7)并提示密切观注“RUP for Business Modeling”变量，而在网络一栏里的更高的工件密度暗示着 “RUP for SOA”(面向服务的构架)可能的角色。

　　图7：根据 Zachman 设计的工件分布  

    事实上，因为一些原因没有描述组织系统的工件或者没有与 Zachman 清晰的映射的情况是可能发生的。在这样的情况下，RUP 变量的选择可以围绕预期的辅助项目计划的工件分布来考虑。

　　应用6：RUP 项目结束后，可以由 Zachman 接替

　　从项目级到企业级(或者相反)转化系统工件的活动可能是十分痛苦的，因为它不能被很好地理解，也没有被很好的描述。虽然RUP部署规程有很多对将开发的系统移植到产品环境活动的支持，但是它不能涵盖围绕转换项目中创建的构架模型的活动。

　　这对RUP引入方面同样是适用的;在企业级别中，在启始和精化阶段并没有系统地讲述使用可用模型的活动。

　　既然RUP生命周期不包含企业构架规程，在RUP中就没有关于模型应该如何被项目接收、如何被向后转化至企业和系统被移植生产环境之后如何维护模型方面的指导。如果企业构架在RUP计划和和转化活动中被正式认可(事实不是如此)，那么这将不是上述情况。

　　有一个企业和项目构架师必须协同合作的局限性，Zachman 在这里要扮演一个角色——使项目构架工作具体化的框架。尽管每个组织将为连接企业和项目级别工件开发其自己独特的方法，但是一个共同的目标是将 Zachman 单元格与 RUP 的工作流和活动连接起来(见图8)。  不幸的是这些例子仅代表描述的一部分，因为他们只描述工件到表格的静态映射，通常不提供动态的阶段/迭代/活动事件方面的指导。

　　图8：RUP 与 Zachman 之间的工件的可追踪性(图解)

　　当RUP项目计划工作正在进行的时候，需要为连接工件引入一个容易操作的结构。最普遍的做法是复制RUP生命周期结构。我看见过许多设置的例 子，其中文件夹相当于迭代，下面的子文件夹通过规程来组织。这种方法有明显的缺点，因为项目结构只在项目存活时有关系，当项目结束后这种关系将立即消失。

　　Zachman 的例子可以在这一点上产生，因为它的主要结构可能用于在信息来源和文件管理工具里建立项目配置。更简单的实现可以使用文件系统文件夹复制 Zachman 结构。如果在RUP项目完成时，工件被移至已建立的档案中来连接 Zachman 结构，那么以后的企业和项目团队可以很容易得到它们。像这样的一个投资将有益于未来的RUP和企业项目，并使得企业构架更加清晰并具有可持续性。

　　应用7：在计划 RUP 项目时，考虑 Zachman 结构

　　如果您的组织已经根据 Zachman 已有组织的结构形式管理其工件，那么是一件不错的事情。如果不是，还是有可能从在建模活动和询查框架侧重的各个方面过程中从系统的评价 Zachman 结构中受益的。关于这个框架需要记住的一件事情是它是 John Zachman 和其他取得系统工程项目经验的人的集体智慧的结晶。因此 Zachman 不同的观点都是针对项目团队可能面对的许多相同问题(见图9)。

　　图9：RUP 计划中的 Zachman 元分析

　　Zachman 结构的一些方面通过一些公式化的问题，例如，什么、哪里、如何，来表述，这些问题对所有的项目类型来说是通用的，而且如果有必要，也可以转化成为针对特定 项目的问题。另外一些方面涉及关于系统构架提出的重要问题;例如“规则设计”可能会引出“解决方案将需要一个规则引擎吗?”这样的问题。其他像“实体=业 务事件类”或者“过程=应用功能”这样的表述可能传递特定技术的需要，例如模型驱动构架(MDA)或者业务过程建模(BPM)，这些可以在开发过程的不同 阶段被使用。

　　Zachman 产生的观点可能也在项目和迭代计划期间有帮助，不难想象“迭代评估”或者“开发风险管理计划”活动可能如何使用那些极好的方面。

　　当然，对于一些(特别是缺乏经验的)构架师来说，按照我所描述的方法使用 Zachman 听起来可能太混乱，而经验丰富的专业人员可能觉得对于他们自己的知识框架来说那是多余的。我仍相信大多数实践人员将会发现 Zachman 在他们的工作中是便利的分析参考资源。当为项目建立环境时，计划自身是一项重要的任务，它通常不是很难，而且对项目和组织来说都很有价值。

　　应用8：结合使用 Zachman 与 RUP，来帮助架起企业和项目构架之间的桥梁

　　许多开发组织的一个共同特点是在感知到复杂的事物蔓延之前忽视企业构架。大多数组织尝试通过引入企业构架实践并要求其处理跨系统和跨项目的问题的办法 来解决这一问题。这一方法可以帮助管理项目生产的工件，而同时通过使项目拥有公有的企业模型来减少业务风险。最后也是最重要的一点是，企业构架实践将鼓励 企业和项目团队之间的相互作用，这将使得他们彼此受益。

　　通常情况，企业和项目构架之间在他们各自的影响领域会有冲突发生，全部归结为什么工件(是否是UML)最好地代表企业系统、什么团队创建了它们以及如 何维护和使用它们。如图10所示，当工件从被创建(在开发项目或者其他企业项目的时候)，再到随后的使用，最后到工件不再被需要(可能在退出系统之后)的 生命周期可以被清楚的跟踪时，可以达到构架透明度的最终水平。RUP 和 Zachman 的结合覆盖了工件生命周期的重要部分，这可以帮助组织实现一个统一的、完全透明的构架的重要益处。

　　图10：工件的生命周期

　　总结

　　作为他们各自领域的领导者，UML、RUP 和 Zachman 框架可以在任何组织同使用以产生更加全面的构架价值。RUP 和 Zachman 都是模型驱动的并需要某种符号来实现功能。既然 RUP 规定 UML 作为其符号，那么对于企业构架来说，使 UML 作为标准化的符号可能更加有意义，因为通常情况下，它没有任何缺点。

　　虽然 RUP 和 Zachman 都依赖模型，但实际上它们没有功能交迭。这主要是因为 RUP 是一个过程，而 Zachman 是一个框架，但是也反映了 RUP 以项目构架为目标，而 Zachman 的重点是在企业组织上。

　　既然 RU P和 Zachman 都可以依赖 UML，后者是三个方法中先要引入的首选方法。将 RUP 应用于 Zachman 或者相反，有助于更全面的学习经验。

　　使用 Zachma 将现有的工件分类或者只是提及 Zachman 结构和规程使得裁剪 RUP 更加简单，因为它引起了关于对开发组织重要的角色、工件、工作流程和活动的思考。

　　项目计划成果也得益于对 Zachman 的应用，因为它可以很快地使您得到需求收集或分析/设计中可以用到的工件。即使在没有连接到 Zachman 工件时，Zachman 结构本身仍是非常有帮助的，因为在项目反映的业务问题上它提供了各种有用的观点。

　　一个组织几乎必然将从支持企业构架和其项目之间的工件可追踪性中受益，这种可追踪性可以通过建立对一个工件从创建到结束的生命周期的控制来取得。通过这种方法，RUP 和 Zachman 都可以被应用于管理工件。

　　最终的思考

　　当要创建灵活的和可维护的解决方案的时候，项目和企业团队应该协同合作。项目成员应该了解更广泛的企业环境，而他们对应的企业必须不断地监控项目以保 持知识是最新的。在 RUP 和 Zachman 中结合应用用例可以帮助缩小企业与其项目之间的差距，从而使得组织更加有效。最后，那就是所有的一切。