随着中间件概念的不断更新，SOA已成为了一项事实标准。抱着这种观念，IBM高级管理人员和很多其他供应商、分析师和软件开发人员都开始重新定义SOA，并总结出了一些非常鲜明的观点。
专家认为：SOA促进了服务流程的可用性，并将业务需求与 IT 功能真正意义上结合起来。
如何部署SOA，选用SOA应遵循何种原因与何种时机，如何当前竞争激烈且快速变化的业务环境中具备快速的应变能力。一些专家分别根据他们与IBM内外开发先驱合作的实践经验提供了一些新颖的看法。而这些看法将帮助关注中间件发展的人们了解SOA在何时何地（甚至何种情况下）在新一代IT体系结构和开发计划中使用。
Holt Adams
IBM解决方案顾问 IT 架构师，他的工作职责包括将客户的业务需求和信息技术相结合，以将其包含到 IBM 产品中或设计为新产品。
不要轻易决定使用 SOA，这与人们改变生活方式有些类似，因为任何开发和操作团队所遵循的IT控制模式将完全不同。
—Holt Adams
SOA不能盲从急进
IBM的目标之一就是在其产品内开发和采用开放标准。通过这种手段，就能在公司的IT基础结构中实现 SOA的价值主张。
从功能上看，SOA能够优化业务需求与 IT的一致性，能够将业务流程活动从服务实现中分离出来，还能够降低操作成本。只有在不固定供应商的情况下才能真正实现这些功能，此时面向SOA实现的技术可以无缝集成，甚至构造全面的端到端解决方案。
当考虑了策略业务目标和活动时，理论上的SOA概念将非常具有吸引力。不过，SOA却不能“盲从急进”，这与改变生活方式有些类似，因为任何开发和操作团队遵循的IT控制模式都是完全不同的。进行业务驱动的开发，必定涉及到将业务需求细化为IT需求，然后将IT需求细化为IT功能。因此，尽管SOA的价值主张十分诱人，但选择何时采用SOA，用户必须考虑业务环境的实际情况。
采用SOA不一定要跨一大步，最好的方法通常是采用循序渐进的方式进行:首先找到可以利用SOA概念和原则的项目，然后使用主要性能指标测定其价值，这是一种让大家都能受益的好方法。
将业务与IT结合起来
SOA是一个很好的开发范例。该体系结构可用于在业务和 IT之间构建中间地段，其中包含双方都同意的一组IT服务，由于这些服务融洽地结合在一起，因此可以实现组织的业务流程和目标。
SOA这种范例还提供了前所未有的灵活性：它允许将业务流程的结构化组成从为流中每个活动提供功能的服务中分离出来;还允许将业务实现与其描述分离开来。
进行了这些分离后，公司能以增量的方式更改其后端遗留系统，并添加新功能来支持新需求，而不用受到供应商选择的限制。
因此，可以在最小化对业务流程和IT系统的影响的前提下对软件包和自定义应用程序进行替换。
软件工程发展的下一步就是优秀的体系结构，它使我们从结构化对象转向分布式对象和组件，然后以一组公共服务为中心来将业务和 IT加以结合（这些服务结合在一起，可以实现组织的流程和目标）。
除此以外，SOA还允许将公司的部分业务流程向业务生态系统中的合作伙伴公开。
使用SOA技术时，实时或被动系统通常不是进行实现的最佳选择，因为当前的技术不支持将SOA用于有大量并发使用情况的实时系统。SOA非常适合用于消除冗余以及将业务紧密耦合到特定服务中，最终实现业务与IT功能的结合。
Ali Arsanjani
IBM全球服务中心的首席架构师。主要负责收集和制定 SOA和Web服务的建模、分析、设计和实现方面的最佳实践。
使用SOA技术时，实时或被动系统通常不是进行SOA实现的最佳选择，因为当前的技术不支持将SOA应用于含大量并发情况的实时系统。不过，这些系统的建模可以从SOA提供的分离和独立概念中获益。
——Ali Arsanjani
正确应用SOA
在快速发展的全球经济环境中，企业要保持竞争优势，必须保持足够的灵活性。通过使用SOA原则将IT基础结构与核心企业流程结合，可以提供和保持这个优势。因此，理解和采用SOA所面临的问题不是“为什么而用”，而是“什么时候要用”。基于SOA的企业解决方案已被证实能简化业务操作、提高效率、降低成本及消除冗余。
不过要获得这些利益,必须正确地应用SOA。必须具有相应企业范围内的远景和转换路线图，还必须有业务执行人员的财务支持和承诺，并由有经验的架构师以增量迭代的方式进行部署。目前，SOA平台也在经历着巨大的转变，尤其在开发工具方面，开发环境包含大量的建模工具、行业根深蒂固的场景、重用模式、方案和丰富的可视表示和控件以及模拟技术。可以肯定的一点是：对于中间件技术，我们正处在对解决方案生命周期的每个方面进行改革的浪尖上，而SOA则是其中关键的催化剂。但若从长远来看，如果我们不谨慎的话，这个抽象和易用性可能会使 IT架构师或开发人员和计算机科学与技术的根本基础脱离联系。
Sanjay Bose
供职于IBMSoftware Strategy部门。有超过 12 年的 IT 行业从业经验，主要涉及创建产品体系结构、设计和细化技术策略。
我们正处在对解决方案生命周期的每个方面进行改革的浪尖上，而SOA则是关键的催化剂。不过，如果我们不谨慎的话，这个抽象易用的技术概念可能会使 IT 架构师或开发人员与计算机科学技术的根本基础脱离联系。
—Sanjay Bose
驾御SOA
SOA为企业提供了一个机会，以标识其核心能力和决定能否值得其行业和业务合作伙伴信赖。另一方面的事实是:企业可以对作为其核心基础结构中一部分流程和应用程序进行标识，然后确定进行购买。企业架构师可以牵头开展相应的工作，以发现企业中具有公共功能集的业务流程和 IT流程。可以将执行功能打包为外部依赖性很小的组件，并作为服务提供。这就使得业务流程创建者或应用程序开发人员的工作得到简化，以将精力放在能满足股东的业务动力的唯一功能上。让SOA正常工作在很大程度上不是技术问题，而是一个业务控制和IT控制问题。IT架构师需要向执行股东报告业务从其SOA投资和投入方面获得的价值。
为了让SOA与业务合作伙伴进行协作，需要涉及企业之间已经建立的原有关系。
目前很少有客户在其建立的合同关系之外为合作伙伴提供或购买服务。服务级别协议和争议解决的相关事项要求配备封闭的协作系统，目前，有关信任和安全的结构化信息系统发展组织标准在过去两年中取得了长足的发展。
David K. Jackson
IBM Americas Software Sales的顾问 IT 架构师，常驻纽约技术支持中心。同时，他还是Open Group Architecture Forum的副主席。
让SOA正常工作在很大程度上不是一个技术问题，而是一个业务控制和 IT 控制问题。
—David K.Jackson
这里没有神话
恰当的体系结构控制将对其服务可供新应用程序使用的项目进行标识。要使得SOA投资最终能物有所值，惟一的办法就是让高级管理人员承诺控制预算，或采取某种方式保证业务线能不受干扰。
目前关于为什么应该考虑SOA 有三个简单的理由:
首先，这是目前最热门的领域之一，不要落后于时代的步伐;其次，工具、基础结构和标准经过组合，可为整个SOA生命周期提供全面支持；最后，如果一位应用者总在不断地追求事半功倍，那么 SOA可以为他提供帮助，寻找他可以再次利用的东西，而不要所有东西都自己从头做起。
SOA的最终目的就是寻找现有服务，对其进行调整，并加以使用。然后对其中一些服务进行共享。帮助创建一个生态系统，以便在将来能更快地装配更多有意义的解决方案。
开始采用SOA与采用任何其他技术或体系结构没有什么区别。可以通过常识来看这个问题:如果用户的项目处于十分关键的位置，而拥护的团队必须投入大量精力学习工具和 API，它就有可能是错误的选择。相反，如果用户可以在小项目中试用 SOA，则是不错的选择。
利用这一类经验，架构师可以帮助用户定义和扩展到下一个更大的项目。不容忽视的关键就是:SOA的各种实施都遵从“循序渐进”的法则，因为这里没有神话。
Christina Lau
IBM On Demand Development团队架构师。她目前参与的项目包括创建 Pattern Solutions using Rational Software Architect 项目和试用业务创新的功能。
如果您的项目处于十分关键的位置，而您的团队必须投入大量精力学习工具和 API，SOA 就有可能是错误的选择。因此率先在小项目中试用 SOA，是个不错的选择。
—Christina Lau
不容忽视的指标
一直以来，SOA的支持者不断不畏余力地宣传SOA的主要技术优势：能够松散绑定，还能够通过组件封装可重用业务功能，最后还能提供更好的集成。
但是，客户真的对这种技术推论感兴趣吗？在过去两年，笔者经常发现，有些客户经常一厢情愿地得出一种结论：认为非常有经验的架构师和开发团队可以通过使用传统EAI体系结构获得很大价值。甚至有人认为:这些方法经过验证，实现风险并没有直接采用 SOA进行设计的风险大。
这个观点可能会让架构师认识到在有些情况下，SOA是错误的选择，至少不是最好的选择。目前大多业务及IT相关的问题将减慢或阻碍任何构思良好的技术SOA活动的实现。 曾有一位汽车行业的CTO反馈出这样一种意见：“SOA只是一种业务而已。” 这位CTO和他的团队仅关心如何使用其现有的技能在预算内按时达成这些目标。他们已经在其现有EAI基础结构中进行了大量投资。
在资金有限的业务环境中，几乎没有客户能为解决特定的业务问题无限制地投入资金。因此，作为用户，请同时根据技术指标和业务指标来确定是否采用 SOA。
Calvin Lawrence
IBM Software Group Emerging Technology团队的执行架构师。他的职责范围包括通过关键策略活动的支持来推广战略 IBM 体系结构、技术和产品。
虽然我们不知道每个具体解决方案到底是什么样的，但都应当客观地看待每一个问题。请同时根据技术指标和业务指标来确定是否采用 SOA。
——Calvin Lawrence
利用SOA改善信息质量
人们之所以关心SOA，是因为 SOA具有直接和间接影响信息管理系统的能力。为了获得成功，人们需要在业务服务所涉及的信息的上下文中对其进行考虑,人们需要知道检索到的信息是准确的。
被更新的信息经过了验证。交换的信息的意义对于服务提供者和使用者都是一样的。如果忽略了这些事情，服务的价值和可重用性就会减少。
可以采用很多办法实现信息协定。其中一个变得越来越重要的就是主数据管理(MDM)领域。MDM系统可为业务应用程序或服务提供经过清除、整合且特定于域的信息。最常见的MDM系统是作为客户和产品信息的信息集线器使用的系统。每个集线器都作为中心点使用，可以在此对信息进行添加、更新、审核、清除、搜索和查询。
MDM系统可以是事务型的（在操作业务流程的主线中更新），也可以是引用型的（提供业务流程所引用的信息的一致来源）。但最重要的是，人们可以将MDM系统看作其本身提供了一个一致的服务集，以供在各种业务流程内使用和进行重用。
通过MDM等方法现实地实现信息提供者和使用者之间的协定，可以帮助人们实现SOA所承诺的灵活业务流程和服务可重用性，更重要的是，它同时为人们提供了高效管理信息质量的机会。
Dan Wolfson
IBM杰出工程师，在研究商业分布式计算方面具有 20 多年的经验，曾涉猎事务和面向对象的系统、编程语言、消息传递和数据系统等。
SOA表示的不仅是服务提供者和使用者的协定，而且也是信息提供者和使用者间的协定
—Dan Wolfson
服务超越基础技术
在企业的业务范围中，大量的创新都出现在以下两个方面：企业边缘和企业之间。在边缘上，人们可以看到很多企业向中间件之上的框架投入了很多精力（这些框架包括独立于领域的框架，如Ajax，以及特定于领域的框架），也投入了很多精力进行与设备相关的工作 （比较典型有大家熟悉的RFID应用设备）。而在企业之间，人们可以经常看到各种系统（包括旧有系统和新系统）概念的形成。这些事实正逐步印证一个事实：在企业边缘，服务是提供超越基础技术的行为。在企业之间，服务则提供了各种系统之间语义丰富的强大通信方式。其中，SOA向分布式对象添加面向服务，从而可以在进程之间调用服务。它是一种用于设计应用程序体系结构的方法，以便应用程序的各个部分可以在不同的进程中运行，而且还允许不同的应用程序共享和重用正在运行的部分。
值得一提的是，在目前以Web 为中心的系统中，服务已经被证实为一种重要的机制，但在系统的构造中，服务的手段却略显不足。
Grady Booch
曾参与过全球几乎所有领域的以软件为中心的系统设计，在其中担任架构师或体系结构顾问，发表了数百篇关于软件工程的文章。
在企业边缘，服务是提供超越基础技术的行为。在企业之间，服务则提供了各种系统之间语义丰富的强大通信方式。
—Grady Booch
IT应用的康庄大道
随着我们进入下一个十年，人们将开始着手大幅度减少工作量（过去，人们不得不将来自不同IT供应商的产品或组件组合成可行的有价值的端到端解决方案）。
未来，供应商提供的业务组件将不依赖于基础结构，可以在各种平台上执行。因此，软件开发人员会将更多的精力放在有效集成供应商组件和确保有效的互操作性上。客户的IT 操作部门将主要负责选择最适合业务需求的运行时平台；即提供恰当部署和管理业务组件所需的必要服务质量和运行时支持的平台。
IT 业务操作部门所属的人员将是业务和企业体系结构专业人士。无论人们是如何定义业务或企业架构师的：为了实现这个远景，整个行业将需要更多的具有IT和企业体系结构背景的人士。
虽然这个远景可能十分诱人，但在实施过程中仍然存在很大的风险，在进入组件天堂之前，人们必须小心地减小这些风险。
在开始进行实现模型服务的体系结构的任务时，最重要的减小风险方法可能就是要求有强有力的管理良好的控制流程和策略。只有通过强有力的企业服务控制策略才能够避免更改管理问题，甚至于解决服务间的语义不匹配，系统功能结合方面难于调试的等等问题。
Andras Szakal
IBM Federal Software Group 的首席架构师，同时也是杰出工程师和高级认证 IT 架构师。他还是The Open Group的理事会成员。
无论人们是如何定义业务或企业架构师的，但为了实现IT应用的未来康庄大道，整个行业将需要更多的具有 IT 和企业体系结构背景的人士。
—Andras Szakal