Après la dégustation de spécialités mauriciennes et le résultat du jeu concours lancé par Ippon, retour aux choses sérieuses avec la présentation de deux BRMS présents sur le marché : ILOG et Drools.
Daniel Selamn, architecte du produit chez IBM Websphere est venu nous présenter Ilog, l’ancien JRules. Convaincu que dans un monde qui change vite, le SI doit être capable d’évoluer très vite, Daniel est venu nous parler de ce qu’il appelle une “Change Oriented Architecture”.
Daniel Salamn – Photo : José Paumard
De la même façon qu’on a externalisé les données dans des bases, on cherche maintenant à externaliser la logique métier dans un dépôt externe. Néanmoins les changements dans une application peuvent être de types très différents : il peut s’agir d’un refactoring de code, de modèle, de règles métiers, de GUI, etc … Chacun de ces changement impliquera un processus et aura un impact différents sur l’application, les tests et la validation ne seront pas les mêmes pour tous.
Un processus de validation du changement a besoin de méta-donnée : quel est le numéro de version ? est-ce validé ? est-ce déployé ? Ces méta-données vont aussi refléter l’aspect humain du changement : qui a demandé ce changement ? qui l’a fait ? qui l’a validé ? De plus même lorsqu’une nouvelle version est disponible et déployée, les précédentes doivent toujours fonctionner. Tout ceci rentre en compte dans le processus de traçabilité, processus relativement coûteux d’où l’intérêt d’externaliser les règles. C’est ce que Daniel appelle le “time-travel” : la possibilité de simuler à tout moment un résultat avec un ancien jeu de règles.
Les audits quant à eux coûtent cher aussi, néanmoins avant tout changement il faut s’assurer que les conditions nécessaires sont réunies : le code doit être prêt avant que l’utilisateur ne s’en serve, ce qui demande une coordination dans l’équipe. De plus il ne faut pas perdre de vue que le travail réalisé doit rester compréhensible par des humains, c’est à dire des personnes dont le raisonnement, contrairement à celui d’une machine, ne peut pas changer toutes les semaines voir tous les jours ou toutes les heures.
Les développeurs et l’architecte doivent mettre en place le container for change, ce qui nécessite :
Pour le développement du langage usuel qui sera utilisé par le métier, Ilog offre un environnement eclipse : le Rule Studio. Le RuleTeamServer quant à lui, est un environnement basé sur le web pour les utilisateurs métiers offrant à la fois la possibilité d’éditer les règles dans le repository, de les versionner, commenter etc … Les modifications sont clairement repérables et traçables. Les règles sont ensuite déployées dans un serveur qui sera appelé par l’application finale pour les exécuter : le Rule Execution Server. Celui ci permet d’obtenir des statistiques, de rechercher une transaction individuelle, d’exporter les données, bref de faire du Business Intelligence.
Plus d’informations sur Ilog ici.
Cette quatrième partie de la soirée a été présenté par Geoffrey De Smet. Geoffrey a travaillé dans plusieurs projets opensource, notamment des plugins Maven, Spring Rich Client et d’autres projets JBoss. En 2007, son framework des méta-heuristiques – aujourd’hui connu sous le nom de Drools Planner – a été pris par JBoss.org et la communauté Drools. Depuis 2010 il travaille pour Red Hat à temps complet sur la plateforme Drools.
Geoffrey De Smet – Photo : José Paumard
La présentation a été vraiment riche en contenu, très intéressante et méritait bien une heure complète.
La plateforme de Drools est composée des modules suivantes :
Geoffrey est venu nous présenter le module “Planner”
Geoffrey, très passionné par son métier, nous a démontré par un exemple récent de sa vie quotidienne ce qu’est un problème de planning.
Qui n’a jamais été chez Ikea, ou n’a jamais déménagé ? On se retrouve avec plusieurs cartons de différentes tailles … mais on ne dispose que d’une seule voiture. On souhaite tout y mettre afin de réaliser un seul voyage (ou le minimum de voyages possible), donc pour cela il faut économiser l’espace, ranger les boîtes dans un ordre précis et les placer dans la bonne position, ce qui n’est pas évident. On doit toujours passer pas mal de temps pour trouver le bon ordre… Et finalement on se demande si on avait bien choisi ou si une autre manière d’ordonner n’aurait pas été plus performante….
Ceci est connu comme étant un problème de “Bin packaging”. La réalité est que pour un problème déterminé, il n’existe pas une et une seule solution. Pis, si la solution n’existe pas, il n’est pas facile de prouver la non-existence de solution. Drools planner est là pour trouver la solution la plus optimale, ou nous montrer qu’aucune solution n’existe.
Organisation des employeurs
Imaginons le besoin d’organiser le travail des employés d’un hôpital, notamment les rotations des infirmières. Drools Planner est capable d’organiser tout cela en tenant compte des contraintes – qu’elles soient fortes ou faibles, tout en travaillant en parallèle avec Drools Expert (le moteurs de règles). Par exemple, une contrainte forte peut être qu’une infirmière ne peut travailler qu’un tour par jour (sinon elle sera trop fatiguée) :
// a nurse can only work one shift per day
rule "oneShiftPerDay"
when
$left : EmployeeAssignment(
$employee : employee,
$shiftDate : shiftDate,
$leftId : id
);
$right : EmployeeAssignment(
employee == $employee, shiftDate == $shiftDate,
id > $leftId);
then
// Lower the hard score with a weight ...
end
Et en même temps, des contraintes faibles vont venir s’ajouter : par exemple certaines infirmières préféreront ne pas travailler le mercredi et d’autres préféreront avoir leur week end. Or, la quantité de contraintes faibles est plus nombreuse que celle des contraintes fortes. Drools planner est capable de travailler avec beaucoup de contraintes de manière efficiente, ce qui améliore ne seulement le service offert, mais également l’optimisation des ressources.
Admission des patients d’un hôpital
Une autre problématique liée à la planification, en restant dans le domaine de la santé, est l’organisation de l’admission des patients dans un hôpital. Ainsi :
Quelques contraintes fortes:
Quelques contraintes faibles :
Les données suivantes sont réelles. On dispose de 310 lits et de 2750 patients (admissions) – sans tenir compte ici ni des départements, ni du genre de la chambre, ni du nombre de nuits à planifier.
Combien existe-t-il de solutions possibles ? Moins que …
La quantité de possibilités dans le cas décrit est d’un peu plus de 10^6851 !!!!!!!! Et comment ? (ahh les maths …)
Drools planner à l’aide de Drools Expert nous permettra de trouver la bonne planification.
Geoffrey nous a expliqué ici que la recherche des résultats de planification avec les données décrites précédemment, et ce de façon performante n’est pas possible aujourd’hui avec les seules machines et leur hardware aussi puissant soit-il (c’est qui est appelé la force brute). Ainsi, si on réalise des algorithmes un tant soit peu intelligents, mais pas suffisamment, on n’y arrivera pas non plus.
Dans cette partie qui a été très rapidement expliquée, faute de temps, on retient que Drools Planner comprend des fonctionnalités pour réaliser des recherches et des algorithmes complexes et performants. On apprend que ces algorithmes de recherche ont aussi une nature stateful : les voies de recherche déjà explorées sont mémorisées, les branches qui ne sont pas liées à un changement particulier dans l’arbre de recherche ne sont pas explorées etc. Cette partie n’est pas facile, mais elle suppose un vrai challenge vis -à-vis de notre métier.
Avec Drools planner on pourra résoudre des vrais problèmes de planification. On sera capable d’ajouter des contraintes facilement et de façon scalable, et rendre facile l’adaptation et/ou la combinaison des algorithmes de recherche.
Pour en savoir plus rendez-vous sur http://www.jboss.org/drools/
Au prochain Paris JUG !!
La soirée a commencé par la réunion d’une quinzaine de personnes à l’Avant JUG, dont l’un de nos speakers de la soirée : Emmanuel Bonnet ! Ce dernier nous a d’ailleurs parlé du JUG qu’il fréquente régulièrement : le JUG Toulouse.
Puis départ vers les locaux de l’ISEP et pour commencer la soirée, un petit retour d’Antonio sur la réunion à laquelle les JUGs leaders européens étaient conviés par Oracle le mois dernier. Pour un résumé de cette rencontre, voir ici. Pour continuer un retour sur le fonctionnement du site javablackbelt par le responsable du site mais qui ne vient jamais au JUG 
Et pour finir avec l’introduction de la soirée, présentation d’Ippon, sponsor de la soirée qui mettait en jeu deux places pour Devoxx, hébergement et transport inclus.
Durant cette première moitié de soirée (ils sont comme ça au JUG, ils n’hésitent pas à passer sur la quantité, pourvu que la qualité soit au rendez vous ) Emmanuel Bonnet, consultant et expert en BRMS chez Génigraph nous a présenté les concepts fondamentaux liés aux BRMS et les moteurs des règles.
Emmanuel Bonnet – Photo : José Paumard
Et pour commencer nous apprenons que le concept des BRMS n’est pas nouveau. En effet, notre speaker travaille depuis 10 ans maintenant dans l’implémentation de solutions d’architecture basés sur les moteurs de règles.
Les moteurs de règles s’articulent autour de trois concepts :
La recette du moteur de règle en trois ingrédients :
Prenez quelques règles métier …
Une règle métier, c’est du contenu métier exprimé sous forme intelligible par tous, y compris (et surtout en fait) le commun des mortels. Traditionnellement une règle métier est exprimée sous la forme “Si … Alors …”.
… ajoutez-y un un moteur d’inférence …
Sous ce mot quelque peu barbare se cache en fait le “cœur” du moteur de règle : les algorithmes et ensemble d’API qui exécutent les règles précédemment énoncées.
… et faites cuire le tout dans un BRMS !
Le BRMS est là pour assembler les règles métiers et le moteur d’inférence. C’est lui qui est responsable du cycle de vie des règles, de leur écriture et de leur exécution. Il doit permettre de gérer une configuration qui s’avère souvent problématique, permettre d’avoir des version des règles et de mettre en place des processus de test et de validation.
Quand utiliser un moteur de règle ?
Dans la demande du client peut se faire sentir le besoin de changement qui peut parfois être extrêmement difficile à atteindre. Deux cas nous sont proposés :
Emmanuel illustre son propos avec des exemples parfaitement concrets dans un cas comme dans l’autre :
Le BRMS est là pour gérer tout ça : on externalise le métier, on l’explicite en règle et le réinjecte dans l’application.
Une fois explicité, le métier est compréhensible par un utilisateur métier ce qui lui donne deux avantages majeurs, il est à la fois :
La traçabilité devient un avantage non négligeable dans un métier où les règles évoluent rapidement : dans le cas d’un robot trader, elle permet de savoir pourquoi telles actions ont été vendues à tel moment, en remettant le contexte de l’époque en mémoire par exemple.
Remarque intéressante, notre speaker insiste sur le fait que le rôle du métier n’est pas forcément de faire des spécifications ou de gérer les prestataires mais bien de savoir dans son contexte. La forme si/alors va permettre de modéliser le savoir du client en un langage usuel et le rôle du développeur est alors le mapping entre le langage objet qu’il maîtrise et le langage usuel du métier, entre les concepts et la grammaire.
Comme nous le disions en introduction, le concept de BRMS existe depuis des années et il est maintenant assez avancé pour permettre de proposer un langage naturel aux utilisateurs. Le mapping du Business Object Model en Business Rules va lui permettre d’exécuter ce qu’il lit, mais il a néanmoins toujours besoin d’être guidé et c’est là le rôle du développeur. Typiquement, l’usage d’un moteur de règle est particulièrement courant dans des grandes banques, qui vont avoir jusqu’à 14000 règles métiers et des dizaines d’experts, non développeurs, qui sont là pour les gérer.
Le rôle du moteur de données est donc d’inférer pour produire un résultat en fonction du code, des données et des règles qui lui sont passés, et ce en grande quantité puisqu’il a été optimisé pour traiter un très grand nombre de faits et un très grand nombre de règles à la fois.
Emmanuel, apparemment fan d’Odile Deray , appelle l’algorithme Red Is Dead :
De plus il est capable de ré-exécuter ces règles, encore et encore puisque le résultat qu’il produit est une conclusion qu’il l’amène à de nouveaux faits et donc de nouveaux éléments. C’est la cohérence garantie dans l’exécution, principe qui est résumé par l’algorithme de RETE.
L’architecture
Le client souhaite donc pouvoir modifier la logique régulièrement tout en continuant à faire tourner d’autres versions du contenu en production et ce sans avoir de connaissances en informatique : c’est le rôle du BRMS, qui va lui permettre de gérer les règles, de les exécuter, de faire du monitoring et des statistiques le tout dans un environnement varié, voir même familier.
Un BRMS est principalement constitué de 3 parties :
La gestion de configuration nécessite quant à elle quelques outils indispensables pour supporter le processus mis en place : gestion de l’accès concourant, des rôles et autorisations, des processus, etc …
Retour d’expérience
Et pour finir de nous convaincre, notre speaker va insister sur les défis à relever et les faux problèmes à éviter.
Les défis à relever avant de se lancer sont :
Les faux problèmes qui pourraient être soulevés sont :
Laurent Magnin – Photo : José Paumard
Présentée par Laurent Magnin, consultant senior chez In Fine, cette deuxième partie tombait à point nommée pour nous convaincre que dans la vraie vie, les applications aux BRMS sont multiples et intéressantes.
Laurent est détenteur d’un doctorat en Intelligence Artificielle, discipline qu’il a enseigné à l’université de Montréal avant d’être consultant JRules pour Ilog USA avant de revenir en France pour continuer à travailler sur d’autres projets impliquant des BRMS, avec JRules ou Drools.
Ex. 1 : Turbinage
Une compagnie de production d’aluminium ayant de gros besoin d’électricité, elle possède en règle générale un ou plusieurs barrages. Mais leur fonctionnement est complexe, fortement lié à la météo, au prix de l’électricité, etc … Le problème de la compagnie pour laquelle Laurent est intervenu était le départ en retraite des experts qui ont donc formalisé leur savoir pour permettre le pilotage et la prise de décision de ces barrages via un BRMS.
Ex. 2 : A la bonne température
Le chauffage de bâtiments dans un pays aussi froid que le Canada est un problème complexe, impliquant la connaissance de nombreuses règles métiers. Laurent nous fait remarquer que le technicien qui vient diagnostiquer un problème de chauffage ne se base pas sur ces règles, mais plutôt sur leurs cas d’utilisation. Il connait de nombreux cas “généraux”, mais retient surtout les solutions qu’il a appliqué aux cas particuliers : c’est le Case-Base Reasoning.
De là une initialisation avec des règles générales et des cas de départ qu’on exécute en simulation a été faite, puis adapté aux bâtiments. Le BRMS a fait office de technologie complémentaire permettant de faire parler les experts.
Ex. 3 : Money Money
La capitale du Nevada, Carson City, est une ville principalement occupée par les fonctionnaires … et les casinos . Parmi ces fonctionnaires, ceux en charge de verser les pensions à la population devaient connaître un certain nombre de règles qui venaient “se superposer” les unes aux autres : la personne a-t-elle fraudé, quelle est sa situation familiale etc … rendant ce travail particulièrement complexe.
En effet dans la vie de tous les jours, les humains n’ont “pas de règles”, d’où la nécessité de se baser sur des cas concrets pour pouvoir élaborer ces règles, ce que Laurent résumera ainsi : “l’humain ne travaille jamais avec des règles, toujours avec des cas; et les cas permettent de tester les règles.”
Ex. 4 : Sans sucre
Dans une banlieue aisée de Boston où les cas de diabètes sont récurrents, la nécessité de diagnostiquer automatiquement les cas dans un domaine très sensible a amené à la création d’un ruleflow très affiné, afin de ne pas risquer de manquer un cas avéré. Le cheminement est parfaitement déterminé, chaque cas est évalué (âge, sexe, origine etc …) et le tout est réalisé en langage naturel avec des experts médecins.
Face au cas particulier de son patient, le médecin peut alors tracer le raisonnement qui a été suivi et prendre la décision particulière qui s’impose.
Ex. 5 – Faire son marché
Le cas d’une grande banque de marché française vient en opposition totale au cas précédent. Là où le cas médical est beaucoup testé avant d’être utilisé, le cas financier est tout de suite utilisé en production, quasiment sans test préalable, impératifs économiques obligent.
Cette banque disposait déjà d’un système qui connaissait des problèmes de maintenance et de performance, et c’est pourquoi, plutôt que de le refaire alors qu’il était devenu ingérable, Laurent a proposé l’utilisation d’un tableau décisionnel, a pu résumer 23 cas de demandes de prêt en un seul, tout en fournissant aux utilisateurs métiers un tableau de bord de type fichier excel, aisément compréhensible.
Fin de la première partie, direction la salle de pause où nous attend un buffet mauricien particulièrement alléchant, offert par Ippon
En continuant à utiliser le site, vous acceptez l’utilisation des cookies. Plus d’informations
Les paramètres des cookies sur ce site sont définis sur « accepter les cookies » pour vous offrir la meilleure expérience de navigation possible. Si vous continuez à utiliser ce site sans changer vos paramètres de cookies ou si vous cliquez sur "Accepter" ci-dessous, vous consentez à cela.
