從今天開始打算寫兩三篇文章，力求說清楚什么是中臺，什么時候要考慮建中臺，怎么建中臺。今天是第一篇，目標是厘清什么是中臺。

中臺的概念一熱，很多似是而非的東西都在往中臺的概念上湊，一下子出現很多中臺，如業務中臺、數據中臺、技術中臺、算法中臺、移動中臺等等。特別是很多原來稱作平臺的，現在也都搖身一變成了中臺，趕時髦。

一個概念太過寬泛是不利的，如果隨隨便便都是中臺，必然導致很多所謂的中臺項目失敗，導致中臺無用論。所以有必要對中臺的概念做一個比較準確的定義。

1 什么是中臺

要定義中臺，重要的是要能比較明確的區分中臺和平臺。中臺和平臺都是某種共性能力，區分兩者的重點一是看是否具備業務屬性，二是看是否是一種組織。中臺是支持多個前臺業務且具備業務屬性的共性能力組織，平臺是支持多個前臺或中臺業務且不具備業務屬性的共性能力。

為什么要強調中臺必須具備業務屬性？可以來看一個例子。我們可以分析什么叫數據中臺。如果一個企業把所有業務的數據都存儲在Oracle里，我們能說這個Oracle數據庫是數據中臺嗎？顯然大家都會說不是（否則中臺不是幾十年的老古董了？）。那么現在很多企業換成了Hadoop，所有業務數據都在一個Hadoop集群里，能說是數據中臺嗎？顯然也不是，這個Hadoop無非跟原來的Oracle一樣存了一堆數據而已。有人說這是因為這個Hadoop集群只是一個系統，中臺必須是一個組織。那么我們再加上建設和維護這個Hadoop集群的團隊，整個加起來就是中臺了嗎？

仍然不是，因為這個團隊是不需要為業務負責的，不具備業務屬性。而現在大家比較公認的數據中臺，指的是確保OneID、OneData得以實現的組織，使得數據不再是各前端業務獨立管理，而是通過統一的團隊在數據標識、指標、數據倉庫等方面實現了跨業務的整合。之所以這樣大家會認為是名符其實的數據中臺，是因為指標一定是面向業務的，數據倉庫的建設一定也包含了一些業務邏輯。所以那個大大的Hadoop并不是數據中臺，而是大數據平臺。

我們還可以看到是中臺還是平臺與所在的業務環境相關。同樣的能力對A業務來說可能具備業務屬性從而是中臺，但對B業務來說沒有業務屬性從而是平臺。比如說IDC建設和運維對AWS來說可謂至關重要的業務中臺，而對絕大多數企業來說只能說是平臺。PaaS平臺對SaaS廠商來說是業務中臺，但對絕大多數企業來說也只能說是平臺。

所以，不具備業務屬性的能力，即便是共性的，即便有一個專職的部門在做，即便對業務非常重要，也不能稱之為中臺，而還是應該稱之為平臺。否則就會出現很多與業務八桿子打不著的各種中臺，混淆視聽。因此，應該說所有中臺都是業務中臺，沒有別的類型的中臺。數據中臺、搜索中臺、內容中臺、零售中臺等等，都是特定形式的業務中臺，也還是業務中臺。

中臺的定義還要求以下兩點：

1.  中臺是一種共性能力組織，支持了多個業務。

2.  中臺支持的是多個前臺業務。

第一點不用多說，只支持一個業務的能力至少暫時不能稱為中臺（當然可以有進一步建設為中臺的規劃或可能性）。之所以強調第二點是因為有太多的公司的業務不是靠前臺打下來的，而是靠財務后臺做賬做出來的。理論上可以有，但我們應該支持這樣增強做賬能力的中臺嗎？對于那些專業提供做賬服務的公司，還真需要這樣的中臺，但這時做賬就是它的前臺業務了。

中臺的定義并沒有限定中臺的建設層次。中臺可以在很多個層次上建設，并不是說必須是企業或集團級別的。BU和BG層面建設中臺往往更常見，也通常很有意義。即便更小的層面比方幾十人的小部門，中臺也很有價值。比如一個小團隊也可以做電商業務，這時如果有一套好用的電商中臺那就幫了大忙了，而事實上業界也有很多公司在提供這樣的能力（淘品牌可以說用的就是阿里提供的中臺）。

2 典型的中臺有哪些

除了常說的業務中臺，我們還經常聽到數據中臺、用戶中臺、搜索中臺、推薦中臺、內容中臺、技術中臺、算法中臺、移動中臺、研發中臺等等一系列的XX中臺的說法，但這些中臺未必都是真正的中臺。

