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的事，更是一个负责任的方案提供商需要考虑的问题。
网友评论