中台系统发展到如今的几点思考

小熊猫 2023-07-28 15:38:10

一、前后台模式的弊端

近些年来，中台的概念越来越热门，打开谷歌搜索，收入“中台系统”就能检索出来5亿多条结果，可见大家对其关注度有多高。

产品经理，产品经理网站

在介绍中台之前，我们先介绍在中台产生之前，常见的互联网系统的模式——前台+后台。

后台（例如：订单系统、交易系统、供应链系统等）通过配置为前台提供计算服务，前台再通过自定义的样式，呈现给用户所看到的页面及功能。

如果在此模式中市场、运营、销售等前线人员突然有了一个非常棒的idea，要在原有的电商系统里增加拼团功能（如聚划算的拼团），这时候不仅需要重新设计前端页面，而且后台的接口与数据表都要重新设计。这样导致系统的很多底层应用重复搭建，拉长了开发时间，影响需求上线节点，最终可能会造成功能还没开发好，已经被竞争对手抢先占了先机。

因此若公司内部有多条业务线同时进行发展，并要探索新的业务场景时会遇到此类问题，我们再展开来说，可分为几点：

1. 公司内部多系统不统一

很多公司在发展到一定阶段后会分化出多条业务线，每一条业务线（也可以是部门）又像一家子公司一样，所赚得的收益都归为本子公司的功劳。

为了维护好自己部门内部的利益和绩效，每个部门的大佬们在做决策时也会从自己所待的部门角度出发，可能不会从公司全局角度考虑，这种行为会让公司内部各部门形成信息孤岛。

当其他部门要使用某一些功能模板时，一方面是其他部门可能不知道此部门有这种功能，另一方面由于本部门的功能搭建时只考虑对本部门使用，所以很多细节不适用于其他部门的需求，其他部门还需要重复搭建类似的功能，这样会大大消耗公司的研发成本，并且无法快速迭代完成任务。

2. 原有系统不支持现有业务发展

在创业初期的系统所面临的业务场景相对单一，但随着企业的不断壮大，所涉及的领域也在不断拓张，不管是通过将原有系统进行底层架构改造二次开发，还是从0到1开始研发一套新的系统去适应市场的变化，都会非常耗费精力，更何况是多条场景同时进行，难度可想而知。

3. 系统臃肿

业务系统为了支持越来越多的前台需求，后台需要不断通过模块化设计（解耦）的方式来保持系统的稳定性，这种设计方案反而会导致系统越来越复杂，同时这样的后台变得越来越没法去快速响应前台业务调整所带来的改变。

二、中台的本质

为了解决以上的问题，中台系统应运而生。

中台可以理解为一个耦合剂，通过高度抽象，把使用频率高，可复用性强的模块提炼出来，单独做一套系统，在前后台中间起到关联的作用，这样就可以快速响应前台需求，后台也不会变得臃肿。

举个例子，在抖音刚出来时，美团也想打造一个新的短视频APP与抖音竞争，这时候需要开发一套新的系统。

可能需要的功能有：在线播放短视频、商品交易、用户社区等。

分析以上需求，可以从中抽象出的模块有：视频编辑、商品编辑、账号体系等。

结合美团APP和被其收购的大众点评APP自身现有的功能，可以把团购的视频编辑功能、商品编辑功能及账号体系剥离出来，做成中台系统，这样前台只需调整样式和定制化的需求，即可快速上线运行，根据市场反馈及时调整运营策略，从而抢占一部分市场。

当然这个中台系统需要提前做好相关的功能，这样才能事半功倍。也就是说，中台系统有时候需要走在业务前面，去分析公司内部的未来战略以及市场上接下来的变化，从而能及时响应满足业务需求。

中台的一个重要价值：为企业内部不同业务提供可复用的基础模块。

三、中台的现状

1. “小前台+大中台”阶段

08年阿里成立天猫事业部，其中技术团队是负责淘宝网设计的团队；
09年成立共享业务事业部，对天猫和淘宝网这两个业务线中高度重合的共用模块进行开发维护。
10年成立聚划算业务，搭乘创建好的中台系统，实现了快速落地。
15年阿里巴巴开始对外宣布“小前台+大中台””的架构。

产品经理，产品经理网站

阿里数据中台全景图

阿里的某个事业部曾在一年内立项研发了近百款产品，其中顺利上线的只有十几款，而被大众所熟知的产品仅有几款，这种情况下，要想在一年内高产地孵化这么多产品，如果没有中台系统的支持，每个系统都从零开始搭建，耗费的成本将会多么巨大。

2. “大前台+小中台”阶段

20年底阿里突然提出“拆”中台，不是中台不行了，是场景变化了。

中台在高度抽象现有系统、提升企业内部工作效率上还是非常棒的，但是这只是把内部系统进行整合创新，无法做出颠覆性创新。如果没有中台，阿里就无法快速打造“盒马鲜生”这种新零售领域的新星，但在互联网的下半场里，一二线互联网公司需要的是重新引领某个细分领域场景的产品，这个时候只需使用一点点中台的基础模块，剩下的功能交由团队内部打造、摸索。

从阿里中台的进化我们可以看出，虽然中台将会变得越来越“薄”，但也是一种不可或缺的架构。