中臺詳解（下）-怎麼搭建中臺

提示：《中臺詳解系列》共分上下兩篇，本文為下篇，總計約12000字，因為文中涉及知識體系較為廣泛，建議預留30-50分鐘進行閱讀。閱讀本文前建議閱讀系列上篇——《中臺詳解（上）-什麼是中臺？》，點選下方連結即可閱讀。

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

阿里雲在提出“中臺”戰略後，僅在一定程度上給出了“資料中臺”的建設規範，同時市面上關於“中臺”的介紹性文章也都避而不談“中臺”的落地方案，想是仍未統一。本文中，我將主要介紹基於我個人對於“中臺”的定義及在“中臺”建設方面的經驗，總結得出的“中臺”總體建設建議方案，不過因為篇幅原因可能不會過於細緻，也不會探討“業務中臺”、“資料中臺”、“技術中臺”在細節上的差別。相關內容主要包括以下幾個章節：

1. 如何劃分“中臺”
2. “中臺”領域內建模要點
3. “中臺”資料治理方案
4. “中臺”模組間建設順序
5. “中臺”對外服務要點
6. “中臺”迭代要點
7. “中臺”對組織架構及其協作關係的影響

第一章：如何劃分“中臺”

要做“中臺”，首先自然就是得梳理清楚可以有哪些“中臺”。

1.1.原理說明：

我對於“中臺”的劃分方法是基於“以終為始”的原則及我個人對“中臺”的定義總結的，其細則如下：

• “中臺”需要通過專業化分工來解決“軟體平臺間職能邊界劃分問題”，專業化分工的本質是一種分類規則，要想分類我們就先得梳理自己有哪些業務功能以及要做哪些業務功能。
• 所有的軟體及其背後的理論、原理、概念、技術都是為了解決業務問題而產生的，所以在梳理“自己有哪些業務功能以及要做哪些業務功能”之前，需要先梳理清楚業務目標，這可以幫助我們評估業務功能梳理及其他工作的合理性。
• “軟體平臺”的專業化職能分工所需採用的“能力專業化”的原則，有著“多同一不”的特點（上篇文章有說明），所以建議提煉業務功能中的實體作為後續業務功能“分類”的“錨點”。
• 將業務功能轉化為類圖等直觀可視的靜態模型，可以有效降低思維難度。
• “中臺”的構建需要在企業層面拉通。

1.2.方法選擇：領域驅動設計

因為“中臺”揹負著解決“軟體平臺間職能邊界劃分問題”的使命，從這個角度出發，我認為最適合應用於“中臺”職能邊界梳理的方法是“領域驅動設計”，因為從“領域”這倆字就可以看出來，“領域驅動設計”是為定義職能邊界而生的。

不過目前“領域驅動設計”的落地實施方案是由技術人員總結的，主要應用於某個既定領域內的建模，如果我們直接用來進行“中臺”的“專業化分工”和“資料唯一性建模”可能不太行。所以針對“中臺”的目標特徵，我這裡藉助“領域驅動設計”思想，魔改了一套經驗證可行的方案。大家可以簡單瞭解一下。（由於“領域驅動設計”是基於物件導向思想衍生出來的一種建模方法，如果對於物件導向不太熟悉，可能不太看得懂，所以如果實在看不懂建議先跳過本段。）

1.3.人員分工：產品經理主導

基於前文的分析，“平臺”間的職能邊界劃分需要遵循專業化分工原則，所以建議增設“業務架構師”崗主導相關工作，除技術“中臺”外，包括“業務中臺”、“資料中臺”的職能邊界劃分工作均由產品經理擔任“業務架構師”。

1.4.操作方案：

在用本方案進行“中臺”劃分時，我們大致需要經過兩個階段，共計8個步驟：

（1）第一階段：

第1-3步為第一個階段，是由“領域驅動設計”原落地方案中的“事件風暴”環節演變而來。分別為“企業全量業務目標分解”、“企業全量業務功能風暴”和“企業全量業務功能擴充”。

①目標：梳理清楚“中臺”所需支援的業務功能邊界。

②輸出物：企業全量業務功能藍圖（ER圖或類圖）。

業務功能版圖示例，圖片來自網路

③具體流程：

1.第一步：企業全量業務目標分解。

（1）在進行業務目標分解時需要優先關心其在商業上的橫向擴充。以下為我個人總結的幾個擴充點：

