urbanisation-si.com

urbanisation-si.com

DMN ( Decision Model Notation ) : Ne serait-ce pas un langage de plus, une contrainte de plus imposée à la MOA par la MOE ?

La bonne pratique est de séparer les préoccupations et donc, en urbanisation du Système d'Information, les règles métiers doivent avoir leur langage de modélisation, c'est ce qu'a fait l'OMG ( Object Management Group ) avec DMN ( Decision Model Notation ), mais sera t'il utilisé par les experts métiers ou deviendra t'il une spécification "poussiéreuse" rangée dans les placards de l'OMG et oublié des utilisateurs ?

 

dmn-drools-table-de-decision-decision-model-notation-2.PNG

 

Ci-dessus une table de décision dans Excel, au format du moteur de règles métiers open source Drools, conforme aux spécifications de la norme DMN.

 

Après la série d’articles ( voir : Tutoriel – didacticiel – exemple complet sur la norme de modélisation des règles métiers DMN ( Decision Model Notation ) : Exemple d'exécution du modèle de décisions ) consacrés au langage de modélisations des règles métiers DMN , normalisé par l’OMG, il est légitime de se demander si c’est vraiment utilisé dans la « vraie vie » ?

 

Comme on le sait, un gouffre sépare maîtrise d'ouvrage et maîtrise d'œuvre.

Un des objectifs de l’urbanisation du Système d’Information, est justement d’estomper ce fossé.

L'urbanisme cible la réappropriation du SI par la maîtrise d'ouvrage.

Pour y arriver, une compétence plus grande en matière de SI leur est nécessaire.

Une meilleure communication maîtrise d'ouvrage - maîtrise d'œuvre pourra s'instaurer.

 

Dans le cadre de la refonte du SI d’un assureur, j’ai proposé l’intégration d’un moteur de règles ( voir nos articles dans la catégorie :  MOTEUR DE RÈGLES ). Mon équipe d’urbanistes à gérer les préoccupations techniques et métiers.

Au lancement du projet, pour moi le risque était avant tout technique à cause du contexte extrêmement contraignant et complexe.

Le domaine métier me paraissait plus maîtrisé. Les règles métiers étaient certes nombreuses, certaines très compliquées et mal formulées. Mais avec l’outil Enterprise Architect, en appliquant ses profils UML et sa méthode, j’étais plutôt confiante.

Les solutions de moteur de règles métier, proposaient tous des outils pour les experts métiers, comme la possibilité d'intégrer leur propre terminologie en concevant un DSL ( Domain Specific Language ), des assistants pour la conception et les tests des règles ainsi que des tables de décision de production avec Excel.

 

Et puis au fil du temps, après consultation des éditeurs et experts techniques en BRMS ( Business Rules Management System ) et BPM ( Business Process Managment ), les exigences techniques ont toutes été satisfaites, un « Proof Of Concept ( POC )» a été réalisé avec succès sur un vrai cas métier simplifié.

 

Restait à convaincre les experts métiers d’utiliser la méthode et les outils orientés utilisateur ( DSL Domain Specific Language = langage utilisant les concepts et la terminologie métier de l’assureur, fichiers Excel pour les tables de décision, tests utilisateur, …).

Et la patatras !

Malgré des présentations, puis des formations spécialement conçues pour eux avec un prototype qui s’exécutait et qui leur permettait de voir réellement les apports, d’une gestion des règles métiers bien à part, l’intégration dans un processus métier et l’automatisation dans un moteur de processus exécutables couplé à un moteur de règles métiers, les utilisateurs ont refusé d’avoir à faire l’effort d’intégrer cette nouvelle méthodes et ces nouveaux outils.

 

En ce qui concerne DMN, pour ne rien arranger, il existe très peu d’outils conviviaux destinés aux utilisateurs et aucun ne s'interface avec par exemple Drools.

 

L’outil Sirius ( l’open source Obeo Designer Community basé sur la plateforme standard Eclipse ) de la société Obeo, permet de créer son propre langage de modélisation et donc DMN. En plus, le métamodèle ( la grammaire du langage ) en UML ( Unified Modeling Language ) est bien spécifié par l’OMG et donc peut être injecté dans l’outil.

Cela sera peut-être possible dans certaines organisations comme dans le domaine de l'aéronautique par exemple, mais pour d’autres ( mutuelles, ... ) cela ne fera pas partie de leurs préoccupations et restera l’affaire d’experts en ingénierie dirigée par les modèles et de passionnés de méthodes et autres théories, certes très intéressantes intellectuellement parlant, mais qui n’a rien à voir avec la liquidation de garantie d’un capital décès.

 

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 tous ses objectifs d’amélioration de l’é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 forcement 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 a l'ensemble des acteurs projet y compris la direction générale et la DSI.

 

Et puis très important, 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.

 

dmn-les-raisons-d-utiliser-decision-model-notation.PNG

 

Ci-dessus, un exemple de règle métier ( le fameux "Hello world" pour les apprentis d'un langage ) écrite en DRL ( Drools Rules Language ) , le langage standard du moteur de règles métiers open source Drools, adopté par l'industrie et copié par d'autres éditeurs comme IBM.

Le moteur de règles métier open source Drools ( voir nos articles dans la catégorie : DROOLS ), est le standard choisi par l'industrie. 

Son langage a été repris par la plupart des autres éditeurs.

La spécification des tables de décision a même été repris par l'OMG ! 

Drools s'intègre parfaitement avec le moteur de processus métiers exécutables open source jBPM ( voir nos articles dans la catégorie :  JBPM ) de la même société.

Tous les acteurs du domaine d'urbanisation du SI des règles métiers ont leurs outils, cela va du développeur avec des plugins Eclipse, en passant par l'administrateur pour la gestion et le cycle de vie des règles métiers jusqu'à l'expert métier avec des applications web permettant la conception avec leurs propres DSL reprenant leur jargon métier.

On peut donc avec une telle plate-forme, se passer aisément de DMN.

 

En conclusion, DMN n'est t'il pas un DSL ( Domain Specific Language ) pour "savants fous", méthodologues et autres théoriciens de l'IDM ( Ingénierie Dirigée par les Modèles voir nos articles : INGÉNIERIE DIRIGÉE PAR LES MODÈLES (IDM) ), épris uniquement de concepts abstraits et éloignés des préoccupations pratiques de la vraie vie des experts métiers qui ont d'autres choses à faire que d'apprendre un langage et des outils techniques ? 

 

"Le danger, ce n'est pas ce qu'on ignore, c'est ce que l'on tient pour certain et qui ne l'est pas."

Mark Twain

 

 Rhona Maxwel

@rhona_helena

 

 

Articles conseillés :

 

Tutoriel – didacticiel – exemple complet sur la norme de modélisation des règles métiers DMN ( Decision Model Notation ) : le processus métier BPMN

 

Tutoriel – didacticiel – exemple complet sur la norme de modélisation des règles métiers DMN ( Decision Model Notation ) : La vue des exigences des décisions

 

Tutoriel – didacticiel – exemple complet sur la norme de modélisation des règles métiers DMN ( Decision Model Notation ) : Le niveau logique de décision

 

DMN



21/01/2017
0 Poster un commentaire

A découvrir aussi


Inscrivez-vous au site

Soyez prévenu par email des prochaines mises à jour

Rejoignez les 705 autres membres