策略3：保证你的治理平台能够支持全面的服务部署技术

    应用范围：设计时间

    虽然许多人错误地认为Web服务是实施SOA的唯一方法，但是，还有许多其它技术能够同样好地完成这个工作。这些技术包括Java对象、CORBA和其它服务实施技术。考虑到这些事实，无论你选择什么实施策略，你的治理平台能够识别和兼容广泛的服务是非常重要的。治理解决方案应该尽可能地不受干扰，因为它不可能修改你的机构现有的服务。

    如果你不能选择一个满足这些要求的解决方案，那么，你就只能治理你的企业的一部分，或者需要部署多个治理平台。这两个结果都是不理想的。部分治理与根本没有治理差不多。许多管理员和程序员在克服与治理有关的问题时都选择了错误的道理从而浪费了许多时间。

    策略4：认识到测试作为你的整个SOA治理责任的一部分的重要性

    应用范围：测试和治理保证

    一个令人遗憾的事实是，质量保证经常在软件开发的各种要素中摆在次要的位置。虽然这在制造传统的竖井式的应用程序时也许是可以容忍的，但是，这种做法在实施SOA的机构中不行的。由于服务构成了多个应用程序的基础，用适当的时间和注意力进行测试是非常重要的。治理保证的整个范围也将扩大：重要的是你的测试要超越单个的服务，包含多个服务的复杂的组合。组合测试通常需要大量的性能驱动的回归测试。由于运行时间组合应用是很难分辨的，也许有必要使用观测或者其它监视技术确定真正的服务相互作用。最后，由于服务和治理的关系非常密切，认真考虑把你选择的测试软件结合到你的整个治理环境中是明智的。

    策略5：搜集重要的与治理有关的测量结果并且定期进行评估

    应用范围：运行时间

    现代治理平台能够捕捉大量的运行数据。这种信息的真正质量是很高的。遗憾的是，当面对海量的统计数据时，管理员会忽略这些数据，除非有需要直接修改的问题。这里的教训是仅仅搜集测量数据是不够的，你需要评估这些数据并且对这个数据采取行动。你可以使用许多智能产品了解你搜集到的海量数据的意义。

    策略6：通过多个IT资源层跟踪活动

    应用范围：测试与质量保证/运行时间

    虽然一个面向服务的计划旨在把商务逻辑集中到一个可再利用的、可组合的服务集合中，但是，重要的是不要忘记这些服务通常要面对许多现有的资源，如数据库、应用服务器、对象等等。这个结果是一个架构由许多“移动部件”组成。由于这些潜在的故障点，这些问题很难解决是很自然的。简单地找到这个问题的根源就是一个繁重的任务。在许多情况下，这个问题不是服务的错误，而是底层资源的问题。

    然而，用户并不在乎问题发生在什么地方，他们只需要解决问题(或者避免这些问题!)。如果要解决这个现实问题，重要的是你的治理平台除了跟踪和解决传统的Web服务问题之外还能够监视和解决其它问题。通过向管理员提供所有技术资源的全景图，一个设计良好的解决方案能够帮助阻止发生这些问题，帮助迅速解决发生的任何问题。

    策略7：消除存储与注册之间的障碍

    应用范围：运行时间

    这两类产品之间存在许多混淆的概念，包括不同的定义和对责任的解释。然而，不管这些产品的具体解释是什么，这两种产品在有效的SOA实施中都发挥着重要作用，包括在设计和运行时间阶段。下面解释这两种产品在这两个重要阶段是如何使用的。

    服务注册回答下列设计时间问题：

    ·服务在哪里?

    ·它的目的是什么(通常是简短的回答)?

    服务注册回答下列运行时间问题：

    ·这个服务的版本是什么?

    ·这个服务的合同在什么地方?

    ·这个服务的政策实际上是什么?