郭东白的架构课_64_53思考实例下到底是什么因素左右了中台的成败
你好，我是郭东白。
这节课呢我们继续来讲中台有了上节课的分析呢，我们就可以来思考中台的合理定位和建设路径了。
顺便说一句呢，在阐述这个案例的过程中呢，我们将会采用之前介绍的分析思维。
你可以留行一下。
如果说总结中台创造的价值领域呢，我们可以归类为六类。
第一，低成本上线。
同一个功能模块呢在多个场景中被使用，要求这个能力的接口确定性高。
第二呢，加速上线，同一个基础能力呢不需要修改或者简单修改即可上线，也就是模块化支持要求高的API确定性和好的功能通用性。
第三，提升稳定性。
同一个业务能力呢持续打磨要求需求能够同时具备高的接口稳定性以及好的跨业务线通用性。
第四，加速能力扩散。
基础业务能力呢可以跨业务线模式要求，该能力呢具备比较好的通用性，可以在多个业务线之间共享。
第五类统一数据资产数据模型呢可以在多个业务线之间统一对功能的通用性要求高，且业务需求呢相对稳定。
第六，集团资源的高效利用业务能力共享不仅是技术资源，其实是业务能力有高的通用性，且需求稳定。
我把中台这六类增值场景呢放在一个四象限图里。
其中呢横轴代表技术演化的稳定性，数重呢代表功能通用性涂在文稿里。
听完音频呢你可以去看一下，我来强调一下图中的内容啊。
中台的优势领域呢在第三象限。
在这个象限里呢，技术具有高的确定性。
业务功能呢通用比较好的例子呢，其实是云计算、芯片、支付、物流等等。
第二象限呢属于比较稳定，但是不通用的小众行业。
第四象限呢属于普遍流行，但是高速变化的领域，比如说内容服饰和端上的交互的等。
而第一象限呢属于创新业务，不但定制化程度高，而且演化快速。
比如说垂直行业的创新技术或者监管一家依然在不断调整的领域。
当下很火的web three其实就是一个很好的例子。
从适用性的角度来说呢，我们可以得出这么一个结论，中台的使用范围呢是有限的。
仅仅限于技术演化相对慢且功能通用性高的场景中。
过往的中台示范案例呢也集中在把中台强推到创新业务中的情况下。
比如说前两年传遍全网的阿里国际化中台，就是这个例子。
在这里呢，我们把中台的缘起、弊端和定位都分析的差不多了，似乎要接近它的本质了。
不过你不要着急，这里面呢其实还有一个非常大的疑点。
依照我们刚才的分析，中台的使用范围是有限的，仅仅限于技术演化相对慢并且功能通用性比较高的场景中。
但是对于物流、供应链、财务这种在全球范围内标准化比较彻底，全球的业务形态又比较类似演化没那么快的疑点，国内企业为啥没有取得类似super sale中台那样的效率呢？为什么在北欧这些国家里，很多企业靠一两百个研发人员就能撑得起一个独角兽，甚至是跨多个大洲的超级独角兽呢？值得一提的是，类似super sale的中台呢并非个案。
在仅仅百万人口的小国艾沙尼亚就有四个独角兽，他们的中台团队呢也不过是百人左右。
为什么我们的中台动辄就是成百上千人的研发团队，但效率却更低呢？我先举一个我经历过的国际化物流中台示范的案例。
海外的物流体系不太发达，包裹损坏和丢失呢是个常事，而且损坏和丢失的原因呢也五花八门。
商家抱怨看不到真实的原因，然后不断的投诉平台。
而商家运营团队呢就希望系统能够透传各种本地定制的非标准化的原因投描述。
但是，国际化物流、中台和商家中台都不支持这个描述方式。
于是就这么一个变更需求，就需要和商家前台、商家中台、订单、中台、供应链、履约中台、物流中台、物流、前台、物流商接入团队、物流数据团队等，就个国家八个团队数百人达时协作。
而他们整个业务线汇报线的交集呢，就只有一个人，那就是一个十几万人物的大集团的CEO.这个问题呢整整拖了一年半都没办法达到排期。
其实原因呢也很简单，也很合理。
就海外业务来说，累计一年的订单都没有，国内的一天多，为了一个就是打引号的小错误，去修改一个支持日分值十亿级别的物流的中台，或者是全球的商家中台完全不值得，但就是这样一个又一个不值得的小需求，加在一起就成压死骆驼的最后一根稻草。
这里呢其实还有一个客观原因，前台业务的规模和优先级差异非常大当优先级差异太大的时候呢，就像任务调度问题中最常见的现象一样，第一，优先级任务呢会被饿死。
这种现象呢在技术侧呢也同样存在巨大的规模，差异呢，也会导致技术解决方案被匹配。
举个例子，我团队开发的一个营销场景的java的炸包之前呢只有一百三十兆营销领域。
被中台化之后，炸包的大小超过了三个g也就是说中台的解决方案巨大，复杂缓慢，低效成为托曼尼业务的一个重要原因。
这呢其实还不是根因，我有幸接触过芬兰和艾沙尼亚的几家独角兽，他们全球的业务体量其实差异也很大，本土、欧洲、非洲和亚洲的体量相比，能查出三四个数量级，那么他们为什么就可以支持这么大跨度的业务体量呢？分析到这里，我们就开始逼近国内中台的失败的根因了。
想找到根因呢，我们还得要总结一下中台常见的管理和建设方式。
第一，中央集权对于哪个团队做中台或者哪个人来做中台，是一个自顶而下的中央决策。
做中台的人呢缺乏必要的抽象能力以及业务理解能力。
第二，忽视产权掠夺。
创新。
中台的推行机制呢往往是一个掠夺的过程，对业务线的创新直接复制。
复制之后呢就立即裁掉前台团队，不尊重发明者的知识产权和劳动。
中台所到之处寸草不生。
第三独家授权。
中台能力一旦发布呢，由中台团队独家专供。
第怕功能不完善，设计不合理，也不允许业务团队复制或者是分支前台。
业务线，不仅看不到代码不能改，改动数据模型，还不允许另外搭建自己的版本。
第四，强制推行中台。
为了做规模，强制向业务线推行业务线呢，则被迫接受中台的设计方案，被迫修改上层代码，消除势力消耗严重。
每次中台升级呢，小BU呢更是叫鼓不迭，故障频乏。
如果你拿这些这建设方式跟上节课提到的中台弊端，对照一下，你很容易就明白为什么中台有拖慢业务，遏制创新人才流失和伤害客户的弊端了。
国内的中台呢因为一出生就具备绝对的权利，使得针对中台的权利方分配变成了封建王朝的分封制或者是专卖权的授予过程。
打个比方呢，在英国酒类的专卖权呢是最贵族最重要的收入来源。
但受分者呢仅仅是因为因为生在了地域，玩家，有没有酿酒的这个能力根本不重要。
那么中台在国内为什么会变成一个权力呢？当今国内几乎所有的大厂都有同样的晋升和薪酬激励机制。
一个人管理的研发越多，层级越高，收入就越高。
这种机制呢有一个巨大的弊段，一个奖励组织膨胀的机制必然会带来组织的膨胀，而组织的膨胀最终会因为康威定律的作用导致系统膨胀，也就是我们常说的loadware膨胀软件。
相比之下呢，北欧国家人口稀少，造就了存上简约、尊重原创以及组织扁平的研发膨胀。
而我们国家高科技行业从业人口全球第一。
过去十年间呢又有大量的新的从业者不断加入。
这些新的从业者呢又普遍有大厂情节，希望为一个技术品牌相对比较高的公司工作。
也就是说呢大厂具备了孵化中台的条件，而且有源源不断的对成长，没有太多诉求的劳动力。
所以客观来说呢，我们国内大厂确实存在着组织膨胀的土壤，有了土壤，又有了不合理的激励机制。
那么膨胀就变成必然了。
这种膨胀现象当然不信于中台，整个公司都在膨胀用。
这种膨胀对于中台而言，却是灾难性的。
一个膨胀的业务线伤害到了自己。
但一个膨胀的中台伤害到的是整个集团。
所以中台的建设要有和他匹配的组织和文化机制。
那么接下来呢我们就看看怎么建设中台。
首先呢就是要寻找中台的正确的组织文化机制，用什么样的机制才是合理的组织文化机制呢？很遗憾，我其实呢也不知道终极的正确答案。
但是我们可以用之前提到的历史观的思维方式，从过去的失败中寻求教训，从历史中寻找启发。
其实我们上节课提到的几个问题，并不是中泰所独有的。
上面的这个问题呢，其实和封建社会的分封制是类似的，本来应该由市场选择良性竞争和创新所来完成的事情。
现在被强权和封建制度所禁锢，而历史上打破这种禁锢的事件，在全球各地都成功的上演过，也就是工业革命和它背后的机制。
从某种角度来说呢，这些机制呢把人类从封建社会的束缚中解放了出来，释放了人类社会的创造力及其潜能。
所以从历史观来看呢，工业革命背后的机制就是我们可以间接的出炉。
那么这些机制是什么呢？第一，市场选择，也就是机会，配置呢是由市场决定的。
第二，保护产权，也就是尊过自由产权和创新，第护参与者的创新意愿。
第三，自由准入，也就是通过自由准入来维持市场活力，形成自然收敛。
最终通过需求带动的规模效应，形成统一的实施标准。
虽然我还不能确定这是不是最终的合理的中台机制，但是思想实验至少有可以让我们避免过去国内建设的一系列失败。
而未来的中台建设，必须要有公平的、合理的、能够保障长期价值创造的组织机制。
主要呢有四个，第一呢是由市场来选择最好的中台提供者以及最合理的设计。
第二，尊重原创，通过溯源和产权机制保护创新，有了自由准入，不做自上而下的独家专供。
第四，由市场化的经济机制，把技术加速收敛到规模效应最强的基础上。
有了这些机制呢，中台就不需要被强制推行呢。
因为中台设计统一是一个演化的结果，而不是一个行政命令。
那么接下来呢我们就进一步解释这四个机制的实施方法。
第一，逐步建设市场机是由前台业务线研发来做选型决策，保障业务优先。
同时，通过控制前台业务线的总人力成本来引导业务线做最优的决策。
最终呢靠市场和预算驱动最经济的决策，防止中台或者前台的膨胀。
而中台和前台呢必须要有统一的研发体系和人才流转机制。
在考核指标上，前台考核业务的增长。
而中台呢则考核前台对新需求响应的延迟，前台定制的成本和接口的高稳定性。
第二，尊重原创，把中台变成由需求迭代，来自我进化的过程，中台的代码边界组织边界和服务边界都不需要完全相等。
代码呢可以由原创团队用SDK发布，并且共享发明者呢自己他的团队和其他团队都可以重新包装这个SDK对外形成服务。
而其他的前台业务呢也可以直接引用SDK,也可以引用其他团队包装之后的服务。
也就是说呢，中台呢不是中央授权的，而是因为原创内容的价值而被普遍接受的。
第三，建设自由的准入能力。
并同时呢也要鼓励经营和创新。
将中台的代码开源允许前台业务分支建设、去中心化的研发体系加速分布式创新。
同时呢为了鼓励中台经营呢，通过控制前台业务线的研发成本，防止重复兆龙作为中台呢定期做设计review以及日常的变革约束，避免技术频繁重构的同时，保障大版本的迭代，能跟得上竞争的需求。
第四，控制前台的资金投入迫使前台在自研和中台之间做选择。
这样的话呢前台有限的资金最终会投入到增值最大的技术中去。
因此呢前台会理性的部分或者全部的选择中台技术，而不是去重复罩轮子，而被前台选择的技术也会获得相应的激励，进一步提升中台和开前台的适配性。
总结下来呢，中台的建设呢就要跟它匹配的市场化的尊重、原创的鼓励、经营的组织和激励机制。
有了中台相关的整体的市场文化和产权机制之后，我们就具备了建设中台的人和那么建设中台有天时和地利吗？答案是有的。
我们得出中台的正确定位和组织机制。
那么什么时候开始在企业里做中台呢？我在文稿里呢放了张图，它描述了中台启动之后的复杂度的变化情况。
首先呢，随着时间的推移，中台服务的调用频次逐渐上升，呈指数上涨。
其次，BU的数目呢逐渐减少，最后变更频次呢逐渐减少。
从这张图里能看到呢，太早上线中台其实价值不大的。
因为极端情况就是一两台业务线之间做复用，那么中台带来的合力还抵不上增加的重构成本、沟通成本和人力开项目。
所以呢中台需要有一个正确的启动时间，也就是我们说的天使。
这个天使呢发生在一家具备核心技术竞争力的企业，迅速扩张成多个垂直市场。
之前如果说呢一家企业呢有一个核心技术，而且这个核心技术呢在多个行业中都可以创造价值，比如说机器人技术或者图像识别技术。
那么这家企业呢可能会在短时间内迅速建立多条业务线，各自呢在定位上有差异，但是技术基础相似。
这时候呢多条业务线同时处在探索期，都需要控制成本和加速启动，那么中台呢就可以创造最大的增值。
如果我们做个简简单的建模呢，我们就会发现业务线的体量、业务线的数量以及需求变更的频繁程度，是决定这个中台研发复杂度的核心因素。
我们可以大致建模为中台的变更复杂度等于QPS乘以BU数除以变更频次。
就任何一个服务QPS越低，依赖这个服务的BU数就越少，迭代的就越频繁，那么变更的难度就越小，变更带来的风险呢也就越小。
为了帮助你理解这一点，我也在文稿里放了一张图。
在中台建设期间呢，由于自动化测试能力不够，接口设计不完善，团队同学的运维和沟通能力呢也还在成长中。
那么风险上升相对来说呢就比较快，等中台建设相对完善了，风险的增长和迭代难度呢就会逐渐变化。
所以呢最合适建设中台的企业最好有多条业务线，他们的体量相似，QPS都不高，业务线之间的相似度高，多条业务线的变更频次基本稳定。
了解了中台的启动时间和环境。
接下来呢我们再看看中台的质量保障和交付要求。
一旦过了孵化期呢，建设一个实体的中台呢，我们就必须要建立机制，对中台软件呢提出完整的要求和约束，防止出现膨胀的情况。
当然呢这么做呢也有实际的考量，以及各家公司开发中台很少对中台软件做出系统性的要求。
中台团队想交付什么就交付什么软件。
质量呢参差不齐，往往是项目的时间节点。
一到中台团队就三互完美，有什么就算什么业务团队呢？如果稍有抱怨，未来需求呢就不免遭受到打压。
为了避免这种情况呢，我们对中台软件做出要求。
这些要求呢有大致分为两类，一类是必要条件，一类是充分条件。
先说到两个必要条件，第一，中台软件必须有可解释性，也就是中台能力呢可以被完整描述的行为。
这里特别要向强调一下完整描述。
有些团队在做中台，先不说自己做啥，而是先占领一个关键词，然后再问前台延务，你想要什么，你想要什么，我们就可以做什么。
这是一个典型的圈地形态，对做什么功能解决什么问题，完全没有任何前瞻性的思考，结果呢就是越做越无序，前台团队呢跟着变得越来越低效。
第二，中台呢必须具备可验证性。
也就是说呢，中台的计算结果呢是可以被验证的。
中台交付的功能可以被证伪或者证真，这是独立测试需求。
很多中台从业务心里划分出来的，由于需求繁忙呢，一般不会对自己的边界做清晰的定位，更没有完备的自动化测试功能。
更别说场景的集成测试的，哪怕有边界也经常变动，没有兼容能力。
这个要求呢就是对能力和兼容性做限制，避免中台坠入深不可测的状态。
再说呢，两个充分条件就是第一呢中台软件必须具备可隔离性。
中台能力呢应该由多个相对独立的模块构成。
每个模块呢对相对实体的状态改变，必须对隔离。
在模块内部这个要求呢可以确保前台对中台的依赖做到最小化。
而且这种依赖可以局限在前台的个别业务模块中。
这样做呢既不会降低整个系统的稳定性，也可以防止中台过度侵入到前台无序扩张。
第二，中台的模块呢必须可以被局部替代，中台的各模块加载独立，而且个别模块所分装的能力可以被等价接口所替代，而不影响剩余的模块功能。
这个要求呢跟可解释性、可验证性一起，就可以允许业务线对中台形成部分依赖，而不是只依赖中台的一个功能，就必须要所有功能全依赖。
永远全家统。
为什么说前两个要求是必要条件的？因为他们合在一起，就是要解决中台提供能力的可分装性和可用性。
也就是说呢，一个前台团队可以根据能力的描述决定是不是要使用一个中台功能。
而后面的两个充分条件呢就是中台提供的能力，业务线可以选择不用，或者使用那些有价值的模块。
这样中台既可用，亦可弃满足了中台作为一个通用能力加速业务线迭代的充分必要条件。
那么我们来看看中台的退出机制，不是说建设了一个中台就永远存在了。
中台也要有竞争和退出机制架构好不好，赢得市场的认可才是第一性的。
内部的中台也必须证明它的市场价值。
一旦市场放弃它了，那么它作为一个中台的价值也就不存在了。
这种市场机制反映在技术设计上，主要包括在四个方面，第旦需求决定架构。
市场机制呢意味着市场会选择淘汰落后中台，多数时候呢由业务线的需求决定中台的架构选型，而不是由中台自行随意想象。
中台的架构不合理，跟当前的业务不匹配。
那么前台团队呢就不会选择某个中台技术，一旦被多数人放弃，那么这个落后的中台架构就消亡了。
第二，中台扁平化。
整个中台强制要求扁平化的微服务设计，降低依赖深度，加速复制和内部的竞争压力。
也就是说呢，某个中台可以占领搜索中台这样的大关键词。
但是对开源的要求和依赖复杂度的要求，意味着他必须提供足够优秀的解决方案，否则就会被分支掉。
第三，模块化开发状态必须由最小可用的独立模块构成，各模块之间有明确的边界和独立的文档，可以独立设计、发布。
被替代和升级。
模块呢尽量要以原子服务模式向上突出。
模块之间的依赖呢主要是服务依赖。
这种模块化的研发呢会让他们更容易被传播和引用。
未来呢也会出现更多的中台。
第四，可以自由存储，允许边界的存储，从而提升中台可以提供的能力范围。
其他团队呢也可以重新定义中台的边界，或者通过引用现有中台的部分模块，来重新定义一个不同的边界和抽象深度的中台。
只要有足够的市场需求，那么他也可以成长为一个新中台。
中台的具体边界和抽象深度呢是一个非常有挑战的问题，往往是个平衡，也没有对错。
因此呢，中台团队应该是有设计追求，也就是刚才提到过的边界存储机制。
从两方面呢最大化。
一方面呢是边界合理，也就是寻找中台的正确边界，平衡研发成本和业务迭代速度。
中台的边界呢应当使得API最简化。
另一方面呢，最大信息增值中台对多个业务的抽象呢逼近最优模型，在信息量最大的情况下能够保持相对稳定。
我在文稿里呢放了一张图展示呢，就是一个具体的例子。
我来在简单的解释一下图的内容，在图里呢左侧的模型呢比较简单，相稳稳定。
但是呢呢这个模型能提供服服务力度，右右侧的模型能更复杂。
这个模型呢能提供相对更细力度的服务。
如果后者能够同时适应多个业务性的现有模式的话，那么它的信息容量更大。
所以呢当前的业务矩阵之下呢是一个更好的模型。
事实上呢抽象力度这件事情呢不一个架构构做做了值，具体要分解成什么力度，是由市场做了算的。
我们之前在关于商业和技术周期竞争的法则里，就提到过当联网时代引假通知。
你做技术呢是为了服务用户的，你给用户提供的服务的精细程度。
服务质量迭代速度必须能保证用户能赢得竞争才行。
也就是意味着架构式的取舍不是一个艺术，而是一个理性思考的过程。
也就是说呢，如果你马马虎虎的做一个粗力度的服务，你还不如不做。
事实上呢这也是很多大中台最后一败涂地的重要原因。
有了中台启动分析质量保障交付需求，完整的竞争和退出机制。
在一个中台的确可以创造价值的环境内，你就可以建设中台了。
好了，关于中台的思考呢就是这么多。
我来简单总结一下，跟风大厂呢是一个非常愚蠢的行为，因为大厂自己也在犯错误，多数人连概念都没搞清楚，就一股脑入场大厂的优势。
你有嘛？中台不是靠相信就能成功的。
简单的相信其实就是交直生税思考的过程呢，其实是一个复盘过程。
你要不断的提出问题，一直发到根赢竞争环境决定你的架构动作。
在一个高度竞争的环境，架构的选择和升级是升级速度，不是你所能够完全左右的。
你要尊重市场，就像澳洲的生物，不进化的都被淘汰掉了。
有传统行业，在新互联网玩家进入之后呢，必须要升级。
比如说餐饮和外卖。
历史证明，在没有合理机制的情况下，市场机制就是一个好机制。
好的，最后是我们的思考题环节。
今天的题目呢有两道，你可以根据自己的实际情况任选一道来作答。
第一题，你有过失败的中台经历吗？你能不能把你的案例分享出来？其中的根因是什么呢？和我们课程中提到这些原因有关系吗？第二题，你所在的团队或者公司有成功建设中台的案例吗？成功的原因是什么？欢迎把你的思考和想法分享在留言区，我欢迎你把课程分享给你的朋友。
咱们下节课再见。