信息系统是复杂的，要让它们向业务需求和目标靠齐被证明是一项非常具有挑战性的任务。这涉及到在一个不断发展的业务和技术环境里处理像保持（retention），监察（compliance），可用性，实时可视化，复杂事件处理等等一系列问题。
以上问题都是常常妨碍 IT 给业务需求提供价值的绊脚石，而 SOA 则被吹捧成是它们的解决之道。然而，并非所有 SOA 构建方法最终都会产生同样的结果。在他最近发表于 CIO 杂志的这篇文章里，Mike Kavis 写到：
缺少可靠治理模型的 SOA 实现无异于一个没有指挥塔的机场
他建议，在考虑治理时，应在流程和机动性之间找到合适的平衡：
我已经看到有太多的公司在尝试实现 SOA 治理的过程中常常落入两个不同的陷阱。第一个是，缺乏一个足够健壮的治理模型；第二个则是，流程太多以至于事情永远也到不了头。
他声称：
- 流程不足将导致混乱
- 流程过多会抑制创新且损害机动性
- 治理应该与时俱进
例如，缺少有效的治理模型：
SOA……就可能 [意味着]……系统宕机、高开发成本、不可控的生产环境以及满脸怒色的客户。
再者：
为了获得 SOA 承诺的重用性、灵活性、机动性和易于集成等特性，设计时治理必须保证服务的构建方法是一致的，该方法必须能够提供业务价值、满足性能和安全性需求、平台中立，且不会破坏已部署的服务。
他同时暗示，运行时治理：
极为关键，[因为] 一个业务服务可能是由多个组件组成的……当服务失效的时候，你最好有恰当的流程和工具，在客户发现之前，快速发现问题并恢复。
那我们如何能够在施行 SOA 治理的同时又能保持机动性呢？
Mike 对此给了我们一些实践步骤：
- 从文字繁缛的文档迁移到可视化的文档是一条可行之路。
- SOA 治理不应由项目经理定义；事实上，该由架构师定义。
- 如 SOA 一样，SOA 治理就是一次没有终点旅程。从小做起，并只实现当时必要的步骤。
同时须记得这些要避免的东西……
我曾看到有些公司花了超过一年才将所有适当的治理流程到位。整整一年未给业务增加任何价值。我建议，将 SOA 治理作为关键环节包含到你的 SOA 路线图里。
毋庸置疑，治理是构建 SOA 过程中最棘手和最关键的因素之一，特别是在考虑流程和机动性的同时，还要把政治和资金等因素也考虑进来的时候。你是如何来构建你的 SOA 治理组织和流程的呢？你认为你成功了吗？为什么？如何做的？
暂无签名
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论