《說透中臺》讀書筆記

在產業互聯網火爆的當下，在BATJ等互聯網大廠大肆推廣中臺建設成果的當下，各個行業的企業彷佛都想作數字化轉型，建設業務中臺，可是中臺究竟是啥，須要咱們提早了解和學習，本文就是個人學習總結，但願能對你初步的理解中臺這個概念有所幫助。

1、學習背景

　　所謂的中臺戰略，仍是停留在感性層次，只會說出幾回消除煙囪，數據孤島之類的感性的「大話」。然後在極客時間王健老師的《說透中臺》專欄想要進行深刻學習加以更好地理解，因而有了你看到的這篇的學習總結文章。

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

　　（1）中臺是什麼？

　　企業級能力複用平臺！

　　（2）如何構建中臺？

　　一句話歸納：「以用戶爲中心，從戰略入手，願景爲指引，用科學有效的方法，步步爲營沉澱企業級能力，輔以必要的組織與系統架構調整，方得中臺。」

　　（3）中臺的價值是啥？

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

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

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

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

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

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

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

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

2、中臺的發展歷程

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

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

　　無論是身處浪潮一線的互聯網大廠，仍是傳統行業的轉型企業，彷佛在2020年都有建設一箇中臺的需求（至少都在採起行動或開始學習），無論真的想進行能力沉澱複用 仍是 追概念來個彎道超車，中臺正在被愈來愈多的人熟知。

互聯網大廠的集體吹牛逼

3、中臺的核心概念

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、中臺的落地規劃

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）技術中臺與中間件的區別？

　　技術中臺強調從全局業務視角的出發，中間件則主要從技術去重的視角出發。

5、學習小結

　　由於近年來經濟行情的壓力，致使愈來愈多的企業開始尋求轉型並開始了本身的數字化戰略。由於本身的公司正在作數字化轉型，因此我纔會參與其中並有動力去了解中臺的概念。看來看去，讀來讀去，無論是中臺仍是X臺，本質都是企業想要加強肯定性來應對行情的不肯定性所作的一個措施而已。爲了讓企業的管理者可以不慌得一批，中臺是被強行推着上了舞臺中央，而且四面八方都給了它閃光燈。對於咱們開發者而言，對於新概念應該保持好奇，而不是一開始就去盲目地否認，先接納再結合自身的狀況作判斷，但願個人學習總結能爲你解開一丟丟的疑惑我就心滿意足。

參考資料

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

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

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

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

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

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

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

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

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

（9）Edison Zhou《據說你在作數字化轉型，瞭解中臺一下不？》