24 11 月 中台是個什麼鬼｜白話中台戰略

從去年開始，好像就有一隻無形的手一直將我與「微服務」、「平台化」、「中台化」撮合在一起，給我帶來了很多的困擾和思考與收穫。

故事的開始源於去年的技術雷達峰會，我在會上做了一場關於平台崛起的主題分享（《The Rise of Platform》），這場分享主要是從技術的層面從Global的視角介紹了平台化的興起，以及分享從基礎設施到人工智慧等各個領域不斷湧現的各類平台，以及平台化對於軟體開發人員及企業的影響。

記得當時在做演講綵排的時候，有同事就提到過，在中國提「數字化平台戰略」可能大家會覺得比較抽象比較遠大空，如果你提「中台」大家會更熟悉一些。

而這也是我第一次聽到「中台」這個詞，原來除了我們熟悉的「前台」和「後台」外，居然還有個「中台」這樣一個神奇的存在。

那…… 中台到底是什麼？會不會又是另一個Buzzword呢？這個從名字上看像是從前台與後台中間硬擠出來的新斷層，它與前台和後台的區別和界限到底在哪兒？什麼應該放到中台，什麼又應該放到前台或是後台？它的出現到底是為了解決什麼問題呢？

從那時開始，一個接一個的問題就不斷的湧出並縈繞在我的腦子裡。直到一年多後的今天，隨著參與的幾個平台化、企業中台相關的項目已經順利地步上了正軌，終於可以坐下來回顧一下這一年的實踐與思考，再次試圖回答這些問題，並梳理成文，與大家交流探討。

中台迷思

到處都在喊中台，到處都是中台，中台這個詞在我看來已經被濫用了。

• 在有些人眼裡：中台就是技術平台，像微服務開發框架、Devops平台、PaaS平台，容器雲之類的，人們都叫它「技術中台」。
• 在有些人眼裡：中台就是微服務業務平台，像最常見的什麼用戶中心，訂單中心，各種微服務集散地，人們都叫它「業務中台」。
• 在有些人眼裡：中台應該是組織的事情，在釋放潛能：平台型組織的進化路線圖 (豆瓣)中就提出了平台型組織和組織中台的概念，這類組織中台在企業中主要起到投資評估與投後管理的作用，類似於企業內部資源調度中心和內部創新孵化組織，人們叫它「組織中台」

看完本篇你就會理解，上邊的這幾類「中台」劃分還是靠譜的，更多我看到的情況是大家為了響應企業的「中台戰略」，乾脆直接將自己系統的「後端」或是「後台」改個名，就叫「中台」。

中台到底是什麼？它對於企業的意義到底是什麼？當我們談中台時我們到底在談些什麼？

想要尋找到答案，僅僅沉寂在各自「中台」之中，如同管中窺豹，身入迷陣，是很難想清楚的。不如換個 ⾓度，從各類的「中台迷陣」中跳脫出來，嘗試以更高的視角，從企業均衡可持續發展的角度，來思考中台的價值，來試圖反推它存在的價值。

所以，為了搞明白中台存在的價值，我們需要回答以下兩個問題：

1. 企業為什麼要平台化？
2. 企業為什麼要建中台？

第一個問題：企業為什麼要平台化？

先給答案，其實很簡單：

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

不斷快速響應、探索、挖掘、引領⽤戶的需求，才是企業得以⽣存和持續發展的關鍵因素。

那些真正尊重用戶，甚⾄不惜調整⾃己顛覆⾃己來響應⽤戶的企業將在這場以⽤戶為中心的商業戰爭中得以⽣存和發展；⽽反之，那些在過去的成就上故步⾃封，存在僥倖⼼理希望⽤戶會像之前一樣繼續追隨⾃己的企業則會被用戶淘汰。

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

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

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

又有點遠大空是不是，我們來看⼏個經典的例子:

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

2.海爾也早在⼗年前就已經開始推進平台化組織的轉型，提出了「平台⾃營體⽀撐⼀線⾃營體」的戰略規劃和轉型⽬標。構建了「⼈單合一」、「⽤戶付薪」 的創客文化，真正將平台化提⾼到了組織的⾼度。

3.華為在幾年前就提出了「⼤平台炮火支撐精兵作戰」的企業戰略，「讓聽得到炮聲的人能呼喚到炮火」 這句話形象的詮釋了大平台⽀撐下小前台的作戰策略。這種極度靈活又威力巨⼤的戰法，使之可以迅速響應瞬息萬變的戰場，一旦鎖定目標，通過大平台的炮火群，迅速精準對於戰場進行強大的火⼒支援。

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

