Question classique. Devant la déferlante des acronymes, il n’est pas toujours facile de vraiment comprendre les enjeux, surtout lorsque la confusion est possible, notamment sur leur interdépendance. Dans le domaine qui nous intéresse, les deux sigles qui nous reviennent le plus souvent se trouvent être BPM (Business Process Management) et SOA (Service Oriented Architecture). Quel est le rapport entre les deux ?

Sans rentrer dans les détails, le BPM consiste à formaliser et automatiser les processus métier de l’entreprise, en incluant les utilisateurs et les applications dans les mêmes processus. Pour ce faire, il est nécessaire de mettre en place une solution logicielle fournissant d’une part des outils de paramétrage pour la modélisation et la description des enchaînements des étapes des processus, et d’autre part un moteur d’exécution qui va traiter chacun des dossiers initiés par des utilisateurs (agent du front office, acheteur…), des événements (nouveau mail, nouveau fichier XML…) ou par des applications (appel API, message applicatif, web service…). La suite logicielle de BPM fournit par défaut les techniques nécessaires pour traiter ces trois « populations », que ce soit pour le démarrage d’un nouveau dossier, le traitement d’une étape, ou chaque « intervenant » apportera sa valeur ajoutée au dossier en cours de traitement ou l’accès à une ressource du système d’information.

La SOA est une façon de concevoir, déployer et administrer l’infrastructure logicielle dans laquelle les ressources sont exposées sous la forme de services indépendants accessibles sous une forme standardisée par les personnes et les systèmes.

Un service est une tâche métier ou une fonction correctement définie et répétable qui peut être appelé d'une façon standard.  La nature de cette fonction peut être plus ou moins étendue. Ceci peut être une simple tâche unitaire, comme mettre à jour l’adresse d’un employé, ou une tâche beaucoup plus complexe mettant en œuvre plusieurs actions et un certain nombre de résultats possibles.

La convergence entre SOA et BPM semble relativement évidente, un processus devient un service composé de services élémentaires que sont les étapes du processus ; de même le processus peut être consommateur de services standard du système d’information.

L’approche conjointe du BPM et de la SOA répond à une autre problématique et qui est probablement la plus complexe : comment définir la granularité des services, comment organiser la refonte ? En effet mettre en œuvre la SOA est un travail de refonte du système d’information, avec les risques que cela comporte d’effet tunnel si un certain nombre d’objectifs opérationnels ou fonctionnels ne sont pas fixés. L’expérience BPM montre que la mise en place des processus donne, au fil de l’eau de leur formalisation, la marche à suivre pour le passage progressif des applications à interfacer vers une architecture SOA, car le BPM est pas essence centré sur des besoins métier.

Enfin, cette convergence ne sera bénéfique que si l’on n’oublie pas que le BPM n’est pas un outil d’orchestration de service, mais bien une démarche centrée sur la formalisation des processus métier et donc centré sur le besoin des utilisateurs.