數(shù)字化轉(zhuǎn)型案例：源自阿里，中臺設計流程及方法

在過去幾年中臺項目的實踐中，我們團隊積累了一套成熟的中臺服務中心建設思路，該思路包含了從業(yè)務調(diào)研到中臺設計開發(fā)的標準流程和方法論，值得企業(yè)在進行中臺建設時參考。

我們把業(yè)務中臺的落地方法總結(jié)為一個流程圖，如圖4-1所示。從業(yè)務的調(diào)研與規(guī)劃開始，到產(chǎn)出中臺設計，大致步驟包括：

1）調(diào)研與規(guī)劃。

2）需求分析。

3）中臺設計。

4）開發(fā)實現(xiàn)。

（1）調(diào)研與規(guī)劃

業(yè)務的調(diào)研與規(guī)劃目標是，從發(fā)展角度去看企業(yè)當下的業(yè)務運營情況和未來的業(yè)務規(guī)劃。這一步非常重要，業(yè)務規(guī)劃的長遠度決定了業(yè)務中臺的高度。所以這里要求業(yè)務方綜合考慮企業(yè)自身的特性、新技術應用、新業(yè)務發(fā)展趨勢等方面。這里列舉一個零售行業(yè)某企業(yè)的例子，如圖4-2所示。

從這個業(yè)務規(guī)劃中，能明確看到企業(yè)中臺建設的總體規(guī)劃，在不同階段對于會員、庫存、營銷以及供應鏈方面的業(yè)務訴求。有了規(guī)劃，接下來的中臺分析設計就更加有的放矢，不會出現(xiàn)目標混淆和不可持續(xù)發(fā)展的問題。

（2）需求分析

業(yè)務規(guī)劃之后就是需求分析，單純從中臺設計的角度來說，需求分析更關注粗粒度核心業(yè)務流程，并不關心業(yè)務層面具體的用戶交互和功能細節(jié)需求。一般業(yè)務系統(tǒng)和中臺架構(gòu)設計的需求調(diào)研都是同步進行的，所以這里也不用分得太清晰。

需求分析的目標是，從業(yè)務規(guī)劃的各種業(yè)務場景出發(fā)，梳理核心業(yè)務流程。業(yè)務流程的粒度需要包含這幾類：業(yè)務角色、業(yè)務實體、業(yè)務規(guī)則、已經(jīng)存在的業(yè)務系統(tǒng)的接口、外部系統(tǒng)或者平臺的服務和接口。這個過程是邊梳理業(yè)務流程邊識別業(yè)務實體，兩者相輔相成。

（3）中臺設計

從需求分析到中臺設計有兩條路徑，如前面圖4-1所示。路徑A是從業(yè)務域分析開始的完整過程，經(jīng)過流程分析、時序圖分析和聚合分析，最后得出中臺設計方案；路徑B針對業(yè)務比較明確和相對簡單的場景，或者行業(yè)已經(jīng)有類似的業(yè)務沉淀（行業(yè)模型庫），可以基于這些模型庫進行迭代，直接基于已有的方案開始迭代推演。下面我們演示路徑A的方法和過程。

這時就會遇到企業(yè)客戶經(jīng)常提出的問題—我們的公司到底需要幾個中心？這些中心怎么出來的？這些中心是什么樣子？

中臺設計一般分兩個階段：業(yè)務中心分析和業(yè)務中心設計。業(yè)務中心分析是從業(yè)務流程紛繁復雜的業(yè)務場景出發(fā)分解出目標業(yè)務中心，業(yè)務中心設計需要完成中心的概要設計和詳細設計。

階段1：業(yè)務中心分析

這一步需要架構(gòu)師具有深度的行業(yè)業(yè)務理解能力和軟件分析設計能力，中臺既是前臺業(yè)務的基石，也是銜接前后臺業(yè)務的中樞，所以中臺設計一定要從企業(yè)核心業(yè)務場景和流程出發(fā)。

第一步，識別整個體系中最核心的業(yè)務流程，如圖4-3所示。從這些流程出發(fā)，分析流程中參與進來的關鍵業(yè)務和數(shù)據(jù)實體，一一列舉。從核心到邊緣，從前臺到后臺、從后臺到前臺，正向流程、逆向流程，正常流程、異常流程，完整分析之后，你會得到一個企業(yè)業(yè)務實體的全景圖，這個圖包括用戶、會員、企業(yè)組織架構(gòu)、商品、交易（批發(fā)、零售），等等。