而平台化恰好可以助力企業更快更好的做到這些，所以這回答了第一個問題，企業需要平台化。

第二個問題：企業為什麼要建中台？

好，想明白了第一個問題，為什麼需要平台化。但是平台化並不是一個新概念，很多企業在這個方向上已經做了多年的努力和積澱。那為什麼最近幾年「中台」這個相對較新的概念又會異軍突起？對於企業來講，傳統的「前台+後台」的平台化架構又為什麼不能滿足企業的要求呢?

好，這就引出了我們的第二個問題：企業為什麼要建中台？

來，先定義一下前台與後台

因為平台這個詞過於寬泛了，為了能讓大家理解我在說什麼，我先定義一下本篇文章上下文下我所說的前台和後台各指什麼：

• 前台：由各類前台系統組成的前端平台。每個前台系統就是一個用戶觸點，即企業的最終用戶直接使用或交互的系統，是企業與最終用戶的交點。例如用戶直接使用的網站，手機App，微信公眾號等都屬於前台範疇。
• 後台：由後台系統組成的後端平台。每個後台系統一般管理了企業的一類核心資源（數據+計算），例如財務系統，產品系統，客戶管理系統，倉庫物流管理系統等，這類系統構成了企業的後台。基礎設施和計算平台作為企業的核心計算資源，也屬於後台的一部分。

後台並不為前台而生

定義了前台和後台，對於第二個問題（企業為什麼要建中台），同樣先給出我的答案：

因為企業後台往往並不能很好的支撐前台快速創新響應用戶的需求，後台更多解決的是企業管理效率問題，而中台要解決的才是前台的創新問題

大多數企業已有的後台，要麼前台根本就用不了，要麼不好用，要麼變更速度跟不上前台的節奏。

我們看到的很多企業的後台系統，在創建之初的目標，並不是主要服務於前台系統創新，而更多的是為了實現後端資源的電子化管理，解決企業管理的效率問題。這類系統要不就是當年花大價錢外購，需要每年支付大量的服務費，並且版本老舊，定製化困難；要不就是花大價錢自建，年久失修，一身的補丁，同樣變更困難，也是企業所謂的「遺留系統」的重災區。

總結下來就兩個字「慢」和「貴」，對業務的響應慢，動不動改個小功能就還要花一大筆錢。

有人會說了，你不能拿遺留系統說事兒啊，我們可以新建後台系統啊，整個2.0問題不就解決了。

但就算是新建的後台系統，因為其管理的是企業的關鍵核心數據，考慮到企業安全、審計、合規、法律等限制。導致其同樣往往⽆法被前台系統直接使用，或是受到各類限制⽆法快速變化，以⽀持前台快速的創新需求。

此時的前台和後台就像是兩個不同轉速的⻮輪，前台由於要快速響應前端用戶的需求，講究的是快速創新迭代，所以要求轉速越快越好；⽽後台由於⾯對的是相對穩定的後端資源，⽽且往系統陳舊複雜，甚至還受到法律法規審計等相關合規約束，所以往往是穩定至上，越穩定越好， 轉速也自然是越慢越好。

所以，隨著企業務的不斷發展，這種「前台+後台」的⻮輪速率「匹配失衡」的問題就逐步顯現出來。

隨著企業業務的發展壯大，因為後台修改的成本和⻛險較⾼，所以驅使我們會盡量選擇保持後台系統的穩定性，但還要響應用戶持續不斷的需求，自然就會將大量的業務邏輯(業務能力)直接塞到了前台系統中，引入重複的同時還會致使前台系統不斷膨脹，變得臃腫，形成了一個個⼤泥球的「煙囪式單體應用」。漸漸拖垮了前台系統的「⽤戶響應⼒」，用戶滿意度降低，企業競爭力也隨之不斷下降。

對於這樣的問題，Gatner在2016年提出的一份《Pace-Layered Application Strategy》報告中，給出了一種解決方案，即按照「步速」將企業的應用系統劃分為三個層次（正好契合前中後台的三個層次），不同的層次採用完全不同的策略。

而Pace-Layered Application Strategy也為「中台」產生的必然性，提供了理論上的支撐。

Pace-Layered Application Strategy

在這份報告中Gatner提出，企業構建的系統從Pace-Layered的⾓度來看可以劃分為三類: SOR(Systems of record )，SOD(Systems of differentiation)和SOI(Systems of innovation)。

