中国银行保险核心趋势分析.docVIP

无意中网上看到一篇文章，个人觉得有些观点值得鉴戒。发来共享，希望用户在选择系统更新换代的时候，保持清醒，选择适合自己的架构，而不是追赶潮流，追赶潮流往往需要付出代价。放眼看世界银行与保险公司的核心业务系统，真正用J2EE架构的确实很少，但作为IT公司与用户却都叫得要往J2EE架构转，这里的原因有几个：1、IT公司必须炒作新概念，才能获得新利润目前各银行与保险公司都有自己的核心业务系统，一般而言一个系统使用时间越长，系统会越稳定（使用过程实际是一个不断的排除BUG与系统优化的过程），但随着业务的发展，系统还是要有所发展的，如新增业务功能的处理，新增服务渠道等，一个好的架构，这些扩展都可在原有架构上有序的扩展，当然有的系统基础架构不好，或由于开发过程中的“大跃进”，使得每一次系统升级都要打快速补丁，最终导致破坏了原有良好的系统架构。系统升级过程中破坏了原来较好的架构，这是如何做好软件工程的问题，与是否采用J2EE无关，而且在国内导致这个问题更重要的原因是用户方在软件方面的投入不足，要求的开发周期严重不合理，而打补丁的方法是最快最省市的方法，很少考虑该补丁对系统结构长远是否有不利的影响，结果是系统在几年后不得不作一次大规模的修改，否则原有系统已经无法打上新的补丁了。这种系统的维护升级方式实际上更花钱，而且风险更大，但用户似乎更能接受，如果采用平稳的升级方法，每次要投入较多的资金与时间，但风险小，长远来说更省钱，但国内用户很难接受这种理念，老觉得IT公司是要让用户付出更多的费用。实际上这样的开发方式IT公司更喜欢，因为每过几年可能会拿到一个较大的单子，但由于新的单子也不一定就落到原来开发公司的口袋里，而每次重新招标都会增加很高的市场成本，因此各公司会把更多的精力放在如何维护与客户的关系上，而对现有产品增加投入则没有动力。这就是国内软件业的现状，并且已经进入恶性循环，到一天国内的软件公司撑不下去了，则用户可能面临着不得不选国内的产品，但价格则可能是国内产品的几十倍或上百倍。当然国外的产品会在某些方面好于国内的产品，但如果国内的软件公司能取得合理的利润进入良性发展，也是可以把自己的产品做得更好的。正因为在上述大环境下，IT公司当然更愿意鼓吹一切新的技术，而不论该技术是否成熟，也不论该技术是否适合用户的实际需要，因为只有鼓吹新技术才会使系统不断地重新开发，这样才会把市场的总盘子做大，也只有这样，大家才会有钱赚（因为在国内挣不到维护费，版权费，只有不断变才会有开发费赚）。但变的风险，开发商是不关心的。2、用户希望简化客户端的维护C/S结构，客户端程序的升级安装总是比较麻烦，再加上可能的病毒破坏，客户端操作人员的误删程序等都可能导致不能正常使用系统。用户方的IT技术人员都希望能捞到一种办法，使客户端象原来的笨终端一样，加电就能用，这样就省事很多。这样基于J2EE架构的B/S结构就很有吸引力。用户的想法并不错，但简化客户端的维护，不一定只有采用J2EE架构一条路，而用户以为只有J2EE才是唯一的途径正是IT公司长期“教育”的结果。用户方的IT人员，特别是CIO们缺乏战略眼光，即使采用传统的C/S结构，使客户端的升级维护可能会麻烦一些，但这只是战术方面的投入，而由于系统架构长期处于不稳定，特定是在升级过程中如何保证数据迁移不会导致数据“失真”（由于改变架构往往会换一家公司开发，而新的开发商对原有系统的数据库表结构不能完全了解，最省事的办法也是不负责任的办法，就是库结构一起改，然后进行数据迁移）这些战略方面的风险则很少关心。架构变更的风险究竟有哪些呢？我们可作简单的归纳：1、数据风险在上述讨论中已经提及。2、系统稳定性除非是已经很成熟的应用了软件产品，否则任何一个开发的应用系统都要经过2—3年才能逐步稳定。而国内用户很少同意购买一个产品，再根据产品的要求来对自己的业务流程进行重组，这样实际上就没有真正意义上的软件产品，即使有一个产品的基本版本，在任何一个用户单位都要经过大量的修改或客户化才能适应用户要求，结果就是系统的稳定性被破坏，趋于稳定的周期加长。3、效率风险任何一种架构实际都是有一定的适用范围。2层的C/S架构适用的小型企业应用，因为有很多开发工具支持，开发周期快，即使有变化，重新开发的成本不会太大。N层C/S架构（采用IBM-CICS,BEA-TUXEDO中间件），该架构已经把业务逻辑设计成一个一个独立的可供调用的SERVICES，增加或修改业务逻辑只是增加SERVICES或修改已有的SERVICES，客户端只作界面处理。这样的架构使得业务逻辑的变更极为方便，而这正是银行保险这样的应用更为关心的。这样的架构是专为OLTP应用设计的。J2EE架构也可把业务逻辑后移，设计成SAERVICES，也可按