在產業網際網路火爆的當下，在BATJ等網際網路大廠大肆推廣中臺建設成果的當下，各個行業的企業似乎都想做數字化轉型，建設業務中臺，但是中臺到底是啥，需要我們提前瞭解和學習，本文就是我的學習總結，希望能對你初步的理解中臺這個概念有所幫助。

一、學習背景

　　2019年夏，領導（我司CIO）送了我一本鍾華老師的《企業IT架構轉型之道：阿里巴巴中臺戰略思想》（該書的讀書筆記），閱讀之後初步地瞭解所謂的中臺戰略，但又還是停留在感性層次，只會說出幾次消除煙囪，資料孤島之類的感性的“大話”。而後在2019年冬季又訂閱了極客時間王健老師的《說透中臺》專欄想要進行深入學習加以更好地理解，於是有了你看到的這篇的學習總結文章。

　　在這篇文章裡，我將我在這個專欄和其他書籍中的內容加以整理，也從眾多參考資料中copy了很多圖示加以其中，最後給出我繪製的整體的知識總結腦圖。不過我決定不按套路來寫本文，先給出學習總結中最最精華的部分，給那些只想快速瞭解中臺的人。但是中臺這個東西，現在業界並沒有一個完整的標準定義，每個人的經驗和視角也不同，因此可能一百個學習者心中會有一百個中臺，這裡我主要引用我學習的專欄中內容的總結：

　　（1）中臺是什麼？

　　企業級能力複用平臺！

　　（2）如何構建中臺？

　　一句話概括：“以使用者為中心，從戰略入手，願景為指引，用科學有效的方法，步步為營沉澱企業級能力，輔以必要的組織與系統架構調整，方得中臺。”

　　（3）中臺的價值是啥？

　　中臺為前臺而生，專注於為前臺賦能，沉澱企業的能力與複用，提升企業的客戶響應力。

　　（4）我應該關注什麼才能成為合格的中臺參與者？

　　如果你是企業的CIO/CTO，資訊部總監，那麼你可能需要更多關注與企業架構方法（如TOGAF）、組織架構、事件風暴、願景規劃等等，因為你要做是中臺最基本的工作：數字化全景規劃；

　　如果你是架構師，那麼你可能需要更多關注中臺團隊能力建設、DDD工作坊、精益產品研發流程、敏捷開發流程等等；

　　如果你是開發者，那麼你需要更多關注微服務架構風格、DDD領域驅動設計、DevOps、敏捷開發等等；

　　（5）建設中臺需要學習哪些技術？

　　中臺是一個偏業務層面的概念，技術上並沒有帶來什麼新的東西。其實，只要你瞭解微服務、DDD、DevOps、敏捷開發等就足以做一個合格的中臺開發者了。當然，做中臺不一定就需要微服務架構，而別人使用微服務架構可能也不一定建設的是中臺。

　　OK，到此為止，以上五個問題就是我學習的資料裡面的精華內容了，如果你覺得不夠，那麼請繼續往下看。先劇透一下，由於中臺是個偏業務層面的概念，因此想要了解具體實現技術的童鞋，走錯片場了，可以離場了，本學習總結Cover不到你的需求。

二、中臺的發展歷程

　　瞭解一個東西，需要首先了解它的發展史，又或者說看看它的過去，這裡我們就先看看中臺的發展歷程：

• 2008~2015：孕育期
  • 2008年阿里巴巴開始戰略調整，重複建設與煙囪架構問題出現
  • 阿里共享事業部誕生，前臺系統中的公共部分開始平臺化改造
• 2015：中臺戰略誕生
  • 馬雲帶領阿里高官走訪芬蘭遊戲公司Supercell受到觸動
  • 阿里巴巴正式啟動中臺戰略“大中臺、小前臺”
• 2017：橫空出世
  • 網際網路大廠集體發聲，各自分享中臺建設經驗
• 2018：全面爆發
  • 網際網路大廠集體宣佈組織架構調整，正式將中臺推上舞臺
• 2019：迷霧仍存
  • 中臺的熱度越發高漲，跟進企業越來越多，但問題不降反增

　　不管是身處浪潮一線的網際網路大廠，還是傳統行業的轉型企業，似乎在2020年都有建設一箇中臺的需求（至少都在採取行動或開始學習），不管真的想進行能力沉澱複用 還是 追概念來個彎道超車，中臺正在被越來越多的人熟知。

網際網路大廠的集體吹牛逼

三、中臺的核心概念

3.1 中臺為何會火爆？

　　（1）網際網路大廠的樣板效應

　　不得不說，BAT等大廠的樣板和標杆效應非常強！先行者們的建設效果讓人羨慕不已！

　　（2）網際網路大廠一致地推動

