說起中臺，大家很容易想到阿里在16年提出的“大中臺小前臺”戰略，其實John現在也在思考搭建數據中臺的想法，所以現在結合自己的思考來寫寫這篇文章。

中臺價值就是——一切以快速響應需求為依歸。

一、中臺是怎樣誕生的呢？

其實中臺是想象出來的概念。中臺和產品經理職位一樣，中臺并不是一開始就有的，而是基于“前臺 后臺”的架構發展演變的，先說下前臺和后臺。

前臺：前臺是系統的前端平臺，是直接與終端用戶進行交互的應用層。拿電商平臺來舉例，我們日常使用的app、H5端、pc端以及小程序都屬于電商的前臺系統。

后臺：后臺是指系統的后端平臺，終端用戶是感知不到他的存在的。后臺的價值是存儲和計算企業的核心數據。例如供應鏈管理系統存儲商品及庫存數據、客戶管理系統存儲用戶信息。

產品經理都知道，用戶的需求是瞬息萬變的，用戶需求的變化決定了前臺系統需要快速迭代響應用戶需求，而前端的變化需要后端的變化來支撐，因此這就對后臺的快速應變產生了要求。而后臺設立之初核心目的并不是服務于前臺，而是提升后端數據的安全及系統的管理效率。

舉例來講：隨著業務的擴大后端存儲大量的合同、商品、訂單及用戶等私密數據，因為安全性及緣故，這些數據無法供前臺拿過來直接用，同樣也無法快速的改造系統來響應前臺的變化。因此，出現了“前臺為了用戶需求，期望系統不斷的快速迭代”與“后臺為了數據安全與系統穩定，期望系統趨于穩定”的矛盾局面。

在這一矛盾的局面下，為了滿足前臺的快速迭代需求和后臺的穩定性需求，偉大的架構師們，創造性的提出了“中臺”概念，核心是將后臺的邏輯層拆出來，形成”前臺（應用層）-中臺（邏輯層）-后臺（數據層）“的產品架構。在這一產品架構下，當前臺需求來臨時，中臺能快速的進行響應，從而提升了研發效率，降低了創新成本。

（圖片放大后再看哦）

傳統“前臺 后臺”系統架構

“前臺 中臺 后臺”系統架構

中臺并不是一開始就有的，而是系統為適應需求的快速迭代而產生的。具體來講，中臺其實是將系統的通用化能力進行打包整合，通過接口的形式賦能到外部系統，從而達到快速支持業務發展的目的。比如：

業務中臺，更多的是對業務的支持，比如客戶信息，組織信息、產品信息等，這些都來自某一個系統，且分別支持多個系統的業務。各個系統有相關需求時，需要重新開發。而業務中臺的作用就是省去開發，直接從中臺獲取相關功能。

數據中臺，利用獲取的各類數據、對數據進行加工，獲取分析結果，然后提供給業務中臺使用。數據中臺的數據來自各業務系統或者數據湖，有源數據、關聯數據、加工好的數據（已經整理的主題數據、算法、模型），再提供給業務中臺使用。以購物網站的推薦為例，數據中臺根據數據提供算法，然后業務中臺基于算法的結果，支撐關聯推薦。

從技術角度，中臺是為了搭建一個靈活快速應對變化的架構，可以快速實現前端提的需求，避免重復建設，這也是復合敏捷開發理念。從業務角度，根據中臺沉淀的能力，可以支持快速創新，業務更敏捷，以應對未來市場變化。相關業務板塊已經做好，那么底層只要組合一下即可，更加靈活和快速。所以歸根到底，我們必須需要結合企業的實際情況，走出符合企業戰略目標的中臺之路。不能盲目跟風，為了中臺而中臺。

二、怎么做中臺？

從產品層面，中臺本質上是將后臺的邏輯層抽象出來的一種系統模塊，其目的在于快速的支持業務發展，因此，個人認為，中臺實際上是站在“快速響應需求迭代”角度的一種產品設計思維。

當系統足夠龐大時，產品、業務和用戶的每個需求都會涉及到多個系統關聯，尤其是針對多事業部的公司，這些系統都分布在不同的事業部，所以難免會有一些問題：

