中台真的不香了 补台 阿里

图片来自 Pexels

自从 2 阿里巴巴提出中台概念和策略，“中台”这个技术术语逐渐炽热起来。

尤其是从 2019年开局，各类技术大会、各类群众号都在鼎力宣扬中台，出版社也趁着热点连忙出版各类中台书籍，一期间中台有“旧时王谢堂前燕，飞入寻常百姓家”的觉得。

假设你跟人聊技术的时刻，不宣布一些中台的舆论，不探讨一些中台的疑问，那必需会显得你技术有点落伍了!

假设咱们细心浏览这些文章，或许会发现一个幽默的现象，绝大局部谈中台的都是做中台的，很少看到用中台的人进去评价。

从兽性的角度来讲，做中台的必需不会说中台不好，毕竟还要靠这个恰饭，王婆卖瓜不自诩的话，买瓜的人自然会少。

偶然有几篇说中台有疑问的文章，例如《中台翻车纪实：一年叫停，员工转岗被裁，资源全糜费》、《中台，我信了你的邪 | 深氪》。

也很快会有人跳进去说“你们才干不行，所以中台没做好”、“中台是一个业务、组织、技术的协同，你们必需是组织没保障”……

总而言之，如今四处都能看到做中台的人说中台如何如何好，偶然有几个跳进去说不好的都会被质疑才干不行!

依照我的技术理念来看，没有完美的技术，没有放之四海皆好的技术，假设你只能看到一项技术的好处，而看不到坑，那实践上很或许就会掉到坑里去。

我尽管没有真正担任做过中台，但我做过平台和两边件，更为特意的是，我介入了两个基于中台的业务名目，一个名目是将手游买卖系统迁徙到电商中台，另一个名目是在支付中台上从0 到 1 搭建一个钱包。

这两个名目让我亲身通常了一下在阿里和蚂蚁的中台上做名目，让我无时机近距离观察中台的运作机制，在一次性次与中台的探讨、PK、撕逼的环节中，对中台也有了更深的了解和意识。

从我团体的阅历和了解来看，目前关于中台的很多说法是言过其实、模棱两可、甚至是失误的，接上去我将给大家谈谈实践上的中台究竟是怎样运作的，会有哪些坑。

由于我真正就是用的阿里电商中台和蚂蚁的支付中台，因此不用质疑中台才干不行和组织才干不行才会有我说的那些疑问。

01.中台的价值真的有那么玄乎么?

关于中台的价值，你看到的是这样的：

可以让各业务部门坚持相对的独立和分权，保障对业务的敏理性和翻新性;另一方面，用一个弱小的平台来对这些部门启动总协和谐允许，平衡集权与分权，并为新业务新部门提供成长的空间，从而大幅降落组织改革的老本。中台部门提炼各业务线的特性需求，最大限制地缩小“重复造轮子”。

实践上的中台是这样的：

①业务部门并不独立

基于中台的业务会被分为不同优先级，大业务关于中台的影响力远远大于小业务，外围业务对中台的影响力远远大于新业务。

笼统点来说，中台抱大业务的大腿，小业务抱中台的大腿，由于中台也是有 KPI 的，中台的 KPI 怎样来?

这会造成什么疑问呢?大业务的翻新不论是不是特性的，中台会鼎力允许，毕竟判别是不是特性需求是中台判别的，而不是每次有个新业务的时刻拉上一切业务方来评价和投票。

小业务就比拟悲催了，中台要拒绝你，只需繁难一句话“你这个业务不通用”，“你这个需求太不凡”。

假设小业务不信服能怎样办?没什么方法，不会存在仲裁委员会之类的机构，就算有，你去仲裁的期间都够你自己把业务虚现 5 遍了!

就算中台以为你的需求是特性需求，假设你是小业务，很或许也会以优先级的要素被排在很前面，这里的“很前面”可不是几天几周，很或许就是几个月半年了!

而恰好很多初守业务一开局规模必需是比拟小的，基于中台的开发形式很或许会制约翻新业务的极速开展，除非这个翻新业务一开局就有重量级人物挂帅，对中台能够有足够的影响力。

②中台并不总是能够提炼特性需求

留意这里的需求不是指电商中台外面“买卖”这个粒度的需求，而是指“买卖”系统外面一个个实践的性能点，你要是坚持说“买卖”是特性需求，这实践上是一句正确的废话。

