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.

Tâche 4 : Définition du processus d'analyse approfondie de l'application

Maintenant que vous avez terminé d'établir les règles et les processus de priorisation des applications, vous devez effectuer une analyse approfondie des applications qui vous aidera à affiner la priorité de chaque application. Vous effectuez l'analyse approfondie de l'application sur une application à la fois, de la priorité la plus élevée à la plus faible. Pour les projets impliquant plusieurs équipes de portefeuille, chaque équipe peut effectuer une analyse approfondie d'une application différente en même temps.

Au cours de l'analyse approfondie, vous pouvez rencontrer des problèmes inattendus, tels que des dépendances, qui ont une incidence sur la complexité de la migration de l'application. Dans ce cas, vous devez modifier les critères de notation de complexité que vous avez définis à l'étape précédente et mettre à jour la feuille de score en conséquence afin d'obtenir des scores de complexité plus précis pour les futures applications. Vous pouvez ensuite mettre à jour les priorités des applications en utilisant les nouveaux scores de complexité.

Cette tâche comprend les étapes suivantes :

Étape 1 : Définir le processus de l'atelier de candidature

Le processus d'atelier est l'une des approches les plus efficaces pour une analyse approfondie d'une application. À l'aide de ce processus, vous collaborez avec les parties prenantes, les propriétaires de l'application et l'équipe du portefeuille pour évaluer et analyser l'application. L'objectif est de bien comprendre l'état actuel de l'application, notamment son architecture, son objectif commercial, ses dépendances et son environnement. Vous utilisez ensuite ces informations détaillées sur la taille et la complexité de l'application pour définir l'état cible de l'application.

Chaque atelier dure généralement de 1 à 8 heures, mais vous constaterez peut-être que du temps supplémentaire est nécessaire pour les applications très complexes. Vous pouvez également diviser l'atelier en plusieurs réunions, en fonction de la disponibilité des ressources, de vos préférences, ainsi que de la taille et de la complexité de l'application.

Identifier les résultats attendus

Avant d'organiser un atelier de candidature, vous devez établir un ordre du jour et définir les résultats attendus de l'atelier, ou les informations que vous devez collecter dans le cadre de l'atelier. Cela permet aux participants à l'atelier de se préparer pour l'atelier, aide à respecter les objectifs de la réunion et garantit qu'à la fin de l'atelier, vous disposez de toutes les informations nécessaires pour établir les priorités, planifier les vagues et faire migrer l'application.

Nous vous recommandons de définir un ensemble standard de résultats attendus et de les documenter dans votre manuel de priorisation des applications. Lorsque vous préparez un atelier, vous utilisez les résultats attendus standard et vous en ajoutez de nouveaux pour l'application spécifique.

Définissez l'ensemble standard de résultats attendus pour les ateliers de candidature comme suit :

Voici des exemples de résultats attendus pour l'atelier de candidature.

Définir les règles de l'atelier d'application

Avant d'organiser un atelier de candidature, vous devez définir les règles qui régiront votre atelier. Les règles communes incluent la durée de l'atelier, les outils qui peuvent être nécessaires dans le cadre de l'atelier et les considérations relatives à la planification ou aux délais à prendre en compte. Cela permet de respecter les objectifs de la réunion et de garantir que les décisions prises dans le cadre de l'atelier sont conformes au calendrier de migration.

Nous vous recommandons de documenter les règles de l'atelier d'application dans votre runbook de priorisation des applications.

Définissez les règles de votre atelier d'application comme suit :

Vous trouverez ci-dessous des exemples de règles pour l'atelier de candidature.

Définir le processus de l'atelier de candidature

Il est important que vous définissiez un processus standard pour l'organisation des ateliers de candidature. Cela garantit une expérience cohérente et définit les attentes des participants à l'atelier, ce qui peut améliorer l'efficacité de l'atelier.

Le processus de candidature à l'atelier de candidature comporte trois étapes :

Le modèle Runbook pour la priorisation des applications inclut un step-by-step processus standard de préparation, de conduite et de finalisation d'un atelier de candidature. Définissez le processus de votre atelier de candidature comme suit :

