Création d’un moteur de règles métier agile sur AWS

Les mutuelles ou les compagnies d’assurance sont souvent régies par des membres et ont des règles commerciales et/ou d’adhésion qui régissent les subventions d’adhésion. Ces règles sont classées en règles d’inclusion et règles d’exclusion.

Les règles d’inclusion sont des règles commerciales qui récompensent les clients qui répondent à certains critères, tels que l’achat d’obligations ou d’instruments financiers de grande valeur, et l’ancienneté ou l’association avec l’entreprise.

Inversement, les règles d’exclusion sont définies pour mettre à jour/accorder/révoquer l’adhésion en fonction des activités des membres, telles que l’achat de certains produits ou types de produits, ou le fait d’avoir un rôle secondaire sur le produit (en particulier les produits qui ont des participations communes).

Lorsqu’elles sont mises en œuvre dans des systèmes sur site hérités, ces règles ont tendance à être de nature rigide et à avoir un impact sur l’agilité de l’entreprise. Les utilisateurs professionnels qui dépendent du service informatique pour apporter des modifications et des mises à jour aux règles déclenchées par l’évolution des exigences commerciales ou réglementaires doivent planifier la disponibilité des ressources de développement, la gestion des modifications, les délais de développement des règles et les coûts de projet associés.

Cela inhibe la capacité d’une organisation à être agile et à servir efficacement ses membres, à augmenter le nombre de ses membres et à s’adapter rapidement à l’évolution des exigences commerciales ou réglementaires.

Dans cet article, nous allons explorer comment Capgemini utilise Amazon Web Services (AWS) pour créer une solution simple, agile et configurable qui implémente des règles commerciales et d’adhésion sur les données client ou de référence. Ceci est encore amélioré en utilisant des métadonnées pour introduire ou modifier des règles commerciales supplémentaires.

Un tel modèle de conception peut être facilement personnalisé pour un cas d’utilisation commerciale supplémentaire ; pas seulement des clients ou des membres.

Capgemini est un Partenaire consultant AWS Premier et Managed Service Provider (MSP) avec une équipe multiculturelle de 220 000 personnes dans plus de 40 pays. Capgemini possède plus de 12 000 accréditations AWS et plus de 4 900 certifications AWS actives.

Architecture de haut niveau

Le schéma ci-dessous illustre l’architecture de haut niveau d’un moteur basé sur des règles sur AWS. Les principaux composants de cette architecture sont :

• Référentiel de règles qui stocke les règles métier.
• Magasin de données qui héberge les enregistrements client ou la fiche client.
• Moteur de traitement.
• Magasin de données pour capturer les résultats du traitement et tenir à jour un registre des membres.
• Mécanisme d’orchestration de flux de travail de bout en bout.

Cette architecture prend en charge le nettoyage et la déduplication des données client, ainsi que la création de données de référence lorsqu’une organisation peut avoir plusieurs sources de données client.

De par sa conception, le moteur de règles est configurable, permettant des règles métier configurables et gérées avec des métadonnées spécifiques aux règles pour le type d’instance de règle, la catégorie, etc. Les résultats de l’évaluation des règles sont enrichis et capturés avec des détails pour maintenir l’historique afin de comprendre le parcours du membre.

Figure 2 montre comment une telle architecture peut être réalisée à l’aide de services gérés natifs AWS qui réduisent les dépenses liées aux activités de maintenance opérationnelle, telles que les correctifs et la gestion de la capacité, tout en fournissant un accès programmatique à la fonctionnalité de service. Cela permet l’excellence opérationnelle via l’automatisation.

Présentation de la solution de mise en œuvre AWS

La première étape de la mise en œuvre de cette solution consiste à obtenir toutes les données client et associées nécessaires pour exécuter les règles métier dans votre lac de données. Le lac de données sert d’emplacement central pour toutes les sources de données sur lesquelles le moteur de règles s’exécutera.

D’autres points importants à prendre en compte lors de la mise en œuvre du lac de données sont :

