之前介紹過，應用業務架構模型可以快速對新需求進行企業級分析，那就講一個實際發生過的例子供大家參考。
以前做企業級項目的時候，曾經接到一個緊急設計業務架構方案的通知。由於當時公司還處於企業級轉型項目的施工期間，所有業務需求都要經過業務架構分析，出具業務架構方案，再落實到具體項目組。鑑於當時有50多個項目組同時施工，這樣的企業級分析過程是非常必要的。
該需求是與某寶合作的實物貴金屬在線銷售業務，當時，另一家競爭對手與某互聯網巨頭剛剛合作了此類項目，受市場形勢所迫，必須快馬加鞭，緊急施工。所幸業務部門已經連夜寫出了業務需求，需求共計15頁，將近9000字，涉及11個大的需求項，要馬上根據業務需求文檔形成業務架構方案。
需求的主要內容包括：爲客戶建立虛擬賬戶，用於記錄客戶買賣交易、持倉等；支持使用某寶黃金髮送紅包（黃金份額）；紅包的賬務性處理、紅包資金的支付結算及劃轉；支持黃金實物兌換；支持黃金轉贈；銷售數據提取、報表統計、實物提取配送數據交互以及相應的核算規則等。
當時公司早已經完成了企業級的業務架構和業務模型建設，並使用模型驅動企業級開發近四年時間，工具使用已經沒有問題。公司的企業級業務模型包含上百個組件和數十個大型應用，其中，該需求所屬的業務領域自己包含十餘個應用，業務活動近三十個，任務超過一百多個，涉及多個核心組件及公共類支持組件，需求牽涉的只是其中一個應用。在有業務架構和業務模型的情況下，業務架構人員的工作就是識別新業務流程與原有業務流程的差異，以判斷涉及的模型範圍，包括識別出需要使用的活動、任務、涉及的組件，以及需要新增那些內容，新增的應該歸屬給哪個任務和組件，進而，應用架構人員會根據分析結果給項目組指派具體承接的需求。當然，這不是簡單的對號入座，架構設計最重要的就是理清結構和關係，要說清楚各部分的具體分工和協作，給出明確的設計理由，否則，項目組會質疑任務分工。
經過對文檔的仔細研讀，最終理出了“簽約”、“產品查詢”、“交易（含紅包）”、“對賬”、“結算費用”這幾個主要工作流程，涉及9個現有業務組件，現有業務模型基本支持該需求的實現，部分任務需增加業務規則。
業務架構關係圖如下：
大致流程和組件分工描述如下：
- 簽約。客戶向某寶提出建立購買我司貴金屬的合約申請，某寶將相關信息及客戶在某寶的PID（客戶在某寶的身份標識）傳給我司，由於一個客戶可能有多個PID，因此需要分別爲其建立賬戶，該過程的處理，由我司與某寶新增的渠道負責信息傳輸，客戶信息及客戶關係組件負責識別是否應爲我司新增客戶，記錄客戶在某寶的PID信息，並與我司客戶信息進行關聯；XX交易組件則負責爲每個PID建立單獨的交易合約和賬戶。考慮到未來可能與某寶有更多產品合作，因此，PID應該在客戶信息組件作爲企業級信息管理，方便各組件查詢並保持唯一性。
- 產品查詢。產品信息由產品目錄的統一管理平臺——產品研發組件負責提供；報價涉及7*24小時實時人民幣黃金報價，並允許在賬戶金報價、金交所報價、交易對手報價等各個報價來源之間切換，允許買入價、賣出價、中間價等多種形式報出，因此，由投X與XX交易組件支持的企業級定報價平臺負責。
- 交易。交易涉及貴金屬買賣和對紅包轉賬的支持，由XX資金交易組件負責賬戶金交易、貴金XX組件負責實物金交易、運營XX組件負責庫存和配送管理，覈算由財會組件完成，都有現有業務活動和任務可以支持。
- 對賬清算和手續費扣收。這兩項都由XX資金交易組件基於交易記錄發起，清算結果和扣收都是在某寶在我司的存款賬戶和內部賬戶之間轉賬完成，也有基礎的業務活動可以支持。
- 報表。報表由於都是基於該組件的交易記錄，因此可以由該組件負責提供支持。
上述方案從閱讀需求到設計，再到跟領導請示彙報，發出方案，總共花了四個多小時。因爲會議緊急，所以方案出的也比較簡要，只搞了一頁PPT，其實，這樣也不錯，如果一頁PPT能說清楚問題，幹嘛非得搞上一大堆文稿呢？這方面敏捷宣言非常值得讚賞。
這個方案的製作過程體現了以下幾點：
- 對原有業務架構和模型的充分複用。方案最終只是在原有的業務模型中增加了部分步驟和規則，就一個抽象業務模型而言，不需要再增加活動、任務這些較大的元素了。
- 模型化的業務架構工具對企業級需求分析的加速作用。該方案涉及的客戶信息管理、交易、覈算、運營配送等，都是由不同業務條線負責管理的，是典型的企業級方案，由於有模型化的架構分析工具，就能夠快速識別需求的歸屬，併爲跨條線的協調提供客觀依據。
- 業務架構師必須經常熟悉項目情況。該方案能夠快速形成也得益於剛剛完成的產品設計重檢工作，設計者對模型與實施之間的實際映射情況非常瞭解，方案設計乃至後續項目組對分工的接受都很順利。由於分工的原因，企業級業務架構師可能會與項目之間有一定的“距離”，因此務必時刻注意補充自身對項目的瞭解，防止“距離”變成“疏離”。
由於之前業務上已經準備了較爲詳細的需求文檔，因此業務架構設計工作少去了一些瞭解過程，但是，從上面的例子可以看出，如果業務架構人員從需求梳理就開始介入，也可能會進一步提高需求分析的效率，推動一種基於業務模型的敏捷過程。所以，一開始建立企業級業務模型一定會是一個漫長的過程，因爲要處理大量的標準化整合，也會觸動一些深刻的利益關係，一旦完成了這個過程，建立了企業級業務架構，就可以向敏捷過程看齊，這種有企業級參照的敏捷過程，好於沒有“籬笆”的快速開發，有清晰的邊界總是開發人員願意看到的。看似“笨重”的業務模型方法，其實提供了一個“紮實”的下盤，如同練武術一樣，沒有紮實的馬步，怎麼能夠“飛檐走壁”呢？
中臺和組件化一樣，都是通向快速響應的方式，單就快速響應而言不能簡單比較孰優孰劣，基於企業級業務架構的組件化設計，其實優勢還是在於有效連接戰略與開發，實現上下貫通的一體化設計，這方面不是單純追求中臺的技術實現可以獲得的。
相關文章：
中臺之上（一）：重視業務架構，不要讓“業務的歸業務、技術的歸技術”
中臺之上（二）：爲什麼業務架構存在 20 多年，技術人員還覺得它有點虛？
中臺之上（三）：戰略和組織結構，業務架構設計中不應被忽視的關鍵因素
中臺之上（四）：面對複雜的流程和數據，我們總結出了一個分析套路
中臺之上（五）：業務架構和中臺的難點，都是需要反覆錘鍊出標準模型
中臺之上（六）：如何爲一個商業銀行設計業務架構？
中臺之上（七）：不神祕但很麻煩的業務架構落地過程
中臺之上（八）：企業級業務架構的實現需要不斷溝通和調整
中臺之上（九）：如何基於企業級業務架構管理業務需求？
中臺之上（十）：業務架構設計“笨重”，它能跟敏捷沾邊嗎？
中臺之上（十一）：企業級業務架構設計的“五難”
作者介紹：付曉巖，原國有大行資深業務架構師，負責業務架構設計、項目管理，熱衷新技術探索與實踐，具有豐富的銀行業務經驗和企業級項目業務架構設計經驗，曾主導客戶關係、金融市場、同業、資管、養老金等多個領域核心系統的業務架構設計。公衆號：曉談巖說。