urbanisation-si.com

L’expert métier : 

• Définit le modèle de règles en collaboration avec l’administrateur du moteur de règles 

• Conçoit les règles selon le modèle défini, si elles répondent aux critères définis par l’administrateur (granularité, complexité, style, correspondance avec un modèle, table de décision, …)  

  • Si une règle ne correspond pas aux critères, elle devra être écrite par le développeur 

• Effectue les tests unitaires  

Le développeur de règles : 

• Injecte le modèle métier (classes Java JAR) dans le référentiel des règles (Guvnor)  

• Conçoit le langage métier (DSL = Domain Specific Language) qui servira à l’expert métier pour écrire ses règles 

• Conçoit, réalise et teste :  

  • les classes Java à partir du modèle de données métier MEGA 

  • le composant générique pour lancer le moteur de règles 

  • les fonctions utilitaires (conversions, …) et les formules de calculs (l’expert métier peut écrire des fonctions et des expressions) 

  • ajouter des « import » de packages et des variables globales 

  • le DSL 

  • les modèles de règles à destination des experts métiers  

  • les tables de décision à destination des experts métiers 

• Teste les règles écrites par l’expert métier, à l’aide de scénarios  (valeurs en entrée et valeurs attendus), ainsi que les tests de non régression 

• Met à jour les règles (versionning) et gère les impacts d’une modification du modèle métier 

  • Méta-modèle, généricité (code, libellé, valeur, type, …) 

• Ordonnance les règles (rule flow ou processus avec un BPM=  Business Process Management) 

• Conçoit le service technique pour le lancement du moteur de règle  

L’administrateur du moteur de règles : 

• Etablit une méthode et la fait valider par le Métier 

  • Périmètre 

  • Modèle de règles 

• Définit la granularité des objets 

  • Objets spécifiques ne contenant que les données nécessaires au moteur de règles 

• Définit le passage par lots (1 ou plusieurs objets avec leurs grappes par ex. un dossier et ses dossiers liés) 

  • Ex : IHM du traitement d’un sinistre, traitement batch de plusieurs sinistres…  

• Réalise une 1ère itération de l’application avec les développeurs… 

• … puis une 2e itération avec le métier et les développeurs (ajout de nouvelles règles)  

Retour d'expérience : pendant la 1ère itération, les développeurs doivent implémenter les règles dans le langage technique du moteur puis dans les itérations suivantes on communique  la méthode mise au point comprenant la structure et les granularités des règles aux experts métier pour qu'ils se lancent à leur tour dans l'aventure.

Voir aussi :  http://urbanisation-si.over-blog.com/

http://urbanisation-des-si.blogspot.fr/

http://bonnes-pratiques-si.eklablog.com/

http://rhonamaxwel.over-blog.com/

Quels sont donc les cas ou l'utilisation d'un moteur de règles est recommandée ? 

. Pour un problème simple qui sera résolu usuellement avec de la cuisine/bricolage algorithmique 

. Un problème trop difficile à résoudre avec des algorithmes traditionnels 

. La logique métier  change fréquemment 

. Les experts fonctionnels doivent modifier les règles dynamiquement 

Et quels sont ceux ou c'est déconseillé ? 

. Petit projet  (quelques dizaines de règles) 

. La logique métier est bien défini et change rarement 

. Les règles sont simples et peuvent être  contenu dans un même objet métier 

. La performance est la principale inquiétude (règles et faits sont en mémoire !) 

. Pas de ressources (temps et budget) pour former les  développeurs 

Que peut on espérer comme Bénéfices ? 

. Mise à disposition d’un référentiel de connaissances (règles) permettant de rechercher facilement une règle, la modifier, l’archiver et créer de nouvelles règles 

. Intégration de nouvelles règles plus rapide et plus facile  

. Accroissement de la rapidité de développement de nouvelles fonctionnalités 

. Réutilisabilité 

. Évolutivité  

. Maintenabilité 

Mais comme rien n'est jamais parfait, quels sont les points d’attention ? 

. L’organisation du travail doit être modifiée 

. Les développeurs doivent connaître la technologie 

. Les experts métiers doivent se familiariser avec de nouvelles méthodes de travail et de nouveaux outils 

Il y a pléthore d'offres de moteurs de règles open source ou commerciales qui ont fait leurs preuves avec de nombreux retours d'expérience couronnés de succès. Si vos activités sont sujettes à des fréquents changements alors tentez l'innovation et lancez vous dans l'intégration d'un moteur de règles. 

Voir aussi :  Les bonnes pratiques des SI

Le blog de Rhona Maxwel

La première étape est la phase de conception qui consiste à : 

. paramétrer le moteur de règles 

. définir les concepts métier (diagramme de classes UML) et le langage utilisé pour les règles 

. définir les objets physiques et les liens avec le modèle métier 

. définir le modèles de règles 

La deuxième étape consiste à écrire les règles par l’équipe de développement dans un premier temps puis par l’expert métier ensuite, à tester les règles et à les valider. 

