"中臺"這個概念火了一年多，很多公司都進行了實踐，關於中臺的文章，也真的是百家爭鳴，筆者在閱讀了一些資料後，按照一些偉大公司"黃金圓環"的why→how→what順序，將所閱讀的信息整理成本篇，算是在百家爭鳴中響應一家。本文適用於初期概念導入，更多操作類、實踐類 敬請期待下一篇。本文很乾貨，建議收藏後慢慢讀。

本文約8000字，重點圖片9張，預計閱讀時間為30分鐘，建議多次閱讀。

本文·導讀·目錄

1 為什麼要平臺化？為什麼要建中臺？（why）

2 如何建立中臺？（how）

3 中臺是什麼（what）

4 總結

Part 1 為什麼要平臺化？為什麼要建中臺？（why）

1.1企業為什麼要平臺化？

先說答案：

因為互聯網時代流量為王，⽤戶才是商業戰場的中心，為了快速響應用戶的需求，藉助平臺化的力量可以事半功倍。

不斷快速響應、探索、挖掘、引領⽤戶的需求，才是企業得以⽣存和持續發展的關鍵因素。那些真正尊重用戶，甚至不惜調整⾃己顛覆⾃己來響應⽤戶的企業將在這場以⽤戶為中心的商業戰爭中得以⽣存和發展；⽽反之，那些在過去的成就上故步⾃封，存在僥倖⼼理希望⽤戶會像之前一樣繼續追隨⾃己的企業則會被用戶淘汰。

很殘酷，但這就是這個時代最基本的企業生存法則。

《數字化企業》

⽽平臺化之所以重要，就是因為它賦予或加強了企業在以用戶為中心的現代商業戰爭中最最最核心的能力：⽤戶響應力。這種能力可以幫助企業在商戰上先發制⼈，始終搶得先機。

在互聯網時代，商業的鬥爭就是對於用戶響應力的比拼。

下面舉2個經典例子：

1. 阿里中臺

《企業IT架構轉型之道》

最先想到的應該就屬是阿⾥的"⼤中臺，⼩前臺"戰略：阿⾥⼈通過多年不懈的努力，在業務的不斷催化滋養下，將自己的技術和業務能力沉澱出一套綜合能力平臺，具備了對於前臺業務變化及創新的快速響應能力。

2. 海爾中臺

海爾於2005年啟動了"人單合一"管理模式改革，海爾最大化地釋放了每名員工的工作活力，企業則轉化為員工"自我創業"的平臺，打造"平臺型組織"，並致力於構建"全球商業生態系統"，與顧客變交易關係為交互關係，開放式創新，共同謀求發展與進步，互惠互利，實地踐行"無邊界企業"原則。

可見在互聯網熱火朝天、第四次工業革命的曙光即將到來的今日，企業能否真正做到"以用戶為中心"，並不斷提升自己的用戶響應力來追隨甚至引領用戶的腳步，持續規模化創新，終將決定企業能否在這樣充滿挑戰和機遇的市場上笑到最後，在商業上長久保持創新活力與競爭力。而平臺化恰好可以助力企業更快更好的做到這些，所以企業需要平臺化。

《數字平臺戰略》

1.2企業為什麼要建中臺？

平臺化並不是一個新概念，那為什麼最近幾年"中臺"這個相對較新的概念又會異軍突起？對於企業來講，傳統的"前臺+後臺"的平臺化架構又為什麼不能滿足企業的要求呢?

同樣我先給出答案：

為了更快的響應市場，打贏戰爭！"消除煙囪"、"架構解耦"、"統一中臺"、"服務重用"都是為了能夠快速的賦能業務進行落地實施、改造、試錯、轉型，企業降本提效的手段。

