企業(yè)級(jí)業(yè)務(wù)架構(gòu)（EBA）方法源自Zachman框架和TOGAF理論。企業(yè)架構(gòu)總是給人一種龐大而笨重的印象，實(shí)踐往往也需要一定的時(shí)間周期，相信很多人都會(huì)懷疑這種連它自己都快不起來的實(shí)施模式會(huì)對(duì)提升企業(yè)級(jí)應(yīng)用系統(tǒng)軟件開發(fā)效能有什么幫助，本文筆者就試著討論下這個(gè)問題，同時(shí)，也跟各位讀者分析分析軟件工程發(fā)展至今仍有很大不足的一處“盲區(qū)”。

?

企業(yè)級(jí)系統(tǒng)軟件開發(fā)效能存在的一些瓶頸

?

1. 令人頭疼的源頭管理

?

軟件行業(yè)一直在致力于工程效率方面的持續(xù)改進(jìn)，從瀑布模型、螺旋模型到敏捷過程。對(duì)于效率而言，其實(shí)各種工程模式并沒有絕對(duì)的好壞，雖然對(duì)“古老”的瀑布模型的批評(píng)之聲始終不絕于耳，但是新冠抗疫期間，武漢二神山醫(yī)院的建設(shè)奇跡正是用瀑布模型完成的，從基建到設(shè)備到軟件僅用了28天，這都是在瀑布模型的規(guī)劃下完成的，所以，目標(biāo)和需求清晰的情況下，瀑布模型能創(chuàng)造敏捷過程也無(wú)法完成的奇跡。

?

此外，瀑布模型的一個(gè)好處是對(duì)軟件工程的主要環(huán)節(jié)說的一清二楚，自瀑布模型之后，無(wú)論工程模式如何改變，都沒能將瀑布模型中的這些環(huán)節(jié)真正省略掉，無(wú)非是實(shí)施順序、方式的變化。所以，本文還是借用瀑布模型的“清晰”來說說企業(yè)級(jí)系統(tǒng)軟件開發(fā)中存在的最大瓶頸——源頭管理。

?

?

從上面這張圖中，我們可以發(fā)現(xiàn)，軟件過程中越靠后，也就是越進(jìn)入純粹技術(shù)實(shí)現(xiàn)部分，比如編碼、測(cè)試、運(yùn)營(yíng)，工程效率改進(jìn)非常明顯，持續(xù)集成、持續(xù)發(fā)布、測(cè)試驅(qū)動(dòng)開發(fā)，以及各種軟件開發(fā)平臺(tái)，頭部企業(yè)已經(jīng)搞出了很多神兵利器。

?

但是，從這個(gè)部分再往前推的話，在需求分析、概設(shè)、詳設(shè)的效率方面，平臺(tái)和工具的支持能力就大大減弱了，因?yàn)檫@方面我們更需要的是一套清晰的架構(gòu)，要能更好的識(shí)別企業(yè)的業(yè)務(wù)資產(chǎn)和IT資產(chǎn)，設(shè)計(jì)能在架構(gòu)中找到有哪些東西，能復(fù)用哪些東西，才有可能把效率大幅度提升上來，不然的話就經(jīng)常會(huì)重復(fù)造輪子。

?

那么再往前到源頭，到需求提出這部分，其實(shí)已經(jīng)走出了軟件工程真正可控的范圍，因?yàn)檫@部分來自于業(yè)務(wù)，受技術(shù)實(shí)現(xiàn)能力的制約，但是不歸技術(shù)管制。在這4個(gè)環(huán)節(jié)上，我們通常采用評(píng)審機(jī)制進(jìn)行管理，可能互聯(lián)網(wǎng)公司的評(píng)審工作會(huì)略微優(yōu)化下，但總體而言，評(píng)審機(jī)制的工作效率并不是很高。

?

越靠前的環(huán)節(jié)對(duì)總體工程效率的影響實(shí)際上越大，如果是在源頭環(huán)節(jié)發(fā)生錯(cuò)誤的話，那整個(gè)開發(fā)過程就變成“試錯(cuò)”了，盡管目前工程方面有鼓勵(lì)試錯(cuò)的觀點(diǎn)和實(shí)踐，但是“縱容”試錯(cuò)也是有很多問題的，尤其是在傳統(tǒng)行業(yè)里邊，能避免要盡量避免，輕易地去“試錯(cuò)”會(huì)對(duì)軟件開發(fā)造成很大的資源浪費(fèi)，尤其是非常寶貴的時(shí)間資源。此外，對(duì)于一些“家業(yè)”沒那么大的企業(yè)來講，頻繁“試錯(cuò)”可能會(huì)把企業(yè)都搭進(jìn)去。

?

