你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

均衡项目组合

云采用是巧妙地伪装成技术实现的项目组合管理工作。 与任何项目组合管理练习一样，平衡项目组合非常重要。 在战略层面，这意味着要平衡迁移、创新和试验，以最大限度地利用云。 当云采用工作过于偏向某个方向时，采用工作就会变得复杂。 本文将向读者介绍用于实现项目组合平衡的方法。

一般范围扩大

平衡项目组合在本质上具有战略性。 因此，本文中所述的方法同样也是战略性方法。 为了让策略以数据驱动的决策为依据，本文假设读者已评估现有数字资产（或已开始评估）。 这种方法的目标是帮助评估工作负荷，以通过定性问题和项目组合优化来确保整个项目组合的适当平衡。

记录业务成果

平衡项目组合前，请务必先记录并共享驱动云迁移工作的业务成果。 下表有助于记录和共享相应业务成效。 值得注意的是，大多数企业都在同时追求多个业务成效。 这项工作的重要性在于，阐明与云迁移工作最直接相关的业务成效：

业务成效	衡量依据	目标	期限	此工作的优先级
降低 IT 成本	数据中心预算	减少 2 百万美元	12 个月	#1
数据中心退出	退出数据中心	2 个数据中心	6 个月	#2
提高业务敏捷性	缩短上市时间	将部署时间缩短六个月	2 年	#3
改善客户体验	客户满意度 (CSAT)	将客户满意度提高 10%	12 个月	#4

重要

上表是一个虚构示例，不得用来设置优先级。 在许多情况下，可以将此表视为反模式，因为它将节省成本优先于改善客户体验。

上表可以准确地表示云策略团队和云采用团队的优先级。 由于有短期约束，此团队更加重视降低 IT 成本，并将退出数据中心作为实现所需 IT 成本降低的方式来确定优先级。 不过，通过在此表中记录竞争的优先级，云采用团队有能力帮助云策略团队确定更好地协调总体项目组合策略实现的机会。

快速迁移的同时保持平衡

关于数字资产增量合理化的指导意见提出了一种方法，即合理化始于不平衡的位置。 云策略团队应评估每个工作负荷与重新托管方法的兼容程度。 之所以建议采用这种方法是因为，它可便于根据定量数据对复杂数字资产进行快速评估。 做出这样的初始假设，可以让云采用团队快速参与进来，从而缩短获取业务成效的时间。 不过，正如本文中所述，定性问题可实现必要的项目组合平衡。 本文记录了创建承诺平衡的过程。

停用决策的重要性

上面记录业务成效部分中的表缺少支持降低 IT 成本这一首要目标的关键业务成效。 无论降低 IT 成本排在业务成效列表中的任何位置，都请务必考虑停用工作负荷的可能性。 在某些情况下，可以通过不迁移不需要短期投资的工作负载来节省成本。 一些客户报告说，通过停用未充分利用的工作负荷，节省的成本超过20% 的节省总成本。

为了平衡项目组合，同时更好地反映终止和停用决策，建议云策略团队和云采用团队在评估和迁移期间针对每个工作负载提出以下问题：

• 在过去六个月内，最终用户是否使用了此工作负荷？
• 最终用户流量始终如一，还是在增长？
• 从现在开始的 12 个月内，业务是否需要此工作负荷？

如果这些问题的答案都是“否”，那么此工作负载可能就是停用候选项。 如果应用程序所有者确认了停用可能性，那么迁移此工作负载可能就没有意义了。 这就引出了一些资格问题：

• 能否为此工作负荷制定停用计划？
• 能否在退出数据中心前停用此工作负荷？

如果这两个问题的答案都是“能”，那么考虑不迁移此工作负载则是明智的做法。 这种方法有助于实现降低成本和退出数据中心的目标。

如果这两个问题之一的答案是“不能”，明智的做法是制定一个计划，用于在此工作负载停用前托管它。 此计划可能包括将资产迁移到成本较低的数据中心或备用数据中心，这也会实现降低成本和退出一个数据中心的目标。

采用过程变更

若要平衡项目组合，需要在采用阶段进行额外的定性分析，这有助于推动简单项目组合合理化。

根据上面记录业务成效部分中表内的数据，项目组合可能过于倾向于以迁移为重点的执行模型，这可能会带来风险。 如果改善客户体验的优先级最高，那么项目组合更有可能是偏重创新。 两者都没有对错之分，但是过于偏向一个方向通常会导致收益递减、增加不必要的复杂性，并延长与云采用工作相关的执行时间。

为了降低复杂性，你应当遵循传统的项目组合合理化方法，但是要采用迭代模型。 以下步骤概述了此类方法的定性模型：

