1.你不能出售SOA。SOA可以使公司更灵活。SOA可以使公司更机敏。是的，如果没有适应性和机敏性是不能建立业务解决案例或形成正当成本，你只能以解决业务问题为基础来构建SOA。在应当的环境中SOA可以使业务方案解决业务问题:这就足够了。
2.就算你可以出售SOA你也不能这么做，因为你不能向商人描述SOA到底是什么。事实上也没有SOA的确切定义。即使作为一个概念SOA也是脆弱的，不同的软件提供商和分析师会给出不同的(大量的)SOA定义。所以就连IT行业都没有统一的定义，你怎么能够期望商家可以理解这一概念?最好就是说SOA是代表一系列有效的技术。
3.业务流程管理(Business Process Management ，BPM)不是SOA。两者并非必须共存的，当然，虽然没有BPM的SOA可能会很灵活。
4.业务流程管理(Business Process Management ，BPM)处理引擎将成为SOA的潜在瓶颈。如果每一件事都是围绕BPM套件布署，那么服务就不得不回到BPM处理引擎来接收指令，这样一来BPM处理引擎就变成了SOA的瓶颈。所以，你可能需要有多个这样的引擎以及一个“协调引擎的引擎”，就好比一个管弦乐队。更好的方法就是拥有智能、恰当的服务，可以明白自己的路由，保存状态信息:因此减少了对引擎的调用。
5.总之，仅有业务流程管理(Business Process Management ，BPM)是不够的。BPM可以处理相对简单的流程，但是当环境非常复杂时，尤其是业务不可掌控时，BPM则不能发挥作用。这就需要复杂事件处理((complex) event processing ,CEP)来协调。
6.在SOA领域，大多数软件提供商都承认事件处理的潜在角色，但是大家都不理解这一角色的具体含义。例如，我曾见过在SOA中将复杂事件处理(complex event processing ,CEP)与BI型事件处理混淆不清的现象。当然，SOA中应有相应的CEP区块(例如，生产监控而不是业务活动监控(BAM-Business Activity Monitoring)的实例监控――尽管应该将两者结合起来)。Oracle公司明白事件处理，它将复杂事件处理CEP分配在SOA成熟模型的第五层:这样很好，除非复杂事件处理CEP可以完全独立与SOA单独实施。
7.你不需要使用简单对象访问协议(simple object access protocol ，SOAP)。有趣的是该协议并不像大家期望的那样简单――有其他更为简单的协议。
8.SOA面向服务体系结构的一个最大优势就是能够帮助企业重组应用程序，再利用服务。但是怎么再利用呢?我们不能对对象进行再利用，同时我们也不能对组件进行再利用，所以为什么我们认为我们可以对服务进行再利用呢?这是因为我们可以建立SOA管治、执行IT策略与标准，可是这样就意味着开发人员将会严格执行策略吗?什么时候有这样的压力?什么时候规定这项工作必须在明天之前完成?
9.讨论一下管治，怎样进行管治?――SOA与数据管治(data governance)之间的关系是怎样的，举例说明?如果管治的目的之一是为了对进程和数据建立所有权，那么就会出现一个问题，因为所有权就意味着责任，如果有一点点机会，人们就会逃避责任。为管治打造的理论模型都非常优秀，不过如果这些理论模型不能被应用于实际(至少有时可以应用于实际)，那么我们就需要一组更注重实效的“我们可以实际作到”的方案，而不是总是以理想状态为目标。
10.大多数讨论SOA的软件提供商都忽略了数据这一块(这里，IBM是一个例外)，许多公司的应用程序架构就像一团纠结在一起的面条，可是如果说SOA的作用就是解开、理清过去纠结在一起的面条，那么复杂的数据环境不也一样吗?
文章来源于领测软件测试网 https://www.ltesting.net/
