一种方法在企业和IT之间建立了一种紧密的关系，提高企业的灵活性，改善软件的重复使用性，让更高程度的灵活性适应企业的需求。

　　把SOA定义为一种结构化商业方法。这种方法把一些能力组织为一套单独的、但是可以衡量价值的相互关联的服务。

　　SOA的强大和灵活性将给企业带来巨大的好处。如果某组织将其IT架构抽象出来，将其功能以粗粒度的服务形式表示出来，每种服务都清晰的表示其业务价值，那么这些服务的顾客(可能在公司内部，也可能是在公司的某个业务伙伴)就可以得到这些服务，而不必考虑其后台实现的具体技术。更进一步，如果顾客能够发现并绑定可用的服务，那么在这些服务背后的IT系统能够提供更大的灵活性。

　　但是，要得到强大和灵活性，需要一种实现架构的新方法，这是一项艰巨的任务。企业架构设计师必须要变成面向服务的架构设计师，不仅要理解SOA，还要理解SOA的实践。在架构实践和最后得到的架构结果之间的区别非常微妙，也非常关键。

　　SOA需要完成从以IT为中心的技术向业务加速器解决方案的转型。从大与小的思路出发， SOA对应BPM，IT必须要注重SOA的真正商业价值之所在。这意味着SOA需要帮助。BPM能将部分SOA价值提升到业务层面。正如一些企业Ajax公司能够证明，诸如Silverlight, Flash/Flex, 和Ajax等丰富的互联网应用(RIA)工具也能成为很好的SOA使用者。但是一些RIA应用程序并不认可企业范围内的多年性SOA成果。我们需要一些商业人士像谈论CRM与ERP那样谈论SOA，这也是他们工作的关键之处。

　　SOA环境的不利风险包括减少一个机构达到的安全水平和不遵守法规的更高的风险。因此，当企业进入到一个SOA环境的时候，企业需要重新考虑他们的IT治理方法。

　　SOA不需要对企业的整个IT治理模型进行重大的改变。但是，SOA需要在IT治理做法方面以及与运营的IT互动方面进行重要的改变。向SOA过渡意味着在整个公司范围内进行永久性的改变。这将伴随着风险，需要有一个强大的有关安全、质量和遵守法规等事情的IT治理观念。

　　一个重要的变化是配备人员的要求和职位的说明有所提高。此外，在整个机构，IT技能和竞争力已经成为一个必要的先决条件，特别是在软件开发、系统集成和管理等领域。

　　SOA的消费者不需要再花钱买老式的昂贵的软件堆栈了。SOA设计需要一个好的方式来创造和配制可再利用性服务，无论何时何地只要有需要就能够很简易并且直接地拿出来用的方式。消费者需要成本低的选项，可以让他们从小规模开始，随需要逐渐增加对它的采用，运用点对点通讯方案可以避免使用昂贵的新服务器和集成线路，根据需求增加服务的质量和其他性能。总而言之，他们需要SOA的基础构架，它能够真正符合一个SOA固有的分布式特征。

　　SOA将在政策、原则和标准等水平上对IT治理产生影响，只要现有的政策需要改变或者额外的政策必须要定义，就会产生影响。

　　通常，什么应该是服务这个问题的答案并不明显。功能应该与一组可重复的业务任务匹配。服务的边界应当封装一项可重用、不受上下文约束的功能。接口应该公开服务进行的工作，但要隐藏服务是如何实现的，并允许更改实现或采用替代实现。从头设计服务时，可以将其设计成对业务进行建模;包装现有服务时，创建并实现好的业务接口可能会更难。定义服务边界的潜在困难的一个有意思的例子就是在何处设置事务边界。服务通常在自己的事务中运行，确保其工作要么完全完成，要么完全回滚。不过，服务协调程序(也称为协调器或编排器)可能希望在单个事务中调用多个服务(最好是通过指定的交互，如 WS-AtomicTransactions)。此任务要求服务接口公开其事务支持，以便能参与调用方的事务。但这样的公开要求对调用方信任，对提供者具有很大的风险。例如，提供者可能会锁定执行服务的资源，但如果调用方永远不完成事务(没有提交或回滚)，提供者将很难干净地释放资源锁定。正如这种情况所表明的，服务的范围以及谁具有控制权有时候并不太容易确定。

　　她做结论称，虽然向SOA发展不会影响到通讯领域和改变管理层，但是，这种功能对于推动SOA取得成功是非常重要的。随着各个公司开始使用 SOA 来更好地保持 IT 与业务间的一致，可以使用 SOA 治理来非常理想地改进总体 IT 治理。如果公司要实现 SOA 的各种好处，采用 SOA 治理是非常关键的。对于 SOA 的成功，SOA 业务和技术治理不是可选的，而是必须使用的手段。从广义方面说，一个机构中的强大的IT治理观念对于任何SOA实施来说都是一个必要的先决条件。