面向服务架构使用的太多了，所以来自于产品公司的热心销售与组织内过分使用的SOA应用的结合给人们造成了一个错误的幻像，那就是SOA可以解决所有问题。SOA是企业服务，展示整个企业的功能，这些都很难处理。在那里SOA仍然适用，但必须在更好的水平使用，而且要放在架构和集成及服务的适当位置上。
组织将会对一项技术进行投资，然后使用这一技术解决所有问题，这很常见。因此，人们在那些并不适合的地方使用过或将要使用SOA。然后他们就会发现它并不适合，就会指责它，说SOA并不是一项好的技术，因为它不能解决这一问题。同样，人们将会以不合适的方式使用企业服务总线。
SOA可以用于解决大型系统中艰难的集成问题，在你需要定义接口的地方，尤其是在那些不同的组织或组织上的不同部门之间要定义的接口；以及在组织的不同部分之间你需要明确责任和定义合同。
今天SOA还是可行的，因为它还有许多不同的方式。那些在SOA和企业服务总线保护伞之下的技术是如此的不同。
对于SOA技能，在我的工作中，我看到架构同师们在处理非功能性（如性能、扩展性、总体稳定性以及应用程序处理用户负载的能力）问题上，技能有点弱。我的建议是，他们最好是根据用户的数量和响应时间，了解一下业务的实际需求。
我认为在过去的5至10年中，SOA技能已经被束之高阁了，这是因为功能驱动的开发方法的流行度正日益增长。新焦点已经集中在了把功能集成于应用中、测试单一用户的工作环境，然后是签署完成。因为精力集中在这些焦点上，协作、实现和非功能性需求测试常常会失败。
架构师们常常忽略的是因为可能会工作的很，以及对于小量数据和用户功能已经很完备。然而，他们常常不会在大环境中测试这些。所以，当用户在大环境中使用它时，他们就会发现这一应用根本就不工作，因为架构不合适或他们又做错了一个决定。
像AJAX这样的技术使用有点过度，对于页面你可以做一些地的，快速的异步事情。如果你的网站有一些用户那么就会更好了；但当你有了10，000个用户，所有这些用户都在一秒钟内发送他们的请求，来更新屏幕上的MessageBox，那么后端服务器的处理对这一负载的处理就会很难。
在这种情况下，为了解决非功能性需求，并正确收集需求，而建立SOA技能是很重要的一件事。从功能的焦点上转移。学习如此关注那些需要解决的业务问题。这是一种使架构更好的工作，更有价值的工作的一种方法。
