Dans le domaine de l’architecture d’entreprise, les modèles d’architecture constituent un outil essentiel pour concevoir des solutions efficaces face à des problèmes courants. Les modèles permettent de placer les blocs de construction dans un contexte, et peuvent fournir aux architectes un plan directeur pour concevoir des solutions éprouvées dans le passé. Dans cet article, nous explorons le concept des modèles d’architecture dans le cadre du TOGAF ADM, et fournissons un exemple de modèle d’architecture dans le contexte du développement d’applications métier.
Qu’est-ce que les modèles d’architecture
Un « modèle » a été défini comme : « une idée qui s’est révélée utile dans un contexte pratique et qui sera probablement utile dans d’autres » (Source : Patterns d’analyse – Modèles d’objets réutilisables, par M. Fowler).
Dans la norme TOGAF, les modèles sont considérés comme une manière de placer les blocs de construction dans un contexte ; par exemple, pour décrire une solution réutilisable à un problème. Les blocs de construction sont ce que vous utilisez : les modèles peuvent vous indiquer comment les utiliser, quand, pourquoi, et quels compromis vous devez accepter pour le faire.
Les modèles offrent la promesse d’aider l’architecte à identifier des combinaisons de blocs de construction d’architecture et/ou de solutions (ABBs/SBBs) qui se sont révélées efficaces dans le passé, et pourraient constituer la base de solutions efficaces à venir.
Les techniques de modèles sont généralement reconnues comme ayant été établies comme une méthode de conception architecturale précieuse par Christopher Alexander, architecte de bâtiments, qui a décrit cette approche dans son livre The Timeless Way of Building, publié en 1979. Ce livre présente une introduction aux idées sous-jacentes à l’utilisation des modèles, et Alexander a ensuite publié deux autres ouvrages (A Pattern Language et The Oregon Experiment) dans lesquels il a approfondi sa description des caractéristiques et des avantages d’une approche basée sur les modèles en architecture.
Modèles d’architecture dans le cadre du TOGAF ADM
La méthode de développement d’architecture (ADM) est un élément clé de la norme TOGAF de The Open Group, qui fournit un cadre pour concevoir et gérer l’architecture d’entreprise. Dans le cadre de l’ADM, les modèles d’architecture constituent un outil puissant qui peut aider les architectes à identifier des solutions éprouvées face à des problèmes courants et à accélérer le développement d’architectures efficaces.
Au cœur de tout modèle d’architecture se trouve simplement une description d’une solution réutilisable à un problème qui s’est révélée efficace en pratique. Comme le suggère la définition ci-dessus, un modèle est une idée qui s’est révélée utile dans un contexte et qui sera probablement utile dans d’autres. Les modèles peuvent être utilisés pour décrire des solutions à différents niveaux d’abstraction, allant des modèles d’architecture de haut niveau qui décrivent la structure globale d’un système aux modèles de conception de bas niveau qui décrivent la manière dont les composants individuels doivent être implémentés.
L’un des principaux avantages de l’utilisation des modèles d’architecture est qu’ils aident les architectes à identifier des combinaisons de blocs de construction d’architecture (ABBs) ou de blocs de construction de solutions (SBBs) qui se sont révélées efficaces dans le passé. Cela permet d’économiser du temps et des efforts en fournissant un point de départ pour le développement d’architecture, plutôt que de commencer à zéro pour chaque nouveau projet.
En outre, les modèles d’architecture peuvent contribuer à garantir que les architectures soient cohérentes et conformes. En utilisant des modèles pour décrire des solutions à des problèmes courants, les architectes peuvent établir un langage commun et un ensemble de concepts pouvant être utilisés à travers l’organisation. Cela peut aider à éviter les malentendus et à garantir que tous travaillent vers une vision partagée de l’architecture.
Les techniques de modèles ont été établies comme une méthode précieuse de conception architecturale par Christopher Alexander, architecte de bâtiments, qui a décrit cette approche dans son livre The Timeless Way of Building. Les idées d’Alexander ont ensuite été développées dans deux autres ouvrages, A Pattern Language et The Oregon Experiment.
Dans le contexte de l’architecture d’entreprise, plusieurs types différents de modèles d’architecture peuvent être utilisés. Parmi les plus courants figurent :
- Architectures de référence – Elles décrivent la structure globale d’un système ou d’une application, et fournissent un point de départ pour le développement d’architecture.
- Modèles de solution – Ils décrivent comment des problèmes spécifiques peuvent être résolus en combinant des ABBs et des SBBs.
- Modèles de processus – Ils décrivent les meilleures pratiques et les flux de travail courants pour concevoir et mettre en œuvre des architectures.
- Modèles de conception – Ils décrivent comment les composants individuels doivent être conçus et implémentés, et peuvent aider à garantir la cohérence et la maintenabilité à travers l’architecture.
Les modèles d’architecture constituent un outil puissant pour les architectes souhaitant développer des architectures d’entreprise efficaces et performantes. En identifiant des solutions éprouvées face à des problèmes courants, les architectes peuvent économiser du temps et des efforts tout en garantissant que les architectures sont cohérentes, conformes et alignées sur les objectifs et buts organisationnels.
Un modèle pour la documentation des modèles d’architecture
1. Nom du modèle
Un nom descriptif pour le modèle, qui doit communiquer clairement le problème à résoudre.
2. Problème
Une description du problème ou du défi auquel le modèle est destiné à répondre. Elle doit être claire et précise, et fournir un contexte pour le modèle.
3. Contexte
Une description du contexte dans lequel le modèle est destiné à être utilisé. Elle doit inclure des informations sur l’organisation, le système ou l’application en cours de développement, ainsi que toute contrainte ou limitation pertinente.
4. Solution
Une description de la solution que le modèle fournit. Elle doit être claire et précise, et expliquer comment le modèle peut être utilisé pour résoudre le problème décrit à la section 2.
5. Avantages
Une description des avantages de l’utilisation du modèle. Elle doit expliquer comment le modèle peut aider à résoudre le problème, et fournir des preuves en faveur de son efficacité.
6. Compromis
Une description des compromis ou concessions qui doivent être effectués lors de l’utilisation du modèle. Cela doit inclure toute limitation ou inconvénient du modèle, ainsi que tout risque à gérer.
7. Mise en œuvre
Une description de la manière dont le modèle peut être mis en œuvre. Cela doit inclure des conseils sur la manière d’appliquer le modèle, ainsi que des exemples ou cas d’utilisation pertinents.
8. Modèles connexes
Une liste de modèles connexes qui pourraient être utiles en conjonction avec le modèle actuel. Cela doit inclure tout modèle étroitement lié ou pouvant être utilisé en combinaison avec le modèle actuel.
9. Références
Une liste des références et sources utilisées dans la conception du modèle. Cela doit inclure toute publication, article ou autre ressource pertinente.
En utilisant ce modèle, les architectes peuvent créer des modèles d’architecture clairs et efficaces, facilement partageables et réutilisables dans différents projets et contextes.
Un exemple de modèle d’architecture dans un contexte métier
Examinons un exemple de modèle d’architecture dans le contexte du développement d’applications métiers.
Supposons qu’une entreprise doive développer une nouvelle application web pour gérer les relations clients. L’un des principaux défis auxquels elle est confrontée est de garantir que l’application soit évolutive et capable de gérer un grand nombre d’utilisateurs simultanés.
En utilisant le modèle de modèle d’architecture décrit ci-dessus, nous pouvons créer un modèle pour résoudre ce problème :
1. Nom du modèle : Application web évolutif
2. Problème : Développer une application web pour gérer les relations clients capable de gérer un grand nombre d’utilisateurs simultanés.
3. Contexte : Une entreprise doit développer une nouvelle application web pour gérer les relations clients. L’application sera utilisée par un grand nombre d’utilisateurs et doit être évolutive pour gérer les pics d’utilisation.
4. Solution : Le modèle Application web évolutif propose une solution pour développer une application web capable de gérer un grand nombre d’utilisateurs simultanés. Les éléments clés de ce modèle incluent :
- Équilibrage de charge : répartir les requêtes entrantes sur plusieurs serveurs afin de garantir qu’aucun serveur ne soit surchargé.
- Mise en cache : utiliser le cache en mémoire pour stocker les données fréquemment consultées et réduire la charge sur la base de données.
- Mise à l’échelle horizontale : ajouter des serveurs supplémentaires à l’infrastructure pour gérer une charge accrue.
- Fractionnement de la base de données : diviser la base de données en partitions plus petites pour répartir la charge sur plusieurs serveurs.
5. Avantages : En utilisant le modèle Application web évolutif, l’entreprise peut garantir que son application peut gérer un grand nombre d’utilisateurs simultanés sans rencontrer de problèmes de performance ou d’indisponibilité. Cela peut améliorer la satisfaction client et augmenter les revenus en assurant que l’application est toujours disponible.
6. Compromis : Le modèle Application web évolutif nécessite une infrastructure et des ressources supplémentaires pour être mis en œuvre, ce qui peut augmenter les coûts. En outre, la mise en œuvre de l’équilibrage de charge et du cache peut ajouter de la complexité à l’architecture de l’application.
7. Mise en œuvre : Pour mettre en œuvre le modèle d’application web évolutif, l’entreprise devrait envisager d’utiliser un équilibreur de charge tel que NGINX, mettre en œuvre le cache à l’aide d’une technologie comme Redis ou Memcached, et faire évoluer horizontalement l’application à l’aide d’une plateforme cloud comme AWS ou Azure. Le fractionnement de la base de données peut être mis en œuvre à l’aide d’une technologie de base de données comme MongoDB.
8. Modèles connexes : Des modèles connexes qui pourraient être utiles en conjonction avec le modèle d’application web évolutif incluent :
- Architecture microservices : diviser l’application en services plus petits et plus faciles à gérer, pouvant être mis à l’échelle de manière indépendante.
- Passerelle d’API : fournir un point d’entrée unique pour accéder aux services de l’application et gérer le trafic.
9. Références : Quelques références qui pourraient être utiles pour développer le modèle d’application web évolutif incluent :
- High Scalability (blog):
- Construire des sites web évolutifs (livre) par Cal Henderson
En utilisant ce modèle d’architecture, l’entreprise peut économiser du temps et des efforts dans le développement d’une application web évolutif pour la gestion des relations clients. Le modèle fournit une solution éprouvée à un problème courant et peut être facilement adapté aux besoins et contraintes spécifiques de l’entreprise.
Exemple d’un modèle d’architecture dans le contexte de la connexion unique
Voici un exemple de modèle d’architecture dans le contexte de la connexion unique (SSO) :
1. Nom du modèle : Connexion unique (SSO)
2. Problème : Plusieurs applications au sein d’une organisation exigent que les utilisateurs s’authentifient séparément, ce qui entraîne une mauvaise expérience utilisateur et un surcroît de charge administrative pour la gestion des comptes utilisateurs.
3. Contexte : Une organisation possède plusieurs applications qui exigent que les utilisateurs s’authentifient séparément, ce qui cause de la frustration et de la confusion pour les utilisateurs. L’organisation souhaite offrir une expérience utilisateur fluide en permettant aux utilisateurs de s’authentifier une seule fois et d’accéder à toutes les applications sans avoir à ressaisir leurs identifiants.
4. Solution : Le modèle de connexion unique fournit une solution permettant aux utilisateurs de s’authentifier une seule fois et d’accéder à plusieurs applications sans avoir à ressaisir leurs identifiants. Les éléments clés de ce modèle incluent :
- Fournisseur d’identité (IdP) : un service centralisé qui authentifie les utilisateurs et fournit des jetons ou des assertions pouvant être utilisés pour accéder à d’autres applications.
- Fournisseur de service (SP) : une application ou un service qui dépend de l’IdP pour authentifier les utilisateurs et fournit l’accès en fonction des jetons ou des assertions fournis par l’IdP.
- Protocoles standard : utiliser des protocoles standard de l’industrie tels que SAML, OAuth ou OpenID Connect pour permettre la communication entre l’IdP et les SP.
5. Avantages : En utilisant le modèle de connexion unique, l’organisation peut offrir une expérience utilisateur fluide et réduire la charge administrative liée à la gestion des comptes utilisateurs. Les utilisateurs n’ont besoin de s’authentifier qu’une seule fois et peuvent ensuite accéder à toutes les applications sans avoir à se souvenir de plusieurs ensembles d’identifiants. Cela peut améliorer la satisfaction des utilisateurs et réduire les coûts de support technique.
6. Compromis : La mise en œuvre du modèle de connexion unique nécessite une infrastructure et des ressources supplémentaires, ce qui peut augmenter les coûts. En outre, l’intégration avec les applications existantes peut nécessiter un développement personnalisé ou une configuration, ce qui peut ajouter de la complexité.
7. Mise en œuvre : Pour mettre en œuvre le modèle de connexion unique, l’organisation doit choisir un fournisseur d’identité qui prend en charge des protocoles standard de l’industrie tels que SAML, OAuth ou OpenID Connect. Les fournisseurs de services doivent être configurés pour s’appuyer sur le fournisseur d’identité pour l’authentification et l’autorisation. Les applications existantes peuvent nécessiter une intégration avec le fournisseur d’identité, ce qui peut exiger un développement personnalisé ou une configuration.
8. Modèles connexes : Les modèles connexes qui pourraient être utiles en conjonction avec le modèle de connexion unique incluent :
- Identité fédérée : étendre le modèle de connexion unique pour prendre en charge l’authentification à travers des organisations ou des domaines.
- Contrôle d’accès basé sur les attributs : utiliser les attributs d’utilisateur fournis par le fournisseur d’identité pour contrôler l’accès aux ressources au sein des applications.
9. Références : Quelques références qui pourraient être utiles pour développer le modèle de connexion unique incluent :
En utilisant ce modèle d’architecture, l’organisation peut améliorer l’expérience utilisateur et réduire la charge administrative en mettant en œuvre une solution de connexion unique qui permet aux utilisateurs d’accéder à plusieurs applications sans avoir à ressaisir leurs identifiants. Ce modèle fournit une solution éprouvée à un problème courant et peut être facilement adapté pour répondre aux besoins spécifiques et contraintes de l’organisation.
Modèles d’architecture d’entreprise vs modèles d’architecture logicielle
Les modèles d’architecture d’entreprise et les modèles d’architecture logicielle sont des concepts liés mais distincts.
Les modèles d’architecture logicielle se concentrent sur la conception et la mise en œuvre de systèmes logiciels ou d’applications individuelles. Ils fournissent un ensemble de directives et de bonnes pratiques pour concevoir et implémenter les composants logiciels d’un système, tels que ses modules, interfaces et interactions.
Les modèles d’architecture d’entreprise, en revanche, se concentrent sur la conception et l’alignement de plusieurs systèmes et applications logiciels au sein d’une organisation. Ils fournissent un ensemble de directives et de bonnes pratiques pour concevoir et mettre en œuvre l’architecture globale d’une entreprise, y compris ses processus métiers, ses structures de données et son infrastructure technologique.
Les modèles d’architecture d’entreprise traitent généralement des questions telles que l’intégration des systèmes, l’interopérabilité et la scalabilité, qui ne sont pas habituellement couvertes par les modèles d’architecture logicielle. Ils prennent également en compte le contexte plus large dans lequel les systèmes logiciels sont déployés, et visent à aligner les systèmes informatiques sur les objectifs et buts organisationnels.
Des exemples de modèles d’architecture d’entreprise incluent l’architecture orientée services (SOA), la gestion des processus métiers (BPM) et les modèles d’intégration d’entreprise (EIP), tandis que des exemples de modèles d’architecture logicielle incluent le modèle Vue-Contrôleur-Modèle (MVC), les microservices et l’architecture en couches.
Modèles d’architecture logicielle
Les modèles d’architecture logicielle sont des solutions réutilisables pour des problèmes courants dans la conception logicielle. Ils offrent une approche structurée pour concevoir et implémenter des systèmes logiciels en définissant un ensemble de règles et de directives qui aident à garantir que le système est robuste, évolutif et maintenable.
Les modèles d’architecture logicielle offrent une vue d’ensemble du système, en identifiant ses composants clés et leurs interactions. Ils définissent les relations entre ces composants et fournissent un ensemble de règles sur la manière dont ils doivent communiquer et collaborer.
En utilisant des modèles d’architecture logicielle, les développeurs peuvent économiser du temps et des efforts en réutilisant des solutions éprouvées pour des problèmes courants, plutôt que de commencer à partir de zéro pour chaque nouveau projet. Cela peut aider à améliorer la qualité du logiciel résultant, tout en réduisant le temps et les coûts de développement.
Quelques exemples de modèles d’architecture logicielle incluent le modèle Vue-Contrôleur-Modèle (MVC), les microservices, l’architecture en couches, l’architecture orientée services (SOA) et l’architecture orientée événements (EDA).
Voici quelques modèles d’architecture logicielle populaires :
- Modèle Vue-Contrôleur-Modèle (MVC) : ce modèle sépare une application en trois composants interconnectés – le Modèle, la Vue et le Contrôleur – afin d’aider à gérer la complexité et à atteindre une séparation des préoccupations.
- Architecture des microservices : ce modèle divise une application en services plus petits, pouvant être déployés indépendamment, et qui peuvent être développés, déployés et mis à l’échelle séparément.
- Architecture en couches : ce modèle divise une application en couches logiques, chacune étant responsable d’un aspect spécifique de la fonctionnalité de l’application, afin de garantir la modularité et la séparation des préoccupations.
- Architecture orientée services (SOA) : ce modèle est une approche architecturale pour construire des systèmes distribués qui utilisent les services comme éléments fondamentaux.
- Architecture orientée événements (EDA) : Ce modèle met l’accent sur la production, la détection, la consommation et la réaction aux événements qui se produisent au sein d’un système, permettant une architecture plus flexible et évolutive.
- Conception orientée domaine (DDD) : Ce modèle encourage l’utilisation d’un langage commun et d’un modèle pour décrire le domaine d’un problème, ce qui conduit à une base de code plus facile à maintenir et à comprendre.
- Architecture hexagonale : Ce modèle structure une application autour d’un noyau central, avec des ports et des adaptateurs qui permettent la communication entre le noyau et les systèmes externes.
- CQRS (séparation des responsabilités de commande et de requête) : Ce modèle sépare les modèles de lecture et d’écriture d’une application, permettant des requêtes plus efficaces et une meilleure évolutivité.
- Architecture réactive : Ce modèle est un ensemble de principes de conception visant à construire des systèmes résilients, évolutifs et réactifs capables de réagir aux changements dans l’environnement.
- Architecture propre : Ce modèle met l’accent sur la séparation des préoccupations entre les différentes couches d’une application, dans le but de produire un code facile à lire, à tester et à maintenir.
Résumé
Les modèles d’architecture sont une technique de conception précieuse en architecture d’entreprise qui offrent aux architectes un moyen de concevoir des solutions efficaces aux problèmes courants. En fournissant un plan directeur pour concevoir des solutions éprouvées dans le passé, les modèles d’architecture peuvent aider les architectes à économiser du temps et des ressources, tout en améliorant la qualité globale de la solution. Dans cet article, nous avons fourni un exemple de modèle d’architecture dans le contexte du développement d’applications métier, plus précisément dans le contexte de la connexion unique (SSO). En utilisant le modèle de connexion unique, les organisations peuvent offrir une expérience utilisateur fluide et réduire la charge administrative liée à la gestion des comptes utilisateurs, tout en améliorant la satisfaction des utilisateurs et en réduisant les coûts de support informatique.