如果SOA不能虚拟化，它就没有灵活性

　　在硬件和数据中心的级别上实施虚拟化可以产生立竿见影的节省运营成本的回报，可直接节省数百万美元IT成本。

　　然而，当我们把组件或者服务开发任务分配给多个团队的时候，我们经常忘记这些团队仍需要实时访问这个应用程序的其它部分以完成自己的开发和测试目标。所有这些团队之间仍需要高水平的依赖性和相互沟通以提供一个完整的工作流。对于大规模企业系统来说，这给SOA的投资回报提出了严格的限制。

　　有一种方法可以是使用SOV（面向服务的虚拟化）把这两种技术联系起来：模拟应用软件资产行为的策略以及合成制作企业SOA应用程序的组件。不利用SOV的优势，在整个企业范围内最大限度地实现SOA价值是很困难的，如果不是不可能的话。

　　挑战：SOA的障碍

　　企业采用SOA的最佳做法实现商业灵活性和成本的好处。遗憾的是，当SOA应用程序试图通过升级来满足大型企业的现实需求的时候，最佳的SOA架构和治理战略仍很缺乏，即使拥有虚拟的服务器也是如此。出现这种事情有若干原因。

　　共享的系统资源的冲突

　　SOA就是通过把企业系统当作共享的服务提供来发挥企业系统的优势。然而，访问共享的资源问题危害每一个单独的SOA计划。一个主要的ERP系统管理员或者大型计算机管理员可能会对他们在生产中的应用程序采取保护措施，限制开发和测试团队直接访问这个应用程序以避免出现不可预料的问题。

　　此外，即使允许访问，实时的服务经常会受到一个SOA环境中的多个机构需求的限制。当各个团队被迫排队等候访问一个现实的环境以便进行测试和开发的时候，灵活性就受到了影响。在大型企业应用程序中，通过硬件虚拟化本身创建另一个环境的实例成本太高，是不允许的。

　　不连贯的开发和整合生命周期

　　开发人员需要把服务接口做成一个占位符模型以便确定他们的服务如何与其它服务互操作。例如，一个开发团队正在扩建用户数据，而第二个开发团队正在创建账户数据。由于这些应用程序是并行开发的，这两个团对需要相互依赖对方的服务。每一个团队都需要依靠访问接近完成或者已经实施的服务来证明他们自己的服务能够正确地互操作。

　　SOA通过把松散耦合的组件当作服务来实现灵活性。因此，更小的和更分散的团队能够并行开发和集成这些服务。当仍然存在依赖性的时候，我们如何才能达到这种并行开发的水平呢？看一下这个典型的项目计划或者甘特进度表。在下一个开发团队继续开发下一个组件的之前，肯行会遇到一个项目中可用组件的下一个“依赖性”。这正是我们希望用SOA打破的一个模式。

　　增加的复杂性和异质性

　　虽然许多做SOA的计划都是以Web服务（WSDL/SOAP）为中心的，但是，在最佳的企业实施的SOA计划中只有大约50%是基于Web服务的。有多种技术可以用来创建SOA中间件软件。这些SOA中间件软件也许是非常合法的，对于一个指定的机构来说也许比一个Web服务栈更好，例如使用一个几乎不依赖Web服务的企业服务总线。要保证SOA的质量，各个团队需要验证实施状况和对各种不同技术产生的副作用，而不仅仅测试自己选择的Web服务或者中间件软件层。