La troisième étape représente la phase de maturité. On met en place les processus de  modification, ajout  et suppression de règles. On s'appuie sur des données existantes dans le SI. L’utilisateur métier est autonome. Si le modèle de données évolue alors l’intervention de l’équipe de développement est alors nécessaire. 

La quatrième étape a pour but d'intégrer le moteur dans l'application avec par exemple l'utilisation native du langage Java, l'Intégration dans l’architectures cible choisie (COBOL ou Java). 

Les prérequis et contraintes sont : 

. la couche d’objets « métier » doit être suffisamment stable avant d’écrire les règles. 

. les première phases d’écriture de règles sont à réaliser par un développeur, puis le transfert doit être progressif vers l’utilisateur « métier ». 

Le point critique d’un projet BRMS concerne le développement de tout ce qui va être exposé aux utilisateurs « métier », c’est à dire : 

. le langage « métier » utilisé,  

. l’élaboration de modèles et d’autres fonctions connexes comme des tests de non-régression ou des aides au débogage.  

. la criticité vient principalement du niveau technique des utilisateurs « métier » concernés. 

Si trop de liberté est laissée et que les utilisateurs ne sont pas assez formés, le système peut devenir instable, incompréhensible et donc ne pas remplir du tout ses objectifs d’amélioration de d’évolutivité du système, les utilisateurs ayant systématiquement besoin de l’assistance de l’équipe informatique. 

À l’inverse, si le système est trop contraint, les utilisateurs ne pourront pas forcément exprimer toutes les règles qu’ils souhaiteraient. Dans ce cas, soit les utilisateurs cessent d’utiliser le système, soit les demandes à l’équipe informatique se multiplient. 

Un bon conseil, n'hésitez pas à réaliser un POC avec comme objectifs de concevoir la méthode, les modèles et la granularité des règles, de former quelques développeurs et experts métiers, de communiquer avec pédagogie à l'ensemble des acteurs projet y compris la direction générale et la DSI.  Puis faites une première itération ou seul les développeurs vont écrire les règles. Les processus d'intégration, d'exploitation, de tests et de cycle de vie des règles doivent être validés. Profitez-en pour mesurer les temps de développement et autres charges pour affiner votre retour sur investissement. 

Voir aussi :  Les bonnes pratiques de SI

Le blog de Rhona Maxwel

Mais d'abord qu’est-ce qu’une règle ? 

Une règle est composée d’un ensemble de conditions et d’un ensemble d’actions exécutées uniquement si les conditions précédentes sont réunies. 

Si un ensemble de conditions est vrai… 

… alors on exécute un ensemble d’actions 

Exemple : 

Si un évènement initial avec une personne sinistrée dont le type n’est ni assuré, ni conjoint 

Alors créer un évènement métier bloquant avec un message. 

Objectifs d'un moteur de règle : 

. La formalisation sous forme de règles permet de capitaliser et d’automatiser le savoir-faire des experts 

. Apporte une standardisation et une auditabilité de ces règles « métier », facilitant leur consultation et leur maintenance par le plus grand nombre 

. Evite d’écrire un analyseur syntaxique. 

. La sémantique d’une règle standard (« Si ….Alors … ») est particulièrement bien adaptée à ce que l’on peut trouver dans les réglementations ou dans les spécifications, ce qui permet d’avoir des délais de mise en œuvre et de validation plus courts que pour un projet écrit dans un langage classique, le passage de la spécification aux règles étant naturel. 

. Les règles sont donc beaucoup plus lisibles que du code COBOL ou Java. Le raisonnement global complexe est ainsi décomposé en règles simples et lisibles (au moins autant qu’un document de spécifications), et non noyées dans un code source complexe compréhensible uniquement par des informaticiens (voire de l’informaticien qui l’a écrit) 

. Fournir un environnement d’édition des règles utilisable simplement et directement par des experts « métier » sans compétences informatiques particulières.  

. Permet de faciliter la maintenance évolutive, grâce à la lisibilité des règles, et induit donc une meilleure réactivité et adaptation aux changements.  

. Le codage et la validation des nouvelles règles sont plus rapides à effectuer et plus aisées à mettre en œuvre, les utilisateurs font moins appel aux services informatiques.  

. Conçus pour séparer la logique « métier » (la formalisation des règles, en utilisant directement les concepts « métier ») de la logique système (la mise en œuvre technique). 

. Permet d’exprimer  ce qu’on veut faire (langage déclaratif) et non pas comment on le fait (langage impératif) 

. Rapidité et dimensionnement (algorithme RETE) pour trouver les règles en fonction des entités métiers. 

On verra dans un prochain article quelles sont les étapes d’un projet avec un moteur de règles.  

Intégrer un moteur de règles est une véritable révolution dans le SI mais il contribue pleinement aux enjeux de l'urbanisation des SI qui est de faire évoluer les entreprises plus rapidement et puis n'oublions pas qu'un changement dans notre environnement peut nous dynamiser.  

Voir aussi :  http://bonnes-pratiques-si.eklablog.com/

http://rhonamaxwel.over-blog.com/