SOA能否足够轻量级和灵活以便处理敏捷项目呢？SOA治理项目如何才能保持敏捷开发者的协调但又不至于妨碍自己的项目呢？

　　有一种错误的观点认为敏捷和架构是不兼容的，无论我们说的是面向服务架构还是企业架构均如此。大家听到架构这个词的时候马上就会把它等同于一种大型的预先设计，比如瀑布方法论，实际上情况并非如此。

　　依我看，架构必定与根据情况建立边界有关。相关背景不仅包括了实现项目目标的需求、预算以及时间，还必须包括企业目标、运营成本以及未来的变更成本等。尽管在管理项目内部环境方面已经证实了敏捷成功了，但我们仍然需要将之与项目外部的环境进行平衡。

　　SOA和企业架构需要把上下文注入到敏捷过程之中以确保其被重视。除非你是在初创企业，否则的话项目不会是从一张白纸开始的。当前系统、企业目标等，所有这一切，都会为决策设定约束。可是如果这些约束没有很好地记录、沟通以及理解，就别指望项目会顺利开展，敏捷过程还可能会遭罪，因为需要提供背景指导的人并不是项目团队和迭代计划活动的成员。

　　正确的答案并非“多找一些架构师。”相反，而是要让敏捷团队的人获得做出好决策所需的信息，让他们不仅能够根据项目提供的上下文，也能够了解企业的背景来做出决策。这要靠路线图、参考架构、模式、标准、指南等来完成，而且这些东西不只是放在SharePoint网站上还要时时沟通更新。你通过可靠的沟通和教育让大家来做出的正确决策越多，所需的重度审核过程和文档就越少。

　　记住，所有这一切都意味着组织运营的方式也许要发生改变。它是否会被视为是轻量级，决在适度上依赖于该公司的文化。需求的变化越多，重量级似乎也越多。你需要为公司文化找到一个平衡点，它可以以合适的速度消化并变化。如果你试图运用大多数SOA书籍的理论（包括我的），而不考虑你的文化是否适合它的话，那么就会造成负面影响。

　　我想许多人认为治理和轻量级是对立的概念，但我觉得它们不必如此。治理的最佳办法是顺着阻力最小的方向走。如果能够实现这一点，那么你的治理也许就不会感觉那么累人。同时，治理还包括监管，而多数人又认为监管是消极的信号。

　　比方说，如果你希望确保每一项服务均对服务交互提供审查跟踪，如果你告诉他们“通过企业服务总线（ESB）发送所有的请求就行了”，或者“使用这个基类的共享库”，结果就会好很多很多。如果你只是指出政策，那么他们就会选择对自己来说最为便利的办法来做，这就会导致方法和顺从性的不一致。照我们说的做你就能减少他们需要做的工作，而不是给他们增加负担。

　　如果你竭尽所能，让人们能尽可能简单地做出正确的决策，而错误决策又明显地令人痛苦和存疑的话，那么你的治理计划就会更加成功。