一、 背景

引子是最近又被要求把一个模块做成中台，但到底什么是中台、怎样才能建设好，很多同学还没有清晰的概念。目前主流的一些文章介绍的都比较抽象。在这里我有一些不同的经验和想法，可能跟你想象中的中台不太一样，也更具体。希望有可能从另一个角度让大家理解中台。

1) 阿里的问题

内部的问题

村淘是将电商能力下沉到农村的一个业务场景，最高时团队规模达到了几百人。但是在一次汇报的时候，团队向上反馈遇到的问题，受到了很多挑战：

(1) 地图和配送的地址簿不统一

运营确定村点位置用的是高德，配送是使用的菜鸟，在运营过程中有配送到错误村点的情况，在细粒度的地址簿上两个平台有差异。

集团内类似地址簿的基础服务依然没有内部统一，运营在选择依赖的平台的时候也是基于习惯，而不是基于实际业务场景。

(2) 存在品控差和刷单的现象

开始村淘使用的是淘客的模式，有人从淘宝采购开店再卖到农村，这个过程商品的管理和销售都有村淘构建的产品流程支持。难以保证产品质量和售卖过程有人刷单的情况。

天猫和淘宝曾经做过一次大规模的改造，合并了两个产品线的商品数据形成了统一商品库，一方面统一了两边的商品模型方便两个平台打通；另一方面是在商品进驻的前置链路（品控）和后置链路（刷单）都有了统一的解决方案。理论上阿里在品控和刷单问题上已经有了非常丰富的经验，所以问题一出现逍遥子最先问的就是为什么没有接入统一商品库。具体的理由大概是不了解平台有这方面的能力，平台产品库接入成本问题，以及场景上也有略微不同。

总体来说在当时的情况下即使是内部人也看不全阿里的全貌。

外部对平台的认知

逍遥子还提到一个问题，阿里目前多个产品线独立对外，“打出去的拳是散的”，很多人不知道高德、UC、优酷等产品是自己的服务。单业务独立对抗外部竞争，例如饿了么。

2) “特种部队”的故事

Supercell 的故事已经讲烂了，那是一个小前台的典范。这里介绍一个马老师讲的特种部队的故事。

他说电影中的美国特种部队执行任务都是几人或十几人的小队，去完成一项艰难的任务，其实不是他们有超人的能力，有一个重要的原因是他们能够通过一个电话调动后台美国的飞机大炮。看着是十几个人，其实背后有美国的强大支持。其中最重要的就是这个中控指挥部。阿里缺的就是这个可以调度飞机大炮的指挥部。

3) 小前台大中台

基于上面的故事，逍遥子提出了“小前台，大中台”的概念。希望能做到充分发挥公司沉淀的能力，快速落地业务，降低风险，提高效率，降低成本。前台指的是直接在一线做业务落地的团队，当时阿里有很多的新业务在推进，但是新业务为了快速解决问题，往往配备了大量人力。对于阿里来说，所需的平台能力积累已经足够了，能够满足大部分新业务的探索和执行，现在缺少一个”中间件团队“或者”中控指挥部“的中台，能够给业务前台调动全公司服务的组织。通过中台的强大能力，让前台可以小起来，快起来。

二、 实践落地

1) 雷声大雨点小

中台不同于平台，它更贴近前台业务，能够直接连线业务，给业务前台提供平台能力支持。这大概是传出来的关于中台的描述中，唯一被听进去的一句话。

阿里发布了”大中台小前台“战略后，很多公司很快就跟进了这个战略概念。但是由于电商平台没有发布任何关于该概念的方法论或执行策略，只根据传出来的部分信息，理解构建自己的中台。很快就发现了一些问题，不仅没有达到预期的效果，似乎还有拖累业务的趋势。中台出现一年多，并没有什么成熟的中台案例出来，概念很火，但落地分享的少，更多的是中台失败的总结。美团技术干脆没有跟进过这个概念。

一方面是新产生的中台职责定义不太明确，另一方面，很多中台的建设带着原来平台的思想，建设出的中台并没有那么接地气。还有人总结，团队能力不行，期望过高，边界不清晰等问题。所以有人开始质疑中台的真伪和必要性。”中台是否有必要存在“和”中台是否适合我“是很多公司技术负责人提出的疑问。

（中台化的方案：虚拟中台）

在原来的平台基础上，同组织架构中提出来一个中台组，或在原平台上平行建立一个中台部门。或有些平台直接改名定义成中台。最后形成一个中台结构群，但是各个中台间还是独立的，一个虚拟中台。但是这很难解决真正的问题：

1. 对于【业务 1】来说，依然要对接三个团队。

2. 对于不了解【平台 3】的【业务 2】，通过什么方式了解【中台 3】。

3. 类似【平台 2】、【中台 2】这种更离散的组织架构下，需求的传递和能力的沉淀该怎么做。

4. 中台和平台的能力如何界定。

PS:当然随着时间推进，坚持建设中台的大中型公司已经从实践中慢慢总结形成了适合自己的中台概念和结构，也能合理的快速支持业务，但是跟电商最出提出的”中台“概念的目标可能已经有了一定的偏离。不过这时，它叫“中台”还是“后台”还是“东西南北台”都不重要，适配自己的发展就可以了。

2) 数据中台

其实也不是全都是反面的例子，几年中有很多数据中台落地很好的例子，形成了很好的产品体系，也得到了业务的认可，切实的解决了大部分的业务问题。数据中台是怎么成功的？

3) 平台和中台

• 平台化的过程

