SOA：通往IT敏捷性的又一歧途？

　　就我个人感觉，在近期我所听到的关于IT敏捷性的讨论中，IT又在把自己引入一条已被证实错误的道路。所有人都赞同今天的IT需要的是速度。而近期商务活动管理协会所做的一次调查表明，今天的商业对IT的期望排在第一位的是在应用过程中的迅速性、柔性和响应性。

　　而且同样清楚的是，IT还不够快。这项调查还发现，只有11.2％的调查接受者可以在改变流程的同时满足商务需求。更遗憾的是，约36％的调查接受者反应其公司的IT部门“存在重大困难”（26.6％）或“完全难以维继”（9.2％）。

　　这项调查还发现，IT正面临着大量急需改进的流程。平均看来，现在的核心业务流程中有40％正需要IT技术的引进。

　　理论上如果IT技术可以更加敏捷的话，那么它将可以填补应用需求的空缺并使得各项商务各得其所。然而敏捷性的真正含义是什么？而IT需要怎样使自己具备这种性质？我所担心的是这一词语又将是一个刻意生造的词汇，其目的是掩饰IT难以控制的问题——日渐老化的软件和组织的官僚主义。

　　面向服务的架构(SOA)被当作征服敏捷性的英雄受到欢迎——事实确实如此，我对某些人对这一概念的狂热做过一些报告，这些人包括分析家、销售商以及一些在喜欢IT的官僚主义组织（譬如电信和金融服务此类IT往往就是其产品本身的机构）里工作的CIO们。

　　SOA至少道出了当今一些高度联合的超级IT公司之间的一种现实情况，那就是商务已经不再仅仅依赖于技术。正如著名分析家兰迪.海弗诺所说，今天的商务已经“具体到了技术内部”。要想改进业务模式，就必须进行技术的改革。如果技术层是缺乏柔性的，那么业务的改革就会非常缓慢，从而最终影响到公司的竞争力。

　　根据前文提到的调查，限制企业进行业务流程改革的能力的最主要因素是时间和资源的缺乏（47.7％），其次是有限的预算（41.5％）。对业务理解力和流程领悟力的缺失远远列于其后，分别为26.8％和26.5％。

　　所以，理论上如果减少IT在业务流程改进上的时间或者提高相关人事的生产力（或者两者兼有），IT所承受的内在阻碍将会得到缓解，而流程的无效性（请注意组织官僚主义这一确定变量）就很容易凸现出来。

　　SOA的支持者们通过吹嘘它给软件开发带来的益处来强调它提高生产力的可能性。突破网络服务来建立一种复合型的应用，你就抽象出了远高于基层组织的编码以使它在多样化环境里得到重复利用。

　　而重复可用性正是创造生产力敏捷性的驱动因素。我并没有找到确切的数据，但人们一直以来所估计的是，如果你可以重复利用软件项目中的编码，你可以节省一般的努力。

　　但最近我开始听说人们对重复可用性的预计并没有得到印证。我看到过一些早期的观点：只有10～30％的服务得到了重复利用。

　　其次，这些复合性应用应该能够使得公司各个部门的人都能够充分地利用你所缔造的服务，而我认为当务之急在于遏制对创建这种复合性应用的复杂性的忽视。（这里，官僚主义的潜在威胁有一次构成了威胁——怎样才能得知不同部门的人员的需求而后让他们使用它呢？）

　　关于面向服务的开发过程的另一论点是，即使不进行代码的重复利用，它也可以使服务更容易进行调整。一个具有较低的集成度，并分散为不同业务职能的服务软件相比之下更易于改良。而一个传统的集成软件中，所有不同的职能都紧密集成在一起，所以即使你只是想改变其中的信用核查程式也必须进行全盘的调整。但是在我的研究中我听到太多设计师讲述他们是多么辛苦地进行服务软件的设计而后又不辞辛苦地返工，故而我不会再相信这种“易调整性得到改善”的论调。

　　现在让我们回到我们所讨论的开发方法——SOA这一自从面向目标规划出现以来就一直存在的方法。面向服务的开发方法在项目最初对开发的原因不做任何的假设。是否由于业务上的原因而必须重写代码，还是简单地假设这种开发方法将会自动地带来收益？那些和我讨论这一问题的相关设计者告诉我，想要开发一个优良的面向服务应用软件，所需的工作量将会大大超出开发一个传统的集成应用软件的工作量。所以实际上SOA开发方法带来了额外的成本。如果说这项工作将会带来收益的话，就必须取消其他的一些工作，因为这种开发方法本身并不能创造收益。