一份來自Cutter Consortium的報告向我們提出了這樣一個問題：“敏捷方法和企業架構兼容嗎?”并且也給出了這樣一個答案：“是的，但需要付出努力”。該報告的作者推薦運用特殊技巧以允許敏捷方法和企業架構互相受益。此外，他們的觀察結果、分析和建議也直接是適用于敏捷方法和“面向服務的架構SOA”之間的結合。
　　企業架構(EA)和敏捷方法(AM)擁有共同的目標??交付能夠跟業務需要對齊的軟件，并響應對這些業務需要無可避免的變更。然而，EA和AM在達成這個目標時卻采用了截然不同的方式。在報告中，對EA和AM定義如下：

　　EA處理如下的企業級問題：

　　通過提供一個整體的業務過程藍圖將業務策略連接到IT系統，藍圖可以映射到架構模式、核心服務和應用兼容性等方面。

　　通過維護一個當前的數據模式(schemas)、過程流和服務定義等內容的詳細目錄來改進貫穿于整個企業的一致性

　　通過減少系統間的冗余以及標識可以統一的組件和系統來改進操作效率

　　確保靈活的IT能力，能夠響應技術廠商以及新的或者增強性的業務流程自動化的變化

　　通過維護IT 組合(portfolio)、當前和目標架構以及遷移路線圖來支持項目成本化和優先級劃分

　　為正在進行中的操作和系統開發提供一個穩定的、可信賴的基礎設施平臺和公用服務

　　敏捷方法關注于以下觀念：

　　改進效率：關注于近期的問題，僅開發能夠滿足當前需要的的部分，允許以后形成設計

　　改進項目可見的可管理性：關注于允許任務的完成能被有效評估的短期的、迭代的開發周期

　　通過提供一個完整的過程，關注于廣泛的自動化測試、盡可能早并且經常解決集成問題、允許多個(缺少豐富經驗的)開發人員在共同的代碼上開展工作以及從終用戶處得到持續反饋等方式來改進質量。

　　通過建立在持續重構過程上的集成來改進(內部質量的)可維護性

　　改進處理變更的能力：它是一個需求變更、一個澄清、一個新的需要優先處理的特性?通過綜合客戶反饋計劃迭代內容。

　　通過隱式知識的使用、共享的團隊空間以及關注問題的小的組成部分來改進交流效果。

　　我們會先從EA的視角來檢驗AM然后反過來檢驗以分析EA和AM之間的鴻溝。從EA的視角來看：

　　敏捷迭代提出的使用一到六個周的時間盒來構建一個可運行的部分系統的要求，很少得到采納。當在一個迭代發生時嘗試EA時，常常會割裂時間盒??在這個周期結束時并沒有得到可工作的軟件。

　　在一個典型的敏捷項目中，當系統的設計激增時，采用演進的設計、有機的增量的方式風險很大，可能會導致冗余和不同應用間的不兼容性。EA組希望引領設計和推薦的公用基礎設施組件、數據庫模式定義等……

　　敏捷非常依賴于可執行的的工件，例如：編寫好的測試(不管是單元測試還是系統測試)。EA的工件不是可以測試的。它們限制了項目的影響范圍，因為他們沒有反饋環??當沒有遵照設計時，不會給出警告。

　　敏捷提倡的客戶作為團隊成員是不能被承認的。EA組中不會存在任何一個客戶，但是它有一個從IT到運營到開發團隊到終用戶的間接的大型的廣泛客戶群。

　　從AM的視角看，EA也不是非常有意義的：

　　EA關注于對齊IT系統和業務策略。一個映射了從現在到將來系統的計劃被開發出來，然后落到一個獨立的項目中。使用了AM的團隊可能會使用此類文檔中的信息，但當這些文檔到達團隊時它們已經失去了上下文環境，會變得難以理解。而且，文檔是可測試的。不能接觸現實狀況，這也是EA團隊被視作“象牙塔”架構的一個主要原因。

　　為了減少冗余并增進一致性，EA組會針對如何構建應用而產出參考架構、推薦框架、發布指南。AM團隊將這些決定看做是單個項目的領域，不會由未在”前線“上的人來口述。

　　EA也關注于企業內不同應用的集成。同樣，EA組推薦使用參考架構和框架的特定方案。許多的AM團隊任務這些決定的是不成熟的甚至是毫無根據的。