观察过去一年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和传统面向应用的需求、项目管理方式，所带来最大价值。