Création d'un plan de mise en oeuvre par phases

Pour identifier les groupes d'applications que vous pouvez rassembler dans la même phase d'adoption, dessinez un graphique à quatre quadrants permettant de comparer le niveau de préparation pour le nuage et la valeur opérationnelle de chaque application.

Voici un exemple de graphique :

La préparation pour le nuage indique si vous êtes plus ou moins bien préparé à déplacer une application vers le nuage. Par exemple :

• Coût

• Risque

• Changement

• Contraintes techniques

Les applications les mieux préparées pour le nuage sont celles qui peuvent changer de plate-forme ou d'hébergement facilement, ou qui ne dépendent pas d'autres applications qui, elles, ne sont pas prêtes. Les applications les moins prêtes pour le nuage sont celles qui nécessitent un réusinage plus conséquent, ou qui présentent des dépendances importantes par rapport à d'autres applications qui doivent être réécrites avant de pouvoir être migrées.

La valeur opérationnelle saisit les objectifs. Par exemple :

• Automatisation

• Agilité

• Innovation

• Continuité des activités

La valeur opérationnelle vous aide à caractériser le rôle d'une application dans votre entreprise ou la priorité stratégique associée au transfert d'une application vers le nuage. La valeur opérationnelle 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 architectures futures possibles. Les applications que vous prévoyez de migrer au cours de la même phase doivent être relativement bien regroupées. Si vous privilégiez la préparation pour le nuage, les applications d'une phase peuvent couvrir le spectre de valeur. De même, si vous donnez la priorité à la valeur commerciale, les applications peuvent couvrir le spectre de préparation. Toutefois, 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 de l'environnement en nuage. Faites une exception si vous évaluez plusieurs projets parallèles et relativement indépendants; dans ce cas, vous devez consulter le graphique de chaque projet séparément.

Si vous disposez de nombreuses applications existantes critiques et que vous souhaitez migrer vers le nuage sans avoir à passer du temps à les réécrire, vous pouvez commencer par les applications situées dans le coin supérieur gauche, moins prêtes en raison des contraintes existantes, mais présentant une valeur opérationnelle supérieure. Si votre organisation est exposée au risque, vous pouvez commencer par les applications situées dans le quadrant inférieur droit (prêtes pour le nuage mais présentant une valeur inférieure) car elles sont prêtes à migrer vers le nuage et que toute défaillance potentielle aurait une incidence moins importante sur l'organisation. Si votre organisation préfère se concentrer sur un projet pilote initial ou qu'elle souhaite se familiariser avec la plate-forme, l'un ou l'autre des quadrants supérieurs constitue un bon point de départ.

Dans une grande entreprise, vous pouvez avoir des applications relativement indépendantes et adopter des approches parallèles différentes pour l'adoption de l'environnement en nuage selon les secteurs d'activité.

L'élaboration d'un plan de mise en oeuvre du nuage est un processus itératif. Regroupez vos applications dans des phases, mappez les applications aux priorités de l'entreprise, planifiez les phases d'adoption, puis procédez à des itérations avec les parties prenantes de l'entreprise, en effectuant des compromis sur les dates, la portée ou le classement des opérations.

Commencez par identifier les groupes d'applications qui doivent être traitées ensemble. Ensuite, examinez les implications des différentes options de classement. Les priorités et les contraintes d'affaires de votre organisation doivent être prises en compte lors de cette analyse. Souvent, les attributs suivants jouent un rôle déterminant dans le regroupement des applications et la planification des phases d'adoption :

• Densité des données : Existe-t-il des groupes d'applications qui ne peuvent pas être fractionnées entre le nuage et l'environnement sur place, et qui doivent être traitées ensemble? Incluez des scénarios dans lesquels certaines applications sont retirées et d'autres changent d'hébergement.

• Portée des modifications : Pour faciliter la gestion des modifications, vous devrez peut-être diviser les groupes d'applications en groupes plus petits. La gestion des modifications concerne autant les personnes et les compétences que le nombre de composants technologiques. Le changement d'hébergement de nombreuses applications peut entraîner moins de modifications que le réusinage et le changement de plate-forme d'un plus petit nombre d'applications.

• Tolérance au risque : Dans quelle mesure les incertitudes et les risques liés au projet sont-ils amplifiés ou atténués par le rôle que jouent les applications dans vos processus critiques?

• Événements incontournables : Existe-t-il des facteurs technologiques de fin de vie, comme le soutien logiciel ou les renouvellements de matériel, ou des fermetures de locaux, qui motivent une décision particulière?

Lorsque vous avez analysé votre architecture courante et votre architecture planifiée, vous avez évalué de nombreux attributs. Lorsque vous planifiez les phases d'adoption, utilisez également une vue de haut niveau. Les attributs décrits ci-dessus (densité des données, portée des modifications, tolérance au risque et événements incontournables) sont un bon point de départ pour une analyse de haut niveau. Selon vos besoins d'affaires, vous pouvez identifier d'autres attributs qui sont plus importants pour le regroupement des applications par phases et la validation de votre plan.

Dans votre plan, montrez comment chaque phase s'aligne sur vos objectifs d'entreprise (par exemple créer des systèmes plus résilients, favoriser le développement ou faire face à des événements incontournables). Lorsque vous ne pouvez pas réaliser une phase d'adoption dans l'ordre préconisé par votre organisation, expliquez pourquoi la priorité a été donnée à une phase par rapport à une autre.

Pour valider votre stratégie, comparez le graphique de préparation pour le nuage, la matrice des fonctions stratégiques, la vue d'attributs globale et d'autres perspectives architecturales en fonction des attributs que vous avez collectés.

La gestion de la portée est essentielle pour avancer. Effectuez des itérations sur des petits groupes d'applications, voire des sous-ensembles d'applications. S'il y a lieu, répartissez les flux parallèles entre les différents secteurs d'activité. Si votre organisation peut accepter l'ambiguïté, ne vous engagez pas sur tous les détails des phases futures, mais identifiez les principaux points qui devront être arbitrés et présentez-les en tant que risques inconnus, ou essayez de déterminer quand vous serez en mesure de prendre une décision. Par exemple, votre organisation choisira-t-elle une stratégie multinuage ou pouvez-vous accepter un modèle hybride limité en raison des exigences en matière de résidence de données ou de l'environnement sur place?

Plus important encore, faites accepter le principe de base selon lequel la planification de l'adoption de l'environnement en nuage ne se fait pas en un jour. Il s'agit d'une activité qui nécessite de nombreuses itérations à mesure que vous acquérez des connaissances. Changer les plans des phases futures ne doit pas être considéré comme une réaction face à un problème, mais comme un service pour soutenir les objectifs de l'entreprise dans le contexte d'un écosystème de technologies et d'architectures en nuage en constante évolution.