起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識中臺實戰（2）：數據中臺化實戰
今天就接著上次聊到的中臺實戰提到的項目管理系統和采購管理系統的案例繼續講，看看數據中臺方案是怎么實踐的。
先回歸一下上次案例的主要問題：
在A公司里項目管理系統和采購管理系統是屬于獨立兩個業務線團隊，在后臺是有著兩套獨立的業務數據體系，這些數據由各業務線團隊進行自主定義和維護的。
但在一體化平臺建設中，單獨對兩個系統的業務數據的維護成本是非常高的，而且把兩個原本是有數據關聯的系統阻隔開后，那么系統對數據之間的關聯應用效率就非常地低。所以我們要針對這些問題進行中臺方案的構建。
步驟一：強干弱枝
在A公司的一體化平臺中，包含了項目管理子系統、采購管理子系統、資產管理子系統等7個業務子系統，涵蓋的數據量是非常的大。
那么，對于龐大的數據量時，我們首先要做的是把數據剝離各業務線團隊，進行抽象提取，保留“主干”。將數據存儲至獨立的數據中心（即中臺1.0）進行維護，打破各業務線團隊之間的阻隔墻，此時原有的數據環節變為：
項目數據與其他各業務線生產的數據都匯總到數據中心，在數據中心對各業務線數據進行統一維護后，面對各業務線團隊的數據需求，我們可以在數據中心劃分各虛擬數據源以支撐各業務線團隊使用。
數據中心是為整個A公司的產品基礎服務提供全局的數據。
步驟二：特異性管理
在數據應用中，我們會經常遇到對不同業務線中有關聯的數據進行調用的情況，例如：在采購管理系統中新增了一個采購項目，那么項目管理系統此時就需要對該采購項目進行數據新增。
所以，對其他業務線數據進行調用時，需經過這些步驟：
這時我們可以看到從其他業務線數據源調用數據時主要做了兩個步驟的工作：
- 數據提取：根據業務方（項目管理系統）所要的數據范圍提供數據（如，本次業務需要讀取項目ID、項目名稱這兩個字段）；
- 數據業務格式化：根據業務方（項目管理系統）所要的數據格式進行特定數據格式/順序生成（如，業務方A（采購管理系統）返回數據格式：項目ID=“12345”+項目名稱=“項目1”；業務方B（項目管理系統）返回數據格式：項目名稱->“項目1” and 項目ID->“12345”）。
看完以上兩個步驟的工作，有沒有感受到實際上這就是原本整個后臺支撐系統巨大的工作量的重要原因。像上文提到的每次接口只能為一個業務方提供服務，而且這個接口由于數據返回格式是特定的所以具有很強的特異性，這樣就導致后端開發需要不斷地進行新的提供數據的接口開發工作。
這無疑是對企業資源的巨大浪費。這種情況在我們的日常工作中應該是非常常見的（此處有沒有共鳴），例如：產品迭代升級中每次版本更新導致需要重新設計接口（新舊版本就同一個數據的不同封裝形式的取用）；老版本數據接口與新版本的同一數據接口不同，需要重新設計編寫，且需要分別維護。
對于這個問題，我是這樣解決的：這兩個步驟中第一個服務共性很高，很容易提取成一個公共服務。所以，我們就在數據中心提供一個標準的數據提取接口，各個業務方只需要傳輸需要什么字段，我們的統一數據返回接口就把數據返回至各業務方。
這樣，在所有的版本中，我們始終只需要對同一批相同功能的接口進行維護（負載均衡），各個接口沒有任何特異性的標準的數據提取接口，只根據請求內容進行內容返回，這樣就可以大大減少重復低效的開發工作量。
針對第二步數據業務格式化的特異性特別高，我們仍將這種與業務強相關的步驟放到業務端中，由各業務線進行數據處理，加工成他們需要的組織形式再返回給客戶端。
此時，后端開發人員只需要開發面向數據源的數據輸入接口，也就是將收集的數據進行清洗整合成為中臺的數據原材料。數據中心也就成為了中臺，將各個業務數據存留在這，并提供統一的取數方法。前臺人員根據需要去請求數據，將原本后臺的這兩個步驟統一處理后劃分為：數據獲?。ㄖ信_）與數據業務端組合（前臺）兩部分：
最后
最后給大家一個個人理解中臺戰略，特別是業務中臺的搭建是一個高度定制化的戰略，如果我們想要發揮中臺化戰略的最大價值，就需要依據不同公司、不同業務、不同階段的特征去定義與動態調整中臺演進方向。
就像本文的項目數據中心案例一樣，只有最適合當前業務的中臺框架，才是真正的解決方案。
作者：叫我阿逸，公眾號：人云逸云；產品道路上不斷前行的產品小白
本文由 @叫我阿逸 原創發布于人人都是產品經理，未經許可，禁止轉載
題圖來自 Unsplash，基于 CC0 協議
為什么是2，1呢？
有沒有直接點的案例展示呢
有個問題咨詢，按照上述流程嗎，是不是各個業務線前端數據取的數據都來自于中臺系統，存的時候又在各個業務后臺獨立的數據庫，最終通過ETL存入DW？
上一篇在我的公眾號有，有興趣的朋友可以去看看。