错误一：非理性的SOA扩展
服务太多，还未准备好与应用的商业模式相匹配。这样的SOA环境意味着应用完成后需要再次检查。这样的环境可能具有服务众多、大量文档以及新工具和中间件丰富的特点，但却缺乏敏捷性和增量软件版本性，或重用性。
错误二：遗忘数据
设计一个服务模型就像设计一个数据模型。在处理过程中遗忘数据易于导致服务性能差，从而影响应用的完整性。在设计服务时，努力配合基础数据库的设计模型。
错误三： 将SOA留给技术人员
如果把SOA的大部分过程留给企业的IT部门处理，优化软件性能和可靠性的设计服务出发点将面临风险，可能不会完全反应出商业要求。
明确商业接口是跨应用集成或多企业使用的本质所在。
错误四：忽略企业文化障碍
SOA带来的预期优势之一就是增强软件重用性，但是达到这个预期目标是一个很大的挑战。企业文化障碍会影响SOA重用的效果。例如，如果IT部门患有“非我发明”症（not invented here），程序员、项目领导和架构师就会不信任其它组开发的重用服务，或者只是希望自己去开发整套的解决方案。“非我发明”症会导致多余的编程工作，多余人员分配以及因缺乏可用资源而丧失机会，这里体现了SOA重用机制的主要障碍。
错误五：做出突然的投入
许多企业，特别是那些认为在SOA方面起步已晚的企业，容易倾向从先前的怀疑一下子跳跃到突如其来的策略投入。但是，没有做好正确的准备和计划之前，就投入大规模的SOA开发，这往往会导致严重的错误。因为面向服务是一个长期的阶段，企业应该在进行意义关键的SOA项目之前，多投入理解该项目和培养企业文化。对大部分公司而言，循序渐进才是可取的方式。
错误六：错误的起点
最常见的错误起点是遵循订购服务的第一个用户的商业需求。例如，如果服务是一个面向用户的应用程序，你可能设计的工具符合他们对数据的需求.。然而，这样的设计过程可能最后会生成出和用户接口一样多的服务，常常导致服务多余并持续增长的问题。更加统一、系统化和有效的方法是围绕应用程序的商业过程或数据模型来设计一系列耦合的信息服务。错误七：误以为每个人的想法都与你一致
SOA起源于一种用于先进分布式系统的技术设计模式。现在SOA远是编程社区之外的热门话题。在适应商业通信时，我们要考虑并认同这些各个层次上的差异。
对于程序员而言，SOA是一种分布式计算的形式，其功能块可能可以运用于其它应用程序。
对于软件架构师而言，从另一方面说，SOA起到翻译的作用，消除了不同应用产品之间的障碍。
对于首席信息官而言，面向服务是一种未来投资。代码重用意味着减少开发新应用程序的开销和时间。
不过，对于首席执行官而言，SOA可以有助于IT更好地响应商业需求，并且适应竞争激烈的商业变化。
错误八： 选择独裁以反抗无政府主义
独立的IT项目、组、部门和领域通常都有自主的渴望，可以把这看作“无政府主义”，因为由于这样会导致一个大企业里不能实行共享目标。与这样的无政府主义的另一种极端是独裁，即部门和项目被强制遵从中央命令。这两种方法都无法为一个成功的SOA环境提供所需的平衡。一个结构良好的SOA环境通常包括一个SOA卓越中心（COE），包括所有的早期参与者以及独立项目之间或者企业内部不同部门之间的协同合作。卓越中心还要将对内部过程的参与者造成不必要的干扰降低到最小。IT员工在为公司共同目标努力的同时，仍可以保留他们的自主性。
错误九： 低估技术问题
SOA用户必须了解中间件的复杂性。尽管面向服务越来越流行并且有越来越多的基于SOA的中间件，对于新手来说仍存在很大的风险会做出错误的决定。为一个小规模、试验型的SOA项目，采用点到点的网络服务连接。如果配置的服务超过二十或三十个，就用基于中间件的中介，即SOA背板。
错误十：允许不可共享的服务数量激增
共享服务促进了消费应用产品的更快发展，降低开发成本和更加方便维护。如果每个用户应用程产品的平均服务数量明显超过共享服务的20%或者低于10%，这也许意味着共享服务的数量不是最理想的。
错误十一：过度集中化
与其强加一个单独的、企业级的SOA背板，还不如采用联邦方法，也许会更可行和明智。公司的SOA计划 划分为SOA域、子公司、商业单位或者部门。每个域由一名商业管理者和一名技术经理共同管理。每个域都有它自己特定的SOA背板和服务注册表。它由一个域SOA卓越中心提供支持，并按照以政府规为基础来进行管理。
错误十二： 在你准备好之前就推行SOA
一个企业级的SOA需要高层管理者，也许还有董事会的支持。然而，过早寻求管理者对企业级的SOA的支持是一件很危险的事。到2010年底，只有少于25%的大公司将具备在企业范围内推行SOA所需的技术和组织技巧。
