成也SOA 败也SOA,SOA在中国的经历

互联网 | 编辑: 江海明 2006-12-20 14:00:00转载 一键看全文

SOA架构设计≠“服务”设计

孙维作为新悦集团的IT主管,2005年本有机会成为公司有史以来的第一位CIO,可随着SOA在集团内的应用,他却与此越来越远。孙维没想到,他的希望会随着SOA的应用而破灭。为什么会这样?明明知道SOA项目对自身的关键性,准备工作也做了又做。“我错在哪里了,经验、沟通或是?”孙维不停地问自己,并尽量把自个拉向最初的记忆。

作为一名“元老”,孙维已经伴随新悦集团走过了5个年头。让他自豪的是,与集团IT系统(从无到有、从最初的非核心系统到如今的各大核心业务系统)的发展一样,自己也从一名网管员成长为IT主管。让他高兴的是,新悦集团在各方因素的促进下,业务势头猛烈,已形成跨地区、跨领域的扩展。让他头疼的是,随着跨地区、跨领域的业务扩展,对管理、资金、成本等各方面都提出了挑战,不能实现集中管理、不能实现信息共享,这些问题都需要通过信息技术来解决。让他兴奋的是,机会来了,如果能搞定阻挡业务发展的这些棘手问题,对自身的职业发展将会有一个极大的提升。

孙维的一份请示报告,很快得到了领导的同意:“你主导去做吧,我们等你好消息。”孙维带着兴奋开始了他的工作。他敏锐并清楚地注意到了二个问题:由于原有IT系统已基本贯穿企业绝大部分业务,因此历史数据的安全性是第一个问题;企业正在变革之中,这个过程还会一直持续下去,如何让新系统能够支持灵活多变的业务需求,则是第二个问题。

在这二个问题的基础上,孙维在与蜂拥而来的各种方案提供商大战三百回合之后,决定采用SOA来打赢这场对自身有深远意义的战役。可是让孙维没有想到的是,正是从此次的决定开始,他离所希望的目标越来越远……

“我觉得现在没有一家厂商的SOA方案合适我们,因此,需要借助方案提供商的咨询服务来自己做这件事情。”从项目伊始,孙维便调集精兵强将,与业务骨干和咨询顾问组成了SOA领导小组,全面负责SOA项目的架构设计。小组的主要工作是定义SOA应用领域、分析企业现有IT架构、分解业务流程、对服务进行分类、重新定义流程、对服务统一描述以及对最终的企业集成进行相关的定义、描述和架构决策。

对新悦集团来说,以前也作过很多IT系统建设,所以业务需求收集和流程分解的工作并没有遇到很大阻力。

孙维发现,“要想很好发挥SOA松耦合的优势,服务一定要足够精细。”。每过一段时间,他就会回头看看之前设计的服务,总是觉得还应该再修改的细致些。于是,就派相关IT人员转回去再来修改这些服务。

“这样不成,服务精密度太高了,我们得逐步过渡到这种程度,不然所有人都要耗在这里了。”几乎每次孙维要求修改服务时,咨询顾问都会跟他争吵这个问题。“不这样,服务怎么复用?如果以后再重新修改,可能工作量更大。就按我说的做吧。”而孙维每次都是用这个理由坚持自己的“信念”。为此,咨询顾问还主动向公司寻求帮助。可得到的答案却是,“就按他的想法做吧,以前的系统也都听他的,没出过问题。”

服务设计的精密度确实直接决定着服务在SOA应用范围内的复用程度——越细致的服务就越容易被更多的服务所用,这很类似于砖头越小就越容易被组合成不同的形状的道理—样。但是高精密度的服务设计方案,也意味着对开发人员及架构设计人员能力和经验的更高要求。

在反复的修改设计过程中,新悦集团SOA项目的架构设计比原计划延后了近50%的时间。这还不是最致命的问题。其实,真正给新悦集团SOA项目埋下致命隐患的并不是孙维过渡强调服务设计精密度,而是因此忽略了原有IT架构向SOA迁移的过渡计划制定,以及对现有IT架构的分析和运行效率的评估,这是很多SOA项目都容易犯的错误之一。通过松耦合方式编排构建的SOA服务并非简化了IT风险。相反,松耦合方式能够更好地支撑业务敏捷性的要求,但SOA也使业务与技术的结合比以往更加紧密,从而使IT项目变得更复杂。BEA企业解决方案部经理刘松表示,“像新悦集团这种自上而下的SOA项目,应该从开始就细致分析企业已有的IT应用情况,依此找出一条SOA演进道路,然后分步实现SOA目标。”

提示:试试键盘 “← →” 可以实现快速翻页 

总共 2 页12
一键看全文

本文导航

相关阅读

每日精选

点击查看更多

首页 手机 数码相机 笔记本 游戏 DIY硬件 硬件外设 办公中心 数字家电 平板电脑