深度 | 新一代银行IT架构：新在哪，架多高，构啥样？

一、新一代银行架构之“新”在何处

当前国内银行正处在业务转型期，业务产品与经营结构在不断调整。作为银行的IT部门，一方面在积极配合业务进行IT系统的建设，另一方面，将科技作为对全行业务的促进，进行了比较多的新的尝试。于是，“科技转型”、“银行架构转型”便也成了科技部门的日常功课。

笔者作为一个IT从业人员，又是为不少的银行提供“科技规划”、“IT架构规划”咨询服务的顾问，就个人观点来看，企业的IT架构本身是“朴实”的，没有优、劣之分。单纯从架构上借鉴、学习并不能快速有效地提升银行的IT或者业务经营水平，充其量仅仅是同业之间比较之后补齐“标配”而已。我们为银行数百个系统建立IT架构“视图”，是为了更好地管理IT系统，发现潜在问题，进行优化。做架构的主要方式也是为了给银行IT系统分好层、分好大类，让各子系统的性能特点能够得到体现。

很多银行高层见到笔者之后，经常会首先关心，什么样是最先进的银行架构？这个问题很难回答。应该说，根本不存在某一种最先进的架构，架构没有所谓的先进落后、优劣之分，只有合适不合适。每个银行都有每个银行的特点，比如可以去IOE，也可以继续用IOE，做出的具体选择取决于行里科技的力量，取决于行里的技术储备、基础设施。分布式架构也一样，银行做分布式架构就必须要有懂分布式架构的团队和专业人员，银行要能掌控这种架构；如果掌控不了，分布式反而会变成一个全行灾难性的问题。

以下就“银行架构的发展”，先提几点观点：

第一点，如果就IT论IT架构，可谈的并不多。IT架构是一个结构，并不是受技术发展的影响而变化，一个“好”的架构除了密切体现业务变化，还要考虑到“实用”。我们参考和学习别人的宝贵经验，也是要重点关注这两点。早些年国际知名的科技咨询公司很受银行青睐，是因为中国银行的很多业务都在和外国银行学习，如花旗银行、富国银行、荷兰银行，而国际咨询公司能够把这些先进经验带进中国来。但中国银行业发展到今天，从国外能学习的东西已经不太多了，这时候同行之间、本土经验的学习借鉴就变得很关键。

第二点，“新一代银行架构”现阶段有一个重要的发展趋势。以前，银行在选购信用卡、现金管理等系统的时候，很大部分都会找第三方厂商选型、实施。在现有厂商里选购IT系统会造成一个矛盾的局面：一方面银行想找一个口碑好、市场占有率高的厂商，这样产品比较成熟标准；但另一方面，银行又要求IT系统有本行特色，能够支持业务的特色化经营。因此，近几年一些银行开始放弃省事的“一站式服务”，而花心思做更深层次的业务以及IT设计。银行逐渐意识到，银行的组织形式、业务流程都在变化，IT也要做出相应的调整，不能套模板、一劳永逸。可以说，新一代银行架构之“利”不仅仅在技术，更多的则在业务，在银行对科技与业务的关系的理解。

第三点，银行对科技的定位从支持向增值发展，很多银行都在考虑如何利用科技做自己的竞争优势。等银行科技发展到高阶之后，才会获得战略洞察和转型的能力，这就要求银行架构要有“前瞻”。战略洞察是指在设计一个产品的时候，预判出未来迭代时的需求，比如说苹果在设计Iphone7的时候，其设计理念、内部性能也许已经达到了Iphone9的水平，只不过在生产时出于对市场成熟度，供应链、材料成熟度等因素的考虑，规划一个从7到9迭代的过程。银行的科技和业务只有很好地融合，才能够实现战略洞察，而等达到这一阶段之后，才能说要去做科技转型。

二、新一代银行架构的整体目标

虽然没有一个叫“最佳实践”的模板，但银行在设计新一代银行架构的时候，基于外部环境和业务需要，有几点能力是需要着重体现的。这几点不仅是科技的能力，也决定了银行的整体能力。

其一是合作和协作的能力。这两年大家都在谈生态、谈场景，朴素点讲，就是合作和协作，银行和产业之间的协作、和金融机构间的合作、和金融市场的合作。要使合作顺畅，业务一旦发生，IT就要能跟得上，这就需要IT架构具备相应的可接入性和业务弹性。

其二是敏捷。敏捷经常被认为只是IT开发的任务，其实不然，业务和IT都需要能够迅速地根据市场变化进行调整，而这种能力需要架构支持。举例来说，核心系统的产品设计，以前是以参数化设计为目标；但核心系统是一个交易系统，从业务上来讲，是应该跟着客户和市场情况变化的，个性化的银行产品可以很复杂多变，很多银行的现有核心系统并不能支持。所以说，首先产品的设计需要敏捷，能够根据市场快速变化，相应的架构也需要敏捷，才能满足业务对敏捷的需求。

