Modernisation des applications : Quand la réécriture est meilleure que le refactoring

L’un des impacts les plus importants de la transformation numérique est la perturbation du développement des applications. Historiquement, l’introduction de nouvelles architectures dans le développement d’applications prend généralement plusieurs années avant de prendre son essor et d’être adoptée par le grand public. Les architectures d’application qui ont tendance à envahir des secteurs entiers deviennent finalement la norme de facto. Nous avons vu cela se produire au milieu et à la fin des années 1990, lorsque J2EE est devenu lentement mais sûrement la « norme d’entreprise » pour le développement d’applications Web à trois niveaux.

Aujourd’hui, l’architecture qui semble destinée à « perdurer » et à devenir la nouvelle norme est le cloud native. Ces architectures de microservices basées sur des conteneurs évoluent rapidement pour dominer les nouveaux projets de développement dans tous les secteurs. La croissance réussie de Kubernetes, sur lequel un nombre important de ces applications sont déployées et exploitées, indique que cette dernière architecture d’application est là pour rester. Nos recherches montrent qu’au moins la moitié des organisations explorent de « nouvelles architectures » en raison de la transformation numérique. 

Aujourd’hui, cela est souvent interprété comme signifiant que les organisations sont engagées dans un processus de « modernisation ». Et nous (l’industrie) avons tendance à parler de modernisation en termes très généraux (et vagues). Comme si les organisations agitaient simplement une baguette magique et que toutes leurs applications seraient construites sur ce nouveau modèle. 

La réalité est que les organisations disposent de nombreuses façons de moderniser leurs applications. Seuls certains (37 %) adoptent une approche de refactoring. Les méthodes de refactorisation abondent, l'une des approches les plus populaires étant Red Green Refactor. Mais il en existe d’autres, notamment le refactoring préparatoire et une sélection d’options basées sur l’abstraction parmi lesquelles choisir. La plupart sont basés sur la simplification du code. En d’autres termes, ils s’appuient largement sur une forme de réécriture de l’application moins perturbatrice.

Mais il y a des moments où une réécriture complète est la meilleure stratégie de modernisation. En règle générale, l’effort nécessaire pour réécrire complètement une application existante peut être suffisamment important pour décourager même le défenseur le plus déterminé de la transformation numérique. Mais dans certains cas, cela peut générer des économies importantes.

Considérez l’approche adoptée par une agence fédérale pour moderniser son portefeuille d’applications. Dans le cadre d'un mandat visant à passer à une méthodologie Agile, l'agence avait besoin d'une autorisation spéciale pour développer des applications de manière traditionnelle, en cascade. Or, la méthode en cascade était la méthodologie dominante lorsque je codais, donc oui, c'est vieux. L’agence a décidé que le meilleur point de départ était de comprendre son propre portefeuille et de rationaliser la nécessité de chaque application.

Au cours de cet audit, ils ont trouvé près de 200 applications, sur environ 6 000, qui effectuaient la même tâche de base de gestion des actifs. Imaginez, un instant, qu’un changement soit nécessaire à cette fonction commerciale de base, nécessitant la modification des 200 applications.

Cela représente beaucoup de temps et d’efforts de la part des développeurs et des opérateurs pour développer, tester et déployer la même fonction métier.

L'agence a décidé de se moderniser en remplaçant les 200 applications par un seul microservice qui peut désormais être utilisé dans toute l'agence pour suivre les actifs. Développé à l'aide de méthodologies Agile et exploité dans un environnement moderne, il peut évoluer pour répondre aux besoins de chaque fonction qui s'appuyait sur sa propre application personnelle et privée.

Tous les efforts de modernisation ne se concentrent pas sur la refactorisation. Explorer de manière stratégique ce que la modernisation signifie pour l’ensemble du portefeuille d’applications peut générer des avantages commerciaux significatifs. De nombreuses organisations, en particulier celles qui fonctionnent depuis des décennies, sont susceptibles d’être confrontées au même problème de portefeuille : la duplication. Les restructurations, les acquisitions, les fusions et les changements de direction peuvent facilement conduire à une duplication des applications.

Il serait bénéfique pour chaque organisation de procéder à un audit et à une rationalisation des applications dans le cadre d’une stratégie de modernisation. Vous constaterez peut-être que vous disposez de centaines d’applications, mais que vous n’avez besoin que de certaines d’entre elles. Ce type de stratégie permet aux dirigeants de justifier une application entièrement nouvelle, développée dans une nouvelle architecture, afin d’éliminer la redondance des applications et les coûts qu’une telle situation entraîne.