Un de mes clients m’a récemment poussé cette vidéo de Martin Fowler et Jim Webber sur une présentation acide sur la SOA et son outillage. Je vous partage ma vision.
En résumé, Martin et Jim attaquent là où ça fait mal: au niveau de l’agilité des processus de construction des intermédiations et sur la complexité des outils. Leur constat est (était?) le suivant:
| Middleware propriétaire | Technologies Web Centriques |
| – Non performant – Coûteux – Risqué – Echelle de l’entreprise – Spécialisé – Intégration est une activité à part en tiers |
– Design évolutif – Delivry continue – Pas couteux – Incrémental – Croix avec internet – Intégration contrôlée par le consommateur |
En un mot, ils préconisent la mise en oeuvre d’une démarche de services sans ESB car ils portent une complexité trop importante à contrario de l’approche Web. A ce propos, est-ce l’origine de la vague d’API Management actuelle ?
Bref, je comprends complètement leurs critiques. Pour être franc, j’ai moi-même connu des mastodontes tant sur leurs besoins en ressources matérielles que sur leur incapacité à évoluer. Mais…
Lors de la mise en œuvre d’une démarche SOA outillé, je fais souvent le constat que l’interconnexion est assez coûteuse en effort humain. Il faut beaucoup communiquer pour clarifier les mécanismes envisageables, identifier les contraintes, définir les capacités du système, mettre en corrélation avec les patterns existants, etc. tout ceci avec de nombreux interlocuteurs : les chefs de projets, les architectes logiciels, les architectes systèmes, les architectes SOA et les urbanistes. Malgré tous ces efforts et après d’âpre discussions, le propriétaire du système craint alors des impacts sur ses flux existants et veut donc, tout naturellement, minimiser l’impact de ces nouveautés.