早在1987年，從Zachman先生提出企業架構的開端——“Zachman框架”開始，B端軟件開發就開始關注企業的全景信息，而非僅僅是瑣碎的需求，這也意味着，只有開發人員更好地瞭解了企業整體，纔有可能讓B端軟件成爲提升企業整體管理能力、創新能力的武器。
但是，企業架構一路起起伏伏的發展讓人反思一個問題：開發人員如何才能更好地瞭解企業整體？顯然信息只能從業務人員那裏來。如何更有效地獲得這些信息？除了筆者經常談的企業級業務架構外，另一個答案很可能會出乎意料——應該先努力讓業務人員瞭解開發。
獲得信息的有效途徑當然是交流和溝通，業務制度、流程圖這些都是“死”的，“活”的信息只能來自於不同層級的業務人員，而有效的交流溝通並非單向的，不是業務人員單純向技術人員“傾述”，如同兩個人交往一樣，越是互相深入瞭解，溝通才能越有效率。面對日益膨脹的軟件需求，技術人員需要向業務人員普及下到底什麼是軟件開發，軟件開發關注什麼，也許只有業務人員瞭解了軟件開發關注什麼，才能更好地解釋業務關注的點和技術關注的點是什麼關係。
“技術的歸技術，業務的歸業務”，這種涇渭分明的思想要不得。時代在發展，數字化時代需要勞動者技能發生改變，結構化思維是數字化時代很重要的業務思維方式，而數字化產品也是數字化時代最主流的產品，軟件將是最主要的生產工具，無論從以上那個角度講，技術人員都有義務幫助業務人員更好地理解軟件開發，以提升溝通效率，業務人員也應當更加積極主動地瞭解這些知識，從而推動業務思維的轉變。打破理解的鴻溝，業務與技術纔有深度的融合，而兩者之間的差距也許沒有大家想想的那麼大。
一、軟件也是一種“業務”
（一）軟件過程與業務過程的相似性
軟件開發關注的核心問題主要是過程與設計，也就是軟件工程和軟件設計，前者關注的是軟件的生產過程，後者關注的是軟件的設計方法，其實這兩個核心問題在思維模式、工作套路上與業務人員的工作也是很相似的，完全可以很好地解釋給業務人員聽。軟件開發關注的主要問題如下圖所示：
圖1 軟件開發關注的問題
軟件過程主要是從工程管理的角度研究軟件生產過程的工序、標準，按什麼樣的方式和順序組織生產，每個生產環節該達到什麼樣的標準，這樣做的核心目的是爲了提高軟件的質量，減少BUG，也是爲了儘可能通過科學地安排工序，縮短軟件開發時間，從而提高產量。
技術人員對軟件過程的關注其實與業務人員對業務過程的關注沒有什麼本質區別。業務人員推出一個新業務產品時，也要關注產品的全生命週期管理，從需求收集、市場調研到產品設計、內部審批，再到試運行或者上市，之後關注運營、客服，這也是一個基於工序和標準的管理；業務人員也經常研究如何優化內部流程加速產品上市，如同技術人員研究工程模型一樣；業務人員對業務的關注也集中在產品質量上，不違規、不給客戶帶來困擾；最後，業務人員對產品流程的優化也包含着讓客戶在更短的時間、更好的體驗中快速獲得產品，也就是對產量的關注。並非由於技術人員生產的是軟件，二者就搞出了多大的底層思維的差別。
（二）軟件設計與業務產品設計的相似性
軟件開發中關注的另一個問題是軟件設計，設計中最重要的部分是架構設計，架構設計關注的核心是結構和關係，如何劃分模塊、組件、服務，各部分之間又是一種什麼樣的關係。
清晰架構的目的一是爲了更好地復現，目前大部分軟件開發的需求還是來自業務，是對業務需求的復現，無論你寫沒寫需求文檔，這個本質是不變的。所以，理清了業務的結構、應用的結構，才能保證復現的正確性，也就是確保軟件的質量。目的之二是爲了更好地實現複用，清晰、統一的架構定義，有助於識別已有的業務能力、軟件資產是否可以被複用，複用有助於解決產量問題，也就是縮短開發週期，而已經被使用過的軟件資產往往經歷過檢驗，也有助於保證新應用的質量。
其實軟件設計與業務人員搞產品設計關注的東西也沒有很大差異，業務人員做產品設計時一樣要考慮產品的構成，產品中包含什麼內容，比如銀行產品中申請的環節、審批的環節、放款的環節，不同的環節之間是什麼關係；如何更好地復現、迎合客戶需求；以往的業務經驗、業務規則能不能用在新產品設計上，如果能用那自然產品設計的效率也會提高。所以，二者思維模式接近，如何更好地幫助業務人員在設計產品時進行結構化的思考，就會讓業務和技術的關係更近一步。
（三）“樂高積木”的局怎麼破？
隨着軟件需求量的激增，現在到了需要需求側能力提升的時候了，技術端無論如何改進自身，如果需求端沒有相應的改進，那麼，軟件開發效能的上升始終是有限的。比如，談論近30餘年的“樂高積木”式構件化設計遲遲未見好的實現，是不是與需求側的結構化程度嚴重不足有關呢？需求側的結構化思維中，是不是也需要對軟件開發的關注點多瞭解一些呢？
“樂高積木”問題其實也就是服務的顆粒度問題，服務的顆粒度與業務管理上經常處理的分工問題是不是高度相似呢？給小張同學安排1件事情好還是5件事情好？如果有100件不同的事情，是安排給100個小張同學好還是安排給20個小張同學好？這個問題對業務人員和技術人員的困擾是一樣的，並非是一個有着極大專業界限的問題。
“樂高積木”最終是要支持業務人員的需求變化，那服務的切分到底是技術人員自己的事情，還是也需要業務人員的參與呢？我們目前在B端軟件上經常會以雙方關注點的分離來解釋現有的軟件研發分工，但是，面向數字化轉型，這個分工該適當改進一下了，新的時代需要新的生產方式，不然，“樂高積木”這個局可能就無解了。
二、軟件過程是業務人員學習技術知識的基礎
現在科技發展速度越來越快、應用越來越普及，用技術改變業務模式的呼籲也越來越強烈，所以很多業務人員也對技術發生了濃厚的興趣，人工智能、區塊鏈、大數據、雲計算也都成了業務人員的案前書。但是很多業務人員都忽略了對軟件工程、系統設計、業務架構這些基礎性內容的瞭解，經常直接撞上了技術領域中“不講人話”的部分。
這些“不講人話”的內容，比如人工智能中的各種算法、區塊鏈中的哈希與共識等等，這裏邊的內容很多是技術人員自己都說不太清楚，靠封裝好的函數、模塊進行調用的，業務人員在此花費精力很不值當。而再“牛”的新技術，也是要經過軟件工程中的辛苦勞動才能轉化爲應用，所以，在關注這些新技術之前，先了解軟件工程和系統設計原理，反倒可以更好地思考這些新技術的落地方式。
軟件設計的架構知識中確實有不適合業務人員學習的技術理論部分，但是就整體模塊的設計與劃分而言，是業務和技術可以溝通的部分，也是必須要溝通的部分，通過雙方對軟件工程、業務架構、應用架構的共同理解，可以打破雙方在理念上人爲設置的“鴻溝”，更好地促進雙方融合，只有強化了這些底層的融合，纔可能讓戰略層面、企業層面的業技融合真正得以實現。
作者簡介：
付曉巖，新書《銀行數字化轉型》剛剛面市，受到熱議。另著有《企業級業務架構設計：方法論與實踐》一書，對企業級業務架構設計、企業數字化轉型、金融科技發展有持續的研究和深厚的實踐積累，現就職於建信金融科技有限責任公司。公衆號：曉談巖說。