Création d'un plan d'implémentation en plusieurs phases

Pour identifier les applications que vous pouvez regrouper en cluster dans la même phase d'adoption, dessinez un graphique à quatre quadrants qui représente la préparation au cloud par rapport à la valeur commerciale de chacune des applications.

Voici un exemple de graphique :

La préparation au cloud montre dans quelle mesure vous êtes prêt à déplacer une application vers le cloud. Par exemple :

• Coût

• Risque

• Changement

• Contraintes techniques

Les applications davantage prêtes pour le cloud sont celles pour lesquelles la reconception de plate-forme ou le réhébergement présente le moins de difficultés, ou celles qui ne dépendent pas d'autres applications moins prêtes. Les applications moins prêtes pour le cloud peuvent nécessiter davantage de refactorisation ou présenter des dépendances importantes à d'autres applications qui doivent être réécrites avant de pouvoir être migrées.

La valeur commerciale correspond aux objectifs. Par exemple :

• Automatisation

• Agilité

• Innovation

• Continuité des activités

La valeur commerciale vous aide à catégoriser le rôle joué par une application dans votre entreprise ou la priorité stratégique associée au déplacement d'une application vers le cloud. La valeur commerciale d'une application est indépendante de son architecture.

Placez chaque application dans un quadrant du graphique. Pour déterminer la position appropriée, utilisez l'analyse d'attributs que vous avez effectuée précédemment pour les architectures existantes et les futures architectures possibles. Les applications que vous prévoyez de migrer au cours de la même phase doivent plus ou moins être incluses dans un même cluster. Si vous donnez la priorité à la préparation au cloud, les applications d'une même phase peuvent s'étendre sur tout le spectre de la valeur. De même, si vous privilégiez la valeur commerciale, les applications peuvent s'étendre sur tout le spectre de la préparation. Cependant, si une phase couvre plus de deux quadrants, nous vous recommandons de réévaluer le risque et la portée des changements, en particulier dans le contexte de l'adoption du cloud. Dans le cas où vous évaluez plusieurs projets parallèles relativement indépendants, vous devez examiner le graphique pour chaque projet séparément.

Si vous disposez de nombreuses applications héritées essentielles et que vous souhaitez effectuer une migration vers le cloud sans vous soumettre au préalable au long processus de réécriture de ces applications, il est conseillé de commencer par les applications situées dans le coin supérieur gauche, dont le degré de préparation est moindre en raison des contraintes héritées, mais la valeur commerciale plus élevée. Si votre entreprise n'aime pas prendre de risques, vous pouvez commencer par les applications du quadrant inférieur droit (degré de préparation plus élevé, valeur plus faible). En effet, ces applications sont prêtes à migrer vers le cloud et une panne potentielle aura un impact plus faible sur l'organisation. Si votre entreprise veut se concentrer sur un projet pilote initial ou a besoin d'apprendre à maîtriser la plate-forme, vous pouvez commencer par l'un ou l'autre des quadrants correspondant à un degré de préparation élevé.

Dans les grandes entreprises où il existe des applications relativement indépendantes, vous pouvez choisir de suivre différentes approches d'adoption du cloud en parallèle, dans différents secteurs d'activité.

La création d'un plan d'implémentation cloud est un processus itératif. Regroupez vos applications en différentes phases, mettez-les en correspondance avec les priorités de votre entreprise et planifiez les phases d'adoption. Répétez ensuite le processus avec les intervenants de votre entreprise, en faisant des compromis si nécessaire sur les dates, la portée ou le séquencement.

Commencez par identifier les groupes d'applications à traiter ensemble. Ensuite, examinez les implications des différentes décisions de séquencement. Les contraintes et les priorités de votre organisation doivent être prises en compte dans l'analyse. Souvent, les attributs suivants jouent un rôle majeur dans le regroupement des applications et la planification des phases d'adoption :

• Gravité des données : existe-t-il des groupes dont les applications ne peuvent pas être réparties entre le cloud et l'environnement sur site et qui doivent donc être résolus globalement ? Incluez des scénarios dans lesquels certaines applications sont retirées et d'autres réhébergées.

• Portée des changements : pour faciliter la gestion du changement, vous devrez peut-être décomposer des groupes d'applications plus importants en groupes plus petits. La gestion du changement est autant une question de personnes et de compétences que de nombre de composants technologiques. Les modifications consécutives au réhébergement d'un grand groupe d'applications peuvent être moins importantes que celles dues à la refactorisation et à la reconception de plate-forme d'un groupe d'applications plus petit.

• Tolérance au risque : comment les incertitudes et les risques inhérents au projet sont-ils amplifiés ou atténués par le rôle joué par les applications dans vos processus stratégiques ?

• Evénements déterminants : des technologies en fin de vie (par exemple, support logiciel ou renouvellement du matériel) ou des fermetures de locaux motivent-elles une décision particulière ?

Lorsque vous avez analysé votre architecture actuelle et votre architecture planifiée, vous avez évalué de nombreux attributs. Lors de la planification des phases d'adoption, utilisez également une vue agrégée ou de haut niveau. Les attributs répertoriés précédemment (gravité des données, portée des changements, tolérance au risque et événements déterminants) constituent un bon point de départ pour une vue de haut niveau. Selon les besoins de votre entreprise, vous pouvez identifier d'autres attributs plus importants pour le regroupement des applications en différentes phases et la validation du plan.

Dans votre plan, montrez comment chaque phase s'aligne sur les objectifs de votre entreprise (par exemple, création de systèmes plus résilients, possibilité de nouveau développement ou réponse à un événement déterminant). Si vous ne pouvez pas effectuer une phase d'adoption dans l'ordre souhaité par votre organisation, indiquez les raisons pour lesquelles la priorité a été donnée à une autre phase.

Pour valider votre stratégie, recoupez le graphique de préparation au cloud, la matrice de fonction stratégique, la vue d'attributs agrégée et d'autres angles d'approche architecturaux en fonction des attributs que vous avez collectés.

La gestion de la portée est essentielle pour progresser. Procédez à des itérations par petit bout, voire par sous-ensemble d'applications. Si nécessaire, répartissez les flux parallèles entre les différents secteurs d'activité. Si l'ambiguïté ne pose pas de problème à votre organisation, ne vous engagez pas dans tous les détails des futures phases. Identifiez plutôt les principaux points de décision à venir et présentez-les comme des risques inconnus ou essayez de définir quand vous pourriez être en mesure de prendre ces décisions. Par exemple, votre organisation choisira-t-elle une stratégie multicloud ou pouvez-vous prendre en charge un modèle hybride limité en raison d'exigences de résidence des données ou d'exigences sur site ?

Plus important encore, posez l'attente de base suivante : la planification de l'adoption du cloud n'est pas une activité ponctuelle, mais une activité que vous réitérez au fur et à mesure que vous apprenez. La modification des plans des phases futures ne doit pas être considérée comme un basculement en réaction à un problème, mais comme une révision visant à appuyer les objectifs de votre entreprise dans le contexte d'un écosystème technologique et architectural cloud en constante évolution.