商业银行IT系统架构规划

一、中小银行面临的挑战与应对策略

       我国大量的中小银行（数百家城市商行和农村信用社）是在九十年代中后期开办的。经过十多年的发展，中小银行逐步建立起了支持其主要业务运转的IT基础设施、应用系统以及相应的管理、开发和运维体系。目前，中小银行IT应用水平大致与四大国有商业银行第二个发展阶段相当。虽然中小银行近年来不断加大IT投入，IT建设也更趋理性化，但仍然普遍存在诸多问题：

       1.中小银行的IT架构可扩展性较差，难以适应不断变化的经营环境，难以满足快速发展的业务需求；核心业务系统的可伸缩性不足，处理性能难以应对业务量快速增长的形势，业务高峰时刻经常出现堵塞、宕机、数据差错等可靠性问题。

       2.更重要的是，中小银行的IT建设缺乏规划。从基于PC的第一代架构，到基于小型机的第二代架构，中小银行的IT建设基本上是跟在大银行后面亦步亦趋，没有能够很好地吸取大银行的经验教训，让自己少走弯路；近十年来，国内银行业市场竞争日趋激烈，由于实力不及大银行，中小银行大多只能依靠先声夺人的方式来争夺新产品市场，许多项目等不及规划就匆匆上马，整个IT架构逐渐变得无序，甚至混乱——技术纷繁复杂，功能重复，管理成本不断提高；许多中小银行IT自主实施能力薄弱，应用系统的设计和开发大多依靠集成商，或者干脆外购，形成众多以部门为边界、孤立建设的应用系统，难以满足未来新产品研发和全业务流程支撑的需要。

       3.由于缺乏信息的整合和关联，管理层很难获得准确的市场、销售、财务等方面的数据来支持其进行快速、正确的决策，只能根据自己的经验和不完整的信息来进行管理，决策风险依然很大。

       如何能在有限的资源配置下，拓展出一条可行的、能够适应未来业务发展的IT建设之路，是对中小银行IT部门的一大挑战。目前，中小银行自身高端的业务和技术人才匮乏，借助专业金融IT咨询公司为自己梳理和规划IT架构，显得非常必要。但最大的问题可能还不是如何制订一个适用的、有前瞻性的IT规划，而是怎样才能有效地实施IT规划。一方面，中小银行需要有管理机制上的变革，打破部门障碍，确保IT规划能够在整个企业范围内得到落实；另一方面，需要精心选择一个整体性的IT架构解决方案，这个解决方案必须与IT规划相融合，能够构建一个既适用于当前，又能够满足长远发展需要的相对稳定的IT架构，确保整个IT系统能够柔和、平缓地完成转变，最终实现IT规划目标。