需求管理還是挺頭疼的一個(gè)事，經(jīng)常有產(chǎn)品經(jīng)理和技術(shù)人員互懟的這種段子。開發(fā)上常說需求來的太模糊，給你兩個(gè)圈就想要你畫出一匹馬。其實(shí)按照科學(xué)方法按部就班地慢慢來，確實(shí)也能畫出一匹馬，但是如果我們真的這么細(xì)致地搞需求，可能兩三個(gè)月就耗掉了，老板們就會(huì)抱怨，說是人家兩三個(gè)月系統(tǒng)系統(tǒng)都上線了，我們才搞出個(gè)需求，所以這種方法盡管很科學(xué)，但是現(xiàn)在大家普遍都不接受了。比較接受的是什么呢？這兩個(gè)圈有了之后，一頓頭腦風(fēng)暴，非驢非馬的形象先出一個(gè)，開始開發(fā)，再多輪迭代，直到搞出馬來。

?

即便開發(fā)端如此“折磨自己”，業(yè)務(wù)端可能還不滿意，要么不滿意速度，要么不滿意結(jié)果，總之，跟需求還是有“差距” 。領(lǐng)導(dǎo)可能會(huì)想，為啥別人家的娃干活又快又好，咱家的娃就不行？是不是咱家娃的姿勢(shì)不對(duì)？很自然的就把鍋背給了工程方法和工程團(tuán)隊(duì)。

?

其實(shí)工程這個(gè)問題IT行業(yè)已經(jīng)研究了很久了，瀑布模型誕生于上個(gè)世紀(jì)70年代，軟件工程已經(jīng)有50年歷史，研究也很系統(tǒng)，出版了很多經(jīng)典教材，像《軟件工程》這種教科書級(jí)別的著作。而且內(nèi)容并不深?yuàn)W，業(yè)務(wù)人員稍花心思也能看懂，但是幾乎很少有業(yè)務(wù)人員對(duì)這本書有興趣，也就是說沒有哪個(gè)人員對(duì)我們的開發(fā)過程真感興趣，沒有真正融入到開發(fā)過程中，所以他們也不太清楚在對(duì)于一個(gè)軟件開發(fā)來講，我們到底需要什么樣的需求，到底需求應(yīng)該怎么做合適。而有的時(shí)候技術(shù)人員也也愿意把工程這個(gè)東西封閉在自己的圈子里，“上帝的歸上帝，凱撒的歸凱撒”。

?

但是，如果把工程封閉在技術(shù)人員自己這個(gè)圈子里，對(duì)互聯(lián)網(wǎng)企業(yè)來講還好一點(diǎn)，開發(fā)人員通常在企業(yè)總?cè)藬?shù)中占比過半，技術(shù)氛圍濃厚。但是很多傳統(tǒng)行業(yè)的企業(yè)中，開發(fā)人員占比幾乎都是個(gè)位數(shù)，甚至是很低的個(gè)位數(shù)，這種情況下，如果業(yè)務(wù)人員對(duì)工程缺少足夠了解的話，那很自然的就會(huì)認(rèn)為提什么樣的需求都對(duì)，技術(shù)團(tuán)隊(duì)開發(fā)效能低的話，是你技術(shù)的問題，因?yàn)槟隳菈K我又不懂。

?

所以，在軟件工程的改進(jìn)中一直缺少一件事情，就是筆者在文章開頭說的那個(gè)“盲區(qū)”，沒把業(yè)務(wù)人員真正納入工程中，我們的工程理論過于封閉了，沒有在企業(yè)內(nèi)部更好地向業(yè)務(wù)宣傳。現(xiàn)在都講IT與業(yè)務(wù)之間的融合，融合應(yīng)該是雙向的，不僅是IT人員要去多了解業(yè)務(wù)，也要讓業(yè)務(wù)人員多了解軟件的開發(fā)過程，這對(duì)提升企業(yè)未來競(jìng)爭(zhēng)力而言將會(huì)是一件非常重要的基礎(chǔ)性工作。

?

2. 對(duì)企業(yè)戰(zhàn)略和管理的忽視

?

首先，很多人都對(duì)戰(zhàn)略有個(gè)“假大空”的壞印象，技術(shù)人員也不例外。企業(yè)搞衛(wèi)星、發(fā)宏愿跟我有什么關(guān)系？我只看需求，戰(zhàn)略說的再好，如果不能轉(zhuǎn)換成需求，那對(duì)技術(shù)而言有什么意義？因?yàn)槲乙膊恢滥阋鍪裁础＿@種想法盡管可以理解，但并不正確，因?yàn)閼?zhàn)略跟企業(yè)中的每一個(gè)人都相關(guān)，所以這作為企業(yè)的一員來講，IT人員也應(yīng)該關(guān)心企業(yè)要走到哪個(gè)方向，要去做什么。

?

其次，就是企業(yè)管理。企業(yè)管理確實(shí)是一個(gè)非常瑣碎的事，有太多的雜務(wù)，開發(fā)人員還是更原意待在一個(gè)跟業(yè)務(wù)有一定隔離的后端里邊，更愿意讓業(yè)務(wù)提出需求，自己來寫代碼。

?

