? 　世事唯有變化不變，架構亦如此。企業(yè)架構因其龐大的體量，必然蘊含眾多引致其變化的因素，即便是一個被仔細切分過的服務也很難保證自己不會變化，何況包羅萬象的架構。架構設計并不是為了一味的追求穩(wěn)定，甚至不是為了單純以復用為目標，架構首要任務是澄清事物的內部結構，這即是為了更好地再現事物(從業(yè)務需求到技術實現，本身就是一個再現的過程)，也是為了通過一個清晰的結構接納變化。架構的關鍵職能之一就是如何更好地接納變化，對變化的范圍和影響作出盡可能清晰的判斷，而這個判斷除了架構師的能力外，還可以依靠良好的架構資產，良好的架構資產是提高架構師團隊平均水平和復雜工程管理效能的有效方式。企業(yè)架構的設計本身需要消耗較大的資源，而破壞卻很容易，通過一個一個需求對整體架構的些小違犯，就會積累出大量的偏離。架構資產相當于企業(yè)的能力地圖，如下圖所示：

　　圖1 基于企業(yè)級業(yè)務架構的企業(yè)能力地圖作戰(zhàn)需要軍事地圖，旅游需要旅游地圖，做企業(yè)架構、企業(yè)轉型自然也需要企業(yè)能力地圖，有了地圖才好走路。企業(yè)能力地圖可以標識企業(yè)從戰(zhàn)略到業(yè)務流程到IT實現的完整路徑，但是地圖的準確性是需要不斷維持的，需求總在路上，系統一直在變化，地圖自然需要更新，而更新最好的方式莫過于使用，堅持用企業(yè)級業(yè)務架構方法分解新需求，從而保持對地圖的更新。關于企業(yè)級業(yè)務架構的詳細構建方法，請參看筆者《企業(yè)級業(yè)務架構設計：方法論與實踐》一書，本文集中討論基于企業(yè)級業(yè)務架構已有的架構資產進行需求管理。

　　一、需求分析

　　需求管理是一個過程，在討論管理之前，還是先討論下如何應用架構資產進行分析，討論過用法再討論管理問題。既然本文已經假設了具備架構資產，那么就先虛擬一個業(yè)務范圍不是很完整的銀行業(yè)務架構，并集中在對業(yè)務組件的展示上，不再花費過多筆墨從價值鏈一路討論到業(yè)務組件了。我們假定一個具有存款、貸款、理財、貿易融資等幾項業(yè)務的銀行，其主要業(yè)務組件可能如下圖所示：

　　圖2 基于企業(yè)級業(yè)務架構的企業(yè)能力地圖在這個不完整的銀行中，假定暫有9個組件，4個位于領域層，分別負責存款、貸款、理財、貿易融資方面的業(yè)務處理;5個位于公共層，分別負責統一的客戶信息管理、統一的客戶關系管理(一般包括客戶政策、客戶分配、集團客戶關系維護等)、匯總分類賬進而產生總賬的財務會計、統一的風險管理和報表管理等職責。其實一提公共層，很多讀者可能就會發(fā)現，這個架構是不是也有些“中臺”的味道。

　　請注意，這里是業(yè)務組件，不是邏輯子系統，提到業(yè)務架構，也不要輕易把目前很多技術方案中畫了幾個功能模塊的“業(yè)務架構”與通過完整的企業(yè)級業(yè)務架構方法得出的業(yè)務組件等同。熟悉筆者之前方法論介紹的讀者會知道，每個組件中聚類的是關系相近的數據以及和這些數據關系相近的行為，是經過充分的分析和企業(yè)級標準化處理之后的結果，而非在預先指定了系統邊界后切出來的內部功能模塊。

　　有了架構(當然線條很粗)就可以應用架構資產進行需求分析，我們可以用下區(qū)塊鏈的例子，區(qū)塊鏈在金融領域的應用還是比較廣泛的，我們可以虛擬討論下，如果業(yè)務部門或者技術團隊提出要用區(qū)塊鏈技術構建新的貿易融資平臺，那么業(yè)務架構會怎么看這個問題?

　　首先，業(yè)務架構是從業(yè)務角度出發(fā)看問題，而不會直接受技術實現方式的干擾。那么，區(qū)塊鏈的貿易融資平臺就要先分析業(yè)務流程有哪些變化。國內區(qū)塊鏈一般是聯盟鏈的方式，多數平臺對成員資質都有認證，既有發(fā)行機構CA證書的，也有采用國家CA證書的，無論用那種方式，成員管理都是其必要流程之一。

