L’architecture logicielle pour moderniser son SI

Besoins de transformation et architecture logicielle

L’évolution du Système d’Information traduit la nécessité pour une organisation de s’adapter à son environnement concurrentiel et réglementaire. Mais il ne s’agit pas d’un processus linéaire et les transformations à réaliser peuvent prendre plusieurs formes.

Lorsque l’architecture du SI est à l’état de l’art et que l’obsolescence technologique est faible, l’évolution est mise en oeuvre de manière progressive. Dans ces conditions, elle se limite à livrer de nouveaux services ou à améliorer les processus existants, sans remise en cause de la conception des applications ni des technologies utilisées. Mais il arrive aussi, et de plus en plus fréquemment, qu’une refonte complète du SI soit nécessaire en raison de l’érosion des technologies ou des méthodes de conception utilisées. On se situe à la fin d’un cycle de l’architecture informatique. Il faut reprendre les choses en profondeur et repenser la manière dont les applications sont conçues et développées. C’est alors le bon moment pour questionner l’expertise et les habitudes de travail actuelles, pour innover et pour sélectionner les meilleures pratiques en matière de développement informatique.

En d’autres termes, c’est le bon moment pour faire le point et améliorer sa pratique de l’architecture logicielle.

L’architecture logicielle peut être vue comme la description d’un ensemble de composants et de leurs interactions. C’est aussi une discipline majeure en génie logiciel qui a beaucoup évolué au cours des dernières décennies. Elle consiste à étudier et à orienter les choix en phase de conception d’un projet de développement informatique. Ce domaine a gagné en importance ces dernières années car on sait désormais que les mauvaises décisions de conception entraînent à coup sûr l’échec d’un projet.

Qualité d’une architecture logicielle

Les deux principaux objectifs de toute architecture logicielle sont la réduction des coûts et l’amélioration de la qualité du produit.

Une architecture de qualité aura donc un impact positif sur la qualité du produit logiciel. À l’inverse, négliger l’architecture dans le processus de développement logiciel se traduira la plupart du temps par des conséquences désastreuses.

Les architectures logicielles de qualité sont celles qui permettent de créer des systèmes modernes, maintenables et évolutifs. Elles partagent quelques caractéristiques communes que je vais m’efforcer de rappeler brièvement.

L’abstraction

Le principe d’abstraction entre composants est un concept clé en architecture logicielle. Il consiste à diviser un système en couches indépendantes et interopérables dans le but de limiter les adhérences. Les détails de l’implémentation d’un composant ne doivent pas être exposés à d’autres composants. Il est ainsi possible de modifier ou de remplacer les fonctionnalités au sein d’une couche en minimisant les impacts sur le reste de l’architecture du la solution.

L’extensibilité

Une bonne architecture doit favoriser les développements futurs du logiciel en réponse à l’évolution des besoins de l’organisation. Bien qu’il ne soit pas possible de prédire la nature de ces changements, l’architecture doit être conçue de manière à permettre des modifications et des extensions sans nécessiter de changements significatifs du code existant. On fait souvent référence au principe “ouvert-fermé” pour décrire ce type de comportement.

La simplicité

La complexité dans une architecture logicielle va engendrer de la dette technique, mais également affecter négativement la performance et l’évolutivité des applications. Cette complexité est souvent due à une conception médiocre, à une ingénierie excessive ou à des défauts dans la conception globale. Pour garantir la simplicité, l’architecture doit être compréhensible et se conformer à des modèles de conception reconnus.

La modularité

Le système logiciel doit être divisé en modules ; chaque module remplissant une fonction spécifique. La modularité contribue à la production d’un code bien organisé, facile à comprendre et à modifier. Elle facilite le développement, le test et la maintenance du système. Une conception logicielle qui divise une application en modules plus petits et autonomes permet d’envisager plus facilement la réutilisation de ces modules dans d’autres applications. Les développeurs peuvent utiliser des bibliothèques de modules pour accélérer les nouveaux développements.

Le recours aux normes et aux standards

Les normes et les standards sont des règles et des directives qui, lorsqu’elles sont adoptées, contribuent à une utilisation efficace et sécurisée des technologies mises en œuvre dans les projets informatiques. Les architectures logicielles respectant ces règles et directives permettent d’améliorer la qualité des systèmes informatiques en garantissant leur interopérabilité, leur portabilité et leur compatibilité avec d’autres systèmes. Les normes et les standards permettent également de réduire les coûts de développement et de maintenance tout en facilitant la collaboration entre les différents acteurs impliqués dans le processus de développement.

Cette liste n’est probablement pas complète mais elle donne une bonne vision des principes que tout bon architecte va s’efforcer d’appliquer pour élaborer l’architecture d’un système, qu’il s’agisse d’une application ou du Système d’Information dans son ensemble.

