要不要趕個時髦，去建設一個「 中臺 」？（轉）

不少技術人老是抱怨 新技術/新框架/新概念 太多了，老是學不完，抱怨實在是學不動了。哈哈，這不，最近「 中臺 」這麼火熱，要不要中止抱怨，再咬咬牙學一波？

「不少人都擔憂被技術新潮流所拋棄，因此當碰見不斷涌現的新技術時，老是慌忙的去學習。但是其中到底有多少是真正有用的？又有多少是曇花一現的技術呢？當你沒法分辨的時候，其實沒必要慌張，當一項新技術/概念剛出現的時候，你沒必要匆忙的去學習，更沒必要擔憂本身會錯過它，若是它是一個真正有價值的東西，是一個真正經受得住考驗得技術，它早晚會再次出如今你面前」

這是我很喜歡的一段話，對技術浪潮的見識太到位了。不過很慚愧，我不記得是哪位大神說的了。

回到「 中臺 」這個話題，其實中臺已經不算新潮流了，而且它仍是被不少企業成功驗證過的模式了。那麼，既然這麼靠譜，我們是否應該趕個時髦，搞一個？

在回答這個問題以前，我們先縷一縷啥是中臺吧。

中臺 這個理念在國內最先是由阿里巴巴帶起來的，後來國內一些互聯網大廠（滴滴、京東等）也開始在內部推行，加上今年騰訊在「全球數字生態大會」上再度提起中臺架構，引發了你們一波又一波的追捧。不過這個架構理念也不是由阿里巴巴提出的，而是馬雲帶着阿里團隊拜訪 Supercell 公司學習來的。Supercell 是芬蘭一家著名的移動遊戲公司 ，我說幾個他們開發的遊戲你們就能明白了這家不到兩百人的公司有多牛逼了，好比著名的《部落衝突》《卡通農場》《皇室戰爭》。

Supercell公司公司人員人少，採用的就是「小前臺」+「部落」的模式。就是有多個「前臺」小組，這些小組就是專門用來快速研發遊戲的，每一個小組雖然人員很少但它包含了開發一款遊戲所需的各類角色人員。這些「前臺」小組只關注在業務側，也就是遊戲業務研發和創新上。而對於遊戲的底層基礎設施：遊戲引擎、開發工具、服務器後臺等這些都東西，前臺小組不用去關心，這些基礎功能交由一個稱爲「部落」的組織獨立去負責。這種模式就像是戰鬥小組專門去負責打仗，後勤彈藥又由另外的小組去搞定，分工明確，業務也能快速試錯、快速創新。

根據此次拜訪學習，阿里巴巴隨後宣佈組織架構全面升級，啓動中臺戰略，構建「大中臺、小前臺」的組織機制和業務機制。

在201七、201八、2019年不少互聯網大廠都對外分享了本身的中臺實踐成果，包括阿里、騰訊、京東等都爲中颱戰略作出組織架構的調整。

在互聯網大廠的領頭、產業互聯網的風口，傳統企業的轉型契機下，「 中臺 」不火都不行啊。

對於中臺的瞭解，網上資料簡直多的不要不要的，但體系化的學習，我推薦看看雲徙科技的幾位大佬新出的**《中臺戰略》這本書，以及極客時間的《說透中臺》**專欄，這兩個資料算是對中臺介紹的比較全面的。本文的部分觀點也是吸收了這些內容後的收穫，建議找來一讀。

1、「 中臺 」究竟是什麼？

想了好久，想用一句簡潔清晰的語句給 中臺 下個定義，仍是有點難度（嗯，沒錯，仍是個人認知太淺了，哈哈）。

中臺 就是一個架構理念，它是介於前臺與後臺之間的（這句好像是廢話），它是但願將一些可複用的「能力」統一塊兒來，採用共享的方式去建設，用來解決各個業務團隊重複開發、數據分散、試錯成本高等問題，中臺的核心就是**「對能力的共享」、「對能力的複用」**，它應該是公司內部的統一協同平臺。

另外再給個參考，在《說透中臺》專欄中王健老師將中臺定義爲：

企業級的能力複用平臺

我以爲這個定義至關準確且簡潔。受不了我上面一大段囉嗦定義的同窗，能夠按照這個簡潔的定義去理解中臺。

上面講完了中臺的定義，咱們再來看看 前臺、中臺、後臺 的區別吧。

「前臺」是直接服務客戶、觸達用戶的平臺，可以洞察用戶需求，進行產品創新、提高用戶價值，保持精簡和足夠敏捷度的平臺。好比阿里的 淘寶、天貓、聚划算等。

「中臺」前面已經定義過了。它經過組件化的形式輸出通用能力，爲全部「前臺」的業務運營和創新，提供專業能力的共享平臺。中臺部門提煉各業務線的共性需求，將各類資源轉化爲方便「前臺」使用的能力，最大程度避免重複「造輪子」。

「後臺」的職能是提供基礎設施建設、服務支持，爲「前臺」和「中臺」提供基礎保障。後臺會比中臺更底層、更通用。「中臺」有的時候會更關注在某一行業/領域內的，而「後臺」應該是行業/領域通用的。

要注意的是，中臺並非專指技術，相反主流的中臺更側重於業務。

