Prise de décision architecturale : équilibrer les compromis avec les données du monde réel

La prise de décision architecturale est l'un des aspects les plus critiques du développement logiciel et de la conception du système. L'architecture ne consiste pas à poursuivre la conception parfaite; elle consiste à prendre des décisions intentionnelles sous des contraintes réelles : temps, coût, clarté, échelle. Dans le paysage technologique complexe d'aujourd'hui, les architectes doivent naviguer sur un réseau complexe de priorités concurrentes tout en assurant que leurs systèmes restent robustes, évolutives et durables.

L'architecture logicielle, comme la vie, consiste en une série de décisions de compromis prises avec des informations incomplètes et souvent sous une pression temporelle énorme. Cette réalité souligne l'importance de tirer parti des preuves empiriques pour guider les choix architecturaux. En intégrant les données du monde réel dans le processus décisionnel, les architectes peuvent mieux comprendre le comportement du système, valider les hypothèses et faire des compromis éclairés qui s'harmonisent avec les objectifs commerciaux et les exigences techniques.

La nature fondamentale des compromis architecturaux

C'est la première loi de l'architecte logiciel selon Mark Richards et Neal Ford, dans leur livre "Fundamentals of Software Architecture". Le concept que "tout dans l'architecture logicielle est un compromis" représente une vérité fondamentale que chaque architecte doit internaliser. Un système logiciel doit répondre à de multiples exigences concurrentes: performance, évolutivité, maintien, sécurité, coût, et complexité.

Comprendre les attributs de qualité et leurs conflits

Les attributs de qualité sont constamment en conflit les uns avec les autres. Vous voulez de meilleures performances ? Vous attendez une maintenance réduite. Besoin d'une cohérence solide ? Acceptez une disponibilité réduite. Ces tensions se manifestent dans pratiquement toutes les décisions architecturales, du choix entre architectures monolithiques et microservices à la sélection des technologies de base de données ou à la conception d'interfaces API.

Considérez l'exemple classique des stratégies de cache. La mise en cache locale des données peut améliorer le temps de réponse en éliminant l'accès à distance aux données sur un réseau, mais elle peut aussi réduire la concordance si les caches deviennent obsolètes et réduire les performances si les caches locaux doivent être fréquemment rafraîchis. Ceci illustre comment une décision architecturale unique peut avoir des effets en cascade sur plusieurs attributs de qualité, ce qui rend essentiel de comprendre l'ensemble des implications avant de s'engager dans une approche particulière.

La nature contextuelle des décisions architecturales

La conception optimale dépend entièrement de votre contexte, contraintes et priorités commerciales spécifiques. Ce qui fonctionne brillamment pour une organisation peut se révéler désastreux pour une autre. Une plate-forme de trading à haute fréquence nécessite une latence microseconde et peut justifier des optimisations complexes, tandis qu'un système de gestion de contenu peut prioriser la productivité et la maintenance du développeur sur les performances brutes.

Une décision d'échange technique dépend du contexte, et le choix de ces critères les plus importants pour votre solution vous permet de saisir et de décrire. Les capacités techniques dépendent de ce qui est construit ou doit être construit, de la disponibilité de l'équipe, du contexte du marché, de l'appétit pour le risque, du budget, etc. Cette sensibilité au contexte signifie que les architectes doivent développer une compréhension approfondie des circonstances uniques de leur organisation, y compris les capacités techniques, la structure de l'équipe, les objectifs commerciaux et les contraintes opérationnelles.

Scénarios communs de compensation architecturale

Les systèmes de haute performance nécessitent souvent des optimisations complexes qui rendent le code plus difficile à comprendre et à modifier. L'optimisation des requêtes de base de données fournit un exemple clair : des requêtes simples et lisibles peuvent scanner des tables entières, tandis que les versions performantes utilisent des jointures complexes, des sous-requêtes et des conseils spécifiques à la base de données qui nécessitent des développeurs expérimentés pour déboguer.

Un autre compromis commun concerne la sélection de style architectural. Les microservices peuvent améliorer la maintenance en créant des frontières claires entre les équipes et les services. Mais ils introduisent des frais de rendement provenant des appels réseau, de la sérialisation et de la découverte de services.

La réduction des coûts d'infrastructure et de développement est essentielle, notamment aux premières étapes d'un projet. L'opting pour une architecture monolithique simple peut être un choix rentable, car il est plus rapide à développer et plus facile à maintenir à court terme. Avec moins de composants et moins de complexité, les systèmes monolithiques ont généralement besoin de moins de ressources pour se mettre en place et gérer.

Le rôle critique des données du monde réel dans les décisions architecturales

La prise de décision axée sur les données (DDDM) est un processus qui permet d'utiliser l'analyse et l'interprétation des données pour guider la prise de décision organisationnelle. En se fondant sur les données plutôt que sur l'intuition ou l'expérience personnelle, les organisations peuvent faire des choix plus éclairés, objectifs et efficaces.

Dépasser les hypothèses et les idées

La prise de décision en architecture fondée sur les données implique l'utilisation de données empiriques pour guider le processus de conception. Cette approche contraste avec les méthodes traditionnelles qui reposent fortement sur l'intuition, l'expérience et les préférences esthétiques.

Les approches d'EE traditionnelles, manuelles, basées sur l'intuition, la documentation dispersée ou les inventaires périmés, ne peuvent tout simplement pas fournir la précision, la visibilité ou l'agilité nécessaires à la prise de décision moderne.

Aucune analyse pure n'est suffisante pour évaluer les décisions de compromis; la rétroaction du monde réel est la seule façon de savoir si le compromis est acceptable. Ce principe met en évidence la nature itérative de la prise de décision architecturale, où les choix initiaux doivent être validés par rapport à la performance réelle du système et au comportement des utilisateurs.

Établir une source unique de vérité