但是，如果忽略了戰(zhàn)略和管理這兩個(gè)問題的話，那么就像Zachman框架提出的思想那樣，想在企業(yè)級(jí)系統(tǒng)軟件中把開發(fā)這件事情做好，你必須對(duì)企業(yè)整體有深入的了解。而忽視戰(zhàn)略和管理，則會(huì)影響到我們?cè)诩軜?gòu)設(shè)計(jì)上的一些決策。業(yè)務(wù)需求要跟企業(yè)發(fā)展方向吻合的，但是我們把這個(gè)責(zé)任只留給了業(yè)務(wù)，自己卻沒有關(guān)注。企業(yè)管理也是在處理各個(gè)業(yè)務(wù)模塊之間的關(guān)系，如果都是都交代給了業(yè)務(wù)人員去承擔(dān)，需求書上怎么寫我們就怎么做，那么這種情況下有些需求即便有問題，可能我們也看不出來，這些問題到后續(xù)的時(shí)候都會(huì)影響開發(fā)效能，包括一些返工，一邊趕工一邊還要返工。所以，現(xiàn)在主流思想已經(jīng)是提升IT與業(yè)務(wù)的融合深度了，就不要再把業(yè)務(wù)和技術(shù)這兩側(cè)截然的分開去看待。

?

EBA 方法的價(jià)值

?

1. EBA 的核心價(jià)值

?

?

上面這張圖是筆者在自己的《企業(yè)級(jí)業(yè)務(wù)架構(gòu)設(shè)計(jì)：方法論與實(shí)踐》一書中給出的業(yè)務(wù)架構(gòu)定義，是一個(gè)操作型定義，同時(shí)也闡明了EBA的價(jià)值。EBA就是為了落地企業(yè)戰(zhàn)略，對(duì)企業(yè)業(yè)務(wù)能力進(jìn)行整體規(guī)劃，再把這種規(guī)劃結(jié)果傳導(dǎo)給IT實(shí)現(xiàn)端的一種結(jié)構(gòu)化分析方法。從這個(gè)定義上大家能看出來EBA到底要做什么：把戰(zhàn)略落實(shí)到業(yè)務(wù)上，再通過業(yè)務(wù)的需求傳導(dǎo)給IT。

?

EBA也幫助業(yè)務(wù)進(jìn)行了戰(zhàn)略在業(yè)務(wù)側(cè)的落地。最近筆者看了一篇研究報(bào)告，提到了一個(gè)數(shù)字，雖然無(wú)從考證，但報(bào)告中說85%的國(guó)有企業(yè)沒能找到有效將戰(zhàn)略分解執(zhí)行的方法。EBA其實(shí)很適合做這件事情。另一方面，EBA也可以解決IT人員不關(guān)心戰(zhàn)略的問題，因?yàn)閼?zhàn)略到IT中間需要業(yè)務(wù)進(jìn)行傳導(dǎo)，否則IT人員很難理解戰(zhàn)略。

?

在EBA方法下，戰(zhàn)略不能僅停留在綱領(lǐng)性要求這個(gè)層面，而是要分解成更細(xì)的戰(zhàn)略能力能力。然后把現(xiàn)有的業(yè)務(wù)梳理成結(jié)構(gòu)化的現(xiàn)狀業(yè)務(wù)模型，把戰(zhàn)略能力需求跟模型之間進(jìn)行匹配后，會(huì)發(fā)現(xiàn)有哪些業(yè)務(wù)要調(diào)整或新增，進(jìn)而形成目標(biāo)模型。通過這個(gè)過程，實(shí)現(xiàn)戰(zhàn)略與業(yè)務(wù)的結(jié)合，結(jié)合在一起的戰(zhàn)略能力需求再傳導(dǎo)給IT人員的時(shí)候，我們就不會(huì)說這個(gè)東西是不明確的了。戰(zhàn)略、業(yè)務(wù)和IT之間一直缺少一個(gè)有效的銜接，只有通過業(yè)務(wù)架構(gòu)這個(gè)橋梁進(jìn)行連接，我們才能真正讓企業(yè)變成一個(gè)整體，這也是EBA的核心價(jià)值。

?

2. 與 TOGAF 相比的改進(jìn)之處

?

與TOGAF相比，筆者介紹的EBA方法更強(qiáng)調(diào)獨(dú)立使用時(shí)對(duì)業(yè)務(wù)人員的價(jià)值。TOGAF中，業(yè)務(wù)架構(gòu)仍是IT架構(gòu)的一個(gè)延伸，也就是說，做業(yè)務(wù)架構(gòu)目的是為了更好的去做IT設(shè)計(jì)，這對(duì)業(yè)務(wù)人員而言，貢獻(xiàn)就比較小了，本質(zhì)上還是IT的事，是業(yè)務(wù)在幫IT做事，業(yè)務(wù)人員應(yīng)用業(yè)務(wù)架構(gòu)的意愿和動(dòng)力相對(duì)就會(huì)差很多。但實(shí)際上，獨(dú)立應(yīng)用業(yè)務(wù)架構(gòu)方法去管理、理解業(yè)務(wù)過程對(duì)業(yè)務(wù)人員而言也很有意義。現(xiàn)在大家都在談數(shù)字化轉(zhuǎn)型，未來企業(yè)中的很多產(chǎn)品都是數(shù)字化形式的，尤其像金融行業(yè)，本身業(yè)務(wù)都是服務(wù)化、虛擬的，非常適合在去虛擬空間中開展。這種情況下，所有的金融產(chǎn)品幾乎都是軟件，業(yè)務(wù)想要?jiǎng)?chuàng)新產(chǎn)品、想要改善客戶體驗(yàn)，哪怕想提一些內(nèi)部管理建議，最終都要轉(zhuǎn)化成軟件的。

