任何架构师都会证实，治理并不是一个“为什么要治理”的问题，而是“如何治理”和“何时治理”的问题。更明确的说，谈论和争论常常是集中在什么程度的治理是真正需要的什么时候实施，以及在哪个方面实施。
如今，三大技术愿景正在使很多这类关于治理的谈论成为大家的焦点：云计算，SOA，大型机现代化。在上述每个领域中实施治理的方法都要相似之处：每一个都要打破壁垒，保护和保持信息集成，并使得IT在创建业务价值方面更加敏捷。
随着更多的应用和服务通过Web开放，并潜在地进一步扩展，构成复合的应用和服务，访问和复用这些技术资产相关的风险也更大了。随着更多产品和服务的不断引入和集成，这其中的差距也不断在加大。随着基础架构的不断发展，违反策略和编码错误发生的可能性会更高，这就需要我们进一步改进透明度。
然而，如何管理这些随着基础设施不断发展变化的资产，在处理责任和所有权方面是极需技巧的。这是因为，一旦应用由多个不同小组使用，那就很难清楚的定义该应用的边界。如果应用或服务被用来处理一个特定的业务需求，这会变得日益更加复杂；如何不实行合适的治理，随着对软件的修改次数的增加，将带来更多的编码错误，软件系统将变得更加脆弱。
亡羊补牢式的治理通常是很困难的，并且也有些低效。这这种情况下，治理被看作一种战术手段，主要关注在基础架构之内的工具和功能上，而不是一个更加战略性的目标，其设计的本意是保证所采用的技术和公司更大的业务目标相一致。
为什么有时候治理在整个IT策略中处于次要地位，原因或理由不一而足。通常这既是一个企业文化问题，也是一个软件开发流程问题。这些开发流程常常会把治理当作出现问题时的补救措施，或只有最重要的应用和服务才实施治理。可能对某些部门来说治理是一个需要优先考虑的事情，也对如何共享应用或服务实施了一些控制，但这些治理方式是不一致的，迟早有一天，这些问题都会暴露出来，并带来难以预料的后果。
