?

資訊中心 NEWS真實、正向、傳遞價值

當前位置: 首頁 > 資訊中心 > 行業快訊

如何通過企業級業務架構方法提升B端軟件開發效能

日期:2020-09-09 11:23:53 / 人氣:

企業級業務架構(EBA)方法源自Zachman框架和TOGAF理論。企業架構總是給人一種龐大而笨重的印象,實踐往往也需要一定的時間周期,相信很多人都會懷疑這種連它自己都快不起來的實施模式會對提升B端軟件開發效能有什么幫助,本文筆者就試著討論下這個問題,同時,也跟各位讀者分析分析軟件工程發展至今仍有很大不足的一處“盲區”。

一、B端軟件開發效能存在的一些瓶頸

(一)令人頭疼的源頭管理

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

此外,瀑布模型的一個好處是對軟件工程的主要環節說的一清二楚,自瀑布模型之后,無論工程模式如何改變,都沒能將瀑布模型中的這些環節真正省略掉,無非是實施順序、方式的變化。所以,本文還是借用瀑布模型的“清晰”來說說B端軟件開發中存在的最大瓶頸——源頭管理。

如何通過企業級業務架構方法提升B端軟件開發效能(圖1)

從上面這張圖中,我們可以發現,軟件過程中越靠后,也就是越進入純粹技術實現部分,比如編碼、測試、運營,工程效率改進非常明顯,持續集成、持續發布、測試驅動開發,以及各種軟件開發平臺,頭部企業已經搞出了很多神兵利器。

但是,從這個部分再往前推的話,在需求分析、概設、詳設的效率方面,平臺和工具的支持能力就大大減弱了,因為這方面我們更需要的是一套清晰的架構,要能更好的識別企業的業務資產和IT資產,設計能在架構中找到有哪些東西,能復用哪些東西,才有可能把效率大幅度提升上來,不然的話就經常會重復造輪子。

那么再往前到源頭,到需求提出這部分,其實已經走出了軟件工程真正可控的范圍,因為這部分來自于業務,受技術實現能力的制約,但是不歸技術管制。在這4個環節上,我們通常采用評審機制進行管理,可能互聯網公司的評審工作會略微優化下,但總體而言,評審機制的工作效率并不是很高。

越靠前的環節對總體工程效率的影響實際上越大,如果是在源頭環節發生錯誤的話,那整個開發過程就變成“試錯”了,盡管目前工程方面有鼓勵試錯的觀點和實踐,但是“縱容”試錯也是有很多問題的,尤其是在傳統行業里邊,能避免要盡量避免,輕易地去“試錯”會對軟件開發造成很大的資源浪費,尤其是非常寶貴的時間資源。此外,對于一些“家業”沒那么大的企業來講,頻繁“試錯”可能會把企業都搭進去。

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

即便開發端如此“折磨自己”,業務端可能還不滿意,要么不滿意速度,要么不滿意結果,總之,跟需求還是有“差距” 。領導可能會想,為啥別人家的娃干活又快又好,咱家的娃就不行?是不是咱家娃的姿勢不對?很自然的就把鍋背給了工程方法和工程團隊。

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

但是,如果把工程封閉在技術人員自己這個圈子里,對互聯網企業來講還好一點,開發人員通常在企業總人數中占比過半,技術氛圍濃厚。但是很多傳統行業的企業中,開發人員占比幾乎都是個位數,甚至是很低的個位數,這種情況下,如果業務人員對工程缺少足夠了解的話,那很自然的就會認為提什么樣的需求都對,技術團隊開發效能低的話,是你技術的問題,因為你那塊我又不懂。

所以,在軟件工程的改進中一直缺少一件事情,就是筆者在文章開頭說的那個“盲區”,沒把業務人員真正納入工程中,我們的工程理論過于封閉了,沒有在企業內部更好地向業務宣傳?,F在都講IT與業務之間的融合,融合應該是雙向的,不僅是IT人員要去多了解業務,也要讓業務人員多了解軟件的開發過程,這對提升企業未來競爭力而言將會是一件非常重要的基礎性工作。

