10.3 Gestion de l'architecture de solution
Objectifs d'apprentissage
À la fin de cette section, vous serez capable de :
- Identifier les motifs de processus de génie logiciel
- Décrire la progression des modèles logiciels vers l'implémentation logicielle
Le processus de gestion, de conception et de description de l'ingénierie de solution en relation avec des problèmes commerciaux spécifiques est appelé gestion de l'architecture de solution (solution architecture management). Un gestionnaire d'architectes de solutions (solutions architect manager) est responsable de la constitution d'équipes, de l'établissement de relations, de la définition de la stratégie, ainsi que de la mesure et de la livraison des résultats pour tout problème ou opportunité que l'entreprise pourrait rencontrer.
Pleins feux sur l'industrie
Gestion de l'architecture de solution
La gestion de l'architecture de solution est importante dans toutes les industries aujourd'hui. Elle joue un rôle particulièrement crucial dans le secteur de la santé. L'architecture de solution est utilisée pour maintenir les dossiers de santé électroniques et assurer la confidentialité et la sécurité des données des patients. À mesure que les systèmes de santé deviennent plus complexes et que les données deviennent plus sensibles, l'architecture de solution peut être utilisée pour concevoir des systèmes sécurisés, évolutifs et efficaces. Ces cadriciels (frameworks) permettent aux fournisseurs d'accéder à des informations fiables tout en respectant les réglementations en matière de données.
Motifs de processus de génie logiciel
Comme nous l'avons appris au Chapitre 9 Génie logiciel, le processus logiciel peut être défini comme une collection de motifs (patterns) qui définissent un ensemble d'activités, d'actions et de tâches requises pour développer un logiciel. Le génie logiciel (Software engineering) est une étude détaillée de l'ingénierie pour concevoir, développer et maintenir des logiciels. Les motifs de processus de génie logiciel établissent une communication collaborative entre les clients et les ingénieurs logiciels pour garantir la réussite des motifs de tâches dans le cadre des exigences et de la portée du projet.
Comme vous vous en souvenez peut-être, divers processus et motifs de processus connexes ont été abordés au Chapitre 9 Génie logiciel pour expliquer comment les solutions logicielles peuvent être développées en affinant un modèle d'architecture en une solution entièrement codée et prête à être déployée.
La technologie au quotidien
Gestion de l'architecture dans la vie réelle
La gestion de l'architecture de solution n'a peut-être pas d'impact direct sur les individus dans leur vie quotidienne, mais elle influence indirectement leurs expériences par le développement et la gestion de diverses solutions technologiques. Elle garantit que des systèmes comme les applications bancaires, les plateformes d'achat en ligne et les appareils domestiques intelligents fonctionnent efficacement en gérant la manière dont les différents composants technologiques interagissent. Lorsqu'elle est bien mise en œuvre, elle améliore la fiabilité et les performances de ces outils, rendant les tâches quotidiennes plus fluides.
Lien vers l'apprentissage
Pour en savoir plus sur l'architecture d'entreprise et son utilisation dans les affaires et la technologie modernes, explorez les sites Web de publications industrielles comme CIO Magazine pour des aperçus et tendances actuels en matière de gestion technologique.
Des modèles logiciels à l'implémentation logicielle
Rappelons qu'un sous-système (subsystem) est un ensemble de composants collaboratifs qui exécutent une tâche donnée incluse dans les systèmes logiciels ; il est considéré comme une entité distincte au sein d'une architecture logicielle. Un composant (component) est une partie encapsulée d'un système logiciel, qui possède une interface et sert de bloc de construction pour la structure d'un sous-système. Les sous-systèmes interagissent avec d'autres sous-systèmes et composants pour exécuter leurs tâches désignées. Au niveau du langage de programmation, les composants peuvent être représentés comme des modules, des classes, des objets ou comme un ensemble de fonctions connexes.
Lors de la conception d'architectures pour des systèmes logiciels, les concepteurs de logiciels commencent généralement par un modèle d'exigences (explicite ou implicite) qui présente une représentation abstraite du système. Le modèle d'exigences (requirements model) est un modèle qui décrit l'ensemble des problèmes, établit le contexte et identifie le système de forces qui prévalent, telles que les attributs de qualité de conception. La méthode (method) de masquage des détails d'arrière-plan (c'est-à-dire l'implémentation inutile) concernant les données afin que les utilisateurs ne voient que les informations requises est appelée représentation abstraite (abstract representation).
Dans une approche de conception d'architecture traditionnelle qui ne tire pas parti des motifs, les concepteurs de logiciels recueillent la « vue d'ensemble » du modèle d'exigences et procèdent à la définition des entités externes telles que d'autres systèmes, appareils et personnes. Le système logiciel interagit avec les entités externes et définit la nature de l'interaction. Les concepteurs de logiciels doivent ensuite identifier un ensemble d'archétypes architecturaux et spécifier la structure du système en définissant et en affinant les composants logiciels qui implémentent chaque archétype. Un archétype (archetype) est une abstraction (similaire à une classe) qui représente un élément du comportement du système.
Réfléchissez-y
Architecture et génie logiciel
Les activités d'architecture et les activités de génie logiciel collaborent tout au long du processus de développement logiciel. L'architecture fournit le plan (blueprint) que les ingénieurs logiciels doivent suivre, tandis que les activités de génie logiciel fournissent des retours qui aident aux décisions architecturales.
Étant donné que l'architecture est maintenue à différents niveaux de portée au sein de l'entreprise, comment les activités d'architecture s'intègrent-elles aux activités de génie logiciel ?
Figure 10.46 illustre comment les activités de gestion de l'architecture d'entreprise s'intègrent généralement au cycle de vie du développement de solutions au sein des entreprises. L'intégration des activités de gestion de l'architecture d'entreprise au cycle de vie du développement de solutions garantit que les solutions sont développées en alignement avec les objectifs stratégiques de l'organisation, les principes (principles) architecturaux et les exigences de gouvernance (governance). Elle aide à optimiser l'allocation des ressources, à rationaliser les efforts de développement, à améliorer l'interopérabilité et à accroître l'efficacité globale des solutions technologiques au sein de l'entreprise.
Patrons architecturaux et de conception
Les patrons de conception sont une représentation des solutions testées précédemment à un problème spécifique, ce qui est utile pour résoudre des problèmes futurs. Lorsque les concepteurs de logiciels envisagent d'appliquer des motifs ou commencent à penser en motifs (patterns), ils essaient d'abord de relier les motifs au modèle d'exigences, qui communique la vue d'ensemble et le contexte dans lequel le logiciel à construire réside. Après cela, ils extraient les motifs présents à ce niveau d'abstraction et commencent leur conception avec des motifs de haut niveau qui définissent un contexte ou un squelette pour les travaux de conception ultérieurs. Ils travaillent ensuite de l'intérieur vers l'extérieur du contexte, recherchant des motifs à des niveaux de spécialisation inférieurs qui contribuent à la solution de conception. Les mêmes étapes d'application des motifs sont répétées jusqu'à ce que la conception complète soit élaborée, et la conception est affinée en adaptant chaque motif aux spécificités du logiciel en cours de construction. Selon l'approche, les divers motifs mentionnés précédemment sont appliqués à la vue d'ensemble en tenant compte de leur niveau d'abstraction.
Rappelez-vous qu'un style architectural (architectural style) est un ensemble de caractéristiques qui rendent un système logiciel notable ou identifiable ; c'est aussi une transformation qui est imposée à la conception de l'ensemble du système logiciel. Dans tout système logiciel, il existe un ensemble de contraintes architecturales qui restreignent les rôles/fonctionnalités des éléments architecturaux. Un style architectural correspond à des rôles coordonnés et permet des relations entre les éléments au sein de toute architecture conforme à ce style. Un patron d'architecture (architectural pattern) exprime un schéma d'organisation structurelle fondamental pour le système logiciel en prédéfinissant les sous-systèmes, en prédéfinissant les responsabilités des sous-systèmes, en créant des règles et des lignes directrices pour organiser les sous-systèmes, et en établissant des relations entre les sous-systèmes. Enfin, l'affinage des sous-systèmes ou des composants du système logiciel, ou des relations entre eux, est la règle d'un patron de conception. Cela fournit un schéma qui décrit une structure de composants communicants couramment récurrente et résout un problème de conception général dans le contexte particulier du système logiciel.
En se penchant sur la conception architecturale d'un système logiciel, il devient généralement clair que le système ne peut pas être conçu directement en appliquant simplement des motifs. Penser en motifs aide à relier les motifs à un modèle d'exigences d'environnement technologique et révèle généralement que les solutions logicielles devraient tirer parti des caractéristiques de plusieurs styles architecturaux (par exemple, infonuage (cloud), P2P et microservices (microservices)). Cela peut également aider à identifier la nécessité de tirer parti des patrons architecturaux EAM, BPM et Agents Autonomes Intelligents dans le cadre d'une solution logicielle.
Concepts en pratique
Architecture d'entreprise et aménagement du territoire
Il est facile de considérer un projet d'aménagement du territoire comme étant axé sur le développement d'un certain nombre de communautés résidentielles peuplées de maisons personnalisées. La société d'aménagement du territoire peut être considérée au niveau de l'entreprise. Chaque communauté résidentielle individuelle est développée par des unités commerciales au sein de l'entreprise, et les maisons individuelles au sein de chaque communauté résidentielle sont créées comme des projets individuels. Cela peut être comparé à ce qui se passe lorsque l'architecture d'entreprise est appliquée pour gérer les architectures au niveau de l'entreprise, du portefeuille et du projet. Au niveau du projet, la gestion des projets logiciels devient la préoccupation de l'ingénieur logiciel, mais il est clair que l'architecture d'entreprise est nécessaire pour garantir que les projets individuels sont mis en œuvre conformément aux directives établies à un niveau supérieur.
Cadriciels d'architecture technique d'entreprise
Alors que l'approche de conception architecturale ouvre la voie à la conception basée sur les motifs, les motifs eux-mêmes peuvent ne pas toujours suffire à développer une conception complète. Dans certains cas, il peut être nécessaire de fournir un cadriciel. Rappelez-vous qu'un cadriciel est un sous-système squelettique spécifique à l'implémentation pour le travail de conception. La mini-architecture fournit la structure et le comportement génériques pour une famille d'abstractions logicielles. Les mèmes (c'est-à-dire les métaphores) spécifient la collaboration des sous-systèmes au sein d'un domaine donné. Vous pouvez réutiliser les mini-architectures avec un mème pour créer le cadriciel, qui n'est pas un patron architectural mais plutôt un squelette avec une collection de « points de branchement » qui permettent d'adapter le cadriciel à un domaine de problème spécifique. Les points de branchement — également appelés crochets et fentes — vous permettent d'intégrer des classes ou des fonctionnalités spécifiques au problème au sein du squelette. Par conséquent, un cadriciel définit l'architecture d'une famille de sous-systèmes, fournit les blocs de construction de base pour les créer et définit où les adaptations pour des fonctionnalités spécifiques doivent être faites. En général, les motifs peuvent être utilisés pour décrire le cadriciel comme des informations sur le système et les cadriciels sont des logiciels qui définissent une conception générique.
Piles logicielles
Une pile logicielle (software stack) est une collection de composants indépendants ou de sous-systèmes (subsystems) tels que des systèmes d'exploitation, des protocoles, des bases de données, des couches architecturales et des appels de fonction qui travaillent ensemble pour prendre en charge l'exécution d'une application. À mesure que les modèles architecturaux sont transformés en architectures d'implémentation, il est nécessaire d'identifier les produits spécifiques qui peuvent être utilisés dans le cadre de l'implémentation. C'est là que la sélection des piles de produits/logiciels a lieu. Par exemple, un choix peut être de sélectionner parmi les piles de produits IBM, Oracle ou Microsoft telles que Dynamic 365 (ou une combinaison) pour implémenter une architecture particulière.
Figure 10.47 est un exemple de pile logicielle simple pour l'implémentation d'un site Web. La pile se compose d'une interface utilisateur, d'une couche d'application, d'une infrastructure d'application et d'une infrastructure technique.
Une fois qu'une pile logicielle est sélectionnée, divers produits peuvent être ajoutés via des légendes sur le plan d'architecture d'implémentation correspondant.
Enjeux mondiaux en technologie
Sécurité de la gestion de l'architecture à travers le monde
Les enjeux mondiaux en technologie peuvent avoir des implications significatives pour la gestion de l'architecture de solution dans le monde entier. La gestion de l'architecture de solution doit aborder les réglementations en matière de protection des données, assurer une gestion sécurisée des données sensibles et mettre en œuvre des mesures de sécurité robustes pour se prémunir contre les cybermenaces. La conformité au RGPD de l'Union européenne exige des organisations qu'elles mettent en œuvre des contrôles stricts de confidentialité des données. Cela influence à son tour la conception des solutions informatiques mondiales, car elles doivent tenir compte des réglementations locales et régionales.
Patrons d'implémentation et idiomes
Comme nous l'avons déjà dit, les patrons de conception abordent des principes structurels généraux ; en revanche, les idiomes (idioms) représentent des motifs de bas niveau qui décrivent comment résoudre des problèmes spécifiques à l'implémentation dans un langage de programmation, tels que la gestion de la mémoire en C++ ou Java.
À mesure que les modèles architecturaux sont transformés en architectures d'implémentation, il devient nécessaire de spécifier comment les patrons architecturaux et de conception sont réalisés concrètement au sein de la solution. Cette cartographie commence en fait à un niveau élevé avec les styles architecturaux eux-mêmes. Par exemple, un style architectural BPM peut être réalisé via la sélection de services REST d'entreprise et avec un produit correspondant tel que MuleSoft. Cela dicte ensuite l'utilisation de patrons d'implémentation et d'idiomes spécifiques à la pile de produits MuleSoft.