Équilibrer les priorités concurrentes

Le succès de toute transformation numérique est déterminé par les capacités commerciales et technologiques des parties prenantes à équilibrer les priorités concurrentes.

Comme d’autres transformations numériques, l’adoption du cloud expose à des priorités concurrentes tout au long du cycle de vie de l’adoption. Et comme avec d’autres formes de transformation, la capacité à équilibrer ces priorités a un effet significatif sur l’obtention d’une valeur métier. L’équilibre de ces priorités concurrentes nécessite des conversations ouvertes et quelquefois difficiles entre les parties prenantes, et parfois avec des contributeurs individuels.

Cet article décrit certaines des priorités concurrentes communément abordées pendant l’implémentation de chaque méthodologie. Il peut vous aider à vous préparer à ces discussions lorsque vous développez votre stratégie d’adoption du cloud.

Les sections suivantes s’alignent sur le flux du diagramme du cycle de vie d’adoption du cloud précédent. Toutefois, il est important de reconnaître que l’adoption du cloud est un processus itératif, et non séquentiel, et que ces priorités concurrentes peuvent réapparaître à différents moments de votre parcours d’adoption du cloud.

Thème général de l’approche du Cloud Adoption Framework

Les solutions monolithiques et la planification avancée reposent sur une série d’hypothèses qui peuvent se révéler inexactes au fil du temps. L’adoption du cloud est souvent une nouvelle expérience pour une entreprise et ses équipes techniques. Comme dans la plupart des nouvelles expériences, il est probable que les hypothèses initiales se révèlent incorrectes.

L’adoption de principes agiles éprouvés faisant suite à des décisions techniques différées est l’approche à privilégier pour la plupart des instructions de ce framework. Cette approche suit un modèle cohérent : établir un état final général, passer rapidement à l’implémentation initiale, tester et valider les hypothèses et enfin refactoriser rapidement pour remédier aux hypothèses erronées. Cet état d’esprit axé sur le développement maximise l’apprentissage et minimise les risques pour la valeur métier. Il requiert cependant une certaine tolérance de l’ambiguïté.

L’ambiguïté peut parfois être plus effrayante, ou plus dangereuse, que de fausses hypothèses. Bien que cette infrastructure privilégie l’apprentissage et le traitement des ambiguïtés au cours de l’implémentation, de nombreuses situations nécessitent que l’équipe donne la priorité aux approches basées sur des analyses ou des hypothèses. Les sections suivantes fournissent au moins un « exemple développé d’étendue » qui montre quand une deuxième version plus approfondie peut être utile.

Équilibre pendant la phase de stratégie

L’objectif principal d’une méthodologie de la stratégie est de développer un alignement des parties prenantes. Après l’avoir définie, la position stratégique alignée entraîne un comportement dans chacune des méthodologies afin de garantir l’alignement des décisions techniques avec les résultats métier souhaités. Le fait d’encourager un alignement des parties prenantes crée un ensemble commun de priorités concurrentes : la profondeur de la justification face au délai d’impact sur l’activité.

Priorités concurrentes :

• Profondeur de la justification : Avant d’être capables de prendre une direction stratégique, les parties prenantes veulent souvent une analyse financière approfondie et une justification métier complète. Malheureusement, ce niveau d’analyse peut prendre beaucoup de temps avant de permettre la collecte et l’analyse des données.

• Délai d’impact sur l’activité : Inversement, les parties prenantes sont souvent tenues responsables de la livraison de résultats métier dans les délais fixés. Une analyse et une évaluation longues dans le temps peuvent compromettre ces résultats avant même le début du travail technique.

Étendue minimale : Pour parvenir à un bon équilibre, les parties prenantes doivent entamer des discussions au tout début du processus. La méthodologie de stratégie suggère de limiter l’étendue de l’alignement durant ces premiers efforts. Dans l’approche suggérée, les parties prenantes tentent de s’aligner autour d’un ensemble de motivations de base, de résultats mesurables et d’une justification métier générale. Les parties prenantes doivent ensuite rapidement s’engager sur plusieurs projets initiaux ou pilotes pour générer les opportunités d’apprentissage requises.

Exemple développé d’étendue : Si l’analyse métier initiale indique un risque élevé d’influence négative sur l’entreprise, les parties prenantes peuvent être contraintes de temporiser et de mener avec plus de prudence une analyse plus approfondie pendant la justification métier.

