在最近的一篇文章中，Martin Fowler尝试探索演进式设计——一种极限编程的常用实践——对于SOA实现的适用性。他从两种常用的设计范型（计划式和演进式）着手开始讨论：
计划式设计于某一阶段做出设计并在此之后构建（编程）。在这种情况下，一旦你开始建造，设计改动将十分困难。演进式设计假定设计变更是一种常态，即使你已经完成了重大编程亦不例外。我将其概括为，XP的实践为演进式设计提供了受节律的方式，因此使其比人们所认识到的更加实用。这一变化并未摈弃软件设计（它仍未消亡），但是确实深刻地改变了我们思考设计的方式。
计划式设计于SOA中得以支持的主要理由在于：它通过互联、可重用的服务向企业暴露它们公开接口的形式创建了企业IT系统的架构性蓝图。援引Martin的说法：
公开接口很难更改，因此你必须对其进行正确的计划式设计以保证不用去改动它们。计划式设计同时也是对人们在大多数组织所看到的那种混乱系统互联的一个回应。这种混乱就是设计不力的结果，所以感觉上似乎更好的计划式设计将使这种情况在将来不会发生。
但这就提出了关于SOA实现的真实稳定性的问题：
所以当我检查SOA，或者其它任何设计上下文的时候，我提的最基本的问题就是：“变更是可预测的吗？”。只有当变更是可预测的，计划式设计方法才有效。我的感觉是，如果预测在单一应用的上下文中是不可预测的，那么跨越整个企业的可预测性根本无从谈起。如若我们在一个不可预知的上下文中使用计划式设计，我们会发现，无论计划得多么完美，终将被不可知的变更而削弱，带来的仍将是我们现在所处的这种混乱。然而，通常情况下，这种混乱将更加糟糕。因为在计划式设计中有着相当的沉没成本，很容易地就抵消掉了一个SOA成果试图创造的商业价值，特别在市场响应速度（time-to-market）悠关的情况下。
因此，SOA实现的一个基本面应当是演化服务契约作为整体需求来实现变更的能力。Martin提出了增量SOA实现将为实现的每一步产生业务价值这一论点来完成这篇短文：
演进式设计对于SOA的规模也有良好的伸缩性吗？我的观点是，我们已经有一个比大型SOA项目还要大得多的现成证明——Web本身。Web的构建是以非常松耦合的方式，并充满着许多不可预知的变更。它确实，从很多层面上来说，是一团糟——但于这个大杂烩工作得很好，每天都为许多人交付真正的价值。
在SOA实现中运用演进式设计并没有错。这里的问题是要能够把握好计划式与演进式两部分之间适当的平衡。纯演进式自底向上的方式通常会导致基于SOA的集成，往往从长期来看无法交付真正的价值。一种计划式并兼顾演进的方式将会带来更大的成功。