Critères de sortie de l'étape

Étape 2 : définir le processus de mappage des applications

Le mappage des applications est le processus qui consiste à attribuer à chaque application un modèle de migration, que vous avez identifié et validé. Étape 4 : Valider les modèles de migration Au cours de cette étape, vous définissez les règles que vous utiliserez pour évaluer l'application. Vous définissez ensuite le processus que vous utiliserez pour évaluer chaque candidature. Le mappage de chaque application en fonction du cas d'utilisation du modèle de migration vous permet d'identifier l'outil de migration, les compétences nécessaires pour effectuer la migration et la complexité du modèle de migration.

Vous ne migrez pas toujours une application vers un modèle unique. Pour plus d'informations sur les cas où vous pourriez avoir besoin de plusieurs modèles pour la même application, voir Définition du processus de mappage des applications plus loin dans cette section.

Règles de mappage des applications

Les règles de mappage des applications vous aident à évaluer l'application et à identifier le modèle de migration approprié. Chaque règle comprend toutes les informations que vous devez utiliser pour évaluer l'application et faire correspondre les critères du modèle.

Dans les modèles de playbook de portfolio, le modèle Runbook pour la priorisation des applications inclut une section pour documenter les règles de mappage de vos applications. Définissez votre processus comme suit :

Le tableau suivant fournit des exemples de règles de mappage d'applications.

Définition du processus de mappage des applications

Lorsque vous associez des applications aux modèles de migration, il est utile de demander des données de découverte pour l'application à l'équipe de découverte. Ces données incluent généralement des informations telles qu'un modèle de migration recommandé (parfois appelé modèle R ou score R), des informations sur l'utilisation, les dépendances des applications et d'autres informations que vous pouvez utiliser dans le cadre de l'évaluation. Au fur et à mesure que vous explorerez cette application en détail, vous déciderez peut-être de modifier le modèle de migration précédemment identifié.

Lorsque vous disposez des données, vous pouvez comparer l'application aux critères commerciaux et techniques que vous avez identifiésÉtape 2 : Identifier les moteurs commerciaux et techniques. Vous avez enregistré vos pilotes dans votre runbook de priorisation des applications. L'évaluation de l'application par rapport aux critères peut vous amener à sélectionner plusieurs modèles de migration pour l'application ou à éliminer des modèles basés sur le coût, le calendrier ou d'autres limitations.

Voici un exemple de moteur commercial qui vous oblige à utiliser plusieurs modèles de migration sur une seule application. Vous souhaitez migrer une base de données SQL Server sur site vers Amazon DynamoDB, mais comme le contrat du centre de données arrive à expiration, l'entreprise souhaite la migrer plus tôt que prévu pour la replateforme. Pour répondre à ce facteur commercial, vous devez revoir le plan de migration de l'application selon une approche à deux modèles. Tout d'abord, vous réhébergez l'application dans le cloud afin de la supprimer du centre de données. Plus tard, une fois l'application dans le cloud, vous pouvez la reconfigurer selon le calendrier proposé.

Vous devez également déterminer si l'application est une application à n niveaux, c'est-à-dire une application composée de plusieurs niveaux. Un niveau d'application est un groupe de serveurs physiques hébergeant les couches horizontales de votre application. Les applications de niveau N sont plus complexes car chaque niveau peut nécessiter une stratégie différente, et vous pouvez choisir de migrer les niveaux d'application par vagues différentes. Par exemple, si vous avez une application composée de niveaux de présentation, de service métier et de base de données, il est possible que vous puissiez mapper un modèle différent pour chaque niveau.

Vous évaluez ensuite l'application par rapport à vos règles de mappage d'applications, que vous avez définies dans votre runbook de priorisation des applications. Pour plus d’informations, consultez Règles de mappage des applications plus haut dans cette section.