• Identifiez les éléments de données critiques qui seraient nécessaires pour exécuter vos règles métier et les systèmes source qui contiennent ces éléments de données.
• Si vous disposez de plusieurs sources de données client, vous pouvez utiliser un outil de gestion des données de référence (MDM) tel qu’Informatica, Reltio ou d’autres outils tiers pour fusionner les données client.
• S’il existe une source dorée de données client, celle-ci peut être utilisée pour identifier les adhésions.
• Assurez-vous que les données client peuvent être jointes à d’autres éléments de données tels que le produit, le service et les rôles afin que les règles métier puissent être évaluées.

L’implémentation utilise les services AWS suivants :

Service de stockage simple d’Amazon (Amazon S3)

AmazonS3 est utilisé pour créer un lac de données de toutes les données nécessaires au traitement du moteur de règles. En tant qu’aspect du magasin de données de l’architecture, les lacs de données sur S3 bénéficient de sa durabilité de 99,999999999 % (11 neuf) et de sa nature de magasin d’objets, permettant au lac de données de contenir plusieurs formats de données, ensembles de données et de pouvoir être consommé par une variété de services dans les applications AWS et tierces.

Toutes les informations client de l’environnement source sont extraites et placées sur le lac de données pour un traitement ultérieur par le moteur de règles.

Amazone Aurore

Amazone Aurore est utilisé pour configurer et capturer les règles métier avec les métadonnées et les données de référence (telles que les types de règle et d’appartenance) nécessaires pour provisionner une base de données relationnelle simple.

Aurora est un moteur de base de données pour Service de base de données relationnelle d’Amazon (Amazon RDS) et répond aux exigences. Cela fournit également un modèle relationnel qui peut être étendu pour inclure des métadonnées supplémentaires telles que la version de la règle, les règles actives ou inactives.

Ces attributs permettent de comprendre plus facilement le parcours du client/membre et comment et quand ils sont devenus membres, ainsi que les règles en vigueur à ce moment-là, etc.

Notez qu’en fonction de la complexité des règles et des exigences métier sur la fréquence de modification de ces règles, vous souhaiterez peut-être configurer les données de référence en conséquence.

Amazon EMR

Amazon EMR est utilisé pour créer un processeur de données qui peut facilement joindre des données de différents magasins de données et exécuter SQL en mémoire. Il peut également exécuter des règles en parallèle, s’adapter à l’évolution de la charge de l’entreprise et optimiser les coûts en activant des fonctionnalités transitoires afin que vous puissiez réduire les coûts lorsque le système n’est pas utilisé.

Amazon EMR fournit ces fonctionnalités sur AWS pour traiter, analyser et appliquer rapidement le machine learning (ML) au Big Data à l’aide de frameworks open source.

L’architecture utilise Apache Spark sur Amazon EMR en raison de sa flexibilité de pouvoir configurer des conditions et des filtres sur le référentiel de règles. L’utilisation de SQL facilite la création et la maintenance des règles.

Spark exécute ces règles basées sur SQL en parallèle pour identifier les inclusions et les exclusions par rapport à toutes les données client, et peut être utilisé pour se joindre aux autres éléments de données critiques (comme le produit et le service) et pour valider par rapport aux données de référence configurées dans les règles. dépôt.

Sous le capot, le moteur de règles :

• Créez des trames de données des données client à partir du lac de données et du référentiel de règles.
• Lisez les éléments de données client et critiques du lac de données, ainsi que les règles et les données de référence des règles de la base de données Aurora.
• Distribuez et exécutez les règles SQL d’inclusion ou d’exclusion en parallèle sur tous les clients pour vous assurer que chaque client est évalué par rapport à chaque règle.
• Écrivez les résultats de ces exécutions SQL dans un stockage éphémère ou un compartiment S3 pour pouvoir exécuter des évaluations basées sur les résultats d’inclusion et d’exclusion. Cette étape peut être exécutée en mémoire en fonction de votre volume de données et des considérations de performances.

Considérations de conception supplémentaires pour les modules d’inclusions et d’exclusions du moteur de règles :

