編輯導語：中臺這一概念，這兩年在國內大熱，不少企業接連開始組織架構的調整，意圖建設中臺；中臺到底是什么？哪類企業可以搭建中臺？本文作者對中臺進行了非常詳細的分析，我們一起來看一下。

《中臺詳解系列》共分上下兩篇，本文為上篇，總計約8100字，因為文中涉及知識體系較為廣泛，建議預留20—25分鐘進行閱讀。

目前市場僅對“中臺”和“平臺”間的繼承和發展關系有一定共識，“中臺”的定義及建設規范尚未有明確定論；本系列文章旨在基于“以終為始”的思維模式，及“軟件對現實世界建?！钡幕A條件，梳理傳統軟件“平臺”所面臨的問題；并以此為起點，結合經濟學中專業化分工協作理論，為“中臺”進行職能定義，再通過“中臺”的職能定義給出“中臺”建設的建議方案。

18年初，我初次接觸到“中臺”概念的時候，也不免心馳神往了一番，畢竟即使在概念漫天飛的國內IT圈，“中臺”也算是天空中最亮的那顆星；現在臨近2020年末，近3年的時間如白駒過隙，期間我有幸參與了多個“中臺”項目，其中吉利汽車全球營銷業務“中臺”項目在整個阿里云“中臺”戰略中也算是比較成功的案例。

然而遺憾的是，“中臺”也未能逃脫國內IT圈大熱概念“站得越高，摔得越疼”的魔咒，年初茅臺拆除“中臺”的消息像一把利劍，戳破了“中臺”的泡沫；一時間各種“馬后炮”震耳欲聾，這也算對得起“中臺”一直以來的熱度，只是其中內容漏洞百出，讓人啼笑皆非。

有“顧名思義”說“中臺”是夾在前臺和后臺之間，起到承上啟下作用的：

有引用美國經濟學出版圖書《平臺戰略》來解釋“中臺”的：

節選自科技自媒體“技術領導力”推文

而作為一個過來人，我覺得有必要聊一聊自己的心得，以使得大家可以對“中臺”有更加客觀的理解。

老規矩，咱們還是按照“是什么”、“有什么價值”、“怎么做”的順序來聊。

一、什么是“中臺”？為什么要搞“中臺”？

有人說：現在大家爭論“中臺”樣子，跟當年爭論“云”一模一樣；顯然什么是“中臺”，市面上還沒有一個統一的說法，所以這里我自己給“中臺”下了一個定義：

“中臺”是對傳統“軟件平臺”的升級和加強，通過在企業層面引入新的專業化職能分工、數據唯一性建模等規則；在解決軟件行業“重復造輪子”問題的基礎上，進一步解決了傳統“軟件平臺”未能解決的“軟件平臺間職能邊界劃分問題”及“數據孤島問題”。

這里有幾個關鍵詞——“企業層面”、“軟件平臺”、“專業化職能分工”、“數據唯一性建?！?。

“中臺”是對“軟件平臺”的自然演進這一觀點，可以說在IT業界已經得到了初步的共識，阿里云的架構師也通過科技自媒體透露過阿里云對于這一問題的認知。

那“軟件平臺”到底是怎么演進成“中臺”的呢？“軟件平臺”又到底為什么要演進成“中臺”呢？相關工作又為什么要在企業層面完成？“專業化職能分工”、“數據唯一性建?！庇质鞘裁垂?？

鑒于所有的軟件及其背后的理論、原理、概念、技術都是為了解決業務問題而產生的，就讓我帶著大家一邊梳理“中臺”產生的業務背景，一邊揭開“中臺”的面紗。

圖片來自于阿里云業務中臺&云原生架構師“宇升”在自媒體上發表的《我們阿里內部是怎么做業務中臺的？》一文。

1. 信息化帶來甜蜜的煩惱