La norme ISO 25010 propose une autre classification basée sur deux catégories principales : la qualité d’utilisation et la qualité du produit. La qualité du produit est-elle même définie selon huit critères : fonctionnalité, fiabilité, performance, compatibilité, utilisabilité, sécurité, maintenabilité et portabilité. Ces propriétés fournissent une terminologie cohérente pour la spécification, la mesure et l’évaluation de la qualité des systèmes et des produits logiciels. Un autre article de Redsen traite plus spécifiquement de la qualité du code.

Revue des principaux modèles d’architecture logicielle

Les architectures logicielles « de qualité » reposent généralement sur des modèles ou styles d’architecture bien établis. L’idée est simple et largement répandue. Plutôt que de créer une architecture de toutes pièces, les architectes et les développeurs vont chercher à appliquer des principes de conception éprouvés. On définit les modèles d’architecture logicielle comme des solutions réutilisables en réponse à des problèmes de conception courants.

Le recours à ces modèles ou patrons d’architecture en phase de conception va permettre aux équipes informatiques de revisiter et de se réapproprier deux objectifs :

• Faciliter le développement, le déploiement et l’évolution des solutions informatiques. Il s’agit de rendre tout ajout ou modification simple et rapide en maximisant la productivité des développeurs.
• Maximiser l’interopérabilité et la compatibilité au sein du SI et avec les Systèmes d’Information externes.

Certains des modèles présentés dans cet article s’appliquent davantage à la conception de l’architecture d’une application alors que d’autres concernent plutôt le Système d’Information pris dans son ensemble. Pris deux à deux, ils ne sont ni systématiquement exclusifs, ni systématiquement complémentaires.

Les modèles d’architecture bien ancrés dans les projets

L’architecture en couches

est un modèle de conception logicielle largement adopté dans l’ingénierie logicielle moderne. Elle compartimente le système en couches logiques, où chaque couche exécute un ensemble spécifique de fonctions. Les couches sont autonomes, ce qui signifie que les changements réalisés sur une couche n’affectent pas les autres. Le nombre de couches dans une architecture logicielle peut varier en fonction des besoins et des choix de conception. Une architecture en couches typique peut comporter entre trois et cinq niveaux, allant de la couche d’interface utilisateur à la couche d’accès aux données en passant par les couches de présentation, de logique métier et de services. Cette approche permet une meilleure organisation et une simplification de la complexité des systèmes. La séparation des responsabilités facilite le développement, le test et la maintenance. Attention cependant au nombre de niveaux implémentés. Ajouter plus de couches peut augmenter la complexité du système et avoir un impact sur les performances. Il est nécessaire de trouver un juste équilibre entre les objectifs de modularité et d’abstraction, et l’objectif de performance.

Le schéma Modèle-Vue-Contrôleur (MVC)

Le schéma Modèle-Vue-Contrôleur (MVC) est un modèle de conception utilisé pour structurer les développements informatiques. Il segmente une application en trois parties distinctes : le modèle, la vue et le contrôleur. Le modèle représente les données de l’application et les règles métier qui y sont associées. La vue est responsable de l’interface utilisateur et de son affichage. Le contrôleur gère les interactions de l’utilisateur avec l’application et fait le lien entre le modèle et la vue. Il s’agit d’un type particulier de modèle en couches. Grâce à cette séparation des responsabilités, le schéma MVC permet une meilleure organisation du code et facilite la maintenance et l’évolution de l’application.

Le modèle basé sur les composants

décompose le logiciel en composants réutilisables dotés d’interfaces bien définies, ce qui améliore la réutilisation et la maintenance du code. Toutefois, une fragmentation excessive peut entraîner des difficultés dans la gestion des dépendances. Dans tous les cas, les interactions entre les composants doivent être gérées avec soin.

Le modèle d’architecture de type pipe-filter

est un style d’architecture logicielle popularisé par les systèmes Unix dans les années 1970. Il a été conçu autour du concept de « filtres » connectés par des « pipes ». Dans cette architecture, chaque composant du système est un filtre qui transforme ou filtre les données qu’il reçoit du pipe d’entrée puis les renvoie vers le pipe de sortie. Chaque filtre est indépendant des autres et peut être réorganisé ou remplacé sans affecter le reste du système. L’utilisation de ce modèle a permis une grande flexibilité dans la manière dont les systèmes gèrent les flux de données car chaque filtre peut être réutilisé dans différents pipelines pour obtenir des fonctionnalités différentes. Mais il faut aussi souligner que la gestion du séquencement et des interactions des filtres peut rapidement devenir complexe.

Le modèle de type courtier

