任何架构师都会证实，治理并不是一个“为什么要治理”的问题，而是“如何治理”和“何时治理”的问题。更明确的说，谈论和争论常常是集中在什么程度的治理是真正需要的什么时候实施，以及在哪个方面SOA实施。

    如今，三大技术愿景正在使很多这类关于治理的谈论成为大家的焦点：云计算，SOA，大型机现代化。在上述每个领域中实施治理的方法都要相似之处：每一个都要打破壁垒，保护和保持信息集成，并使得IT在创建业务价值方面更加敏捷。
 

    随着更多的应用和服务通过Web开放，并潜在地进一步扩展，构成复合的应用和服务，访问和复用这些技术资产相关的风险也更大了。随着更多产品和服务的不断引入和集成，这其中的差距也不断在加大。随着基础架构的不断发展，违反策略和编码错误发生的可能性会更高，这就需要我们进一步改进透明度。

    然而，如何管理这些随着基础设施不断发展变化的资产，在处理责任和所有权方面是极需技巧的。这是因为，一旦应用由多个不同小组使用，那就很难清楚的定义该应用的边界。如果应用或服务被用来处理一个特定的业务需求，这会变得日益更加复杂；如何不实行合适的治理，随着对软件的修改次数的增加，将带来更多的编码错误，软件系统将变得更加脆弱。

    亡羊补牢式的治理通常是很困难的，并且也有些低效。这这种情况下，治理被看作一种战术手段，主要关注在基础架构之内的工具和功能上，而不是一个更加战略性的目标，其设计的本意是保证所采用的技术和公司更大的业务目标相一致。

    为什么有时候SOA治理在整个IT策略中处于次要地位，原因或理由不一而足。通常这既是一个企业文化问题，也是一个软件开发流程问题。这些开发流程常常会把治理当作出现问题时的补救措施，或只有最重要的应用和服务才实施治理。可能对某些部门来说治理是一个需要优先考虑的事情，也对如何共享应用或服务实施了一些控制，但这些治理方式是不一致的，迟早有一天，这些问题都会暴露出来，并带来难以预料的后果。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。