• 上下游業務擴充：比如犀牛製造和菜鳥物流之於淘寶 。
• 資源變現：比如滴滴搞外賣 。
• 資料變現：比如抖音、微信的使用者標籤等 。
• 流量變現：比如抖音、微信的引流服務等 。

（2）具體到某個業務線、或體系下，業務功能都是通過解決一個一個小問題再最終解決小問題背後的大問題的，所以這裡業務目標最好是採用金字塔模型來進行梳理。以營銷體系為例：

①營銷的最終目標是“賣更多的東西”，其子目標可以分為“讓更多人買東西”、“讓人買更多東西”；
②“讓更多人買東西”的子目標可以繼續分為“拉新”、“給使用者洗腦”、“推薦合適的商品”；“讓人買更多東西”的子目標可以繼續分為“給使用者洗腦”、“推薦合適的商品”；
③ “給使用者洗腦”的子目標又可以繼續分為“提升品牌好感度”、“提升產品認知度”、“提升購物積極性”等…

雖然我們在“中臺”設計過程中，業務目標劃分的越細越好，不過業務子目標的分解也不是無限制的，最終狀態的子目標會有著鮮明的場景化特徵，大致可以用以下模型表示。比如：連鎖零售商總部營銷部門在“女性使用者”“非首次”情況下通過“APP”購買“任意”商品時向其發放“肯德基10代金券”，以提高使用者通過APP下單的積極性 。

2.第二步：企業全量業務功能風暴

即對照“業務目標金字塔模型”對已有業務功能進行梳理，輸出已有全量業務功能版圖。要求精確到實體，在操作本環節時，以下幾點需要注意：

（1）前文說明“資料孤島”問題時提到過關係資料的重要性，所以在進行已有全量業務功能版圖梳理時，關係型實體或欄位務必要梳理清楚，不能遺漏，比如訂單觸發積分發放的記錄等。
（2）一般來說因為缺乏專業化職能分工設計，業務系統中會出現大量以下型別的臨時方案：
人機互動型臨時方案：比如業務場景沒有定義好，在使用某服務時由人工錄入服務的使用場景 。
在程式碼中埋資料的臨時方案：比如某店鋪的銀行卡資訊直接寫死。 在進行業務功能風暴時，此類臨時方案一定要還原成通用方案。

3.第三步：企業全量業務功能擴充

即對照“業務目標金字塔模型”，基於第二步中輸出的已有全量業務功能版圖，梳理未來還可能會有哪些業務功能。因為“中臺”在應用時處於底層，會被很多上層業務系統整合，如果“中臺”沒有做好前瞻性設計，後續迭代風險會比較大。以下為我個人總結的幾種擴充點：

（1）業務功能細化擴充：在資料層面表現為欄位取值範圍的增加，比如客戶型別的列舉值從“個人客戶”增加到“個人客戶,機構客戶”，即表示目標客戶從個人客戶擴充到了機構客戶。另外拋開約束性校驗和介面互動，所以軟體的底層功能有且僅有對某實體某欄位的增刪改查，即每個實體天然有“欄位數量*增刪改查”個功能。

（2）業務功能閉環性擴充：這一項主要是基於物件導向中的組合思想進行的擴充，即解決某一問題時可能需要多個功能組合完成，我們據此判斷缺失了哪個功能。比如要達成使用者激勵，光有積分發放是不行的，還得需要積分消費功能。

（3）業務功能依賴/約束性擴充：在資料層面表現為實體欄位的增刪改查需要從外部資料來源取數或對外部資料來源進行校驗。比如物流單中商品資訊就需要從商品模組獲取，使用者下單時需要對商品庫存數量進行校驗

（4）業務功能支撐性擴充：即為了讓業務更好的開展而進行的業務功能擴充。比如為了提高開啟某文章的概率，我們會開發閱讀指定文章送積分的功能。

（5）業務功能縱向擴充：在資料層面表現為對實體及其屬性、方法、實體間關係進行定義。比如設定積分的面值，進行使用者操作許可權授權等。
（6）業務功能解耦分化型擴充：在資料層面表現為實體的拆分。比如有些車企自建的整車商城，包含汽車交易及汽車物權管理兩條業務線，為了保障業務靈活度，最好就是將整車交易單拆分為商品交易單和物權轉讓單。

