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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　我們會(huì)先從EA的視角來(lái)檢驗(yàn)AM然后反過(guò)來(lái)檢驗(yàn)以分析EA和AM之間的鴻溝。從EA的視角來(lái)看：

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

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

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

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

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

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

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

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