SOA监管是一个复杂的主题。与SOA监管有关的事情非常繁杂，令人头疼。有技术元素，如注册库或存储库、策略管理、策略实施代理、安全性提供者、服务虚拟化，以及看似无穷无尽的其他技术列表；但还存在非技术元素，如组织结构、激励模型和监管流程。因此就出现了我们的问题——SOA监管有着如此之多的元素，我应该在何时、何处开始？如何入手？

　　我做的是产品营销，所以，您应该期待看到关于应选用哪种技术的答案，无论我提到了哪种产品，都应假设我准备告诉您这就是正确的产品。毕竟，这就是大多数产品营销人员的做法，对吗？好吧，一会儿我就掀开我这种产品的盖头来，现在是目标明确的过程。

　　有两件事需要先说明。第一，SOA监管需要的是多种人员、流程和技术的协同努力。如果仅关注一个方面，忽略其他方面，那么就只能得到一个不完整的监管解决方案。第二，对于何时、何处、如何应用监管这一问题不存在错误答案。

　　让我们从“何时”开始。简单的答案是：无论何时开始应用监管，都不会太早或太迟。然而，与尽早开始监管相比，较晚开始监管的机会成本很高。理论上来讲，一旦有了一个服务，就应该开始应用监管。遗憾的是，通常事实并非如此。大多会等到出现问题，且其SOA引入了过多的混乱而非解决业务问题时。一旦它成为问题，再去纠正方向、应用监管，成本就要远远高出在SOA计划中较早开始监管的成本。因而，不应等到遇到麻烦才开始在组织中实施监管。如果腿上有伤，您会等到无法走路时才去看医生吗？

　　接下来是“何处”。SOA监管应深入组织，跨越IT和业务的边界。许多人错误地将SOA监管与监管服务联系在一起。这并不完全正确。您需要监管所构建的服务，包括功能和业务服务，但也应为BPM流程应用监管，因为BPM流程很可能称为SOA工件的消费者，此外其自身也有可能会作为服务公开。最终，尝试管理整个项目时，在各个独立资产的级别上进行监管可能有些过分，还应在项目级别上应用监管。

　　最后就是“如何”。要讨论这个问题，就要花一些时间思索要考虑多少个方面，这样我将在某些入口点使之保持高级别。启动SOA监管计划的方法有许多种。可以归结为您的麻烦在何处；您希望得到怎样的结果。示例如下：

　　您已构建并部署了服务，但目前还没有对于存在哪些服务、它们用在何处或连接到其他哪些资产的可见度。在这种情况下，您可能希望首先使用一项 SOA管理 解决方案，来覆盖服务网络中的服务，并获得生态系统的一个快照。

　　您深谋远虑，希望尽早应用监管。为此，您希望加以控制，来确保以正确的方式产生正确的服务。此处，您希望从带有策略管理功能的 注册库/存储库 开始，在流程和服务开发出来时进行编目，确保其符合关于开发方式的规则。

　　或许您的组织极具安全性和管控意识。在这种情况下，您可以首先着眼于 安全性解决方案。基于策略的安全性解决方案允许您在应用程序代码以外管理和监管安全性，因此赋予了您轻松适应新安全性需求的最大灵活性。

　　接下来是关于服务虚拟化的概念。许多组织都会从实现 服务总线 入手，但未意识到他们正在监管——尽管只是松散地应用。服务虚拟化是实施变更管理、版本控制和运行时策略遵从的一种常见及有效方法，这将打破与后台流程和服务的脆弱连接，隐藏与这些流程和服务的通信有关的复杂性。

　　上面只是关于可选入手方式的一些例子，但这些例子都是面向技术的。之前我提到过，监管不仅仅是技术。通常情况下，尝试所有这些选项对于组织结构和流程而言是必须的。这实际上也应该就是您的起点。如若没有定义正确的组织结构和流程，技术方面的价值就会受限，因为不了解它们所应用的是怎样的结构。换句话说，技术因素应作为一种途径，在流程和其他因素（如愿景、架构方向等）中提供可靠性和响应性。

　　以上内容显然并非SOA监管必要任务的详尽列表，SOA监管是一个广博复杂的主题。底线就是：您需要识别出最大的麻烦或需求在哪里，并从那里入手。您的SOA监管框架随后就可以随着SOA的发展演进而演进了。