L’externalisation de la gestion des règles métier (1ère partie)

Détacher le traitement des règles métier des applications informatiques traditionnelles accroît la rapidité d’adaptation aux changements, accentue la cohérence, rationalise la gestion des règles dispersées dans différents systèmes et surtout rapproche le monde opérationnel de la logique métier en lui offrant une plus grande autonomie en la matière. Cette approche soutien également les processus de décisions en permettant d’une part de simuler des règles (par exemple de remises commerciales) et d’autre part de raccourcir le temps de mise en œuvre de celles-ci au niveau opérationnel.


D’un point de vue technologique les solutions logicielles sont regroupées sous l’acronyme BRMS pour Business Rule Management Systems. Ce type d’application constitue un excellent tremplin à l’urbanisation d’un système d’information en permettant de sortir la logique opérationnelle enfouie dans des programmes informatiques monolithiques qu’il est ardu et couteux à faire évoluer pour la gérer de manière centralisée dans une architecture orientée service (SOA -  Service Oriented Architecture) plus souple, plus ouverte et plus évolutive. Ce modèle d’interaction entre les constituants du système d’information, mettant en œuvre des services (composants logiciels) que sont ces nouvelles technologies, offre les 2 principaux atouts suivants :

• Une cohérence interne par l’utilisation d’un langage d’échange standard comme l’XML ;
• Et un couplage lâche grâce à une couche d’interface interopérable (web services).

Le but principal du BRMS et plus largement de la SOA, doit rester l’accroissement de la capacité d’absorption des évolutions de l’organisation, de ses activités et de son environnement tout en maîtrisant les coûts.


Les brisques constitutives d’une architecture agile

A noter que le BRMS peut être implémenté sans les 2 autres briques de la couche métier d’une telle architecture applicative. Mais ce point dépend fortement de la spécificité des situations notamment de la maturité d’harmonisation du système d’information ou de l’hétérogénéité des solutions informatiques en présence. Par exemple, il peut se révéler judicieux de coupler une approche BRMS avec un projet MDM.


Du fait que le système de gestion des règles métier collabore avec l’existant informatique il est considéré comme non « intrusif ». Il est nettement moins complexe à mettre en place si on le compare à la refonte complète d’une architecture traditionnelle en une architecture SOA. En réalité il peut très bien s’inscrire comme une première étape d’une modernisation d’un système d’information vieillissant ou trop rigide. Il ne constitue pas forcément une révolution mais peu s’insérer dans une démarche d’évolution douce.


Un autre aspect intéressant du BRMS : lors de la conception ou de la refonte d’un logiciel ou d’un module, la définition et la simulation des règles métier par les experts fonctionnels en amont des développements réduisent considérablement les risques du projet, permettent une analyse plus fine des besoins et donc un gain de temps et par conséquent des coûts moindres. De plus cette partie métier pourra toujours évoluer sans trop, voir pas du tout, perturber le cœur plus rigide de l’applicatif développé.


Les 4 fonctions principales du BRMS :

• Gérer les règles pour en faciliter la création, la mise à jour, le suivi des différentes versions (cycle de vie) et la validation (workflow) dans un référentiel centralisé ;
• Simuler l’impact tant fonctionnel que technique de leur mise en œuvre et permettre d’effectuer des tests sur un environnement de référence ;
• Exécuter les règles en définissant des priorités les unes par rapport aux autres et en veillant à la sécurité des accès ;
• Administrer les règles de façon homogène et cohérente à la fois au niveau des droits d’accès, du monitoring et de la supervision.

Ce petit tour d’horizon du BRMS sera poursuivi dans un prochain billet.