urbanisation-si

urbanisation-si

DMN


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

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

Un scénario pour tester notre modèle DMN de règles métiers

 

Un premier article :

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

vous a présenté le processus métier BPMN utilisé pour ce tutoriel sur DMN et qui comporte des tâches de type décisions ou règles métiers.

 

Le deuxième article :

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

propose le DRG ( Decision Requirement Graph )

 

Le troisième article :

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

détaille le modèle précédent en montrant les tables de décision et les règles métiers. 

 

L'objectif de cet article est d'illustrer par un exemple de données en entrée, le fonctionnement du modèle de décisions.

 

Exemple de données en entrée : « Applicant Data »

 

dmn-decision-model-notation-tutoriel-didacticiel-exemple-complet-95.PNG

 

Exemple de données en entrée : «  Requested Product »

 

dmn-decision-model-notation-tutoriel-didacticiel-exemple-complet-96.PNG

 

Exemple de données en entrée : «  Bureau Data »

 

dmn-decision-model-notation-tutoriel-didacticiel-exemple-complet-97.PNG

 

Résultat du service de décision : «  Bureau Strategy »

 

dmn-decision-model-notation-tutoriel-didacticiel-exemple-complet-98.PNG

 

Résultat du service de décision : «  Routing  »

 

dmn-decision-model-notation-tutoriel-didacticiel-exemple-complet-99.PNG

 

Ce scénario de test, termine notre série d'articles sur la norme de modélisation des règles métiers DMN.

 

Rhona Maxwel

@rhona_helena

 

"Je veux être tout ce que je peux devenir."

Katherine Mansfield

 

 

Articles conseillés :

 

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

 

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 processus métier BPMN


02/01/2017
0 Poster un commentaire

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

Exemple de tables de décision liées à un DRG ( Decision Requirement Graph )

 

Le DRG de notre article précédent : 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 est complété en détail par les expressions associées aux décisions et modèles de connaissances :

 

« Strategy decision » défini une table de decision déduite de « Strategy » allant de « Eligibility » et « Bureau Call Type »

 

dmn-decision-model-notation-tutoriel-didacticiel-exemple-complet-76.PNG

 

« Bureau Call Type » décision invoque la table « Bureau call type », passant la sortie de « Pre-bureau risk category » décision comme le paramètre « Pre-Bureau Risk Category ».

 

dmn-decision-model-notation-tutoriel-didacticiel-exemple-complet-77.PNG

 

La table de décision « Bureau call type ».

 

dmn-decision-model-notation-tutoriel-didacticiel-exemple-complet-78.PNG

 

« Eligibility » invoque la règle métier « Eligibility », passant « Applicant data », le paramètre « Age » , la sortie de la décision « Pre-bureau risk category » comme le paramètre « Pre-Bureau Risk Category », et la sortie de la décision « Pre-bureau affordability » comme le paramètre « Pre-Bureau Affordability ».

 

dmn-decision-model-notation-tutoriel-didacticiel-exemple-complet-79.PNG

 

« Eligibility Rules »

 

dmn-decision-model-notation-tutoriel-didacticiel-exemple-complet-80.PNG

 

« Pre-Bureau Risk Category »

 

dmn-decision-model-notation-tutoriel-didacticiel-exemple-complet-81.PNG

 

La table de décision « Pre-Bureau Risk Category »

 

dmn-decision-model-notation-tutoriel-didacticiel-exemple-complet-82.PNG

 

« Application Risk Score »

 

dmn-decision-model-notation-tutoriel-didacticiel-exemple-complet-83.PNG

 

« Application Risk Score Model »

 

dmn-decision-model-notation-tutoriel-didacticiel-exemple-complet-84.PNG

 

« Routing decision »

 

dmn-decision-model-notation-tutoriel-didacticiel-exemple-complet-85.PNG

 

« Routing Rules »

 

dmn-decision-model-notation-tutoriel-didacticiel-exemple-complet-86.PNG

 