理想上，提炼特性需求关键是中台从 0 到 1 的树立的时刻，由于这个时刻曾经有多个业务需求的样本存在，哪些是特性哪些是特性是比拟容易剖析进去的。

但一旦建成后后续的业务开展和翻新，中台和业务方自然存在对特性需求的不同诉求。

业务方总是希冀将自己的需求划为特性需求，由于这样就能够让中台出人来成功需求。

中台总是希冀先不要把需求划为特性需求，而是等到多个业务都有相似需求的时刻再由中台来笼统提炼，这样才干最大化复用，否则中台每个需求都以为是特性需求的话，中台会累死。

而理想上简直不太或许产生多个业务同时提出某个需求，除了国度公布的法律法规关系的需求外，绝大局部业务需求都是由某个业务方先提进去的。

这个时刻中台是无法判别能否为特性需求的，只能又回到前面说的潜规定来操作：优先满足大业务，怠慢小业务。

反正大业务的需求不论是不是特性的，做了后数据必需难看，中台 KPI有保障;小业务就算被证实是特性的，前期做了也没多少数据，中台很或许费劲不讨好。

③中台的“轮子”会始终变动

很多好友看到“防止重复造轮子”就以为中台把轮子造好了，业务方尽管用就可以了，而实践状况是中台确实把轮子造好了。

但是它每隔一段期间就会把轮子换一遍，例如中台的数据模型、接口、架构等其实都是须要依据业务开展始终变动的。

为了到达中台“复用”的指标，通常状况下中台在推出新轮子后，就不会再常年保养老轮子，否则假设中台同时保养 4~5 个相似的轮子，复用就无从谈起。

这就要求基于中台的业务都必需在某个期间段内成功轮子的切换，相当于是业务方启动了一次性主动架构演进。

当然，假设没有中台，业务方的架构必需也要随着业务的开展而演进，那这和追随中台主动演进有什么区别呢?

最关键的区别是中台的架构演进频率会比独立的业务架构演进要快，情理很繁难：中台融合了多个相似业务的开展!

举个繁难例子：假设中台允许 10 个业务，其中有 1 个业务开展很快，中台就必需跟着演进，残余的 9个业务即使没有任何开展，也必需跟着主动演进!更何况假设这 10 个业务自身都在始终开展，那中台的演进会更快!

④中台是某类业务的中台，不是一切业务的中台

中台的实质是提炼特性需求复用，假设业务差异太大的话，复用度不高，提炼和保养中台破费的代价抵不上中台复用带来的价值。

所以，实践上应该叫“电商中台”、“支付中台”、“物流中台”、“出行中台”、“视频中台”、“保险中台”，而不应该是“阿里中台”、“腾讯中台”、“百度中台”、“滴滴中台”。

当然，由于如今“中台”概念火爆，产生了原来很多做两边件和技术平台的团队，纷繁将自己担任的“XX平台”改为“技术中台”。

从狭义的角度来说也可以，由于这确实是“各业务线特性需求”，毕竟存储、缓存、信息队列这些必需是各业务线的特性需求，但通常状况下咱们说中台时所指的“需求”，还是指“业务需求”，即客户可以经常使用到的性能。

所以，即使只是看到“茅台云商”这种中台名目的 PPT，也能大略率是可以推断这个名目失败的或许性会十分高：

02.中台真的能够以搭积木的方式来极速翻新业务么?

关于中台的成果，你看到的是这样的：

由于阿里巴巴的生态十分复杂，很多业务方自身也很年轻，要怎样去做，高层究竟能提供什么样的撑持是不分明的。

当有大中台思绪之后，第一，咱们这集体系里有什么样的才干，可以让各业务很分明的知道，也可以让前台业务方更快的了解、选用和经常使用中台才干。

第二、咱们提供了基础处置打算，业务方依据须要做定制开发满足自己的业务特性，对前台的业务来说会更快。

摘自《中台的疑问，是技术的疑问，还是人的疑问》

实践的中台是这样的：

①中台的体系有什么样的性能，业务方基本不是很分明的知道，而是基本不知道

理想上中台自己也没有人完整的知道中台外面各个域各个子系统的才干，愈加谈不上业务方更快的了解、选用和经常使用了。

你可以随意关上一张某个技术大会上分享的中台架构，满满的一页甚至几页PPT，大框小框几十上百个，对应到详细的线上运转的系统或许几百上千个，这么复杂的一个系统，怎样或许有人知道一切的性能和细节?更何况是业务方了。

