Inventaire de l'architecture et des charges globales en cours

Nous vous recommandons de créer une matrice d'attributs, en procédant de manière "naturelle". Commencez petit, puis procédez par itération. Si possible, limitez dans un premier temps la portée des applications prises en compte.

Voici le processus global à suivre :

1. Créez une matrice d'applications. Pour ce faire, appuyez-vous sur les attributs de base de ces applications. Si ces dernières font partie de la même suite architecturale, vous pouvez les évaluer en tant que groupe. Identifiez ensuite une liste limitée de valeurs pour chaque attribut.

2. Effectuez une nouvelle itération de la matrice d'applications, d'attributs et de valeurs d'attribut.

   Ce faisant, 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 la façon dont vous les regroupez. Par exemple, vous pouvez définir initialement un attribut de latence comme ayant la valeur latence élevée, latence moyenne ou latence faible. Après une évaluation plus approfondie, vous décidez que vos exigences en matière de latence sont mieux définies par colocalisation que par tolérance à la distance.

   Votre matrice doit être suffisamment descriptive pour vraiment vous aider à prendre des décisions relatives à l'architecture et à la migration, mais suffisamment petite pour s'adapter à votre espace décisionnel cognitif. Si votre évaluation doit porter 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.

   En fin de compte, vous devrez évaluer toutes les charges globales que vous prévoyez de migrer. Toutefois, pour les premières itérations, vous devez donner la priorité à l'évaluation d'un sous-ensemble de charges globales. Idéalement, les objectifs de l'entreprise identifient des applications spécifiques ou des objectifs ciblés qui peuvent vous aider à déterminer les applications à prioriser.

4. Examinez l'ensemble des applications.

   Réévaluez les attributs existants dans le contexte de l'ensemble des applications que vous prévoyez de migrer. Si vous identifiez des informations importantes qui nécessitent d'être prises en compte, ajoutez-les à la matrice. Par exemple, vous pouvez découvrir une dépendance de données liée à des détails de latence ou d'intégration qui ne faisait pas partie de la portée initialement définie. Autre exemple : vous pouvez identifier une technologie héritée clé dont la planification de la mise hors service ou de la migration nécessite un effort particulier, et donc une évaluation plus approfondie.

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

Selon les objectifs de votre 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 au jargon utilisé au sein de votre organisation. La plupart des contraintes et objectifs d'entreprise existants sont reflétés dans ces attributs.

Evaluez la fonction stratégique :

• Par exemple, appliquez une version du modèle coeur/contexte de Geoffrey Moore à votre portefeuille informatique. Désignez les fonctionnalités stratégiques et non stratégiques. Indiquez également si elles font une différence ou sont purement opérationnelles.

  • Si les objectifs de l'entreprise mettent l'accent sur l'innovation, votre architecture initiale doit se concentrer sur les applications faisant une différence, mais pas encore stratégiques.

  • S'ils mettent l'accent sur l'efficacité opérationnelle, votre architecture doit se concentrer sur les applications opérationnelles stratégiques.

Comprenez les implications du plan d'informations pour les applications tierces :

• Comprenez-vous le plan d'informations du fournisseur pour chaque technologie tierce de votre pile actuelle, y compris les fonctions de réseau, le calcul et le stockage ?

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

• Une application tierce peut-elle continuer avec une mise à niveau ?

• Sans vous plonger dans les futures architectures, Oracle Cloud Infrastructure propose-t-il une version cloud ? Le fournisseur tiers propose-t-il une version cloud sur Oracle Cloud Marketplace ?

Identifiez toute fonctionnalité unique en lien avec la technologie, le déploiement et les opérations intervenant dans des domaines non fonctionnels clés :

• Sécurité. Par exemple, existe-t-il des fonctionnalités de masquage des données intégrées ?

• Conformité. Par exemple, existe-t-il une prise en charge intégrée des exigences PCI (Payment Card Industry) ?

• Résilience. Par exemple :

  • Le niveau d'application peut-il être inclus dans un cluster ?

  • La redondance du stockage est-elle automatique ?

  • Utilisez-vous la migration en direct pour assurer la continuité des activités ?

• Gouvernance et opérations. Par exemple, existe-t-il une intégration directe à des outils externes de cycle de vie de développement logiciel (SDLC) ou à des points d'ancrage de surveillance ?

• Efficacité. Par exemple :

  • Des plates-formes de virtualisation telles que VMware figurent-elles dans votre pile ?

  • Possédez-vous d'autres fonctionnalités de calcul, de stockage ou de partage de base de données ? Si des serveurs de base de données partagés exécutent plusieurs applications, vous auriez par exemple la valeur d'attribut Déploiement de base de données partagée.

• Automatisation. Par exemple :

  • A quel point votre modèle de création/de déploiement/d'exploitation est-il automatisé ?

  • Quels outils sont utilisés ?

Identifiez les domaines fonctionnels partagés, les données partagées et d'autres composants communs, et comprenez comment vos applications prennent en charge l'intégration :

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

• 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 "remplissage de boîtes" ?

  • Comment vos composants de fonctions de réseau sont-ils partagés ? Par exemple, si les segments réseau interviennent dans la continuité des activités inter-sites, les détails des fonctions de réseau peuvent être un attribut pertinent.

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

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

  • Intégration synchrone et intégration asynchrone.

  • Volume élevé et volume faible.

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

Evaluez d'autres caractéristiques non fonctionnelles de l'architecture ou de la conception. Tenez compte des domaines dans lesquels les choix de déploiement et d'architecture fournissent des composants plutôt que des fonctionnalités techniques ou de plate-forme.

• Volume des modifications de données et accès simultané. Par exemple :

  • Connaître la quantité nette de nouvelles données et celle des données existantes mises à jour peut être pertinent si un système effectue principalement une opération ou l'autre. Par exemple, un lac de données peut présenter un volume élevé de nouvelles données ajoutées, alors qu'un cache d'emplacements GPS actuels peut présenter un volume élevé de données mises à jour.

  • Accès simultanés aux applications et nombre de clients.

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

• Redimensionnement. Par exemple :

  • Votre architecture actuelle augmente-t-elle et diminue-t-elle en fonction d'un cycle de demande récurrent ou de pics inattendus ?

  • Quel est le mécanisme de redimensionnement ?

• Sensibilité des données ou problèmes particuliers de conformité. Par exemple :

  • Les charges globales 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 des données telles que celles du règlement général sur la protection des données (RGPD) ?

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

  • Certaines charges globales basculent-elles vers un autre emplacement en cas d'incidents spécifiques, tandis que d'autres passent simplement à l'état Arrêté ? Certains niveaux d'application ou de base de données utilisent des clusters de basculement. Certaines applications qui ne disposent pas du basculement automatique peuvent bénéficier d'une automatisation de l'intégralité de la reconstruction. Pour d'autres applications, le processus de récupération peut être entièrement manuel.

  • Identifiez un nombre limité de modèles correspondant aux modes d'échec spécifiques de vos applications.

• Coûts d'exploitation. Les niveaux de coût peuvent être approximatifs plutôt que correspondre à des chiffres exacts. Exemples de points à prendre en compte :

  • Des appliances uniques sont-elles requises ?

  • Quel est le coût de la main-d'oeuvre ? La main-d'oeuvre fait souvent l'objet d'une allocation. Il peut donc être difficile de déterminer des nombres exacts. Toutefois, effectuez des estimations dans une matrice agrégée ou récapitulative.

  • Votre pile de technologies inclut-elle des licences ou un support technique tiers Premium ? Si tel est le cas, ces licences ou ce support technique tiers sont-ils portables ?

  • Existe-t-il des gains d'efficacité partagés importants à souligner ? Par exemple, citons la technologie de virtualisation telle que VMware ou les applications basées sur des conteneurs qui partagent des serveurs.

Vous pouvez identifier des attributs supplémentaires à prendre en compte. Nous vous recommandons de contrôler la portée de votre analyse pour éviter d'être dépassé.

Au fur et à mesure des itérations, ajustez la matrice d'applications, d'attributs et de valeurs d'attribut en cours en fonction de la manière dont vous percevez le paysage technologique existant, des objectifs de l'entreprise et des plans d'adoption du cloud, ainsi que de la mise en correspondance de l'architecture actuelle avec l'architecture planifiée.

Définissez les attributs de votre architecture cloud et de vos charges globales planifiées.