其三是对新技术的“兼收纳并”。大家在这些年发展的云化平台、移动化、大数据、人工智能等并不是科学技术的革命性的创新，更多是来自于计算机产业发展后，一部分技术被剥离出来单独发展，对应用开发模式的支持越来越成熟。就个人观点来看，所谓的技术创新，在大多数银行科技的视角来看，主要还是体现在和业务的结合上，而不应是某种技术本身。

最后就是业务经营全数字化。不是说现在业务系统都跑在计算机上就叫数字化了，银行应有对数字化更深层次的应用，比如网点柜员排班、每个ATM里应该放多少钞票，都能通过数据去计算、模拟，得到最优解。

2016年银监会发布了十三五规划和一些指引，列出来的都是银行普遍欠缺的能力。比如，以应用架构来说，银行缺少“互联网+”渠道。有些银行做了网银、直销银行就觉得自己有了互联网渠道，这是误区。做渠道首先要有策略，清楚这个渠道是要达到什么效果。有的银行在线上门户的开发上投入了很多，其实是缺乏渠道策略。大家都知道现在的趋势是“移动优先”，银行与其投入很大的代价去升级“网银”，反倒不如花些时间去研究微信小程序，把银行服务嵌入进去，比起网站来，这样和客户能走得更近。又比如银行现有应用架构无法支持多元化、一体化的金融服务。现在银行业态多元化，不限于传统银行，还有直销银行、消费金融，一些银行还成立了数金公司，传统的应用架构肯定需要转型。再者，在安全方面，现在银行逐渐从独立自有数据中心IDC走向互联网，网络安全上进入了“非安全区”，相应的安全策略、方法和手段就愈发重要，这也是目前很多商业银行的短板。

今年起，很多商业银行进行内部体制改革，利用IT大集中，提出了发展“科技与服务型”总部，业务发展的权力更多下放到分行，同时利用总行的科技转型，对各分行提供业务支持与精细化管理。以前总分行的关系是，总行给各分行定业务指标，分行在落实过程中遇到问题上报总行，总行包括科技部再去处理解决。这种模式在今天已经跟不上银行的发展了。举例来说，今天的零售银行和互联网银行线下网点很少，没有那么多的客户经理和信贷员，更多是靠互联网与客户互动，也就不会产生很多问题反馈。分行作为区域业务经营的主体，在不和客户产生面对面接触的情况下，如何获知客户需求，分行产品如何交付，是通过电话还是微信，产品能否跟得上需求的变化？这就要求银行总行提供一个强大的后台，业务和IT能力都足够强。

过去两年，笔者曾经给一些全国性的股份制商行规划过IT架构，发现银行总行的总部职能在变，能力重点往“小管理、大服务、大平台”方向发展。小管理是指只对战略绩效、目标和预算、风险管理、人力资源（人员编制）等必要职能，在总行牵头统一管理，分行配合工作。大服务是指总行为分支行等提供专业支持和建议，帮助分支行提升经营效率和效益，包括但不限于产品服务创新及以下领域的工作方法和标准体系：数据分析、客户经营、精准营销、渠道运营、风险控制等等。相应的，IT要做大平台，总行搭建平台和工具，把原来在前端发生的业务处理、数据处理都放到后端，为分支行提供经营、内部沟通管理提升需要的渠道和协调机制，促成协同合作，提升运作效率。

在全国各地走访分行的过程中，笔者经常会听到分行说，总行只顾着下绩效指标，却没有提供配套的工具和方法做支撑。分行连自己的客户在哪里都不知道，也不知道如何建立联络。分支行也是银行科技产品的一类用户，对于这类用户，总行科技建设的目标应该是“水到田头”，无论是数据还是功能，一线部门应该随时需要随时就能用到，利用总行提供的这些“武器”，来和客户面对面接触，获得客户、完成交易。具体场景例如：银行对公业务已经不再是简单的代发工资、公司存款，银行要给公司提供复杂的金融解决方案。一线人员有丰富的业务经验，可以设计出复杂的方案，但必须依赖于后台系统去实现，那后台是否有能力支持前台的设计和交付，就是总行对分行“大服务”的体现。

我们称科技平台为“大平台”，因为其面向的群体是多元的，并且要考虑多种可能性。举例来说，客户有钱的时候买了理财产品，没钱了又要找银行贷款，但理财没到期，那他能不能用理财产品做抵押去贷款？从客户的角度看，这个需求很合理，但从银行业务的角度看，应该属于哪个部门的业务？所以说，银行已经不能再把自己看作简单的存款部门、信贷部门、风险部门。又比如说，在设计风险的时候，要考虑到成员行的管理机构和业务部门、其他同业客户、第三方合作厂商等，这样多维度、多用户视角去考虑，不能只站在单个业务条线的角度去审视平台。

