当考虑了策略业务目标和活动时，理论上的 SOA 概念非常具有吸引力，更加容易得到支持。不过，不可轻易决定要实现 SOA。这与改变生活方式有些类似，因为开发和操作团队遵循的 IT 控制模式将完全不同。我提倡进行业务驱动开发。此过程涉及到将业务需求细化为 IT 要求，然后将 IT 要求细化为 IT 功能，以确定满足这些需求所需的技术。根据我过去四年开发基于 Web 服务的解决方案和更为成熟的基于 SOA 的解决方案的经验，以下这些相关因素通常会让我建议采用面向服务的体系结构：

　　何时采用 SOA

　　集成成本持续增长，而并未因为可提供真正投资回报 (ROI) 的新业务机会而得到缓解。

　　兼并和收购是您公司扩大市场份额和获得新发展机会的业务模式的核心。

　　解决方案要求对来自异构系统和编程模型的业务功能进行集成。

　　业务的生存依赖于根据市场变化快速调整或即时响应竞争威胁的能力。

　　全球经济的影响要求您的公司事半功倍地开展业务，而且有必要依赖业务合作伙伴提供非核心业务功能。

　　就提高收益而言，与业务合作伙伴协作的效率对您的公司十分关键。

　　您公司业务资产的价值在减少，因为不能对其进行评估，以在最初用途之外的其他地方使用。

　　您公司员工的效率出现了问题，因为他们的大部分时间并没有花在提供公司业务模型的核心功能和服务上。

　　您公司的业务充满了机会型的业务工作。

　　您公司从头开始开发新应用程序。(我认为 SOA 应当作为定位将来的新应用程序的缺省体系结构样式，业务条件有其他限制时除外。)

　　在理想情况下，您和您的业务合作伙伴间没有预算限制、计划期限、技能差距和优先级差异，我想，此时完全可以说每个人都会采用 SOA，或者至少会考虑采用 SOA。不过，我们的选择实际上经常受到过去的决策的影响和限制(例如，技术投资、编程模型采用、服务的合同协定等)。因此，我们并不能总是自由地采用看起来能满足某个业务需求或技术要求的最佳选项。以下的注意事项会让我不建议采用面向服务的体系结构或说明现在实现 SOA 的边际收益：

　　何时不采用 SOA

　　您公司只将小部分 IT 预算用于集成活动。

　　您公司的大部分流程都是手动的或以文档为中心的，自动化的机会几乎为零。

　　您公司的大部分应用程序开发都使用相同的编程模型。

　　您公司的操作由一个或两个客户关系管理 (CRM) 和企业资源规划 (ERP) 应用程序管理，几乎没有集成要求。

　　您公司的现有技能库与实现支持 SOA 的基础结构所需的技能库之间存在重大差异。

　　未发现可从 SOA 提供的功能受益的业务需求或机会。

　　新业务服务的可用性将对现有的收益流带来负面影响。

　　您公司依赖的业务合作伙伴对公司间流程的自动化采用了不同的优先级。

　　您公司的主要业务的开展涉及到海量且同步性和实时性要求非常高的事务。

　　前面的列表只是一个示例，用以说明 SOA是否是您公司最佳选择的原因。当然，每个合同或项目都具有唯一的要求，因此关于何时采用 SOA 的决策取决于您公司的业务状况。SOA 的价值主张十分诱人，但选择何时让您的公司采用SOA必须考虑业务环境的实际情况。采用 SOA不一定要跨一大步，而通常是采用循序渐进的方式进行的。首先找到可以利用 SOA 概念和原则的项目，然后使用主要性能指标测定其价值，这是一种让大家受益的好方法。