策略是一条弯曲的道路，机制让你保持在正轨上

作者：Gregor Hohpe，发表于2021年7月15日，企业策略永久链接评论

重点总结

在登山时，你不会沿着一条直线爬升。相反，平缓的坡道和弯道让你能够逐步上升。尽管你的目标并不在眼前，但你始终能从周围的风景或高度追踪你的进展。如果你已经有一段时间没有遇到转弯，你可能会查看地图，以确保没有偏离正确的路径。即使是看似与你目标相悖的小下降也是必然现象，需要你注意：你总是会比实际的高度上升更多。有时候，你需要绕道而行或许是为了避开阻塞或冲毁的小径，但你会确保最终能回到主要的路径上。

执行策略的过程与登山十分相似。在我前一篇文章中提到的，选择目标相对简单，而走向目标的道路却可能经历许多转折与绕行。因此，你需要一些东西来帮助你保持在正轨上。

战略道路并不是直线

战略并不是地图上的某个点那是你的目标，而是从你当前的位置到你想要到达的地方的路径。这个路径是由你所做出的重要决策形状的，那些你可以向左转却选择了向右转的决定。这就是为什么战略很少是一条直线，正如爬山时一样。你可能会进行一系列的弯道，但因为始终盯着目标并随时调整，你最终会到达目的地。

云策略也是如此

云转型的路径也类似。最直接的途径可能是将所有应用程序现代化，使其具备云原生特性，通过无服务器运行时进行扩展，将数据存储在完全托管的NoSQL数据存储中，并通过机器学习工具自动优化。这就是当你站在云的巅峰时所看到的样子！

可惜的是，这也是登山过程中最陡峭的路径，对于一个复杂的企业来说是很难在广泛的IT环境中采取的。因此，你需要分步进行。你可能会“原样”将一些应用程序移动到云中，以获取初步的可用性和透明度。接下来，也许你会将一些组件，例如数据存储，迁移到托管服务中，以降低成本和运营困难。将必须应对突然负载峰值的组件迁移到像AWS Lambda这样的无服务器运行时可能是你下一个转弯的重要一步。

你甚至可能希望运行现有系统的多个实例来简化迁移。外部观察者可能会对这个决定感到惊讶，因为多个实例可能会增加运营复杂性和成本。但就像走坡道可能看似在横向移动一样，临时的复制在全球环境中以及在为所有市场排定监管审批时，可能是获得价值的最快路径。看似不理想的中间阶段在转型路径上几乎是不可避免的，你不能指望一蹴而就。

保持在轨道上

在一次与客户的对话中，该公司的CIO与我讨论了他们的重大转型项目时，他提到了一个团队重写主机遗留代码为Java的努力。令他失望的是，他们最终得到了一个4000行的Java类，这可能不是面向对象分解或可测性设计的巅峰。因此，看起来这个团队在云原生顶峰的攀登上并没有获得太多的进展。

但他们可能在正确的道路上吗？只有下一个弯道能告诉你。或许创建一个大型Java类只是一个中间步骤，简化了验证现有逻辑的复制是否正确。一旦进入Java的世界，团队可以利用更多的工具：自动重构、单元测试和代码覆盖工具可以帮助团队更好地组织代码，以提高可理解性和可维护性。因此，就像你看到一个登山者走得并不“向上”，他们实际上可能在走一条好的路径。

通过分解类来横向攀爬可能在某些人眼中显得缺乏进展：没有新的功能可展示。然而，这可能为团队的下一步实质性进展做好准备。当他们在一片深厚的遗留系统的逐渐上升时，要向利益相关者解释进展会十分困难。评估团队的进展必须掌握全局。同时，团队必须致力于走下一个转弯并继续攀爬否则，他们真的只是外出走走而已。

将整体战略与短期战术联系起来，这些战术可能看起来是在横向引导团队，是成功转型的重要因素。

良好的意图没有用机制才有效

执行策略的过程充满了曲折与绕行。但你如何确保一个绕道不会变成错误的路径？你如何知道团队何时需要走下一个转弯？多长时间后你不得不宣布自己迷路？

没有魔法答案，但在亚马逊网络服务AWS，我们走过很多蜿蜒的道路，发现了一些能帮助保持在轨道上的良好实践。最有用的一项是实施机制。在亚马逊，我们有句俗语：“良好的意图没有用机制才有效。”或许这就是我们如何避开通往地狱或其他不受欢迎地方的道路，看来这条路是由这样的意图构成的。我们发现，良好的意图不能解决问题，因为人们通常在问题发生时就已经有了良好的意图。

机制是完整的过程，包括工具、采用工具的实际使用和检查验证机制是否有效。它们也是确保你不可避免的绕道重新回到主要战略路径的绝佳方法。我的一个朋友建立了一个有效的机制，以确保他们大规模的云迁移保持在正轨。团队会将他们本地数据中心的成本分配到剩余的应用程序中。换句话说，留在本地的成本会随着剩余应用程序的减少而逐渐增加。显然，你不想在最后一个应用程序上运行并承担整个遗留数据中心的成本。这个机制比良好的意图、提醒和最后期限的延长要有效得多。团队可以自由地进行临时的绕行，但机制确保没有人会长时间偏离预定路径。

