银行要跟风中台战略吗？

作者：费伟伟
上海华瑞银行数字银行开发中心

前言

今年突然发现所有的技术论坛或者大v的博客都在讨论中台，突然间中台这个词成了技术热搜词，对于很多互联网公司更是都将系统的名称由原来的XX平台XX中心改成了XX中台，中台并不是简单改下名字，也不是最近一两年新出的概念。笔者最早听说中台这个说法是在2016年，当时在一家电商公司，当时公司内的系统在进行全面的中台重构，对中台也是有一些自己的理解，网上大部分关于中台的文章都是互联网公司的，因为笔者在银行IT也干了将近10年，所以结合自己对中台战略的理解发表下目前的传统银行是否需要跟风中台战略的观点。

什么是大中台

传统烟囱架构的硬伤

在介绍什么是中台之前先探讨下传统烟囱架构主要的问题，虽然现在的银行大部分都进行了核心系统拆分和平台化建设，但很多传统银行目前还是在部分业务领域采用烟囱架构，烟囱架构的出现很大程度上是前期为了快速满足业务需求，就采购一个all in one的产品系统，把所有的功能都涵盖了，一旦同业务领域的产品多了以后就会出现多个雷同的烟囱，下面列举下烟囱架构的硬伤：

1）成本高，动作慢：早期使用烟囱架构能够快速搭建系统，但随着业务复杂，会出现极大的集成和协作成本，整个公司灵活度和整体执行力会下降；

2）抑制创新：每次业务创新都面临大量重复的功能建设，使得在新开业务线不得不面临较大的前期投入，一旦方向错误，损失巨大，试错成本高；

3）经验无法共享：烟囱架构会把能力留在一个烟囱里，成功和失败经验无法跨烟囱共享；

4）稳定性差，质量层次不齐：因为经验无法共享，导致有的烟囱高而不稳，有的烟囱矮而变僵，遇到外力很可能折断。

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

中台的起源

介绍了传统烟囱架构的硬伤，下面介绍下中台的起源，按照业界的说法中台概念起源于2015年马云带队去参观芬兰的SuperCell公司的高效研发团队，SuperCell整个公司只有80多人，但是却开发出了《部落冲突》、《卡通农场》、《皇室战争》等热门手游，2016年被腾讯以86亿美金收购，每个人对公司的贡献度达到了惊人的1亿美金，SuperCell是具备了什么样的能力，让整个公司能够有如此高效的产出。

后来很多专家分析下来发现了其中的奥妙，整个SuperCell公司内部从组织架构到系统架构层面采用了小前台大中台的战略，有以下几个特征：

1）公司以小前台的方式组织了若干个开发团队；

2）每个小产品团队包含开发一款游戏所需的各种角色，可以快速决策、快速开发；

3）基础设施、游戏引擎、内部开发工具和平台则由类似部落的部门提供；

4）部落可以根据需要扩展为多个小分队，但各小分队都保持共同目标；

5）部落本身并不提供游戏给消费者，游戏由各个小前台开发团队开发；

阿里大中台战略

2015年阿里巴巴业务种类纷繁复杂，业务之间交叉依赖，业务团队众多，不能及时响应业务需求，阿里集团在调研过SuperCell公司后发现了该种组织结构和系统架构的巨大优势，2015年12月张勇宣布启动中台战略，构建符合DT时代的更具备创新性和灵活性的“大中台，小前台”的组织机制和业务机制。即将产品技术力量和数据运营能力从前台剥离，成为独立的中台，包括搜索、共享业务、数据平台等事业部，为前台电商事业群提供服务。从而前台得到精简，保持足够的敏捷度，更好地满足业务发展和创新需求。基于中台架构阿里在最近几年时间内迅速发展出很多前台新业态，并且能在很短的时间内拥有阿里集团内部众多成熟产品的能力。

2017年阿里大中台战略在互联网圈得到广泛流传，随后很多互联网公司快速跟进中台战略，最近两年传统企业也都开始考虑中台战略。

什么是中台？

在我个人的理解里，中台 = 共享组织 + 共享系统 ，中台由两部分组成，在网上查到的更多的文章大部分都是关于中台系统架构方面的文章，很少提到中台战略能够成功的过程中很重要的一部分，那就是中台的共享组织，需要有个能够满足中台战略的组织架构，中台系统对应的有中台产品部门，由中台部门负责维护中台产品，相应的产品还是由前台产品来负责开发。

三大中台

