郭东白的架构课55

你好，我是郭东白。

有了上节课的分析，我们就可以来思考中台的合理定位和建设路径了。顺便说一句，在阐述这个案例的过程中，我们将会采用第49节介绍的分析思维，你可以留心一下。

国内中台失败的根因

中台的合理定位

如果总结一下中台创造价值的领域，可以归纳出如下六类：

1. 低成本上线：同一个功能模块在多个场景中被使用，要求该能力的接口确定性高。
2. 加速上线：同一个基础能力不需要修改，或者简单修改即可上线。也就是模块化支持，要求高API确定性和好的功能通用性。
3. 提升稳定性：同一个业务能力持续打磨，要求需求能同时具备高的接口稳定性和好的跨业务线通用性。
4. 加速能力扩散：基础业务能力可以跨业务线模式，要求该能力具备比较好的通用性，可以在多个业务线之间共享。
5. 统一数据资产：数据模型可以在多个业务线之间统一，对功能的通用性要求高，且业务需求相对稳定。
6. 集团资源高效利用：业务能力共享，不仅仅是技术资源，其实是业务能力有高通用性，且需求稳定。

如下图所示，我把中台这六类增值场景放在了一个四象限图里。其中横轴代表技术演化的稳定性，竖轴代表功能的通用性。

我也再来强调一下图中的内容：

• 中台的优势领域在第三象限，在这个象限中，技术具有高确定性，业务功能通用，比较好的例子是云计算、芯片、支付、物流等。
• 第二象限属于比较稳定，但是不通用的小众行业。
• 第四象限属于普遍流行，但是高速变化的领域，比如内容、服饰和端上的交互等。
• 而第一象限属于创新业务，定制化程度高，演化快速。比如垂直行业的创新技术，或者监管依然在不断调整中的领域，当下很火的Web 3就是一个很好的例子。

从适用性角度来说，我们可以得出这样的结论：中台的使用范围是有限的，仅仅限于技术演化相对慢，且功能通用性高的场景中。

过往中台的失败案例，也集中在把中台强推到创新业务中的情况，比如前两年传遍全网的某大厂国际化中台就是典型的例子。

中台的困惑

对于中台的失败，上节课分析似乎很完美了，但是这里还有一个非常大的疑点。依照前面的分析，中台的使用范围是有限的，仅仅限于技术演化相对慢且功能通用性高的场景中。

但对于物流、供应链、财务这种在全球范围内标准化比较彻底，业务形态在全球上又比较类似的、演化也没那么快的领域，怎么没有看到国内企业能取得类似Supercell中台那样的效率呢？为什么北欧这些国家里，很多企业靠100~200个研发人员便能撑起一个独角兽，甚至是跨多个大洲的超级独角兽？

值得一提的是，类似Supercell的中台并非个案，仅仅百万人口的小国爱沙尼亚就有4个独角兽，他们的中台团队也不过是百人左右。为什么我们的中台动辄就是成百上千人的研发团队，但效率却更低呢？

先举一个我经历过的国际化物流中台失败的案例：海外的物流体系不发达，包裹损坏和丢失是个常事儿，而且损坏和丢失的原因也五花八门。商家抱怨看不到真实原因而不断投诉平台。所以商家运营团队期望系统能够透传各种本地定制的、非标准化的原因描述，但是国际化物流中台和商家中台都不支持这个描述方式。

于是这么一个变更需求，就需要商家前台、商家中台、订单中台、供应链履约中台、物流中台、物流前台、物流商接入团队、物流数据团队等三个国家八个团队数百人同时协作，而他们在整个企业中汇报线的交集只有一个人，那就是一个十几万人的大集团的CEO。

这个问题整整拖了一年半都没办法得到排期。原因很简单也很合理：就海外业务来说，累积一年的订单都没有国内一天的多。为一个“小错误”，而去修改一个支持日峰值十亿物流的中台或全球的商家中台，完全不值得！但就是这样一个又一个不值得的小需求，加在一起就成了压死骆驼的最后一根稻草。