?

所以，在這個(gè)新的時(shí)代里，對(duì)從業(yè)人員的素質(zhì)要求逐漸會(huì)改變，因?yàn)檐浖蔀榱俗罨A(chǔ)的生產(chǎn)工具，從業(yè)者必須能夠駕馭軟件。這不僅僅是我們開發(fā)人員，業(yè)務(wù)人員也需要很好的理解軟件，這樣提出來的建議才能夠以最快的速度被開發(fā)理解。

?

EBA本身可以用來獨(dú)立的去解決企業(yè)的轉(zhuǎn)型問題，同時(shí)也可以幫業(yè)務(wù)人員去提升結(jié)構(gòu)化思維能力，所以業(yè)務(wù)架構(gòu)應(yīng)該從我們?cè)械腡OGAF理論框架中獨(dú)立出來，逐漸由業(yè)務(wù)架構(gòu)師交給業(yè)務(wù)人員去使用，這樣就不再只是為了幫IT更好的做系統(tǒng)才去搞這些事情。如果業(yè)務(wù)人員能夠用這種思路去分析他自己的業(yè)務(wù)，那對(duì)我們IT開發(fā)效能的提升也會(huì)很明顯，會(huì)幫助我們的軟件工程走出技術(shù)端。

?

3. EBA的落地應(yīng)用

?

建設(shè)銀行的“新一代核心業(yè)務(wù)系統(tǒng)”是采用企業(yè)架構(gòu)方式推動(dòng)的。業(yè)務(wù)架構(gòu)設(shè)計(jì)采用自頂向下逐層分解的方式，將建設(shè)銀行的戰(zhàn)略濃縮成26個(gè)業(yè)務(wù)方向，并進(jìn)一步細(xì)化為72個(gè)轉(zhuǎn)型舉措，形成了108個(gè)能力主題，這108個(gè)能力主題最終分解為2000多個(gè)戰(zhàn)略能力需求，這是對(duì)戰(zhàn)略的解析，多數(shù)企業(yè)在研究自身戰(zhàn)略時(shí)，都缺少這種詳細(xì)的分解，以致于戰(zhàn)略總是保持在高階層面，難以向下融合。

?

為了落地戰(zhàn)略，還需要梳理現(xiàn)狀模型和目標(biāo)模型，基于現(xiàn)狀模型導(dǎo)入戰(zhàn)略能力需求，進(jìn)而產(chǎn)生目標(biāo)模型。業(yè)務(wù)模型其實(shí)是業(yè)務(wù)架構(gòu)的表述方式，建行的實(shí)踐中，業(yè)務(wù)模型分成四種：在流程模型這部分，共計(jì)梳理900多個(gè)三級(jí)活動(dòng)，任務(wù)層面做到4500多個(gè)，步驟大約是2萬(wàn)多個(gè)；數(shù)據(jù)模型約有3000多個(gè)數(shù)據(jù)實(shí)體，2萬(wàn)多個(gè)屬性，把原來分散在各個(gè)系統(tǒng)中的數(shù)據(jù)，在企業(yè)級(jí)層面重新定義，所有數(shù)據(jù)的標(biāo)準(zhǔn)都統(tǒng)一，然后把舊的數(shù)據(jù)統(tǒng)一轉(zhuǎn)換成新的數(shù)據(jù)；產(chǎn)品模型則提升了配置化能力，做了15條產(chǎn)品線、150多個(gè)基礎(chǔ)產(chǎn)品，在新一代期間是支持了1萬(wàn)多個(gè)可售產(chǎn)品配置；體驗(yàn)?zāi)Ｐ驮诋?dāng)時(shí)主要是以界面體驗(yàn)為主。

?

基于業(yè)務(wù)架構(gòu)推導(dǎo)應(yīng)用結(jié)構(gòu)，再結(jié)合技術(shù)架構(gòu)進(jìn)行實(shí)施，最后變成了建行的新一代信息系統(tǒng)。由于建行的實(shí)踐涉及100多個(gè)主要業(yè)務(wù)系統(tǒng)的SOA改造，所以，這么大的一個(gè)工程如果不從上到下把結(jié)構(gòu)處理好，后邊的實(shí)施會(huì)很難處理，是架構(gòu)設(shè)計(jì)提供了對(duì)總體效能的基本保障。

?

大的企業(yè)轉(zhuǎn)型工程，尤其是傳統(tǒng)企業(yè)轉(zhuǎn)型，的確需要先把業(yè)務(wù)架構(gòu)梳理清楚，才能保障實(shí)施的順利。建行的實(shí)踐證明了這種“龐大”的方法是可以落地實(shí)踐的。

?

EBA方法對(duì)開發(fā)效能的改善

?

1. EBA一般設(shè)計(jì)過程

?

EBA一般設(shè)計(jì)過程如下圖所示：

?

?

