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目标。”
SOA催化数据管理难题快速形成
由于在前一阶段的工作中，整个SOA领导小组在孙维的带领下把大部分精力都消耗在反复修改服务设计中，导致对现有IT架构的分析不够彻底。随着开发工作的全面展开，要孙维决定的事情越来越多。
“老孙，这个单线程的问题怎么解决？”
“孙头儿，这个定时运行的程序怎么办？”
由于老系统的某些业务功能只能通过单线程方式访问，或者原本只能在特定时间运行的应用限制了服务与应用之间的交互，孙维不得不为此伤脑筋。“先放一放，如果能用别的办法解决就用别的办法，实在不行就只能留着以后再解决。”可说归说，除了极个别的“问题”能通过对老系统的简单二次开发解决掉，其它的问题只能通过调整本就“粗制滥造”的迁移计划留待以后处理。
“让我们比较痛疼的是程序书写习惯的问题。”仍在新悦集团“服役”的王立回忆到，“最初的一段时间经常因为这个问题返工。”SOA所倡导的松耦合要求服务应该是独立的、自包含的，不应该或要尽量避免一个服务需要依赖另一个服务，提供的信息才能实现自身功能。但是在开发过程中，部分技术人员错误地将一些服务设计成了与此相悖的实现。例如，原来的程序会用“查询张三的在职时间以及他的业绩档案”的方式设计。而按照SOA松耦合所要求的，这个功能应该用“查询张三的在职时间，查询张三的业绩档案”这种方式进行设计。
“要解决的问题太多了，之前根本没想到。不过后来我发现，像老系统的遗留问题和书写习惯都还只是小问题。”随着服务开发工作的不断推进，孙维还发现不仅服务变得越来越多，连数据库也随之“丰满”起来了，“很多服务往往要调用原本存储在很多个数据表里的数据，另外一些服务又对表结构有新要求，所以每次都要为这些服务设计新的表结构。以后的数据管理会存在非常大的难度，开发工作的后期我们就遇到过一次：要修改一个数据，却发现必须同时更新很多个数据表的情况，哪怕有一个遗漏都可能给实际工作带来很大的麻烦。”
其实，关于数据管理的问题早已存在，一定程度上来说SOA只是加快了这一问题的显现速度。因为SOA的松耦合方式使服务看起来更像“即插即用”，这就让很多开发人员忽略了数据存储的问题。包括数据大集中概念的出现，也是一些数据库高手为了解决这个问题而提出的设想，希望通过把所有数据存储在一个大数据库中，从而降低管理难度和成本。多年过去了，实践已证明这并非一个行之有效的解决方案。东方通研发中心副总设计师刘川认为，“要从根本上解决数据管理问题必须从IT架构设计阶段入手。可以把数据也当作一种特殊的服务看待，对其标识、索引、注册。”带着这个问题，记者也采访了其它SOA方案供应商，尽管大家都推荐了类似“把数据当服务”的主数据管理（MDM）的解决思路，但是动辄百万以上的成本投入目前在国内企业中又有几家能承受的起？
联调测试终结CIO梦想
SOA项目上线前的第一轮测试由各个开发小组独立完成，主要针对本组负责开发的服务进行功能性测试和修改。而第二轮测试才真正算是联合测试。孙维抽调骨干开发人员临时组成联调修改小组和协调小组，同时组织相关业务骨干成立业务测试小组。在第二轮的业务测试通过后，还要再组织技术人员进行第三轮的系统压力测试，验证系统是否能够稳定运行。
第一轮测试进展相对顺利，毕竟只是在小组内进行，其间并没有出现什么大差错。但好景不长，进入第二轮测试后，人的问题变得比技术问题更加严重。
“还要修改？你们当初是认可我们的设计思路的，可现在都修改四次了为什么还要让我们改？”一位负责修改程序的测试人员大声抱怨着。
“我们也没想到程序写出来是这样，当初你们要是再多征求几次我们的意见就不会这么麻烦了。”另一位参与联调测试的业务骨干也毫不示弱。
按孙维的说法，第二轮测试经历了“沉默—争吵—再沉默”的一个循环过程。“测试的最开始，大家还都心平气和的，业务人员提出问题，技术人员就修改问题。”但好景不长，随着问题的逐渐增多，开发人员在经历了长时间超负荷工作后开始急躁。有的抱怨业务人员提出的修改要求与过去不同，属于不合理要求；有的抱怨这些问题是老系统就存在的限制，根本不是自己的问题；还有些技术人员认为自己开发的程序已经通过测试，现在的工作不应该自己来干；更有技术人员相互抱怨的情况发生，不同组开发的服务之间有些接口存在问题，彼此之间也经常毫不留情的“大打出口”。
“最让我们难以接受的是竟然有业务人员矢口否认我们的设计曾得到过他们的确认。”王立回忆起了这样一幕，“一位部门经理跑来问，为什么我们的业务数据要给别的部门看？还要求我们彻底修改。”
由于整个项目的进度从最初的架构设计阶段就落后近50%的进度，联调测试也引起了高层的“特别关注”，多次向孙维和项目组施压，要求系统尽快上线。可这个“特别关注”不但没有起到推动作用，反倒使推卸责任的情况愈演愈烈。“最后所有业务流程走通的时候，大部分人不是高兴，而是一种解脱的感觉。”回忆着难堪的一幕幕，孙维说，“这简直是一次人性的测试。”
但是不管怎样，业务流程的测试最终还是在不断的推卸责任和反复修改中完成了。尽管出现了这么多问题，但孙维此时仍然坚信，距离成功仅一步之遥，很快，自己也会从IT主管晋升到日思夜想的CIO。但是第三轮测试还没结束，孙维却主动向集团管理层递交了一份辞职申请。
“由于一个业务流程的运行需要编排的服务太多，使硬件系统无法承受由此带来的负载，在一些关键业务的压力测试还远没达到现有业务量的时候，就出现了多次宕机。”尽管孙维对其中的一些服务又进行了调试，甚至是重新开发，但是总体性能仍然达不到保证业务正常运行的要求，甚至比现有系统的效率还低。而早已“透支”的项目周期和资金投入也早就让集团管理层对SOA项目不满了。此时对孙维来说，要想再让集团为此投入更多资金和时间，甚至比做上CIO还要难。“与其说孙维主动辞职，不如说是不得已而为之。”作为方案提供方的顾问，李辉说这都是一意孤行导致的结果。
这样的结局大大出乎孙维的意料，甚至与他一起从头至尾奋战过来的“兄弟们”也都很难想象到这种结果。实际上出现这种问题不仅是因为孙维执意采用高精密度服务设计方案导致的，这与新悦集团在SOA项目中没有做好迁移计划也有很大关系。此外，当使用Web Services等Web方式实现松散耦合时，SOA引入了数据处理层，同时也带来了由这些层所影响执行效率问题。而孙维和咨询顾问也都没有考虑到其执行效率上一直存在的问题。结合这些原因，就出现了这么一种递进关系：服务的高精密度设计导致业务流程需要编排更多的服务，更多的服务意味着更多的Web Services和数据处理层工作，更多的Web Services又意味着更大的执行效率问题，最后导致众多压力测试无法通过的结局。正在着手进行新一期SOA项目建设的中外运信息管理部副总经理张思宇对这个问题也是早有“领教”，对此，他建议“简单的程序，没有必要用SOA。”
可是说什么都晚了，孙维不仅搞砸了这次的SOA项目，也搞砸了自己的前程。尽管集团领导没有批准他的辞职申请，但是集团CIO的位子也从此变成了孙维的一个奢望。而新悦集团的SOA项目最终也变成了部分数据接口的SOA实现。“我觉得SOA还有很多实质性难题没有解决，就跟ERP一样，多年来一直在喊分步实施，可仍然成功率很低。”孙维语重心长地叹了口气。尽管目前很多SOA方案提供商有一套自己的SOA实施方法指导，可是至今在整个行业内对服务精密度如何把握、服务的注册管理等问题更多的也只是停留在理论阶段。所以SOA能不能成功应用不仅仅是CIO的事，更是一个负责任的方案提供商需要考虑的问题。
网友评论