BPMN 2.0 : ce que la nouvelle version de la notation va apporter (ou pas)
Portabilité, propriétés d'exécution des modèles de processus... En cours de finalisation au sein de l'OMG, la version 2.0 du langage BPMN apporte son lot de nouveautés.
Bpms.info a toujours suivi avec intérêt l'évolution de la notation BPMN . Il y a deux ans, dans l'article « BPMN, la norme du BPM » nous parlions des principes de cette norme et déjà nous évoquions la préparation de la version 2.0 pour couvrir ses lacunes.
Qu'en est-il exactement ? Les souhaits formulés par la communauté ont-ils été exaucés ?
Comme en témoigne sur son blog Bruce Silver, auteur du site "BPMS Watch website" et du livre "BPMN Method and Style", considéré comme un expert dans le domaine et membre actif de la commission chargée de rédiger les nouvelles spécifications, cette version 2.0 n'a pas répondu à toutes les attentes mais a fourni des solutions concrètes sur un certain nombre de points. En voici quelques exemples.
Portabilité des modèles entre les différents outils
Portabilité vers un outil BPM
Parmi les principaux sujets traités par l'OMG, définir un schéma d'échange standard basé sur XML pour l'échange de modèles exécutables, en était le principal.
Le format XML, qui sera défini, est un enjeu important car BPMN 2.0 a la volonté de devenir un langage de modélisation exécutable en remplacement de BPEL.
L'intérêt étant bien sûr d'être en capacité d'exécuter directement les modèles dans un moteur de workflow. Ce sera une grande avancée pour les clients d'IBM, Oracle, SAP & autres fournisseurs qui prendront en compte BPMN 2.0.
Malheureusement, le schéma XML défini ne suffira probablement pas. Cela requiert également des spécifications pour lister les éléments à inclure pour l'échange entre les différents outils à l'instar de BPEL, qui lui possède des spécifications complètes - différents niveaux de portabilité - basées sur XPDL.
Portabilité entre outils BPA
Actuellement, échanger un Modèle d'un outil par un autre signifie souvent devoir tout reprendre, et pourtant BPMN est supposé être un standard : le schéma d'échange standard basé sur XML devrait répondre à ce manque. Malheureusement la portabilité au niveau graphique risque d'être décevante.
Si l'on exporte un modèle BPMN d'un outil à un autre, on n'a pas la prétention que la représentation soit exactement la même, mais que la mise en forme soit préservée.
Et pourtant, les informations graphiques comme la taille, la position des couloirs, activités, connecteurs et événements ne sont pas définis dans un schéma XML standard mais dans ce que l'on appelle une librairie nommée "M1 library" qui risque de compliquer la portabilité de son contenu avec des outils basés sur XML.
Enrichissement de la bibliothèque d'événements
La grande différence entre BPMN et d'autres notations, c'est que BPMN utilise une approche événementielle très développée.
Un événement signale que quelque chose s'est passée & BPMN permet de dire comment le Processus doit répondre : commencer une nouvelle instance, rediriger vers un traitement exceptionnel, reprendre un flux qui était en attente, ou stopper une activité en cours. BPMN 2.0 se propose d'ajouter des événements appelés "événements de non interruption".
Concrètement, vous voulez simplement envoyer un rappel ou envoyer une notification à un manager tout en laissant la tâche se dérouler. De la même façon, si un client met à jour une commande, il n'est pas nécessaire d'abandonner la préparation de la commande, mais simplement y ajouter d'autres articles.
Un autre événement fera également son apparition : escalation en anglais. Il se traduira par un signal qui est généré dans le processus. Un événement de ce type au niveau d'une tâche manuelle signifie que, pendant que la tâche est exécutée, si l'événement survient, cela déclenchera, soit l'annulation de la tâche pour réaliser autre chose ou commencer une autre série d'activités en parallèle.
Un dernier événement sera rajouté également pour faciliter le traitement des exceptions. BPMN 1.x proposait déjà une solution pour ce type de flux (boundary event) mais un bon nombre d'outils du marché pourtant estampillés BPMN ne respecte pas la norme sur ce point car les exceptions étaient mal gérées dans les moteurs BPEL.
Pour faciliter la prise en compte d'exceptions, un événement appelé événement sous processus sera créé. Un sous processus lié à l'événement encapsulera le traitement exceptionnel quand l'événement surviendra.
Cela répond à la plupart des situations où les boundary events sont actuellement utilisés et c'est plus facile à implémenter par les moteurs de workflow existants. Cela enlève donc une importante barrière en permettant aux fournisseurs actuels de respecter la notation dans son ensemble.
Ajout d'un type de tâche spécifique : la Règle de gestion
Enfin, et non des moindres, nous devrions voir apparaître une tâche « règle de gestion ».
En effet, ce sont les relations entre les processus et les règles de gestion qui génèrent le plus de désinformation et de frustration.
Le problème principal vient du fait que les outils de modélisation n'ont jamais fourni une façon claire de représenter les règles de gestion dans les processus, on ne parle pas ici des règles de routage qui clarifient le gateway.
Les experts métiers et la communauté BPM sont aujourd'hui d'accord sur ce que l'on entend par règle de gestion. BPMN 2.0 proposera donc une tâche spécifique qui indiquera clairement l'utilisation d'une règle de gestion, autrement appelée décision ou règle du jeu.
Elle retournera seulement le résultat qui sera utilisé de différentes manières dans le processus. A noter que cette règle de gestion sera placée dans le flux, à l'instar d'une tâche, alors qu'elle n'est pas une action dans le processus.
Ce choix peut paraître étrange quand d'autres méthodes de modélisation proposent de relier directement cette règle de gestion aux tâches.
BPMN 2.0 offre donc plusieurs avancées qui raviront la communauté, malheureusement, tous les sujets n'ont pas pu être satisfaits et un certain nombre de personnes se retrouveront à fonder leurs espoirs sur la version 3.0.
En effet, s'il est vrai que les précédentes versions n'avaient pas réussi à distinguer les informations relatives à la modélisation et celles relatives à l'exécution, cela importait moins car aucun outil n'utilisait BPMN pour l'exécution des informations contenues dans les attributs.
Chacun utilisait sa propre méthode. La partie visible du diagramme, c'est-à-dire la partie modélisation était ce qui importait lorsqu'on utilisait BPMN 1.x. Pour BPMN 2.0 non plus, cette distinction n'est pas faite.
Pas de distinction entre les informations liées à la modélisation et celle liées à l'exécution
On aurait donc pu penser que L'OMG allait y apporter une solution, pourtant, aucun consensus n'est ressorti sur le détail des informations de modélisation requises pour être correctement interprété par les différents outils de modélisation pure. Seules certaines données liées aux interfaces, aux messages & opérations WSDL, et autres détails liés à l'exécution seront facultatifs.
Sans liste officielle, chaque éditeur choisira librement les informations relatives à la modélisation qui seront reprises dans leur outil, adieu donc à la standardisation.
Autre point non couvert par BPMN 2.0, la sémantique des modèles non exécutables.
Pas de distinction entre sémantique des modèles exécutables et non exécutables
BPMN présume qu'essentiellement la sémantique des modèles exécutables et non exécutables est la même, en réalité, ce n'est pas si simple.
Par exemple, pour l'interprétation du flux, une activité A est terminée, l'activité B démarre immédiatement, c'est de cette manière qu'un moteur de workflow fonctionne.
Pourtant, dans un modèle non exécutable, on aimerait pouvoir spécifier que l'activité B ne s'exécute pas nécessairement tout de suite après (cela arrive souvent à un niveau peu détaillé).
On aimerait pouvoir ajouter cette information non visible dans le modèle et qu'elle soit transmise d'un outil à un autre, malheureusement BPMN 2.0 ne prend pas en compte ce détail.
Un dernier point qui prouve que l'équipe chargée de définir la Version 2 s'est concentrée sur la partie exécution et non sur la partie modélisation est que les propriétés liées à la simulation n'ont pas non plus été cadrées.
Propriétés liées à la simulation non définies
La plupart des outils BPMN offre aujourd'hui des fonctionnalités de simulation basées sur des paramètres spécifiques des activités, des rôles, des connecteurs et des événements. La standardisation de ces paramètres n'a pas été définie et laisse donc le champ libre aux éditeurs.
Conclusion
Alors que la première version de BPMN avait pour objectif de normaliser la notation, BPMN 2.0 s'est clairement concentré sur la partie exécutable des modèles laissant une nouvelle fois en attente les modélisateurs et analystes métier.
On peut même penser que cette population va encore s'éloigner davantage de cette notation qui servira surtout à une modélisation dans le but d'exécuter les processus modélisés. Pour le public visé, celui qui va transformer un processus métier en processus exécutable, la V2.0 est pleine de promesses, attendons de voir maintenant quand les outils d'automatisation (BPM) proposeront cette nouvelle version.