Je viens de passer quelques mois à travailler avec le produit Jrules. Le sujet des moteurs de règles me semble intéressant je vous livre donc mes réflexions…
Sur son site web Ilog parle de Jrules ainsi:
“ILOG JRules 5.1 makes it easy for business users to manage rules “
“Grâce à ILOG JRules, les utilisateurs métier des sociétés de placement et de courtage pourront modifier eux-mêmes les règles régissant la conformité.”
Le message est très séduisant et passe très bien en présentation powerpoint auprès des décideurs… Mais en réalité ça donne quoi?
Que faut-il pour pouvoir écrire des règles?
L’exécution des règles dans Jrules repose sur un modèle objet. Avant de pouvoir écrire une règle il faut définir le BOM ou Business Object Model. Le BOM défini une sorte de modèle sémantique qui va permettre d’écrire les règles en langage naturel. Pour chaque objet et méthode on donne une traduction en langage naturel. L’écriture des règles se fait à partir du BOM.
Que faut-il pour pouvoir écrire de bonnes règles?
La qualité des règles dépend donc directement de la qualité du BOM qui lui même dépend du modèle objet.
Définir le BOM c’est fabriquer une sorte de Domain Specific Language: si le langage est trop pauvre: l’utilisateur sera trop limité. Si le langage est trop riche: l’écriture des règles sera trop compliqué. Il faut trouver l’équilibre.
Peut-on arriver à écrire de bonnes règles?
L’un des risques est que les utilisateurs se servent du prétexte Jrules pour ne pas spécifier précisément leur besoin, ça se traduit dans les documents de spécifications par des phrases du type “sera traité par des règles Jrules.” dès que ça devient un peu compliqué. C’est une recette pour une catastrophe.
Je pense qu’il est possible d’atteindre l’objectif initial: “permettre aux utilisateurs de modifier leurs règles sans intervention du service informatique”. Mais uniquement si les utilisateurs maîtrisent extrêmement bien leur domaine fonctionnel. Ils doivent être capable de définir entre quelle borne et quelle borne leurs règles métiers vont varier. C’est à cette seule condition qu’on peut définir un BOM solide qui permettra d’écrire des règles en langage naturel qui seront facilement modifiables.
=> La phase d’analyse et de modélisation est capitale, encore plus que pour un projet traditionnel.
=> La phase de définition du BOM ne l’est pas moins. C’est là ou réside en plus du coût des licences le surcoût d’un projet Jrules.
Peut-on faire des économies avec un moteur de règles?
On peut donc modifier des règles ou en ajouter facilement mais uniquement dans la limite de ce qui a été prévu. Si vous désirez ajouter des données il faut mettre à jour le modèle objet donc le BOM ce qui a parfois tendance à caser les règles existantes. De toute façon vous êtes bon pour repasser par la casse équipe informatique… Adieu les économies.
L’utilisation d’un moteur de règles ne dispense d’aucune des tâches d’un développement classique par contre on trouve en plus la phase de définition du BOM qu’il ne faut pas sous-estimer. La phase de développement initial est donc forcément plus coûteuse avec Jrules que sans. Le ROI ne vient qu’après avoir modifié de nombreuses fois les règles sans faire appel au service informatique.
J’ai pu constater que même après une semaine de formation il est difficile de s’en sortir dès que l’on sort des cas standards sans l’aide des consultants d’Ilog heureusement ceux avec qui j’ai travaillé était très compétent.
Un autre problème est la question du débugguage des règles. Bien que le produit d’Ilog fournisse des outils pour le débugguage ils sont très limités dès qu’il s’agit de travailler avec un modèle un tan soit peu conséquent. Nous avons été obligé de réaliser des développements spécifiques pour pouvoir tester et débuguer les règles dans de bonnes conditions.
Les performances?
C’est l’une des questions qui revient souvent à propos des moteurs de règle, qu’en est-il des performances? En fait il y a rarement de problème de performance provenant directement du moteur de règles. Celui de Jrules implémente l’algorithme Rete qui lui évite d’exécuter toutes les règles à chaque fois. C’est à ce jour la meilleure optimisation connue pour ce type de problème et elle semble donner satisfaction. Et l’on peut toujours aider le moteur en lui indiquant dans quel ordre il doit éxécuter les régles pour éliminer le plus grand nombre de cas dès le départ.
Mais utiliser un moteur de règles ne nous affranchi pas des problèmes de performance classique que l’on rencontre dans toute application. En premier lieu le problème de l’accès aux données. Jrules est très très orienté objet, lors de l’exécution des règles le graphe objet peut être parcouru de manière intense… Comme les données sont souvent stockée dans des bases de données relationnel le problème du mapping objet/relationnel, “l’impedance mismatch” peut devenir très important.
Les alternatives?
En discutant avec d’autres personnes utilisant ou souhaitant utiliser un moteur de règle on constate que bien souvent ce ne seront pas les utilisateurs fonctionnels qui modifieront les règles mais bien les équipes informatiques. Dans ce cas utiliser un langage de script tel que jruby ou jpython apportera les mêmes bénéfices que Jrules en terme de souplesse sans les inconvénients (définition du BOM par exemple). Par contre avec une telle solution on ne bénéficie pas des avantages de l’utilisation de l’algorithme Rete, à moins de le recoder soit même…
Il existe d’ailleurs un produit open source qui fait cela: Drools. Je ne le connais pas, si quelqu’un à un avis?
Conclusions
Les promesses de Jrules ne sont pas impossible à atteindre mais les conditions pour y parvenir me semblent difficiles à réunir. (non non je ne fairais aucun lien vers un dessin de Dilbert!!)
Si vous voulez creuser un peu la question des moteurs de règles je vous recommande ce rapport:
Service Oriented Business Rules Management Systems.
Ainsi que ces animations pour comprendre la magie de l’algorithme Rete.