這個過程做得越細越好。在這個過程中，不要給自己設定用戶中心、商品中心的概念，這時候你的眼里應該沒有中心和業(yè)務系統(tǒng)的邊界，只關注流程和實體本身。流程梳理完全是從具體業(yè)務場景出發(fā)，忠實于用戶期望的業(yè)務需求，不要被現(xiàn)在實際的流程和系統(tǒng)所束縛。

圖4-4展示了O2O場景下一個線上下單、線下物流送貨的處理流程中，把所有跨系統(tǒng)流程全部梳理后得到的流程全景圖。

第二步，把第一步分析的業(yè)務流程全景圖聚合分析，從不同業(yè)務領域來歸納分析產(chǎn)生的業(yè)務和數(shù)據(jù)實體。這時你會發(fā)現(xiàn)，整個大圖中最關鍵的那些業(yè)務實體與絕大多數(shù)的流程都有關系，而且和絕大多數(shù)的業(yè)務場景都有交互。通常，這時你所要找的適合納入中臺的業(yè)務領域就呼之欲出了，比如會員域、商品域、交易域、庫存域，等等。這時就可以初步確定中臺的基本輪廓。

圖4-5是從上面梳理的業(yè)務流程全景圖出發(fā)，分析流程中的主要業(yè)務對象，歸類整理形成核心業(yè)務域，這些業(yè)務域?qū)⒊蔀橄乱徊椒罩行脑O計的基礎。

第三步，對這些初步確定的業(yè)務域進行進一步分析，分析業(yè)務域相互之間的依賴關系、復雜度、實體之間的親密度等。不同業(yè)務場景得到的結(jié)果可能大不一樣，例如，有的企業(yè)積分營銷活動還不是很規(guī)范，也不成熟，在第一、二步的分析中可能會把積分賬戶放在會員域，因為用戶注冊時會贈送初始積分，這是很自然的事情。

而有的企業(yè)營銷活動非常成熟，會員消費行為會導致積分賬戶變化，同時積分營銷活動又會消費積分，所以會把積分賬戶放在交易域。

這一步需要基于一些服務化設計原則（參見后面的“服務化設計原則”部分）把這種初篩后的業(yè)務域的邊界清晰化，有些需要把某些實體從A業(yè)務域放進B業(yè)務域；有時需要去偽存真，把一些噪音型的對象剔除，讓它們回歸本來的前臺或者后臺；還有一些需要火眼金睛，把本該進入但是卻由于業(yè)務場景覆蓋度不夠暫時沒有進入業(yè)務域的業(yè)務實體有預判性地拉進來。這一步需要架構(gòu)師有豐富的分布式架構(gòu)、服務化設計、中臺設計的經(jīng)驗。

基于上一步的產(chǎn)出再用時序圖的形式分析應用與業(yè)務域之間的關系，如圖4-6所示，如果做得細致一點，這個過程可以進一步細化出調(diào)用過程之中參與的業(yè)務實體。注意，這里的時序圖是基于業(yè)務域得出的，不是舊有系統(tǒng)依賴關系的時序圖。

分析業(yè)務規(guī)劃中的業(yè)務場景和用例會產(chǎn)出完整的基于中臺業(yè)務域架構(gòu)的調(diào)用關系，再把這些時序圖按業(yè)務域進行分類歸集。時序圖中和業(yè)務域的每一次交互算一次“觸點”，按業(yè)務域把所有觸點進行聚合，如圖4-7所示，通過觸點數(shù)我們可以直觀地看出來這些“業(yè)務域”的活躍度以及與業(yè)務場景的依賴程度。這時可以結(jié)合上節(jié)介紹的判斷標準、團隊的資源以及業(yè)務規(guī)劃，定義出第一批可以升級到“中心”的業(yè)務域。

通過業(yè)務域與實體對象之間的依賴關系、業(yè)務域復雜度、業(yè)務實體之間的親密度對業(yè)務域做進一步的聚類，這樣就可以將每一個業(yè)務實體歸類到合適的業(yè)務域。

