第五扇门：服务构建

    有趣的是，许多架构设计师和开始人员都错误地把门五当作SOA的第一步。而这里它是构建服务的重要一步。

    从上面几条建议我们可以看出，如果没有清晰地定义业务需求、了解当前情况，而直接跳进服务创建这一阶段的话恰会产生反效果。必须认清JBOWS（一打网络服务）与SOA的区别。

    在服务构建阶段，应该注意验证开发重点是否与在方案架构及服务设计阶段确定的政策、非常好的实践和标准一致。

    如果治理是架构的重要组成部分，那么它就能保证对所有新服务进行检查。理想情况下，这是由一个自动过程进行的：根据开发组件跟踪其源码并在服务的整个生命周期跟踪其质量。有了这个与组件相关的信息，重用的潜力就会以指数倍地增长--因为审核跟踪会一直伴随着服务质量。这样，在部署组件之前就会先对其进行检查以确定其符合相关政策。

    第六扇门：服务测试

    部署之前，先要对服务进行测试，而这正是SOA治理起关键作用（检测服务的政策相关性并截取潜在的错误代码）的另一个地方。

    虽然有许多测试工具并且架构设计师和开发人员已在使用，但是在部署服务时还要根据一些特殊标准进行测试。而且服务测试一定要包含：

    · 允许迅速更换测试软件的自动构建环境，

    · 测试非功能性需求、规范、创建、和测试数据加载的负载/压力测试工具，

    · 可以持续向管理层报告测试状态的测试管理报告工具。

    第七扇门：服务认证与部署

    胜利即将到来，门七的任务即是将服务融合到产品环境中，并且最小化客户端故障时间及其对业务的影响。从本质上来说，你是在保持业务运行并且对客户、合作伙伴和雇员保持一定的透明度的同时转换业务。

    可能你已经发现，如果这一步由手工完成，会很容易犯错误。这正是自动化治理发挥光芒的地方，因为它能够保证迅速、准确地部署服务的正确版本，而且不会忽视对其进行最后的认证检查以确定服务符合政策与标准。

    第八扇门：服务的生命力

    显然，我们应该根据实际情况定期对治理过程、流程、政策和标准进行检查和更新。服务的生命力这一阶段是在进行中——特别是SOA迅速增长、服务持续添加的情况下检查服务的整体质量。

    门八还为IT及业务决策制定者们提供了一种透明的方式来检测SOA的有效性和效率，并能先一步确定何时何地可能会需要发生改变。

    结论

    某些企业可能会把治理当成非必须的、浪费时间的“待办事项”，但是这种做法只会带来灾难性的后果。要注意自动化治理有助于流水线化软件开发生命周期，并且使其成为整体过程的无缝组成部分。

    但是，成功的自动治理并不是随手拈来的。企业必须对其有足够的重视、有计划地进行，并且还需要领导层能够清晰地定义各种职责。它还需要成熟并且能够持续增强的政策和程序。而且，它还必须支持控制门的建立，从而从中反映并支持企业的目标和文化。