中臺之上（七）：不神祕但很麻煩的業務架構落地過程

摘要： 將模型轉化成方案 業務架構設計不是替代需求分析的 經過之前的努力，我們終於建立了通過業務模型設計的企業級業務架構，建模過程中，已經分析了企業戰略、企業價值、組織結構、價值鏈、業務領域、崗位角色、業務流程、資料等一系列架構元素，通過模型方法對上述元素進行了分析，並形成了元件、主題域的劃分...

將模型轉化成方案

業務架構設計不是替代需求分析的

經過之前的努力，我們終於建立了通過業務模型設計的企業級業務架構，建模過程中，已經分析了企業戰略、企業價值、組織結構、價值鏈、業務領域、崗位角色、業務流程、資料等一系列架構元素，通過模型方法對上述元素進行了分析，並形成了元件、主題域的劃分。業務架構設計並不是為了停留在紙上，而是為了實踐，為了推動開發，尤其是面向複雜系統的企業級開發。但是，模型能夠表達的資訊其實是有限的，所以，將模型應用於開發之前，我們還是要明確好模型的使用價值和定位。

按照之前的方式做的模型是用來進行高階設計的，從戰略出發，分析企業的目標和為實現目標需要的業務能力。然後，按照業務領域，將能力需求落實到實際的業務流程中，並根據架構設計方法，劃分出能力元件，形成企業的能力檢視。這樣，就產生了高階架構。但是這個架構雖然分析的有條有理，卻並沒有細到可以直接出 IT 設計方案的程度，也就是說，它只能明確企業級架構，不足以替代具體的需求分析。它更關注的是企業視角的整體結構，而非每一個細節。企業級業務架構是一個規劃，而非詳細的實施圖紙，它要求的是 IT 設計繼承這套結構，繼續向下分解為 IT 的設計元素。

業務架構設計到當前這個層級是可以與實施之間保持一定自由度的，即，不完全受實施方式的約束。這種自由度是好事兒，可以保持架構的穩定和靈活；但也有不利的一面，它與實施的結合離不開架構設計人員與實施人員的密切溝通，它不是一個無需解釋就可以直接繼承的設計。

業務模型向業務架構方案的轉化

明確了這個定位，我們再繼續探討業務架構落地過程的第一步，也就是將模型轉化成業務架構設計方案。模型涵蓋了很多東西，但是直接看模型並不是一個好選擇，特別是做企業級專案，多個專案組同時開工，如果業務架構設計以模型的方式直接扔下去，必然會解讀的千奇百怪，這是很自然的事情，“一千個人眼中有一千個哈姆雷特”。所以將模型轉化為方案的過程其實是個導讀和解釋的過程，我們一起理理方案應包含的內容。

IT 人員做系統分析時會關注三個比較重要的東西：邊界、結構、關係。首先是邊界，邊界就是系統的範圍，也是我們工作成果的範圍，沒有邊界的專案永遠做不成，因為永遠也做不完。所以，業務架構方案要闡明業務的邊界，這是最高階的上下文。對於整體價值鏈和全領域視角的整體介紹可以單獨形成文件，作為整體概念向整個企業傳導。而領域級闡述的方式則應首先解釋業務領域的定義、範圍和利益干係人檢視，利益干係人檢視可以解釋清楚所有業務參與方及其訴求，也就是大家對功能的期待。在闡述清楚上述內容之後，要明確業務目標，就是方案要達到的業務效果。如果目標比較巨集大，則可以在總目標下分解出子目標或者分階段的目標，以使 IT 人員能夠理解具體的目標點或者實施路徑。

解釋了專案邊界與目標之後，進入結構、內容的編寫，也就是闡述活動、任務、實體及元件的設計，以及它們之間關係。對於新建領域，可以從價值鏈的簡介開始，明確高階的結構。之後，可以選擇活動的介紹順序，按照活動的內在順序介紹還是按照價值鏈的順序介紹其實都可以，並沒有嚴格規則，但是一個企業內部最好採用同一種順序，這樣便於跨領域閱讀架構文件。我們上一講介紹的案例比較簡單，如果我們採用它繼續做示例，則可以按照價值鏈的順序依次介紹各個活動，比如存款領域，依次介紹“設計上架產品”、“獲取新客戶”、“維護老客戶”、“存款”四個活動，以活動為單位介紹活動的範圍，要達到的目的以及活動之間可能的銜接關係；詳細介紹參與到活動中的角色，包括其歸屬的部門；簡述每個任務的執行過程，任務間的銜接關係、角色在任務中的許可權，每個任務中如何建立、修改資料實體。對活動和任務介紹完後，則對本業務領域涉及的資料實體按照主題域進行 ER 圖展示。流程模型和資料模型介紹完之後，介紹本領域涉及的元件，對每個元件的邊界、包含的任務和資料實體進行說明。業務架構方案大體包含這些內容。

