在几周前的一篇文章中,RDA 公司的首席架构师 Steve Stefanovich 提出了这样一个问题:“你有 SOA 治理计划吗?”
想到没完没了的会议和委员会审查,你不禁感到一阵阵的反胃。
但是,他接着写道
在规划 SOA 架构时,不要对“治理”一词感到不寒而栗。你可能已经实践过治理了,只是不知道而已……它不过是重定位和规范化大多数优秀软件架构师已经一直在做的事情。
他认为治理可以让你:
按照正确、一致和可重复的方式前进。在设计、构建和管理整个组织的服务时,一致性是根本。
这一观点倒是和 Todd 的观点有几分相似:
我认为,治理就是指导组织获得预期的行为。
Steve 把 SOA 治理分成:
设计时治理涵盖了分析、设计、构造和开发阶段,而运行时治理则作用于运营和维护。
其他人,如 Software AG 的副总裁 Gary So 把粒度分得更细:
- 架构治理
- 服务治理
- 设计时治理
- 运行时治理
- 变更时治理
Neil Macehiter 最近还给 SOA 治理的领域增加了数据治理。
接着,基于以下原则,Steve 为服务构造的每个阶段提供了一系列建议:
你从前一个 SOA 项目中获得的所有经验和所有经验证的实践仍然适用于 SOA 世界。理解到这一点将有助于你理解治理是你的朋友,并且设计中缺乏治理计划的 SOA 将是不完整的。
在得出以下结论之前:
一匙治理即可让 SOA 走上阳关大道。
你在你的 SOA 治理努力中身处何处?你覆盖整个生命周期了么?它是否集成进了一个更通用的 IT 治理流程?你在使用 SOA 治理套件吗?你面临哪种运行时的问题?
评论