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 : http://urbanisation-si.blog4ever.net/

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