这里还有一个客观原因：前台业务的规模和优先级差异很大。当优先级差异太大的时候，就像任务调度问题中常见的现象一样，低优先级任务会被饿死。

这种现象在技术侧也同样存在，巨大的规模差异会导致技术解决方案不匹配。举个例子，我团队开发的一个营销场景Java Jar包，之前只有130M。营销领域被中台化之后，Jar包的大小超过了3G。中台的解决方案巨大、复杂、缓慢、低效，成为拖慢业务的一个重要因素。

这还不是根因。我有幸接触过芬兰和爱沙尼亚的几家独角兽，他们全球的业务体量其实差异也很大。本土、欧洲、非洲国家的体量和亚洲的体量相比，能差出三四个数量级，他们为什么就可以支持这么大跨度的业务体量呢？

分析到这里，我们就开始逼近国内中台失败的根因了。

国内中台各种弊端的根因

想找到根因，我们先来总结描述一下国内中台常见的管理和建设方式：

1. 中央集权：对哪个团队做中台或者哪个人做设计中台的决策，是个自顶而下的中央决策。做中台的人缺少必需的抽象能力和业务理解能力。
2. 忽视产权，掠夺创新：中台的推行机制往往是个掠夺的过程。对业务线的创新直接复制，复制之后就立即裁撤前台团队，不尊重发明者的知识产权和劳动。中台所到处，寸草不生。
3. 独家授权：中台能力一旦发布，由中台团队独家专供，哪怕功能不完善、设计不合理，也不允许业务团队复制或分支。前台业务线不仅看不到代码，不能改动数据模型，还不允许另外搭建自己的版本。
4. 强制推行：中台为了做规模，强制向业务线推行，业务线则被迫接受中台的设计方案、被迫修改上层代码，削足适履，消耗严重。每次中台升级，小的BU更是叫苦不迭，故障频发。

如果拿这些建设方式和上节课提到的中台弊端对照一下，就不难明白为什么中台有拖慢业务、遏制创新、人才流失和伤害客户的弊端了。

国内的中台因为一出生就具备绝对的权力，使得针对中台的权力分配，变成了封建王朝的分封制或者专卖权授予的过程。打个比方，在英国，酒类的专门权是贵族最重要的收入来源，受封者仅仅是因为生在了帝王家，有没有酿酒能力根本不重要。

那么中台在国内为什么会变成一种权力呢？当前国内几乎所有大厂都有着同样的晋升和薪酬激励机制：一个人管理的研发越多，层级越高，收入也就越高。这种机制有个巨大的弊端：一个奖励组织膨胀的机制，必然会带来组织的膨胀。而组织膨胀最终会因为康威定理的作用，导致系统膨胀，也就是我们常说的膨胀软件（Bloatware）。

相比之下，北欧国家人口稀少，造就了崇尚简约、尊重原创和组织扁平的研发文化。而我们国家的高科技从业人数全球第一，过去十年间又有大量新的从业者不断加入。这些新的从业者又普遍有大厂情节，期望为一个技术品牌相对比较高的公司工作。

也就是说，大厂具备了孵化中台的条件，且有源源不断的对成长没有太多诉求的劳动力。所以客观上来说，我们国内大厂的确存在组织膨胀的土壤。有了土壤，又有了不合理的激励机制，那么膨胀就变成必然了。

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

所以中台的建设，要有与之匹配的组织和文化机制。

建设中台的天时地利与人和

寻找中台的正确组织文化机制

那么什么样的机制才是合理的组织文化机制呢？很遗憾，我也不知道终极的正确答案。但是我们可以利用第49节提到的历史观的思维方式，从过去的失败中寻求教训，从历史中寻找启发。

其实上节课提到的几个弊端并非中台所独有。这些问题和封建社会的分封机制类似，本来应该由市场选择、良性竞争和创新来完成、解决的事情，现在却被强权和封建制度所禁锢。

