当企业规划一个SOA项目以推动用户价值并充分利用语音通信基础设施时，面临的一个主要挑战是他们缺少拥有合适的SOA技能的架构师。事实上，在很多企业中，人们对软件架构规则仍然误解很深。与此同时，目前架构专业分为好多种类型，大多数架构师只精通其中一两门专业。要成为面向服务的架构师，首先要对于企业架构有清除的了解，其次还要熟悉技术架构、信息架构、业务流程架构和数据架构。要找到具备所有这些技能的人无异于大海捞针。

　　部署中型SOA项目同样需要技能熟练的架构师，但这些架构师的经验深度不必与那些规划重量级SOA工程的架构师相同。事实上。事实上，在完成几个中型SOA部署后，你的架构师就会变得逐渐程序，并且他们的SOA技能也在不断提高，这为将来他们能够胜任重量级SOA项目的部署工作打下了良好的基础。

　　开发人员和架构挑战

　　SOA给整个IT机构都提出了技能挑战，而不仅仅是架构师团队。特别是，SOA–就像其它任何架构一样，给应用开发团队带来了很多困难。毕竟，开发人员都是有创造性的精英，他们喜欢自由自在，不欣赏太多的结构。然而，作为一种架构，SOA给开发人员带来了太多地限制。

　　重量级SOA的部署可能涉及到很大的团队进行参与，并且责任分工很广泛，而中型SOA项目一般都是由规模较小、比较灵活的开发团队完成的，在部署过程中，架构师可直接与开发人员、测试人员和其它日常工作人员直接打交道。此外，如果企业能够利用可以支持如此广泛专业的工具，那么，这样的一个以团队为基础工具可以缓解许多架构师和开发人员之间的矛盾。

　　其实上，这些冲突往往归结为SOA治理（governance）问题–当开发人员在创建、发布、发现以及重用服务时，应该使用什么策略，谁负责制定和执行这些政策。中型SOA工具因此应该还具备对于这种治理能力的支持，从而使得应用程序开发团队与架构师可以一起参与策略的制定和执行，而不是仅仅让架构师负责制定这些策略，这种做法是不切实际的，通常会引起开发人员的抵制。

　　过程专家和技术实施的挑战

　　SOA提出的挑战超越了应用开发团队的范围。事实上，商业分析家和其他业务流程专家也必须应对SOA提出的挑战。毕竟，为了实现灵活性，业务流程必须保留其商业背景。然而，大多数情况下，技术上的细节占据了上风。如果代表商业发展路线的商业分析师无法有效地与架构师以及应用开发团队进行交流，那么，服务所需要的这个关键性的业务需求背景以及SOBA（面向服务的业务应用），将可能会丢失。

　　中型SOA方法对于简化业务流程的自动化可能极为重要的，尽管底层技术的复杂很高。在一个架构清晰的SOA中，商业服务给业务提供了一个简化的接口。如果业务流程建模环境能够充分利用商业服务，那么业务分析师以及其它业务流程专家就可以有一个创建和配置SOBA的环境，这对于SOA团队很有意义。

　　当然，实施一个中型SOA项目和重量级SOA项目的最主要的区别之一就是成本。项目越大，成本也就越高。成本的限制往往是企业部署中型SOA的主要动力。所以，这种类型的夏木要面对的挑战，一般侧重于利用相对较低的成本实现较大的商业价值—这就是你可能称之为“一美元大收获”型项目。

　　避免SOA中间件陷阱

　　很多重量级软件供应商千方百计想要使你相信要部署SOA,你需要购买大量的中间件–但是，事实上，这是不正确的。“SOA中间件”或“SOA平台”以及其它重量级、以集成为中心（integration-centric）的产品，实际上对于有效的降低SOA部署的成本不会起很大的作用。但即使如此，市场上也有许多成熟的产品，可以对于你成功部署SOA做出真正的贡献，同时还能降低成本。尽管如此，重要的是要记住，目前在市场上你可以买到最好的SOA产品，无论你花钱多少，那都不能代表你拥有了SOA.毕竟“购买最好的工具不会让你成为一个木匠的”.请记住，SOA是由组成一套最佳做法组成的—需要遵循一些规则。

　　因此，在SOA产品的选择中，中型项目的办法与重量级项目、以中间件为中心的方法是有本质上的不同的。在中型SOA项目中，体系结构和业务流程驱动SOA基础设施和工具的选择，而这应该是最好方法，与之相反的是单个大型厂商的推动。SOA基础设施一般依赖于中间件，这是可以肯定的，但是，大部分企业已经有足够多的中间件软件。中型SOA部署对于中间件的使用方法是，充分利用那些已经部署了的中间件，同时还要引入一流的治理、质量、管理以及服务创建和组合工具。

　　利用中型工具

　　重量级和轻量级工具所面临的最大的挑战之一是缺少重视SOA最佳实践。最重量级的工具取决于较早的集成技术。

　　另一方面，轻量级的解决方案，仅仅着眼于服务，而且很少提供架构上的协助。不过，中型解决方案专注于把许多SOA的核心规则同集成工具打包在一起。因此，架构师有可能会充分利用这些工具，并且他们也可以灵活地参与企业SOA和治理项目的措施。