一位企业架构师在推进SOA治理时候怎样才不会变成坏人呢？他们害怕如果一个人总是说“不”，会被视为不合作和起反作用的。

　　毫无疑问，在许多组织那里，治理就是四字经。如果你的情况也如此，你最好的做法可能就是大体上要避免把它称为治理，但是这并不意味着你就不能进行有效的治理。

　　治理有四个关键的流程，其中只有一个流程存在反生产的潜在可能性，这通常是因为未给予其他三个流程以足够的关注度。这些流程是：

1. 　　策略定义
2. 　　培训教育
3. 　　实施执行
4. 　　衡量反馈

　　当人们想到治理的时候，他们只会考虑第三点，实施执行。如果审查者并不了解他们所审核的东西的话，架构审查将会是一次非常痛苦的经历。我就曾有过这样的经历，我相信其他人也一样。

　　审查由项目架构师为首的一到多个被组织认为是“聪明”的人组成，这样的审查会演变为更多的是让他们去展示自己知识，而非根据任何类型的规范和指南来对项目进行审查。

　　公平而言，审查委员会通常没有得到任何更多的指南。他们被要求根据自己的经验来做出判断，而不是基于任何记录在案的标准或指南。修订这一点的办法是通过其他流程来做到的。

　　它从策略定义开始。为了让一个成功的治理程序有任何的希望，你必须明确所审查的项目的期望。这些是原则、标准和指南。他们必须根植于公司的业务目标和运营模型中，否则就会有被视为武断专横的风险。

　　比如说，实施使用RESTful实践的服务的方案是一回事，要求一个非常特别的开发框架去实现它则是另一回事。如果你的公司担心开发人员跨项目的可移植性，且你有一个集中化的支撑组织，那么后者也许就非常有意义了。

　　如果开发者被分配到特定的业务线并提供其自己的三线支持，那么使用REST可能就很重要，但对开发框架进行标准化也许就不重要，可能就会受到抵触。一旦你确立了这些原则、标准以及指南，现在，对于项目要达到什么目标你就有了一套清晰的策略了。

　　接下来就是要确保你的开发团队意识到这些策略。尽管有文档记录的策略好过没有策略，如果审查者是仅有了解它们是什么的人的话，它并没有多大的好处。将受到治理的开发团队必须通过有效的教育培训程序认识到这些期望。

　　自始至终，整个流程里面都不能仅仅是传递审查信息，相反，要让他们的工作更简单些，以便他们能关注于项目的重要部分，即实现业务逻辑。简而言之，对于开发团队而言，你已经给了成果所需的一切东西。没有对成功进行恰当的定位，有太多的项目皆是如此。要尽你所能，以便项目从一开始就是成功的。

　　如果你正确地进行这些流程，实施可以变得非常有效。团队可以对策略执行自我评估，使得他们关注于需要例外的领域，或者那些所关心的当前策略无法覆盖到的领域。这样做可以保持对创建最佳方案可能性的关注，并避免在不必要的领域内浪费时间。

　　最后，跟任何好的流程一样，该系统必须持续改善。如果特定的策略不断被要求有所例外，也许这个策略本身就存在问题。如果业务需要变更，比如需要从最大化增长转为减少成本，这些策略也将需要作出变更。

　　新的方案和新的技术将会携手出现，在那些领域里也许会需要这些新策略。定义这些策略的团队必须倾听他们所审查的那些团队的意见，并将他们的经验体现到他们所做出的方针决策上面。

　　如果你有效地实施了全部这四个流程，由于治理程序是有效的而非令人生畏的，你的机会就会好得多，而不用仅仅关注于实施。