中臺之上（十一）：企業級業務架構設計的“五難”

摘要： 我們簡單回顧一下，以業務架構的發展過程和對業務模型基本介紹作為開始，結合筆者的工作經驗和自身一些不成熟的理解，在業務架構設計方面陸續講到了企業戰略解讀、企業組織結構的影響、如何劃分業務領域和流程、與流程建模配套的資料建模、企業級的模型標準化，並設計了一個虛擬的案例；在業務架構驅動開發方面，講到...

我們簡單回顧一下，以業務架構的發展過程和對業務模型基本介紹作為開始，結合筆者的工作經驗和自身一些不成熟的理解，在業務架構設計方面陸續講到了企業戰略解讀、企業組織結構的影響、如何劃分業務領域和流程、與流程建模配套的資料建模、企業級的模型標準化，並設計了一個虛擬的案例；在業務架構驅動開發方面，講到了如何將業務架構設計轉化為業務架構方案、業務架構師如何基於模型與專案開發團隊溝通、專案開發團隊如何基於模型開展設計、專案團隊之間的協調、模型基於實施的調整和企業級專案完成後如何繼續建立持久的企業級工作機制，之後還分析了與敏捷開發的關係。這已經算得上是一個完整的歷程了，包括了企業級轉型的規劃、設計、實施及建成後的應用機制。企業級建設是個很艱難的過程，經歷前面的介紹之後，我們不妨聊一聊企業級的實施之難，也給各位已經投入或者即將投入企業級轉型的同仁們提供一點兒思路上的參考，或者就算幫大家發發牢騷、吐吐槽吧。

企業級是一個美好而艱難的願景，瞭解“領域驅動設計（DDD）”的朋友可能會知道，DDD 是不對企業級抱太大希望的，認為企業級的建設路徑只能是一個領域一個領域的不斷嘗試融合，換句話說，DDD 不認為企業級真的可以通過自頂向下的規劃產生，只能是自底向上的生長；科技公司中如果說企業級的代表，可能莫過於阿里的“大中臺”模式，但這個模式是“演化”出來的，有興趣的朋友可以讀讀相關書籍，但阿里畢竟有個好處，其業務範圍總體而言是垂直的電商領域，當然，這並不是說電商業務很簡單、很單一，而是領域中還是有一定的公共部分可以抽離的，這個觀點也得到一些阿里同學的認同。但說到金融，學過或者做過金融的同學可能有體會，這是一個很不“專業”的專業，裡邊東西五花八門，看似大家都在同一個領域，實際上卻是“各懷鬼胎”，傳統的存貸款跟票據業務其實沒啥直接關係，票據跟金融市場沾邊，但是關係也不深，代收代付不過是個約定轉賬，現金管理是個大雜燴，託管是另外一個領域，後來還多出個養老金，這幾年新興的資管、理財完全可以自成一體，不然支付寶、餘額寶也不會發展那麼迅速。說到底，大家的共性無非是客戶都是同一群客戶，圍繞客戶共建了一個賬戶體系，業務雖然差別很大，但是多數都得記賬。也就是說，如果自頂向下看，客戶和賬務是應該企業級的，而其他部分，嚴謹地說，真就像 DDD 主張的那樣，得一個領域一個領域去研究，這也是建模和標準化的難點。所以，企業級建設的難度跟企業所在行業的特點有直接關係，沒有一個通用的企業級業務模型可以隨便套，甚至一個行業內，企業跟企業之間內部特點的差別，也會決定企業級建設路徑和結果的不同。

這算得上是企業級的第一難吧，也即，很難通過簡單複製的方式快速切換到企業級。別人的經驗，無論成敗，對你而言都是個借鑑，自己的路還要自己走，但是實踐中找個“老司機”帶帶路，找個做過企業級開發的科技公司幫助做轉型還是比較穩的。

第二難，企業級多數情況下不是個技術問題。這是非常讓技術人員為難的，因為這根本不在他們的能力範圍之內。前面提到過綜合積分的事情，這只是眾多要協調的事例中的一個，如果是一個業務種類繁多、部門龐雜、等級森嚴的傳統企業，建企業級不次於一場“內戰“，一場對部門邊界、協同關係的重新界定。你可能會覺得，真有那麼可怕嗎？如果沒有那麼可怕，我倒寧願相信是以下兩種情況中的一種：一是企業之前分工非常合理，無可挑剔；二是大家都沒去觸動真正要解決的問題，一團和氣的結束了。前者基本是不可能的，而後者是非常可能的。如果真的是下了決心要做，對於一個傳統企業而言，要改的東西實在太多了，而引入新方法、新思維產生的衝擊也需要大量的時間去消化，是一個徹頭徹尾的大轉身。這其中，需要業務上做的調整不亞於技術上的調整，而對企業文化的調整尤為重要，現代管理學之父彼得·德魯克曾說過這樣一句名言：“文化能把戰略當午餐吃掉（Culture eats strategy for lunch）”，這的確是個難題。

