Gestion De La Dette Technique Dans Une Architecture Microservices

À QCon Plus, Glenn Engstrand a parlé d'une méthodologie pour faciliter la gestion de la dette technique. La plupart des personnes impliquées dans le développement de logiciels ont eu du mal à convaincre les chefs de produit ou de projet de les laisser passer du temps à régler la dette technique de leur projet. La méthode utilisée par Glenn Engstrand chez Optum Digital (anciennement Rally Health) permet de gérer ces problèmes de priorisation de manière systémique et non conflictuelle.

Qu'est-ce que la dette technique ?

D'une manière générale, la dette technique est l'ensemble des décisions prises lors du développement d'un logiciel qui réduisent la capacité des équipes à construire des fonctionnalités qui apportent de la valeur.

L'échange suivant devrait être familier. Le chef de produit décrit la prochaine fonctionnalité qu'il souhaite ajouter au produit. Les développeurs donnent une estimation élevée du temps de mise en œuvre, considéré comme trop long. Les développeurs parlent de devoir gérer les implications de modifications apportées à de nombreux codes difficiles à comprendre ou de contourner des bugs dans d'anciennes bibliothèques ou frameworks. Ensuite, les développeurs demandent du temps pour résoudre ces problèmes, et le chef de produit refuse, se référant au backlog de fonctionnalités souhaitées qui doivent être implémentées en premier.

S'il n'est pas maîtrisé assez longtemps, ce cercle vicieux peut conduire à l'incapacité de rivaliser avec succès sur le marché ou même à l'effondrement catastrophique complet de systèmes logiciels complexes.

Il se divise en deux parties : l'une concerne le choix d'une solution facile ou rapide au lieu de la meilleure solution ; une autre est liée à l'obsolescence ou à l'inadéquation de la pile technique. Les deux parties font passer du temps d'ingénierie à gérer la complexité accidentelle au lieu de créer de la valeur ou de corriger des bugs.

Rembourser la dette technique tout en maintenant une vitesse compétitive en fournissant des fonctionnalités peut être difficile, et cela ne fait qu'empirer à mesure que les architectures système s'agrandissent. La gestion de la dette technique pour des dizaines ou des centaines de microservices est beaucoup plus compliquée que pour un seul service, et les risques associés au non-remboursement augmentent plus rapidement.

Chaque éditeur de logiciels arrive tôt ou tard à un point où la gestion de la dette technique devient inévitable.

Chez Optum Digital, un portfolio - également appelé gamme de produits logiciels - est un ensemble de produits qui, combinés, répondent à un besoin spécifique. Plusieurs équipes sont affectées à chaque produit, généralement alignées sur un client logiciel ou un service backend. Il existe également des équipes pour des services plus orientés plateforme qui fonctionnent sur plusieurs portfolios. Chaque équipe est très probablement responsable de divers référentiels de logiciels. Plus de 700 ingénieurs développent des centaines de microservices. Ils prennent la dette technique très au sérieux car les risques qu'elle devienne incontrôlable sont bien réels.

Notre CTO a initialement publié un blog sur l'importance des investissements en ingénierie en 2018, environ deux ans après qu'ils aient initialement divisé leur monolithe en microservices.

Le plan de capacité technologique

Les ingénieurs de l'entreprise ont élaboré un plan de capacité technologique (Technology Capability Plan ou TCP) pour résoudre le problème de la dette technique.

Le TCP est une méthode communautaire pour créer des plans de remboursement de la dette technique. Il est utilisé par et pour l'ingénierie pour signaler l'intention à la fois à l'ingénierie et au produit en collectant, organisant et communiquant les exigences en constante évolution dans le paysage technologique de l'architecture pour la longévité et l'adaptabilité. En d'autres termes, il peut être utilisé pour indiquer quand l'entreprise sera dans une mauvaise situation si des mesures spécifiques ne sont pas prises à temps.

Ces communautés sont motivées pour créer des plans de remboursement de la dette technique, selon un format spécifique. Un score de risque est ensuite calculé pour chaque domaine de dette technique, et les priorités sont définies en fonction de ce score de risque. Les plans hiérarchisés permettent de négocier positivement et concrètement le temps d'ingénierie pour le remboursement de la dette technique avec les chefs de produit.

