互联网中台的兴亡历程

提到中台，很多同学都会想到阿里在2015年提出了一个大中台，小前台的模式，下面我们来聊聊中台由兴到衰的过历程。

1、中台的提出

中台源自于芬兰的一家小公司名叫SuperCell的小公司，这家公司主要是做游戏业务，SuperCell公司有个特点，就是内部任何人都可以提出自己的关于游戏的业务想法，这个想法通过审批后可以在公司内部组建游戏团队快速开发，快速落地和推广，游戏上线一段时间后，如果游戏火爆就可以存活下来，如果游戏在这段时间内市场不理想就快速的下线。SuperCell公司的这种快速开发，快速落地的方式使用的就是中台的思想。

阿里正是借鉴SuperCell公司的这种思想形成了一个自身的大中台，小前台模式，当然中台在每个公司都有不同的理解，它并不是一个具体的东西。

2、中台分类

中台就是将各个业务线中可以复用的一些功能抽取出来，剥离个性，提取共性的过程，中台大体上可以分为三类：业务中台、数据中台和技术中台。

（1）业务中台

抽象出在各个业务线都可以共用的一些组件，比如像用户中心、订单中心、支付中心等等这些公用的组件，如下图所示的业务中台：

（2）数据中台

数据中台是对整个业务系统的数据进行统一的存储建模与计算，为各个业务系统的数据分析与利用提供支持，如下图所示的数据中台：

（3）技术中台

技术中台是通过封装各个系统需要的技术框架，对上层业务开发的这种门槛可以降低，同时提高系统的交付速度。

3、中台的实践

在中台没有提出来的时候，业务之间的开发采用的是烟囱式架构，如下图所示：

业务A、业务B和业务C是公司内部的不同业务线，此时难以避免各个系统中存在很多重复建设内容（如商品中心、订单中心），同时数据之间也是没有在底层打通，就出现大量数据孤岛，能力无法复用，建设成本非常高。

提出中台之后，需要构建出一个独立管理、独立维护的中台团队，这个团队对于已有的业务团队进行抽象，将商品中心、订单中心进行抽象出来，如下图所示：

通过中台可以将底层数据被打通，然后很多数据之间可以进行二次加工创造出更多的有用价值，在业务方面可以进行能力复用。中台强调能力复用，强化敏捷化、轻量化，就是常说的“小前台，大中台”，中台极大地提高了业务开发的速度，降低各方面的成本。

传统开发模式中，每个业务线有自己的业务团队向对应的研发部门提出需求，研发部门构建大前台应用，这样的设计中，业务线之间是相对隔离的，如下图所示：

引入中台之后，产品人员很多的时候是面对独立管理的中台，中台团队提供业务支撑，原先大前台是什么事情都做的，现在就变成了小前台打散成一个个的小研发团队去调用由大中台构建出来的数据和业务能力，如下图所示：

中台的优势是将原先各个业务线中的可以复用的东西进行统一的管理，避免了多次的重复开发，提供了开发的复用度；同时在架构上有统一的团队负责管理，未来公司有新的业务线可以直接使用中台能力进行快速开发和落地。

4、中台的弊端

（1）职责界限模糊

当有一个新的需求来的时候，产品人员不清楚找小前台还是大中台，职责不明确。

（2）新业务线适用性差

针对新业务线会出现研发速度越来越慢，因为开发一个新需求的时候，首先要考虑能不能抽象，能不能做复用。

（3）中台设计越来越臃肿

中台部门是一个独立的部门，开发人员也需要开发任务，当中台开发成熟后，中台的开发任务越来越少，这个时候就会部门内拍脑袋想需求、想场景，设计出一堆无用的东西，导致中台越来越臃肿。

中台适用于稳定业务的能力复用，如阿里是电商起家，它在做电商零售方面是很有经验的，围绕电商构建出来的业务可以复用中台，典型的产物是盒马，所以阿里使用中台可以快速搭建起盒马业务线；但是把阿里的金融业务、健康业务、大文娱业务都整合在一个中台上的话，由于这些业务的场景都不一样，就出现了中台不适用的情况。所以阿里在2023重新提出了1+6+N新的架构。

总结：

（1）中台适合多年沉淀下业务稳定的公司做能力聚合，中台可以为企业提供一种协同、标准化、灵活的IT架构，促进企业的数字化转型和业务创新。

（2）中台不适合业务还在迅速变化的企业，因为中台不利于快速迭代和创新，不适合公司的所有业务场景。