眾所周知，阿里拜訪芬蘭的遊戲公司Supercell後提出中臺戰略的。這個公司是典型的小團隊運作方式，每個獨立團隊不超過7人（典型的Scrum團隊規模），稱之為Cell（細胞）。團隊自己決定做什麼樣的產品（自組織的團隊），以最快的速度開發出公測版，獲取用戶反饋（精益創業的模式），如果用戶不歡迎，迅速放棄這個產品（fail fast, fail cheap）。團隊失敗時沒有懲罰和悲傷，反而會慶祝從失敗中學到了東西（容忍失敗的文化很重要）。這個模式使得Supercell成為年稅前利潤15億美元的遊戲公司。這個公司有多少人呢？不超過200人。這個公司開發過哪些遊戲？有《部落戰爭》《海島奇兵》《卡通農場》等。為什麼Supercell能按這種模式運作？是因為它構建的"中臺"能力，包括多年積累的非常科學的研發方法和體系。

這種強大的業務試錯能力是Supercell相比於其他遊戲公司最大的差別，也是最核心的競爭力。

而大部分企業IT建設都是"煙囪式"，都是基於業務需求建設系統，無法承受業務爆發式增長和業務創新的重擔，具有典型的三大弊端：

1. 重複功能建設和維護帶來的重複投資，造成成本和資源浪費。
2. 打通"煙囪式"系統間交互的集成和協作成本高昂。實施SOA項目，構建企業服務產品線，基於服務的方式來解決交互問題，其中牽涉大量的協同和開發成本 。
3. 不利於業務的沉澱和持續發展。ESB是解決不同系統間互聯互通的好架構，但各個系統自頂向下的建設模式，導致了新的業務發現有服務不能很好地滿足需要後，原服務方可能不想改造服務，或改造可能對原有業務帶來極大風險，導致新業務方不得不再造一個煙囪。

煙囪方式建設的系統體系，導致企業中一個業務領域的數據和業務往往被打散在不同的系統中，採用系統打通的方式解決了眼前的業務交互問題，但治標不治本。

隨著企業業務的發展壯大，重複造輪子的同時還會致使各個系統不斷膨脹，變得臃腫，形成了一個個大泥球的"煙囪式單體應用"，漸漸拖垮了"⽤戶響應⼒"，用戶滿意度降低，企業競爭力也隨之不斷下降。以淘寶單一系統模式為例，就有以下弊端：

• 1. 團隊協同成本高，上線前分支合併，各種包衝突，代碼衝突，需要各團隊間進行確認和協調；
• 2. 應用複雜度已超出人的認知負載，各種業務錯綜複雜，牽一髮而動全身；
• 3. 錯誤難於隔離：所有代碼運行在同一個環境中（JVM），任何一個小功能或非核心功能可能引起整個業務受影響；
• 4. 數據庫連接能力很難擴展，數據庫集群的連接數量有限，隨著應用實例數量增加，越來越不夠用。平臺也因為過高的數據庫連接而處於一個非常不穩定的狀態；
• 5. 應用擴展成本高。通常系統出現業務處理瓶頸時，只是由於一個或幾個功能模塊負載較高，但因為所有功能打包在一起，沒法對單獨的幾個功能模塊進行服務能力擴展，只能將整個應用進行擴容，帶來了資源額外配置的消耗。
• 6. 所有服務都通過服務總線，服務總線的訪問和計算壓力都很大。一般企業服務產品線包含的功能非常多，如服務發現、註冊、路由等，對服務器的要求較高，所以每次擴容升級都會帶來在軟件授權和硬件資源上的不小投入。另外，服務總線的調用量比較大，網絡帶寬要求可能會超過目前網絡設備的能力範圍，成本高。

中臺就是在VUCA時代幫助企業在開展數字化工作，幫助企業贏得戰爭的指揮官體系。

環球易購CTO-喬新亮《什麼是中臺，為什麼需要中臺》

指揮官體系的核心能力包含兩點：

1. 由用戶體驗驅動內部運營管理不斷完善。