　　消費網際網路進入中後期，產業網際網路開始火爆！而云和中臺是網際網路企業進入傳統行業的非常好的切入點。這些網際網路企業依靠自身儲備幫助傳統企業數字化轉型，而在傳統企業的轉型過程中，中臺是很好的抓手和利器！

　　（3）傳統行業數字化轉型的需要

　　剛好這幾年匹配上傳統行業從系統化向平臺化轉型的時間節點，企業資訊化的問題凸顯，如煙囪林立、資料孤島等等；似乎家家企業都覺得有做中臺的需求和痛點，並開始了中臺規劃和建設。

　　（4）整體經濟形勢對企業要求更高

　　近年來，不確定性和不可預測性不斷衝擊各個行業的企業，企業的高層管理者們焦慮倍增。在看到網際網路大廠的樣板效應之後，想要模仿也將自身企業的能力進行沉澱與複用，用確定性應對不確定性（這裡所謂的確定性，我的理解就是基於核心能力的複用，在面對業務擴張或轉型時，不會慌得一批，因為你知道你可以很快的複用已有能力去開拓新業務並實現轉型而不是從零開始，或許你可以認為你企業的使用者響應時間是可以確定的），這對傳統企業來說的確是一個突圍方向！

衝突：市場的無序與企業的有序

3.2 企業為何要建中臺？

　　（1）區分前臺和後臺

　　這裡的前臺是由各類前臺系統組成的前端業務平臺，例如官網、公眾號、小程式、H5客戶端等；而後臺是由後臺系統組成的後端支撐平臺，例如ERP、CRM、WMS等核心系統。

　　（2）後臺的響應速度慢且貴

　　經歷過企業級專案開發的人都知道，大型企業的後臺是所謂的企業“遺留系統”的重災區。前臺需要快速響應前端使用者的需求，要求越快越好，但是後臺是相對穩定的企業核心後端資源，陳舊而複雜，因此出現了“前臺+後臺”的“齒輪失衡”問題凸顯！

衝突：前臺需要快速響應，後臺則改動成本極大

　　（3）平臺化：提升使用者響應力

　　在網際網路時代，使用者才是商業戰場的中心，網際網路公司們紛紛藉助平臺化，以實現快速響應使用者的需求。無論各行各業，企業的核心能力都是：使用者響應力！因此，傳統企業也需要進行平臺化轉型。這裡的平臺化，主要側重於IT能力的去重，屬於Cost Saving（降低成本）的策略。

演進：系統化，中心化，平臺化

　　（4）中臺化：平臺化的下一站

　　在平臺化的過程中，平臺不斷對於自身治理演進、逐漸擁抱業務的過程就是中臺化的過程，大家會發現需要一箇中臺，這個中臺主要關注為前臺業務賦能，要真正為前臺而生，實現Value Add（放大價值），Cost Saving + Value Add即我們通常所說的降本增效。例如，阿里巴巴的業務中臺其實就是由阿里早先的交易平臺演進而來，最終實現業務能力的靈活複用，所以這裡才說中臺化是平臺化的下一步。

3.3 中臺的價值何在？

　　剛剛說到，中臺出現的背景主要就在於：“前臺+後臺”的“齒輪失衡”問題凸顯。因此，中臺其實就是架在前臺與後臺之間的一組“變速齒輪”，起到的作用類似於橋樑及潤滑劑，其價值主要在於：將後臺資源順滑通過前臺流向使用者，提高企業使用者響應力。

 中臺：前臺和後臺之間的橋樑與潤滑劑

 　　雖然中臺有這麼大的價值，但是就跟技術架構一樣，每引入一項新的東西都會增加現有的複雜度，你要享受微服務架構風格的牛逼和瀟灑，也得承受微服務帶來的各種複雜度，無論是整合、部署還是運維，都會增加你的負擔，中臺亦是如此。中臺需要強力的戰略執行力、必要的組織架構調整、合格的技術團隊建設等等，都是需要很大成本的。

3.4 現在有哪些中臺了？

　　目前來說，主流的中臺分類（即大家廣為談論的）有兩個：

　　（1）業務中臺

　　主要是指通過將不同業務線解決相同問題域的解決方案進行抽象和封裝，通過配置化、外掛化、服務化等機制兼顧支撐不同業務線的特性需求。大部分談論中臺的人，應該都是談的業務中臺，因為不論什麼中臺，最終都是為業務服務，賦能前臺，提高企業的使用者響應力的。

 一個常見的電商業務中臺示例圖

　　（2）資料中臺

　　資料中臺也是個火爆的概念，在DT時代，企業逐漸都深刻意識到資料的價值。那麼，它與業務中臺的聯絡在什麼地方？