Après avoir mappé votre application à un ou plusieurs modèles, passez en revue et vérifiez cette décision auprès du propriétaire de l'application. Le propriétaire de l'application doit confirmer le modèle sélectionné et vous aider à planifier et à effectuer la migration. À l'heure actuelle, les propriétaires d'applications peuvent également fournir des informations basées sur leur expérience ou partager les problèmes qu'ils anticipent concernant la migration.

Lorsque vous avez mappé l'application sur un ou plusieurs modèles de migration et que vous avez confirmé les modèles avec le propriétaire de l'application, vous enregistrez l'application, l'ID du modèle, le nom du modèle et les pilotes pertinents dans une table de mappage des applications de votre runbook de priorisation des applications.

Dans les modèles de playbook de portfolio, le modèle Runbook pour la priorisation des applications inclut un step-by-step processus standard de mappage des applications. Définissez votre processus comme suit :

Le tableau suivant est un exemple de tableau de mappage d'applications. Le modèle Runbook fourni pour la priorisation des applications inclut un tableau vide dans lequel vous pouvez enregistrer les résultats du processus de mappage des applications.

Critères de sortie de l'étape

Étape 3 : (Facultatif) Définissez l'état cible de l'application

Au cours de cette étape, vous définissez les attributs et le processus que vous utilisez pour documenter l'état cible, ou futur, de l'application. L'état cible correspond au mode de fonctionnement de l'application dans l'environnement cloud cible après la migration. L'environnement cible varie en fonction de votre plate-forme ou service cible et des exigences commerciales. L'environnement cible peut être le AWS Cloud ou AWS Managed Services (AMS).

La définition de l'état cible permet aux chefs de projet, aux consultants en migration, aux architectes, aux propriétaires d'applications et aux parties prenantes de collaborer efficacement. En utilisant ce processus, l'équipe peut identifier et résoudre les problèmes à l'avance et implémenter plus efficacement l'environnement de l'état cible.

Pour certaines applications, cette étape est facultative. Vous pouvez ignorer cette étape si l'application que vous migrez est autonome ou peu complexe. Les stratégies de migration qui ne modifient pas l'application, telles que le réhébergement, peuvent ne pas nécessiter cette étape. Toutefois, pour les stratégies de migration plus complexes, telles que la replateforme et la reconfiguration de l'architecture, vous devez définir l'état cible avant de commencer la migration.

L'atelier vous fournit une compréhension approfondie de l'état actuel de l'application. Il est donc conseillé de rédiger l'état cible une fois l'atelier terminé. En outre, le mappage de l'application à son modèle de migration fournit des informations supplémentaires et vous aide à déterminer s'il est nécessaire de définir l'état cible. Par exemple, si vous mappez l'application au modèle Rehost to Amazon EC2 à l'aide d'Application Migration Service ou de Cloud Migration Factory, vous avez identifié que la stratégie est le réhébergement et vous n'avez probablement pas besoin de définir l'état cible pour cette application.

Attributs de l'état cible

Lorsque vous définissez l'état cible et que vous prenez des décisions concernant l'application, nous vous recommandons de prendre en compte les attributs d'état cible suivants :

Définir le processus de l'état cible

Pour définir l'état cible de l'application, nous vous recommandons d'utiliser le modèle fourni, Feuille de travail sur l'état cible de l'application (format Excel), qui est disponible dans les modèles de playbook de portfolio. Le modèle inclut des attributs standard que vous pouvez utiliser ou modifier. Définissez le processus de documentation de l'état cible de l'application comme suit :

Exemples de l'état cible de l'application

Le tableau suivant montre un exemple de la manière dont vous utilisez la feuille de travail sur l'état cible de l'application pour documenter l'état cible de l'application.

Critères de sortie de l'étape

Étape 4 : Finalisation du processus d'analyse approfondie de l'application

À présent, vous définissez comment le flux de travail du portefeuille utilise l'atelier, les règles et les processus que vous avez établis dans le cadre de cette tâche pour effectuer une analyse approfondie de l'application. Il s'agit du processus auquel le flux de travail du portefeuille fait référence lors de la phase de mise en œuvre de la migration.

Personnalisez ce processus dans le runbook de priorisation des applications comme suit :