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

　　EA處理如下的企業(yè)級問題：

　　通過提供一個整體的業(yè)務(wù)過程藍(lán)圖將業(yè)務(wù)策略連接到IT系統(tǒng)，藍(lán)圖可以映射到架構(gòu)模式、核心服務(wù)和應(yīng)用兼容性等方面。

　　通過維護(hù)一個當(dāng)前的數(shù)據(jù)模式(schemas)、過程流和服務(wù)定義等內(nèi)容的詳細(xì)目錄來改進(jìn)貫穿于整個企業(yè)的一致性

　　通過減少系統(tǒng)間的冗余以及標(biāo)識可以統(tǒng)一的組件和系統(tǒng)來改進(jìn)操作效率

　　確保靈活的IT能力，能夠響應(yīng)技術(shù)廠商以及新的或者增強(qiáng)性的業(yè)務(wù)流程自動化的變化

　　通過維護(hù)IT 組合(portfolio)、當(dāng)前和目標(biāo)架構(gòu)以及遷移路線圖來支持項目成本化和優(yōu)先級劃分

　　為正在進(jìn)行中的操作和系統(tǒng)開發(fā)提供一個穩(wěn)定的、可信賴的基礎(chǔ)設(shè)施平臺和公用服務(wù)

　　敏捷方法關(guān)注于以下觀念：

　　改進(jìn)效率：關(guān)注于近期的問題，僅開發(fā)能夠滿足當(dāng)前需要的的部分，允許以后形成設(shè)計

　　改進(jìn)項目可見的可管理性：關(guān)注于允許任務(wù)的完成能被有效評估的短期的、迭代的開發(fā)周期

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

　　通過建立在持續(xù)重構(gòu)過程上的集成來改進(jìn)(內(nèi)部質(zhì)量的)可維護(hù)性

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

　　通過隱式知識的使用、共享的團(tuán)隊空間以及關(guān)注問題的小的組成部分來改進(jìn)交流效果。

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

　　敏捷迭代提出的使用一到六個周的時間盒來構(gòu)建一個可運(yùn)行的部分系統(tǒng)的要求，很少得到采納。當(dāng)在一個迭代發(fā)生時嘗試EA時，常常會割裂時間盒??在這個周期結(jié)束時并沒有得到可工作的軟件。

　　在一個典型的敏捷項目中，當(dāng)系統(tǒng)的設(shè)計激增時，采用演進(jìn)的設(shè)計、有機(jī)的增量的方式風(fēng)險很大，可能會導(dǎo)致冗余和不同應(yīng)用間的不兼容性。EA組希望引領(lǐng)設(shè)計和推薦的公用基礎(chǔ)設(shè)施組件、數(shù)據(jù)庫模式定義等……

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

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

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

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

　　為了減少冗余并增進(jìn)一致性，EA組會針對如何構(gòu)建應(yīng)用而產(chǎn)出參考架構(gòu)、推薦框架、發(fā)布指南。AM團(tuán)隊將這些決定看做是單個項目的領(lǐng)域，不會由未在”前線“上的人來口述。

　　EA也關(guān)注于企業(yè)內(nèi)不同應(yīng)用的集成。同樣，EA組推薦使用參考架構(gòu)和框架的特定方案。許多的AM團(tuán)隊任務(wù)這些決定的是不成熟的甚至是毫無根據(jù)的。