企业在实施SOA时,是从总体规划起步,全面实施呢?还是从项目开始,逐渐扩展?BEA公司的建议是采取“中间相遇”的策略,达到降低风险、快速获得投资回报的目的……
面向服务的架构(SOA)已经在全球的信息化建设进程中掀起了一波行动浪潮。Gartner的一份报告显示,到2008年,SOA将为80%的新开发项目提供实施基础; 到2010年,应用软件收入增长的80%将来自基于SOA的产品。
SOA提高快速响应能力
对所有企业而言,提高竞争力的关键是提高业务敏捷性及快速响应市场需求变化的能力。然而,业务敏捷性取决于企业信息的自由流动、服务和业务流程。对大多数企业来说,其IT系统一般都具有异构本性,这就使得这种流动陷入困境。许多平台和技术都要求IT硬编码点对点连接,这妨碍了信息的快速流动,减慢了新业务服务的交付。
于是面向服务架构(SOA)这种旨在流线化服务交付的IT策略出现了。SOA的根本目标是通过把企业应用系统中的分散功能整合成可操作的、基于标准的服务,使其能被重新组合和重用,从而快速满足业务需求的变化,实现IT对业务提供最佳支持的终极目标。从这个意义上说,SOA是一种立竿见影的企业IT战略,它能够对企业业务的改变做出迅速响应。
我们可以这样理解SOA:它在各个不同的系统之下建立一个新的中间层,用这个中间层联系各异构系统,从而在资源重用的前提下整合原有系统。SOA将应用拆解成一个个“插”在SOA标准平台上的服务元件,这些服务元件可以迅速组合、配置及重用。
看看不同行业的用户通过实施SOA取得的成就,就能看到SOA的前景:在电信行业,SOA为四网合一和3G时代的到来创建服务交付系统; 在金融服务业,SOA为顾问们提供了统一视图,帮助他们了解客户; 在医疗业,SOA正在改变使用病历卡的方式……这些越来越多的成功应用,让世界各地用户部署SOA的愿望变得越来越强烈。
“中间相遇”策略
尽管SOA带来的好处是显而易见的,但如何实施,才能获得最佳效果呢?
有些企业在推进SOA实施时采取的是“自顶向下”的方式,即从企业的战略开始,逐步向下展开; 另一些企业则采用了另一种途径,就是“自底向上”的方式。这里所说的“自底向上”,并不是说由底层的技术推动业务,而是说,从小的项目开始做起,积累经验,然后做大项目,最后上升到战略层面。
然而,无论是“自顶向下”还是“自底向上”,这两种SOA实施策略都各有利弊,很难达到理想的效果。
“自顶向下”是企业实施SOA战略性的策略,其核心思想就是从企业层面做SOA实施的整体规划。它的好处是从企业整体进行考虑,面向业务,企业可以根据其业务的发展情况以及现有的IT情况做一个SOA实施的整体规划。这样可以推动整个企业的标准化,所有的服务模块都基于相同的标准,方便今后的重用。但是它的风险也不小:一方面是范畴涵盖大,周期长,初期的投资大; 另一方面是它要求整个企业要有比较高的纪律和技能,有一套完整的组织架构和管理流程。
“自底向上”的实施办法则是战术性的,它强调从小处着手,从一个部门级应用开始实施SOA。这种方法的好处是见效快,风险小,初期的投资也不大。不过这种实施方式的弹性相对比较差,特别是当企业需要在更大层面实施SOA时,可能会产生一些衔接问题。
结合多年来帮助客户成功实施SOA的经验,BEA提出了一种更加切合实际的SOA实施策略,这就是“中间相遇”(meet in the middle)的实施策略。BEA认为,在SOA的实施中必须结合“自顶向下”和“自底向上”的方法,寻求两者之间的结合点,才能最有效和成功地实施SOA。因为对绝大多数企业或组织机构来说,在业务系统实施的初期,存在很多不确定性,包括业务需求和项目所选择的开发技术、平台等都存在不确定性。遵循“中间相遇”的原则,业务人员和开发者都各自循序渐进地做事,在过程中不断沟通,这样就能够使得业务的改变得到最快的响应,并且不会影响开发效率,最终两者能够在某一点相遇,从而搭建起符合需求的系统。通俗地说,“中间相遇”的原则就是我们常说的“大处着眼,小处着手”,在做一个一个项目时,并不仅仅把眼光局限在正在进行的项目,同时也兼顾企业IT系统和业务发展的整体规划。
如何遵循“中间相遇”
首先我们来分析项目1和项目2。虽然这两个项目都是从底层编码开始实施,但是项目参与者已经有意识地在用SOA的思想去做,并且在遵循按服务契约设计的实施方式。在这里,项目1和项目2的选择是一个很重要的问题。由于是处于尝试阶段,前两个项目通常会选择比较紧迫、能体现一些用户需求、并且能够体现SOA优势的项目。项目1和项目2尽管都是从编码做起,但不完全是自底向上地做,而是遵循一种“中间相遇”的思想,这也是BEA及其他SOA领先厂商通过实践总结出来的比较安全的推进方法。从项目3开始,参与者就开始有意识地构建那些重要的服务层以及相关的管理控制策略,以形成企业资产。前两个项目中的服务,在后期的项目中被重用的几率可能有一些折扣,但是在实施的过程中,可能已经体现出了SOA的优势,如此一来,很容易博得企业决策层的认同,进而支持项目3的推进。
项目3是非常关键的环节,在实施过程中,需要形成一些涉及到战略层面的管理知识和规则。从项目3开始,就要抽象出一个服务层来:即需要在业务层和技术层之间增加一层服务层,以弥补业务与技术之间的鸿沟。也正是由于服务层的形成,能够保证在技术的跳变时不会直接影响到业务需求。
开始做最初的SOA项目时,我们会先解决比较急迫的业务问题,然后根据这些业务问题用SOA方法,如分层的结构、ESB结构,实施一两个项目。此时要尽量具体着眼于项目本身对具体业务的价值。实施完这两个项目以后,就能给整个组织带来信心,尤其是管理高层。随后,就考虑引入一个管理SOA的规则,把前两个项目总结的经验和包装的服务标准化,尽量在后面的建设中应用,即引入SOA管控。所以,这是一个循序渐进的过程。但我们在做第三个项目的时候就不再自底向上,而是开始从SOA实施小组管控中心的规则和最初的两个项目达到磨合,而产生了服务的中间层,包括服务本身具体的架构。
今天,已经有一些欧美的企业利用“中间相遇”的策略,成功地实施了SOA,并获得了预期的收益。对中国企业来说,尽管其业务系统与欧美企业相比有一定的特殊性,但在实施SOA的过程中,“中间相遇”的策略同样有效—从投入少、见效快的项目入手,逐渐推进到整个企业范围,最终完成SOA的实施。
我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。
我原创,你原创,我们的内容世界才会更加精彩!
【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号
TechTarget
官方微博
TechTarget中国
相关推荐
-
事件驱动框架和SOA在空军的应用
空军正在利用SOA来改善数据共享,并实时跟踪战机,美国空军机动司令部的Michael Marek解释了企业可从中学习的经验。
-
揭秘New Relic APM技术细节
New Relic应性能管理(APM)套件主要用于Web软件开发。它允许用户在面向服务的架构(SOA)上跟踪关键事务性能,并且支持代码级别的可见性来评估特定代码段和SQL语句对性能的影响
-
仅凭SOA和云无法解决业务数据管理风险问题
SOA和云可以是某些恼人问题高效的解决方案;这一点我们已经知道了。但是也要记住它们并不是所有事情的直接答案,特别是当你的问题是业务数据管理风险,而不是技术问题时。
-
购买应用集成工具可以采取平衡做法
购买应用程序集成工具需要好好看看你的公司需求,知道从供应商里面要寻找哪些关键功能。