　　客戶信息的建立與維護自不必說，這個流程必然有，而且總體來講，因為貿易融資的業(yè)務要求現階段并不會因為區(qū)塊鏈改變，所以客戶信息管理流程也不會有什么變化。同樣不變的還有業(yè)務處理流程，比如信用證的處理過程，區(qū)塊鏈平臺一般是提供了業(yè)務資料的可信傳輸，利用了區(qū)塊鏈的防篡改屬性進行信息加固。采用區(qū)塊鏈平臺之后也許自動化處理能力可以適度提升，但自動化處理嚴格來說并沒有徹底改變操作環(huán)節(jié)，而是操作者從人變成了計算機，如果業(yè)務建模具備適當的抽象度的話，那么，自動化處理對業(yè)務模型的改變并不是十分明顯，RPA理論上也是如此。

?????? 如果上述分析成立的話，那么，主要的流程變化其實在聯盟管理上，也就是成員的資質認證，這部分可以歸屬于客戶關系管理組件，在數據上可以表現為客戶間的聯盟關系、聯盟角色等，相應的業(yè)務處理過程，也就是新增的任務，可以放在客戶關系管理組件中。那么區(qū)塊鏈在哪里呢?業(yè)務架構上其實看不到的，業(yè)務架構主要看業(yè)務是否變化了，而區(qū)塊鏈賬本這些東西屬于技術實現上的選擇，也就是說，技術架構上會增加區(qū)塊鏈平臺，應用架構上會增加在區(qū)塊鏈平臺上部署的服務，而這些服務對應的是上述提到的業(yè)務功能。相當于在業(yè)務架構梳理清楚后，應用架構根據技術架構的變動改變了服務的位置。

　　那么區(qū)塊鏈不在業(yè)務架構上體現，怎么看得到業(yè)務與技術的融合呢?如果想讓業(yè)務側真的感受到變化，那一定是區(qū)塊鏈改變了業(yè)務形態(tài)。比如需要新增加的聯盟管理，這個業(yè)務有充分的感知，但是其他流程的變化是否會有如此明顯，考驗的就是業(yè)務和技術雙方結合運用區(qū)塊鏈改善現有業(yè)務形態(tài)的能力了，而新技術的應用最終是簡化了流程和架構，還是導致了更復雜的處理，也可以通過對比得出。對其他新技術的應用也是如此。通過這個虛擬的分析過程，讀者可以感受到業(yè)務架構是如何分析需求、如何處理新技術的，而新技術如何應用才可能為業(yè)務帶來改善。本文因篇幅和信息的限制，不再展開詳細的建模過程。

　　二、需求管理

　　談到管理就是組織和流程的問題了。首先，企業(yè)是否有專門的業(yè)務架構師團隊或者崗位，如果有的話，當然應該由業(yè)務架構師們牽頭建立企業(yè)的架構資產，然后依托架構資產進行業(yè)務需求的架構層級設計，負責識別需求相關的業(yè)務流程、數據實體、業(yè)務組件等架構元素，給出業(yè)務架構解決方案，再通過項目管理機制轉化為項目任務執(zhí)行，理想的工作方式是筆者之前一直主張的業(yè)務架構師派駐到業(yè)務部門中進行需求管理的方式，示意圖如下：

　　圖3 基于企業(yè)級業(yè)務架構的企業(yè)能力地圖在這個流程中，從組件到企業(yè)架構這部分是負責解決項目團隊間的架構分歧的，由統一的企業(yè)架構管理團隊負責最終決定。架構資產的變動最好由業(yè)務架構師統一維護，如果建模層次較深，細節(jié)較多，也可以采取分層級維護的方式，顆粒度最細一級的由組件項目團隊中的需分或產品人員負責。業(yè)務架構團隊也必須定期進行架構資產的質量檢查，以確保資產更新的及時性和準確性，可以將這部分列為對項目團隊的考核依據。

?????? 通過需求分析那部分的介紹，讀者也可以理解為什么業(yè)務架構師派駐在業(yè)務部門更合適，這樣可以離前端更近，有更好的業(yè)務感覺，第一時間了解業(yè)務人員需要什么、困惑什么，幫助業(yè)務人員了解新技術的應用。業(yè)務架構師每工作一段時間后應該在部門間進行輪換，以保持其企業(yè)級視角，并推動部門間的協作。那么對于沒有業(yè)務架構師團隊或者崗位的企業(yè)，這樣的企業(yè)一般也沒有業(yè)務架構方面的架構資產，相當于要從頭建立上述管理體制。培養(yǎng)業(yè)務架構師對企業(yè)進化、數字化轉型等工作而言非常必要，通過業(yè)務架構將業(yè)務和技術銜接起來，是實現業(yè)務與技術深度融合的起步性工作。培養(yǎng)多少業(yè)務架構師則要看企業(yè)的規(guī)模，人少的企業(yè)，除了少數專職的架構師外，也可以考慮在業(yè)務部門、項目團隊中建立適當數量的兼職業(yè)務架構師。

　　三、提升開發(fā)效能