• 云策略团队维护要迁移的已设置优先级的工作负荷积压工作。
• 在完成每次发布前，云策略团队和云采用团队主持发布计划会议。
• 在发布计划会议中，团队就已设置优先级的积压工作中的前 5 到 10 个工作负荷达成一致。
• 在发布计划会议之外，云采用团队向应用程序所有者和行业专家提出以下问题：
  • 此应用程序能否替换为平台即服务 (PaaS) 等效项？
  • 此应用程序是否为第三方应用程序？
  • 预算是否已获准在未来 12 个月内投资用于持续开发此应用程序？
  • 此应用程序的额外开发是否会改善客户体验？ 是否会创造竞争优势？ 是否会带来额外业务收入？
  • 此工作负载中的数据是否有助于与 BI、机器学习、IoT 或相关技术有关的下游创新？
  • 此工作负荷是否与新式应用程序平台（如 Azure 应用服务）兼容？
• 上述问题的答案以及其他任何必需的定性分析都会影响对已设置优先级的积压工作的调整。 这些调整可能包括：
  • 如果可以用 PaaS 解决方案替换工作负荷，就能将此工作负荷从迁移积压工作中完全删除。 至少，决定是重新托管还是替换的额外尽职调查将作为一项任务添加进来，暂时降低此工作负载在迁移积压工作 (backlog) 中的优先级。
  • 如果工作负载正在（或应该）进行开发改进，它可能最适合“重构-重新架构-重新生成”模型。 由于创新和迁移需要不同的技能，因此通过创新积压工作（而不是迁移积压工作）来管理适合“重构-重新架构-重新生成”方法的应用程序。
  • 如果工作负荷是下游创新的一部分，最好重构数据平台，但要将应用程序层留作重新托管候选项。 工作负荷数据平台的次要重构通常可以在迁移或创新积压工作中解决。 此合理化成效可能会导致积压工作中的工作项更细化，但除此之外不会改变优先级。
  • 如果工作负载不是战略性的，但与基于云的新式应用程序托管平台兼容，那么明智的做法是，对应用程序进行次要重构，以将它部署为新式应用程序。 这可能会通过减少云迁移的总体 IaaS 和 OS 许可需求来促进节省总成本。
  • 如果工作负荷是第三方应用程序，且此工作负荷的数据没有计划用于下游创新，那么最好将它留作积压工作中的重新托管选项。

这些问题不应属于针对每个工作负载完成的定性分析范围，它们帮助引导关于应对非平衡项目组合的复杂性的对话。

迁移过程变更

在迁移过程中，项目组合平衡活动可能会对迁移速度（资产迁移速度）造成负面影响。 下面的指南将扩展介绍为什么以及如何协调工作来避免中断迁移工作。

项目组合合理化需要技术工作的多样性。 云采用团队很容易在迁移工作中配合这样的项目组合多样性。 业务利益干系人要求，由一个云采用团队来处理整个迁移积压工作。 这很少是一种可取的方法，在许多情况下，这可能会适得其反。

应在两个或更多个云采用团队中细分这些不同的工作。 使用一个两团队模型作为执行模式示例，团队 1 是迁移团队，团队 2 是创新团队。 对于更大型的工作，可以进一步细分这些团队，以应对其他方法（如替换/PaaS 工作或次要重构）。 下面概述了重新托管、重构或次要重构所需的技能和角色：

重新托管：重新托管要求团队成员实现以基础结构为重点的变更。 通常使用 Azure Site Recovery 等工具将 VM 或其他资产迁移到 Azure 中。 这项工作非常适合数据中心管理员或 IT 实现人员。 云迁移团队的结构良好，可以大规模地交付这项工作。 在大多数情况下，这是迁移现有资产的最快方法。

重构：重构要求团队成员修改源代码、改变应用程序体系结构或采用新的云服务。 一般来说，这项工作会使用 Visual Studio 等开发工具和 Azure DevOps 等开发管道工具，将新式化应用程序重新部署到 Azure。 这项工作非常适合应用程序开发角色或 DevOps 管道开发角色。 云创新团队的结构最适合交付这项工作。 虽然使用这种方法将现有资产替换为云资产可能需要更长时间，但这些应用程序可以利用云原生功能。

次要重构：一些应用程序可以在数据或应用程序级别通过次要重构来实现新式化。 这项工作要求团队成员将数据部署到基于云的数据平台，或对应用程序进行少量的配置变更。 这可能需要对数据或应用程序开发行业专家的有限支持。 不过，这项工作类似于 IT 实现人员在部署第三方应用程序时执行的工作。 可以很容易地与云迁移团队或云策略团队协调这项工作。 虽然这项工作的速度不如重新托管迁移快，但是执行它所需的时间要比重构工作短。

在迁移期间，应按上面列出的三种方式对工作进行细分，并由适当的团队在适当的迭代中这些工作。 尽管你应使项目组合多样化，但也要让工作重点突出且相互隔离。

后续步骤

了解全球市场决策对转换旅程的影响。

了解全球市场