而历史上打破这种禁锢的事件，其实在全球各地都成功上演过，也就是工业革命和它背后的机制。从某种程度上来说，这些机制就是把人类从封建社会的束缚中解放了出来，释放了人类的创造力和潜能。所以从历史观来看，工业革命背后的机制就是我们可以借鉴的出路。

那么这些机制都包括什么呢？

1. 市场选择 ：机会配置由市场决定。
2. 保护产权：尊重知识产权和创新，保护参与者的创新意愿。
3. 自由准入：通过自由准入来维持市场活力。
4. 自然收敛：最终通过需求带动的规模效应，形成统一的事实标准。

虽然我还不能确定这是不是最终合理的中台机制，但思想实验至少可以让我们避免过去国内中台建设的一系列失败。而未来的中台建设，必须要有公平的、合理的、能够保障长期价值创造的组织机制，主要包括如下四个机制：

1. 由市场来选择最好的中台的提供者和最合理的设计。
2. 尊重原创，通过溯源和产权机制保护创新。
3. 自由准入，不做自上而下的独家专供。
4. 由市场化的经济机制，将技术加速收敛到规模效应最强的技术上。

有了这些机制，中台就不需要被强制推行了。因为中台设计统一是演化的结果，而不是行政命令。那么接下来，我们就来进一步解释这四个机制的实施方法。

第一，逐步建设市场机制。由前台业务线研发来做选型决策，保障业务优先。同时，通过控制前台业务线的总人力成本，来引导业务线做最优决策。最终，靠市场和预算驱动最经济的决策，防止中台或前台的膨胀。

而中台和前台，必须有统一的研发体系和人才流转机制。在考核指标上，前台考核业务增长，中台则考核前台对新需求响应的延迟、前台定制的成本和接口的高稳定性。

第二，尊重原创。把中台变成由需求的迭代而自我进化的过程。中台的代码边界、组织边界和服务边界都不需要完全相等。代码可以由原创团队用SDK发布并共享，发明者自己、他的团队、其他团队都可以包装这个SDK，并对外形成服务。其他前台业务可以直接引用SDK，也可以引用其他团队包装后的服务。

也就是说，中台不是中央授权的，而是因为原创内容的价值而被普遍接受。

第三，建设自由准入能力，同时鼓励经营和创新。将中台的代码开源，允许前台业务分支，建设去中心化研发体系，加速分布式创新。同时，为了鼓励中台经营，通过控制前台业务线的研发成本防止重复造轮。对中台定期做设计Review和日常的变革约束，避免技术频繁重构的同时，保障大版本的迭代能跟上竞争的需求。

第四，控制前台的资金投入，迫使前台在自研和中台之间做选择。这样的话，前台有限的资金最终会投入到增值最大的技术上去，因此前台团队会理性地部分或全部选择中台技术而不是去重复造轮子。而被前台选择的技术也会获得相应的激励，进一步提升中台和该前台的适配性。

总结下来，中台的建设要有与之匹配的市场化的、尊重原创的、鼓励经营的组织和激励机制。

有了中台相关的整体市场、文化和产权机制之后，我们就具备了建设中台的人和。那么中台建设有天时和地利吗？答案是有的。

中台的启动时间和环境

我们得出了中台的正确定位和组织机制，那么什么时候可以开始在企业里做中台呢？

如下图所示，它描述了中台启动之后的复杂度的变化情况。首先，随着时间的推移，中台服务的调用频次逐渐上升，呈指数上涨。其次，BU数目逐渐上升。最后，变更频次逐渐变少。

从这张图可以看到，太早上线中台其实价值不大。因为极端情况就是一两条业务线之间做复用，那么中台带来的合力还抵不上增加的重构成本、沟通成本和人力开销。

所以中台需要有一个正确的启动时间，也就是我们说的天时。这个天时发生在一家具备核心技术竞争力的企业在迅速扩张成多个垂直市场之前。

