Découvrez le MMI pour évaluer le ROI des efforts de réduction de la dette technique

Depuis plus de vingt ans maintenant, il est devenu évident dans toutes les DSI et dans la plupart des équipes de développement que le sujet de la dette technique (un terme inventé en 1992 par Ward Cunningham, un fameux agiliste et inventeur du concept de wiki, rien que ça) doit être traité, au même titre que les aspects fonctionnels des applications informatiques.

Les efforts financiers destinés à s'affranchir des systèmes monolithiques d'antan ou à numériser nos bureaucraties modernes sont tels qu'un retour sur investissement significatif est attendu. Or, ce que les systèmes d'information ont gagné en souplesse semble avoir été perdu en longévité. Et c'est pour éviter le syndrome de la solution jetable que des réflexions ont démarré il y a plus de dix ans pour définir un "indice de maturité de la modularité" (Modularity Maturity Index ou MMI).

Bien qu'il existe évidemment différents types de dette technique, cet indice de maturité - qui fait écho à d'autres concepts comme les modèles de maturité SOA ou encore le Capability Maturity Model (CMM) datant de 1986 - se donne pour objectif d'appréhender l'état courant de l'implémentation, de la conception technique du système d'information ou de la couverture de tests et de documentation , afin de dégager les priorités qui vont permettre d'investir efficacement. Graham Charters (IBM) a proposé 6 niveaux de maturité distincts sur la trajectoire d'une modularité complète du SI :

• Niveau 1 : Ad hoc. Rien n'est modulaire. On n'a qu'un gros tas de librairies, ou pire, de classes. Cela correspond généralement à une application monolithique.
• Niveau 2 : Modules. Les modules sont formellement identifiés/versionnés et les dépendances sont constituées par rapport à l'identité du module plutôt qu'aux unités elles-mêmes.
  Les outils Maven/Gradle, Ivy, RPM et OSGi mènent à cette catégorie.
• Niveau 3 : Modularité/encapsulation. Les modules sont déclarés via des contrats, et non plus via des identifiants/versions de module en dur. Les exigences peuvent être abstraites (par exemple, que les services déclaratifs soient disponibles) ou pointer vers des paquetages spécifiques (via un nom de domaine, par exemple).
• Niveau 4 : (dé)Couplage. Les implémentations ne sont pas obtenues via des fabriques (factory method or abstract factory design patterns) ou les constructeurs ; au lieu de cela, ils sont retrouvés dynamiquement à partir d'un registre ou injectés à la demande.
  Le couplage faible doit amener à identifier des sous-ensembles dotés d'une forte cohésion, qui doit obligatoirement faire écho à une nécessité fonctionnelle évidente. C'est alors qu'on peut commencer à juger qualitativement le SI.

REM: On pourrait considérer que le couplage lâche, ou l'indépendance de mise en œuvre (sans classe commune), entre les modules fait partie de la modularité. En effet, on peut décrire le partage des implémentations en termes d'exigences et de capacités. Cependant, il arrive qu'on doive exécuter les modules dans un environnement non modulaire, très structurant, et l'adoption du couplage lâche est alors problématique.

• Niveau 5 : Désistement. Les propriétés des artefacts sont transférées à des référentiels, supports de la modularité, qui peuvent prendre en charge la collaboration entre modules pour y accéder en fonction des capacités requises.
• Niveau 6 : Dynamisme. Les modules participent à un cycle de vie dynamique qui inclut la possibilité d'ajouter, de mettre à jour et de supprimer des modules au moment de l'exécution, tout en préservant l'état du système.

La réduction de la dette technique s'inscrit dans un cycle sans fin d'améliorations (fonctionnelles ou non fonctionnelles) et de dégradations successives. De ce fait, elle a toute sa place dans la méthodologie agile, qui reconnaît le changement contextuel permanent et la perfectibilité chronique des logiciels. Malheureusement, cette conscience d'une nécessité budgétaire adéquate ne fait qu'émerger dans l'industrie IT. La succession de générations d'informaticiens avec des formations académiques nouvelles (Cobol, C++, Java, JavaScript, etc.) n'y étant d'ailleurs pas étrangère : le turnover a ses travers…

Comment se mettre en ordre de bataille ?

Un état des lieux soigneux et l'identification d'un niveau de maturité global permet de définir les directives nécessaires à une meilleure maintenabilité des systèmes d'information. Selon moi, cette trajectoire n'a pourtant pas besoin d'être linéaire. L'intelligence des architectes provient essentiellement de leur capacité à reconnaître et à saisir les opportunités de procéder à des bonds significatifs, lorsque l'occasion se présente. Quoi qu'il en soit, gardons en tête l'intention d'origine derrière la modularité : une réutilisation optimale des composants et une une empreinte évolutive la plus réduite possible ("innovation, j'écris ton nom"). À cet égard, c'est l'approche headless qui aujourd'hui constitue l'état de l'art. Ce qui, en dessous, relève de la conception modulaire (SOA, event-driven, event sourcing, data streaming…) me paraît finalement être secondaire.

Concrètement, une façon de mesurer la modularité d'un système est d'observer le nombre de fois où les modules logiciels sont retouchés (compilés) chaque mois/année, et de le comparer au nombre total de modules. De cette façon, on obtient une indication de la quantité de code modifié. Une meilleure modularisation et un meilleur découplage réduiront ce ratio en cascade. Notons que cela fonctionne aussi avec les spécifications fonctionnelles ; bienvenue dans un monde orienté produit !

En pratique, ce sont le refactoring et le remplacement des composants qui permettent de s'attaquer au problème de la dette technique. De solides principes d'architecture/rationalisation et le MMI permettent de se situer dans ce chantier et de mesurer les progrès effectués. Avec normalement un impact à plus ou moins long terme sur la vélocité (valeur par sprint) et surtout la qualité (nombre de bugs) des projets.

La fragmentation, la hiérarchisation et la schématisation/généralisation (qui sont les trois capacités les plus remarquables de notre cerveau d'après les sciences cognitives) doivent permettre de cartographier le SI, de fixer un cap, et de suivre les avancées réalisées. Vous trouverez plus de détails à ce sujet, notamment une méthode de calcul complète pour le MMI, dans ce chapitre écrit par Carola Lilienthal, qui fait partie de l'excellent ouvrage collectif Software Architecture Metrics publié aux non moins excellentes éditions O'Reilly. Malgré une méthodologie laborieuse, les architectes récipiendaires de systèmes complexes bénéficieront d'un précieux outil quantitatif pour les guider dans leurs choix.