Accueil > Divers > Brèves d’experts : retour d’expérience sur les BRMS (Business Rule Management System)

Brèves d’experts : retour d’expérience sur les BRMS (Business Rule Management System)

Le BRMS (Business Rule Management System) est a priori séduisant : en effet, quoi de plus sympathique comme idée que de confier au métier (ou tout au moins à une MOA un peu éduquée), la gestion des évolutions de ses règles métier ?

Ça, c’est la théorie, et pour vous mettre dans le bain, je vous engage à consulter ce précédent article : http://blog.viseo-bt.com/javaee/paris-jug-soiree-moteur-de-regles

Mais dans la pratique, ça donne quoi ?

J’ai espionné quelques ODésiens qui en discutaient…

Domoina :

J’aimerais savoir si certains d’entre vous ont déjà utilisé des BRMS dans des projets, et si oui lesquels et avec quelle architecture ?

Les points importants dans le projet où je dois en utiliser un sont:

  • L’utilisateur final doit avoir une certaine autonomie
    • Il doit pouvoir créer/modifier/supprimer lui-même ses règles
    • Il doit pouvoir ajouter des propriétés et des objets à son modèle métier.
  • Des règles doivent pouvoir  être importées en lot depuis une autre source de données, avec des coefficients de priorité affectés à chaque règle.
  • La logique de raisonnement du moteur d’inférence (l’enchaînement des règles utilisées) doit pouvoir être affichée.

Julien :

Si tu entends par BRMS, « système expert », je connais de nom JESS et Drools que je n’ai pas expérimentés mais dont on m’a dit du bien :

On trouve, pour ces deux frameworks, un nombre non négligeable de ressources sur internet.

Et sinon une liste non exhaustive ici : http://stackoverflow.com/questions/9642004/are-there-open-source-expert-systems-with-reasoning-capabilities

Domoina :

Apparemment, JESS est à voir. Mais sa dernière version (7.1) remonte à 2010 et les règles sont écrites en LISP ce qui me freine un peu.

Dong :

