要阅读有关SOA的积极的测评和SOA对于IT行业正在做什么事情，人们也许会认为因为SOA架构方法而出现一些认真的转变。事实是，使用当前的技术组合实施一项SOA设计(如达到真正的松散耦合，或者一项服务在根本上和在客户方面不能与任何其它的服务共享一个共同的关系)是复杂的、笨拙的并且有许多陷阱。

独立的IT架构顾问JP Morgenthal说，我曾经与我的一位朋友讨论过这个问题。我了解我的那位朋友知道如何开发可维护的和可持续使用的解决方案。因此，当他说，做这个事情吧。我知道这个意思是使用一些通用的和公认的最佳做法开发灵活的软件解决方案的意义。因此，我们都回避可持续性的这个概念，我们最后一致认为关键是重点理解业务。这意味着可持续性来自于自上而下的分析，而不是自下而上的分析，因为自下而上的分析是战术性的解决方案，不能保证随着时间的推移与业务的需求保持一致。

Morgenthal说，我知道最后一种说法是有争议的。毕竟这个观点是很难接受的。如果你使用很好的面向组件的方法进行开发，你不能用当前的自下而上的方法来更新未来的自下而上的方法。但是，事实是，这个自下而上的方法表示了“如何做”，而不是这样做的理由。“如何做”将受到提供信息的人的客观现实的限制。然而，真正地理解业务能够让设计师设计一个客观的目标并且以当前需要的主观方式展示出来。

Morgenthal说，让我们重新看一下我的说法：目前实施SOA设计是复杂的、笨拙的并且有许多陷阱。他认为，当服务是没有状态的时候，SOA工作得很好并且很容易与松散耦合一致。这种情况使SOA更复杂。这意味着这个服务在使用之前和使用之后都不了解消费者，不知道消费者的环境。

而且，一个服务应该以确定的方式运行。消费者应该不会推测这个服务在同样的环境中以不同的方式运行。更重要的是，如果这个实施的任何一个部分与任何其它的服务或者应用程序的实施联系在一起，那么，它就不能根据消费者的需求转化环境。

在许多情况下，无状态是商业应用程序直接对立的。商业应用程序有丰富的用户环境和假设的用户环境。报告、安全和治理是这些功能的极好例子。如果实施方法过多地依赖一个特定的应用程序的要求，限制这个服务在多个应用程序环境中运行的能力，向松散耦合的服务架构过渡就会阻碍这些功能。

例如，如果一项服务使用一个与其它表格(如外键)有关的数据库表，并且这个服务没有使用在这些相关表格中的数据，但是这个数据库在操作这个表格的时候没有强制要求数据的完整性，从而迫使这个服务认识这些关系，那么，松散耦合的关系就会中断，因为消费者被迫了解了这个服务范围之外的信息。

此外，人们一直强调在SOA方面的再利用，以至于再利用已经成为定义一个服务的单个的决定性因素。然而，再利用是与SOA完全不相关的问题。再利用是由两个因素推动的：专业化水平和接口水平。低水平的专业化将推动再利用。然而高水平的专业化不会使一项服务设计失效，只是使它的再利用性差一些。接口只是通讯的接入点。因此，我们能够创建可再利用的组件。这些可再利用的组件在消费者不知道这个系统的其它部分(如计划ID)的情况下是不能运行的，因为这些局限性使它失去了松散耦合的资格，因此不是SOA意义上的服务。

Morgenthal说，我认为，如果你评估这些自称是SOA的系统，你很可能发现这些具有服务功能的应用程序包括可再利用的软件组件和Web服务接口。因为许多当前的SOA平台还没有提供必要的手段在没有牺牲整个服务的数据完整性等东西的情况下实现真正的松散耦合，实施当前的SOA设计经常需要一些让步，从而使最终的服务缺少可持续性。