Définissez votre architecture logicielle grâce aux standards reconnus

Dans ce chapitre, nous allons aborder l'architecture client-serveur (client-server architecture), en quoi elle consiste et quand vous devez l'utiliser. À la fin du chapitre, je vous montrerai un exemple concret (la société minière IrisGold), puis vous devrez résoudre un cas similaire en appliquant ce que vous avez appris.

Qu'est-ce que l'architecture client-serveur ? 

Vous est-il déjà arrivé d’entrer dans un restaurant et de commander votre repas directement au cuisinier ? C’est peu probable. Normalement, vous vous asseyez à une table et vous attendez qu’un serveur vienne prendre votre commande. Vous lui dites ce que vous voulez manger et celui-ci va dans la cuisine et le dit au cuisinier. C'est logique. Vous n'utilisez pas nécessairement le bon jargon pour le cuisinier, et ce dernier ne sait peut-être pas à quelle table envoyer votre plat lorsqu'il est prêt. L'intermédiaire : le serveur, est dans notre cas efficace. D'autant plus que la chose la plus importante pour vous, c’est que votre commande soit correcte. Le cuisinier se moque de qui vous êtes tant qu'il obtient les instructions dont il a besoin.

L'architecture Client-Serveur fonctionne selon le même principe : elle répartit les tâches entre les fournisseurs d'un service, appelés Serveurs, et les consommateurs du service, appelés Clients. Un Serveur est comme le cuisinier dans notre métaphore du restaurant, et le Client est le consommateur. 

Tout comme le véritable client du restaurant, les Clients initient généralement des sessions de communication avec les Serveurs qui attendent les demandes entrantes. Le dispositif (ordinateur portable, tablette, smartphone) qu'un Client utilise pour demander un service au Serveur est comme le serveur du restaurant de notre exemple : il sert de médiateur entre le consommateur de service et le fournisseur de service, et sait comment parler avec les deux.

Quelle est la structure de l'architecture client-serveur ? 

Voyons à quoi cela ressemble :

Comme vous pouvez le voir dans le schéma ci-dessus, une architecture Client-Serveur standard comporte trois parties :

• Le Front-End : Il s'agit de la partie du logiciel qui interagit avec les utilisateurs, même s'ils se trouvent sur des plateformes différentes avec des technologies différentes. Dans une architecture Client-Serveur, les modules front-end sont conçus pour interagir avec tous les appareils existant sur le marché. Cela comprend les écrans de connexion, les menus, les écrans de données et les rapports qui fournissent et reçoivent des informations des utilisateurs. Par exemple, la plupart des outils et frameworks de développement permettent de créer une version du programme qui fonctionne à la fois pour les PC, les tablettes et les téléphones.
  Le front-end est comme le client du restaurant, et le matériel (PC, tablette ou téléphone) est comme le serveur du restaurant.

• Le serveur d'application (Application Server) : Il s'agit du Serveur où sont installés les modules logiciels de l'application. Il se connecte à la base de données et interagit avec les utilisateurs. Le serveur d'application est comme le cuisinier du restaurant de notre exemple.

• Le serveur de base de données (Database Server) : Il contient les tables, les index et les données gérés par l'application. Les recherches et les opérations d'insertion/de suppression/de mise à jour sont exécutées ici. 

1. L'utilisateur (User) fait une demande via le front-end, par exemple : « Donne-moi toutes les factures des clients du 1er janvier jusqu’à aujourd'hui, pour les clients qui ont acheté le produit X ».

2. Le serveur d'application reçoit cette demande et l'envoie à la base de données. Le serveur de base de données exécute cette requête et envoie la réponse au serveur d'application, qui renvoie le résultat au client à l'aide du module front-end.

L'utilisation de l'architecture Client-Serveur présente plusieurs avantages :

• Comme vous pouvez le voir dans notre exemple, l'architecture Client-Serveur sépare le matériel, le logiciel et la fonctionnalité du système. Par exemple, si une adaptation du logiciel est nécessaire pour un pays spécifique, autrement dit si un changement de fonctionnalité est nécessaire, celui-ci peut être adapté dans le système sans avoir à développer une nouvelle version pour les téléphones, les tablettes ou les ordinateurs portables.

• Puisque cette architecture sépare le matériel, le logiciel et la fonctionnalité du système, seule la partie front-end doit être adaptée pour communiquer avec différents appareils.

Il existe également quelques inconvénients majeurs :

