上“中台”，是送分，还是送命？( 七 ) _中台

举个例子，一个稍经通用设计的商品中心，从日用百货，到飞机大炮，再到房产基金都可以卖!
何必去搞一个万能电商工厂，根据所卖的货物不同而生成一套新的电商系统呢?
如果担心很多定制化个性化的逻辑无处表达，那就做好基础能力建设，然后一个小团队就可以基于这些通用能力去快速构建出新的电商系统了。
笔者有信心，这种方式比搞一个万能电商工厂来的更加现实和经济。
以下是笔者眼中的合理中台架构：

文章插图

不同的前台可以有自己的产品工厂，比如金融业务可以有自己的贷款产品工厂、电商业务可以有自己的商品中心等。
在写该部分的时候，由于内容很抽象，笔者在极力寻找生活中的例子来帮助读者理解笔者的意图。
关于这个部分，可以这样来比拟：

如果您某天特别想吃川菜，可以选择自己买菜来做。
如果你想能定时吃到按照自己口味做的菜又不想自己做，你可以开个该菜系的小饭馆，请个川菜厨师。
如果你还想吃湖南菜，那么你可以尝试招聘一个又会川菜又会湖南菜的厨师(类似业务线是存在抽象复用的可能性的) 。
如果你心血来潮，想着自己还喜欢看书，就想着开一个超级工厂，可以生产你想要的任何东西(食物、书和其他)，很可能您会落到一个舍本逐末、烂尾收场的境地。

因为本来成立这个工厂就是为了节省成本，而建设它的投入已经远大于分别去搭建按现有需求所需的小生产线了。
即便万幸你的超级工厂建成了，你也会发现它的内部很可能也是一条条小生产线组成的，写书和炒菜毕竟差的太远了。
这个例子告诉我们以下几点：

尽早识别出截然不同的业务线，不要企图去构建同时支撑他们的中台。
保守的做法是，优先为很容易就被识别的同类业务线去搭建复用中台。
不要激进的去框定一个万能中台的目标，落到实处，为前台老百姓们切切实实的解决一些实在的问题。
中台的设计讨论可以从上至下的去分析，但是实施路径一定要从底至上，先从最基础的通用能力开始，慢慢往上建设，不用强求高度复用性，因为很可能那是业务差异决定的。即便是有解的，高度复用性设计也是在从底至上的建设过程中逐渐形成的。

各大互联网中台实施现状
具体内容参考文献[8] 。笔者看完的感受是：广观各大互联网中台建设，都是打着中台的幌子在进行复用性设计战略实施，而且他们的战略实施都有个规律，都是从稳固底部做起，从下至上。
似乎只有大阿厂是锚定了一个理想化终态从上至下的大搞特搞的。
从腾讯中台定义来看就知道阿厂中台大而泛了，腾讯都是建设了具体的内容中台、用户中台等，而阿厂上来就是业务中台、数据中台和技术中台。
不过随着 2019 年组织结构调整，“大中台、小前台”战略已经无人提及了，提出中台的阿里正在像行业理解的中台前进!
这就好比老师跟学生说了某个知识，结果学生理解到了精髓，而老师却曲解了知识本意。
互联网业务参差不齐、细节差异大，很难像超级细胞那样搞个超级中台工厂，业务随便来配置一下就可以生成一个新的业务前台了。
不如从基础能力复用性做起，建设好通用基础业务领域能力，其他的个性化前台业务还是需要各自的研发团队负责。
从本质上看，全局中台没有意义，但能想的很清楚的领域能力一定要提供出来，比如用户、物流、支付、营销、数据管理等，能减轻多少上层的负担是多少，不必逞强。
另外，前台业务的研发团队是需要保留的，他们需要基于全局的通用基础能力去构建属于自己业务的“小”中台。
中台由中台能力组成，具体表现为一个个领域系统，叫不叫中台不重要，重要的是这个领域的服务能力是复用的。
总结
火极一时的阿里“大中台、小前台”战略折射出的是高层管理者在初尝复用技术的甜头后引发的一系列创造性思考，表明企业的管理者正开始思考自身研发体系的科学性和可持续性。
中台的提出是粗犷研发转向精益研发的重要里程碑，就像冷兵器时代早期打仗靠堆人，后面慢慢的演化出高效用兵的兵法。
很难想象如果没有中台思想的提出，还有多少公司要陷入研发滚雪球、竖烟囱的状态并且管理层还认为就应该是这样，业务催着要交付产品，研发毫无机会去思考复用性，大家都为着短期的利益做着极端的取舍：前台业务需求第一，不管合不合理，先怼上去，烟囱先竖起来。