En utilisant les dépôts d'architecture comme source centrale de vérité, les organisations acquièrent des connaissances fiables sur leurs applications, leurs processus, leurs technologies, leurs capacités et leurs dépendances, ce qui permet de définir des priorités plus claires, de réduire l'incertitude et de construire des feuilles de route prêtes à l'avenir, fondées sur des preuves réelles, et non des hypothèses.

Une approche d'EE axée sur les données élimine l'incertitude en donnant aux organisations une compréhension factuelle et définitive de leur paysage actuel et des options futures. Lorsque les données architecturales sont recueillies, connectées et analysées systématiquement, les équipes peuvent : Spot inefficiences et redondances dans les applications, Aligner les décisions avec des objectifs stratégiques, avec des preuves mesurables. Comprendre l'impact réel des changements, au lieu de se fier à des hypothèses.

Les avantages des décisions architecturales d'origine data

L'architecture axée sur les données est un paradigme émergent de la conception des systèmes qui privilégie les données comme élément de base dans la conception des applications et des services. En tirant parti de l'analyse des données et des renseignements en temps réel, les organisations peuvent prendre des décisions éclairées, optimiser les performances et améliorer l'expérience des utilisateurs.

Les organisations peuvent obtenir une meilleure précision dans la prédiction du comportement du système, une meilleure alignement entre les décisions techniques et les objectifs opérationnels, et une réduction des risques grâce à la validation fondée sur des données probantes. Les approches fondées sur les données permettent également une amélioration continue en fournissant des boucles de rétroaction qui informent les améliorations itératives aux choix architecturaux.

Ce sont là toutes les décisions qui profitent des données empiriques que les données offrent. Que ce soit l'évaluation des choix technologiques, l'évaluation des exigences d'évolutivité ou l'optimisation du rendement du système, les données du monde réel constituent la base pour prendre des décisions éclairées qui équilibrent efficacement les priorités concurrentes.

Cadres et méthodes d'évaluation des compromis architecturaux

Les cadres structurés offrent des approches systématiques pour évaluer les décisions architecturales et en comprendre les répercussions.Ces méthodologies aident les équipes à naviguer dans la complexité, à communiquer des compromis aux intervenants et à documenter les raisons qui sous-tendent les choix architecturaux.

Méthode d'analyse des compromis d'architecture (ATAM)

La méthode d'analyse des compromis d'architecture est une technique rigoureuse fondée sur des scénarios pour évaluer les architectures logicielles, qui met l'accent sur la façon dont les décisions architecturales affectent la capacité d'un système à répondre aux objectifs opérationnels et aux exigences en matière d'attributs de qualité.

En ingénierie logicielle, Architecture Tradeoff Analysis Method (ATAM) est un processus d'atténuation des risques utilisé au début du cycle de vie du développement logiciel. ATAM a été développé par l'Institut d'ingénierie logicielle de l'Université Carnegie Mellon. Son but est d'aider à choisir une architecture appropriée pour un système logiciel en découvrant des compromis et des points de sensibilité.

Le processus ATAM comporte plusieurs étapes clés qui guident les équipes par une évaluation systématique des options architecturales. Le processus ATAM consiste à rassembler les intervenants pour analyser les moteurs d'affaires (fonctionnalité du système, objectifs, contraintes, propriétés non fonctionnelles souhaitées) et de ces moteurs extraire des attributs de qualité qui sont utilisés pour créer des scénarios. Ces scénarios servent ensuite de base pour évaluer la manière dont les différentes approches architecturales satisfont les exigences du système.

ATAM fait progresser SAAM en évaluant plusieurs attributs de qualité pour comprendre les compromis inhérents à l'architecture logicielle, découvrir les exigences implicites et révéler à quel point une architecture satisfait à des attributs de qualité particuliers.Cette capacité d'évaluation multi-attributs rend ATAM particulièrement utile pour les systèmes complexes où les préoccupations de qualité multiple doivent être équilibrées.

Arbres d'utilité de qualité

Générer un arbre d'utilité d'attribut qualité – définir les exigences opérationnelles et techniques fondamentales du système, et les cartographier à une propriété architecturale appropriée. Présenter un scénario pour cette exigence donnée. Les arbres d'utilité d'attribut qualité fournissent une façon structurée d'organiser et de prioriser les diverses préoccupations de qualité qui influencent les décisions architecturales.

Ces arbres aident les équipes à formuler des scénarios précis et mesurables qui représentent la façon dont le système doit se comporter dans différentes conditions. Par exemple, un scénario de performance pourrait préciser que le système doit répondre aux demandes des utilisateurs dans un délai de 200 millisecondes dans des conditions de charge normales.

Cadres de hiérarchisation et de notation

Un cadre simple qui a bien fonctionné pour moi pour toutes sortes de décisions techniques consiste à hiérarchiser un ensemble de critères et à leur présenter les solutions possibles en plusieurs niveaux, ce qui implique de définir les critères les plus importants pour un contexte de décision particulier et d'évaluer ensuite chaque solution potentielle par rapport à ces critères.

Le concept économique de l'Utilitaire est souvent utilisé – en marquant chaque caractéristique sur 10 pour chaque architecture. Les cadres de notation fournissent une base quantitative pour comparer les alternatives architecturales, bien qu'ils devraient être utilisés judicieusement pour éviter une fausse précision. L'objectif n'est pas de réduire les décisions complexes à des nombres simples mais de faciliter la discussion structurée et de veiller à ce que tous les facteurs pertinents soient pris en considération.

L'adoption d'un modèle de qualité standard aide une équipe d'architecture à amener ses intervenants à comprendre comment penser aux compromis en architecture. Il devient un langage commun que les propriétaires d'entreprises, les développeurs, les utilisateurs, les gestionnaires de projets et, bien sûr, les architectes, peuvent partager lorsqu'ils envisagent de changer.

Modèle de qualité ISO 25010

ISO 25010 contient un tel modèle de qualité. Il divise la qualité du système et du logiciel en huit caractéristiques, telles que la sécurité, la fiabilité et la qualité fonctionnelle. Ces caractéristiques sont ensuite subdivisées en trente et un sous-caractéristiques. Ce cadre normalisé couvre de façon exhaustive les préoccupations en matière de qualité et permet de s'assurer que les aspects importants de la qualité du système ne sont pas négligés lors de l'évaluation architecturale.

