從19年中開始，中臺概念的熱度突然間蹭的一下就上去了，而我所在的企業（某頭部電商企業）則在去年年底提出了全面建設中臺的戰略，于是我便吭哧吭哧的在中臺這個大坑里倒騰了大半年；期間起起伏伏的血淚總結，將在后文中與君分享，并借此分享真心希望幫助即將走上中臺建設與正在進行中臺建設的朋友們少走彎路。

中臺的緣起

明確中臺建設的目的十分重要！十分重要！十分重要！

關于中臺的緣起，想必阿里的例子，大家已經聽得耳朵起繭了：為了快速支持業務擴展，同時降低開發成本，阿里把能夠通用的服務抽離出來并以中臺的形式來提供共享服務。

那么，在這一句大家都耳熟能詳的關于中臺的定義中，中臺它最核心的目標又是什么呢？

避免重復開發？

抽離通用服務？

不，這些都只是手段。

中臺最核心的目標，沒有之一，就是快速響應業務訴求。

以終為始，方得善終。

以我們中臺項目團隊的親身經歷來回顧的話，在整個項目的一開始，領導給項目團隊制定的目標就是，減少系統之間的重復開發，最短時間內，先把能夠抽象的公共服務完成打造。

整個項目團隊，二三十號人，吭哧吭哧的搞了好幾個月之后，總算是把第一階段的公共服務完成交付了。

但是極其殘酷的現實擺在面前：業務團隊根本不買單，而且毫不避諱地說這個東西的作用不大。

而在這一堆的公共服務打造的這幾個月里，所有的業務需求幾乎全部停滯。

換句話來說，在這幾個月的中臺的打造工程中，我們只是把原來已有的系統進行重新整合或者重構，又或者說是把原來一些業務同學認為并不是十分重要的功能模塊實現了通用化打造，但對于業務同學來說，最急最痛的一些東西，并沒有得到很好的滿足。

總結起來就是：你給的我不要，我要的你不給。

為什么會得到這一荒誕的結果呢？

很重要的一個原因就是把目的和手段搞反了：為了做中臺而做中臺，為了通用化而通用化。

但我們不妨再細想一層，我們為什么要做中臺？我們為什么要做通用化？這不都是為了更快速的響應業務的訴求嗎？

所以說，建設中臺的目的，從來都是為了快速有效的響應業務訴求，通用化這些都只是手段而已。

中臺的定義

關于中臺的定義，我十分認同王健老師的觀點：中臺就是企業級能力的復用。

拿大家熟悉的阿里巴巴的例子來說，他們把電商業務核心的模塊都梳理出來，并以共享的形式對前臺提供服務，這些核心的業務模塊包含：用戶中心，商品中心，交易中心，支付中心，庫存中心，物流中心。

而這些中心本質上就是阿里這個電商帝國核心的企業級能力，阿里通過把這些核心能力的中臺化，讓阿里的電商版圖在業務擴張的過程中，能夠快速的復用這些核心能力，最終達到快速響應業務的目的。

下面我們來一一細數這中臺定義的關鍵詞。

1. #企業級

企業級，就是說，中臺這個東西，在設計的時候，就應該站在全盤來考慮，做出來的東西定位是企業層的某項能力，而不單單是某個業務線或者某個項目組內部使用。站在全盤的角度來進行業務的抽象與復用，站在全盤的角度來考慮數據服務的融合與通用，并借此支持業務的快速與低成本的擴展。

基于上面的闡述：中臺做出來的東西定位是企業層級的某項通用能力，中臺的打造大概率涉及業務線和組織的調整。

如原先獨立的兩條業務線的交易模塊，在打造中臺的交易中心的時候，必定涉及原先這兩個團隊中該系統模塊的整合與人員的調整；這樣的調整下，必定需要由公司高層出面推進，即自上而下的推動，推動業務線的整合，推動利益的重新分配。

2. #能力

這里用的是能力這個詞，或者服務這個詞，而不是用系統、功能、模塊這些詞——就像產品的定位一樣，所有產品的，用戶消費的時候，本質上都是為了得到某個能力或者服務。中臺的打造也是一樣的，中臺的打造不是為了把原來的某個系統，某個功能在企業層面做整合打通，中臺要做的是能力的抽象和共享。

這個能力每個企業都有自己的現實情況，如數據能力、技術能力、算法能力、業務能力等；具體要從哪些能力方面入手，要把哪些能力中臺化，這個都需要每個企業結合自己的實際情況，結合企業的戰略，結合企業的市場定位，綜合再做決定。

而判斷的標準說來既簡單也復雜：業務在后續的發展中，最高頻、最迫切需要解決的是哪些場景問題。

3. #復用

提到“復用“這個詞，或者“共享“這個詞的話，想必很多朋友對中臺的認知都是如此吧？