經過上面一番猛如虎的操作後，正常來說我們應該可以得到一張比較全面的業務功能藍圖（ER圖或類圖），接下來我們將進入第二個階段，開始“中臺”的劃分工作。

（2）第二階段：

第4-8步為第二個階段，是基於“領域驅動設計”原落地方案中的“聚合”概念擴充而來。分別為“關鍵屬性定義”、“實體抽象合併”、“可複用業務定義”、“中臺邊界劃分”和“中臺邊界修正”。

①目標：進行“中臺”的專業化職能模組劃分，並調優。

②輸出物：“中臺”產品架構圖。

③具體流程：

4.第四步，關鍵屬性定義。

每個業務都有很多附加功能，這使得這些業務對應的實體會有很多屬性，但實際上每個實體都僅有少量的幾個關鍵屬性定義了“它是它”。實體的屬性過多會對實體間的關係整理形成干擾，所以我們需要找出每個實體的關鍵屬性。關於什麼是核心屬性，我這裡舉幾個例子。

• 商品的核心屬性：價格，關聯物品或產品編碼 。 權益的核心屬性：標的物、抵扣規則及面值 。
• 訂單的核心屬性：買賣雙方、交易額、交易商品、成交數量、成交單價 。
  

5.第五步，實體抽象合併。

按照“多同一不”（上篇文章有說明）原則，我們需要根據某一個“模型、方法”是否服務於不同的“物件”來進行專業化分工。所以需要把相關實體進行抽象合併，保障各類實體的唯一性。因為我們在第四步“關鍵屬性定義”中找到了各實體的關鍵屬性，這一步就相對容易。這個環節有一點需要注意：

• 因為缺乏規範，可能明明相同的實體，但關鍵屬性的命名卻完全不一樣，這可能導致將其分成了兩個實體，所以在對實體關鍵屬性定義時需要多檢查幾遍。

6.第六步，可複用業務定義。

接下來，我們需要基於“多同一不”（上篇文章有說明）的原則找到那些服務不同物件的“模型、方法”，這是專業化分工的基礎。這裡還是舉個例子，比如“權益發放”即為服務不同物件的“模型、方法”。

• “權益發放”作為服務不同物件的“模型、方法”在業務上表現為：
  權益發放可以應用於包括使用者註冊、使用者簽到、使用者下單等多個業務，所以即為服務不同物件的“模型、方法”。

• “權益發放”作為服務不同物件的“模型、方法”在資料上表現為：
  情況1：實體：使用者註冊記錄（如果有的話）、使用者簽到記錄（如果有的話）、使用者訂單（如果有的話）都冗餘了權益發放數量資訊 。
  
  情況2：實體：使用者註冊記錄（如果有的話）、使用者簽到記錄（如果有的話）、使用者訂單（如果有的話）都冗餘了權益發放規則資訊，而權益發放規則冗餘了積分發放數量資訊。

7.第七步，“中臺”邊界劃分。

接下來，我們就可以正式進行“中臺”邊界的劃分了。

（1）首先，我們需要將第六步“核心業務定義”環節找到的服務不同物件的“模型、方法”，與其服務物件分開。比如權益發放因為可以同時服務使用者註冊、使用者簽到、使用者下單等，所以其需要與後三者分開。

（2）然後我們在通過實體關鍵屬性所表現出關聯關係進行組合。比如：

• 物流單的核心屬性：物品、數量、取貨地址、收貨地址 。
• 訂單的核心屬性：買賣雙方、交易額及交易商品 。 權益賬戶：所屬使用者、所屬權益、權益餘額。
• 權益發放流水：流水型別（發放）、支出權益賬戶、收入權益賬戶、所屬權益、流轉權益數量 。
  

我們可以看出，物流單和訂單基於核心屬性是沒有直接聯絡的，所以我們不會輕易將它們放到一個“中臺”業務域中；而積分賬戶和積分發放流水基於核心屬性是有直接聯絡的，所以我們會將他們放到一個“中臺”業務域中。

（3）需要注意的是，因為“中臺”強調專業化職能分工，就像企業員工在實施某專案時，協作的各工種之間有很多銜接環節一樣，在實際開展業務過程中，“中臺”功能間也需要很多銜接性功能才能夠真正支援業務。一般來說，為了避免影響業務職能的完整性，不建議將這些銜接性功能強行劃分到某個“中臺”業務域中，實在不行，建議單獨抽象一個“業務流程編排/管理中臺”來統一行使功能銜接的職能。

