業務架構是推動業務與技術深度融合的重要方法，之前的文章中也提到，要在各種場合儘可能推廣模型的使用和模型思維方式，以促進“統一語言”的建立，那麼，業務架構還有一項很重要的工作就是使用既有的架構去管理新的需求，這是業務架構的長期應用機制問題。
項目結束了怎麼辦？
企業級轉型，或者搞中臺，都不是“一錘子買賣”，不是項目上線，搞個慶功儀式就萬事大吉了。按照熵增理論，沒有良好的維護，再好的架構也會慢慢崩壞，何況架構還得與時俱進。任何領先都是暫時的，尤其是在技術方面。
企業級業務架構建立之後，必須堅持用這個架構去管理新的需求，隨着業務和技術的發展不斷調整架構，以保持架構常用常新。那什麼樣的機制合適呢？
做企業級轉型時，爲了項目的順利進行，大部分企業都會選擇按照項目管理的套路構建臨時管理機構，比如筆者原來所在單位，就是安排各部門領導、骨幹組成臨時的跨部門項目管理組織，爲業務架構、應用架構、技術架構、數據架構、安全架構都設立專職團隊，形成企業級架構管理。除進行最初的企業級規劃外，由於項目週期長達數年，在舊系統改造的基礎上還要不斷疊加新需求，架構團隊也會承擔基於已經建好的業務模型進行新需求整合與分配的職責。項目期間，這樣的臨時機制沒問題，而且，有跨部門的項目管理組織做後盾，雖然少不了磕磕絆絆，但還是走得下去。項目結束之後呢？顯然各部門不能總是把精力花在這些項目協調和管理工作上，而跨部門的項目管理組織即便形式上可以固化，也難以長期維持其熱情和效率。所以，看似可以簡單繼承的項目管理機制，實際上很難直接繼承下去。
如何解決這個問題呢？我們從模型工具、高階管理和具體執行三個角度看一下。
模型工具。完成企業級轉型項目後，如果業務模型構建的合理，質量過關，就意味着企業有了一張從業務直通技術的“作戰地圖”，而新需求大部分都是對已有流程和功能的改良，這些改良可以“按圖索驥”，找到模型中需要做的變更；少部分需求是全新的，需要增加流程和功能，也就意味着模型內容要增加，這樣的模型應用邏輯，簡單而直接，始終保持着企業級理念，從工具角度看，繼續使用模型是沒有問題的。
高階管理。前邊我們說過，業務架構不宜過於中心化，但是作爲爭端的解決機制，終歸還是要有個仲裁者，所以，保留一個適當規模的企業級架構決策團隊（包括業務架構、應用架構、技術架構、數據架構、安全架構）作爲整體架構的指導者和仲裁者也是有必要的，但顯然，這個團隊是不可能太大的，否則工作效率會有問題。
具體執行。這就是探討項目結束後，企業級架構決策團隊以外的業務架構人員工作方法的問題了。業務架構不同於需求分析，所以，不能簡單把業務架構人員分散到項目或者組件管理團隊中去，因爲時間久了，會淡化業務架構人員的企業級視角。以我個人的經歷來講，我覺得最合適的方式是迴歸“初心”，讓業務架構人員進入業務條線工作，繼續承擔推動業務與技術融合的職能，尤其是承擔起向業務人員普及技術應用方式的職責，去填補“數字鴻溝”。
深度融合該怎麼搞？
現在大家都常說要實現業務與技術的深度融合，但是怎麼做呢？所有業務線上化、大力提高科技戰略地位？個人認爲，融合首先是人的融合。深度融合不是找幾個技術大牛或者請些頭部科技公司做幾個“亮瞎眼”、不明覺厲的項目，而是業務人員和科技人員能夠坐到一起充分交流、溝通，多瞭解對方的想法，互相碰撞和滲透，改變過去按部就班地接需求、搞項目的“面向過程”的開發，實現具有互相理解的“面向對象”、“面向服務”的開發。這就要求技術人員必須向前一大步，參與到業務中去，而業務架構人員非常適合擔任這個“先鋒”。利用企業級轉型過程，培養大量業務架構人員，再分散到業務部門，但是人員管理不歸屬業務部門，以保持工作的獨立性。在日常工作中與業務人員廣泛交流，不斷提升業務人員對企業級理念、技術實現、技術趨勢的理解，激發業務人員更大的想象空間和跨部門協作的動力，使需求在交流中“自然”產生，也可以減輕過去業務人員“冥思苦想”新需求的痛苦，讓雙方在工作起步時就交融在一起。大家可能會覺得，這得需要多少技術人員？是需要不少，不過，目前很多大企業在研究轉型戰略時都把提高技術人員佔比列入了計劃中，在我個人看來，如果不提升技術人員比重，談數字化轉型無異於“霧裏看花”，試想，一個企業用了一大堆“不知其所以然”的工具，真的能搖身一變成了“數字領袖”嗎？提升技術人員比重的長遠用意，也不僅是加強技術掌控力、提高自主研發率，而是要通過人員的增加帶動更深入的交流，從而幫助業務人員實現數字化思維的轉型，這纔是業務與技術深度融合的目標。業務架構師非常適合作爲與業務人員接觸的“技術第一人”，在工作中，還可以及時調動需求分析、產品經理、技術人員提早參加到需求形成過程中，將需求管理直接轉變爲業務規劃，這纔是大家都希望實現的融合與快速反應。基本的工作組織形式可以如下：
業務架構師分散駐紮在各個業務部門，需求產生時即採用模型工具與業務人員共同討論，可以根據需要要求組件開發團隊的需求分析人員、產品經理或者開發人員提前介入分析；需求成型後即進入實施過程，業務架構師可以代表業務人員進入項目組（在長期駐紮業務部門的情況下，業務架構師即便不能完全代替業務人員，也可以減少對業務人員的需要量），與開發團隊共同工作一段時間；項目組產生業務架構師不能“擺平”的協調問題時，提交給企業架構進行溝通，必要的時候進行仲裁。這種機制下，一是要保證業務架構師的數量，不能每個部門一個，那樣是做不過來也做不到位的，要有“替補”；二是要保證業務架構師每隔一至兩年左右進行部門間的輪崗，業務人員不能輕易換部門，但是業務架構師則要保持一定的流動性，以促進企業級理念的生長，架構師要有替補也是爲了加強輪換能力。業務架構師與企業架構之間要有定期的工作交流，以增強業務架構師對企業級的把握和企業架構對業務前端的理解。在工作過程中時刻注意使用模型工具分解需求，通過模型工具把控企業級設計。
“打江山容易，坐江山難”，做企業級項目無論過程多痛苦，咬咬牙也是能堅持過去的，但是企業級理念的長期保持和應用則是更爲困難的事情，需求管理機制對非科技類企業而言，很難說是企業的工作重心，儘管大家科技意識已經普遍提高。然而，恰恰這麼一個非重心工作，卻是檢驗企業級理念應用、保持和維護機制的關鍵，說的嚴重點兒，企業級項目的建成其實就是其崩壞的開始，而崩壞就是由一個一個看似微不足道的需求形成的，“千里之堤潰於蟻穴”。
再說說想學中臺的同學們，你們的企業考慮過以一個什麼樣的機制去管理需求、維護中臺架構嗎？這件事只靠技術同學就可以搞定嗎？實現了中臺就達到了快速響應、達到了業務與技術深度融合嗎？很多傳統企業儘管在努力轉型，但是技術人員仍然是“少數派”，比不得那些互聯網企業，動輒技術人員佔比超過50-60%，對於這些互聯網企業，技術也是業務，但也時常聽到這些企業的技術人員抱怨業務與技術之間的互不理解，那就更不用說傳統企業了，如果不從企業級業務架構入手、不從戰略入手，把業務整體拉入到開發機制當中，那作爲“少數派”的技術同學又如何能規範得了一個“中臺”呢？
相關文章：
中臺之上（一）：重視業務架構，不要讓“業務的歸業務、技術的歸技術”
中臺之上（二）：爲什麼業務架構存在 20 多年，技術人員還覺得它有點虛？
中臺之上（三）：戰略和組織結構，業務架構設計中不應被忽視的關鍵因素
中臺之上（四）：面對複雜的流程和數據，我們總結出了一個分析套路
中臺之上（五）：業務架構和中臺的難點，都是需要反覆錘鍊出標準模型
中臺之上（六）：如何爲一個商業銀行設計業務架構？
中臺之上（七）：不神祕但很麻煩的業務架構落地過程
中臺之上（八）：企業級業務架構的實現需要不斷溝通和調整
作者介紹：付曉巖，原國有大行資深業務架構師，負責業務架構設計、項目管理，熱衷新技術探索與實踐，具有豐富的銀行業務經驗和企業級項目業務架構設計經驗，曾主導客戶關係、金融市場、同業、資管、養老金等多個領域核心系統的業務架構設計。公衆號：曉談巖說。