网上大家说的中台主要是业务中台，其实中台主要分为业务中台、数据中台和技术中台。下面就分别介绍下这3个中台：

三大中台-业务中台

下面以银行的业务系统的业务中台架构来举例子，业务中台顾名思义就是业务系统方面的共享中台架构。小前台、大中台架构不一定是所有前台产品都是在下游，中台产品都是在上游，这里的前台和中台更多的是一个逻辑上的概念，中台指拥有稳定的共享能力的系统，前台指的是对应不同前台业务部门的小产品，每个产品都有自己独特的流程，但是在某一个业务领域，所有的前台产品都是依赖于中台产品的共享能力。这样可以保证当前台业务部门想短时间上线一个新的产品时，可以基于现有大中台70%的共享能力，只需要独立新建一套前台产品就能满足业务上线要求，例如下图所示当业务想新上线一个新的小程序渠道产品，那么只需要依托于现有的移动开发中台mpaas和渠道中台就能够复用80%-90%的现有能力，业务开发项目组只需要按照新渠道技术要求开发一套前台渠道产品就可以，其他的功能例如安全控制、用户行为分析、灰度发布、移动设备管理、银行业务功能都能复用中台的能力。这样的小前台大中台的架构是不是可以很方便的做到新渠道拓展，新产品的创新，不用每次新建一个产品都要把之前做好的功能在新产品中重复建设。

下图就是银行的一套小前台大中台的逻辑架构图，从图中可以发现，前台产品包含了多渠道的小产品还有针对具体银行业务中台的小前台产品，这样设计的逻辑好处显而易见就是前台产品部门只需要关注产品特色逻辑，基础功能都是中台现成的，大部分都是可以复用中台接口。

银行业务中台架构

三大中台-数据中台

三大中台中对于传统银行来说最难的其实就是数据中台的建设，数据中台的设计其实跟传统银行的OLAP系统和数仓的设计思路存在一定意义上的雷同。数据中台要实现的核心功能是全行数据的共享，所以数据服务的前台和中台其实分为了6层结构：

• 数据使用前台
• 数据应用前台
• 数据中台模型层
• 数据中台数据仓库层
• 数据中台加工层
• 数据中台源数据层

银行数据中台架构

数据中台源数据层

我们先从最底层数据源开始讨论，银行的数据中台最终数据来源其实和传统银行的OLAP系统的数据源是一样的，包含了业务日志文件、业务系统DB数据、业务系统的NoSQL数据、外部三方数据，只不过原先很多传统银行OLAP系统更多的只是聚焦在业务系统DB数据和外部数据，没有把一些业务日志文件和业务NoSQL数据也加入到原始数据源，对于很多业务日志和NoSQL信息也是很有价值的，数据中台的源数据层和数仓的ODS层（原始数据层）其实是非常类似的。

数据中台加工层

数据中台加工层在传统银行的OLAP系统中其实就是存储过程数据加工的逻辑，传统存储过程对数据的基础加工性能是很差的，而且很容易出现各类SQL因为执行计划变化跑不过去的问题，所以在数据中台的建设过程中一般来说对于数据加工层会采用Hadoop、Spark或者是阿里的MaxCompute之类的非结构化数据加工技术。使用主流的分布式大数据加工技术后，会让数据加工效率大幅提升，而且能够加工的数据格式也更加多样性。

数据中台数据仓库层

在源数据加工完成之后，会将数据按照业务领域划分的宽表进行加工，作为业务基础宽表用于下一步的业务模型层数据加工。

数据中台模型层

数据中台模型层主要功能是按照业务领域进行主题模型设计，例如银行系统可以分为交易主题、报送主题、风险主题、用户画像主题、营销主题。模型层是根据数据仓库层各业务领域宽表数据根据模型要求加工出来的主题数据，这些主题数据是按照业务模型进行抽象设计，加工出来的模型数据是提供给下游的数据应用前台进行报表加工或者风控使用。

数据应用前台

数据应用前台就不属于中台了，属于数据的前台产品，主要是进行银行各类对外数据的应用加工，例如分为了用户画像应用、报送应用、智能风控应用、精准营销应用，这些都是对全行的统一数据应用，传统银行可能是将各类报送或者是业务统计报表放在各个业务系统自己去加工，数据中台架构中其实是将这些数据应用都设计为前台产品基于中台模型层的主题数据进行前台应用加工。

数据使用前台

