Cet article est un des articles de la suite `Vision des ESBs par un architecte d’entreprise`.
La mise en place d’un ESB dans un SI peut se faire au travers de plusieurs approches différentes.
Approche « top/down »
Cette approche part du métier de l’entreprise pour descendre jusqu’à la technique. Elle est assimilable à une refonte du SI. Il y a besoin d’urbaniser le SI en îlots fonctionnels et quartiers, de bien définir les processus métiers de l’entreprise, …, pour définir la cartographie fonctionnelle du SI. Il s’avère que c’est très souvent des projets longs, coûteux, avec un effet « tunnel » de plusieurs années, et souvent n’aboutissent pas vraiment.
Approche « bottom/up »
Cette approche est l’inverse de l’approche « top/down ». Un petit projet se charge de mettre en place l’ESB pour ses besoins. Puis un autre vient se greffer, et ainsi de suite. Cette approche ne permet pas l’agilité requise au paragraphe précédent, car chaque projet ne voit que ses objectifs et ne se préoccupe du reste du SI.
Approche « mixte »
L’approche « bottom/up » est intéressante, car permet la mise en œuvre d’un ESB à coût réduit comparativement à l’approche « top/down », et avec un ROI1 visible plus rapidement. Il suffit d’adjoindre à cette approche quelques règles et bonne pratique pour faire en sorte de conserver l’agilité, par exemple l’application d’une démarche d’architecture d’entreprise restreinte au contexte du petit projet, sans ignorer le reste du SI.
L’urbanisation globale du SI sera faite alors au fur et à mesure que les projets utiliseront l’ESB. Ceci a alors une contrainte sur le choix de l’ESB fait au premier projet, l’ESB doit être en mesure d’évoluer avec les projets qui vont arriver, c’est à dire : être capable de monter en charge, d’être hautement disponible ou d’être agile.
Il reste tout de même un point négatif à cette approche. Le coût d’acquisition de l’ESB peut être très important comparativement au budget du projet. Par exemple, le coût d’acquisition d’un ESB commercial peut être de plusieurs centaines de milliers d’euros. On ne peut imaginer qu’un projet d’à peine 100k€ puisse se permettre cet achat !. La solution est alors du coté des ESBs opensource dont les coûts d’entrée sont réduits.
Indépendance vis-à-vis de l’organisation de l’entreprise
Les grandes entreprises sont très souvent organisées par domaine fonctionnel. Leur IT est aussi très souvent organisé en suivant ces mêmes domaines. L’introduction d’un ESB impacte classiquement l’organisation de deux manières différentes :
création d’un équipe dédiée ESB : cette équipe a en charge tous les développements effectués sur l’ESB. D’un coté, cette organisation permet de mettre très facilement des règles de développement sur l’ESB afin d’en assurer l’agilité. Mais d’un autre coté, cette équipe devra avoir la pleine connaissance du métier de l’entreprise (certes pas en détails), ce qui est source de problème. Et c’est sans compter sur les problématiques de planning qui arriveront, car les équipes des domaines fonctionnels qui vont interagir avec l’équipe ESB ont leurs contraintes. Au final, cette équipe ESB va devenir le « bottle neck » du développement.
ou, chaque domaine fonctionnel assure sa part : cette organisation a l’avantage de supprimer le goulot d’étranglement par rapport à l’organisation précédente, et aussi d’avoir des personnes maîtrisant parfaitement le métier. Un autre point positif, et que chaque domaine fonctionnel est très indépendant des autres, jusqu’à la mise en production qu’il planifie en fonction de ses besoins. Par contre, il sera très compliqué de définir des modèles de données communs (ex : modèle métier et pivot), de définir des services avec la bonne granularité (comment faire évoluer un service développé par une autre équipe ?). On commence à voir que cette organisation mets en péril l’agilité de l’ESB avec le temps.
Une organisation intermédiaire pourrait gommer les inconvénients de chacune des organisations précédentes, toute en conservant ces avantages. L’idée est de partir d’une organisation basée sur des équipes par domaine fonctionnel. Chacune de ces équipes développe ces services comme elle le souhaite. Par contre dans le processus de développement, il y a une nouvelle étape : un contrôle de qualité effectué par une équipe dédiée ESB. Ce contrôle consiste à vérifier que les bonnes pratiques sont respectées (modèle métier, pivot), que les documents associés aux services sont publiés, … Si le contrôle décèle des irrégularités, un « no go » est prononcé, et le service repart en développement, comme si un test de validation obligatoire avait échoué. Le temps de contrôle étant très rapide par rapport au temps de développement global, il ne peut être considéré comme « bottle neck ».
En ce qui concerne le cas de faire évoluer un service, initialement développé par un domaine fonctionnel, pour un autre domaine fonctionnel, il suffit de mettre en place dans le contrat de service un item concernant cette modification. Ex : « toute demande de modification du service XXXX est à soumettre de manière détaillée et argumentée par écrit à , une réponse incluant le délai de développement sera faite sous un délai maximum de N jours. Pour information, une modification de service est généralement disponible sous X jours ». Ainsi l’équipe utilisant le service à modifier pourra intégrer ces délais dans son propre planning.
