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

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

　　一、需求分析

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

　　圖2 基于企業(yè)級(jí)業(yè)務(wù)架構(gòu)的企業(yè)能力地圖在這個(gè)不完整的銀行中，假定暫有9個(gè)組件，4個(gè)位于領(lǐng)域?qū)?，分別負(fù)責(zé)存款、貸款、理財(cái)、貿(mào)易融資方面的業(yè)務(wù)處理;5個(gè)位于公共層，分別負(fù)責(zé)統(tǒng)一的客戶信息管理、統(tǒng)一的客戶關(guān)系管理(一般包括客戶政策、客戶分配、集團(tuán)客戶關(guān)系維護(hù)等)、匯總分類賬進(jìn)而產(chǎn)生總賬的財(cái)務(wù)會(huì)計(jì)、統(tǒng)一的風(fēng)險(xiǎn)管理和報(bào)表管理等職責(zé)。其實(shí)一提公共層，很多讀者可能就會(huì)發(fā)現(xiàn)，這個(gè)架構(gòu)是不是也有些“中臺(tái)”的味道。

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

　　有了架構(gòu)(當(dāng)然線條很粗)就可以應(yīng)用架構(gòu)資產(chǎn)進(jìn)行需求分析，我們可以用下區(qū)塊鏈的例子，區(qū)塊鏈在金融領(lǐng)域的應(yīng)用還是比較廣泛的，我們可以虛擬討論下，如果業(yè)務(wù)部門或者技術(shù)團(tuán)隊(duì)提出要用區(qū)塊鏈技術(shù)構(gòu)建新的貿(mào)易融資平臺(tái)，那么業(yè)務(wù)架構(gòu)會(huì)怎么看這個(gè)問(wèn)題?

　　首先，業(yè)務(wù)架構(gòu)是從業(yè)務(wù)角度出發(fā)看問(wèn)題，而不會(huì)直接受技術(shù)實(shí)現(xiàn)方式的干擾。那么，區(qū)塊鏈的貿(mào)易融資平臺(tái)就要先分析業(yè)務(wù)流程有哪些變化。國(guó)內(nèi)區(qū)塊鏈一般是聯(lián)盟鏈的方式，多數(shù)平臺(tái)對(duì)成員資質(zhì)都有認(rèn)證，既有發(fā)行機(jī)構(gòu)CA證書的，也有采用國(guó)家CA證書的，無(wú)論用那種方式，成員管理都是其必要流程之一。

　　客戶信息的建立與維護(hù)自不必說(shuō)，這個(gè)流程必然有，而且總體來(lái)講，因?yàn)橘Q(mào)易融資的業(yè)務(wù)要求現(xiàn)階段并不會(huì)因?yàn)閰^(qū)塊鏈改變，所以客戶信息管理流程也不會(huì)有什么變化。同樣不變的還有業(yè)務(wù)處理流程，比如信用證的處理過(guò)程，區(qū)塊鏈平臺(tái)一般是提供了業(yè)務(wù)資料的可信傳輸，利用了區(qū)塊鏈的防篡改屬性進(jìn)行信息加固。采用區(qū)塊鏈平臺(tái)之后也許自動(dòng)化處理能力可以適度提升，但自動(dòng)化處理嚴(yán)格來(lái)說(shuō)并沒(méi)有徹底改變操作環(huán)節(jié)，而是操作者從人變成了計(jì)算機(jī)，如果業(yè)務(wù)建模具備適當(dāng)?shù)某橄蠖鹊脑?，那么，自?dòng)化處理對(duì)業(yè)務(wù)模型的改變并不是十分明顯，RPA理論上也是如此。

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

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

　　二、需求管理

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

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

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

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

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

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

　　“樂(lè)高”式軟件的探討已有多年，但是遲遲未見(jiàn)良好的實(shí)現(xiàn)，低代碼平臺(tái)也是這方面的探索者?！皹?lè)高”式軟件一直比較難于構(gòu)建的關(guān)鍵原因很可能是技術(shù)人員一直無(wú)法真正把握業(yè)務(wù)人員心目中的“樂(lè)高”式業(yè)務(wù)該是什么樣，坦白的講，我覺(jué)得業(yè)務(wù)人員也不是很清楚可以靈活、快速地組裝的業(yè)務(wù)流程到底是什么樣。業(yè)務(wù)人員盡管會(huì)在ISO9000、六西格瑪?shù)葮?biāo)準(zhǔn)化管理過(guò)程中進(jìn)行流程的標(biāo)準(zhǔn)化，但是很少有與技術(shù)人員嘗試共同用結(jié)構(gòu)化的思維一起理解所謂靈活的流程到底是什么，更少有將這種嘗試上升到企業(yè)級(jí)層面。

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

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

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

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

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

　　軟件開(kāi)發(fā)效能提升任重道遠(yuǎn)，架構(gòu)之路也很漫長(zhǎng)，業(yè)務(wù)架構(gòu)更像一團(tuán)“前浪”般的星星之火，但是，未來(lái)的“后浪”們可能越來(lái)越需要這團(tuán)星星之火。

?????? 以上文章來(lái)源于技術(shù)瑣話 ，作者付曉巖 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?