聊了那么久的中臺概念，本篇文章我們來看一個中臺MVP的實戰(zhàn)案例，以底層數(shù)據(jù)中心為例的實戰(zhàn)案例。在前幾篇文章《中臺實戰(zhàn)0、1、2》中我們已經(jīng)詳細描述了中臺戰(zhàn)略的建設(shè)目標與演化方式，抽象來看我們可以將其總結(jié)為這三個關(guān)鍵詞：復用、提效、一次開發(fā)。

一、中臺化前的產(chǎn)品現(xiàn)狀

在項目早期我們公司提供的服務(wù)就是在線酒店預(yù)訂，這種業(yè)務(wù)模式的整個流程也不復雜，主要分為這幾個環(huán)節(jié)：

BD進行拓店?-> 邀請酒店入駐平臺?-> 平臺上架?-> 用戶下單?-> 分傭

重點來看第一個環(huán)節(jié)，BD拓店實際就是將線下的酒店住宿服務(wù)當做商品“進貨”至公司的后臺中，從而為后面整個服務(wù)奠定基礎(chǔ)，這里也是整個業(yè)務(wù)的核心與數(shù)據(jù)唯一進口。

在這個環(huán)節(jié)中公司由BD與商務(wù)團隊維護并積累的大量底層“商品”數(shù)據(jù)，而初期這些底層數(shù)據(jù)在數(shù)據(jù)庫中，就是簡單的以“Key=Value”形式進行存儲。

存儲字段截取

當經(jīng)過一段時間的積累后，這種數(shù)據(jù)存儲方式由于維度簡單導致的結(jié)果，就是整個數(shù)據(jù)庫的數(shù)據(jù)量在很短時間內(nèi)出現(xiàn)猛增。

但是雖然看著每天都有“商品”數(shù)據(jù)入庫，慢慢的我們卻發(fā)現(xiàn)這些數(shù)據(jù)很多都是沒有辦法進行二次使用的，只能供特定的業(yè)務(wù)方進行獨立使用。

具體來說，在公司內(nèi)部我們通常會有多個業(yè)務(wù)團隊，每個業(yè)務(wù)團隊往往都會根據(jù)自己的業(yè)務(wù)需求在數(shù)據(jù)庫中建立一張屬于自己的數(shù)據(jù)庫表（這里為了行文方便我們視作一個表），這些表的業(yè)務(wù)數(shù)據(jù)字段與定義方式都是按照業(yè)務(wù)方定制化進行的。

例如在當時，我們的酒店預(yù)訂就分為兩個業(yè)務(wù)團隊：

• 非標住宿預(yù)定，也就是民宿；
• 標準酒店預(yù)定；

所以此時在后臺我們有了兩套業(yè)務(wù)數(shù)據(jù)體系，這些數(shù)據(jù)都是這兩個業(yè)務(wù)方進行自主定義的。

二、挑戰(zhàn)：業(yè)務(wù)線

這樣的數(shù)據(jù)看似很尋常，目前很多企業(yè)也是這樣對內(nèi)部團隊管理的。但是對于這種我稱之為依托于前端統(tǒng)一團隊的業(yè)務(wù)來說（兩個業(yè)務(wù)方由統(tǒng)一的一群BD去進行掃街），我們實際上去做的就是將已經(jīng)標準化了的數(shù)據(jù)（酒店錄入數(shù)據(jù)）再次人為進行了割裂，變成了兩個獨立的業(yè)務(wù)數(shù)據(jù)庫，如下圖所示。

我們要知道很多企業(yè)平時日常所做的工作大多數(shù)都是在進行數(shù)據(jù)的遷移與整合，如：將用戶行為數(shù)據(jù)與用戶唯一標識數(shù)據(jù)結(jié)合，從而唯一確定分析這個用戶的喜好。

那么也就意味著我們每破壞一次數(shù)據(jù)之間的關(guān)聯(lián)性就意味著，為后期增加了一次需要進行反向操作，也就是將數(shù)據(jù)進行合并的工作負擔。特別是我們將酒店天然性以業(yè)務(wù)墻進行了阻攔，更是破壞了數(shù)據(jù)的強關(guān)聯(lián)性（同類數(shù)據(jù)）。