通過這三個步驟，基本可以確定在當前規(guī)劃的業(yè)務場景下，我們的中臺到底應該有幾個中心，分別是哪些中心。

從業(yè)務調(diào)研得出中臺服務中心的設計，這一步現(xiàn)在很多企業(yè)做得非常隨意，一般都參考一些互聯(lián)網(wǎng)公司的實際經(jīng)驗或者基于自己對中臺的理解，看到相關的流程就照搬過來，結(jié)果很可能會“水土不服”。在這里，我們推薦的方法是從企業(yè)的實際情況和具體需求出發(fā)，進行科學分析，從客觀分析中總結(jié)得來。

階段2：業(yè)務中心設計

階段1分析出了有幾個中心以及中心邊界，這一階段要完成中心的詳細設計工作。在這個階段中，不是簡單地根據(jù)業(yè)務需求劃分模塊后把這些模塊落到中臺層就是中臺了，這樣設計出來的中臺只是具體的業(yè)務模塊下沉，缺乏抽象建模的過程，讓中臺的能力和擴展能力都非常有限，這不能成為稱職的中臺。業(yè)務中臺一定要經(jīng)歷從具體到抽象的建模過程，中臺設計的核心是對業(yè)務抽象建模。

服務中心是業(yè)務中臺最核心的架構(gòu)元素，看起來和原來的應用系統(tǒng)的模塊名稱差不多，但是在本質(zhì)上提升了維度。中心是拉通所有前后端系統(tǒng)的相關功能模塊，進行統(tǒng)一抽象設計，用一個統(tǒng)一的模型去支持前后臺不同業(yè)務場景的需求，如圖4-8所示。

我們從三個維度來描述一個完整的業(yè)務中心設計：業(yè)務模型、數(shù)據(jù)模型、服務能力，一個服務中心通過業(yè)務模型描述業(yè)務承載邏輯，通過數(shù)據(jù)模型描述數(shù)據(jù)的底層規(guī)范，通過服務能力描述服務接口契約。通過這三個維度明確一個服務中心的設計，每個服務中心設計說明書要產(chǎn)出這三個核心概念。圖4-9是一個會員中心的設計示例。

維度一：業(yè)務模型

業(yè)務模型是一個比較難直接定義的概念，我們拿一個實際的例子來說明。一家多業(yè)態(tài)經(jīng)營的房地產(chǎn)企業(yè)，旗下有傳統(tǒng)的商業(yè)地產(chǎn)、住宅、物業(yè)，隨著業(yè)務的拓展也有酒店、旅游門票，甚至會發(fā)展出社區(qū)零售的業(yè)務。如果這家企業(yè)選擇中臺架構(gòu)，那么商品中心應該是什么樣子？

從任何一個單一維度去看這家企業(yè)對商品的需求，可能差異都非常大，商業(yè)地產(chǎn)類的商品是租售的鋪位，住宅類的商品是商品房，物業(yè)是服務類商品，酒店和旅游門票是類似于電子憑證類的虛擬商品，社區(qū)零售是通常意義上的百貨商品。我們對這些商品模型進行每種業(yè)務場景的建模，都會面對這些模型的業(yè)務術語、模型結(jié)構(gòu)，它們完全不一樣。地產(chǎn)商品屬性特別多，商品描述復雜但是模型結(jié)構(gòu)單一，需要支持復雜組合查詢；社區(qū)零售類商品種類會比較多，變化比較快，用戶并發(fā)量較高，商品描述結(jié)構(gòu)都比較簡單；酒店和旅游門票類商品要求分類特別清晰，簡單易管理。

如果基于“煙囪式”架構(gòu)來設計，針對這幾種商品都可以推導出相應的模型。如果用中臺架構(gòu)，就需要對這幾種業(yè)態(tài)的商品模型需求進行再一次抽象，用一個通用的模型支持多種場景需求。可以用主子類目來滿足商品分類管理需求；用產(chǎn)品、屬性、屬性值、子屬性來滿足多業(yè)態(tài)商品多樣化描述需求；用標簽來支持商品離散化管理需求；用前后臺類目分離來滿足基于前臺類目的營銷和基于后臺類目管理的需求。通過這樣的抽象，我們建立了如圖4-10所示的業(yè)務模型。

