前段時間聽一位“新零售大咖”講零售企業數字化轉型，他說傳統零售企業的數字化轉型一定要建設“業務中臺”、“技術中臺”和“資料中臺”。我問大咖三個問題：

你見過的零售企業中，有多少有這三個臺的？

真有這三個臺的零售企業，有多少程式設計師在搞開發？

那這些企業究竟是在搞零售還是在搞軟體公司？

（二）

有朋友介紹了一家規模挺大的公司找諮詢公司來規劃“資料中臺”，用“資料中臺”來管理企業的資料資源、資料治理，賦能分析應用。

我問：那你們這個資料中臺要做啥業務呢？

企業負責人說，他希望資料中臺落地的應用場景是：客戶管理、商機管理、合同管理、回款管理等功能。

我說：領導，我建議您不要折騰啥資料中臺了。你們要做的這個東西叫CRM，跟資料中臺沒啥關係，建議你們先買個現成的CRM軟體來用，千萬不要自己去開發，找諮詢公司幫你們把銷售管理的流程和管理制度梳理好吧。

（三）

有位某大型房地產企業CIO老朋友參加一個行業論壇，看到一個講中臺的圖，拍照發過來給我看，跟我討教圖裡中臺和前臺究竟是啥意思：

我說我看不懂這個圖，原因有三：

為什麼會把“核心業務系統”放到“前臺”了？供應商、房間、專案、客戶、組織等“業務中臺”應該就是地產企業ERP系統的各個模組，沒明白為啥叫“業務中臺”？至於把開發運維技術平臺、中介軟體、資料、分析軟體叫“後臺”，更是不明白和“前臺”、“中臺”的關係是啥？從這個圖來看，我有點懷疑他們根本就沒有DevOps能力。

反正這個“中臺”跟阿里說的“中臺”不是一回事：

可是仔細看阿里這張圖很有意思，有“前臺”、“中臺”，卻沒有“後臺”。如果沒有“後”的話，那叫“中”還有意義嗎？

（四）

其實我自己曾經非常熱衷於佈道“中臺”理念。

不過，現在這個詞兒已經變味了，在市面上能把“業務中臺、技術中臺、資料中臺”說得特別順溜的專家，基本上可以判斷此人沒有實操過任何企業級資訊系統的實施。因為企業資訊系統不是這樣長的，這些臺都是他們想象出來的。

20年前在企業軟體市場上，去投ERP方案時，有的人上來就是“三層架構”、“N層架構”，客戶還一定要你證明SAP是N層架構，不是就不夠先進……

可是，那時的SAP ERP還真不是“N層架構”；而號稱N層架構的ERP軟體，也沒有幾家活到了今天的。

“中臺”這個概念出現，對於企業數字化轉型的架構規劃本來是有積極意義的。在我來看，就是使用者層、業務邏輯層、資料存取層、資料來源等前後臺分離，也就是當年“N層架構”的升級版而已。

這些工程師的概念，其實對企業的業務使用者來說意義並不大，也不用在乎究竟有幾張臺。下圖是我們團隊對企業系統架構現代化的分層模型：

網際網路和電商企業包裝出來的“中臺”概念，即作為服務的“業務能力”（技術上稱為“微服務/API”）是以軟體程式碼形式存在的，不是任何使用者級的企業應用系統。換句話說，要變成面向終端使用者能用的軟體，需要工程師寫程式碼的；新零售的所謂中臺，就是“無頭電商”。參見 Headless Commerce（無頭電商）與中臺隨想

所以，對於絕大多數傳統企業來講，只要沒有一大堆程式設計師成天在寫程式碼、搞開發，你的IT系統沒有上雲，不是每兩、三週就迭代釋出一次的話，基本上就沒“中臺”啥事。

除非是自研資訊系統，絕大多數企業實際使用的商業化資訊系統裡，是不存在所謂“業務中臺”、“技術中臺”的；或者即使存在，使用者也是看不到、感知不到的。

炒作“中臺”這事兒，實質就是網際網路公司掀企業軟體公司的桌子，同時，搞自研系統的整合商或企業們跟著起鬨；當然，一些大型機構因為各種原因，確實需要自研IT系統。

看著別人說中臺說得熱鬧，企業軟體公司或者是用ERP的企業們就急了，紛紛辯解、解釋：我們也是有中臺的，接著就是各自對“中臺”的各種胡亂解釋。

寫了這麼多，技術小白也不一定看得懂，記住兩句簡單結論就行了：

1，正宗的“中臺”，就是讓企業自己養一大堆程式設計師，來開發使用者可用的系統

2，如果有人告訴你一個軟體叫“中臺”，還給你演示“中臺”的介面，這都不是正宗的“中臺”。

最後的建議就是，如果你要讓真正幹企業系統的人覺得你不是在忽悠，最好不要連串講“中臺”，因為現在這詞兒真的臭大街了。