【IT专家独家】有数不清的文章专注于建立面向服务架构的商业案例，提出可预期的投资收益(ROI)并且向业界证明SOA为什么能提供短期利益，SOA是通过解决当前紧迫的问题并提供IT能力如何持续地满足不断变化的业务需求问题的答案来为企业创造利益的。尽管如此，带着这些美好的商业意愿，你可能认为SOA投资将不会受到任何阻力。毕竟，如果SOA可以向那些掏钱买单的人证明其价值，那么回忆曾经的网络泡沫时代，当SOA所许下的承诺与以往的IT一样时，为何我们不能想见无所约束的SOA花费呢?

　　SOA价值被持续不断地衡量部分原因是SOA都是关于架构的，而将架构做好确是很难。不管一些供应商是如何描绘它的，你不可能仅仅购买一个产品而预期它能奇迹般地创造出你需要的服务以及支持它们的敏捷的架构和组织。在最好的情况下，你能获得一些工具以及创造那些服务的基础设施。与之相对，经验表明成功的SOA实施要求企业花更多的时间改变他们实施IT的方式而不仅仅是他们用来应对短期需求的技术。

　　ZapThink发现SOA实施的最主要障碍不是来源于业务管理，因为它们基本上已经认识到一个敏捷、可重用以及松散耦合的架构的价值(即使他们没有如此称呼它)，而是来源于IT组织内部，他们因为许多原因抗拒向SOA的过渡——而其中大部分原因与业务需求没有多大联系。ZapThink发现在大多数案例中，即使企业已经赞成投入大笔资金到他们的SOA项目中，他们自己的IT组织也能并愿意波坏这些努力，减缓SOA的进程。

　　IT-SOA实施的主要障碍?

　　一个企业自身的IT部门居然是SOA实施过程中的最大阻碍，在表面上看来这并不明显。毕竟，许多SOA概念的起源于IT实践者和技术人员的经验。至今在IT部门中仍有许多人将SOA仅仅看作一个技术概念，这些想法将SOA视为用来开发、保护、运转以及管理服务的一套技术和基础设施。被那些技术迷雾所蒙蔽，这些IT实践者认为SOA不过是类似于Web服务和标准化中间件的东西。理所当然，他们的这种想法是错误的。这种想法的最致命的缺点是将位于服务这个抽象水平之下的技术与服务所使用的架构相混淆，服务通过该架构运用结构化的方法，意图达到减轻执行过程中的消耗并专注于可兼容连续变化的可持续架构——一种与技术观点完全不相容的方法。

　　成功的SOA实施要求实施IT的方式的文化上的转变。为达到敏捷性和松散联结需求的面向服务的运动要求从传统的瀑布式的开发流程(设计——构造——测试——安装——管理)转向一个迭代反复的方式以进行持续服务建模。松散联结的驱动要求一种与以往不同质的方式来计算，这种方式降低了对单个供应商平台和堆栈的依赖性。点对点整合向构成的过程驱动的转移，其从公司层面广阔的资产矩阵中消耗服务，这种方式要求开发和管理方法都必须基于服务域而不是系统具体的点。

　　在面向服务的环境中，治理从有一个漂亮的事后解决方法转移到了一个绝对在第一次使用服务之前的需求。安全考虑则从网络边界转移到了内容具体化的、消息驱动的以及联合化的。因此理所当然，IT以往的做法将作为一个整体从专注于短期项目管理转移到满足长期的持续性的变化的业务需求。所有这些大型的转移显著的改变因此也伤害到了那些认为采用一个接一个的技术新潮相当简单的IT管理者的核心。这可能是因为SOA要求IT实施方式的基本改变，而这在大多数人看来是一种威胁。

　　旺盛的复杂性和对未知的恐惧

　　一种最简单的解释SOA的IT阻力的方式就是，它代表了太多的未知因素，而未知的事物则是恐惧的源泉。很少有人知道如何适当的为SOA做计划，或是如何适当的管理SOA项目，或是如何处理所认识到的绩效表现以及安全问题。因为SOA产生了可与其解决的问题数量相媲美的新问题，于是很多人选择干脆一起避开。一些理由是“当你最起码懂得以前的紧的耦合的整合是如何工作的，你为什么要为这个新的SOA事物而费心?”当然，如果企业完全被对未知事物的恐惧所控制，那么我们可能还处在乘坐马车的时代。创新需要变革，而变革不可能不伴随不确定性。

　　在iT部门，抗拒SOA的原因还可能是因为SOA可能使他们现在的技术过时。如果某人是大型机的专家，而SOA允许一些非专家就可以利用所有的功能模块建立新的应用，而在以前这些仅能被拥有具体系统知识的人所利用，那么这使那些专家反对SOA运动。这里存在一个来自于懂得复杂事物的一定的工作安全性。SOA则是服务于在某些方面简化事物，尤其是那些紧密耦合以及缺乏灵活性的IT方面。这很自然的可以预料到一些人想保护他们的工作，但是这是一个很自私的反对SOA的原因。如果业务的最好的利益要求创新，而这个创新不再需要复杂事物的专门的知识，那么很难不遇到源于个人的反对。

　　这个反对想法的“东西不是越简单越好”诗句的进一步证据可在公众的评论(analogy of comparing SOA with LEGO)中看到。对LEGO缩写的请求就暗示了复杂系统可以被抽象为简单的模块，而业务组织能仅仅需要调节少量的精力到其根本的复杂性上。这也是IT组织内部一些人员以及产业学者批评这种对比的主要原因。对于他们来说，LEGO缩写代表了对实际的IT复杂性的过渡简化。

　　伴随这个推理就是去建议企业应该在组件IT系统时像小孩子堆积木一样简单，这是一个相当危险的想法。尽管如此，这个思路使坚持复杂现状的想法更加旺盛。LEGO缩写之所以如此吸引人是因为商业对与获得IT挑战的过渡简化已经完全失望。很多商业人士已经痛苦地意识到IT的复杂性与不灵活性，并试图使他们相信这是无关紧要的。没有任何必要告诉商业人士他们应该仅仅以复杂的方式来思考IT。实际上，我们所需要的是整体的简化，因为没有任何理由解释今天IT的复杂状态的合理性。当然对为什么IT抗拒这些简化的一个简单解读就是因为复杂性给了那些IT人员的工作——不仅是组织的雇员，还有供应商，甚至分析人员。那些在复杂环境中繁荣的工作在转向简化的运动中将失去很多。