(二)對企業戰略和管理的忽視

首先,很多人都對戰略有個“假大空”的壞印象,技術人員也不例外。企業搞衛星、發宏愿跟我有什么關系?我只看需求,戰略說的再好,如果不能轉換成需求,那對技術而言有什么意義?因為我也不知道你要做什么。這種想法盡管可以理解,但并不正確,因為戰略跟企業中的每一個人都相關,所以這作為企業的一員來講,IT人員也應該關心企業要走到哪個方向,要去做什么。

其次,就是企業管理。企業管理確實是一個非?,嵥榈氖?,有太多的雜務,開發人員還是更原意待在一個跟業務有一定隔離的后端里邊,更愿意讓業務提出需求,自己來寫代碼。

但是,如果忽略了戰略和管理這兩個問題的話,那么就像Zachman框架提出的思想那樣,想在B端把開發這件事情做好,你必須對企業整體有深入的了解。而忽視戰略和管理,則會影響到我們在架構設計上的一些決策。業務需求要跟企業發展方向吻合的,但是我們把這個責任只留給了業務,自己卻沒有關注。企業管理也是在處理各個業務模塊之間的關系,如果都是都交代給了業務人員去承擔,需求書上怎么寫我們就怎么做,那么這種情況下有些需求即便有問題,可能我們也看不出來,這些問題到后續的時候都會影響開發效能,包括一些返工,一邊趕工一邊還要返工。所以,現在主流思想已經是提升IT與業務的融合深度了,就不要再把業務和技術這兩側截然的分開去看待。

二、EBA方法的價值

(一)EBA的核心價值

如何通過企業級業務架構方法提升B端軟件開發效能(圖2)

上面這張圖是筆者在自己的《企業級業務架構設計:方法論與實踐》一書中給出的業務架構定義,是一個操作型定義,同時也闡明了EBA的價值。EBA就是為了落地企業戰略,對企業業務能力進行整體規劃,再把這種規劃結果傳導給IT實現端的一種結構化分析方法。從這個定義上大家能看出來EBA到底要做什么:把戰略落實到業務上,再通過業務的需求傳導給IT。

EBA也幫助業務進行了戰略在業務側的落地。最近筆者看了一篇研究報告,提到了一個數字,雖然無從考證,但報告中說85%的國有企業沒能找到有效將戰略分解執行的方法。EBA其實很適合做這件事情。另一方面,EBA也可以解決IT人員不關心戰略的問題,因為戰略到IT中間需要業務進行傳導,否則IT人員很難理解戰略。

在EBA方法下,戰略不能僅停留在綱領性要求這個層面,而是要分解成更細的戰略能力。然后把現有的業務梳理成結構化的現狀業務模型,把戰略能力需求跟模型之間進行匹配后,會發現有哪些業務要調整或新增,進而形成目標模型。通過這個過程,實現戰略與業務的結合,結合在一起的戰略能力需求再傳導給IT人員的時候,我們就不會說這個東西是不明確的了。戰略、業務和IT之間一直缺少一個有效的銜接,只有通過業務架構這個橋梁進行連接,我們才能真正讓企業變成一個整體,這也是EBA的核心價值。

(二)與TOGAF相比的改進之處

與TOGAF相比,筆者介紹的EBA方法更強調獨立使用時對業務人員的價值。TOGAF中,業務架構仍是IT架構的一個延伸,也就是說,做業務架構目的是為了更好的去做IT設計,這對業務人員而言,貢獻就比較小了,本質上還是IT的事,是業務在幫IT做事,業務人員應用業務架構的意愿和動力相對就會差很多。但實際上,獨立應用業務架構方法去管理、理解業務過程對業務人員而言也很有意義?,F在大家都在談數字化轉型,未來企業中的很多產品都是數字化形式的,尤其像金融行業,本身業務都是服務化、虛擬的,非常適合在去虛擬空間中開展。這種情況下,所有的金融產品幾乎都是軟件,業務想要創新產品、想要改善客戶體驗,哪怕想提一些內部管理建議,最終都要轉化成軟件的。