现在银行独立的风险机构其实控制不了操作性风险，更多是在做事中和事后风险检查。想要控制操作性风险，风险官要前置，嵌入到业务部门里面去，在业务设计、流程设计的时候就考虑操作风险，包括数据风险、道德风险等等。现在很多银行这种机制还是缺失的。

三、新一代银行架构的构建思路

前文已经提过，购买现成系统正在被视为一种“偷懒”的行为，第三方系统的堆砌不会形成银行的核心竞争力。一个好的架构离不开对银行业务的底层理解和顶层设计，这一认识对于银行科技来说很关键。在此基础上，未来商业银行的应用系统建设需要在平台化、组件化、服务化、企业化等能力上进一步加强，打造开放弹性、高效灵活、安全可靠的新时期应用架构。

思路一：业务组件化、微服务化

组件化是为了快速叠加。IBM曾经提过一个概念叫“乐高银行”，是指银行业务系统可以做组合叠加，从而快速构建出新业务。服务化是指把系统拆成服务，这是渠道对架构提出的要求。从前些年的SOA到近两年的微服务，服务粒度在逐渐拆分到可以跟APP、跟一些交互场景直接对接，而不再致力于做某种大块业务的交易接口。

此外还有企业化，是针对以前银行系统的条块化建设而言。今天银行的客户信息管理要企业化，要做到全行层面，营销线索要做全行层面，风险管理也是全行层面，产品也是全行的，所以银行信息系统也要做到企业化。

思路二：全渠道建设思维

“架构转型”的另一个关键领域是渠道。前文已经提过，做渠道首先要有渠道策略，不应该一上来就找做网银、做手机银行的厂商，罗列一些交易功能，让他们去做出来；这是面向功能的设计，不是客户思维。银行应该先把各渠道统一成一个渠道的总体概念，然后制定相应的渠道策略。具体来说：

1、网站：网站的作用是企业形象宣传，那网站上应该有些标准的功能，如客服入口，让客户能够触及银行，当出现信任上、品牌上的问题时，可以通过这个渠道获得需要的信息。

2、短信：短信的作用是发布通知。

3、手机银行：手机银行现在其实是个四不像，各种功能和场景都混在一个APP里。对于手机这个渠道，银行应该告诉客户，每个场景里可以用手机端做什么，每件事应该有对应的APP去做，而不是一个统一系统。

4、网点：网点这个传统渠道，目标不是取消，而是做轻网点，提升效率，提升服务能力。虽然年轻一代已经习惯了线上操作，但年龄大的客户可能还是需要在线下操作，所以网点应该针对这样的客户群体做相应的设计，至于年轻人，由于不是网点的主要客群，其需求反而可以放在次位。

上面简单讲了渠道策略，渠道还要考虑渠道定位、渠道运营，比如根据银行的品牌形象进行网点改造、线上布局、客户回馈等等。

有了这些顶层思考、把各种渠道看成一个整体之后，才能讨论IT设计的渠道协同。渠道协同应用位于各个渠道系统以及后端业务系统之间，实现多渠道在业务流程中端到端的协同和信息共享。多渠道协同服务，共同参与与客户接触的生命周期，包括需求产生、营销、签约、交付、服务和沟通反馈。同时多渠道协同营销，利用平台加强在各个客户接触点的精准营销能力，实现营销线索在渠道间的适时推送和转介。

现在做渠道讲究“移动优先”。从技术上看，像ApplePay、扫码支付、无卡预约取款、扫码取款等，实现起来其实都很简单。渠道端的设计不全是基于功能，要更多地从用户体验出发，用户会不会觉得这家银行很cool，是不是面向年轻人的银行，是不是有更好的手段去支持客户，而不是一些死板的功能陈列。所以移动优先更多要从策略上理解，不只是工具手段上的换代。

思路三：混合型应用集成

应用集成技术的使用也是要分情况讨论。应用集成技术在商业银行中的应用经历了一个螺旋发展过程，从六七十年代的单机应用、无集成概念，到八九十年代“大集中”，到现在又在讨论SOA、分布式。其实每家银行基础不太一样，也不是互联网银行，传统银行可能只是需要企业服务总线，把大量的异构系统，信贷系统、报表系统等，向总线进行服务的包装、协议转换。像互联网金融这种同构的信息系统，现在流行做分布式架构，可以很好地提升性能。所以当前银行的服务总体规划，只要不是近三年内新成立的银行，大多数都适用混合型，即保留现有的SOA架构，也建立面向分布式的架构。

思路四：交易核算分离

