今天就接著上次聊到的中台實戰提到的項目管理系統和採購管理系統的案例繼續講，看看數據中台方案是怎麼實踐的。

先回歸一下上次案例的主要問題：

在A公司里項目管理系統和採購管理系統是屬於獨立兩個業務線團隊，在後臺是有著兩套獨立的業務數據體系，這些數據由各業務線團隊進行自主定義和維護的。

但在一體化平臺建設中，單獨對兩個系統的業務數據的維護成本是非常高的，而且把兩個原本是有數據關聯的系統阻隔開後，那麼系統對數據之間的關聯應用效率就非常地低。所以我們要針對這些問題進行中台方案的構建。

步驟一：強乾弱枝

在A公司的一體化平臺中，包含了項目管理子系統、採購管理子系統、資產管理子系統等7個業務子系統，涵蓋的數據量是非常的大。

那麼，對於龐大的數據量時，我們首先要做的是把數據剝離各業務線團隊，進行抽象提取，保留“主幹”。將數據存儲至獨立的數據中心（即中台1.0）進行維護，打破各業務線團隊之間的阻隔牆，此時原有的數據環節變為：

項目數據與其他各業務線生產的數據都彙總到數據中心，在數據中心對各業務線數據進行統一維護後，面對各業務線團隊的數據需求，我們可以在數據中心劃分各虛擬數據源以支撐各業務線團隊使用。

數據中心是為整個A公司的產品基礎服務提供全局的數據。

步驟二：特異性管理

在數據應用中，我們會經常遇到對不同業務線中有關聯的數據進行調用的情況，例如：在採購管理系統中新增了一個採購項目，那麼項目管理系統此時就需要對該採購項目進行數據新增。

所以，對其他業務線數據進行調用時，需經過這些步驟：

這時我們可以看到從其他業務線數據源調用數據時主要做了兩個步驟的工作：

• 數據提取：根據業務方（項目管理系統）所要的數據範圍提供數據（如，本次業務需要讀取項目ID、項目名稱這兩個字段）；
• 數據業務格式化：根據業務方（項目管理系統）所要的數據格式進行特定數據格式/順序生成（如，業務方A（採購管理系統）返回數據格式：項目ID=“12345”+項目名稱=“項目1”；業務方B（項目管理系統）返回數據格式：項目名稱->“項目1” and 項目ID->“12345”）。

看完以上兩個步驟的工作，有沒有感受到實際上這就是原本整個後臺支撐系統巨大的工作量的重要原因。像上文提到的每次接口只能為一個業務方提供服務，而且這個接口由於數據返回格式是特定的所以具有很強的特異性，這樣就導致後端開發需要不斷地進行新的提供數據的接口開發工作。

這無疑是對企業資源的巨大浪費。這種情況在我們的日常工作中應該是非常常見的（此處有沒有共鳴），例如：產品迭代升級中每次版本更新導致需要重新設計接口（新舊版本就同一個數據的不同封裝形式的取用）；老版本數據接口與新版本的同一數據接口不同，需要重新設計編寫，且需要分別維護。

對於這個問題，我是這樣解決的：這兩個步驟中第一個服務共性很高，很容易提取成一個公共服務。所以，我們就在數據中心提供一個標準的數據提取接口，各個業務方只需要傳輸需要什麼字段，我們的統一數據返回接口就把數據返回至各業務方。

這樣，在所有的版本中，我們始終只需要對同一批相同功能的接口進行維護（負載均衡），各個接口沒有任何特異性的標準的數據提取接口，只根據請求內容進行內容返回，這樣就可以大大減少重覆低效的開發工作量。

針對第二步數據業務格式化的特異性特別高，我們仍將這種與業務強相關的步驟放到業務端中，由各業務線進行數據處理，加工成他們需要的組織形式再返回給客戶端。

此時，後端開發人員只需要開發麵向數據源的數據輸入接口，也就是將收集的數據進行清洗整合成為中台的數據原材料。數據中心也就成為了中台，將各個業務數據存留在這，並提供統一的取數方法。前臺人員根據需要去請求數據，將原本後臺的這兩個步驟統一處理後劃分為：數據獲取（中台）與數據業務端組合（前臺）兩部分：

最後

最後給大家一個個人理解中台戰略，特別是業務中台的搭建是一個高度定製化的戰略，如果我們想要發揮中台化戰略的最大價值，就需要依據不同公司、不同業務、不同階段的特征去定義與動態調整中台演進方向。

就像本文的項目數據中心案例一樣，只有最適合當前業務的中台框架，才是真正的解決方案。

作者：叫我阿逸，公眾號：人雲逸雲；產品道路上不斷前行的產品小白

本文由 @叫我阿逸 原創發佈於人人都是產品經理，未經許可，禁止轉載

題圖來自 Unsplash，基於 CC0 協議