据最近发表的两篇研究报告称，SOA实施没有像SOA厂商希望的那样迅速为人们接受。然而，推迟应用并不是因为技术问题。

　　厂商和解决方案提供商表示，从整合厂商的角度看，这里缺少的主要东西是向用户推销SOA商务流程好处的能力，而不仅仅是技术能力。

　　据SAP负责解决方案营销的副总裁Fergus Griffin说，客户有时候把SOA看作是一个问题的解决方案。这个观点给SAP及其合作伙伴带来了同样的麻烦。客户一般不把SAO列入IP或者业务部门预算。因此，厂商和解决方案提供商需要展示SAO如何能够使他们的商务流程速度更快、更容易使用和更盈利。

　　销售产品厂商

　　我不相信各个在面向服务架构领域的SOA厂商在对外销售其产品的时候会用一种真正客观而且单纯的手段，抛开自身技术产品而真正让客户去达到某种效果，满足需求，相信也不会有人这样觉得。事实上，可能会让我感到吃惊的反而是如果某一个厂商在从自身角度出发时并没有反复强调自身技术的领先，当然，这有可能是他们已经在我之前的书中学到关于如何处理，并从其客户的建议中寻找到了解决方法。

　　就我认为，之所以会出现这么多的厂商一直都只是在吹捧自身技术这种情况的原因只有一个，要么是这些所谓的SOA厂商并不能完美的解释其自身的产品，展现其核心特点，要么则是这些产品如何真正实现SOA等核心问题已经能够得到完美解决。显然，这个原因不会是后者。众多的SOA厂商知道如何列举一些关键词去吸引更多已有的或者将有的客户的关注，让他们惊叹原来还有这样的内容存在。然而，在大部分情况下，这样的后果则是有更多的客户开始混淆，不清楚下一步该如何进行，甚至，并没有得到最为核心的产品，更不要说SOA的有效实施。

　　SOA厂商们需要采取更具资讯式的销售模式。因此，成功的厂商将应该拥有一颗老师而非销售的心。他们应该训练所有的销售人员去了解SOA特性，学习如何听取业务的核心问题，并学着如何找出客户也许并没有告诉你的真实问题所在。例如，我经常听到他们讲述现行的架构式多么的好，但经过更深的分析却发现存在需要指出的重要缺陷，最典型的是现有架构的敏捷度，或是适应业务要求变化的能力等等。

　　主要的一点是所有的一切都是全新的。大多数厂商都只是销售针对某些具体目的的策略性产品，而不是将架构作为商品来贩卖。包括SOA在内的所有架构都是关于技术配置和理解的，而不是技术本身。这对于许多厂商来说是个很大的转变，而我相信绝大多数的厂商在尝试转变其方案的时候都会失败。

　　业务方面的IT技术战略

　　从Comcast公司到美国联合航空，这些大公司不分行业都已经开始纷纷投入到SOA领域之中，他们改变其组织计划、开发和部署企业应用软件以进一步的实现这一领先的IT技术架构理念。

　　SOA在最初发展的时候，目的仅仅只是为了使应用功能可以被作为共享服务来使用，这一点牵引着这个领先的IT架构理念一步一步走到现在。不过，企业从最初开始得SOA道路到现在，都还在建立属于自己的架构体系。相比之下，不同的是在过去几年中，业务方面的需求更好的体现了这一IT技术的战略价值，而IT方面也更多的了解了业务方面需要承受多大的竞争压力。如此一来，SOA就能够提供IT与业务前所未有紧密结合的可能。

　　业务需要的是一组服务：能够重组，得出新业务流程以支持新的产品或服务组件。而SOA的职责所在就是发布这些服务，提供连贯一致的框架，使服务组件能够得到治理并重组为应用。虽然许多SOA的举措仍停留在早期阶段，它对增加业务反应度的承诺还是真是可靠的。我们看到越来越多的企业正推进更为高级的部署。

　　对于开发人员而言，他们无时无刻不面临的问题是：所有的应用程序使用在对于一个很普遍的系统时，即便是在同一时刻不同的团队之间也无法很好的达成协作。公司并不仅仅只是打算让简单的让SOA在开发工具和综合应用平台上发挥微乎其微的作用。更多的是他们希望SOA能够在更为广泛的程度上自由发展，从一个领先理念指导的前提出发整合所有平台为一体以达到最佳的效果，从而可以更好的专注于应用程序的功能性并在此程度上最大限度的使用各个开发技术所带来的优势。但是对于SOA的核心观点而言，对于完全不同的系统是需要友好整合在一起的。对于SOA最为明智的理解是对于处理散乱的信息处理功能，能够将业务流程作为整体指导并分成若干的不同的组件，发展成型的独立应用服务，并根据不同的业务应用需求将这些组件有选择性的匹配起来。在SOA的基础上，这些不同的功能模块组件能够像积木一样组合，同时也可以几乎无限的分散成各个块。

　　制造服务的公司让客户整合简单化

　　当然，并不是所有的业务都是那么的具有可分散性，而且对于业务的进展也是很难去估计的，相反，他们更多的依赖于具体的序列事件。大部门的公司之所以对SOA理念情有独钟是因为清楚的认识到SOA能够大幅度缩短应用程序开发周期。但是，一些以SOA为指导的开发人员发现实际上有一些关键的服务治理如果处理不当将会严重降低开发速度，而不会带来理想中的开发速度。一家侧重于制造服务的公司需要容纳范围广泛的客户整合，如不同系统间帐单、预测和订单系统。然而随着你的客户系统的增长和演变，你将很难管理这些点对点的沟通。这是许多制造商转向交易枢纽-VANs(增值网络)第三方供应商的原因，这样一来对于每一组消费供货关系，双方只需要担心VAN的连接一个方面。VANs就不太适合应用于定制程序，当你与客户涉及到此时，这种方法就会失败。