核心之争：松耦合还是紧耦合？

    因为极具重要性，核心业务系统被喻为银行的“心脏”。近三四年来，国内银行业纷纷开始了升级、更换、重新开发核心业务系统的工程，有自主开发的，也有寻找伙伴联合开发的，或者干脆引进吸收国外成熟产品。总之，大家不约而同地挑战自我——换“心脏”。

    但对于这个“心脏”的概念理解，国内银行业有着不同的看法。

    “核心系统即是综合业务系统。”这是国内银行业以前普遍认同的概念，综合业务系统的主要特征是： 通过银行交易系统实现会计核算和支付清算，在交易系统中加进了一些事中处理流程管理，包括信贷管理、风险管理、财务管理的部分流程管理，客户基本信息也放在系统之内，系统结构通常采用紧耦合的方式。

    而近五六年来，随着国外产品、经验、人才的全面流入，一些国内银行IT人士开始倡导“Core Banking”的理念。就连部分土生土长的应用软件开发商也被“西化”，加入推动Core Banking的行列，提出“瘦核心+大外围”的建设模式。

    一石激起千层浪，Core Banking的理念打破了综合业务系统对核心的理解，强调松耦合、模块化的“瘦核心”，通常指剥离了大部分事中、事后管理功能的交易处理系统，只是完成存款业务、贷款业务、支付业务、结算业务等银行基础产品和/或服务的账务等核心逻辑，是以客户为中心的按产品进行管理的交易处理系统。

    两种对核心的不同理解，体现出不同的开发和建设理念。

    对于银行而言，10年前开发设计的综合业务系统肯定需要改造。是推崇松耦合，把系统打散细分，还是继续紧耦合，以保持一个相对完整的系统，目前尚无定论。而这几年引进国外核心系统的银行，有的折戟沉沙、有的初战告捷、有的埋头蜕变，但不经历痛苦和思索不可能有所收获。

    中国工商银行信息科技部副总经理苏文力指出： “不能盲目针对核心系统内部各子系统进行松耦合拆分。一定要看清楚拆分的条件是否具备，不拆分是否就一定不能解决问题。没想清楚拆分所要付出的代价，就急于进行，很可能无法控制变化后的局面。”

    中国工商银行目前的综合业务系统脱胎于1995年，其间经历了不间断的版本升级，以适应业务与技术环境的不断进步，系统在不断调整中已经有了相当大的变化。其系统设计上的先进和高效多年来一直被同行所称道，系统背后对应了工行强力集中的管理风格。

    中国建设银行在2003年就确定了“分层松耦合多系统支撑”的总体应用架构，这是建设银行根据其多年来的经营管理模式、IT治理架构、IT系统开发模式，以及对业务变化的理解而决定的。

    建行信息技术管理部应用架构处高级副经理周乐说： “是瘦核心还是胖核心并不关键，关键是要区分清楚核心服务、核心交易和核心系统三个概念。”

    周乐说： “核心系统不宜实现变化大、产品周期短或功能相对独立的业务功能，也不宜处理流程控制和数据分析。核心系统要突出稳定、高效。目前建行的信用卡、个人贷款、理财产品、证券等都在核心之外实现，有些适合独立，有些适合归入核心系统。”

    业内专家贾凤军告诉记者： “综合业务系统的思路是典型的中国式思维，追求的是对业务功能和要素的高度归纳，而国外Core Banking的功能细分和松耦合源自演绎的思维，中西方思维模式的差异其实是文化上的差异，反映到系统设计理念的不同，其实并无对错、好坏之分，哪种方式能运用自如就是最适用的。”

    采用松耦合的架构，模块之间的通信变得更频繁，所以业界也有了信息服务总线的产品，它成为模块之间通信的中间枢纽，这个创意很好的产品，其实也带来了新问题。苏文力说： “系统全面松开后，信息服务总线成为所有模块间交互的‘核心’，你能否搞明白这个总线，遇到问题能否迅速判断根源，这与没采用总线之前有很大的区别。”

    苏文力认为，核心里面的东西是否值得分开需要评估，不能头脑一热就分了，需要衡量分开之后的模块之间的通信是否方便、资源消耗能否承担、稳定性和可靠安全性是否有保障。

    业务之变： 流程重组之痛

    核心之争源自业务之变。中国银行业这些年发生了翻天覆地的变化，没有清醒认识到变化本质的IT部门将陷入变幻的业务漩涡中，迷失前进的方向。

    除了核心之争，还有诸多矛盾萦绕在IT管理者的心头，也让银行管理层左思右想。“IT规划刚做完，业务新需求就打乱了规划，是IT规划不够前瞻性，还是业务发展突发性太强？”“系统建设时追求业务部门的局部最优，并不是企业的总体最优，如何找到部门与企业的最佳平衡点？”

    探究这些问题的答案，需要分析业务环境的复杂变化。曾先后担任花旗银行、建设银行总行的IT管理工作，现就任神州数码咨询有限公司总裁的曹志鹏将业务环境的变化梳理为三大类： “渠道多样化、产品多元化和以前后台分离为特征的流程重组，是这些年陆续发生的三种主要变化。”

    商业银行从单一的网点柜员渠道，增加到ATM等自助设备渠道，再到网上银行、手机银行、家居银行的涌现，呈现出渠道多样化的特点。曹志鹏说： “传统的核心系统主要是交易、结算、会计处理三个部分，是总行与分支机构进行清算和结算的系统，对总行的业务管理没有支持。各种渠道系统发展后，与原来的核心系统产生了矛盾，例如，如何划分系统边界、如何管理结算。”

    近年来，信用卡、投资理财、国际结算、中间业务等多元化产品创新发展，也对银行应用系统产生了很大影响； 以前后台分离为特征的流程重组对银行的业态将产生革命性的变化，由此带来两个明显变化： 网点转型和中后台集中处理。

    “ 传统的银行网点兼有营销、流程处理、管理、风险控制的全业务功能，对网点的业务员素质要求很高，前后台分离将突出网点的营销职能，把集中的流程处理和管理工作后移到专业处理中心。” 曹志鹏说，“通过中后台专业人员的集中处理，能够突破银行的扩张瓶颈，提高总体资源配置效率，还能通过流程优化达到减少风险的目的。”

    前后台分离导致了网点由全业务单元向营销单元的转变，而总行会成立更多的专业处理中心来承担流程处理的工作。近年雏形初现的有票据处理中心、信用卡审核中心、中小企业贷款审批中心这类的机构。

    “前后台分离只是大概说法，具体到每个业务都有各自的流程重组方式，分离的形式不一样，分离的时间有先有后，不可能一下都分开，但可以把公用流程先分离出来。”曹志鹏说。

    以前后台分离为特征的流程重组强调了专业分工，由此引发了银行对业务外包的需求。西方银行业的成功例子是将信用卡审核、额度授权等工作集中外包到印度等国处理，这种外包不仅是跨地域的，而且是跨企业的，这对银行的核心系统的设计提出了挑战，如果系统设计不能包容这种跨地域、跨部门，甚至是跨企业的变化，应用系统的修改工作会异常繁重。

    无论是网点转型，还是中后台处理的专业化集中，银行在组织机构设置、业务流程、数据管理、考核机制等方面都会发生巨大改变，无疑会对银行的核心业务系统，乃至整个IT架构产生结构性的变化。

    由于业务环境的巨变，银行的业务部门本身也发生了变化。

    “伴随着市场竞争、法人治理、产品创新、客户服务和风险管理的需要，银行业务部门的素质水平也有相应的提升，眼界更高，操作能力更强，业务专业化的趋势越来越突出。”北大青鸟商用信息系统公司副总裁冯明刚说。

    架构之眼： 整体布局当先

    业务的发展变化是必然的，也是IT部门所不能拒绝的。IT部门的命运是跟从业务的变化而随波逐流吗？

    回答是： “不”。

    正因为业务的变化繁多而无序，所以更需要一个相对不变的东西，IT架构的必要性由此而来。用企业级架构的眼光来看待和应对业务变化、IT建设，这是一种大局观。

    但是架构怎么搭，在行业内并没有标准答案。

    “银行竞争不能等都准备好了才动手，否则市场就丢了，这是IT开发面临的现实问题，某些时候只能先做出一个系统，然后再去优化和整合。这种变化是经常的，并不按理出牌。而架构的目标是能快速、灵活、低成本地适应这种变化。”周乐说。

    贾凤军说： “IT架构基于对业务发展与技术走向的深刻理解，在归纳业务要素的同时，处理好数据和功能的配合，架构对灵活性的要求必不可少。”核心系统究竟应该是瘦是胖、是紧还是松，首先是个架构问题，因为核心系统是应用架构中的一部分，不可能脱离总体讨论局部得失，探讨核心系统其实很多时候是在追问应用架构怎么搭？

    “国外银行业也是到上世纪90年代中才把架构的思路引进到IT建设中来。”曹志鹏说，“国内银行核心系统的设计背景是按照10多年前的会计统管，网点是独立业务单元来做的，目前需要重新设计。”

    贾凤军说： “架构设计要简洁，环节少，系统应该适度耦合，不宜一味追求松耦合，这样才能实现‘柔性IT’，让开发和交易处理都能够体现出一个‘快’字。”

    城市商行是近年来最活跃的金融群体，在由单一城市向区域化经营的扩张中，也产生了管理和业务上的巨变。徽商银行就是其中之一，为了应对变化，徽商银行也把视角对准了企业总体架构。

    徽商银行科技部总经理王勇说： “IT总体架构是银行IT规划的核心部分，是根据业务架构对银行的网络、数据、应用、安全和信息系统的总体集成等制定蓝图和实现方法，是由数据架构、应用架构和技术架构三部分共同组成的。数据架构是IT总体架构的核心，因为信息系统支撑下的业务运作状况，是通过信息系统中的数据反映出来的，数据是重要资源。因此构建IT总体架构时，首先要考虑数据架构对当前业务的支持。”

    企业级IT架构在国内银行的应用是从2004年开始的，作为国内银行业架构的先行者，中国建设银行的架构建设仍然在积极探索中。中国建设银行在2002年根据业务能力要求制定了IT整体愿景规划，2003年随之确定了“分层松耦合多系统支撑”的总体应用架构。

    据了解，建行应用架构处的职能一是总体定义全行的应用架构规范和政策，梳理应用系统现状和差距，明确系统定位和目标，定义系统能力基线等； 二是对项目开发方案的审核和规范，架构处会告诉项目组： 哪些在哪里做，哪些不能做，边界在哪里、标准是什么。

    “ 做架构一定要考虑企业文化和治理结构，要有一个与历史系统衔接的详细方案，有些厂商夸大信息总线产品的作用，容易让用户误认为安装了信息总线产品就把架构做好了，其实还差得很远。” 周乐说，“银行IT部门需要改变自己的是开发模式，传统模式是由项目驱动的，业务需求形成后直接进入项目开发，而新的开发模式应该在需求形成后有一个导入架构的步骤，经过架构的过滤和规范，项目开发才得以进行。”

    融合之道： 补课IT治理

    当前的中国银行业，正经历着业务之变、转型之痛，应对变化需要IT与业务的融合。在IT与业务的融合过程中，勺子难免碰锅沿，IT部门作为最了解银行总体运作的部门，更适合采取主动，但融合的过程中少不了银行管理层的重视和实际支持。

    IT部门是银行内部的特殊部门，不直接做业务，但又负责支持整个银行的运作，是所有业务部门的依托平台。这种特点造就了IT部门更容易站到企业的角度来考虑问题。但尴尬的是，绝大多数IT部门并没有被赋予规划银行未来、规范业务需求的职能，即使看到了有利方向，也经常是无力推动。

    “首先要根据业务规划把IT规划做好，这是IT部门与业务部门沟通的桥梁。” 曹志鹏说，“IT部门需要深究业务规划中的每一个细节，从中找出IT的原动力和发展方向。”

    苏文力说： “如果IT部门的运作方式是‘铁路警察各管一段’，设计、开发、测试、推广、运营各管各的，没有站到整个企业的角度来看对企业本身产生了多大价值，IT所发挥的作用将无法达到企业的要求。”

    据了解，建设银行的信息技术管理部成立了“业务条线”处室和架构处室。业务条线处室专门负责与业务部门的日常沟通，做到第一时间收集业务需求。而架构处室会跟业务条线处室密切沟通，根据业务热点和动向，提前规划，根据具体的需求提前给出方案建议。

    “比如今年银行的热点之一是前后台分离，架构处就要看它的本质是什么？在应用系统和架构上需要做哪些改变和应对，提前设计几种方案来适应未来业务部门的具体需求。”周乐说。

    工商银行于2007年成立了产品创新管理部，部门的职能之一就是对业务部门的需求进行整合，作为业务与IT之间的桥梁部门发挥沟通作用。

    还有一些银行内部率先成立了架构职能部门——通常是IT部门的一个处室，他们站在企业的角度看待系统建设，能够发现问题所在，但人微言轻，不可能直接纠正和改善。

    IT 部门和架构职能处室的尴尬，折射出的是银行IT治理的缺失。国外银行的架构部门大多由CIO来领导，由CIO直接在银行管理层出面协调业务需求与架构之间的矛盾。目前，国内只有交通银行、渤海银行等少数几家商业银行设置了CIO一职。银行作为国内信息化起步最早、水平最高的行业，IT治理已经落后于证券业和保险业。

    据了解，中国人寿保险股份有限公司早在2006年就建立了CIO岗位。该公司CIO刘安林曾强调： “这不是一个职位，而是CIO机制的建立，其核心目标是在企业内形成有效的信息化治理结构。中国人寿信息化建设是围绕着如何支持公司战略和目标的实现、支持公司经营价值链的有效开展进行的。”

    到2008年9月， 中国证监会则颁布了《证券期货经营机构信息技术治理工作指引（试行）》，同期发布的通知提出： IT治理是公司治理的重要组成部分，是证券期货行业信息系统的基础性建设，通过设计和实施IT决策权系统，妥善处理好企业的IT决策内容、IT决策部门和责任人，以及如何制定和监控这些IT决策的问题。

    而就在记者进行本次采访报道期间，欣闻中国银监会也发布了《商业银行信息科技风险管理指引》，指引中明确提出： “商业银行应设立首席信息官，直接向行长汇报，并参与决策。”“设立一个由来自高级管理层、信息科技部门和主要业务部门的代表组成的专门信息科技管理委员会，负责监督各项职责的落实，定期向董事会和高级管理层汇报信息科技战略规划的执行、信息科技预算和实际支出、信息科技的整体状况。”

    监管部门的导向为商业银行的IT治理创造了环境，但最终的落实还要靠银行观念的转变、制度的建立、组织机构的设置、激励机制的配套等全方位的执行情况。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。