Le modèle offre un langage commun qui donne une vue à 360 degrés de la qualité du système, parfait pour explorer les aspects de la qualité qui varieront selon les architectures. En utilisant des modèles de qualité établis, les équipes peuvent bénéficier des meilleures pratiques de l'industrie et s'assurer que leurs évaluations architecturales tiennent compte de l'ensemble des attributs de qualité.

Méthodes d'incorporation des données du monde réel dans les décisions architecturales

Pour tirer parti efficacement des données du monde réel, il faut adopter des méthodes systématiques de collecte, d'analyse et d'interprétation des données, et établir des processus et des outils qui permettent de recueillir des commentaires continus des systèmes de production et de les traduire en éléments architecturaux concrets.

Surveillance et observation du rendement

En instrumentant des systèmes de collecte de données sur les temps de réponse, le débit, l'utilisation des ressources et les taux d'erreur, les équipes acquièrent une visibilité sur la façon dont leurs architectures fonctionnent dans des conditions réelles. Les pratiques modernes d'observation vont au-delà des mesures simples pour inclure le traçage distribué, l'enregistrement structuré et l'analyse en temps réel.

Les sondages et la rétroaction des utilisateurs peuvent fournir des renseignements précieux sur le comportement et les préférences des occupants. L'analyse spatiale et les SIG peuvent être utilisés pour analyser les données sur les modèles urbains, les systèmes de transport et les facteurs environnementaux. Les systèmes de gestion des bâtiments (SGB) peuvent fournir des données sur les performances des bâtiments, y compris l'utilisation de l'énergie, la consommation d'eau et les performances des systèmes CVC. Bien que ces exemples proviennent de l'architecture physique, les principes s'appliquent également aux systèmes logiciels, où divers outils de surveillance et instruments permettent de connaître le comportement des systèmes.

Les équipes devraient se concentrer sur les mesures qui se rapportent directement aux attributs de qualité et aux objectifs opérationnels, en évitant de recueillir de vastes quantités de données sans avoir de but clair. Les indicateurs de rendement clés devraient être établis sur la base de scénarios d'attributs de qualité, ce qui permettra de vérifier directement si les décisions architecturales atteignent les résultats escomptés.

Commentaires des utilisateurs et analyse de l'utilisation

L'analyse de l'utilisation révèle des modèles de comportement des utilisateurs, d'adoption de fonctionnalités et d'efficacité du workflow qui ne sont pas nécessairement apparents des seuls paramètres techniques. Cette information aide les architectes à comprendre quelles parties du système connaissent le plus de charge, quelles caractéristiques nécessitent une optimisation et où les investissements architecturaux offriront la plus grande valeur.

L'analyse des flux de piétons peut révéler comment les gens se déplacent (ou se déplaceront) dans un bâtiment ou un paysage, guider les décisions de conception et les modifications pour améliorer l'expérience des visiteurs tout en préservant le caractère du lieu. De même, l'analyse des flux d'utilisateurs par le biais des applications logicielles aide les architectes à identifier les goulots d'étranglement, à optimiser les chemins critiques et à s'assurer que les décisions architecturales soutiennent les modes d'utilisation réels plutôt que supposés.

Les mécanismes de rétroaction des utilisateurs devraient être intégrés dès le début aux systèmes, ce qui permettrait de recueillir en permanence des données qualitatives et quantitatives sur les expériences des utilisateurs, notamment des instruments permettant de suivre l'utilisation des fonctions, des cadres d'essai A/B pour évaluer les solutions de rechange architecturales et des canaux de rétroaction qui permettent aux utilisateurs de signaler les problèmes ou de suggérer des améliorations.

L'analyse comparative par rapport aux normes industrielles

L'analyse comparative fournit un contexte pour évaluer le rendement du système en le comparant aux normes de l'industrie, aux systèmes concurrents ou aux pratiques exemplaires établies.

Pour être efficaces, il faut choisir soigneusement les points de comparaison qui sont pertinents au contexte du système. Les points de repère génériques ne reflètent peut-être pas les caractéristiques uniques d'un domaine d'application particulier, de sorte que les équipes devraient rechercher des points de repère spécifiques à un domaine ou établir leurs propres mesures de référence.

Les organismes de normalisation et les organisations professionnelles publient souvent des architectures de référence, des modèles de conception et des repères d'attributs de qualité qui représentent la sagesse collective de l'industrie. La mise à profit de ces ressources aide les équipes à éviter de réinventer des solutions à des problèmes communs et à s'assurer que leurs décisions architecturales s'harmonisent avec les pratiques éprouvées.

Simulation et essais de scénarios

Au lieu de faire des hypothèses, testez les implémentations à petite échelle de différentes approches. Les simulations et les tests de scénarios permettent aux équipes d'évaluer les alternatives architecturales avant de s'engager dans la mise en oeuvre complète.

Cette approche expérimentale de l'architecture traite les décisions comme des hypothèses à valider plutôt que des engagements fixés dans la pierre. Les équipes peuvent utiliser des techniques comme les implémentations de validation de concepts, les tests de charge, l'ingénierie du chaos et la modélisation de performance pour recueillir des données sur les alternatives architecturales.

Les tests de scénarios consistent à définir des conditions spécifiques ou des cas d'utilisation et à évaluer comment différentes approches architecturales les gèrent. Cela pourrait inclure des tests de comportement du système sous charge maximale, l'évaluation de la récupération des défaillances ou l'évaluation de l'impact de l'ajout de nouvelles fonctionnalités.

Boucles de rétroaction continue

La prise de décision architecturale ne devrait pas être une activité ponctuelle, mais plutôt un processus continu, qui repose sur la rétroaction continue des systèmes de production. L'établissement de boucles de rétroaction qui relient les données opérationnelles aux décisions architecturales permet aux équipes de valider leurs choix, de cerner les nouveaux enjeux et d'adapter les architectures au fur et à mesure que les besoins évoluent.

