- Advertisement -

Architecture logicielle : ce n’est peut-être pas ce que vous pensez que c’est

Recevez des mises à jour en temps réel directement sur votre appareil, abonnez-vous maintenant.

Points clés à retenir

  • L’architecture logicielle doit être arrachée à des comités de personnes déconnectées du développement, et la mettre entre les mains de ceux qui peuvent réellement la rendre réelle et exécutable, les développeurs. Ce n’est qu’alors que nous atteindrons la résilience et la durabilité dont nous avons besoin des applications d’aujourd’hui
  • L’architecture logicielle consiste à capturer des décisions, pas à décrire la structure
  • L’architecture est une compétence que les équipes agiles incarnent, ce qui signifie que l’architecte ne devrait pas être un rôle
  • L’architecture signifie explorer en permanence de nouvelles approches et différentes alternatives pour répondre au mieux aux attributs de qualité
  • L’activité clé de l’architecture consiste à formuler des hypothèses sur la manière dont le système atteindra les objectifs d’attributs de qualité, puis à utiliser l’empirisme pour tester si le système les atteint, puis à répéter cette boucle jusqu’à ce que le système atteigne ses objectifs de qualité.

L’architecture logicielle a une réputation controversée dans la communauté agile. Dans l’expérience de beaucoup, elle est la cause de rencontres sans valeur et de documentations sans pertinence que résume bien l’expression « la carte n’est pas le territoire ». Et pourtant, les applications avec une mauvaise architecture peuvent rapidement devenir comme des véhicules abandonnés au bord de la route, cassés et irréparables. Existe-t-il donc un juste milieu entre ces pôles d’inutilité ?

Une partie du problème est que l’architecture est une métaphore inappropriée pour le résultat du travail d’architecture des systèmes logiciels. Inspiré par le travail des architectes du bâtiment, le mot évoque des images de beaux designs qui font allusion à des futurs utopiques. Mais le travail d’architecture des systèmes logiciels est bien plus dynamique que ne le soutient la métaphore de l’architecture du bâtiment. Les bâtiments sont statiques et le travail des architectes du bâtiment n’est effectué qu’une seule fois. Le logiciel, de par sa nature, est en constante évolution et dynamique ; quand il cesse de changer, il commence à mourir.

Pour mieux comprendre l’architecture logicielle, il faut remonter aux origines du mot architecte : il vient du grec ancien arkitekton, ρχι- (arkhi-, « chef ») +‎ τκτων (téktn, « bâtisseur ”). L’architecture est créée par des gens qui construisent des choses. Ce sens s’est perdu dans le travail des architectes du bâtiment, dont beaucoup n’ont jamais coulé de fondation, encadré un bâtiment ou fait passer des tuyaux de plomberie ou de chauffage. La conception et la construction se sont séparées. Ce n’est pas le cas dans les logiciels, où la façon dont quelque chose est construit influence ce qui est construit, et vice versa.

L’architecture logicielle concerne les décisions, pas la structure

L’analogie du bâtiment a conduit certains architectes logiciels à trop se concentrer sur la structure et les comportements, et non sur les décisions qui produisent ces structures et ces comportements. Ce n’est pas que la structure et le comportement soient sans importance, mais ils sont le résultat d’un processus de réflexion qu’il est important de préserver si le système doit évoluer durablement dans le temps. Savoir pourquoi quelqu’un a fait quelque chose est tout aussi important que savoir ce qu’il a fait. Ce qu’ils ont fait devrait être facile à voir dans le code, s’il est bien organisé et commenté, mais le pourquoi est souvent perdu.

La raison en est que les décisions architecturales dans les logiciels sont rarement claires ; presque chaque décision architecturale est un compromis entre des alternatives concurrentes, et le mérite des alternatives est difficile à voir jusqu’à ce que vous en essayiez quelques-unes et que vous voyiez comment elles fonctionnent. Savoir ce qui a été essayé et rejeté est souvent plus utile que de savoir ce qui a fonctionné. Comme le dit un vieil adage, un bon jugement vient de l’expérience, dont la plupart vient d’un mauvais jugement.

C’est aussi l’une des raisons pour lesquelles les architectes logiciels doivent toujours être des développeurs ; ils ne peuvent pas comprendre ou prédire les forces à l’œuvre dans un système sans développer et tester quelque chose. L’architecte logiciel n’est pas une sorte d’honoraires pour les personnes qui ont pris leur retraite du développement actif mais qui ont encore des connaissances que l’organisation trouve utiles ; ça doit être plus. L’acte d’architecture nécessite une connaissance suffisante d’un système pour formuler des hypothèses utiles sur les attributs de qualité, et l’expertise pour écrire du code et concevoir des tests (ou travailler en étroite collaboration avec les membres de l’équipe qui le peuvent) qui peuvent évaluer ces hypothèses.

