最近，一份Forrester的报告把服务存储描述成服务治理的基础：

　　有效的服务治理的远景和目的是有效地开发、运作和交付有价值的且与业务对齐的服务。为了实现该目的，IT必须要实现自我转变，从拥有众多技术和功能竖井（silo）的组织转向可靠且经济地提供服务的业务。企业的态度，行为以及文化必须转变成服务提供者的。转型的第一步是建立一个用于描述支撑业务服务乃至业务流程的IT服务服务目录。

　　尽管WebLayer的Chandu Natarajan赞同该说法：

　　毫无疑问，注册存储对于面向服务的架构的成功至关重要。毕竟，作为更大的治理战略的一部分，注册和存储在管理服务元件、管理服务的生命周期、消除冗余和促进重用等方面都起着关键的作用。

　　但是，是否要部署一个完全成熟的注册存储应由公司的大小以及公司拥有的服务的数量决定。

　　根据客户的经验和反馈，服务注册和存储在有以下需求的环境中是最佳的：

　　要管理的服务多余50个，这些服务可能是

　　内部创建的或通过外部资源横跨架构的。

　　在企业范围内动态发现服务。

　　为了社区重用而向公共注册库暴露服务。

　　通过使用高级安全，政策执行和审计能力等支持广阔的合规法则。

　　为服务执行广泛和持久的审计和日志，检验运行时SLA等。

　　据Chandu，在设计时用于存储SDLC元件的现有的企业存储库(如源代码控制系统)在多数情况下即可用于管理服务、服务相关的元数据和其他服务相关的元件。

　　当然，治理可以而且需要补充注册于存储。然而，治理战略并不一定需要注册和存储辅助架构师们进行政策执行并获得更高的可视性以消除(为支持SOA的业务目标而设计的)开发软件带来的风险。

　　而且，简化SOA实施的探索从没有间断。当然你可以说有了SOA治理，使用什么工具并不重要：

　　……怎么治理由你，但是要治理

　　但是，这其实不算什么观点。首先，在SOA治理中，服务注册和存储之间差异很大而且服务于完全不同的目标。第二，（用于创建IT工件的）SLDC工具是否能真正适用于要求IT和业务人员紧密配合的服务治理还有待商榷。最后，为什么临界点是50？它有什么特别之处吗？