La convergence BPA-BPM est-elle une utopie ?

La combinaison des deux technologies vise à rapprocher les opérationnels qui décrivent, parfois à grandes échelles, leurs processus métier et les informaticiens chargés d'orchestrer ces processus.

L’annonce par Software AG de l’intégration technique des outils Webmethods et Aris n’est pas une surprise : voilà 2 à 3 ans que les éditeurs d’automatisation de processus (communément appelés outils de Workflow ou BPM) s’emploient à créer des ponts techniques avec les outils d’architecture d’entreprise (BPA). Ces rapprochements prennent différentes formes : développement d’interface ( W4/ARIS, Appian/ Mega), intégration OEM (WinDesign/W4, Oracle BPA/BPM) ou rachat pur et simple (Proforma/Metastorm) et donc Aris/Webmethods.

Mais tous poursuivent le même objectif : rapprocher deux mondes, les opérationnels qui décrivent, parfois à grandes échelles, leurs processus métier et les informaticiens chargés d'orchestrer ces processus en étroite collaboration avec les applications métiers existantes.

"Reste que cette transition automatique des deux mondes, déjà tentée par SAP et Oracle sans résultat concluant, est encore un vœu pieu", lisais-je dans 01 Informatique ("Traduire les contenus métier en processus informatiques", par Vincent Berdot dans le numéro du 24/06/2010). Entièrement d'accord sur ce constat mais par sur les raisons invoquées par Sylvain Spenlé dans le même article : "La Modélisation dans Aris ou Mega traduit un processus générique, une gestion de sinistre par exemple. De l'autre côté, le monde de l'exécution reflète une réalité avec ses cas particuliers : la gestion de sinistre appliquée aux domaines de l'épargne ou de la prévoyance. Les deux univers sont trop éloignés pour être rapprochés automatiquement."

En effet, la plupart des projets BPA, en tout cas ceux qui réussissent, ne se contentent pas de décrire quelques processus génériques à des fins de documentation ou de certification. Ils visent au contraire à coller à la réalité opérationnelle dans toute sa complexité (c'est d'ailleurs un frein à l'essor de ces projets car cela est consommateur de temps).

D'où l'espoir que la convergence des deux mondes allait justement permettre de gagner du temps dans la mise en oeuvre de ces processus au niveau applicatif.

Si cette perspective a, jusqu'à présent, généré plus de déception que de satisfaction, ce n'est pas parce que ce pont est irréalisable, c'est simplement parce que tous les acteurs, sans exception, se sont contentés d'une transposition technique : visant à reproduire dans l'outil de BPM le Modèle décrit dans l'outil de BPA. Ce faisant, ils commettent une erreur de fond : la Granularité de ces deux modèles diverge largement. 

Vouloir retrouver 100% des étapes du processus métier dans l'outil BPM signifierait que toutes les étapes métier, même si elles sont hors SI, ont vocation à constituer une étape gérée par le SI : inconcevable et surtout beaucoup trop contraignant.

Le métier doit pouvoir décider quels sont, dans le déroulement du processus métier, les "points de passage obligatoires" que le système informatique, au travers de l'outil de BPM, imposera. De ce point de vue, le modèle technique est potentiellement beaucoup plus simple que le modèle métier qu'il automatise.

Mais l'inverse est également vrai : une tâche anodine du modèle métier tel que "proposer tarifs" va supposer côté BPM une Orchestration de services tellement complexe qu'elle peut nécessiter de nombreux modèles qui s'enchaînent. On est bien loin de la correspondance 1 pour 1 actuellement opérée quand le modèle métier a été parfaitement réalisé ! 

Faut-il pour autant désespérer de cette convergence ? Je ne crois pas. Toute cette charge de regroupement / éclatement est actuellement réalisée manuellement par l'architecte logiciel qui retravaille donc, dans les grandes largeurs, le modèle technique généré. Il suffirait que l'on intègre, côté BPA, des fonctionnalités simples de regroupement / éclatement de tâches pour que la génération du modèle technique puisse diverger du modèle métier tout en maintenant un minimum de cohérence avec ce dernier. Cela suffirait à changer la perception de l'utopie de cette transposition.

Il faudrait aussi au passage que ces mêmes éditeurs de BPM, largement représentés à l'OMG, organisme en charge de la Notation BPMN, en profitent pour introduire cette distinction métier/technique dans ce standard largement utilisé pour opérer ce "pont". Cela ne résout pas tout, il y aura toujours un niveau de personnalisation technique (synchronisation des branches, délimitation des transactions) qui n'a pas vocation à se traduire côté métier mais on aura déjà fait un grand pas.

Rendez-vous debut 2011 pour vérifier si Software AG aura su tirer profit des plâtres essuyés par les précurseurs de la convergence. 

Auteur : Jean-François Pirus, Président Directeur Général de BPMS