如果一家企业有了一个核心技术，而且这个核心技术在多个行业中都可以创造价值，比如说机器人技术或者图像识别技术。那么这家企业可能会在短时间内迅速扩展建立多条业务线，这些业务线在定位上有差异但是技术基础相似。这个时候，多条新业务线同时处在探索期，都需要控制成本和加速启动，那么中台就可以创造最大的增值。

如果我们做个简单的建模，会发现业务线的体量、业务线的数量和需求变更的频繁程度，是决定这个中台研发复杂度的核心因素。那么我们可以大致建模为：中台变更复杂度=（QPS*依赖中台的BU数量/变更频次）。

任何一个服务，QPS越低，依赖这个服务的BU数就越少，迭代得就越频繁，那么变更的难度就越小，变更带来的风险也越小，如下图所示。

在中台建设期间，由于自动化测试能力还不够，接口设计不完善，团队同学的运维和沟通能力也还在成长中，那么风险上升相对来说就比较快。等中台建设相对完善了，风险的增长和迭代难度就会逐渐变缓。

所以最合适建设中台的企业最好有多条业务线，它们的体量相似，QPS都不高，业务线间相似度高，多条业务线的变更频次基本稳定。

中台的质量保障和交付要求

一旦过了孵化期，要想建设一个实体的中台，就必须要建立机制，对中台软件提出完整的要求和约束，防止出现膨胀的情况。

当然，这么做也有很实际的考量。以前各家公司开发中台，很少对中台软件做出系统性的要求。中台团队想交付什么就交付什么，软件质量参差不齐，往往项目的时间节点一到，中台团队就三呼完美，有什么就算什么。

业务团队如果稍有抱怨，未来的需求就免不了遭受打压。为了避免这种情况，就必须对中台的软件做出要求。这些要求又可以大致分成两类，一类是必要条件，一类是充分条件。

先说两个必要条件。第一，中台软件必须具有可解释性，也就是中台能力可以被分解成一组可以被完整描述的行为。

这里要特别强调一下完整描述。有些团队做中台，先不说自己能做什么，而是先占领一个关键词，然后再问前台业务团队想要什么。“你想要什么我们就可以做什么”，这是一种典型的圈地心态。对做什么功能、解决什么问题，完全没有任何前瞻思考，结果就是越做越无序，前台团队跟着变得越来越低效。

第二，中台必须具备可验证性，也就是说中台的计算结果可以验证，中台交付的功能可以被证伪或被证真。这是独立的测试需求。

很多中台是从业务线里划分出来的。由于需求繁忙，一般不会对自己的边界做清晰的定义，也没有完备的自动化功能测试，更别说场景集成测试了。哪怕有边界，也经常变动，没有兼容能力。这个要求就是对能力和兼容性做限制，避免中台堕入深不可测的状态。

再说两个充分条件。第一，中台软件必须具备可隔离性，中台能力应该由多个相对独立的模块构成，每个模块对相关实体的状态改变，必须隔离在模块内部。

这个要求可以确保前台对中台的依赖做到最小化，而这种依赖也可以局限在前台的个别业务模块中，既不会降低整个系统的稳定性，也可以防止中台过渡侵入到前台，避免无序扩张。

第二，中台的模块必须可以被局部替代。中台的各模块加载独立，且个别模块所封装的能力可以被等价接口所替代，不影响剩余的模块功能。这个要求与可解释性/可验证性合在一起，就可以允许业务线对中台形成部分依赖，而不是只要依赖中台的一个功能，就必须所有功能全依赖，永远全家桶。

为什么说前面两个要求是必要条件呢？因为它们合在一起，就是要解决中台提供能力的可封装性和可用性。也就是说，一个前台团队根据能力的描述，可以决定是否使用中台功能。

而后面两个是充分条件，就是因为中台提供的能力业务线可以选择不用，或者部分使用那些有价值的模块。这样一来，中台既可用亦可弃，满足了中台作为一个通用能力来加速业务线迭代的充分必要条件。

中台的退出机制