• Complexité : en fonction de la complexité des règles et des catégories de règles, vous pouvez préférer configurer les instructions SQL complètes dans le référentiel de règles lui-même. L’étape d’évaluation tient compte de toutes les inclusions et exclusions pour chaque client. Si un client est admissible aux inclusions, et selon les exclusions qui s’appliquent, il accordera ou ignorera les adhésions.
• Inclusions et exclusions numériques : pour implémenter des règles métier plus complexes, les règles d’inclusion et d’exclusion peuvent se voir attribuer des pondérations numériques telles que 1, 2, 3 dans la configuration des règles lorsque vous concevez le référentiel de règles. Ce serait une bonne idée d’espacer les poids des règles avec des multiples de 10 comme 10, 20, 30.
• Nécessité d’ignorer : s’il est nécessaire d’ignorer certaines exclusions et de remplacer ces exclusions lorsque certaines règles d’inclusion s’appliquent, ces pondérations peuvent être utilisées dans l’étape d’évaluation. Attribuez des pondérations numériques plus élevées aux règles d’inclusion qui remplacent les règles d’exclusion. Lors de l’évaluation, vous pouvez appliquer une fonction somme à toutes les pondérations de chaque catégorie ; l’agrégat des pondérations d’inclusion et d’exclusion peut être utilisé pour accorder ou ignorer les adhésions en fonction de la valeur la plus élevée.

Le moteur de règles génère un ensemble d’inclusions et d’exclusions de clients étiquetées avec des métadonnées supplémentaires telles que des types d’adhésions. Dans une prochaine étape, ces inclusions et exclusions sont évaluées pour déterminer un résultat binaire qui marquera uniquement les clients qui se qualifient sous les différents types d’adhésion.

Amazon DynamoDB

Amazon DynamoDB stocke les résultats du moteur de règles, car il fournit une base de données NoSQL clé-valeur entièrement gérée, sans serveur, conçue pour exécuter des applications hautes performances à n’importe quelle échelle pour la consommation du système final.

Les enregistrements d’adhésion sont insérés dans une base de données DynamoDB qui conserve l’historique des résultats. Les enregistrements peuvent être insérés dans DynamoDB à l’aide de Python. Ce sera une table d’insertion uniquement pour capturer tout l’historique.

Amazon DynamoDB peut être partitionné sur l’ID client principal et trié à l’aide d’une date de création d’historique. L’avantage de partitionner les données sur la même clé utilisée dans le référentiel client facilite la combinaison de ces ensembles de données. La date de création de l’historique facilite le tri pour générer le parcours du client ou de l’adhérent.

En option, ces résultats peuvent être diffusés à l’aide de flux DynamoDB dans une autre table DynamoDB pour maintenir un registre des membres actuel avec les derniers détails pour un accès facile ou une vue actuelle du registre des membres. Souvent, les entreprises peuvent avoir une autre clé comme le numéro de membre, donc l’avantage d’utiliser une autre table DynamoDB actuelle avec la version actuelle est de pouvoir utiliser une autre clé de partition et permettre un accès plus rapide.

Flux de travail gérés par Amazon pour Apache Airflow (MWAA)

Amazon MWAA est utilisé pour orchestrer le séquencement de flux de travail des événements requis pour ingérer, transformer et charger des données à l’aide d’un service géré. Cela permet aux équipes de développement de se concentrer sur la définition des séquences de flux de travail et de ne pas se soucier de la capacité et de la disponibilité de l’infrastructure sous-jacente.

Conclusion

En utilisant une combinaison de services gérés AWS, Capgemini peut créer un moteur de règles basé sur le cloud qui peut être adapté à l’augmentation du volume de données, facilement configuré et rapidement accessible. Cela permet aux organisations d’être totalement agiles dans le développement de nouvelles règles métier, ou la mise à jour/retrait de règles métier, sans dépendre de l’informatique.

Capgemini, avec son expérience mondiale, sa technologie, ses processus et ses équipes de pointe, peut s’associer à vous pour vous aider à concevoir et à créer des solutions qui peuvent être adaptées pour gérer d’autres règles commerciales moyennes à complexes pour n’importe quel secteur, en utilisant AWS cloud-native prestations de service.

Visitez nous pour en apprendre plus sur AWS et Capgemini, et contactez l’un de nos experts.