B 端軟件開發效能存在的一些瓶頸
1. 令人頭疼的源頭管理
軟件行業一直在致力於工程效率方面的持續改進，從瀑布模型、螺旋模型到敏捷過程。對於效率而言，其實各種工程模式並沒有絕對的好壞，雖然對 “古老” 的瀑布模型的批評之聲始終不絕於耳，但是新冠抗疫期間，武漢二神山醫院的建設奇蹟正是用瀑布模型完成的，從基建到設備到軟件僅用了 28 天，這都是在瀑布模型的規劃下完成的，所以，目標和需求清晰的情況下，瀑布模型能創造敏捷過程也無法完成的奇蹟。
此外，瀑布模型的一個好處是對軟件工程的主要環節說的一清二楚，自瀑布模型之後，無論工程模式如何改變，都沒能將瀑布模型中的這些環節真正省略掉，無非是實施順序、方式的變化。所以，本文還是借用瀑布模型的 “清晰” 來說說 B 端軟件開發中存在的最大瓶頸——源頭管理。
從上面這張圖中，我們可以發現，軟件過程中越靠後，也就是越進入純粹技術實現部分，比如編碼、測試、運營，工程效率改進非常明顯，持續集成、持續發佈、測試驅動開發，以及各種軟件開發平臺，頭部企業已經搞出了很多神兵利器。
但是，從這個部分再往前推的話，在需求分析、概設、詳設的效率方面，平臺和工具的支持能力就大大減弱了，因爲這方面我們更需要的是一套清晰的架構，要能更好的識別企業的業務資產和 IT 資產，設計能在架構中找到有哪些東西，能複用哪些東西，纔有可能把效率大幅度提升上來，不然的話就經常會重複造輪子。
那麼再往前到源頭，到需求提出這部分，其實已經走出了軟件工程真正可控的範圍，因爲這部分來自於業務，受技術實現能力的制約，但是不歸技術管制。在這 4 個環節上，我們通常採用評審機制進行管理，可能互聯網公司的評審工作會略微優化下，但總體而言，評審機制的工作效率並不是很高。
越靠前的環節對總體工程效率的影響實際上越大，如果是在源頭環節發生錯誤的話，那整個開發過程就變成 “試錯” 了，儘管目前工程方面有鼓勵試錯的觀點和實踐，但是 “縱容” 試錯也是有很多問題的，尤其是在傳統行業裏邊，能避免要儘量避免，輕易地去 “試錯” 會對軟件開發造成很大的資源浪費，尤其是非常寶貴的時間資源。此外，對於一些 “家業” 沒那麼大的企業來講，頻繁 “試錯” 可能會把企業都搭進去。
需求管理還是挺頭疼的一個事，經常有產品經理和技術人員互懟的這種段子。開發上常說需求來的太模糊，給你兩個圈就想要你畫出一匹馬。其實按照科學方法按部就班地慢慢來，確實也能畫出一匹馬，但是如果我們真的這麼細緻地搞需求，可能兩三個月就耗掉了，老闆們就會抱怨，說是人家兩三個月系統系統都上線了，我們才搞出個需求，所以這種方法儘管很科學，但是現在大家普遍都不接受了。比較接受的是什麼呢？這兩個圈有了之後，一頓頭腦風暴，非驢非馬的形象先出一個，開始開發，再多輪迭代，直到搞出馬來。
即便開發端如此 “折磨自己”，業務端可能還不滿意，要麼不滿意速度，要麼不滿意結果，總之，跟需求還是有 “差距” 。領導可能會想，爲啥別人家的娃幹活又快又好，咱家的娃就不行？是不是咱家娃的姿勢不對？很自然的就把鍋背給了工程方法和工程團隊。
但是，如果把工程封閉在技術人員自己這個圈子裏，對互聯網企業來講還好一點，開發人員通常在企業總人數中佔比過半，技術氛圍濃厚。但是很多傳統行業的企業中，開發人員佔比幾乎都是個位數，甚至是很低的個位數，這種情況下，如果業務人員對工程缺少足夠了解的話，那很自然的就會認爲提什麼樣的需求都對，技術團隊開發效能低的話，是你技術的問題，因爲你那塊我又不懂。
所以，在軟件工程的改進中一直缺少一件事情，就是筆者在文章開頭說的那個 “盲區”，沒把業務人員真正納入工程中，我們的工程理論過於封閉了，沒有在企業內部更好地向業務宣傳。現在都講 IT 與業務之間的融合，融合應該是雙向的，不僅是 IT 人員要去多瞭解業務，也要讓業務人員多瞭解軟件的開發過程，這對提升企業未來競爭力而言將會是一件非常重要的基礎性工作。
2. 對企業戰略和管理的忽視
首先，很多人都對戰略有個 “假大空” 的壞印象，技術人員也不例外。企業搞衛星、發宏願跟我有什麼關係？我只看需求，戰略說的再好，如果不能轉換成需求，那對技術而言有什麼意義？因爲我也不知道你要做什麼。這種想法儘管可以理解，但並不正確，因爲戰略跟企業中的每一個人都相關，所以這作爲企業的一員來講，IT 人員也應該關心企業要走到哪個方向，要去做什麼。
其次，就是企業管理。企業管理確實是一個非常瑣碎的事，有太多的雜務，開發人員還是更原意待在一個跟業務有一定隔離的後端裏邊，更願意讓業務提出需求，自己來寫代碼。
但是，如果忽略了戰略和管理這兩個問題的話，那麼就像 Zachman 框架提出的思想那樣，想在 B 端把開發這件事情做好，你必須對企業整體有深入的瞭解。而忽視戰略和管理，則會影響到我們在架構設計上的一些決策。業務需求要跟企業發展方向吻合的，但是我們把這個責任只留給了業務，自己卻沒有關注。企業管理也是在處理各個業務模塊之間的關係，如果都是都交代給了業務人員去承擔，需求書上怎麼寫我們就怎麼做，那麼這種情況下有些需求即便有問題，可能我們也看不出來，這些問題到後續的時候都會影響開發效能，包括一些返工，一邊趕工一邊還要返工。所以，現在主流思想已經是提升 IT 與業務的融合深度了，就不要再把業務和技術這兩側截然的分開去看待。
EBA 方法的價值
1. EBA 的核心價值
上面這張圖是筆者在自己的《企業級業務架構設計：方法論與實踐》一書中給出的業務架構定義，是一個操作型定義，同時也闡明瞭 EBA 的價值。EBA 就是爲了落地企業戰略，對企業業務能力進行整體規劃，再把這種規劃結果傳導給 IT 實現端的一種結構化分析方法。從這個定義上大家能看出來 EBA 到底要做什麼：把戰略落實到業務上，再通過業務的需求傳導給 IT。
EBA 也幫助業務進行了戰略在業務側的落地。最近筆者看了一篇研究報告，提到了一個數字，雖然無從考證，但報告中說 85% 的國有企業沒能找到有效將戰略分解執行的方法。EBA 其實很適合做這件事情。另一方面，EBA 也可以解決 IT 人員不關心戰略的問題，因爲戰略到 IT 中間需要業務進行傳導，否則 IT 人員很難理解戰略。
在 EBA 方法下，戰略不能僅停留在綱領性要求這個層面，而是要分解成更細的戰略能力能力。然後把現有的業務梳理成結構化的現狀業務模型，把戰略能力需求跟模型之間進行匹配後，會發現有哪些業務要調整或新增，進而形成目標模型。通過這個過程，實現戰略與業務的結合，結合在一起的戰略能力需求再傳導給 IT 人員的時候，我們就不會說這個東西是不明確的了。戰略、業務和 IT 之間一直缺少一個有效的銜接，只有通過業務架構這個橋樑進行連接，我們才能真正讓企業變成一個整體，這也是 EBA 的核心價值。
2. 與 TOGAF 相比的改進之處
與 TOGAF 相比，筆者介紹的 EBA 方法更強調獨立使用時對業務人員的價值。TOGAF 中，業務架構仍是 IT 架構的一個延伸，也就是說，做業務架構目的是爲了更好的去做 IT 設計，這對業務人員而言，貢獻就比較小了，本質上還是 IT 的事，是業務在幫 IT 做事，業務人員應用業務架構的意願和動力相對就會差很多。但實際上，獨立應用業務架構方法去管理、理解業務過程對業務人員而言也很有意義。現在大家都在談數字化轉型，未來企業中的很多產品都是數字化形式的，尤其像金融行業，本身業務都是服務化、虛擬的，非常適合在去虛擬空間中開展。這種情況下，所有的金融產品幾乎都是軟件，業務想要創新產品、想要改善客戶體驗，哪怕想提一些內部管理建議，最終都要轉化成軟件的。
所以，在這個新的時代裏，對從業人員的素質要求逐漸會改變，因爲軟件成爲了最基礎的生產工具，從業者必須能夠駕馭軟件。這不僅僅是我們開發人員，業務人員也需要很好的理解軟件，這樣提出來的建議才能夠以最快的速度被開發理解。
EBA 本身可以用來獨立的去解決企業的轉型問題，同時也可以幫業務人員去提升結構化思維能力，所以業務架構應該從我們原有的 TOGAF 理論框架中獨立出來，逐漸由業務架構師交給業務人員去使用，這樣就不再只是爲了幫 IT 更好的做系統纔去搞這些事情。如果業務人員能夠用這種思路去分析他自己的業務，那對我們 IT 開發效能的提升也會很明顯，會幫助我們的軟件工程走出技術端。
3. EBA 的落地應用
建設銀行的 “新一代核心業務系統” 是採用企業架構方式推動的。業務架構設計採用自頂向下逐層分解的方式，將建設銀行的戰略濃縮成 26 個業務方向，並進一步細化爲 72 個轉型舉措，形成了 108 個能力主題，這 108 個能力主題最終分解爲 2000 多個戰略能力需求，這是對戰略的解析，多數企業在研究自身戰略時，都缺少這種詳細的分解，以致於戰略總是保持在高階層面，難以向下融合。
爲了落地戰略，還需要梳理現狀模型和目標模型，基於現狀模型導入戰略能力需求，進而產生目標模型。業務模型其實是業務架構的表述方式，建行的實踐中，業務模型分成四種：在流程模型這部分，共計梳理 900 多個三級活動，任務層面做到 4500 多個，步驟大約是 2 萬多個；數據模型約有 3000 多個數據實體，2 萬多個屬性，把原來分散在各個系統中的數據，在企業級層面重新定義，所有數據的標準都統一，然後把舊的數據統一轉換成新的數據；產品模型則提升了配置化能力，做了 15 條產品線、150 多個基礎產品，在新一代期間是支持了 1 萬多個可售產品配置；體驗模型在當時主要是以界面體驗爲主。
基於業務架構推導應用結構，再結合技術架構進行實施，最後變成了建行的新一代信息系統。由於建行的實踐涉及 100 多個主要業務系統的 SOA 改造，所以，這麼大的一個工程如果不從上到下把結構處理好，後邊的實施會很難處理，是架構設計提供了對總體效能的基本保障。
大的企業轉型工程，尤其是傳統企業轉型，的確需要先把業務架構梳理清楚，才能保障實施的順利。建行的實踐證明了這種 “龐大” 的方法是可以落地實踐的。
EBA 方法對開發效能的改善
1. EBA 一般設計過程
EBA 一般設計過程如下圖所示：
EBA 設計起點是戰略設計，企業對環境的變化做出的最高級別的響應就是戰略調整，設計新的戰略一般也會要求組織結構發生相應變化，因爲組織結構是要承擔戰略實現的，組織結構的設計好壞會影響戰略實施效果。但是戰略和組織設計對業務架構設計的技術層面而言，是約束，因爲這是決策層的職責而不是業務架構師的。
戰略和組織確定後，就進入技術層面的業務架構設計。通過業務分析來推導業務能力，並將業務能力聚類成業務組件。業務組件可以被理解成一個 “筐”，裏面放的就是各種能力零件，把這些能力串接起來就成爲業務過程。串接的順還是不順，也會檢驗我們原來的流程設計是不是合理，兩者之間可以有一個互相驗證，所以業務分析可以推導組件設計，組件設計也可以反過來可以優化業務分析。
業務架構設計完之後，它的目標是什麼？當然是實現企業戰略目標，這就是 EBA 的一般設計過程。
雖然業務架構師無法真正影響企業的戰略和組織設計，但是面向數字化轉型，在管理層、管理思想中引入架構思維卻是非常必要的，如今有各類 CXO，其實可以考慮在企業設置 CAO（首席架構官），順理成章地將架構思想引入到管理層中來。
2. 推動技術和業務思維的接近
EBA 核心邏輯如下圖所示：
這個整體視圖大家可以看到，從上往下其實是業務邏輯。頂層是企業最高階的價值鏈，濃縮了企業的價值創造過程。要做這種企業級架構設計目標上是要把不同領域的業務進行整合，去找它的公共部分，公共部分提煉出來了之後，才能更好地複用，從而提升以後的開發效能，這也是中臺方法的目標。那麼不同的領域最好能夠按照同一個 “尺子” 去梳理自己的業務活動，纔有可能比較各個領域的工作。如果沒有上面這個統一價值鏈，每個領域自說自話地整理流程，就很難找到公共部分了。
在統一價值鏈下，我們可以看到每一個領域是如何按照企業統一的價值創造過程去展開業務活動的，進而把業務活動再細分到任務層級。任務需要創造數據，現在大家經常提 “一切業務數據化”，但如何做呢？通過這種方式，我們可以看到任務創造了哪些關鍵數據，反過來也可以檢驗一下，這個數據是不是完整？是不是所有關鍵的活動都會記錄下來？
這個整體視圖從下往上解讀則是技術視角。計算機設計主要關注的是行爲和數據，一般在設計模塊或者設計組件時，可以先從數據的聚類開始，通過主題域的方式把關係相近的數據先聚在一起，因爲這些數據的變化通常會互相影響。通過數據再把行爲聚類，也就是功能聚在一起，這樣的話，有數據有功能，就形成了業務組件。從圖上，IT 人員可以在總體上看到，組件包含了哪些數據和行爲，組件的能力又是如何支持業務活動，支持企業價值創造的。
這張圖可以把業務和技術的思維結合到一起，如果讓業務人員具備結構化思維，那就必須給他們提供工具，否則結構化思維就是空話，無法聚焦。而這個工具又必須跟我們 IT 的思維有一定程度的接近，這樣兩者的思維才能夠走到一起。有了共同的思維模式，纔會有共同語言，業務跟技術的交流纔會真正好起來。如同本文第一部分分析的那樣，通過推廣業務架構方法才能更好解決軟件工程走出 IT 封閉圈子的問題，推動需求側的變化。
3. 提升實施階段的溝通效率
對於企業轉型這類複雜的企業工程，大家經常說它是一種 “巴別塔” 項目，“巴別塔”項目失敗在哪裏，就是溝通，項目之間各自有各自的利益述求，通常需要站在自己的角度去看問題，作爲需求方的各個部門其實也會如此。有企業級業務架構模型的好處就是能夠把所有的項目橫向拉通，均衡地分析問題。
實施中，如果對一個組件的邊界有爭議，那麼從開發團隊的角度來講，他會先質疑應用架構有沒有問題，應用架構自然會反推業務架構有沒有問題，這樣就把大家的爭吵溯源到同一個源頭上來，企業級業務架構相當於吸引了所有人的 “火力”，最後大家吵架能夠吵到同一個點上，吵到如何去判斷業務架構是不是合適？如何去調整？所有的矛盾期都集中到這裏之後，反倒會有處理這個問題的解決。作爲複雜項目的橫向溝通工具來講，企業級業務架構給了大家一個統一的藍圖，現在經常講的一張藍圖繪到底，一個藍圖有助於統一大家的概念，不要公說公有理婆說婆有理地討論問題。模型也有助於結論的結構化記錄，比單純的會議結果更容易保存和查閱。
4. 通過能力地圖提升設計效率
EBA 並不指定特殊的實現方式，EBA 實際上是在澄清業務能力結構，業務側理清楚之後，IT 側，只要是團隊駕馭得了的設計風格都可以用來進行企業級實現，無論是 SOA 還是微服務。實現後的企業能力地圖如下圖所示：
落地之後我們就回到了 EBA 概念強調的內容，我們能夠把戰略分解成需求，把需求映射到業務，業務最終映射到 IT 設計，可以把這三者之間串聯起來，串聯起來就構成了能力地圖。無論是互聯網企業還是傳統企業，其實在總體架構上來講，都在找這種關係，在這方面的訴求是一樣的，能力地圖代表了對業務資產和 IT 資產的清晰描述，無論是在複用方面還是在新增設計方面，都有助於效率的提升。
大家經常說 TOGAF 不利於推廣的原因之一就是它的維護比較麻煩，但其實維護麻煩的一個原因是在於使用日常是不是能夠堅持使用這個方法去項目管理。模型是常用常新的，如果在使用中持續的去改進的話，那麼它的維護量其實是可以分散的，如同跑步一樣，堅持跑一千公里並不是要你一次就跑一千公里。
5. 對需求源頭管理的改進
這個改進的責任可以落給業務架構師。對於企業級業務架構實施來講，較長的實施週期也必然會培養大量的業務架構師，對業務架構師的日常使用，筆者認爲其主要使命就是促進 IT 與業務的融合。從這個角度來講，把他們分散到業務部門去，讓他們在業務部門裏邊，在業務需求萌芽期就形成體系化的引導，即減小了企業級實施的阻力，也能夠真正讓業務人員多接觸業務架構模型，多理解結構化的思維，多瞭解業務需求應該按照一個什麼樣的套路形成，從而逐步從源頭上去解決需求管理的問題。
軟件工程一直沒能處理好這個盲區，這是我們在效能提升過程中必須要關注的一個點，因爲我們在 IT 側的改進上取得了很大的成果，但是如果業務這一層不加強，我們的天花板高度就是有限的。
就工程方法而言，國內相當於有兩種做複雜企業工程的思路，一個是以建行爲代表的自上而下通過企業架構規劃進行的實施；另一種就是差不多在同一時間開展的阿里巴巴的 “中臺”，“中臺” 被認爲是從下而上的演進式發展。但這兩種工程方式有一個非常有趣的共同點——都很強調業務架構的作用，雖然雙方業務架構師的工作方式方法相差很多。
阿里巴巴做 “中臺” 之前，總結了自己存在的問題，包括缺乏業務全鏈路視角的需求管理機制、缺少可複用的業務資產等，從企業架構的角度來講，就是業務資產、IT 資產都不清楚。這種述求與建行開展 “新一代” 建設的述求在本質上是相同的，都是要去找這個企業裏可以複用的東西，把資產定位清楚，才能夠提升開發效能。
架構資產的描述方式並非只有一種，建行的、阿里巴巴的，此外還有 TOGAF 的模型、DDD 模型也都是資產描述方法，孰優孰劣的區分未必很有意義，長槍短炮的差別最終還是體現在使用者的運用能力上，很多對工程方法的非議並非來自深入實踐之後的結論，很多時候，成功是看堅持到什麼程度，“行百里者半九十”。
對從行業層面提升開發效能的一點展望
說過了眼前的苟且，再看看詩和遠方。
從行業級層面提升開發效能首先一點要考慮的是如何跨企業複用，上文講的還是企業內部基於自身架構的複用設計，但是從行業的角度來講，比如金融行業這種監管比較嚴的行業，很多業務規則大家都一樣，但是做出的系統就是不一樣，經常要把別人做過的功能換一個企業再重做，這對誰而言都是浪費。
如果想在這方面有所改進的話，就得發揮業務架構的引導作用，在業務架構設計過程中是很強調標準化的，通過標準化過程梳理出來業務結構，能不能做一些橫向的比較、橫向的複用？這就是行業級標準化的問題，目前歐美銀行中有一種架構理論，銀行業架構網絡（BIAN）模型，就是從標準化構件的角度思考的。
標準化構件也就是大家常說的 “樂高積木”，不知道大家是不是刻意觀察過，樂高積木的第一個特點是簡單易懂，這些積木塊放那沒有說明書你也能用，我們現在很多軟件遠遠達不到這個程度，其服務層級的結構劃分業務人員完全是一頭霧水，是照着技術自己的理解搞的，業務的思想沒有充分體現在技術側的切分上。樂高積木的第二個特點是不同系列大約有 70% 是採用通用組件，有 30% 左右是有差異的。我們所說的差異化，同一行業的各個企業，業務上能達到 30% 的差異化就已經相當高了。那也就意味着，其實我們 70~80% 的開發是換了個環境在重複做，有 20-30% 是真正有可能產生差異化的，但是並沒有分配到足夠的資源，按照二八定律來講，我們其實應該倒過來給這 20% 或者 30% 的業務分配 80% 或者 70% 的資源，但實際上並非如此，大量的時間和資源還是被用來做跟別人一樣的東西，還經常是加班做。
改進這一點並不容易，希望做出這種在行業可以推廣的構件，那設計上必須要做到對業務友好，一定是一個業務人員可理解的設計，他才能參與進來。很多時候服務的切分都太過於技術化了，甚至非常碎，以實現技術理解的 “解耦”。阿里巴巴做“中臺” 之前也出現了這個問題，微服務快速膨脹到 1 萬多個，最後大家都很難說清楚服務的關係了，這也應該算是開發上效率上的一種損失吧。只有能被業務人員理解並可以用來組裝產品的構件，纔是合格的構件，這是我們在設計上要努力去追求的。
自 Linux 誕生後，開源的集市和閉源的大教堂就成爲人們心目中的兩大開發流派，現在大家也經常使用開源軟件進行 B 端開發工作。開源有利於更廣泛的進行高效的軟件創新，主動添加的各種功能可能會讓開源系統支持更多的應用目標，但是目前開源多爲技術組件，需要再加入一些業務組件，否則，我們難以應對今後更大規模的對軟件的需求。
源代碼不是可口可樂的配方法，技術人員真正的核心能力是利用各類構件進行要素組合去解決問題的能力。通過 “集市” 上找到的構件，更快地完成大教堂的建設纔是目標，這樣才能集中精力去搞 20~30% 的差異部分，對企業而言也纔有價值。對 70-80% 的重複部分進行保護，實際上是整個行業的損失。
本文從 B 端軟件開發的瓶頸講起，對軟件工程中還需要通過 EBA 方法進行改進之處做了自己的闡述，一家之言，供大家探討。最後，筆者想引用一句古詩做個總結：“問渠那得清如許，爲有源頭活水來”，開發的河想要清澈，不能僅僅在開發側發力，除了持續的供給側改革，我們更需要需求側革命，這是數字化時代的要求，而非我們對業務人員的過度期許。未來企業都會逐漸轉變爲科技公司，一旦起跑線差不多，我們比拼的就不再是技術實力，而是誰家的業務人員更能幫助技術人員快速理解業務，因此，沒有業務這一側結構化思維的改進，開發效能的提升最終還是有限的。
作者 | 付曉巖
來源 | 曉談巖說（ID:gh_18519a945f4e）
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/RyE56rZxMJoPZzFV_fbZNw