前述的主机遗留迁移也可以受益于类似的机制。这些工具可以基于多少代码模块被重写和这些新模块的代码质量指标如测试覆盖率或模块化来制定指标。这将奖励员工重写旧代码，也鼓励后续的重构在一个巨大的Java类中实现良好的覆盖率是相当困难的。因此，团队如果只是重写未经良好结构化的代码，将有明确的激励去转弯并投入时间去重构代码。

采用工具是你很少能强制的事情至少当你希望它能够正常运作时，所以最佳的采用路径是为团队提供合适的工具，使得跟随所期望路径变得尽可能容易。正如你在徒步小径上见到的，人们会选择捷径，如果比停留在指定路径上更容易的话。在遗留代码迁移中，团队将乐于拥有强大的开发环境、高效的测试框架，以及在遇到模糊或有缺陷的遗留代码障碍时能够快速获得支持。任何指标，尤其是那些导致奖励的指标都存在风险，即团队可能会专注于达成指标而忽视指标本身的原意。这就是为什么你需要检查机制是否有效，以确保工具依然有意义，并识别团队是否在精心设计体系中玩弄数据。

机制不是护栏

当企业讨论如何引导团队朝向期望的行为时，常常提到护栏，即团队应该操作的定义界限。护栏可以是应该使用的标准产品或编程语言，或者是它们可被部署的运行时环境。然而，护栏在现实生活中，以及在企业中，是最后手段的安全机制。

任何司机都不会愿意通过护栏来修正他们的路径。护栏是一种安全设备，可能在极端情况下拯救司机免于严重事故。然而，它并不擅长引导司机：沿着护栏行驶不仅会损坏车辆，而且还会造成巨大的摩擦，这在企业中同样可以见到。相反，司机会使用道路标记和汽车的车道保持辅助系统来安全驾驶。

企业护栏往往是非黑即白的规定：团队不能使用数据库X或编程语言Y，所有提交的代码必须包括一些测试。与路上的护栏一样，它们可能防止混乱发生，如将敏感数据存储在公共数据存储中或推送充满安全漏洞的代码，但对轻松引导团队朝向良好的结果几乎没有帮助。相比之下，机制则对团队提供了温和的引导，以保持在正确的路径上，而不会撞到护栏上。

一个帮助团队保持在轨道的好例子是我们企业策略负责人[Phil Potloff](https//awsamazoncom/executiveinsights/enterprisestrategists/philpotloff/的博客文章。Phil描述了压缩周期时间的重要性换句话说，减少构建、测试和部署新代码所需的时间，对许多团队而言仍是一个挑战。因此，形成的机制是将周期时间视为有限资源，如预算、人员或时间表。团队可以自由地在这些指标之间权衡，以确保不造成碰撞或刮擦。

上述的云迁移示例达到了同样的效果。与其施加一个单一的硬性截止日期这无疑会延长以便容纳例外，不如让成本分配机制逐渐增加不迁移的成本，以便每个团队可以找到其収支平衡点，而不会撞上护栏。

前几天在铁道博物馆

作为一名工程师，我对灵感来源于移动机器的隐喻有某种偏爱。我曾谈论过不要在IT转型中爆炸锅炉和在换挡时磨损组织离合器。因此，我最喜欢的机制隐喻来自于日本东京附近的大宫火车博物馆的参观。

火车车轮跑在钢轨上，内部有一个大的法兰。然而，这个护栏仅用于极端情况，Rarely接触到轨道。当它这样做时，会发出刺耳的尖叫和磨擦声。

相反，火车的车轮通过一种机制保持在轨道中心。每个车轮的运行表面是倾斜的，外部的车轮比内部的车轮小。当火车的轴向一侧偏移如草图所示时，轮子的形状会导致那侧的有效轮径增加。这反过来使得该车轮所走的距离大于另一侧的车轮，因为两个轮子通过刚性轴相连。这一机制将轴推回到轨道的中心。

这个简单的机制使得火车车厢在200多年里保持在轨道上，且几乎没有撞上护栏。因此，考虑用机制引导你的转型之旅，而不仅仅是依靠护栏。你会花更少的精力，也会少听到磨擦声。

用更少的磨擦进行转型

下次当你制定云战略的执行计划时，请考虑一次在铁路博物馆的日子或征服一座大山。隐喻的选择可能取决于你的倾向或天气，但在任何情况下，你都会想起能柔和地引导你保持在轨道上的机制。

Gregor Hohpe

作为高级首席传播专员，Gregor将无服务器技术与客户的IT战略相结合，以实现快速实验和创新。他相信，现代IT领导者应当与其技术“引擎室”保持联系，因为当今的技术决策决定了企业未来的应变能力。在硅谷度过十年后，Hohpe先生曾担任金融服务的首席架构师，并作为新加坡政府的智能国研究员，推动公共部门平台和云战略。他喜欢在他的书籍中分享对架构和架构师的看法，包括《软件架构师电梯》、《云战略》和《平台战略》。