Sonic软件和Progress软件公司技术总监Dan Foody,在接受TechTarget采访中他所认为SOA最差实践基础上正见证着SOA的一系列失败。作为技术总监，他并没有从技术层面上来看待这个问题。在他看来，问题在于项目的管理，缺乏对SOA方案的理解和企业没有能够作出适合SOA理念应有的改变。

　　在SOA方面，你们看到了什么?　　

如今，人人都在谈论SOA，企业里人人都知道SOA并想参与其中。但是，其自身正遭遇着挑战，因为并不是每个人都能正确理解在面向服务架构里应该做些什么。

　　这种对于SOA的无知会带来什么挑战呢?

　　我们发现当人们宣称他们在做面向服务架构时，他们所做的事却并不是SOA所预期的，甚至有些吓人。

　　有例为证吗?

　　给你们举一个我最喜欢的例子。有一家公司在做一个大会主题演讲中提到他们在面向服务架构方面有多么的成功:他们已经具有300项服务，并且在一年之内能达到1000项。听起来很不错不是吗?唯一的问题在于这种类型在发展中却很糟糕。

　　为什么SOA理念会脱轨呢?

　　我们做面向服务架构，目的是避免复杂性，而不是让多达30种web服务去做同一件事情。你的目的是要去再利用。如果有上千个Web服务，实现再利用的可能性事实上为零。因此，他们也许拥有许多Web服务，但却无法实现面向服务架构。所以，在业务上也表现不出任何好处。这就是一个SOA脱轨的例子，人们错误的认为“越多越好”。

　　这是因为人们在定义面向服务架构时的问题吗?

　　这个问题有两个方面引起。一方面，一些人根本就不理解SOA的含义。建立Web服务，并不代表你建立了面向服务架构，这与Web服务的数量无关。SOA关系到你对已有的Web服务利用途径的数量。这才是在各方面定义面向服务架构的一个标准。许多人都在这一点上误解了。真正有价值的是对于Web服务的再利用而不是Web服务本身。跨组织的共享资源才是面向服务架构的价值所在。

　　还有一部分人，即使他们理解了这一点，也不一定知道如何去建立成功的面向服务架构。有的人认为建立所有权标准可以创建有效的面向服务架构。于是我们看到一些组织将Web服务与SOAP作为基础，将之拆散，让其不能与外界任何程序相互作用，然后将自己的特性加入准则当中。然后，他们需要将所有的东西编码然后联结，在此过程中将丢失掉许多协调性的益处而致使在开始的时候建立面向服务架构变得很困难。虽然在这些例子中，尝试SOA的人们理解了他们将要达成的目标，但他们并不知道途径为何。

　　标准能够帮助我们看清道路吗?

　　多数人会说:SOA并不存在技术问题，最大的挑战在于结构性问题。所以对于技术架构的重视只能解决20%的问题，但80%关于人员的问题仍有待解决。

　　我认为，犯了最差实践这些错误的人们不会在一开始就按照规则来办事。他们相信自己知道自己在做什么，这也是问题之一。那个在大会上发言的先生，讲述建立上千Web服务，他就相信自己比任何人都了解如何来做SOA，并且不会听取他人的建议。

　　因此，我并不认为标准结构能够解决这个问题。一个企业能从SOA得到的最重要的益处并不是用纯技术的形式能够呈现的，而是使信息技术将对商务有意义的资源组织起来。将信息技术与商务结合起来并使其随着时代的发展而持续进步。因此，当一个商人谈到盘点时，IT人士就能知道这意味着什么，他们会将相关的资源和技术组织到一起运作。这才是SOA的真正益处所在，这是你在任何一张架构图表上找不到的。

　　当人们有需要的时候，也会有技术帮助加入其中。他们想要，就能找得到。而恰恰是那些自以为是并没有好好利用技术帮助的人在技术层面上出现问题。

　　那么，这是不是说无知和缺乏理解是非常危险的?

　　对，自信和缺乏知识是非常坏的结合。

　　那么，在企业认识到他们应该采取别的途径之前，我们是不是会看到许多SOA失败的最差实践案例呢?

　　我们必然会看到许多项目的失败例子。一切引起企业变革的因素都会有附加效果。不是所有企业都能够完成变革的，也不是所有企业都知道如何进行变革的。所以，我认为在进行此类变革的同时，我们将不可避免的看到许多附带作用的产生和项目的失败。关键在于企业要认识到从失败中吸取教训而不要半途而废。

　　因此，我们要关注所有关于SOA失败案例的报道，避免同样的错误。如果一个人要引领SOA的启动，他不能在遇到失败时觉得羞耻，而是应该接受这些失败并将之当成又一个他能从中学到经验的案例。