在這種指揮官體系的管理下，企業會越來越體現出這兩個特點：協同、進化。IT部門的職責是要助力企業從關注內部經營管理轉向關注外部用戶體驗。這個指揮官體系的核心是用戶體驗驅動，用戶為大。什麼叫用戶為大？什麼叫用戶體驗驅動？舉個例子：假設一個做零售的企業，它經常沒貨，那這個問題應該誰去處理？客服，因為客服是最需要直接面對用戶回答這個無貨的問題的角色，也是安撫用戶的第一人。但是客服的工作不能僅此而已，他還需要做什麼？他需要來找採銷的麻煩，要求採銷補貨，不行就處罰，這個無貨的後果不能讓用戶承擔，客服必須要有反饋用戶體驗的權利。另外，上述例子中無貨的用戶體驗，必須要有數據記錄，數據孕育革新是基礎。要構建用戶為大、數據驅動的體系，用戶為大不是企業裡各個BU的負責人為大，各個BU做不好，BU的老大就要被幹掉，這樣的體系才能讓讓企業越來越好。

2. 由數據驅動內部運營管理不斷完善。

互聯網時代，無數據不決策，無數據不運營。作為指揮官體系的決策中樞和企業高管，時時刻刻都需要用數據說話，數據化運營增加營收，增效降本。洞察用戶畫像，深諳用戶偏好，用數據驅動來指揮經營決策，莫做"三拍"領導。在認識到數據的重要性的時候，莫忘數據完整性、可用性和閉環，否則徒勞。

所以，企業在平臺化的過程中，要結合自身企業實際情況思考，建設自己的中臺層（同時包括技術中臺，業務中臺和組織中臺等）。

Part 2 如何建立中臺？（how）

每個企業都應該通過理解業務優先級、技術形態、成熟度以及正在進行的項目，為自身定製數字平臺戰略的目標和實施路徑，不可盲目模仿。數字化建設並非一步到位，企業需要根據自己的現實情況與數字化目標，建立自己的數字平臺戰略，穩步提升能力。數字平臺給企業帶來了顯著的收益：

《數字平臺戰略》

2.1可行性分析

中臺的建設不是那麼件輕鬆的事情。中臺戰略的推進過程一定是自頂向下的，至少是 CIO/CTO 層面向下推動，一定需要得到高層的支持。不然中臺團隊最初的處境可能會如阿里的"共享業務事業部"一樣，不被相關事業部接受，讓中臺團隊的處境十分艱難。建議先評估自己是否適合建中臺，從下面幾個方面判斷與評估：

A.明確並統一各相關方建設中臺的目標與意義

畢竟企業在建設中臺之前如果不統一人員認知的話，必然在中臺的建設過程中就會四面碰壁，各種扯皮、推諉，面臨多方面的阻礙，陷入一個被動的局面。需要做好兩個方面：一方面，是職責邊界的劃分問題，需要明確知道那些東西該中臺來做，那些不該中臺來做，需要業務部門自己去做；另一方面，更多的是涉及溝通的藝術和做事情的方式方法。

B.是否具備建設中臺的條件與時機

1）戰略分析

企業需要從公司整體的戰略佈局、核心競爭力、戰術方法、業務方向等維度來，明確知道自己的優劣勢綜合判斷，現階段做與不做中臺對於企業未來發展的利弊都有哪些，對於未來業務影響到底有多大。從而進一步明確企業建立中臺的目標是真的想賦能業務，做到真正的降本增效，實踐用戶至上，還只是單純的想對外秀肌肉。

2）業務調研

只有深入業務，明確業務單元后，梳理出業務價值鏈條後，拆解各個業務系統的情況，才能評估出業務是否有值得中臺化的場景。

同時，也能明白通過組件化、模塊化、標準化、解耦等方式來拆分系統和業務，再基於數據服務化的方式，就真的能快速支撐前臺業務的迭代更新，從而不斷的沉澱能力，做到服務和體驗都統一升級嗎？

3）數據調研

基於業務統計出數據來源，確定數據資源分類，做好數據評估，確定當前數據容量，結合業務運行頻度，數據產生效率，預測數據成長規模。

因為，建設中臺是在全域級數據彙集之後，做數據清洗、數據治理、數據資產管理等工作之前。所以，需要對數據使用情況進行盤點，為後續中臺建設過程中數據流動和使用機制提供有力依據。

4）技術調研

通過技術現狀調研，可以提前瞭解技術落地情況、人員技術情況，做好建設中臺的技術人員準備，提前規避風險。