　　軟件工程發(fā)展至今接近50年了，企業(yè)架構的歷程也有30多年，技術側作為技術服務供給方一直在持續(xù)提升自己的開發(fā)效能，軟件開發(fā)和設計工藝取得了長足的進步，但是，隨著社會逐步開始向數字化轉型，軟件需求的規(guī)模只會越來越大，甚至出現爆炸性增長。據Gartner最新預測，未來五年新構建的應用數量可達5億之多，超過之前40年的總和，盡管很難考證這一數據，但數字化社會最主要的生產工具莫過于軟件，數字化銀行的愿景如筆者在新書《銀行數字化轉型》中所描述，軟件覆蓋一切，這就意味著更大規(guī)模的軟件生產還在等待著技術人員，如何提升開發(fā)效能是重中之重。

　　已有的工程和架構理論基本上都是站在技術側看待這個問題，而很少從業(yè)務側看待如何提升開發(fā)效能。數字化轉型是整個社會的轉型，是一個新的時代，新的時代必然要求從業(yè)者的技能發(fā)生很大變化，從農業(yè)的農耕技能到工業(yè)的機器操控技能到信息時代的軟件應用技能，那么數字化時代，所有從業(yè)者必須具備的就是軟件構建技能，當然，這不意味著必須懂編程級的實現，而是懂得如何構筑“樂高”式軟件，來實現業(yè)務與技術的高效銜接。

　　“樂高”式軟件的探討已有多年，但是遲遲未見良好的實現，低代碼平臺也是這方面的探索者?！皹犯摺笔杰浖恢北容^難于構建的關鍵原因很可能是技術人員一直無法真正把握業(yè)務人員心目中的“樂高”式業(yè)務該是什么樣，坦白的講，我覺得業(yè)務人員也不是很清楚可以靈活、快速地組裝的業(yè)務流程到底是什么樣。業(yè)務人員盡管會在ISO9000、六西格瑪等標準化管理過程中進行流程的標準化，但是很少有與技術人員嘗試共同用結構化的思維一起理解所謂靈活的流程到底是什么，更少有將這種嘗試上升到企業(yè)級層面。

　　如果讀者認可數字化時代的核心生產工具是軟件，核心生產方式也是通過軟件送達服務，那么，業(yè)務人員提升思維結構化水平就是必須要考慮的事情，不然，“樂高”式軟件很難真正實現，軟件開發(fā)效能也很難獲得根本性提升。這個道理可以用經濟學中供求曲線的關系來類比，如下圖所示：

　　圖4 軟件開發(fā)效能中的供求曲線經濟需中用SS’代表供給曲線，DD’代表需求曲線，該理論的大意是供給曲線和需求曲線的交匯點就是價格與數量的平衡點，供求總體平衡，形成均衡價格E，也代表均衡水平。該理論的一個核心點是，單靠供給或需求曲線一方的移動，均衡水平很難獲得良好的提升，兩條曲線同時移動才能獲得均衡水平的較大提升。類比中，我們可以將橫軸的數量替換成軟件的產量，而縱軸調整為軟件的質量，將曲線定義為供給能力曲線和需求能力曲線，二者的交匯點，我們可以視為效能在產量和質量上的平衡點。

　　沿用供求理論，我們將供給能力曲線S1S1’向S2S2’的移動視為工程方法的提升，也就是以技術側為主的努力，那么在需求能力曲線沒有上升的情況下，單純的技術改善并不能很好地解決效能問題，甚至可能造成質量下降，這也許與多數技術人員的直觀感覺不同，但是從現在軟件重構勢頭穩(wěn)增不減的趨勢看，如果我們把“技術債務”也視為一項遠期質量問題，可能會更容易理解這個觀點。

　　如果需求能力曲線同步從D1D1’向D2D2’移動，即需求能力曲線也上升，那么，均衡點E3相比E2和E1，都會是一個很大的提高。從E2到E3這部分，我們可以視為業(yè)務思維的提升。

　　上述類比盡管不是很精確，但是相信讀者能夠理解在數字化轉型過程中，我們強調業(yè)務和技術融合時該做的一件事是什么，那就是“刷新”業(yè)務側的思維模式，從而在整體上提升軟件開發(fā)效能。如果數字化不是一個新時代，軟件不是這個新時代最主要的生產工具，我們大可不必如此。但如果是，我們這幾年一直在討論的數字化員工的基本技能中，就必須要有結構化思維能力這非常重要的一項，而在這一能力的形成過程中，業(yè)務架構方法起到的推動作用不可忽視，它將逐漸成為一項基本能力訓練。

　　軟件開發(fā)效能提升任重道遠，架構之路也很漫長，業(yè)務架構更像一團“前浪”般的星星之火，但是，未來的“后浪”們可能越來越需要這團星星之火。

?????? 以上文章來源于技術瑣話 ，作者付曉巖 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?