第3章
全面解讀中台
中台，通過對業務、資料和技術的抽象，對服務能力進行複用，建構了企業級的服務能力，消除了企業内部各業務部門、各分子公司間的壁壘，适應了企業，特别是大型企業集團業務多元化的發展戰略。基于中台，可快速建構面向最終消費者和客戶的前台應用，進而滿足各種個性化特征的前台需求，為企業的數字化轉型提供明确的道路。
3.1 什麼是中台
那麼中台到底是什麼？中台是一個新的概念，但卻是一個舊有的名詞，在新時期我們賦予其新的内涵。本節介紹中台的曆史起源，以及數字化時代中台在企業資訊化建設中的表現和作用。
3.1.1 中台的源起
在中國古代東漢時期，尚書台成為政府的中樞，号稱中台。唐朝所完善的三省六部制，以門下省為西台，中書省為東台，也将尚書省稱為中台。尚書省作為執行機構，轄吏、戶、禮、兵、刑、工六部，如圖3-1所示。
圖3-1 中國古代官場的“中台”架構
在一個投資銀行的組織結構中，前台（Front Office）是與客戶（無論是個人客戶還是公司客戶）直接互動的崗位，諸如大堂經理、客戶經理、櫃員等。中台（Middle Office）是指直接支援前台工作的所有人員，使用前台或背景的資源，為前台提供專業性的管理和指導，并進行風險控制，比如風險管理、合規應對、财務管控以及IT服務等。背景（Back Office）指幕後的職能崗位，行使管理職能，比如結算、清算、會計、人力資源等。
位于芬蘭的著名移動遊戲公司Supercell以小前台的方式組織了若幹個開發團隊。每個團隊包含了開發一款遊戲所需的各種角色。這樣各個團隊可以快速決策、快速開發。而基礎設施、遊戲引擎、内部開發工具和平台則由類似“部落”的部門提供。“部落”可以根據需要擴充為多個小分隊，但各個小分隊都保持共同的目标。“部落”本身并不提供遊戲給消費者。
2015年的阿裡巴巴已擁有規模龐大的個人會員和企業會員，業務種類紛繁複雜，業務之間交叉依賴，業務團隊衆多，不能及時響應業務的要求。是以當年12月，時任阿裡巴巴集團CEO的張勇通過内部郵件宣布啟動阿裡巴巴2018年中台戰略，建構符合DT時代的更具創新性和靈活性的“大中台，小前台”的組織機制和業務機制，實作管理模式創新。即将産品技術力量和資料營運能力從前台剝離，成為獨立的中台，包括搜尋事業部、共享業務事業部、資料平台事業部等，為前台即零售電商事業群提供服務。進而前台得到精簡，保持足夠的靈活度，更好地滿足業務發展和創新需求。
2017年5月出版的《企業IT架構轉型之道：阿裡巴巴中台戰略思想和架構實戰》詳細闡述了業務中台是介于前台與背景之間的。其采用共享的方式建設，解決了以往煙囪式和單體式架構設計的重複開發、資料分散、試錯成本高等問題。書中列舉了建設業務中台的一些原則：高内聚低耦合、資料完整性、可營運性、漸進性等。此書的出版推動了中台思想的發展和中台的建設。
之後，很多網際網路公司快速跟進中台。滴滴出行在2017年12月分享了《如何建構滴滴出行業務中台》。滴滴出行在前端業務上形成了計程車、快車、專車、代駕等多業務共同發展的業态。雖然各業務的應用場景不同，但所有業務本質都是出行，交易流程是相同的。如果各業務獨立發展，則業務間缺少協同性。
京東在2018年12月宣布采用前台、中台和背景的組織架構。前台職能是了解和洞察客戶需求和行為，通過産品創新和精細化營運服務客戶，最終實作和提升客戶價值。中台通過沉澱、疊代群組件化地輸出服務于前台不同場景的通用能力，作為為前台業務營運和創新提供專業能力的共享平台。背景職能則提供基礎設施建設、服務支援與風險管控，為中、前台提供保障。
3.1.2 從組織管理和技術系統角度看中台
中台可以作為一種企業組織管理模式和理念（Middle Office）。不過從技術系統角度看，中台也可以作為一種新型的企業IT設施架構（Middle Platform）。此外，為建設中台系統，有些企業會成立專門的中台技術團隊來整體負責、實作和營運。是以作為組織管理模式的中台和中台系統這兩者并不是完全分開的。
中台化的組織方式就是在公司内部建構統一的協同平台。一方面，可以讓各業務部門保持相對的獨立和分權，保證對業務的敏感性和創新性；另一方面，用一個強大的平台來對這些部門進行總協調和支援，平衡集權與分權，并為新業務、新部門提供生長空間，進而大幅降低組織變革的成本。中台部門提煉各業務線的共性需求，最大程度減少重複“造輪子”。
從技術系統層面看，中台是企業級共享服務平台。傳統的IT系統或套件沒有太多關注系統能力的複用和共享，是以企業在多年的資訊化過程中引入和建設了多套具有重複功能的煙囪型系統。而中台則要求對能力進行細粒度分析，識别共享能力，并将共享能力建設成為統一的平台。是以中台不是單系統的服務化。
綜上所述，中台是能力的樞紐和對能力的共享。中台是在集中的基礎上建設分權的業務，進行聯通，并為各業務提供統一的服務。是以一切将企業的各式各樣的資源轉化為易于前台使用的能力，為企業進行“以使用者為中心”的數字化轉型服務的平台，都是中台。但要注意，與此思想相比對所建設的中台團隊并不能當作資源共享團隊。中台團隊關注的是如何形成基礎服務，為前台團隊建設業務應用提供便利。是以中台要實作平台邏輯與業務邏輯的分離，并隔離不同前台業務。
另外，中台不是微服務，因為中台不僅是一種技術架構，還是企業進行數字化轉型的整體參考架構。不過從技術角度，可以認為微服務是建設中台的最佳實踐。微服務是将J2EE時代的單體架構拆分為多個提供微服務的技術架構。微服務将相關聯的業務邏輯及資料放在一起形成獨立的邊界。各個微服務之間通過标準的協定，比如HTTP RESTful風格進行通信通路。各個微服務間是松耦合的。不同的微服務開發團隊理論上可以使用不同的技術棧來實作微服務而無須強求一緻。另外，微服務所需的資料存儲一般都由單獨的資料庫執行個體或資料庫模式隔離，資料的互動隻能通過接口或消息實作，而不能在資料庫層直接通路另一個微服務的資料。微服務強調接口的隔離原則，通過接口封裝。由于微服務可單獨部署，是以可根據需要對所需的微服務進行擴縮容，無須針對整個系統，進而使系統的伸縮性更靈活，更能應對大流量并發場景，比如秒殺。微服務擁有與生俱來的獨立開發、獨立部署、獨立釋出特性，支援高并發高可用，以及去中心化管理等優點。但由于微服務是分布式程式設計，提高了開發、調試、部署、運維等的難度，增加了服務管理的複雜度，且需要重新設計原先由單一資料庫保證的原子性等。雖然微服務對開發團隊提出了更高的要求，但是它促進了研發團隊的一體化運維能力，進而改變了企業的研發組織架構。
3.2 中台系統及其展現形式
中台是數字化轉型下重構企業IT基礎設施的最佳實踐。那麼，怎麼了解中台是企業級共享服務平台？我們先來看看中台的起源地—阿裡巴巴建設中台的驅動力和成果。
2008年的阿裡巴巴集團由于内部部門之間的隔離、業務目标相對不一緻，淘寶和淘寶商城（即現今的天貓）是作為兩套獨立的系統分别建設的，即是兩套獨立的煙囪型系統。但二者的基礎業務都是電商交易，是以基本功能是類似的，包括商品、交易、支付、評價、物流、積分、論壇等功能。由于系統間的隔離，雖然商城的流量和交易持續走低，卻無法将淘寶的流量引流到淘寶商城。是以，兩個業務部門商量如何打通兩個電商平台，進而成立了共享業務事業部，着手進行内部稱為“五彩石”的項目。“五彩石”項目的成果，即現在稱為“中台”的各共享業務服務中心，這為後續天貓的快速發展奠定了堅實的基礎。中台整合了阿裡巴巴集團的産品技術能力和營運資料能力，對各前台業務形成了強有力的支撐。後續上線的聚劃算、1688等均得益于中台的建設。
由此可以看到，企業在資訊化建設過程中，不同業務部門基于本部門的業務需求提出了相對獨立的方案。IT部門為滿足不同業務部門的不同業務需求（有時甚至是互相沖突的），搭建了紛繁複雜且部分功能重複的煙囪式系統。煙囪式系統的建設不僅帶來了功能的重複建設，還帶來了重複維護，導緻企業的重複投資。此外，為了打通煙囪式系統，還需要專門設計第三方內建方案或引入企業服務總線（ESB）的概念，內建和協作成本高昂。是以，在建設和引入新的系統時，雖然各部門根據自己的業務需求建構了定制化的最優解決方案，但這些方案可能隻是局部最優；如果從公司整體來看，不一定是全局最佳的解決方案。是以，建構系統如果不從全局出發，不進行現有系統的改造更新、重複利用，那麼隻能是在舊有的複雜性上再次引入新的複雜性，導緻系統越建越複雜，而效率卻越來越低。
既然我們強調中台是能力的複用，那麼在建設新系統或業務應用時，可複用的能力具體是以什麼樣的形式提供的呢？在程式設計中，函數是将一段經常使用的代碼封裝起來，然後在需要使用時直接調用。使用函數展現了程式設計子產品化的指導思想，即将大問題分解為小問題，通過解決小問題來解決大問題。其次，函數的使用大大減少了重複編寫程式段的工作量。相關的通用函數集，可以編譯成動态連結庫及類庫，這再次提升了複用的可能。既然我們可以使用函數、類庫的方式将一些可複用的功能封裝起來，那是不是也可以将可複用的功能作為服務提供？以服務的方式提供共享能力的平台就是中台。中台是比函數和類庫更高一層次的複用封裝（見圖3-2），進而更好地服務于業務。
圖3-2 共享的三個層次
3.3 中台的作用
中台應該包含哪些内容呢？什麼應該包括在中台裡？什麼不應該放在中台裡？中台與企業現有的ERP、CRM是什麼關系？如果建設了中台，中台應當如何發揮作用，而不是又讓企業陷入建設另一套IT系統的老路？
3.3.1 中台的分類
中台是從多個相似的前台業務應用共享的需求中産生的，是以最先提出的中台是業務中台。資料是從業務系統産生的，而業務系統也需要資料分析的結果，那麼是否可以把業務系統的資料存儲和計算能力抽離，由單獨的資料處理平台提供存儲和計算能力？這樣不僅可以簡化業務系統的複雜性，還可以讓各個系統采用更合适的技術，專注做本身擅長的事。這個專用的資料處理平台即資料中台。
3.3.2 業務中台定義及建設内容
業務中台是阿裡巴巴首先提出的企業IT架構的轉型之道。站在阿裡巴巴集團全局的角度看，業務中台是從整體戰略、業務支撐、連接配接消費者和業務創新等方面進行統籌規劃的。是以業務中台内含了阿裡巴巴電商交易的主營業務。業務中台更多關注的是如何支撐線上業務。阿裡巴巴一開始将淘寶作為平台方連接配接商家和消費者，進行電商交易活動，随之發展出淘寶商城，即後來的天貓。天貓本質上還是電商交易平台。既然都是電商交易平台，就都涉及售前、售中和售後的業務流程。
業務中台圍繞以交易為核心關聯的領域組成。交易的對象是商品，商品通過店鋪售賣給會員，交易的憑證是訂單，線上交易需要支付，成單後需要貨品出庫和物流派送等，售前需要營銷促銷活動吸引流量并加強轉化，售後使用者會對店鋪、商品進行評價等。由此可見，典型的業務中台由多個業務服務中心組成，如
圖3-3所示。
會員中心服務于使用者的消費全生命周期，為使用者提供特定的權益和服務，企業可以通過會員中心與使用者進行互動，培養使用者忠誠度。其主要能力包括：
- 會員營運管理：包括會員注冊、個人資訊維護、會員登出、會員卡辦理等相關能力。
- 會員體系管理：包括會員體系的建立、積分規則、成長值規則、等級、權益等相關能力。
- 客戶服務管理：包括客戶的新增、導入、查詢等相關能力。
- 積分交易管理：包括積分擷取、核銷、清零、當機、兌換等相關能力。
圖3-3 一個典型的由服務中心組成的業務中台
商品中心提供管理商品核心資料的能力，圍繞商品建構商品關聯資料，諸如商品版本資訊、商品品牌、商品屬性、商品類目等。其主要能力有：
- 品牌、類目、屬性管理：包括對商品品牌的維護、查詢，前後端類目的維護，屬性及屬性組管理等相關能力。
- 産品資料管理：包括對産品模闆的建立、編輯、查詢、禁用等相關能力。
- 商品資料管理：包括商品建立、修改、查詢等相關能力。
-
商品釋出管理：包括商品釋出、上下架（即時+定時）等相關能力。
交易中心負責企業業務交易訂單的整體生命周期管理，包括加入購物車→訂單生成→合并分拆→流轉→支付→發貨→退換貨→完成。所有電商業務的核心系統都是圍繞交易訂單進行建構的。其主要能力包括：
- 購物車管理：包括購物車商品添加、編輯、查詢、校驗等相關能力。
- 正向交易管理：包括交易訂單生成、發起支付交易訂單、商品發貨管理、上門自提及核銷等相關能力。
- 逆向交易管理：包括換貨、退貨、退款等相關能力。
- 訂單資料管理：包括交易訂單、支付記錄、發貨記錄、換貨記錄、退款記錄等資料管理能力。
-
交易流程編排：支援交易流程節點的配置化，便于根據業務場景的不同設定與之比對的流程。
評價中心提供對評價主體對象、評價規則/等級、評價内容、評價操作的管理能力，進而滿足不同角色的評價使用者對評價内容的釋出、追加、平台稽核、平台申訴等需求。主要能力包括：
- 評價内容管理：包括管理評價的主體對象、評價規則配置、評價等級、評價标簽配置等相關能力。
- 評價操作能力：包括評價的釋出、修改、追加、回複、申訴等相關能力。
-
評價監管能力：包括評價釋出稽核、申訴稽核、評價屏蔽等監管相關能力。
店鋪中心提供企業店鋪主體管理、店鋪管理、類型管理、經營對象管理等能力以支援企業為商戶提供線上門店，同時也支援商戶管理、店鋪會員、店鋪會員等級管理、店鋪裝修等。其主要能力包括：
- 商戶管理：包括商戶單個、批量開通，商戶稽核，商戶基本資訊維護等相關能力。
-
店鋪管理：包括店鋪開通、店鋪基本資訊維護、店鋪稽核、店鋪會員等相關能力。
支付中心給下遊商戶輸出标準的支付服務，提供代付代收、财務對賬等服務。通過對接多個主流管道，穩定輸出微信、支付寶、銀聯等支付能力。其主要能力包括：
- 支付能力：包括建立支付訂單、接收管道通知、查詢管道訂單等基本支付能力。
- 支付路由：包括支付管道管理、支付方式管理、支付商戶和應用開通管理等相關能力。
-
資金賬戶：包括資金賬戶管理、充值維護、提現等相關能力。
營銷中心提供商家的活動計劃、申報、審批、執行、核銷的全鍊路管理，也提供基本的促銷能力，如優惠券活動、滿減買贈等。其主要能力包括：
- 活動模闆管理：包括提供營銷活動的政策模闆、規則配置、條件、動作模闆等相關能力。
- 活動管理：包括提供具體活動的基本資訊配置、人群圈選、商品管理、觸發條件等相關能力。
- 優惠券管理：包括優惠券的發放、領取、查詢、使用核銷等相關能力。
-
贈品管理：對于滿贈、買贈活動，提供贈品維護、查詢、啟用、禁用等相關能力。
庫存中心提供倉庫、庫存、貨品、單據（入庫單/出庫單/
盤點單/盤點盈虧單）、稽核（調撥/盤點）、包裹、貨品運費、物流運輸、接入第三方物流公司的服務能力。其主要能力包括：
- 倉庫管理：包括服務區、倉庫、倉位及其關聯管理等相關能力。
- 貨品管理：包括貨品進貨入庫、銷售出庫、調撥入庫、調撥出庫、調撥稽核等相關能力。
- 貨品盤點：包括盤點單生成、稽核、查詢等相關能力。
-
履約管理：包括庫存檢查、發貨單建立及查詢、包裹物流查詢、運費管理、物流狀态跟蹤等相關能力。
建設一套中台系統，可同時運用在多個電商平台的開發設計和服務中。是以，中台可以為同時建設、營運多套電商平台的網際網路企業節省系統建設和營運成本。因為中台既可以避免功能重複建設，又可以通過全管道打通會員系統來增加流量、互相促進，還可以減少營運成本和人員。有了中台，再發展電商相關應用就會變得更加容易，比如，阿裡巴巴發展出的聚劃算。
如果使用傳統的系統思維來設計業務中台，很有可能隻是将原先隔離的各業務系統通過微服務的方式，強行內建在一起，如圖3-4所示。這種方式建構的微服務不是純粹基于領域進行建設，而是從一個系統的粒度層次進行建設。比如PMS會涉及使用者和訂單，OMS也需要關注會員和訂單，CRM同樣涉及會員。是以，按此方式建設的所謂中台，它的各組成部分還是互相交叉重疊的，并不能展現中台是能力共享平台的核心理念。是以，隻對企業業務系統做一個大一統的內建，并不是中台。
圖3-4 傳統思維下所建設的“業務中台”
3.3.3 資料中台定義及建設内容
資料中台是什麼？
資料中台與資料倉庫有什麼差別？
資料中台到底怎麼與業務中台融合？
這三個問題一直以來是人們問得最多的問題。本節将試着對這三大問題進行一一解讀。
在回答資料中台是什麼這個問題之前，先了解一下大家比較熟悉的資料倉庫。在以BAT為首的網際網路公司蓬勃發展起來之前，國内三大電信營運商對于資料倉庫的建設走在其他行業的前面。早在2011年的時候，中國移動集團公司就組織編寫了指導各省公司建設資料倉庫的綱領性檔案《中國移動NG2-BASS3.0建設規範》。在檔案中明确将中國移動的業務分成了7大業務闆塊，按照功能将資料資産劃分為三層：資料層、功能層、應用層。這是很典型的資料倉庫建設的分層模式，如今的資料中台資料分層建設模式也延續了資料倉庫的分層建設規範，後面會詳細講到。
圖3-5所示是某電信營運商資料倉庫的應用層規劃内容，詳細規劃了每個應用領域的資料應用。但是仔細研究可以發現，這些資料應用幾乎全是“分析”，也就是解決了事後“看資料”的問題。
再來看看圖3-6所示的阿裡巴巴的資料中台支撐的資料應用層，除了通用的資料分析以外，還包含“個性化推薦”“風險評估”“預警監控”等與業務緊密結合的資料賦能業務的應用。而這些豐富的賦能業務的資料應用必須依賴資料中台提供的強大的資料服務來支撐。
圖3-5 某電信營運商資料倉庫分層模型
圖3-6 阿裡巴巴資料中台總體架構圖
通過上面的對比不難看出，資料中台與資料倉庫最大的差別就是資料中台更加貼近業務，不隻提供分析功能，更重要的是為業務提供服務，與業務中台或者業務系統（老舊系統）連接配接更加緊密了。就拿大家比較熟悉的“千人千面”案例來說，除了要整合業務系統産生的使用者基礎屬性、訂單、評價、加入購物車等行為資料，還要通過埋點的方式實時擷取使用者偏好浏覽、搜尋、分享商品等行為資料，經過資料中台對一系列的資料進行加工處理（見圖3-7），最終以微服務的形式提供支援。在業務系統中，每個需要呈現商品給目标使用者的資料服務，已不是簡單地、一成不變地去商品庫查詢資料，而是調用資料中台提供的商品推薦接口，以此來根據不同的人群偏好、浏覽曆史、商品相似度等資料來為每個人推薦他最感興趣的商品。試問這種業務、資料緊密關聯的場景在資料倉庫時代又如何能做到呢？
圖3-7 資料中台與外部系統互動
在介紹完資料中台與資料倉庫的差別之後，我們再回過頭談談資料中台到底是什麼。首先說說資料中台不是什麼。
第一，資料中台不等于大資料。近些年來，“大資料”這個名詞可能是被提及最多的詞彙之一，大資料甚至成為國家戰略。同時，“資料中台”也正是在大資料概念興起之後應運而生的。是以，相當一部分人把資料中台和大資料劃等号，一提到資料中台，就想起Hadoop、Spark等大資料處理技術，這樣的想法是不對的，這些大資料處理技術隻是資料中台的基礎設施提供者。大資料技術大行其道，加速了資料中台戰略成熟。
第二，資料中台也不是一個研發工具。最近一段時間，在市面上流行着一種說法，說某某公司有一個資料中台産品，可以直接賣給某某客戶。這種說法是在忽悠客戶。實際提供給客戶的僅僅是一個可視化的研發工具而已。資料中台一定是整合了企業自身資料并經過加工、治理後形成企業自身的資料資産的平台。試問，根本還沒了解客戶到底有什麼資料的情況下，如何能說自己有一個資料中台産品呢？
那麼如何定義資料中台呢？我們也曾嘗試在網上找到一個标準答案，也曾找過首倡“資料中台”概念的阿裡大咖們尋求标準答案。最近網絡媒體上各種資料中台分享、峰會紛紛擾擾，各種解讀真是亂花漸欲迷人眼，但都沒有得到一個很精煉、标準的關于資料中台的定義。但越是沒有标準，越是被人問得多，這就是為什麼開篇提到的第一個問題就是“什麼是資料中台”。
經過這些年來對資料中台的一腔熱血，我們也曾經為此翻閱大量資料，力求言簡意赅，力求精準定義。我們認為：資料中台是一個用技術連接配接大資料計算存儲能力，用業務連接配接資料應用場景能力的平台。
“連接配接能力”是資料中台的精髓。作為一個處在中間層的能力平台，“連接配接”是其根本任務。在業務層面需要盡可能連接配接各種資料源作為其生産資料；同時，由于生産資料的場景越來越多，覆寫了線上、線下等多管道，各資料生産資料之間也需要進行連接配接，才能形成全域的資料；資料在資料中台這個平台上按照标準的模型進行規範加工處理後需要服務于多種場景，同樣需要我們提供标準的資料服務接口将資料與應用場景連接配接起來。是以，連接配接是資料中台的根本能力，也是資料中台的價值所在。
3.3.4 業務中台和資料中台的關系
無論是業務中台還是資料中台，都是在企業IT系統架構演進過程中形成的，并從企業自身IT系統規劃、建設、營運、運維等多年的經驗中提煉出來的共性能力。業務中台和資料中台作為兩個輪子并肩建構了數字中台，支撐前台對會員提供從營銷推廣、轉化交易到智能服務業務的閉環服務，促進企業業務的提升和發展，如圖3-8所示。數字中台對内連接配接企業的背景系統，諸如ERP、人力資源、協同辦公、财務管理等。
業務中台抽象、包裝和整合背景資源，轉化為便于前台使用的可重用、可共享的核心能力，實作了後端業務資源到前台易用能力的轉化，為前台應用提供了強大的“炮火支援”能力，且随叫随到。業務中台的共享服務中心提供了統一、标準的資料，減少了系統間的互動和團隊間的協作成本。
圖3-8 業務中台與資料中台雙輪驅動的數字中台支撐前台業務
資料中台接入業務中台、背景和其他第三方資料，完成海量資料的存儲、清洗、計算、彙總等，構成企業的核心資料能力，為前台基于資料的定制化創新和業務中台基于資料回報的持續演進提供了強大支撐。可以認為，資料中台為前台戰場提供了強大的“雷達監測”能力，實時掌控戰場情況，料敵先機。不過資料中台所提供的資料處理能力和在之上建設的資料分析産品，也不局限于服務業務中台。資料中台的能力可以開放給所有業務方使用。
從前台應用的角度看，業務中台所提供的“炮火支援”能力和資料中台所提供的“雷達監測”能力是一體的，并不是互相獨立的。業務中台與資料中台相輔相成，互相支撐。對于業務方來說，自己産生資料，并同時消費自己的資料，在消費自己的資料時又在繼續産生資料，進而形成資料閉環。打個比方，業務沉澱資料是産礦，将資料導入資料中台是探礦和挖礦，資料中台對資料進行模組化等加工處理是對礦物的加工提純，通過資料服務指導業務的開展是礦産再生的過程。業務中台和資料中台隻是技術實作方式不同，它們一起組成了支撐業務創新的兩個“輪子”，缺一不可。
3.4 中台的發展與進化
中台的存在價值是為它的客戶服務，比如業務中台和資料中台要快速響應前台應用的需求。但如果中台同時服務于多個前台應用，在資源有限的情況下，必然涉及對來自不同應用的需求的優先級排序和取舍。如果前台應用急需某一能力，但中台又不能及時提供，是否允許前台先實作，等中台有時間再來沉澱？由此可以看出，大中台立足于橫向的、全局的長遠考慮，而小前台則注重于解決縱向的業務應用的目前問題。大中台的發展必然涉及權衡，但如何做取舍沒有标準答案，需要結合實際情況進行。
3.4.1 中台的演變
中台的催生基石是能力共享。如果中台所提供的能力無法被共享，那就不是中台能力。如果中台隻服務于一個前端應用，那就不是中台。那麼哪些能力比較通用且是多個前台系統的共性需求？要回答這個問題，可從系統的組成開始分析，如圖3-9所示。一個應用系統首先是為使用者服務的，是以最先離不開的是系統的角色和使用者。是以，建設中台的一個起步點就是先将角色和使用者這些資源管理起來，形成使用者共享中心。統一使用者、統一權限、統一登入，可以看作是中台的雛形，但如果僅僅停留在此階段，就退化成了單點登入。在此基礎上，再發展與人相關的會員系統，比如會員的積分、積分的變動、會員的等級等就形成了會員中心。再者，使用者是通過商品、訂單與系統進行互動的，是以，商品的管理、訂單的集中處理也是可以一起共享的。這些資源的統一集中管理後，相關的使用者、會員、積分、訂單等資料被存儲在一起，友善全局管控。進行集中管理的資源越多，建設中台所取得的成果就會越大，就越能展現中台對前台應用的支撐作用。
圖3-9 中台建設的三個步驟
在資源集中管理的基礎上，更重要的是抽象出系統能力。抽象是指在考慮目标事物時，去除表象的、次要的方面，而抽取相同的、主要的方面，進而做到從個别中把握一般規律。通俗一些的說法就是将目标事物模型化。隻有通過抽象，設計出來的能力才能應用到類似的需求中。
中台是為前台業務服務的，是以目前台業務有所更改時，中台要随需而變。這就要求中台具有很好的靈活性來支撐業務的開拓和發展：
1）資料模型需要根據前台業務要求實作可擴充性。
2）業務流程可根據場景和需求重新定義和編排，并可通過插件機制進行定制。
3）中台環境需要支援多環境可部署。比如不同的基礎設施環境，包括公有雲、私有雲及容器雲等；再比如不同的微服務架構，如阿裡雲的EDAS、開源的SpringCloud、Dubbo等。
中台的建設不是從零起步，但是中台是為業務服務的，是需要根據企業業務演進逐漸積累而成的。是以中台的建設不是一蹴而就的。
3.4.2 中台生态的形成
中台是企業級共享能力平台，是以除了最開始提出的業務中台和資料中台，還會逐漸發展出技術中台、研發中台、移動中台、AI中台、算法中台、組織中台等其他中台。
技術中台整合和包裝了雲基礎設施，以及在其上建設的各種技術中間件，比如微服務、分布式緩存、消息隊列、搜尋引擎、分布式資料庫等，并在此基礎上建設和封裝了簡單易用的能力接口，如圖3-10所示。技術中台的建設标準是參考在一個隻提供虛拟機或容器的私有雲上，建設一個業務中台或資料中台所需但私有雲沒有提供的技術相關元件。技術中台作為工具群組件，為建設前台應用和業務中台提供了基礎設施重用的能力，大大縮短了它們的建設周期。如果數字中台（即業務中台+
資料中台）是強大的中台炮火群，則技術中台提供的是如何根據需要快速搭建中台炮火陣地（即建立和部署不同環境下的中台）。
如何讓陣地建設得更加可靠、簡捷易用（通過技術中台提供資源的動态擴充能力等）？隔離數字中台對基礎設施的依賴。比如業務中台的每個業務服務中心都需要關系型資料庫。關系型資料庫要提供一主一備和自動切換功能，以及讀寫分離和隻讀庫建立的能力。為了快速通路大資料量的表，一般需要使用分布式資料庫對其進行分庫分表操作。分布式緩存是提高通路效率的一個必不可少的元件。通過消息隊列實作異步解耦和大流量削峰填谷，這大大增強了前台應用應對大使用者并發的能力。使用CDN加速的對象存儲，可極大提高前端通路的性能。數字中台是在技術中台的基礎上開發、運作的，但又不能與技術中台綁定。因為數字中台關心的是如何滿足業務要求，而技術中台提供基礎設施底層的能力，兩者互相促進但又互相隔離。
圖3-10 技術中台
研發中台是關注應用開發效率的管理平台，如圖3-11所示。軟體開發和系統建設是一項工程，涉及項目管理、團隊協作、流程、測試、部署、營運、監控等方面。如何将在企業應用開發過程中的最佳實踐沉澱為可重用的能力，進而更好地快速疊代開發創新型的應用，也是很多企業目前的一個關注點。這個關注點也是企業能力的展現，即研發中台。研發中台為應用開發提供了流程和持續傳遞的能力，包括靈活開發管理、開發流水線、部署流水線、持續傳遞。靈活管理一般由問題、疊代、實施等組成，并管理研發人員的日常工作和任務。開發流水線則涉及源代碼的版本管理、分支的建立、合并和送出，半成品的建構、存儲和使用以及産成品的建構。将産成品部署到指定環境并上線運作是部署流水線的職責。線上的應用需要監控，包括基礎設施監控、應用監控、日志洞察、浏覽器監控、鍊路分析和追蹤等功能。研發中台為應用的開發提供了流程、品質管控和持續傳遞的能力。
圖3-11 研發中台
消費者接觸得最多的企業前台觸點在移動端。如何保障移動端的疊代效率和穩定性也是企業需要着重考慮的。一個電商業務一開始可能隻是一個工具型的App，完成對商品全生命周期的閉環支援。随着在業務中台基礎上發展出相似業務，需要平台級的移動端開發支援。繼續深化發展可能還需要支援多業态。是以為快速開發移動App、H5和小程式以支撐前台業務發展所進行的最佳實踐就逐漸沉澱為移動中台，如圖3-12所示。
1）移動App與其他前端技術比較，有其特殊性。比如移動App作為一個C/S架構，其發版模式需要通用應用市場的稽核，而其用戶端的更新是使用者控制的，提供遠端配置、動态更新有助于控制App端。
2）移動業務是線上業務，對網絡存在強依賴，而移動鍊路本身的穩定性和連通率等相比有線網絡有一定的不足，是以消息推送的實作需要考慮網絡因素。
3）因移動端品質相關問題，需要提供熱修複等功能。
4）對移動App本身的安全掃描和加強也是一個需要着重考慮的因素。由于前端有不同的實作技術，如果完全使用不同的開發方式，對于企業來說是重複投入，且資源和技術不能共享。是以，使用Hybrid混合開發的方式，既可以支援移動App，又可以支援H5，甚至小程式，這也是移動中台需要研究的一部分。是以，盡可能将前端元件化，比如UI元件和圖表元件，在此之上組裝成業務元件，能大大提高移動端開發效率和品質。
圖3-12 移動中台
前面所提的業務中台、資料中台等都是從技術系統層面展開的中台演變。企業在進行中台建設時，容易着手的也是對技術體系的改進。但要發揮中台的能力，讓中台戰略實際落地到企業，并為企業的業務目标服務，需要有與中台技術架構相比對的組織架構。從Supercell 的“部落”，比如阿裡巴巴的共享業務事業部、資料平台事業部，京東的前、中、背景，大家都可以看到建設中台需要兩手抓，兩條路線相比對，齊頭并進。如果将業務中台、資料中台等稱為“戰鬥部隊”，那麼為企業提供的項目投資管理、風險管理、資源排程等的組織中台則是“戰場指揮部”，指揮前線，排程後方。
“大中台，小前台”這種組織形式，并不是什麼新鮮事物，實際上它是一種理想化的支撐模式。前台業務足夠靈活，配套支撐足夠快捷，資源還能夠高效複用。不過要讓中台模式在企業中發揮作用，對企業本身也是有一定要求的，比如企業有一定規模，業務比較豐富，值得去提煉共性元素形成共享能力。如果同時開展多種相類似的業務，那麼從業務A提煉出來的能力可能提供給業務B使用；或者雖然業務單一，但同一業務在不同地域有不同的模式，也能沉澱出很多共享能力。
資料中台提供了資料分析報表來響應營運，并在此基礎上提供資料能力直接服務于業務。那能不能更進一步，提供諸如個性化服務等與智能相關的能力？答案是肯定的，通過AI中台就可實作。AI中台借助資料中台的能力，嘗試解決模型的訓練、釋出，智能服務的建構自動化，統一的中繼資料管理體系，模型的全生命周期管理等問題，通過AI能力平台化，降低對人員能力的要求。與資料中台利用CPU級别的資源不同，AI中台需要擴充對GPU資源管理和整合能力，為算法模型的開發者、訓練者、标注管理者、資料管理者等建構智能服務的人員服務，并最終為業務人員提供智能化的服務。
3.4.3 中台與前台的博弈
中台通過提供基礎服務和解決方案為前台業務應用提供服務。中台的職責是不斷提升整體平台的服務能力基線。根據中台對前台業務的支援與參與度不同（見圖3-13），會産生不同的中台建設路徑。
圖3-13 中台對業務的參與度
一個極端了解是中台是工具，即将中台作為工具平台來建設。由于工具的通用能力強，抽象層度高，是以工具可适應各行各業的企業。如此，中台的研發人員可隻專注技術相關的問題，而無須關注和了解企業本身的業務。但是正由于工具無法深入業務場景，也不内含業務能力，導緻中台不能沉澱業務，進而使中台開發人員與業務方溝通不順暢，中台方無法直接為業務賦能。為了解這個問題，需要一個長期的業務了解和系統建設過程。
另一極端是中台完全為業務服務。中台方能快速了解業務需求，參與業務方的資料模型讨論、流程設計等，并将其變成系統實作。中台研發人員參與業務建設，符合中台為業務服務的目的，而且中台的能力也是通過業務沉澱下來的。但是過分關注業務，過分與業務團隊耦合，會受限于時間和團隊的能力，不僅中台可能會沒有考慮通用的業務能力，也會導緻無法更專注于對中台技術的深入研究。中台如果不從抽象度、适配性等角度出發，投入建設機制性的工作，很有可能局限于某單一業務，導緻中台無法很好地适應其他相關業務的要求，進而不能很好地應對業務的變化。
目前很多宣傳中描述的資料中台走到了圖3-13所示的最左側：把資料建設的工具稱為資料中台，或把資料治理、資料模組化等工具宣稱為資料中台（其實隻是片面地在了解資料中台）。中台最主要的能力是提供業務方可重複使用的并與業務相關的能力。資料工具的能力太泛化，會導緻與業務方的距離太遠，進而不能很好地為業務方賦能。
從曆史發展來看，一開始企業建設了一個前台應用A（如
圖3-14所示）。随着業務的發展，擴充到類似的業務，由于業務快速發展的需要，很有可能重新開發另一個前台應用B。但随着應用B的建設，發現應用A和應用B的很多功能和能力是重複或相似的，是以考慮是不是可以通過建設公共的部分，避免重複投入和建設。由不同前台應用抽取出來的公共部分即為中台。但是中台建設是一個新的命題，需要更強有力的團隊，需要不斷探索。如果中台研發團隊的研發能力和時間進度無法跟上前台業務的需求變化，那麼中台就隻能滿足部分前台業務的需求。再者，如果中台的抽象程度低、擴充性差，則會導緻中台無法滿足前台業務需求。這時前台應用又因為業務本身的發展目标和壓力不得不自行組織團隊完成這部分功能，由此可能發生本應由中台提供的能力卻最終實作在業務應用中。中台越做越小，前台應用越做越大。這樣一來，進一步壓縮了中台的生存空間。
圖3-14 中台與前台應用的關系
是以，中台既需要滿足業務的需求，但又不能過度參與業務。中台能力的建設首先要保證投入到中台的資源不能成為業務建設的瓶頸。中台提供的能力要具有靈活性和可定制性，便于業務方根據規範自主完成，減少溝通成本，提升效率。
“大中台，小前台”，并不意味着前台不重要。相反，建設大中台就是為了更好地服務于小前台。大中台要想發揮作用，展現出自己的價值，必須通過小前台的引導。是以，判斷中台建設是否成功的名額應包括：前台有沒有使用中台，前台從使用中台中獲得了哪些好處，中台好不好用，願不願意繼續使用中台。
3.4.4 中台的進化政策
雖然中台概念的提出到現在僅幾年時間，但中台已經在這幾年中走出了自己的路徑。根據中台的進化和演變的曆史及可能的方向，目前可以看到共有廣度和深度兩種途徑，如圖3-15所示。
圖3-15 中台的廣度和深度兩種進化政策
廣度是指中台所涉及的内容會越來越多，即可以認為各種中台的不斷出現，也可以認為是一個中台内部的共享服務中心會不斷橫向擴充，從一開始所提的業務中台、資料中台，逐漸演化到AI中台、技術中台、研發中台等。另一方面，一個中台範圍内的共享能力也在擴充，從使用者中心、交易中心、營銷中心等擴充到内容中心、工單中心、成長中心等。中台團隊如發現某一前台業務模式很好，則将其沉澱為共享服務，進而提供更多的業務，這也是在建設和加強中台。由于中台作為中樞點同時支撐多個前台業務，是以中台成為打通前台業務的最好着力點，讓不同的前台業務可以互相借力和引流，互相促進發展。
中台所沉澱的共享服務能力并不要求支撐所有前台業務，隻要有多于一個前台業務需要某一種能力，此能力即可沉澱為中台能力，是以我們不能大而全地建設中台。如果企業認為現在企業各系統的使用者管理能力需要統一，那就可以着手進行使用者中心的建設。在此基礎上，如果企業發現會員需要統一管理，訂單需要全局視圖，那麼就建構會員中心和訂單中心。是以，中台的建設是可以分階段逐漸實施的，無須将所有重構全部一起推動，而後者既會增加複雜性，又會提高風險，還不能及時得到回報。
中台的成長離不開前台業務的創新。隻有不斷進行業務疊代和更新試錯，對中台提出新的挑戰和沉澱，才會讓中台做得更好。另一方面，中台團隊也需要有自己的産品化、平台化建設思考，并作為新業務的孵化器。
中台還需要建設成為開放的體系。開放不僅僅是對企業内部開放，也要對企業外部開放。通過中台建設，企業可以将自有的系統變為開放式平台，進而為其他企業充分提供第三方的資料和服務。再者，中台本身通過開放也可以充分利用其他第三方資料和服務。開放可以接口的方式，通過開放API，開創新的商業機會和應用模式。
中台的開放也意味着中台需要支援個性化需求。通過抽象能沉澱共性的流程、資料模型等。但不同業務總有不同點，這些不同的需求就需要個性化的支撐。中台和前台一般是由不同團隊負責的。是以為了提高效率，中台必須留出足夠靈活的擴充點，以便不同前台業務根據其需求進行定制化擴充。
中台作為平台，必然需要考慮拆分整體應用形成業務元件，通過業務抽象模組化，解決共性的問題，進而更好地為業務服務。對業務問題的抽象程度越高，中台對業務的适配度就越高，需要對具體業務參與度就越低，進而更能發揮中台及中台團隊的價值。因為越好的抽象越能發揮業務應用開發的創造性。在考慮拆分的同時，必須設計整體架構群組裝政策，即元件間的協作機制。通過協作機制，才能讓各業務元件協同實作業務場景以達到業務目标。
中台作為一個平台，其本身的營運也需要資料支撐。比如需要統計和觀察中台以API形式提供的共享能力，進而了解中台哪些能力被業務引用及引用的頻率，所使用的參數模式等；哪些設計的接口能力沒有用處等。有了實際的資料，可更好地疊代中台。
中台建設是一個綜合性的系統工程，是以需要有效的方法論的指導。中台建設方法論會在後續章節專門讨論。