Communautés d'ingénierie

Des communautés d'ingénieurs se forment transversalement à l'organisation ; en d'autres termes, ils ne sont pas associés à une équipe ou à un produit spécifique. Souvent, les ingénieurs sont attirés par ces communautés de pratique en raison de leur passion pour le travail avec les mêmes technologies, ce qui signifie que les communautés peuvent être ouvertes et se développer de manière organique.

Cependant, si certaines communautés sont considérées comme ayant une valeur stratégique, celles-ci peuvent être définies uniquement sur invitation. Si l'adhésion est organisée, l'accent devrait être mis sur la culture ajoutée plutôt que sur l'adéquation culturelle, et cela devrait également assurer la représentativité et la diversité.

Ils ont généralement des ressources de communication dédiées (par exemple, un sujet wiki, un canal de discussion et une liste de diffusion) pour les conversations en cours et le partage des ressources.

Les politiques sont définies de bas en haut par ces communautés d'ingénieurs, ce qui est la clé de l'efficacité et de l'authenticité du TCP.

La réunion mensuelle de la communauté est enregistrée et partagée, et son résumé est envoyé à tous les ingénieurs. La partie du TCP de chaque communauté est un document vivant tenu à jour en fonction de l'activité des réunions. Une fois par trimestre, ces documents sont collectés et publiés en interne comme le TCP.

Construire des plans pour rembourser la dette technique

Le plan de chaque communauté contient environ une page d'un récit explicatif et un tableau représentant l'évolution technologique souhaitée dans le temps.

Chaque ligne du tableau est dédiée aux versions préférées, acceptables, déconseillées ou inacceptables (preferred, acceptable, discouraged, ou unacceptable : PADU) d'une technologie du langage de programmation, du framework, de la bibliothèque ou de la plate-forme en tant que service concerné. Il est naturellement propre à la ou aux stack(s) technologique(s) de l'organisation.

Chaque colonne représente une période de temps (par exemple, un trimestre ou une année). L'ensemble du tableau est censé représenter les trois prochaines années.

Chaque cellule du tableau contient l'état du cycle de vie de la version de la technologie pendant la période de la colonne : planifier, déprécier, migrer, utiliser ou supprimer.

L'état du plan indique la nécessité de planifier une mise à niveau. Obsolète (Deprecate) signifie que les équipes ne peuvent plus adopter la version technologique. L'état de la migration (Migrate) suggère que chaque équipe doit migrer activement vers la version appropriée. Le statut d'utilisation (Use) signifie que cette version de la technologie doit être celle que vous utilisez. Le statut de suppression (Remove) signifie que la technologie peut être rendue indisponible à tout moment au cours de cette période.

Le récit explicatif définit le contexte dans lequel chaque technologie doit être utilisée et l'impact ou les conséquences pour chaque équipe qui ne suit pas le plan. Ces plans communautaires aident l'organisation à gérer l'aspect de la dette technologique qui concerne l'utilisation de versions technologiques obsolètes, non sécurisées ou non prises en charge.

Chaque portefeuille doit également soumettre un plan à inclure dans le TCP. Les plans axés sur le portefeuille signalent l'intention de rembourser les autres formes de dette technologique, telles que la refactorisation de grandes bases de code ou la scission de services monolithiques en de nombreux services plus petits.

En plus des sections de la communauté et du portefeuille du TCP, il y a aussi une introduction exposant la vision du plan et une section décrivant les domaines de produits qui présentent actuellement le plus de risques.

Qu'est-ce que le risque technologique ?

Les communautés d'ingénieurs et les ingénieurs principaux du portefeuille élaborent un plan de remboursement de la dette technique, qui a abouti à une longue liste d'investissements en ingénierie à réaliser. Sachant que les ressources sont limitées, comment hiérarchisez-vous la liste ? La gestion des produits ne sait pas comment faire cela parce que les investissements en ingénierie ne viennent pas d'eux. La réponse vient de la compréhension du risque relatif de ne pas suivre chaque partie du plan.

Ce risque est saisi sous la forme d'un score de risque numérique. Plus le score est élevé, plus le risque est grand, donc plus la priorité est élevée. Les technologies avec le statut utilisation ont toujours un score de zéro. Le score de risque non nul peut augmenter pour chaque période où une version de technologie a la status à migrer, obsolète ou supprimé.