信息技術的發展對人類的影響是空前的，但對于效率的極致追求，使得人類在信息技術大規模應用后，又發掘出了一系列新的待解決問題；比如大家一致認為“中臺”核心要解決的問題——重復造輪子。

軟件研發重復造輪子的問題：

為了應對市場發展及用戶成長對業務增長帶來的負面沖擊，企業會拓展新業務，或將已經較為成熟的業務線拆分為若干條子業務線、若干子環節以開展精細化運營。

這些業務線、業務環節中，會有很多相似的業務內容，比如可能都需要廣告投放、商品展示、用戶激勵、訂單交易、支付收款等；不過不同業務線中相似業務的發生時間和細節要求并不一致。

以往為了追求效率，很多企業是通過不斷為不同業務線中的相似業務定制開發相似的功能來解決這個問題的——這就產生了重復勞動，會造成研發資源的極大浪費。

更要命的是，重復造輪子還會造成“次生災害”——運維成本的爆炸性增長。

重復造輪子造成高運維成本的問題：

一方面，針對不同業務線中的相似業務定制開發相似的功能，會導致相似功能的模型及代碼有很多份，技術框架不一致，就像汽車的零件型號一樣，從數量上增加了運維難度；另一方面，在實際運維工作過程中，軟件中相似功能過多也很容易讓運維人員記錯，導致二次事故。

2. 求助現實，見招拆招

幸運的是，因為軟件的本質是“對現實世界建?！?，所以在軟件建設和應用過程中，遇到的很多問題都可以在現實世界中找到類似情況及解決方案。

為了應對“重復造輪”的問題，軟件開發領域很早就引入了“平臺化”模式。

平臺化：

“平臺化”概念最早出現在工業制造領域，更廣為大眾所熟知的則是汽車生產平臺。

汽車上零件眾多，開發一個車型涉及技術集成、零部件設計、試驗驗證等繁雜環節，出了名的耗資大、周期長、風險高；而絕大多數消費者，在拿到車之后，并不關心車的底盤是怎么設計的，發動機是橫置的還是豎置的；他們可能更關心車是什么顏色的，座椅是不是真皮的，保險杠上的大燈好不好看。

于是乎，絕大多數汽車企業會使用相似底盤和下車體的公共架構，在這個平臺結構上生產出外形功能都不盡相同的產品。這就是汽車的平臺化/模塊化戰略。

汽車的平臺化

軟件的“平臺化”也是類似，將可復用部分抽象成模塊組件，再基于這些模塊組件進行業務化串聯、增量包裝，就可以適應不斷變化的業務需求。

不過需要說明的是，“平臺”本身是個多義詞，《平臺革命》中的“平臺”說好聽點叫做掌握市場入口，說難聽點就是中介，跟這里說的“平臺”一點關系都沒有，只怪古早時期的譯制工作太粗糙。

平臺是個多義詞

然而對于效率的極致追求，又使得人們很快發現，就像電影、唱片、磁帶等文化產品與一般的商品在生產、流轉和使用過程中有著很大的差別一樣，完全照搬工業制造領域的“平臺化”理論好像也有問題。

軟件“平臺”間的職能邊界問題：

“平臺”的本質是模塊組件，模塊組件多數情況下是必須與其他模塊組件進行業務化串聯，甚至還需要進行增量的個性化定制包裝，才能夠真正解決業務問題的。

這就帶來了“平臺”間如何協作的問題，即“軟件平臺”間的職能邊界是什么？

如不解決這個問題就很容易出現以下兩種情況：

• 各協作的模塊組件都不集成某一可復用能力——出現這種情況，就解決不了“重復造輪子”的問題。
• 各協作的模塊組件同時集成了某一可復用能力——出現這種情況，則會導致“軟件平臺”間面臨類似企業組織分工常常面對的多頭管理的情況：職能上，你也能干，我也能干；解決問題時，你不想干，我也不相干，最終結果就是兩個模塊組件都難以使用、難以迭代；這一點，做過大型軟件1-n迭代的朋友應該都深有感觸。