需要說明的是，從業務領域入手形成業務架構方案，實際上是從應用視角著手，對於較為複雜的業務領域，可能包含多個應用，比如金融市場領域中，外匯、貴金屬、利率等業務都可以形成不同的應用，那麼一個領域下就可以再細分為多個業務架構方案，而不必都混在一起，把方案搞得太過複雜，部頭兒太大，難以閱讀。另外，業務領域或者說應用與元件之間是多對多的關係，比如存款領域中的客戶管理、賬戶管理元件跟貸款領域就是共用的。習慣上 IT 通常會按照應用視角組織專案，這樣比較容易管理專案目標和處理協作關係，但是專案內部又會考慮按照元件來劃分實施團隊，這樣便於功能開發的分工。

所以，業務架構方案必須具備兩種視角的構造能力，既能從領域視角形成元件的協作檢視，又能從元件視角形成一類業務能力如何被整個企業運用的分工檢視，這是兩種不同的文件，做為架構方案來講都應該支援，否則，負責元件開發的實施團隊就難以把握企業級的實施要求，對於粉“中臺”的同學來講，元件文件也是規劃中臺需要的，但是文件製作是件非常麻煩的事情，所以，最好採用工具支援文件生成。

寫方案的過程要下定義、講範圍，好多時候看起來是枯燥的文字工作，甚至有些時候為了區分一些相近的概念，還會玩起“文字遊戲”，但是，整理業務架構方案的過程其實是對業務架構設計的再次確認，而非單純的圖紙翻文案、搞 PPT 彙報，一定要把這個過程當作是一次全面的模型質量檢驗來做。

落地的關鍵：對模型的解釋

人是社會性生物，群體力量遠勝過個體，而群體力量的發揮依靠的是明確的分工和有效的溝通。溝通順暢，不同族群的人也能一起把巴別塔修到天上；而溝通不暢，再偉大的工程也只能半途而廢。企業級專案就是一類典型的巴別塔專案，巴別塔要成功就要所有人形成統一語言，而用於描述企業級業務架構的業務模型，其主要作用之一就是承擔統一語言的職能，通過模型傳播業務知識。

為什麼還需要解釋？

經過建模過程，我們將企業目標落實到業務過程中，並將其整理成業務架構設計方案，做為“語言”的模型和做為“書籍”的方案都齊備了，但是知識的傳播並不會就這樣順理成章地進行下去，如同練功一樣，需要一個不間斷的實踐過程。

大家可能會覺得，建模過程不就解決了各方對模型的理解了嗎？如果專案範圍小、參加人數少，這自然不會成為大問題，但是如果在大型企業，數萬人、十幾萬人、甚至幾十萬人的企業，按照管理學定律，溝通的複雜度是呈幾何級數上升的。大型企業中，直接參加專案的人也是非常多的，以筆者所在單位曾經做過的企業級專案而言，集中建模階段，參加業務建模的人數約 500-600 人，而實際參加開發的人員則達到上萬人次。可見，真正做過建模的與參加專案的人數比例大約在 1：20 以上。

集中建模階段過後，常規負責建模工作的人大約不到 100 人，也就是後續需求產生時，即便只按照專案平均參加人數計算，在同一時間內，建模人員與專案人員的比例也在 1：50 左右，可以說還是非常少的。在這種情況下，如果建模完成後，沒有建模人員到專案中去以模型溝通需求、以模型宣講企業級理念，指望模型自己說話是不大可能的。

現實情況中更可能的是，做為需求提出方的業務部門和做為實施方的專案團隊坐到一起，在雙方對模型理解不一致或者對模型中有些地方解釋不清時，如果得不到業務架構團隊或者建模團隊的及時支援，自然會傾向於雙方直接協商需求，而這時的溝通結果很可能與最初的建模會有差異，如果這種差異在多個專案組中形成、累積，勢必會造成業務模型的崩壞，最終結果可能使模型和企業級業務架構失效，而失效之後更麻煩的是，將沒有一個統一的檢視能夠對模型失效產生的“真空”進行有效填補，時間一長，就會形成架構的紊亂，“統一語言”可能會變成“統一誤解”。

跟上去，業務架構師

