中臺之上（五）：業務架構和中臺的難點，都是需要反覆錘鍊出標準模型

摘要： 企業級業務模型的建設離不開標準化操作，因為做企業級模型要橫向對比分析企業所有業務領域，以期望在設計上實現“以更少支援更多”，這是很多企業搞企業級系統建設或者企業級轉型的目標，希望能夠同時實現系統實現的快速靈活和減少重複開發以降低成本這兩個目標。這個願望是非常美好的，也是很多企業級架構設計追求的...

企業級業務模型的建設離不開標準化操作，因為做企業級模型要橫向對比分析企業所有業務領域，以期望在設計上實現“以更少支援更多”，這是很多企業搞企業級系統建設或者企業級轉型的目標，希望能夠同時實現系統實現的快速靈活和減少重複開發以降低成本這兩個目標。這個願望是非常美好的，也是很多企業級架構設計追求的目標，關於對這一點的體會，留待以後再講，這節我們還是一起討論下為實現這一目標所需要進行的標準化工作。

基本的標準化方法

標準化最重要的是資料標準化，資料建模中已經提到了，企業級資料模型要保證資料實體和屬性的唯一性，這樣就不會由重複的概念產生，重複的概念會造成資料的“同義不同名”。影響資料的使用和統計結果，資料模型的唯一性從工具角度比較容易控制，通過對定義、取值的比較，能夠篩查出多數概念問題，但是依然有些定義問題不易發現，這就需要通過與流程模型的配合檢查了。

資料模型是標準化的基礎，我們先假定多數資料概念重複問題已經通過工具篩查解決，資料實體和屬性基本保持唯一，這時我們可以將資料與流程對應起來，對應的主要方式就是識別任務需要使用的資料實體，包括讀和寫兩類，上文說過，對元件的識別就是先通過資料聚類，進而到任務聚類實現的，任務聚類主要就是對寫操作的任務進行聚類，因為讀操作不會改變資料，可以由負責寫操作的元件提供讀取服務實現，所以，寫操作是聚類任務的基本原則，這樣是為了保持資料的一致性。

在對應過程中，經常會遇到多個不同的任務都可能要對同一個資料實體在不同時間進行寫操作的情況，比如，個人客戶初次到一個銀行存錢，申請銀行賬戶時，銀行要建立客戶的資訊，會包括姓名、證件型別、證件號碼等基本資訊，也會包括電話等聯絡資訊，或者郵寄地址等地址資訊，這時的整體業務場景是存款。而客戶過了一段時間再次來辦理業務時，聯絡資訊可能會有變化，這需要更新客戶資訊，但是此時的場景有可能發生變化，不再是來存款，可能是來購買實物黃金，從產品的角度，這就是兩個不同的業務領域了。

那麼，在進行企業級標準化以前，對客戶資訊的建立和修改完全有可能在存款和實物黃金的領域各有一套流程，可能是任務級別的重複，也能是在不同的任務中各自的內容有重複，實際上，以前做豎井式開發的時候，這是很常見的現象，每個業務系統都是獨立的、完整的，都各自有一套客戶資訊，不僅重複，最重要的是經常會不一致。

當我們通過企業級資料模型去除重複的資料概念之後，通過任務與實體之間的寫操作對應關係，會清晰地發現重複的操作。這時我們就需要做出建模的決策，是分開建模還是將所有對客戶資訊進行寫操作的部分集中到一起建模。在 FSDM 提供的資料模型上，參與人這個分類中可以容納與客戶資訊相關的所有資料，建模上可以把此類實體聚集在一個主題域下，比如叫做客戶主題域，那麼從企業級的角度也就可以將各業務領域中與之相關的任務或者涉及到該操作的任務中的客戶資訊部分全部抽離出來，集中到起來組成一個元件，而其他領域的任務經過調整後，不再包含此類內容，這就完成了一個標準化過程。

可能會遇到的問題

上述操作是相對較為簡單、清晰的標準化過程，還有些標準化過程要更難以判斷，這種情況通常出現在流程看似相近的業務領域，以及一個領域內部的多個產品之間，後者其實更難判斷，因為一個業務領域內部的流程本就相近，會很容易讓人產生“整合”的衝動，尤其是對於業務建模來講，因為業務建模畢竟是一種“紙上操作”，分、合都是很容易的，調整下結構而已，而整合對建模者來講又有很大吸引力。為了避免這種錯誤，需要從業務和資料兩方面下手，業務上自然是要重新審視、理清業務流程，搞清楚具體差異；而資料上要重新檢視資料實體劃分的顆粒度是否正確，是否包含的屬性太多而導致內聚性不夠。資料實體的顆粒度太小，會放大業務差異，而顆粒度太大，則會抹殺業務差異，二者都會導致不合理的標準化結果。

因此，流程模型與資料模型之間的配合檢查是一個反覆錘鍊的過程。儘管標準化問題很重要、很困難，不幸的是，並沒有什麼很好的方法能夠幫助大家快速解決問題，這就又回到了之前說的，模型質量嚴重依賴建模者的經驗，除了經驗之外，還要依靠高質量的建模輸入，既包括完善的業務資料，更需要有豐富經驗的業務人員，看資料是學不會業務的，尤其是業務中經常會有“活情況”。

業務人員與技術人員融合得越好，就越能產生高質量的模型和系統，這也難怪高盛、大摩這些金融機構中數字化轉型的堅定執行者，會引入佔員工比例 15%、甚至 20% 還多的技術人員，並直接派駐到業務部門與之共同工作。一般國外金融機構技術人員佔比不足 8%，國內通常為 4% 左右，近年才剛剛有所增加。

儘管標準化過程很痛苦、自身又似乎很不“標準”，但是因其對企業級系統的構建意義非凡，因此，所有做企業級轉型、希望建設企業級系統的企業和開發者，都必須認真對待這一過程，儘管這一過程未免有點“紙上談兵”，但它的優勢也在這裡，這一階段的任何調整都是代價極低的，而不合理的設計一旦傳導到開發上，就將產生較大的糾正成本。本人原來所在單位規模很大，業務龐雜，因此這一過程耗時兩年，其後仍在持續優化、完善。對於大型複雜系統而言，因其面對的問題域異常龐大，所以需要一套清晰的業務與 IT 的架構對映關係指導企業的持續建設，這就如同我們對地圖的需要一樣，只有踐行標準化才能提供一張準確的地圖。

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