• Si tous les Clients demandent simultanément des données au Serveur, celui-ci peut être surchargé. 

• Si le Serveur tombe en panne pour une raison quelconque, aucun utilisateur ne peut utiliser le système.

Maintenant que vous savez comment cette architecture fonctionne, voyons comment l'utiliser !

Quand utiliser l'architecture client-serveur ? 

Voici quelques situations réelles où cette architecture peut être utile :

Étude de cas : Résolution d’un problème métier grâce à l'architecture client-serveur 

Appliquons ce que vous avez appris sur l'architecture Client-Serveur et voyons comment celle-ci a été utilisée dans une véritable entreprise.

IrisGold est une société d'extraction d'or. Voici quelques généralités :

• IrisGold est présente sur trois continents, avec plus de 21 000 employés. 

• Les mines de la société sont pour la plupart situées dans des endroits reculés comme l'Amazonie au Brésil, la chaîne de montagnes des Andes, les montagnes de l'Oural en Russie et l'est de l'Afrique du Sud. 

• L'entreprise est en train de choisir un progiciel de gestion intégré (ERP). En quoi cela influence-t-il votre décision ? 

Quelle est la problématique de l'entreprise ?

IrisGold souhaite déployer et exploiter son nouvel ERP en toute sécurité. Cependant elle a deux grandes contraintes :

1. Ses utilisateurs se trouvent dans des endroits reculés à travers le monde et disposent de différents types d'appareils (ordinateurs portables, notebooks, téléphones, tablettes). 

2. Les appareils des clients doivent être légers : il doit s'agir d'un simple ordinateur portable, d'une tablette ou d'un téléphone doté de quelques capacités de traitement et de stockage, et capable de communiquer avec un serveur distant. 

C'est à nous de concevoir une architecture qui prendra en charge ces besoins commerciaux.

Commençons par les faits !

Tout d'abord, examinons le nombre d'employés et l'utilisation de la technologie. L’entreprise est immense et internationale. Les grandes entreprises avec de nombreuses personnes réparties en divers endroits sont généralement caractérisées par des pratiques diverses en matière d'utilisation des technologies. Nous pouvons déjà en déduire qu'il existe probablement une diversité de plateformes, de systèmes d'exploitation, de matériel, de logiciels et de composants de communication nécessaires au fonctionnement des systèmes d'administration et de production. Cela se confirme dans la problématique de l'entreprise : les employés du monde entier utilisent tous des appareils différents.

Nous avons donc besoin d'un système qui garantisse que tous les appareils puissent communiquer avec un module front-end, et que ce module communique avec le système ERP. En outre, les dispositifs doivent être légers et dotés de quelques capacités de stockage et de traitement. Il suffit donc que les clients puissent se connecter à un serveur central. Un modèle Client-Serveur est une solution parfaite pour ces deux situations. 

Ensuite, passons en revue la nature du système ERP. Ce type de système devra gérer les ressources de l'entreprise telles que les liquidités, les matières premières, les ressources humaines, la capacité de production et le statut des engagements de l'entreprise tels que les factures, les bons de commande et les salaires. En pratique, certains modules du système ne seront accessibles qu'à un groupe restreint d'employés du département des ressources humaines.

Alors comment gérer l'accès des utilisateurs ? Nous pouvons nous assurer qu'il existe une table dans une base de données centrale qui spécifie les menus du système auxquels un utilisateur particulier peut accéder.

Enfin, examinons à nouveau les endroits où le système sera utilisé. La logistique est un élément clé  : la plupart des sites sont éloignés et difficiles d’accès, ce qui signifie qu'ils auront probablement des problèmes de communication et d'accessibilité. Mais les données d’ERP avec lesquelles nous travaillons doivent être sécurisées, malgré ces contraintes.

Comment pouvons-nous répondre à cette exigence ? En plaçant la plupart des composants du système ERP au siège social d'IrisGold. Les utilisateurs peuvent communiquer avec ce système central par le biais de leurs appareils, mais ces derniers ne stockent pratiquement aucune donnée. Cela répond également au besoin de légèreté des dispositifs !

Donc, pour résumer :

• Nous savons que les utilisateurs sont dispersés dans le monde entier et utilisent différents appareils qui doivent être légers. 

• Nous savons que les utilisateurs ont des capacités d'infrastructure déficientes et travaillent dans des endroits éloignés de tout.

• Il suffit que les clients puissent se connecter à un serveur central.

