中台究竟被谁搞死了？
作者 | 马工在瑞典
来源 | 瑞典马工
中台是有价值的
波吉的《中台：一场彻头彻尾的自欺欺人》题目很直接，再一次说出了中台这个国王没有穿衣服的事实，以至于很多人都羞于承认自己在做中台。业界也掀起了中台究竟有没有价值的讨论。
如果把中台换成阿里巴巴集团最开始的名字“共享业务事业部”，可以看出中台的价值是不需要质疑的：任何上规模的企业都会有一些共享IT系统是由集团建设以供业务单元直接使用的。
中台的价值，在我看来有两个：降低不同业务单元的协作成本和落实集团的管控权。
中台降低不同业务单元
的协作成本
数据是现代企业的命脉。各个业务单元会产生大量的经营数据。出于大家都知道的原因，甲部门并不一定愿意和乙部门共享这些数据。如果随机查看一个大型企业的邮件和会议纪要，会看到大量的时间花费在部门间的数据请求上。
工作流也是如此。如果一个项目需要跨部门的工作流协调，那么项目的落地时间就要以年计算。很多大型企业，为什么养了很多看上去完全没有专业技能的老混子？一个重要因素就是这些老混子掌握了书面上不会写下来的工作流和人员信息，他们确实能帮助项目快速落地。
中台的价值就在于，与其依赖不可靠的人际沟通，不如在IT系统上打通数据和工作流，使得毕业生也能做到以前只有老混子才能做到的跨部门协作。
试举一例，一家上规模的传统零售企业试水电子商务，在初期可能选择独立建设电商的CRM。随着电子商务规模增长，出现了线上客户要在线下门店退货的需求，但是门店并没有这个客户的账号/订单/支付信息，这是一个难题。
如果电商部的客服部如果想连接线上线下的用户系统，退货流程和财务流程，不说不可能，至少也是成本高到得不偿失。
这时候集团如果能建设一个统一的用户账号系统，那么不仅退货流程能自然打通，甚至可以做到线上线下互相引流，互相交叉销售，共享库存。
这种中台，我们可以称之为协作型中台。
中台落实集团的管控权
集团的集中管理权和业务单元的自主权，几乎是一个永恒的管理学冲突。这里并没有放之四海而皆准的分配方式。淘宝天猫的统一账号系统很好的促进了业务的发展，而微信/QQ账号的隔离似乎也行得通。我们只能信任集团CEO做出明智的决策，而当他/她决定了某种分配方式的话，下一个问题自然就是：怎么低成本的落实CEO的决定？如果只是发一些红头文件或者会议纪要，那业务单元很可能钻漏洞或者阳奉阴违，落实效果很难保证，落实成本也很高。这时候中台就排得上用场了。
这种共享中台的实质就是：
CEO决定收回某些权力到集团。
用IT系统把上述权力分配固化下来。
此处有一个很明显的场景：欧盟GDPR规定企业严重侵犯客户个人信息的话，可以处以全球销售额4%的罚款。而众所周知，狂奔的新兴业务单元，不管是意愿上还是能力上，都不是个人信息最佳的保护者。如果CEO认为新兴业务飞速增长的价值，并不能覆盖4%营业额罚款的风险，那么建设一个直属的用户账号中台，对个人信息予以严格的保护，是非常明智的选择。
如果没有中台，而只是不停的让集团办公室，合规部，政府关系部，网络安全部，审计部给业务单元发红头文件搞突击检查，效果显然会差很多。
如果稍微引申一下，金税系统，可以看作是中央政府的一个中台系统。数据从企业直接上报到总局和省局，地方政府只是金税工程的用户之一。
这种中台，我们可以称之为管控型中台。
节省投资不是中台
的价值所在
中台鼓吹者一直主张的“中台有助于节省重复投资”，我觉得是一种很没有深度的判断：如果业务单元愿意重复投资，说明他们承担得起建设的成本，那让人家投资就好了，你为什么要替业务单元节省人家自己不想节省的钱？
就像你办公室10个人，如果忍受一点不方便的话，5台电脑也够用。你还是会配备10台电脑（甚至11台），因为你们承担得起。这时如果其他部门过来一个人说“我来建设一个笔记本中台，节省你们办公室在笔记本上的重复投资”，你们只会觉得他神经病吧。
这种中台，我们称之为“吃饱了撑着没事找事干中台”。
中台是一个管理学工具
综上所述，和ERP一样，中台主要是一个管理学的工具。它不是像数据库一样的IT工具，也不是一个能获客的App，更不是能解决业务发展问题的神丹。
可惜这不是中台爱好者们向市场传递的信息。过去几年，中台爱好者给甲方做虚假承诺，几乎惹起了人神共愤。此处不再详述，有兴趣的读者可以阅读36氪的这一篇《中台，我信了你的邪》。
在很多没有底线的南郭先生之外，也要承认中台爱好者有很多实实在在的技术人员。他们不能被简单的视作骗子，但是这批人也要对中台的失败承担起以下道德责任：
中台爱好者无法定义中台
中国IT从业者的工程实践能力是不可否认的。在各方的夹击下，中国产App仍然占据了美国App Store前六名的一半：CapCut和TikTok分别是字节跳动剪影和抖音的美国版，Temu是拼多多的美国版。
但是中国IT从业者缺乏抽象能力，无法从良好的实践中总结出共性因素，不能给读者呈现一个清晰的模型，从而就无法影响行业发展。我在文章《BAT真的是高科技公司吗？》对此有过抨击。
中台，作为中国的原创概念，本来可以是一个很好的突破。但是可惜的是，不论是阿里的倡导者，还是外部的推广人，都从来没有给出一个清晰的中台定义。
我以阿里钟华《企业IT架构转型之道—阿里巴巴中台战略思想与架构实践》为例，全书两百多页，宏观上讲到了阿里巴巴共享事业部的历史， 微观上讲到了“使用JDBC 时，不支持useServerPrepStmts=true参数设置”，就是没有回答几个关键问题：
中台究竟要解决什么问题？
中台不是什么？（这个问题甚至可能比中台是什么更重要）
中台的限制和前提条件是什么？
中台的用户是谁？
中台有什么分类？
行业从来没有在以上几个问题得到共识，导致我们看到的一个尴尬事实：中台可以用来指代任何计算机上跑着的系统。最后，中台 is everything, and 中台 is nothing。
中台爱好者分不清业务，
组织和IT工具
再以上书为例，书中有一个架构图：
这个图把业务，共享IT系统，具体的云服务，以及运维等完全不同维度的东西混在一起，造成了这样一个效果：外行看起来很有道理，但是内行看了一脸懵逼。
一个内行会自然的问：
上层的业务只是业务，还是包含了业务自己的IT系统？
共享业务单元是标准品，而业务必然有巨大而且持续的定制化需求，这个定制化反应在哪里？
图中显示阿里云平台只支撑共享业务事业部，阿里巴巴集团业务只接受共享业务事业部的支撑，是否意味着阿里巴巴集团业务并不直接使用阿里云？
图中的阿里云平台是否是必须的？如果不在云上，对中台和业务有什么影响？
图中右侧运维是一条从上画到下的竖线，是否意味着阿里云/共享业务事业部/阿里巴巴集团业务的运维是共享的？
所有这个问题都没有得到讨论，作者画完图之后，就认为他已经证明了“共享业务事业部在阿里巴巴业务架构中的重要地位”，而读者实际上更迷惑了。
中台爱好者没有技术追求
中台作为一个管理学的IT工具，在落地的时候，必然以满足管理者的需求为最高优先级，不得不会在产品和技术上有所牺牲，这是所有成年人都能理解的妥协。
但是一个成熟的从业者，也必须认识到，这种牺牲是一种实施过程中的临时决策，在有条件的时候，还是要追求产品的标准交付。
不幸的是，中台从业者普遍缺乏这种独立的技术追求。
上书中提及阿里巴巴很多中台组件提供图形操作界面：
淘宝的商品中心的商品发布能直接提供用户操作界面，商品的泪目管理也会有淘宝小二操作的界面，类似的交易中心，营销中心都有提供界面形式的服务能力
有经验的读者一看就知道，这只能是办公室政治的产物。因为从技术上而言，中间件/中台提供无法复用的图形操作界面是绝对愚蠢的，会使得业务单元定制的成本上升一个数量级，也会使得中台部门陷入无穷无尽的定制活动中。这是行业常识。
但是作者没有勇气承认这种尴尬的历史事实，而是从部门利益出发，试图证明中台也可以，甚至应该，提供图形用户界面。这就让人忍不住摇头了。
实际上，中台从业者不只是技术不行，在项目管理上也很业余。比如下图是我随便找到的一个数据中台交付能力概述：
当年工农红军在根据地面对广大文盲群众，选择顺口溜来做宣传工作，取得了巨大的成功。但是现在在高等教育毛入学率达到59.6%的今天，这种一二三四五的顺口溜实在没有必要。明显可以看出作者为了文本的工整，生编硬造了一些无聊的概念。这对中台的传播和落地，实在不会有帮助。
总结
如上所述，中台本来可以是村里唯一的希望，但是最终还是失败了。我觉得核心的失败在于行业内缺乏有抽象能力的思想领袖，具体的说，就是中国IT行业没有Martin Fowler，没有设计模式Gang of Four，说的严重些，甚至没有一个Kelsey Hightower。这是创新的瓶颈所在。
微信扫码关注该文公众号作者