注意，基于這樣的方法設計的業(yè)務模型，需要與上層業(yè)務對接的業(yè)務術語做一個統(tǒng)一。比如，對于地產(chǎn)類業(yè)務，如果原來是基于項目、分期、樓棟建立的樹形結(jié)構(gòu)，就要對應到現(xiàn)在的類目體系上（對地產(chǎn)業(yè)態(tài)建立業(yè)務約束規(guī)范實現(xiàn)對接）；如果原來是社區(qū)零售業(yè)務，應該對應到現(xiàn)在的商品類目管理體系下，這就是中臺的業(yè)務模型。

商品偏于主數(shù)據(jù)模型結(jié)構(gòu)，但是不要因此就誤以為服務中心的模型都是主數(shù)據(jù)模型，交易時要統(tǒng)一交易流程，營銷時要統(tǒng)一規(guī)則：針對不同的業(yè)務領域，有不同的建模訴求；基于業(yè)務但一定要高于業(yè)務。如果做不到模型層面的抽象統(tǒng)一，那就只是具體業(yè)務形態(tài)的模塊下沉，中臺的價值難以發(fā)揮。

維度二：數(shù)據(jù)模型

數(shù)據(jù)模型是服務中心底層的數(shù)據(jù)層實現(xiàn)，包括OLTP和OLAP兩種場景。根據(jù)業(yè)務的需求，可能需要結(jié)合分布式數(shù)據(jù)庫技術。

與交易相關的業(yè)務場景中，最常見的數(shù)據(jù)模型方案是定義實體關系模型，如果對擴展性有要求，則可結(jié)合分布式數(shù)據(jù)庫技術形成方案。數(shù)據(jù)模型的第一個職責是明確數(shù)據(jù)的業(yè)務規(guī)范，為業(yè)務數(shù)據(jù)化和數(shù)據(jù)中臺建設做好基礎準備工作。

維度三：服務能力

服務能力是中臺業(yè)務能力對外的服務契約，外部系統(tǒng)通過接入中臺的服務來使用中臺。服務列表包括兩部分：第一部分是針對中心的外部用戶部分，這部分要明確服務的接口契約，包括使用的通信協(xié)議、安全鑒權(quán)方案、服務的請求報文和響應報文、服務的具體業(yè)務含義以及調(diào)用的上下文、異常情況等；第二部分是服務的開發(fā)實現(xiàn)，這部分內(nèi)容需要設計者畫出服務的業(yè)務流程、業(yè)務邊界、異常處理等。

上面已經(jīng)完成了中臺的設計，在進入具體的開發(fā)之前，為了保證設計的中臺模型能滿足真實的業(yè)務場景，最好將中臺的服務放入具體的業(yè)務流程中進行驗證，也可以基于服務的mock實現(xiàn)來進行驗證。這個過程可能比較煩瑣，但是通過這個驗證過程，可以發(fā)現(xiàn)中臺的業(yè)務模型抽象是否正確，使用是否方便，服務是否完整，發(fā)現(xiàn)設計中模型的問題，再快速迭代修改。如果所有的業(yè)務場景都能通過這樣的驗證，那么中臺的設計方案是可行的。

（4）開發(fā)實現(xiàn)

開發(fā)實現(xiàn)基于服務接口規(guī)范、數(shù)據(jù)模型和業(yè)務流程進行，當數(shù)據(jù)模型和服務能力都具備后，開發(fā)者就能進行詳細設計和開發(fā)了。這里并沒有特殊之處，但需要開發(fā)人員掌握分布式、服務化相關的一些開發(fā)原則和技術，特別是在分布式體系下，引入了一些在傳統(tǒng)一體化架構(gòu)體系下不太關注的技術原則，比如分布式事務、異步、冪等問題。相關技術可參考《企業(yè)IT架構(gòu)轉(zhuǎn)型之道》一書。

本文由機械工業(yè)出版社獨家授權(quán)發(fā)布，中臺圣經(jīng)——《企業(yè)IT架構(gòu)轉(zhuǎn)型之道》作者鐘華新作！《數(shù)字化轉(zhuǎn)型的道與術：以平臺思維為核心支撐企業(yè)戰(zhàn)略可持續(xù)發(fā)展》。