在模塊組件間協作時，實物產品先天有空間限制條件作為基準，比如汽車前車燈和車尾燈，就可以根據空間位置不同而解決不同的問題；而軟件產品的各“平臺”間就和企業的組織機構一樣缺乏這種天然的協作標準。

數據孤島問題：

“數據孤島”這個詞看起來唬人，實際上它只不過是以下3種原因造成業務數據難以統一分析、管理情況：

• 針對不同業務線中的相似業務定制開發相似的功能，使得不同業務線的相似功能的數據天然隔離。
• 在針對不同業務線中的相似業務定制開發相似的功能過程中，沒有對數據模型做出統一標準要求，上線后的產生的業務數據字段的命名/排序/格式/注釋等不一致。
• 在同一業務線不同功能的開發過程中，未對不同業務之間的關系進行建模，上線后的產生的業務之間的關系數據沒有保存下來，以至于難以判斷同一業務線不同業務之間的關聯性。

而原有的“平臺化”理論起源于工業制造領域，顯然沒有專門考慮過數據治理的問題。

雖然很多開發者在構建“軟件平臺”時，也會關注數據治理，使得軟件的“平臺化”可以在一定程度上緩解“數據孤島”；但因為“軟件平臺”本身還面臨著職能邊界的問題，即不同“軟件平臺”可能集成同一可復用能力，所以其無法從根本上解決問題。

為此，市場上長時間流行著一套“臨時解決方案”——外接“數倉”，具體步驟是：

• 先進行業務分析；
• 再梳理原有各系統的數據結構；
• 然后在新的“數據倉庫”中重新建模；
• 接下來將原有各系統中的數據字段與新的“數據倉庫”中數據字段建立映射關系；
• 然后再執行腳本提取歷史數據；
• 最后啟動定時器定時提取原有各系統中增量數據。

看這個過程就知道，這一通操作下來的成本肯定是低不的，實際上這么浩大的工程確實也只有那些銀行或大型上市公司才能負擔的起。

另外這個解決方案還有著一堆的毛病，比如說，這個新的“數據倉庫”不直接支持業務，里面的建模合理嗎？原有各系統都不知道哪一年、那個團隊、根據什么樣的業務規則、用哪種語言和技術框架做的，還能梳理清楚嗎？數據遷移時的數據映射關系寫錯了是不是一定要等錯誤的數據阻塞業務了才能夠發現？定時取增量數據的時效性如何保障？取數時如何保障數據不會丟失？未來的新系統咋辦？

3. “中臺”崛起

這個世界上的概念從來都不是沒來由的，就像前人們會引入“平臺”理論來解決“重復造輪子”的問題一樣，背負著解決“軟件平臺間職能邊界劃分問題”、“數據孤島問題”的使命，中臺誕生了。

在解決“軟件平臺間職能邊界劃分問題”上，“軟件平臺”間缺乏先天條件作為協作基準；但萬幸的是我們還可以求助現實世界，這里推薦的是“微觀經濟學”領域中的“協作理論”，它是經過了高度總結的，在各個領域中都有著豐富且成功的應用案例。

協作：

定義：個體組合在一起協力完成工作，協作分為簡單協作和復雜協作；簡單協作是沒有專業分工的協作，復雜協作則是建立在專業分工基礎上的。（摘自現代經濟詞典）

從定義中我們可以看出，傳統情況下“軟件平臺”間的協作即是“簡單協作”，而“中臺”則需要采用“復雜協作”，即專業化分工協作，來解決“軟件平臺”間“簡單協作”所暴露出的問題。專業化分工有以下兩種原則。

工藝專業化：按照工藝階段或工藝設備相同性的原則來建立生產單位，即按不同的生產工藝特征，建立不同的生產單位。

