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

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

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

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

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

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

另外套路化的優點則是很好行銷與販售，任何道理只要給出一套 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 讓程式對接。甚至作為溝通的橋樑，將業務需求轉化成資料基礎建設的設計與重構提案。

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

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

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

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

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

原文連結東京疊塔