本文來源 / 51CTO官微
講中臺之前，我想有必要先說說什麼是產品實現機制的前臺和後臺。
所謂前臺就是用戶直接接觸到的產品部分，如可在應用商店下載的APP，像微信、抖音、淘寶，或者可以使用的網站等。用戶對產品的認知與體驗也由此而生。比如大家對於微信的理解就是這個前臺APP給大家展示的一切。
而後臺包含兩個部分：
- 企業的內部管理服務的統稱，如：內部的CRM，ERP等；
- 為前臺提供服務能力的，如：數據壓縮能力，併發等。
後臺最重要的特點就是其提供的服務都是不被普通用戶所感知的，就像用戶不會因為應用的併發，傳輸速度而記住微信這個品牌。
在搞清楚了前臺與後臺的概念後，前後臺模式的產品服務模式我們就可以用一張圖來概括描述：
總的來說就是：後臺提供能力與計算，前臺將後臺的能力進行封裝以圖形化的形式展示給用戶，讓用戶能更容易的使用公司提供的服務來解決個人需求。
在廚房裡，配菜小哥就是中臺
實際上，中臺的出現更多是因為公司業務在發展到某一階段時，在擁有多個業務線時繼續發展遇到瓶頸與障礙後，為了解決如何繼續朝下走的實際問題而提出的一個組織前臺業與後臺關係新解決方案的統稱，而不是某個新的系統。
在互聯網進入日益複雜的市場環境的今天，市場中由於存在眾多的競爭者，也逼迫著企業需要不斷去更新產品去搶奪市場。而作為實際用戶真正接觸的前臺業務，如：APP、小程序、網站等，必須要快速迭代新的功能才能讓用戶感知到。
而在這個大背景下帶來的矛盾就是——以往為了支撐前臺越來越多的業務，後臺不斷地建設龐大起來的系統，由於一直在追求穩定性而生，反而在這個時候顯得越發笨重起來。這樣的後臺變得越來越沒法去快速響應前端變化所帶來的改變。原先的前後臺模式的這種直接關聯決定了兩者的衝突不可避免。
中臺解決方案到底是什麼呢？讓我們舉個通俗的例子來說，如果將互聯網公司的研發中心比作一個廚房，將研發新產品的過程比做菜的話，我們就可以很容易理解這個概念了。
首先請大家想一個問題，在一家客流量非常大的餐廳中我們要如何縮短客人的等待時間呢？
相信很多人的第一想法就是增加多名廚師，但時大多數的餐廳單純的增加廚師這是不實際的，因為每增加一個廚師是有很高成本的，而且每天忙的就是中午和晚上這兩個時間點，雖然在飯點解決了問題，但是在一天中其他的時間裡，廚師人員就顯得非常冗餘了。
而正確的做法是先將做菜這個任務拆分，讓做菜這一件事變為多個環節來思考，我們完全可以只需要增加一位配菜的小哥來代替廚師去進行前兩步，這也就是現在大多數上規模餐廳的組織架構：
這樣我們每一位廚師新做一道菜時沒有必要一定要從買菜，洗菜，切肉這些最基礎的環節開始，而是完全可以直接使用他人切好的肉片，洗好的菜下鍋，唯一需要關心的就是如何在搭配調料上研究不同的創意，這完全可以大大提高廚師的做菜速度，同時在成本上我們只增加了一個人就解決了所有問題。
回到研發流程來看，買菜其實就是我們研發的後臺，他們幫助我們解決最基礎原料問題。廚師是我們的一個個業務前臺團隊，他們要做的就是根據不同地區口味烹飪出對應的菜系，而在業務多元化後洗菜，切菜，配菜都可以交給中臺解決方案去完成，做菜的時候作為大廚只需要喊一句要什麼材料既可，當然這裡的配菜小哥就是我們的中臺。
如何培養中臺思維
從產品層面，中臺本質上是將後臺的邏輯層抽象出來的一種系統模塊，其目的在於快速的支持業務發展，因此，個人認為，中臺實際上是站在“快速響應需求迭代”角度的一種產品設計思維。
當系統足夠龐大時，產品、業務和用戶的每個需求都會涉及到多個系統關聯，尤其是針對多事業部的公司，這些系統都分佈在不同的事業部，所以難免會有一些問題：
1.系統複雜，無法快速拿出產品方案
2.多重對接，溝通成本巨大
3.系統間耦合性較大，牽一髮而動全身
基本上因為以上問題，新的業務需求無法快速滿足。當一個業務訴求牽涉到系統較多時，需要對應配合的人數太多。因此，從產品/系統角度，我們就需要考慮以中臺化的思維去進行方案設計：
通用性
對於業務需求，要跳出需求看本質，理解業務方的真實需求是什麼；要跳出模塊看全局，理解這個需求的實現，除了對消費者、商家的價值，要看到它對平臺的價值。
例如之前負責的訂單導出功能，其實用戶需求很簡單：快速導出數據，進行業務分析，但是站在平臺角度，平臺富有對用戶數據保護的義務，因此需要考慮從數據及用戶層面做權限控制；同時也考慮到商家不僅需要導出訂單，後續可能導庫存、商品及其他業務數據，因此需要考慮產品的通用性，以降低後續開發的成本。作為平臺型產品經理，要通盤思考整體的結構，才能做到互不牽連。
結構化
在方案設計上，要做到通用性，需要將通用能力從解決方案中抽離出來，與業務場景進行解耦，從而實現“業務場景-通用能力”系統架構。
還是拿訂單導出舉例，剛開始設計訂單導出時，權限控制，導出任務創建，導出數據下載，訂單業務耦合，其他業務接入時費事費力，還有可能對現有業務產生影響。因此才將訂單導出的通用能力從業務場景中解耦出來。
標準化
將通用能力與業務場景解耦只是第一步，我們要將通用能力進行打包，形成一套標準化模版，以接口化的形式賦能到外部的業務場景，供業務場景按照標準化的形式進行接入和開發，降低其他業務導出的開發成本。
以訂單導出舉例，我們將“權限控制”，“創建導出任務”，“下載導出數據”封裝為不同的接口，形成導出中心，提供給不同的業務場景。
可拓展
到這一步，已經形成了“單通用能力對應多業務場景”的系統架構，若業務側有定製化需求，可從業務場景角度進行單獨定製，以致於不會對其他業務場景產生影響，也提升了定製化需求的研發效率。
正在思考的數據中臺
所謂數據中臺，即實現數據的分層與水平解耦，沉澱公共的數據能力，筆者認為可分為三層，數據模型、數據服務與數據開發，通過數據建模實現跨域數據整合和知識沉澱，通過數據服務實現對於數據的封裝和開放，快速、靈活滿足上層應用的要求，通過數據開發工具滿足個性化數據和應用的需要。
這個圖只是John思考的一個點，如何有效的講數據打通，主體是建立更完備的用戶畫像。也許我的目的就達到了。
中臺是什麼真的不重要
以用戶為中心的持續規模化創新，是中臺建設的核心目標。企業的業務響應能⼒和規模化創新能力，是互聯⽹時代企業綜合競爭⼒的核⼼體現。平臺化包括中臺化只是幫助企業達到這個目標的⼿段，並不是⽬標本身。
中臺(⽆論是技術中臺、業務中臺還是組織中臺)的建設根本上是為了解決企業響應⼒困境， 彌補創新驅動快速變化的前臺和穩定可靠驅動變化週期相對較慢的後臺之間的⽭盾，提供⼀箇中間層來適配前臺與後臺的配速問題，沉澱能⼒，打通並順滑鏈接前臺需求與後臺資源，幫助企業不斷提升用戶響應⼒。
所以，中臺到底是什麼根本不重要，如何想方設法持續提高企業對於⽤戶的響應⼒才是最重要的。⽽平臺化或是中臺化，只是恰巧走在了了這條正確的⼤道上。
閱讀更多 啟迪雲Tuscloud 的文章
