ZapThink的不断变化，发布的集成化成本曲线，从2002年一直到今天，引发了ZapThink设计师的广泛讨论，讨论的核心是，当业务需求改变时，建立在传统中间件基础上的集成有可能导致不可预知的成本，如果用面向服务架构（SOA）来解决集成化问题，成本的浮动则相对平缓。实施SOA意味着寻求改变，由此引发的争论一直不断，成本总是有的，但是一个灵活的设计师能够减缓IT集成成本的上下浮动。

　　到2008年底，虽然ZapThink一再警告大家不要在SOA中率先采取ESB方法，但是，迫于供应商的压力，大多数机构还是首先采用了ESB方法，即“SOA平台”方法实施SOA。正如我们在ZapFlash所提到的，使用ESB实施SOA是有可能的，并且许多机构都是这样做的——但是最佳的方法是把ESB看做是服务中介物而不是集成中间件，在集成成本曲线这个环境下采用这个方法，当要求增加时，ESB做为集成中间件的这种做法就会导致成本的突增，由此降低了SOA的净成本，只有机构在SOA中首先实施架构方法，机构才有可能实现其收益。

　　用于中间件的中间件

　　目前市场上出现了这样一种趋势，一些机构试图缩减以平台为中心的SOA实施，但是他们很快遇到了麻烦。因为当今企业的规模，没有一个单一的平台能够满足整个机构SOA基础设施的所有需求。因此，我们必须就不同的业务部分实施不一样的平台——即那些分析人士所说的“SOA域”（读者不要把此命题和ZapThink 2004年提出的服务域弄混，这种服务域是在业务为中心的理念下提出的）。相反，SOA关注SOA平台以及操作这个平台的服务。因此，对SOA措施的缩减需要不同SOA域间的互操作，这样我们就会遇到许多SOA域之间互操作和合作问题。

　　这里隐藏着SOA平台为中心方法的最大问题：因为这种方法依赖于集成中间件，因此那些SOA试图解决的中间件问题也势必会影响到这种方法的实施，即灵活性的缺乏以及集成成本的不断增加。从根本上说，你需要更多的中间件运行SOA中的ESB，以确保这些域可以相互协作，完成互操作。现在可以用这种方式实施这种方法了，但是，如果不能实现业务灵活性或者节省成本，那么还干嘛费力采用这种方式呢？

　　更有趣的是，Forrester Research公司Mike Gilpin提醒我们要对这个问题做更进一步的思考。虽然他的研究进行的紧锣密鼓，似乎是天衣无缝，但是结论却不完整。自从企业有了SOA平台策略之后，他的观点就变得不完整了，当这些企业开始缩减SOA措施时，它们需要的更多SOA域之间的互操作和合作，而这样就需要更多的中间件，而Gilpin却没有看到这点，这就是归谬法：如果你认为SOA的实施依赖的是SOA平台策略，那么最终你的中间件就需要中间件了，这样就会最先降低SOA给架构带来的收益。因此，SOA不应该依赖SOA平台策略。

　　果断地采用无ESB SOA

　　ZapFlash没必要知道，为什么我们从架构角度而不是以集成为中心的角度来看待SOA。之前我们在ZapFlashes中探讨过这个话题。我们认为没必要迫于供应商的压力而采用SOA平台方法。我们也解释过架构驱动的基础设施，也谈过中间物形式，阐释过对松耦合的意义，并且关注业务服务抽取的建设和维护。