編輯導語：上篇文章中作者詳細介紹了《什么是中臺》，2016年阿里提出的“大中臺小前臺”戰略后，很多企業開始想搭建中臺；本文作者詳細介紹了中臺的定義及在“中臺”建設方面的經驗和方案，我們一起來看一下。

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

目前市場僅對“中臺”和“平臺”間的繼承和發展關系有一定共識，“中臺”的定義及建設規范尚未有明確定論。

本系列文章旨在基于“以終為始”的思維模式，及“軟件對現實世界建?！钡幕A條件，梳理傳統軟件“平臺”所面臨的問題；并以此為起點，結合經濟學中專業化分工協作理論，為“中臺”進行職能定義，再通過“中臺”的職能定義給出“中臺”建設的建議方案。

阿里云在提出“中臺”戰略后，僅在一定程度上給出了“數據中臺”的建設規范，同時市面上關于“中臺”的介紹性文章也都避而不談“中臺”的落地方案，想是仍未統一。

本文中，我將主要介紹基于我個人對于“中臺”的定義及在“中臺”建設方面的經驗，總結得出的“中臺”總體建設建議方案；不過因為篇幅原因可能不會過于細致，也不會探討“業務中臺”、“數據中臺”、“技術中臺”在細節上的差別。

相關內容主要包括以下幾個章節：

• 如何劃分“中臺”
• “中臺”領域內建模要點
• “中臺”數據治理方案
• “中臺”模塊間建設順序
• “中臺”對外服務要點
• “中臺”迭代要點
• “中臺”對組織架構及其協作關系的影響

一、如何劃分“中臺”

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

1. 原理說明

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

“中臺”需要通過專業化分工來解決“軟件平臺間職能邊界劃分問題”，專業化分工的本質是一種分類規則，要想分類我們就先得梳理自己有哪些業務功能以及要做哪些業務功能。

所有的軟件及其背后的理論、原理、概念、技術都是為了解決業務問題而產生的，所以在梳理“自己有哪些業務功能以及要做哪些業務功能”之前，需要先梳理清楚業務目標，這可以幫助我們評估業務功能梳理及其他工作的合理性。

“軟件平臺”的專業化職能分工所需采用的“能力專業化”的原則，有著“多同一不”的特點（上篇文章有說明），所以建議提煉業務功能中的實體作為后續業務功能“分類”的“錨點”；將業務功能轉化為類圖等直觀可視的靜態模型，可以有效降低思維難度。

“中臺”的構建需要在企業層面拉通。

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

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

不過目前“領域驅動設計”的落地實施方案是由技術人員總結的，主要應用于某個既定領域內的建模，如果我們直接用來進行“中臺”的“專業化分工”和“數據唯一性建?！笨赡懿惶?。

所以針對“中臺”的目標特征，我這里借助“領域驅動設計”思想，魔改了一套經驗證可行的方案，大家可以簡單了解一下。（由于“領域驅動設計”是基于面向對象思想衍生出來的一種建模方法，如果對于面向對象不太熟悉，可能不太看得懂，所以如果實在看不懂建議先跳過本段。）

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

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

4. 操作方案

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

第一階段：

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

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

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

具體流程：

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

1）在進行業務目標分解時需要優先關心其在商業上的橫向拓展。

以下為我個人總結的幾個拓展點：

• 上下游業務拓展：比如犀牛制造和菜鳥物流之于淘寶 。
• 資源變現：比如滴滴搞外賣 。
• 數據變現：比如抖音、微信的用戶標簽等 。
• 流量變現：比如抖音、微信的引流服務等 。

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

以營銷體系為例：

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

雖然我們在“中臺”設計過程中，業務目標劃分的越細越好，不過業務子目標的分解也不是無限制的，最終狀態的子目標會有著鮮明的場景化特征，大致可以用以下模型表示。

比如：連鎖零售商總部營銷部門在“女性用戶”“非首次”情況下通過“ APP”購買“任意”商品時向其發放“肯德基10代金券”，以提高用戶通過APP下單的積極性 。

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

即對照“業務目標金字塔模型”對已有業務功能進行梳理，輸出已有全量業務功能版圖。

要求精確到實體，在操作本環節時，以下幾點需要注意：