5）組織分析

通過高層訪談、組織架構分析，明確企業中臺的目標與意義，同時調研分析各個事業部對建設中臺的看法，為後續中臺的溝通落地、推廣做好前期準備。

2.2規劃和實施

首先要建立"中臺"配套的相關管理機制，其次是建立應用架構，從相對容易的基礎共享服務開始，到定製與業務貼合的業務中臺。在建立中臺的過程中，需要配套中臺運行的後臺基礎架構。中臺的建設可以總結為五步走。

知乎@朱海根《"中臺"到底是什麼？》

A.建立合理的管理機制: 中臺的建立，切忌做成項目制，中臺需要使用產品管理的方式來對待。這是因為中颱對外提供的服務需要不停的迭代，適應業務的需求，否則經過一段時間，前臺因為中颱提供的服務固化，只好自己新建一個服務來滿足業務需求，逐漸不使用中臺提供的公共服務。對於中臺產品來說，必須思考的問題是，這個功能在現在或者將來能滿足多少業務場景？如果將來有新的業務出現，是不是能夠複用？或者說，需要做多大的調整才可以複用？甚至於，這個功能有沒有可能對外輸出，提供SaaS化的服務。

B.搭建適合企業的應用架構: 企業和阿里巴巴不同，阿里巴巴基本上都是C端應用，電商、文娛、消費。業務系統都是自己開發。企業則歷史包袱重，自主開發能力不強，既有購買的商品化軟件，又有自行開發的系統。比如，製造企業既有後端的SAP ERP，PLM，MES，WMS等系統，這些年又產生了面向外部的電商，客戶服務，營銷服務等前端系統。前端系統由於市場需要變化快，要求系統迭代速度以周甚至天計算，而後臺的傳統應用，變更和迭代通常以月甚至年來計算。

C.提供基礎共享服務: 基礎共享服務是面向技術層面的基礎公共共享服務，因為大部分服務就是集成功能，因此也可以稱為"集成中臺"。大致有如下的共享公共服務：

知乎@朱海根《"中臺"到底是什麼？》

D.數據中臺 進入到數據時代（DT），數據的重要性越來越被企業認知。對數據的收集，分析計算，深度學習，並轉讓為企業的核心競爭力。

知乎@朱海根《"中臺"到底是什麼？》

5.業務中臺 業務中臺每一個企業都是不同的，它是高度個性化的，無法通過直接購買獲得，因為它與業務密切相關。業務中臺需要長期的沉澱，抽象和歸納。打造一個業務中臺絕不是一朝一夕的事情。

Part 3 中臺是什麼（what）

3.1企業級能力複用平臺

中臺本身就是一個比較抽象的概念，很多時候我們被那個"中"字困住了，整天在前與中、中與後的具體差別和評判標準上糾結不已。但是，就像「看板」不是"我們看到的那個板子"一樣，「中臺」也不一定就是代表"處於中間平臺"，這兩個字作為一個整體，代表了一種新的思維和理念。

那這種新的思維和理念到底是什麼呢？是否能夠給「中臺」這個相對抽象的概念找到一個清晰的定義。因為只有通過定義才能讓抽象的概念清晰化，從而明確邊界、體現價值。

中臺就是「企業級能力複用平臺」

一直以來，中臺有各種各樣的定義曾浮現出來，但至少到目前為止，只有這個定義是我覺得最貼切、最簡單、也最準確的，它能解釋幾乎所有我碰到的關於中臺的問題，例如：

• · 為什麼會有那麼多中臺，像上文提到業務中臺、數據中臺、搜索中臺、移動中臺，哪些才是中臺，哪些是蹭熱點的？
• · 中臺與前臺的劃分原則是什麼？
• · 中臺化與平臺化的區別是什麼？
• · 中臺化和服務化的區別是什麼？
• · 中臺該怎麼建設？
• · 等等……

這9個字看起來簡單，重要的是其背後對「中臺」價值的闡釋：

