導讀：阿里巴巴的中臺戰略最早從業務中臺和資料中臺開始，採用業務和資料中臺相結合的雙中臺建設模式。後來又有人提出了各種各樣的其他中臺，比如技術中臺、AI中臺等，不一而足。
其實不少企業在很多年前就已經有了建設大平臺的實踐經驗。在中臺被熱議的當下，相信你一定聽過很多對中臺的質疑聲。
比如，有人說：“中臺就是個怪名詞，它不就是已經做了好多年的平臺嗎？”
確實！中臺源於平臺，但它的戰略高度要高於平臺。
本文希望你能清楚平臺與中臺的主要差異是什麼，中臺到底是什麼，傳統企業的中臺建設策略是否應該和阿里一樣等內容。
01 平臺是中臺嗎在阿里巴巴完美落地中臺戰略後，很多企業開始與阿里的中臺對標。其中有不少企業在十多年前就完成了大一統的集中式系統拆分，實現了從傳統大單體應用向大平臺的演進，他們也按照業務領域將公共能力和核心能力分開建設，解決了公共功能模組重複投入和重複建設的問題。
那這是不是阿里所說的中臺呢？在回答這個問題之前，我們不妨先了解一下阿里的中臺到底是什麼樣的。
阿里業務中臺的前身是共享平臺，而原來的共享平臺更多是被當作資源團隊，承接各業務方的需求，併為業務方在基礎服務上做定製開發。
阿里業務中臺的目標是把核心服務鏈路（會員、商品、交易、營銷、店鋪、資金結算等）整體當作一個平臺產品來做，為前端業務提供的是業務解決方案，而不是彼此獨立的系統。這種能力有別於傳統的煙囪式的系統建設方式。
有些企業的IT人員說：“我們系統很多，功能很強大，所有業務點都有系統支援，但為什麼業務人員總抱怨系統做得不夠好，業務響應不夠快呢？”
其實這是一個很多企業都在討論的、應用“可用”與“好用”的話題。拋開商業模式的原因，問題根源很有可能出在系統的共享、聯通和融合能力上。在進行應用建設時，有些人可能會站在部門或個人利益的角度，特別強調和關注應用的區域性“可用”，卻忽略了企業級業務和流程的整體“好用”。
有的企業由於缺乏總體規劃，應用建設目標不夠明確，加上天然的組織架構、資料和業務邊界，很自然地就出現了明顯的系統邊界和系統重複建設的問題，難以支援企業級業務能力的快速融合，不能快速響應企業級業務和商業模式創新，對前臺一線業務支援和融合也不夠好，難以在前臺形成一致的使用者體驗，最終影響企業業務發展。
這種問題在業務領域分佈廣泛的大型集團級企業可能會更加突出。而對於大型企業而言，要想解決從“可用”到“好用”的問題，其實還有很長的路要走。
下面我們來分析一下傳統企業大平臺戰略和阿里中臺戰略的主要差異。
傳統企業的很多平臺只是將部分通用的公共能力獨立為共享平臺。這類平臺雖然可以透過API或者以資料服務的形式對外提供共享服務，解決系統重複建設的問題，但它們並沒有與企業內的其他平臺或應用實現從前端到後端的頁面、業務流程和資料的全面融合，沒有將企業核心業務服務鏈路作為企業級解決方案來考慮。各平臺仍然是分離且獨立的，本質上仍然是煙囪式建設模式。
可見，專案級的平臺雖然解決了公共能力複用的問題，但與企業級中臺的建設目標顯然還有一定差距！
02 中臺到底是什麼“一千個讀者就有一千個哈姆雷特”，用這句話形容技術圈對中臺的理解再合適不過了。這也說明了大家對中臺的定位和理解還存在很大的爭議。
我們先看一下阿里對中臺的定義：
中臺是一個基礎的理念和架構，我們要用中臺的思想建設、聯通所有基礎服務，共同支援上端的業務。業務中臺更多的是支援線上業務，資料中臺則提供基礎資料處理能力和很多的資料產品供所有業務方使用。即由業務中臺、資料中臺、演算法中臺等一起提供對上層業務的支撐。
再看一下ThoughtWorks對中臺的定義：
中臺是企業級能力複用平臺。
綜上，我們可以提煉出幾個關於中臺的關鍵詞：共享、聯通、融合和創新。聯通是前臺以及中臺之間各業務板塊的聯通，融合是前臺企業級業務流程和資料的融合，並以共享的方式支援前臺一線業務的發展和創新。
我認為，中臺首先體現的是一種企業級的能力，它提供的是一套企業級的整體解決方案，解決小到企業、集團，大到生態圈的能力共享、業務聯通和融合的問題，支援業務和商業模式創新。透過平臺聯通、業務和資料融合，為前臺使用者提供一致體驗，更敏捷地支撐前臺一線業務。
對前臺業務的快速響應能力。企業級的複用能力。從前臺、中臺到後臺的設計、研發、頁面操作、流程、服務和資料的無縫聯通、融合能力。其中最關鍵的是業務快速響應能力和企業級無縫聯通及融合能力，尤其是對於跨業經營的超大型企業來說，這種能力至關重要。
03 傳統企業中臺的建設策略與傳統企業不同，擁有流量入口的超大型互聯企業是網際網路生態圈的創造者，而傳統企業只是生態圈種群中的個體，除了需要做好原有的傳統渠道業務外，還需要融入網際網路生態圈，其商業模式、個體能力，以及與其他個體共生的能力決定了它的發展潛力。
相對網際網路企業而言，傳統企業的渠道應用更加多樣化，有面向內部人員的門店類應用、面向外部使用者的網際網路電商以及移動App類應用。這些應用面向的使用者和場景可能不同，但其功能與產品同質化嚴重，基本涵蓋了企業的核心業務能力。
此外，傳統企業也會將部分核心應用的頁面或API服務能力開放給生態圈第三方，實現業務的優勢互補，相互借力發展。
為了適應不同業務和渠道的發展，過去很多企業的做法是開發很多相互獨立的應用或App。但由於IT系統建設初期並沒有企業級的整體規劃，平臺之間融合不好，直接影響了使用者體驗，歸根結底是使用者並不想安裝那麼多App。
為了提升使用者體驗，實現統一運營，很多企業開始縮減App的數量，在一個App中整合企業內的所有能力，聯通前臺所有的核心業務鏈路。
由於傳統企業的商業模式和IT系統建設發展的歷程與網際網路企業不是完全一樣的，因此傳統企業的中臺建設策略與阿里中臺戰略也會有所差異，中臺需要共享的內容也不太一樣。但是傳統企業的中臺建設策略與阿里的中臺建設策略基本相同，都需要從業務中臺和資料中臺這種雙中臺的模式開始建設，如圖1-1所示。
▲圖1-1 “業務+資料”雙中臺建設模式
我們來分析一下企業中臺的能力建設過程。企業中臺業務能力建設一般會經歷“分”和“合”兩個過程。透過將企業可複用的能力沉澱，形成多個不同業務領域職責單一的中臺領域模型，然後對這些不同型別的中臺業務能力進行組合和編排，形成企業級業務能力，從而在企業領域模型的“穩”和商業模式與業務流程的“變”中找到最佳平衡。
“分”的主要目標是透過業務領域邊界劃分和微服務拆分，建立穩定的、單一職能的領域模型，讓業務和應用具有更強的擴充套件和複用能力。但分不是目的，而是手段，是根據單一職責原則實現業務能力的複用和高內聚。
分的過程主要發生在業務中臺，在完成業務領域和微服務拆分後，降低了應用建設的複雜度，使業務和應用具有更強的擴充套件能力和穩定性。
在完成業務能力拆分後，我們還需要對這些拆分後的、穩定的、可複用的核心領域能力進行組合、編排和融合，形成企業級能力，從而靈活快速地適配外部業務和流程以及商業模式的變化，這是“合”的過程。
“合”包括業務融合和資料融合。業務融合主要作用在前臺，實現企業不同業務板塊能力的聯通、組裝和整合，實現企業級業務流程的融合，提供一致的前臺使用者體驗。而資料融合則主要作用在資料中臺，實現企業不同業務板塊資料的彙集、整合、智慧分析和商業模式創新等，為企業前臺業務提供統一的智慧化資料服務。
在進行業務領域劃分和中臺設計時，由於渠道多樣化，傳統企業不僅要將通用能力中臺化，以實現通用能力的沉澱、共享和複用（這裡的通用能力對應DDD的通用子域或支撐子域），還需要將核心能力中臺化，以滿足不同渠道的核心業務能力共享和複用的需求，避免傳統核心和移動互聯等不同渠道應用之間出現“後端雙核心、前端兩張皮”的問題（這裡的核心能力對應DDD的核心子域）。
上述這些都屬於業務中臺的範疇，需要我們解決核心業務鏈路的聯通和不同渠道服務複用的問題。
注意：“後端雙核心、前端兩張皮”主要是指IT重複建設的問題。對於相同的核心業務領域，傳統核心應用和移動互聯應用分別採用不同的技術棧重複建設，出現傳統應用和移動互聯應用兩個核心。而兩者在前端技術棧和展現方式又完全不同，無法複用。除此之外，我們還需要解決微服務拆分後的資料孤島、資料融合和業務創新等問題，這就屬於資料中臺的範疇了，尤其是當我們採用分散式微服務架構以後，就更應該關注微服務拆分後的資料融合和共享問題了。
綜上，在中臺設計和規劃時，我們需要整體考慮企業內前臺、中臺以及後臺應用的協同，實現不同渠道應用的前端頁面、流程和服務的共享，還有核心業務鏈路的聯通以及前臺流程和資料的融合、共享，以支援前臺一線業務和商業模式創新。
關於作者：歐創新，某大型保險公司架構師，擁有十多年的軟體架構設計經驗。熱衷於DDD、中臺和分散式微服務架構設計。在DDD、中臺和分散式微服務架構設計方面有深厚的積累，擅長分散式微服務架構設計。鄧頔，某大型保險公司高階工程師，全國青年崗位能手。致力於基於DDD的企業級中臺微服務架構改造實踐，精通前端開發相關技術棧，擁有豐富的企業級微前端實戰經驗。
本文摘編自《中臺架構與實現：基於DDD和微服務》，經出版方授權釋出。
延伸閱讀《中臺架構與實現》
推薦語：資深架構師撰寫，系統闡述基於DDD的中臺和微服務建設方法論，深刻揭示中臺從領域建模到微服務落地完整過程。