观察：
“这是为什么？”
“它的使用频率比我们设计时想象的要高。”
“这是为什么？”
“可能是有些人或流程使用了不该使用的服务。”
“那么谁在使用这项服务？为什么使用？这些意料之外的用户使用它没问题吗？”
“呃，我不知道。我想我应该先调查一下……”
这就需要思考你想通过这项服务实现什么，它的商业价值是什么，以及商业价值可以和应该是什么。必须有人负责这项服务并从战术和战略层面考虑它。
这就是治理！ （在维基百科上可以找到关于 SOA 治理的更正式的描述）
再次升级
回到问题。事实上，它在技术层面（5）表现出来并不意味着它应该在 加密货币数据 那里得到解决。相反，人们（4）应该提出问题。其中一些问题可以在 2 级或 3 级回答，而其他问题只能在 1 级回答。
这里暴露出了真正的治理问题：技术层面的人知道这一点！他们知道每项服务都需要一个所有者。他们知道需要保管角色来保护和跟踪模式、策略、注册表等。但不知何故，他们无法达到正确的级别来实施这一变更。
几年前，我向一小部分听众解释了 SOA 治理，这是他们的一个问题：我们这些在技术层面工作的受雇顾问，怎样才能让更高层次的人明白，组织需要正式化这些角色才能在 SOA 上取得成功？我当时并不知道答案。我可能含糊地说了一些关于教育的可能性并建议他们应该努力尝试。
变更管理
幸运的是，我最近参加了一个变革管理课程，突然一切都顺理成章了。处于某一层级的人只会听取处于同一层级的其他人的意见。更重要的是：你无法改变这一点。