Introduction

Les entreprises recherchent continuellement l'excellence opérationnelle, la maîtrise des risques, la conformité réglementaire, dans une efficacité se voulant agile et réactive. Il est souvent nécessaire de réagir très rapidement ou très fréquemment. Mais dans certaines situations complexes, les règles de gestion doivent prendre en compte un nombre important de paramètres.

Decision Model and Notation (DMN) est une notation pour décrire et modéliser des décisions opérationnelles, un peu comme la norme BPMN (Business Process Model and Notation) pour décrire des processus métiers structurés.

DMN a été officialisée en 2014 par l’Object Management Group (OMG), l'organisation qui a créé les normes UML, MDA, BPMN, CMMN, ... C’est une spécification standard, indépendante d’un éditeur de logiciel, qui utilise un langage graphique de haut niveau, normalisé. DMN favorise l'interopérabilité et préserve les investissements en évitant d’être lié à une solution propriétaire. En effet, les grands éditeurs logiciels proposent maintenant tous une implémentation de cette norme (Oracle, IBM, Red Hat, Camunda, Trisotech, …).

Grâce à DMN vous pouvez documenter vos décisions opérationnelles de manière structurée et claire afin de les rendre faciles à comprendre par tous les acteurs impliqués. Cela facilite la collaboration, améliore la compréhension métier et élimine les ambiguïtés.

Finalement, le contrôle des décisions opérationnelles est rendu, en partie, aux experts métiers avec l’essor de différentes plateformes permettant des développements de type “low code” ; il n’est plus forcément nécessaire d’avoir des compétences sérieuses en programmation pour pouvoir développer, rapidement et à moindre coût, des décisions opérationnelles.

La modélisation des décisions

Une décision opérationnelle est souvent plus qu'un arbitraire jugement humain. Elle est basée sur une logique métier définie. Elle peut être formulée par une question dont les réponses sont choisies parmi un ensemble possible de valeurs définies. Une décision peut ainsi être caractérisée par le fait de déterminer une ou plusieurs valeurs en sortie (résultat) à partir d'un ensemble de valeurs en entrée (facteurs ou variables de décision), en s’appuyant sur des règles souvent appelées règles de gestion ou règles métiers. La formalisation et la structuration des règles métiers permettent à chaque acteur d'avoir une représentation précise, complète et cohérente des modes de décision opérationnelle.

La gestion des décisions est à la fois une approche métier et une problématique technologique. La gestion des décisions permet à une organisation de contrôler, de gérer et d'automatiser les décisions reproductibles au cœur de ses activités en appliquant efficacement des règles métier.

DMN propose deux niveaux d’abstraction

1. Les Diagrammes des exigences de décision (DRD pour Decision Requirements Diagrams). Ils permettent de représenter les décisions métiers complexes du début à la fin, chaque nœud de décision utilisant une logique (voir point suivant). Ils formalisent les dépendances entre les éléments nécessaires à la décision, notamment les données en entrée et la décision finale.

2. Les logiques de décision qui définissent les règles métiers, telles que des tables de décision, des fonctions, des expression littérales…

La représentation emblématique de la notation DMN est le DRD (Decision Requirements Diagram)

Un diagramme des exigences de décision (DRD) ne propose qu’une palette de cinq éléments graphiques :

On trouve souvent plusieurs éléments de type décision dans un seul diagramme. En effet, une décision complexe est souvent décomposée en un ensemble de sous-décisions intermédiaires, le résultat d'une décision devenant alors un prérequis de la décision suivante et donc une valeur en entrée. On crée ainsi une hiérarchie de décisions. Cela permet une meilleure lisibilité, maintenabilité, adaptabilité et surtout réutilisabilité car ces décisions intermédiaires peuvent être utilisées dans d'autres contextes.

L'exemple suivant illustre l'utilisation de certains de ces composants DMN :

L'expression des logiques de décision

