对于SOA治理来说，什么样的定制化是重要的，理由是什么？（BAM？BI？CEP？还是其它？）

　　第一眼看之，消费化和治理可能看起来有点反直觉。毕竟，治理是关于加强政策，并使事情保持黑白分明的一件事吗？我们先来说说定制化的由来。

　　政策定制化通常只在一个环境下发生，即在服务合同中。一个合同就是一套政策明细，对于消费者和供应都来说。当然合同之间可以存在共同的政策，每一个合同以对涉及到消费者和提供者来说都是唯一的。

　　让们来看看在不同的上下文中的定制化。有一个关于BAM（业务行为监控）、BI（商业智能）和CEP（复杂事件处理）的问题。我们不再谈论SOA治理定制化了，而是开始讨论扩大治理工作的范围，超出SOA。这对于没有强壮的架构治理实践的公司来说，是相当正常的一个事件。

　　服务设计阶段治理实践常常会把焦点放在服务接口上。有时，这些接口决策是基于接口背后的元素，如基础的数据库结构。这是SOA治理的一个问题吗？当然，如果它产生了一个很不好的接口的话，它就的确是一个问题。即使是从运行阶段的角度来看，也有相似之处。

　　SOA在运行阶段的问题是，确保了一个客户的请求的同时，也不会不顾其它客户的请求。从概念上讲，这与BI世界里的问题很相似，在BI世界中，确保给其中的一个客户的分析性分析和报告不会影响到其它人的性能。

　　在CEP领域，也有相似的地方。在SOA领域，我们需要一个编目来提升已经有服务的可见性，这样其它的项目就不同重建它们。在事件中也有同样的事情。我们不希望多个所有业务流程都生产一个他们与们相同的事件来。缠上你的事件，就像服务一样，这样会提供可见性，确定你的企业不会有冗余。

　　关于BAM，这与度量集合有关。显然,度量集合是运行时治理的一个关键组件。如果你有基于这些度量的政策，你就必须收集它们来加强这些政策，无论是被动（如，确保每月正常运行地时间）的，还是主动（如允许请求速率）的。

　　运行时SOA政策只是系统中整个运行时管理的一个子集。现在，如果你的运行时管理很糟糕，那么实现运行时SOA治理的工作就会暴露出这那些缺点，但是也会提供一次机会，不仅仅只对SOA产生影响。

　　至此得到的消息如下：不要让固体治理实践是局限于SOA。如果在其它领域你没能解决治理的弊端的话，那么这些不足就会浮出来影响你的SOA治理工作，就会失去潜在的好处。相反，要把成功的SOA治理工作当作跳板，来改善治理，无论是在设计阶段还是运行时，还是其它领域。