同時這樣的數(shù)據(jù)也使得對于既屬于民宿又屬于標準酒店業(yè)務(wù)庫中的數(shù)據(jù)成為總庫的冗余數(shù)據(jù)，曾帶來的一個很嚴重隱患，就是當民宿業(yè)務(wù)線的運營同學發(fā)現(xiàn)酒店名稱發(fā)生改變并變更后，我們另一端的運營同學很難去即時發(fā)現(xiàn)并處理。此時在標準酒店業(yè)務(wù)端出現(xiàn)了多次用戶下單后，該酒店因為店名與實際店名不統(tǒng)一，而旅客無法入住的情況，并多次投訴平臺。

當然這只是若干次業(yè)務(wù)數(shù)據(jù)管理中的一個小小的縮影，正是因為這樣的意外挑戰(zhàn)出現(xiàn)，讓我們對于現(xiàn)有的數(shù)據(jù)管理方式產(chǎn)生了要去進行變革的意圖。

三、挑戰(zhàn)2：創(chuàng)新業(yè)務(wù)

我們知道絕大多數(shù)互聯(lián)網(wǎng)的產(chǎn)品本質(zhì)就是以不同的展示形式、遞進次序陳列出不同的數(shù)據(jù)，滿足用戶的信息需求。如新聞網(wǎng)站與今日頭條都是在展示新聞數(shù)據(jù)，而陳列的次序一個是按編輯維度，一個是按讀者的閱讀習慣維度。

那么也就是說只要有了數(shù)據(jù)源，我們在這基礎(chǔ)上就可以衍生出不同的產(chǎn)品。我們原公司業(yè)務(wù)也不例外，在我們收集了一段時間市場的酒店信息后我們就想著可以用這些數(shù)據(jù)來組織些新的產(chǎn)品，以此來滿足不同細分市場人群。

如將酒店的基本信息數(shù)據(jù)（照片，介紹等）與第三方游記攻略類數(shù)據(jù)共享，提供數(shù)據(jù)輸出服務(wù)。和想分析現(xiàn)有的數(shù)據(jù)的數(shù)據(jù)預(yù)測服務(wù)：根據(jù)不同地區(qū)的新增房源數(shù)據(jù)進行旅游真實熱門景區(qū)排行。

這個時候面對之前分散的非標住宿預(yù)定與標準住宿預(yù)定兩個獨立業(yè)務(wù)，我們更想要看的兩個業(yè)務(wù)線匯總后的全維度數(shù)據(jù)，而在現(xiàn)有條件下這個變得必須要逾越兩個業(yè)務(wù)線的阻隔。

四、業(yè)務(wù)中臺解決方案

面對這樣的幾個挑戰(zhàn)，我們的選擇就是利用中臺去進行解決，此時中臺1.0是這樣構(gòu)建的：

步驟1：中央集權(quán)

將酒店數(shù)據(jù)剝離各業(yè)務(wù)線團隊，把酒店數(shù)據(jù)存儲至獨立的數(shù)據(jù)中心（也就是中臺1.0）進行維護，打破各團隊隔離，此時將原有的環(huán)節(jié)改為：

BD進行拓店?-> 邀請酒店入駐平臺?-> 數(shù)據(jù)中心（新增）?-> 平臺上架?-> 用戶下單?-> 分傭

而在新增數(shù)據(jù)中心進行統(tǒng)一維護后，面對各自團隊的數(shù)據(jù)需求我們可以在數(shù)據(jù)中心劃分為虛擬數(shù)據(jù)源用以進行支撐。

酒店數(shù)據(jù)與各個業(yè)務(wù)線生成的訂單等數(shù)據(jù)都匯總到數(shù)據(jù)中心中，數(shù)據(jù)中心是整個企業(yè)的基礎(chǔ)服務(wù)提供全局的數(shù)據(jù)。

步驟2：特異性管理

接下來讓我們來分析下整個業(yè)務(wù)運作流程，在原有兩個產(chǎn)品線的業(yè)務(wù)模式與創(chuàng)新產(chǎn)品的業(yè)務(wù)模式中，當我們以數(shù)據(jù)流轉(zhuǎn)的整個視角來看，本質(zhì)上這些業(yè)務(wù)就是下圖所示的數(shù)據(jù)流。

