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能更快更省地得到这种数据以及功能，那么它就是赢家了。这恰恰是企业Mashups介入地领域。“网络驱动源”是个SOA花哨的说法，也指所有的符合标准，在通用网络协议中运行服务：HTTP。
清楚认识服务虚拟化与SOA
服务虚拟化：Mashups 不仅将多个服务的数据连合到一起，还能从未SOA化的资源中创建用户消费服务。众所周知，SOA要取得成果需要好几年的时间。在SOA功能正式实现之前，这是一项标准化的便捷的服务，能帮助用户更早起步。
用户级服务：Mashups允许用户根据自身需求确定服务规模大小。目前IT没有必要去猜测、研究或是分析一项服务提供的数据是否“太过具体”，“太过概括”，“太陈旧”或是“太冰冷”。
Mashup协作：Mashups允许用户通过在业务云上的发布与其他用户共享他们的Mashup。目前，IT也没有必要独立的承担建立所有服务的职责，而用户则可以以前所未有的方式相互协作。
Mashup互动：Mashup允许用户以图表、表格、地图等形式与其SOA mashups。除了期望公司的门户能实现其应有的功能，用户现在也有除IT之外的另一种方式根据需要与数据对话。
SOA边缘：现在的SOA努力大多集中在内部思想或是中间件上的。Mashups使得用户能够从企业内部和外部链接点数据。如此以来，SOA努力就能与那些更能体现其意义和价值的外界资源联系起来。SOA“边缘化”使这一切成为可能。
但是，这只是个理论。
企业级Mashup”必将为帮助我们更好的实现以数据为导向的服务，并为不断变化以及客户和合作伙伴一直在问的问题提供最有效的解决方法。供应商总是通过一些难以接受的新行业术语来过度形容他们的东西，诸如“新型大型应用中的简捷”，“过程而不是终点”，“新用户的杀手级应用”……但是，务实的态度可以让我们更好的学到更多。企业级Mashup将补充和完善我们的服务，帮助我们的服务和数据产品更贴近客户和合作伙伴的需求。
松散耦合
在SOA环境中，松散耦合是指服务消费者到服务提供者间的松散耦合。在服务契约设计上，通过抽象设计减少技术信赖性；在服务调用层面上，通过各种中介保持服务调用双方的技术透明性；在服务实现层面上或者SOA计算环境中，各种架构元素间的松散耦合。其中包括：
1. 保持服务契约层面的抽象性。
2. 通过WEB服务技术保持服务调用的平台中立性。
3. 采用隔离关注的方法保持业务架构和技术架构的清晰性。
4. 利用组件化设计方法保持更细粒度业务功能和技术实现的清晰性。
SOA模型驱动
业务流程管理（business process management ，BPM）与面向服务架构（service-oriented architecture ，SOA）的结合将有效驱动一种新的应用程序开发建模。来自IDC应用开发研究部副主席Steve Hendrick这样说道。
从企业角度出发来看，他们需要一个更多条理性和连贯性的方式去构建他们的应用系统，达到以Web服务的方式重用，根据迫切业务需求进行建模，以及确凿的业务流程从而更进一步的实现SOA所带来的好处。
从过去的历史看来，我们只是熟悉了UML流程建模。但是在SOA面前，这远远只是低层次的，甚至几乎起不了什么具体的效果。”
回到最初，开发人员往往是最大限度的忍受着来自需求征集方面的工作，这就如同去收集隔板上的灰尘，然活将这些需求整理起来并开始着手代码开发工作。然后在SOA和BPM得到采用之后，以及在伴随的相关技术的支持下，诸如业务流程建模标注（business process modeling notation，BPMN）和业务流程执行语言（business process _execution language，BPEL），整个应用系统开发过程的困难将得到最大程度的降低。
在过去的一两年时间里，正是业务流程建模标注（BPMN）的迅速发展让整个业务流程建模得到广泛的关注。如何将BPMN列入计划清单，并有效的与BPEL结合起来，同时做一些自动化的代码工作，这一系列的想法在你接受BPMN供应商所提供产品并考虑将现有的业务规则能力统一起来的时候将会是一种特别吸引人的东西。
对于SOA的实现其重要的体现之一则是重用方面的功效。实际上，如果你真的需要实现重用，那你就必须有一个能够在比以往更高层次的建模工具，并以此为基础去监控每一个组件以及其之间是如何构建在一起的。
模型驱动的SOA能够确保从一开始到最后，应用程序系统都能和最高层次的业务需求以及底层的Web服务功能取得一致，并有效结合。
“最显著的优势则是通过这样的一个模型驱动，你可以在一个逻辑的模型层面即可解决如何分散你的应用系统或是构建他们，通过你的设计你便可以很快的通过模型实现。