我在阿里巴巴工作期间是一个名副其实的“刺头”，批判中台、批判架构师、批判技术管理者，当然，也包括自我批判。
今天就先聊聊批判中台！前些年，阿里巴巴提出了“大中台、小前台”战略，在业界掀起了不小的波澜，一时间，各种中台建设的方法论和最佳实践满天飞。
中台的底层逻辑是什么？中台能带来的价值到底是什么？
我们有必要用批判的眼光来审视一下中台建设。
中台的底层逻辑中台的底层逻辑，用一句话解释就是通过复用提升研发效率。建一所房子，首先要打地基、铺钢筋，然后往上一块一块地垒砖头。没办法，原子世界就是这么物质，一块砖头都少不了。软件是比特世界，软件开发很少是从买服务器开始的，特别是在云原生时代，云厂商通常已经帮我们做好了“基建”的事情。IaaS是对算力、网络、存储、操作系统等基础设施的复用，PaaS是对中间件的复用。
如图1所示，基于这样的演进路径，有没有可能做一个Business-PaaS（业务中台），提炼业务中具有共性的内容，减轻前台业务，提升研发效率呢？
图1业务中台的位置
单看图1，这个逻辑似乎是通的。于是，在“大中台、小前台”的旗帜下，业务中台诞生了。可是不管是一线研发人员的反馈，还是高层人员的质疑声，都表明了业务中台似乎并没有解决问题，反而制造了更多的阻碍和困难，这是为什么呢？
业务中台为何低效中台战略没有错，大中台也没有错，技术中台、数据中台都没问题，为什么到业务中台就出现问题了呢？我想问题就出在这个“业务”身上。IaaS也好，PaaS也罢，之所以能提效，是因为其具有业务无关性，它们和业务的边界很清晰，彼此正交，互不干扰。IaaS和PaaS解决的是技术问题，业务解决的是业务问题。PaaS偶尔也会侵入业务应用，为了与应用隔离解耦，于是有了PandoraBoot、ServiceMesh等技术。
业务中台却没有这样的“好命”，它解决的是复杂、多变的业务问题。如果你把镜头拉近一点看，会发现业务和业务中台的关系并不是像我们理想的一样在中间有一道清晰的边界线，而是像图2一样，犬牙交错地耦合在一起。
图2业务和业务中台的关系
前台业务要借助业务中台一起去完成业务逻辑，所以有一部分埋在了业务中台里，至于埋得多深，则取决于使用中台能力的多少，用得多就埋得深，用得少就埋得浅。
因此，用一句话来说，业务中台低效的根本原因在于，前台业务和业务中台的“深度单体耦合”。这种耦合性至少在以下3个方面严重影响了整体的研发效率。
1.协作成本
研发≠写代码，实际上我们大部分时间不是在写代码，而是在沟通协调，况且与人打交道要比与机器打交道麻烦得多。这也是《人月神话》一书中说“加人只会让项目更糟糕”的原因，因为额外增加了更多的协作成本。
除了组织协作成本倍增，耦合带来的工程协作成本也很高。试想一下：如果几百名研发人员在同一个代码库上修改代码并部署，会是怎样的体验？
以下是一位同事的真实反馈：
“业务中台在外面宣传的是业务方7í24小时想发就发，实际远远做不到，很多限制，效率很低，体验过才知道。”
2.认知成本
就阿里巴巴的业务中台体系来说，不可谓不复杂，其中有大量的新概念——业务身份、活动（Activity）、领域服务（DomainService)、领域能力（Ability）、扩展点（ExtensionPoint），扩展实现（Extension）、奥创、Lattice、业务容器，等等。这些概念显著增加了开发者的认知负荷，让系统变得异常复杂。
正如尼古拉斯所说，
在现代生活中，简单的做法一直难以实现，因为它有违某些努力寻求复杂化以证明其工作合理性的人所秉持的精神。
3.稳定性成本
现在的业务中台很精巧，同时也很脆弱。它与所有的大设计（Bigdesignupfront）犯了同一个错误，即忽视了那些“对未知的未知（Unknowunknows）”。业务的灵活性和差异性导致我们很难提前抽象，因为抽象在归纳之后，可是新的业务需求还没出现。
理想的情况是我们能预见所有的业务变化，提前做抽象，预留所有的业务扩展点，这样针对不同的业务只需要在扩展点中定制就好了。但没人能预见未来，这样就难免要改动平台代码，比如加一个扩展点。由于平台代码是被所有业务共享的，这就给稳定性带来了极大的隐患。比如，A业务改动了平台代码，然而B业务什么也没做就出了故障。
解决中台的困境为了解决上述业务中台碰到的问题，我认为可以尝试做以下工作。（1）把业务能力做薄。做薄是为了解耦，业务最懂自己，因此不要尝试去“control”它们。中台可以更多地