规范和统一：中信银行统一平台建设实践

作为全国性股份制商业银行，中信银行在信息化建设方面也一直走在同类银行前列，在发展过程中建立了相对完善的IT业务支撑链，包括从核心账务类、渠道类、信贷类、数据类等全业务IT支撑和相应的管理能力，而且IT部门的建设也覆盖了包括从设计、开发、测试、运维、质量控制在内的全生命周期管理体系。

         不过，随着流程银行、电商业务的日益兴盛，以及交叉销售建设的深入开展，如何更好适应“随需应变”的业务发展需求变得越来越重要，这也对金融IT建设提出更多挑战和要求。

挑战一：如何固化和统一技术架构

         中信银行的IT规划提出了建立以“客户为中心”的应用架构和“以服务为导向”开放/松耦合的应用架构，并明确了应用系统架构设计原则。但IT部门在逐步落实IT规划提出的要求时，也发现了一些问题。其中最为显著的是银行内部对于架构目标和架构设计原则理解的不一致，评判应用系统架构的标准不统一，架构设计结果和实现方式千差万别，另外，项目建设质量还受到较大的人为因素影响。因此，如何选择好的架构并将好的架构固化和统一到可落地的平台和工具，是贯彻IT规划很重要的挑战。

挑战二：高效、高质量、易管控完成应用系统开发

         如何高效、高质量、用易管控的模式完成各类应用系统开发，也是中信银行IT部门很关心的问题。为此，我们调研了18个应用项目，发现中信银行的项目从立项到实施完成，一般都要比预计时间（计划时间）晚20％左右；此外，中信银行针对项目管理和质量监测，虽然有很多明文规定，但因检查和管理手段比较单一，具体实施起来还是依赖于各项目组自身的自觉约束和管控，从而导致各应用项目开发进度不一，质量参差不齐。

         另一方面还会发现，中信银行的应用项目在其上线前三个月的时间段内，系统的可靠性普遍小于98％，故障定位和处理也较慢，事前防范系统生产风险的能力较弱。

挑战三：如何保证和提高系统的非功能需求

         相对而言，业务部门对应用系统的主要关注点在于系统对业务需求的支撑能力，而对于系统的非功能需求则考虑较少。同时IT部门如何保证系统非功能需求，也缺少较好的手段。事实上，系统非功能性需求会严重影响系统使用效果和生命力，例如系统可扩展性要求。我们曾遇到这样场景：原有客户信息均分布在不同系统中。但是当ECIF系统在建时，我们就考虑将客户信息从不同系统中剥离出来，这其中就会存在很大风险和潜在工作量，毕竟当初大部分系统在建设时，各模块均采用紧耦合的方式，模块之间相互依赖性较高，常常是牵一发而动全身，导致变更的工作量难以评估。因此基于中信银行本身有限的IT资源，如何在众多应用系统建设中，均能保证系统非功能性需求满足，是一个很大的挑战。

挑战四：持续全行级软件资产复用能力

         在统一平台建设前，中信银行一般均采用众多开发商自有框架和平台进行应用开发与运维，缺少基于全行范围内，跨应用、跨开发商软件资产复用体系和能力，从而导致各应用存在大量重复、低水平的开发工作，另外系统中还存在大量类似功能操作模式，与界面差距很大，代码质量参差不齐。

         目前如何解决这些挑战，更好让IT服务既满足中信银行的业务发展需要，还能实现低成本、高质量的开发和管控，成为中信银行IT部门核心需要解决的问题。

选择平台之路

         通过我们全面和深刻的市场调研工作，以及国内外先进银行的IT建设经验，中信银行的领导认识到，必须通过建设全行统一平台才能有效解决这些挑战；但是如何选择平台，如何建设平台，也存在多种建设模式，常见的建设模式包括：

         1）完全自主建设模式，但这种模式作为仅有200人左右的中信银行IT部门，是不现实的。而中信银行向来在IT项目建设上，也都采用合作开发商模式。

         2）完全外包或成型产品模式，这种模式好处是产品成型和稳定，同时投入和工期可控：但是缺点也很明显，很难适应中信银行总体IT架构规划，很难契合中信银行现用的IT能力和基础设施，容易药不对症。

         3）合作开发模式，这种模式好处是一方面，中信银行能充分吸收平台厂商产品的研发成果和经验，能有一套完整方法论来保证平台方向和质量，另一方面中信银行自身人员也参与其中，能提升平台契合度，使其符合中信IT技术架构的规范要求。但缺点就是项目周期和投入较大。

         最后，中信银行领导在进行充分调研和POC基础上，选择了合作开发模式。

实施平台之路

         中信银行在选择平台建设模式和厂商之后，在实施过程中，也充分遵守“总体规划、分步实施、持续发展”的原则，按照方法与规范、平台与工具、资产与知识、应用框架、项目推广五个维度全面推进和展开。（如图1所示）

 1 2 3 下一页 尾页

扫码即可手机
阅读转发此文