EBA設(shè)計(jì)起點(diǎn)是戰(zhàn)略設(shè)計(jì)，企業(yè)對(duì)環(huán)境的變化做出的最高級(jí)別的響應(yīng)就是戰(zhàn)略調(diào)整，設(shè)計(jì)新的戰(zhàn)略一般也會(huì)要求組織結(jié)構(gòu)發(fā)生相應(yīng)變化，因?yàn)榻M織結(jié)構(gòu)是要承擔(dān)戰(zhàn)略實(shí)現(xiàn)的，組織結(jié)構(gòu)的設(shè)計(jì)好壞會(huì)影響戰(zhàn)略實(shí)施效果。但是戰(zhàn)略和組織設(shè)計(jì)對(duì)業(yè)務(wù)架構(gòu)設(shè)計(jì)的技術(shù)層面而言，是約束，因?yàn)檫@是決策層的職責(zé)而不是業(yè)務(wù)架構(gòu)師的。

?

戰(zhàn)略和組織確定后，就進(jìn)入技術(shù)層面的業(yè)務(wù)架構(gòu)設(shè)計(jì)。通過業(yè)務(wù)分析來推導(dǎo)業(yè)務(wù)能力，并將業(yè)務(wù)能力聚類成業(yè)務(wù)組件。業(yè)務(wù)組件可以被理解成一個(gè)“筐”，里面放的就是各種能力零件，把這些能力串接起來就成為業(yè)務(wù)過程。串接的順還是不順，也會(huì)檢驗(yàn)我們?cè)瓉淼牧鞒淘O(shè)計(jì)是不是合理，兩者之間可以有一個(gè)互相驗(yàn)證，所以業(yè)務(wù)分析可以推導(dǎo)組件設(shè)計(jì)，組件設(shè)計(jì)也可以反過來可以優(yōu)化業(yè)務(wù)分析。

?

業(yè)務(wù)架構(gòu)設(shè)計(jì)完之后，它的目標(biāo)是什么？當(dāng)然是實(shí)現(xiàn)企業(yè)戰(zhàn)略目標(biāo)，這就是EBA的一般設(shè)計(jì)過程。

?

雖然業(yè)務(wù)架構(gòu)師無(wú)法真正影響企業(yè)的戰(zhàn)略和組織設(shè)計(jì)，但是面向數(shù)字化轉(zhuǎn)型，在管理層、管理思想中引入架構(gòu)思維卻是非常必要的，如今有各類CXO，其實(shí)可以考慮在企業(yè)設(shè)置CAO（首席架構(gòu)官），順理成章地將架構(gòu)思想引入到管理層中來。

?

2. 推動(dòng)技術(shù)和業(yè)務(wù)思維的接近

?

EBA核心邏輯如下圖所示：

?

?

這個(gè)整體視圖大家可以看到，從上往下其實(shí)是業(yè)務(wù)邏輯。頂層是企業(yè)最高階的價(jià)值鏈，濃縮了企業(yè)的價(jià)值創(chuàng)造過程。要做這種企業(yè)級(jí)架構(gòu)設(shè)計(jì)目標(biāo)上是要把不同領(lǐng)域的業(yè)務(wù)進(jìn)行整合，去找它的公共部分，公共部分提煉出來了之后，才能更好地復(fù)用，從而提升以后的開發(fā)效能，這也是中臺(tái)方法的目標(biāo)。那么不同的領(lǐng)域最好能夠按照同一個(gè)“尺子”去梳理自己的業(yè)務(wù)活動(dòng)，才有可能比較各個(gè)領(lǐng)域的工作。如果沒有上面這個(gè)統(tǒng)一價(jià)值鏈，每個(gè)領(lǐng)域自說自話地整理流程，就很難找到公共部分了。

?

在統(tǒng)一價(jià)值鏈下，我們可以看到每一個(gè)領(lǐng)域是如何按照企業(yè)統(tǒng)一的價(jià)值創(chuàng)造過程去展開業(yè)務(wù)活動(dòng)的，進(jìn)而把業(yè)務(wù)活動(dòng)再細(xì)分到任務(wù)層級(jí)。任務(wù)需要?jiǎng)?chuàng)造數(shù)據(jù)，現(xiàn)在大家經(jīng)常提“一切業(yè)務(wù)數(shù)據(jù)化”，但如何做呢？通過這種方式，我們可以看到任務(wù)創(chuàng)造了哪些關(guān)鍵數(shù)據(jù)，反過來也可以檢驗(yàn)一下，這個(gè)數(shù)據(jù)是不是完整？是不是所有關(guān)鍵的活動(dòng)都會(huì)記錄下來？

?

這個(gè)整體視圖從下往上解讀則是技術(shù)視角。計(jì)算機(jī)設(shè)計(jì)主要關(guān)注的是行為和數(shù)據(jù)，一般在設(shè)計(jì)模塊或者設(shè)計(jì)組件時(shí)，可以先從數(shù)據(jù)的聚類開始，通過主題域的方式把關(guān)系相近的數(shù)據(jù)先聚在一起，因?yàn)檫@些數(shù)據(jù)的變化通常會(huì)互相影響。通過數(shù)據(jù)再把行為聚類，也就是功能聚在一起，這樣的話，有數(shù)據(jù)有功能，就形成了業(yè)務(wù)組件。從圖上，IT人員可以在總體上看到，組件包含了哪些數(shù)據(jù)和行為，組件的能力又是如何支持業(yè)務(wù)活動(dòng)，支持企業(yè)價(jià)值創(chuàng)造的。