Pour compléter le Diagramme des exigences de décision (DRD), DMN propose un deuxième niveau : le niveau logique pour exprimer les logiques de décision. Cela permet de détailler certains éléments du DRD et notamment de capturer un ensemble complet de règles de gestion et de calculs. Cette formalisation permet d'automatiser la décision dans une application ou dans un moteur d'exécution DMN comme un moteur de règles (BRMS - Business Rules Management System) ou un moteur BPM.

DMN propose différentes possibilités pour exprimer la logique de décision : tables de décision, expressions littérales, contextes,
relations, fonctions, invocations et listes. Il fournit également un langage Low-Code pour la logique à l'intérieur de chaque décision : FEEL (Friendly Enough Expression Language).

Les tables de décision

Les tables de décision ont longtemps précédé la norme DMN, mais DMN impose des règles strictes concernant leur format et leur syntaxe. L'objectif de DMN est avant tout de standardiser la formalisation des tables de décision pour une représentation commune.

Les tables de décisions rendent la logique de décision compréhensible par tous et sont facilement transposables si vos règles métiers sont déjà disponibles sous la forme de tableaux ; Car une table de décision dans DMN est une représentation visuelle d'une ou plusieurs règles métiers sous forme de tableau aussi !

Vous utilisez des tables de décision pour définir des règles pour un nœud de décision qui applique ces règles à un point donné du modèle de décision. Chaque règle se compose d'une seule ligne dans le tableau et comprend des colonnes qui définissent les conditions (entrée) et le résultat (sortie) pour cette ligne particulière. La définition de chaque ligne est suffisamment précise pour dériver le résultat à l'aide des valeurs des conditions. Les valeurs d'entrée et de sortie peuvent être des expressions FEEL (Friendly Enough Expression Language) ou des valeurs de type de données définies.

Une règle est définie par une combinaison de valeurs en entrée permettant de définir la valeur de résultats. Chaque cellule du tableau est en fait une condition booléenne, c'est-à-dire l'expression d'une condition pouvant être soit vraie soit fausse.

Les conditions exprimées pour chaque colonne sont combinées par la conjonction « ET ». Une règle « matche » si chacune des conditions exprimées est vraie.

Certains types de tables de décision doivent contenir toutes les combinaisons possibles des valeurs en entrée, c'est-à-dire toutes les règles.

Toute la difficulté de la mise en place d'un modèle DMN réside dans l'acquisition des connaissances d'un expert métier et de leur formalisation en tant que données manipulées et règles de gestion. L'expert métier doit décrire minutieusement les traitements alors que certains experts métiers éprouvent des difficultés à expliciter un raisonnement parce que le savoir métier est peut-être perdu ou non documenté.

Mais heureusement, la mise au point d'un modèle DMN est réalisée rapidement et est d'une grande fiabilité. L'environnement d'exécution DMN peut même expliquer son raisonnement (« Quelle est la valeur de chaque décision ? Quelle règle dans une table de décision a été appliquée ? »), ce qui permet à ses concepteurs de juger de son niveau de fiabilité.

L'intégration de DMN avec vos applications

DMN s'intègre avec n'importe quelle application cliente de type RESTful (Java, PHP, Node.js, .NET…) et permet ainsi de mutualiser cette brique décisionnelle.

L’intégration, la plus simple, reste d’encapsuler votre intelligence décisionnelle dans un micro-service pour que vos applications legacy puissent ainsi profiter de votre conception DMN. A noter, qu’un moteur de type « Decision Management » ou moteur de règles peut vous offrir cette fonctionnalité nativement [1]. En général, lors de l’appel de la brique décisionnelle, on fournit tous les objets métiers à évaluer et le retour de cet appel contient tous les nouveaux objets déduits.

Une autre méthode consiste à ce que votre application (webapp, batch…) embarque un moteur d’exécution DMN pour utiliser ses propres modèles de décision DMN au format XML [1].

Une dernière solution est la possibilité d’intégrer DMN à des processus métiers décrits en BPMN. Généralement, les décisions DMN peuvent être référencées à l’intérieur des tâches métiers (Business Tasks) de BPMN, si votre moteur BPM embarque un moteur d’exécution DMN, sinon en les référençant dans des tâches services (Service Tasks) de BPMN en mode appel d’un micro-service externe.

