建行:奔向SUP2.0--统一平台在建设银行的应用


 2010-08-23 00:00:00       754

由于较早认识到基于统一开发平台的重要性,建设银行建立了J2EE的技术规范和标准,开发了SUP1.0开发工具平台,建立了开放、高效、安全、稳定、统一的J2EE架构,为J2EE项目的设计、开发、运维提供了良好的技术支持。随着银行业务发展与IT需求的提升,建设银行在2009年完成了SUP2.0平台的搭建工作,新一代银行系统平台的作用与价值越来越突出。
 
一、背景和挑战
 
建设银行J2EE架构平台的实施成效显著,但SUP1.0在设计之初的定位决定了其存在的缺陷,随着平台应用的不断深入,其不足之处逐步显现。
 
架构级:审视架构的视角不够完整,缺少必要维度的规划;系统内部的耦合性高,结构复杂,维护成本相对较高;没有统一的服务接口方案,不利于业务复用;架构中缺少跨业务、跨页面的数据管理,完全依赖 Web容器提供,对有状态逻辑的处理不方便;缺乏统一的监控框架以及管理监控的基础设施,不利于系统的管理、优化;对已有的公共系统如EAI、UAAP等,没有进行进一步包装,各项目组自行实施,成本大、不统一;技术支持组件不足,如缓存、资源管理、消息等。
 
组织级:对技术平台的研发投入不够,技术规范覆盖范围和技术平台提供的功能有限;缺少专门的支持、推广团队,技术平台的推广、实施速度较慢;缺少专门人员持续研发,平台缺少可持续发展的能力;对平台的维护投入不足,版本更新不及时,影响项目使用。
 
过程级:缺乏从已有系统中抽象可复用单元的过程保障;普遍偏向技术组件的提炼,业务专业化组件和面向领域的组件提炼不足;软件开发过程中单元测试不足,不进行每日构建与集成,不利于规模较大的项目管理;软件的非功能规范难以落实和检查,虽然进行了代码走查,但过多的java代码,走查比较困难。
 
二、解决之道
 
建设银行为实现J2EE体系建设目标,确定了相应的建设思路:技术标准->平台实现->平台推进三部曲。
 
技术标准:走具有建设银行特色的J2EE之路,结合实际,借鉴外部经验;建立行内J2EE标准体系,作为系统建设的依据。平台实现:屏蔽技术框架,固化规范和开发流程;锻炼J2EE专业化队伍,专注于底层技术研究。平台推进:以工具平台的推进带动行内J2EE环境的规范化;促进技术人员专注于业务需求和系统分析。
 
通过技术标准规范全行的业务应用系统基于J2EE开发。通过研发一套工具或平台,将技术标准及规范固化到平台中,并提供相应的开发流程、模板和工具。技术人员在实现业务需求时,不需要太关注标准、规范和底层技术细节。最后在全行推广该工具平台,将J2EE环境逐步净化和统一。
 
三、统一平台的选择之路
 
意识到SUP早期版本的不足,建设银行高层决心研发新一代SUP平台,以满足建设银行IT系统的建设需要。同时在接受普元公司的咨询服务后,建设银行更加明确其SUP平台的建设目标。新一代SUP平台的建设策略如下。
 
策略一:开源整合
 
在 SUP 1.0 版本基础上,遵循《组件规范》,参考《技术架构完善方案》,参照主流厂商已有平台产品,自行组织力量,整合开源技术,设计和开发新一代应用平台。优点:有利于自身技术掌控,不受厂商控制。缺点:难度较高,难以保证平台质量和先进性,开发周期长(预计2年以上),项目风险性较高,维护工作量大,人力资源及自身持续发展能力不足,总体拥有成本较高。
 
策略二:购买商业产品
 
从业内领先的专业化IT厂商中选择已有的成熟产品,在此基础上进行封装,使之符合建设银行的特点。优点:平台质量和先进性得到保障。缺点:对厂商依赖性较大,且难以较好满足建设银行的个性化需求,原有系统移植较为困难。
 