至于说中台提供完整的处置打算，业务方只需定制一下就可以极速上线，说起来容易做起来难，除非业务方是预备复制一个和已有业务基本一样的业务，否则基本上是无法能成功的。

要素在于中台提供的处置打算，肯定是基于已有的业务来笼统进去的“特性需求”的大汇合，假设这个处置打算可定制化度很高，那么就说明可复用度比拟低;假设这个处置打算的可定制化度很低，尽管可复用度高但业务可裁减度比拟低。

而从中台的实质登程，中台肯定会选取“可定制度低可复用度高”的方向，这就解放了只要复制一个十分相似的新业务的时刻中台的处置打算才有很大价值，但是关于同一个公司来说，为何要复制两个基本一样的业务呢?

假设真的有中台选用了“可定制度高”的处置打算，当新业务和已有业务有较大差异的时刻，中台的处置打算并没有什么很大价值，由于少量的上班量会消耗在定制那局部。

实践上我接触的中台是这样运作的：中台会分为很多“域”，例如“买卖”、“搜查”、“会员”等，而后业务方将自己的业务需求写进去，而后拉上各个域的产品接口人和技术接口人，一个域一个域的探讨。

以“会员域”为例，探讨的时刻，会员域的产品接口人技术接口人必需很相熟会员的性能、模型和接口。

业务方须要跟中台子域接口人解说业务需求，而后中台子域接口人来评价会员的才干哪些是允许的，哪些是不允许的。

不允许的局部是属于特性需求还是属于特性需求，假设是特性需求，须要给出中台的修正的打算，而且修正打算还要会员域的架构师启动评审，由于改中台是影响一切业务的。

假设是特性需求，须要设计出中台和业务方交互的方式，例如是提供接口、性能、裁减包等。

所以假设你真正基于中台做过名目你就会发现，编码的期间确实少了，但是前期的沟通和前期的联调十分耗期间，随意做个什么名目，拉上 20~30人算普通的，稍微大点的名目拉上 50~100 人也是很反常的。

以淘宝的中台为例，如下是淘宝电商中台共享事业部外面买卖中心的结构：

留意：买卖中心只是共享事业部的一个业务域，同级别的业务域从地下资料来看有 10 来个，而买卖中心外部就有 13 个子性能了，这些子性能最后都或许对应 1个或许多个实践运转的系统。

②中台的所谓的“快”，并没有谨严的权衡

目前各类文章都会说有了中台后业务开发快，但并没有详细的案例和剖析究竟有多快，仅有的几个案例看起来很夸张，但没有详细背景形容其实并没有压服力。

例如说某个业务新上线很快，究竟是由于第一版性能很繁难，还是第一个版本投入了少量的人力来做，还是真的是由于用了中台?

理想上我阅历过的两个接入中台名目并不能看进去快，从实践的开发阅从来看，业务方和中台的需求解说和探讨，业务方和中台打算的设计探讨，前期的业务系统和中台系统联调这些上班量并没有缩小，反而还会有肯定水平的参与。

由于中台在剖析需求、设计打算、联调测试的时刻须要思考对其它业务的影响。

中台能够带来的效率优化关键体如今两方面：

理想上我之前在阿里游戏做过几个从 0 到 1的名目，由于老板注重，都是将原来相似的系统已有的外围开发人员拉过去开发新名目，最后的代码也是从原系统拷贝过去改，开发效率一样很高，外围要素繁难来说就是“熟手开发”。

以上是我从基于中台的开发名目中观察到的一些疑问，演绎总结进去的一些阅历。

总体来看如同我在质疑中台，其实不然。关于中台的好处曾经有太多的文章了，本文试图提供从经常使用者的视角来看中台所看到的一些信息和疑问，目的在于协助大家愈加片面的了解中台。

我在《从零开局学架构》一书中提炼出的架构设计三准则中第一条就是“适合准则”，这个准则对中台也是顺应的。

03.总结

总结来说就是：中台不是灵丹妙药，不要有疑问就想着用中台处置;中台也不是放之四海而皆准，明白中台的顺应场景和或许的坑，才干更好的落地中台!

其实提出中台的逍遥子曾经早就循循善诱了：

中台并不实用于每家公司的每个阶段。在独立业务拓展期、打破期，“肯定用独立团、独立师、独立旅建制来做”，否则就会变成瓶颈;但开展到肯定阶段，产生太多山头时，就要“关停并转、要兼并同类项。问治理要效率，敞开重复性树立。

作者：李运华

编辑：陶家龙