8.第八步，“中臺”邊界修正。

（1）首先，我們不排除有“基於關鍵屬性是沒有直接聯絡的兩個實體”需要劃分到同一個“中臺”業務域中的可能，也不排除有“基於關鍵屬性是有直接聯絡的兩個實體”需要劃分到不同“中臺”業務域中的可能。比如：

• 我司會因為部署需要，把權益中心在拆分為會員卡中心、積分中心、卡券中心等；
• 也會有企業因為商品和訂單在業務上緊密的關係而將兩者劃歸為交易中臺。

所以在“中臺”邊界劃分完成後，我們還需根據實際情況進行微調。

（2）其次，會有一些業務特徵不明顯的功能是跨領域的，這種功能實際上可以抽象提取出來作為一個獨立的“中臺”板塊，比如基於使用者行為髮卡券、積分、簡訊的功能可抽象為事件營銷中臺。

經過驗證，只要按照以上步驟執行，就可以梳理出相對理想的“中臺”結構。不過“中臺”劃分原則的細節還有很多可聊，這些內容我後面也都會單獨寫專題文章介紹。這裡就不贅述了。

第二章：“中臺”領域內建模要點

鑑於“中臺”揹負著解決“軟體平臺的職能邊界問題”的使命，其領域內建模即包括業務建模和技術建模兩個方面：

2.1.業務建模

這一塊的工作可以進一步細分為“功能擴充”和“業務欄位定義”兩塊工作，同樣建議由產品經理作為“業務架構師”承擔。

（1）功能擴充：

主體步驟跟“中臺劃分原則”中“第一步”階段的差不多，主要還是基於業務目標和“領域驅動設計”思想對已有實體和功能進行各種形式的擴充，這裡也就不重複說明了。僅強調以下要點：

在“中臺”的業務建模過程中，如果發現某個“中臺”業務域對某些外部資料有依賴，而相關資料來源還沒有構建完成，這時萬萬不可私自在當前“中臺”業務域中定義相關資料，這會嚴重破壞業務完整性，所謂“中臺”的職能邊界劃分就無從談起了。此種情況的解決方案在下文“3.3.中臺資料治理”章節會給出。

（2）業務欄位定義：

由於“中臺”還承擔著解決“資料孤島”的使命，所以在進行“中臺”的業務建模時需要進行實體業務欄位的定義。這一部分我們重點聊一下：

除了核心屬性欄位外，我們需要基於以下要點進行欄位冗餘：

• 基於實體間的依賴關係進行欄位冗餘，比如“卡券僅可用於指定商品功能”，就要求“卡券”實體冗餘可用“商品ID”欄位 。
• “中臺”是底層應用，不會直接對使用者提供服務，都是上層業務系統按照一定邏輯順序呼叫“中臺”的介面來實現業務串聯的。而上層業務系統在呼叫中臺服務時是基於明確的業務場景的，為了滿足後續資料分析、生產問題定位等目標，上層業務系統呼叫“中臺”服務時需要入參相關服務呼叫的具體應用場景，而“中臺”建模時也需要考慮相關資料的儲存。比如某APP後臺呼叫積分中心、卡券中心進行積分或卡券的發放時都需要入參渠道ID、業務終端ID、操作人ID、業務ID（如訂單這一業務的ID）、業務流水號（如具體某一筆訂單的ID）、後臺發放還是使用者行為觸發等，後續就可以用這些資訊進行營銷成本分析了。
• 為了便於擴充，實體業務欄位的定義儘可能做到全解耦，即欄位名稱不要有任何定語。欄位耦合的重災區是各種“型別”，比如“流水型別”，有很多人會設計為“系統發放”、“人工發放”、“系統核銷”、“人工核銷”，就建議拆分成“流水型別”和“操作方式”兩個欄位。
• 因為業務欄位直接決定了“中臺”間的專業化職能分工關係，所以定義欄位時，還要定義欄位資料來源及列舉 。

（3）特別提醒：

上篇文章在介紹“資料孤島”問題時提到過關係資料的重要性，所以在進行“中臺”“領域內”的業務建模時，需要基於全量業務功能藍圖，充分考慮到關係型實體或欄位的定義需求。

2.2.技術建模