• Le système ERP installé sur le serveur central doit couvrir toutes les règles de gestion. En substance, il doit gérer en interne tous les modules pour tous les pays, et répondre aux demandes des clients en communiquant avec une base de données centrale.

Quelle est la solution ?

Maintenant que nous avons procédé à cette réflexion, voyons le schéma d'architecture détaillé :

Voyons en détail chaque composant du système ERP :

• Le Front-End : Il s'agit de l'élément du logiciel qui interagit avec les utilisateurs de l'ERP, même s'ils se trouvent dans des pays différents.

• Le serveur ERP : Il s'agit du serveur où le logiciel ERP est installé.

• Le serveur de fichiers : Le serveur ERP demande des fichiers au serveur de fichiers pour répondre aux demandes des utilisateurs. Exemples : une facture imprimée au format PDF, un rapport, un fichier de données dont l'utilisateur a besoin. L'installation d'un serveur de fichiers est une bonne pratique lorsque l'application compte de nombreux utilisateurs qui lisent, mettent à jour ou écrivent fréquemment des fichiers. 

• Le référentiel des règles métier : Un référentiel de procédures, de méthodes et de réglementations commerciales pour chaque pays (toutes différentes), afin que l'ERP fonctionne selon les besoins propres à chaque pays. Ce repository est souvent séparé du logiciel afin de rendre les personnalisations plus agiles et plus sûres. Il s'agit d'une bonne pratique introduite par les ERP dans les années 1990, et qui s'est étendue à de nombreux autres types d'applications.

• Le serveur de base de données : Ce serveur contient les tables, les index et les données gérées par le système ERP. Exemples : tableau des clients, tableau des fournisseurs, liste des factures, tableaux des stocks, identifiants des produits, etc.

Tous les traitements lourds sont effectués au siège d'IrisGold. Les clients sont légers ; c'est pourquoi on les appelle « clients légers ». Ils ne traitent ni ne stockent de grandes quantités de données. Ils ne font que communiquer avec le serveur.

L'essence même de l'architecture Client-Serveur est que chaque composant illustré dans le schéma est situé dans le centre de données général (au siège social d'IrisGold). Tous les utilisateurs se connectent à ces composants par le biais de leurs appareils.

Essayez vous-même !

Maintenant que vous avez découvert une solution, voyons si vous pouvez appliquer ce que vous avez appris à un autre cas !

Le contexte : Imaginez que vous soyez architecte logiciel dans une grande banque. Votre patron est John, le directeur des systèmes d'information (DSI). La banque compte 2 400 agences dans le pays, et plus de 16 000 employés.

Votre mission : On vous demande de développer un système logiciel pour gérer les ressources humaines de la banque. Ce système comprend des modules tels que :

• L’administration des employés : il gère la création de nouveaux employés dans le système, met à jour les données des employés existants ainsi que ceux qui ne travaillent plus pour la banque.

• L’évaluation des performances : il gère les résultats et analyse les évaluations semestrielles des performances des employés. Tous les secteurs de la banque organisent des sessions d'évaluation au cours desquelles les employés reçoivent un feedback de la part de leurs supérieurs, et expriment leurs objectifs pour le trimestre à venir.

• La planification du parcours de carrière : le département RH élabore le parcours de carrière futur souhaité pour l'employé. Ce parcours est discuté à la fin de chaque session d'évaluation des performances.

• Le programme de formation : le département RH analyse les besoins de formation pour chaque département de la banque et élabore les programmes de formation en conséquence, en faisant parfois appel à des prestataires externes.

• La paie : le département RH est responsable du paiement correct des salaires de tous les employés de la banque. Ce module gère les salaires, les primes, les commissions, les vacances, les congés et le paiement des salaires de tous les employés.

Maintenant, c'est à vous de créer une architecture pour la banque ! Pour commencer, voici quelques questions que vous pouvez vous poser :

1. Les ordinateurs et les postes de travail de la banque sont dotés de nombreuses technologies, plateformes et systèmes d'exploitation différents. Comment allez-vous résoudre ce problème ? 

2. Les données de l'ERP doivent être sécurisées, même si les utilisateurs sont dispersés dans tout le pays. Comment allez-vous répondre à cette exigence ?

3. Certains modules du système ne sont accessibles qu'à un groupe restreint d'employés du département RH. Comment allez-vous résoudre ce problème ?

Pouvez-vous créer un schéma d'architecture pour ce contexte commercial ?

En résumé