不是说建设了一个中台就永远存在了，中台也要有竞争和退出机制。架构好不好，赢得市场的认可才是第一性的。内部的中台也必须要证明自己的市场价值，一旦被市场放弃了，那么中台的价值就不存在了。

这种市场机制反映在技术设计上如下：

1. 需求决定架构。市场机制意味着市场选择会淘汰落后中台。多数时候，由业务线需求决定中台的架构选型，而不由中台自行想象。中台的架构不合理，与当前业务不匹配，那么前台团队就不会选择某个中台技术。一旦被多数人放弃，这个落后的中台架构就消亡了。
2. 中台扁平化。整个中台强制要求扁平化的微服务化设计，降低依赖深度，加速复制和内部竞争压力。也就是说，某个中台团队可以占领搜索中台这样的大关键词，但是开源和依赖复杂度的要求，就意味着它必须提供足够优秀的解决方案，否则就会被分支掉。
3. 模块化开发。中台必须由最小可用的独立模块构成，各模块之间有明确的边界、独立的文档，并且可独立设计/发布/被替代/升级。模块尽量以原子服务模式向往透出，模块间的依赖主要是服务依赖。这种模块化的研发，让它们更容易被传播和引用，未来也会出现更多的中台。
4. 可自由重组：允许中台边界的重组，从而提升中台可以提供的能力范围。其他团队可以重新定义中台的边界，或者通过引用现有中台的部分模块来重新定义一个不同边界和抽象深度的中台。只要有足够的市场需求，就可以成长为一个新中台。

在这里，中台的具体边界和抽象深度是个非常有挑战的问题，往往是个平衡，没有对错。对此，中台团队应该有以下的设计追求，也就是通过上面的边界重组机制，最大化以下两点。

第一，边界合理。寻找中台的正确边界，平衡研发成本和业务迭代速度，中台的边界应当使得API最简化。

第二，最大信息增值。中台对多个业务的抽象逼近最优，模型在信息量最大的情况下能够保持相对稳定。

下图就是个具体的例子，左侧模型简单，相对稳定，但是在这个模型下能够提供的服务粒度粗。右侧模型更复杂，在这个模型下能够提供相对更细粒度的服务。但是如果后者能够同时适用多个业务线的现有模式的话，那么它的信息容量更大，所以在当前的业务矩阵之下是个更好的模型。

事实上，抽象粒度这件事情不由一个架构师说了算。具体要分解成什么粒度，是由市场说了算。我们之前在互联网的商业和技术周期的竞争法则里就提到过，互联网时代赢家通吃。

你做技术是为了服务用户，给用户提供的服务的精细程度、服务质量、迭代速度，必须保证你的用户能赢得竞争才行。这也意味着架构师的取舍不是一个艺术，而是一个理性思考的过程。

也就是说，你马马虎虎做一个粗粒度的服务，还不如不做。事实上，这也是为什么很多大中台最后一败涂地的原因之一。有了正确的中台启动分析、质量保障、交付要求和完整的竞争和退出机制，以及的确可以创造价值的环境内 ，你就可以建设中台了。

小结

跟风大厂是个非常愚蠢的行为。因为大厂自己也在犯错误。多数人连概念都没搞清楚就一股脑入场。大厂的优势你有吗？要知道，中台不是靠相信就能成功的，简单的相信就是交智商税。

竞争环境决定了你的架构动作，在一个高度竞争的环境，架构选择和升级速度不是你能完全左右的，要遵从市场。就像澳洲的生物，不进化的话就会被淘汰掉。任何传统行业在新互联网玩家进入之后必须升级，比如说餐饮和外卖。

历史证明，在没有合理的机制的情况下，市场机制就是个好机制。

思考题

1. 你有过失败的中台经历吗？能否将你的案例分享出来？根因是什么呢？和我们在课程中提到的这些原因有关系吗？
2. 你所在的团队或公司有成功建设中台的案例吗？成功的因素有哪些呢？

欢迎把你的思考和想法分享在留言区，咱们下节课再见！