• · 「企業級」定義了中臺的範圍，區分開了單系統的服務化與微服務；
• · 「能力」定義了中臺的主要承載對象，能力的抽象解釋了各種各樣中臺的存在；
• · 「複用」定義了中臺的核心價值，傳統的平臺化對於易複用性並沒有給予足夠的關注，中臺的提出和興起，讓人們通過可複用性將目光更多的從平臺內部轉換到平臺對於前臺業務的支撐上；
• · 「平臺」定義了中臺的主要形式，區別於傳統的應用系統拼湊的方式，通過對於更細粒度能力的識別與平臺化沉澱，實現企業能力的柔性複用，對於前臺業務更好的支撐。

3.2 Platform as a Product

但是接觸的中臺場景越多，就越發現其實每家企業建設中臺的目的可能都是不一樣的，大面上就能分成：內部研發效能提升、資源整合、新零售、全週期、全渠道、開放銀行、多品牌戰略、全球化戰略、產業互聯、構建商業生態等等等等。

當我們真正下定決心，捋起袖子加油幹，嘗試真正去推動中臺落地的時候，才發現原來通往美好遠方的是條佈滿荊棘之路：

• · 中臺的建設經費從哪裡來？中臺團隊的人從哪裡來？誰應該為中颱的建設買單？
• · 中臺的建設效果如何來體現？誰來驗收誰來評價？
• · 我們說中臺是企業級，要支撐多個前臺團隊，那四面八方的需求湧進來，會不會出現擁堵和排期？如何處理排序需求？
• · 如果不同的前臺團隊的需求出現矛盾和衝突，中臺如何處理？都是金主，以誰為主？
• · 前臺與中臺的職責怎麼劃分？
• · 前臺不配合中臺團隊怎麼辦？
• · 前臺提的需求不合理怎麼辦？
• · ……

問：那，如何破？

答：給中臺一個邊界，產品的邊界，將中臺團隊從共享職能團隊轉變為中颱產品團隊，將前臺與中臺的關係由被服務與服務的關係變為產品與產品的關係 ，即：Platform as a Product！

ThoughtWorks首席諮詢師-王健《白話中臺系列》

有意思的是，在思考這些問題的同時，回頭再去看看這幾年一直關注的阿里中臺，才意識到答案其實一直就在那裡。阿里巴巴早已將自身的中臺能力，通過產品化包裝整合到了阿里雲上，對外輸出，無論是承載了技術中臺能力的Aliware，還是承載著數據中臺能力的Dataphin，還是承載著研發效能能力的雲效。再去看各大互聯網巨頭，亦是如此，早已將眼光放到了更寬闊的企業外部，放到了整個社會，放到了各個行業，通過中臺能力的產品化包裝和輸出，開始打造各自的生態系統了。

Part 4 總結

·基於企業的使命與願景，結合當前的商業形勢，制定匹配的公司戰略，並基於戰略迅速調整組織進行戰略落地。 再根據康威定律，通過組織的變化引導IT架構的演進，所以中臺的誕生只是企業戰略層面上，在企業發展某個階段強調加強組織橫向協同性的一箇中間產物而已。

·天下大事分久必合合久必分。戰略在不斷調整，組織就會不斷調整，IT架構就會不斷調整。凡事沒有完美，沒有完美的戰略，沒有完美的組織，也自然沒有完美的IT架構，都是在持續地演進中。所以要將關注點從試圖找到完美的解決方案轉換到提升調整能力上來，這點無論是對於戰略、組織還是IT架構都是適用的。

·以用戶為中心的持續規模化創新，是中臺建設的核心目標。企業的業務響應能⼒和規模化創新能力，是互聯⽹時代企業綜合競爭⼒的核⼼體現。平臺化包括中臺化只是幫助企業達到這個目標的⼿段，並不是⽬標本身。

·中臺(⽆論是技術中臺、業務中臺還是組織中臺)的建設根本上是為了解決企業響應⼒困境，彌補創新驅動快速變化的業務和穩定可靠驅動變化週期相對較慢的單系統之間的⽭盾，提供⼀箇中間層來適配的配速問題，沉澱能⼒，打通並順滑鏈接前臺需求與後臺資源，幫助企業不斷提升用戶響應⼒。

