數(shù)據(jù)中臺的建設(shè)第三年，我們開始推動數(shù)據(jù)中臺的API開放，原因見《為什么是API而不是文件，對于數(shù)據(jù)中臺的開放如此重要？by 傅一平》這篇文章，就是why，這篇文章再講講how，也就是如何做的，當(dāng)然現(xiàn)在做的還很稚嫩和艱難，權(quán)當(dāng)拋磚引玉。

1、業(yè)務(wù)驅(qū)動

數(shù)據(jù)團(tuán)隊的工作很多，雖然API服務(wù)開放很重要，但重要的并不一定緊急，不緊急的就沒必要現(xiàn)在做，但正在發(fā)生的三個事情促使我們要做出一些改變，也就是業(yè)務(wù)的壓力。

第一是對外變現(xiàn)規(guī)模日益擴(kuò)大。

面對快速增加的客戶，各條產(chǎn)品線需不停的申請數(shù)據(jù)開發(fā)資源滿足需求，導(dǎo)致資源緊張，而且開發(fā)的模型質(zhì)量很低，大量重復(fù)，沒有什么沉淀價值。

結(jié)果就是，很多數(shù)據(jù)產(chǎn)品運營了幾年漸成雞肋，因為最核心的數(shù)據(jù)競爭力沒了，畢竟數(shù)據(jù)產(chǎn)品是無法靠體驗或運營來續(xù)命的。

第二是數(shù)據(jù)中臺生態(tài)環(huán)境不好。

外人看我們的數(shù)據(jù)中臺建得如火如荼，但實際卻離產(chǎn)品很遠(yuǎn)，做的主要工作就是數(shù)據(jù)采集、數(shù)據(jù)開發(fā)和運維保障。

久疏戰(zhàn)陣的數(shù)據(jù)中臺模型大多退化，偶偶有一次產(chǎn)品方需要數(shù)據(jù)中臺來提供模型支撐，但發(fā)現(xiàn)數(shù)據(jù)中臺根本支撐不動，或者耗時很長，久而久之，產(chǎn)品方就失了耐心。

我在想，數(shù)據(jù)中臺如果再沒有一種強(qiáng)制的與業(yè)務(wù)協(xié)同的保障機(jī)制，數(shù)據(jù)中臺就完了，跟20年前的數(shù)據(jù)倉庫沒啥區(qū)別。

第三是數(shù)據(jù)中臺缺乏成就感。

數(shù)據(jù)中臺成員要么做非常底層的模型工作，要么去做定制開發(fā)，相對商務(wù)和產(chǎn)品人員，獲得感是不足的，即使考核傾斜也沒啥用，因為很多人追求的是價值感。

自己去研讀了很多公司的數(shù)據(jù)中臺架構(gòu)，包括阿里的OneService、史凱的公眾號等等，最后得出結(jié)論：數(shù)據(jù)變現(xiàn)只要有了規(guī)模，API的開放和運營就不得不做，因為支撐不動。

2、組織保障

數(shù)據(jù)中臺要建設(shè)好，運營至關(guān)重要，API運營職能放在哪個組織就很關(guān)鍵。

有一種選擇是設(shè)立獨立的中臺運營組織，畢竟運營是非常專業(yè)的事情，但在大家對于中臺的概念還沒扯清的時候，設(shè)置獨立的運營組織風(fēng)險就很大，因為中臺運營組織一旦獨立，承上啟下的工作會非常多，管理成本直線上升，比較保守的做法就是在現(xiàn)有的相關(guān)組織增加運營職能，讓子彈先飛一會兒。

當(dāng)時有三種選擇，將API運營職能放在平臺開發(fā)組，數(shù)倉模型組或是挖掘服務(wù)組。

平臺研發(fā)組主要負(fù)責(zé)數(shù)據(jù)開發(fā)、治理、運維、開放等平臺的建設(shè)和運營，數(shù)倉模型組主要負(fù)責(zé)基礎(chǔ)模型、融合模型的建設(shè)和運營，挖掘服務(wù)組主要滿足業(yè)務(wù)方提出的數(shù)據(jù)需求。

如果把API運營職能放在平臺研發(fā)組，優(yōu)勢是API開放相關(guān)功能本身就是由該組負(fù)責(zé)開發(fā)的，建設(shè)的溝通成本會低很多，但劣勢是離業(yè)務(wù)太遠(yuǎn)了。

數(shù)倉模型的運營失敗告訴我們，API的運營組織必須具備在業(yè)務(wù)流程中強(qiáng)制卡位的能力，否則API就會做死。

因此唯一的選擇就是挖掘服務(wù)組，其本來就直接面向業(yè)務(wù)提供數(shù)據(jù)支撐，進(jìn)行API開放運營具有天然的優(yōu)勢。

圍繞API運營我定出了三個組織的新職能：

挖掘服務(wù)組：負(fù)責(zé)API體系規(guī)劃、API規(guī)范制定、API需求管理、API開發(fā)實現(xiàn)，API上架審核、API開放審核、API評估等