“領域驅動設計”有很明確的技術建模落地方案，在此我僅強調一下充血模型在“中臺”技術建模過程中的重要性，它可以有效保障系統的可擴充性。舉個例子：

支付清結算業務中涉及多方分賬，多方分賬包括“指令分賬”和“自動分賬”兩種情況。

• 如果我們將“支付”、“分賬”分別作為一個事務進行封裝，等我們需要修改“指令分賬”功能時整個流程就阻塞了。
• 如果我們將“支付——指令分賬”、“支付——自動分賬”分別作為一個事務進行封裝，等我們需要修改“指令分賬”功能時“支付——自動分賬”這條流程將不會收到影響。

第三章：“中臺”資料治理方案

3.1.資料依賴性治理：

“中臺”的劃分遵循“多同一不”的原則，而各個“中臺”業務域中的實體本身也可能作為業務物件存在的，所以在“中臺”的業務建模過程中，可能出現某些“中臺”業務域之間有資料依賴關係的情況。為了保障各個中臺業務域的獨立性，建議採用“主資料”管理平臺對中臺間的資料依賴關係進行解耦處理。具體方案為：

1. 構建主資料管理平臺，提供主資料寫入介面；
2. 梳理領域間的資料依賴關係，並在主資料管理平臺進行需要在多領域共享的資料實體定義 。
3. 可通過“中臺”基礎資訊維護的前端直接呼叫主資料寫入介面進行相關主資料的寫入，或通過主資料獨立寫入前端進行相關主資料的寫入 。
4. 因為各有資料依賴需求的“中臺”業務域對於主資料的資料依賴規則有所區別，所以在應用時還需要根據實際資料依賴情況進行資料依賴需求註冊，從原始主資料中圈選依賴的資料；比如在主資料中“活動”和“商品”是兩個實體，卡券的可用物件需要包含“活動”和“商品”，就可以通過這種方式把“活動”和“活動”打包應用。
   
   此處是採用物件導向表示業務結構，不代表技術方案

這樣做有兩點好處：

1. 在進行“中臺”研發時各個模組之間不需要點對點進行對接聯調，都只需要對接主資料，大大降低研發難度 。
2. 因為有主資料的存在，即便被依賴的資料來源暫未構建完成，我們也可以通過資料庫預設、匯入等方式維護相關主資料 。

3.2.資料唯一性治理：

我們在進行了“中臺”專業化職能分工後，相似業務的相似資料在職能上的唯一性已經有所保障。但因為“中臺”的本質是模組元件，模組元件多數情況下是必須與其他模組元件進行業務化串聯，甚至還要進行增量的個性化定製包裝，才能夠真正解決業務問題。這時可能出現“中臺”業務域間、“中臺”和定製內容間對於不同業務的資料欄位命名一樣的情況，這雖然不會影響資料分析，但容易誤導研發，造成事故。所以建議採用“後設資料”管理來規避這種風險。具體方案為：

1. 構建“後設資料”管理平臺模組，提供“後設資料”查詢介面及監察外掛 。
2. 各“中臺”業務域及對接“中臺”服務的業務系統在進行模型構建時，可以根據業務依賴關係查詢後設資料，並選擇繫結。
3. 如果需要新增“後設資料”則後設資料管理平臺會通過外掛進行“後設資料”唯一性校驗；校驗不通過則預警，校驗通過且正式使用相關“後設資料”後，後設資料管理平臺即自動進行相關“後設資料”的註冊。
   
   此處是採用物件導向表示業務結構，不代表技術方案

3.3.資料一致性治理：

由於種種原因，某“中臺”業務可能會依賴甚至冗餘外源資料，如果外源資料發生變動，就會出現雙方資料不一致的情況。比如為了檢索更方便可能會在“積分中心”——“積分流水”中冗餘使用者手機號資訊，但使用者手機號是支援換綁的。對於此類情況我們一般有4種處理方案：

1. 僅冗餘主鍵欄位：比如積分賬戶中僅冗餘使用者ID，前端展示時使用主鍵屬性前往資料來源進行指定欄位查詢；檢索時則使用指定欄位前往資料來源查詢主鍵屬性，再用主鍵屬性去查詢當前模組資料。因為主鍵欄位不會改變，所以自然就不會出現上述問題。
2. 冗餘資料不做增量修改：比如積分發放流水冗餘了使用者手機號，我們可以理解積分發放流水為積分發放那一刻的憑證，後續就算使用者手機號變了，而積分發放那一刻的手機號是沒變的。
3. 冗餘資料在資料來源變動後實時同步，這個難度比較大。
4. 冗餘資料在資料來源變動後採用定時任務同步。