?

這張圖可以把業(yè)務(wù)和技術(shù)的思維結(jié)合到一起，如果讓業(yè)務(wù)人員具備結(jié)構(gòu)化思維，那就必須給他們提供工具，否則結(jié)構(gòu)化思維就是空話，無(wú)法聚焦。而這個(gè)工具又必須跟我們IT的思維有一定程度的接近，這樣兩者的思維才能夠走到一起。有了共同的思維模式，才會(huì)有共同語(yǔ)言，業(yè)務(wù)跟技術(shù)的交流才會(huì)真正好起來。如同本文第一部分分析的那樣，通過推廣業(yè)務(wù)架構(gòu)方法才能更好解決軟件工程走出IT封閉圈子的問題，推動(dòng)需求側(cè)的變化。

?

3. 提升實(shí)施階段的溝通效率

?

對(duì)于企業(yè)轉(zhuǎn)型這類復(fù)雜的企業(yè)工程，大家經(jīng)常說它是一種“巴別塔”項(xiàng)目，“巴別塔”項(xiàng)目失敗在哪里，就是溝通，項(xiàng)目之間各自有各自的利益述求，通常需要站在自己的角度去看問題，作為需求方的各個(gè)部門其實(shí)也會(huì)如此。有企業(yè)級(jí)業(yè)務(wù)架構(gòu)模型的好處就是能夠把所有的項(xiàng)目橫向拉通，均衡地分析問題。

?

實(shí)施中，如果對(duì)一個(gè)組件的邊界有爭(zhēng)議，那么從開發(fā)團(tuán)隊(duì)的角度來講，他會(huì)先質(zhì)疑應(yīng)用架構(gòu)有沒有問題，應(yīng)用架構(gòu)自然會(huì)反推業(yè)務(wù)架構(gòu)有沒有問題，這樣就把大家的爭(zhēng)吵溯源到同一個(gè)源頭上來，企業(yè)級(jí)業(yè)務(wù)架構(gòu)相當(dāng)于吸引了所有人的“火力”，最后大家吵架能夠吵到同一個(gè)點(diǎn)上，吵到如何去判斷業(yè)務(wù)架構(gòu)是不是合適？如何去調(diào)整？所有的矛盾期都集中到這里之后，反倒會(huì)有處理這個(gè)問題的解決。作為復(fù)雜項(xiàng)目的橫向溝通工具來講，企業(yè)級(jí)業(yè)務(wù)架構(gòu)給了大家一個(gè)統(tǒng)一的藍(lán)圖，現(xiàn)在經(jīng)常講的一張藍(lán)圖繪到底，一個(gè)藍(lán)圖有助于統(tǒng)一大家的概念，不要公說公有理婆說婆有理地討論問題。模型也有助于結(jié)論的結(jié)構(gòu)化記錄，比單純的會(huì)議結(jié)果更容易保存和查閱。

?

4. 通過能力地圖提升設(shè)計(jì)效率

?

EBA并不指定特殊的實(shí)現(xiàn)方式，EBA實(shí)際上是在澄清業(yè)務(wù)能力結(jié)構(gòu)，業(yè)務(wù)側(cè)理清楚之后，IT側(cè)，只要是團(tuán)隊(duì)駕馭得了的設(shè)計(jì)風(fēng)格都可以用來進(jìn)行企業(yè)級(jí)實(shí)現(xiàn)，無(wú)論是SOA還是微服務(wù)。實(shí)現(xiàn)后的企業(yè)能力地圖如下圖所示：

?

?

落地之后我們就回到了EBA概念強(qiáng)調(diào)的內(nèi)容，我們能夠把戰(zhàn)略分解成需求，把需求映射到業(yè)務(wù)，業(yè)務(wù)最終映射到IT設(shè)計(jì)，可以把這三者之間串聯(lián)起來，串聯(lián)起來就構(gòu)成了能力地圖。無(wú)論是互聯(lián)網(wǎng)企業(yè)還是傳統(tǒng)企業(yè)，其實(shí)在總體架構(gòu)上來講，都在找這種關(guān)系，在這方面的訴求是一樣的，能力地圖代表了對(duì)業(yè)務(wù)資產(chǎn)和IT資產(chǎn)的清晰描述，無(wú)論是在復(fù)用方面還是在新增設(shè)計(jì)方面，都有助于效率的提升。

?

大家經(jīng)常說TOGAF不利于推廣的原因之一就是它的維護(hù)比較麻煩，但其實(shí)維護(hù)麻煩的一個(gè)原因是在于使用日常是不是能夠堅(jiān)持使用這個(gè)方法去項(xiàng)目管理。模型是常用常新的，如果在使用中持續(xù)的去改進(jìn)的話，那么它的維護(hù)量其實(shí)是可以分散的，如同跑步一樣，堅(jiān)持跑一千公里并不是要你一次就跑一千公里。

