上“中台”,是送分,还是送命?( 四 )


笔者猜测,由于管理层过度的理想化,导致技术实施时困难重重,毕竟复用性并不是想做多大就可以做多大的,支撑的业务模式越多,抽象出来的通用复用性就越底层 。
这就达不到小前台的效果,前台还是需要一定规模的研发团队,事实证明,目前阿里的各个 BU 仍然各自都有着大量的研发团队 。
阿里中台战略败点分析
该部分没有什么参考文献,全部为个人的观点 。笔者做软件设计和研发已有 12 年,作为一名架构师和码农,个人最怕的就是自己因为害怕走出舒适区而陷入“极端陷阱” 。
这是一个笔者自己发现和定义的现象:很多时候,绝大多数人会认定一个死理,难以自拔 。
而究其本质是一旦大脑好不容易发现了某种理解可行时,不想再接受更多的反例,不愿意再去用第一性原则慢慢推导,个人认为这也是一种不想走出舒适区的表现 。
陷入极端陷阱后引发的问题是,当时你以一个高层领导的身份急着去拍了一个方案,实际上还有很多细节没想明白,这样大概率的结果就是项目烂尾 。
以下是按个人理解总结的阿里“全局大中台、小前台”战略的两个致命问题 。注:本节仅代表个人思考,不能作为事实依据 。
①中台应当分门别类,因地制宜,全局中台并不适合大集团
阿里集团业务繁杂度远高于超级细胞,中台范围应当细化,不适全局中台 。
治理小区和治理国家固然有一些类似的点和方法论,但是问题规模变大后,很多小规模下的方法也会变得不再适用,这是一个广泛被认可的观点 。
超级细胞的业务范围很专一,就是手游,所以它可以很容易就做成游戏工厂 。放到阿里这样的大集团,业务种类繁杂,性质大相径庭,何必强融?
像淘宝、一淘、天猫,这些其实换汤不换药,那么即便没有中台战略,架构师也知道很多业务逻辑可以复用,要说阿里架构师没有超级细胞的架构师懂?怎么可能 。
文献[5]中提到的第三阶段其实已经在考虑通过搭建业务平台来建设通用业务能力 。
而管理层想通过打造一个统一的万能中台来支撑所有集团业务前台,是未经深度思考的表现,从超级细胞小公司到阿里大集团,业务复杂度规模急剧增大,怎么能照搬模式呢 。
正如没有一个架构师可以在新问题上做出百分之一百与实际匹配的架构一样,也不会有一个统一的万能中台能在保证开闭原则的基础上适配所有业务 。
总结来说,阿里集团业务繁杂,不能把 BU 当做前台来构建大中台,每个 BU 就是一个独立的公司,有着自己独立的业务,根本“小”不了 。
而为各个 BU 做的那些通用的东西也是具有局限性的,只能帮助上层 BU 节省部分研发成本 。
过度贪求高度复用,会陷入“强求陷进”:把不该抽象的东西硬是抽象到了一起,结果就是系统的复杂度并没有降低,而是从多个地方搬到了一个地方 。
因此,管理层想要的“全集团大中台、小前台”,是一种理想主义,注定难以实现 。
②全局中台带来的新问题:依赖单点和热点
按上文的理解,中台战略的实际意义更大的是在于提醒所有 BU,要尽量的增强能力复用,为 BU 业务创新营造一个高效低成本的环境 。
而如果我们把一家大集团的所有主要业务系统都放到一个事业部去管理,就会产生一个新的问题:单点甚至是热点现象 。
每个 BU 甚至业务线都各自有 KPI,如果某个 BU 发现中台无法支撑自己的场景(因为总会有没考虑的情况),那么势必要求中台团队做支撑,需求一多,还得排队,这和 BU 寻求自身的生存和发展势必是矛盾的 。
所以,复用能力涉及的业务范围越大,单点问题就越是严重,单点变热点的概率也就越大 。
即便中台事业部做的再大,哪怕为每个 BU 都搞一个小团队去支持,由于所背的 KPI 和汇报关系并不在所支撑的 BU,实践起来总是会存在信息断层 。
合理的复用是不会产生热点的,因为正确的抽象聚焦是的领域内的业务,设计思路会无差别的对待所有用户,要么一个用户都没法用,要么所有用户都可以用(无故障的情况下) 。
就好比数据库一样,任何一款数据库都不会关注数据的业务属性,电商的数据能存,金融的数据必然也能存 。
引入数据库就是一种数据存取能力复用:数据库属于基础设施,复用性是必要的 。
阿里中台战略的成功之处
时至今日,中台的理念已经深入所有互联网人的心,阿里集团各个 BU 也在打着自己的中台算盘 。


推荐阅读