在为美国国防部编写的一部ZapThink设计教材中，我们探讨了面向服务架构的质量，我曾指出随着SOA技术实施日益成熟，质量管理在整个服务生命周期就显得尤为重要了。SOA的灵活性要求质量保证减少对部署前的测试活动的关注。一些学生指出国防部要求必须经过九个月的验证测试才能部署新的软件。当然这两个观点并不一致。现在的问题是哪一方应该首先妥协：是国防部还是实施SOA技术的其它机构，是为了保证质量而放弃SOA的灵活性，还是为了灵活性而放弃质量。

　　尽其所能SOA质量

　　答案是二者都不能放弃，这些机构不能为了保证质量放弃灵活性，他们需要重新考虑的是在SOA这个大环境下质量的意义如何。正如 ZapThink 之前所讨论的，我们在解释灵活性以及SOA灵活性模型的元要求时，灵活性要求将如何保证质量复杂化了，因为功能测试和性能测试不足以确保SOA实施能够满足业务灵活性要求。事实上，业务并不是简单地要求技术小组利用A功能或者B功能、C功能去创建某种事物，而是要求他们建造的事物能够灵活地满足日后的要求——尽管这些要求还没有被发现。

　　为了支持灵活性要求，传统的部署验证测试就显得不切实际了，因为验证测试影响了业务所需的灵活性。相反，质量则是一个进行中的过程，需要人们持续的关注和警戒。但是只要业务理解实施SOA这样灵活架构的内在含义，质量本身就不会受到影响了。

　　与此相似的是，电信界出现的SOA质量要求转移到了移动电话网。在早期简单电话服务年代，运输公司必须提交同名承运人的服务质量，递交众所周知的五个九 (99.999%)可行性。但是，到目前为止新手机网络无法完全递交承运人的可行性级别，我们还是会经历掉线，死区这样的事件。那么这是否意味着移动电话的质量不如单老式电话服务呢？回答是否定的，只要你在新环境中定义了质量即电信界所说的“尽其所能”。毕竟网络的组件——移动塔和手机等等——完全都经过测试。整个网络交付电话公司所需的质量。只要基础设施尽其所能完成并维护用户的电话，我们就知足了。

　　SOA质量也是一样，如果我们在质量等式中排除了灵活性要求，我们对这个结果是不会感到满意的。但是如果我们在寻求质量的过程中考虑了灵活性这个因素，结果会令双方更为满意。但是我们还会在质量和灵活性之间进行权衡，这种权衡取决于两个以上的变量。实际上，我们还需要了解更多的内容。