在《用顶层客户群驱动SOA：架构驱动的SOA范式》中，Rick Sweeney为我们介绍了一种架构驱动的SOA范式，下面将介绍SOA的EA方法以及在采纳架构驱动的SOA范式方法时遭遇的阻力。

　　什么是SOA的EA方法？

　　Sweeney：真正的问题是，业务思考/定义/审视/资助IT需求的传统方式已经被体制化为基于单根烟囱式的解决方案；IT和PMO（项目管理办公室）的工作方式也都已经被体制化；这三方面的工作与SOA的概念都是背道而驰的；对于全面推动SOA来说，这些都是不可逾越的壁垒。

　　我的书描述了如何去组合形成一个SOA的商业计划……该计划并非有关于我们要去按照这种次序来交付这些方案，其讲述的是我们如何去改变人们的技能，所使用的流程，以及开发框架所需的围绕着架构技能的实践，从而，当我们进行这个业务活动的时候，我们能获得合适的人、适当的流程、适用的实践以及匹配的平台。这就是一个受监管的实践所应当运营的方式；就是SDLC所应该呈现的样子。比对一下你的当前环境然后进行差距分析。识别出那些鸿沟以及行动项目。

    架构限制延缓了接受SOA的进度具体指哪些方面？

    Rick Sweeney：在建设SOA解决方案的时候，几乎没有一家公司能开发出开发框架和应用标准的产品组合。而解决方案……也不是在更大的SOA图景的背景基础上设计出来的。它们并不把处理诸如个性化和例外情况这些问题当做设计原则。SOA并不仅仅是Web服务；已经建设出来的东西更多是查询或单向数据提供。一旦你进入更为复杂的交易事务和业务流程里，对于例外应该进行处理，登录如何去处理等等，这些事实上你没有框架可以参考；你不得不深入挖掘到每个服务的内部，以便找出究竟来，从而你最后又弄出了多样的逻辑机制之类的东西，因为做出的所有决策都是针对单个实现而定的。缺乏了架构这个组件，延缓到了SOA的采纳。

    在书中我谈论了SOA的开发框架和设计模式。比如个性化的框架，比如语种选择，或者如何验证用户使用权限的框架。每一个服务应当都可以理解和应用设计框架的属性。它们是在大多数环境里缺失的那种框架类型，使得服务是以孤立的方式建设出来，而非成为企业级解决方案整体的一部分。