管理方法最重要 SOA并非万能
 
2009-03-12 来源:网络
 

SOA技术在IT界掀起巨大的狂潮,然而它不同于以前的技术变革:模块化编程、面向对象、Web技术等,不论多难理解,总是能很快被大家接受,SOA之所以让很多人觉得难以理解,是因为它不再单纯地从IT人的角度理解IT系统,而是从业务人员的角度分析IT业务系统。

有两种现象相继呈现:一方面是企业SOA改造,精简企业业务流程,提升企业市场竞争与创新的能力,企业IT部门成为了企业管理的核心链条---“神经系统”;另一方面很多企业觉得无从下手,SOA太空无实,业务部门人员不愿支持,业务流程改造单靠IT部门是难以完成的,而企业内非IT部门,尤其是管理层对SOA了解的还很少…

一、SOA是业务驱动的,不是技术驱动的

SOA概念的提出是在上个世纪了,但近两年在许多大公司相关产品与业绩推动下,SOA一下进入了实际应用的黄金阶段。

SOA的出发点是从业务角度重用应用系统的开发元素,最大程度地降低IT系统开发与维护的成本。很多企业的CIO都面临一个共同的问题:随着网络建设的浪潮涌过,各种业务系统的开发如雨后春笋,在大一些的企业,需要维护成百上千个业务系统是很常见的事,从机房配置、服务器管理、各种支撑系统的维护都让IT部门难以应付,更不用说病毒攻击过后的系统清理与业务恢复,仅仅是查看一下各个业务系统的状态,就需要工作人员花很长时间,要是业务的持续性保障,更是望尘莫及。业务系统的繁多与各自孤立,为新业务的上马带来更大困难,重复开发造成极大的浪费,信息不互通让每个系统都“麻雀虽小,五脏具全”,企业失去了市场竞争的灵活性,极大地触动了企业管理者的神经。

很多大公司开始推广ERP之类的大企业软件系统,希望在一个大系统架构中,可以融合更多的业务流程,各个业务的信息可以交流,避免各个“业务孤岛”带来的管理弊端与效率低下。然而随着单个系统的庞大,开发的难度指数般提升,要考虑的因素太多了,客户业务又千差万别,开发企业的管理成为极大瓶颈;另外“同制化”的设计模式恰恰抹杀了企业的创造力,而失去了“特点”的企业等于选择自杀。IT基础架构如何适应企业的“创造化”需求,新业务的开发如何快捷,如何降低IT支撑系统的管理成本,并提供持续性的服务保障,CIO们重新选择了SOA。

在这种情况下,SOA重新被提出来,按照时髦的解释,SOA是一种IT技术框架,是一种最佳实践,而不是一种具体的技术,能实现SOA的技术很多,如何选择的关键是达到SOA提出的业务灵活度的目标。

SOA的思路其实在IT人中有过类似的想法,我们回顾一下编程人员走过的历程:模块化编程就是把可重用的程序提炼出来,方便调用,提高软件的结构性;后来发展到面向对象,把数据与程序封装在一起,让软件设计人员的思路逐渐接近现实的人类思维方式;B/S架构的流行把客户端的变成维护简单化,业务更适合于网络方式;Web2.0的发展解决了B/S体系的交互问题;中间件技术让跨平台、跨语言的业务开发变得容易……IT人一直在探索、提炼可以重用的、优秀的软件模块,让我们的业务系统开发如搭积木一样容易。

虽然SOA是IT人员的思路,但推动SOA的是企业管理层,SOA是业务驱动发展,而不是技术驱动发展。新的视觉角度,并非所有的企业CIO们对SOA都得心应手,因为IT人员的业务认知弱点是由来已久的。

不再从IT开发人的眼光看待要开发的业务系统,而是从业务的使用者角度看待要开发的系统,面向服务就是面向系统的实际使用者,“谁干谁说的算”,系统应该具备什么功能,应该做成什么样子,要看用户使用的效果。简单地说,就是用“敏捷”的开发思路,代替了“闭门造车”的开发方式。所谓敏捷就是用户的参与,用户不懂你的专业“语言”,就需要快速的模型与界面展现,快速展现不重用是不现实的,而用户理解不从业务流程入手,是与用户没有共同语言的。

二、SOA的“官方”解释

SOA的文章与资料很多,技术实现与最佳实践为多,这里只是说一下SOA的参考模型,展示SOA的架构。对于SOA的实现技术,会随着IT技术的发展更新,Web2.0是目前的一个最佳实践,SOA的目标的提高企业业务的灵活性,围绕这个目标,技术实现只是手段而已。

Sandy Carter给SOA的定义是:SOA(面向服务构架)是一种业务驱动的IT架构方式,支持对业务进行整合,使其成为一种相互联系、可重用的业务任务或服务。

SOA组成的五大要点:

1、重用:创建服务与重用服务是SOA的工作。重用不仅可以节省费用,而且可以减少重复,建立企业间可以共享的服务,从而增加企业的灵活性,而且可以通过服务的实现、包装,利用已经证实是有效的核心应用和功能

2、连通性:业务系统的连通,但松耦合方式,是实现企业业务灵活性的基础,获得连通性也是整合企业人员、信息、流程的前提

3、流程:流程是企业对业务管理、监控的方式,SOA是实现对业务流程的支撑

