“…… 模型潜在地处于被误导、及无知冠以其一个纯粹代表产品特征的破旧称号的危险之中。毕竟，这或多或少发生在EAI上。可能暗杀SOA的势力包括：集成平台厂商，企业架构师，特定行业分析家及CIO们。”

　　考虑到这些，来自ZapThink的最新文章试图全面的看待这些事情。
　　“任何要求执行者和从业者的时间和预算占重要部分的动向都需要被严格检查，这样所有团体的利益都得到满足。毕竟，极少有人能从满是宣传而没有实质内容的动向中受益。”

　　按照分析师的说法，SOA失败的高发原因是不当使用。公司试图在业务案例不合理的时候就在企业内全面使用SOA，“不能一刀切(one size does not fit all)”显然可作为对这一陷阱的精确总结。

　　“基本原理表明SOA是企业级架构的一个方面，因此它的范围是企业级的，或者因为它如此重要且具战略性，它必须在企业级被实现。其他IT从业者只是习惯于实现他们的主要企业目标，那为什么SOA应该不同？因为SOA不是一个项目或一个技术——它是一种方法，这就是为什么。”

　　SOA不能适合所有问题，决定在何时何地(如果要用)应用SOA原则应该总是尝试使用SOA的第一步。不当使用(或过度使用)一个技术、方法论等等，经常导致其在我们的行业中衰败：

　　“当公司针对一个业务案例(不合理地使用了上百万美元的未测试技术)企图实现成百个未经证实的服务时，他们失败风险的非常大。当那些SOA项目没有按期交付，他们会谴责自己的努力、他们所用的产品、或他们的方法吗？当然不会。他们会把指责留给SOA本身” ，至于作者所关心的：
　　“另一方面，合理限制范围的(well-scoped)SOA项目经常会取得显著的成功。大多数SOA成功的个案涉及到组织着眼于特定的业务问题，多半只是在部门级，使用面向服务的方式去解决它。SOA的拥护者非常了解，成功来自关注特定问题的解决方案并很好的解决它。”

　　文章接下来给企业架构团队用举了一个应用SOA原则最好方法的案例，因为很少有人既懂业务，又具有必备理解SOA最佳实践如何可以推动业务解决方案发展的技术头脑。构建包括如排列典型业务、应用程序开发、数据模型、过程模型、安全以及网络操作角色的功能交叉团队是SOA开发成功的关键要素。

　　还有很强的教育需求需要贯穿组织：

　　“业务上可以看到解决方案的地方，有时IT看不到。太多次IT部门试图使用SOA锤子将每个问题作为钉子解决。实际上，没有合理限制范围(ill-scoped)的SOA项目的症状部分源于能力不足(或缺乏经验)去正确地使用SOA。……技术专家陷入捍卫与特定技术方法(REST 对比 Web Services 哪一个好？)有关的立场。这些争论根本与手头的业务问题关系甚微，如果有的话也非常少，并退化为书生气十足的语义学争论。事实上任何能够解决业务问题的技术方法都是有效的，而且不管怎样，在若干年后这些技术可能将被更好的技术所代替。”

　　然而，文章结束时给那些注意到要基于SOA原则部署应用或怀疑自己在继续进行现有部署方面是否有正确的技巧的人们一些中听的建议：

　　“寻求应用SOA去解决他们问题的聪明的架构师和业务管理者们应当被牢牢把握什么时候SOA将取得成功、什么时候是不恰当的。这种把握能力包括对于人员、技术、过程、现有环境的方法、已提议解决方案以及任何潜在解决方案缺陷的现实估价。持有这么一种兼顾均衡的办法为SOA进一步成功提供了可能性，决不会毁灭SOA本身的价值。