上面提到的 前臺、中臺、後臺 所有都是從用戶和職能角度出發的，不少開發同窗一聽先後臺就理解成了技術架構了，技術架構中的前端展現層、技術中間層、後端數據層，與這裏的前中後臺徹底不是一個概念。

阿里的中臺戰略是以業務中臺和數據中臺相結合，這也是目前市面上主流的中臺架構。

業務中臺是提供可複用的業務服務，包括如用戶中心、會員中心、訂單中心、支付中心等，既可拆箱即用，又可複用的業務能力。說白了，各個不一樣的業務線/業務部門其實有不少相似、共通的業務組件，你們就不要各自搞各自的了（傳說中的煙囪式、單體式項目架構），既浪費資源，也不利於協同。乾脆你們把這些共性的可複用的業務組件從前臺裏提煉出來，下沉到中臺，一塊兒建設一塊兒用，你好我好你們好。

數據中臺是基於技術和大數據能力爲業務提供可複用的數據服務，將業務中產生出來的數據進行二次加工，將加工的結果再服務於業務，爲業務賦能。但要注意的是，你們在理解上不能將數據中臺與傳統的數倉、大數據平臺劃等號。數據中臺與它們的區別是，數據中臺更貼近業務，數據中臺不僅關心技術層面，不僅提供分析功能，更多關心數據資產化、關心數據對業務的運用，爲業務提供服務。

業務中臺與數據中臺相輔相成、互相支撐。因此如今你們也很流行的說法就是：數據業務化、業務數據化嘛。

 

（圖片來源雲棲社區）

除此以外，在實際應用中，也衍生出了不少其它的中臺概念，如：移動中臺、算法中臺、技術中臺、研發中臺、運營中臺、組織中臺 等等。下面挑選幾個簡單解釋一下：

技術中臺：提供通用的技術設施能力、技術中間件能力，過濾掉技術細節，像各個前臺應用提供統一的易用的技術服務，避免重複造輪子（也有人認爲技術中臺不具有業務屬性，屬於技術中間件平臺，不能歸屬中臺）。

研發中臺：研發中臺是關注開發效率的平臺，將公司的開發流程、最佳實踐沉澱爲可重用的能力，爲應用的開發提供了流程、質量管控和持續交付的能力。

移動中臺：將移動APP開發中的通用技術、框架、業務組件等進行封裝，沉澱到移動中臺，提升移動開發組件的可複用性，方便快速構建新的APP開發（有些人對移動中臺的爭議與技術中臺相似）。

爲何會出現這麼多的讓人眼花繚亂的中臺呢？根本緣由是每一個人本身的職業不一樣，因此看待的角度不一樣，出發點不一樣，而且每一個公司的業務性質、形態也不相同。好比 電商團隊、AI團隊、運營團隊、研發團隊，他們眼中的中臺確定都是不同的，但初衷是同樣的：資源的複用。

另外，這裏還得再囉嗦一句：「平臺不是中臺」。什麼意思呢？

有的互聯網企業在對公司內的模塊進行定義和表述中，並不經常使用「後臺」的概念，反而用「平臺」比較多。好比 大數據平臺、運維自動化平臺、財務平臺等等。這些「平臺」與咱們今天描述的「中臺」並非一回事。平臺比中臺更底層一些，更基礎一些。平臺通常是不帶業務屬性的，而中臺，確必須是具有業務屬性的，由於中臺是直接爲前臺業務所服務的，是一個提煉業務能力共性的組織，在這一點上就與平臺區別的很明顯了。

2、咱們要不要去建設「 中臺 」？

「中臺」這麼火，大小企業都蠢蠢欲動，各類靠譜不靠譜的平臺都往中臺的概念上靠，要乾的勁頭擋不住啊。行吧，既然要幹，我們至少得先看看問題吧，把明顯不適合搞中臺的基本條件弄清楚嘛。

1. 公司得核心業務不成熟 或 公司業務線不多

   若是企業屬於創業公司，主業務模式都不明朗，這種狀況就真的不建議搞什麼中臺的。中臺是講究多業務服務用的，咱就一個業務，這個業務還在探索，搞啥子中臺嘛，把技術平臺搞好點就能夠了。

2. 公司裏沒有相相似的業務

   即便不是創業公司，是一箇中型甚至是大型公司了，但若是公司裏雖然業務多，可是每一個業務線作的領域都區別很大，好比業務線1作面向C端的電商，業務線2作遊戲，業務線3作面向B端企業級產品。這種狀況，很難沉澱共性的業務服務，也作不了中臺，仍是拉一個團隊繼續作基礎平臺給各個業務服務吧。

3. 公司沒有足夠的人力

   人力是硬指標，即便上面說的問題都沒有，徹底符合作中臺，那也得考慮考慮人員安排。畢竟中臺的建設是須要由獨立的團隊去完成，而且還應該是一個高效率的團隊（否則前臺業務會抱怨中臺響應不及時），公司是否有這部分的人力預算去建設中臺，人員從哪兒來，這個硬性條件必須提早考慮。

這篇文章闡述了 啥是中臺、要不要建中臺，但貌似缺一個「怎麼建中臺」了，這個之後聊。

另外，還有不少人擔憂「 中臺 」會不會是曇花一現的新概念，我以爲糾結這個徹底不必。當我們充分理解了中臺，學到了其中的理念以後，它是否是曇花一現並非很重要嘛。由於咱們已經得到了成長，得到了視野和思惟的提高，足以。您以爲呢？