Gérer la dette technologique architecturale

Quand je pense à la dette technique, je me souviens encore de la première application que j'ai créée et qui m'a fait prendre conscience des conséquences d'une architecture inadaptée. Cela s’est produit à la fin des années 1990, lorsque je débutais en tant que consultant.

Le client avait demandé l'utilisation de la plateforme Lotus Notes pour créer un système d'approvisionnement pour ses clients. À l'aide du client Lotus Notes et d'une application personnalisée, les utilisateurs finaux pouvaient formuler des demandes qui seraient suivies par l'application et satisfaites par l'équipe du propriétaire du produit. En théorie, c'était une idée vraiment intéressante, d'autant plus que les applications développées sur le Web n'étaient pas répandues et que tout le monde utilisait Lotus Notes quotidiennement.

Le problème principal est que les données étaient de conception très relationnelle – et Lotus Notes n’était pas une base de données relationnelle. La conception de la solution nécessitait une gestion de schéma dans chaque document Lotus Notes et s'appuyait sur une série de champs à valeurs multiples pour simuler les relations entre les attributs de données. C'était le bordel.

Une grande partie de la logique dans l'application Lotus Notes n'aurait pas été nécessaire si une meilleure plate-forme avait été recommandée. Le code source était compliqué à prendre en charge. Les améliorations apportées à la structure des données ont entraîné une refactorisation majeure du code sous-jacent, sans parler de l'exécution de tâches basées sur le serveur pour convertir les données existantes. Ne me lancez pas dans les efforts liés à la création de rapports.

Depuis le début de ma carrière, je me suis concentré sur la fourniture d’une solution souhaitée par le client plutôt que d’essayer de proposer une meilleure solution. C'est certainement une leçon que j'ai apprise au début de ma carrière, mais au fil des années qui ont suivi ce projet, j'ai réalisé que la conséquence de la dette technique architecturale est une triste réalité à laquelle nous sommes tous confrontés.

Explorons un peu plus le concept de dette technologique architecturale à un niveau macro.

Dette technologique architecturale (ATD)

La bibliothèque de la dette technique architecturale (ATD) de l'Université Carnegie Mellon fournit la définition suivante.) de l'ATD :

La dette technique architecturale est une approche de conception ou de construction qui est opportune à court terme, mais qui crée un contexte technique dans lequel le même travail nécessite une refonte architecturale et coûte plus cher à réaliser plus tard que ce qu'il en coûterait maintenant (y compris une augmentation des coûts au fil du temps). .

Dans la « Réponse rapide : Comment gérer la dette technique de l’architecture » (publiée le 22/09/2023), Gartner Group définit l’ATD comme suit :

La dette technique architecturale est le type de dette technique causée par une dérive architecturale, des décisions architecturales sous-optimales, des violations de l'architecture de produit cible définie et des meilleures pratiques architecturales établies de l'industrie, ainsi que des compromis architecturaux effectués pour une livraison plus rapide des logiciels.

Dans les deux cas, les bénéfices qui donnent souvent lieu à des célébrations à court terme peuvent être confrontés à des défis à long terme. Ceci est similaire à mon exemple Lotus Notes mentionné dans l'introduction.

Pour compliquer encore les choses, les outils permettant d'aider à identifier et à gérer la dette technologique pour l'architecture logicielle manquaient par rapport aux autres aspects du développement logiciel :

Pour la qualité du code, l'observabilité et SCA, des outils éprouvés existent avec des produits comme Sonarqube, Datadog, New Relic, GitHub et Snyk. Cependant, le segment de l’architecture logicielle est à la traîne sans aucune solution éprouvée.

C’est regrettable, étant donné que l’ATD est systématiquement le type de dette technique le plus important – et le plus dommageable, comme le montre l’étude « Measure It ? Gérer? L'ignorer ? Software Practitioners and Technical Debt » Étude 2015 publiée par Carnegie Mellon.

L'illustration suivante résume la figure 4 de ce rapport, concluant que les mauvais choix d'architecture étaient clairement les principales sources de dette technique.

S’il n’est pas géré, l’ATD peut continuer à croître au fil du temps à un rythme croissant, comme le démontre cette illustration simple :

Sans atténuation, la dette architecturale finira par atteindre un point de rupture pour la solution sous-jacente mesurée.

Gérer l'ATD

Avant de pouvoir gérer l’ATD, nous devons d’abord comprendre le problème. Desmond Tutu a dit un jour avec sagesse : « Il n’y a qu’une seule façon de manger un éléphant : une bouchée à la fois. »