数据使用前台主要就是最终的数据使用方式，主要有Data API、文件、BI工具，传统银行用的比较多的一般是文件和BI工具，对于Data API还比较少，数据使用前台的Data API是想实现一个类似数据API超市的效果，前台业务想使用什么样的数据，直接调用数据API就能够获取到，想做一道什么菜就去超市买什么菜然后自己加工，前台业务用了数据中台以后，在前台使用数据就是通过Data API选择自己需要的数据，然后根据数据中台返回的数据进行加工组合成自己需要的报表或者统计数据服务于业务部门。

数据治理平台

数据中台中最核心的就是数据，为了保证数据的统一标准、数据质量和数据资产的管理需要有一套数据治理平台对数据资产进行统一管理，一套数据治理平台需要具备数据资产管理、数据标准管理、数据质量管理、数据安全管理等功能，对数据进行全生命周期的管理，数据的治理工作贯穿于数据中台和数据前台的各个阶段，对于数据中台建设是一个基石。

三大中台-技术中台

技术中台就很好理解了，就是服务于上面介绍的业务中台和数据中台的技术，包括了服务治理平台、中间件PaaS、安全平台、Devops相关平台、IaaS层平台。各个方面这里就不详细介绍了，网上有很多相关介绍，每一部分都可以是一个专题。

银行技术中台架构

大中台小前台适用场景

大中台小前台的架构其实并不适用于所有场景，适用场景主要如下几条：

• 中台模式特别有利于业务复制尝试和需要大量尝试创新的新业务；
• 10-100阶段（高速发展性公司），1-10（成长性公司）可以开始尝试；
• 不适合0-1阶段（初创公司）

对于初创公司，首要考虑的问题是通过快速构建一套业务系统产生业务营收，优先满足公司生存问题，这个阶段其实一个烟囱架构的系统可能更合适。

如何落地中台

落地一整套中台架构战略，不单单是需要系统架构层面的设计和重构，更重要的是关注在公司组织架构的调整，公司组织架构会增加相应的中台业务部门，由中台业务部进行全公司的共享需求的管理和扎口，各前台部门涉及到的公共需求由中台业务部根据对公司的贡献情况进行排序实施，避免多前台部门共同开发相同的功能，重复建设，重复投入。

下面简单介绍下中台建设的过程，这里还只是简单的介绍下几个大的建设步骤，其实还有很多建设细节，后续会再整理一些比较详细的介绍如果实际落地的文章。

组织架构调整

组织架构就像上面提到的会根据中台架构进行较大的调整：

银行组织架构

• 物理拆分独立的共享中台部门；
• 在公司业务层面通过把公共能力下沉为服务，并做好服务连接，赋能前台部门；
• 公司科技部门拆分独立的服务中台业务部门的研发团队。

公共能力下沉为服务

在组织架构调整后还需要进行公共服务能力的下沉，主要有以下步骤：

• 按照DDD划分大业务领域；
• 梳理同一业务领域现有系统中的烟囱，梳理出领域中各产品重复开发功能；
• 根据各个产品重复开发的功能提炼出公共抽象模型，并下沉为共享服务；
• 重新根据前台产品流程和新共享服务重构新的前台产品。

如何判断一个中台建设的好不好

判断一个中台建设的好不好其实很简单，个人总结通过以下两点可以直观的体现出来：

• 业务提了新的产品需求，从“这个做不了，系统不支持”变成了“这些需求没问题，大部分都能做了”；
• 业务提了新的产品需求，科技回复的开发时间从“6个月”变成“1个月”。

银行是否适合建设中台

银行在业务和技术架构上与互联网系统都存在差异点，这些差异点也会导致中台系统建设上的差异点。

银行与电商业务差异点

从业务共同点、流程通用性、组织结构3个纬度进行了电商和银行的对比：

	电商	银行
业务共同点	电商业务同质化非常厉害，不同事业部具有很多共同点	银行内部业务产品在不同的大业务线存在很多共同点
流程通用性	业务产品核心流程基本一致	业务产品核心流程会存在差异
组织结构	主流电商现在基本都采用了前台事业部，中台共享事业部的组织架构	银行目前基本都还是传统的按照业务线的垂直组织架构

通过这样的对比能够看出电商能够共享抽象的内容更多，业务同质化厉害、流程也基本一致，所以除了底层业务模型，业务流程也可以进行公共抽象下沉到中台中进行多前台复用，但是银行同一业务领域的不同产品可能都会存在流程上的不同，所以流程这块可能很难做到高度抽象下沉。

