世事唯有變化不變，架構亦如此。企業架構因其龐大的體量，必然蘊含衆多引致其變化的因素，即便是一個被仔細切分過的服務也很難保證自己不會變化，何況包羅萬象的架構。架構設計並不是爲了一味的追求穩定，甚至不是爲了單純以複用爲目標，架構首要任務是澄清事物的內部結構，這即是爲了更好地再現事物（從業務需求到技術實現，本身就是一個再現的過程），也是爲了通過一個清晰的結構接納變化。架構的關鍵職能之一就是如何更好地接納變化，對變化的範圍和影響作出儘可能清晰的判斷，而這個判斷除了架構師的能力外，還可以依靠良好的架構資產，良好的架構資產是提高架構師團隊平均水平和複雜工程管理效能的有效方式。
企業架構的設計本身需要消耗較大的資源，而破壞卻很容易，通過一個一個需求對整體架構的些小違犯，就會積累出大量的偏離。架構資產相當於企業的能力地圖，如下圖所示：
圖1 基於企業級業務架構的企業能力地圖
作戰需要軍事地圖，旅遊需要旅遊地圖，做企業架構、企業轉型自然也需要企業能力地圖，有了地圖纔好走路。企業能力地圖可以標識企業從戰略到業務流程到IT實現的完整路徑，但是地圖的準確性是需要不斷維持的，需求總在路上，系統一直在變化，地圖自然需要更新，而更新最好的方式莫過於使用，堅持用企業級業務架構方法分解新需求，從而保持對地圖的更新。關於企業級業務架構的詳細構建方法，請參看筆者《企業級業務架構設計：方法論與實踐》一書，本文集中討論基於企業級業務架構已有的架構資產進行需求管理。
一、需求分析
需求管理是一個過程，在討論管理之前，還是先討論下如何應用架構資產進行分析，討論過用法再討論管理問題。
既然本文已經假設了具備架構資產，那麼就先虛擬一個業務範圍不是很完整的銀行業務架構，並集中在對業務組件的展示上，不再花費過多筆墨從價值鏈一路討論到業務組件了。我們假定一個具有存款、貸款、理財、貿易融資等幾項業務的銀行，其主要業務組件可能如下圖所示：
圖2 基於企業級業務架構的企業能力地圖
在這個不完整的銀行中，假定暫有9個組件，4個位於領域層，分別負責存款、貸款、理財、貿易融資方面的業務處理；5個位於公共層，分別負責統一的客戶信息管理、統一的客戶關係管理（一般包括客戶政策、客戶分配、集團客戶關係維護等）、彙總分類賬進而產生總賬的財務會計、統一的風險管理和報表管理等職責。其實一提公共層，很多讀者可能就會發現，這個架構是不是也有些“中臺”的味道。
請注意，這裏是業務組件，不是邏輯子系統，提到業務架構，也不要輕易把目前很多技術方案中畫了幾個功能模塊的“業務架構”與通過完整的企業級業務架構方法得出的業務組件等同。熟悉筆者之前方法論介紹的讀者會知道，每個組件中聚類的是關係相近的數據以及和這些數據關係相近的行爲，是經過充分的分析和企業級標準化處理之後的結果，而非在預先指定了系統邊界後切出來的內部功能模塊。
有了架構（當然線條很粗）就可以應用架構資產進行需求分析，我們可以用下區塊鏈的例子，區塊鏈在金融領域的應用還是比較廣泛的，我們可以虛擬討論下，如果業務部門或者技術團隊提出要用區塊鏈技術構建新的貿易融資平臺，那麼業務架構會怎麼看這個問題？
首先，業務架構是從業務角度出發看問題，而不會直接受技術實現方式的干擾。那麼，區塊鏈的貿易融資平臺就要先分析業務流程有哪些變化。國內區塊鏈一般是聯盟鏈的方式，多數平臺對成員資質都有認證，既有發行機構CA證書的，也有采用國家CA證書的，無論用那種方式，成員管理都是其必要流程之一。
客戶信息的建立與維護自不必說，這個流程必然有，而且總體來講，因爲貿易融資的業務要求現階段並不會因爲區塊鏈改變，所以客戶信息管理流程也不會有什麼變化。同樣不變的還有業務處理流程，比如信用證的處理過程，區塊鏈平臺一般是提供了業務資料的可信傳輸，利用了區塊鏈的防篡改屬性進行信息加固。採用區塊鏈平臺之後也許自動化處理能力可以適度提升，但自動化處理嚴格來說並沒有徹底改變操作環節，而是操作者從人變成了計算機，如果業務建模具備適當的抽象度的話，那麼，自動化處理對業務模型的改變並不是十分明顯，RPA理論上也是如此。
如果上述分析成立的話，那麼，主要的流程變化其實在聯盟管理上，也就是成員的資質認證，這部分可以歸屬於客戶關係管理組件，在數據上可以表現爲客戶間的聯盟關係、聯盟角色等，相應的業務處理過程，也就是新增的任務，可以放在客戶關係管理組件中。
那麼區塊鏈在哪裏呢？業務架構上其實看不到的，業務架構主要看業務是否變化了，而區塊鏈賬本這些東西屬於技術實現上的選擇，也就是說，技術架構上會增加區塊鏈平臺，應用架構上會增加在區塊鏈平臺上部署的服務，而這些服務對應的是上述提到的業務功能。相當於在業務架構梳理清楚後，應用架構根據技術架構的變動改變了服務的位置。
那麼區塊鏈不在業務架構上體現，怎麼看得到業務與技術的融合呢？如果想讓業務側真的感受到變化，那一定是區塊鏈改變了業務形態。比如需要新增加的聯盟管理，這個業務有充分的感知，但是其他流程的變化是否會有如此明顯，考驗的就是業務和技術雙方結合運用區塊鏈改善現有業務形態的能力了，而新技術的應用最終是簡化了流程和架構，還是導致了更復雜的處理，也可以通過對比得出。對其他新技術的應用也是如此。
通過這個虛擬的分析過程，讀者可以感受到業務架構是如何分析需求、如何處理新技術的，而新技術如何應用纔可能爲業務帶來改善。本文因篇幅和信息的限制，不再展開詳細的建模過程。
二、需求管理
談到管理就是組織和流程的問題了。首先，企業是否有專門的業務架構師團隊或者崗位，如果有的話，當然應該由業務架構師們牽頭建立企業的架構資產，然後依託架構資產進行業務需求的架構層級設計，負責識別需求相關的業務流程、數據實體、業務組件等架構元素，給出業務架構解決方案，再通過項目管理機制轉化爲項目任務執行，理想的工作方式是筆者之前一直主張的業務架構師派駐到業務部門中進行需求管理的方式，示意圖如下：
圖3 基於企業級業務架構的企業能力地圖
在這個流程中，從組件到企業架構這部分是負責解決項目團隊間的架構分歧的，由統一的企業架構管理團隊負責最終決定。
架構資產的變動最好由業務架構師統一維護，如果建模層次較深，細節較多，也可以採取分層級維護的方式，顆粒度最細一級的由組件項目團隊中的需分或產品人員負責。業務架構團隊也必須定期進行架構資產的質量檢查，以確保資產更新的及時性和準確性，可以將這部分列爲對項目團隊的考覈依據。
通過需求分析那部分的介紹，讀者也可以理解爲什麼業務架構師派駐在業務部門更合適，這樣可以離前端更近，有更好的業務感覺，第一時間瞭解業務人員需要什麼、困惑什麼，幫助業務人員瞭解新技術的應用。業務架構師每工作一段時間後應該在部門間進行輪換，以保持其企業級視角，並推動部門間的協作。
那麼對於沒有業務架構師團隊或者崗位的企業，這樣的企業一般也沒有業務架構方面的架構資產，相當於要從頭建立上述管理體制。培養業務架構師對企業進化、數字化轉型等工作而言非常必要，通過業務架構將業務和技術銜接起來，是實現業務與技術深度融合的起步性工作。培養多少業務架構師則要看企業的規模，人少的企業，除了少數專職的架構師外，也可以考慮在業務部門、項目團隊中建立適當數量的兼職業務架構師。
三、提升開發效能
軟件工程發展至今接近50年了，企業架構的歷程也有30多年，技術側作爲技術服務供給方一直在持續提升自己的開發效能，軟件開發和設計工藝取得了長足的進步，但是，隨着社會逐步開始向數字化轉型，軟件需求的規模只會越來越大，甚至出現爆炸性增長。據Gartner最新預測，未來五年新構建的應用數量可達5億之多，超過之前40年的總和，儘管很難考證這一數據，但數字化社會最主要的生產工具莫過於軟件，數字化銀行的願景如筆者在新書《銀行數字化轉型》中所描述，軟件覆蓋一切，這就意味着更大規模的軟件生產還在等待着技術人員，如何提升開發效能是重中之重。
已有的工程和架構理論基本上都是站在技術側看待這個問題，而很少從業務側看待如何提升開發效能。數字化轉型是整個社會的轉型，是一個新的時代，新的時代必然要求從業者的技能發生很大變化，從農業的農耕技能到工業的機器操控技能到信息時代的軟件應用技能，那麼數字化時代，所有從業者必須具備的就是軟件構建技能，當然，這不意味着必須懂編程級的實現，而是懂得如何構築“樂高”式軟件，來實現業務與技術的高效銜接。
“樂高”式軟件的探討已有多年，但是遲遲未見良好的實現，低代碼平臺也是這方面的探索者。“樂高”式軟件一直比較難於構建的關鍵原因很可能是技術人員一直無法真正把握業務人員心目中的“樂高”式業務該是什麼樣，坦白的講，我覺得業務人員也不是很清楚可以靈活、快速地組裝的業務流程到底是什麼樣。業務人員儘管會在ISO9000、六西格瑪等標準化管理過程中進行流程的標準化，但是很少有與技術人員嘗試共同用結構化的思維一起理解所謂靈活的流程到底是什麼，更少有將這種嘗試上升到企業級層面。
如果讀者認可數字化時代的核心生產工具是軟件，核心生產方式也是通過軟件送達服務，那麼，業務人員提升思維結構化水平就是必須要考慮的事情，不然，“樂高”式軟件很難真正實現，軟件開發效能也很難獲得根本性提升。這個道理可以用經濟學中供求曲線的關係來類比，如下圖所示：
圖4 軟件開發效能中的供求曲線
經濟需中用SS’代表供給曲線，DD’代表需求曲線，該理論的大意是供給曲線和需求曲線的交匯點就是價格與數量的平衡點，供求總體平衡，形成均衡價格E，也代表均衡水平。該理論的一個核心點是，單靠供給或需求曲線一方的移動，均衡水平很難獲得良好的提升，兩條曲線同時移動才能獲得均衡水平的較大提升。
類比中，我們可以將橫軸的數量替換成軟件的產量，而縱軸調整爲軟件的質量，將曲線定義爲供給能力曲線和需求能力曲線，二者的交匯點，我們可以視爲效能在產量和質量上的平衡點。
沿用供求理論，我們將供給能力曲線S1S1’向S2S2’的移動視爲工程方法的提升，也就是以技術側爲主的努力，那麼在需求能力曲線沒有上升的情況下，單純的技術改善並不能很好地解決效能問題，甚至可能造成質量下降，這也許與多數技術人員的直觀感覺不同，但是從現在軟件重構勢頭穩增不減的趨勢看，如果我們把“技術債務”也視爲一項遠期質量問題，可能會更容易理解這個觀點。
如果需求能力曲線同步從D1D1’向D2D2’移動，即需求能力曲線也上升，那麼，均衡點E3相比E2和E1，都會是一個很大的提高。從E2到E3這部分，我們可以視爲業務思維的提升。
上述類比儘管不是很精確，但是相信讀者能夠理解在數字化轉型過程中，我們強調業務和技術融合時該做的一件事是什麼，那就是“刷新”業務側的思維模式，從而在整體上提升軟件開發效能。如果數字化不是一個新時代，軟件不是這個新時代最主要的生產工具，我們大可不必如此。但如果是，我們這幾年一直在討論的數字化員工的基本技能中，就必須要有結構化思維能力這非常重要的一項，而在這一能力的形成過程中，業務架構方法起到的推動作用不可忽視，它將逐漸成爲一項基本能力訓練。
軟件開發效能提升任重道遠，架構之路也很漫長，業務架構更像一團“前浪”般的星星之火，但是，未來的“後浪”們可能越來越需要這團星星之火。