[萧百龄]乐见SOA和EA融合之势

ZDNet软件频道 时间:2009-02-04 作者:萧百龄 | CSDN 我要评论()
本文关键词:EA SOA 萧百龄
观察过去一年 SOA 在美国的发展,一个愈来愈明显的趋势是,SOA 和传统 EA (Enterprise Architecture;企业架构) 领域逐渐在协作和融合。

  观察过去一年 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(常见翻译包括:治理、管控、督导、监管)。由此可看出,EASOA 有着相同的总目标 -- 让业务和 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 的炒作和杂音,似乎只让问题更为加剧。这是个非常有趣的话题,因为 SOAEA 带来的关键价值,我认为其实正在于此 -- 表面上看,“服务” 的确是个模糊的概念,从业务人员、架构师,到程序员,各自对“服务”的解读,都不相同;但这恰好是 SOAEA 、传统面向应用的需求管理,和项目交付方式,所带来的最大价值。“服务”概念的出现,其最大意义,在于提供了我们一个能贯穿从业务需求、架构规划、项目交付,一路到上线后的运营监控的统一概念 -- 一个具有很长的生命周期、能够全程管理的单元。业务功能能通过“服务”来沟通,并且针对个别服务,制定契约来规范它的功能,以及效能指标、安全要求等非功能性需求。用扎克曼层次化的概念来看,尽管“服务”在各个层次所着重的内容不同,但最终是个统一贯穿的概念;更重要的,是它跨越了传统 EA 和项目交付两大迭代,让 EA 所规划出来的模型和规范,能真正贯彻、落实到项目的执行,甚至于上线后的生产运营,和监控管理(第三个迭代),将绩效反馈给业务的 stakeholder,形成一个能不断迭代精炼的闭环。这是 SOA 概念及方法论给 EA 和传统面向应用的需求、项目管理方式,所带来最大价值。

 文章引用自:  

  Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1801103


百度大联盟认证黄金会员Copyright© 1997- CNET Networks 版权所有。 ZDNet 是CNET Networks公司注册服务商标。
中华人民共和国电信与信息服务业务经营许可证编号:京ICP证010391号 京ICP备09041801号-159
京公网安备:1101082134