特點：“三同一不”；三同——同類型的機器設備、同工種工人 、相同工藝方法；一不——不同的勞動對象。（摘自現代經濟詞典）

對象專業化：按照業務對象來劃分生產單位的原則，即按不同的勞動對象，建立不同的生產單位。

特點：“三不一同”；三不——不同類型的機器設備、不同工種工人、不同工藝方法；一同——相同的勞動對象。（摘自現代經濟詞典）

因為相關經濟學原理比較早的應用于實物領域，所以這兩個原則中的各名詞都是比較貼近實物場景的，不過這不影響我們理解其中含義。

我們可以基于軟件行業的要素特征對上述原則進行名詞上的替換：

能力專業化：按照業務方案階段或模型、方法相同性的原則來建立生產單位，即按不同的業務能力方案特征，建立不同的生產單位。

特點：“多同一不”；多同——相同模型 、相同方法、相同服務等；一不——不同的業務對象。

對象專業化：按照業務對象來劃分生產單位的原則，即按不同的業務對象，建立不同的生產單位。

特點：“多不一同”；多不——不同模型 、不同方法、相同服務等；一同——相同的業務對象。

在解決“數據孤島問題”上，業務間關系數據缺失的情況比較好解決，也不影響“中臺”理論的構建，就暫且不討論了；而從其余情況的產生原因上我們就可以看出，要解決它們最好的辦法就是“從頭到尾相似的數據就只有一份”。

在“軟件平臺”間“簡單協作”的情況下，很難達成這個目標；而如果 “軟件平臺”間采用“復雜協作”，即專業化職能分工，我們只要將分工后的“軟件平臺”進行數據唯一性建模，就可以達成“從頭到尾相似的數據就只有一份”的目標。

而不管是要進行“軟件平臺專業化分工”，還是“數據唯一性”建模，顯然都要在企業層面進行拉通，而不是各個子產品間各自為政。

綜上所屬，我給“中臺”下了本章節開頭的定義：即“中臺”是對“平臺”的升級，承擔著企業層面軟件能力資源的專業化、職能化管理，生產數據歸一的職責。

二、“中臺”帶來新的機會

新事物必然帶來新的機會。

這里我們就先來聊一聊“中臺”給市場內主要參與角色——“企業”和“云服務商”帶來的機會；另外，因為我自己是產品經理，所以也會聊一聊產品經理之于“中臺”的角色定位。

1. 企業——“中臺”是什么不重要，能解決什么問題最重要

“thought works”的首席咨詢師王健在談論他對“中臺”的看法時說到：“中臺是什么不重要，能解決什么問題最重要?！睂τ谶@句話我深以為然。

而令人遺憾的是，以“茅臺中臺項目”為代表的一系列失敗的“中臺”項目案例，似乎讓場內玩家在“中臺能解決什么問題”上紛紛失去了方寸；甚至連阿里巴巴CEO逍遙子也公開表示：“中臺”并不適用于每家公司的每個階段；在獨立業務拓展期、突破期，一定用獨立團、獨立師、獨立旅建制來做，否則就會變成瓶頸；但發展到一定階段，出現太多山頭時，就要關停并轉、要合并同類項；問管理要效率，取消重復性建設。（消息來自36氪）

對于這樣的觀點我并不能認同，原因有3：

1）無論是阿里云還是其他場內玩家，對于“中臺”這么重視，不都是因為其可以解決“重復造輪子”的問題，從而解放研發人力，最終保障創新業務有足夠的人力資源支持嗎？那什么樣的企業業務發展速度最快？人力成本壓力最大呢？當然是創業期和拓展期的企業。

2）在很多企業進行產品經理或架構師招聘時，都有這么一條——能夠設計可拓展型系統，而要保障系統的拓展性，系統模塊間的專業化分工設計必不可少；實際上，為了追求效率而繞開軟件各模塊的職能劃分環節，直接采用砌式產品研發，使得軟件系統功能耦合嚴重，最終導致系統難以迭代必須重構的情況，在IT業界比妹子還常見；對于一些創業期和拓展期來說，這種問題的影響是近乎致命的。

