业务中台会吞并数据中台吗?

2022-10-11 07:30 浏览量:194

这个话题备受争议,今天就来聊一聊。

OLAP系统和OLTP系统分别叫事务系统和分析系统,业务中台一般属于OLTP,数据中台一般属于OLAP,传统业务中台和数据中台无论在组织上、系统上都是泾渭分明的,除了数据中台需要从业务中台采集数据,两者甚至可以做到老死不相往来。

 

随着数字化转型的深入,很多企业的数据中台和业务中台的界限越来越模糊了,甚至开始发生职能冲突,下面是一个例子,大家可以感受一下:

 
 

上面这张图体现出一个重要但隐蔽的问题,就是为前台提供推荐服务的场景,到底用哪种方案,是用③ + ① 还是 ④?

 

方案一:由业务中台团队提供相关的能力,数据中台辅助,即走③+①的通路,这一般是业务中台团队希望的架构。

 

方案二:直接由数据中台团队直接对接前台团队,提供相关的能力,即直接走④的通路,这一般是数据中台团队希望的架构。

 

那么,哪种方案更合理呢?

 

第一种方案的优势主要体现为四点:

 

1、从业务看,业务中台方一般承载着公司的核心业务流程,其对于业务的理解更好。

 

2、从组织看,前台应用与业务中台方一般同属一只OLTP团队,沟通成本相对较低。

 

3、从架构看,由于业务中台和前台应用所采用的技术栈类似,数据服务通过业务中台可以无缝集成到前台的业务流程中,体验会更好。

 

4、从运维看,业务中台提供数据服务的可用性,连续性会更好。

 

第二种方案的优势主要体现为二点:

 

1、从认知看,数据中台团队拥有更多的数据驱动业务的思维,用数据赋能业务的驱动力更强。

 

2、从能力看,数据中台更具备基于数据建模打造优质数据服务的能力。

 

从以上比较看,似乎第一种方案更好,即由业务中台统一对接前台应用。


 

从本质上讲,无论是传统的业务服务或者是新型的数据服务,都是为客户提供的一种服务,它们应该通过统一的业务流程体现出其价值,不能因为技术实现上的差别就改变支撑的模式,比如业务服务就让业务中台团队牵头实现,数据服务就让数据中台团队牵头实现,长远来讲,这样做的集约化效率肯定是偏低的。

 

当然选择哪种方案还跟企业所处的行业和发展阶段相关。比如很多企业业务中台团队对自己定位就是纯粹的在线受理系统,精确营销的实际主导者在数据中台团队,对于业务中台来讲,数据中台提供的精确营销服务就是一个外挂,或者只是提供了一个展示的窗口而已,这个时候如果强制使用方案一,那管理的代价可能会很大,因为认识很难短期改变。

 

在相当长的时间内,很多企业的数据中台和业务中台实际都采用了方案二来解决推荐服务的问题,但方案二存在先天的问题,即在规模越做越大的时候,短板会不断暴露,包括:

 

1、距离业务较远,与业务的协同难度偏高

 

2、数据服务过于依赖业务中台提供的运营位,场景适配能力低

 

3、数据采集和效果评估依赖业务中台,数据闭环运营挑战大

 

4、数据服务的连续性和可用性保障水平偏低

 

近几年情况也有了些变化,业务中台团队的数字化意识渐起,不再满足于仅仅实现业务流程,更希望在业务流程中嵌入数智化服务来创造更大的价值,这个时候采用方案二的合理性就大幅增加了。


 

但业务中台团队短期内无法解决数据服务能力的问题,因此还是要通过组织优化的方式来解决,即剥离数据中台团队的部分职能,归并进业务中台团队,那么具体怎么做呢?

 

1、数据中台团队的工作大致可以分为两大类:决策支持类和业务响应类,决策支持类主要面向管理者,包括传统的报表、取数、BI等等,业务响应类主要面向执行者,包括嵌入在业务流程中的推荐,预测服务等等,需要将业务响应类的工作划转到业务中台团队。

 

2、基于人随事走的原则,数据中台团队原来负责业务响应类工作的人员划转到业务中台团队,确保其一开始就拥有基本的数据服务能力,OLTP和OLAP人员混编也是数据网格特别推崇的组织方式,因为两者能力互补,有利于协同对外提供统一的服务能力。

 

3、基于数据湖建设两个数据仓库,前者为新业务中台团队服务,后者为原数据中台团队服务,这里并不提倡模型复用,因为两者面向的业务场景不同,决定了其模型复用度不会很高,而且采用的数据技术栈也各有侧重,比如业务中台团队一般会强调仓库的实时性,而原数据中台团队不一定。

 

组织架构优化后,新的业务中台团队实际上包含了业务和数据两个团队的人员,独立的数据中台团队不再存在,或者说成为了业务中台团队的一部分,数据中台团队退化回数据仓库时代的状态,只为决策支持提供服务。

 

还有一种可能是数据中台团队升级为企业级的数据治理团队,当然企业级治理团队的使命跟业务无关,它主要的工作变成了建章立制,拉通数据,提供通用的数据湖或一站式工具链等等。

 

当初数据仓库从业务系统拆出来的时候,其目的可是仅满足决策支持的需要,当数据仓库逐步壮大到能直接反哺传统业务系统的时候,数据仓库其实早已不是当初那个数据仓库了,这个时候也许就到了重新思考其定位的时候了,所谓合久必分,分久必合。


 

当然对于很多企业来讲,由于连数据仓库还没做好,那就完全不用考虑,而对某些企业来讲,或许已经是这种架构了。

 

作者:傅一平

来源:与数据同行

上一篇:数据治理:数据血缘关系

下一篇:数据资产如何进行有效分类?

  • 分享:
龙石数据
咨询电话: 0512-87811036,18013092598
联系我们
商务联系微信

商务联系微信

0512-87811036,

18013092598

咨询电话