本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 实施路线图
制定路线图后，需要将其付诸实施。我们发现，客户面临的下一个挑战就在这里：他们已经花时间进行了*思考*，现在必须转向*行动*。为了将您的策略与实施联系起来，我们建议您执行以下步骤：
+ [决定从哪里开始以及如何开始](#decide)
+ [组织以取得成功](#organize)
+ [建立推动变革的机制](#establish)
+ [逐步发展成熟度](#develop)
## 决定从哪里开始以及如何开始
这听起来很简单，但由于要实现的目标太多了，找到切入点往往是一个棘手且充满争议的问题。正在向云迁移的组织有许多需要关注的方面，如果没有放在合适的背景中，这一举措很容易变得令人不堪重负。多年来，客户趋势不断演变，但一个始终如一的起点是[变革型领导力](https://docs.aws.amazon.com/whitepapers/latest/aws-caf-people-perspective/transformational-leadership.html)。自上而下推动指令和策略，制定使命宣言、原则和公关常见问题解答，使中层管理人员和个人能够自主作出决策，提高清晰度，通过云转型推动业务价值。如果您还没有进行过此类练习或类似的练习，我们建议您将其作为首要任务。
在此练习过程中，您应该认识到，与其他技术转型不同，云转型使技术更贴近业务。技术是企业用来实现更广泛目标的杠杆，通过赋能敏捷性、稳定性、成本优化等类似成果来达成这些目标。您必须将技术与业务结合起来规划这一转型，从组织未来 3-5 年的战略倒推，确定前进道路上的目标，并在需要时勇于调整。
## 组织以取得成功
随着组织的成熟，其为实现云迁移、采用和转型目标而构建的组织结构也将发生变化。了解这一点，做好准备，并有意识地进行规划，是确保成功的关键。
通常，在旅程开始时，最大的团队在本地环境中工作。然后，随着云采用率的增长，这些团队会迁移以构建、完善、运营和优化云平台，而您的组织必须在每个阶段适应新的工作方式。我们观察到，当组织将其 5% 到 10% 的工作负载迁移到云（从启动阶段转换到扩展阶段）时，就会发生困难但重要的变化。此时，由于迁移规模尚不足以需要进行全职调整，组织会安排本地团队来运营云资源，因此这些团队必须在现有职责与新职责之间取得平衡。同时，现在被要求运营云服务的本地团队需要掌握新技能，而这往往伴随着陡峭的学习曲线。
要了解您的组织并制定实现这些变更的计划，我们建议您审视整个 IT 组织中的团队拓扑结构。我们与客户一起使用此方法，以了解 IT 组织内部各职能之间的安排和相互关联（通常与组织结构不同），然后使用 AWS COM Framework 来指导如何组织以实现转型阶段和里程碑。任何可能需要的组织结构变更都以此为据。
我们与客户一起使用的拓扑包括分散式、集中式和联合模式。它们扩展了 [AWS Well-Architected Framework：卓越运营支柱](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/operating-model-2-by-2-representations.html)中涵盖的运营模式 2×2 展示图。
### 分散式
在不同地区或行业领域运营的大型跨国公司通常使用分散式模式，如下图所示。在这些公司中，各个业务部门都有自己的 IT 规定，其可能与其他地区或业务部门重叠。但是，这通常被理解和接受为在该区域内提供自主权和专业化的一种方式。
![\[分散式运营模式\]](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/strategy-cloud-operating-model/images/decentralized-op-model.png)
使用分散式方法意味着每个地区或业务部门都有自己的云运营模式，根据该地区或业务部门的需求量身打造。
### 集中化
集中式 IT 职能是我们最常见的模式。采用这种模式时，客户在建立云运营模式时力求保持相同的拓扑结构。此过程如下图所示。
![\[集中式运营模式\]](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/strategy-cloud-operating-model/images/centralized-op-model.png)
在此模式下，中心团队提供一个精心策划的平台，可供拥有自己云运营模式的工作负载团队使用。通过此方法，工作负载团队可以专注于为最终客户提供的价值，而不必担心其所使用平台的服务、运营或安全性。这种模式非常适合小型公司。但是，在大型跨国组织中，工作负载团队的数量可能达到数百甚至数千个。为了在不失去中央平台优势的情况下以这种规模进行管理，组织经常过渡到联合模式，下一节将对此进行概述。
### 联合身份
许多组织之所以采用联合 IT 模式，是因为该模式提供了一个负责云平台的中央职能部门，但在工作负载层面允许存在多种运营模式。这意味着中心团队可以专注于为组织提供可能的最佳平台，而不必受限于最低的共同点。下图展示联合模式。
![\[联合运营模式\]](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/strategy-cloud-operating-model/images/federated-op-model.png)
在大型组织中，联合模式既为工程团队提供了所需的自主性，又确保中央团队提供平台以及在所有工作负载之间通用的、无差异化的繁重工作。在这种模式下，中央团队必须与工程团队一样以产品为中心开展工作，但他们的产品就是平台。
### 更改拓扑结构以匹配旅程
您选择的拓扑结构取决于公司的规模，但也会根据您的云之旅所处阶段进行调整。部门或团队的组织并非一成不变，而是随着云采用的每个阶段变化。这意味着随着环境的变化，您可能要设计、讨论和扩充不同的拓扑结构。影响因素示例包括：
+ 从概念验证（POC）迁移到试点工作负载
+ 地域或业务部门扩张
+ 转向以产品为中心的团队
+ 通过共享组件或模式获得规模经济收益的机会
+ 实现 [Conway's Law](https://martinfowler.com/bliki/ConwaysLaw.html)，其对应用程序和服务设计的影响超过架构要求
+ 云优先规定或其他自上而下的举措
+ 由于团队目标或组织不兼容而导致未达成 KPI 或业务目标
## 建立推动变革的机制
在 Amazon 中，定义如下的一种*机制*：*将输入转换为输出并由组织杠杆组装而成的一种完整流程。它使用数据和反馈来支持流程并确保实现成果。*由于每个组织都不一样，因此每一次云运营模式之旅都不一样，但它们都需要一种机制来推动变革。
我们建议您花时间了解并开发相应的机制，以适应实施云运营模式所需的更改。一种常见的方法是采用敏捷原则。敏捷机制打破了孤立的团队之间基于组织和流程的壁垒，建立反馈循环，以确保您的组织花时间在最具影响力的活动上进行创新，从而带来最大的业务价值。
## 逐步提升成熟度
云运营模式背景下的*成熟度*是指您的能力与云优先工作方式的接近程度。例如，与创新（改变公司）相比，您的流程自主程度如何？管理日常业务（运营公司）需要多少人为参与？ 如果您的活动更侧重于前者，则您的（云）成熟度较低；如果侧重于后者，则成熟度较高。成熟度较低并非坏事，它反映了您在旅程中目前所处的阶段。目的是了解您当前所处的位置以及需要达到的目标。当我们与 AWS 客户合作时，我们会使用 AWS COM Framework 中的成熟度来提供整个旅程的各个步骤。
我们建议使用机制来逐步提高 AWS COM 框架功能的成熟度。例如，我们曾以这种方式与客户合作，将成熟度评估和优先级排序（输入）转换为成熟度的提升（输出），然后开展基于经验的活动，例如[实际试用](https://wa.aws.amazon.com/wellarchitected/2020-07-02T19-33-23/wat.concept.gameday.en.html)（反馈循环），以验证结果并根据需要进行调整。通过与客户一起建立这些机制，我们发现，当这种组织能力得到发展时，不仅能够实现短期里程碑，还能带来持续超越旅程初始阶段的渐进式改进。
关注组织能力的完善，并在路线图的特定时间点逐步构建特定能力所需的变革，将战略与实施紧密联系起来。这种方法还能帮助您利用既有成果积累带来的规模经济效益。