最后，EA方法通過考慮了將來的設計(例如建立抽象來輕松應變)的方式來應對變更。AM團隊將此方式視為是不成熟的，認為是典型的龐大的預先設計(BDUF)。實踐AM的團隊寧愿遲些使用抽象，通過重構并依賴于自動化測試來允許變更。
報告的標題確實說：“是的，但需要付出努力”，所以仍然還有希望。但需要EA組和AM項目認識到對方有價值的貢獻，并在他們的工作中做出適應性調整。EA組和AM團隊可以相互得到以下收益:
一個AM團隊應該認識到雖然參考架構和框架可能是一個項目級別的BDUF，但在企業中需要重復做，而且耗費好多。如果已經建立好了就沒有理由再發明輪子了。
EA團隊應該保證信息在正確的范圍內以正確的方式可提供。例如，創建的工件應該努力與每個項目創建的工件相關。
EA組應該考慮將客戶和他們的指南視為是一類需求。
每個AM項目的架構應該與架構組進行聯絡
努力將AM項目范圍內的重構變成是企業級的。
應該建立可測試的EA工具
標準的基礎設施和平臺配置
數據模式
服務
參考架構
業務流程模型
EA應該確保企業級的“上下文”應該是隨時間流逝而分段的，以解決AM團隊關于BDUF的質疑。
EA應該與項目的生命周期有關。
信息流應該是雙向通道，當AM團隊在參考架構或者框架的瑕疵或者不足時，他們需要一種執行變更的方式，這個變更也應該有方式返回到EA組。例如，EA的過程應該支持企業服務的增強。
AM團隊可以盡可能去影響企業架構
企業內的測試環境應該增進一致性、重用并啟用集成。AM團隊是編寫測試的專家，他們應該進行均衡。EA工件應該盡可能變得可執行。
InfoQ同報告的兩位作者(Michael Rosen和Jim Watson)就該專題的內容以及導致他們給出的推薦方案的客戶經驗等方面進行了交談。Jim Watson描述了最場景的場景：
一個曾經使用過其中一種但因為缺乏對另一個的使用而失敗了的項目會最大程度擁有使用兩者的經驗。例如，一個重要的文檔處理系統可以使用最好的AM實踐開發出來，但不能協調好系統的EA需要如跨越需求、接口、和操作性問題等。作為選擇，一個采用瀑布方式的項目會準備妥當它的所有的企業架構，但是卻不能向及早的向客戶展現它的價值，或者不能夠通過有意義的迭代來解決風險問題。所以，這些paper都是來自于經驗的，例如：項目是如何因為忽略了其他可行的規程才陷入這種境地的，有效的處理方式是什么等。
一個意義更加深遠的案例可能是在項目啟動時均衡EA和AM。 然而，這其實非常難，很少發生，主要是因為組織性問題，以及誰在過程的哪個部分被涉及的角度。你會看到很多的失敗，例如架構師跟客戶(更慘的是在根本沒有客戶)但沒有開發團隊參與的情況下整理需求，然后開發團隊脫離開架構師進行接管。
Jim Watson和Michael Rosen告訴我們，關于這個專題的范圍，SOA可以被看作是EA的一個實例。因此這里所有相關的問題和解決方案適用于采用了SOA并存在AM團隊的組織(無需驚訝，這與InfoQ上的文章SOA和敏捷：是朋友?還是敵人?相吻合)
EA和AM的交互并不依賴于SOA，但值得注意的是SOA提供了相互的興趣和問題以允許進程一起使用EA和AM。例如，想在一個SOA主導的項目定義真正有用的業務級別的服務可能具有難度，一個缺乏AM開發實踐的由EA主導的SOA會產生許多的SOA shelfware，因為它很難實現或者僅僅定義出不是真正需要的接口。
一個推薦的方案是， 對一個AM團隊而言它被當作架構的一個包含部分，作為每個團隊的成員與EA組進行聯絡。當被要求闡明推薦Architect Reloadus 或是 Architect Oryzus(其定義見Martin Fowler的Who Needs an Architect? )中的哪種架構類型時，Michael Rosen建議哪種也不采用。在大的組織中會擁有重要的EA組，一個典型的IT組可能擁有2000個員工，500個架構性的重大項目，在EA組中只有70個架構師。沒有足夠的架構時可供應因此Architect Oryzus很難應用。Architect Reloadus同樣不能得到應用，因為它們沒有可實施的環境。有效的架構師的使用方式是作為一個單獨的AM團隊的咨詢顧問，這樣，一個來自EA組的架構師就可以發揮效用而不是嵌入到團隊中。
所以，擁有EA組和AM團隊的組織不必要互相容忍，雖然他們擁有共同的目標，他們的缺省操作模式是不與其它成對的并且(成對使用通常會)產生問題。因此這些實踐等對達成企業的戰略目標和交付戰術性的軟件項目非常有用。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
