Un système « legacy » est souvent un mot tabou, utilisé pour désigner un code que nous ne comprenons plus. Une autre définition aussi répandue est celle d’application obsolète, ancienne.
Un article (en construction) pour en savoir plus sur les applications « legacy », leur obsolescence et leur modernisation.
(Chaque semaine, notre auteure publie un complément à cet article sur son profil linkedin. Un challenge limité à 1.300 mots par semaine …)
W1 – Les critères de l’obsolescence
Toutes les applications métiers sont, par définition, spécifiques.
Si votre entreprise souhaite diminuer les coûts de maintenance et/ou récupérer une capacité à introduire de l’innovation, il est important d’identifier les principales raisons de leur obsolescence. Et sans concession !
Basé sur mon expérience, j’utilise une liste simple pour identifier une application métier problématique, certains clients diront « toxique », dans un portefeuille applicatif :
– Les utilisateurs s’en plaignent régulièrement,
– L’application est critique pour le coeur business et donc irremplaçable,
– Des évolutions sont nécessaires mais trop couteuses,
– Les technologies utilisées pour construire l’application sont obsolètes ou posent des enjeux de performance ou de sécurité,
– Il n’y a aucun test automatisé pour vérifier les non-régressions,
– La conception de l’application est problématique,
– Les développeurs ne sont plus là et les compétences sont rares voire perdues.
Une fois identifiée cette obsolescence, reste une question essentielle avant d’envisager une modernisation : est-ce que l’application mérite d’être sauvée ?
W2 – Votre application mérite-t-elle d’être sauvée ?
Après avoir identifié la ou les raisons de l’obsolescence de votre application coeur de métier, il reste la question essentielle avant d’envisager sa modernisation : « mon application mérite-t-elle d’être sauvée ? »
Vous avez toujours de bonnes raisons de conserver votre application « legacy » :
– Elle fonctionne de manière satisfaisante, les couts de remplacement sont prohibitif en regard des (faibles) avantages fonctionnels apportés,
– Elle requiert une haute disponibilité et ne peut être interrompue, les couts pour concevoir une nouvelle application équivalente sont prohibitifs, le système existant étant peu maitrisé, peu documenté, et les sachants sont partis.
En réalité, le remplacement de votre application legacy doit intervenir dès qu’il est nécessaire de la maintenir et que ce coût de maintien dépasse sa valeur.
Il ne faut pas négliger non plus les impacts sur votre business de rester avec un système obsolète : risques liés à la sécurité, time-to-market pour l’introduction de nouvelles fonctionnalités, démotivation des ingénieurs assurant les évolutions et la maintenance, dégradation de la dette technique …
Une fois votre décision prise, il reste encore à choisir le bon scénario pour se désengager de cette application.
W3 – Les scénarios de désengagement
Vous avez décidé de vous désengager de votre application toxique, et vous êtes maintenant devant un choix cornélien, celui du scénario. Petite revue des différentes possibilités qui s’offrent à vous.
– Migrer vers un système totalement neuf, en espérant que cette réécriture va inclure l’accès à de nouvelles technologies, possiblement plus utilisées et moins onéreuses,
– Conserver le système existant en découplant l’architecture de l’application en blocs techniques et/ou fonctionnels afin d’identifier des actions de modernisation bloc par bloc, en espérant que cette approche permette un niveau de décision assez fin et limite les risques liés aux travaux de transformation,
– Sous traiter maintenance et évolutions de l’application à un tiers, une approche directe et rapide, en espérant ne pas devenir dépendant d’un prestataire et ne pas avoir à gérer une réversibilité devenue encore plus complexe pour les mêmes raisons qu’à l’origine de votre décision,
– Migrer vers un progiciel, en espérant y retrouver vos processus et règles métiers et garder une agilité et compétitivité face à vos concurrents.
Dans la suite, nous allons comparer plus précisément l’approche « Big Bang » de rééecriture et l’approche incrémentale.
W4 – Big Bang ou bien ?
Dans les scénarios de désengagement d’une application toxique, il existe deux grandes approches, la ré-écriture complète et la modernisation incrémentale.
Le big bang est tentant : après avoir visionné des vidéos, lu des blogs vantant la dernière technologie à la mode – comme les micro-services, votre équipe est unanime, l’application ne peut pas être modernisée, il faut tout réécrire.
Le projet est excitant et les promesses sont nombreuses. Mais comme le dit si bien l’adage …
Dans nos missions nous tentons de sauver toutes ces applications qui nous arrivent avec toutes sortes d’atrocité et de bizarreries d’architecture, de code, (d’absence) de tests.
Et bien je peux vous l’assurer, le big bang est généralement la plus mauvaise décision, le chemin le plus long / dur / couteux / … et le plus propice à un échec critique :
– utilisateurs mécontents, la couverture fonctionnelle n’est plus assurée,
– problèmes de performance dès la première version,
– dépassements de budgets, souvent entre 50 et 400% !/
– écarts comportementaux entre le système legacy et le nouveau système.
Le plus terrible est de redécouvrir des règles métiers anciennes, que plus personne ne maitrise.
W5 – Big Bang, vraiment ?
Votre application est toxique, vous voulez vraiment la réécrire complétement ? Quelques éléments de réflexion à intégrer …
– Repartir d’une feuille blanche, n’est-ce-pas le risque d’oublier des règles métiers essentielles pour votre business ?
– La correction du code existant est-elle vraiment impossible et trop couteuse ? Une approche incrémentale au-delà d’une impression de mauvaise conception et piètre réalisation est-elle vraiment impossible ?
– Ce legacy ne peut-il pas atteindre les nouveaux critères de performance par améliorations successives ?
– Le big-bang va-t’il vraiment apporter de la valeur ajoutée aux utilisateurs ?
– Les nouvelles technologies utilisées vont-elles avoir un impact positif pour les utilisateurs ?
– Pendant la réécriture, n’allez-vous pas rater des opportunités business et prendre du retard face à la compétition ?
– La maintenance de l’application legacy ne sera-t-elle pas pénalisée pendant cette opération de réécriture, avec le risque de perdre des utilisateurs ?
– Avez-vous bien mesuré l’attachement de vos utilisateurs aux processus et écrans de l’application legagy avant de tout changer ?
N’y-a-t-il donc aucune bonne raison qui justifie une réécriture totale ?
W6 – Big Bang, les bonnes raisons
Malgré tous les désagréments que nous avons identifié, vous voulez vraiment de bonnes raisons pour justifier une réécriture totale de votre application toxique …
– L’architecture de votre legacy est impossible à modulariser et tout changement devient irrésistiblement un cauchemar,
– L’aspect financier n’est pas un problème,
– L’application est construite au-dessus d’une pile technologique dont chaque élément est forment couplé et tout changement est impossible à réaliser manuellement,
– L’application est parfaitement spéficiée dans le détail et sa réécriture ne comporte aucun risque,
– L’équipe en charge de l’application legacy est tout à fait apte à concevoir et développer la nouvelle cible,
– Vos sponsors ne comprennent pas l’approche incrémentale et l’investissement sur la durée par rapport à un simple coût forfaitaire de réécriture.
Pas vraiment convaincu ?
Il est peut être temps d’étudier l’approche incrémentale, la moins onereuse et la moins risquée lorsqu’elle est bien exécutée : elle requiert des experts ayant de bonnes connaissances à la fois sur les environnements legacy, sur les outils de refactoring d’architecture et de code et sur la nouvelle cible.
Rendez-vous à la rentrée de septembre pour approfondir cette approche.
W7 – Approche Incrémentale, en quelques mots
(à suivre jeudi 20 septembre …)