策略三:客户化定制+开源集成
 
以建设银行的《组件规范》和《技术架构完善方案》为指导和目标,在厂商已有平台的基础上定制开发适合建设银行的新一代应用平台。建设银行获得知识产权,厂商提供知识转移的培训和后续服务,并帮助建设银行建立在此领域能够满足发展需求的人力资源队伍,建设银行的科技力量集中在业务组件的建设和积累上。优点:在别人的基础上快速自主掌控核心技术,可以最大限度地满足建设银行的需求并保证平台质量和先进性。缺点:初期投资成本高(需要厂商转移核心技术),需要厂商对建设银行有战略合作意愿,能够开放源码和知识转移。
 
建设银行最终认为,实现真正意义上的定制化开发是实施统一应用平台的最好模式,并选择与普元公司合作,建设新一代SUP平台。该平台虽然以普元公司的EOS6为基础,但同时结合了建设银行的实际状况,充分吸收了SUP1.0的宝贵经验。在平台建设过程中,建设银行的科技人员充分参与,普元公司积极配合进行多轮知识转移,部分关键任务的开发工作完全以建设银行的科技力量为主。最终建设银行完全掌握并拥有了具有自主知识产权的SUP2.0平台。
 
四、实施路线
 
阶段一,J2EE技术架构规范。自由开发:每个应用拥有各自的J2EE技术架构,基本处于自由开发阶段。组件基本无积累:每个应用实施之后,留下一对jar包,相关的文档、接口不一致,基本无积累和沉淀。
 
阶段二,SUP1.0。该阶段的任务包括规范手动开发、规范流程、技术组件的简单积累及统一应用架构的搭建等工作。
 
阶段三,依靠专业咨询服务。出于对普元公司的了解与信赖,针对SUP1.0存在的问题与不足,建设银行希望通过接受普元公司的咨询服务,保证其顺利完成SUP2.0的开发与实施。
 
阶段四,客户化改造需求。在IT厂商已有平台的基础上定制并开发适合建设银行的新一代应用平台,并最终获得自主知识产权。由厂商提供知识转移培训和后续服务,壮大建设银行在该领域的科技资源队伍,将主要精力集中在业务组件的建设和积累上,迅速掌控核心技术,最大限度地满足其业务及技术需求。建设银行的新一代应用统一平台客户化改造实施路径如图所示。
 
阶段五,发布新一代SUP平台并推广。该阶段包括随需应变的开发、更加灵活的流程、技术组件迅速积累、业务组件持续积累以及建立企业级服务体系等工作。
 
五、实施效果
 
建设银行J2EE组件化平台的能力可从支持应用系统的技术架构、开发、互联等多个角度阐述。
 
首先,支持应用的设计开发,减少工作量。其次,具有可复用的应用框架。基础应用框架包含了菜单组件包、安全组件包(本地和UAAP)等功能模块在不同应用项目中的最大复用。第三,规范系统结构,为应用系统提供统一的组件化结构视图。第四,J2EE应用互联,为J2EE应用系统的互联提供方便,支持将现有的J2EE系统快速发布成服务。第五,工作流集成,实现了与工作流的业务接口集成,即通过接口封装实现了具体工作流产品的无关性。第六,报表集成,实现了与建设银行统一报表平台RIDE的集成,方便应用项目组使用RIDE报表功能。第七,兼容既有成果,兼容建设银行原有的SUP1.0开发平台和原有的java开发规范。支持主流的基础环境。支持WebLogic、WebSphere多应用服务器、支持Oracle、Infomix、DB2等数据库,支持Windows、Linux、HPUX、AIX等多操作系统。
 
截至2009年底,建设银行已有近20个应用系统基于SUP2.0开发上线。例如对公客户关系管理系统、个贷系统、反洗钱监测分析系统、操作风险管理系统等。实践证明,这些坚持以应用为导向、并能够有效实现自主掌控的系统开发体系最终将满足建行不断提升的业务及技术要求。
 
 

相关阅读: