Discussion :

[VirusCrazy]

Bonjour à tous,

Après avoir longuement étudié les articles et documents scientifiques sur les processus métier, BPM... je me tourne vers vous pour avoir votre avis. J'ai eu à rédiger une étude sur les langages de modélisation de processus métier dans les SI.

Après confirmation auprès de mon professeur il s'agissait bien des langages utilisés à partir de la modélisation graphique par BPMN ou UML donc des langages du genre XPDL, BPEL...

Ne connaissant pas ce sujet à la base, j'ai la désagréable sensation de ne pas avoir étudié tous les langages. Je suis partie du principe de parler des langages d'exécution implémentables dans les moteurs de workflow et de ceux utilisés pour interagir avec d'autres organisations. Voici les langages dont j'ai parlé :XPDL, BPDM, BPEL,WS-CDL, Wf-XML

Qu'en pensez vous? Quels autres langages auriez vous abordé?

J'ai une autre question, j'ai lu à plusieurs reprises dans le forum que le BPEL n'était pas un langage adéquat aux processus métiers. Quels sont les arguments en sa défaveur?

Merci beaucoup de votre attention.

[Mickael_Istria]

Hello,

Le langage d'échange qui s'impose dans l'industrie depuis quelques mois est BPMN2.
Niveau langage d'exécution, il ne faut pas oublier que BPMN2 a une spécification d'exécution (qui souffre des memes lacunes que XPDL: tout est basé sur l'extensibilité si bien que beaucoup de choses sont "custom" a une implémentations).

BPDM, Wf-XML & cie sont a priori resté assez expérimentaux et/ou académiques sans trop percer dans l'industrie; BPEL est maintenant le mouton noir du BPM, qui rend les choses plus compliquées qu'elles ne le sont en vrai.
J'ai fait un pamphlet contre BPEL dans un autre post de ce site, je te laisse chercher pour plus de détails.

[VirusCrazy]

Bonsoir,

Merci pour ta réponse.

Si j'ai bien compris, les langages d'exécution les plus en vogues dans l'industrie sont BPMN2 et XPDL. Mais tous deux souffrent que tout soit basés sur l'extensibilité. Reste t'il des langages qui n'aient pas ce désavantage et soient intéressant à utiliser?

[Mickael_Istria]

Le fait est que chaque "vendeur" de solution BPM a ses propres features qui dépassent ce qui était prévu par les standards. Les standards spécifient l'essentiel, mais pas ce qui fait la différence entre 2 vendeurs, c'est pour ca qu'ils sont rendus extensibles.
A ma connaissance, il n'existe pas de langage qui modélise tout parfaitement. Et j'irai meme jusqu'a croire qu'un tel langage ne peux pas exister!
Pour Bonita du coup on a pris le parti d'avoir notre propre modele d'exécution et d'intéragir avec les langages standards par les imports/exports. Et ca marche plutot bien!

[VirusCrazy]

Merci beaucoup pour tes réponses constructives.

Donc au final, plusieurs moteurs ont développé leur propre langage et les autres utilisent les standards. Corrige moi si je me trompe.

La liste de langage étudiés (cités dans mon premier post) te parait elle pertinente pour un sujet universitaire? D'après toi, y a t'il d'autres langages dont j'aurais pu parler?

Le but de mon travail était de faire une étude comparative. Je pense que pour mon oral je ferais un focus sur BPMN2, XPDL et BPEL en faisant un apparté sur les solutions proposées par les BPMS comme BOnita . Cela te parait'il pertinent?

Merci beaucoup

[Mickael_Istria]

Je pense qu'avec ces sujets, tu seras tres proches de l'industrie et de l'état actuel du monde du BPM, ce qui est tres bien. Avec ca tu auras une vraie étude comparative de ce qui se fait actuellement dans le milieu. Bref, du tres concret!

Comme c'est une étude que tu vas présenter de maniere plus ou moins académique, tu peux aussi en profiter pour donner quelques pistes sur ce qui se fait dans la recherche en matiere de BPM, pour t'informer sur ce que sera le futur (c'est souvent aussi l'un des intérets de l'étude). Pour le coup je peux plus trop t'aider, le seul truc dont j'ai entendu parler c'est le BPM sémantique et compagnie. Pour ca il faut commencer par regarder le programme de conf IEEE en rapport avec le BPM.

Bonne continuation.

[VirusCrazy]

Merci beaucoup