另外，為了便於後續進行資料核對，還建議所有的資料維護所有資料的修改記錄及歷史版本。在實際操作中，我們需要對“中臺”業務域內的業務細節進行全面排查，具體情況具體分析，分別選取上述不同的解決方案。

第四章：“中臺”模組間的建設順序

“中臺”的建設是有順序的，這個順序主要基於依賴性原則，即被依賴的實體、功能先做。在“中臺”劃分時，我們幾乎不可能把所有具備依賴關係的實體、功能劃分到同一個“中臺”業務域中。

鑑於除了關係型實體有著明確的依賴物件外，依賴關係並沒有什麼特別的規律，所以我建議是在進行“中臺”劃分時就需要把各“中臺”間的依賴關係理清楚。以我目前的實踐經驗來看，包含以下實體的“中臺”業務域需要優先搭建：

• 業務基礎實體：組織機構資訊、客戶、賬戶、商品等；絕大部分企業的最核心業務都是交易，交易最核心依賴的就是這些資料 。
• 資料分析關鍵實體：業務場景、渠道、終端、頁面、點位等；業務分析最核心的就是找出最有效的上述資訊。

第五章：“中臺”對外服務要點

5.1.對外介面欄位標準化：

（1）通用標準欄位定義：

上文有提到，“中臺”是底層應用，不會直接對使用者提供服務，“中臺”的對外服務需要記錄應用場景資訊。這一情況在“中臺”各業務域中都是普遍存在的，所以所有“中臺”對外暴露的介面中都應該冗餘這些通用欄位。當然，我們也可以根據具體企業的業務需要定義其他通用欄位。

（2）業務標準欄位定義：

這裡的業務標準欄位主要是根據“充血模型”的建模需求定義的。比如積分發放介面，基於貧血模型定義的介面可能如下：

• 通過積分發放賬戶關聯B端使用者ID來找到積分發放賬戶，再進行積分發放。
• 使用積分發放賬戶進行積分發放。

過多的校驗環節可能帶來較大的錯誤風險，所以建議改成“積分賬戶查詢”及“積分發放”等兩個介面，示例如下：

5.2.服務組合

前文提到“中臺”之間可能存在資料依賴，這使得很多時候上層業務系統在呼叫某“中臺”介面時，需要先去被依賴的資料來源取數，再回過頭來呼叫原先的介面。這種情況無疑會大大增加“中臺”服務的理解難度，以及上層業務系統對接“中臺”服務的聯調工作量與出錯概率。針對這種情況，建議是擴充一個“中臺”服務組合層，通過這個組合層進行各“中臺”相互依賴的介面間的組合。這樣做的好處有以下幾點：

• 可以保障領域層服務的獨立性，保障充血模型的有效性。
• “中臺”服務還可整合中臺應用服務閘道器的職能。
  

5.3.對外服務應用架構

前文有多次強調過，“中臺”的本質是模組元件，模組元件多數情況下是必須與其他模組元件進行業務化串聯，甚至還要進行增量的個性化定製包裝，才能夠真正解決業務問題。這裡的“業務化串聯”及“個性化定製包裝”工作就需要單獨擴充一個“業務應用層”來完成。注意這個“業務應用層”與“第二點”中的“中臺服務組合層”並不是一回事，服務組合層主要是基於介面間的依賴關係構建的，而“業務應用層”中需要串聯的業務之間不只存在依賴關係，比如前文“3.1.如何劃分中臺”中提到的業務之間的“支撐關係”。這裡舉個例子：抽獎活動的建立和卡券的建立之間並不存在必然的依賴關係，而在實際操作過程中，我們常常會在活動建立的過程中建立新的卡券，這就需要研發人員在“業務應用層”進行邏輯編碼。這裡有2點需要說明：

（1）“業務應用層”的設計建議採用前文提到的經濟學原理——專業化分工原則中的“物件專業化”原則，這裡就當開了個新坑，以後再專門寫一篇相關的文章，在本文中就暫不細聊了。

• 物件專業化：

