e-works数字化企业网  »  文章频道  »  企业管理  »  经理人

浅谈:SOA实施之前 CIO应做些什么?

2006/7/8    来源:赛迪网-中国计算机报    作者:汪蔚  郝峥嵘  郭莹      
关键字:SOA  CIO  实施  
在众多IT厂商的推动下,SOA成为一个家喻户晓的概念,在SOA实施之前,企业的CIO们应该做些什么?

    第一步 判断

    “上不上SOA呢?”这是国内某保险公司信息中心王主任犹豫不定的事情。最近王主任注意到,几乎天天都有媒体报道SOA,上门游说SOA的厂商也是络绎不绝,但他对于怎么判断公司现有系统是否适合上SOA这个问题有点拿不准。尽管他对SOA很是动心,依然迟迟没有下定决心。

    在众多IT厂商的推动下,SOA成为一个家喻户晓的概念。俗话说,世界上没有两片相同的树叶。同理,每个企业的IT系统都是独特的。即使SOA是个好东西,也不见得就是一剂包治百病的灵丹妙药,就能够适合所有的企业。另外,还有一个不容忽视的话题是,很多来游说的厂商都不能解释清楚什么是面向服务的架构。面对波涛汹涌的SOA大潮,作为用户,首先要判断的就是自己企业的IT系统是否适合SOA。

    在这个客户就是上帝的时代,银行、保险等企业面临的迫切需要就是整合为客户提供的多种服务。通常,不同的服务是由企业不同IT系统支撑的,整合服务就需要集成各个不同的支撑系统,然而,集成的高昂成本让许多企业望而却步。SOA正是在这样的大背景之下应运而生的。简单地说,SOA是一种拥有很多大小不同、功能各异的应用组件的软件架构,它可以根据需求通过网络对各种应用组件进行分布式部署、组合和使用,从而满足用户统一服务界面、快速部署新业务等需求。服务层是SOA的基础,可以直接被应用调用,从而有效控制系统中与软件代理交互的人为依赖性。

    可见,在异构的系统妨碍企业为客户提供整合服务时,SOA才能更好地发挥优势。对于某些企业来说,IT系统并没有这样的问题,实施SOA的优势会受随之而来的负面影响而打折扣。

    对于一些企业来说,采用了单一厂商的技术和产品,拥有同构的IT环境,实施SOA就并不显得那么急迫。但是,当企业需要通过信息系统和合作伙伴建立更紧密联系时,SOA就是解决跨企业平台不可避免地会遇到的灵活性问题的良好途径。

    实时或被动系统也不是实施SOA的最佳选择。SOA依赖异步通信模式实现服务提供者与服务消费者之间的松耦合,对大量并发的实时系统并不支持。当然,对不同企业来说,实时的内涵并不相同,对SOA也就有不同的判断。

    当一切运转正常,信息中心主任也没有必要自作聪明去尝试SOA。尤其对于早早就使用了应用系统的金融行业来说,很多年前就已经成形的业务支撑系统,虽然经过了很多次修修补补,但是一直在正常运作。这种系统,轻易改变架构会是一件“不可完成的任务”—结构老,补丁多,又肩负重任,与其对它再做大手术,还不如等这种系统寿终正寝,重新开发符合SOA架构的新系统,进行自然淘汰比较好。当然,市场竞争激烈,业务人员可能随时要求改变企业为客户提供的服务,对系统修正、升级是必不可少的。

    有了这样一番分析,王主任对是否该上SOA的认识比较清晰了。对他来说,目前最重要的核心业务系统是核保系统,这是很多年前建设的,当时还是使用C/S结构开发的,现在修修补补一直在用。除此之外,还有一些新系统,比如数据挖掘等系统是最近两年做的。王主任深知,在金融行业中,保险业开放最早,竞争也最为激烈,为用户提供更好的服务是必然的趋势,SOA也是必要的。但是,他考虑到,现在就在核心系统——核保系统上尝试SOA的话,成本太高,风险也很高。再者,公司高层也在考虑换核心系统,还是等等看吧。而数据挖掘系统不一样,是新上的系统,本身就是三层架构,向SOA进军条件比较成熟。那就先拿数据挖掘作为SOA的试验田吧。
   
    第二步 算账

    对于一个保险公司来说,核心业务系统的SOA建设是伤筋动骨的事情,慎之又慎很正常。但是,这并不意味着所有的系统都不能上SOA。恰恰相反,鉴于所有的系统都早晚要SOA,因此从很多新建系统或边缘系统练手是最容易想到的事情。

    对于很多用户来说,上SOA要算好投入产出账。尤其对于那些预算有限,很多系统要上线的用户来说,如果没有充分的理由,又不能核算投入产出比,上SOA会面临很多问题。对于用户来说,在算经济账时有四点要注意。

    首先要有充分的规划。如果仅仅是对现有系统进行整合,或者将服务构建在新的分支机构上,而不是通盘考虑,往往会导致单项计划的成本迅速增加,甚至导致失控。SOA是一项长期的工程,而在项目初期要明确哪些目的是要达到的,哪些目的是下一次才能实现的。最忌讳的是,在项目开始时设计了一个大而全的目标,结果实施越久发现需要解决的问题越多,最后导致项目无限期拖延下去,投入大而长时间见不到效益,让领导和实施者都丧失信心。

    其次,要选择合适的合作伙伴。现在基本上所有大的IT厂商都推出了各种SOA解决方案,国内很多服务提供商也打出了SOA的牌子。其实,宣布能做SOA并不意味着真的就可以帮助用户实现。从实际操作角度上说,SOA是个长期工程,而且相当于把以前的系统打散了用一种新理念重新构筑,所以国际上成功实施的案例并不多。这就更要求用户在选择合作伙伴时要慎重。合作伙伴首先要具备一定的实力,起码知名度要高,研发实力要强,这样才能保证他们的方案经过反复的验证。同时,合作伙伴最好有一定的行业背景,甚至用户可以优先考虑从以前系统的建设厂商中挑选,这样,在进行系统迁移和重整时,不用从零开始。

    第三,要有模块化意识。从这一点上来说,SOA与系统的开发和实施没什么区别。最大可能地将系统模块化,这样通过多次调用降低开发成本,从而获得最佳性价比。只是,模块化思想以及实施与项目初期的规划息息相关,只有良好的长期规划,系统才具有可复制性。

    第四,人力资源是重要因素。毋庸置疑,SOA虽然不是新概念,但真正具备成功实施经验的人才还是弥足珍贵的。尤其对于用户来说,不可能一味依靠乙方的力量完成全面转向SOA这一浩大的工程,所以,培养自己的人才队伍对于很多用户来说是个长期工程。尤其刚开始时,不妨拿一些小范围的SOA迁移项目练手,等技术力量成熟时,再进行大一些的项目,循序渐进,逐步成功。当然,这其中不可避免的问题是“为他人做嫁衣”,人才培养出来了,却成为别人挖墙角的对象,损失当然不小。不过,这个问题的解决就像目前用户信息中心人才流失问题一样,需要用体制来保障。

    BEA的专家对SOA的成本问题有自己的看法,他们反对四处出击,重要的是按成本受益顺序确定服务开发的优先级,这样SOA从一开始就显示出ROI(Return on Investment,投资回报率)。通过仔细规划,启动成本要限制在现有预算内。经过一段时间后,服务模块的重用会确保以后每个新业务应用程序的启动成本很低。同时,用户需要在实施开始时设置好基线,确保可测量性,避免临时修路的效果。 

    第三步 避险

    成本的问题考虑清楚之后,SOA的实施风险就摆到用户面前。
   
    尽管SOA的技术基础已渐趋成熟,但这并不意味着从此SOA就可以飞入寻常百姓家,相反,很多企业用户对部署SOA顾虑仍存。

    联邦快递有限公司(FedEx)亚太区副总裁兼首席资讯总监莲达·C·柏勤(Linda C Brigance)表示:联邦快递对SOA的态度比较谨慎。花旗软件技术服务(上海)有限公司董事主席周亚贵是花旗集团亚太区IT系统规划的重要参与者。他透露,花旗集团亚太区并不打算在近期采用SOA。中国平安保险(集团)股份有限公司信息总监罗士礼曾经表示:部署SOA需要花费企业大量的时间和精力,而业务部门不会有那么好的耐心。对于IT部门来说,改变系统架构还必须考虑业务层面的现实压力。

    实施SOA潜在的风险迟滞了部分用户迈向SOA的脚步。

    要将现有的IT架构转变到SOA架构除了需要资金,用户还需要时间、勇气,以及抗风险的充分准备。
   
    一般来说,部署SOA主要面临两类风险。

    一是技术风险。首先,用户选择的SOA平台和开发队伍对Web服务、J2EE等技术标准的掌握程度,都可能潜藏着技术准备失利造成SOA项目失败的风险。SOA还处于发展阶段,一些技术并不是完全成熟,正处于从理念付诸实施的探索中。早有国外专家指出,SOA作为一个具有发展前景的应用系统架构,尚存在许多有待改进的地方,例如在可靠性、安全性、编制(Orchestration)、遗留系统(Legacy support)支持和语义(Semantics)方面均存在不足。其次,SOA可以让原本不同的IT系统快速整合在一起,只须调用系统组件就可以进行业务整合。然而SOA目前还没有确定调用系统组件的统一标准。譬如税务部门与公安部门交换车辆数据,公安管理的是车辆,一辆车是一个数据,而税务管理的是纳税人,一个人可能有好几辆车,这就涉及数据约定的问题。SOA能做多大,就要看它能在标准化这个方向上能走多远。

    二是管理风险,传统的企业管理模式执行垂直管理,部署SOA必须要改变企业内部的IT文化、IT组织,这对管理有很大的冲击。从已有的系统迁移改造成SOA架构,是一个长期的工程。尤其是如果企业打算向外部推广一些服务,和它的供货商、分销商、代理商、客户等一起来构建SOA架构的应用,那就还有更长的路要走。这里有一个实际的例子。商业银行现在向客户提供很多代缴固话费、手机费、水费、电费、煤气费等服务,一个省级分行要和几十个需要收费的单位互联,实现应用的相互访问。从纯技术的角度看,这无疑是基于Web服务的SOA架构应用的最佳用武之地。但现实是,没有人这么做—因为需要改造自己的业务系统,牵涉很多人员和投入。此外,也有安全的问题、效率的问题等,目前还没有成熟的解决办法。

    为了实现这一目标,对企业内所有的员工——既包括IT部门员工,也包括其他部门的员工,都需要转变对业务流程的固有看法。这需要相关的职能部门为了长远的目标而放弃眼前的利益,也要求IT系统设计师及开发人员从服务的角度来考虑系统的构成,同时,他们可能会放弃某些环节的控制权,如版本控制等。整个SOA系统可能要涉及变更管理、技术管理、风险管理以及日常业务管理等多个已有的业务系统。

    实施SOA存在风险,但我们也不可能因为存在风险就因噎废食。对于SOA项目的实施,专家提出的建议是,用户不能一次实现所有的功能,不能一口吃个胖子。在SOA项目中将风险最小化的一个方法,是先将一些小的或有利于业务的流程使用SOA模式,构建相应的服务模块。这样可以让员工先适应这种新的服务模块。不至于使整个公司因为引入了新的IT系统而陷入混乱。
 
    记者手记

    SOA应用 70度

    当改革大潮轰轰烈烈而来时,我们要做的是隔岸观火还是顺势而动?

    看现在这架势,好像隔岸观火者并不能完全袖手旁观。因为各大厂商实在是在用各种各样的武器—媒体报道、学术会议等等各种手段讲述SOA的好处。弄得好像谁要是不上SOA,就被社会抛弃了一样。

    其实,任何一个新事物给社会带来的变化可能都是颠覆性的。但是,这并不代表它一面世就会有如此惊人的效果。早在上个世纪80年代,互联网就已经诞生,但其真正普及却在十年之后,其所带来的翻天覆地的变化也在很多年后才凸现出来。

    SOA也是如此。SOA为我们描述了如此动人的场景,以至于让每个从事信息化的人都热血沸腾,但它什么时候才能真正普及,谁也说不清楚。很多厂商为我们提供了各种各样的方案,他们说,只要按照他们的指引,就能实现那些梦想。于是,很多跃跃欲试的用户开始摩拳擦掌,他们纷纷在一些关键或者非关键的旧业务系统改造、新业务系统初建的过程中,开始了SOA之旅。他们中的一些人有了收获,一些人有了经验,他们发现,SOA仅仅是个长期过程的代名词,阶段性成果并不那么遥不可及。
   
    于是,SOA终于有能力进入实质性的高温阶段,用户的应用热情也逐渐高涨起来。要说现在的温度,100度不够,70度刚刚好。

责任编辑:张妮
e-works
官方微信
掌上
信息化
编辑推荐
新闻推荐
博客推荐
视频推荐