在这个市场演变的时候，各个组织看起来懂得什么是SOA，也明白为什么他们应该这么做，但是关于如何以一种保证业务收益且能持续运营的方式来实现SOA依然存在着广泛的争论。

　　在最近一次会议上，一个企业架构师向ZapThink哀叹道，他的组织原本计划在2003年就开始涉足面向服务的体系结构(service-oriented architecture，SOA)的，结果两年过去了，他们居然进展很小。除了沮丧，他还受到了来自他同事的压力，那些人指望从他的进展中得到升级。不幸的是，这个架构师并非孤家寡人。很多组织都发现把SOA应用于实际比他们预期的要更加困难。

　　在这个市场演变的时候，各个组织看起来懂得什么是SOA，也明白为什么他们应该这么做，但是关于如何以一种保证业务收益且能持续运营的方式来实现SOA依然存在着广泛的争论。有的公司发现把组织的、技术的以及架构的问题综合在一起，结果却是使他们在SOA之路上停滞不前。而另一些公司则缺乏从业务经理那里得到足够支持，以使SOA度过试验品阶段。实际上，我们已经辩识出一些阻碍公司在SOA上取得更大进展的具体障碍。以下就是其中最要紧的几个:

　　与真正的互操作性还相去甚远 今天，SOA的远景取决于在异构系统中的松耦合交互，并且这个远景还取决于基于标准的互操作性。毕竟，交叉产品、交叉平台的互操作性是Web services存在的理由。然而，就算所有的工作都服从标准团体和Web services互操作组织(Web services Interoperability Organization，WS-I)，可是还是有公司报告说，即使在实现最基本的Web services标准——SOAP和WSDL时依然有少量的但却是很大的差异。假如供应商不能使他们的SOAP和WSDL进行互操作，那么在计划中的更多标准又怎么会有希望呢?要跨越这个障碍，公司必须使他们的供应商至少要适应大多数基本的服务标准。假如供应商不答应，就替换他们——想得到你业务的供应商比你想的还多呢。

　　很少有人知道如何写合约或者策略 ZapThink最近问询了很多企业架构师，他们是否对达成服务合约有什么主意，因为那是抽象出服务提供者和消费者之间的接口的关键元数据文件。一些架构师用WSDL实现了基本的合约，但还没人超越WSDL的局限性，用更多的元数据来描述服务级别、安全性或者其它策略信息。实际上，很少有人知道怎样把基于人类语言的策略转换成软件能懂的元数据。正在开发的标准WS-Policy也只提供了策略容器，而不是策略本身，而且几乎没有任何公司已采纳WS-Policy。

　　公司缺乏具有合适技术的架构师 软件架构的规则在企业中依然存在广泛的误解。除了这种误解，还存在很多类型的架构说明，而大多数架构师只熟悉一到两种。做为一个面向服务的架构师，他需要有对企业架构的扎实把握，并且对技术架构、信息架构、业务过程架构和数据架构非常熟悉。有这些技能的人真是凤毛麟角。组织必须在将来意识到这一点，架构师比开发者更有价值。

　　标准还不完整，很局限，欠考虑 一些标准团体和他们的供应商成员已经建立了详细的路线图，用于被推荐的标准、涵盖的集成、管理、安全性等等。诚然，他们在按照路线图装配这些标准上已经取得了很大的进展，但是距离让我们拥有一个一致的、完整的SOA互操作标准还有很长的路要走。除此之外，有的标准过于局限甚至更糟，更欠考虑。比如，WSDL就是被认为过于局限的标准，因为它没有描述服务消费者的服务级需求或合约限制。欠考虑的标准还有UDDI和WS-BPEL。UDDI多年来不能改变优先级，而WS-BPEL则融合了两个不合前驱的说明书，并且缺乏工作流能力。

　　整体策略 在很多组织中，业务部门和IT部门有时结合得很紧密，而有时则对立得很厉害。业务管理部总是经常把IT部门看作是高风险的烧钱部门，于是在公司执行战略目标时设置各种限制。同样的，IT部门的人在提到组织中的IT历史时不愿意提及开销超支、项目失败以及对底线毫无帮助的很多活动。然而，这种在业务和IT部门之间根深蒂固的缺乏信任使得任何SOA行动都变成一场政治困局，于是IT部门的头不得不在这种情况下为依旧充满潜在风险的架构方法做大量的艰巨的解释。因此公司在实现SOA时，必须在他们的实现中体现早期的、持续的业务收益，以此来降低这种紧张感。一个22个月的SOA项目变成18个月可能都还是嫌时间长。只有短期、迭代、高价值，才不会让你的业务管理部门阻碍你前进。

　　产品选择要么过于琐碎要么过于以集成为中心 没有软件或硬件产品会给组织一个SOA(或为出于相同原因提供其它架构)，但是任何SOA实施都需要新的产品来应对对松耦合、组合、密集元数据、面向服务的新的需求。尽管一些公司已经加入了专门SOA产品的争夺、但问题是你需要装配很多供应商的不同产品才能得到想要的功能，而且这些供应商在像上面提到的那样为互操作性而争吵。于是靠大厂商来救驾，而他们每一个都试图提供所有的SOA产品。但是，这些厂商发现他们不过是在升级他们以前的集成中间件产品，然后把它们揉成新的SOA基础设施，却不管它们如何适应SOA。随着时间推移，SOA解决方案市场会稳步增长。那些先规划架构后选择产品的公司将会更好，更平滑地过渡到SOA。

　　怀疑、自私与顽固 抗拒变化是人的本性。尽管SOA的局限和问题已经被明摆出来，组织中依然总是有人抱着怀疑的态度而不是用理智的态度去对待诸如平台选择、供应商偏见、个人偏爱等问题中的情感因素。此外，有很多人抗拒新方法，不是因为他们真的看到了新方法中的问题，而是仅仅因为他们对他们现有的技术很适应，而不愿意学习任何新东西而已。另一些人把他们的影响范围看做他们个人的城池，当他们的群体外部有人开始谈论共享服务或联邦策略时，他们就拉起吊桥，然后从城墙上放箭。那些希望他们的SOA项目获得持续进展的公司，应该不仅要识别那些推动面向服务的勇者，也要识别那些一旦认为是威胁就予以阻止的拦路人。

　　ZapThink的做法

　　和任何好教练一样，当有东西阻碍队员们发挥他们全部潜力时，他就该发现问题、指出问题、帮助他们解决问题议以使他们回到正轨上。假如SOA团队丢了球，那么教练就会大声吼叫——但这不是因为教练认为团队不能完成任务或者比赛不能取胜。相反，教练对团队大声吼叫正是因为所有团队在困难的时刻需要的就是这种粗暴的关爱。因此，当上面列出的阻碍成为问题时，你就能克服它们中的每一个。秘诀就是一步一个脚印的做事情。ZapThink把采用迭代的方法达到SOA作为一个关键的最佳实践，不仅是因为需求总是不断变化的，也是因为在通向成功实现企业SOA的道路上有很多跟上面提到的那些一样的拦路虎。

　　架构师不能及时跟进怎么办?培训他们。标准不够成熟怎么办?修补它们。组织中有太多自私且顽固的人怎么办?取信于他们或者重新分配工作。供应商和你兜圈子怎么办?施压或者替换他们。这样，上面提到的障碍将没有一个阻碍会你初步实施高层SOA的规划或装配一些松耦合的服务。障碍可能使你变慢，但毫无疑问的是，现在有很多主要组织在考虑SOA，基本的SOA业务收益毕竟多与它的缺点。耐心点，坚持下去，准备学习新的东西，这样你就会最终成功实现你的SOA。