实施路线图 - AWS Prescriptive Guidance

实施路线图

制定路线图后,需要将其付诸实施。我们发现,客户面临的下一个挑战就在这里:他们已经花时间进行了思考,现在必须转向行动。为了将您的策略与实施联系起来,我们建议您执行以下步骤:

决定从哪里开始以及如何开始

这听起来很简单,但由于要实现的目标太多了,找到切入点往往是一个棘手且充满争议的问题。正在向云迁移的组织有许多需要关注的方面,如果没有放在合适的背景中,这一举措很容易变得令人不堪重负。多年来,客户趋势不断演变,但一个始终如一的起点是变革型领导力。自上而下推动指令和策略,制定使命宣言、原则和公关常见问题解答,使中层管理人员和个人能够自主作出决策,提高清晰度,通过云转型推动业务价值。如果您还没有进行过此类练习或类似的练习,我们建议您将其作为首要任务。

在此练习过程中,您应该认识到,与其他技术转型不同,云转型使技术更贴近业务。技术是企业用来实现更广泛目标的杠杆,通过赋能敏捷性、稳定性、成本优化等类似成果来达成这些目标。您必须将技术与业务结合起来规划这一转型,从组织未来 3-5 年的战略倒推,确定前进道路上的目标,并在需要时勇于调整。

组织以取得成功

随着组织的成熟,其为实现云迁移、采用和转型目标而构建的组织结构也将发生变化。了解这一点,做好准备,并有意识地进行规划,是确保成功的关键。

通常,在旅程开始时,最大的团队在本地环境中工作。然后,随着云采用率的增长,这些团队会迁移以构建、完善、运营和优化云平台,而您的组织必须在每个阶段适应新的工作方式。我们观察到,当组织将其 5% 到 10% 的工作负载迁移到云(从启动阶段转换到扩展阶段)时,就会发生困难但重要的变化。此时,由于迁移规模尚不足以需要进行全职调整,组织会安排本地团队来运营云资源,因此这些团队必须在现有职责与新职责之间取得平衡。同时,现在被要求运营云服务的本地团队需要掌握新技能,而这往往伴随着陡峭的学习曲线。

要了解您的组织并制定实现这些变更的计划,我们建议您审视整个 IT 组织中的团队拓扑结构。我们与客户一起使用此方法,以了解 IT 组织内部各职能之间的安排和相互关联(通常与组织结构不同),然后使用 AWS COM Framework 来指导如何组织以实现转型阶段和里程碑。任何可能需要的组织结构变更都以此为据。

我们与客户一起使用的拓扑包括分散式、集中式和联合模式。它们扩展了 AWS Well-Architected Framework:卓越运营支柱中涵盖的运营模式 2×2 展示图。

分散式

在不同地区或行业领域运营的大型跨国公司通常使用分散式模式,如下图所示。在这些公司中,各个业务部门都有自己的 IT 规定,其可能与其他地区或业务部门重叠。但是,这通常被理解和接受为在该区域内提供自主权和专业化的一种方式。

分散式运营模式

使用分散式方法意味着每个地区或业务部门都有自己的云运营模式,根据该地区或业务部门的需求量身打造。

集中化

集中式 IT 职能是我们最常见的模式。采用这种模式时,客户在建立云运营模式时力求保持相同的拓扑结构。此过程如下图所示。

集中式运营模式

在此模式下,中心团队提供一个精心策划的平台,可供拥有自己云运营模式的工作负载团队使用。通过此方法,工作负载团队可以专注于为最终客户提供的价值,而不必担心其所使用平台的服务、运营或安全性。这种模式非常适合小型公司。但是,在大型跨国组织中,工作负载团队的数量可能达到数百甚至数千个。为了在不失去中央平台优势的情况下以这种规模进行管理,组织经常过渡到联合模式,下一节将对此进行概述。

联合身份

许多组织之所以采用联合 IT 模式,是因为该模式提供了一个负责云平台的中央职能部门,但在工作负载层面允许存在多种运营模式。这意味着中心团队可以专注于为组织提供可能的最佳平台,而不必受限于最低的共同点。下图展示联合模式。

联合运营模式

在大型组织中,联合模式既为工程团队提供了所需的自主性,又确保中央团队提供平台以及在所有工作负载之间通用的、无差异化的繁重工作。在这种模式下,中央团队必须与工程团队一样以产品为中心开展工作,但他们的产品就是平台。

更改拓扑结构以匹配旅程

您选择的拓扑结构取决于公司的规模,但也会根据您的云之旅所处阶段进行调整。部门或团队的组织并非一成不变,而是随着云采用的每个阶段变化。这意味着随着环境的变化,您可能要设计、讨论和扩充不同的拓扑结构。影响因素示例包括:

  • 从概念验证(POC)迁移到试点工作负载

  • 地域或业务部门扩张

  • 转向以产品为中心的团队

  • 通过共享组件或模式获得规模经济收益的机会

  • 实现 Conway's Law,其对应用程序和服务设计的影响超过架构要求

  • 云优先规定或其他自上而下的举措

  • 由于团队目标或组织不兼容而导致未达成 KPI 或业务目标

建立推动变革的机制

在 Amazon 中,定义如下的一种机制将输入转换为输出并由组织杠杆组装而成的一种完整流程。它使用数据和反馈来支持流程并确保实现成果。由于每个组织都不一样,因此每一次云运营模式之旅都不一样,但它们都需要一种机制来推动变革。

我们建议您花时间了解并开发相应的机制,以适应实施云运营模式所需的更改。一种常见的方法是采用敏捷原则。敏捷机制打破了孤立的团队之间基于组织和流程的壁垒,建立反馈循环,以确保您的组织花时间在最具影响力的活动上进行创新,从而带来最大的业务价值。

逐步提升成熟度

云运营模式背景下的成熟度是指您的能力与云优先工作方式的接近程度。例如,与创新(改变公司)相比,您的流程自主程度如何?管理日常业务(运营公司)需要多少人为参与? 如果您的活动更侧重于前者,则您的(云)成熟度较低;如果侧重于后者,则成熟度较高。成熟度较低并非坏事,它反映了您在旅程中目前所处的阶段。目的是了解您当前所处的位置以及需要达到的目标。当我们与 AWS 客户合作时,我们会在 AWS COM Framework 内使用成熟度等级来提供整个旅程的各个步骤。

我们建议使用机制逐步提升 AWS COM Framework 功能的成熟度。例如,我们曾以这种方式与客户合作,将成熟度评估和优先级排序(输入)转换为成熟度的提升(输出),然后开展基于经验的活动,例如实际试用(反馈循环),以验证结果并根据需要进行调整。通过与客户一起建立这些机制,我们发现,当这种组织能力得到发展时,不仅能够实现短期里程碑,还能带来持续超越旅程初始阶段的渐进式改进。

关注组织能力的完善,并在路线图的特定时间点逐步构建特定能力所需的变革,将战略与实施紧密联系起来。这种方法还能帮助您利用既有成果积累带来的规模经济效益。