L'architecture axée sur les données consiste à concevoir et à organiser des systèmes, des applications et des infrastructures, en mettant l'accent sur les données en tant qu'élément central.Dans ce cadre architectural, les décisions concernant la conception, l'évolutivité, les processus et les interactions des systèmes sont guidées par des connaissances et des exigences découlant des données.

Les tableaux de bord qui affichent les paramètres clés, les systèmes d'alerte qui avisent les équipes des anomalies, et les plateformes d'analyse qui permettent une enquête approfondie sur le comportement du système contribuent tous à créer des boucles de rétroaction actionnables. L'objectif est de minimiser le temps entre le comportement du système d'observation et l'intégration de ces observations dans les décisions architecturales.

Documenter les décisions architecturales avec les EIM

Pour pouvoir retracer ces décisions, j'ai commencé à utiliser les documents de décision architecturale (ADR) qui ont été précieux pour suivre les raisons de certains choix et les revoir à mesure que le contexte évolue. Les documents de décision architecturale constituent un mécanisme léger mais puissant pour documenter les raisons des choix architecturaux, y compris les compromis pris en considération et les données qui ont éclairé la décision.

Structure et objet des ADR

Un dossier de décision architecturale comprend généralement plusieurs éléments clés : le contexte dans lequel la décision a été prise, la décision elle-même, les solutions de rechange envisagées, les conséquences de la décision et la justification du choix d'une option par rapport aux autres.

Documenter et justifier les décisions d'alignement des équipes et des intervenants.Les MARC servent à plusieurs fins, au-delà de la simple documentation.Ils facilitent la communication entre les membres de l'équipe, aident les nouveaux développeurs en expliquant pourquoi le système est structuré tel quel et fournissent un dossier historique qui peut éclairer les décisions futures.

Contrairement à la documentation sur les poids lourds qui exige des efforts importants pour les maintenir, les MARC se concentrent sur la saisie des renseignements essentiels dans un format concis, ce qui permet d'accroître la probabilité que les équipes créent et tiennent des dossiers décisionnels.

Incorporation de données dans les EIM

Lorsqu'on documente les décisions architecturales, y compris les données du monde réel qui ont éclairé le choix, on renforce le dossier et on fournit des preuves de la validité de la décision, notamment des repères de performance, des statistiques d'utilisation, des analyses de coûts ou des résultats de tests prototypes.

Les EIM enrichis en données facilitent également l'analyse rétrospective. Lorsque les équipes doivent comprendre pourquoi une décision architecturale particulière a été prise, avoir accès aux données qui ont éclairé le choix fournit un contexte précieux. Ceci est particulièrement important lorsque les circonstances changent et les décisions doivent être réexaminées. Les données originales aident les équipes à comprendre quelles hypothèses étaient valides à l'époque et comment les conditions actuelles diffèrent.

Les MARC devraient aussi documenter les compromis explicitement pris en considération au cours du processus décisionnel, notamment les attributs de qualité qui ont été classés par ordre de priorité, les solutions de rechange qui ont été rejetées et les raisons pour lesquelles, ainsi que les limitations ou les risques connus associés à l'approche choisie, cette vision globale aide les intervenants à comprendre non seulement ce qui a été décidé, mais aussi pourquoi c'était le meilleur choix compte tenu des contraintes et des priorités à l'époque.

Évolution des EIM au fil du temps

Les décisions architecturales ne sont pas immuables. À mesure que les systèmes évoluent, les exigences changent et les nouvelles technologies apparaissent, il faudra peut-être revoir les décisions qui étaient optimales à un moment donné. Les MARC appuient cette évolution en fournissant un relevé clair de ce qui a été décidé et pourquoi, ce qui facilite l'identification des circonstances suffisamment modifiées pour justifier un réexamen.

Lorsque les décisions architecturales sont remplacées, l'ADR original devrait être mis à jour pour refléter ce changement plutôt que supprimé. Cela préserve le contexte historique et aide les équipes à comprendre l'évolution de l'architecture au fil du temps.

Stratégies pratiques pour équilibrer les compromis

Pour réussir à équilibrer les compromis architecturaux, il faut plus que des cadres et des données, ce qui exige des stratégies pratiques que les équipes peuvent appliquer dans des situations réelles.Ces stratégies aident à naviguer dans la complexité des priorités concurrentes et à s'assurer que les décisions architecturales s'harmonisent avec les exigences techniques et les objectifs opérationnels.

Commencez par les moteurs d'affaires et les attributs de qualité

Comprendre les priorités fondamentales de votre système : - Performance -Scalabilité -Maintenabilité -Sécurité -Coefficient Avant de plonger dans les détails techniques, les équipes doivent comprendre clairement ce que le système doit réaliser dans une perspective d'affaires.

Ce ne sont pas des règles, mais des leçons qui ont été façonnées par l'expérience - et elles m'ont aidé à naviguer dans la tension entre le design idéal et les contraintes du monde réel : que essayons-nous de réaliser au cours des 6 à 12 prochains mois ?

Un système de négociation financière pourrait privilégier les performances et la cohérence, tandis qu'un système de gestion du contenu pourrait mettre l'accent sur la maintenance et l'extensibilité. La compréhension de ces priorités constitue à l'origine le fondement de compromis éclairés tout au long du processus architectural.

Architecture itérative d'adhésion

Une équipe peut d'abord choisir de concevoir quelques gros composants et les exécuter dans le même serveur cloud pour simplifier le développement et le déploiement et faciliter l'obtention de leur première version pour les clients. Ils soupçonnent que cela ne va pas bien à l'échelle, mais ils n'ont pas besoin d'échelle dans la première version; ils doivent savoir si le système est attrayant pour sa communauté d'utilisateurs potentiels.

