Points Clés
- Comprendre ce qu'est l'évolutivité architecturale
- Comprendre ce qu'est l'ADR
- Techniques de mise à l'échelle de l'architecture
Avec le passage du temps et l'évolution des technologies, la construction de logiciels est devenue plus rapide, mais plus complexe dans la même proportion. Par conséquent, les outils qui organisent et documentent principalement la prise de décision en matière d'architecture logicielle sont plus que bienvenus. Dans cet article, nous vous présenterons l’Architecture Decision Records (ADR) et comment nous avons adopté ce document chez Zup.
Mais prenons un peu de recul et revenons sur l'agilité et la complexité dans le développement logiciel. Cela est principalement dû à deux facteurs : l'évolution du rôle des logiciels et la nature des logiciels. Ensuite, voyons-les en détail.
L'évolution du rôle du logiciel : le logiciel comme moyen d'atteindre une fin
Aux premiers jours du développement d'applications, des logiciels ont émergé dans le seul et unique but de traiter des données. À cette époque, le matériel était un point de plus grande attention, principalement en raison de son coût et, par conséquent, cela rendait l'utilisation de cette technologie peu accessible.
Avec l'évolution économique et technologique, le logiciel a cessé de traiter uniquement les données et a commencé à jouer un rôle stratégique ; ainsi émergent les systèmes d'information, où ces traitements de données ont commencé à aider aux tâches et à la prise de décision dans les entreprises.
Le matériel n'était plus un facteur déterminant et cela rendait la technologie plus accessible. En parallèle, les changements technologiques et économiques se sont poursuivis et le logiciel a commencé à être utilisé de manière massive et n'est plus le privilège de quelques personnes ; devenir un facteur d'innovation et d'avantage concurrentiel> pour ceux qui l'utilisent.
Ce changement de périmètre et de performance a transformé l'impact du logiciel sur l'entreprise, ce qui a fait de son utilisation une stratégie et un moyen d'atteindre son objectif.
Cette nouvelle vision a changé la façon dont les logiciels sont créés. Ainsi, des méthodologies agiles ont émergé, dans le but d'accélérer et de faciliter les livraisons et les changements lors du développement logiciel. Le besoin était que le développement fonctionne rapidement et de manière cohérente afin que les changements n'affectent pas négativement l'entreprise.
La nature des logiciels : versatilité et évolution
Dans la lignée de tout ce changement de rôle, on peut dire que le logiciel a trois caractéristiques : complexité, éphémère et mutabilité.
-
Complexité : le logiciel n'est pas seulement du code ; il implique la technologie, les personnes, les processus et le métier.
-
Éphémère : les technologies vont et viennent quotidiennement. Une fonctionnalité ou un logiciel entier peut devenir irréalisable/obsolète d'un moment à l'autre, que ce soit en raison d'une technologie obsolète ou d'une vulnérabilité cartographiée, entre autres.
-
Mutabilité : en raison des deux caractéristiques mentionnées ci-dessus, la mutabilité devient essentielle pour que le logiciel continue de fonctionner. Il faut constamment évoluer.
Après tout, qu'est-ce que l'architecture ?
L'une des discussions les plus homériques dans le domaine du génie logiciel est certainement la définition du terme architecture. En résumé sans polémique :
L'architecture est l'organisation, la communication et la structure de tous les logiciels et services d'un domaine, en plus de nourrir la vision technologique.
Modèle décentralisé de réussite !
Au fil du temps, différentes méthodologies ont émergé et ont remplacé les autres. C'est le cas par exemple du Management 3.0 qui condamne le fordisme ou le modèle top-down et valorise un modèle avec plus de participation à travers de six points:
-
dynamiser les gens
-
responsabiliser les équipes
-
aligner les contraintes
-
développement de compétences
-
développer la structure
-
amélioration continue
Le leadership doit contrôler l'environnement, pas les gens. C'est-à-dire fournir toutes les conditions nécessaires pour que les activités soient réalisées de la meilleure façon possible par les individus, et ainsi maximiser les résultats.
Ce mode de leadership n'a pas seulement un sens pour la gestion des personnes, mais aussi pour l'architecture logicielle. Après tout, comment s'assurer que toute la structure fonctionne avec une seule personne qui la contrôle ?
Bien sûr, il n'y a pas de logiciel ou une seule personne capable de garantir une bonne gouvernance. Après tout, il n'y a pas moyen d'échapper à la loi de Conway. En d'autres termes, si l'organisation est désordonnée, cela se reflétera dans le logiciel. Par conséquent, une architecture distribuée doit considérer que l'équipe est bien distribuée et dispose d'une autonomie.
Remplacer "faites-le !" par "est-ce que ça a du sens ?"
Au fil des ans, on a pu percevoir les diverses tentatives d'avoir une seule personne comme professionnel de l'architecture ou une seule entité responsable de l'architecture. Mais, ces approches ont lamentablement échoué, ce qui n'a donné que de bonnes blagues:
-
"architecte ninja" : disparaît à la même vitesse qu'il est apparu
-
"maître des mages": a le titre, mais disparaît aux moments les plus critiques
Il convient toujours de mentionner que le plus grand rôle des professionnels de l'architecture est de choisir les compromis des décisions architecturales, c'est-à-dire que le contexte est la clé de toute décision stratégique au niveau technologique.
Un autre point est le livre "Skin in the game", qui dit que nous avons plus peur de prendre une mauvaise décision quand cela nous impacte aussi. Sans oublier que les logiciels évoluent et s'adaptent constamment, et nous avons appris avec le Manifeste Agile, qu'une bonne décision aujourd'hui peut ne pas être une bonne décision demain.
La solution à cela est une surveillance éternelle de toutes les équipes en tant qu'architectes logiciels. Autrement dit, la responsabilité de l'architecture n'est pas une seule personne externe, mais toute l'équipe, y compris sa maintenance. Erik Dörnenburg le confirme et le rapporte dans sa présentation: Architecture sans professionnels de l'architecture.
Vous devez suivre un modèle décentralisé pour résoudre ce problème. Et aujourd'hui, il est possible d'observer une forte adhésion et avec des résultats positifs, par exemple, dans le livre Software Engineering chez Google il y a une section pour condamner le mythe d'un génie unique.
Si nous nous concentrons sur l'autre extrême, nous échouerons certainement, après tout, si tout le monde peut prendre des décisions, cela peut aboutir à un mélange de solutions avec un haut degré de complexité. Ruth Malan défend cependant le rôle des professionnels de l'architecture en tant que facilitateurs.
Documentation, décentralisation et inspiration : la meilleure adéquation avec l'évolutivité de votre architecture
Il existe un certain nombre d'erreurs et de mythes dans le domaine du génie logiciel et je suis absolument convaincu que le code auto-documenté figure sur cette liste. Nous avons besoin de faire du bon code, fluide et proche du langage ubiquitaire, cependant cela ne nous dispense pas de documenter notre code.
En d'autres termes, il est nécessaire d'appliquer de bonnes pratiques de clean code telles que des noms significatifs, la taille de la méthode, une courbe cyclomatique plus petite, appliquer la conception pilotée par le domaine (DDD), entre autres bonnes pratiques. Ce n'est qu'une partie du travail d'écriture d'un bon code, pas tout.
Il existe plusieurs exemples de bons logiciels qui prêchent l'importance de la documentation, par exemple:
Les grands éditeurs de logiciels comme Red Hat ont des guides sur la façon de documenter leurs logiciels. De plus, il existe des professionnels possédant cette qualification : les rédacteurs techniques.
Aujourd'hui, une bonne documentation logicielle est aussi essentielle que les tests.
La documentation garantit la scalabilité de votre architecture et rend les décisions et leurs fondamentaux clairs pour tous, sans risquer de se perdre dans le temps ou avec le départ d'un membre de l'équipe. Pour l'architecture, cela va au-delà, ce n'est pas seulement la qualité, mais définit où nous en sommes, ce que nous avons mal fait et où nous voulons aller.
Andrew Harmel-Law dans son article sur la scalabilité architecturale, défend une manière de travailler avec l'architecture basée sur quatre principes:
-
Forum consultatif sur l'architecture : un endroit pour tenir des conversations. Cette conversation pourrait être un forum ou une réunion hebdomadaire
-
Enregistrements de décision d'architecture légère (ADR) : un endroit pour stocker les décisions architecturales
-
Team Origin Principles : une inspiration pour unifier les objectifs de l'architecture
-
Votre propre radar technologique : votre pile technologique et des capteurs indiquant la maturité de votre technologie et donc la confiance et la fiabilité de votre équipe pour utiliser cette technologie
Qu'est-ce que les enregistrements de décision d'architecture (ADR) ?
Un point peu mentionné dans ce contexte d'architecture est l'Architecture Decision Records (ADR). C'est un document qui capture les décisions architecturales avec leur contexte et, surtout, leurs conséquences.
Il n'y a pas de norme pour établir ce type de décision. Il est déjà présent dans des langages comme Java, avec les JEP, et dans des spécifications logicielles comme Jakarta, en plus des architectures plus « triviales ».
Quel que soit le format, un bon ADR doit répondre aux exigences suivantes:
-
simple à écrire et à maintenir. Après tout, s'il est difficile à créer/maintenir, l'ADR a tendance à tomber en désuétude ou à devenir obsolète très rapidement
-
consiste en une décision architecturale durable: éviter les efforts répétitifs, être stratégique, réaliste et mesurable
-
soyez clair et objectif sur votre objectif
Structure de base d'un dossier de décision d'architecture et exemple
Par conséquent, un document ADR doit généralement contenir les champs suivants :
-
Titre : quelque chose de déclaratif indiquant son objectif
-
Conseil : commencez par incréments, c'est-à-dire 01 titre, 02 titre, etc
-
Séparez par année, quelque chose qui est facile à rechercher et à trier par ordre chronologique
-
-
Date : le jour du document
-
Statut : l'état de l'ADR, cela peut varier selon l'organisation, pensez à : brouillon, révisé, approuvé ou désapprouvé.
-
Contexte : l'explication du fait et du contexte de manière riche, simple et directe
-
Décision : la conclusion qui a été tirée en fonction du contexte
-
Conséquences : sur la base de ce que nous comprenons de l'architecture, quels sont les compromis de cette action. Il est important d'énumérer toutes les conséquences, après tout, les décisions architecturales sont basées sur l'étude et l'analyse et la mise en évidence d'une étude précédente est très importante
Vous trouverez ci-dessous un exemple simple de la structure d'un dossier de décision d'architecture :
|
1. Enregistrer les décisions d'architecture Date : 21/07/2017 Status Accepté Context Toutes nos décisions, études et plans architecturaux seront documentés à partir d'un ADR. Decision Un modèle simple d'ADR sera utilisé Consequences Toutes nos décisions doivent être écrites, examinées et traduites afin de garantir la clarté, la transparence et l'évolutivité de notre architecture. |
Ce n'est qu'un exemple, ce n'est pas définitif, vous pouvez ajouter et supprimer des champs selon les besoins de votre organisation.
Comment le faisons-nous dans l'Open Source chez Zup?
La décentralisation et la documentation sont les clés des grands cas de réussite et aussi la recommandation des littératures. De la même manière, nous préconisons également une structure décentralisée et orientée vers la documentation dans l'équipe Zup Open Source.
Nous essayons de travailler sur quatre fronts pour assurer une communication fluide avec une plus grande flexibilité, de manière décentralisée et également partagée.
L'évolutivité architecturale vise à s'assurer qu'il n'y a pas de personne ou de point de défaillance unique. La documentation est certainement un moyen de s'en assurer.
-
Tech Radar : nous surveillons les technologies que l'équipe connaît, étudions et définissons les niveaux d'utilisation dans l'organisation
-
Modèle C4 : une carte de l'ensemble de l'architecture, de ses composants et de la manière dont ils s'articulent
-
Dossiers de décision d'architecture : raison mentionnée précédemment
-
Communication active des idéaux et synchronisation : elle peut être synchrone ou asynchrone, toujours basée sur le contexte et privilégiant la voie asynchrone
Comment fait-on les ADR ?
Au sein de l'équipe, il existe une philosophie forte consistant à traiter toutes les choses comme du code, y compris la documentation. Nous avons déjà de l'expérience dans ce domaine et nous travaillons ainsi avec l'équipe de rédaction technique.
Nous avons choisi MADR comme modèle par défaut pour la création d'enregistrements de décision d'architecture.
De plus, nous avons adopté Log4Brains pour la gestion et la visualisation ADRS. Il permet une visualisation historique et transforme les écrits Markdowns en HTML pour l'affichage.
Conclusion
Comme dans le monde du logiciel, une architecture évolutive permet au plus grand nombre de professionnels de l'architecture d'exercer cette activité sans rupture ni changement d'orientation. De plus, cela permet de prendre des décisions avec assurance, en évitant le changement ou l'acceptation aveugle ; quelque chose de récurrent dans les projets dont l'histoire et le contexte ne sont pas correctement cartographiés.
L'assurance que tout le monde va dans la même direction est certainement une bonne documentation.
Au sein de l'équipe Open Source de Zup, nous suivons cette philosophie à travers une communication synchrone ou asynchrone, avec des fonctionnalités très importantes telles que Tech Radar, C4-model et Architecture Decision Records (ADR). Et avec cette transparence, cette attention portée au code, aux tests et à la documentation, nous pensons que la qualité de nos projets continuera à aller vers l'infini et au-delà.
References