業務中臺會吞併資料中臺嗎?
這個話題備受爭議,今天就來聊一聊。
OLAP系統和OLTP系統分別叫事務系統和分析系統,業務中臺一般屬於OLTP,資料中臺一般屬於OLAP,傳統業務中臺和資料中臺無論在組織上、系統上都是涇渭分明的,除了資料中臺需要從業務中臺採集資料,兩者甚至可以做到老死不相往來。
隨著數字化轉型的深入,很多企業的資料中臺和業務中臺的界限越來越模糊了,甚至開始發生職能衝突,下面是一個例子,大家可以感受一下:
上面這張圖體現出一個重要但隱蔽的問題,就是為前臺提供推薦服務的場景,到底用哪種方案,是用③ + ① 還是 ④?
方案一:由業務中臺團隊提供相關的能力,資料中臺輔助,即走③+①的通路,這一般是業務中臺團隊希望的架構。
方案二:直接由資料中臺團隊直接對接前臺團隊,提供相關的能力,即直接走④的通路,這一般是資料中臺團隊希望的架構。
那麼,哪種方案更合理呢?
第一種方案的優勢主要體現為四點:
1、從業務看,業務中臺方一般承載著公司的核心業務流程,其對於業務的理解更好。
2、從組織看,前臺應用與業務中臺方一般同屬一隻OLTP團隊,溝通成本相對較低。
3、從架構看,由於業務中臺和前臺應用所採用的技術棧類似,資料服務透過業務中臺可以無縫整合到前臺的業務流程中,體驗會更好。
4、從運維看,業務中臺提供資料服務的可用性,連續性會更好。
第二種方案的優勢主要體現為二點:
1、從認知看,資料中臺團隊擁有更多的資料驅動業務的思維,用資料賦能業務的驅動力更強。
2、從能力看,資料中臺更具備基於資料建模打造優質資料服務的能力。
從以上比較看,似乎第一種方案更好,即由業務中臺統一對接前臺應用。
從本質上講,無論是傳統的業務服務或者是新型的資料服務,都是為客戶提供的一種服務,它們應該透過統一的業務流程體現出其價值,不能因為技術實現上的差別就改變支撐的模式,比如業務服務就讓業務中臺團隊牽頭實現,資料服務就讓資料中臺團隊牽頭實現,長遠來講,這樣做的集約化效率肯定是偏低的。
當然選擇哪種方案還跟企業所處的行業和發展階段相關。比如很多企業業務中臺團隊對自己定位就是純粹的線上受理系統,精確營銷的實際主導者在資料中臺團隊,對於業務中臺來講,資料中臺提供的精確營銷服務就是一個外掛,或者只是提供了一個展示的視窗而已,這個時候如果強制使用方案一,那管理的代價可能會很大,因為認識很難短期改變。
在相當長的時間內,很多企業的資料中臺和業務中臺實際都採用了方案二來解決推薦服務的問題,但方案二存在先天的問題,即在規模越做越大的時候,短板會不斷暴露,包括:
1、距離業務較遠,與業務的協同難度偏高
2、資料服務過於依賴業務中臺提供的運營位,場景適配能力低
3、資料採集和效果評估依賴業務中臺,資料閉環運營挑戰大
4、資料服務的連續性和可用性保障水平偏低
近幾年情況也有了些變化,業務中臺團隊的數字化意識漸起,不再滿足於僅僅實現業務流程,更希望在業務流程中嵌入數智化服務來創造更大的價值,這個時候採用方案二的合理性就大幅增加了。
但業務中臺團隊短期內無法解決資料服務能力的問題,因此還是要透過組織最佳化的方式來解決,即剝離資料中臺團隊的部分職能,歸併進業務中臺團隊,那麼具體怎麼做呢?
1、資料中臺團隊的工作大致可以分為兩大類:決策支援類和業務響應類,決策支援類主要面向管理者,包括傳統的報表、取數、BI等等,業務響應類主要面向執行者,包括嵌入在業務流程中的推薦,預測服務等等,需要將業務響應類的工作劃轉到業務中臺團隊。
2、基於人隨事走的原則,資料中臺團隊原來負責業務響應類工作的人員劃轉到業務中臺團隊,確保其一開始就擁有基本的資料服務能力,OLTP和OLAP人員混編也是資料網格特別推崇的組織方式,因為兩者能力互補,有利於協同對外提供統一的服務能力。
3、基於資料湖建設兩個資料倉儲,前者為新業務中臺團隊服務,後者為原資料中臺團隊服務,這裡並不提倡模型複用,因為兩者面向的業務場景不同,決定了其模型複用度不會很高,而且採用的資料技術棧也各有側重,比如業務中臺團隊一般會強調倉庫的實時性,而原資料中臺團隊不一定。
組織架構最佳化後,新的業務中臺團隊實際上包含了業務和資料兩個團隊的人員,獨立的資料中臺團隊不再存在,或者說成為了業務中臺團隊的一部分,資料中臺團隊退化回資料倉儲時代的狀態,只為決策支援提供服務。
還有一種可能是資料中臺團隊升級為企業級的資料治理團隊,當然企業級治理團隊的使命跟業務無關,它主要的工作變成了建章立制,拉通資料,提供通用的資料湖或一站式工具鏈等等。
當初資料倉儲從業務系統拆出來的時候,其目的可是僅滿足決策支援的需要,當資料倉儲逐步壯大到能直接反哺傳統業務系統的時候,資料倉儲其實早已不是當初那個資料倉儲了,這個時候也許就到了重新思考其定位的時候了,所謂合久必分,分久必合。
當然對於很多企業來講,由於連資料倉儲還沒做好,那就完全不用考慮,而對某些企業來講,或許已經是這種架構了。
來自 “ 大魚的資料人生 ”, 原文作者:討厭的大魚先生;原文連結:https://mp.weixin.qq.com/s/i8EAXx8ksLTH8I6kQPoPrw,如有侵權,請聯絡管理員刪除。
相關文章
- 【資料中臺商業化】資料中臺微前端實踐前端
- 資料中臺即服務——資料中臺的四大支柱
- 從資料中臺到AI中臺,企業到底要建什麼中臺?AI
- 地產業 X 資料中臺產業
- 資料中臺
- 企業數字化轉型必須要有資料中臺嗎?
- 資料中臺中的核心概念解析
- 資料中臺:宜信敏捷資料中臺建設實踐敏捷
- 資料中臺是什麼意思?如何建設資料中臺?
- 小米資料中臺建設實踐賦能業務增長
- 資料中臺和平臺區別在哪
- 2019,資料中臺元年
- 資料中臺(安全篇)
- 企業資料中臺實施過程中失敗的因素
- 10張架構圖詳解資料中臺,附全套資料中臺PPT架構
- 資料中臺(資料整合篇)
- 資料中臺(方法論篇)
- 資料中臺(介紹篇)
- 資料中臺(架構篇)架構
- 中臺涼了,企業慌嗎?
- 走好資料中臺最後一公里,為什麼說資料服務 API 是資料中臺的標配?API
- 企業級大資料中臺架構實戰大資料架構
- 資料中臺不是企業的萬能妙藥
- 資料平臺、大資料平臺、資料中臺……還分的清不?大資料
- 資料中臺:資料服務的架構設計實踐架構
- 怎麼建設全渠道會員資料中臺系統?
- 為什麼要用資料中臺
- 資料中臺從何而來
- 到底什麼是資料中臺?
- 資料中臺(資料資產管理篇)
- 企業在資料中臺上該怎麼選擇
- 遊戲行業應該如何建設資料中臺?遊戲行業
- 企業級大資料中臺架構實戰【3】大資料架構
- 企業級大資料中臺架構實戰【1】大資料架構
- 宜信資料中臺全揭祕(一)資料中臺整體介紹|分享實錄
- Spring Cloud Alibaba 分散式微服務高併發資料平臺化(中臺)思想+多租戶saas企業架構SpringCloud分散式微服務架構
- 現在資料中臺還是發展趨勢嗎?_光點科技
- 為什麼說資料服務是資料中臺的標配?