L’approche « shift-left » adopte le concept consistant à rapprocher un aspect donné du début plutôt que de la fin d’un cycle de vie. Ce concept a gagné en popularité avec le décalage vers la gauche pour les tests, où la phase de test a été déplacée vers une partie du processus de développement et non comme un événement distinct à terminer une fois le développement terminé.

Shift-left peut être implémenté de deux manières différentes dans la gestion d'ATD :

• Shift-gauche pour la résilience : identifier les sources qui ont un impact sur la résilience, puis les corriger avant qu'elles ne se manifestent dans les performances.
• Maj-gauche pour la sécurité : détectez et atténuez les problèmes de sécurité pendant le cycle de vie de développement.

Tout comme le déplacement vers la gauche pour les tests, une concentration prioritaire sur la résilience et la sécurité pendant la phase de développement réduira le risque d'incidents inattendus.

Observabilité architecturale

L'observabilité architecturale donne aux équipes d'ingénierie la possibilité de traiter progressivement la dérive architecturale au sein de leurs services à un niveau macro. En fait, le Wall Street Journal a rapporté le coût de la réparation de la dette technique à 1,52 billion de dollars plus tôt cette année dans l'article « Le problème invisible de 1,52 billion de dollars : les vieux logiciels maladroits ».

Pour réussir, le leadership en ingénierie doit être pleinement aligné sur les objectifs organisationnels suivants :

• Résilience – pour se remettre rapidement d’incidents inattendus.
• Évolutivité – pour évoluer de manière appropriée avec la demande des clients.
• Velocity – pour offrir des fonctionnalités et des améliorations conformes aux attentes du produit.
• Cloud Suitability : transformer les solutions existantes en offres de services cloud natives efficaces.

J'ai récemment découvert la plateforme d'observabilité architecturale basée sur l'IA de vFunction , qui se concentre sur les livrables suivants :

• Découvrez la véritable architecture des solutions via des analyses statiques et dynamiques.
• Empêchez la dérive de l'architecture grâce à des vues en temps réel de l'évolution des services.
• Augmentez la résilience des applications en éliminant les dépendances inutiles et en améliorant les domaines d'application et leurs ressources associées.
• Gérez et corrigez la dette technologique grâce à l’observabilité basée sur l’IA.

De plus, la plate-forme vFunction offre l’avantage secondaire de fournir un chemin de migration pour passer des solutions monolithiques aux solutions cloud natives. Une fois que les équipes ont modernisé leurs plateformes, elles peuvent les observer en permanence pour déceler une dérive continue. Si les entreprises disposent déjà de microservices, elles peuvent utiliser vFunction pour détecter la complexité des applications distribuées et résoudre les dépendances qui ont un impact sur la résilience et l'évolutivité. Dans les deux cas, une fois mis en œuvre, les équipes d’ingénierie peuvent atténuer l’ATD bien avant d’atteindre le point de rupture.

Dans l'illustration ci-dessus, les équipes d'ingénierie sont en mesure d'atténuer la dette technique dans le cadre de chaque version, grâce à la mise en œuvre de la plate-forme vFunction et à une approche sous-jacente de décalage à gauche.

Conclusion

Mes lecteurs se souviendront peut-être que je me suis concentré sur l'énoncé de mission suivant, qui, à mon avis, peut s'appliquer à tout professionnel de l'informatique :

« Concentrez votre temps sur la fourniture de caractéristiques/fonctionnalités qui augmentent la valeur de votre propriété intellectuelle. Tirez parti des frameworks, des produits et des services pour tout le reste. -J.Vester

La plateforme vFunction adhère à mon énoncé de mission en aidant les équipes d'ingénierie à adopter une approche de décalage vers la gauche pour la résilience et la sécurité de leurs services à un niveau macro. Il s'agit d'une distinction importante, car sans de tels outils, les équipes sont susceptibles d'atténuer leurs problèmes au niveau micro, résolvant ainsi une dette technologique qui n'a pas vraiment d'importance d'un point de vue organisationnel.

Quand je repense à cette application qui m'a fait prendre conscience des défis liés à la dette technologique, je ne peux m'empêcher de penser à la façon dont cette solution a généré plus de problèmes que d'avantages avec chaque fonctionnalité introduite. Certes, l’utilisation du décalage vers la gauche uniquement pour la résilience aurait contribué à faire ressortir les problèmes liés à l’architecture sous-jacente à un point où le coût de l’examen d’alternatives serait réalisable.

Si vous souhaitez en savoir plus sur la solution vFunction, vous pouvez en savoir plus ici .

Passez une très bonne journée !