做中台2年多了，中台到底是什么呢？万字长文来聊一聊中台

1.1 对待中台的两种极端态度

当前对中台的看法主要有两种极端，一种是认为中台是一个完全错误的方向， 要紧急刹车， 另一种是认为中台就是技术终局， 是业务增长的不二法门。我们先分别讨论一下这两种观点。我开始讨论QCon的演讲话题的时候， 中台只是多个备选话题之一， 但是当我意识到大家对待这个话题非常极端的时候， 我才觉得有必要把这个话题讲通讲透。最终选择以中台做为架构师独立思考的能力的一个案例。这是题外话。

先说中台是否是个完全错误的方向思考清楚这个方向是否错误， 我们可以先看到中台最初的动力来自哪里nbsp;不论是甲骨文还是后来的阿里， 其实本质动因是一个大公司内部的大业务呈军阀割据现象，导致多条业务线重复造轮。由此而衍生出其他的问题， 比如说团队之间内耗严重；小业务无资源， 增长乏力；整个公司数字资产不统一， 损失机会成本；业务线也不能对核心系统做打磨，业务线不稳定。  因为这些原因， 所以阿里的高管们就以美国海军陆战队和Supercell的组织形式为启发， 做了“大(业务)中台， 小(业务)前台”的策略。这里先不谈中台是否能解决这些问题， 或者是说战略启发是否正确， 但是毫无疑问的是， 中台想解决的问题既没有过时， 也依然正在不同的公司里发生， 所以这些问题也必须解决。也就是说从问题定义角度来说， 中台是个完全正确的方向。

那么中台是否是这些问题的完美解决方案台是不是万能药们已经知道答案是否定了。现在看来中台的解决方案至少有以下几个缺陷：

「1.对创新的遏制」：一个被完全中台化的业务导致集团内部过分分工， 任何前台业务都被认为是中台能力的线性组合。 举个例子， 有的公司会有接近或超过千人的供应链中台，搜索广告中台，内容中台等等， 而多数业务前台少则几个人，多不过几十人。前台团队任何一个人哪怕是全职和一个中台域对接， 也无法理解该域的全貌或者是跟得上这个中台的演变。这意味着前台业务完全无法在这些中台相关的领域做创新。本来的创新业务变成无从创新， 当初的动力变成了中台的最大的诅咒。有说法说，一个业务靠拖拉拽就能编排出来了， 这不是创新是什么实证明这种创新完全无用。没有任何一个投资人会把自己的钱投到一个可以被大公司拖拉拽出来的商业模式的。真正的创新不是现有能力的线性组合。

「2.反人性」：中台自身的场景往往缺乏前瞻设计 ，是对现有场景的抽象。而当某个创新在一个前线业务线孵化出来之后，中台团队会通过强制收编该能力来扩大自己的能力， 同时强迫前台团队下线一个他们研发了很久的创新。这种行为往往造成精英人才的流失， 使得本来就受到遏制的前台创新变得更为匮乏。

「3.过渡设计」：中台经常以最全的最复杂的实现来应对任何一个简单的应用场景。大量成熟行业和强监管环境下的需求被带入到了创新业务中。在带来了大量的运营复杂性的同时增加了用户（买家，卖家，本地运营）的学习难度。这就是我们常讲的膨胀软件(Bloatware): 巨大， 复杂， 缓慢，低效。

「4.丧失对客户心智的追求」：中台团队的产品和研发的核心技能在于抽象和降本。前台业务的核心能力在于对商业机会的捕捉和新商业机会的创造。这是两种完全不同的技能，往往对应着完全不同类型的人才。一个长期在多个业务中间找共性来降本的人是不会专注在最大化前台业务增长的。

之前做中台的公司往往被以上一个或者多个问题所困扰。也就是说中台事实上不是完美的。为什么呢/p>

2.思考中台的本质

我们先思考一下中台的本质。中台本质是把一些分散的重复的开发工作集中起来， 通过共享同一个研发团队来提升不同业务线之间的共性， 也就是通过抽象和统一来获取增量价值。 具体的增量可以分成以下几类：

「1.以零成本研发加速上线」：对完全可以复用的标准化功能集中开发，未来以低研发成本上线， 比如说一些无状态的计算能力，类似SDK。

「2.提升业务稳定性」：对产品差异不大的领域通过集中研发运维而获取更高的业务稳定性。这样一个团队开发的底层服务能够同时服务多个业务场景， 聚合所有的流量来加速积累。同时研发同学也通过更多的场景来加速打磨设计。常见的领域是会员，营销， 交易，资金等服务。

「3.加速技术和业务能力扩散」：把整个集团的能力尽量跨BU复制。这包括两种类型，一种是类似SaaS服务的场景，比如说Chatbot，直播，内容等领域，另一种是类似ISV的场景，由一个中央的团队同时提供研发，对内服务和运营，比如说安全，风控，财务，人力资源等。

「4.统一数据资产」：在集团内部统一数据标准，最大化数据复用， 把一个场景积累的数据优势应用到其他的业务场景中去，逐渐建设企业的数据壁垒。