處於不同Pace-Layered的系統因為⽬的不同，關注點不同，要求不同，變化的「速率」自然也不同，匹配的也需要采⽤不同的技術架構，管理流程，治理架構甚至投資策略。

⽽前面章節我們提到的後台系統，例如CRM、ERP、財務系統等，它們⼤多都處於SOR的Pace-Layered。這些系統的建設之初往往是以規範處理企業底層資源和企業的核⼼可追溯單據(例如財務單據，訂單單據)為主要⽬的。它們的變更周期往往比較⻓，⽽且由於法律律審計等其他限制，導致對於它們的變更需要嚴謹的申報審批流程和更高級別的測試部署要求，這就導致了它們往往變化頻率低，變化成本高，變化⻛險高，變化周期⻓。⽆法滿⾜由⽤戶驅動的快速變化的前台系統要求。

我們又要儘力保持後台(SOR)系統的穩定可靠，⼜要前台系統(SOI)能夠⼩而美，快速迭代。就出現了上文提到的」齒輪匹配失衡「的問題，感覺魚與熊掌不可兼得。

正當陷入僵局的時候，天空中飄來一聲IT諺語：

軟體開發中遇到的所有問題，都可以通過增加⼀層抽象⽽得以解決!

⾄此，⼀聲驚雷滾過，「中台」腳踏七彩祥雲，承載著SOD(Systems of differentiation) 的前世寄託，橫空出世。

中台才是為前台而生

我們先試著給中台下個定義：

中台是真正為前台而生的平台（可以是技術平台，業務能力甚至是組織機構），它存在的唯一目的就是更好的服務前台規模化創新，進而更好的響應服務引領用戶，使企業真正做到自身能力與用戶需求的持續對接。

中台就像是在前台與後台之間添加的⼀組「變速⻮輪」，將前台與後台的速率進行匹配，是前台與後台的橋樑。它為前台而生，易於前台使用，將後台資源順滑流向用戶，響應用戶。

中台很像Pace-Layered中的SOD，提供了比前台（SOI）更強的穩定性，以及⽐後台（SOR）更高的靈活性，在穩定與靈活之間尋找到了⼀種美妙的平衡。

中台作為變速齒輪，鏈接了用戶與企業核心資源，並解決了配速問題

有了「中台」這⼀新的Pace-Layered斷層，我們即可以將早已臃腫不堪的前台系統中的穩定通用業務能力「沉降」到中台層，為前台減肥，恢復前台的響應⼒；又可以將後台系統中需要頻繁變化或是需要被前台直接使用的業務能力「提取」到中台層，賦予這些業務能力更強的靈活度和更低的變更成本，從而為前台提供更強大的「能力炮火」⽀援。

所以，企業在平台化的過程中，需要建設自己的中台層（同時包括技術中台，業務中台和組織中台）。

總結

思考並回答了文初提出的兩個關於中台價值的核心問題，解決了我對於中台產生的一些困惑，不知道對你有沒有啟發，讓我最後再來總結一下：

• 以用戶為中心的持續規模化創新，是中台建設的核心目標。企業的業務響應能⼒和規模化創新能力，是互聯⽹時代企業綜合競爭⼒的核⼼體現。平台化包括中台化只是幫助企業達到這個目標的⼿段，並不是⽬標本身。
• 中台(⽆論是技術中台、業務中台還是組織中台)的建設根本上是為了解決企業響應⼒困境， 彌補創新驅動快速變化的前台和穩定可靠驅動變化周期相對較慢的後台之間的⽭盾，提供⼀個中間層來適配前台與後台的配速問題，沉澱能⼒，打通並順滑鏈接前台需求與後台資源，幫助企業不斷提升用戶響應⼒。
• 所以，中台到底是什麼根本不重要，如何想方設法持續提高企業對於⽤戶的響應⼒才是最重要的。⽽平台化或是中台化，只是恰巧走在了了這條正確的⼤道上。

PS: 本文是《白話中台戰略》的第一篇，後續還打算繼續寫，總結分享介紹從問題到解決方案，從技術到業務到組織的一些實踐經驗。會涉及到企業技術中台規劃，業務中台規劃，遺留系統微服務化改造落地一系列內容，先立個Flag，希望大家看後能給一些反饋，謝謝。

---

文/ThoughtWorks王健

原文：https://insights.thoughtworks.cn/what-is-zhongtai/