任何公司都需要知道他们当前的情况。尤其对于IT部门而言，非常渴望有办法能够衡量工程的进展，很多业务人员认为这是难以捉摸，难以预测的，甚至是不可靠的。有一种严格控制的这些所有不确定因素的方法是在企业的IT工程中应用一些业内的度量标准和措施。用这些措施，公司能从理论上决定他们是否领先于他们的竞争对手，使他们的IT工程大体上朝着正确的方向迈进。很多公司指望某一种业内的成熟度模型能满足他们的需要。然而，这样恰使多数成熟度模型未达到预期效果。

　　多数情况下，公司都对这些成熟度模型趋之若鹜，像赫赫有名的能力成熟度模型集成（CMMI），而没有并充分地理解他们衡量措施的意图。现在，这个ZapFlash不是为了说明什么是CMMI或CMMI和SOA成熟度模型等同关系……他们相互之间无论内容上还是上下文都没有什么关系。然而，多数SOA成熟度模型都试图在结构和格式上效仿CMMI，却没有认识到它们之间其实并不相关。

　　在不考虑组织的大小、地理或行业之外的因素下，很多对专断的成熟度措施抽象地衡量一个组织。零售部门、IT组织和财务部门面对同样严格的IT度量管制有意义吗？在组织内一切活动的平均水平上进行成熟度因素的衡量，是最先进，还是最落后的？成熟度模型是在部门和部门的基础上，还是在每个工程的基础上衡量公司组织范围？在没有理解成熟度模型衡量的是什么的情况下，很难说它是真正的成熟度衡量。

　　更重要的是，这个成熟度模型想促进什么呢？对很多公司而言，达到某个成熟度层次主要是对终端用户具有市场价值。其他成熟度模型主要被用来推销一些厂商的产品。而意在提升组织中采用某个IT实践状态的极其少见。如果最流行的成熟度在这都没达到预期效果，那么SOA成熟度模型也更是如此。根据讨论，我们无法从数量上衡量成熟度，那么在这个SOA成熟度模型的ZapFlash中我们还能找到什么，多数SOA成熟度模型都属于以下三个阵营中的其中一个：模糊不清的，主要基于服务实现，而不是服务架构的抽象模型，试图通过SOA架构的采购决定来推动客户度模型的厂商驱动模型，和试图通过尚未被证实能真正提高SOA状态的练习架构推动客户的顾问驱动成熟度模型。

　　我们已经清楚行业内事实上并不需要SOA成熟度模型。合理的实施SOA行为本身就是很多公司费尽周折寻找的成熟度架构。公司都试图了解如何成功应用SOA并领悟到对他们自己的业务目标的益处。就这点而论，并不需要这些抽象的，企业范围内，行业范围内，遵从CMMI五个级别的人为衡量的成熟度，只是对SOA自身根本目标实现SOA状态的衡量方式：即敏捷性。