J’utilise drools sur mon projet actuel.

  • concernant l’autonomie de l’utilisateur final :
    • Faut pas rêver : c’est déjà assez compliqué pour un technicos
    • Pour y arriver, on a dû développer une surcouche complète en développant un langage simplifié pour l’utilisateur final. Derrière, on a traduit ce langage en règle drools.
    • Nuance à cette réponse, il existe un outil graphique permettant d’écrire les règles : Drools Guvnor (http://www.jboss.org/drools/drools-guvnor.html). Je n’ai jamais testé mais à mon avis ça ne va pas chercher bien loin.
  • Concernant la possibilité d’importer des règles en lot depuis une autre source de données : les règles peuvent être packagées, sérialisées et utilisées où bon te semble.
  • Concernant la possibilité d’affecter des coefficients de priorité à chaque règle : Oui, ça s’appelle Salience chez drools. Associé à ça, il existe d’autres mécanismes permettant de définir l’ordre d’exécution des règles.
  • Concernant la possibilité d’afficher la logique de raisonnement du moteur d’inférence (l’enchaînement des règles utilisées) : je ne crois pas que ce soit possible. Il existe un outil JBPM (http://www.jboss.org/jbpm) mais qui se situe à un plus haut niveau. On l’a très vite abandonné sur le projet (pas d’utilité pour nous)

Drools est un outil puissant et pas si difficile que ça à maîtriser (pas besoin de consultants Drools pour le faire marcher). C’est loin d’être parfait, les possibilités de debug des règles sont rudimentaires, l’intégration à Eclipse est anecdotique, des bugs importants persistent au fil des versions… Malgré tout, si on avait dû s’en passer, je crois qu’on y serait encore. Il rend plus de services qu’il ne donne de soucis.

 

Christophe :

J’ai utilisé Drools sur une application de tarification d’assurance.

L’idée était d’avoir un moteur de règle complet qui serait paramétrable rapidement sans redéployer l’application.

Deux problèmes sont apparus :

  • la stabilisation des règles a été extrêmement fastidieuse, car les logs et le retour sur erreurs était quasi nuls
  • il est très difficile de maintenir les règles, car peu de personnes sont formées au langage et les équipes changeaient souvent.

De mon point de vue, il aurait été plus efficace de coder les règles dans le langage du projet, Java. Il me parait peut crédible de confier l’écriture des règles à des experts métiers fonctionnels. Mais l’avantage, c’est que l’on peut très vite réparer ce qui a été cassé sans tout re-déployer.

 

Cyril de Ninja Squad :

Mes expériences de BRMS (au nombre de deux) peuvent se résumer ainsi :

  • le choix d’utiliser un BRMS a été fait par des décideurs séduits par l’idée que des analystes pourraient écrire leurs règles métiers sans devoir payer des développeurs pour les coder.
  • ça coûte cher en intégration (mais IBM pour JRules se fait une joie de vous proposer du support à prix d’or, heureusement d’autres sont open source)
  • pour au final réaliser que des règles métier, c’est compliqué, ça change tout le temps, et que le modèle prévu initialement n’est pas assez évolutif. Alors on finit par en coder une, puis deux, puis trois en dehors du BRMS. Puis on abandonne le BRMS avec un gros trou dans le budget. Finalement, un développeur, c’est bien, ça code les règles métiers qu’on lui demande même si elles ne rentrent pas dans les cases initiales.

Voilà mon retour d’expérience, certainement biaisé par le manque d’expérience de l’équipe de développement sur ce genre d’outils, et par l’inadéquation possible d’un BRMS avec les uses cases de notre contexte.

Vincent :

J’ai à peu de chose près la même expérience que Cyril avec JRules. J’ai sérieusement été séduit par cette idée, et m’y suis accroché jusqu’à arriver en face du mur de la réalité !

On était en .Net et nous avions fait appel à des consultants JRules.

On a utilisé le JRules « classique » pour que le métier puisse écrire avec Word leurs spécifications en français (ça génère des WebServices et contrats wsdl, donc pas nécessaire d’utiliser JRules pour .Net).

Problème : nous fonctionnions en mode Agile, avec des itérations de 2 semaines alors que l’équipe JRules était en mode étude et modélisation. Nos 2 équipes étaient désynchronisés et nous avions du mal à anticiper l’étendue de l’effort requis pour l’intégration de JRules, puisque nous n’avions que des présentations Powerpoint et UML à notre disposition.

Lorsque les Mocks sont arrivés, ils ont re-modélisé leurs règles, avec des contrats différents, cassant ainsi notre intégration. Comme le précise Cyril, le modèle est rigide, et la moindre modification le casse.

Au bout de quelques itérations, c’était véritablement un bulldozer pour accoucher d’une souris.

Au final, nous n’avons pas retenu JRules malgré ses atouts, et on a codé en C# les règles sous forme de « Behaviors » et le projet a été livré en temps et en heure avec la satisfaction client.

Domoina :

Effectivement, ces retours d’expérience remettent en question la pertinence d’utiliser un BRMS. Ce qui est sûr c’est que le système peut vite devenir ingérable si les utilisateurs finaux touchent aux règles et au modèle. Mais justement, en y pensant dès le début du projet et en faisant en sorte de bien cadrer l’utilisateur sur ce qu’il peut ou non faire, on pourrait avoir une autre approche de l’implémentation d’un BRMS, non ?

Vincent, avec les règles sous forme de « Behaviors », les utilisateurs écrivent leurs règles via Word, c’est ça ? Est-ce qu’ils peuvent modifier le modèle ? Est-ce que tu as quand même utilisé un système expert pour raisonner sur ces règles ?

Vincent :

On a repensé la logique de l’application, et recréer un Designer pour le métier :

  • Terminé les doc Word (ou Excel) avec des règles mises à la disposition du métier :
    • Ca semble flexible, mais la base du modèle est totalement rigide car nécessite de penser à tous les cas et exceptions possibles
    • il est quasi-impossible de tout penser dès le départ (« big design up-front » !). Du coup, ça fait des « breaking changes » dans notre code.
  • Pour être bien plus flexible, on a créé des blocs métiers dans une bibliothèque (où le dév créait les règles métier). Ces blocs rappelaient un peu la SOA : chaque bloc était spécialisé et on l’associait à d’autres blocs.
  • Le métier, aidé du dév (si besoin), composait son nouveau contrat dans une interface basée sur du XAML (par exemple Blend, Visual Studio, …) avec les blocs de la bibliothèque.

Ca correspondait à 90% du besoin, et donc terminé LE modèle rigide, on était libre de composer ce que l’on voulait. Pour les 10% restant, c’était le dév qui créait de nouveaux blocs et ça enrichissait la bibliothèque (avec des droits spécifiques par profils).

Pour répondre à ta dernière question : si par « système expert », c’est JRules ou toute autre solution de gestion de règles métier dont tu parles, oui on a laissé tomber ! On a tout fait par code, en axant notre conception sur la modularité du code.

Categories: Divers Tags:
  1. pierre
    10/09/2013 à 20:29 | #1

    Bonsoir, cela fait maintenant 4 ans que nous utilisons Drools. Il y a eut des grosses évolutions avec le temps et le module guvnor permet ( grâce surtout au table de décision ) de faire très rapidement énormément de règles simples qui sont finalement 80 % de nos applications. Une bonne integration est primordiale, et un.modele generique sous forme de clé, valeur fournit ènormément de flexibilité. Par contre je suis d’accord ça reste difficile de prouver aux utilisateurs finaux de rentrer dans le fonctionnement. Surtout pour modifier. Directement des règles en production…..

  1. 17/01/2014 à 16:37 | #1