Cet exemple illustre la puissance de l'architecture itérative, où les décisions initiales optimisent l'apprentissage et la vitesse de mise en marché plutôt que d'essayer d'anticiper toutes les exigences futures. Construire pour l'échelle que vous n'avez pas encore est coûteux et souvent contre-productif. Mais reconstruire les systèmes à partir de zéro lorsque vous touchez les limites d'échelle est également coûteux et risqué.

L'architecture itérative nécessite la conception de systèmes en fonction de l'évolution. Cela ne signifie pas construire pour chaque scénario futur possible, mais plutôt s'assurer que les limites architecturales clés sont bien définies et que le système peut être refactorisé progressivement à mesure que les exigences deviennent plus claires.

Gérer la dette technique de manière délibérée

La clé est de faire des compromis conscients plutôt que d'accumuler accidentellement la dette : Dette délibérée : Prendre des raccourcis avec un plan pour les réparer plus tard · Dette accidentelle : Devoirs mal décidés sans comprendre les conséquences La dette technique n'est pas toujours mauvaise – accepter parfois des compromis à court terme permet une livraison plus rapide de la valeur.La distinction critique est entre dette délibérée, gérée et dette accidentelle qui s'accumule par des décisions mal prises ou une méconnaissance.

Certaines équipes maintiennent des « arriérés de dettes » en plus des arriérés de données, allouant du temps à chaque sprint pour le nettoyage. D'autres utilisent des mesures comme le temps de construction, le temps de test et la fréquence de déploiement pour mesurer l'impact de la dette.

Lorsque le hack est choisi et que votre équipe choisit de prendre la dette technique, assurez-vous de la documenter. Nous employons une page séparée sur notre wiki décrivant les dettes, les décisions architecturales pertinentes et reliant les tâches nécessaires pour la corriger correctement. La documentation garantit que la dette technique ne devient pas invisible et fournit le contexte pour les décisions futures sur le moment et la façon de l'aborder.

Communiquer les compromis aux intervenants

Par conséquent, l'autre compétence essentielle en architecture est de pouvoir expliquer la raison d'être des compromis aux gestionnaires qui ne peuvent (ou ne veulent pas) comprendre les détails techniques. Une communication efficace sur les compromis architecturaux exige la traduction des préoccupations techniques en termes d'affaires que les intervenants peuvent comprendre et évaluer.

En s'aligneant sur la solution la plus idéale, il sera plus facile de naviguer dans d'éventuelles solutions de rechange et de mettre en évidence les compromis entre les solutions pour les pairs non techniques. L'établissement d'une compréhension commune des critères et des priorités d'évaluation permet de mener des conversations plus productives sur les décisions architecturales entre divers groupes d'intervenants.

Pour présenter les options architecturales aux intervenants, concentrez-vous sur les implications commerciales de différents choix plutôt que des minuties techniques. Expliquez les compromis en termes de coûts, de temps à temps pour le marché, de risques et de capacités commerciales plutôt que de détails de mise en oeuvre.

Examiner la structure et les capacités de l'équipe

Une bonne correspondance entre la conception du système et les limites de l'équipe accélère les progrès et réduit les frictions. Les décisions architecturales doivent tenir compte des capacités, de la taille et de la structure des équipes qui construiront et maintiendront le système. Une architecture qui nécessite une expertise que l'équipe ne possède pas ou des modèles de coordination que l'organisation ne peut pas soutenir est peu probable pour réussir, peu importe ses mérites techniques.

La Loi de Conway suggère que les systèmes ont tendance à refléter les structures de communication des organisations qui les construisent. Plutôt que de lutter contre cette tendance, des architectes efficaces travaillent avec elle, en concevant des architectures qui s'alignent sur les limites organisationnelles et les modèles de communication.

Les capacités de l'équipe devraient également influencer les choix technologiques. La sélection de technologies de pointe que l'équipe ne possède pas d'expérience en matière de risques et qui peuvent ralentir le développement. Inversement, le maintien de technologies familières mais dépassées peut limiter les capacités du système.

Exemples de décisions architecturales fondées sur des données

L'examen d'exemples concrets de la façon dont les organisations ont utilisé les données du monde réel pour éclairer les décisions architecturales fournit des indications précieuses sur l'application pratique de ces principes.

Netflix: prioriser la disponibilité sur la cohérence

Considérez l'architecture de streaming vidéo de Netflix. Ils priorisent la disponibilité et les performances sur la cohérence — si leur algorithme de recommandation montre des données légèrement inexistantes, les utilisateurs ont encore une grande expérience. Cette décision architecturale reflète une compréhension profonde des priorités des utilisateurs et des exigences opérationnelles, éclairée par des données sur la façon dont les utilisateurs interagissent avec la plateforme.

Le choix de Netflix pour prioriser la disponibilité a un sens dans leur contexte : les utilisateurs se soucient beaucoup plus de pouvoir regarder le contenu sans interruption que d'avoir des recommandations parfaitement à jour. En analysant les données de comportement des utilisateurs et en comprenant ce qui stimule la satisfaction et la rétention, Netflix a fait un compromis éclairé qui optimise pour les attributs de qualité qui comptent le plus pour leur entreprise.

Cet exemple illustre également comment les décisions architecturales devraient s'aligner sur le modèle d'entreprise et les attentes des utilisateurs. Un autre type de système, comme une application bancaire, ferait des compromis très différents, en privilégiant la cohérence et la justesse par rapport à la disponibilité, car les exigences commerciales et réglementaires l'exigent.

Uber: Passage de Monolith à Microservices

À mesure que leurs services se sont développés dans le monde entier et que le nombre d'utilisateurs et de fonctionnalités s'est accru (comme UberEATS), ils sont passés à une architecture plus souple basée sur les microservices pour répondre aux divers besoins opérationnels.

L'évolution architecturale d'Uber démontre l'importance d'adapter l'architecture à l'évolution des besoins des entreprises. Leur architecture monolithique initiale leur a bien servi au début, ce qui a permis un développement et un déploiement rapides.