L’architecture est une compétence; L’architecte n’est pas un rôle

En vérité, utiliser un titre comme Software Architect envoie un mauvais message sur la nature du travail. La réalité est que de nombreux développeurs de logiciels font du travail d’architecture, mais ils ne le reconnaissent tout simplement pas comme tel. Chaque fois qu’ils prennent des décisions sur la façon de gérer les attributs de qualité, ils affectent l’architecture du système. Être plus conscient de la façon dont les décisions implicites affectent la capacité du système à atteindre les objectifs de qualité est la première étape de l’amélioration de l’architecture du système.

Alors, quel genre de compétences les gens doivent-ils développer pour améliorer la qualité de leur travail architectural ? Il y a un peu:

  • Une concentration accrue sur les attributs de qualité, qui sont les principales exigences transversales auxquelles une bonne architecture doit répondre. Il est facile pour les équipes de se concentrer sur les exigences fonctionnelles, car elles ont tendance à être des choses tangibles, voire visibles, que le système fait pour ses utilisateurs. Mais ce sont les attributs de qualité d’un système qui déterminent sa viabilité à long terme : des éléments tels que l’évolutivité, les performances, la sécurité, la prise en charge et la maintenabilité, pour n’en nommer que quelques-uns.
  • Une capacité à conceptualiser et à résoudre les problèmes à l’échelle du système. Les attributs de qualité sont le plus souvent déterminés par des forces qui affectent l’ensemble du système, pas seulement une partie. Bien que la conception modulaire et la séparation des préoccupations soient importantes pour construire de bons systèmes, elles rendent également plus difficile pour les membres de l’équipe d’avoir une vue globale du système.
  • Compréhension du cycle de vie complet d’un système. Cela nécessite non seulement d’avoir de l’expérience dans le développement d’un système, mais aussi de le tester, de le déployer, de l’exécuter en production, de le maintenir dans le temps et de le moderniser considérablement lorsqu’il doit faire des choses significativement nouvelles. Comprendre le cycle de vie d’un système et comment il réagit au changement est essentiel pour prendre de bonnes décisions qui limitent la dette technique qui, au fil du temps, peut menacer la viabilité d’un système.
  • Une capacité à équilibrer les préoccupations et les compromis. Il y a rarement une seule bonne réponse dans le travail d’architecture. L’architecture implique souvent de faire des compromis entre des exigences d’attributs de qualité (QAR) et des contraintes conflictuelles.
  • Une capacité à apprendre de l’expérience et à synthétiser de nouvelles approches. Cela implique la capacité de prendre les résultats d’essayer des choses d’une manière dirigée (faire des expériences) et de généraliser cet apprentissage sous la forme de principes qui peuvent guider d’autres expériences. Certains de ces principes prennent la forme de « normes », ce qui est un terme quelque peu trompeur, car les normes doivent être constamment testées à l’aide d’expériences pour déterminer quand elles ne sont plus utiles. Nous avons vu de nombreux développeurs frustrés à juste titre par des « normes » organisationnelles qui avaient du sens à un moment donné, mais qui maintenant maintiennent les équipes dans le passé.
  • Une capacité à faire preuve de leadership. La capacité à soulever des préoccupations, à favoriser la discussion de différentes perspectives et à faciliter le consensus aide une équipe à affronter et à surmonter des problèmes architecturaux complexes. N’importe qui dans une équipe peut le faire, et toute personne qui fait de l’architecture doit le faire.

Concevoir signifie explorer en permanence

L’architecture d’applications logicielles modernes est une activité fondamentalement exploratoire. Les équipes qui créent les applications d’aujourd’hui sont confrontées chaque jour à de nouveaux défis : des défis techniques sans précédent ainsi que la fourniture aux clients de nouvelles façons de résoudre des problèmes nouveaux et différents. Cette exploration continue signifie que l’architecture ne peut pas être déterminée à l’avance, sur la base des expériences passées ; les équipes doivent trouver de nouvelles façons de satisfaire aux exigences de qualité.

Comme exemple de la façon dont l’exploration est essentielle pour découvrir l’architecture, considérez ce qui suit : Supposons que vous faites partie d’une équipe travaillant sur un système logiciel conçu à l’origine pour gérer des données tabulaires structurées stockées dans une base de données SQL. Ce système doit maintenant être amélioré pour gérer les données non structurées, y compris les images et les vidéos, et les volumes devraient augmenter considérablement par rapport à ce que le système gère actuellement. Vous envisagez d’ajouter une base de données NoSQL à votre pile technologique pour gérer les nouveaux types de données, mais comme votre équipe n’a pas d’expérience significative avec cette technologie, l’expérimentation est essentielle pour sélectionner le bon produit de base de données et le configurer pour répondre aux nouvelles exigences de volume de données.

