編輯導語：上篇文章中作者詳細介紹了《什麼是中台》，2016年阿裡提出的“大中台小前台”戰略後，很多企業開始想搭建中台；本文作者詳細介紹了中台的定義及在“中台”建設方面的經驗和方案，我們一起來看一下。
《中台詳解系列》共分上下兩篇，本文為下篇，總計約12000字，因為文中涉及知識體系較為廣泛，建議預留30-50分鐘進行閱讀。
目前市場僅對“中台”和“平台”間的繼承和發展關系有一定共識，“中台”的定義及建設規範尚未有明确定論。
本系列文章旨在基于“以終為始”的思維模式，及“軟體對現實世界模組化”的基礎條件，梳理傳統軟體“平台”所面臨的問題；并以此為起點，結合經濟學中專業化分工協作理論，為“中台”進行職能定義，再通過“中台”的職能定義給出“中台”建設的建議方案。
阿裡雲在提出“中台”戰略後，僅在一定程度上給出了“資料中台”的建設規範，同時市面上關于“中台”的介紹性文章也都避而不談“中台”的落地方案，想是仍未統一。
本文中，我将主要介紹基于我個人對于“中台”的定義及在“中台”建設方面的經驗，總結得出的“中台”總體建設建議方案；不過因為篇幅原因可能不會過于細緻，也不會探讨“業務中台”、“資料中台”、“技術中台”在細節上的差别。
相關内容主要包括以下幾個章節：
- 如何劃分“中台”
- “中台”領域内模組化要點
- “中台”資料治理方案
- “中台”子產品間建設順序
- “中台”對外服務要點
- “中台”疊代要點
- “中台”對組織架構及其協作關系的影響
一、如何劃分“中台”
要做“中台”，首先自然就是得梳理清楚可以有哪些“中台”。
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對多”的關系，正常情況下如果“中台”出了問題所有業務系統都會受到影響，是以在某個業務系統與“中台”的銜接環節出現了問題後，需要先由業務系統相關運維團隊進行問題定位。
基于上述要點，我們建議業務系統研發流程大緻如下：
業務系統研發流程：
- 業務系統研發團隊“産品經理”、“技術經理”深度學習“中台”服務；
- 業務系統研發團隊“産品經理”、“技術經理”對自身業務及模型進行梳理，初步确定與“中台”間的互動關系；
- 業務系統研發團隊“産品經理”、“技術經理”送出工單申請“中台”服務咨詢，并與“中台”團隊的“業務咨詢顧問”及“技術咨詢顧問”交流确認業務系統與“中台”間的互動關系；
- 業務系統研發團隊“産品經理”、“技術經理”在得到“中台”團隊的“業務咨詢顧問”及“技術咨詢顧問”确認後，申請接入“中台”服務，并在通過後獲得相關接口文檔及其他必要材料/工具/網關授權等；
- 業務系統研發團隊在系統建構過程中全程受“中台”中繼資料管理平台及業務編排監控插件的監控，以免出現資料“張冠李戴”等錯誤；
業務系統研發流程異常處理：
- 業務系統如涉及到“中台”還在研發中的需求，可以在經過高層審批後，酌情讓業務系統自身定制，但相關問題需要由負責的“業務咨詢顧問”及“技術咨詢顧問”記錄，并在後續“中台”相關服務上線後立即進行服務切換及資料遷移；
- 一旦發現“中繼資料重複定義”及其他明令禁止的，會影響“中台”職能定義及“資料歸一”的問題，即使相關子產品已上線，也需要立刻進行修正。
運維流程大緻如下：
“中台”内部運維流程：
- 由“中台”測試團隊每日彙總内部問題，并根據問題嚴重性進行排期，嚴重問題需要當日解決；
- 各“中台”業務域按照測試的排期計劃進行相關修複工作。
缺陷型業務應用生産問題運維流程：
- 問題發生後由業務系統運維團隊優先定位問題，在排除業務系統問題後，向“中台”運維團隊業務運維崗送出工單；
- 由“中台”運維團隊的業務運維崗每日彙總缺陷型業務應用生産問題，所有問題必須當日定位，當日解決；
需求性業務應用生産問題運維流程：
- 由業務系統運維團隊送出需求性業務應用生産問題工單至“中台”運維團隊的應用運維崗；
- “中台”運維團隊的應用運維崗對業務需求進行核實和确認，制定伺服器記憶體擴容等解決方案，并送出相關主管稽核；
- 相關主管稽核通過後即可以啟用相關解決方案；
在實際操作中，細節可能要比上述描述更加複雜，因為篇幅有限，暫且略過了。
八、寫在最後
至此，《中台詳解系列》文章完結了，文中所載均是我個人一些微薄、淺顯的見識，“中台”作為軟體建設的一個裡程碑式概念（至少基于個人對“中台”的定義我是這麼認為的）有着太多内容可以探讨。
文章來源：http://www.woshipm.com/it/4231444.html