Équilibrage durant la phase de planification

Comme pendant la phase de stratégie, la phase de planification nécessite de trouver un équilibre entre la profondeur de la planification initiale et les décisions techniques retardées.

Priorités concurrentes :

• La profondeur de la planification initiale de l’implémentation technique dans le cloud est souvent basée sur de nombreuses hypothèses. Notamment si l’équipe a des lacunes en matière de compétences, si l’environnement subit d’un manque en matière de découverte ou si les charges de travail ne bénéficient pas d’états finaux clairement définis sur le plan architectural. Toutes ces hypothèses sont courantes dans les plans détaillés d’adoption du cloud. Une expérimentation, des pilotes et une analyse qualitative sont nécessaires pour vérifier ou améliorer ces hypothèses.

• Les décisions techniques différées reposent sur l’hypothèse que plus une décision technique est prise tard, plus elle est précise. Le respect des principes de planification de produit agile aide à retarder les décisions techniques, qui sont donc prises au bon moment, avec suffisamment d’informations. Toutefois, cette approche entraîne une plus grande ambiguïté du plan initial.

Étendue minimale : Nous suggérons des approches de développement de produit agile pour générer des actions rapides au sein de plans gérables. La méthodologie de la planification recommande les étapes suivantes pour atteindre cet équilibre :

1. Inventoriez l’ensemble de l’espace numérique à l’aide d’outils de découverte automatisés, mais utilisez une rationalisation incrémentielle pour planifier les 1 à 3 prochains mois de travail.
2. Veillez au bon alignement de l’organisation pour pouvoir agir rapidement.
3. Créez un plan de préparation des compétences pour l’équipe affectée. Utilisez le modèle de stratégie et plan pour déployer rapidement un backlog initial.

Exemple d’étendue développée : La mise en place d’un plan d’adoption du cloud peut parfois être la réponse à un événement commercial urgent ou à fort impact. Quand la réussite passe par le déplacement d’un grand nombre de ressources dans une période fixe, les étapes précédentes sont souvent suivies d’un effort de planification plus soutenu. La clé du succès dans ces scénarios est de planifier suffisamment pour lancer la procédure, puis de planifier ultérieurement l’engagement complet. Cette approche réduit la probabilité qu’une planification bloque les résultats métier.

Équilibrage durant la phase de préparation

Quand les équipes se préparent à faire leurs premiers pas dans l’adoption du cloud, elles sont souvent confrontées à des priorités concurrentes entre le délai d’adoption et les opérations à long terme. L’équipe peut avoir du mal à trouver un équilibre entre le fait d’honorer ses impératifs et le fait d’assurer une bonne gestion de ses activités. Ce conflit est nécessaire dans les environnements informatiques traditionnels, où l’acte de développement d’une plateforme passe par des ressources physiques et des cycles d’acquisition. Toutefois, quand la plateforme informatique est entièrement définie dans le code, les tactiques de développement traditionnelles, comme la refactorisation, réduisent la nécessité d’une bonne gestion initiale.

Priorités concurrentes :

• Opérations à long terme : Les organisations sont souvent bloquées par le souhait de disposer d’un environnement cloud qui répond à la parité des fonctionnalités avec les systèmes actuels de gestion des opérations, de gouvernance et de sécurité. Dans une étude, plus de 90 % des organisations avaient besoin d’aide pour dépasser cette mentalité. Cet inhibiteur peut provoquer des mois de retard, ralentissant voire éliminant l’impact métier.

• Temps d’adoption : les outils cloud tels qu’Azure Policy, l’intégration continue et livraison continue (CI/CD), tels que l’infrastructure en tant que code (IaC), et les groupes d'administration peuvent simplifier le processus de refactorisation sur la plateforme informatique. Des zones d’atterrissage prédéfinies fournissent également des recommandations pour accélérer le déploiement sur un environnement qui répond déjà à de nombreuses exigences en matière de parité des fonctionnalités. Ces outils offrent des opportunités d’accélérer le délai de commercialisation tout en ayant un effet minimal sur les opérations à long terme.

