通过观察在面向服务的世界中当下的开发实践，我发现（有些吃惊），有三个几乎毫不相干的领域，有可能会制约或早已经影响了，在业务和IT之间采用面向服务的策略。这三个领域是：

　　（1） 云计算
　　（2） 系统运营支持
　　（3） 外购公司

　　你也对此感到吃惊吗？那么让我们一起来分析一下这些案例吧。

　　正如我们所知，SOA是同时涵盖了业务和技术的一个全球性的范例，这也已为OASIS SOA参考架构基础所证实。这意味着，一个SOA服务是一些人工和自动业务操作的紧密结合体，它是专门针对某个特定业务功能的。在这个结合的过程中，技术的作用因时而异，但通常来说，技术是十分重要，甚至可以说是至关紧要不可或缺。一位分析师如此说道 － “数字时代的现状是，你的业务是包含在你的技术中 — 除非你已经实施了这些技术，否则你不会有业务，只有你的技术发展了，你的业务才可能会同步改变”，这段话描述了越来越多的行业的实际情况。

　　基于上述对SOA的理解，一个主要的结论是，业务和技术需要紧密相关，密切合作。要想使得现代的业务取得成功，技术能力必须和业务“同呼吸，共命运”。面向服务应该不仅仅是一个业务产品的模型，同时它也应该是公司整体业务的一个组织准则。

　　有鉴于此，很显然，SOA并不推崇将IT推到云端的趋势，尽管这是云计算在一直推动的一个发展趋势。公共云计算的确有其合适的定位（主要是那些小型和微型企业，它们很难负担IT部门的开销）。当公司发展壮大后，业务和IT之间的紧密联系将日趋明显。业务中自然的面向服务要求就使得同IT的接合成为一种必然，或至少是要求业务中技术部分的业务完全透明性。这意味着，公司的大量投资将会要求云计算变得更加接近于公司业务，而这却不是公共云计算所期望的。同时，公司的首席信息官CIO将会面临技术选择的十字路口 —— 是否采用业务SOA，由此公司业务可以创造更多利润；抑或采用云计算，由此公司可以获得很快的IT能力？ 孰优孰劣？公共云计算是否能快速适应业务的发展变化？尚未有定论！

　　对SOA一个更危险的反对声音是来自系统运营支持。多年之前技术领导者就发现软件产品（以及这些产品相应的商业用户）一个非常让人困扰的问题是测试不充分和测试被推迟。随着软件开发方法的改进，现在已经要求测试部门从业务需求分析的早期阶段开始就介入软件的开发周期。测试要能够并且必须能够研究架构和设计解决方案，从而验证相关的实现是否符合业务的需求。系统运营支持人员就没有测试人员那么幸运，他们被开发“先锋”们远远抛在身后。

　　在《面向服务的“拦路虎”（下）》中我们会继续为您分析相关内容。