系統復雜，無法快速拿出產品方案多重對接，溝通成本巨大系統間耦合性較大，牽一發而動全身

基本上因為以上問題，新的業務需求無法快速滿足。當一個業務訴求牽涉到系統較多時，需要對應配合的人數太多。因此，從產品/系統角度，我們就需要考慮以中臺化的思維去進行方案設計：

通用性

對于業務需求，要跳出需求看本質，理解業務方的真實需求是什么；要跳出模塊看全局，理解這個需求的實現，除了對消費者、商家的價值，要看到它對平臺的價值。

例如之前負責的訂單導出功能，其實用戶需求很簡單：快速導出數據，進行業務分析。但是站在平臺角度，平臺富有對用戶數據保護的義務，因此需要考慮從數據及用戶層面做權限控制；同時也考慮到商家不僅需要導出訂單，后續可能導庫存、商品及其他業務數據，因此需要考慮產品的通用性，以降低后續開發的成本。作為平臺型產品經理，要通盤思考整體的結構，才能做到互不牽連。

結構化

在方案設計上，要做到通用性，需要將通用能力從解決方案中抽離出來，與業務場景進行解耦，從而實現“業務場景-通用能力”系統架構。

還是拿訂單導出舉例，剛開始設計訂單導出時，權限控制，導出任務創建，導出數據下載，訂單業務耦合，其他業務接入時費事費力，還有可能對現有業務產生影響。因此才將訂單導出的通用能力從業務場景中解耦出來。

標準化

將通用能力與業務場景解耦只是第一步，我們要將通用能力進行打包，形成一套標準化模版，以接口化的形式賦能到外部的業務場景，供業務場景按照標準化的形式進行接入和開發，降低其他業務導出的開發成本。

以訂單導出舉例，我們將“權限控制”，“創建導出任務”，“下載導出數據”封裝為不同的接口，形成導出中心，提供給不同的業務場景。

可拓展

到這一步，已經形成了“單通用能力對應多業務場景”的系統架構，若業務側有定制化需求，可從業務場景角度進行單獨定制，以致于不會對其他業務場景產生影響，也提升了定制化需求的研發效率。

John正在思考的數據中臺

所謂數據中臺，即實現數據的分層與水平解耦，沉淀公共的數據能力。

筆者認為可分為三層：數據模型、數據服務與數據開發。通過數據建模實現跨域數據整合和知識沉淀，通過數據服務實現對于數據的封裝和開放，快速、靈活滿足上層應用的要求，通過數據開發工具滿足個性化數據和應用的需要。

這個圖只是John思考的一個點，如何有效的講數據打通，主體是建立更完備的用戶畫像。也許我的目的就達到了。

三、總結

以用戶為中心的持續規?；瘎撔?，是中臺建設的核心目標。企業的業務響應能?和規模化創新能力，是互聯?時代企業綜合競爭?的核?體現。平臺化包括中臺化只是幫助企業達到這個目標的?段，并不是?標本身。

中臺（?論是技術中臺、業務中臺還是組織中臺）的建設根本上是為了解決企業響應?困境， 彌補創新驅動快速變化的前臺和穩定可靠驅動變化周期相對較慢的后臺之間的?盾，提供?個中間層來適配前臺與后臺的配速問題，沉淀能?，打通并順滑鏈接前臺需求與后臺資源，幫助企業不斷提升用戶響應?。

所以，中臺到底是什么根本不重要，如何想方設法持續提高企業對于?戶的響應?才是最重要的。?平臺化或是中臺化，只是恰巧走在了了這條正確的?道上。

當然，這篇文章只是John的思考，純主觀思考。也許并不是這么去解剖，但是過程中去快速試錯，小步快跑或許能達到不一樣的目的。那咱們去試試。

作者：John，產品狗一枚，微信公眾號：產品狗聚集地。歡迎一起溝通交流。

本文由@John 原創發布于人人都是產品經理，未經許可，禁止轉載。

題圖來自Unsplash, 基于CC0協議