業務架構中間件與輔助開發平臺的差異

在整個軟件開發項目的過程中，都要經歷在軟件需求分析、系統設計、系統實現的過程，即使我們採用了組件化的開發、面向對象的設計，還是會發現，分析設計人員、程序員和用戶之間，仍然無法溝通的很好，應用系統在交付用戶使用時，仍然離用戶的真實意圖比較遠。這是因爲，提出需求的用戶和系統設計的技術人員看問題的角度不同。
用戶是從業務的角度，提出應用軟件是哪個職能範圍的、有哪些應用模塊、每個模塊又有哪些子模塊，這是一種基於“業務對象”的描述方法。而開發人員則是從技術的角度，架構是什麼？數據庫的結構是什麼樣的？表間關係是什麼？業務邏輯如何編寫？頁面展現如何設計？這是傳統的“組件”或“構件”思路。所以，用戶和開發人員之間溝通起來仍然很難，業務實現及業務調整都依然爲軟件開發項目帶來很大的難度和不可控因素。
而對應與應用系統實現，軟件開發平臺爲了解決這些問題，經歷了語言級開發到輔助開發平臺的升級，直到我們所提供的面向業務架構的中間件平臺。
而輔助開發平臺源自與語言級軟件開發環境，是從軟件項目框架和程序開發過程各環節的開發效率上增加了許多特色的工具，從而爲開發團隊、開發者提供了更爲高效的開發工具和項目控制與組織管理的手段，最終爲整個項目降低了開發成本，提高了開發效率，但這並未真正意義上解決上面的問題。
例如：基於軟件輔助開發平臺，我們依然遵循需求分析，數據庫建模，業務邏輯建模，頁面設計，調試跟蹤，測試，發佈等過程，但是在每個節點上輔助開發工具都會提供相應廠商所特有的“可視化工具”以減低過程的操作難度，提升開發效率。
我們從軟件系統開發實現的過程來看，開發人員會按照調研的需求分析報告，按照數據庫建模，業務邏輯建模，頁面設計的過程對業務需求進行分層的計算機語言轉化，然後再將業務邏輯與物理數據庫、展現頁面與業務邏輯之間建立映射關係，之後在開始跟蹤調試，最終發佈應用程序。在這整個過程中程序員會利用輔助開發平臺的“可視化工具”進行配置和關聯，去自動生成系統的70%-80%的代碼，複雜業務邏輯仍需手工代碼編寫實現。這對開發人員來說確實減低了很大的開發工作量，具體體現在開發過程中的普遍性及通用性的工作量，細節性的複雜業務邏輯處理難度和工作量並沒有得到改善，這大概會佔20%-30%的代碼量。
但是軟件系統的並不是一成不變的，隨着業務需求的升級，軟件系統功能及業務處理必須進行同步的更新，例如數據結構上需要增加一個字段，這時就會涉及物理數據庫的調整，也會涉及業務邏輯的調整和頁面展現的調整等等，當然也包括各層面的映射關係的調整。這時不管是哪個方面的調整都會影響其他層面的設計，而且既可能是通過“可視化工具”自動生成的代碼部分，也可能是自定義的代碼部分，而這種雖然只是系統從1.0到1.01的升級，都需要我們調整這0.1的升級部分所涉及的三層調整，以此看來並不是20%和80%的關係了，而是100%的調整。
而面向業務結構的中間件平臺又是如何解決上述問題的呢？
業務架構平臺是以業務對象建模爲核心的業務中間件及其集成開發工具。在它的支持下，應用軟件徹底實現“業務驅動導向”的軟件開發模式，並實現“應您所需，隨時而變”的應用系統。基於業務中間件平臺，開發者只需要基於業務和管理的層面，而非技術的層面來理解、設計、構架和集成企業的信息系統（基於業務層面是指開發人員只需描述企業的組織機構、業務流程、業務信息、業務資源、業務邏輯、業務事件等業務內容，而不考慮技術層面的東西），就可以實現各類基於WEB的高層次的信息化應用。而且，用戶可以隨時在運行中重新定義或調整業務模型，從而達到使自己的信息系統完全貼近不斷變化的業務需求，這也是“靈動”的價值體現。
在這樣的平臺裏，開發者所關注的就是“業務模型”，在集成開發環境中通過對“業務對象（BO）”的分析來設計描述模型，而“業務模型”的處理流程通過“業務流程（BP）”來描述業務對象的邏輯關係，業務模型提交至中間件服務器後自動會生成標準應用系統的三層架構，自動建立關聯映射關係。當業務對象調整時，只需要修正業務模型重新提交至服務器，服務器又自動修正應用系統中的每個層面，關聯映射關係會自動關聯。
通過以上我們可以看出，隨着兩大主流語言開發工具的發展，輔助開發平臺的生存空間將會不斷縮小，這主要源自各種輔助開發平臺的初衷只是語言級開發工具的補充，事實上這是一廂情願的做法，從計算機語言的發展趨勢來看，它將是主流的語言開發工具的過度品，這種現象在微軟.net架構的VS上已經有了較大的體現。而且我們通過對各種輔助開發平臺的對比可以看出，其核心的差異主要體現爲：一方面業務邏輯分解上的顆粒度粗細不同，組件、構件、服務……；另一方面所提供的工具的便捷性不同，可視化、圖形化、嚮導模式、拖拽模式……；而這些“差異特色”都將會在主流語言的開發工具的逐步體現。
而業務架構平臺則是在開發工具之上的業務模型描述工具，它與開發工具之間是分工關係，可以基於.net也可以基於J2EE，而且他會隨着開發語言的發展而越來越強大，畢竟業務模型的建立永遠是在系統開發設計實現之前。