Impact de la "Continuous Architecture" sur l’organisation
Préambule
Suite à notre premier article, nous abordons ici les impacts de l’introduction de la continuous architecture dans les organisations.
Pour rappel et en quelques mots, la “Continuous Architecture” consiste à faire évoluer et grandir sans rupture les systèmes informatiques au fur et à mesure des besoins avérés.
Notre formation est désormais en ligne : “Continuous Architecture - Construire et faire évoluer une architecture de manière adaptative et dans une optique produit”
Introduction
Le défi majeur réside dans la construction d'une architecture capable d'évoluer pour apporter des réponses adéquates et efficaces aux évolutions du produit. Ce processus ne vise pas à identifier une solution unique mais à écarter les options inadéquates, favorisant une approche qui n'exige pas nécessairement une uniformité architecturale mais plutôt une adaptabilité et une intégration harmonieuses.
Cette approche impacte les organisations à la fois en terme de compétences nécessaires dans les équipes de développement, de la documentation autour du SI et de l’organisation et l’élaboration des choix d’architecture.
La “Continuous Architecture” consiste à faire évoluer et grandir sans rupture les systèmes informatiques au fur et à mesure des besoins avérés
Impact de la continuous architecture sur l’organisation
Les compétences techniques traditionnelles des Tech Lead s’enrichissent de celles de l’architecte
Sur le terrain des delivery, les Tech Leads (TL) se trouvent souvent confrontés à une confusion entre les décisions de design et d'architecture. Alors que le design est principalement lié à des considérations telles que la lisibilité, la maintenabilité et l'organisation du code, l'architecture s'intéresse davantage à des problèmes de robustesse, de scalabilité, performance. Cette confusion devient particulièrement évidente lors de transitions majeures telles que le passage d'une architecture monolithique à une architecture basée sur des microservices. Les TL se retrouvent ainsi à jongler entre les deux domaines, devant à la fois s'assurer que le code est bien structuré et compréhensible, tout en prenant des décisions architecturales cruciales pour garantir la performance et la fiabilité du système dans son ensemble.
Avant on avait parfois besoin d’un mouton à 5 pattes désormais il en faut 7 ou alors miser sur 2 moutons : un TL et un architecte ;-)
Les compétences techniques du Tech Lead s’enrichissent de celles de l’architecte
Aller vers l’automatisation de la cartographie son SI
Pour maintenir une cartographie applicative et les flux inter applicatifs associés, aujourd'hui, il faut s’y atteler au moins tous les 2 ans. Au niveau d’une petite structure comme une startup, les cartographies sont rendues obsolètes en 1 an à peine. De ce fait, les SI deviennent difficiles à cartographier sans outillage permettant l’automatisation de certains éléments cartographiques.
Ce travail n’étant plus soutenable entièrement manuellement, une automatisation “cartographique” s’impose.
Plus les plateformes évoluent, plus la décentralisation de la cartographie applicative devient nécessaire. Aujourd’hui, les outils d’APM (Elastic apm, Grafana, Datadog, … ) sont une aide précieuse pour la mise à jour des cartographies applicatives, mais ne la remplacent pas.
La cartographie applicative est indispensable car c’est un des rares outils qui aide au dialogue entre les architectes, le métier et les responsables applicatifs. Elle est comprise par l’ensemble de ces parties prenantes et elle aide à comprendre, évaluer les impacts dans le SI.
La cartographie applicative est un des rares outils qui aide au dialogue entre les architectes, le métier et les responsables applicatifs
Complexité et enjeux des choix d’architecture
La prise de décision en matière d'architecture doit être éclairée par une analyse approfondie des implications sur la production, des coûts potentiels de remise en cause des choix, de la complexité des designs applicatifs et des enjeux métier. Ce processus décisionnel itératif implique une collaboration étroite entre les parties prenantes techniques et métier.
- Impact sur la production : Toute décision architecturale doit être évaluée en fonction de son impact sur la production et ce pour limiter les risques. Cela inclut la prise en compte des volumes de données, des performances attendues, de la disponibilité du système, etc.
- Gestion de l’incertitude : Lorsque les hypothèses (métier, …) ne sont pas suffisamment fiables pour prendre une décision d'architecture, le mieux est bien sûr de retarder cette décision. Néanmoins cela n’est pas toujours possible et il peut être nécessaire de devoir prendre une décision pour ne pas bloquer le développement. Dans ces cas, il est essentiel d'estimer les coûts associés à une éventuelle remise en cause de la décision architecturale. Cela comprend non seulement les coûts financiers directs, mais aussi les coûts liés à la perte de temps, de ressources et d'opportunités. Si les conséquences d'une erreur potentielle sont significatives, il peut être préférable de retarder la prise de décision afin de recueillir davantage d'informations ou de mener une analyse approfondie.
- Complexité des designs applicatifs : Introduire une architecture complexe peut rendre le système plus difficile à comprendre, à maintenir et à évoluer. Il est important de peser les avantages potentiels d'une complexité accrue (comme une meilleure performance ou une plus grande extensibilité) par rapport aux inconvénients (comme une augmentation des coûts de développement et de maintenance).
- Enjeux métier : Il est essentiel de comprendre les exigences fonctionnelles et non fonctionnelles du système, ainsi que les contraintes opérationnelles et réglementaires. Une architecture qui répond aux besoins métier actuels et futurs est essentielle pour assurer le succès à long terme du projet.
Complexité, enjeux des choix d’architecture et gestion de l’incertitude
Documenter l'Essentiel : Clé de l'Alignement
Avec l’accélération des changements, les décisions aux mains des équipes autonomes, le turnover dans les équipes, les équipes distribuées en remote…il devient urgent d’aligner ses choix d’architecture en formalisant le dit choix. Cette approche favorise le partage de la connaissance, aide la mise en œuvre opérationnelle en donnant du sens à la solution choisie, facilite les prises de décisions futures.
Mais attention, documenter avec la bonne granularité, c'est-à-dire par exemple les choix d’architecture dans leurs concepts, dans leurs principes et non par exemple dans les choix d’outils ou le comment pour les implémenter avec tel ou tel framework.
Exemples de choix et principes d’architecture à documenter :
- Critères d’un découpage applicatif
- Architecture d’intégration avec un système tiers particulier
- SLAs suivant les types d’interaction
Les choix et principes d’architecture se formalisent dans un document immutable, durable et facilement consultable : l’ADR (Architecture Décision Record).
La production puis le suivi de cette documentation s’inscrit dans les responsabilités des architectes qui, de concert avec les parties prenantes, entérinent les décisions.
Exemples non pertinents à documenter dans un ADR :
- Description de règles métiers, description d’implémentation de règles métier, …
- Description technique d’implémentation de principes dans un outil ou dans un framework en particulier
- Projection de l’architecture sur les infrastructures : découpage en instance, mutualisation d’instances, …
Formaliser ses choix d’architecture dans un document immutable, durable et facilement consultable
Design authority en lieu et place de la tour d’ivoire des architectes
La “design authority” est responsable d’orienter et veiller à l'application des standards d’architecture tout au long des projets. Elle maintient l'ordre et la direction dans le processus de développement, assurant que le produit final est non seulement fonctionnel et efficace, mais aussi sécurisé, maintenable et évolutif.
Pour que les solutions préconisées soient applicables, rien de mieux que de les confronter à la réalité des projets et de les adapter si besoin. La légitimité d’une “design authority” provient de ses membres qui sont impliquées et responsables dans les projets des choix de leur architecture.
Rôle et responsabilités de la “design authority”
- Gouvernance de conception : revues de conception exceptionnelle, revues des architectures proposées
- Coordination entre équipes : sur des composants logiciels différents, elle facilite la coordination et l'intégration de ces composants pour assurer une cohérence globale
- Assurance qualité : s'assure que les logiciels sont développés selon les exigences (pratiques et couverture par des tests, industrialisation des développement,...)
- Responsable (mais pas coupable) des impacts de l’architecture sur les performances en production, de la robustesse des architectures en production, de la bonne communication sur les patterns d’architectures; observabilité, facilités d’appropriation des patterns…
Lors des développements, la “design authority” peut être représentée par un architecte ou un comité d'architecture composé de membres expérimentés. Impliquée dès les premières phases du projet pour définir l'architecture, elle continue à jouer un rôle consultatif tout au long du développement (orientations techniques, conformité avec les directives établies).
La “design authority” est responsable d’orienter et veiller à l'application des standards d’architecture tout au long des projets.
Conclusion
Faire de la “Continuous Architecture” souligne l’importance d'intégrer des compétences d'architecture dans le rôle de Tech Lead et de maintenir une gouvernance efficace à travers une "design authority" pour naviguer au fil des évolutions produit.
En synthèse les impacts sur les organisations:
- Évolution des compétences des Tech Leads : Les Tech Leads sont souvent au croisement du design et de l'architecture. Le design se concentre sur la lisibilité et l'organisation du code, tandis que l'architecture s'attache à la robustesse, la scalabilité et la performance. Cette distinction devient floue, notamment lors du passage d'une architecture monolithique à une architecture de microservices, nécessitant des compétences étendues pour les TL.
- Automatisation de la cartographie du Système d'Information (SI) : La cartographie applicative est essentielle pour le dialogue entre les architectes, les parties prenantes métier et les responsables applicatifs. Cependant, la cartographie manuelle devient insoutenable avec l'évolution rapide des SI. L'automatisation de la cartographie est donc cruciale pour maintenir une vue à jour et pertinente des flux entre les applications.
- Complexité et enjeux des choix architecturaux : Les décisions architecturales doivent être prises en considération de leur impact sur la production, les coûts et la complexité des designs applicatifs. Un processus décisionnel itératif et collaboratif est essentiel pour aligner les choix techniques avec les enjeux métier.
- Documentation et alignement : Documenter les choix architecturaux devient crucial avec l'accélération des changements. La création d'Architecture Decision Records (ADR) aide à formaliser et à partager les décisions prises, facilitant ainsi les décisions futures et l'alignement stratégique.
- Rôle de la design authority : La "design authority" assure la gouvernance de conception, coordonne les équipes sur différents composants logiciels, et garantit la qualité des développements. Elle est responsable de l'impact des choix architecturaux sur les performances en production.
Si tu viens à la formation Continuous Architecture
Si tu es développeur senior, Tech Lead ayant le besoin de monter en compétence sur l’architecture de systèmes et de “systèmes de systèmes” ou si tu es un architecte souhaitant améliorer ses pratiques, lors de la formation tu pourras
- T'approprier les concepts de “continuous architecture”, architecture émergente et intentionnelle
- Identifier le rôle de l’architecte, ses enjeux en termes de communication et d'alignement des parties prenantes
- Élaborer un argumentaire pour communiquer sur les choix d’architectures et leurs impacts “tech” et “non tech”
- Prendre du recul sur ta pratique d’architecte ou de Tech Lead
- Expérimenter l’approche “Continuous Architecture” lors de mises en pratique
- Te familiariser au travers d’exemples concrets sur les problématiques classiques d’architecture, les patterns de solutions associés, ainsi que la manière de les traiter dans le cadre de l’architecture continue
En pratique