Inventaire des charges de travail et de l'architecture courantes

Nous vous recommandons de créer une matrice d'attributs et de la faire évoluer naturellement. Commencez petit, puis itérez. Si possible, au départ, limitez la portée des applications envisagées.

Voici le processus général à suivre :

1. Créez une matrice d'applications en fonction des attributs de base de ces applications. Si les applications font partie de la même suite architecturale, vous pouvez les évaluer en tant que groupe. Identifiez ensuite une liste de valeurs finie pour chaque attribut.

2. Itérez la matrice d'applications, d'attributs et de valeurs d'attribut.

   Au fil des itérations, vous pouvez identifier de nouveaux attributs, combiner des attributs ou modifier les valeurs d'un attribut. Vous pouvez également ajuster la liste des applications ou leur mode de regroupement. Par exemple, vous pouvez définir les valeurs initiales Haute, Moyenne ou Faible pour un attribut de latence. Après une évaluation supplémentaire, vous pouvez décider que les valeurs Avec colocalisation (contre Fonctionnement à distance toléré) sont plus adaptées à vos besoins.

   Votre matrice doit être suffisamment descriptive pour vous aider à prendre des décisions en matière d'architecture et de migration, mais suffisamment petite pour s'adapter à votre espace de décision cognitif. Si votre évaluation porte sur l'ensemble du portefeuille informatique de votre organisation, envisagez de créer une matrice consolidée de niveau supérieur.

3. Définissez la portée initiale des applications à évaluer.

   Au bout du compte, vous devrez évaluer toutes les charges de travail que vous prévoyez de migrer. Toutefois, pour les premières itérations, vous devez définir un sous-ensemble de charges de travail à évaluer en priorité. Idéalement, vos objectifs d'entreprise doivent identifier des applications spécifiques ou des objectifs ciblés qui peuvent vous aider à choisir ces applications.

4. Examinez l'ensemble des applications.

   Réévaluez les attributs existants dans le contexte du jeu complet d'applications que vous prévoyez de migrer. Si vous identifiez des informations importantes auxquelles accorder une attention particulière, ajoutez-les à la matrice. Il peut s'agir par exemple d'une dépendance de données due à la latence ou de détails d'intégration qui ne faisaient pas partie de la portée initiale. Vous pouvez également identifier une technologie existante clé qui nécessite un effort spécifique de planification en vue du retrait ou de la migration, et qui doit donc faire l'objet d'une évaluation plus approfondie.

Utilisez les attributs de cette section comme point de départ pour évaluer vos charges de travail et votre architecture de plate-forme existantes.

Selon vos objectifs d'entreprise et les applications que vous prévoyez de migrer, certains attributs peuvent être plus pertinents que d'autres. Nous vous recommandons d'adapter la terminologie aux termes privilégiés au sein de votre organisation. La plupart des contraintes et objectifs d'entreprise existants sont pris en compte dans ces attributs.

Évaluer la fonction stratégique :

• Par exemple, appliquez une version du modèle de base/contextuel de Geoffrey Moore à votre portefeuille informatique. Identifiez les fonctionnalités essentielles et non essentielles. Établissez également une distinction entre les fonctionnalités opérationnelles et différenciatrices.

  • Si vos objectifs d'entreprise mettent l'accent sur l'innovation, votre architecture initiale doit se concentrer sur les applications différenciatrices mais pas encore critiques.

  • Si vos objectifs d'entreprise mettent l'accent sur l'efficacité opérationnelle, votre architecture doit se concentrer sur les applications opérationnelles critiques.

Familiarisez-vous avec la feuille de route destinée aux applications de tierce partie :

• Comprenez-vous la feuille de route du fournisseur pour chaque technologie de tierce partie de votre pile actuelle, notamment en matière de réseau, de calcul et de stockage?

• Une application de tierce partie est-elle en fin de vie?

• Est-il possible de continuer à utiliser une application de tierce partie en la mettant à niveau?

• Sans entrer dans le détail des architectures futures, Oracle Cloud Infrastructure offre-t-il une version en nuage? Le fournisseur de tierce partie offre-t-il une version en nuage d'Oracle Cloud Marketplace?

Identifiez toutes les caractéristiques uniques liées à la technologie, au déploiement et aux opérations dans les dimensions non fonctionnelles clés :

• Sécurité. Par exemple, des fonctions de masquage de données sont-elles intégrées?

• Conformité. Par exemple, le soutien des exigences de l'industrie des cartes de paiement est-il intégré?

• Résilience. Par exemple :

  • Le niveau de l'application peut-il être mis en grappe?

  • Le stockage est-il automatiquement redondant?

  • Faites-vous confiance à la migration en direct pour permettre la continuité des activités?

• Gouvernance et opérations. Par exemple, existe-t-il une intégration directe avec des outils de développement de logiciels ou des crochets de surveillance externes?

• Efficience. Par exemple :

  • Votre pile contient-elle des plates-formes de virtualisation telles que VMware?

  • Disposez-vous d'un autre système de partage du calcul, du stockage ou des bases de données? Si des serveurs de base de données partagés exécutent plusieurs applications, vous pouvez utiliser la valeur d'attribut Déploiement de bases de données partagé.

• Automatisation. Par exemple :

  • Dans quelle mesure votre modèle de création, de déploiement et d'exploitation est-il automatisé?

  • Quels outils sont utilisés?

Identifiez les secteurs fonctionnels partagés, les données partagées et d'autres composants communs, et intéressez-vous à la façon dont vos applications prennent en charge l'intégration :

• Une application prend-elle en charge plusieurs secteurs d'activité, rôles d'utilisateur ou processus d'affaires?

• Quelles sources de données sont partagées? Une infrastructure est-elle partagée? Par exemple :

  • Vos applications s'exécutent-elles sur un hôte partagé pour des raisons autres que l'efficacité opérationnelle ou le stockage optimal?

  • Comment vos composants de réseau sont-ils partagés? Par exemple, si les segments de réseau prennent en compte la continuité des activités entre sites, les détails du réseau peuvent constituer un attribut pertinent.

  • Quel système utilisez-vous pour la gestion des identités? Si votre organisation utilise plusieurs systèmes ou sources de gestion des identités, le système d'identités peut être un attribut pertinent.

• Comment les fonctions, les données et les composants partagés sont-ils intégrés les uns avec les autres? Par exemple :

  • Intégration synchrone par rapport à une intégration asynchrone.

  • Volume élevé par rapport à un volume faible.

  • Quelle est la méthode d'intégration? Par exemple : liens entrants et liens sortants, composants intergiciels.

Évaluez d'autres caractéristiques de conception ou d'architecture non fonctionnelle. Examinez les domaines dans lesquels les choix en matière de déploiement et d'architecture portent sur les composants plutôt que sur la plate-forme ou les fonctions techniques.

• Volume de modification de données et concurrence. Par exemple :

  • La distinction entre nouvelles données nettes et mises à jour des données existantes peut être pertinente si un système effectue principalement une opération ou l'autre. Par exemple, un lac de données peut traiter un volume élevé de nouvelles données ajoutées, alors qu'un cache d'emplacements GPS courants peut comporter un volume élevé de données mises à jour.

  • Concurrence des applications et nombre de clients.

  • Selon vos applications, tenez compte des données transactionnelles, des données de référence et des données analytiques.

• Ajustement. Par exemple :

  • Votre architecture courante évolue-t-elle à la hausse ou à la baisse selon un cycle de demande récurrent ou en fonction des pics de demande inattendus?

  • Quel est le mécanisme d'ajustement?

• Sensibilité des données ou exigences de conformité spécifiques. Par exemple :

  • Les charges de travail incluent-elles des données soumises à la réglementation PCI ou HIPAA (Health Insurance Portability and Accountability Act)?

  • Les données stockées ou traitées sont-elles soumises à des exigences de résidence telles que le Règlement général sur la protection des données (RGPD)?

• Pratiques opérationnelles résilientes. Par exemple :

  • Certaines charges de travail basculent-elles vers un autre emplacement en réponse à des incidents spécifiques alors que d'autres s'arrêtent? Certains niveaux d'application ou de base de données utilisent des grappes de basculement. Certaines applications qui n'utilisent pas le basculement automatisé peuvent bénéficier de l'automatisation de reconstruction complète. Pour d'autres applications, le processus de récupération peut être entièrement manuel.

  • Identifiez un nombre limité de modèles concernant les modes de défaillance spécifiques de vos applications.

• Coûts opérationnels. Les niveaux de coûts peuvent être des approximations plutôt que des chiffres exacts. Exemples de domaines à prendre en compte :

  • Des boîtiers uniques sont-ils requis?

  • Quel est le coût de la main-d'œuvre? La main-d'oeuvre est souvent affectée, de sorte qu'il peut être difficile de saisir des chiffres exacts, mais vous pouvez tenir compte des estimations d'une matrice agrégée ou sommaire.

  • Votre pile de technologies comprend-elle des licences ou un soutien de technologies de tierce partie premium? Le cas échéant, ces licences ou ce soutien sont-ils portables?

  • Le partage peut-il vous permettre d'optimiser votre efficacité? Par exemple, vous pouvez envisager d'utiliser la technologie de virtualisation (VMware, par exemple) ou des applications basées sur des conteneurs qui partagent des serveurs.

Vous pouvez identifier d'autres attributs à prendre en compte. Nous vous recommandons de gérer la portée de votre analyse afin de ne pas vous laisser déborder.

À mesure que vous itérez, ajustez votre matrice d'applications, d'attributs et de valeurs d'attribut courants en fonction de votre compréhension de votre environnement technologique existant, de vos objectifs d'entreprise et de vos plans d'adoption de l'environnement en nuage, y compris le mappage de l'architecture courante à l'architecture planifiée.

Définissez les attributs de votre architecture en nuage et de vos charges de travail planifiées.