聽說你在做數字化轉型，了解中台一下不？

2020 年 3 月 13 日
筆記

在產業互聯網火爆的當下，在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台，本質都是企業想要增強確定性來應對行情的不確定性所做的一個措施而已。為了讓企業的管理者能夠不慌得一批，中台是被強行推着上了舞台中央，並且四面八方都給了它閃光燈。對於我們開發者而言，對於新概念應該保持好奇，而不是一開始就去盲目地否定，先接納再結合自身的情況做判斷，希望我的學習總結能為你解開一丟丟的疑惑我就心滿意足。