最后，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团队的组织不必要互相容忍，虽然他们拥有共同的目标，他们的缺省操作模式是不与其它成对的并且(成对使用通常会)产生问题。因此这些实践等对达成企业的战略目标和交付战术性的软件项目非常有用。
文章来源于领测软件测试网 https://www.ltesting.net/
