Dans ce chapitre, nous allons aborder l'architecture centrée sur les données (data-centric architecture), en quoi elle consiste et pourquoi elle est utile dans certaines situations. À la fin du chapitre, je vous montrerai un exemple concret (l'université Sainte-Trinette), puis vous résoudrez un cas similaire en appliquant ce que vous avez appris. Alors, prêt ?
Qu'est-ce qu'une architecture centrée sur les données ?
Avez-vous déjà acheté un billet d'avion en ligne ? Parfois, lorsque vous effectuez votre achat, le site web vous recommande un hôtel, une société de location de voitures et même d'autres choses. Parfois, ces offres continuent à apparaître les jours suivants (par e-mail), ou après que vous soyez rentré de voyage.
La compagnie aérienne a une stratégie de vente : elle identifie différents types de clients et définit différentes actions à mener avec chaque client après l'opération d'achat. Voici un exemple de ce à quoi pourrait ressembler une telle stratégie :
Type de client | Définition | Prochaines étapes après l'achat |
1 | Entre 21 et 35 ans. Il voyage en solo. Il paie avec une carte de crédit premium. |
|
2 | Entre 21 et 35 ans. Voyages avec son conjoint. Il a acheté deux billets sur le même vol. |
|
Ce schéma se poursuit pour les types de clients 3, 4, 5 et jusqu’à 20.
Supposons maintenant que la stratégie marketing de la compagnie aérienne change, que vous n'ayez plus 20 types de clients, mais 25, et que vous mettiez à jour les « prochaines étapes » après l'achat.
Allez-vous réécrire le code du module de vente dans votre système logiciel à chaque fois que la stratégie marketing change ? Pas du tout. Une bonne pratique est d'inclure un tableau comme ci-dessus dans la base de données du système, et de faire en sorte que le logiciel lise le tableau et agisse en conséquence pour chaque type de client. De cette façon, si la stratégie marketing change, vous ne devrez modifier que le tableau et non le code.
C'est comme ça que fonctionne une architecture centrée sur les données. Elle utilise des règles basées sur des tableaux (par opposition aux règles basées sur des codes) pour gérer les différentes catégories et actions à effectuer après un événement donné. Ces tableaux sont appelés tables de contrôle et permettent aux programmes d'être plus simples et plus flexibles.
Quelle est la structure de l'architecture centrée sur les données ?
Voyons à quoi cela ressemble :
Comme vous pouvez le voir dans le schéma ci-dessus, une architecture centrée sur les données standard comporte cinq parties :
Le système logiciel (Software System) : Le système développé en utilisant le modèle d'architecture centré sur les données.
Les tableaux de contrôle (Control Tables) : Un ensemble de tableaux qui définissent les actions que le système doit exécuter pour chaque catégorie.
Les catégories (Categories) : Un ensemble de catégories d'un élément dans le système (types de clients, types de produits, types d'articles, types d'employés) utilisé pour exécuter des actions.
Les actions à exécuter (Action Items) : Un ensemble d'actions à exécuter pour une certaine catégorie.
Les règles de gestion (Business Rules) : Les règles de gestion qui déterminent les actions à exécuter en fonction des catégories.
Si vous avez un groupe spécifique de personnes qui peuvent définir les catégories ou les actions à exécuter ou les deux, vous devez les ajouter au diagramme. Habituellement, on les représente en ajoutant une boîte avec leur nom, et le lien avec les catégories ou les actions à exécuter via une flèche.
Comment cela fonctionne-t-il en pratique ?
Nous avons un système logiciel qui vend des billets d'avion en ligne.
Le système dispose d'un ensemble de tables de contrôle qui mettent en œuvre la stratégie de vente de l'entreprise.
Il existe de nombreuses catégories de clients, et des actions pour chaque catégorie (vous pouvez voir un extrait de ces catégories dans le tableau des types de clients précédent).
Ces définitions répondent à des règles de gestion qui proviennent de la stratégie de vente.
L'utilisation d'une architecture centrée sur les données présente plusieurs avantages :
Si des catégories changent ou sont ajoutées, il n'est pas nécessaire de modifier le code.
Les règles de gestion sont beaucoup plus faciles à gérer dans un tableau que dans un ensemble de programmes.
Il existe également quelques inconvénients majeurs :
Ce schéma peut poser des problèmes de performance car chaque fois que le code s'exécute, il doit rechercher des données dans une table.
Si la table de contrôle est endommagée, l'ensemble du système ne fonctionne plus.
Quand utiliser l'architecture centrée sur les données ?
Alors, quelles sont les situations où cela peut être utile ?
Nom de l'exemple | Définition | Exemple concret | Avantages |
Système CRM (gestion de la relation client) des compagnies aériennes | Le CRM est un système logiciel qui gère les relations personnalisées avec les clients d'une entreprise. Les campagnes de marketing, le service Client et les campagnes de ventes croisées sont généralement gérés par un système CRM. |
| Un système CRM peut s'occuper de millions de clients. Il serait impossible de faire la même chose manuellement. Les systèmes de gestion de la relation client ont été introduits dans les années 90 et ont permis d'augmenter considérablement la productivité des ventes. |
Module de paiement de commissions | Faisant généralement partie d'un système de vente, un module de paiement de commissions est une application qui calcule les commissions des vendeurs et organise les paiements correspondants dans une période prédéfinie. | Tout système de vente dispose d'un module de paiement de commissions. | Les modules de paiement de commissions disposent généralement d'une table de types de commissions qui détermine le calcul de la commission et représente la politique de l'entreprise en matière de paiement des commissions de vente. |
Étude de cas : Résoudre un problème d'entreprise avec l’architecture centrée sur les données
Appliquons ce que vous avez appris sur l'architecture centrée sur les données et voyons comment elle fonctionne dans une organisation réelle.
L'université Sainte-Trinette est une université imaginaire. Voici quelques généralités :
L'université compte plus de 45 000 étudiants pré et postlicence.
L'université met à jour son système logiciel pour les nouveaux étudiants, les diplômes, la gestion des frais de scolarité et des prêts étudiants.
Quelle est la problématique ?
L'université souhaite définir des actions pour les catégories d'étudiants en fonction de certaines règles. Ces actions sont issues d'une politique de communication établie par le conseil d'administration. Par exemple : « Si un prêt étudiant est approuvé, nous devons envoyer un courriel à l'étudiant, à ses parents ou à ses tuteurs et mettre à jour nos dossiers administratifs sur les frais de scolarité en conséquence. »
Analysons cette situation !
Imaginez qu'il existe de nombreuses catégories d'étudiants à l'université : diplômés, étudiants de premier cycle, étudiants ayant demandé un prêt, étudiants dont le prêt a été approuvé, étudiants âgés de 16 à 21 ans, étudiants de plus de 21 ans, étudiants internationaux, etc.
Un étudiant peut appartenir simultanément à plusieurs catégories.
Les actions définies par le conseil d’administration sont exécutées pour un groupe de catégories d'élèves, généralement, si elles se produisent ensemble. Par exemple : « Si l'étudiant est étranger et qu’il a demandé un prêt, alors faites X, Y, Z ».
Nous ne voulons pas réécrire le code chaque fois que le conseil met à jour ou crée des mesures à prendre pour une catégorie donnée.
C'est un scénario parfait pour une architecture centrée sur les données : il doit y avoir une table pour les actions à exécuter selon les catégories, et le système doit rechercher chaque entrée de la table afin d'agir.
Quelle est la solution ?
Voyons maintenant le schéma d'architecture détaillé de cette solution :
Voyons en détail chaque composant du système ERP :
Le système administratif : Il s'agit du système développé pour l'université.
Les tables de contrôle : Il s'agit d'un ensemble de tables qui définissent les mesures que le système doit prendre pour chaque catégorie en fonction des décisions du conseil.
Le conseil d'administration : Il s'agit d'un groupe de directeurs, d'administrateurs ou de conseillers d'une université ou d'une école, qui définit la stratégie de l'établissement pour inscrire des étudiants et maintenir un programme d'études adéquat et un niveau de qualité souhaité.
Les catégories : Il s'agit d'un ensemble de catégories d'étudiants.
Les actions à exécuter : Il s'agit d'un ensemble d'actions à exécuter pour une certaine catégorie.
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 : Imaginons que vous soyez architecte logiciel chez un grand opérateur de téléphones portables. On vous a demandé de développer un système logiciel pour gérer les relations avec certaines catégories de clients telles que les particuliers, les entreprises, les associations, les administrations, les nouveaux clients, les nouveaux prospects, les organisations, etc.
Votre mission : Maintenant, c'est à vous de créer une architecture pour l’opérateur !
Voici quelques questions clés que vous pouvez vous poser pour commencer :
Un client peut appartenir à plusieurs catégories. Comment allez-vous définir les actions à entreprendre pour un groupe de catégories ?
Qui devez-vous interroger dans votre organisation au sujet des catégories de clients ? Qui doit informer les développeurs des modifications apportées aux politiques marketing ?
Que se passe-t-il si les actions changent en fonction de nouvelles politiques marketing de l'entreprise ?
Pouvez-vous créer un schéma d'architecture pour ce contexte commercial ?
En résumé
Modèle d'architecture | Description | Avantages | Inconvénients | Quand l'utiliser |
Centrée sur les données | Une structure d'application qui utilise les données au lieu du code pour prendre des décisions de comportement. | Il n'est pas nécessaire d'analyser tous les cas dans le code. Les catégories peuvent s'étendre indéfiniment. Des modifications peuvent être apportées sans changer le code. | Peut devenir compliqué à comprendre et à gérer lorsqu'il y a de nombreuses catégories. | Lorsqu’il y a de nombreuses catégories différentes et que vous devez agir différemment pour chacune d'entre elles. |