前文說明“數據孤島”問題時提到過關系數據的重要性，所以在進行已有全量業務功能版圖梳理時，關系型實體或字段務必要梳理清楚，不能遺漏，比如訂單觸發積分發放的記錄等。

一般來說因為缺乏專業化職能分工設計，業務系統中會出現大量以下類型的臨時方案：

• 人機交互型臨時方案：比如業務場景沒有定義好，在使用某服務時由人工錄入服務的使用場景 。
• 在代碼中埋數據的臨時方案：比如某店鋪的銀行卡信息直接寫死。
• 在進行業務功能風暴時，此類臨時方案一定要還原成通用方案。

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

第三步：企業全量業務功能拓展。

即對照“業務目標金字塔模型”，基于第二步中輸出的已有全量業務功能版圖，梳理未來還可能會有哪些業務功能；因為“中臺”在應用時處于底層，會被很多上層業務系統集成，如果“中臺”沒有做好前瞻性設計，后續迭代風險會比較大。

以下為我個人總結的幾種拓展點：

業務功能細化拓展：在數據層面表現為字段取值范圍的增加，比如客戶類型的枚舉值從“個人客戶”增加到“個人客戶、機構客戶”，即表示目標客戶從個人客戶拓展到了機構客戶。

另外拋開約束性校驗和界面交互，所以軟件的底層功能有且僅有對某實體某字段的增刪改查，即每個實體天然有“字段數量*增刪改查”個功能。

業務功能閉環性拓展：這一項主要是基于面向對象中的組合思想進行的拓展，即解決某一問題時可能需要多個功能組合完成，我們據此判斷缺失了哪個功能；比如要達成用戶激勵，光有積分發放是不行的，還得需要積分消費功能。

業務功能依賴/約束性拓展：在數據層面表現為實體字段的增刪改查需要從外部數據源取數或對外部數據源進行校驗；比如物流單中商品信息就需要從商品模塊獲取，用戶下單時需要對商品庫存數量進行校驗 。

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

業務功能縱向拓展：在數據層面表現為對實體及其屬性、方法、實體間關系進行定義；比如設置積分的面值，進行用戶操作權限授權等。

業務功能解耦分化型拓展：在數據層面表現為實體的拆分；比如有些車企自建的整車商城，包含汽車交易及汽車物權管理兩條業務線，為了保障業務靈活度，最好就是將整車交易單拆分為商品交易單和物權轉讓單。

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

第二階段：

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

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

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

具體流程：

第四步：關鍵屬性定義。

每個業務都有很多附加功能，這使得這些業務對應的實體會有很多屬性，但實際上每個實體都僅有少量的幾個關鍵屬性定義了“它是它”。

實體的屬性過多會對實體間的關系整理形成干擾，所以我們需要找出每個實體的關鍵屬性。

關于什么是核心屬性，我這里舉幾個例子：

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

第五步：實體抽象合并。

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

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

第六步：可復用業務定義。

接下來，我們需要基于“多同一不”（上篇文章有說明）的原則找到那些服務不同對象的“模型、方法”，這是專業化分工的基礎。

這里還是舉個例子，比如“權益發放”即為服務不同對象的“模型、方法”。

“權益發放”作為服務不同對象的“模型、方法”在業務上表現為：權益發放可以應用于包括用戶注冊、用戶簽到、用戶下單等多個業務，所以即為服務不同對象的“模型、方法”。

“權益發放”作為服務不同對象的“模型、方法”在數據上表現為：

情況1：實體：用戶注冊記錄（如果有的話）、用戶簽到記錄（如果有的話）、用戶訂單（如果有的話）都冗余了權益發放數量信息 。

情況2：實體：用戶注冊記錄（如果有的話）、用戶簽到記錄（如果有的話）、用戶訂單（如果有的話）都冗余了權益發放規則信息，而權益發放規則冗余了積分發放數量信息 。

第七步：“中臺”邊界劃分。

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

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

然后我們在通過實體關鍵屬性所表現出關聯關系進行組合，比如：

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

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

需要注意的是，因為“中臺”強調專業化職能分工，就像企業員工在實施某項目時，協作的各工種之間有很多銜接環節一樣，在實際開展業務過程中，“中臺”功能間也需要很多銜接性功能才能夠真正支持業務。

