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目标。”
网友评论