在铺天盖地的SOA宣传文章中，最佳实践是出现频率最高的词汇之一。相比起来，最差实践就没那么风光了。但是，俗话说得好“吃一堑，长一智”，看看别人犯过的错，未尝对自己没有帮助。最近，Information Builders的市场副总裁Jake Freivald就撰文介绍了SOA实现中常见的4种最差实践，并针对每个实践给出了解决方案：

1. 过分强调低级别的代码
   • 上榜理由：重用性差，难以根据业务的变化迅速地做出反应。
   • 解决办法：关注业务级别的服务。将整个系统切分成逻辑的构建单元——即所谓的服务——将创建出一个随业务需求一道成长的可持续解决方案。Jake Freivald将服务分为3层：细粒度服务、粗粒度服务和全局服务。并写道：

     当组织过于强调细粒度的服务时，其结果就是有太多无法聚合成业务层服务的服务。照这种方式编码，将创建出难以维护或复用、低效且复杂的流程

2. 集中设计和部署
   • 上榜理由：其一，知识依赖个人，当这些人离开时，知识也随之一起离开；其二，个人不可能熟悉所有系统，当需要设计和构建服务的系统超出其知识范围时，难以设计出好的服务。
   • 解决办法：分散服务创建。服务的分散化和本地维护，这使得粗粒度和全局服务的开发者不必时刻关心底层信息资产，而且底层服务开发者的变更不会影响到整个系统
3. 撕碎并替换遗留软件
   • 上榜理由：只看到了数据的重要性，却没有意识到遗留应用同样也是信息资产之一。并且由于对数据迁移的困难估计不足，造成项目延误，更有甚者直接有损于日常业务。
   • 解决办法：重用为王。只要遗留系统还能工作，就不要管它。为技术而升级技术永远不是一个好的业务选择。
4. 购买没有支持的软件
   • 上榜理由：缺乏对操作SOA软件的足够认识，很可能会构建出过于复杂的系统，以及没有为任务选择合适的工具。
   • 解决办法：要成功，就要有支持。就算企业有SOA架构师来帮助组织来建立SOA的原则，但要想成功，依旧需要把工作落到实处。

     组织设计的成果是消息转换还是消息分拆，到底有多大影响？最好预先花时间把这搞明白，免得再在架构上线运行之后去去和效率问题相纠缠。通过足够支持的保驾护航，组织可以避免开发出过于复杂的系统，并知道哪个工具是针对哪项工作的合适工具。

Loraine Lawson对这篇文章评论道

Freivald特别提到了与“使用SOA作为一种集成解决方案”相关的最差实践。现在，我知道，有些人说SOA不应该用作集成。其总的观点是避免点对点、紧耦合的方式。但是，如果做得好，SOA可以解决很多你的集成问题。

Jignesh Shah则对于Freivald的“分散服务创建”表示出了不同看法（注：见该文的评论部分）。

看到服务的“集中设计和部署”被列为一个最差实践着实令人觉得有趣。我们越来越多地看到客户建立“共享服务”组织给他们乳臭未干的SOA来掌舵和提供动力。这样一个组织负责围绕企业范围内的核心系统识别、设计和交付服务。这有几个好处，包括可以全盘考虑整个企业的服务组合的塑形，简化资助模型，以及打通政策壁垒。

这样一个组织要对他们准备在其之上构建服务的系统非常了解，Freivald在这一点上是对的。这是为什么实际常常选择集成团队作为SOA共享服务组织的原因。这个小组有企业的视角，有处理核心系统的经验，理解异构环境下的挑战，并拥有所要求的中间件相关的技术技能。

Freivald建议的“分散服务创建”方法实际要求一个理想化的公司，在那里，他人利益排在每个小组利益的前面。这在大多数开始建立SOA的大型组织中实在难以出现。