一般來說，為了避免影響業務職能的完整性，不建議將這些銜接性功能強行劃分到某個“中臺”業務域中；實在不行，建議單獨抽象一個“業務流程編排/管理中臺”來統一行使功能銜接的職能。

第八步：“中臺”邊界修正。

第一，我們不排除有“基于關鍵屬性是沒有直接聯系的兩個實體”需要劃分到同一個“中臺”業務域中的可能，比如，有企業因為商品和訂單在業務上緊密的關系而將兩者劃歸為交易中臺；

第二，也不排除有“基于關鍵屬性是有直接聯系的兩個實體”需要劃分到不同“中臺”業務域中的可能。比如，很多軟件供應商會因為部署需要，把權益中心在拆分為會員卡中心、積分中心、卡券中心等；

第三，會有一些業務特征不明顯的功能是跨領域的，這種功能實際上可以抽象提取出來作為一個獨立的“中臺”板塊，比如基于用戶行為發卡券、積分、短信的功能可抽象為事件營銷中臺。

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

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

二、“中臺”領域內建模要點

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

1. 業務建模

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

1）功能拓展

主體步驟跟“中臺劃分原則”中“第一步”階段的差不多，主要還是基于業務目標和“領域驅動設計”思想對已有實體和功能進行各種形式的拓展，這里也就不重復說明了。

僅強調以下要點：

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

2）業務字段定義

由于“中臺”還承擔著解決“數據孤島”的使命，所以在進行“中臺”的業務建模時需要進行實體業務字段的定義。

這一部分我們重點聊一下：

除了核心屬性字段外，我們需要基于以下要點進行字段冗余：基于實體間的依賴關系進行字段冗余，比如“卡券僅可用于指定商品功能”，就要求“卡券”實體冗余可用“商品ID”字段 。

“中臺”是底層應用，不會直接對用戶提供服務，都是上層業務系統按照一定邏輯順序調用“中臺”的接口來實現業務串聯的；而上層業務系統在調用中臺服務時是基于明確的業務場景的，為了滿足后續數據分析、生產問題定位等目標，上層業務系統調用“中臺”服務時需要入參相關服務調用的具體應用場景，而“中臺”建模時也需要考慮相關數據的存儲。

比如某APP后臺調用積分中心、卡券中心進行積分或卡券的發放時都需要入參渠道ID、業務終端ID、操作人ID、業務ID（如訂單這一業務的ID）、業務流水號（如具體某一筆訂單的ID）、后臺發放還是用戶行為觸發等，后續就可以用這些信息進行營銷成本分析了。

為了便于拓展，實體業務字段的定義盡可能做到全解耦，即字段名稱不要有任何定語；字段耦合的重災區是各種“類型”，比如“流水類型”，有很多人會設計為“系統發放”、“人工發放”、“系統核銷”、“人工核銷”，就建議拆分成“流水類型”和“操作方式”兩個字段。

因為業務字段直接決定了“中臺”間的專業化職能分工關系，所以定義字段時，還要定義字段數據來源及枚舉 。

3）特別提醒

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

2. 技術建模

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

舉個例子：

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

如果我們將“支付”、“分賬”分別作為一個事務進行封裝，等我們需要修改“指令分賬”功能時整個流程就阻塞了。

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

三、“中臺”數據治理方案

1. 數據依賴性治理

“中臺”的劃分遵循“多同一不”的原則，而各個“中臺”業務域中的實體本身也可能作為業務對象存在的，所以在“中臺”的業務建模過程中，可能出現某些“中臺”業務域之間有數據依賴關系的情況。

為了保障各個中臺業務域的獨立性，建議采用“主數據”管理平臺對中臺間的數據依賴關系進行解耦處理。

具體方案為：構建主數據管理平臺，提供主數據寫入接口；梳理領域間的數據依賴關系，并在主數據管理平臺進行需要在多領域共享的數據實體定義 。

可通過“中臺”基礎信息維護的前端直接調用主數據寫入接口進行相關主數據的寫入，或通過主數據獨立寫入前端進行相關主數據的寫入 。