互联网疯狂的扩张过程中，沿着相同或者类似的方向，发展出来了大量的业务场景。很快产品研发人员就发现了众多业务场景里有很多通用的部分，例如技术上的监控，数据等；业务上的商品管理，支付，财务等。这些通用的能力很多是在各个业务重复建设的，所以有人提出了之前在软件行业也经历过的”产品化“过程，在互联网行业里更多的叫平台化。一段时间里，甚至到现在，技术产出的主要体系就是平台化能力，服务的业务方数量。平台化后的互联网公司有了很多可以通用的基础能力，这些能力抽象出来的主要目的就是可复用，提高效率，降低风险等。

• 中台与平台的关系

从平台化过程来看，平台是抽象业务通用部分，形成聚焦的产品化方案，以基础能力提供出来，做降本增效的。而中台的问题演化和定义的过程中，“特种部队指挥部”本身是没有飞机大炮的能力的，它只是聚合连接了这些能力提供给“特种部队”。所以中台和平台的一个明显的区别是，中台是聚合能力的，平台是提供能力的，而中台聚合的就是平台的能力。

平台化产品化过程使能力可复用，中台化过程聚合平台形成合力，为业务提供保障。很多企业、团队在中台上失败了，网络上有很多原因总结，例如团队能力不行，期望过高，边界不清晰等问题，究其主要原因还是对中台概念和定位不清晰，如果按照聚合能力和提供能力来理解中台，那么很多问题都可以迎刃而解。

• 平台的能力足够强大才能使得前台足够小

中台就是连接平台和前台业务的指挥部，它让业务知道公司都有什么能力，如何选取，怎么使用；同时中台也会从业务中不断提炼、迭代平台能力，反哺平台。从而解决第一章中说的，有问题不知道找谁，重复建设，各个平台之间感知弱，平台复用性差等问题。

对外部通过中台的调度，可以提供公司业务能力的全貌，联动各业务线对外形成合力。

• 数据中台

数据天生就是需要聚合的。数据平台就是聚合各个业务线的数据整合后提供给各个业务线，数据平台本身并不生产数据，更多的是分析加工数据后支持各个线。所以它天生具备中台的特性——聚合能力，所以数据中台更容易成功。

4) 技术能力还是组织能力

从问题的提出者可以看出，中台概念最初不是一个技术向的概念，或者技术只是其中的一部分。它更多的应该是一个组织架构设计问题，是一个典型的通过组织架构设计来解决公司内外部问题的方法论。所以从公司的角度来看，我理解中台更多的是一种组织能力。当焦点放小到技术内部，依然是可以用中台思路解决技术管理过程中遇到的类似的问题，这时就是一个偏技术考量的中台了，但是面向的问题和解决的思路与公司视角的时候应该大同小异。

三、 重新理解

从上面的分析过程看，以聚合能力的定义来设计，中台化的方案可以做些调整，以更适配中台的概念。

1) 对比方案

业务可以从中台获得全部的平台能力，介于平台和业务中间，独立的可以被直接 touch 的组织结构。

（常规方案和演化方案）

2) 类似中台的成功案例

中台要解决的问题应该是一个普遍问题，解决的思路也不是很特别，理论上应该有过相似的解决方案。实际上，在传统软件行业，还真的有类似的织设计与中台思想不谋而合。这种组织就是传统软件中的售前。

以 Oracle 为例。在 Oracle 的售前团队，是一批由资深技术和业务组成综合型团队，团队里的成员都蹭在各个技术产品团队工作过，所以对 Oracle 集团的技术体系了解的特别深入。而他们在售前的工作，就是给各个项目组提供技术解决方案和技术支持，销售得到一个客户后，会配置售前团队给目标客户制作一份技术解决方案，例如以客户的需求，应该选择什么数据库（Oracle，Mysql），使用什么软件套件（PeopleSoft，ERP），硬件服务器，云计算产品等。销售不需要了解产品的技术特性，由售前统一对接了 Oracle 所有产品线，并对销售客户的需求给出产品搭配建议。同时，售前团队也会收集用户需求给产研团队提升产品能力。在有的公司，售前还有二次开发的能力，帮助销售在基础产品能力上，完成客户个性化的业务需求。这样就有一个团队能从公司的视角为客户提供更全面考量，一方面避免了销售选择错误产品导致产品需求不匹配，提高了客户的留存；另一方面形成了内部产品合力，多维度服务客户，也形成更多的销售可能。

四、 其他

1) 与微服务的关系

没有直接关系。微服务是解决研发维度的架构方法，与中台面向的主体和问题不同。微服务可以做一个单独的话题介绍。

2) 我们要中台吗

首先看当前的结构下是否遇到类似问题，如果当前业务跑的流畅，也符合预期，那没有必要引入更复杂结构来增加运营难度。

其次看自己的平台化的程度，一个是通能力够不够强，另一个是平台化内容够不够多。如果能力不够通用，可复用程度低，那也没有必要提到中台；如果平台化的产品少，只有一两个平台，也没有必要提成中台，直接平台对接业务就好。

3) 概念、具象与“一手信息”

互联网行业中有很多新颖的名词，抓手、赋能、闭环等，经常被人吐槽晦涩难懂，中台也曾在这个行列。主要原因就是这些名称都只是概念，没有具象的例子给人直观的感受，容易让人望文生义，理解错误；更何况有些概念“望文”都难以“生义”。上学的时候我们就知道，所有概念的教学配以几个生动的例子，能够更容易被理解和记住。而互联网概念的传播过程往往是概念多，例子少。需要经过多层人的理解，包装，解读后才传递到我们手中。这个过程中难免会产生理解的偏差，过度的解读，或配上了不太准确的例子。这时在传到我们的手里，加上自己的理解后，就很难还原这些概念最初的含义了。所以学习新的概念或技术的时候，要尽可能的获取“一手信息”，获得的信息产生的越早，那么它离最初设计者的想法就越近，也更容易理解。