其實復用這個概念在整個行業提了很多年了，例如編寫代碼的時候，封裝函數，各方調用，就有點這個味道。

只是說，中臺這個概念把「復用」這個概念的重要程度提升到了一個新的高度，而且從單單一個函數的復用，上升到了業務能力、數據能力、AI能力的高度。

讀到這里的時候，其實不少的朋友一定會在心里默默地念叨：阿里的中臺戰略之所以這么成功，很大一部分原因就是因為阿里絕大部分的業務都是屬于電商類業務，業務上面存在很多的共性，所以才可以復用，所以做中臺對于像阿里這樣的電商帝國來說，才是一個很好的選擇。

但這是不是就意味著說做中臺的企業，必須都是業務模式比較集中的呢？

這個我覺得倒是未必。

中臺的本質

經歷過了這大半年的實踐之后，我對中臺的本質最深的認知就是：中臺的本質是一種企業級能力復用的設計思維。

在企業業務發展的過程中，在滿足業務發展的系統建設過程中，每一個系統，每一個模塊的設計和打造，我們都要去思考：是否有做通用化的必要？或者在未來的業務場景里是否有通用性的訴求？

至于說是否需要都像阿里那樣，弄一個中臺部門出來，把各大核心模塊全部打造成一個中臺系統——我倒是覺得未必。

例如我們在做電商賣場貨品結構分析的時候：

在一開始的時候，我們只做了一個賣場，但是這個模塊在設計之初就有一個很重要的考量點：這個模塊后續能否為其他的賣場繼續提供貨品結構分析服務？以及這個服務直接復用之后是否能夠直接滿足其他業務線的需求？

又例如創業公司在打造自己的用戶中心的時候：

在業務的前期，可能只有一兩條業務線，而為了業務的快速擴展，在打造新產品線的時候，可能會為了求快而采取新的用戶系統。但是這些用戶系統設計的時候，都面臨同一個問題的挑戰：后續多個系統間的用戶體系如何才能更加高效低成本的融合？

所以說，中臺本質上就是一種企業級能力復用的設計思維。

也正因為這是一種思維方式，故而真沒必要給自己加那么多的條條框框，沒必要拘泥于市面上各種中臺的系統現狀和中臺應該長什么樣的定義：以快速支持業務擴張為目的，以企業級能力復用為設計思維——就可以了。

這就好比編程中的函數思維一樣，把一些通用的邏輯，封裝在一起，然后各方直接調用即可。

就像現在很多的算法，你要是刨根問底的解釋起來或者從零開始寫的話，那叫一個復雜；但是當前很多的算法調用對應到python的語句中，就是一行函數而已，各方調用同一個算法的時候都十分的方便——本質上，這也是一種復用的思維。

所以說，中臺落地后到底長什么樣？

這個真沒有定論。

這個要看你希望中臺化的業務形態：是業務線？還是技術實現？還是算法？又或者是AI能力？

除卻要看你的業務形態之外，也需要和你們企業當前的系統現狀做結合，進而再決定是中臺是通過底層技術模塊封裝，還是通過中間層，又或者是通過微服務，還是說通過Sass來對外提供服務。

若實在需要給中臺做一個形象的類比，我覺得各種云服務就是很好的類比對象。

例如阿里云中的各種能力，如：機器視覺、智能推薦、智能語音交互，其實就可以理解為某某中臺能力，阿里把這些通用的能力封裝成云服務，各個企業按需調用即可。

用的都是一樣的接口，一樣的服務，各個業務線再也不需要自己重新開發，直接拿來使用即可——而我們做中臺，不就是為了這個目的么：當業務線需要擴張的時候，直接拿來使用即可，大大降低實現時間成本，提高市場響應速度。

借此回應上一節留下的疑問：做中臺的企業，業務模式是否需要集中？

未必。

集中當然好，能夠抽象和共享的內容就更多了，業務擴展的時候，能夠復用的場景也很多。

就像suppercell在游戲領域，制作新游戲的時候，直接調用游戲引擎中臺即可；就像阿里在開拓聚劃算業務線的時候，直接拿原有的交易中心、商品中心等一系列中臺元件組裝即可。

但是，業務不集中的，例如騰訊，它的業務領域橫跨游戲、社交、視頻、內容等，你說他真沒法做中臺嗎？

肯定不是的，不然人家也沒必要成立技術委員會去干這個事兒了，例如用戶方面總可以收攏吧？游戲引擎可以抽象和共享吧？又或者說底層一些消息推送服務可以抽離吧？等等…

還是那句話——中臺是一種思維：企業級能力復用的設計思維。可以指導產品設計，可以指導技術設計，也可以指導AI能力設計。萬事結合自己實際情況來，沒必要拘泥于各項規則。

文章的最后，我們做最后的一次總結：

中臺不是必須的，也不是萬能的——支持業務發展才是永遠的王道。