还有一点就是组织架构上的差异，电商目前大部分都采用了阿里的组织架构，分为前台事业部和中台共享事业部的组织架构，银行还是按照传统业务线进行划分，有些银行甚至还是不同业务前台部门存在同类型业务产品的问题，所以银行要做中台一定要做组织架构调整，需要增设一个中立的共享中台部门，不然就算建设了中台，最后也会发展成为某个牵头部门的独享系统。

银行如何落地中台

银行如果要落地中台必须要进行一些调整，因为银行一般会比较保守不太会像阿里那样进行特别大的组织架构调整，所以可以采取小范围试点的作法。这里简单罗列下落地大的步骤，其实实际每步都可以整理出一篇文章，后续会再整理一些具体中台建设的文章。

• 挑选局部产品线调整组织架构；
• 聚焦在共享功能的下沉，而不一定要将功能和流程一起下沉到中台；
• 优先将相对稳定的业务功能进行下沉；
• 将产品线共性产品进行模型抽象；
• 将产品线中的流程部分剥离到前台产品层。

华瑞中台架构实践（渠道）

下面就用华瑞银行渠道中台的进行举例说明下业务中台的架构实践。华瑞银行在今年实施渠道中台之前，移动银行APP、开放平台、微信银行都是完全独立的很多功能都是重复建设，例如用户注册、开户、绑卡、转账、支付、存款、贷款等等业务接口的组合逻辑很多都是重复的开发，在银行渠道领域，未来一定是全渠道整合，全渠道会共享用户、资源，在系统架构层面也将会进行整合。未来如果新建一个渠道不会再像现在的开发模式从渠道前端到服务端全部是从头开发，未来有了渠道中台以后70%的渠道业务能力在渠道中台都是ready状态，不需要再进行重复开发，新渠道只需要开发出新的前台产品和前台产品对应的BFF（Backend for Front），不需要再重复开发渠道中台已经实现的组合逻辑。

华瑞银行目前的渠道端架构图可以参考下图，各个前端渠道产品都属于小前台，未来可能会有更多新的前端渠道，在前端产品下面是前端的共享服务中台，里面包含了前端接口访问安全控制、前端用户行为分析、设备管理等等，这些能力对于所有前端产品来说都是通用共享的。

在mPaaS下面是各个前端渠道产品对应的BFF，很多同学可能会问有了渠道中台有了前端产品后为什么还要每个前端产品配一个BFF？如果做过渠道端开发的同学一定知道，虽然都是前端渠道，但是每个前端渠道的会话管理、返回信息、产品流程可能还是会存在一些不同，所以还是需要将前台渠道的BFF和渠道中台解耦开，避免将渠道中台建设成多个烟囱的集合。

在建设中台的时候设计和开发人员一定要考虑哪些应该属于前台产品去开发哪些应该属于中台产品去开发，这里对于设计人员的要求是非常高的，他需要能站在很高的角度看到该中台产品是服务于全公司产品的，不是只服务于某一个产品，这是和以前建设产品系统和平台的最大差异，1）首先要对公司业务充分理解，能够抽象出共享的业务模型和部分共享流程，2）同时在实施前台和中台的时候要能够合理的划分出前台和中台的边界，要有一套设计原则，哪些应该在前台，哪些应该下沉到中台，3）最后在设计中台服务接口的时候一定要考虑到，“这个服务接口是服务于全公司或者是某个业务领域的，不是单单服务于某个前台产品的”，每次开发中台接口的时候都要自己问一下这个问题。

华瑞渠道中台架构

总结

本篇文章整体介绍了中台的基本概念和目前主流的3大中台的架构，同时也简单描述了下落地中台的步骤和关键点，最后讨论了下银行是否适合建设中台，对比了电商和银行业务的差异点，并且最后举了华瑞银行正在实施的渠道中台的例子。中台这个理念是非常好的，中台战略不单单是系统层面的建设，更多的还是需要公司组织架构的同步调整，不然大概率会出现系统原先规划按照中台战略设计了，但是最后因为组织架构的问题导致最后中台渐渐走偏。

最后回答下标题的问题，中台战略是一种比较好的能够提升公司整体产品创新能力和敏捷开发的一个整体数字化战略，中台战略其实是数字化发展到极致情况下的战略方案，其实很多银行一直在超这个方向努力只不过没有明确提出中台战略，所以银行并不是跟风中台战略而是一直以此为目标，为了满足未来高速业务发展对现有组织和架构的重构，希望这篇文章能够帮助到银行的朋友理解中台的概念。