观察过去一年 SOA 在美国的发展，一个愈来愈明显的趋势是，SOA 和传统 EA (Enterprise Architecture；企业架构) 领域逐渐在协作和融合。不久前，美国知名的 SOA 顾问大卫·林锡肯，David Linthicum 在一个由 The Open Group 主办的大会上预言：五年后，大家将不再像现在这么看待 SOA，因为 SOA 将逐渐融入 EA，变成只是 EA 实践中的一部份。此话一出，引发各方激烈的讨论。
对于绝大多数 IT 从业人员来说，"EA" 一直是个模糊而遥远的名词，尽管它已经悄悄存在约二十来年了（这点，从 EA 相关书籍数量之少，便可看出）。在许多世界五百强、一千强的大企业中，尽管在 IT 中存在着 EA 的组织，但这些架构师在组织外的其他 IT 同事眼中，往往是一小撮象牙塔里的文书官僚 (paper-pushers)，对于他们实际的工作内容，往往非常陌生，也不关注；许多项目实施团队，对于 EA 架构小组所制定的各种标准和规范，甚至采取 “上有政策，下有对策” 的态度。
要正确了解什么是“企业架构”？首先必须先对 “Enterprise”、即“企业”有一个清楚的界定。制定 EA 规范的机构 The Open Group，对 “Enterprise” 所下的定义是：
若干个组织的集合体，具有共同的目标和/或单一的财务底线。
一个企业可以是：
- 一个政府机关
- 整个公司
- 某公司的一个分支
- 一个单独的部门
- 一个组织链，所有权同属于某群人/组织
- 一个“延伸型企业”，其中包括伙伴、供应商，和客户，以及内部的业务单位
由此可见，EA 架构方法论，对“企业”适用的范围，相当具有弹性。不过，任何企业或组织在实施 EA 之前，应先在宪章中，对 “企业” 的范畴，有清楚的界定。必也正名乎。
把 EA 中的 "E" 交待了以后，我们可以把 EA 简单定义为：一套管理企业 IT 转型计划和变革的一连串动态过程和方法论。它为企业提供一个何去何从的地图，为业务和 IT 变化提供路线，计划，和蓝图。作为一个专业科目，EA 的任务在通过架构督导和治理，来促成业务和 IT 的紧密配合。
在这里，我们看到一个在 SOA 领域不断出现的关键词 -- governance（常见翻译包括：治理、管控、督导、监管）。由此可看出，EA 和 SOA 有着相同的总目标 -- 让业务和 IT 更紧密地配合 (alignment)，以 IT 作为重要的竞争工具，进而达成企业的战略目标，包括为客户提供更好的服务、提升客户满意度，进而为股东创造最大的价值。至于 SOA 究竟为 EA 带来什么样的新思维和新方法，稍后再来谈 。
上面对于 EA 的解释，比较抽象。我们可以进一步用城市规划 (City Planning) 来比喻：EA 要做的工作，就是一个城市的整体规划，具体的工作和内容，涉及多几种角色，包括市政府领导（业务拥有者、stakeholder）、建筑师（架构设计）、土建包商（项目管理）、专业施工团队（程序员）。大家都知道，软件设计有许多灵感来自可重复套用的建筑模式 (Design Patterns)，被 Gamma 等进一步体系化，一转眼已经走过一轮生肖了；其实 EA 甚至更早便从建筑中得到灵感，例如著名的 Zachman （扎克曼）框架体系，正是受建筑和航天工业的启发，这是二十年前的事了（注："ch" 在此发 /k/ 的音，美国著名的投资银行 Goldman Sachs，和一家大银行 Wachovia 名字中的 "ch"，也是相同的发音）。扎克曼以建筑作比喻，让规划者能将复杂的企业架构内容，分解成水平六层不同的视角来分析，就像前面比喻的城市规划，市政府领导、建筑师、包商，和施工队成员，各层有各层关注和需要的信息；在纵向的维度，再根据六大问句来切割 -- What（数据）、How（功能）、Where（网络）、Who（人、演员）、When（时间、事件）、Why（动机）-- 来一一整理出不同层面的架构信息。扎克曼提供了一个很好的逻辑分类结构，来描述企业信息化的方方面面。
除了扎克曼架构外，其他几个最主流的 EA 架构，包括 The Open Group 的 TOGAF（The Open Group Architecture Framework；读作：偷盖夫）、美国联邦政府的标准架构 FEA、美国国防部的 DoDAF。
TOGAF 的主干是一个包括业务、信息、应用，和技术架构的四维模型：
- 业务架构：定义业务战略、业务驱动因素、治理 (governance)、组织结构、角色定义，和重要的业务流程
- 信息/数据架构：描述一个组织的逻辑数据模型、物理结构，和数据管理资源，包括数据的规类、与业务应用的关系、数据的使用和管理策略等
- 应用架构：对要部署的应用系统，提供一个蓝图，应用间的相互关系，和他们与核心业务流程之间的关系
- 技术架构：描述用来支持业务、数据、应用服务部署的基础设施能力，包括中间件、网络、通信等软硬件，及相关的平台和技术标准等
TOGAF 提供一套详细的方法过程（称作 ADM; Architecture Development Method），依据业务需求，来指导企业架构的开发。ADM 和 Zachman、FEA
等框架间没有冲突或矛盾，而是为所有的框架，提供一个从收集、记录现况，然后制定未来蓝图愿景，再分析鸿沟，并制定如何填满鸿沟的计划；一个自上而下的规划过程。
看到这里，可能有人会问：EA 工作如果做得好，规划出来的项目都能一一落实，是不是就不需要 SOA 了？换一个角度问，SOA 是否给传统 EA 领域，带来什么新的理念和方法？
前面一开始提到，多年下来，许多企业的 EA 组织，在一般 IT 同事的心目中，往往是一群定标准规范、做 PPT、画蓝图，定架构发展路线图的理论家。换句话说，EA 规划和项目的执行成效，落实与否之间，往往有一个断层。在许多企业中，EA 的角色，最后往往流于只是在制定软硬件采购标准这类的工作。但制定标准规范这件事本身，并不能使业务更加敏捷灵活（应该说只有比较间接的帮助），而这样的贡献，更是很难订出指标来衡量其绩效；在这样的恶性循环之下，EA 的 ROI 很难得到充分的支撑。
有人批评 SOA 的 “S”，认为到底什么是“服务”，已经说不清楚了；而这两年市场上关于 SOA 的炒作和杂音，似乎只让问题更为加剧。这是个非常有趣的话题，因为 SOA 给 EA 带来的关键价值，我认为其实正在于此 -- 表面上看，“服务” 的确是个模糊的概念，从业务人员、架构师，到程序员，各自对“服务”的解读，都不相同；但这恰好是 SOA 给 EA 、传统面向应用的需求管理，和项目交付方式，所带来的最大价值。“服务”概念的出现，其最大意义，在于提供了我们一个能贯穿从业务需求、架构规划、项目交付，一路到上线后的运营监控的统一概念 -- 一个具有很长的生命周期、能够全程管理的单元。业务功能能通过“服务”来沟通，并且针对个别服务，制定契约来规范它的功能，以及效能指标、安全要求等非功能性需求。用扎克曼层次化的概念来看，尽管“服务”在各个层次所着重的内容不同，但最终是个统一贯穿的概念；更重要的，是它跨越了传统 EA 和项目交付两大迭代，让 EA 所规划出来的模型和规范，能真正贯彻、落实到项目的执行，甚至于上线后的生产运营，和监控管理（第三个迭代），将绩效反馈给业务的 stakeholder，形成一个能不断迭代精炼的闭环。这是 SOA 概念及方法论给 EA 和传统面向应用的需求、项目管理方式，所带来最大价值。