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目标。”