Étendue minimale : La méthodologie de préparation établit une voie directe entre adoption rapide et opérations à long terme. Cette approche commence par une présentation de base des outils que vous pouvez utiliser pour refactoriser votre environnement. Les outils prennent en compte vos besoins et vous guident vers une sélection de zones d’atterrissage prédéfinies, chacune fournie avec des modèles IaC. Vous pouvez ensuite refactorisé le code au cours de l’adoption du cloud pour améliorer les opérations, la sécurité et la gestion.

Exemple d’étendue développée : Pour les équipes dont le plan d’adoption prévoit à moyen terme (dans les 24 mois) d’héberger plus de 1 000 ressources (applications, infrastructures ou ressources de données) dans le cloud, nous recommandons une vue plus fiable des zones d’atterrissage. Dans ces situations, vous devez prendre en compte les méthodologies de gouvernance et de gestion au cours de vos conversations initiales sur les zones d’atterrissage. Cependant, cette considération plus approfondie ajoute souvent des semaines ou des mois à un plan d’adoption du cloud. Pour minimiser l’effet sur les résultats métier, l’équipe d’adoption doit piloter les charges de travail réelles dans le cloud en créant, en même temps, une zone d’atterrissage plus avancée et une solution d’architecture centrale.

Équilibrage durant la phase de migration

Pendant la migration, les équipes d’adoption partent couramment du principe que les charges de travail seront réhébergées dans le cloud dans leur configuration actuelle. Cette hypothèse entre directement en concurrence avec le plan prospectif selon lequel il est nécessaire de réarchitecturer chaque charge de travail pour mieux tirer parti des capacités du cloud. Les deux vues ne s’excluent pas mutuellement et peuvent être complémentaires lorsque vous les gérez à l’aide d’un processus commun.

Priorités concurrentes :

• Réhéberger : Les organisations associent souvent la migration à une approche lift-and-shift qui réplique toutes les ressources dans le cloud dans leur configuration actuelle. Cette approche génère une dérive minime au sein du portefeuille informatique. C’est également le moyen le plus rapide de mettre hors service des ressources dans un centre de données existant.

• Réarchitecture : La modernisation de l’architecture de chaque charge de travail maximise la valeur de l’adoption du cloud en termes de coûts, de performances et d’opérations. Cependant, cette approche est plus lente et nécessite souvent un accès au code source de chaque application.

Étendue minimale : Lors des étapes préliminaires de planification, utilisez l’option de réhébergement pour la planification. Sachez toutefois que ce choix est basé sur une hypothèse métier initiale et n’est pas une décision technique. Dans la méthodologie de migration, l’équipe d’adoption du cloud remet en cause ensuite cette hypothèse pour chaque charge de travail migrée. Cette méthodologie suit l’approche d’évaluation, de migration et de promotion de chaque charge de travail ou groupe de charge de travail pour créer une fabrique de migration. Au cours de la phase d’évaluation, l’équipe d’adoption évalue l’adéquation technique et l’architecture de chaque charge de travail. Ce travail d’évaluation débouche rarement sur une approche « lift-and-shift » pure, car la plupart des composants de l’architecture ont tendance à être sélectionnés pour être refactorisés et modernisés.

Exemple d’étendue développée : Pour les charges de travail stratégiques ou très sensibles, telles qu’un ordinateur mainframe ou des applications de microservices multiniveaux, une évaluation plus approfondie de la charge de travail peut être nécessaire durant la phase d’évaluation. Dans ces situations de réarchitecture, vous devez utiliser la revue d’Azure Well-Architected et Azure Well-Architected Framework pour affiner les exigences de la charge de travail pendant l'évaluation.

Équilibrage durant la phase d’innovation

Une véritable innovation orientée client crée fréquemment des priorités concurrentes entre la nécessité de fournir un ensemble de fonctionnalités planifiées et l’implémentation d’un processus de développement reposant sur l’empathie envers les clients.

Priorités concurrentes :

• Focus sur les fonctionnalités : Les plans initiaux en matière d’innovation s’appuient sur les fonctionnalités existantes de l’espace numérique et du cloud pour établir un ensemble de fonctionnalités répondant aux besoins des clients. Il est facile de paramétrer le plan de manière à privilégier l’implémentation technique, d’où des efforts de développement axés sur les fonctionnalités. Cette approche aboutit souvent à la satisfaction temporaire des parties prenantes, mais réduit la probabilité de stimuler des innovations qui influencent les comportements des clients.

