多数SOA技术在SOA范围内都具有一定的价值，但随着我们越来越了解SOA实施和其成功的需要，许多现存的技术似乎都没有带来很大的作用。这是一个在任何技术趋势中都会产生的自然的技术正常化过程，SOA也不例外。
治理是SOA明确的一个要求，你需要一个能够跟踪、安全、界定和维护服务的地方。于是出现了两种截然不同的SOA治理方法：设计时间治理和运行时间治理。
运行时间SOA治理，顾名思义更多的是关于运营要求的，包括实践服务水平协议(SLA)的能力，执行围绕服务的政策，确保服务共同协作支持SOA，由此支持业务运转。这个价值是清楚而明确的，因此多数运行时间SOA治理产品很是畅销，我将此技术看作是SOA成功之关键。
设计时间SOA治理，顾名思义通常提供一个集成的注册表或存储器，试图从服务设计到部署阶段而不是在服务运行时间对其进行管理。SOA设计时间治理的关键组件大体来说包括：
注册表和/或存储器，跟踪服务设计、管理、政策和安全，并测试伪冒品
设计工具，包括服务建模、从属跟踪、政策建立和管理以及辅助服务设计的其他工具
部署配置工具，包括服务配置，通常是通过与外部开发环境捆绑来实现
与测试工具和服务的链接，让开发者或设计者建立一个测试计划和测试情境，而后利用服务测试技术从本质上说，设计时间SOA治理参与了从数据到服务的过程，收集关键信息。因此你一般都从界定基本的数据架构和转变为元数据的转折点(或者是数据提取)开始。进一步你会界定与数据和数据服务互动的服务，而后是更高一层的交易服务，你可以继续定义流程或编排。所有的一切都在设计时间信息的帮助下完成，也就是在设计时间SOA治理系统中发生。
问题在于设计时间SOA治理技术能够从何种程度上为上述真正的“设计”概念服务。多数是达不到这个程度的，因此许多SOA设计师缺少更强大的特色和只能，包括在SOA设计和开发最佳实践基础上的真正建模和模拟能力。因此，多数都绕过设计时间治理直接进入运行时间这是有理由的。
像多数SOA技术一样，另一个问题就是缺少设计时间SOA治理的标准方法。当一些新的标准出现时，许多SOA治理技术已经以自己的方式走上了各自的方向，找不出两个是相似的。因此，你不仅要挑选一个工具，你还要选择设计方式，而这个方式还不一定适合你的架构。我见过的多数SOA项目都被设计来最好利用传统办公司自动化工具，而这些项目似乎都还运作的不错。这对于利用良好设计环境来说是件坏事。不过，好的环境也似乎不存在于现有设计时间SOA治理工具之中。
除此以外，大部分设计时间SOA治理工具将大量的时间花在了对于运行时间问题的担忧上，如服务水平协议(SLAs)，而绝少解决关键的设计时间问题。许多SOA架构师对现有的设计时间选择很失望，转而采取电子数据表作为他们的设计时间工具。很明显今天的设计时间SOA治理厂商在这方面的理解和表现都非常不足。
那么你要怎样解决现有设计时间SOA治理工具的问题呢?
首先,你应该得出一个有意义的高水平方法,再解决如何将这个方法融合到一个更大的SOA设计和配置方法论中去。现有的工具基本上不存在背景，也就更谈不上价值了。
第二，要么是运行时间工具要么就不是，因此你要了解你的工具需要进入到架构哪一个部分。我的建议是选择一部分做好而不要所有的涉及，因为已经有许多不错的运行时间SOA治理工具了。
