中臺究竟是什么？它對于企業的意義又是什么？當我們談中臺時，我們到底在談些什么？

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

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

第一個問題：企業為什么要平臺化？

先給答案，其實很簡單：

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

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

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

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

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

在互聯網時代，商業的斗爭就是對于用戶響應力的比拼。

我們來看?個例子:

1、阿里

說起中臺，最先想到的應該就屬是阿里的“?中臺，?前臺”戰略。阿里?通過多年不懈的努力，在業務的不斷催化滋養下，將自己的技術和業務能力沉淀出一套綜合能力平臺，具備了對于前臺業務變化及創新的快速響應能力。

2、華為

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

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

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

第二個問題：企業為什么要建中臺？

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

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

先定義一下前臺與后臺

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

前臺：由各類前臺系統組成的前端平臺。每個前臺系統就是一個用戶觸點，即企業的最終用戶直接使用或交互的系統，是企業與最終用戶的交點。例如用戶直接使用的網站，手機 app，微信公眾號等都屬于前臺范疇。

后臺：由后臺系統組成的后端平臺。每個后臺系統一般管理了企業的一類核心資源（數據+計算），例如財務系統，產品系統，客戶管理系統，倉庫物流管理系統等，這類系統構成了企業的后臺。基礎設施和計算平臺作為企業的核心計算資源，也屬于后臺的一部分。

后臺并不為前臺而生

定義了前臺和后臺，對于第二個問題（企業為什么要建中臺），同樣先給出我的答案：

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

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

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

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

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

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

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

所以，隨著企業務的不斷發展，這種“前臺+后臺”的?輪速率“匹配失衡”的問題就逐步顯現出來。

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

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

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

在這份報告中，Gartner 提出，企業構建的系統從 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 斷層，我們即可以將早已臃腫不堪的前臺系統中的穩定通用業務能力“沉降”到中臺層，為前臺減肥，恢復前臺的響應?；又可以將后臺系統中需要頻繁變化或是需要被前臺直接使用的業務能力“提取”到中臺層，賦予這些業務能力更強的靈活度和更低的變更成本，從而為前臺提供更強大的“能力炮火”?援。

——這就是為什么企業在平臺化的過程中，需要建設自己的中臺層（同時包括技術中臺，業務中臺和組織中臺）。

華為的數據中臺建設方案（文末附下載鏈接）

阿里的數據中臺建設方案（文末附下載鏈接）

根據阿里云發布《數據中臺交付標準化》白皮書，基于對數據中臺交付的挑戰分析和多個行業的實踐經驗，提出了“1+3+3+1”的交付標準參考框架、標準化技術要求和交付標準體系。

同時，白皮書詳細分析了某行業客戶數據中臺標準化交付的典型案例，是數據中臺交付的方法、工具、平臺等體系建設方面的重要實踐指引，同時促進數據中臺交付標準持續迭代。

數據中臺交付“1+3+3+1”框架

白皮書指出，數據中臺是業務與技術的結合點，其基于產品化的運營思路，跑通數據流轉之后，服務于業務前臺，企業基于對數據的洞察優化業務方向，并通過反饋回來的業務數據再次輸入數據中臺，持續提升中臺使用價值，實現數據和業務不斷的正向循環和相互促進。數據中臺需要不斷的打磨、開發和持續運營，在不斷實踐的過程中企業也會建立起走出經驗主義、走入數據管理的核心邏輯。

數據中臺交付技術服務挑戰

挑戰1：數據中臺交付專業要求高

白皮書指出，企業家面臨最大的確定性是如何應對巨變時代的不確定性，未來十年全球數字經濟最重要的主題之一是數字基礎設施的重構、切換與遷移以及基于新型數字基礎設施的商業生態再造。今天越來越多的企業因管理失衡、市場失焦、營銷失語、系統失靈、增長失速等方面的風險而進行數字化轉型，進行數據中臺建設。

然而，實踐表明，數據中臺建設經常遇到客戶預期過高、低估困難、押注外力等情況；客戶想要服務商以標準專業的交付體系，以專業能力指導項目高質量完成，甚至是從各個維度以最佳實踐和未來驅動的思想引領客戶進入數據智能的全新時代。實際上，數據中臺技術服務提供商因行業經驗、專業人員、方案成熟度等方面的不足，導致以客戶價值為中心的定制化需求服務面臨巨大挑戰。