平臺研發(fā)組：負(fù)責(zé)API服務(wù)的訂閱，開放等功能的實現(xiàn)

數(shù)倉模型組：根據(jù)API服務(wù)的要求，持續(xù)優(yōu)化倉庫模型

挖掘服務(wù)組是API運營的中樞，其是API開放的第一推動力，其他組織基于專業(yè)能力做好API服務(wù)的支撐。

3、服務(wù)梳理

有了組織保障就可以干活了，第一件事就是要對游離在各類產(chǎn)品中的存量的API服務(wù)進(jìn)行統(tǒng)一梳理，以下是一個示例。

基于梳理的結(jié)果，可以總結(jié)出當(dāng)前API服務(wù)面臨的五個挑戰(zhàn)：

（1）服務(wù)能力透明度低：雖然現(xiàn)有服務(wù)數(shù)量較多，但由于分散在不同系統(tǒng)，沒有形成統(tǒng)一服務(wù)開放目錄，業(yè)務(wù)方和產(chǎn)品方對于服務(wù)的理解不夠，導(dǎo)致調(diào)用量非常低，開放實現(xiàn)還是以文件為主

（2）服務(wù)開發(fā)冗余度高：當(dāng)前服務(wù)均同業(yè)務(wù)需求緊耦合，以定制化開發(fā)實現(xiàn)為主，相似服務(wù)在多套系統(tǒng)承載，服務(wù)冗余度很高

（3）服務(wù)開通流程較長：現(xiàn)有服務(wù)開放流程是以需求管理的模式實現(xiàn)的，需求流轉(zhuǎn)消耗時間長，服務(wù)開通平均周期1~2周，進(jìn)一步降低了服務(wù)開放的可能性

（4）服務(wù)運行穩(wěn)定性不足：各方產(chǎn)品實現(xiàn)服務(wù)的技術(shù)棧不同，服務(wù)資源的集約化水平不夠，運維保障水平參差不齊

（5）服務(wù)運營缺少閉環(huán)：缺乏對于各類服務(wù)的常態(tài)化效果評估，無法進(jìn)行迭代優(yōu)化提升

4、服務(wù)目錄

基于存量服務(wù)的梳理，需要設(shè)計出API服務(wù)目錄體系，透明化是服務(wù)對外開放運營的基礎(chǔ)，以下是一個服務(wù)目錄的示例：

API服務(wù)與模型都屬于可以開放的資產(chǎn)，數(shù)據(jù)交換目錄和API服務(wù)目錄構(gòu)成了統(tǒng)一的數(shù)據(jù)資產(chǎn)目錄，以下是一個示例。

5、流程控制

API的需求管理流程要增加運營組的審核環(huán)節(jié)，確保API服務(wù)發(fā)布的規(guī)范性，如下是一個流程示例：

API發(fā)布的時候填寫的屬性越豐富，可用性就越好，運營組審核的關(guān)鍵內(nèi)容示例如下：

有一點要特別強(qiáng)調(diào)，API運營團(tuán)隊要在原有數(shù)據(jù)開放的流程環(huán)節(jié)進(jìn)行控制，確保能用API實現(xiàn)的開放不采取文件的形式，這也是挖掘服務(wù)組的一個原生優(yōu)勢。

6、平臺建設(shè)

我們打造了數(shù)據(jù)服務(wù)網(wǎng)關(guān)，用以收斂所有的服務(wù)，數(shù)據(jù)服務(wù)網(wǎng)關(guān)提供統(tǒng)一的數(shù)據(jù)目錄，承載所有數(shù)據(jù)中臺能力的發(fā)布和開放，包括數(shù)據(jù)服務(wù)目錄、數(shù)據(jù)服務(wù)提供、數(shù)據(jù)服務(wù)保障、數(shù)據(jù)服務(wù)開發(fā)及數(shù)據(jù)服務(wù)運營等功能，如下圖所示：

7、運營保障

關(guān)于API開放的認(rèn)知、組織、體系、平臺、流程都可以在短期內(nèi)建立，但要讓API開放能夠形成生產(chǎn)力，還是要靠持續(xù)的運營。

運營的關(guān)鍵則在于數(shù)據(jù)驅(qū)動，即能從數(shù)據(jù)、業(yè)務(wù)、資源等維度對API服務(wù)進(jìn)行常態(tài)化評估，形成從發(fā)現(xiàn)問題到解決問題的閉環(huán)，從而不斷提升API服務(wù)的質(zhì)量和規(guī)模，這也是API運營團(tuán)隊將面臨的最大挑戰(zhàn)。

治大國如烹小鮮，API開放只是數(shù)據(jù)中臺的一個點，而數(shù)據(jù)中臺也只是中臺的一個點，但正是這個點，往往決定了數(shù)據(jù)中臺的成敗。

在我們建的平臺到底是數(shù)據(jù)倉庫還是數(shù)據(jù)中臺的糾結(jié)中，也許API是唯一的救命稻草。