Alors que chaque plan vient du bas vers le haut, le score de risque vient du haut vers le bas. Le plan provient des ingénieurs participants de la communauté, et la hiérarchisation de cette liste provient de la direction de l'ingénierie exécutive.

Les mesures d'Optum Digital sont rassemblées dans ce que l'on appelle un tableau de bord équilibré (balanced scorecard), qui est un outil de gestion de la performance stratégique issu à l'origine de la Harvard School of Business.

Chaque technologie des différents plans est regroupée par produit à cet effet. Le score de risque par produit est la somme des scores de risque pour ce produit. Un produit est pénalisé par un score de risque si même un seul de ses référentiels utilise ou dépend encore d'une technologie obsolète, migrée ou supprimée. Ce score de risque n'est compté qu'une seule fois, même si plusieurs référentiels ne sont pas conformes. La médiane de ces agrégats de score de risque par produit est enregistrée dans le tableau de bord équilibré.

Il est logique d'utiliser une analyse de code statique automatisée sur vos référentiels pour déterminer les dépendances technologiques. Vous aurez également besoin d'un bon support concernant CI/CD, DevOps et GitOps pour calculer rapidement et de manière fiable cette métrique.

Nous calculons également le score de risque TCP différemment pour aider à concentrer les équipes sur chaque produit. Chaque technologie des plans est cumulée par référentiel dans cette métrique. Le score de risque par référentiel est la somme des scores de risque pour ce référentiel.

Les scores de risque agrégés pour les référentiels d'un produit sont résumés comme le score de risque agrégé pour le produit lui-même. De cette manière, nous pouvons suivre l'épuisement des risques pour chaque produit ou effectuer des comparaisons de produits en fonction du risque TCP.

Placer les investissements en ingénierie sur la feuille de route

Maintenant que nous avons un plan hiérarchisé pour rembourser la dette technologique défini par des ingénieurs et validé par le leadership, comment pouvons-nous financer ce plan et l'inscrire sur la feuille de route ?

Tout d'abord, examinons ce qui se passe généralement sans TCP lorsque le responsable de l'ingénierie s'assoit avec le chef de produit pour établir le calendrier de développement des prochains sprints : dans un environnement non TCP, il n'y a que le responsable de l'ingénierie contre le chef de produit. Le chef de produit peut toujours invoquer les ventes pour obtenir ce qu'il veut.

Reprenons cette même négociation, cette fois avec le TCP en place. Le chef de produit, tout juste sorti d'une réunion avec les dirigeants sur l'importance du TCP et sur la manière dont nous devons réduire notre score de risque TCP dans le tableau de bord équilibré, s'assoit avec le responsable de l'ingénierie pour établir le calendrier des prochains sprints. Le chef de produit demande trois fonctionnalités. Le directeur de l'ingénierie déclare : "Si cela ne tenait qu'à moi, je vous donnerais ces trois fonctionnalités. Malheureusement, tous nos ingénieurs et leurs dirigeants ont identifié cette dette technique super risquée qui doit être remboursée ce trimestre. Vous auriez déjà été au courant de cela si vous aviez suivi le TCP au cours de la dernière année".

Voyez-vous comment la dynamique a changé ? Parce que le TCP est un authentique consensus à l'échelle de l'entreprise sur la dette technologique et ses risques, le responsable de l'ingénierie peut utiliser ce pouvoir de négociation collective lorsque vient le temps d'inscrire les investissements d'ingénierie sur la feuille de route sans crier ni menacer.

Dans le cas peu probable où le chef de produit continue d'être inflexible pour autoriser les investissements d'ingénierie sur la feuille de route, la chaîne d'escalade atteindra éventuellement le niveau exécutif. Vous souvenez-vous que le score de risque fait partie du tableau de bord équilibré ? Pour les dirigeants, ce tableau de bord équilibré est leur tableau de bord. C'est ainsi qu'ils voient dans quelle direction l'entreprise va. L'affichage de cette mesure sur le tableau de bord rend la dette technologique très réelle pour eux, ce qui augmente les chances de choisir des investissements d'ingénierie comme le remboursement de la dette technologique.

