你的组织是否涉猎SOA？你是否在犹豫不前，因为你不想因错误的方式而浪费资源？如果你能够了解怎样避免出现平平无奇的SOA的陷阱，会怎样？不妨来看看分布式系统架构幕后的奇才Arnon Rotem-Gal-Oz，看看它是怎么做的？这里是TheServerSide的一些发现：

　　面向服务架构不是魔法

　　这是建立分布式系统的一个简单该当，因为它是组件化和灵活的。然而，当组织不了解原则时，他们就会遇到麻烦。我们问Arnon（Nice Systems公司企业部分架构主管）哪里人们最容易出错。你回答说：“他们在服务粒度大小上容易错。他们需要金凤花的大小，不能太大也不太小。”

　　组织通常需要在业务流程灵活性、性能和重用性之间做出权衡。做为一个例子，恰当的粒度意味着少量的网络流量，但是每个调用要检索出更多的信息。经验是解决这些问题的老方法。但是通过阅读关于《SOA项目服务粒度（Service Granularity in SOA Projects）》的，这篇富有洞察力的硕士论文：Claudia Steghuis的权衡分析（A Trade-off Analysis by Claudia Steghuis）后，你仍然可以避免重新发明轮子的问题。

　　不要抓的太紧

　　模块化你的交互，找出把服务恰当地构建到一起方法，是很关键的。因太紧耦合而失败的解决方案是一个常见的错误。管理一个单片系统是非常困难的——但它确实是扩展的问题。紧耦合系统允许你控制所有，且从单一解决看事情。如果你有一个小的、简单的解决方案，那么从管理员的角度来看它是非常吸引人的。从是Rotem-Gal-Oz警告说，一旦你走入一个特定的大小（或你有很多开发人员），你就会丢失敏捷性。

　　—系统的不同部分之间有许多信赖关系
　　—你不得不等待其它团队成员进入到下一个项目阶段
　　—你不自己自由发展，因为实施更改需要巨大量的时间

　　在持续部署时代，这种笨拙的发展步伐是不可以接受的。聪明的组织知道技术、需求、接口和其他方面的计算很容易改变。SOA使系统组件化，因此你得到更小的部分，很容易管理。这并没有为也web而使开发变得更加敏捷。它也创建了一个移动开发变得更简单的环境，因为你需要在资源非常受限的平台上获得更多的灵活性.

　　把各部分组合到一起

　　当然，在你的SOA拼图中有越多的部分，意味着就越来越多的耦合需要管理。Arnon说这不一件坏事，“学习怎样使事情更好的一起工作是一件有益的事。当你开始后，你会得到意想不到的行为。”从SOA角度进行模块化和了解你的业务流程的一些额外努力并不是错误，相反它是一种特色。