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

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

　　但实际SOA实施并没有像SOA厂商希望的那样迅速为人们接受。然而，推迟应用并不是因为技术问题。通过标准化流程和政策替代特殊工具和技术手段，开发人员可以更好地坚持架构的意图而不是将每个人的努力硬塞进某种特殊工具或技术的限制或假设中。在共同架构下保持技术异质也是有现实原因的

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

　　据甲骨文合作伙伴CD Group公司的首席技术官Bill DeSpain称，整个企业范围内的SOA应用是有限的。我们的成功是有限的。当你决定要采用SOA方案时，购买ESB、注册库和其他工具是很具吸引力的，这样能够使其所创建的应用程序结合起来并应用到其所执行的业务流程中去。从架构入手能帮助你确保目前和将来随时间推移后，任何需要改变的时候都有一个正确的框架来指导执行。

　　CD Group部署的试验计划通常是客户机构的IT员工推动的。然而，他们的首要任务是创建一个更灵活的应用程序架构，而不是对业务部门有明显的好处。DeSpain说，当一个试验计划转变为进入全面的SOA实施的时候，这通常是因为这个实验计划没有给业务领导人留下深刻的印象。

　　DeSpain说，他们没有认识到SOA的好处，主要是因为这个计划没有业务方面的事情。

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

　　Griffin说，成功地展示一个流畅的商务流程不仅有助于完成一笔交易，而且还是让IT与商业关系更密切的一种途径。

　　CD Group使用的一个成功的战略的是以客户商务流程的工作流为起点，然后围绕这些流程建立一个SOA解决方案，而不是采取其它的方法。这样，客户的业务和IT领导人都会立即看到SOA的好处。他说，你最终是在销售两个项目。

　　DeSpain说，从最基础的地方实施SOA通常是做起来容易做起来难。因为这个技术还不存在。甲骨文的Fusion应用程序和其它企业资源规划(ERP)计划等技术将使成功地部署SOA更加容易。他说，这是甲骨文Fusion应用程序的隐性好处之一。

　　销售SOA除了要了解许多解决方案提供商之外还需要商务流程的知识。要解决这个问题，SAP有自己的商务流程专家社区。这个门户网站有通用的SOA和ERP资源以及有关不同垂直行业的具体的商务流程信息。

　　大部门的公司之所以对SOA理念情有独钟是因为清楚的认识到SOA能够大幅度缩短应用程序开发周期。但是，一些以SOA为指导的开发人员发现实际上有一些关键的服务治理如果处理不当将会严重降低开发速度，而不会带来理想中的开发速度。来自财经出版和信息服务公司，Thomson金融的产品核心服务管理副总裁Vladimir Mitevski说道，这是他们公司在开始SOA征途初期的时候所发现的一个令人惊讶的事实。

　　Mitevski指出：“如果要真的成为一个对企业产品具有指导意义的资产，一个服务需要有着许多极其严格的要求和实现策略。”很多要求看起来是非常苛刻的，比如说一些基本的XML元素名称不能用缩写，必须是字典里真正有的字，举例来说，在某些系统里的登陆程序，用户名称和密码必须是有规范要求的。之所以会有这样苛刻的要求必定是有着充足的理由。它他补充道，当你只是有着很少的一些服务时，企业的架构团队能够很容易的理解这些问题并作出正确及时的处理，但是，一旦服务开始达到一个量的时候，如果没有这些苛刻的要求，架构团队肯定则会出现种种的疏漏，工作量和工作压力都无法缓解，更严重的是如何处理服务的瓶颈将无法很好的解决。

　　Thomson金融有着无数的服务组件，但是相对的他们的架构团队成员则并不是很多，这正式缘于他们对这些服务组件有着极其标准的统一与要求，所以才能够很快的解决服务组件的一些相关问题。“我们不用担心每个服务组件的粒度问题，不用担心他们是如何在整个流程中怎样进行的。” Mitevski说道。只有当服务组件能够达到这样的一个要求时才会被允许进入到库中。同样，新的服务组件在得到应用之前也必须要经过这样的评估才会允许注册入库，然后再可供产品使用。Mitevski还说道：“因为得考虑让库中的服务组件能够有一个大的规模，但是基于这样的评估标准，这对于架构方面的工作人员而言确实是个难度不小的瓶颈问题。”