·聚焦到中臺建設的過程中，引入產品化的思路則可以讓我們換個視角更好的思考中臺的邊界和責任，思考其核心的建設價值，更好的解決中臺建設過程中出現的各種矛盾與問題。

·同時可以將中臺切成更小的產品單元，引入類似於組織中臺這樣的內部孵化投資管理組織，對於中臺產品群進行產品化市場運作。這樣的好處還在於可以通過投資方向的調整來引導內部IT架構的演進，加速企業的戰略調整落地。

·使用產品化的思路來建設中臺，還有一個巨大的好處：因為中颱作為一個產品，除了產品形式（可能就是API）和用戶（內部前臺團隊）外，其他方面和其他產品沒有什麼不同。這就意味著在產品構建上我們過去已經積累了的大量成熟的方法和工具，都可以平移應用到中臺的建設上來！

漫漫中臺路，才剛剛開始，期待下一篇更深入的探討實操問題吧！例如"中臺每個階段的效果如何來驗證？OKR如何定？團隊人員如何選拔？知名企業的中臺長啥樣？…."

1. 中臺概念

· 對話阿里雲總裁行癲：最詳解密阿里雲頂層設計和底層邏輯

· 湖畔大學阿里 CEO 張勇：找人的核心，就看 2 點

· 什麼是中臺，什麼不是中臺。所有的中臺都是業務中臺

· 到底啥是平臺，到底啥是中臺？李鬼太多，不得不說

· 平臺戰略 == 中臺戰略？

· 在構建數據中臺之前，你需要知道的幾個趨勢

· 火熱的數據中臺對企業的價值是什麼？

· 你真地需要一箇中臺……嗎？| 商業洞見

· 阿里的中臺戰略其實是個偽命題 （從企業架構看中臺）

· 從海爾模式看數字化平臺 | 透明思考

· 湖畔大學，一所別樣的大學

· 《中臺戰略》

2. 中臺與組織

· 白話中臺戰略 -4：Platform as a Product(組織篇)

· 中臺禁區：為什麼最關鍵的組織架構卻鮮少人談？

· 《釋放潛能：平臺型組織的進化路線圖》 – 穆勝

· 《重塑海爾：可複製的組織進化路徑) – 穆勝

· 構建網狀組織架構 – 讀《賦能》 – 為程序員服務

· 企業IT的經營模式及其與企業架構師的關係 | 透明思考

· 小米、海爾、華為、阿里巴巴的阿米巴運營

· 馬雲的阿里和盛稻和夫的阿米巴

· 稻盛和夫“阿米巴經營”和海爾張瑞敏“自主經營體”的兩同三異

· 《企業IT架構轉型之道》

3. 建設經驗

· 從平臺到中臺 | Elasticsearch 在螞蟻金服的實踐經驗（平臺與中臺）

· 滴滴出行構建業務中臺應對軟件複雜度的具體對策與實踐

· 七問七答，親歷者講阿里中臺落地的實踐

· 我的一年中臺實戰錄 （網易教育中臺實戰錄）

· 跳開 DDD 和中臺概念看阿里巴巴交易平臺的問題及解決思路

· 阿里玄難：面向不確定性的軟件設計幾點思考

· 不要做中臺！不要做！不要……要 （中臺人員能力模型）

· 企業核心業務數字化轉型最佳實踐

· 數字化轉型 移動化先行 雲棲大會上發佈了哪些移動研發新利器？

· 《阿里技術手冊-研發篇》

· 《數據中臺》

4. 方法論相關

· 談談企業的規模化創新

· 以願景與目標驅動，讓創新無處不在（精益價值樹）

· 當用戶不是客戶，需求價值怎麼定？| 商業洞見（用戶與客戶）

· 架構設計實踐思路：什麼是架構，怎麼畫架構圖？（企業架構展開解釋）

· Microservices Guide （微服務）

· EventStorming （事件風暴）

· 《Pace-Layered Application Strategy》

閱讀更多 陳誠的智能製造隨筆 的文章

關鍵字: 美好，一直在身邊 跳槽那些事 海爾集團