introduit un élément central (le broker) qui gère la communication entre les composants distribués. Le courtier joue le rôle de coordinateur et établit les communications entre les différents composants d’un système ou d’une application. Ce modèle centralisé offre une meilleure gestion et un meilleur contrôle des communications. Il apporte des avantages significatifs en termes de flexibilité, de modularité, de réutilisabilité et de sécurité. Son adoption n’est cependant pas sans inconvénients. Le noeud central constitue un point de défaillance unique (single point of failure) et le routage des messages peut s’accompagner de latences. La capacité du courtier peut limiter la scalabilité de l’ensemble du système.

Le bus de messages

Dans ce modèle, les composants communiquent par l’intermédiaire d’un bus en publiant des messages et en s’y abonnant. Il s’agit d’un modèle d’architecture conçu pour une communication asynchrone distribuée. Il permet de créer des solutions ou des systèmes évolutifs, basés sur l’implémentation de composants faiblement couplés. L’utilisation du modèle peut toutefois conduire à des interactions complexes, difficiles à maintenir.

Les modèles d’architecture émergents

L’architecture pilotée par les événements (EDA)

est un modèle d’architecture logicielle asynchrone qui repose sur le traitement et la persistance de tout événement significatif. Dans ce type de conception, les événements sont utilisés comme moyen de communication entre les composants logiciels. Cette approche est donc adaptée à la conception de systèmes ou d’applications modernes distribués. Elle offre plusieurs avantages, notamment une meilleure évolutivité, une plus grande souplesse et une plus grande réactivité. Le modèle EDA se distingue nettement du bus de messages décrit précédemment. Tous deux sont utilisés pour concevoir des systèmes ou des applications qui nécessitent une communication asynchrone. Néanmoins, l’architecture de type bus de messages utilise un intermédiaire pour distribuer des messages, tandis que l’architecture pilotée par les événements utilise des gestionnaires d’événements pour déclencher des actions en réponse aux événements.

L’architecture en micro-services

est un modèle qui permet de décomposer un large système logiciel en services plus petits et faiblement couplés qui communiquent via des API. Chaque micro-service est conçu pour effectuer une fonction métier spécifique. Les différents micro-services de l’architecture peuvent être développés, déployés et mis à l’échelle de manière indépendante. Le modèle offre plusieurs bénéfices tels qu’une meilleure rapidité de développement, davantage d’évolutivité, une plus grande résilience et une flexibilité accrue. Il est à la base de la construction des applications cloud-native. En revanche, ce type d’architecture est complexe à implémenter. Il est difficile d’assurer la cohérence des données entre les services. De plus, la surcharge de communication entre les services peut avoir un impact négatif sur les performances.

L’architecture sans serveur

également connue sous le nom de « serverless », est un modèle de développement informatique dans lequel le fournisseur de services cloud gère entièrement l’infrastructure du serveur et l’allocation de ressources. Elle offre la possibilité d’exécuter du code hébergé dans le cloud en réponse à des événements, sans qu’il soit nécessaire de disposer d’une infrastructure. Les développeurs n’ont pas besoin de se soucier de la gestion des serveurs ou de l’infrastructure et peuvent se concentrer sur le développement de leurs applications. Ce modèle gagne en popularité car il présente plusieurs avantages, notamment la réduction des coûts d’exploitation, ainsi que l’amélioration de l’évolutivité et la flexibilité des applications.

La conception pilotée par le domaine (DDD)

est une approche de conception de logiciels qui se concentre sur la compréhension approfondie du domaine d’application avant de commencer à écrire du code. Les développeurs peuvent ainsi créer des modèles de données et des architectures logicielles qui reflètent fidèlement le domaine d’application. L’utilisation de ce modèle est intéressante à plus d’un titre. Elle permet une meilleure collaboration entre les développeurs et avec les experts métier du domaine, une plus grande facilité de maintenance et une meilleure qualité du code. Cette conception présente aussi certains inconvénients qui doivent être pris en considération. Elle est complexe à mettre en oeuvre et nécessite une courbe d’apprentissage relativement longue pour avoir une compréhension suffisante des règles métier et des problèmes posés. Elle peut également conduire à faire de la « sur-ingénierie » sur des modèles complexes et en partie inutiles.

En conclusion

L’architecture représente un aspect essentiel du développement des produits logiciels. Une architecture bien conçue doit, en principe, contribuer à la qualité et à la performance du système, tandis qu’une architecture mal pensée peut, à terme, entraîner des problèmes et des limitations. La conception de l’architecture logicielle est donc une activité majeure de l’ingénierie logicielle.

Cependant, aboutir à la conception d’un système à la fois robuste et évolutif demande du temps et des efforts.

C’est la raison pour laquelle les modèles d’architecture sont devenus incontournables. Chacun d’entre eux propose une approche particulière pour la conception d’une architecture logicielle. Ils apportent des réponses à des problèmes de conception courants et sont utilisés pour guider la conception et le développement de logiciels complexes. Leurs utilisations conjointes doivent aboutir à la construction de système correctement organisés, maintenables et évolutifs.