　　降低这些服务组件的顺从性并不是一个好的解决方法，这都是由所需要面对的关键应用的性质所决定的，诸如单点服务登陆，对于分析师和交易人员的基于金融市场信息的Web服务，基于网络的财务分析和服务……这些都是服务组件严谨性的苛刻前提。

　　Thomson公司对于遵从工作量问题的解决方案是求助于自动化、使用WebLavers的政策评估工具。Mitevski说：“这些工具是很有效的，不会错过任何一个违反案例。”为这些工具标准的遵从性制定政策是需要时间的，更关键的是架构师需要评估工具分析来确定特定的事件是否重复出现，这是否意味着开发人员对于关键政策的理解不够或者架构中的模糊点存在。尽管Mitevski发现许多违反政策案例都有由于开发人员走捷径而造成的，他还是指出：这能帮助我们看到应该怎么做更好，而一些政策的确需要调整。除少数发生的违反规定的情况外，架构师还将决定甚么时候给与开发人员例外的权限，而这些额外权限将被写上注册表以告知其他用户。

　　让服务组件顺从性自动化给Thomson金融带来的最大好处则是服务组件开始变得更加灵动。Mitevski说：“曾经需要20个人参与的大的流程项目，在自动化实现了之后仅仅只是需要一个人就能顺利完成。”

　　一家侧重于制造服务的公司需要容纳范围广泛的客户整合，如不同系统间帐单、预测和订单系统。然而随着你的客户系统的增长和演变，你将很难管理这些点对点的沟通。这是许多制造商转向交易枢纽-VANs(增值网络)第三方供应商的原因，这样一来对于每一组消费供货关系，双方只需要担心VAN的连接一个方面。

　　VANs就不太适合应用于定制程序，当你与客户涉及到此时，这种方法就会失败。Jabil是一家电子产品制造商，面临着其两难的抉择：手工维护所有定制应用程序和界面。Jabil拥有5000多家贸易伙伴，虽然大多数都能通过VAN方案来处理，但是有50家客户是需要特殊的沟通机制或业务流程的，因此Sterling Commerce VAN应运而生。该公司电子商务经理Lowel Gilvin回忆说：通常来说每一个客户都会有好几个这样的特制连接组合。这种情况需要改变，因此Jabil按照SOA原则用以服务为基础的连接替代了绝大多数的定制连接，并使得常见功能可以被再利用。

　　第一步就是分将如订单到付款管理，预测和库存发送等等的业务流程从沟通流程中分散出来。Jabil目前已经为多数沟通机制制定了服务标准，例如AS1 (适用性声明1)，AS2(适用性声明2)和FTP，以及为XML、平面文件，Excel和SAP的iDocs格式都有各自的数据处理服务。它为每一个客户将适当的沟通服务、数据处理服务和业务服务组合到一起。在大多数情况中，这些操作都是通过表格和元数据自动进行的。Gilvin指出：在某些情况下，客户也许是基于分工要使用一个以上的机制，那么这些表格就要处理这些不同的机制。

　　Gilvin还说：SOA原则下提取、模块性和服务组合通常是管用的。但在一些情况下，特殊要求不能仅仅通过组合服务得到满足，因此Jabil仍然使用一次性整合去维护。但即使在这里，Jabil往往可以将SOA方案用在部分的整合当中。举例来说，XML和SSL证书验证不能通过标准化服务来处理，因为证书都是独一无二的，但Jabil可以使用一种硬布线数据处理服务将适当的通信和业务服务组合起来，在三分之二的整合中保持了SOA的重组和一致性的益处。

　　Jabil Sterling Commerce公司的Gentran Integration Suite来实现信息、服务注册和进行服务的管理和开发，而不是用ESB管理信息，注册表来管理服务注册，或是面向SOA发展环境开发服务。该套装是专为供应链的互动而设计的，这是jabil所要管理的一切了。这个有限的范围让Jabil能依赖于工具嵌入式架构。Gilvin指出：我们的标准化业务流程是很小的。