　　可以這樣理解，業務中臺在產生資料，資料中臺是做資料的二次加工，並將加工結果再服務於業務，為業務進行資料和智慧的賦能。

 業務中臺與資料中臺的聯絡

 　　當然，在不同的人的眼中，看到的中臺都是不同的型別，可能張三認為中颱是技術中臺，應該是微服務、DevOps平臺、容器雲平臺這一套組合；而李四可能認為中颱是組織中臺，應該是企業內部資源排程中心和內部創新孵化組織等；因此，每個人的視角和立場不同，都會對中臺有不同的理解，其他的被大廠推廣的類似中臺還有研發中臺、安全中臺等。

 技術人的視角：你心中的中臺可能是中介軟體平臺

　　面對種類繁多的中臺，我還是比較認可網易雲的觀點“所有的中臺都是業務中臺”，而其他的中臺其實都是一種廣義上的業務中臺，被稱之為中颱，就需要具備一定的業務屬性，最終都要為業務服務。

 網易雲：所有的中臺都是業務中臺

3.5 能不能給中臺一個定義？

　　可能看了這麼多，我們還是不能給中臺下個定義，不過這裡我真的很認同王健老師的這句話“中臺，即企業級能力複用平臺！”

　　所謂企業級，主要是指中臺處理的問題範圍在企業級別，即包含多條業務線或服務多個前臺產品(團隊)，且建設中臺一定要跳出單條業務線、站在企業整體視角來審視業務全景。

　　所謂能力，主要是指中臺主要承載的物件，每家企業的核心能力都不同，要找到差異化競爭力。

　　所謂複用，即中臺的核心價值，它的可複用及易複用的特效能夠實現更多地對前臺業務的支撐。

　　所謂平臺，即中臺的主要形式，它通過對於更細粒度能力的識別與平臺化沉澱，實現企業能力的柔性複用。

四、中臺的落地規劃

4.1 提前想清楚幾個問題

　　（1）你建設中臺的願景是什麼？

　　所謂“遇事不決看願景”，即建設中臺為了解決什麼問題？對於企業和業務又有什麼價值？這是需要提前想清楚的，並且這個願景是需要所有角色都要明確並且達成一致的。否則，會在後續建設過程中迷失方向，偏離初心。

遇事不決看願景”

　　（2）你的中臺的錢由誰出？

　　一般採用投融資模式，即在建設前期就由企業本身的戰略儲備資源投資建設，服務穩定之後，對前臺產生穩定價值之後，再逐漸從前臺收取一定的資源。因此，這種模式比較適合適合解決企業長期戰略目標（比如業務轉型，這也是大部分企業正在做的事兒）。這種模式的優點在於中臺團隊在建設初期有更多的自主權，有利於實現中臺願景，但是需要企業有較雄厚的戰略資源支援和更大的戰略決心才能推廣下去。

　　（3）你的中臺的目標如何驗證？

　　這個問題也是需要在建設中臺之前就要思考如何驗證和度量的，像阿里巴巴就將其中臺的考核設計為：40%穩定性+25%業務創新+20%業務接入量+15%客戶滿意度。驗證指標的設計是一個複雜的過程，也是需要不斷演進，需結合願景、投資模式等綜合設計。

 中臺成功度量：驗證指標設計

4.2 建設方法論支援：D4模型

　　在長期的諮詢指導和架構實踐的過程中，ThoughtWorks形成了一套完整的中臺建設方法論模型：D4模型。之所以稱之為 D4（也與Diss這個單詞有關），主要是ThoughtWorks把中臺從整體規劃到落地交付的過程劃分了四個不同的階段，包含了兩次發散與收斂的過程。這個模型的主要受眾應該是CIO、資訊部總監、業務架構師等等；

 中臺建設方法論支援：D4模型

　　（1）第一個D：Discovery

　　在這一階段，主要是做企業戰略的分解及現狀的調研，目的是建立一個對企業和行業的全面視野，儘量發散收集大量資訊；

　　由外到內：行業與競爭對手分析，目的是知己知彼百戰百勝！工具：SWOT/商業模式畫布等

　　由上而下：企業戰略分解，目的是找到中臺建設的大方向！工具：精益價值樹等

　　由下而上：現狀調研與分析，目的是瞭解現狀和歷史，收集彙總痛點！工具：使用者旅程+服務藍圖等

 現狀調研工具：使用者全旅程地圖

　　（2）第二個D：Define

 　　這一階段，主要是對Discovery階段收集的資訊進行分析和收斂，最終形成企業的數字化全景規劃。這個過程中，需要對跨業務線的業務梳理進行重合度分析、探索企業核心問題域（使用DDD）以及形成具體的實施路徑規劃。等到這個過程結束，其實就幫助回答了兩個問題：一是到底需不需要中臺？二是需要哪些中臺？