新一代银行架构应该做到交易核算分离。以前银行就是管账的，所以有核心系统记录交易。但现在银行要做业务经营和产品经营，这样就出现了两本账：一本财务账，由总账系统去承担，管会计分录、套账等等；另一本是业务账，应该由业务系统承接，记录各个产品卖出多少，赎回多少，手续费收了多少，计息产生了多少等等，但现在很多银行还做不到记业务账。虽然银行业提产品工厂、产品全目录的概念已经不下十年了，但是很少有银行能真正能说出本行到底有哪些产品，每个产品卖得好不好，某个产品是不是应该优化，或者干脆就不卖了。所以我们要做交易核算分离，要建立业务系统记业务账的能力，才能更好地实施精细化管理运营。

思路五：发挥数据资产价值

完善大数据平台，并建立数据资产使用体系。大数据平台本身并不难建，很多厂商都可以给出解决方案。数据仓库现在很多银行也都已经建立，业务系统数据经过数据仓库，方便做数据的存储、集市和分析。对于一些非结构化数据，比如前台传到后台的影像数据通过OCR扫描之后产生的非结构化数据，以及渠道端涉及到客户行为的非结构化数据，目前应用还不是很明朗，但是概念已经建立起来了，所以现在在数据仓库之外，还要建立非结构化数据的处理系统。在两者之上要有统一的处理服务，把非结构化数据和结构化数据都变成相应的一些数据提示，去丰富银行数据的维度。

然而，大数据平台建立的关键不在此，在更上一层。数据是资产这个概念已经不新鲜，现在银行都认为数据是资产，也羡慕阿里之类的电商在用数据赚钱。银行的数据要比他们好得多，但银行不会去变现，不会用这些数据去产生价值，为什么？是因为在面向应用场景、面向数据使用的层面，银行的能力没有建立。

这里的能力不光是科技能力，也包括业务能力，业务部门对数据没有想法，没有行业洞察。比如说，业务部门没有想过要弄清楚银行的存款账户规模可以分成几大类，0到1万、1万到5万等，每类有多少人，年龄层次分布什么样，消费行为、理财偏好什么样，而针对这些人的偏好，银行又应该如何触及他，怎样进行营销、提供服务。业务部门自己没有完整的想法，就很难产生数据应用。所以“数据是资产”的资产是有的，但缺乏数据的应用体系。

影响数据作为资产发挥价值的另一因素是数据质量。现在很多银行的数据质量很差，等真正需要应用的时候，才发现很多数据维度缺失，需要通知业务部门重新进行采集，通知科技部门进行补录、完善系统，这样就极大地拖延了项目周期。所以，不论顶层业务部门是否有设计，从科技部门角度来讲，要建立大数据平台，在数据标准、数据治理环节，一定要花精力去打好基础。

其他思考

现在一个热门技术叫人工智能，听起来很科幻，人们的想象可能是用机器人去替代网点柜员，但目前光语音识别技术水平就还未达到应用级别，不具备现实场景中的应用能力。更朴素的说法应该叫认知技术，本质上是由计算机对数据进行分析、挖掘和认知，进而指导业务的决策。认知有三个层面，互动、发现和决策。通过互动产生数据，通过分析数据发现、挖掘机会，发现机会后进行模型计算，把机会从数据变成具体的行动，把行动内容提供给业务部门进行决策。

最后来谈谈互联网金融，或者国际上所谓的“平台+服务”。这里的平台和前文讨论的银行架构平台化不是一个概念，它更多是叫开放平台。现在很多银行在做产融、融融合作，主要通过单点对接的银企直联、银银之间同业的专线连接。但随着银行跟国际民生、跟客户的关联越来越紧密，单纯靠点对点的连接已经很难满足合作需求，因此要建立开放平台。以花旗银行为例，花旗从2014年建立了APIs，把银行的很多金融服务做成API的方式，发布到公网上。这样做需要强有力的后台支撑。第一，银行要有API的管理和安全策略；第二，要有API的社区，因为其他开发者在开发过程中会需要一些支持；第三，API的承载问题，传统的银行技术架构较难支撑，更多是通过混合云的方式。API是一个入口，是其他机构和银行对接的入口，对于这种入口的管理，银行必须谨慎。

四、总结

本文探讨了新一代商业银行IT架构的建设问题，主要观点有以下几点：

1、架构是一种交互语言，是业务和科技之间、执行层和决策层之间对话的语言，讲架构只是为了把其他问题讨论清楚。

2、架构没有对错，没有绝对的好与不好。在进行同业学习借鉴时，应该去观察每个环节的优秀实践，如营销、数据、平台建设等方面，借鉴别人的经验，但最终要融入自己的银行架构里面，成为自己的东西。

3、科技和业务部门应该多投入精力，共同从上到下梳理本银行的战略，只有这样才有可能形成一个属于银行自己的支持特色经营的IT平台，业务也才能真正和IT做到融合创新。

以上是从一个咨询顾问的角度去看银行架构和银行转型，希望能够给银行朋友们一些启示，也欢迎大家留言发表自己的看法、共同讨论。