因為各有數據依賴需求的“中臺”業務域對于主數據的數據依賴規則有所區別，所以在應用時還需要根據實際數據依賴情況進行數據依賴需求注冊，從原始主數據中圈選依賴的數據；比如在主數據中“活動”和“商品”是兩個實體，卡券的可用對象需要包含“活動”和“商品”，就可以通過這種方式把“活動”和“活動”打包應用。

此處是采用面向對象表示業務結構，不代表技術方案

這樣做有兩點好處：

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

2. 數據唯一性治理

我們在進行了“中臺”專業化職能分工后，相似業務的相似數據在職能上的唯一性已經有所保障；但因為“中臺”的本質是模塊組件，模塊組件多數情況下是必須與其他模塊組件進行業務化串聯，甚至還要進行增量的個性化定制包裝，才能夠真正解決業務問題。

這時可能出現“中臺”業務域間、“中臺”和定制內容間對于不同業務的數據字段命名一樣的情況，這雖然不會影響數據分析，但容易誤導研發，造成事故；所以建議采用“元數據”管理來規避這種風險。

具體方案為：

• 構建“元數據”管理平臺模塊，提供“元數據”查詢接口及監察插件 。
• 各“中臺”業務域及對接“中臺”服務的業務系統在進行模型構建時，可以根據業務依賴關系查詢元數據，并選擇綁定。
• 如果需要新增“元數據”則元數據管理平臺會通過插件進行“元數據”唯一性校驗；校驗不通過則預警，校驗通過且正式使用相關“元數據”后，元數據管理平臺即自動進行相關“元數據”的注冊。

此處是采用面向對象表示業務結構，不代表技術方案

3. 數據一致性治理

由于種種原因，某“中臺”業務可能會依賴甚至冗余外源數據，如果外源數據發生變動，就會出現雙方數據不一致的情況；比如為了檢索更方便可能會在“積分中心”——“積分流水”中冗余用戶手機號信息，但用戶手機號是支持換綁的。

對于此類情況我們一般有4種處理方案：

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

另外，為了便于后續進行數據核對，還建議所有的數據維護所有數據的修改記錄及歷史版本。

在實際操作中，我們需要對“中臺”業務域內的業務細節進行全面排查，具體情況具體分析，分別選取上述不同的解決方案。

四、“中臺”模塊間的建設順序

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

鑒于除了關系型實體有著明確的依賴對象外，依賴關系并沒有什么特別的規律，所以我建議是在進行“中臺”劃分時就需要把各“中臺”間的依賴關系理清楚。

以我目前的實踐經驗來看，包含以下實體的“中臺”業務域需要優先搭建：

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

五、“中臺”對外服務要點

1. 對外接口字段標準化

1）通用標準字段定義：

上文有提到，“中臺”是底層應用，不會直接對用戶提供服務，“中臺”的對外服務需要記錄應用場景信息。

這一情況在“中臺”各業務域中都是普遍存在的，所以所有“中臺”對外暴露的接口中都應該冗余這些通用字段；當然，我們也可以根據具體企業的業務需要定義其他通用字段。

2）業務標準字段定義：

這里的業務標準字段主要是根據“充血模型”的建模需求定義的，比如積分發放接口，基于貧血模型定義的接口可能如下：

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

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

2. 服務組合

前文提到“中臺”之間可能存在數據依賴，這使得很多時候上層業務系統在調用某“中臺”接口時，需要先去被依賴的數據源取數，再回過頭來調用原先的接口。

這種情況無疑會大大增加“中臺”服務的理解難度，以及上層業務系統對接“中臺”服務的聯調工作量與出錯概率；針對這種情況，建議是拓展一個“中臺”服務組合層，通過這個組合層進行各“中臺”相互依賴的接口間的組合。

這樣做的好處有以下幾點：

• 可以保障領域層服務的獨立性，保障充血模型的有效性。
• “中臺”服務還可集成中臺應用服務網關的職能。

3. 對外服務應用架構

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

這里的“業務化串聯”及“個性化定制包裝”工作就需要單獨拓展一個“業務應用層”來完成。