按照業務物件來劃分生產單位的原則，即按不同的業務物件，建立不同的生產單位。
特點：“多不一同”。多不——不同模型 、不同方法、相同服務等；一同——相同的業務物件。

（2）我們常說的B端或者運營後臺一般就對應著這個業務應用層。所以從這個角度上來說，“中臺”相對所有業務系統來說都是更底層的，不存在文章一開始所說的“業務支撐後臺”概念。

第六章：中臺”迭代要點

6.1.常規版本迭代；

通過前文“3.1.如何劃分中臺”，我們大致可以瞭解到“中臺”以下兩個特點：

• 前瞻性：這使得很多“中臺”功能可能暫時用不到；
• 規模大：這使得“中臺”很難一兩個版本直接搞定；

所以“中臺”的迭代是很正常。在“中臺”的常規版本迭代過程中，我們可以結合企業的業務發展路徑來進行各“中臺”業務域的PI計劃制定。

6.2.重構性迭代；

雖然我們是基於專業化分工原則來劃分“中臺”職能，但以下兩點原因可能會造成中臺的重構：

• “中臺”在進行職能劃分時需要使用“能力專業化”原則，其有“多同一不”的特點，而實際“多同”是可以有不知一種解讀的，比如原先我們將“權益賬戶”劃歸了“權益中心”，後續可能我們又會將其滑軌到“賬號賬戶中心”，其實這都有道理，關鍵是看與相關企業的業務匹配度。
• 因為一些特殊原因需要將中臺進行細化。比如我司會因為部署需要，把權益中心在拆分為會員卡中心、積分中心、卡券中心等。

理論上來說，以上兩種原因造成的“中臺”重構都只是涉及到原有某一個或某幾個“中臺”，如果發現各“中臺”業務域都需要調整，那估計是一開始的“全量業務風暴”和“全量業務擴充”沒做好，這就建議從頭再來一遍了。

第七章：“中臺”對企業組織架構及其協作關係的影響

很多與“中臺”相關的文章和出版圖書中都提到了“中臺”對企業組織架構的影響，其中不乏觀點認為“中臺”的本質就是企業組織架構的升級，這可以說是錯把結果當原因了，因為組織架構是用以解決人與人之間協助問題的。實際上“中臺”與企業組織架構間的關係是這樣的：

就像“中臺”概念是用來協調“平臺”間職能分工、協作關係的一樣，組織機構是用來協調“組織成員”間職能分工、協作關係的，而恰好“中臺”的應用特性使得其需要專門的團隊維護，而新團隊的出現則帶來了新的“組織成員”間協作關係的構建需求。

因為“中臺”繼承了“平臺”解決“重複造輪問題”，並擴充出了解決“資料孤島”問題的使命，所以中臺對於組織架構的影響必然是企業級的。不過一方面運營人員直接面對的是“業務應用層”，另一方面各類資料也可以通過資料許可權進行隔離，所以“中臺”的構建不會對運營工作產生任何影響，這也很符合“中臺”的定義和使命。“中臺”的構建主要影響的還是IT團隊。

7.1.增設新的部門；

“中臺”的構建和運維工作有以下特點：

1. 首先，“中臺”的研發工作將持續一個長週期，這期間工作密度較大，但如果一切正常，在這個階段後，相關研發工作就會急劇減少，除非需要進行某些“中臺”業務域的重構；
2. 其次，“中臺”構建完成後，構建各業務系統的IT團隊在對接“中臺”時，需要進行高強度的業務諮詢及技術諮詢；
3. 最後，因為“中臺”雖然進行了“專業化分工”和“資料唯一性建模”，所以在實際生產環境中，“中臺”承擔的併發量是各業務線相似業務的併發量之和，這使得“中臺”對於業務運維、應用運維人員、技術運維及DBA的能力及響應速度要求都高出一般的業務系統很多。

基於上述特點，我們建議需要圍繞“中臺”增設一個部門，這個部門及其人員配備應具備以下特點：