挑戰2：數據中臺交付過程管控復

數據中臺的建設是業務和技術雙輪驅動的，基于業務價值需求導向，企業在進行數據中臺建設時通常會以數據統一化、標準化、資產化等為手段，進而實現數據面向全業務開放賦能，所以數據中臺建設內容基本都會涉及不同程度的數據治理、數據服務、數據應用、管理流程制度、數據運營及上下游業務協同等，這樣以來其交付周期一般以數月為最小單位，加上以下方面原因導致交付內容和過程管控困復雜。

1）數據中臺項目交付一般都要涉及咨詢、業務、數據、技術、運營等，交付技術覆蓋范圍廣、資源需求大；同時，客戶服務需求的多樣性及服務商專業人員儲備不足，導致數據中臺設計和落地實施存在諸多質量問題和不確定性；

2）在交付過程中，從需求調研、方案設計、開發實施到試運行，基本都是在線下由不同角色、甚至不同服務商完成的，缺乏項目交付全流程、全生命周期的數字化工作臺承載，很難實現對項目全局掌控，各個環節都容易出現不同類型的問題與挑戰；除項目前期需要充分準備與思考外，也需要項目交付人員的個人經驗與能力去把控項目進度與質量；

3）交付驗收周期長，根據各行業數字化轉型趨勢分析和阿里巴巴數據中臺交付實踐經驗發現，數據中臺技術服務從需求調研、方案規劃再到實施落地的整體交付周期以數月為單位，同時交付的業務價值及質量等級很難做到在線化、可視化評估。

挑戰3：數據中臺交付生態協同難

一般產品交付完成產品售賣和產品部署即可，而數據中臺交付是集成交付，包羅萬象，軟件、硬件、基礎設施、大數據平臺、數據資產、數據服務、數據應用、定制化開發等基本都涉及，導致交付復雜度高。

因此，數據中臺服務提供商需要建設數據中臺交付的生態體系作為支撐，形成合作模式，進行彼此資源整合應用，來應對日趨復雜的企業需求及規模化交付需求。

但是，數據中臺服務提供商之間在能力的匹配上有很大不確定性，而造成這種不確定性的原因往往集中在伙伴間能力成長差異性、伙伴內部對員工的不同組織架構帶來的不穩定性以及員工本人對職業路徑規劃所產生的波動性、伙伴對行業領域知識的缺乏。這些因服務提供商的知識和能力上的參差不齊，使得數據中臺交付生態協同難，進而導致企業對數據中臺交付的不確定性存在敏銳的感知。

數據中臺交付標準化參考框架

基于對數據中臺交付技術服務的挑戰分析和解決思路，白皮書提出了“1+3+3+1“的交付標準參考框架。

1個目標：即以業務價值為導向，實現數據中臺技術服務的標準化、在線化、規模化交付；

3個內容：即數據中臺技術服務包含數據咨詢規劃服務、數據資產建設服務、數據應用建設服務；

3個能力支撐：即交付標準流程、交付文檔集、交付工具集；

1個平臺：即數字化工作臺，數據中臺技術服務團隊和政企客戶通過數字化工作臺完成數據中臺項目交付。

數據中臺交付的標準體系

交付流程、交付文檔集、交付工具集是三位一體的能力支撐體系。基于交付流程動作及產出，沉淀交付技術資產，包含交付物、過程產出物、項目評審意見、階段性匯報總結等文檔。

通過對多個項目文檔的提煉抽象脫敏等手段，形成通用解決方案和行業解決方案。結合數據資產目錄劃分方法，進行文檔集的資產目錄構建，一方面做內部參考借鑒，另一方面為交付工具打造提供輸入。

交付工具集，基于通用解決方案和基礎產品開放能力，圍繞具體交付實施場景而構建，能有效降低數據中臺交付門檻，為交付動作執行提供武器彈藥支持，同時倒逼交付文檔集的不斷迭代更新。交付技術服務團隊包含業務架構師、技術架構師、數據產品經理及實施人員等，與政企客戶服務對象一起，基于數字化工作臺進行數據中臺項目在線化交付。

數據中臺交付標準化技術要求