Au fur et à mesure que l’équipe travaille sur ces problèmes techniques, elle formule des hypothèses sur les approches qui répondront le mieux aux QAR souhaités, qui sont également des hypothèses et qui changeront avec le temps. Ils construisent une partie de la solution pour tester ces hypothèses, et ils prennent des décisions en fonction des résultats. Le résultat cumulé de ces décisions sur la manière de respecter les QAR est l’architecture du système. L’équipe peut communiquer ces décisions de différentes manières, y compris en utilisant de la documentation et des diagrammes, mais les documents et les diagrammes ne sont pas l’architecture, ce sont les décisions et leur pourquoi qui comptent.

Les informations importantes sur ces décisions incluent des éléments tels que :

  • Le coût de l’annulation d’une décision, si cela s’avérait nécessaire. Si vous devez remplacer un service, un SGBD ou même un framework, il serait utile de savoir combien vous pensez que cela pourrait coûter. Dans certains cas, cela peut signifier réécrire l’application.
  • En articulant clairement toutes les contraintes ou hypothèses. Comprendre les contraintes de travail et les hypothèses que vous avez faites peut aider l’équipe qui devra rénover votre travail à l’avenir. Par exemple, savoir que vous avez supposé que vous n’aurez pas plus de X utilisateurs simultanés, et que cela vous a amené à prendre certaines décisions concernant les threads ou processus simultanés aidera vos futurs collègues à comprendre où ils pourraient avoir besoin de changer quelque chose si cette contrainte est dépassé.
  • Comment vous avez satisfait aux exigences spécifiques d’attribut de qualité (QAR). Pour chaque QAR, vous devez décrire ce que vous avez fait pour vous assurer qu’il sera respecté, et pas seulement en théorie, mais quels tests vous avez exécutés pour le prouver. Lien vers des cas de test spécifiques et leurs tests automatisés associés, de sorte que lorsque les QAR changent, vous pourrez facilement réévaluer la qualité architecturale du système.
  • Quelles sont les options que vous avez considérées comme justification de vos décisions. Savoir ce que vous avez considéré et rejeté est souvent encore plus utile que de savoir ce que vous avez décidé ; il montre votre processus de réflexion et donne un aperçu des contraintes auxquelles vous étiez peut-être confronté lorsque vous avez pris la décision. Si ces contraintes sont supprimées à l’avenir, savoir pourquoi vous avez pris certaines décisions aidera les futurs développeurs à prendre de meilleures décisions.

Figure 1 : Relations entre QAR, décision et dette technique

  • Quelle dette technique vous avez sciemment contractée. Certaines décisions créeront inévitablement et inéluctablement une dette technique ; par exemple, la décision d’atteindre des objectifs de fiabilité en utilisant une base de données SQL a des effets secondaires sur la dette technique (voir Figure 1). Le «problème Y2K» désormais révolu était une décision consciente que les développeurs ont prise à l’époque qui réduisait le stockage des données, l’utilisation de la mémoire et les besoins en temps de traitement en ne stockant pas les données du siècle dans le cadre des représentations de date standard. Le problème était qu’ils ne s’attendaient pas à ce que les applications durent aussi longtemps, longtemps après que ces contraintes soient devenues inutiles. S’ils avaient communiqué leurs décisions et décrit plus précisément l’impact potentiel, il n’y aurait peut-être pas eu une telle bousculade pour réagir à la fin du siècle dernier.

Conclusion

L’architecture logicielle, en tant que discipline, a besoin d’une cure de jouvence. Son image souffre de beaucoup de vieilles idées sur les problèmes qu’elle doit résoudre et sur la manière dont elle devrait s’y prendre pour résoudre ces problèmes. Considérer l’architecture logicielle comme une activité continue axée sur la formation d’hypothèses sur la manière dont le système répondra aux attributs de qualité, puis utiliser l’empirisme pour prouver que le système les satisfait, est l’essence d’une approche continue de l’architecture logicielle. Ce qui doit également changer, c’est d’arracher l’architecture logicielle à des comités de personnes déconnectées du développement, et de la mettre entre les mains de ceux qui peuvent réellement la rendre réelle et exécutable, les développeurs. Ce n’est qu’alors que nous atteindrons la résilience et la durabilité dont nous avons besoin pour les applications d’aujourd’hui.

www.actusduweb.com
Suivez Actusduweb sur Google News


Recevez des mises à jour en temps réel directement sur votre appareil, abonnez-vous maintenant.

commentaires

Ce site utilise des cookies pour améliorer votre expérience. Nous supposerons que cela vous convient, mais vous pouvez vous désinscrire si vous le souhaitez. J'accepte Lire la suite