Notes
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
La compréhension de la culture et de la gestion des centres de données d’une organisation est essentielle pour la réussite de la migration Azure. Les équipes informatiques centralisées avec des rôles clairs facilitent le processus, mais les entreprises plus grandes ou liées à la conformité sont confrontées à des défis nuancés qui peuvent entraver les progrès.
Le Cloud Adoption Framework Azure souligne le rôle de l’alignement organisationnel dans la migration, qui préconise la collaboration entre services pour remplir les fonctions clés.
Dans cet article, vous découvrirez :
- Rôles spécifiques à la migration qui s'alignent sur la stratégie cloud et les fonctions d'adoption du cloud .
- Les rôles de soutien dont vous pourriez avoir besoin pour d'autres fonctions pendant le processus de migration, par exemple les architectes de zones d'accueil et les architectes de charges de travail.
- Comment identifier des experts ou des propriétaires pertinents pour les rôles dans vos projets de migration.
- Matrice de responsabilité permettant de comprendre quel rôle est responsable de la partie d’un projet de migration.
Conseil
Les rôles mentionnés peuvent ne pas correspondre à des titres de travail spécifiques ou exiger des membres d’équipe dédiés. Souvent, une personne peut couvrir plusieurs rôles, ou plusieurs membres de l’équipe peuvent partager des responsabilités. Cette liste décrit les responsabilités courantes, mais n’est pas un guide de dotation en personnel. La clé est de s’assurer que ces responsabilités sont respectées au sein de votre organisation.
Rôles de la fonction de stratégie cloud
Pour vous assurer que vous disposez de l’engagement et de l’organisation nécessaires pour votre projet de migration, vous avez besoin des rôles suivants pour la fonction de stratégie cloud . Le tableau suivant décrit les rôles de fonction de stratégie cloud et leurs responsabilités :
Rôle | Responsabilités |
---|---|
Sponsor du projet | Définit l’étendue de la migration pour déterminer quelles ressources sont déplacées et l’avantage de déplacer chaque ressource. Fournit la propriété de la prise de décision pour les achats d’outils de migration, pour l’architecture globale de la charge de travail et pour les activités de mise en production. |
Gestionnaire de projets | Pilote un plan de projet pour l’étendue de migration. Dirige les processus de test. Organise les mises à jour de statut des intervenants. |
Gestionnaire des changements organisationnels | Aide l’équipe de projet à communiquer les modifications à l’organisation. Fonctionne avec différentes fonctions pour vous assurer que les bons membres de l’équipe sont impliqués et que les modifications organisationnelles appropriées se produisent pour prendre en charge la migration. |
Spécialiste des licences | Fournit des informations sur les licences et la gestion finOps pour s’assurer que le projet est correctement concédé sous licence et utilise des ressources sous licence existantes. |
Responsable de la charge de travail | Fournit la responsabilité décisionnelle pour les processus d’évaluation, d’architecture et de migration de la charge de travail. Agit en tant que propriétaire pour la valeur métier de la charge de travail dans Azure. |
Rôles de fonction d’adoption du cloud
Pendant votre migration vers Azure, la fonction d’adoption du cloud effectue la plupart de l’exécution technique. Pour cette fonction, envisagez d’avoir les rôles décrits dans le tableau suivant :
Rôle | Responsabilités |
---|---|
Architecte de migration | Supervise la prise de décision technique pour les charges de travail, telles que la planification des vagues de migration et tous les processus de migration. |
Ingénieur migration | Exécute des tâches identifiées dans le cadre du projet. |
Rôles de soutien pour d’autres fonctions
Le tableau suivant décrit les rôles de prise en charge dont vous pourriez avoir besoin pour d’autres fonctions :
Rôle | Responsabilités |
---|---|
Architecte de zone d’atterrissage | Fournit la prise en charge de la migration de charges de travail vers une zone d’atterrissage. Aide à résoudre les problèmes liés aux services de plateforme dans la zone d’atterrissage. Pour plus d’informations, consultez Fonctions de plateforme cloud. |
Responsable des Opérations Cloud | Prend en charge l'intégration des charges de travail migratoires vers la plateforme de gestion afin d'assurer que la gestion appropriée est mise en place pour les charges de travail lorsqu'elles migrent. Pour plus d’informations, consultez Fonctions des opérations cloud. |
Architecte des charges de travail | Fournit des conseils architecturaux et une prise de décision pour la conception de la charge de travail de migration. Pour chaque charge de travail, vous devrez peut-être un expert en matière spécifique pour remplir plusieurs instances de ce rôle. Pour plus d’informations, consultez fonctions informatiques centrales. |
Testeur d’acceptation utilisateur | Teste les charges de travail individuelles. Vous pouvez avoir plusieurs instances de ce rôle par charge de travail pour fournir des commentaires sur les tests d’acceptation des utilisateurs (UAT). Pour plus d’informations, consultez fonctions informatiques centrales. |
Identifier des experts ou des propriétaires pour les rôles
Il peut être difficile d'identifier les ressources appropriées pour certains de ces rôles, comme pour l'architecte de la charge de travail et le responsable opérationnel de la charge de travail. Si une charge de travail est en maintenance pendant une longue période et sans modifications fréquentes, vous pouvez constater des informations limitées sur la responsabilité et peu d'expertise technique pour soutenir une fonction. Par exemple, dans la planification du patrimoine numérique, il arrive parfois que les serveurs ne soient pas attribués à une charge de travail spécifique, ce qui peut rendre difficile de déterminer qui en a la propriété.
Voici quelques recommandations pour identifier les rôles :
- données historiques: utilisez votre base de données de gestion de la configuration ou votre système de tickets pour identifier les éléments historiques qui indiquent qui demande la maintenance ou qui communique sur le serveur ou la charge de travail.
- Journaux des connexions: Cherchez les utilisateurs qui se sont connectés le plus récemment sur les serveurs de la charge de travail. Bien que cette approche n’identifie pas un propriétaire, les utilisateurs récents peuvent vous donner un contexte pour le serveur.
- l’analyse des dépendances: utilisez les outils d’analyse des dépendances pour identifier qui se connecte le plus fréquemment aux fonctions hébergées sur les serveurs. Ces outils peuvent vous aider à identifier les services d’entreprise, qui à leur tour peuvent vous aider à identifier un propriétaire.
- propriétaires d’applications connexes: contactez les propriétaires d’applications qui servicent un service ou une fonction métier similaire. Demandez-lui de vous aider à identifier les rôles que vous devez remplir. Même si vous n’avez pas d’expert pour un rôle dans votre organisation, vous devez remplir le rôle pendant le processus de migration. Les équipes d’entreprise et les équipes informatiques doivent identifier au moins les membres intermédiaires, puis créer un plan de propriété pour la prise en charge à long terme de la charge de travail après sa migration.
Mettre à l’échelle des rôles pour les initiatives de migration à grande échelle
Selon la taille et le nombre de charges de travail que vous migrez, vous devrez peut-être affecter plusieurs membres d’équipe à chaque rôle. Une bonne approche consiste à utiliser la mise à l’échelle décrite par cet article pour jusqu’à cinq charges de travail de taille moyenne et de complexité par sprint de deux semaines.
Toutefois, le dimensionnement et la complexité de la charge de travail peuvent être difficiles à juger. Dans vos premières vagues de migration, commencez par une équipe principale, mais effectuez un scale-out si nécessaire.
Si vous constatez que vous devez effectuer un scale-out, vous devez également planifier les rôles décrits dans le tableau suivant :
Rôle | Responsabilités |
---|---|
Gestionnaire de programmes | Organise les activités de gestion de projet sur plusieurs étendues de projet. |
Responsable de l'architecture de migration | Favorise l'excellence technique dans divers domaines de l'architecture de migration. |
Exemple de matrice de responsabilité
Le tableau suivant utilise cette légende pour indiquer les catégories de responsabilité par rôle pour les étapes d’un projet de migration :
- D = Driver: un individu de l’organisation qui est le seul pilote de l’objectif.
- A = Approbateur : une ou plusieurs personnes de l’organisation qui prennent la plupart des décisions et sont responsables si l’objectif n’est pas atteint.
- C = Contributeur: personnes de l’organisation responsables de la réalisation de tâches qui prennent en charge l’objectif.
- I = Informés : les personnes de l’organisation concernées par le projet et qui sont régulièrement informées des décisions et de l’état du projet.
Vous pouvez utiliser la matrice de responsabilité suivante comme base pour votre projet de migration. Vous devrez peut-être identifier davantage de rôles ou modifier les responsabilités en fonction des besoins de votre organisation.
Rôle | Découverte de patrimoine numérique | Étendue de la migration | Plan de projet | Outils de migration | Découverte de la charge de travail | Évaluation de la charge de travail | Architecture de la charge de travail | Planification par vague | Migration des tests de charge de travail | UAT de migration de charge de travail | Migration de charge de travail | UAT de mise en production de charge de travail | Gestion des changements organisationnels | Transition vers les opérations | Gestion des licences de charge de travail |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Architecte de migration | D | D | A | D | A | A | D | A | A | A | A | A | I | D | I |
Ingénieur migration | C | I | C | C | D | D | C | D | D | C | D | C | I | C | C |
Gestionnaire de projets | I | I | D | I | I | I | I | I | I | D | I | D | I | C | I |
Sponsor du projet | A | A | A | A | I | I | A | I | I | I | A | I | A | A | A |
Testeur d’acceptation utilisateur | I | I | I | I | I | I | I | I | I | C | I | C | I | C | I |
Architecte du flux de travail | I | I | C | C | C | C | C | C | C | C | C | C | C | C | I |
Responsable de la charge de travail | I | I | C | I | A | A | A | A | A | A | A | A | C | C | A |
Gestionnaire des changements organisationnels | I | I | C | I | I | I | I | I | I | C | I | C | D | C | I |
Spécialiste des licences | I | I | C | C | I | C | C | C | I | I | I | I | I | C | D |
Responsable des opérations cloud | C | C | C | I | I | I | I | C | I | I | I | I | C | A | I |
Architecte de zone d’atterrissage | I | I | C | C | I | I | C | C | I | I | I | I | I | I | I |
Étape suivante
préparation des compétences pour la migration