?

5. 對(duì)需求源頭管理的改進(jìn)

?

這個(gè)改進(jìn)的責(zé)任可以落給業(yè)務(wù)架構(gòu)師。對(duì)于企業(yè)級(jí)業(yè)務(wù)架構(gòu)實(shí)施來講，較長(zhǎng)的實(shí)施周期也必然會(huì)培養(yǎng)大量的業(yè)務(wù)架構(gòu)師，對(duì)業(yè)務(wù)架構(gòu)師的日常使用，筆者認(rèn)為其主要使命就是促進(jìn)IT與業(yè)務(wù)的融合。從這個(gè)角度來講，把他們分散到業(yè)務(wù)部門去，讓他們?cè)跇I(yè)務(wù)部門里邊，在業(yè)務(wù)需求萌芽期就形成體系化的引導(dǎo)，即減小了企業(yè)級(jí)實(shí)施的阻力，也能夠真正讓業(yè)務(wù)人員多接觸業(yè)務(wù)架構(gòu)模型，多理解結(jié)構(gòu)化的思維，多了解業(yè)務(wù)需求應(yīng)該按照一個(gè)什么樣的套路形成，從而逐步從源頭上去解決需求管理的問題。

?

軟件工程一直沒能處理好這個(gè)盲區(qū)，這是我們?cè)谛芴嵘^程中必須要關(guān)注的一個(gè)點(diǎn)，因?yàn)槲覀冊(cè)贗T側(cè)的改進(jìn)上取得了很大的成果，但是如果業(yè)務(wù)這一層不加強(qiáng)，我們的天花板高度就是有限的。

?

就工程方法而言，國(guó)內(nèi)相當(dāng)于有兩種做復(fù)雜企業(yè)工程的思路，一個(gè)是以建行為代表的自上而下通過企業(yè)架構(gòu)規(guī)劃進(jìn)行的實(shí)施；另一種就是差不多在同一時(shí)間開展的阿里巴巴的“中臺(tái)”，“中臺(tái)”被認(rèn)為是從下而上的演進(jìn)式發(fā)展。但這兩種工程方式有一個(gè)非常有趣的共同點(diǎn)——都很強(qiáng)調(diào)業(yè)務(wù)架構(gòu)的作用，雖然雙方業(yè)務(wù)架構(gòu)師的工作方式方法相差很多。

?

阿里巴巴做“中臺(tái)”之前，總結(jié)了自己存在的問題，包括缺乏業(yè)務(wù)全鏈路視角的需求管理機(jī)制、缺少可復(fù)用的業(yè)務(wù)資產(chǎn)等，從企業(yè)架構(gòu)的角度來講，就是業(yè)務(wù)資產(chǎn)、IT資產(chǎn)都不清楚。這種述求與建行開展“新一代”建設(shè)的述求在本質(zhì)上是相同的，都是要去找這個(gè)企業(yè)里可以復(fù)用的東西，把資產(chǎn)定位清楚，才能夠提升開發(fā)效能。

?

架構(gòu)資產(chǎn)的描述方式并非只有一種，建行的、阿里巴巴的，此外還有TOGAF的模型、DDD模型也都是資產(chǎn)描述方法，孰優(yōu)孰劣的區(qū)分未必很有意義，長(zhǎng)槍短炮的差別最終還是體現(xiàn)在使用者的運(yùn)用能力上，很多對(duì)工程方法的非議并非來自深入實(shí)踐之后的結(jié)論，很多時(shí)候，成功是看堅(jiān)持到什么程度，“行百里者半九十”。

?

對(duì)從行業(yè)層面提升開發(fā)效能的一點(diǎn)展望

?

說過了眼前的茍且，再看看詩(shī)和遠(yuǎn)方。

?

從行業(yè)級(jí)層面提升開發(fā)效能首先一點(diǎn)要考慮的是如何跨企業(yè)復(fù)用，上文講的還是企業(yè)內(nèi)部基于自身架構(gòu)的復(fù)用設(shè)計(jì)，但是從行業(yè)的角度來講，比如金融行業(yè)這種監(jiān)管比較嚴(yán)的行業(yè)，很多業(yè)務(wù)規(guī)則大家都一樣，但是做出的系統(tǒng)就是不一樣，經(jīng)常要把別人做過的功能換一個(gè)企業(yè)再重做，這對(duì)誰(shuí)而言都是浪費(fèi)。

?

如果想在這方面有所改進(jìn)的話，就得發(fā)揮業(yè)務(wù)架構(gòu)的引導(dǎo)作用，在業(yè)務(wù)架構(gòu)設(shè)計(jì)過程中是很強(qiáng)調(diào)標(biāo)準(zhǔn)化的，通過標(biāo)準(zhǔn)化過程梳理出來業(yè)務(wù)結(jié)構(gòu)，能不能做一些橫向的比較、橫向的復(fù)用？這就是行業(yè)級(jí)標(biāo)準(zhǔn)化的問題，目前歐美銀行中有一種架構(gòu)理論，銀行業(yè)架構(gòu)網(wǎng)絡(luò)（BIAN）模型，就是從標(biāo)準(zhǔn)化構(gòu)件的角度思考的。

