成也SOA败也SOA[1]

　　孙维作为新悦集团的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目标。”

　　SOA催化数据管理难题快速形成

　　由于在前一阶段的工作中，整个SOA领导小组在孙维的带领下把大部分精力都消耗在反复修改服务设计中，导致对现有IT架构的分析不够彻底。随着开发工作的全面展开，要孙维决定的事情越来越多。

　　“老孙，这个单线程的问题怎么解决?”

　　“孙头儿，这个定时运行的程序怎么办?”

　　由于老系统的某些业务功能只能通过单线程方式访问，或者原本只能在特定时间运行的应用限制了服务与应用之间的交互，孙维不得不为此伤脑筋。“先放一放，如果能用别的办法解决就用别的办法，实在不行就只能留着以后再解决。”可说归说，除了极个别的“问题”能通过对老系统的简单二次开发解决掉，其它的问题只能通过调整本就“粗制滥造”的迁移计划留待以后处理。

　　“让我们比较痛疼的是程序书写习惯的问题。”仍在新悦集团“服役”的王立回忆到，“最初的一段时间经常因为这个问题返工。”SOA所倡导的松耦合要求服务应该是独立的、自包含的，不应该或要尽量避免一个服务需要依赖另一个服务，提供的信息才能实现自身功能。但是在开发过程中，部分技术人员错误地将一些服务设计成了与此相悖的实现。例如，原来的程序会用“查询张三的在职时间以及他的业绩档案”的方式设计。而按照SOA松耦合所要求的，这个功能应该用“查询张三的在职时间，查询张三的业绩档案”这种方式进行设计。