La décision de migrer vers les microservices a été étayée par des données empiriques sur les limites de leur architecture existante et les avantages qu'ils pourraient tirer de l'amélioration des limites des services et du déploiement indépendant.

Conception de bâtiments d'origine

Une étude de l'Institut national des sciences du bâtiment a révélé que la conception axée sur les données peut réduire la consommation d'énergie de 30 % et améliorer le confort des occupants de 25 % Alors que cet exemple provient de l'architecture physique, il illustre les avantages tangibles de l'intégration des données du monde réel dans les décisions de conception.

Grâce aux outils d'analyse de données et aux logiciels, les architectes peuvent analyser divers facteurs tels que la consommation d'énergie, le comportement des occupants et l'impact environnemental, et utiliser ces informations pour optimiser leurs conceptions. Les mêmes principes s'appliquent à l'architecture logicielle, où l'analyse des performances du système, le comportement des utilisateurs et l'utilisation des ressources permet d'optimiser les décisions architecturales.

Échanges sans serveur

Imaginez que vous conceviez une application web qui doit être à la fois très évolutive et rentable. L'utilisation de fonctions sans serveur (AWS Lambda) réduit les coûts opérationnels mais ajoute une latence de démarrage à froid. Cet exemple illustre un compromis architectural commun où les équipes doivent équilibrer le rapport coût-efficacité avec les caractéristiques de performance.

Pour prendre cette décision efficacement, il faut des données sur les modes d'utilisation réels, les exigences de performance et les contraintes de coûts.Les équipes doivent comprendre à quelle fréquence les fonctions seront invoquées, quelle latence est acceptable pour leur cas d'utilisation et comment les coûts sont évalués en fonction de l'utilisation.

Défis dans la mise en œuvre de l'architecture axée sur les données

Bien que les avantages de la prise de décisions architecturales fondées sur les données soient évidents, la mise en oeuvre de cette approche pose plusieurs défis que les organisations doivent relever.

Résistance culturelle et changements d'esprit

Les entreprises doivent commencer à recueillir activement des données, elles doivent s'attaquer aux problèmes culturels qui rendent l'industrie peu attrayante pour les étrangers et elles doivent être ouvertes à prendre des décisions avec l'information plutôt qu'avec l'intuition.

Le passage à une approche axée sur les données modifie la façon dont les équipes fonctionnent.Éduquer les intervenants, aborder la résistance de façon proactive et démontrer comment les données améliorent leurs décisions et leurs résultats.

De nombreux architectes et développeurs ont construit des carrières réussies en s'appuyant sur l'expérience et l'intuition, et peuvent considérer les approches fondées sur les données comme une remise en question de leur expertise.

Qualité et disponibilité des données

La valeur de la prise de décisions fondée sur les données dépend entièrement de la qualité et de la pertinence des données utilisées.Les données de mauvaise qualité, incomplètes, inexactes ou non représentatives, peuvent conduire à des décisions pires que celles qui reposent uniquement sur l'expérience.Les organisations doivent investir dans l'infrastructure de collecte des données, établir des normes de qualité des données et mettre en oeuvre des processus de validation pour s'assurer que les données qui éclairent les décisions architecturales sont dignes de confiance.

La disponibilité des données pose un autre défi, en particulier pour les nouveaux systèmes ou organisations qui n'ont pas de capacités de surveillance et d'analyse établies. Dans ces cas, les équipes peuvent avoir besoin d'investir dans l'instrumentation et l'infrastructure de collecte de données avant de pouvoir pleinement tirer parti de l'architecture axée sur les données.

Analyse Paralysie et vélocité de décision

C'est à cause d'une vérité inhérente sur les décisions : elles sont plus faciles à comprendre, moins vous en savez sur le problème. Plus faciles, mais généralement mal. Bien que les approches fondées sur les données améliorent la qualité des décisions, elles peuvent également ralentir la prise de décisions si les équipes sont paralysées par l'analyse ou attendent une information parfaite qui n'arrive jamais.

La clé consiste à trouver le juste équilibre entre la collecte de données suffisantes pour prendre des décisions éclairées et le maintien de la vitesse nécessaire pour fournir de la valeur, ce qui exige l'établissement de critères clairs pour ce qui constitue des données « suffisantes », l'établissement de délais d'analyse et la reconnaissance du fait que certaines décisions peuvent être prises avec des renseignements limités s'il s'agit de données réversibles ou à faible risque.

Les équipes devraient également faire la distinction entre les décisions qui justifient une analyse approfondie des données et celles qui peuvent être prises plus rapidement.

Compétences et compétences Lacunes

Pour tirer pleinement parti des dépôts d'architecture et des analyses avancées, les équipes ont besoin de l'expertise voulue.Investir dans la formation à la modélisation, à l'interprétation des données, à la gouvernance et à la compétence des outils, cela rapporte rapidement.

Les organisations doivent investir dans le développement de ces capacités par la formation, l'embauche ou le partenariat avec des spécialistes, ce qui pourrait consister à faire participer des spécialistes des données ou des analystes à des équipes d'architecture, à former des architectes aux techniques d'analyse des données ou à établir des centres d'excellence qui fournissent des services d'analyse des données à de nombreuses équipes.

Exigences en matière d'outils et d'infrastructure

Une architecture efficace axée sur les données nécessite des outils et une infrastructure appropriés pour la collecte, le stockage, l'analyse et la visualisation des données, notamment des plateformes de surveillance et d'observation, des entrepôts de données ou des lacs, des outils d'analyse et des tableaux de bord de visualisation.

La bonne nouvelle est que l'écosystème des outils soutenant les pratiques basées sur les données a beaucoup évolué ces dernières années. Les plateformes Cloud offrent des services complets de surveillance et d'analyse, les outils open-source fournissent des capacités puissantes à faible coût, et les solutions SaaS facilitent plus que jamais la mise en œuvre de la collecte et de l'analyse de données sophistiquées sans tout construire à partir de rien.

Meilleures pratiques pour la prise de décisions architecturales d'utilisation des données

