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

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

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

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

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

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

　　ZapThink采取的措施

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

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

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