二、银行IT架构规划的关键抉择之一：基础架构

       基础架构规划是IT架构规划的重要组成部分，银行应当立足自身特点，选择适用、有效、成熟的技术，而非时髦、“先进”或者“高端”的技术，构建能够满足业务长远发展需要的基础架构。

       硬件平台、操作系统、数据库、中间件和开发工具是几个关键的、必须慎重抉择的基础技术领域。根据中小银行的业务特征和发展形势，以普遍运用刀片或机架式PC服务器、Windows Server/LINUX和.NET/J2EE为显著特征的基础架构是适用的。



       在这样的基础架构中，除了核心业务后台应用系统（例如，对私、对公业务后台系统，客户信息系统）仍然使用小型机、UNIX和CICS/Tuxedo——这主要是为了满足传统的核心业务对可靠性的极高要求，同时也使已有的基础架构和应用资源得以继续利用——之外，新业务和产品的服务层系统（例如，国内大银行开发的大前置，以及中间业务平台、投资业务平台、现金管理、私人银行等应用的服务层系统）、ESB（Enterprise Service Bus，即企业服务总线。在应用架构中引入ESB可以帮助企业很好地整合其异构的各种应用系统。在国内银行业，目前还鲜有真正成功实施了ESB的。从技术实现方面看，ESB和国内大银行开发的内部的交换系统非常相似，可以看成新一代的综合交换系统）、数据分析和决策支持、电子银行（网上银行、手机银行、电话银行和客服中心）等重要的应用领域均采用PC服务器+Windows Server/LINUX+.NET/J2EE的解决方案。由于支持集群部署，这种解决方案可伸缩性极强，能够以低廉的成本构建具有强大处理性能的基础架构，轻松应对长时期业务量快速增长的严峻形势，整体可靠性完全能够满足关键业务系统的苛刻要求。

       一些中小银行在上述应用领域内选择采用UNIX+J2EE的解决方案，看中这类方案的“开源、免费和标准”。业内大量的实践证明，同等的硬件配置，Windows Server+.NET方案能够达到10倍于UNIX+J2EE方案的性能，可靠性也高得多，更能够满足中小银行业务长远发展的需要；虽然J2EE产品号称开源、免费，但技术支持费用不菲，总拥有成本仍然是Windows Server+.NET方案具有优势；虽然J2EE被当作业内标准，但厂商在各自的产品中附带了大量非标准的扩展功能和组件，一旦使用了这些扩展功能和组件（这是非常普遍的），应用就无法迁移到其它J2EE产品上。考虑到这些因素，相对于J2EE，.NET可能更加适合在中小银行应用——根据最新的统计数据，.NET在欧美金融业的应用已经远远超过J2EE，并且在开源项目的支持下，.NET应用也同样可以部署在LINUX和绝大多数种类的UNIX上。

       此外，各类银行职员（网点柜员、客户经理、客服人员、业务管理人员、系统管理人员、设计人员，等等）统一的工作台和自助银行等客户端应用系统也普遍运用Windows和.NET，这意味着这样的基础架构技术构成相对单一，能够有效地降低中小银行在技术培训、应用开发和系统维护等方面的成本。
这样的基础架构在技术上是成熟的。国外许多先进银行都选择了这种基础架构，国内大银行也在许多重要的应用领域中采用了同样的基础架构（例如，农行的网上银行应用系统，ESB，中行的集中式柜面应用系统，等等）。

三、银行IT架构规划的关键抉择之二：应用标准、平台和框架

       选择优秀的应用标准、平台和框架构建高质量的应用系统，是卓越的应用架构规划和实施的关键。

       例如，WebService就是一个很关键的应用标准，使用和提供WebService是应用架构规划工作中必需考虑的问题。WebService已经在许多行业得到了普遍应用，如果要开发基于企业互联模式的业务应用，WebService将是最佳的对接标准；更重要的是，基于WebService统一企业内部服务标准，能够极大地提高企业内部应用资源的重用程度，同时实现异构基础技术的完美融合。

       但任何事物都有两面性，优秀的应用标准也不例外。WebService就有2个重要问题往往是银行这类企业高度关注的：如果应用都采用WebService标准来提供服务，那么调用ebService的集成型应用（可能要占企业应用总量的90%）的运行效率和吞吐量是否会大大下降；同时，集成型应用的一个处理过程可能会调用多个WebService，一致性又如何保证。

       显然，标准化本身并不是万能的，如果应用设计不当，采用标准反而会产生巨大的负面作用，标准化实际上是对企业的应用设计和实施能力提出了更高的要求。中小银行的IT资源本来就非常有限，其应用设计和实施能力即便是应对当前的需求也已经是捉襟见肘，如何才能高质量地实施一个可以和大银行相媲美的卓越的应用架构规划呢？

       选用优秀的应用平台和框架是一个非常有效的解决办法。所谓应用平台和框架本质上也都是一些应用，这些应用不对具体业务提供支撑，但是可以开发插件加载到这些应用上构成完整的、支撑具体业务的应用系统（通常，应用框架仅指基本的运行框架和基础组件库，不提供插件开发和运行管理工具，而应用平台功能和工具的配备更加完整），这种模式能够大大简化、加速某类业务应用的开发，提高业务应用的质量。与CICS/Tuxedo、J2EE和.NET之类的基础软件不同，应用平台和框架一般都是针对某个行业（或者领域）构建的，提供了该行业（或者领域）大量常用的、公共的基础功能和处理流程的封装，为该行业（或者领域）具体业务应用提供更有效的支持。