1. 為了保障中臺的獨立性，不會輕易被業務系統的需求所碾壓，該部門最好與業務系統的研發部門平行存在；
2. 因為“中臺”構建的工作量前重後輕，所以相關研發團隊建議是從原有業務系統研發部門抽調，待“中臺”研發工作取得階段性成果後，可以逐步釋放回原來的部門。這樣做的好處還有：因為相關研發團隊對原有業務系統比較熟悉，更能夠做好業務組合、關係實體構建以及其他前瞻性設計；
3. 因為“中臺”對於運維工作要求高，所以相關團隊建議單獨建立，可以招聘，可以抽調，但要穩定；
4. 相關業務架構師、技術架構師需要保持穩定，以保持業務和技術理解的連續性。
5. 構建各業務系統的IT團隊在對接中臺時，在進行業務諮詢和技術諮詢時需要有專門的顧問解答，具體工作內容在下方“研發及運維流程調整”章節有詳細描述。

7.2.研發及運維流程調整；

鑑於“中臺”的企業級使命，所以在新的部門成立後，以下工作要點需要注意：

1. 是否需要接入“中臺”服務，不能由業務系統研發團隊自己說了算，需要由業務系統研發團隊派出“產品經理”、“技術經理”與“中臺”團隊的“業務諮詢顧問”及“技術諮詢顧問”共同商討決定；
2. 無論某個業務系統最終是否接入了“中臺”服務，其模型及後設資料必須上報“中臺”-“後設資料管理平臺”，也必須遵循企業層面後設資料唯一性原則；
3. 因為“中臺”與業務系統間是“1對多”的關係，正常情況下如果“中臺”出了問題所有業務系統都會受到影響，所以在某個業務系統與“中臺”的銜接環節出現了問題後，需要先由業務系統相關運維團隊進行問題定位。

基於上述要點，我們建議業務系統研發流程大致如下：

（1）業務系統研發流程：

①業務系統研發團隊“產品經理”、“技術經理”深度學習“中臺”服務；
②業務系統研發團隊“產品經理”、“技術經理”對自身業務及模型進行梳理，初步確定與“中臺”間的互動關係；
③業務系統研發團隊“產品經理”、“技術經理”提交工單申請“中臺”服務諮詢，並與“中臺”團隊的“業務諮詢顧問”及“技術諮詢顧問”交流確認業務系統與“中臺”間的互動關係；
④業務系統研發團隊“產品經理”、“技術經理”在得到“中臺”團隊的“業務諮詢顧問”及“技術諮詢顧問”確認後，申請接入“中臺”服務，並在通過後獲得相關介面文件及其他必要材料/工具/閘道器授權等；
⑤業務系統研發團隊在系統構建過程中全程受“中臺”後設資料管理平臺及業務編排監控外掛的監控，以免出現資料“張冠李戴”等錯誤；

（2）業務系統研發流程異常處理：

①業務系統如涉及到“中臺”還在研發中的需求，可以在經過高層審批後，酌情讓業務系統自身定製，但相關問題需要由負責的“業務諮詢顧問”及“技術諮詢顧問”記錄，並在後續“中臺”相關服務上線後立即進行服務切換及資料遷移；
②一旦發現“後設資料重複定義”及其他明令禁止的，會影響“中臺”職能定義及“資料歸一”的問題，即使相關模組已上線，也需要立刻進行修正。

運維流程大致如下：

（1）“中臺”內部運維流程：

①由“中臺”測試團隊每日彙總內部問題，並根據問題嚴重性進行排期，嚴重問題需要當日解決；
②各“中臺”業務域按照測試的排期計劃進行相關修復工作。

（2）缺陷型業務應用生產問題運維流程：

①問題發生後由業務系統運維團隊優先定位問題，在排除業務系統問題後，向“中臺”運維團隊業務運維崗提交工單；
②由“中臺”運維團隊的業務運維崗每日彙總缺陷型業務應用生產問題，所有問題必須當日定位，當日解決；

（3）需求性業務應用生產問題運維流程：

①由業務系統運維團隊提交需求性業務應用生產問題工單至“中臺”運維團隊的應用運維崗；
②“中臺”運維團隊的應用運維崗對業務需求進行核實和確認，制定伺服器記憶體擴容等解決方案，並提交相關主管稽核；
③相關主管稽核通過後即可以啟用相關解決方案；

在實際操作中，細節可能要比上述描述更加複雜，因為篇幅有限，暫且略過了。

第八章：寫在最後

至此，《中臺詳解系列》文章完結了，文中所載均是我個人一些微薄、淺顯的見識，“中臺”作為軟體建設的一個里程碑式概念（至少基於個人對“中臺”的定義我是這麼認為的）有著太多內容可以探討，所以如有不同觀點，歡迎聯絡作者進行交流，彼此促進，共同成長。