本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 为应用程序组合建立基准
<a name="baseline-application-portfolio"></a>

要制定高度可信的迁移浪潮计划，必须为应用程序组合及其相关基础设施建立基准。产品组合基准提供了迁移范围的全面视图，包括技术依赖关系和迁移策略。产品组合基准可以清楚地说明哪些应用程序在迁移范围内，并收集了 “[了解完整评估数据要求” 部分中概述的数据](understanding-complete-assessment-data-requirements.md)点。同样，所有相关的基础架构（计算、存储网络）都被理解并映射到应用程序。

技术依赖关系可以分为四类：
+ pplication-to-infrastructure依赖关系@@ **建立了**软件与物理或虚拟硬件之间的联系。例如，CRM 应用程序与安装该应用程序的虚拟机之间存在依赖关系。
+ **应用程序组件**依赖关系描述了在不同基础架构资产中运行的组件是如何交互的。应用程序组件依赖关系的一个示例是在虚拟机上运行的 Web 前端，应用程序层在不同的虚拟机上运行，数据库运行在数据库集群上。
+ **pplication-to-application依赖关系与应用程序或应用程序组件与其他应用程序或其组件之间的交互有关。** application-to-application依赖关系的一个例子是付款处理应用程序和库存管理应用程序。这些应用程序是独立的，但它们经常使用定义的 API 操作进行交互。
+ Application-to-infrastructure 鉴于基础设施@@ **服务**本身就是一个应用程序，服务 application-to-application依赖关系在技术上是依赖关系。但是，我们建议将它们分开分类。主要原因是基础设施服务通常由许多应用程序共享，因此它们有很长的依赖关系。它们通常还遵循不同的迁移策略和模式。例如，负载均衡器可以包含多个应用程序的平衡池。重要的是对池的依赖关系，它很可能会与依赖的应用程序一起单独迁移，而负载均衡器本身则被保留或停用。此外，个性化 application-to-infrastructure服务依赖关系有助于避免错误的依赖组。错误依赖组是指将多个业务应用程序组合在一起，这意味着必须同时迁移与基础架构服务有共同依赖关系的业务应用程序。例如，诸如 Active Directory 之类的身份验证服务很可能与大型应用程序组相关联。关键是要单独处理这些应用程序，并通过在云环境中启用服务（例如在云环境 AWS Directory Service for Microsoft Active Directory中）来解决依赖关系。

在为产品组合建立基准时，我们建议您确认每个应用程序组件的迁移策略。迁移策略将是迁移的 6 R 策略之一（参见 “[迭代 6 R 迁移策略](iterating-6-rs-migration-strategy-selection.md)” 部分）。在投资组合基准中，应将6R中的一个与每个应用程序相关联。还应将 6 R 策略与应用程序的每个基础架构组件相关联。

要建立产品组合的基准版本，包括依赖关系和迁移策略，请使用自动发现工具（请参阅[评估对发现工具的需求](understanding-initial-assessment-data-requirements.md#discovery-tooling)）。使用从应用程序所有者和基础设施团队等关键利益相关者那里收集的信息来补充数据。继续收集数据，直到获得与本阶段[数据要求部分](understanding-complete-assessment-data-requirements.md)中概述的属性和保真度相匹配的完整投资组合清单。生成的数据集将有助于推动迁移。

请考虑一下，根据您的迁移范围和可用工具，此活动可能需要几周才能完成。