失误6：在不适当的地方开始SOA

　　最显而易见的起点是按照有意向的第一个用户业务所需的服务。举例来说，如果服务要求是一个面向用户软件，那么你就可能设计一个与其数据要求匹配的工具。

　　但是， 这样的设计过程会产生与用户界面一样多的服务， 通常会导致多余的，数量不断增长的服务。更具一致性，系统性和有效的方案是在应用程序的业务流程和数据模型周围设计一套具有凝聚力的信息服务。

　　失误7：假设大家的想法跟你一样

　　最初，SOA仅仅是一个适用于先进的分布式计算机系统的技术设计模式，但现在除了编程社区以外它也成为了一个热点话题。因此我们需要在制定各个层次的企业通信时考虑和允许这些差异的存在。

　　对于一个程序员来说，SOA是一种分布式计算方式，其中的组成部分是有可能提供给别的程序的。

　　另一方面，对于一个软件架构师来说，SOA意味着应用程序之间界线的消除。

　　而对于首席信息官来说，面向服务架构就是一项对于未来的投资。编码的再利用是一项减少成本和新程序开发的手段。

　　但是对公司首席执行官来说，SOA应该要帮助IT部门更能对业务需求做出反应，并促进具有竞争力的商业变革。

　　失误8：选择以专政对抗“无政府状态”

　　个别的IT项目、集团、公司或是域通常都有着对独立自主的向往，而这也被视为“无政府状态”，因为它破坏了在大的组织结构中建立共同目标的可能。

　　对抗“无政府状态”的另一个极端的武器就是专政，所有的部门和项目都不得不听从指挥中心地命令。

　　这两者都不能为成功的SOA环境建立应有的平衡。

　　一个组织良好的SOA环境总是包含着一个SOA精英团队，及早涉及所有的参与者，促进独立的项目和组织部门之间的协调。

　　这个精英团队也减少那些对内部流程参与者的不必要的打扰。IT工作者既能保持自己的独立性，也能为整个公司共同的更大的目标做出应有的贡献。

　　失误9：低估技术问题

　　SOA用户必须得了解中间件世界的复杂性。

　　尽管面向服务已经日益普及，SOA支持的中间件也可以使用了，但对于新人、新企业来说做出错误决定的风险日益突出了。

　　在小规模，实验型SOA项目中使用点对点Web服务链接。

　　而当实施的服务多于20或30个时，才使用以中间件为基础的媒介SOA底板。

　　失误10：让不可共享的服务持续扩散

　　可共享服务在消费型软件方面获得了迅速的发展，降低了开发成本和减少早期维护。

　　如果每一个消费型软件服务的平均个数超过20个或是少于共享服务的10%就说明共享服务的数量并不是最优化的。