Au fil des rendez-vous chez mes clients et prospects, je rencontre de plus en plus d’entreprises qui voient le BPM comme la mise en oeuvre d’une infrastructure de services de gestion des contenus et des processus et me parlent de SOA autant que d’applications métiers à part entière.
La question de savoir si BPM et SOA représentent plus ou moins la même chose ou bien au contraire des approches différentes est particulièrement intéressante et pertinente.
J’ai lu récemment une note de David Ogren’s qui travaille désormais pour BEA (et Fuego il n’y a pas si longtemps) et qui lui voit tout ça de la façon suivante : le BPM permet de mettre en oeuvre des applications métiers sur la base d’une plateforme (approche Top Down) tandis que le SOA permet de mettre en oeuvre une infrastructure de services qui permettra d’adresser des applications à venir (approche Bottom Up). Cet avis est intéressant et je le rejoins assez volontiers.
Ceci dit, ce que je recommande généralement à qui veut bien m’entendre est d’adopter une stratégie intermédiaire. L’entreprise identifie un processus métier dont la mise en oeuvre est censée ne pas poser trop de problèmes et ne pas demander une gestion du changement trop importante, elle met en oeuvre ce processus en bâtissant une application conçue de telle façon que certaines des briques sous-jacentes puissent être réutilisées dans le cadre d’une architecture à venir de type SOA. Après coup, l’Entreprise aura toute liberté de faire son choix et de s’orienter vers la mise en oeuvre d’applications complémentaires sans architecture de services particulière ou bien au contraire de développer cette architecture initiale et de l’enrichir pour aller vers quelque chose qui ressemble à du SOA. Finalement cela me paraît une approche intéressante, mélant besoin métier à court terme et stratégie d’Entreprise.
Je suis vraiment curieux d’avoir vos commentaires sur ce point car plein de choses restent à dire sur le sujet et à éclaircir surtout.
Retrouvez l’article en question sur ebizq :
Dés qu’on aborde le sujet du BPM on retrouve omni présente son alliée la SOA car il existe une forte complémentarité entre eux. Alors que le BPM permet aux entreprises de mieux appréhender leurs processus métier, l’architecture SOA résout les problèmes de réutilisabilité et d’élimination des données dupliquées dans les infrastructures du système informatique. L’association de ces deux approches améliore significativement le système d’information et la gestion des processus métier, au service de leur croissance. Et comme Le BPM offre au métier la possibilité de mettre en œuvre du changement quand il le souhaite, une infrastructure flexible de type SOA est nécessaire.
j’ai trouvé ce ci dans « The Service-Oriented Media Enterprise SOA,BPM, and Web Services in Professional Media Systems » de John Footen, Joey Faust « Si l’architecture orienté service est le coté architecture et technique du système, le business process management est le coté humain. SOA prend en considération les services que le système offre, leurs interfaces et la communication entre eux. Mais une solution efficace demande beaucoup plus que ces trois éléments, elle nécessite une façon de concevoir la solution basé sur des besoins métier clairs, une méthodologie d’utilisation du système…puisque le BPM s’approprie la tâche du développement et de l’amélioration des processus métiers et celle de la conception des liens que ces processus ont avec le système, c’est vraiment un concept plus large que la SOA qui peut être considéré comme une partie du BPM» ces propos soutiennent la note de David Ogren’s du fait que SOA et BPM ont deux approche différente, et on y comprend que la SOA a besoin du BPM car Il est essentiel que tout projet de SOA tienne compte, dès le départ, des problématiques métier de l’entreprise, sans BPM SOA n’est qu’une initiative technologique interne qui ne traitent pas directement un problème en entreprise.
Et pour parvenir a profiter de l’association BPM SOA, il faut que la communication soit bien établie entre équipes techniques et opérationnelles, car, sans identifier clairement les problèmes, les priorités et les opportunités associés aux processus, les équipes techniques sont incapables de savoir quels services déployer et avec quelle priorité les déployer.