Joe引用的这两份报告都就如何对SOA量化提出了自己的观点，并分别给出了一系列量化指标。它们一份来自Symphony Services的CTO Jerry Smith博士所写的《SOA并没有死亡，而只是需要被有效地进行量化》，另一份则来自于Red Hat的CTO Mark Little博士所写的《你必须知道的SOA重要度量指标》。

Jerry Smith在其文章中认为量化是进行正确决策的基础，为此必须定义出一系列的量化指标。同时，他认为这些量化指标应该是和公司的业务目标一致，而并非那些传统的软件开发指标，因为后者无法帮助你说服CFO给你提供必需的资源。在文章的后半部分，Jerry Smith给出了他认为的面向业务的SOA度量指标：

1. 服务的活跃指数，它跟踪新服务在过去12月内收益占服务收益总和的百分比。Jerry Smith认为该指标可被用来度量SOA的投资价值。
2. 每个服务的收益，这将使组织可以定量地评估服务的价值和SOA的生产率。
3. 新服务产生和使用的数量占服务总数的百分比，创建不必要的新服务不仅是SOA治理不力的表现，而且还会造成服务开发整体成本的上升和服务平均收益的下降。
4. 服务开发平均时间，该指标给企业度量业务机动性提供了方法。
5. 服务变更平均时间，该指标同样跟业务机动性相关，了解该指标有助于企业发现那些设计蹩脚、导致企业成本上升的服务。
6. 服务重用，该指标会影响服务开发平均时间和服务变更平均时间。
7. 服务不可用或停止带来的成本，该指标直接影响到了用户体验，进而给企业的机会成本造成影响。
8. 服务的可用性，该指标定义了服务可被最终用户使用的时间百分比。

Mark Little强调了治理的重要性，同时认为软件虽然对治理是有益的，但是单有软件并不能实现治理。从指标上看，Mark Little和Jerry Smith不乏相似之处。在他看来，SOA的重要指标是：

1. 每个服务的投资回报（ROI），Mark Little特别提到了组合服务的情况，即几个服务一起来完成一个业务任务，此时应该度量的是服务组合，而不是各个服务。
2. 每个服务的收益，该指标和ROI息息相关。
3. 服务的增长率/重用，建立这个指标有助于防止大量开发不必要的新服务
4. 业务机动性，它是指服务从设计到部署的总时间。
5. 可靠性，它反映到了两个时间上：平均故障时间和平均恢复时间，而且Mark特别指出，你不仅应该度量服务的这两个时间，而且应该对机器和网络的这两个时间进行度量。
6. 服务的内部依赖，这将有助于度量某个服务退役之后对业务带来的影响。

对于两人的报告，Dan Foody认为他们都没有切中要害。

首先，他提出“如果你无法获得资助去完成SOA，那么度量SOA意义不大”。他认为“如果你想让SOA落地，那么你需要寻找的是那些在短时间内产生巨大回报的小规模投资”。其次，他认为这些报告存在的第二个问题是“有意义的度量指标”，即度量指标是很重要，但是每个企业各不相同。

如果你是服务提供商企业，你当然可以度量像“每个服务的收益”、“服务活跃性”，以及关系服务收益的ROI。但这和SOA有什么关系？！早在SOA存在之前，人们就已经在构建和交付可以产生收益的服务了。而且，这些度量指标如何作用于那些并不是销售电子服务的公司？对于联邦快递的免费跟踪包裹的Web服务，其直接的ROI是什么？

Dan Foody认为，应该同时度量使用SOA和不使用SOA完成业务的成本，否则度量将是不完整的，而且可能会产生误导。因为两种方法产生的收益可能一样，Dan Foody以联邦快递为例说明了这点。在文章的结尾，他写道：

你必须现实点：

• 不要关注那些“可疑的”指标（如“SOA的ROI”）——业务不会相信你。
• 不要关注那些要多年之后才能测量出的指标（如“某某平均时间”）——业务不会听你。
• 成本越低，你需要进行解释就越少。
• 风险越低，你需要进行解释就越少。
• 你能越早展示可察觉的收益，你就越不需要操心度量指标。

度量指标在SOA有其一席之地——有助于让SOA随着时间不断进化。但是，人们只有在看到结果之后才会相信这些度量指标，这就是你为什么不能以度量开始的原因。使SOA基础设施落地的最佳途径是时间已经证明的老方法：找一帮聪明的实干家（不是演说家，也不是空想家），使用SOA快速地交付一个重要项目。使用这种方法，将能对SOA的能力赢得共识。