Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Établir une base de référence pour le portefeuille d'applications
Pour créer des plans de vague de migration fiables, vous devez établir une base de référence pour le portefeuille d'applications et son infrastructure associée. Une base de portefeuille fournit une vue complète de l'étendue de la migration, y compris les dépendances techniques et la stratégie de migration. La base de référence du portefeuille indique clairement quelles applications sont concernées par la migration et indique que les points de données décrits dans la section Comprendre les exigences complètes en matière de données d'évaluation sont collectés. De même, toute l'infrastructure associée (calcul, réseaux de stockage) est comprise et mappée aux applications.
Les dépendances techniques peuvent être décrites en quatre catégories :
-
Les pplication-to-infrastructure dépendances établissent le lien entre le logiciel et le matériel physique ou virtuel. Par exemple, il existe une dépendance entre une application CRM et les machines virtuelles sur lesquelles elle est installée.
-
Les dépendances entre les composants de l'application décrivent la manière dont les composants exécutés dans différents actifs d'infrastructure interagissent. Une interface Web exécutée sur des machines virtuelles, avec une couche d'application exécutée sur une machine virtuelle différente et une base de données exécutée sur un cluster de bases de données constituent un exemple de dépendance entre les composants d'une application.
-
Les pplication-to-application dépendances ont trait à l'interaction entre des applications ou des composants d'applications avec d'autres applications ou leurs composants. Une application de traitement des paiements et une application de gestion des stocks sont des exemples de application-to-application dépendance. Ces applications sont indépendantes, mais elles interagissent constamment à l'aide d'opérations d'API définies.
-
Les dépendances d'un pplication-to-infrastructure service sont techniquement application-to-application des dépendances, étant donné que le service d'infrastructure est lui-même une application. Cependant, nous vous recommandons de les classer séparément. La raison principale est que les services d'infrastructure sont généralement partagés par de nombreuses applications, de sorte qu'ils ont une longue série de dépendances. Ils suivent également généralement une stratégie et un modèle de migration différents. Par exemple, un équilibreur de charge peut contenir des pools d'équilibrage pour plusieurs applications. Ce qui compte, c'est la dépendance vis-à-vis du pool, qui est susceptible d'être migré individuellement, parallèlement à l'application dépendante, tandis que l'équilibreur de charge lui-même est conservé ou retiré. En outre, l'individualisation des dépendances des application-to-infrastructure services permet d'éviter les faux groupes de dépendances. Un faux groupe de dépendances se produit lorsque plusieurs applications métiers sont regroupées, ce qui implique qu'elles ont une dépendance commune à un service d'infrastructure qui doit être migrée en même temps. Par exemple, les services d'authentification, tels qu'Active Directory, sont susceptibles d'être associés à de grands groupes d'applications. L'essentiel est d'aborder ces applications individuellement et de remédier à la dépendance en activant le service, tel que AWS Directory Service pour Microsoft Active Directory, dans l'environnement cloud.
Lorsque vous établissez une base de référence pour le portefeuille, nous vous recommandons de confirmer une stratégie de migration pour chaque composant de l'application. La stratégie de migration sera l'un des 6 R de la migration (voir la section « Itérer la stratégie de migration des 6 R »). Dans la base de référence du portefeuille, l'un des 6 R doit être associé à chaque application. Une stratégie 6 R doit également être associée à chacun des composants de l'infrastructure de l'application.
Pour établir une version de référence du portefeuille, y compris les dépendances et les stratégies de migration, utilisez des outils de découverte automatisés (voir Évaluation du besoin d'outils de découverte). Complétez les données avec des informations recueillies auprès des principales parties prenantes telles que les propriétaires d'applications et les équipes d'infrastructure. Continuez à collecter des données jusqu'à ce que vous obteniez un inventaire complet du portefeuille qui correspond aux attributs et au niveau de fidélité décrits dans la section sur les exigences en matière de données pour cette étape. L'ensemble de données qui en résultera jouera un rôle déterminant dans la conduite de la migration.
Sachez qu'en fonction de l'étendue de votre migration et des outils disponibles, cette activité peut prendre plusieurs semaines.
