從五個切入點看數據中台的必要性

connor

在上一篇《我的資料工程轉捩點,與數據中台》講完個人經驗之後,我想來拆解數據中台的本質,我在第一次看到這個名詞之後,嘗試搜尋了很多資料,但都只得到模糊的抽象,完全無法理解它葫蘆裡賣的是什麼藥。

直到最近又認真做了一次功課,加上數據中台也逐漸沒有那麼地神祕,才從中國的論壇找到我想要的「真實」業界分享,再根據我個人的經驗逐漸拼湊出它的樣貌。

實務上我認為絕大多數企業都不需要數據中台,但我認為拆解它相關的思路、導入它的精神,還是很有價值。以下雖然也只是個人片面的理解,但如果數據中台對你還是一個很模糊的概念,希望接下來的段落會對你有一些幫助。

數據中台:數據為本的套路化

首先,數據中台已經被高度套路化,換另一個角度來說就是教科書化,它是經由非常多前人的經驗累積起來的方法,只要我們善用這些方法,就可以避免犯下同樣的錯誤、在一開始有比較好的起點。

另外套路化的優點則是很好行銷與販售,任何道理只要給出一套 ABC,學的人馬上就會有成就感,可以用在任何它想用的地方、任何人都可以聲稱自己是實踐者。

但這不代表有效果,反過來說,如果在不清楚自己的狀況與面臨的問題之前,就照單全收、照本宣科,那麼就很可能會事倍功半,甚至適得其反。

數據中台的最大問題,是像阿里巴巴這樣的電商規模,超越了中國多數的電商,當然也遠超過台灣的電商,就算是同樣規模的企業,其組織結構、技術能力與文化也跟阿里巴巴完全不同,創造一個「數據中台」團隊所遇到的問題,很可能完全不一樣,無法泛用。

我試圖整理出五大面向,去從側面看一個組織需不需要考慮數據中台。


一、組織問題可能還沒有嚴重到需要數據中台

  • 數據中台要解決的一個問題就是數據開發跟不上業務需求,所以第一件事情就是業務需求夠強嗎?
  • 以分析來說,有嚴格的資料分析時效性需求,譬如客戶要求報表一定得在隔天甚至當天生出來嗎?
  • 以機器學習應用來說,有多變的建模需求,譬如每週甚至每幾天,就要產生完全不同應用的機器學習模型嗎?
  • 最後,以上這些業務場景,有辦法收斂到數據中台被滿足嗎?(還是每次都必須要重新客製化?)

上述問題只要有一個不確定,那很可能就不需要數據中台。


二、組織可能有問題,但不是數據中台可以解決的

我們知道,大數據平台(後台)的開發要求高可靠性、高擴展性,它們是重要的基礎,天生不可能隨著應用高速迭代。

但「只要數據開發跟不上業務需求,就會需要中台」的想法是錯的,因為中台只適用於很少數的情境。

殘酷的現實是,很多條件跟阿里巴巴不同的組織,在加上中台之後,產品開發很可能不會變快,原因之一是因為數據中台同樣需要很多人力開發、維護,增加了溝通成本。

並且,大數據平台(後台)離業務較遠,更新可以較慢;而數據中台不是,它是要一直跟著業務邏輯快速演進的,許多中小型公司的問題是原本 in-house 工程人力資源就不足,更不可能有人去開發、管理、維護數據中台,所以導入數據中台反而會把問題變得更糟。

如果一個組織連軟體工程師都很缺乏,那在考慮數據中台這麼奢侈的解決方案之前,首先應該考慮最基本的工程需求是否有被滿足。


三、組織準備好面對數據中台的極高成本了嗎?

建立數據中台,代表你要在原本的大數據平台之外,增加一群資料工程師去開發,而因為必須服務各種不同應用,天生不像大數據平台那麼地泛用,所需要的人力也就可能比大數據平台還多,溝通成本也會跟業務場景成比例增加

即使是買現成方案,這個問題也不會消失,而且很可能更貴、更耗時,還會引入更多難解的問題,比如要如何保護自己的資料不被第三方看到?要如何同時建設這麼大的中台,卻一併更新業務邏輯?(別忘了,中台就是要解決資料平台跟不上業務應用快速更新的問題)

再來是數據中台與資料治理(Data Governance)的抵換(trade-off):傳統數據後台(大數據平台)的設計是將資料交給基礎建設儲存,離應用(前台)的確比較遠,但某種程度也確保了資料治理的可控制性;而數據中台劃分了中間這一層的組織,也就意味著資料會複製、流到不同團隊管理的資料倉儲(Data Warehouse)系統中,甚至可能會創造出不只一個「中台」。

一旦發散出去各個中台,就會增加大量資料治理成本。如何管理上下游同步時間、保證不同資料流的一致性與正確性、確保隱私資料能夠被管理、刪除,這些都是非常大的問題。當然,這些都還沒提到錢。


四、小規模組織不需要、大規模組織也因為人的問題很難導入

幾百人的公司,可能不需要數據中台,只要一些 Data Lake 搭配 Data Warehouse 就足夠了,甚至全部都可以在 managed service 的雲端服務解決。

但即使組織夠大,也不代表就一定需要這樣做,因為數據中台與其說是技術架構,不如說他是組織架構,所以無可避免地會直接牽涉到組織調整,任何有經驗的管理階層都比我還懂這其中的困難。以阿里的狀況,他們在幾年內就做了十九次的組織調整,這是非常難以想像的成本與效率。

阿里中台之所以成功,倚靠的不僅是技術,更是敏捷的組織變革。 事實確實如此。2015 年末,在張勇提出「大中台、小前台」的組織戰略後,阿里巴巴在2016-2019 年內,進行過19 次組織調整,當中涉及諸多高管換崗、部門合併,均為拉通中台提供了基礎。

來源:《中台,我信了你的邪 | 深氪


五、數據中台不只是 API,更是負責 Data Service 的一整個團隊

康威定律告訴我們:設計系統的架構受制於產生這些設計的組織的溝通結構。

也就是說,會產生數據中台,是因為有這樣的組織架構,而有這樣的組織,是因為有需求。

很多數據中台的文章都把它具體成「一個 API 平台」,實務上介於中間的這個團隊才是核心的部分,而這個團隊負責的工作遠遠超過「提供 API」這件事情。

它的工作可以是建立 API、可以是建立 Library、當然也可以是管理一堆 Data Warehouse 提供 connector 讓程式對接。甚至作為溝通的橋樑,將業務需求轉化成資料基礎建設的設計與重構提案。


把數據中台概念從內部實踐,而不是從外部導入

我不會說數據中台毫無用處,而是將它當做一個傳記,讓我們學習阿里巴巴與類似的公司如何重整他們的組織、藉以適應大量業務需求的轉變。

各種數據中台的架構就像是有趣的教科書,畢竟沒多少人有機會經歷這樣的業務場景與組織需求,我們甚至可以透過閱讀這些架構,去窺探這些大企業的組織如何分工。

科技管理者可以從中反思自己的組織該如何改進。重用就會需要平台,只要是平台就會帶來對應的成本與風險。我們能做的就是在自己所及能力範圍之內,做出合理的判斷、一點一滴地改善組織體質去適應業務,不管最終那個東西叫做什麼。

阿里的中台終究是一個特化給阿里的組織管理方式,很難從外部導入、或是買外包的中台方案。就像器官移植一樣,若沒有謹慎評估,一定會產生排斥,造成一場災難。

相關文章:  「全棧科學家」模式不適用的可能原因