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

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

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

前臺：前臺是系統(tǒng)的前端平臺，是直接與終端用戶進行交互的應用層。拿電商平臺來舉例，我們?nèi)粘Ｊ褂玫腶pp、H5端、pc端以及小程序都屬于電商的前臺系統(tǒng)。

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

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

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

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

（圖片放大后再看哦）

傳統(tǒng)“前臺+后臺”系統(tǒng)架構

“前臺+中臺+后臺”系統(tǒng)架構

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

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

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

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

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

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

1. 系統(tǒng)復雜，無法快速拿出產(chǎn)品方案
2. 多重對接，溝通成本巨大
3. 系統(tǒng)間耦合性較大，牽一發(fā)而動全身

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

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

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

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

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

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

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

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

所謂數(shù)據(jù)中臺，即實現(xiàn)數(shù)據(jù)的分層與水平解耦，沉淀公共的數(shù)據(jù)能力。

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

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

以用戶為中心的持續(xù)規(guī)?；瘎?chuàng)新，是中臺建設的核心目標。企業(yè)的業(yè)務響應能?和規(guī)?；瘎?chuàng)新能力，是互聯(lián)?時代企業(yè)綜合競爭?的核?體現(xiàn)。平臺化包括中臺化只是幫助企業(yè)達到這個目標的?段，并不是?標本身。

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

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

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