在对SOA进行治理的同时，也不能忘记SOA的目的是让IT为企业实现价值。
要实现SOA所带来的易管理、可靠性和重用性，必须先有一个有效的治理结构对服务的创建、维护、提供和消费进行调整。
然而，虽然SOA具有战略性的优势，但是治理往往会在企业的单个业务线上产生负作用，因此许多中小型企业在开始编制服务目录的时候会遇到种种困难。那么应该怎样对服务资源进行编制从而让我们的项目取得成功呢？本文提供的治理结构可以在接受通常工作的战术性、以项目为中心等特点的同时实现服务的战略重要性。
对治理的需求
根据定义，服务应该是一种共享资源。如果要在利益相关人群体中共享资源却缺乏一个有效的治理系统通常会导致资源管理与资源利用之间产生矛盾。要保持较高的ROI（比如通过避免重复性劳动）并符合SLA协议（比如通过在提供服务的同时保证合适的计算资源以满足消费者的要求），就必须对服务进行有效地治理。治理还能帮助企业发现新的服务需求并根据变化做出调整。
对交付的要求
在对SOA进行治理的同时，也不能忘记SOA的目的是让IT为企业实现价值。不过，企业是通过业务线（LOB）来实现利润（或其它价值）的，因此，完全可以说业务线就是企业的动力之源，而技术项目只是业务用于实现目标的一种手段。有了这种非常直接的关系，那么如何准时地完成业务技术项目就成了关键。
有些关于SOA的书籍和文章建议对服务重新进行完全编制才能实现面向服务所应有的效率。如果按这种方式来的话，那么所有开发项目就都会在标准的、能够在服务资源增长的同时保证架构质量的SOA治理中顺序进行。
可惜的是这种方式通常是以缺乏架构治理（不管是正式的还是非正式的）这个假设为默认条件的。所有企业都有各种正式的和非正式的管理型技术项目，其中某些甚至已经变得很有系统性，与其它技术争夺控制权，甚至阻碍项目的交付以至使项目无法实现其所应有的价值。而治理必须在这样的一个环境中寻得一席之地。
对于中小型企业（SME）来说这更是一个大问题，因为他们可能没有足够的员工在使业务领域及时完成项目的同时处理这样的一个过程。他们可能没有条件组成一个单独的服务团队，也可能没有足够的架构师在不妨碍开发的情况下对所有开发活动进行审查。结果就是业务领域逐渐失去对降低成本和提高生产力的前景的信心，并因此给SOA的实现埋下了问题的种子。他们很自然地会产生疑惑，认为当前的障碍是否是一种在当前条件下无法解决的问题，只能等待下一次技术潮流涌现并取代SOA。他们可能还不知道云计算……。
如果一个开发团队要帮助某个业务领域实现价值，那么这个团队就会设计一个适用于这个业务领域的软件。但是由于这种软件是一种紧耦合，缺乏扩展性，因此无法将它应用于其它的业务领域开发团队。虽然这对企业来说是一种低效率的工作，可是却无法及时地反映到业务领域上。这些团队并不是在为企业寻找实现价值的机会——他们工作的对象是业务领域。他们认为他们的工作具有很高的价值。要减缓开发项目的速度以解决企业层次的低效率问题在这种业务领域环境下是难以行得通的。
解决这种进退两难处境的方法通常是从上层开始推动变化并将所有服务开发平行到另外一个单独的团队中。这是种合理的方法，它能够利用常用的方法提高开发能力（布鲁克定律不算在内）。在各种首席官的带动下，人们希望可以组成一个能够随时实现服务以支持主开发团队的工作的具有各种资源或手段的服务团队。但是这个团队的主要任务并不是帮助业务领域，而是帮助企业。要实现这个目标，这个服务团队在创建服务的时候就要从战略性上着手。它必须对业务团队所提供的需求进行分析并决定这些需求是否对其它团队具有通用性。它还必须对服务的扩展性和易管理性进行评估。总之，它必须小心谨慎。而小心谨慎就意味着时间。在小型企业里，项目的交付期限是很短的，通常少于一年，一般只占一个业务周期的四分之一甚至更少。那么服务团队怎么才能在这么短的期限内还做得小心翼翼呢？
做成，做对，做快
治理的作用就是在企业进行软件开发的时候帮助发现可以提高效率的机会。企业需要治理才能实现面向服务的架构的全部价值，所以我们要保证治理确实是在帮忙，而不是在帮倒忙。因此重点应该放在鼓励成功的措施上，而不是避免错误。Kent Beck有一句名言是"做成，做对，做快"。它并不是从"做快"开始的，因为要做快就必须先有一个完成品。那么如果一个企业在业务团队进行普通的部署工作时发现了可以开发的新服务，却让业务团队自行进行新服务的开发（可能甚至只是作为一个库实现），但让另一个团队对功能进行评估并决定是否值得开展一个新服务计划，这种做法怎样呢？从企业的角度来说，即使业务领域刚开始"做成"的第一步，我们也可能已经开始进行"做对"方面的考虑。这样看起来好像可以得到最好的效果。
可惜的是，许多治理模型将开发和治理过程序列化了--治理是每个项目（甚至点子）都必须跨过的门槛。创建或修改一个服务会对整个企业产生影响，因此必须仔细地进行评估。然后很可能所有项目都堆在了这个门槛，业务领域所需的项目无法执行，而治理团队此刻却正为项目功能与SOA的关系争得面红耳赤。
一旦确定要创建某个服务，通常就会把服务需求交给一个专门从事服务创建/维护/管理的团队。这很可能会成为另一个瓶颈，因为必须仔细对交付给主项目的服务进行调整才能保证项目的交付时间。一个重视各个利益相关人的需求的高质量的企业服务所需要花费的设计、实现和测试时间可能并不比主项目少。
敏捷SOA治理
显然以上两种概念的优势都体现在了SOA中：用治理来对服务进行调整；创建一个以服务为重点的专业团队。问题在于如何管理这些专向小组和业务领域团队的工作。图1为此提供了几种可选的方式。
在这些可选方式中，需求经过整理后被提交到作为服务治理委员会的架构审核小组进行筛选。然后由这个小组决定项目中是否存在适合作成服务的需求。其中某些需求可能有相应的服务并计划在项目中投入使用。还有些虽然已有相应服务但其用途被分析小组筛掉了。剩下的需求即是将用于创建服务或修改服务的需求。
这个审查过程应该尽量简单，以不影响开发流程为原则，因为我们的前提是先进行"做成"这一步，然后才会有机会"做好"和"做快"。项目的交付速度即取决于这些筛选决定，而企业SOA也无疑会更加成功。
图1显示的是一种传统的线性方法。如果服务已经存在，那么它的用途便会被引入到相关的业务开发迭代设计中。如果服务不存在或者当前的功能不充足，那么需求便被送到服务团队，然后开始一个标准的开发周期，在企业的环境下描述详细的需求、设计方案、开发并测试、最后部署并加入到业务开发周期中去。如果该服务是应用开发的基础，那么这种方式很可能会产生问题，而且继续软件的其它部分的开发又必须充分了解并使用服务。问题产生的原因在于业务开发团队直到服务项目完成之前都无从知晓服务的界面或其它特征。如果没有一个周详的计划，那么服务项目和业务项目就会变得序列化，从而减弱单独的服务团队的应有影响。
图2是以服务与业务团队的更早期的交流的方式解决消息延迟的问题。在这种方式中，服务团队在完成设计阶段后即把服务的界面交给业务团队。根据做法的不同，服务团队很可能还会得到除界面之外的信息。比如模拟服务、桩、或者测试等等。所有这些都有益于依赖于服务的软件开发，从而减少瓶颈效应。如果在实现期间需要对服务界面做出改变，那么也应该对这些情况进行沟通以对相关代码进行重构。如果业务团队有本地代理，那么重构应该就会简单地多。然后，当服务完成时，就可以进行集成测试了。不过，最后的集成测试与部署还要取决于服务团队的完成情况。虽然我们之前已经提供了许多信息，采用了更易于调整并且更为精确的方式进行并行开发，但是业务领域的工作仍然可能会因企业方面的原因而延迟。
图3中的方法的前提是业务开发团队可以自行开发一个本地服务或者库来满足项目的需求，从而快速地进行项目工作而无需依赖其他团队。理论上讲，这是使用本地代理隐藏服务的形式，这样当服务完成时便可以与本地服务进行替换。当服务团队完成他们的工作的时候，业务团队就进行重构。还在做出改变界面的决定的时候进行交流可以最小化之后的重复性劳动。
如果这最后一种方法也无法奏效，我们可以让两支团队并行开发非常相似的符合SOA要求的功能。这是一个战术性的决定，它可以使业务领域的进度风险最小化，并同时让企业继续向着战略目标前进。
在这种项目经常变动的环境下，企业必须决定哪一种方式才是最合适的。某些企业服务的开发速度需要比其它的快。开发团队的能力也互不相同。服务对应用的影响取决于服务对应用的重要性。企业需要考虑到所有这些不同的因素并制定出符合情况的最佳方式。