银行IT架构转型

银行IT架构转型中国银行业的数字化转型才刚刚拉开帷幕，作为转型重点的银行IT部门正在经历从开发模式到组织定位的巨大变革。本文从时下银行IT广泛的敏捷转型开始分析，揭示了中国银行业面临的数字化挑战，分享了应对挑战的一些共识，同时给出了中国银行数字化转型的大方向。数字化挑战过去的3年时间里，我作为敏捷转型顾问，合作频次最多的，就是全国大大小小的银行。银行业IT这一波的敏捷转型，很多人会归因为互联网金融的冲击，认为银行业IT被迫从原来的内部职能部门走上前台，迎战外部市场的挑战。也有不少银行从业人员，对此持有不同看法：类似P2P这样的互联网业务，对中国的银行业还谈不上任何的冲击。在我看来，真正冲击中国银行业的，是以下两个方面： 服务渠道的变迁渠道从过去实体的网点向数字化渠道转移。注意，这并不是说所有的服务都变成了移动APP，而是所有的服务都会用某种数字化的形式呈现，比如现在到工行建行网点办卡都是通过一台综合服务机；交行几年前开始试点网点机器人，而招行已经在刷脸取款。由于银行之前是没有数字化部门的，所以这些要求自然跟IT挂上了钩。 FinTech的冲击技术突破正在改变业务形态。最近火过了头的加密货币（比特币）正是这样的技术案例，它可能对未来银行业务产生颠覆性影响。在欧美很多利用智能技术做征信的平台也快速崛起，替代了传统费时费力的背景调查。对比之前的传统银行科技，FinTech拥有非常大的不确定性，这给习惯于购买成熟软件产品的银行带来了不小的挑战。当然由于又是科技相关，所以这口锅自然也得IT背了。以上两点带来的变化显而易见，所以，无论提不提敏捷，银行IT都得转型。建立在支撑基础业务、保证业务稳定运行之上的IT部门，不可能自然而然演进成为“以用户为中心，思考服务体验，并保持对业界先进技术洞察”的新型数字化IT部门。下面就结合我过去3年中，近10家银行的顾问经历，谈谈这个转型中的挑战和可能的应对之策。稳与快我们辅导过一家外资银行，一上来就要求全球范围实施DevOps，“全面”敏捷。作为顾问，感觉很爽，改进起来气贯长虹。半年之后，已经没有不做敏捷改进的项目了，就连基于小型机AS/400的系统也都走上了DevOps的持续发布之路。中国的银行业可就不是这样一个情况了。我和业内熟悉的几个人，经常开玩笑说“喝茶就是悬在中国银行敏捷转型头上的达利摩斯之剑”高管们心里羡慕着互联网玩法的“小、快、灵”，脑子里却时刻担心着因生产事故被请去“喝茶”。转型需要经历烟斗曲线，当刚好处于曲线下挫点时，很可能因为一次事故而被全面叫停。一位银行科技高管曾经在内部会议上对我直言：“不要以为我不支持敏捷，正是因为我支持，所以才拉着你们跑慢一点”。团队里有顾问找到我说不想做中国的银行了，太纠结，犹抱琵琶半遮面。于是我反问这位顾问，为什么中国的银行不能像外行一样一步到位呢？是因为太保守或者太官僚？一时问得对方语塞。其实，外行比起咱们可能更保守，生怕有一点负面消息，有的机构更庞大，更官僚。那么是什么原因，让我们中国的银行不敢“全面”敏捷呢？就我目前认知，中国银行和外资银行有两点显著不同：一是中国银行集中精力办大事儿的构建方式；二是中国银行IT的历史定位。如果我们对比中外银行的业务架构，会发现咱们的银行在业务设计上非常集中。这样的集中思路投射到IT系统建设上也是非常明显的：一般会考虑一套系统支持多条业务线。经典的例子是咱们的银行一般只有一套清算、核算平台，而外行每条业务线可能有自己的独立平台。集中建设的好处自然已经体现出来了，短时间我们就构建起来了一个相对完善的金融电子平台，但带来的问题就是系统非常复杂。(图：中外行典型组织结构区别)在敏捷转型过程中，有两个领域的复杂度是让我头疼的：电信和金融。大家可能想象不到，打通一次电话和完成一笔转账都要涉及近亿行代码！一条业务需求动辄要求修改十几个独立应用！咱们集中建设的银行系统显然不是随便就敢改的，早期即使在银行大型机系统上引入迭代开发都是很困难的。而这些系统往往又是银行的核心主干，任何小错误都可能造成致命的连锁反应。在IT定位上，从国有五大行到各大股份制银行，基本都将IT归到了科技部下面统一管理。从组织结构上，可以看到IT的定位是一个共享的内部服务部门，或者说，是一个成本中心。最初的IT只是管理一些购买的商业软件和平台，并没有作为一个强自研能力的组织存在。银行IT的自有员工和外包人员比例，普遍都在1：6左右，一个主要的IT系统可能也就能投入两三个长期自有员工。到了现代，这个以科技为核心（TechCore）的时代，这样的人员配置显然已经捉襟见肘了。以上两个因素，从技术架构和人员架构两个方面制约了敏捷的大规模推广。所以，银行想要“快”起来，往往不那么容易。各家银行的转型，都会选择相对新的技术领域，或和用户结合比较紧密的应用开始试点。而初期的转型目标，也会设定为“探索在现有约束条件下，如何进行敏捷模式落地”。最终，大多数银行都会走向“双模”：明确哪些系统和应用更看重业务表现的稳定性（采用瀑布模式），哪些更看重市场变化的响应速度（采用敏捷迭代模式）。（图：源于Gartner总结的双模IT架构基本示意图）理论上讲，“双模”只是一个过渡状态，这种方式也受到了不少专家的批评。“双模”可能会掩盖掉一些更深层次的问题，比如系统快不起来，根本原因其实是架构质量问题。从科技的发展趋势来看，确实止步于“双模”是不明智的，微服务化和平台化架构的逐步成熟会让以前稳定第一的系统也快起来。但就目前的约束来看，“双模”是已有成型建制银行IT的必经之路，其意义更多是在组织里植入管理不确定性的能力，从而构建对市场变化的快速响应能力。效率与响应力“唯快不破”是互联网服务发展的必备条件，而这个“快”其实是被很多管理者误解的。这个误解也造成了银行IT管理者们对“快”的提法有些许反感。这个误解的根源，在于对效率和响应力的混淆。如果我们正确分析互联网成功服务的特质，就会发现他们根据市场变化推出和改变服务的速度特别快，而这个快很明确是在响应力上。举个日常生活中的例子，作为干洗店的客户，我们其实并不关心干洗店内部的效率问题（例如单位时间处理多少件衣服、干洗机的利用率等），我们关心的是干洗店能多好多快地把我们衣服洗好。互联网时代给银行业带来的一个明显转变，就是从过去“以自身服务为中心”，到现在“以客户为中心”。从前在以自身服务为中心的时候，我们的管理方法及技术实践都是围绕效率来做的；到了这个时候，显然我们必须用客户的视角来思考问题，所以就需要更加关注响应力。当我们在追求效率的道路上走到一定程度，就有可能伤害响应力。比如为了干洗机的利用率，我们批量分类客户的同类型衣物放一个批次，显然这样的做法在订单达到一定数量的时候，会减缓每个客户的交货时间，让客户等待更久，伤害了对客户的响应力。同理，这也是为什么在敏捷组织里，我们提倡少分角色、跨职能协作。当我们的分工过于细化时，对外部的变化响应能力就下降了。在传统银行IT系统里这样的情况是很普遍的，一个业务需求需要分解到十几个应用模块完成，而每个模块都只能由一个专人完成。理解响应力的重要性并不难，但实践高响应力的管理却是相当困难的。银行业是一个重流程管理的行业，银行IT显然也继承了这样的基因。重流程标准化的管理方法，造成大家习惯性地进行自身局部效率的优化，实则增加了端到端的响应时间。我经常举一个发生在我们每天日常工作中的例子让大家意识到这个问题的严重性。你是一位IT管理者，小王是一位认真负责的开发人员。一天他告诉你，现在项目A上他的工作进入尾声了，接下来只需要占用他一半的工作时间。这样的情况下，小王希望请示接下来的工作安排。在实际工作过程中，大家会赶快告诉小王启动项目B的工作，或者分配给他项目C的部分工作。假设小王启动了项目B的工作，很快他发现需要小李协助才能开展分析工作，而小李这个时候正在项目A上忙得不可开交。接下来有意思的事情就发生了，小王显然会要求小李配合，而这事儿如果真正发生了，显然就耽误了项目A的工期，那么项目A的完成时间就要推后了。小王和小李有可能找到你来请示工作优先级，然而，可怕地是，在你的意识里，会觉得这显然是“加加班”就能解决的问题！于是，整个IT产业陷入了做不完的需求和越来越严重的内耗！（图：小王工作安排示意，由于项目B的引入工作越来越多，成效却变少了）实际上，如果我们认识到项目A的关键要素是快速推向市场，那么我们给小王的安排应该是让他继续专注于项目A，看看什么地方能够协助团队尽快完成项目。这个认知的转变是困难的： 作为管理者，要放弃过去对人员利用率的执着，理解利用率和响应力不是正比关系，在一定阶段后甚至和效率也没有正比关系。 作为员工，要放弃一个萝卜一个坑的工作模式，保持持续学习和跨职能工作的能力，把自己构建成一个T型人才。这个案例中，小王要能够帮助项目A的其它工作，就要求他具有开发之外的其它能力，比如测试。在这样一个时代背景下，银行IT的敏捷转型，实际是基于以用户为中心的根本原则，加强整个组织的响应力。如果大家还在以“一个功能实现是不是更快了”来度量和牵引转型方向，那么请尽快调整到“面向市场和用户的端到端交付指标”上来。业务与技术懂业务是银行业人员晋升的关键因素。曾经在一次银行IT中层管理干部的培训上，我让大家举手表决是向业务方向发展，还是向技术方向发展，结果是全部都选择的业务方向。不可否认，银行业务的复杂度，要设计一套IT系统需要很强的业务理解。但数字化时代，技术成为了越来越重要的一个支柱，各银行组织如果不能快速构建技术人员的职业通道，必然很难在数字化上取得真正的收益。我们从两个方面来看看中国银行业技术方面的挑战。第一点是没有足够的技术封装。经常看到一个有意思的现象是，银行业务人员会看数据库，每一张数据库表就映射一张物理世界的报表。这样的设计结果往往是一张银行数据库表可能有好几百个字段。一段时间内，这样的设计是很流行的，因为沟通需求和最后验收都会相当顺畅，直接看数据库表就完成了技术和业务的交流。隐患就是，数据库根本就没有模型可言，修改任何的数据项都需要波及整个系统，所以大家就倾向于一开始就把所有的数据项全部列好，如果不确定就先留下一些空字段以备后续不时之需。由于根本没有数据模型封装，看似业务上便于理解的设计，到后来也会因为冗余严重、耦合紧密而变得难于理解，或根本不可维护。只要是在基于如此架构上工作过的IT人员，就特别能理解，“为什么弄懂一个几千行的存储过程，需要花几天时间”。没有封装的结果，就是每个维护修改者都需要理解已有系统的所有复杂细节。这也是为什么我们在银行核心COBOL系统中，会看到大量的冗余代码与其修改已有的程序，还不如忘记已实现的业务，为新增业务重新开发。第二点是没有开放的技术生态。银行业经常把基于Java这样现代语言的开发称之为开放平台，与之对比的是传统基于大型机和小型机的封闭开发环境。最近还就开发效率问题和一个老牌银行技术人员进行过讨论。一个观点是，基于成熟封闭环境的开发一旦上手其实效率可以很高，对金融行业来说更加模式化，并且硬件保证了高性能和稳定性。于是我也花了不少时间，来研究这样环境下的开发模式，比如在绿色的传统命令界面上完全采用键盘操作，从代码管理到部署都是私有的平台和工具。从我的角度来看，传统封闭开发环境有以下几个致命伤： 技术设计的表现力不够，造成可维护性差。长期下来，系统修改十分困难，成本随时间爬升很快。 不能够利用很多已有资源。从开源到云服务，实际上都是开放生态中的可用资源。开放技术的全球知识库早已超越了任何一家企业可以提供的技术服务。使用这些共享资源的门槛，就是需要加入到这样的开放生态中去，随着环境的发展而持续演进。