第三難，應對理想與現實的落差。做專案很重要的一項工作是管理好使用者的預期，企業級建設也是如此。因為要耗費大量人力物力，所以，企業級專案啟動之前，往往會將藍圖描繪的太過美好，但是建設週期的漫長、建設過程的曲折，以及中間不斷對現實做的一些妥協和折衷，會讓很多“泡沫”被擠掉，這會讓實現的結果看起來很“骨感”，之前文章中我也提到過，有些目標其實不是企業級要去解決的問題，有些成果也不是非得記在企業級的功勞簿上，甚至做企業級的成本和收益都難以直接計算。這有點兒像從單體應用到 SOA、微服務的演變，看起來零件化了，靈活性上升了，但通訊、維護也變複雜了，企業級效果的積極方面可能也要隨著時間才能逐漸顯現。這會產生對企業級的懷疑，尤其是在專案剛結束的一段時間內，大家都期盼著出現跟以往迥然不同的“大轉變”，但是，往往需要“讓子彈飛一會兒”。所以，要管理好企業的預期，不需要給企業級專案戴上太多的“高帽”，而忽視了真正該戴的“高帽”——完成一次企業文化的建設，實現整體轉型，如果這個目標沒實現，那才是真正該失望的，不要只用系統去檢驗企業級。

第四難，架構的權責定位。在組織中，一件事情能做好，其前提就是做事的人權責匹配，無論是臨時事項還是長期事項，否則，成功就是僥倖而不可複製的。企業級轉型期間，作為臨時性專案組織，架構可以有較大權力去保證專案落地，但是轉型期結束，轉入常態開發時，架構如何定位呢？我之前給出的機制是一種解決辦法，畢竟架構就是架構，不是企業的管理者。但是，架構定位的困難在於，權力太小，不足以維護企業級，甚至讓企業級隨著時間的流逝而“名存實亡”；權力過大，又會發展成新的部門化組織，一旦開始以架構“衛道士”自居，就會導致對架構創新的阻礙。這種說法可能科技公司不太容易理解，但是對傳統大型企業而言，是很正常的，因為這些企業中本就有強烈的“官本位”思想。企業級建設實際上是要讓這些習慣了業務管理的企業去正視技術，定位好自身的科技基因，如何對科技中很重要的一股力量——架構師（既包括業務架構師也包括其他架構師）做出合理定位，就成了對企業的一個大考。

第五難，志貴有恆。企業級的長期堅持是件難事兒，大家可能會覺得，業務架構有了、模型有了、地圖有了、機制有了，還會很難嗎？當然會的，愛美之心，人皆有之，都知道體型好又漂亮又健康，花錢、花時間減肥的大有人在，但是真正堅持到底、不反彈的有多少？企業和個人都是一樣的道理，水會自然流向阻力最小的地方，所以，企業級的放棄和崩壞，未必是把架構組織撤銷、機制停掉這麼激烈的動作，而是各種“畏難情緒”、“客觀原因”導致的緩慢的無序，跟減肥、忌菸失敗差不多。

說了一堆難處，讀者也能體會到，傳統企業，尤其是大型企業談企業級，跟那些網際網路科技公司是不大相同的。對於後者，雖然也有管理方面的因素，但更多還是技術規劃、技術棧建設的問題；而對於前者，自始至終，非技術因素的作用與技術因素相比，至少是等量齊觀的。但是時代已經進入了數字化時代，正如某次交流會上，一位嘉賓豪言，“未來已來，你愛來不來”。隨著國家開放程度的不斷提高，民營領域創新能力的不斷提升，大型傳統企業已經進入了被動的數字化轉型之中，是否會迎面走上、順利走通企業級轉型這條舉步維艱之路，我們拭目以待吧。

作者介紹：付曉巖，原國有大行資深業務架構師，負責業務架構設計、專案管理，熱衷新技術探索與實踐，具有豐富的銀行業務經驗和企業級專案業務架構設計經驗，曾主導客戶關係、金融市場、同業、資管、養老金等多個領域核心系統的業務架構設計。公眾號：曉談巖說。