[1] Solutions Drools / Red Hat Decision Manager (RH-DM).

Note : Red Hat sponsorise le projet communautaire Drools et emploie ses principaux développeurs. Pour les entreprises, Red Hat commercialise sa solution BRMS nommée RH-DM (Red Hat Decision Manager), intégrant un outil de conception DMN graphique et un moteur d’exécution DMN, avec un système de souscriptions annuelles pour disposer d’un support complet du produit.

Niveaux de conformité DMN

En regardant DMN, nous pouvons assister au même phénomène concernant la gestion des processus métier (BPM) car il y avait, et il y a toujours, de nombreuses approches et technologies BPM propriétaires. L’Object Management Group (OMG) a pourtant introduit en 2006 la norme BPMN (Business Process Model and Notation) et beaucoup d’entreprises l’ont adopté, mais beaucoup en partie alors que d'autres sont restées avec des approches propriétaires (spécifiques au fournisseur). Avec DMN, c'est identique, à l’instar des plateformes BPM, on note certaines différences dans les fonctionnalités disponibles sur certaines implémentations DMN.

Ainsi il existe plusieurs niveaux de conformité, en plus des différentes versions de DMN supportées (1.0 à 1.4) :

• Niveau de conformité 1

Ce niveau prend en charge les diagrammes d'exigences de décision (DRD), la logique de décision et les tables de décision, mais les modèles de décision ne sont pas exécutables.

• Niveau de conformité 2

Le niveau 2 de conformité DMN inclut les exigences du niveau de conformité 1, prend en charge les expressions S-FEEL (Simplified Friendly Enough Expression Language, un sous-ensemble de FEEL) et les modèles de décision sont exécutables.

• Niveau de conformité 3

Le niveau 3 de conformité DMN inclut les exigences des niveaux de conformité 1 et 2, prend en charge l'ensemble complet des expressions FEEL (Friendly Enough Expression Language) et les modèles de décision sont entièrement exécutables.

Ainsi, lors d’une évaluation d'une solution DMN, l'objectif de votre étude devra être clair : s'agit-il simplement de documenter les décisions ? Ce cas est plutôt rare car vous passeriez devant la possibilité de rendre exécutables vos règles de gestion. Un simple outil de modélisation avec prise en charge du niveau de conformité 1 suffirait.

Mais généralement, vous souhaitez bénéficier pleinement de la norme et surtout vous souhaitez automatiser des décisions : vous devrez alors choisir un logiciel DMN avec un niveau de conformité 3.

Enfin, parmi les solutions à étudier figurent des plateformes de type moteur de workflows (BPMS) ou de type moteur de règles (BRMS) disposant d’une fonctionnalité DMN intégrée.

Exemple de conception DMN : comment déterminer un niveau de risque pour un assureur ?

Un exemple concret vous permettra de juger de l’efficacité de DMN avec un niveau de difficulté qui n’est pas très élevé :

Le métier d'une entreprise d'assurance est de gérer le risque. Ainsi, lorsqu'une nouvelle personne souhaite souscrire une police d'assurance santé, elle doit en tout premier lieu estimer le type du risque. Elle se base pour cela sur les informations du demandeur comme l’âge et son état médical (très bon, bon, moyen, mauvais, très mauvais).

Les niveaux de risque possibles en retour de l’évaluation sont : Faible, Moyen, Elevé.

Toute personne avec un état de santé « mauvais » ou « très mauvais » donne un niveau de risque « élevé », tout comme les personnes de plus de 65 ans. Toute personne avec un état de santé « très bon » donne un niveau de risque « faible », tout comme les personnes de moins de 35 ans ayant un état de santé « bon ».

Le résultat doit être en priorité le niveau de risque le plus élevé. Si rien ne permet d’évaluer que le niveau de risque est « élevé », alors le niveau de risque est automatiquement « moyen ».

Pour répondre à toutes ces exigences, voici une solution réalisée en DMN :

L’indication de la stratégie est représentée par une lettre dans la cellule du coin gauche de la table de décision : dans notre cas, il s’agit de « P » pour Priority dont voici la définition :

