非理性扩展SOA架构的致命错误

　　错误一：非理性的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员工在为公司共同目标努力的同时，仍可以保留他们的自主性。