Moteur de règles - urbanisation-si, modelisation-metier, processus-metier, expression-des-besoins

urbanisation-si

urbanisation-si

Moteur de règles


BRMS Moteur de règles : mais que fait IBM ?

BRMS-moteur-de-règles-IBM-ODM-1.jpg

En tant qu'urbaniste, j'ai été amenée à travailler avec les BRMS ou moteurs de règles.

Mon premier contact a tout d'abord été avec jRules de l'éditeur français ILOG, puis avec l'open source DROOLS de Red Hat  jBoss  et enfin avec IBM ODM (Operational Decision Manager), anciennement IBM WebSphere ILOG Rules for COBOL, IBM ayant racheté il y a quelques années ILOG pour absorbé son produit phare jRules et le renommer. 

Alors que peut-on dire de ce mastodonte ?

En premier lieu il faut signaler que IBM ODM = ILOG JRules (stateless) + IBM Business Event (stateful). Une des grandes nouveauté est l'intégration de la corrélation d'évènements comme le fait d'ailleurs son concurrent open source DROOLS.

Le moteur de règle d’ODM 8.5 est le même quelque soit l’environnement (zOS, Linux, Windows) et est écrit en Java. C’est le moteur d’origine ILOG JRules. 

Des optimisations ont été faites :

  • L’introspection a été remplacé par un compilateur natif Java qui compile les classes en code natif 
  • Le moteur s’auto tune (factorisation, principe de la compilation just in time)

Le moteur (full Java) et les règles (Java) s’exécutent dans une JVM, 3 solutions possibles :

  1. Stand alone zRES, solution la plus performante
  2. Celle de WAS z/OS avec le framework WOLA, solution la plus confortable, offrant le plus de fonctionnalités
  3. Celle de CICS 

Remarque : la solution 2 (WAS z/OS WOLA) est la solution retenue pour intégrer Drools à CICS/COBOL

Avec ODM, il n’y a plus de COBOL généré (le produit JRules for COBOL a été complètement abandonné !) car il fallait recompiler le COBOL généré ! Il n’y plus qu’un seul produit ODM. Les 2 produits « IBM ILOG JRules for COBOL » et « for Java » ont donc fusionné. Le moteur est un JAR avec du byte code standard. Le code compilé des règles par ODM est factorisé et optimisé.

Ce qui m'a "scotché", c'est l'intégration dans IBM ODM du module Rules for Office permettant d’écrire les règles avec Excel ou Word en proposant un ensemble de macros.

Le Decision Center Repository permet entre autre la synchronisation des versions. La modification d’une règle par l’expert métier stockée dans le Repository sera répercutée au développeur au moment ou il se synchronisera. Ceci est Identique à Drools (IBM Decision Center Repository = JBoss Guvnor). 

ODM possède un outil de vérification de cohérence de règles (règles qui ne peut pas s’exécuter, inclusion d’une règle dans une autre, …).

Mon avis sur IBM ODM zRES est que le coût de la licence reste chère, on est dépendant vis-à-vis d’IBM et pour le mainframe avec l'intégration de COBOL, il faut acheter un processeur spécifique zAAP, donc encore des coûts supplémentaires.

Par contre IBM a tout misé sur les outils pour la MOA permettant vraiment de rédiger les règles avec le vocabulaire métier. Evidemment c'est la meilleure solution d’intégration pour les batchs COBOL et les programmes CICS. 

Se lancer avec un outil propriétaire présente toujours les inconvénients de devenir esclave de l'éditeur et de mettre la main au porte monnaie régulièrement mais pour ceux qui n'aiment pas mettre les mains dans le cambouis, les risques techniques seront mieux maîtrisés.

 

"Il est extrêmement rare que la montagne soit abrupte de tous côtés."
André Gide

 

Voir aussi :  

 

http://urbanisation-si.wix.com/blog

http://urbanisme-si.wix.com/blog

http://urbanisation-si.wix.com/urbanisation-si

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

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

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

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

http://urbanisation-si.eklablog.com/


27/05/2015
0 Poster un commentaire

Comment concevoir une règle ?

regle-metier.jpg

Pour concevoir directement une règle, l’expert métier peut utiliser différents outils, suivant le type de règles :
1. L’assistant de conception de règles (BRL = Business Rule Language)
2. Le DSL (Domain Specific Language)
3. Une table de décision avec un tableau Excel

Les tables de décisions