Pour réussir à mettre en oeuvre des pratiques architecturales fondées sur les données, il faut suivre des pratiques exemplaires éprouvées qui aident les organisations à maximiser la valeur de leurs données tout en évitant les pièges communs, ce qui représente les leçons tirées des organisations qui ont adopté avec succès des approches fondées sur les données.

Établir des critères de mesure clairs et des critères de réussite

Avant de prendre des décisions architecturales, définissez des critères de réussite clairs et mesurables. Quelles mesures indiqueront si l'architecture atteint ses objectifs? Comment saurez-vous si un compromis particulier était le bon choix? L'établissement de ces critères permet de s'assurer que les efforts de collecte de données sont axés sur l'information pertinente et fournissent une base objective pour l'évaluation des résultats.

Les mesures devraient être directement liées aux attributs de qualité et aux objectifs opérationnels. Plutôt que de recueillir des données simplement parce qu'elles sont disponibles, de se concentrer sur des mesures qui éclairent des décisions précises ou de valider des hypothèses particulières.

Construire l'observabilité dans les systèmes depuis le début

Il est beaucoup plus difficile de remettre l'observabilité en place dans les systèmes existants que de les construire dès le début. Concevoir des systèmes avec des instruments, des registres et des contrôles comme des préoccupations de première classe plutôt que comme des réflexions après-vente, notamment définir les données à recueillir, établir des pratiques d'exploitation forestière cohérentes et mettre en oeuvre des systèmes de traçage répartis.

L'observation complète permet des boucles de rétroaction continues qui éclairent les décisions architecturales en cours. Plutôt que de prendre des décisions fondées sur des hypothèses ou des informations dépassées, les équipes peuvent se fier aux données actuelles sur la façon dont les systèmes se comportent réellement dans la production.

Début petit et itéré

Les organisations qui ont adopté une architecture axée sur les données ne devraient pas tout transformer en même temps. Commencez par un projet pilote ou un domaine précis où les approches axées sur les données peuvent démontrer une valeur claire.

Cette approche itérative permet aux équipes de développer leurs compétences et de perfectionner leurs processus sans surcharger l'organisation. Elle leur offre également l'occasion de démontrer leur valeur et de renforcer leur soutien en vue d'une adoption plus large de pratiques fondées sur les données.

Combiner les données avec l'expertise du domaine

Les données doivent éclairer les décisions, et non pas les rendre automatiquement. La prise de décision architecturale la plus efficace combine les données empiriques avec l'expertise du domaine, la compréhension des affaires et le jugement professionnel.

Les architectes devraient considérer les données comme un élément important dans le processus décisionnel. L'expérience, les connaissances de l'industrie, la compréhension du contexte commercial et la sensibilisation aux technologies émergentes jouent tous un rôle important. L'objectif n'est pas d'éliminer le jugement humain, mais de l'améliorer avec des preuves empiriques qui réduisent l'incertitude et valident les hypothèses.

Rendre les données accessibles et compréhensibles

Les données ne sont utiles que si les gens peuvent y accéder et comprendre ce qu'elles signifient.Investir dans les outils de visualisation et les tableaux de bord qui rendent les données accessibles aux intervenants à tous les niveaux. Présenter les données de façon pertinente pour différents publics – mesures techniques pour les développeurs, mesures d'affaires pour les cadres et mesures d'expérience utilisateur pour les gestionnaires de produits.

La visualisation efficace des données aide les équipes à identifier les modèles, à repérer les anomalies et à comprendre les tendances qui pourraient ne pas être apparentes dans les données brutes. Elle facilite également la communication sur les décisions architecturales en fournissant des preuves visuelles qui appuient les recommandations et aident les intervenants à comprendre les compromis.

Examen régulier et mise à jour des décisions

Il faudrait revoir périodiquement les décisions architecturales à mesure que de nouvelles données deviennent disponibles et que les circonstances changent. Établir des cycles d'examen réguliers où les équipes examinent si les choix architecturaux existants ont encore un sens compte tenu des données et des besoins actuels.

Ces examens permettent de valider que les architectures fonctionnent comme prévu, de déterminer les domaines où des améliorations sont nécessaires et de saisir les problèmes avant qu'ils ne deviennent critiques. Ils aident également les équipes à tirer des leçons de l'expérience en comparant les résultats réels aux prévisions et en comprenant les hypothèses qui se sont avérées correctes ou incorrectes.

L'avenir de l'architecture d'exploitation des données

À mesure que la technologie évolue, le rôle des données dans la prise de décisions architecturales ne fera que croître. Plusieurs tendances émergentes indiquent un avenir de plus en plus axé sur les données pour l'architecture logicielle.

L'IA et l'apprentissage automatique en architecture

L'IA et les outils d'apprentissage automatique peuvent améliorer notre capacité à inclure des voix et des perspectives diverses dans des projets de conception complexes, surtout lorsqu'ils travaillent sur des bâtiments historiques. Comme ma collègue Marisa Allen, AIA, LEED AP, Fitwel Amb., dit, « Chez Quinn Evans, nous sommes à la fois axés sur l'expérience utilisateur et sur les données, et cela nous amène à prendre beaucoup plus d'intrants et à analyser pour plus d'expériences que d'autres entreprises. »

L'architecture peut intégrer des composants d'IA et de ML pour extraire des informations plus approfondies des données. Les algorithmes d'apprentissage automatique peuvent analyser de grandes quantités de données opérationnelles pour identifier les modèles, prédire les problèmes de performance et recommander des optimisations qui seraient difficiles ou impossibles à découvrir manuellement pour les humains.

Cependant, l'IA et le ML devraient être considérés comme des outils qui améliorent plutôt que remplacent les architectes humains. Le jugement, la créativité et la compréhension contextuelle que les architectes expérimentés apportent demeurent essentiels. L'avenir implique probablement la collaboration entre l'expertise humaine et l'intelligence de la machine, chacun contribuant à leurs forces uniques au processus architectural.