注意這個“業務應用層”與“第二點”中的“中臺服務組合層”并不是一回事，服務組合層主要是基于接口間的依賴關系構建的，而“業務應用層”中需要串聯的業務之間不只存在依賴關系；比如前文“3.1.如何劃分中臺”中提到的業務之間的“支撐關系”。

這里舉個例子：抽獎活動的創建和卡券的創建之間并不存在必然的依賴關系，而在實際操作過程中，我們常常會在活動創建的過程中創建新的卡券，這就需要研發人員在“業務應用層”進行邏輯編碼。

這里有2點需要說明：

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

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

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

六、“中臺”迭代要點

1. 常規版本迭代

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

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

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

2. 重構性迭代

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

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

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

七、“中臺”對企業組織架構及其協作關系的影響

很多與“中臺”相關的文章和出版圖書中都提到了“中臺”對企業組織架構的影響，其中不乏觀點認為“中臺”的本質就是企業組織架構的升級，這可以說是錯把結果當原因了。

實際上“中臺”與企業組織架構間的關系是這樣的：

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

因為“中臺”繼承了“平臺”解決“重復造輪問題”，并拓展出了解決“數據孤島”問題的使命，所以中臺對于組織架構的影響必然是企業級的。

不過一方面運營人員直接面對的是“業務應用層”，另一方面各類數據也可以通過數據權限進行隔離，所以“中臺”的構建不會對運營工作產生任何影響，這也很符合“中臺”的定義和使命；“中臺”的構建主要影響的還是IT團隊。

1. 增設新的部門

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

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

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

• 為了保障中臺的獨立性，不會輕易被業務系統的需求所碾壓，該部門最好與業務系統的研發部門平行存在；
• 因為“中臺”構建的工作量前重后輕，所以相關研發團隊建議是從原有業務系統研發部門抽調，待“中臺”研發工作取得階段性成果后，可以逐步釋放回原來的部門；這樣做的好處還有：因為相關研發團隊對原有業務系統比較熟悉，更能夠做好業務組合、關系實體構建以及其他前瞻性設計；
• 因為“中臺”對于運維工作要求高，所以相關團隊建議單獨建立，可以招聘，可以抽調，但要穩定；
• 相關業務架構師、技術架構師需要保持穩定，以保持業務和技術理解的連續性。

構建各業務系統的IT團隊在對接中臺時，在進行業務咨詢和技術咨詢時需要有專門的顧問解答，具體工作內容在下方“研發及運維流程調整”章節有詳細描述。

2. 研發及運維流程調整

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

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

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

業務系統研發流程：

• 業務系統研發團隊“產品經理”、“技術經理”深度學習“中臺”服務；
• 業務系統研發團隊“產品經理”、“技術經理”對自身業務及模型進行梳理，初步確定與“中臺”間的交互關系；
• 業務系統研發團隊“產品經理”、“技術經理”提交工單申請“中臺”服務咨詢，并與“中臺”團隊的“業務咨詢顧問”及“技術咨詢顧問”交流確認業務系統與“中臺”間的交互關系；
• 業務系統研發團隊“產品經理”、“技術經理”在得到“中臺”團隊的“業務咨詢顧問”及“技術咨詢顧問”確認后，申請接入“中臺”服務，并在通過后獲得相關接口文檔及其他必要材料/工具/網關授權等；
• 業務系統研發團隊在系統構建過程中全程受“中臺”元數據管理平臺及業務編排監控插件的監控，以免出現數據“張冠李戴”等錯誤；

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

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

運維流程大致如下：

“中臺”內部運維流程：

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

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

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

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

• 由業務系統運維團隊提交需求性業務應用生產問題工單至“中臺”運維團隊的應用運維崗；
• “中臺”運維團隊的應用運維崗對業務需求進行核實和確認，制定服務器內存擴容等解決方案，并提交相關主管審核；
• 相關主管審核通過后即可以啟用相關解決方案；

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

八、寫在最后

至此，《中臺詳解系列》文章完結了，文中所載均是我個人一些微薄、淺顯的見識，“中臺”作為軟件建設的一個里程碑式概念（至少基于個人對“中臺”的定義我是這么認為的）有著太多內容可以探討。

所以如有不同觀點，歡迎聯系作者進行交流，彼此促進，共同成長。

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

題圖來自Unsplash，基于CC0協議