Echange Bidirectionnel : La prochaine étape dans la modélisation des processus

Une fois n’est pas coutume, BPMS.info décide de relayer un article du bpminstitute.org, écrit par Bruce SILVER fondateur de Bruce Silver Associates.

L’une des promesses fondamentales du BPMS (Business Process Management System) était d’améliorer l’alignement métier/infrastructure technologique via la mise en œuvre de « modèles ». Nous allons dans la bonne direction mais les outils et les normes ne l’intègrent pas encore complètement. Dans le cadre de la préparation du BPM Think Tank 2006, le rendez-vous de référence sur le thème, je vous ferai une modeste proposition.

Voilà comment BPMS devrait fonctionner : une fois que votre équipe d’analystes processus a terminé de travailler sur l’existant et sur la cible en utilisant des post-it collés un peu partout sur les murs de la salle, ils sont censés les intégrer non pas dans un diagramme mais dans un véritable outil de modélisation. Cet outil devra être basé sur une notation et une sémantique standard et permettre une optimisation des indicateurs de performance à travers la simulation du processus. La notation devra être indépendante de l’architecture en place (par exemple workflow face à l’orchestration de services), intuitive pour tout « utilisateur métier, » et « abstraite » dans le sens où le design est facultatif.

Pourtant, malgré toutes ces restrictions, le modèle devra pouvoir produire le « squelette » d’un processus. Celui-ci pourra alors être importé dans un environnement graphique qui reprendra les caractéristiques principales du processus (enchaînements des tâches, ressources, indicateurs de performance).

Dans ce cas, BPMN (OMG) serait le standard de notation pour la modélisation des processus métier et BPEL (OASIS), le standard graphique dans l’exécution des processus, au moins pour les logiciels BPM basés sur une architecture SOA. Un certain nombre d’outils BPMN peuvent aujourd’hui exporter vers XPDL, le standard de modélisation dans l’exécution des processus hérité de l’architecture Workflow. Jusqu’ici tout va bien, tout du moins en théorie.

Mais le besoin d’exporter un diagramme modélisé par des « utilisateurs métier » vers un modèle BPEL valide crée quelques problèmes. Le premier est que tous les flux modélisés ne sont pas forcément exportables vers BPEL – à moins que vous l’ayez modélisé directement de la « bonne façon ». J’ai découvert cela après avoir retranscrit dans un outil BPMN un modèle fait à la main par un client. Tout allait bien jusqu’au passage en BPEL, toutes les parties du processus affichaient des messages d’erreur. BPEL n’aime pas les segments de processus imbriqués, les boucles vers des tâches en amont et autres manières courantes de modéliser.

Bien sûr, vous pouvez résoudre le problème en reprenant manuellement le modèle en utilisant des processus restructurés, des variables de contrôle et autres choses que les programmeurs utilisent. Au-delà de la transformation du modélisateur en programmeur, le diagramme deviendra incompréhensible aux utilisateurs métier. En définitif, l’effort pour obtenir un modèle BPMN qui soit compatible BPEL est trop important et j’ai simplement réussi à construire le squelette de mon processus directement dans BPEL.

Maintenant vous pourriez dire que ce n’est pas à cause de la notation BPMN mais à cause de l’outil de modélisation utilisé. En outre, puisque le langage BPEL n’est pas fonctionnellement complet – il omet des choses vraiment fondamentales comme les tâches humaines, les sous-processus, et la transformation de données – chaque système BPMS basé sur BPEL va ajouter ces éléments manquant en utilisant ses propres éléments à disposition.

En aucune façon un éditeur ne peut réussir à proposer une exportation juste et complète vers n’importe quel outil BPEL. A la place, l’outil de modélisation pourrait au moins sauvegarder le modèle BPMN et laisser l’environnement produire le modèle BPEL via l’importation. Cela permettrait également d’éviter de torturer le modèle BPMN juste pour obtenir un modèle BPEL valide.

Ce serait logique, sauf que les créateurs de BPMN ont simplement normalisé les formes et les liens des diagrammes, pas comment le diagramme devrait être sauvegardé comme document XML ! Il n’y a donc aucune manière standard de partager des modèles avec des outils d’exécution des processus autres qu’en les exportant vers du BPEL (ou du XPDL). Ce manque a été largement discuté lors du Think Tank de l’an passé, et OMG s’y attèle maintenant avec la définition d’un méta-modèle BPDM (Business Process Definition Metamodel). Espérons que ces efforts aboutiront rapidement.
Mais maintenant nous arrivons au second problème, voici le cœur de ma proposition.

La question est de savoir comment garder le parallélisme entre le modèle BPMN et l’évolution de BPEL. Le BPM est basé sur la notion de cycle d’amélioration continue des processus. Rappelez-vous, modélisation et analyse ne sont pas simplement la première étape d’un projet BPM, mais elles sont répétées régulièrement pour optimiser la performance et faire face aux exigences de changement.

Les indicateurs réels de performance redéfinissent continuellement la modélisation et les paramètres de simulation, le processus lui-même doit pouvoir être adapté pour répondre à la souplesse inhérente aux services d’orchestration. Mais tout ceci implique que le processus modélisé (avec un diagramme BPMN complété par des indicateurs de performance et des paramètres de simulation) reste valable après la mise en œuvre de BPEL. Le modèle métier et le modèle d’exécution doivent être interchangeables. Cela ne peut pas être unilatéral.

Ainsi le prochain défi est de pouvoir créer un modèle BPMN à partir d’un modèle BPEL. Cela ne signifie pas que tous les détails doivent apparaître dans le diagramme BPMN, mais ils ne devraient pas être perdus non plus. Vous devriez pouvoir passer de l’un à l’autre sans perdre aucune des informations contenues dans le modèle initial. Dans ce sens, BPMN devient un diagramme orienté métier qui contient des paramètres de simulation et des détails d’exécution optionnels tout en restant interchangeable et avec un fonctionnement équivalent à un modèle BPEL. Des changements dans le processus devraient pouvoir se faire dans chacun des deux environnements.

J’ai le sentiment que créer un diagramme BPMN à partir de BPEL devrait être plus facile que dans l’autre sens, et que mettre en application un échange bidirectionnel fournirait probablement des opportunités pour les éditeurs d’outils des BPMN et BPEL.

Auteur : Bruce SILVER est un analyste indépendant couvrant la technologie BPMS dans le secteur de l’industrie et auteur du « 2006 BPMS Report series » disponible sur bpminstitute.org. Des articles et rapports complémentaires sont disponibles sur www.brsilver.com.

Echange Bidirectionnel : La prochaine étape dans la modélisation des processus