做成，做对，做快

    治理的作用就是在企业进行软件开发的时候帮助发现可以提高效率的机会。企业需要治理才能实现面向服务的架构的全部价值，所以我们要保证治理确实是在帮忙，而不是在帮倒忙。因此重点应该放在鼓励成功的措施上，而不是避免错误。Kent Beck有一句名言是"做成，做对，做快"。它并不是从"做快"开始的，因为要做快就必须先有一个完成品。那么如果一个企业在业务团队进行普通的部署工作时发现了可以开发的新服务，却让业务团队自行进行新服务的开发（可能甚至只是作为一个库实现），但让另一个团队对功能进行评估并决定是否值得开展一个新服务计划，这种做法怎样呢？从企业的角度来说，即使业务领域刚开始"做成"的第一步，我们也可能已经开始进行"做对"方面的考虑。这样看起来好像可以得到最好的效果。

    可惜的是，许多治理模型将开发和治理过程序列化了--治理是每个项目（甚至点子）都必须跨过的门槛。创建或修改一个服务会对整个企业产生影响，因此必须仔细地进行评估。然后很可能所有项目都堆在了这个门槛，业务领域所需的项目无法执行，而治理团队此刻却正为项目功能与SOA的关系争得面红耳赤。

    一旦确定要创建某个服务，通常就会把服务需求交给一个专门从事服务创建/维护/管理的团队。这很可能会成为另一个瓶颈，因为必须仔细对交付给主项目的服务进行调整才能保证项目的交付时间。一个重视各个利益相关人的需求的高质量的企业服务所需要花费的设计、实现和测试时间可能并不比主项目少。

    敏捷SOA治理

    显然以上两种概念的优势都体现在了SOA中：用治理来对服务进行调整；创建一个以服务为重点的专业团队。问题在于如何管理这些专向小组和业务领域团队的工作。图1为此提供了几种可选的方式。

    在这些可选方式中，需求经过整理后被提交到作为服务治理委员会的架构审核小组进行筛选。然后由这个小组决定项目中是否存在适合作成服务的需求。其中某些需求可能有相应的服务并计划在项目中投入使用。还有些虽然已有相应服务但其用途被分析小组筛掉了。剩下的需求即是将用于创建服务或修改服务的需求。

    这个审查过程应该尽量简单，以不影响开发流程为原则，因为我们的前提是先进行"做成"这一步，然后才会有机会"做好"和"做快"。项目的交付速度即取决于这些筛选决定，而企业SOA也无疑会更加成功。

    图1显示的是一种传统的线性方法。如果服务已经存在，那么它的用途便会被引入到相关的业务开发迭代设计中。如果服务不存在或者当前的功能不充足，那么需求便被送到服务团队，然后开始一个标准的开发周期，在企业的环境下描述详细的需求、设计方案、开发并测试、最后部署并加入到业务开发周期中去。如果该服务是应用开发的基础，那么这种方式很可能会产生问题，而且继续软件的其它部分的开发又必须充分了解并使用服务。问题产生的原因在于业务开发团队直到服务项目完成之前都无从知晓服务的界面或其它特征。如果没有一个周详的计划，那么服务项目和业务项目就会变得序列化，从而减弱单独的服务团队的应有影响。

    图2是以服务与业务团队的更早期的交流的方式解决消息延迟的问题。在这种方式中，服务团队在完成设计阶段后即把服务的界面交给业务团队。根据做法的不同，服务团队很可能还会得到除界面之外的信息。比如模拟服务、桩、或者测试等等。所有这些都有益于依赖于服务的软件开发，从而减少瓶颈效应。如果在实现期间需要对服务界面做出改变，那么也应该对这些情况进行沟通以对相关代码进行重构。如果业务团队有本地代理，那么重构应该就会简单地多。然后，当服务完成时，就可以进行集成测试了。不过，最后的集成测试与部署还要取决于服务团队的完成情况。虽然我们之前已经提供了许多信息，采用了更易于调整并且更为精确的方式进行并行开发，但是业务领域的工作仍然可能会因企业方面的原因而延迟。

    图3中的方法的前提是业务开发团队可以自行开发一个本地服务或者库来满足项目的需求，从而快速地进行项目工作而无需依赖其他团队。理论上讲，这是使用本地代理隐藏服务的形式，这样当服务完成时便可以与本地服务进行替换。当服务团队完成他们的工作的时候，业务团队就进行重构。还在做出改变界面的决定的时候进行交流可以最小化之后的重复性劳动。

    如果这最后一种方法也无法奏效，我们可以让两支团队并行开发非常相似的符合SOA要求的功能。这是一个战术性的决定，它可以使业务领域的进度风险最小化，并同时让企业继续向着战略目标前进。

    在这种项目经常变动的环境下，企业必须决定哪一种方式才是最合适的。某些企业服务的开发速度需要比其它的快。开发团队的能力也互不相同。服务对应用的影响取决于服务对应用的重要性。企业需要考虑到所有这些不同的因素并制定出符合情况的非常好的方式。