所以,在這個新的時代里,對從業人員的素質要求逐漸會改變,因為軟件成為了最基礎的生產工具,從業者必須能夠駕馭軟件。這不僅僅是我們開發人員,業務人員也需要很好的理解軟件,這樣提出來的建議才能夠以最快的速度被開發理解。

EBA本身可以用來獨立的去解決企業的轉型問題,同時也可以幫業務人員去提升結構化思維能力,所以業務架構應該從我們原有的TOGAF理論框架中獨立出來,逐漸由業務架構師交給業務人員去使用,這樣就不再只是為了幫IT更好的做系統才去搞這些事情。如果業務人員能夠用這種思路去分析他自己的業務,那對我們IT開發效能的提升也會很明顯,會幫助我們的軟件工程走出技術端。

(三)EBA的落地應用

建設銀行的“新一代核心業務系統”是采用企業架構方式推動的。業務架構設計采用自頂向下逐層分解的方式,將建設銀行的戰略濃縮成26個業務方向,并進一步細化為72個轉型舉措,形成了108個能力主題,這108個能力主題最終分解為2000多個戰略能力需求,這是對戰略的解析,多數企業在研究自身戰略時,都缺少這種詳細的分解,以致于戰略總是保持在高階層面,難以向下融合。

為了落地戰略,還需要梳理現狀模型和目標模型,基于現狀模型導入戰略能力需求,進而產生目標模型。業務模型其實是業務架構的表述方式,建行的實踐中,業務模型分成四種:在流程模型這部分,共計梳理900多個三級活動,任務層面做到4500多個,步驟大約是2萬多個;數據模型約有3000多個數據實體,2萬多個屬性,把原來分散在各個系統中的數據,在企業級層面重新定義,所有數據的標準都統一,然后把舊的數據統一轉換成新的數據;產品模型則提升了配置化能力,做了15條產品線、150多個基礎產品,在新一代期間是支持了1萬多個可售產品配置;體驗模型在當時主要是以界面體驗為主。

基于業務架構推導應用結構,再結合技術架構進行實施,最后變成了建行的新一代信息系統。由于建行的實踐涉及100多個主要業務系統的SOA改造,所以,這么大的一個工程如果不從上到下把結構處理好,后邊的實施會很難處理,是架構設計提供了對總體效能的基本保障。

大的企業轉型工程,尤其是傳統企業轉型,的確需要先把業務架構梳理清楚,才能保障實施的順利。建行的實踐證明了這種“龐大”的方法是可以落地實踐的。

三、EBA方法對開發效能的改善

(一)EBA一般設計過程

EBA一般設計過程如下圖所示:

如何通過企業級業務架構方法提升B端軟件開發效能(圖3)

EBA設計起點是戰略設計,企業對環境的變化做出的最高級別的響應就是戰略調整,設計新的戰略一般也會要求組織結構發生相應變化,因為組織結構是要承擔戰略實現的,組織結構的設計好壞會影響戰略實施效果。但是戰略和組織設計對業務架構設計的技術層面而言,是約束,因為這是決策層的職責而不是業務架構師的。

戰略和組織確定后,就進入技術層面的業務架構設計。通過業務分析來推導業務能力,并將業務能力聚類成業務組件。業務組件可以被理解成一個“筐”,里面放的就是各種能力零件,把這些能力串接起來就成為業務過程。串接的順還是不順,也會檢驗我們原來的流程設計是不是合理,兩者之間可以有一個互相驗證,所以業務分析可以推導組件設計,組件設計也可以反過來可以優化業務分析。

業務架構設計完之后,它的目標是什么?當然是實現企業戰略目標,這就是EBA的一般設計過程。

雖然業務架構師無法真正影響企業的戰略和組織設計,但是面向數字化轉型,在管理層、管理思想中引入架構思維卻是非常必要的,如今有各類CXO,其實可以考慮在企業設置CAO(首席架構官),順理成章地將架構思想引入到管理層中來。

(二)推動技術和業務思維的接近

EBA核心邏輯如下圖所示:

如何通過企業級業務架構方法提升B端軟件開發效能(圖4)

這個整體視圖大家可以看到,從上往下其實是業務邏輯。頂層是企業最高階的價值鏈,濃縮了企業的價值創造過程。要做這種企業級架構設計目標上是要把不同領域的業務進行整合,去找它的公共部分,公共部分提煉出來了之后,才能更好地復用,從而提升以后的開發效能,這也是中臺方法的目標。那么不同的領域最好能夠按照同一個“尺子”去梳理自己的業務活動,才有可能比較各個領域的工作。如果沒有上面這個統一價值鏈,每個領域自說自話地整理流程,就很難找到公共部分了。

在統一價值鏈下,我們可以看到每一個領域是如何按照企業統一的價值創造過程去展開業務活動的,進而把業務活動再細分到任務層級。任務需要創造數據,現在大家經常提“一切業務數據化”,但如何做呢?通過這種方式,我們可以看到任務創造了哪些關鍵數據,反過來也可以檢驗一下,這個數據是不是完整?是不是所有關鍵的活動都會記錄下來?

這個整體視圖從下往上解讀則是技術視角。計算機設計主要關注的是行為和數據,一般在設計模塊或者設計組件時,可以先從數據的聚類開始,通過主題域的方式把關系相近的數據先聚在一起,因為這些數據的變化通常會互相影響。通過數據再把行為聚類,也就是功能聚在一起,這樣的話,有數據有功能,就形成了業務組件。從圖上,IT人員可以在總體上看到,組件包含了哪些數據和行為,組件的能力又是如何支持業務活動,支持企業價值創造的。

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

(三)提升實施階段的溝通效率

對于企業轉型這類復雜的企業工程,大家經常說它是一種“巴別塔”項目,“巴別塔”項目失敗在哪里,就是溝通,項目之間各自有各自的利益述求,通常需要站在自己的角度去看問題,作為需求方的各個部門其實也會如此。有企業級業務架構模型的好處就是能夠把所有的項目橫向拉通,均衡地分析問題。

實施中,如果對一個組件的邊界有爭議,那么從開發團隊的角度來講,他會先質疑應用架構有沒有問題,應用架構自然會反推業務架構有沒有問題,這樣就把大家的爭吵溯源到同一個源頭上來,企業級業務架構相當于吸引了所有人的“火力”,最后大家吵架能夠吵到同一個點上,吵到如何去判斷業務架構是不是合適?如何去調整?所有的矛盾期都集中到這里之后,反倒會有處理這個問題的解決。作為復雜項目的橫向溝通工具來講,企業級業務架構給了大家一個統一的藍圖,現在經常講的一張藍圖繪到底,一個藍圖有助于統一大家的概念,不要公說公有理婆說婆有理地討論問題。模型也有助于結論的結構化記錄,比單純的會議結果更容易保存和查閱。

(四)通過能力地圖提升設計效率

EBA并不指定特殊的實現方式,EBA實際上是在澄清業務能力結構,業務側理清楚之后,IT側,只要是團隊駕馭得了的設計風格都可以用來進行企業級實現,無論是SOA還是微服務。實現后的企業能力地圖如下圖所示:

如何通過企業級業務架構方法提升B端軟件開發效能(圖5)

落地之后我們就回到了EBA概念強調的內容,我們能夠把戰略分解成需求,把需求映射到業務,業務最終映射到IT設計,可以把這三者之間串聯起來,串聯起來就構成了能力地圖。無論是互聯網企業還是傳統企業,其實在總體架構上來講,都在找這種關系,在這方面的訴求是一樣的,能力地圖代表了對業務資產和IT資產的清晰描述,無論是在復用方面還是在新增設計方面,都有助于效率的提升。

大家經常說TOGAF不利于推廣的原因之一就是它的維護比較麻煩,但其實維護麻煩的一個原因是在于使用日常是不是能夠堅持使用這個方法去項目管理。模型是常用常新的,如果在使用中持續的去改進的話,那么它的維護量其實是可以分散的,如同跑步一樣,堅持跑一千公里并不是要你一次就跑一千公里。

