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