The Doppler Quarterly (FRANÇAIS) Printemps 2018 - Page 21

Facteur n° 2 : évaluation et analyse objectives sur la base de règles Sitôt que l'on dispose de la visibilité nécessaire sur le paysage et les différents actifs, il devient possible déter- miner le sort d’une application par le biais d’une évalua- tion et d’une analyse. Comme décrit ci-dessus, un effort d’analyse peut être établi au niveau du patrimoine, au niveau spécifique de l’activité et des applications, ou bien à celui de l’infrastructure. Le résultat d’une analyse réalisée au niveau du patri- moine fournit généralement à l’organisation une visibil- ité et une orientation satisfaisantes, notamment en ce qui concerne les premières migrations. Cette analyse indique également là où l’organisation a besoin de con- centrer ses efforts à court, à moyen et à long terme pour répondre à ses objectifs stratégiques. Dans le contexte d’une analyse au niveau application, l'une des interrogations typiques consiste à se demander quelles sont les applications les mieux adaptées aux migrations, et quels sont les modèles de plateforme et d’architecture les plus propices. Les métadonnées appli- catives clés utilisées dans cette analyse entrent dans quatre catégories : commerciales, techniques, opéra- tionnelles, et de sécurité et gouvernance. À titre d’exem- ple, les catégories de métadonnées techniques com- prennent : l'architecture, l’environnement technologique, l'automatisation, les performances, l'évolutivité, les dépendances, la taille des données et la vitesse des données. Une analyse d’adéquation nécessite la définition de car- actéristiques adaptées au cloud, ainsi qu'un mécanisme de notation pouvant s’appliquer à toutes les applications, afin de déterminer si celles-ci doivent être transférées ou non dans le cloud. Une organisation peut par exemple fixer les caractéristiques suivantes pour juger qu'une application est inapte à être déplacée vers la plateforme de cloud : • L'application est volumineuse, repose sur une instance unique et/ou monolithique et ne peut pas être subdivisée en services • L'application comporte une dépendance externe inaccessible via la plateforme de cloud • L'application est incompatible avec la liste des bib- liothèques cloud compatibles approuvées • L'application implique des questions contractu- elles, légales ou de licence, en raison de son incor- poration à un module tiers ou de la technologie nécessaire à son exécution dans un environne- ment cloud Une fois que vous estimez qu'une application répond aux critères, vous pouvez choisir la plateforme de cloud et le modèle de migration appropriés. Nous vous recomman- dons d'adopter une démarche quantitative dans laquelle chaque caractéristique de l’application est notée par rapport à un point de terminaison, puis récapitulée de manière à déterminer la plateforme de cloud adéquate. Dans bien des cas, la décision concernant la plateforme de cloud cible repose sur des facteurs autres que les car- actéristiques techniques, telles que l'octroi de licence, la disponibilité contractuelle de services spécifiques ou l’affinité. Différents facteurs déterminent le modèle de migration, dont la fonction opérationnelle, les objectifs, le cycle d'activité, la criticité/priorité, l'architecture applicative et l'effort requis. Pour prendre un exemple, une applica- tion commerciale personnalisée peut dans certains cas mieux convenir à une relocalisation d'hôte qu'à un changement de plateforme ou une refactorisation. Vous pouvez appliquer un ensemble de règles aux caractéris- tiques d’une application afin de déterminer le modèle de migration. PRINTEMPS 2018 | THE DOPPLE R | 19