• Empathie envers les clients : Les plans initiaux constituent une partie importante de l’aspect métier du développement et doivent être inclus dans les comptes rendus réguliers. Toutefois, l’empathie manifestée envers les clients lors des phases d’apprentissage, de mesure et de création en tant qu’objectif est une mesure plus précise de la réussite d’un effort d’innovation. Le fait de se concentrer sur les clients plutôt que sur les fonctionnalités est plus susceptible d’entraîner la satisfaction du client à court terme et à long terme, et d’avoir un impact sur l’activité.

Étendue minimale : La méthodologie d’innovation montre comment intégrer une stratégie et des plans grâce à un consensus sur la valeur métier. Le guide présente des outils cloud natifs qui peuvent accélérer chaque discipline d’innovation et les meilleures pratiques d’implémentation. Enfin, la section sur les améliorations de processus montre les approches à suivre pour développer l’empathie envers les clients tout en respectant les plans et les stratégies tout au long du parcours d’adoption du cloud. Cette approche se concentre sur la mise en œuvre de solutions d’innovation en réduisant autant que possible la part de la technologie.

Exemple d’étendue développée : Une innovation peut parfois dépendre de charges de travail stratégiques ou hautement sensibles. Lorsque le client est un utilisateur interne, l’effort de développement peut être à la fois stratégique et hautement sensible au cours des premières itérations. Dans ces scénarios, les équipes d’adoption doivent utiliser la revue Azure Well-Architected et Azure Well-Architected Framework pour évaluer la conception architecturale avancée dès le début du processus.

Équilibrage durant la phase de gouvernance

La pratique de la gouvernance du cloud est un équilibre entre deux priorités concurrentes : vitesse et agilité contre environnement bien gouverné. L’équipe de gouvernance du cloud se concentre sur l’évaluation et la minimisation des risques pour l’entreprise grâce à la mise en place de contrôles uniformes et à la minimisation des changements. L’équipe d’adoption se concentre sur l’optimisation des résultats métier, ce qui entraîne de nouveaux risques et crée naturellement des changements.

Priorités concurrentes :

• Bien gouverné : Chaque contrôle conçu pour minimiser les risques bloque certains aspects du changement ou limite les options de conception. Le contrôle est essentiel à un environnement bien gouverné. Cependant, quand les contrôles sont conçus et déployés de manière isolée, ils peuvent être aussi dangereux que les risques qu’ils sont censés prévenir.
• Vitesse et agilité : La vitesse et l’agilité sont des exigences métier fondamentales dans l’économie numérique. Elles nécessitent toutes les deux la capacité de stimuler le changement avec un minimum d’inhibiteurs d’innovation ou d’adoption. Mais quand le changement est conduit sans gouvernance, il génère de nouveaux risques qui peuvent nuire à l’entreprise de manière inattendue.

Étendue minimale : La méthodologie de gouvernance suggère que ni la gouvernance ni l’adoption ne doivent se produire de manière isolée. Cette méthodologie commence par une compréhension des disciplines de gouvernance et par une conversation sur les risques, les politiques et les processus métier. En tant que participant actif tout au long de l’adoption du cloud, l’équipe de gouvernance peut implémenter un ensemble minimal de garde-fous pour faire face aux risques tangibles du plan d’adoption du cloud. Au fil du temps, l’équipe de gouvernance peut refactoriser et développer ces garde-fous pour répondre à de nouveaux risques. Cette approche optimise l’apprentissage et l’innovation tout en minimisant les risques.

Exemple d’étendue développée : Quand un risque métier est élevé, en particulier au début de la phase d’adoption, l’équipe de gouvernance du cloud peut avoir besoin d’accélérer l’expansion des implémentations de gouvernance. Vous pouvez utiliser les mêmes conseils et exercices pour ajouter ce niveau de gouvernance plus élevé, mais vous devrez peut-être aller plus vite. Dans certains scénarios, un état avancé de gouvernance peut même être requis pendant que vous déployez les premières zones d’atterrissage.

Équilibrage durant la phase de gestion

Le modèle économique de gestion des opérations du service informatique n’a cessé d’évoluer au cours de la dernière décennie. À mesure que la maintenance du matériel s’éloigne des tâches de base du service informatique, la vision de la gestion des opérations change. Alors que le service informatique se concentre davantage sur la création d’une valeur métier, les équipes de gestion des opérations doivent trouver un équilibre entre l’approche « no ops/low ops » et la mise en œuvre de vastes investissements.

