“企业架构”一词，是对英文 Enterprise Architecture, EA 的翻译。老一些的习惯也译为“企业体系结构”。在企业工程之屋0.92版我将其列为企业工程的五大支柱之一。国外IT行业巨头例如IBM，近些年似乎开始真正拣起、重视这个概念，在企业应用战略性框架的描述中，EA与BPM、 SOA一起，成为并列的三大要素。国内企业应用领域的一些大企业，也开始运用这个概念。对这个概念的基本背景和内容，网络能找到不错的介绍[注1]，这里就不赘述了。
一个信息系统或IT应用的概念
一般认为，企业架构的概念还没有大家公认的、一致的定义。可以留意，John A. Zachman 1987年的开创性工作，题目是“企业及信息系统架构的框架”（the Framework forEnterprise Architecture and Information Systems Architecture）。1997年，Zachman总结了十年间的研究和实践，提出了扩充的、更完整的框架，并改称为“企业架构框架”（Framework for EnterpriseArchitecture）。这是一个十分重要的改变，但可以说其目的迄今仍未达成，类似的意见，也来自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 GroupArcuitecture 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-RefrenceArchitecture）等为基础概念。企业工程的基本立场，是把关于企业整体的、一般性的表示（描述，即建模）和方法学、建设/改变的准则等，综合归纳起来，作为一个系统化、知识化的，以企业为目标的实践、研究、技术应用的领域，现有的企业架构方面的实践、认识，是目前企业工程可以包括的实质性内容中最重要的方面之一。
企业架构（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 Systemsand software engineering — Recommended practice forarchitectural description of software-intensive systems，系统和软件工程-对于软件密集型系统体系结构描述的指南
[注7]ISO 15704:2000Industrial automation systems — Requirements forenterprise-reference architectures and methodologies 对应国标为GB/T 18757-2002 工业自动化系统企业参考体系结构与方法的需求
补充说明：相关领域关于“巴比伦塔困境”比喻比较有影响的例子，是用来说明企业建模领域存在许多不同的企业建模语言和工具，相互之间却很难沟通，缺乏互操作性的问题。这是欧洲企业建模学术研究领域的关注点之一。近年的一个重要项目统一企业建模语言（UEML）的主要目的之一，就是针对这个问题。
