Un court historique du BPM – Troisième partie

Un court historique du BPM – Troisième partie
sur une idée originale de Sandy Kemsley

A la fin des années 90, quand les éditeurs d’outils workflow réalisèrent les bénéfices apportés par l’EAI et comprirent comment cette technologie pouvait remplacer les intégrations lourdes et coûteuses habituellement mises en oeuvre dans le cadre des projets workflow, ils commencèrent à ajouter des fonctionnalités EAI à leurs moteurs de workflow. A quelques exceptions près, il s’agissait généralement d’avoir un accord avec un éditeur d’EAI et d’intégrer en OEM son moteur. Afin de faciliter la mise en oeuvre, l’outil workflow proposait en plus une intégration fine dans ses propres outils.

La réalité est bien celle-ci est en fait très peu de projets faisant appel aux deux composantes Workflow et EAI ainsi intégrées virent le jour. La complexité du montage, de l’architecture et le besoin persistant d’un minimum d’intégration venaient en effet alourdir les charges au niveau du projet et l’enveloppe financière au niveau des logiciels. D’autre part, les entreprises disposant déjà d’EAI souhaitaient pouvoir utiliser leur propre moteur qui n’était qu’à peu d’exceptions près pas celui intégré par l’outil workflow, et inversement. C’était là un facteur aggravant en avant-vente workflow car la réalisation d’un connecteur spécifique entre le workflow et l’EAI pour les besoins d’un projet venait contrecarrer le bénéfice tiré de l’utilisation de l’EAI. Il devenait alors plus simple et moins coûteux de réaliser des intégrations point à point.

Sans surprise, les éditeurs d’EAI virent également l’avantage de disposer d’étapes proposant des interactions ‘utilisateurs’ à intégrer dans leurs procesus de systèmes à systèmes et ils commencèrent à inclure des fonctionnalités ‘utilisateurs’ rudimentaires dans leurs produits.
Ces fonctionnalités, généralement proposées par l’éditeur lui-même plutôt que par l’intégration d’un outil workflow du marché, étaient très rudimentaires car elles n’avaient pour seul but que d’adresser les besoins de gestion des exceptions ne pouvant être adressées automatiquement lors du déroulement des processus. On pourrait d’ailleurs dire que ces processus étaient « interrompus par l’utilisateur » plutôt que « interagissant avec l’utilisateur ».

Même si on disposait alors (en théorie) de systèmes adressant toute la gamme de besoins en terme d’intégration, il s’agissait en fait plus de systèmes workflow avec un peu d’EAI ou de systèmes EAI avec un peu de workflow, et les éditeurs continuaient à se focalisaient sur leurs suites initiales.

L’allongement des cycles de décision en phase d’avant-projet fût également un des effets de bord qui firent que ces architectures bicéphales furent peu mises en oeuvre. En effet, le fait d’avoir à choisir deux outils au lieu d’un lors de l’acquisition d’un moteur workflow (l’EAI embarqué en OEM n’étant pas nécessairement celui choisi par l’entreprise) complexifiait la démarche et venait fragiliser le montage rendant les Directions peu enclines à donner leur accord.

A suivre: diversification collatérale

Retrouvez l’article original sur le blog de Sandy Kemsley

Lire la suite :

• Un court historique du BPM – Deuxième partie
• Un court historique du BPM – Quatrième partie
• Un processus simple est un processus efficace
• Un court historique du BPM – Sixième partie
• Un court historique du BPM – Cinquième partie
• Différence entre workflow et moteur de règles
• Un court historique du BPM – Septième partie
• Découvrir la valeur du BPM orienté Contenu pour mettre en oeuvre l’innovation – 2
• Un court historique du BPM – Première partie
• BPM et SOA, le duo gagnant ?