很多技術人總是抱怨 新技術/新框架/新概念 太多了，總是學不完，抱怨實在是學不動了。哈哈，這不，最近「 中台 」這麼火熱，要不要停止抱怨，再咬咬牙學一波？
「很多人都擔心被技術新潮流所拋棄，所以當遇見不斷湧現的新技術時，總是慌忙的去學習。可是其中到底有多少是真正有用的？又有多少是曇花一現的技術呢？當你無法分辨的時候，其實不必慌張，當一項新技術/概念剛出現的時候，你不必匆忙的去學習，更不必擔心自己會錯過它，如果它是一個真正有價值的東西，是一個真正經受得住考驗得技術，它遲早會再次出現在你面前」
這是我很喜歡的一段話，對技術浪潮的見識太到位了。不過很慚愧，我不記得是哪位大神說的了。
回到「 中台 」這個話題，其實中台已經不算新潮流了，並且它還是被很多企業成功驗證過的模式了。那麼，既然這麼靠譜，咱們是否應該趕個時髦，搞一個？
在回答這個問題之前，咱們先縷一縷啥是中台吧。
中台 這個理念在國內最早是由阿里巴巴帶起來的，後來國內一些網際網路大廠（滴滴、京東等）也開始在內部推行，加上今年騰訊在「全球數字生態大會」上再度提起中台架構，引起了大家一波又一波的追捧。不過這個架構理念也不是由阿里巴巴提出的，而是馬雲帶著阿里團隊拜訪 Supercell 公司學習來的。Supercell 是芬蘭一家著名的移動遊戲公司 ，我說幾個他們開發的遊戲大家就能明白了這家不到兩百人的公司有多牛逼了，比如著名的《部落衝突》《卡通農場》《皇室戰爭》。
Supercell公司公司人員人少，採用的就是「小前台」+「部落」的模式。就是有多個「前台」小組，這些小組就是專門用來快速研發遊戲的，每個小組雖然人員不多但它包含了開發一款遊戲所需的各種角色人員。這些「前台」小組只關注在業務側，也就是遊戲業務研發和創新上。而對於遊戲的底層基礎設施：遊戲引擎、開發工具、伺服器後台等這些都東西，前台小組不用去關心，這些基礎功能交由一個稱為「部落」的組織獨立去負責。這種模式就像是戰鬥小組專門去負責打仗，後勤彈藥又由另外的小組去搞定，分工明確，業務也能快速試錯、快速創新。
根據這次拜訪學習，阿里巴巴隨後宣布組織架構全面升級，啟動中台戰略，構建「大中台、小前台」的組織機制和業務機制。
在2017、2018、2019年很多網際網路大廠都對外分享了自己的中台實踐成果，包括阿里、騰訊、京東等都為中台戰略做出組織架構的調整。
在網際網路大廠的領頭、產業網際網路的風口，傳統企業的轉型契機下，「 中台 」不火都不行啊。
對於中台的了解，網上資料簡直多的不要不要的，但體系化的學習，我推薦看看雲徙科技的幾位大佬新出的《中台戰略》這本書，以及極客時間的《說透中台》專欄，這兩個資料算是對中台介紹的比較全面的。本文的部分觀點也是吸取了這些內容後的收穫，建議找來一讀。
一、「 中台 」到底是什麼？
想了很久，想用一句簡潔清晰的語句給 中台 下個定義，還是有點難度（嗯，沒錯，還是我的認知太淺了，哈哈）。
中台 就是一個架構理念，它是介於前台與後台之間的（這句好像是廢話），它是希望將一些可復用的「能力」統一起來，採用共享的方式去建設，用來解決各個業務團隊重複開發、數據分散、試錯成本高等問題，中台的核心就是「對能力的共享」、「對能力的復用」，它應該是公司內部的統一協同平台。
另外再給個參考，在《說透中台》專欄中王健老師將中台定義為：
企業級的能力復用平台
我覺得這個定義相當準確且簡潔。受不了我上面一大段囉嗦定義的同學，可以按照這個簡潔的定義去理解中台。
上面講完了中台的定義，我們再來看看 前台、中台、後台 的區別吧。
「前台」是直接服務客戶、觸達用戶的平台，能夠洞察用戶需求，進行產品創新、提升用戶價值，保持精簡和足夠敏捷度的平台。比如阿里的 淘寶、天貓、聚划算等。
「中台」前面已經定義過了。它通過組件化的形式輸出通用能力，為所有「前台」的業務運營和創新，提供專業能力的共享平台。中台部門提煉各業務線的共性需求，將各種資源轉化為方便「前台」使用的能力，最大程度避免重複「造輪子」。
「後台」的職能是提供基礎設施建設、服務支持，為「前台」和「中台」提供基礎保障。後台會比中台更底層、更通用。「中台」有的時候會更關注在某一行業/領域內的，而「後台」應該是行業/領域通用的。
要注意的是，中台並不是專指技術，相反主流的中台更側重於業務。
上面提到的 前台、中台、後台 全部都是從用戶和職能角度出發的，很多開發同學一聽前後台就理解成了技術架構了，技術架構中的前端展示層、技術中間層、後端數據層，與這裡的前中後台完全不是一個概念。
阿里的中台戰略是以業務中台和數據中台相結合，這也是目前市面上主流的中台架構。
業務中台是提供可復用的業務服務，包括如用戶中心、會員中心、訂單中心、支付中心等，既可拆箱即用，又可復用的業務能力。說白了，各個不同的業務線/業務部門其實有很多類似、共通的業務組件，大家就不要各自搞各自的了（傳說中的煙囪式、單體式項目架構），既浪費資源，也不利於協同。乾脆大家把這些共性的可復用的業務組件從前台里提煉出來，下沉到中台，一起建設一起用，你好我好大家好。
數據中台是基於技術和大數據能力為業務提供可復用的數據服務，將業務中產生出來的數據進行二次加工，將加工的結果再服務於業務，為業務賦能。但要注意的是，大家在理解上不能將數據中台與傳統的數倉、大數據平台劃等號。數據中台與它們的區別是，數據中台更貼近業務，數據中台不只關心技術層面，不只提供分析功能，更多關心數據資產化、關心數據對業務的運用，為業務提供服務。
業務中台與數據中台相輔相成、互相支撐。所以現在大家也很流行的說法就是：數據業務化、業務數據化嘛。
（圖片來源雲棲社區）
除此之外，在實際應用中，也衍生出了很多其它的中台概念，如：移動中台、算法中台、技術中台、研發中台、運營中台、組織中台 等等。下面挑選幾個簡單解釋一下：
技術中台：提供通用的技術設施能力、技術中間件能力，過濾掉技術細節，像各個前台應用提供統一的易用的技術服務，避免重複造輪子（也有人認為技術中台不具備業務屬性，屬於技術中間件平台，不能歸屬中台）。
研發中台：研發中台是關注開發效率的平台，將公司的開發流程、最佳實踐沉澱為可重用的能力，為應用的開發提供了流程、質量管控和持續交付的能力。
移動中台：將移動APP開發中的通用技術、框架、業務組件等進行封裝，沉澱到移動中台，提高移動開發組件的可復用性，方便快速構建新的APP開發（有些人對移動中台的爭議與技術中台類似）。
為什麼會出現這麼多的讓人眼花繚亂的中台呢？根本原因是每個人自己的職業不同，所以看待的角度不同，出發點不同，並且每個公司的業務性質、形態也不相同。比如 電商團隊、AI團隊、運營團隊、研發團隊，他們眼中的中台肯定都是不一樣的，但初衷是一樣的：資源的復用。
另外，這裡還得再囉嗦一句：「平台不是中台」。什麼意思呢？
有的網際網路企業在對公司內的模塊進行定義和表述中，並不常用「後台」的概念，反而用「平台」比較多。比如 大數據平台、運維自動化平台、財務平台等等。這些「平台」與我們今天描述的「中台」並不是一回事。平台比中台更底層一些，更基礎一些。平台一般是不帶業務屬性的，而中台，確必須是具備業務屬性的，因為中台是直接為前台業務所服務的，是一個提煉業務能力共性的組織，在這一點上就與平台區別的很明顯了。
二、我們要不要去建設「 中台 」？
「中台」這麼火，大小企業都蠢蠢欲動，各種靠譜不靠譜的平台都往中台的概念上靠，要乾的勁頭擋不住啊。行吧，既然要干，咱們至少得先看看問題吧，把明顯不適合搞中台的基本條件弄清楚嘛。
- 公司得核心業務不成熟 或 公司業務線很少
- 如果企業屬於創業公司，主業務模式都不明朗，這種情況就真的不建議搞什麼中台的。中台是講究多業務服務用的，咱就一個業務，這個業務還在探索，搞啥子中台嘛，把技術平台搞好點就可以了。
- 公司里沒有相類似的業務
- 即使不是創業公司，是一個中型甚至是大型公司了，但如果公司里雖然業務多，但是每個業務線做的領域都區別很大，比如業務線1做面向C端的電商，業務線2做遊戲，業務線3做面向B端企業級產品。這種情況，很難沉澱共性的業務服務，也做不了中台，還是拉一個團隊繼續做基礎平台給各個業務服務吧。
- 公司沒有足夠的人力
- 人力是硬指標，即使上面說的問題都沒有，完全符合做中台，那也得考慮考慮人員安排。畢竟中台的建設是需要由獨立的團隊去完成，並且還應該是一個高效率的團隊（不然前台業務會抱怨中台響應不及時），公司是否有這部分的人力預算去建設中台，人員從哪兒來，這個硬性條件必須提前考慮。
這篇文章闡述了 啥是中台、要不要建中台，但貌似缺一個「怎麼建中台」了，這個以後聊。
另外，還有很多人擔心「 中台 」會不會是曇花一現的新概念，我覺得糾結這個完全沒必要。當咱們充分理解了中台，學到了其中的理念之後，它是不是曇花一現並不是很重要嘛。因為我們已經獲得了成長，獲得了視野和思維的提升，足以。您覺得呢？