3）“數據孤島問題”很可能會讓創業期和拓展期的企業辛苦收集的業務數據一文不值，亡羊補牢式的數據采集及治理方案所需的人力和資金成本，很可能高于前期軟件各模塊間的專業化分工設計和數據唯一性建模；而如果采用“中臺”方案，即便一開始的建模合理性不足，也會因為數據就一份而很容易進行遷移或字段的升級。

所以我認為不管你的項目是to?b還是to?c的，只要不是單純to?vc圈錢的，且具備以下兩點條件，在進行IT建設時就可以、也應該考慮“中臺”。

• 有明確的商業規劃。
• 遠期目標包含業務線的拓展或業務線的細分。

而包括阿里巴巴CEO逍遙子在內的很多人，認為創業期和拓展期的企業不適合上“中臺”，本質上是對初創企業IT建設能力低下與“中臺”建設成本高昂之間難以調和的矛盾的擔心。

但軟件作為信息技術的一種應用形態，它的核心特點之一就是邊際成本會越來越低，創業期和拓展期的企業就算做不起“中臺”，難道還買不起嗎？就算買不起，難道還租不起嗎？而這就給云服務商在“中臺”市場上的發揮留下了充足的想象空間。

2. 云服務商——彎道超車，在此一舉

包括阿里云、騰訊云在內的眾多云服務商，近年來一直都是在硬件和基礎組件的基礎上，盡可能豐富自己的工具生態，以提高自身在客戶面前的競爭力。

比如阿里云就陸續推出了quick?bi、quick?audience等一系列工具產品；如果云服務商能夠提供“中臺”相關saas、paas產品，無疑可以將自身的競爭力提升到頂點。

原因也有3：

1）“中臺”本身就帶有強烈的業務屬性，企業進行對“中臺”的各項能力進行串聯即可完成產品的搭建，這對企業人力的解放是空前的，無疑具備極大的市場需求。

并且我想說，這才是一般企業與信息技術之間最合理的關系；說到底信息技術也只是一個工具，就像當年的電話，也沒見哪家企業自己建基站、造電話機，企業核心要做的是研究“怎么用電話幫助自己的業務增長”，并將相關方法落地。

2）就像不同的企業在部門專業化職能分工上有一定區別一樣，“中臺”模塊間的專業化職能分工業務可以按照不同原則進行劃分，只要合理就好；比如我司會因為部署需要，把權益中心在拆分為會員卡中心、積分中心、卡券中心等——這使得企業在使用云服務商的“中臺”服務進行業務編排時寫得“膠水代碼”變成了命題作文，難以復用；這可以提高企業更換云服務商的成本，換句話說就是可以提高云服務商的客戶粘性。

3）而在業務域數據唯一性建模時，云服務商可以采用獨特的數據字段命名、排序、格式、注釋等方式，甚至采用獨特的數據存儲環境；這也可以提高企業更換云服務商的成本，同時自身的中臺產品迭代時客戶的數據卻可以便捷的進行遷移。

在具體操作上，針對創業期和拓展期的企業可提供saas產品，開箱即用，讓其輕裝上陣；針對發展到一定階段的企業，也可以像華為買斷ARM的芯片架構使用授權一樣，支持其買斷產品使用權限，甚至進行本地化部署。

3. 產品經理——虎口奪食，咱們一起建模吧

最近，產品經理圈子彌漫著一股悲觀情緒——“互聯網的下半場不需要產品經理”，究其原因是因為大量編輯器的出現，使得很多“界面經理”感受到了威脅。

我一貫認為后臺產品經理需要重點關注業務結構，交互界面次之；而“中臺”對于“專業化職能分工”及“數據唯一性建?！钡膹娏倚枨?，勢必會將業務結構設計推向軟件行業舞臺的中心。