解決上述問題的辦法並不難，必須要求做建模的業務架構人員跟進各個專案組的概設過程或者敏捷過程，最好能實地跟進。專案啟動時，首先由業務架構人員就業務模型向參加專案的業務和技術人員統一解釋專案目標、架構方案、業務需求，由參加專案的業務和技術人員共同確認，因為這時參加專案的人員很可能並沒有參加過建模，對模型中的細節、建模中對原有業務基於標準化進行過的處理並不瞭解，需要業務架構人員再次統一思想。之後，再由業務人員和技術人員在模型框架下進行需求溝通和功能分解，遵守基於模型產生的專案邊界和分工。

如果要形成“統一語言”，業務模型必須對專案具有較強的指導性和約束力，但這也對負責建模的業務架構人員提出了較高要求，要對業務、模型、開發都具備足夠的瞭解，這樣的業務架構師必須長期培養才能產生，他們不同於產品經理和專案上的架構師，其對企業需求的巨集觀把握能力只有通過長期的積累才能達到。要求模型具有約束力並不是模型無論對錯都要遵守到底的意思，沒人會這麼“死心眼”地去做架構，因此，業務架構人員跟進專案的另一個目的就是判斷模型的適合性，在建模期間掌握的資訊很可能是不足的，而到了實施階段則會對細節有更多的討論，隨著資訊的增加，包括對客觀因素的考量，很可能會對原有模型進行適度調整，這時，業務架構人員必須切實履行其職能，承擔起架構職責，而非一味要求對模型的遵守。架構是有原則的，但架構也不能失去靈活。建立“統一語言”是為了提升效率，安排業務架構師，是為了讓“語言”被恰當使用，而不是造就新的“技術官僚”。因此，凡是要建立企業級業務架構工作團隊的，務必考慮清楚對其職責的定位和應當給予的信任與權力，同時，也應當堅持選用具有足夠能力的人員。如果不能確定企業會長期堅持這種策略，就不要建立這樣的固定組織，否則對從事該項工作的個人而言，會造成極大的機會成本。

此外，還有一點就是應當在整個企業內部不斷利用業務培訓的機會，用業務模型去解釋業務，使各個條線的員工都能對整體的企業架構有所瞭解，對模型化、結構化的思維方式有所瞭解。其實每個條線或者領域的業務本身都會經常製作流程圖，很多業務培訓也是用模型的方式在培訓，那麼在企業級專案建設的背景下，使用同一種建模方式對業務培訓課件和宣講方式進行統一，會對“統一語言”的建設有很大幫助。

業務架構師也要經常反思自己做過的設計，要“多吃自己的狗糧”；在有業務架構師團隊的情況下，經常開會討論設計得失，集體吃“狗糧”，對於提升業務架構整體和設計思維的一致性也非常有意義。

大家也可能對如此大費周章地建立業務模型、業務架構感到不解，我們不妨回想下業務架構最重要的作用：跨越“數字鴻溝”，尤其是幫助業務人員跨越。現在，科技與業務深度融合已經成為共識，但是融合首先是人與人之間的融合，這種融合非常依賴溝通方式和工具，在科技唱主角的時代背景下，如果業務人員與業務人員、業務人員與技術人員、技術人員與技術人員這三個層次之間的溝通都能具備更高的效率，那會為企業減少多少溝通成本、帶來多大競爭優勢！所以，在“統一語言”上投注多大的力量都不為過，而基於模型的溝通，就是打造“統一語言”一種有效方法。

現在很多企業都想仿效阿里的中臺戰略，通過這種中臺方式支援業務的靈活變化，但是，大家是否深入思考過中臺的積累過程？是像童年的小豬儲蓄罐那樣，你丟個硬幣、我丟個硬幣這樣“攢”起來的嗎？中臺的沉降一定是個不斷標準化、不斷去偽存真的過程，反覆也是一定會有的，而基於能夠提供標準化判斷依據的工具進行持續的溝通，是設計過程匯中必不可少的。阿里多以 DDD 方法為基礎，而要想做更高一級的企業級規劃，則需要採用能夠從企業級視角著手分析的方法。並不是因為阿里的成功，那些看起來有點兒“老氣”的方法就落後了，工具總是“尺有所短寸有所長”，工具的威力，更多還是在使用者自身的運用能力和決心毅力。

作者介紹：付曉巖，原國有大行資深業務架構師，負責業務架構設計、專案管理，熱衷新技術探索與實踐，具有豐富的銀行業務經驗和企業級專案業務架構設計經驗，曾主導客戶關係、金融市場、同業、資管、養老金等多個領域核心系統的業務架構設計。公眾號：曉談巖說。