Cet article a été rédigé par Veliswa Boya & Jason Nicholls et publié avec autorisation.
Dans son livre « War and Peace and IT », Enterprise Strategist chez AWS Mark Schwartz déclare qu’il est temps que le mur informatique des entreprises tombe. Les anciens modèles commerciaux et les stéréotypes ont longtemps opposé les «costumes» aux «nerds». Il poursuit en disant qu’il est temps de favoriser un espace de collaboration et une mission partagée – un espace qui met les technologues et les hommes d’affaires dans la même équipe.
La question est : comment assurer le succès de cette collaboration alors que les deux ne parlent même pas la même langue ? Souvent, les professionnels commerciaux et techniques ne comprennent pas la terminologie des autres. Chaque discipline peut avoir un sens différent pour les mêmes mots.
Dans cette lecture, nous examinerons comment vous, en tant que technologue – ici spécifiquement en référence à vous, l’architecte – pouvez écouter et comprendre vos principales parties prenantes et collaborer avec elles pour comprendre ce qui est le plus important. Nous discuterons de la façon de décoder une partie du « parler » de l’entreprise dans une langue que vous pouvez comprendre, vous aidant ainsi à comprendre ce qui est requis par l’entreprise.
Nous examinerons également comment le cadre AWS Well-Architected peut ensuite aider à déterminer les considérations architecturales les plus importantes pour finalement une application bien architecturée qui répond aux exigences de l’entreprise.
Exigences commerciales mal comprises (préoccupations de domaine) coûtent cher. Ce qui peut commencer comme une remarque d’une entreprise peut finir par être implémenté dans le logiciel qui entre en production.
Combien d’entre nous ont construit une solution qui s’est avérée ne pas être ce que le client voulait, tout cela parce que nous n’avions pas compris l’exigence en premier lieu ? C’est peut-être à cause des délais serrés, mais nous n’avons pas passé de temps à comprendre quelles sont réellement les exigences !
Des exigences commerciales mal comprises entraînent ce qui suit :
- Construire le mauvais produit
- Perdre du temps et de l’argent à construire selon un cahier des charges mal compris
- Des problèmes de sécurité
- Retards de livraison
- Ne pas répondre aux attentes, ce qui entraîne une perte de confiance
Tout d’abord, les attentes fondamentales d’un architecte
Plus tôt, nous avons parlé des architectes qui écoutent les principales parties prenantes et comprennent leurs exigences. Qu’attend-on d’autre d’un architecte ?
Nous ne définirons pas le rôle d’un architecte, car cela peut être difficile à faire. Nous allons cependant nous concentrer sur 8 attentes fondamentales d’un architecte.
Dans leur livre « Fundamentals of Software Architecture : An Engineering Approach », les co-auteurs Mark Richard et Neal Ford recommandent que nous nous concentrions sur les attentes suivantes en ce qui concerne le rôle d’un architecte :
- Comprendre et naviguer en politique
- Posséder des qualités relationnelles
- Avoir une expérience dans le domaine métier
- Exposition et expérience diversifiées
- Veiller au respect des décisions
- Tenez-vous au courant des dernières tendances
- Analyser en continu l’architecture
- Prendre des décisions d’architecture
Caractéristiques architecturales
Les caractéristiques de l’architecture sont des préoccupations essentielles au succès de l’architecture, et donc essentielles au succès du système dans son ensemble. Lors de la définition des exigences métier, l’entreprise spécifiera les fonctionnalités du domaine – communément appelées « exigences fonctionnelles » – ainsi que les caractéristiques de l’architecture.
Les exigences fonctionnelles, pour la plupart, ont tendance à être claires car elles définissent ce que l’application doit faire >> la logique métier. Ils influencent certains aspects structurels de l’architecture et sont essentiels au succès de l’application. Les caractéristiques de l’architecture sont là où le malentendu a tendance à apparaître.
Il existe de nombreuses autres caractéristiques d’architecture : il n’y a pas de liste fixe, mais il existe une norme ISO 25000.
Les caractéristiques architecturales ne sont pas fonctionnelles. Les caractéristiques de l’architecture peuvent être explicites (exprimées dans la doc des exigences) ou implicites (non exprimées) et nous nous concentrerons sur les caractéristiques ci-dessous pour la suite du poste :
- Auditabilité
- Évolutivité
- Disponibilité
- Performance
- Sécurité
- Légalité
En fait, il existe un alignement entre les caractéristiques de l’architecture et les piliers du cadre AWS Well-Architected – mais nous en reparlerons plus tard.
Comment traduisons-nous les préoccupations du domaine en caractéristiques architecturales ?
« Les architectes doivent s’entraîner à être des architectes, tout comme les développeurs ont besoin d’une chance de s’entraîner à être des développeurs. »
Ted Neward, qui a lancé Architectural Katas, a eu l’idée que les architectes ont autant besoin de pratique que les développeurs ont besoin de pratique – et c’est ainsi que les Architectural Katas ont été lancés, inspirés par les Code Katas !
Et qu’est-ce qu’un kata ? L’idée vient des arts martiaux/karaté. Un kata est un exercice de karaté où vous répétez une forme plusieurs fois, en faisant de petites améliorations à chaque fois.
Qui connaît le tristement célèbre kata du code FizzBuzz ? Il existe un projet GitHub qui a rassemblé une liste de quelques exercices de kata que l’on trouve sur Internet et la communauté GitHub.
L’idée avec le Code Kata et l’Architecture Kata est de créer un environnement sûr pour pratiquer et échouer encore et encore, apprendre et acquérir de l’expérience.
Les katas d’architecture ne sont pas conçus pour vous proposer une architecture parfaite, mais pour vous former à trouver des solutions – et vous fournir un espace pour échouer.
Katas architecturaux
Les katas sont essentiellement des exercices de groupe où vous travaillez avec des pairs (dans ce cas, votre équipe de projet) pour arriver à la meilleure architecture possible – vous obtenez des commentaires les uns des autres, itérez et améliorez l’architecture initiale à chaque itération.
L’équipe de projet se réunit pendant un certain temps et découvre des exigences qui ne figurent pas dans la proposition d’origine en posant des questions au « client », qui est généralement le modérateur lors d’un kata d’architecture. C’est à cette phase que les exigences implicites sont découvertes, et pour toute autre question qui n’est pas déjà couverte par les exigences, vous pouvez demander au modérateur.
Les phases qui font partie d’un kata architectural sont :
- Phase de préparation
- Phase de discussion
- Phase d’examen par les pairs
- Phase de vote
Préparer
Pendant la phase de préparation, l’équipe du projet est constituée, généralement par le modérateur qui sera également un facilitateur du kata. Le modérateur est le client ou toute personne la mieux placée pour répondre aux questions que l’équipe du projet aura.
Discuter
Au cours de cette phase, l’équipe du projet détermine ce qu’elle va construire. L’équipe examine les exigences pour le kata telles qu’elles sont données et élabore une vision approximative de ce à quoi ressemblera l’architecture du projet.
L’équipe va demande à Modérez toutes les questions que vous avez sur le projet. Il convient également de noter qu’à ce stade, toute technologie est un jeu équitable comme les clients ont tendance à ne pas vraiment se soucier, la plupart du temps, du type de technologie utilisé. Il n’est donc pas nécessaire, durant cette phase, de trop se focaliser sur la technologie qui sera utilisée pour construire l’application.
Examen par les pairs
Au cours de cette phase, l’équipe projet présentera l’architecture menée par l’architecte. C’est également à cette phase que toutes les questions du reste de l’équipe du projet (en particulier le client) seront répondues.
Vote
Enfin, toute l’équipe vote pour l’architecture qui vient d’être présentée, et ce vote déterminera s’il y a une autre itération ou non.
Identification des caractéristiques de l’architecture
Quelles caractéristiques architecturales pouvez-vous en tirer — sur la base de ces exigences ? Que pouvez-vous en déduire en ce qui concerne la disponibilité, la sécurité et les performances du système ?
Chaque partie de l’exigence peut contribuer à un ou plusieurs aspects de l’architecture (et aucune peut ne pas l’être). Ici, l’architecte recherchera les facteurs qui influencent ou ont un impact sur la conception, en particulier les facteurs structurels.
Tout d’abord, séparez les caractéristiques de l’architecture candidate en caractéristiques explicites et implicites. L’un des premiers détails qui devrait attirer l’attention de l’architecte est le nombre d’utilisateurs — actuellement des milliers, et peut-être un jour, des millions ! Cela signifie que nous devons concevoir pour évolutivité afin de pouvoir gérer un grand nombre d’utilisateurs simultanés sans dégradation grave des performances. Ce sera l’une des principales caractéristiques architecturales. Notez que l’énoncé du problème ne demandait pas explicitement l’évolutivité, mais exprimait plutôt l’exigence sous la forme d’un nombre attendu d’utilisateurs.
Ceci est un exemple d’architectes décodant le langage du domaine (exigences métier) en équivalents d’ingénierie !
Il y a beaucoup d’autres caractéristiques ici : pouvez-vous identifier élasticité ou la capacité de gérer des rafales de clients pendant les promotions et les offres spéciales ?
Cadre AWS bien architecturé
Plus tôt, nous avons expliqué comment la plupart des caractéristiques de l’architecture s’alignent sur les piliers du cadre AWS Well-Architected.
Une fois que vous avez itéré pour arriver aux caractéristiques de l’architecture et que vous avez conçu l’architecture, vous devez ensuite la soumettre à l’examen du cadre bien architecturé pour vous assurer qu’il correspond aux caractéristiques de l’architecture que vous avez découvertes lors de l’itération au cours de l’architecture Kata.
Nous allons maintenant approfondir cela et voir comment, puis examiner pourquoi nous accordons une attention particulière à cet alignement.
Le cadre AWS Well-Architected aide les architectes cloud à créer une infrastructure sécurisée, performante, résiliente et efficace pour une variété d’applications et de charges de travail. Construit autour de six piliers – excellence opérationnelle, sécurité, fiabilité, efficacité des performances, optimisation des coûts et durabilité – AWS Well-Architected fournit une approche cohérente aux clients et partenaires pour évaluer les architectures et mettre en œuvre des conceptions évolutives.
Le cadre AWS Well-Architected décrit les concepts clés, les principes de conception et les meilleures pratiques architecturales pour la conception et l’exécution des charges de travail dans le cloud. En répondant à quelques questions fondamentales, découvrez dans quelle mesure votre architecture s’aligne sur les meilleures pratiques cloud et obtenez des conseils pour apporter des améliorations.
L’AWS…