「5.集团层次的资源高效利用」：把部分资源中央化，变成全集团资源， 比如说商品中台不但包括商品库， 也包括商品质量控制体系，背后的货源，相关货源的价格以及服务竞争力。而商家中台，不仅仅是包含商家的信息，还包括商家的合作意愿和对集团品牌的信任，从而使得商家更愿意和一个新孵化的初创业务合作。集团真正想跨BU复用的是从一个大业务孵化而来的竞争力，而不是信息本身。

从研发和管理难度来说从１到５逐渐变难，而带来的增量价值也依次变得更大。

从这个本质来看， 那么中台似乎就是完美的， 那么之前提到的不完美有从哪里来的呢们有必要更深度的思考一下。

2.1 中台的适用范围

首先我们思考一下上面的要求， 我们把这些要求归类成六类， 其中第一种场景细分成低成本上线和加速上线两个类别， 那么这些类别有以下的共同特征：

「0.低成本上线」：同一个功能模块在多个场景中被使用， 要求该能力的接口确定性高。

「1.加速上线」：同一个基础能力不需修改或者简单修改即可上线， 也就是模块化支持，要求高API确定性和好的功能通用性。

「2.提升稳定性」：同一个业务能力持续打磨， 要求需求同时具备高的接口稳定性和好的跨业务线通用性。

「3.加速能力扩散」：基础业务能力可以跨业务线模式， 要求该能力具备比较好的通用性, 可以在多个业务线之间共享。

「4.统一数据资产」：数据模型可以在多个业务线之间统一， 对功能的通用性要求高， 且业务需求相对稳定。

「5.集团资源高效利用」：业务能力共享， 不仅仅是技术资源， 其实是业务能力有高通用性且需求稳定。

下图把这几个特征分别放在一个四象限图里面。这四个象限的横轴代表技术演化稳定性，竖轴代表功能的通用性。中台的优势领域在第三象限，这个象限技术具有高确定性，业务功能通用。第二象限属于比较稳定但是不通用的小众行业。第四象限属于普遍流行但是高速变化的领域，比如说内容和服饰或者端上的交互。而第一象限属于创新业务，不但定制化程度高且快速演化，比如说面向垂直行业或者初创技术。也就是说：中台的使用范围是有限的，仅仅限于技术演化相对慢且功能通用性高的场景中。这是我们得出的第一个结论。过往中台的失败案例也往往集中在把中台强推到创新业务中的情况。

这个现象当然不局限于中台， 整个公司都在膨胀。但是这种膨胀对中台而言却是灾难性的。一个膨胀的业务线伤害到自己， 但一个膨胀的中台放缓的是整个集团。

所以我们有了第二条重要结论：中台的建设要有与之匹配的组织文化机制。

3.寻找中台的合理组织机制

那么什么样的机制才是一个合理的组织文化机制呢遗憾我自己也不知道正确答案。但是我们或多或少可以从过去的失败中寻求教训，从历史中寻找启发。

先来思考一下过去的失败。我归纳下来大致有这么几个根因：

1. 对哪个团队做中台或者哪个人来设计中台的决策是个自顶而下的中央决策过程。做中台的人没有所必须的抽象能力和业务理解，类似过去封建王朝的分封的过程。受封的仅仅是生在帝王家， 有没有治理和决策能力不重要。

2. 中台的推行机制往往是个掠夺的过程。对业务线的创新直接复制， 不尊重发明者的知识产权和劳动。中台所到处，寸草不生。

3. 中台能力一旦发布， 独家专供， 哪怕功能不完善， 设计不合理也不允许业务团队复制或分支。

4. 中台为了做规模强制向业务线推行，业务线被迫削足适履，消耗严重。每次中台升级小的BU更是叫苦不迭，故障频发。

其实这几个问题并非中台所独有。上面的四个问题其实和封建 会的分封机制类似，本来应该有市场选择,良性竞争和创新来完成的事情变成了强权和行会。其实这个问题是有解决方案的。伴随工业革命带来的人类劳动力巨大释放（具体见Berkley 大学De Long 教授对人类文明史的人均GDP分析）背后也有完整的机制，这些机制就是我们可以借鉴的出路：

1. 机会配置由市场决定。

2. 尊重知识产权和创新， 保护参与者的创新意愿。

3. 通过自由准入维持市场活力。

4. 最终由规模效应形成统一的事实标准。

虽然我还不能确定是否这是完整且合理中台机制， 但是我们的思想实验至少给了我们避免过去的失败的一些希望：

1. 谁来做中台，谁的设计才是真正合理的中台设计由市场决定。

3. 自由准入， 不做独家专供。

4. 不强制推行， 设计统一是演化的结果， 而不是行政命令。

4.中台的演进机制探索

不过哪怕有个这个机制， 我们还是要认识到中台天然的局限性， 中台不是万能的， 它仅仅合适在高确定性和高通用性场景下创造增量价值。没有合理的期望设定其实还会让迭代过程漫长而艰苦。在一个竞争环境下， 错误的目标设定不但会带来大量的资本和时间消耗，而且对员工士气打击也很大， 甚至会最终毁掉一家公司。