“軟件平臺”的“專業化職能分工”加“數據唯一性建?！蔽覀児们医y稱為業務建模。

關于業務建模是否需要產品經理參與這件事，我思考了很久，也與身邊的多位技術架構師進行了多次深入討論，最終我的結論是——業務建模是需要產品經理的參與。

“中臺”所承載的進行“軟件平臺”的“專業化職能分工”的使命，具有強烈的業務屬性；而軟件產品經理這一角色，設立的核心目的之一就是將研發人員從痛苦的業務研究中解放出來。

就像我一位現就職于菜鳥的前同事（技術架構師）在懟“界面經理”時所說的：“都說軟件是對現實世界建模，我哪有空了解現實世界是什么樣子的？如果我把現實世界摸清楚了，我不就是產品經理了嗎？”

換個角度來說，作為將研發人員從業務研究中解放出來的角色，產品經理本身就沒有辦法把真實世界直接搬到研發人員面前。

產品經理所提供的的業務流程圖、規格清單、功能流程圖、RP原型稿、PRD說明文檔等本質上都是對顯示世界的一種模型化表達，只不過“中臺”對于“專業化職能分工”加“數據唯一性建?！钡男枨?，使其對產品經理業務建模能力的要求提高了很多。

現實世界、業務模型、技術模型

之前就有消息說，國內某大型企業內部要求旗下所有產品經理必須懂技術，現在想來，應該是管理層發現了產品經理建模能力的重要性，而粗暴的將其解讀為需要產品經理懂技術吧？

不過，不管“中臺”產品的建設對產品經理的業務建模能力要求有多高， 業務建模需要掌握的只是無外乎都是要掌握如下知識：

• 建模思想：對現實世界的認知視角，如面向過程、面向對象以及封裝概念等。
• 建模方法：對現實世界的描述方法，如領驅動設計等。
• 建模工具：對現實世界的描述工具，以及輸出物載體，如UML等。
• 建模方案：什么情況下采用什么思想什么方法什么工具進行建模，輸出物需要怎么展示的案例。

國內目前還缺乏針對業務建模系統化的方法論，我自己通過一直以來對各種建模思想的研究，摸索了一套相對適合產品經理的業務建模方法論，相關內容我后面都會單獨寫專題文章介紹。

三、說句心里話

軟件是對現實世界的一種數據化呈現，而現實世界中的人類文明發展了幾千年，有很多基礎理論可以支持軟件理論的發展，比如文章一開始提到的“平臺”，又比如“面向對象”認知模式。

1. 面向對象

人類認識世界的一種視角，比如：張三交了一個新朋友，張三關注到這位新朋友的職業是醫生，就想著以后生病了可以找這位朋友，這就是典型的面向對象思維；如今面向對象思維廣泛應用于軟件設計領域。

而目前市場中對“中臺”的種種解讀，大多缺乏基礎原理支持，并且這種情況在IT行業并不鮮見，比如所謂的用戶心理學。

2. 用戶心理學

我翻遍了整個網絡，也沒能找到這個概念的系統化解釋；而我本專業有一門學科叫做“微觀經濟學”，學科定義就是：研究經濟個體（個人或團隊）如何支配自己的稀缺資源，比如時間、人脈、資金等。

作為入行多年的產品經理，我能夠理解“對于營銷概念的爭吵可以增加熱度”的邏輯。

但“中臺”概念已經夠火了，“中臺”概念火熱的背后是市場對于效率的渴求，而目前這些缺乏基礎原理支持的解讀顯然與這樣的目標背道而馳，這會進一步增加市場對“中臺”概念的誤解。

本文也只是我的一家之言，不過我想只有基礎理論嚴肅分析，實實在在的解決問題，形成案例，才能保障一個“概念”可以長久的產出價值。

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

題圖來自Unsplash，基于CC0協議