« Post-Bureau Risk Category »

 

dmn-decision-model-notation-tutoriel-didacticiel-exemple-complet-87.PNG

 

La table de décision « Post-bureau risk category »

 

dmn-decision-model-notation-tutoriel-didacticiel-exemple-complet-88.PNG

 

« Pre-bureau Affordability »

 

dmn-decision-model-notation-tutoriel-didacticiel-exemple-complet-89.PNG

 

« Post-bureau affordability »

 

dmn-decision-model-notation-tutoriel-didacticiel-exemple-complet-90.PNG

 

« Affordability calculation »

 

dmn-decision-model-notation-tutoriel-didacticiel-exemple-complet-91.PNG

 

La table de décision « Credit contingency factor »

 

dmn-decision-model-notation-tutoriel-didacticiel-exemple-complet-92.PNG

 

« Required monthly installment »

 

dmn-decision-model-notation-tutoriel-didacticiel-exemple-complet-93.PNG

 

 

« Installment calculation »

 

dmn-decision-model-notation-tutoriel-didacticiel-exemple-complet-94.PNG

 

Rhona Maxwel

@rhona_helena

 

"Nul ne peut atteindre l'aube sans passer par le chemin de la nuit."

Khalil Gibran

 

 

Articles conseillés :

 

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 processus métier BPMN

 

La norme DMN ( Decision Model and Notation ) pour les tables de décision


02/01/2017
0 Poster un commentaire

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

DRD ( Decision Requirement Diagram ) des prises de décisions

 

dmn-decision-model-notation-tutoriel-didacticiel-exemple-complet-70.PNG

 

 

Le schéma ci-dessus montre un DRD ( Decision Requirement Diagram ) des prises de décisions dans le processus métier vu dans l'article précédent : Tutoriel – didacticiel – exemple complet sur la norme de modélisation des règles métiers DMN ( Decision Model Notation ) : le processus métier BPMN

 

Il y a quatre sources de données en entrée pour la prise de décisions (Requested product, Applicant data, Bureau data and Supporting documents) et quatre décisions dont les résultats sont utilisés dans le processus métier (Strategy, Bureau call type, Routing and Adjudication). Entre les deux sont des décisions intermédiaires : « evaluations of risk », « affordability » et « eligibility ».

 

Les caractéristiques de ce DRD incluent :

  • Il couvre les prises de décisions automatisées et humaine.
  • Des décisions (par exemple, « Pre-bureau risk category ») et des données en entrée (par exemple, « Applicant data) » sont exigées par de multiples décisions, cela signifie que le réseau d'exigences de l'information n'est pas un arbre.
  • Des modèles de connaissance métiers (voir «  Affordability calculation ») peut être invoqué par de multiples décisions.
  • Les modèles de connaissance métiers (voir «  Credit contingency factor ») peut être invoqué par d'autres modèles de connaissance métiers.
  • Quelques décisions n'ont pas de modèles de connaissance associés.
  • Les sources de connaissance peuvent fournir les aspects légaux (autorité) pour de multiples décisions et-ou des modèles de connaissance métiers.

 

Il est conseillé de séparer les DRDs pour les 3 décisions :

 

«  Decide bureau strategy »
 

 

dmn-decision-model-notation-tutoriel-didacticiel-exemple-complet-71.PNG

 

«  Decide routing »
 

dmn-decision-model-notation-tutoriel-didacticiel-exemple-complet-72.PNG

 
«  Review application « 
 

dmn-decision-model-notation-tutoriel-didacticiel-exemple-complet-73.PNG

 

Les 2 services de décisions nécessaires par le processus métier doit être modélisé :

 

Le service « Bureau Strategy Decision Service » appélé par la tâche «  Decide bureau strategy »
 

dmn-decision-model-notation-tutoriel-didacticiel-exemple-complet-74.PNG

 

