Zachman企业架构框架简介.docVIP

谈谈企业架构（EA）一摘要：企业架构（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官方文档注6ISO/IEC 42010:2007 Systems and software engineering Recommended practice for architectural description of software-intensive systems，系统和软件工程-对于软件密集型系统体系结构描述的指南注7ISO 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同时承认每个角色均关注相同的信息类别（维度），即下表各列内容。 数据（什么？） 功能（怎样？）网络（哪里？）角色（谁？）时间（何时？）动机（为何？） 目标范围列出对业务至关重要的元素列出业务执行的流程列出与业务运营有关的地域分布要求列出对业务重要的组织部门列出对业务重要的事件及时间周期列出企业目标、战略 业务模型实体关系图（包括M: M关系、N-ary关系、归因关系）业务流程模型（物理数据流程图）物流网络（节点和链接）基于角色的组织层次图， 包括相关技能规定、 安全保障问题。 业务主进度表业务计划 信息系统模型数据模型（聚合体、完全规格化）关键数据流程图、 应用架构 分布系统架构人机界面架构（角色、数据、入口）相依关系图、数据实体生命历程（流程结构）业务标准模型 技术模型数据架构（数据库中的表格列表及属性）、 遗产数据图系统设计： 结构图、伪代码 系统架构（硬件、软件类型）用户界面（系统如何工作）、 安全设计“控制流”图（控制结构）业务标准设计 详细展现数据设计（反向规格化）、物理存储器设计详细程序设计网络架构屏显、安全机构（不同种类数据源的开放设定）时间、周期定义 程序逻辑的角色说明 功能系统转化后的数据可执行程序通信设备受训的人员企业业务强制标准 编辑企业架构的信息类别 数据（什么？） 功能（怎样？） 网络（哪里？） 时间（何时？） 角色（谁？） 动机（为何？） 编辑企业架构理论术语 “企业”（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服务台的一个功能，我填写了一个问题，但是没有回复，估计这个功能就被打入冷宫了，这样满意度也就会下降了。 通过企业架构，我们可以达到： 企业内不同的人要对企业现状（asis）和企业愿景（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”，表现为一个35的矩阵。1992年，他与John F. Sowa合作发表了扩展的框架方案，名称没有变，但将涉及范围推广到所谓“工程化的企业范围”（”engineered” enterprise-wide），引入了6个基本疑问词（5W1H）作为横向展开的依据，整个框架表现为65的矩阵。这期间人们也开始用“Zachman框架”这个名字直接称呼它。1997年，初次发表10年之时，Zachman再次发表新的论文“Concepts of the Framework for Enterprise Architecture”，在概念上，完成了由信息系统架构框架向“企业架构框架”的正式转变。在随后几年，在框架的细节、单元内容细节等方面持续有改进，矩阵图也变化了好几个版本，但主体结构和内容基本稳定。2008年推出了正式简明定义和框架标准。后面的介绍主要基于这些信息。正式简明定义下面是Johan A. Zachman对的正式简明定义：Zachman框架（Zachman Framework）是一个纲目（schema）两种有几千年历史的分类法的交集。第一种是建立在原始疑问词上的沟通基础要素：什么、如何、何时、何人、何地以及为何。这些问题答案的集成，能够对复杂的想法形成全面、综合的描述。第二种来自具体化，即古希腊哲学中假定的抽象观念到实例的转换，在Zachman框架中记为：辨别、定义、表达、规定、配置和实例化。Zachman说，框架分类的最初启发是来自对建筑、飞机和其它复杂的工业产品的观察经验。对于上述定义，他还强调，Zachman框架是一种描述企业的本体，是元模型，而不是关于创建对象的最终实现（实例）的方法学。它是关于结构的，而不是过程。它是企业架构（EA）的基础。基本结构Zachman框架是一个综合性分类系统。它相当于通过66的分类矩阵，把企业架构涉及的基本要素（而不是企业本身）划分成36种单元（Cells），并清楚地定义了每个单元中的内容（组件、模型等）性质、语义、使用方法等。从相关介绍可以知道，在找到现在这种二维矩阵的划分方式之后，对每个单元的内容也在逐步认识、实践和总结。考察现在的标准叙述，仍可以感觉到，单元的内容和单元间的关系，远不像架构的整体方案所暗示的那样明确、直观。标准中对多单元上用法说明，有些也并非显而易见。这一方面体现在这个表面简单的结构中，还蕴藏着不少“道理”，同时可能也说明，这里还有不少可以探讨的空间和不同的可能性。详细的分类矩阵，可以由其网站上看到。5W1H的描述展开，看来“非常基本”，似乎只有用或不用的选择，但并非没有讨论余地，特别是，如果站在企业规划、建模、模型工作机制这样一些角度上，会更有多的讨论空间不仅是关于5W1H这一方案的选择，而是在更深的层面上（参见后续的分析文章）。相对于行的展开，按照“具体化”层次展开的列，则更需要仔细考察。下表将Zachman提示的具体化标志与实际矩阵上的标签对应起来，以便于观察。同时，对照列出了“Who”这一列单元格里的基本提示。单元格里放的东西，前五层都表现为模型（或文档），而最底层是实例。Zachman具体化标志在他的企业架构框架上的体现具体化层次矩阵左侧标签矩阵右侧标签单元举例（“Who”列）Identification辨别Scope Contexts范围语境Strategists as Theorists战略家，相当于理论家名称：组织识别/边界列表组件：组织类型/类型定义说明：列出业务上重要的组织Definition定义Business conceptes业务概念Executive Leaders as Owners执行领导，相当于所有者名称：组织定义/语义模型组件：组织角色、组织工作说明：工作流模型Representation表达System Logic系统逻辑Architects as Designers架构师，相当于设计者名称：组织表达/图解（Schematic）模型组件：系统角色、系统工作说明：人类界面架构Specification规定Technology Physics技术物理学Engineers as Builders工程师，相当于建造者名称：组织规范/蓝图（Blueprint）模型组件：技术角色、技术工作说明：呈现（presentation）架构Configuration配置Component Assemblies部件组装Technicians as Implementers技师，相当于实施者名称：组织配置/清单组件：组件角色、组件工作说明：安全架构Instantiation实例化Operations Classes操作类Workers as Participants工作者，相当于参与者名称：企业组织实例组件：组织角色、组织工作说明：实际的人和它们的工作（表中内容参考Zachman框架标准2.01版）从现有的单元格内容和关联的解释看，这个表面简单的“正交”二维分类矩阵，每一个交点（单元）上对应的到底应该是什么，并非显而易见，或许有许多值得探讨的可能性。而从现在所给出的方案看，这两个维度也许并非如矩阵图所暗示的那样，完全是简单正交的。纵向的具体化层次划分，表面上看似乎经验性的色彩较为浓厚，但结合其所给的各列内容方案，能够体会到，其中的蕴含还是相当深的，正如它十几年发展已经体现的，一方面有很多经验性的、实践的支持，一方面也是得来不易，很有参考价值。这个分类矩阵的行、列选择，的确相当基本，显示出某种“本质划分”的特点，但也并非没有争议。以后我们将对此进行讨论。如果我们按照这个框架本来的定位作为一种企业架构/工程的描述性逻辑结构、分析框架去使用，它无疑是非常有启发性的一种基础性工具，一旦超出这个范围例如，用来指导实际企业的企业“架构”开发，甚至企业建模，就可能会遇到很多具体的问题。结语本来准备从以前的笔记中摘录做一个浅析，到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