从公司层面来看， 中台要降低成本， 但是抽象带来的增值是有天花板的。抽象的终局是个零和游戏， 就不过是把前台的事情交割给中台去做。没有价值创造，只有权力转移。另外，中台要加速业务迭代也有逐渐减少的边际收入。 一个健康的行业中需求是永远进化的，不存在超前的完美设计为未来不断创造价值。中台在业务起初产生最大的价值，其后逐渐衰减。

从一个团队或者是BU角度来看，小BU期望通过中台带来业务增长，但事实上大BU的需求总是优先， 会占用几乎所有的中台资源。小BU的需求永远排在第二位，会饿死在等待的途中。另外中台靠合理的设计创造价值， 我们期望中台的设计是最优的， 但是真正有能力的架构师不一定在你所依赖的中台团队。你接触的中台边界不一定合理。如果中台很复杂， 跨团队的沟通也会变得更艰难。中台创造的增量价值就越小了。

从个人来看，每个人都期望能力提升， 但是擅于发现机会也擅于抽象的人不一定在中台团队。每个人都期望职业高速发展， 但是高增长的团队往往是高风险的前台团队，而高稳定的中台团队往往变化缓慢。所以没有不论中台还是前台团队， 人才的配置不一定是最优的。

知道了这些局限性， 我们才能对中台设定合理的期望。有了合理的期望， 我们还需要建设合理的迭代机制。这里我们还是可以借鉴其他领域的成功路径。我认为对中台机制探索应该向任何科学探索一样， 是个从假设到实验， 到结果分析， 到修正，最终到正确结论的过程。 我们从相对合理的中台诉求出发， 做合理的机制设计， 通过实施，到效果验证，然后对机制不断修正， 来最终得出逼近真理的一个机制。

5.车好多的中台实践

在分享车好多的中台实现机制之间， 我想先讲一下我为什么要分享车好多的机制。每一个机制设计和迭代都是一个漫长的过程。虽然我们刚刚开始， 但是我把我们中台的机制完整的分享出来，也欢迎大家采用， 甚至是加入到我们的建设中来。我也想听到反馈， 尤其是你们已经发现机制漏洞的地方，那么我们就能够共同进步。

5.1 为什么考虑在车好多做中台

首先，考虑在车好多做中台的原因和之前提到的几个原因类似：加速技术能力和业务能力扩散，整合数据资产，最大化公司资源利用。那么具体什么时间启动有这么几个考虑， 第一和下图有关， 就是中台启动之后的复杂度的变化情况。首先， 随着时间中台服务的调用频次逐渐上升， 往往呈指数上涨， 其次就是BU数目逐渐上升， 最后就是变更频次逐渐变少。太早上线其实价值不大， 因为极端情况就是一两条业务线之间做复用， 中台带来的合力还抵不上增加的重构成本， 沟通成本和人力开销。这一点上车好多有8条不同的业务线， 有了足够的场景复杂度和中台增值空间， 但是也不至于像某些公司有成百条业务线，建设难度非常大。 另外车好多的业务天生是低频业务， QPS低于传统电商３～４个数量级， 所以做中台有绝对优势。最后车好多的主流业务和新兴业务都在不同层次的迭代当中，所以我们的变更频次比较高， 对做中台也是利好。

但是车好多的中台也有自己的挑战：首先三大板块新车，二手车和车后的差异大，而且业务所处的阶段不一样， 有的在做增长，有的在做转型，有的在做赛道探索。所以同样有前面第二节里提到的中台适用范围的挑战。另外整个产业互联 行业还不同于传统互联 ，我们的产品技术还在从生产工具到核心生产力的过渡过程中。也就是说技术的投入是有限的，技术带来的增量价值也待验证， 所以研发投入不能过度超前。最后一个挑战是这几大板块对应着数万亿的线下市场，所以车好多的业务与线下高度结合， 流程往往以天计算， 因此变革要和行业的适配能力和期望相符。

5.2车好多的中台定位和组织文化保障

定位 – 车好多中台要解决的问题集中在集团高确定性和高通用性领域的技术和数据共享，我们不对创新业务探索加速。车好多中台是技术产业链的规模化之后的分工， 它的核心是对研发成本的优化和某些计算和运营资源的集中化管控和共享。

在文化保障上，技术上我们关注设计, 崇尚简约, 鼓励创新。对中台保持一个客观的态度， 中台回 不一定为正，也要迭代进化甚至消亡。中台既不是管理方式，也不是价值观。我们尊重学术自由， 中台设计没有权威， 逻辑面前人人平等。

下图是车好多的中台构成， 所有的业务线共享数据，计算，研发效能，和企业效能中台， 业务线对业务中台形成部分依赖， 算法能力我们还没有中台化， 更多是个共享的组织， 而不是共享的技术能力， 所以用虚线表示。 每个中台域的研发范围如图所示。业务线则按需定制， 我们通过控制业务线的研发人数防止膨胀软件。