不難發(fā)現(xiàn)，在這里作為數(shù)據(jù)源的提供方為業(yè)務(wù)方做了兩個步驟的工作：

• 數(shù)據(jù)取用：根據(jù)業(yè)務(wù)方所要的數(shù)據(jù)范圍提供數(shù)據(jù)（如：本次業(yè)務(wù)需要讀取會員ID，會員姓名這兩個字段）；
• 數(shù)據(jù)業(yè)務(wù)格式化：根據(jù)業(yè)務(wù)方所要的數(shù)據(jù)格式進行特定數(shù)據(jù)格式/順序生成返回（如：業(yè)務(wù)方A返回數(shù)據(jù)格式：會員ID=“12311”+會員姓名=“張三”；業(yè)務(wù)方B返回數(shù)據(jù)格式：會員姓名->“張三”and會員ID->“12311”）。

對比這兩個步驟的工作我們就能發(fā)現(xiàn)，第二個步驟實際上是原來整個后臺支撐系統(tǒng)額外的工作的罪魁禍首。像上文提到的每次數(shù)據(jù)接口只能為一個業(yè)務(wù)方提供服務(wù)，這個接口由于數(shù)據(jù)返回格式是特定的所以具有很強的特異性，導致后臺同學需要不斷進行新的提供數(shù)據(jù)的接口的開發(fā)。對于不懂技術(shù)的同學，我們可以理解為后臺同學在提供同樣的信息而先后順序不一樣時，需要設(shè)計不同的傳輸通道。

大家可以看到這無疑就是巨大的浪費。大家可以回想下在自己的日常工作中這樣的情況是不是也相當常見，例如：產(chǎn)品迭代中每次版本更新導致的需要重新設(shè)計接口（新舊產(chǎn)品就同一數(shù)據(jù)的不同封裝形式的取用）；老版本數(shù)據(jù)接口與新版本的同一數(shù)據(jù)接口不同，需要分別維護。

所以當時我們是這樣解決的，這兩個步驟中第一個服務(wù)共性很高，很容易抽取成公共服務(wù)。我們就數(shù)據(jù)中心提供了一個標準的取數(shù)據(jù)接口，各個業(yè)務(wù)方只需要傳輸需要什么字段名稱，我們的統(tǒng)一數(shù)據(jù)返回接口就把數(shù)據(jù)返回至業(yè)務(wù)方。這樣在所有的版本中我們始終對同一批相同功能的接口進行維護（為了負載均衡），各個接口沒有任何特異性都是標準的取數(shù)據(jù)接口，只根據(jù)請求內(nèi)容進行內(nèi)容返回，這樣大大減少了開發(fā)量。

對第二步驟由于特異性特別高，我們將這種與業(yè)務(wù)強相關(guān)的東西下放到業(yè)務(wù)端，由業(yè)務(wù)方進行數(shù)據(jù)處理，加工成他們需要的組織形式再返回給客戶方。

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

而整個系統(tǒng)的架構(gòu)也就變成了如下圖的樣子：

最后

在最后給大家一個個人理解中臺戰(zhàn)略，特別是業(yè)務(wù)中臺的搭建是一個高度定制化的戰(zhàn)略，如果我們想要發(fā)揮中臺化戰(zhàn)略的最大價值，就需要依據(jù)不同公司、不同業(yè)務(wù)、不同階段的特征去定義與動態(tài)調(diào)整中臺演進方向。就像本文的酒店數(shù)據(jù)中心案例一樣，只有最適合當前業(yè)務(wù)的中臺框架，才是真正的解決方案。

相關(guān)閱讀

最近處處惹人愛的中臺到底是什么

中臺實戰(zhàn)（1）：看懂企業(yè)業(yè)務(wù)演進路線

中臺實戰(zhàn)（2）：中臺的建設(shè)核心原則

#專欄作家#

三爺，微信公眾號：三爺茶館，人人都是產(chǎn)品經(jīng)理專欄作家。曾萬達高級產(chǎn)品、MBA特約講師、獨立創(chuàng)業(yè)者，現(xiàn)某支付公司產(chǎn)品線負責人，擁有多款集團項目從零到一經(jīng)驗并帶領(lǐng)實現(xiàn)商業(yè)化布局。

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

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