中台文章千千万,讲清楚的没几篇。
中台概念诞生几年了,相关文章不计其数,但是真的读下来,读者大概率会产生至少两个疑问:
(1)概念是讲了一堆,架构图是很酷炫,但是中台到底长什么样的?具体咋工作的?
(2)有道理的好话说了一堆,怎么没怎么听见有分量的坏话?落地这么久了,具体遇到了什么问题?为什么会遇到这些问题?这病能治么?怎么治?
本文分两篇,沿用人话+案例的老猿风格,把上述疑问讲清楚。
1、中台的第一性
首先介绍下,为何本小节叫中台的第一性。
所谓第一性原理,从马斯克提出来到现在,也被用滥了。第一性原理的概念,可以理解为回到问题得本质去分析问题(相比之下,比较分析就不符合第一性原理,但是不妨碍其适用性)。但是,老猿在这里不在概念上做过多纠缠,因为,用概念去理解事物的做法,本身就很不符合第一性原理。那用什么方法去理解事物,才是符合第一性原理的呢?老猿认为就是讲清楚是什么。
因为,任何智商正常的人类,在真的搞清楚是什么后,自然而然,不需要别人讲,就可以很好地想到性质、特点、可能存在的问题等扩展问题。
所以,这里所谓的中台第一性,就是讲清楚,中台是什么、长什么样的、怎么工作的,那么在下篇,讨论中台存在什么问题以及可能的改进方法,也就非常好理解了。
2、业务中台
先简单介绍下中台的概念:中台是集成某类业务场景下,可复用功能模块的集成平台。目前中台分为业务中台、数据中台、IT中台、算法中台,前两者是主流,后两者有很多是旧概念直接换了个名字,啥都没变。当然,概念,不重要,关键是知道中台具体是什么,怎么工作的,话不多说,上例子。
典型的电商业务场景下的业务中台架构如下:
怎么理解上述架构?
以阿里为例,阿里的产品经过了1688-淘宝-天猫-聚划算的变迁,但无论哪一款,都是在电商场景的产品,并且无论哪一款产品,都要做以下6个功能:支付、商品数据管理、营销、搜索、用户数据管理、交易信息管理。因此,你是老板你也自然会想这样一个问题:既然在电商场景下,每款产品都要做上述六个功能,那能否把上面六项功能做成六个系统,然后对所有电商产品开放接口,让任意电商产品可以直接取用这六项功能?这样的话,新的产品(例如飞猪、闲鱼)就可以快速实现上述六项功能,把节省下来的时间、资源用在产品的特色功能上,这就是做中台的理想目标。
但是,理想很丰满,现实很骨感,实现上述目标在实际应用中不是一件容易的事,为什么?
因为中台涉及的功能十分庞大,并且功能的边界判断也存在难点。
前言
中台文章千千万,讲清楚的没几篇。
中台概念诞生几年了,相关文章不计其数,但是真的读下来,读者大概率会产生至少两个疑问:
(1)概念是讲了一堆,架构图是很酷炫,但是中台到底长什么样的?具体咋工作的?
(2)有道理的好话说了一堆,怎么没怎么听见有分量的坏话?落地这么久了,具体遇到了什么问题?为什么会遇到这些问题?这病能治么?怎么治?
本文分两篇,沿用人话+案例的老猿风格,把上述疑问讲清楚。
1、中台的第一性
首先介绍下,为何本小节叫中台的第一性。
所谓第一性原理,从马斯克提出来到现在,也被用滥了。第一性原理的概念,可以理解为回到问题得本质去分析问题(相比之下,比较分析就不符合第一性原理,但是不妨碍其适用性)。但是,老猿在这里不在概念上做过多纠缠,因为,用概念去理解事物的做法,本身就很不符合第一性原理。那用什么方法去理解事物,才是符合第一性原理的呢?老猿认为就是讲清楚是什么。
因为,任何智商正常的人类,在真的搞清楚是什么后,自然而然,不需要别人讲,就可以很好地想到性质、特点、可能存在的问题等扩展问题。
所以,这里所谓的中台第一性,就是讲清楚,中台是什么、长什么样的、怎么工作的,那么在下篇,讨论中台存在什么问题以及可能的改进方法,也就非常好理解了。
2、业务中台
先简单介绍下中台的概念:中台是集成某类业务场景下,可复用功能模块的集成平台。目前中台分为业务中台、数据中台、IT中台、算法中台,前两者是主流,后两者有很多是旧概念直接换了个名字,啥都没变。当然,概念,不重要,关键是知道中台具体是什么,怎么工作的,话不多说,上例子。
典型的电商业务场景下的业务中台架构如下:
怎么理解上述架构?
以阿里为例,阿里的产品经过了1688-淘宝-天猫-聚划算的变迁,但无论哪一款,都是在电商场景的产品,并且无论哪一款产品,都要做以下6个功能:支付、商品数据管理、营销、搜索、用户数据管理、交易信息管理。因此,你是老板你也自然会想这样一个问题:既然在电商场景下,每款产品都要做上述六个功能,那能否把上面六项功能做成六个系统,然后对所有电商产品开放接口,让任意电商产品可以直接取用这六项功能?这样的话,新的产品(例如飞猪、闲鱼)就可以快速实现上述六项功能,把节省下来的时间、资源用在产品的特色功能上,这就是做中台的理想目标。
但是,理想很丰满,现实很骨感,实现上述目标在实际应用中不是一件容易的事,为什么?
因为中台涉及的功能十分庞大,并且功能的边界判断也存在难点。
图中6大中心,每一个其实都包含着20几个(甚至大几十个)的子系统。例如交易中心,至少由订单创建、订单删除、订单拆分等20多个子系统构成。下图对交易中心部分子系统进行了列举。
先简单介绍下中台的概念:中台是集成某类业务场景下,可复用功能模块的集成平台。目前中台分为业务中台、数据中台、IT中台、算法中台,前两者是主流,后两者有很多是旧概念直接换了个名字,啥都没变。当然,概念,不重要,关键是知道中台具体是什么,怎么工作的,话不多说,上例子。
典型的电商业务场景下的业务中台架构如下:
怎么理解上述架构?
以阿里为例,阿里的产品经过了1688-淘宝-天猫-聚划算的变迁,但无论哪一款,都是在电商场景的产品,并且无论哪一款产品,都要做以下6个功能:支付、商品数据管理、营销、搜索、用户数据管理、交易信息管理。因此,你是老板你也自然会想这样一个问题:既然在电商场景下,每款产品都要做上述六个功能,那能否把上面六项功能做成六个系统,然后对所有电商产品开放接口,让任意电商产品可以直接取用这六项功能?这样的话,新的产品(例如飞猪、闲鱼)就可以快速实现上述六项功能,把节省下来的时间、资源用在产品的特色功能上,这就是做中台的理想目标。
但是,理想很丰满,现实很骨感,实现上述目标在实际应用中不是一件容易的事,为什么?
因为中台涉及的功能十分庞大,并且功能的边界判断也存在难点。
图中6大中心,每一个其实都包含着20几个(甚至大几十个)的子系统。例如交易中心,至少由订单创建、订单删除、订单拆分等20多个子系统构成。下图对交易中心部分子系统进行了列举。
在实际中,这样一个交易中心如何搭建起来?
首先,为了搭建创建订单模块,需要梳理1688,淘宝,天猫等不同产品创建订单的异同,还要对未来产品的创建订单流程进行预估,提炼不同产品创建订单的共性需求和特性需求,然后评估团队资源和中台能力边界,最后制定解决方案。在业务开展中,一个交易中心可能由一个P8甚至更高负责,一个子系统(如创建订单)由一个P7负责,具有不小的业务量。
在实际中,这样一个交易中心具体长啥样?
由于交易中心离我们个人用户太远,我们无法看到这个交易中心具体长什么样的,但是老猿分享两个消息中心(即时通讯中心)的案例,大家可以举一反三。
消息中心案例1:
消息中心案例2:
https://cloud.tencent.com/document/product/269
在实际中,这样一个交易中心如何发挥作用?
假如我开始做闲鱼APP,我发现闲鱼在交易方面,需要具备:创建-删除-关闭-查询订单,付款-自动发货-确认收货,这几个功能,那么闲鱼团队去电商业务中台系统-交易中心,找到创建-删除-关闭-查询订单,付款-自动发货-确认收货的接口,通过接口获取这些子系统的程序,然后结合闲鱼的特性,对这些程序做些小的改动,就完成了闲鱼这些功能,很省事对吧?
3、其他中台类型
所以数据中台长什么样?看数据中台做了哪些事情,例如上图的数据中台具体形态,其实就是数据建模系统、日志分析系统、用户画像系统三个系统,拼成了数据中台。
实际中数据中台怎么工作的?以上图的用户画像为例,我们在中台同时拿到以下三条信息:
1、一个上海女性用户A经常在淘宝高定服装;
2、还是用户A在闲鱼经常卖贵妇化妆品;
3、还是用户A在飞猪经常定机票定5星宾馆。
我们的中台可以给这个用户A 生成丰富特征标签。这有什么好处呢?-事半功倍。
如果没有数据中台,淘宝、闲鱼、飞猪三个APP的数据独立,不互通,我们需要对A形成三套标签,且不说同样的事情让三个团队各干一遍,浪费时间资源,关键是这三个团队的用户画像,都不可能比数据中台构建的画像完整,事倍功半。
此外,中台还有技术中台和算法中台,典型例子见下图。但是技术和算法中台,更多是新瓶子装旧酒,例如MQ、容器、语音识别等本来就是存在的,没有中台概念的时候,他们就有了,并且也是具备可复用性的,所以实际中,很多公司其实是,把这些功能打包在一起,套一个中台的概念,在此不必多讲。
全部评论
(1) 回帖