编者按：本文转载自网易副总裁，网易杭州研究院执行院长汪源的个人公众号“冷技术热思考”（欢迎搜索关注）。7.26的云创峰会上，汪源承诺会写三篇文章，力求说清楚什么是中台，什么时候要考虑建中台，怎么建中台。今天是第一篇，目标是厘清什么是中台。以下为原文：

中台的概念一热，很多似是而非的东西都在往中台的概念上凑，一下子出现很多中台，如业务中台、数据中台、技术中台、算法中台、移动中台等等。特别是很多原来称作平台的，现在也都摇身一变成了中台，赶时髦。

一个概念太过宽泛是不利的，如果随随便便都是中台，必然导致很多所谓的中台项目失败，导致中台无用论。所以有必要对中台的概念做一个比较准确的定义。

什么是中台？

要定义中台，重要的是要能比较明确的区分中台和平台。中台和平台都是某种共性能力，区分两者的重点一是看是否具备业务属性，二是看是否是一种组织。中台是支持多个前台业务且具备业务属性的共性能力组织消息中台，平台是支持多个前台或中台业务且不具备业务属性的共性能力。

为什么要强调中台必须具备业务属性？可以来看一个例子。我们可以分析什么叫数据中台。如果一个企业把所有业务的数据都存储在里，我们能说这个数据库是数据中台吗？显然大家都会说不是（否则中台不是几十年的老古董了？）。那么现在很多企业换成了，所有业务数据都在一个集群里，能说是数据中台吗？显然也不是，这个无非跟原来的一样存了一堆数据而已。有人说这是因为这个集群只是一个系统，中台必须是一个组织。那么我们再加上建设和维护这个集群的团队，整个加起来就是中台了吗？

仍然不是，因为这个团队是不需要为业务负责的，不具备业务属性。而现在大家比较公认的数据中台，指的是确保OneID、得以实现的组织，使得数据不再是各前端业务独立管理，而是通过统一的团队在数据标识、指标、数据仓库等方面实现了跨业务的整合。之所以这样大家会认为是名符其实的数据中台，是因为指标一定是面向业务的，数据仓库的建设一定也包含了一些业务逻辑。所以那个大大的并不是数据中台，而是大数据平台。

我们还可以看到是中台还是平台与所在的业务环境相关。同样的能力对A业务来说可能具备业务属性从而是中台，但对B业务来说没有业务属性从而是平台。比如说IDC建设和运维对AWS来说可谓至关重要的业务中台，而对绝大多数企业来说只能说是平台。PaaS平台对SaaS厂商来说是业务中台，但对绝大多数企业来说也只能说是平台。

所以，不具备业务属性的能力，即便是共性的，即便有一个专职的部门在做，即便对业务非常重要，也不能称之为中台，而还是应该称之为平台。否则就会出现很多与业务八杆子打不着的各种中台，混淆视听。因此，应该说所有中台都是业务中台，没有别的类型的中台。数据中台、搜索中台、内容中台、零售中台等等，都是特定形式的业务中台，也还是业务中台。

中台的定义还要求以下两点：

1. 中台是一种共性能力组织，支持了多个业务。

2. 中台支持的是多个前台业务。

第一点不用多说，只支持一个业务的能力至少暂时不能称为中台（当然可以有进一步建设为中台的规划或可能性）。之所以强调第二点是因为有太多的公司的业务不是靠前台打下来的，而是靠财务后台做账做出来的。理论上可以有，但我们应该支持这样增强做账能力的中台吗？对于那些专业提供做账服务的公司，还真需要这样的中台，但这时做账就是它的前台业务了。

中台的定义并没有限定中台的建设层次。中台可以在很多个层次上建设，并不是说必须是企业或集团级别的。BU和BG层面建设中台往往更常见，也通常很有意义。即便更小的层面比方几十人的小部门，中台也很有价值。比如一个小团队也可以做电商业务，这时如果有一套好用的电商中台那就帮了大忙了，而事实上业界也有很多公司在提供这样的能力。

典型的中台有哪些？

除了常说的业务中台，我们还经常听到数据中台、用户中台、搜索中台、推荐中台、内容中台、技术中台、算法中台、移动中台、研发中台等等一系列的XX中台的说法，但这些中台未必都是真正的中台。

前面已经说过，广义上讲业务中台包含了所有中台，不同的XX中台都是业务中台的细分方向，反映的是该中台在业务领域或者技术上的某些特征。但大家往往只用业务中台来指称在线业务中台。基于这个假定，当前典型的真正的中台大致只有以下几个：

01（狭义的）业务中台