De multiples règles peuvent correspondre et elles peuvent avoir un résultat différent. Sera sélectionnée la règle avec la valeur de résultat prioritaire.

Prenons, par exemple, les valeurs en entrée « TRES BON » et « 70 » qui correspondent aux règles 2 et 3. Le résultat renvoyé est différent entre ces deux règles : « ELEVE » pour la règle 2 et « FAIBLE » pour la règle 3. Il y a une incohérence mais la stratégie « P » va permettre de sélectionner une de ces deux règles en priorité suivant la liste des valeurs possibles en résultat (en haut à droite : "ELEVE","MOYEN","FAIBLE"). On remarque que la valeur « ELEVE » est prioritaire à la valeur « FAIBLE », simplement parce qu’elle arrive en premier dans la liste. Le résultat sélectionné sera donc celui de la règle 2, à savoir « ELEVE ».

A noter que les règles ne sont pas exhaustives car les valeurs en entrée « MOYEN » et « 30 » ou « BON » et « 40 » ne sont pas prévues dans la table de décision. Pour ces cas, nous avons spécifié une valeur par défaut (élément souligné dans la liste des résultats possibles : "MOYEN"). Ainsi, si aucune règle n’est vérifiée, c’est cette valeur, ici « MOYEN » qui sera retournée.

Nous aurions pu avoir deux données en entrée de cette décision (âge et état de santé) mais j’ai préféré une seule donnée en entrée (personne) dont le type structuré tPersonne est composé de ces 2 attributs.

Certains pourraient dire qu’ils auraient codé cet exemple en quelques lignes avec leur langage préféré alors pourquoi s’embêter à utiliser cette nouvelle méthode ? A ces personnes, je réponds ceci :

Cet exemple n’est pas représentatif : l’usage de DMN est préconisé pour des projets manipulant un nombre important de règles métiers : calculateur de prix ou de taxes, systèmes de recommandations de produits ou de validations de demandes de tous types, calculs de retraite… Généralement, ces projets ont généralement aussi des contraintes réglementaires qui changent périodiquement.

La maintenance des applications s’en trouve améliorée : plus de règles métier noyées dans le code applicatif. De nombreux facteurs peuvent être à l’origine d’un code dit « spaghetti » (tordu et compliqué), comme par exemple, par de nombreuses modifications sur un code complexe pendant une longue période, par l’inexpérience de développeurs, par un manque de revues de code ou par des revues de code inefficaces…

Le paradigme de DMN est de donner accès aux règles de gestion à des personnes ayant un profil technique ou métier. Alors oublions l’usage de Java ou d’un autre langage du même genre hors de portée d’un Citizen developer. Les règles peuvent être spécifiées directement par des personnes ayant le savoir-faire fonctionnel.

En conclusion

Le but principal de DMN est de fournir une notation aisément compréhensible par tous, sans obligatoirement avoir besoin de posséder des connaissances techniques. Les experts métiers peuvent créer des règles métiers ainsi que des tables de décision, puis affiner ces règles pour les livrer aux développeurs responsables d'automatiser ces règles métiers. Finalement, ces experts métiers ont davantage la capacité de gérer et contrôler ces règles.

Un autre objectif de DMN est d'assurer que les modèles de règles métiers soient compatibles : Ils sont représentés en XML et ainsi peuvent être interprétés par différents outils logiciels.

La norme DMN n'est pas dépendante de la norme BPMN, on peut les utiliser chacune séparément sans jamais faire référence à l’autre. De plus, seule la norme BPMN peut utiliser la norme DMN, pas l’inverse.

Pour la logique de décision, DMN fournit un langage d'expression appelé FEEL pour définir et assembler des tables de décision, des calculs, des expressions comme if/then/else, des appels à Java ou à du PMML (Predictive Model Markup Language) qui est une sérialisation XML d’un modèle entrainé de machine learning.

Le développement de modèles DMN nécessite un type de logiciels spécialisés, des savoir-faire nés de l’expérience et de la pratique pour structurer la logique métier ainsi que de bonnes compétences en algorithmie.