. Une table de décision est simple et lisible (avec une approche classique, l’implémentation n’est pas jolie)
. Si on devait développer en Java l’équivalent cela prendrait au minimum 10 jours. Les ajouts ou modifications vont conduire à un code rapidemant inextricable et et inmaintenable, figé, non évolutif et non réutilisable. La documentation technique va être très complexe.
. D’autre part dès qu’on commencerait à ajouter des colonnes, cela deviendrait vite une « usine à gaz » inmaintenable.
. Les experts métier sont familiarisés avec Excel
. Les experts métier peuvent fixer eux-mêmes les valeurs des algorithmes sans l’assistance à temps plein d’un développeur
. L’implémentation (en Excel) est proche de la spécification fonctionnelle (très souvent elle aussi en Excel)

. L’expert métier utilise un modèle de table de décision (sous Excel) à partir du référentiel ou de la DSI
. Il saisit les valeurs des conditions et des actions
. Le développeur récupère la table de décision
. Il met en place des tests
. Il effectue éventuellement des modifications sur la table qu’il fait valider par l’expert métier
. L’expert métier peut ajouter de nouvelles règles dans la table de décision

 

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

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

http://urbanisation-si.eklablog.com/

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

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


21/09/2014
0 Poster un commentaire

Qui fait fonctionner un moteur de règles ?

règle-métier.jpg

La mise en place d’un moteur de règles requiert la collaboration étroite entre 3 grands types d’acteurs : l’expert métier, le développeur de règles, l’administrateur du moteur de règles.

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/


20/09/2014
0 Poster un commentaire

Quand faut il utiliser un moteur de règles ?

moteur-de-règles.gif

Un moteur de règles contribue aux objectifs de l'urbanisation des SI qui sont d'augmenter la flexibilité et l'évolutivité de l'entreprise en permettant d'ajouter de nouvelles règles métiers à moindre coût. Doit on intégrer à tout prix un moteur de règles, existe-t-il des raisons qui justifient son emploi ou au contraire y a-t'il des situations ou c'est fortement déconseillé ?

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


19/09/2014
0 Poster un commentaire

Les étapes d’un projet avec un moteur de règles

BRMS.gif

Utiliser un moteur de règles (BRMS Business Rules Management System) va dans le sens de l'urbanisation des SI dont l'objectif est de rendre le SI flexible et évolutif. Mais quelles sont les étapes à réaliser pour mettre en œuvre un moteur de règles ?

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


18/09/2014
2 Poster un commentaire

A quoi sert un moteur de règles ?

moteur-de-règles.png

 

On entends souvent parler dans le cadre de l'urbanisation des SI, de la gestion des processus métier (BPM Business Process Management) associée à un moteur de règles métiers (BRMS Business Rules Management System). Mais qu'est-ce exactement un moteur de règles ? 

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/


17/09/2014
0 Poster un commentaire

Knowledge Is Everything (La connaissance est tout ?)

Lors d'un récent séminaire sur les moteurs de règles un intervenant citait la maxime préférée d'un des créateurs : "la connaissance est tout" (Knowledge Is Everything). La capitalisation d'un métier, la mise au point de processus avec des spécificités permettant de se différencier de la concurrence et d'apporter de la valeur aux clients est hautement stratégique. Les organisations doivent gérer les règles agissant sur les données métiers et permettant de mener à bien telle ou telle tâche métier. Externaliser les règles permet de gérer l'acquis et les futures connaissances qui permettront de se démarquer de la concurrence et de mettre à disposition de nouveaux services aux clients.

Un moteur de règles est un outil avec un langage déclaratif c'est à dire que l'on décrit ce que l'on veut et pas le moyen pour l'obtenir comme dans les langages impératifs comme les langages de programmation (Java, COBOL, ...). Le moteur peut contenir des dizaines de milliers de règles qui s'appliqueront sur un nombre important d'entités métiers (dossiers de gestion, ...). Le moteur possède ses propres algorithmes d'activation des règles. Si des entités métier sont modifiées le moteur recalcule automatiquement les règles à activer. Ceci offre donc l'économie de développements de ces algorithmes.

Les règles sont stockées dans un référentiel qui permet de les rechercher, de les versionnées.

Si la plupart des organisations utilisent les mêmes briques logicielles, les mêmes outils de conception et de réalisation de logiciels, les seuls critères différenciants restent les processus métier et leurs règles métiers. Car dans un avenir proche il faudra de plus en plus de connaissances à fournir aux systèmes informatiques et les moyens de les gérer pour pouvoir se démarquer de la concurrence et augmenter ses parts de marché.


Voir aussi le site :

Abandonnez le classicisme, relookez votre SI


11/08/2014
0 Poster un commentaire