Alternatives au TCP

La seule autre approche systémique de la gestion de la dette technologique que je connaisse est documentée dans le livre Google Site Reliability Engineering.

Voici un aperçu rapide de cette approche et pourquoi je pense que le TCP est meilleur.

Tout d'abord, vous obtenez un consensus sur une liste de SLO (Service Level Objectives) ou d'objectifs de niveau service. Chaque fois que votre système sort de l'un de ces SLO, vous comptez cela comme une erreur. Vous disposez d'un nombre convenu d'erreurs acceptables par fenêtre de temps, connu sous le nom de budget d'erreurs. Vous n'êtes plus autorisé à publier d'autres fonctionnalités si votre système a dépassé son budget d'erreur jusqu'à la prochaine fenêtre temporelle.

Pour éviter cette situation, les chefs de produit sont censés être plus disposés à détourner les ressources d'ingénierie pour rembourser la dette technologique.

Voici pourquoi je trouve l'approche Google SRE très déstabilisante. La cause et l'effet entre les fonctionnalités et les ventes semblent être plus authentiques pour la plupart des chefs de produit que la cause et l'effet entre la dette technique et les pannes. Il y a une présomption que les releases de réduction de la dette technologique rendront toujours le système plus stable. Bien que l'on espère que cela soit vrai à long terme, ce n'est pas garanti à court terme.

Étant donné que les budgets d'erreur favorisent la réflexion à court terme, cela découragera les chefs de produit d'approuver de tels investissements d'ingénierie. Il est difficile de prédire quand les marges d'erreur seront dépassées et, par conséquent, de prévoir quand planifier le temps d'investissement en ingénierie.

Cette approche tend à opposer les chefs de produit à l'ingénierie dans une relation antagoniste. La rigidité de la méthode la rend plus risquée à adopter, donc plus difficile à obtenir l'approbation de l'exécutif. Enfin, cette approche tend à politiser le remboursement de la dette technologique, où les chefs de produit tentent de déjouer le système en convainquant les dirigeants de ne pas comptabiliser certaines pannes dans leurs budgets d'erreur ou de renégocier les SLO ou les budgets d'erreur pour retarder les conséquences de la sous-alimentation des investissements en ingénierie.

L'approche TCP se concentre sur l'atteinte d'un consensus authentique entre le produit et l'ingénierie. Le développement piloté par TCP est plus prévisible en ce qui concerne la feuille de route, de sorte que toutes les parties impliquées ont moins de surprises stressantes.

Résumé

Un plan de capacité technologique résoudra-t-il tous vos problèmes d'ingénierie ? Bien sûr que non.

Aurez-vous encore une dette technologique ? Absolument.

Aurez-vous encore besoin de prendre des raccourcis pour fournir des fonctionnalités dans des délais axés sur le client ? Je suis sûr que vous le ferez.

Le TCP n'est pas destiné à empêcher ou restreindre l'ingénierie et le produit de faire ce qu'ils font le mieux : créer et publier des logiciels. Le TCP signale aux ingénieurs et aux chefs de produit qu'il y a des coûts supplémentaires à prendre les raccourcis nécessaires et qu'ils ne peuvent pas ignorer ces coûts indéfiniment.

Avec le TCP, vous n'attendez pas que les pannes s'accumulent pour commencer à rembourser cette dette technologique. Aucun processus, aucune politique, aucune technologie ou aucun outil ne peut jamais servir de substitut raisonnable à l'ingénierie de la qualité.

Le TCP documente le consensus parmi les ingénieurs sur ce qui est la dette technologique la plus risquée et quand est-il raisonnable de la rembourser. Pour que le TCP soit respecté, ses plans doivent être pertinents, précis, convaincants et crédibles. Cela ne peut se produire que si ses contributeurs sont des professionnels chevronnés et matures dotés de solides compétences en ingénierie et intégrité.

Je pense que cette citation de notre document TCP le résume :

L'architecture pour la longévité et l'adaptabilité nécessite une compréhension approfondie des réalités d'aujourd'hui et des possibilités de demain. Cela nécessite une appréciation de la technologie et des forces du marché qui la motivent. Cela nécessite un engagement à long terme pour des progrès ciblés et progressifs.