Décommissionnement SI Legacy : un enjeu stratégique pour affronter l’obsolescence du SI

De très nombreuses entreprises sont confrontées à des difficultés de gestion et d’évolution de leurs composants Legacy, c’est -à -dire à un ou plusieurs composant de leur Système d’Information historique. Certaines organisations tentent de migrer vers des solutions plus modernes, mais l’opération est loin d’être simple. L’interview d’Olivier, consultant et Manager de l’Offre Architecture du SI chez Projexion, vous éclairera sur ces composants Legacy, leurs caractéristiques et la démarche pour réussir à les décommissionner.

Peux-tu commencer par nous expliquer ce qu’est un SI legacy?

Le SI Legacy rassemble un ou plusieurs composants applicatifs et porte des fonctions centrales de l’entreprise (cœur de métier) sur un périmètre fonctionnel large et critique pour l’entreprise.

Ces composants ont été développés en spécifique et ont évolué au fil des besoins métier pendant plus de 10 ans, sans cadre d’architecture (fonctionnel et technique), sans documentation d’architecture à jour.

Ces composants “haute couture” répondent très bien aux besoins métier couverts en adressant toutes les spécificités métier de l’entreprise. Les demandes d’évolution récentes sont difficiles à honorer.

Pourquoi les DSI souhaitent-ils se séparer ou décommissionner une partie de leur « SI Legacy » ?

Deux facteurs de motivation conduisent une DSI à se débarrasser de leur SI Legacy :

• L’obsolescence technique :
  • De conception ancienne, ces composants  ont un code et une ossature complexe, couvrent un large périmètre fonctionnel, ce qui les rend difficile à maintenir. Le risque de régression est assez fort, les temps et coûts élevés pour faire des évolutions.
  • Les technologies utilisées pour les implémenter ne sont plus utilisées et il devient difficile de trouver des profils experts sur le marché.
  • Les coûts de maintenance des vieilles technologies sont élevés, voire prohibitifs. Parfois les constructeurs et éditeurs mettent fin à la période de support et de maintenance, laissant les clients sans recours possible.
  • L’exploitabilité est parfois limitante voire bloquante pour adapter l’architecture à des niveaux d’exigence exprimés par les utilisateurs (temps de réponse, volumétrie de données, disponibilité, …).
  • La capacité à adopter des technologies moderne est entravée (ex: cloud)

 

• L’obsolescence fonctionnelle:

L’obsolescence fonctionnelle existe dès lors que les services attendus par les utilisateurs dépassent les capacités apportées par le SI Legacy. Cet écart est alimenté progressivement par : 

• • La stratégie de l’entreprise 
  • L’évolution de l’organisation de l’entreprise, de ses processus et des besoins métier qui requiert des évolutions du SI Legacy. Mais la maintenabilité de ce dernier étant difficile souvent les demandes d’évolution ne sont pas honorées.
  • Les besoins de rationalisation métier et/ou IT suite à des fusions / acquisitions.
  • La mise en conformité du SI dans le cadre d’une trajectoire de modernisation IT.
  • L’accélération du rythme des changements dans un monde VUCA

Existe t’il une recette miracle pour migrer d’un « SI Legacy » vers un « SI moderne » ?

La réponse est clairement non . SI cette recette existait il n’y aurait pas autant de DSI confrontées à des projets de migration qui n’aboutissent pas et se terminent par la coexistence et l’intégration d’un composant legacy toujours actif avec de nouveaux composants. Au final, une situation plus complexe qu’au départ . 

Pour autant, une démarche peut permettre d’éviter les principaux pièges et difficultés pour envisager la migration d’un composant legacy. 

Quels sont les principaux obstacles ou principales difficultés qui rendent ce type de migration si complexe ?

Le plus gros obstacle est lié à la maîtrise de cet existant , à sa complexité intrinsèque (métier, fonctionnelle, données et technique) et à sa structure monobloc. Cette première caractéristique nous éclaire sur la durée du projet qui va être longue.

Les projets de migration de composant legacy sont motivés par l’obsolescence et sont donc vu comme des projets techniques, qui n’apportent pas de valeur aux métiers. Dans le contexte actuel, on ne fait plus de projet pharaonique sans apport de valeur pour l’entreprise. Il est donc nécessaire de faire du projet de décommissionnement de legacy un projet apporteur de valeur pour les métiers. Le concours des acteurs métiers est nécessaire mais leur mobilisation n’est pas évidente lorsque ces derniers sont satisfaits de l’utilisation du composant legacy. Une animation des acteurs métiers autour de la valeur et des bénéfices que peuvent apporter les nouvelles technologies (apports de la digitalisation) doit être prévue. 