(五)對需求源頭管理的改進

這個改進的責任可以落給業務架構師。對于企業級業務架構實施來講,較長的實施周期也必然會培養大量的業務架構師,對業務架構師的日常使用,筆者認為其主要使命就是促進IT與業務的融合。從這個角度來講,把他們分散到業務部門去,讓他們在業務部門里邊,在業務需求萌芽期就形成體系化的引導,即減小了企業級實施的阻力,也能夠真正讓業務人員多接觸業務架構模型,多理解結構化的思維,多了解業務需求應該按照一個什么樣的套路形成,從而逐步從源頭上去解決需求管理的問題。

軟件工程一直沒能處理好這個盲區,這是我們在效能提升過程中必須要關注的一個點,因為我們在IT側的改進上取得了很大的成果,但是如果業務這一層不加強,我們的天花板高度就是有限的。

就工程方法而言,國內相當于有兩種做復雜企業工程的思路,一個是以建行為代表的自上而下通過企業架構規劃進行的實施;另一種就是差不多在同一時間開展的阿里巴巴的“中臺”,“中臺”被認為是從下而上的演進式發展。但這兩種工程方式有一個非常有趣的共同點——都很強調業務架構的作用,雖然雙方業務架構師的工作方式方法相差很多。

阿里巴巴做“中臺”之前,總結了自己存在的問題,包括缺乏業務全鏈路視角的需求管理機制、缺少可復用的業務資產等,從企業架構的角度來講,就是業務資產、IT資產都不清楚。這種述求與建行開展“新一代”建設的述求在本質上是相同的,都是要去找這個企業里可以復用的東西,把資產定位清楚,才能夠提升開發效能。

架構資產的描述方式并非只有一種,建行的、阿里巴巴的,此外還有TOGAF的模型、DDD模型也都是資產描述方法,孰優孰劣的區分未必很有意義,長槍短炮的差別最終還是體現在使用者的運用能力上,很多對工程方法的非議并非來自深入實踐之后的結論,很多時候,成功是看堅持到什么程度,“行百里者半九十”。

四、對從行業層面提升開發效能的一點展望

說過了眼前的茍且,再看看詩和遠方。

從行業級層面提升開發效能首先一點要考慮的是如何跨企業復用,上文講的還是企業內部基于自身架構的復用設計,但是從行業的角度來講,比如金融行業這種監管比較嚴的行業,很多業務規則大家都一樣,但是做出的系統就是不一樣,經常要把別人做過的功能換一個企業再重做,這對誰而言都是浪費。

如果想在這方面有所改進的話,就得發揮業務架構的引導作用,在業務架構設計過程中是很強調標準化的,通過標準化過程梳理出來業務結構,能不能做一些橫向的比較、橫向的復用?這就是行業級標準化的問題,目前歐美銀行中有一種架構理論,銀行業架構網絡(BIAN)模型,就是從標準化構件的角度思考的。

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

改進這一點并不容易,希望做出這種在行業可以推廣的構件,那設計上必須要做到對業務友好,一定是一個業務人員可理解的設計,他才能參與進來。很多時候服務的切分都太過于技術化了,甚至非常碎,以實現技術理解的“解耦”。阿里巴巴做“中臺”之前也出現了這個問題,微服務快速膨脹到1萬多個,最后大家都很難說清楚服務的關系了,這也應該算是開發上效率上的一種損失吧。只有能被業務人員理解并可以用來組裝產品的構件,才是合格的構件,這是我們在設計上要努力去追求的。

自Linux誕生后,開源的集市和閉源的大教堂就成為人們心目中的兩大開發流派,現在大家也經常使用開源軟件進行B端開發工作。開源有利于更廣泛的進行高效的軟件創新,主動添加的各種功能可能會讓開源系統支持更多的應用目標,但是目前開源多為技術組件,需要再加入一些業務組件,否則,我們難以應對今后更大規模的對軟件的需求。

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

轉載編輯  泰州潤揚網絡策劃服務有限公司



? 久久综合国产乱子伦精品免费