传统的软件质量管理包括设计时间和部署时间活动。从根本上来说，就是在一定的要求，一定的时间限制下，在一定的预算支出下，尽可能的保证其完整无缺性。并且监督工作中的软件，确保其能满足你部署的要求。对于那非常有效些已经预先知道自己要求的机构，在这些要求稳定之后，当设计软件满足了这些需求之后，这种方法十分有效。

　　这种假设经常是错误的——在大多数情况下，当要求还不成熟时，会随着时间的推移而改变。最典型的，在没有返工的情况下，软件的目标就是对要求的变化做出回应。在这种情况下SOA十分有效。而且只是针对当下要求的方法不再那么有效了，这也是促进SOA发展的主要因素。

　　运行时间的质量管理就是答案的一部分。确保运行软件服务的质量，无论这些软件有没有被抽取为服务，都是系统管理价值主张的关键性组成部分。SOA管理则增加了服务抽取的运行时间管理。管理服务抽取要求确保要求变化的质量。尤其是非功能要求，例如性能。高效的SOA管理同时也要求处理运行时间例外管理以降低故障的级联影响，保持松耦合。

　　市场上现有的SOA管理工具都能处理运行时间SOA管理。在面对要求变化时，这些工具的用途不是质量管理——变化时间。在这些变化中管理质量意味着管理元数据的质量。因此，这样的变化时间质量管理关注元数据，要是这些元数据能够满足这些变化的要求。这样的要求有两类：持续的日常要求（重新配置可以解决）和更意义更广的灵活性元要求。

　　正如ZapFlash先前的研究结果所示，至少有三种日常的变化时间要求：服务合同变化，策略变化，服务构成变化。不管这些元数据如何变化，要保证质量，必须要确保服务基础实施能够支持变化，还要确保新近配置的元数据满足重新配置的要求。SOA管理工具可以解决前面的这个问题，但是后面的这个问题很难处理。

　　SOA的重新配置的开放源特性导致了变化时间元数据质量的复杂性。如果设计师不能提前做出规划，引进的这种计划很可能完全无法预测，无法管理。从根本上来说，SOA支持用户授权，如果缺乏相应的治理可能产生混乱的局面，需要时刻记在心上的是，要把变化时间元数据质量保证当作策略来抓。为了能够建立、通信并强制执行针对基于元数据的变化策略。你就可以创建和其它治理处理的策略了。

　　描述灵活性的元要求

　　如果能将变化时间质量保证看作是一项策略实施，也就规划了整个SOA质量工具蓝图：设计时间质量的测试工具，运行时间质量管理工具，变化市静安质量治理工具。但是，将变化时间质量降级至治理领域就将问题变成了如何在第一时间创建策略。为了解决这个问题，我们还要回过头来研究灵活性的元要求。

　　当企业架构小组坐下来一同讨论SOA措施时，他们会问许多和SOA实施有关的问题，即这些机构究竟需要何种程度的灵活性。他们将问题的答案归纳为以下几点：

　　服务重用的业务要求是什么？业务会在重用时考虑到成本节省以及其它量化问题吗？

　　松耦合的要求是什么？我们将这个问题分成若干层次：语义层面，数据层面，通信协议层面，以及WIRE协议层面等等。

　　这项实施的用户环境是什么？例如，服务需要支持多少用户？他们都是内部用户么，还是你也接受外来用户？什么用户才被准许更改配置呢，在什么情况下可以更改配置？

　　什么是元策略？换句话说，什么是策略管理机构建立和执行策略？

　　需要注意的是，首先，所有这些问题的最后结果将是一套策略。其次，类似的问题不会关注特定功能的要求，也不会重视你在传统项目建立的软件。相反，这些问题最终又落到了灵活性问题上——即你的机构想实现何种程度的灵活性，更重要的是，在那些地方对灵活性的要求不是特别高。如果能找出阻碍SOA措施发展的障碍，就会节省足够的时间和金钱，也能帮助我们进一步讨论变化市静安质量策略。

　　ZapThink采取的措施

　　尽管将变化时间质量看做是治理问题降低了SOA用户授权的风险，但是，治理并不是完全自动化的，实际上，大部分治理活动都是人为的：训练，组织，管理以及其它人与人之间的沟通活动。SOA治理框架将所有的治理部分连成了一个整体。不管现在的SOA治理方案如何复杂，人为因素依然存在。

　　例如，一家机构有一项策略，所有的服务组合在实施以前必须经过经理的审核。这项策略很显然就是变化时间质量策略，尤其是有相关的策略指导经理人时。有一个工具可以简化这个策略的实施，但是它不可能取代管理者的作用。

　　其次，你们中有些人可能意识到了一个重要的例子：如果元数据质量是策略问题，包括策略元数据本身，你怎样能确保应用到你质量策略的这些策略的质量呢？答案很简单：元策略层面的质量是由人提供的。假如你有一个策略，所有的服务合同必须符合机构制定的某个特定服务规范，将这个策略的实施自动化很简单，但是要确保策略的质量就取决于人了：阅读元要求表看策略是否还在，确保别人能够理解其中的道理。这些活动对于人类来说很简单，但是却很难自动化。