Pour finaliser un tel projet dans un temps raisonnable il est nécessaire d’anticiper avec les acteurs métiers la possibilité de renoncer à certaines spécificités implémentées dans le SI legacy pour simplifier le geste métier et simplifier la migration. 

Une telle migration est littéralement impossible dans une approche “big bang” tant pour que le risque qu’elle représente que pour la complexité.

L’approche de migration nécessite donc une phase de “dual run” faisant cohabiter le composant legacy et les nouveaux composants et ce pendant de nombreux mois, voir années. Cette situation transitoire est inconfortable à la fois pour les métiers que pour les équipes de la DSI qui sont contraints de travailler avec des flux transitoires et des déploiements complexes et fréquents à conduire. Une trajectoire de migration en paliers (approche agile) est incontournable.

La dimension stratégique de ce type de transformation , tant par l’impact et le risque métier auquel elle est associée que par l’ampleur des moyens qu’elle requiert (budget, ressources durée) nécessite l’appui du Comité de Direction et d’un sponsor identifié et influent.

L’acceptation du projet par l’entreprise n’est pas une évidence.

Mais alors, on ne peut rien faire ?

Le constat de départ n’est certes pas rassurant, mais cette migration n’est pas impossible. Plusieurs pré requis clés sont nécessaires avant d’entamer la migration d’un composant legacy :

• Limiter, autant que possible, les évolutions du legacy au strict nécessaire
• Faire un rétro engineering de l’architecture du composant du SI legacy, tant sur le volet fonctionnel que sur le volet Data . L’idéal étant de produire une cartographie des données et des capacités fonctionnelles par bloc présentant les caractéristiques d’indépendance forte.
• Faire un travail de conception modulaire de l’architecture cible remplaçant le SI legacy en  trouvant le bon équilibre entre la taille des modules et le nombre de modules.  Produire une cartographie des blocs fonctionnels et Data de la cible tout en intégrant des éléments de valeur métier additionnels
• Mettre en place un mécanisme d’intégration facilitant les échanges de données entre le legacy et les composants cibles (interface de découplage)

Il faut ensuite conduire une analyse d’écart entre les blocs d’architecture et data initiaux et les blocs cibles, puis évaluer pour chaque objet métier des blocs data du Si legacy les impacts liés à l’inversion de propriété des données entre le SI Historique et du SI Cible. La vision des données et des règles de gestion associées peut être différente entre le Legacy et la cible rendant la cohabitation entre les deux SI très complexe.

Le dernier challenge consiste à définir le séquencement optimal des opérations de démantèlement progressif du SI Legacy permettant d’optimiser l’équilibre entre la durée de migration, le risque et les impacts métier induits et la capacité à apporter de la valeur métier aux utilisateurs.

Quelles situations as-tu observé chez tes clients sur la migration des « SI Legacy » ?

Trois situations observées chez les clients :

• Ceux qui ont les moyens, ont essayé et essayent encore, et ce n’est pas la première tentative
• Ceux qui ont envie, hésitent, renoncent, puis se reposent la question … et sont face à un refus d’obstacle, non pas par qu’il ne veulent pas, mais par qu’il ne sont pas à l’aise sur le comment (la stratégie / la trajectoire)
• Ceux qui n’ont pas conscience du danger et ne font rien.

Globalement les DSI ayant migré un composant legacy de grande taille avec succès sont assez rare pour être peu visibles ! 

Quelles prestations Projexion peut-il proposer à ses clients sur ce sujet ?

Projexion dispose de tous les atouts pour accompagner les entreprises confrontées à de telles migrations.

1. Formaliser l’existant par une étude de retro-engineering du Legacy. 
2. Définir la valeur et les services apportés par la cible en intégrant une forte dose d’idéation avec les équipes métier autour de la digitalisation.
3. Etudier les scénarios d’architecture cible répondant aux besoins fonctionnels et non fonctionnels. Sélectionner le scénario le plus adapté.
4. Identifier, préparer les éléments clés d’aide à la décision en amont du lancement de ces projets afin de convaincre les directions générale d’engager le projet
5. Étudier les scénarios de migration possible. Conduire une analyse comparative multi-critères (coût total, durée, impact utilisateur / impact métier, complexité intégration et échanges de données, complexité reprise de données, investissement sur composants transitoires, …)
6. Piloter les travaux de conception détaillée et d’implémentation de la solution cible, définir les stratégies de migration de données, gérer les risques et la qualité globale du projet,
7. Élaborer et animer les plans de conduite du changement, gérer le volet communication associé à un projet de cet ampleur.