编辑导语：中台这一概念近几年被频繁提及，而当中台被普及应用，在这一过程中，则会出现许多关于中台的疑惑与问题。本篇文章里，作者就对近期他所遇到的关于中台的高频疑问做出解答，并对中台的本质表达了他的看法，让我们一起来看一下。

各位关于中台读者，大家好！好久没和大家再聊聊中台相关的内容了。

最近在我写完中台100讲（《中台产品经理宝典》一书+中台实战30讲）的内容后，我终于有空在我的公众号上去回答和接受邀请去往很多企业参与中台方案的评审。

在这将近一个多月的沉淀与走访中，让我对中台这个概念在一线战场使用的人群中有了新的了解，也正是如此我决定再写一篇中台本质探索的文章，来对近期我遇到的中台高频疑问进行一个梳理。

一、中台的争议

最近关于中台争议**的一个消息，莫过于张勇近期在阿里内网发布的一段话，大概意思如下：“张勇对目前阿里的中台建设并不满意，他直言道现在阿里的业务发展太慢，要把中台变薄，变得敏捷和快速。”

而这段话在流出后，被自媒体一番加工后变为了阿里开始要拆中台，于是乎很多人阅读完这些文章后，也开始说中台已经成为被阿里抛弃的产物。

那事实真的是这样吗？这里我想说其实这些自媒体其实已经从中台的概念源头出现了理解偏差。

也就是说如果有人认为中台是一个具体的产物或一个系统，那么此人对中台概念已经产生了相当大的误区。

如果仔细拆解这里的误区，可以发现他们的思考链条是这样的：

中台的错误认知：中台 = 一套神奇系统 = 降本提效的软件工具。

基于这个错误的认知，加上市场一些SaaS企业的恶意炒作，在市场中很多IT企业主就产生了这样的认知：

企业主的决策认知：我要降低成本 = 所以要上中台系统 = 我不清楚中台是什么，我也没有能力自研 = 我要去买一个中台系统。

大家试想下，无论是之前的某酒厂的中台失败案例，还是某电商的3千万的中台流产项目，这背后其实都是这样的企业主在把中台与一套神奇系统画等号后，进行的一系列错误决策。

二、中台究竟是什么？

那么中台究竟是什么呢？

这里我想说：中台概念其实只是一种设计思路，本质来说就是当企业发展到一定规模后，一次企业内部改建。

众所周知在互联网公司内部的产品其实都是为企业业务所服务的，在很多时候产品的建设都需要优先满足于业务的需求。

因此在很多公司中，会出现为了追风口赶业务新产品会在现有产品基础上进行临时搭建，快速拼凑出一个临时产品。

这种场景，举个形象的例子就很像现实生活中的违章建筑。

违建虽然在一定程度上临时满足了我们的需求，但是他给整座大楼带来了安全隐患，会影响到楼层的稳定性，同时也将原有的楼层主体进行了破坏。

而且更重要的是这种临时建筑由于没有进行全局的设计，只是在现有的结构基础上临时拼凑出来的，就会导致其自身的使用性能与使用体验远低于正常水平。

所以很多时候，在新业务发展到一定时间后，我们都会选择重构来为新业务重新设计产品。因此中台这个概念，本质上就是一种企业内部全产品线的一次改建方案，具体来说分为两点：

1. 对企业内部的这些违章建筑进行一次改建，拆除原有的违章建筑，并将这些违章建筑的原有诉求进行合并；
2. 为了避免在企业后期再次出现违章建筑，我们需要将时下已经跑通并且验证了业务功能变成可复用的原子组件，让其他业务方可以在出现诉求时，直接用现有的组件去拼装出自己的解决方案。

第二点这里我再举个不怎么正确但是很好理解的例子，就是当我们需要再开发一个新的商城时，在公司内部我们可以选择把做的最完整那条业务线的PRD与代码拿过来，此时我们就有了个现成的商城。

当然为了让一份PRD与代码可以全公司复用，我们在设计时就需要尽可能的抽象，比如在某业务线中设计的入库模块，他们根据业务需要在入库类型中定义了海淘商品入库单、残次品退货入库单两种类型。

但是大家试想，如果在新的业务中，商城中不涉及海淘的业务，那么在拿到这个业务线的代码时，就会觉得这里的入库单还需要二次开发。所以我们在将自己的代码交给别人复用时，我们应该先将自己业务的逻辑剥离掉。

比如这里，我们就应该将海淘商品入库单、残次品退货入库单进行业务剥离，得出抽象后的入库单与退货入库单两种原子组件。

当然这里的例子不是很正确，只是为了帮助大家理解。在实际的中台抽象中我们需要大量的建模，原子组件定义等等，这里我就不展开详述了，感兴趣的可以去看看我的《中台产品经理宝典》一书。

三、中台落地产物

涉及到中台的另一个问题就是，中台的落地产物到底是什么？

当我以外部专家身份，参与了多家企业的中台方案评审后，再来看这个问题，我的答案就是：中台产物其实就是六个字，“下定义、给标准”。