“拆烟囱，搭积木”，广发银行的科技“战役”

2014年12月底，广发银行信用卡中心系统部对内提交了一份规划报告——建议开发一个独立于手机银行App的信用卡App。

彼时，不少同业银行已有独立的信用卡App，潜移默化间，手机App似乎已成为信用卡主战场。

对于这份报告，广发银行信用卡中心决定，“参考同业经验，加快建设。”

一年多之后的2016年7月，广发信用卡官方APP发现精彩应运而生。

但是上线一段时间后的发现精彩APP，遇到银行APP当时的普遍难题——与互联网公司的APP产品相比，用户体验不佳，启动时间长、兼容性差、内存占用高等问题突出。

于是，广发信用卡内部决定对标互联网APP，做出一个业内领先的信用卡APP。按照设想，APP要用新互联网思维和技术，也必须有和优秀互联网APP类似的用户体验 。但这一目标在当时的银行架构下，研发人员即便全员“九九六”也难以办到，唯一的道路只有彻底更换App框架。

经过摸索，广发信用卡APP的移动框架最终选择了脱胎于支付宝的移动框架平台MPaaS。他们看中了其运营分析能力，客户无感更新，极高的到达率，可以按照时间、地域以及机型多条件试错等多方面性能。

与此同步，广发开启了中台架构转型，引入企业金融云技术和开源框架，使用分布式架构和服务化，按业务领域构建了互联网业务中台，成为了业内最早构建中台的银行之一。

落地中台两年之后，广发卡研发运营总监张宁东透露了一组数字，发现精彩APP 3.0，其平均启动时间0.52秒，ios闪退率0.04%，卡死率0.01%。并且完成了生产环境线上全链路压力测试，峰值大于4.5万TPS，交易响应小于50ms，成功率大于99%。

另外体现在运营数据上，发现精彩APP的当前用户量接近4500万。2019年双十一，发现精彩App当天交易额突破了110亿，同比增长近两成。

银行客户端之间的大战肉眼可见，而潜藏水面之下的，是银行技术架构和组织架构的快速迭代。两者互为表里，构成了当下银行在金融科技端的进化脉络。

“烟囱” 亟待打破

要想理解银行的中台架构转型，需要了解转型之前的样子。

“烟囱”是形容包企业it架构的经典比喻——每个业务线由不同的开发团队独立建设，技术栈不同，且互不关联。此架构的好处就是可以互不影响地独立部署迭代，但一旦同业务领域的产品多了以后，就会出现多个雷同的烟囱。

有银行业人士总结了烟囱架构的硬伤所在：

成本高，动作慢：早期使用烟囱架构能够快速搭建系统，但随着业务复杂，会出现极大的集成和协作成本，同时也抑制了创新。

经验无法共享：把能力留在一个烟囱里，无法跨烟囱共享；稳定性差，质量参差不齐：有的烟囱高而不稳，有的矮而变僵，遇到外力很可能折断。

总而言之，烟囱架构更多的被建设成为一次性单产品的系统，不同烟囱之间的数据是没有联系的，也很难产生联系；系统的公共组件也很难复用，每次都要重建。

在银行业务线较少且较独立的阶段，该架构足以应付。但银行业如今面临的同样是百年未有之局——金融应用场景越来越多，小额交易频发，交易量不可预知，“秒杀”成为新常态。金融服务、业务推广，社交和客群联系等等都汇集于APP。

潮汐式的系统压力以及流量的不稳定，对IT资源的弹性供给提出了新要求，烟囱架构势必力有不逮了。

广发彼时的架构痛点正在于此。信审、催收、贷后处理、数据分析等均各自拥有单独系统，烟囱林立。

张宁东对此印象深刻，回忆起当年的架构时，其坦言，随着App功能的错综复杂，会联系到三四十个外围系统。牵一发而动全身，每一个新业务上线，所有的数据系统全部都要改一遍。

这一矛盾鲜明体现在业务与研发之间的“纠葛”。当业务人员评价研发工作时，他们常常会说“慢”，“非常慢”，“几个月前提的需求还没有做完？”；研发人员则回复“需求质量太差，想要什么说不清楚”“总是变，当初需求说明书就是这么写的”。

日常“纠葛”只是一方面，对于研发人员来说，此次面临的更大挑战在于，一旦烟囱架构出现失灵的征兆，花再大的精力“修补烟囱”就可能成为南辕北辙之举。

“拆烟囱，搭积木”

确定架构转型方向是工作的第一步，广发的选择是中台架构。

业内普遍认为，中台概念起源于2015年马云带队参观的芬兰SuperCell公司，该公司只有100多人，却开发出了《部落冲突》等热门手游，2016年被腾讯以86亿美金收购。

其中的奥妙是，该公司从组织架构到系统架构层面采用了小前台大中台的战略,本来就不大的公司被分成若干个小组。此举可以快速决策、研发、并把产品迅速推向市场，而游戏引擎、服务器等后台基础则不需要操心。

此次拜访后的半年，阿里开启了组织架构的全面升级，组建“大中台，小前台”的业务体制。

简言之阿里的中台转型，即是将技术力量和数据运营能力从前台剥离，成为独立的中台，包括搜索、共享数据等事业部，为前台电商事业群提供服务。从而前台得到精简，保持足够的敏捷度，更好地满足业务发展和创新需求。

这一思路正与广发彼时的想法不谋而合。

与电商的业务逻辑类似，银行也有很多能力固定不变，比如账户能力、支付能力、认证能力等等。架构的改革，简言之就是将这些能力抽象出来，封装成一个个能力的模块，在系统平台上沉淀、集结、输出和拼装，当碰上新业务需求时，银行的系统就可以像搭积木那样迅速的构建。

由此，广发内部终于确定了中台架构转型方向，但是新问题接踵而至——如何将电商中台落地银行。

与电商业务不同的是，电商业务的同质化相对更加明显、业务流程也基本一致，但是银行不同产品之间可能存在流程上的很大不同。

更大的差异在人员组织架构层面。电商目前大部分都采用了阿里的组织架构，分为前台事业部和中台共享事业部的组织架构，银行大多按照传统业务线进行划分，多层级、多部门的特点明显。

这也决定了广发的IT部门无法原封不动照搬阿里金融云的产品结构，既需要重新组装技术架构，也需要更新人员组织架构。

据张宁东回忆，广发内部首先做的事是调整人员组织架构。建立了独立的中台产品团队和中台研发团队，负责科技能力建设。紧接着，广发整个互联网中台部分都被分成若干个问题独立进行建设，独立进行研发，同时保证它们可以被所有的应用调用、复用。