Le développement augmenté existe d’ores et déjà. Souvent regardés de haut, les outils de GenAI sont une évolution naturelle des fonctionnalités d’autocomplétion. À adopter d’urgence pour en tirer tous les bénéfices.
Même si l'IA est privilégiée, il faut toujours partir de la stratégie et des problèmes à résoudre, prévient la HBR, dont l'approche 3P fait écho au Tech, Orga, Culture de WEnvision.
"The Software Architect Elevator" est une de feuille de route pour les architectes. En embrassant le changement, en comprenant les systèmes organisationnels et en favorisant une communication efficace, les architectes peuvent jouer un rôle central en conduisant les organisations vers le succès.
La dette technique est un problème récurrent des architectures logicielles, accentué par l'accélération des innovations technologiques. Le Modularity Maturity Index permet d'évaluer et de caractériser les systèmes, dans l'optique de fixer des trajectoires pertinentes afin d'y remédier.
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 :
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.
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…
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.