　　可以採用的工具：TOGAF+DDD工作坊+事件風暴等；

平臺型企業架構設計方法論（From ThoughtWorks）

　　（3）第三個D：Design

 　　這一階段，已經得知需要建設一箇中臺，就可以開始規劃和設計了，主要會確定以下幾個事，也是一個發散的過程，儘可能地多輸出。

　　首先，確定中臺產品願景，確定業務梳理範圍（收斂聚焦區域）。其次，細粒度地進行業務梳理，回到業務本身，從問題域出發，以使用者為中心，進行使用者體驗設計和業務服務藍圖的梳理，比如採用使用者體驗旅程圖+服務藍圖等；最後，確定要實施的最小可用品MVP，來一個端到端的縱向切分的薄片進行驗證。

　　在此階段，也可以開始制定迭代計劃及接入計劃，合理的計劃能夠幫助規避一些風險；此外，還可以定義驗證指標，如上面提到的如阿里巴巴就將其中臺的考核設計為：40%穩定性+25%業務創新+20%業務接入量+15%客戶滿意度。

　　（4）第四個D：Delivery

 　　這一階段，已經拿到了一個作為切入點的中臺場景，並且經過MVP進行了快速驗證，如果能夠通過企業內部的立項稽核和流程，就可以開始一個正式的中臺專案建設開發了，這是一個漫長的過程，我們可能會經歷以下三步：

　　第一步：組建中臺建設團隊，這支隊伍應該有戰鬥力。

　　第二步：結合精益思想與敏捷實踐進行中臺的具體研發過程。精益思想的核心目標是消除浪費，創造價值，整個研發流程其實也是一個複雜的系統性工程。這一過程，也就是我們普通開發人員所主要參與和關注的過程。是不是很納悶，這麼長的文字，終於等到我們出場了，TMD戲太長了！不過，這部分童鞋可能真的會失望了，因為正如我在最開始的時候所說，中臺並沒有帶來什麼技術上的新東西，它更多是偏向與業務層面的概念。開發中臺，我們要使用的其實還是微服務、DDD、DevOps、雲原生這一套技術，對，還是這些東西，但是，你又真的學習了多少？

精益產品研發流程（From ThoughtWorks）

 　　第三步：中臺的運營、治理與演進。可以採用三層SLA使用者劃分機制，優先支援高層使用者的響應，構建不同層次的運營體系，從而實現資源的合理調配。

4.3 常見的疑惑與問題

　　（1）業務中臺與微服務的區別？

　　二者解決的是不同的問題，也處於不同的抽象層次。

　　中臺解決的是業務領域複用的問題，微服務解決的是技術領域的"元件編譯時依賴"造成的問題。

　　業務中臺不一定是微服務架構的，微服務架構也不一定是為了能力複用的問題

　　（2）技術中臺與中介軟體的區別？

　　技術中臺強調從全域性業務視角的出發，中介軟體則主要從技術去重的視角出發。

　　（3）中臺是否在炒概念？

　　新概念本身沒錯，永遠保持好奇，先接納再判斷。

五、學習小結

　　因為近年來經濟行情的壓力，導致越來越多的企業開始尋求轉型並開始了自己的數字化戰略。因為自己的公司正在做數字化轉型，所以我才會參與其中並有動力去了解中臺的概念。看來看去，讀來讀去，不管是中臺還是X臺，本質都是企業想要增強確定性來應對行情的不確定性所做的一個措施而已。為了讓企業的管理者能夠不慌得一批，中臺是被強行推著上了舞臺中央，並且四面八方都給了它閃光燈。對於我們開發者而言，對於新概念應該保持好奇，而不是一開始就去盲目地否定，先接納再結合自身的情況做判斷，希望我的學習總結能為你解開一丟丟的疑惑我就心滿意足。

六、整體腦圖

參考資料

本學習總結引用了大量以下文章的內容及圖片，對下面作者表示感謝！

（1）王健，極客時間《說透中臺》專欄

（2）葛曉玲，《不做中臺會死嗎？企業真的需要一箇中臺嗎？》

（3）鍾華，《企業IT架構轉型之道：阿里巴巴中臺戰略思想與實踐》

（4）張善友，《基於Kubernetes建設.NET Core技術中臺》

（5）不止思考，《要不要趕個時髦，去建設一箇中臺》

（6）無涯，《大道至簡，中臺是啥》

（7）沙漠之鷹，《大型科技企業架構：中臺模式的愛與恨》

（8）陳春花，《解讀數字化戰略與新產業時代》

作者：周旭龍

出處：https://edisonchou.cnblogs.com

本文版權歸作者和部落格園共有，歡迎轉載，但未經作者同意必須保留此段宣告，且在文章頁面明顯位置給出原文連結。