今天就接著上次聊到的中臺實(shí)戰(zhàn)提到的項(xiàng)目管理系統(tǒng)和采購管理系統(tǒng)的案例繼續(xù)講，看看數(shù)據(jù)中臺方案是怎么實(shí)踐的。

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

在A公司里項(xiàng)目管理系統(tǒng)和采購管理系統(tǒng)是屬于獨(dú)立兩個業(yè)務(wù)線團(tuán)隊(duì)，在后臺是有著兩套獨(dú)立的業(yè)務(wù)數(shù)據(jù)體系，這些數(shù)據(jù)由各業(yè)務(wù)線團(tuán)隊(duì)進(jìn)行自主定義和維護(hù)的。

但在一體化平臺建設(shè)中，單獨(dú)對兩個系統(tǒng)的業(yè)務(wù)數(shù)據(jù)的維護(hù)成本是非常高的，而且把兩個原本是有數(shù)據(jù)關(guān)聯(lián)的系統(tǒng)阻隔開后，那么系統(tǒng)對數(shù)據(jù)之間的關(guān)聯(lián)應(yīng)用效率就非常地低。所以我們要針對這些問題進(jìn)行中臺方案的構(gòu)建。

步驟一：強(qiáng)干弱枝

在A公司的一體化平臺中，包含了項(xiàng)目管理子系統(tǒng)、采購管理子系統(tǒng)、資產(chǎn)管理子系統(tǒng)等7個業(yè)務(wù)子系統(tǒng)，涵蓋的數(shù)據(jù)量是非常的大。

那么，對于龐大的數(shù)據(jù)量時，我們首先要做的是把數(shù)據(jù)剝離各業(yè)務(wù)線團(tuán)隊(duì)，進(jìn)行抽象提取，保留“主干”。將數(shù)據(jù)存儲至獨(dú)立的數(shù)據(jù)中心（即中臺1.0）進(jìn)行維護(hù)，打破各業(yè)務(wù)線團(tuán)隊(duì)之間的阻隔墻，此時原有的數(shù)據(jù)環(huán)節(jié)變?yōu)椋?/p>

項(xiàng)目數(shù)據(jù)與其他各業(yè)務(wù)線生產(chǎn)的數(shù)據(jù)都匯總到數(shù)據(jù)中心，在數(shù)據(jù)中心對各業(yè)務(wù)線數(shù)據(jù)進(jìn)行統(tǒng)一維護(hù)后，面對各業(yè)務(wù)線團(tuán)隊(duì)的數(shù)據(jù)需求，我們可以在數(shù)據(jù)中心劃分各虛擬數(shù)據(jù)源以支撐各業(yè)務(wù)線團(tuán)隊(duì)使用。

數(shù)據(jù)中心是為整個A公司的產(chǎn)品基礎(chǔ)服務(wù)提供全局的數(shù)據(jù)。

步驟二：特異性管理

在數(shù)據(jù)應(yīng)用中，我們會經(jīng)常遇到對不同業(yè)務(wù)線中有關(guān)聯(lián)的數(shù)據(jù)進(jìn)行調(diào)用的情況，例如：在采購管理系統(tǒng)中新增了一個采購項(xiàng)目，那么項(xiàng)目管理系統(tǒng)此時就需要對該采購項(xiàng)目進(jìn)行數(shù)據(jù)新增。

所以，對其他業(yè)務(wù)線數(shù)據(jù)進(jìn)行調(diào)用時，需經(jīng)過這些步驟：

這時我們可以看到從其他業(yè)務(wù)線數(shù)據(jù)源調(diào)用數(shù)據(jù)時主要做了兩個步驟的工作：

• 數(shù)據(jù)提取：根據(jù)業(yè)務(wù)方（項(xiàng)目管理系統(tǒng)）所要的數(shù)據(jù)范圍提供數(shù)據(jù)（如，本次業(yè)務(wù)需要讀取項(xiàng)目ID、項(xiàng)目名稱這兩個字段）；
• 數(shù)據(jù)業(yè)務(wù)格式化：根據(jù)業(yè)務(wù)方（項(xiàng)目管理系統(tǒng)）所要的數(shù)據(jù)格式進(jìn)行特定數(shù)據(jù)格式/順序生成（如，業(yè)務(wù)方A（采購管理系統(tǒng)）返回?cái)?shù)據(jù)格式：項(xiàng)目ID=“12345”+項(xiàng)目名稱=“項(xiàng)目1”；業(yè)務(wù)方B（項(xiàng)目管理系統(tǒng)）返回?cái)?shù)據(jù)格式：項(xiàng)目名稱->“項(xiàng)目1” and 項(xiàng)目ID->“12345”）。

看完以上兩個步驟的工作，有沒有感受到實(shí)際上這就是原本整個后臺支撐系統(tǒng)巨大的工作量的重要原因。像上文提到的每次接口只能為一個業(yè)務(wù)方提供服務(wù)，而且這個接口由于數(shù)據(jù)返回格式是特定的所以具有很強(qiáng)的特異性，這樣就導(dǎo)致后端開發(fā)需要不斷地進(jìn)行新的提供數(shù)據(jù)的接口開發(fā)工作。

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

對于這個問題，我是這樣解決的：這兩個步驟中第一個服務(wù)共性很高，很容易提取成一個公共服務(wù)。所以，我們就在數(shù)據(jù)中心提供一個標(biāo)準(zhǔn)的數(shù)據(jù)提取接口，各個業(yè)務(wù)方只需要傳輸需要什么字段，我們的統(tǒng)一數(shù)據(jù)返回接口就把數(shù)據(jù)返回至各業(yè)務(wù)方。

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

針對第二步數(shù)據(jù)業(yè)務(wù)格式化的特異性特別高，我們?nèi)詫⑦@種與業(yè)務(wù)強(qiáng)相關(guān)的步驟放到業(yè)務(wù)端中，由各業(yè)務(wù)線進(jìn)行數(shù)據(jù)處理，加工成他們需要的組織形式再返回給客戶端。

此時，后端開發(fā)人員只需要開發(fā)面向數(shù)據(jù)源的數(shù)據(jù)輸入接口，也就是將收集的數(shù)據(jù)進(jìn)行清洗整合成為中臺的數(shù)據(jù)原材料。數(shù)據(jù)中心也就成為了中臺，將各個業(yè)務(wù)數(shù)據(jù)存留在這，并提供統(tǒng)一的取數(shù)方法。前臺人員根據(jù)需要去請求數(shù)據(jù)，將原本后臺的這兩個步驟統(tǒng)一處理后劃分為：數(shù)據(jù)獲取（中臺）與數(shù)據(jù)業(yè)務(wù)端組合（前臺）兩部分：

最后

最后給大家一個個人理解中臺戰(zhàn)略，特別是業(yè)務(wù)中臺的搭建是一個高度定制化的戰(zhàn)略，如果我們想要發(fā)揮中臺化戰(zhàn)略的最大價(jià)值，就需要依據(jù)不同公司、不同業(yè)務(wù)、不同階段的特征去定義與動態(tài)調(diào)整中臺演進(jìn)方向。

就像本文的項(xiàng)目數(shù)據(jù)中心案例一樣，只有最適合當(dāng)前業(yè)務(wù)的中臺框架，才是真正的解決方案。

作者：叫我阿逸，公眾號：人云逸云；產(chǎn)品道路上不斷前行的產(chǎn)品小白

本文由 @叫我阿逸 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自 Unsplash，基于 CC0 協(xié)議