整体企业IT架构的时代已结束了一段时间，现在只关于如何选择正确的灵活的技术策略的时代。你尝试SOA的实施了吗？你是否采用内部应用程序开发的敏捷方法？还是你挑战大家的想象力，把两个创造成邪恶的结合，变成了“敏捷的SOA？”

　　虽然开发与架构营地似乎相距甚远，敏捷SOA的出现似乎并不是巫术。双方有相同的终极目标：使企业能够快速变动。 SOA可以提供一个灵活的架构，使IT支持业务做出更灵活变化，而敏捷方法可以实现更快的软件开发和部署。敏捷方法和技巧远远超出建立业务应用。他们还从高度复杂的、高风险和疯狂昂贵的部署演变成大家认为是好东西的SOA架构和组件。

　　敏捷技术和战略的目的是在不牺牲功能或灵活性的条件下提高灵活性，管理风险和减少成本。但是，SOA为了适应敏捷方法，需要对架构通过合并的方法，极端一点，但对于了解敏捷的价值得人非常合理。

　　SOA比IT倡议更多内容。应当由业务推动、合理化和执行，需要密切合作，就像任何业务联合企业。这种IT与业务之间在超大合作是敏捷方法的基本原理。架构师应坚定自己的想法，但是，作为企业，由市场力量推动，希望现在改变。但是，SOA需要前期的深思熟虑的工作。为改变 “现在”，也就是要求为什么SOA的实施需要在同一时间开展战略和战术的原因所在。

　　从战略上讲，第一次部署的时候，对于一些地方的基础设施数量和什么是应用程序，你需要一张路线图。只不过开始收获SOA的好处之前，你要了解应实行多少基础设施？如果SOA的好处只能通过部署应用程序使用，它的临界点是什么？

　　为了达到这个临界点，你需要为SOA服务建立最低的基础，特别是服务，不是由执行业务驱动的体系结构模式。这些基础设施服务，如安全、消息和接口。这个基础决定了应付业务的变化和重构迈向成熟SOA的企业应用的能力。

　　但最低的基础应该是什么？敏捷开发作为指南的两个核心原则：特别精简（即仅创建所需）和增量开发（只在需要时创建）。首先，看看最初利用SOA基础设施的应用。几乎每一个实例都需要认证和授权，因此必须建立这些服务（如果尚未提供）。但如果应用只需要Web服务，然后保持精简，只有建立一个Web服务的基础，就没有必要建立了，例如，JMS或CORBA的接口。

　　同样，需要治理应当基于应用，使这些程序和控制可被测试并证明，按需逐步建设治理。这可以节省时间、精力和较早实现好处，让SOA战略为自己付出的长远目标。