Optimisation de l'architecture en temps réel

Traitement en temps réel – Les architectures basées sur les données impliquent souvent un traitement en temps réel ou quasi-en temps réel pour permettre des informations et des actions rapides. Avec l'amélioration des capacités de surveillance et d'analyse, les architectures pourront s'adapter automatiquement à partir de données en temps réel.

Ces architectures auto-optimisantes représentent l'évolution logique des approches fondées sur les données, où les systèmes non seulement informent les décisions humaines mais prennent également certaines décisions opérationnelles de façon autonome, basées sur des politiques prédéfinies et des données en temps réel.

Jumelles numériques et simulation

Nous sommes à la tête de l'industrie des jumelles numériques pour les bâtiments existants et historiques, permettant aux intendants de prendre des décisions fondées sur les données concernant la gestion du tissu du bâtiment et les aidant à repérer les possibilités d'économiser de l'énergie, d'améliorer le confort des occupants ou d'entreprendre une maintenance préventive.

Dans l'architecture logicielle, les jumeaux numériques pourraient modéliser le comportement du système dans diverses conditions, permettant aux équipes de tester des alternatives architecturales pratiquement avant de les mettre en œuvre en production.Cette capacité réduirait considérablement le risque de décisions architecturales en permettant des tests et validations complets dans des environnements simulés qui reflètent avec précision les conditions réelles.

L'accent est mis sur la durabilité et l'efficacité

Les architectes devront tenir compte non seulement des exigences fonctionnelles et des performances, mais aussi de l'impact environnemental de leurs décisions. Les données sur la consommation d'énergie, l'empreinte carbone et l'utilisation des ressources éclaireront les choix architecturaux visant à construire des systèmes plus durables.

Cette tendance s'inscrit dans le cadre de l'évolution de l'architecture physique, où la conception axée sur les données a déjà fait des preuves d'avantages importants pour la durabilité.

Conclusion : Faire place à la pratique architecturale axée sur les données

Les compromis ne sont pas des échecs de conception. Ce qui est fondamental, c'est de saisir l'essence de la prise de décision architecturale : le succès ne consiste pas à éviter les compromis, mais à les faire consciemment et efficacement.

La première loi de l'architecture logicielle nous enseigne qu'aucune décision n'est absolue, que chaque choix a des compromis. Un grand architecte comprend, analyse et équilibre ces compromis en fonction des besoins commerciaux, des contraintes techniques et des objectifs à long terme. En intégrant des preuves empiriques dans cet équilibre, les architectes peuvent prendre des décisions plus éclairées qui servent mieux leurs organisations et leurs utilisateurs.

Le cheminement vers une architecture axée sur les données n'est pas sans défis, mais il exige des changements culturels, des investissements dans les outils et les compétences, et un engagement à la collecte et à l'analyse systématiques des données.

Une approche d'architecture d'entreprise axée sur les données donne aux organisations les preuves nécessaires pour prendre des décisions stratégiques et confiantes. En utilisant un dépôt d'architecture comme source unique de vérité, les équipes gagnent en visibilité, réduisent les risques et construisent des feuilles de route fondées sur des données réelles.

À mesure que les systèmes logiciels deviennent plus complexes et que les exigences opérationnelles deviennent plus exigeantes, la capacité de prendre des décisions architecturales fondées sur des données probantes séparera de plus en plus les organisations qui réussissent de celles qui luttent.

L'architecture logicielle ne consiste pas à trouver la solution parfaite. Il s'agit de faire les compromis appropriés pour votre situation spécifique. Chaque décision doit être fondée sur une compréhension claire de vos exigences, limitations et structure d'équipe. En pesant les compromis de chaque style d'architecture et en les alignant avec vos objectifs, vous créez une base pour le succès à long terme.

L'avenir de l'architecture logicielle réside dans la combinaison intelligente de l'expertise humaine et des données empiriques. Ni à elle seule, les données sans contexte et sans interprétation n'ont de sens, tandis que l'expertise sans validation peut conduire à des décisions fondées sur des hypothèses dépassées ou des biais personnels.

Pour les organisations qui cherchent à améliorer leurs pratiques architecturales, la voie à suivre est claire : investir dans les capacités de collecte et d'analyse des données, établir des cadres pour évaluer les compromis, documenter systématiquement les décisions et favoriser les cultures qui valorisent la prise de décisions fondées sur des données probantes.

Les décisions architecturales prises aujourd'hui façonnent les systèmes qui serviront les organisations pendant des années à venir. En étalant ces décisions dans les données réelles et l'analyse systématique des compromis, les architectes peuvent construire des systèmes qui non seulement répondent aux exigences actuelles mais aussi s'adaptent gracieusement à l'évolution des besoins.

Ressources supplémentaires

Pour ceux qui souhaitent approfondir leur compréhension de la prise de décisions architecturales fondées sur les données, plusieurs ressources fournissent des conseils utiles et des conseils pratiques :

• L'Institut d'ingénierie des logiciels de l'Université Carnegie Mellon offre de vastes ressources sur les méthodes d'évaluation de l'architecture, y compris la documentation détaillée de l'ATAM et les techniques connexes.
• Martin Fowler guide de l'architecture fournit des perspectives réfléchies sur la prise de décision architecturale et les modèles.
• Le projet Architecture Decision Records offre des modèles et des conseils pour documenter efficacement les décisions architecturales.
• Des livres comme « Fundamentals of Software Architecture » de Mark Richards et Neal Ford et « Software Architecture: The Hard Parts » offrent une couverture complète des compromis architecturaux et des cadres de décision.
• Les conférences et les communautés de l'industrie axées sur l'architecture logicielle offrent l'occasion de tirer des leçons des praticiens et de partager des expériences avec des approches fondées sur les données.

En tirant parti de ces ressources et en s'engageant dans l'apprentissage continu, les architectes peuvent développer les compétences et les connaissances nécessaires pour prendre des décisions efficaces et fondées sur les données qui créent une valeur durable pour leur organisation.