?

標(biāo)準(zhǔn)化構(gòu)件也就是大家常說的“樂高積木”，不知道大家是不是刻意觀察過，樂高積木的第一個(gè)特點(diǎn)是簡(jiǎn)單易懂，這些積木塊放那沒有說明書你也能用，我們現(xiàn)在很多軟件遠(yuǎn)遠(yuǎn)達(dá)不到這個(gè)程度，其服務(wù)層級(jí)的結(jié)構(gòu)劃分業(yè)務(wù)人員完全是一頭霧水，是照著技術(shù)自己的理解搞的，業(yè)務(wù)的思想沒有充分體現(xiàn)在技術(shù)側(cè)的切分上。樂高積木的第二個(gè)特點(diǎn)是不同系列大約有70%是采用通用組件，有30%左右是有差異的。我們所說的差異化，同一行業(yè)的各個(gè)企業(yè)，業(yè)務(wù)上能達(dá)到30%的差異化就已經(jīng)相當(dāng)高了。那也就意味著，其實(shí)我們70~80%的開發(fā)是換了個(gè)環(huán)境在重復(fù)做，有20-30%是真正有可能產(chǎn)生差異化的，但是并沒有分配到足夠的資源，按照二八定律來講，我們其實(shí)應(yīng)該倒過來給這20%或者30%的業(yè)務(wù)分配80%或者70%的資源，但實(shí)際上并非如此，大量的時(shí)間和資源還是被用來做跟別人一樣的東西，還經(jīng)常是加班做。

?

改進(jìn)這一點(diǎn)并不容易，希望做出這種在行業(yè)可以推廣的構(gòu)件，那設(shè)計(jì)上必須要做到對(duì)業(yè)務(wù)友好，一定是一個(gè)業(yè)務(wù)人員可理解的設(shè)計(jì)，他才能參與進(jìn)來。很多時(shí)候服務(wù)的切分都太過于技術(shù)化了，甚至非常碎，以實(shí)現(xiàn)技術(shù)理解的“解耦”。阿里巴巴做“中臺(tái)”之前也出現(xiàn)了這個(gè)問題，微服務(wù)快速膨脹到1萬(wàn)多個(gè)，最后大家都很難說清楚服務(wù)的關(guān)系了，這也應(yīng)該算是開發(fā)上效率上的一種損失吧。只有能被業(yè)務(wù)人員理解并可以用來組裝產(chǎn)品的構(gòu)件，才是合格的構(gòu)件，這是我們?cè)谠O(shè)計(jì)上要努力去追求的。

?

自Linux誕生后，開源的集市和閉源的大教堂就成為人們心目中的兩大開發(fā)流派，現(xiàn)在大家也經(jīng)常使用開源軟件進(jìn)行企業(yè)級(jí)系統(tǒng)軟件開發(fā)工作。開源有利于更廣泛的進(jìn)行高效的軟件創(chuàng)新，主動(dòng)添加的各種功能可能會(huì)讓開源系統(tǒng)支持更多的應(yīng)用目標(biāo)，但是目前開源多為技術(shù)組件，需要再加入一些業(yè)務(wù)組件，否則，我們難以應(yīng)對(duì)今后更大規(guī)模的對(duì)軟件的需求。

?

源代碼不是可口可樂的配方法，技術(shù)人員真正的核心能力是利用各類構(gòu)件進(jìn)行要素組合去解決問題的能力。通過“集市”上找到的構(gòu)件，更快地完成大教堂的建設(shè)才是目標(biāo)，這樣才能集中精力去搞20~30%的差異部分，對(duì)企業(yè)而言也才有價(jià)值。對(duì)70-80%的重復(fù)部分進(jìn)行保護(hù)，實(shí)際上是整個(gè)行業(yè)的損失。

?

?

本文從企業(yè)級(jí)系統(tǒng)軟件開發(fā)的瓶頸講起，對(duì)軟件工程中還需要通過EBA方法進(jìn)行改進(jìn)之處做了自己的闡述，一家之言，供大家探討。最后，筆者想引用一句古詩(shī)做個(gè)總結(jié)：“問渠那得清如許，為有源頭活水來”，開發(fā)的河想要清澈，不能僅僅在開發(fā)側(cè)發(fā)力，除了持續(xù)的供給側(cè)改革，我們更需要需求側(cè)革命，這是數(shù)字化時(shí)代的要求，而非我們對(duì)業(yè)務(wù)人員的過度期許。未來企業(yè)都會(huì)逐漸轉(zhuǎn)變?yōu)榭萍脊?#xff0c;一旦起跑線差不多，我們比拼的就不再是技術(shù)實(shí)力，而是誰(shuí)家的業(yè)務(wù)人員更能幫助技術(shù)人員快速理解業(yè)務(wù)，因此，沒有業(yè)務(wù)這一側(cè)結(jié)構(gòu)化思維的改進(jìn)，開發(fā)效能的提升最終還是有限的。

總結(jié)

以上是生活随笔為你收集整理的如何提升软件开发效能？企业级业务架构思考与实践的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。