在《面向服务的“拦路虎”（上）》中，我们提到有三个几乎毫不相干的领域，在业务和IT之间都采用面向服务的策略。下面我们会继续分析个中因由。　　

　　SOA一个基本的特性是其分布式的特质。SOA的实现必须可扩展，小到几台虚拟机，大到一个网格。每个SOA服务本身就是一个应用，具有它自己的生命周期和部署策略。当我们从业务实际出发进行SOA的设计，你会发现业务服务的数目在一个企业或一个公司部门并不是很大。这个数目很少能够达到一百这个数量级，可能也有几百的情况。然而，如果你的系统运营支持人员不了解SOA的分布式特点，当你丢给支持人员一百个新的应用（而不是一个）时，毫无疑问，他们会当场傻掉！

　　让我在这里引用一下Alexander Johannesen和Steve Jones（他写了第一本关于OASIS SOA RM 标准的书）之间最近的一些讨论：Alexander：“说真的，即使是在那些非常武断的企业中，企业有很大的压力要求更好地处理负载和流量，并且其解决方法并不是更快的CPU，而是分布式”，Steve：“是的，我相信那是因为99% 的IT人员不能处理分布式系统的问题。”

　　这就是系统运营支持部门经常发生的情况：当一个深奥或者逻辑复杂的软件产品发布后需要支持，这个产品存活的概率很小，因为对于支持人员来说那太难了。当组织机构开始实施业务SOA时，系统运营支持部门受到两方面的压力，这些压力来自业务人员的压力和来自技术复杂性的压力。怎么会有人喜欢它呢？

　　实际上，SOA一点也不复杂，它并不需要也没有使用任何鲜为人知或者从没用过的技术，只是独立运行且共享相同的信息资源的服务的数目远远超过了系统运营支持部门人员和技术资源的数目。IT的开发计划没有将系统运营支持的能力放在心上予以足够考虑，于是乎，系统运营支持的不足又反过来制约了SOA的实施。只有你同时投资于开发和产品支持，业务SOA才会取得技术上的成功。如果你投资于系统运营支持，那么系统运营支持部门就会支持你；否则，工作量带来的压力就会压倒这些支持人员，他们将开始“简化”或对SOA产品弄虚作假，从而应付过去。有些产品的失败是由于部署的简化，或者是由于对几十个同时交互的服务缺乏主动的监督，这些失败会伤害到产品的名声，用户会转向其他的选择。这也就是，一个好的产品，如果被过分简化，将走向末路。

　　然而，这些“拦路虎”如果你处理得当，也会变成支持你的力量。相应的管理包括预先的培训和投资开发一些好的工具。诚然，分布式SOA解决方案的监视工具花费不菲，但这些SOA解决方案实现的目标正是我们的业务要求。公司如果不能明白业务如何运作，什么因素影响其有效运作，公司如果缺乏这样的能力却不去发展该能力，公司怎么会向好发展？因此，当你实施SOA解决方案时，大胆地对系统运营支持部分进行必要的投资吧！