关于什么时间在哪个方面开始治理的具体细节，需要根据现有的基础架构，以及其成熟度和范围而定。简单地说，应该在一个IT项目的起始阶段就开始治理。在最早的阶段如果缺乏治理，将会引起额外的成本。在软件部署之后修改代码错误的成本，比在编码阶段改正错误的花费，要高30～200倍。

　　理想状态下，治理应该是计划和设计阶段的一部分，并在整个软件开发生命周期中贯彻实施。不幸的是，我们不能回到过去，通常也不可能重新返工，尤其是对那些有多个IT项目同时进行的大型组织机构。当新的项目比如云或者SOA在制定规划时，我们就有机会在整体的技术策略中加入治理作为其中的一部分。

　　但是，如果没有这样的机会来扩大项目的初始范围使之包含治理的策略和实施，我们该怎么办呢？这带来的问题是治理方式将会简单地维持原状。它没有坏为什么要修理？尽管公司可能选择让其IT基础架构保持现状，可能出于很多业务和架构方面的原因，现实情况是，终归有一天，他们需要同合作伙伴，客户或其他外部组织交互和交换信息，这些外部组织已经将他们的基础架构的一部分以Web方式开放出来了。为了减轻相应的风险，增加透明度，这需要信息交换的双方都实施更加严格的治理。

　　文化

　　如果治理的引入能够同时结合文化和技术的因素，这样的治理是最有效的。这需要公司提高对治理的相关性和重要性的认识，并保持和企业文化和现有流程的步调一致。让开发人员参与，鼓励成功经验的分享，建立政策，附加奖励，这都是一些行之有效的方法。

　　从技术的角度来讲，利用现有的政策和好的实践经验，能够大大加快治理的实施进度，因为不再需要从头开始创建这些工具而花费时间。政策和成功经验的概念一般来说对开发组并不陌生，然而，在一个真正的治理中如何持续的执行，开发组通常都不太了解。实际上，在开发组中，从架构师到开发人员，认识到这对整个行业的价值的大有人在。

　　会不会有过度治理的情况？有的 ―― 过度治理可能会比治理不足更加糟糕，因为它会阻碍生产能力。在开发的早期阶段，最好采用一个较为被动的治理方式，只是将产生的问题和潜在的影响通知项目组。当你更加接近产品阶段时，你可以实施一个较为主动的治理方式，比如禁止开发人员将程序导入版本库，除非他们已经符合我们已经建立起来的政策。

　　需要牢记的一个要点是，在组织机构在第一次创建和实施治理时，由于这是一个新的过程，从短期来说，这需要额外的花销，但最终，治理会降低总体的开发成本。

　　只要我们持续的开发和部署应用和服务，治理所带来的好处就值得我们付出。这也意味着在在一套好的经验，标准，政策和模式的基础上，在跨部门之间坚持推行我们制定的政策。

    最终，显而易见的是，如果服务和应用要分布在整个基础设施上，那就需要治理。这样，在软件不断演进并服务组织的不同部门时，企业都可以执行应该遵循的策略和好的经验，不论企业采用SOA，云，或其他IT架构。