4、信息:信息是企业决策的基础,是企业的管理神经系统,掌握全面的信息、排除错误的信息、获得及时的信息是IT系统的基础功能

5、协作:协作就是人员。创新不仅靠优秀的员工,更需要优秀的团队,在经济融合发展的今天,不仅依靠自己的团队,还要学会利用外部的力量,要协作就要互通与共享。

企业服务总线ESB位于SOA架构的中心,是五大要素的“交通线”,更为重要的是它提供了新增“服务”的落脚点。有人说ESB是SOA的最大亮点,其实计算机技术里“总线”技术由来已久,总线的好处是方便功能的扩展,但总线本身的能力也限制了总线上应用的扩张,所以总线本身也需要不断地升级。ESB不仅是信息、命令的传输通道,而且是各服务交互的接口标准。

三、SOA不是万能钥匙

SOA是业务驱动,说白了是管理驱动,虽然企业的IT化整合是IT发展的趋势,但每个企业的IT化发展都有自己的文化支撑,IT基础设施的建设、应用的开发是为了企业的业务服务的,脱离了这个宗旨,企业即使图一时的“新鲜”,也不可能长期陪着你玩。

推动企业SOA建设,是从企业的管理层面出发,管理层有“改变”的概念,才可以进行全面的分析与设计,而不是单靠IT技术部门就可以启动的,这一点是国内企业CIO面临的一个大难点。

这么说是基于两点:一是我们国内的IT发展历史还不长,IT部门的管理者在企业内的话语权还不够大,大部分CIO还没有进入企业的高级管理层,IT部门是企业业务的附加服务部门,还不能算是支撑部门;二是国内很多企业的IT建设是跨越式的,老外很羡慕我们新建设万兆网络、优良的处理中心,而很多老外还在使用10M的网络、COBOL设计的应用…我们能直接跨越落后技术是好事,但在IT管理能力与理解上就捉襟见肘,管理理念是需要实际体验的,没有实际的“磨合”,直接开始多业务的整合,用户找不到“感觉”。

SOA本身不是一套严格的技术理论,所谓“最佳实践”也是大家在理解过程中的“实地体验”,是从实际的管理工作与业务经营中总结出来的。而管理一定有其文化作为支撑,中国文化上的差异,可以很快接受一个新技术产品的引进,但对一个管理模式的引进却不尽然。二战后美国的管理体制直接输出到日本,但麦克阿瑟没有把日本变成美国第二,而在似与非似之间,出现了一个崭新的管理模式,日本经济的腾飞不能说不得益于这种模式;安全是“三分技术+七分管理”,这个道理在计算机安全界从一开始就在宣传,中国引进了防火墙、入侵检测、身份认证等多种产品技术、但BS7799、ITIL等安全管理与维护的“最佳实践”,却迟迟停留在培训上,国内真正采用的也是少之又少。

中国有句古话“取其精华、去其糟粕”,管理的思路源自于文化的底蕴,所以SOA这个从管理推动技术的“产品”,要落户中国企业,注定要在“融合”中国的管理意识之后,才会有大的作为。SOA不是万能钥匙,要开中国企业这把锁,需要做一定的改造,总结起来,需要解决下面几方面的问题:

1、管理层重视:SOA是从上而下的业务管理整合,而国内大多企业对SOA的理解目前还处于IT管理层面,企业的管理者不理解就无法深入。让企业的高层领导重视IT,需要把IT部门从企业的服务部门转变为业务支撑部门。

2、标准不是抹杀异化服务:重用服务是为了提高企业开发与管理的效率,越标准的“元件”,越可以降低成本;企业的生命不仅是降低相同服务的成本,还要能不断提供异化的业务,有区别才有市场上的竞争力。若在SOA推行中,过多地强调标准,忽略了创新,而降低了对新业务的支撑能力,同化了业务服务流程的开发,就成为SOA的大败笔。

3、给国内开发商留下生存空间:SOA要求建立ESB,逐渐形成企业服务的标准化,这同时也对业务的开发商提出了要求,标准往往是大厂家主导的,其获得、授权、专利等后期技术壁垒是难预料的,毕竟TCP/IP那样完全公开的标准不容易,中国的业务开发商还都很弱小,若一味注重“国际”标准,势必提高市场进入的门槛,客观上也同化了产品的风格,没有了业务模式的“百花争鸣”,企业也丧失了市场竞争的优势。

4、选择适合企业的:SOA是架构,需要实现技术支撑。中小企业的业务较少,其整合与升级不存在太大的难度,即使是大企业,在选择SOA支撑技术时,并非都要赶时髦,去选择最好的、最先进的,当然也往往是最昂贵的,完全可以根据用户的实际需求选择“最佳”的方式。经济发展的原则是:“永远选择最佳而不一定是最好的。”

SOA是IT管理与发展的趋势,是业务的IT支撑构架,也代表了一种新技术方向,但如何为中国企业所用,需要中、西方的管理思路进一步融合,或者产生适合中国管理模式的SOA架构;SOA不是万能钥匙,解决管理问题离不开管理办法。


火龙果软件/UML软件工程组织致力于提高您的软件工程实践能力,我们不断地吸取业界的宝贵经验,向您提供经过数百家企业验证的有效的工程技术实践经验,同时关注最新的理论进展,帮助您“领跑您所在行业的软件世界”。
资源网站: UML软件工程组织