有数不清的文章专注于建立面向服务架构的商业案例，提出可预期的投资收益(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人员的工作——不仅是组织的雇员，还有供应商，甚至分析人员。那些在复杂环境中繁荣的工作在转向简化的运动中将失去很多。

　　架构?我们不需要任何讨厌的架构

　　很多IT的人也相信架构不会作为开发和项目管理的中心以及单独的角色而需要。这些个人觉得架构就是那些理论家在他们自己的象牙塔中的说教，由于未能考虑短期的时间和预算限制，因此未能做出任何可行的建议。对这些从事IT的人来说，令人信服的信念就是有足够的时间把事情做完，而不是把事情做对。毕竟，商业从未能投资于何时的架构和设计，所以为何他们现在要呢?

　　当你倾听SOA反对者的谴责时，这种短视的失败主义是最明显的，他们认为任何意图建立作为项目独立的架构活动都是注定要失败的，因为任何商业都不会简单的为任何需要超出单个项目需要的投资给予预算。当然，这种态度立刻导致了在重用或敏捷性上尝试的失败，而这些努力则是SOA的主要工作。寻求成功实施SOA并实现其主要利益的企业必须发掘那些失败主义者并使他们相信企业将会持续地投资架构以及其长远的利益，即使存在更便宜的但较不敏捷的替代品。

　　企业阻力

　　很多企业曾经破坏了他们自己的SOA努力，因为IT组织不想让SOA这么简单的成功。尤其是那些没有文化共享的许多企业，它们未能意识到重用的SOA利益。这些企业不仅代表了他们的IT系统，也在以系统为中心的情况下隔离了他们的管理团队。在企业中没有任何服务共享的激励，这将单个项目的预算和责任作为一个个的点而隔离。当预算与控制未作适当的调整时，试图建立一个共享的能贯穿多个系统以及管理水平层次的领域服务是注定要失败的。这种企业不仅需要从技术和方法论的角度采用SOA，而且应该面向服务化他们的组织结构。

　　企业也展现了因为将架构和管理隔离为没有控制、授权或是预算来管理或执行架构性建议或决策的小组所导致的功能紊乱。架构在企业中的独特功能就是战略化管理对于IT能力的业务需求，因此架构小组必须拥有监督、控制权利，并对整个企业的SOA项目的结果负责。还有，很多企业让项目经理负责他们自己的“架构”导致了这些企业而今天杂乱如老鼠窝的现状。

　　实际上，很多企业实际上并没有实施架构，而是在做考古，通过挖掘他们的IT环境来发掘他们企业中技术开发长久以来所丢失的文明，并立即将其埋葬，直到某些事情失败的彻底时才被挖掘出来。一个功能性IT组织赋予架构小组预算和权利。这个的进一步证据就是，大多数CIOs并不执行他们应该执行的角色——作为组织架构的战略管理者。有价值的CIO是那些能看到并计划IT的战略价值的人，他们利用SOA和公司架构作为IT组织的中心使命，因为作为一项资产它能提供给企业持续的利益，而不是简单的灭火和战术层面的、不灵活的以及不精确地回应，只是将IT看作一个成本中心。

　　ZapThink的感受

　　这个行业主要专注于说服企业实施SOA，并在某种程度上来说也成功的阐释了SOA商业案例与ROI。但是，使企业信服对于保证SOA的持续成功是不够的。企业需要发现IT组织内潜在的阻力、敌意、怨恨以及恐惧，因为其会有效地阻止SOA的实施与成功。

　　在我们的书Service Orient or Be Doomed，Jason Bloomberg和我写到了“勒德分子的回归”：

　　实质上每一个SOA项目、组织上或人事上的问题解决起来都远比技术上的问题要难得多。人们是如此的灵活，但毕竟，一组人则比组内很多的个体要更不灵活。这种人类的不灵活性存在许多原因——对未知事物的恐惧，对变革的抗拒、有限的视角以及我们最核心的个人激励，追求自己的利益，避免不适与风险。

　　因此，SOA的拥护者必须担当起这个变革代理的角色，要求他们以个人为基础与人们一起工作，并解决人们不愿意变革的问题。那些准备全面实施面向服务的企业必须全面接纳所必需的组织和文化上的变革。

　　这当然是最好的了。