服务存储回答下列设计时间问题：
·它的目的是什么(通常是简短的回答)?
·这个服务的版本(包括代码)是什么?
服务存储回答下列运行时间问题：
·谁在一直使用这个服务?
·这儿服务提供的响应类型是什么?
·这个服务发生了什么问题?
最后,重要的是指出许多厂商正在积极地把注册和存储结合在一起。无论你是否采用集成的解决方案，明智的做法是保证你的投资能够解决上述问题。
策略8：当选择一个治理产品的时候，写一个计划良好的正式的RFP
适用范围：所有的阶段
首先，重要的是你要知道你需要什么：没有任何东西可以替代家庭作业和准备。在选择数据库、应用服务器或者其它关键的基础设施技术的时候，你要采取同样的原则和流程。不要试图采用一个样板的RFP(征求建议书)，要保证它反应你们的机构的需求。
如果你不能编写这种文件，你可以认真考虑雇佣一个不依赖于任何厂商的外部咨询机构为你编写一个文件，然而，你要记住，如果你利用外部的帮助进行设计或者实施你的SOA，要设法把创建RFP的过程与技术厂商分开。这很容易想到严重的利益冲突。接下来，让厂商认真考虑你的RFP并且做出相应的答复，重点是质量而不是数量。最后，一旦你缩小了选择的厂商的范围，通常是要求这些厂商参加一个试验计划或者概念证明。
策略9：避免需要修改代码的治理工具
应用范围：设计时间和运行时间
为了提高效率，有些产品需要修改一些代码，如加入特殊的头文件，设置文件或者连接专有的库。这需要开发人员完全遵守规定。即使在最优惠的条件下，这也是很难获得的。如果部署一个没有这些增加的组件的服务，你就不能获得你的环境的真实的情况，从而导致基于不完整的和不准确的数据的错误决策。除了使你的开发人员的生活更复杂和减少有效的治理的可能性之外，这种专有的扩展还会严重地破坏你的不依赖于任何厂商的机会。由于这些原因，你部署的任何治理解决方案都要尽可能地在没有干扰的情况下工作是非常重要的。
策略10：要保证治理工具适合你现有的IT环境
应用范围：运行时间
对于大多数机构来说，实施一项面向服务的计划都要采用许多新的工具集、流程和方法。治理仅仅是增加的一项考虑因素之一。不过，需要指出的是这对于大多数企业来说都不是一个新的话题。事实上，以IT为重点的治理技术已经存在多年了。一些最知名的产品包括Tivoli、OpenView和Unicenter。这些软件频繁地用来监视服务器、客户机、网络和软件应用程序的健康。IT机构对于这些解决方案有广泛的知识并且依靠这些知识保持业务顺利地运行。
随着服务成为你的计算基础设施的较大的一部分，强迫你的IT机构学习和维护完全不同的工具集是不明智的。理想的情况是你的SOA治理工具应该与其它IT管理平台集成在一起。过度的复杂性和培训的需求会减少治理软件使用的机会。