標準，是在一定范圍內獲得最佳秩序，經協商一致，并經過人工機構批準，共同使用和重復使用的規范性文件”；數據中臺交付標準化，為是為了在交付前、交付中、交付后獲得最佳秩序，制定交付技術服務流程、業務動作、文檔模板、設計規范、工具平臺、服務角色、職責矩陣等的活動，以提升數據中臺交付效率與質量提升，支撐標準化、在線化、規模化的服務履約，保障客戶服務滿意度。

數據中臺交付各環節的交付任務

1、交付前階段

交付前階段包括交付前置環節，支持售前團隊進行數據中臺需求溝通及方案設計，提前識別交付風險，并提供規避建議，完成數據中臺項目簽約，保障項目交付履約。交付前置環節的交付任務包括需求方案、風險識別、交付評審和啟動規劃。

交付前置的質量管控要求包括：1）明確交付前置的團隊角色職責矩陣和分工協作；

2）提交覆蓋交付全流程的交付風險說明與規避建議文檔；

3）按照可交付性評審模板提交評審意見；

4）按照標準項目管理辦法啟動規劃，并提交啟動規劃會議紀要；

5）基于數字化工作臺進行上述交付文檔的提交和管理。

2、交付中階段

需求調研環節：需求調研環節基于工作說明書中的業務目標和范圍，從業務、數據、技術等方面對客戶的需求進行詳細調研，為交付實施提供需求輸入。需求調研環節的交付任務包括業務調研、技術調研和數據調研。

方案設計環節：方案設計環節基于需求調研環節的交付文檔和交付前置環節的項目交付工作說明書文檔，完成數據中臺業務藍圖設計、數據產品設計、架構設計、數據模型設計及測試方案設計，為開發實施提供輸入。

開發實施環節：開發實施環節基于數據中臺詳細設計方案，進行數據中臺平臺環境搭建、數據采集、代碼研發、數據回刷與校驗、數據服務研發與測試、數據應用研發與測試等交付實施工作。開發實施環節的交付任務包括數據集成、數據研發、應用研發、數據回刷和集成測試。

試運行環節：試運行環節確定試運行目標與范圍，制定試運行方案與運行保障機制，配置監控告警，處理試運行的缺陷及需求；明確交付質量要求，便于制定正式上線運行措施和管理規范，完成知識轉移，為轉維和終驗做準備。試運行環節的交付任務包括試運行和知識轉移。

3、交付后階段

交付后階段包括上線維保環節，制定上線方案和運營管理規范，完成數據中臺正式上線，制定維保方案，完成項目轉維和驗收。上線維保環節的交付任務包括正式上線、售后保障和項目驗收。

上線維保的質量管控要求包括：

1）明確上線維保的團隊角色職責矩陣和分工協作；

2）按照上線方案完成項目正式上線，并提交項目上線報告；

3）提交售后運維保障方案文檔，按照該方案并利用數據校驗工具完成交付轉運維；

4）需按照項目驗收管理規范完成驗收，并提交項目驗收簽字確認單；

5）基于數字化工作臺進行上述交付文檔的提交和管理。

結束語

隨著數據中臺在行業頭部及領先企業逐漸落地，服務商和生態伙伴經歷了各類業務場景能力沉淀過程，產品技術和實施方法日趨成熟，需求端對數據中臺的理解和信任逐步加深，行業增長勢頭明顯，市場規模迅速擴展。

在大型、頭部企業滲透率逐漸增加的同時，中小企業將成為服務商的重要增量市場。因此，提煉和總結數據中臺的服務內容，沉淀行業通用能力，形成標準化的整體解決方案，以助力中小企業數字化轉型，提升數據中臺服務商和生態伙伴的規模化交付能力，其重要意義不言而喻。

現階段，數據中臺技術已相對成熟，在數據中臺的交付實踐過程中，企業自身的資源配置能力、管理經驗、組織變革等成為高質量建設數據中臺的關鍵要素，這些要素的標準能力構建也迫在眉睫。

當然，數據中臺的涵義一直隨著發展而改變，但無論怎么變化，數據中臺交付標準化建設始終以時代發展的趨勢和業務需求為出發點，繼續圍繞要做什么、怎么做、產出什么、怎么衡量等為主線持續迭代演進，不斷將其推向新時代、新臺階、新高度。

阿里云數據中臺解決方案

華為云數據中臺解決方案