Priorités concurrentes :

• Investissements étendus : La vision traditionnelle de la gestion des opérations consiste à investir de manière égale dans la prévention des pannes, la récupération rapide et la supervision de l’environnement. Cette approche peut être coûteuse et parfois faire double emploi avec les produits de prise en charge fourni par le fournisseur de cloud.

• Approche No-ops/low-ops : Utilisez des outils d’exploitation natifs du cloud pour minimiser les tâches répétitives et récurrentes qui ont été précédemment réalisées par vos employés. La réduction de ces dépendances opérationnelles permet aux employés de générer autrement de la valeur. Isolée, cette approche peut cependant conduire à une prise en charge inadéquate des opérations.

Étendue minimale : La méthodologie de gestion suggère d’établir une ligne de base de gestion « no-ops » (pas d’opérations) native Cloud. Étant donné que la ligne de base no-ops ne permet pas de répondre à tous les besoins métier, collaborez avec l’entreprise pour définir des engagements et mieux aligner les investissements. Développez la base de référence pour répondre aux besoins communs de toutes les charges de travail. Instruisez ensuite aux équipes responsables des plateformes ou de charges de travail spécifiques de mettre en œuvre des solutions bien gérées dans un environnement bien géré.

Exemple d’étendue développée : Dans la plupart des environnements, la valeur métier d’un faible pourcentage de charges de travail justifie des investissements importants de la part du service informatique dans les opérations. Pour ces charges de travail, l’équipe informatique peut souhaiter utiliser la revue Azure Well-Architected et Azure Well-Architected Framework afin de mener des opérations plus approfondies.

Équilibrage durant la phase d’organisation

Les priorités concurrentes décrites dans cet article reflètent la volonté des services informatiques de répondre aux demandes de rapidité et d’agilité de l’entreprise. Le même décalage apparaît dans les modifications apportées aux organigrammes ou aux structures d’équipes virtuelles pour offrir une meilleure prise en charge des résultats métier. À mesure que les responsables informatiques réfléchissent à la structure des équipes, deux priorités concurrentes sont généralement abordées : contrôle centralisé contre contrôle délégué.

Priorités concurrentes :

• Contrôle centralisé : Ce modèle d’exploitation est axé sur la centralisation de tous les contrôles nécessaires à l’application de politiques rigides. Dans ce modèle, le service informatique est un frein à l’innovation, à la vitesse et à l’agilité. Cependant, il peut assurer un degré plus élevé de stabilité, de conformité et de sécurité.

• Contrôle délégué : Ce modèle d’exploitation distribué part du principe que chaque équipe DevOps ou équipe d’application métier fournit son propre ensemble de contrôles, basé sur les solutions nécessaires pour répondre aux objectifs métier. Dans ce modèle, l’équipe informatique fournit des recommandations pour aider les équipes à éviter les risques, mais minimise autant que possible les contraintes techniques forcées.

Étendue minimale : La plupart des organisations sont confrontées à un ensemble naturel d’évolutions au fil du temps. La méthodologie d’organisation décrit la série d’évolutions la plus courante. Nous recommandons aux équipes d’essayer de passer à une structure de centre d’excellence du cloud (CCoE) pour fournir des approches de contrôle délégué.

Exemple d’étendue développée : De nombreuses situations déclenchent la nécessité d’un contrôle centralisé. Les exigences de conformité tierces et l’exposition temporaire à la sécurité sont deux exemples déclenchant un contrôle centralisé. Dans ces situations, il est généralement nécessaire d’établir des stratégies de limite et des contrôles rigides et fixes. Cependant, pour assurer la continuité de l’innovation et de l’adoption, nous encourageons les équipes informatiques centralisée à mettre en œuvre ces contrôles en fonction du caractère critique et de la sensibilité de chaque charge de travail. Le fait de créer des environnements avec moins de contrôles, mais avec une étendue ou un profil de risque réduit, offre une flexibilité même lorsque des contrôles sont nécessaires.

Étapes suivantes

Découvrez comment équilibrer la migration, l’innovation et l’expérimentation pour optimiser la valeur de vos efforts de migration vers le cloud.

Équilibrage du portefeuille