前面已經說過，廣義上講業務中臺包含了所有中臺，不同的XX中臺都是業務中臺的細分方向，反映的是該中臺在業務領域或者技術上的某些特征。但大家受阿里的影響，往往只用業務中臺來指稱在線業務中臺。基于這個假定，當前典型的真正的中臺大致只有以下幾個：

1. （狹義的）業務中臺：一般指在線業務為典型特征的中臺。在OLDI（Online Data-Intensive）時代，越來越多的企業的核心業務都是在線業務，因此把在線業務中臺簡稱為業務中臺。但對那些不是以在線業務為主的企業，它需要的業務中臺可能就不是在線業務中臺了，而是數據中臺或別的什么中臺。

2.  數據中臺：一般指以數據采集、數據集成、數據治理，指標體系和數據倉庫統一建設等數據管理活動為典型特征的中臺。同樣，在OLDI時代，數據中臺越來越重要。狹義的業務中臺也就是在線業務中臺負責OLDI中的OL（Online），數據中臺負責OLDI中的DI（Data-Intensive）。

3.  用戶中臺：用戶中臺可以認為是一種特殊的數據中臺，一般以用戶ID統一、全域用戶畫像建設、全域會員體系建設等為典型特征。用戶中臺很通用，比更廣義的數據中臺往往更常見。很多企業沒能力建設更全面的數據中臺，但建設了會員中心等用戶中臺。

4. 內容中臺：內容中臺往往也可以認為是一種特殊的數據中臺，一般以內容的采買、內容爬取、內容的加工處理、內容安全保障等為典型特征。

5. 搜索推薦中臺：這兩個中臺比較像，因為搜索和推薦的技術比較相似。這兩個中臺一般是為推薦和搜索系統提供一套相對標準的工作流程，同時支持流程各環節的可定制能力，從而支持多個前端推薦搜索業務的快速開發。

當然還有很多其他根據業務需要建設的中臺，比方說對美團/餓了嗎來說，本地配送體系可以建設為中臺，前提是這個體系不僅用于送餐。在電商行業，往往渠道運營用單獨的系統和團隊來支持各個BU（一般按品類分），也可以說是中臺。

3 技術/算法/移動/研發中臺當前基本不存在

一般來說，沒有技術中臺，這是因為以技術為典型特征，又具備業務屬性的中臺太難找了，沒有一個很好的案例。可以看看業界所謂的阿里的技術中臺，包含了從IaaS到中間件等一系列在線業務技術，但能稱這些為中臺嗎？可以把里面每個模塊都拿出來分析，保證你找不到一個跟業務相關的字眼。所以這些并不是中臺。

再看業界所謂的阿里移動中臺，其實來源于阿里關于移動研發平臺EMAS的分享。人家阿里其實自稱的是一個研發平臺而不是中臺。還有業界把阿里的研發平臺云效平臺稱為研發中臺，這也是一種誤讀。

其實阿里自己也只說業務中臺和數據中臺。其他的中臺都是某些咨詢公司或不明真相的群眾牽強附會造出來的。

并不是說不能有技術中臺，而是沒必要特別的稱作技術中臺而非業務中臺。對于提供技術服務的企業，它的業務前臺就是技術前臺，它的業務中臺就是技術中臺。比方說SaaS廠商的中臺往往是個PaaS，這時這個PaaS可以稱之為技術中臺，但也是這個產商的業務中臺。同樣的一個PaaS，對于大多數別的企業，就變成只是支撐業務但本身沒有業務屬性的技術平臺了。所以，為了避免混淆，導致把平臺說成中臺，不如堅持認為不存在技術中臺。

同樣的道理，移動中臺似乎只對做移動應用開發業務（比如說很多外包產商）的企業來說才是中臺，但對這些企業來說移動中臺也就是它的業務中臺，所以也寧可不搞出一個移動中臺這樣的新名詞為好。

那么，什么才是研發中臺？華為有專職的研發部負責支持所有前端業務的研發，讓聽得見炮火的人指揮戰斗，可能是名副其實的研發中臺，但云效肯定不是。據我所知云效團隊主要是做云效這個產品，并不負責中臺業務系統的研發。不過，既然可能最有資格說是研發中臺的華為也沒出來趟中臺概念的渾水，我們著什么急呢。

總之一句話，當前并沒有好的技術 / 算法 / 移動 / 研發中臺，那些出來宣傳這些中臺的要么是自己搞不清中臺概念，糊涂，要么就是騙子。不過沒有這些中臺說明整個行業在這方面的積累還不夠，是一種不足，希望過幾年有真正的這些中臺出來。