Le service « Routing Decision Service », appélé par la tâche « Decide routing », possède comme sortie la décision « Routing ».
 

dmn-decision-model-notation-tutoriel-didacticiel-exemple-complet-75.PNG

 

Rhona Maxwel

@rhona_helena

 

 "Accomplis chaque acte de ta vie comme s'il devait être le dernier."

Marc Aurèle

 

 

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

 

La norme DMN ( Decision Model and Notation ) pour les tables de décision

 

DMN - L'antisèche de la notation complète des composants d'un DRD ( Decision Requirement Diagram ) : vues partielles et informations masquées


02/01/2017
0 Poster un commentaire

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

Pour notre tutoriel sur la norme DMN ( Decision Model Notation ) de modélisation des règles métiers, voici un exemple complet basé sur le processus de création de prêt, modélisé avec BPMN 2 ( Business Process Model Notation ) .

 

dmn-decision-model-notation-tutoriel-didacticiel-exemple-complet-69.PNG

 

Le processus métier est implémenté par une application qui a pour but de gérer une demande de prêt, obtenant des données d'un bureau de crédit seulement si c'est nécessaire et décide automatiquement si la demande doit être acceptée, ou renvoyée pour étude par un gestionnaire. Si elle est renvoyée, les documents du demandeur sont rassemblés et un gestionnaire du domaine crédit juge le cas. Cela consiste dans les composants suivants :

 

  • La tâche « Collect application data »  rassemble des données décrivant le produit demandé et le demandeur) (par exemple, par un formulaire de demande en ligne).
  • La tâche de type décision « bureau Strategy » appelle un service de décision en lui transmettant en entrée passant le produit demandé et les données du demandeur. Le service produit deux décisions : « Strategy » et « Bureau call type ».
  • Une passerelle utilise la valeur de « Strategy » pour aiguiller vers les tâches « Decline application », « Collect bureau data » ou « Decide routing ».
  • La tâche « Collect bureau data » rassemble les données d'un bureau de crédit selon la décision de la tâche « Bureau call type », alors le cas est passé à la tâche « Decide routing ».
  • La tâche « Decide routing » appelle un service de décision, en lui transmettant le produit demandé, les données du demandeur et les données du bureau (si la tâche « Collect bureau data » n'a pas été exécutée, les données de bureau sont mises à nulle). Le service rend une décision seule: «  Routing ».
  • Une passerelle utilise la valeur «  Routing » pour aiguiller pour « Accept application », « Review application » ou « Decline application ».
  • La tâche « Collect documents » récupère et télcharge les documents du demandeur.
  • La tâche « Review application » permet au gestionnaire du domaine crédit d'étudier le cas et décider s'il doit être accepté ou refusé.
  • Une passerelle utilise la décision du gestionnaire du domaine crédit pour aiguiller le cas vers « Accept application » or « Decline application ».
  • La tâche « Accept application » informe le demandeur que sa demande est acceptée et initialise le prêt avec le produit de crédit.
  • La tâche « Decline application » informe le demandeur que l'on refuse sa demande.

 

Notez que dans cet exemple deux décisions (automatisées avec des appels aux services de décision) qui ont représentés en BPMN 2 comme des tâches de règle métiers ; la troisième décision (qui est la prise de décisions humaine) est représenté comme une tâche d'utilisateur.

 

Rhona Maxwel

@rhona_helena

 

"Mille victoires sur mille ennemis ne valent pas une seule victoire sur soi-même"

Bouddha

 

 

Articles conseillés :

 

La norme DMN ( Decision Model and Notation ) pour les tables de décision

 

DMN - L'antisèche de la notation complète des composants d'un DRD ( Decision Requirement Diagram ) : le service de décision

 

DMN - L'antisèche de la notation complète des composants d'un DRD ( Decision Requirement Diagram ) : vues partielles et informations masquées


02/01/2017
0 Poster un commentaire


Recherche

Vous recherchez ? :