功能被无限夸大 解析SOA架构实施失败之谜

现在,围绕面向服务的架构仍然有很多未解之谜。很多人—甚至是IT领域的—都说,他们不明白SOA可以做什么,或者如何去部署SOA。SOA已经被软件厂商和分析师们夸大到令人难以置信程度,但是,介绍这种新方法基本含义的珍贵资料却很少。

当没有人真正拥有SOA时,SOA怎么会失败呢?

以下就列出了至今仍然围绕SOA的一些未解之谜:

1.如果SOA真的失败得一塌糊涂,那么,这些"恐怖"的故事在哪里呢?

不少学者和分析家宣称SOA将是一个失败的想法;至今还没有人真正完成SOA的部署工作。一度,大家都迫不及待地宣布SOA半路夭折了,但是,我看到的或者我亲自做的调查显示,大多数公司仍然在规划或考虑他们的第一个面向服务的项目。事实上,这些日子我不断听到的有关SOA面临的在重大挑战是:SOA太成功了,在那些正努力部署SOA的企业中,太多的服务正在被不容分辩地添加进来或创建—或者被要求创建。这也就是为什么有这么多厂商都大肆宣传SOA治理。

2.人们如何知道SOA项目成功或不成功的时间呢?

有关SOA自相矛盾的观点是—那些最倾向于采用SOA的企业恰恰是对SOA需求最低的企业。那些有需要的最低限度。如果这些企业的管理是有远见的,他们也很可能把很多其它应用部署在企业系统中以对SOA提供支持,比如商业智能和分析、数据仓库、客户关系管理,等等。他们正在取得的成功有多少可以直接归因于SOA?成功的定义是什么?成本节省?Web服务提供的一个单一的端到端的过程?

这是SOA首先要面临的一个巨大的挑战之一—收获成功是一个长期的过程。SOA的成功在于企业能够在服务开发时间明显缩减的条件下,跨多个业务单位共享服务;或者,由于SOA不断增加企业底层的基础设施的灵活性,这使得企业重新配置产品或服务并将它们推向市场的时间大大缩减。

但是,在市场上能唯一真正衡量长期成功的标准是企业收入和股票价值的不断增加,除了SOA,还有很多其它因素会对此造成影响。真正的问题在于弄清楚如何衡量SOA对于企业成功的贡献。 SOA本身的"成功"同这是毫无关联的。

3.到底有多少全功能的真正的SOA被部署了?

一些分析机构表示,目前有很多公司(75%或者更多)正在实施SOA项目。还有一些分析机构则表示,目前部署SOA的企业只有4%。他们衡量的标准是什么?根据服务的数量还是这些服务的粒度?根据应用数量或者能够访问具有服务功能的松散耦合组件的过程数量?时,是否只是一堆Web服务,成为国家海洋局?Web服务可能需要更好的"照顾"—治理、注册、管理等等,因而会变得更加SOA化,但是,这个界限是什么?

4.软件供应商是如何给用户灌输了一种观念,使得用户很容易地就使用他们的产品。

这对软件供应商是福还是祸呢?SOA的真正好处在于服务几乎可以根据需求随意调换。用户今天有可能使用这个供应商的SOA组件,没准明天就采用了其它供应商的SOA组件。这也正是软件厂商面临的难题之一,尤其是对于那些大力倡导SOA的厂商。(当然,现在所有供应商都表示他们都与SOA有关,对吧?)

5.谁为SOA买单呢?

哪个部门会花费大量金钱和人力去搭建这样一个会被其它任何人使用的系统呢?其它部门不需要花费任何资源就能利用该系统提供的服务。 具有SOA功能的应用在开始阶段可能会比传统的点到点的接口需要更多的成本,而投资回报率在规模经济效益中将会体现出来。正如马Mark Rix解释的那样,同先期实施的成本较低的点到点的应用相比,长远来看,SOA产生的规模经济效益可以带来更好的投资回报率。然而,风险一般发生在企业认为他们已经部署完了SOA时,但最后却没有投资回报率或者很低,因为他们部署的不是真正的SOA—仍然是点对点的接口。谁会考虑到这些风险呢?或者谁被要求考虑这些风险呢?