ESB et retour sur investissement

Fonctionnalités

Les fonctionnalités des ESB peuvent être cataloguées en 3 classes distinctes. Initialement limitées à de la médiation technique entre un consommateur et un fournisseur de service qui communiquent dans des formats différents avec des protocoles différents à des cadences différentes, elles se sont progressivement étendues à l’orchestration de services de plusieurs fournisseurs au sein de processus métier décrits dans une notation standardisée (BPMN) exécutés dans un langage standardisé (BPEL). Arrivent aujourd’hui des fonctionnalités évoluées : elles déclenchent ou font progresser des processus grâce à des situations décrites dans un moteur de règles intégré ; elles tiennent des statistiques sur les processus exécutés pour en optimiser les étapes ; elles corrèlent des événements unitaires en événements complexes sur un laps de temps donné ; elles assurent la sécurité technique et / ou applicative des services. Sur l’ensemble de ces 3 classes, nous avons dénombré 18 types de fonctionnalités qu’il est pertinent d’étudier pour choisir un ESB : routage, transcodage, enrichissement, décomposition, agrégation, temporisation, conversion, adaptateur, abonnement, sécurité, monitoring, monitoring métier, qualité de service, processus techniques et métiers, contexte, règles, événements complexes, gouvernance. Au vue de ces possibilités, l’ESB devient une passerelle technico fonctionnelle qui maximise les traitements sur les flux en minimisant les temps de latence et ainsi cannibalise progressivement des outils amont ou aval qui ajoutent un hop supplémentaire. Le nouveau créneau des boitiers ESB témoigne de cette volonté hégémonique de faire toujours plus de traitements en toujours moins de temps.

Compétence et gouvernance

A la différence d’une brique d’infrastructure telle un serveur d’application dans lequel sont simplement installées des applications développées en mode projet, l’ESB demande une compétence et une gouvernance spécifiques pour coordonner de façon transverse les services et les processus qui s’y exécutent ou y transitent. Une équipe ESB peut être en charge de développer un « framework » :

• Pour offrir des modes de médiation génériques (asynchrone, sécurisé, caché, audité, rejoué, routé, surveillé, capé…) mis à disposition sous forme de politiques d’accès, en recouvrement ou en extension des normes WS-*. Si les modes génériques ne suffisent pas, un projet peut demander à l’équipe d’en créer des spécifiques,
• Pour supporter des fonctionnalités d’orchestration basiques, comme des sous-processus pour attendre un événement avec timeout et relance, pour gérer les exceptions par appel aux opérations de compensation associées, pour invoquer un moteur de règles qui affecte une tâche à un utilisateur dont l’agenda est libre…,
• Pour assurer l’interopérabilité des services, en imposant des contraintes au-delà du BP 1.1, comme un entête SOAP avec le code des applications communicantes, la remonté d’exceptions normalisées des implémentations de service, la fourniture obligatoire d’opérations de compensation sur les opérations non transactionnelles…

Au-delà du framework, l’équipe peut également édicter des bonnes pratiques SOA comme :

• privilégier les appels asynchrones pour une meilleure tolérance aux fluctuations de performances et aux pannes,
• privilégier des transformations portables avec des standards XSLT, XPATH, XQUERY sur des mappings configurés dans l’ESB,
• obliger à publier les services dans un registre de conception au travers d’un workflow ou des acteurs techniques et métier valident techniquement et fonctionnellement les services.

Ce mode de gouvernance de l’ESB est alors principalement centralisé. On peut opter pour un mode plus décentralisé dans lequel les équipes projet ont des droits et des compétences pour définir des politiques, des sous-processus réutilisables, a minima les transformations…

Retour sur investissement

L’ESB n’est absolument pas nécessaire à une bonne SOA : il est un accélérateur potentiel mais dont on peut se passer techniquement et « méthodologiquement ». Il faut donc très tôt mettre en rapport ses produits potentiels avec ses charges certaines. Les gains ou les pertes d’un ESB sont principalement dépendantes de la capacité à le mutualiser pour un programme ou une société pour faire des gains d’échelle en qualité et en gouvernance sur le nombre de services à interconnecter et de processus à développer. L’idée directrice d’un ROI positif doit être « plus on a de services, plus on a de gains ». Les sections suivantes proposent des éléments pour estimer ce rapport.

Charges : le TOC

Le TCO significatif d’un ESB est le fait de plusieurs contraintes :

• Infrastructure : en tant que nœud central de la SOA, l’ESB constitue un point de panne unique qui impose son hébergement sur une infrastructure dédiée, performante et en très haute disponibilité.
• Framework : un ESB est livré vide. Il est du ressort d’une équipe ESB transverse de monter en compétence pour s’approprier le « langage » de l’ESB voire de définir un framework pour offrir des politiques de communication asynchrone, sécurisées, avec gestion de cache, de transformation…
• Licences : ses fonctionnalités allant de la simple médiation technique, l’orchestration de services métier jusqu’à des fonctions évoluées de corrélation d’événements, le coût d’une licence pour des produits commerciaux se chiffre en centaines de KE. A la licence socle s’ajoutent souvent des licences pour des fonctions ou connecteurs spécifiques.
• Support : les compétences de développement et d’administration d’un ESB sont spécifiques et donc plus couteuses qu’un simple développement Java ou de l’administration système.

L’infrastructure et le framework sont des investissements. Les licences et le support sont des coûts souvent récurrents à l’année.

Produits : le facteur accélerateur

Le facteur accélérateur de l’ESB se trouve dans son support au cycle de vie des services et processus, en particulier dans les phases de conception, développement, maintenance et dans la gouvernance en général. Pour le quantifier, nous proposons un facteur d’accélération pour chacun des 18 types de fonctionnalités répertoriés, estimé sur une échelle de 1 à 3,  un nombre de jours de réalisation sans ESB, pondérés par une importance, à fixer selon le contexte projet.

Variables du calcul

En complément des facteurs d’accélération et des jours de réalisation, il est pertinent d’estimer le pourcentage de services et de processus qui vont utiliser telles ou telles fonctionnalités de l’ESB. Les estimations de ces pourcentages proviennent idéalement d’une étude des besoins qui aboutit en synthèse aux nombres d’occurrence de telle ou telle fonctionnalité. Les variables majeures au retour sur investissement restent le cout de la licence socle et le nombre de services et processus.

Equilibre financier

Pour arriver à l’équilibre financier, 2 situations s’opposent aux extrêmes : un cout de licence faible et un nombre de services et processus faible vs. un cout de licence élevé et un nombre de services et processus élevé. Dans les 2 situations par contre, les gains en délai sont conséquents. Dès lors que l’on définit une gouvernance et qu’elle est supportée par un framework, des workflows et des développements autour de l’ESB, les gains d’échelle sont en théorie au rendez-vous.

Eléments pour le choix

Critères d’évaluation

La grille d’évaluation de la capacité d’un ESB à couvrir les 18 types de fonctionnalités que nous avons répertoriées se décline en 13 axes allant des aspects techniques (médiation, industrialisation…) jusqu’aux aspects commerciaux (support, licence…).  Chaque axe comporte entre 2 et 15 critères. Ces critères peuvent être pondérés selon une importance établie par une analyse des besoins. La notation d’un critère se fait sur une échelle discrète de 0 à 5 : 0 indique que la fonction n’est pas couverte, 5 qu’elle l’est selon « les attentes » de l’étude. La note globale se calcule selon les notations et pondérations associées à chaque critère. Le tableau ci-après liste propose 13 axes d’évaluation à utiliser pour classer les produits.

Axe

Description

Connectivité

Connecteurs techniques (CICS…) ou métier (SWIFT…)

Médiation

Routages, transformations, compositions

Orchestration

Exécution, simulation et optimisation de processus

Connexe

Couverture de fonctionnalités ETL, MDM, CEP

Sécurité

Sécurisation niveaux transport, message, applicatif, WS-*

Standards

Normes WSDL, WS-* BPxx, SCA respectées

Industrialisation

Intégration avec outils de conception, IDE, annuaires

Production

Montée de version, en charge, SLA, caping…

Interopérabilité

Intégration avec IAM, portails, le cloud

Gouvernance

Annuaire de services, gestion des dépendances

BAM

Suivi de bout en bout des processus et des services

Support

Qualité éditeur, produit, offre SOA

Commercial

Retour d’expérience, négociation, acquisition

 Stratégie d’intégration L’ESB n’étant pas a priori un outil dont en a impérieusement besoin, son intégration dans le SI peut s’opérer au fil du temps selon l’évolution des besoins. Nous proposons une stratégie d’intégration de type « montée en gamme » qui peut être mise en œuvre par une démarche en 5 étapes. Cette démarche short liste dès la 1^ere étape 2 ESB open source avec lesquels démarrer et 2 ESB commerciaux vers lesquels évoluer. La 2^ème étape mène un POC sur chacun des 2 ESB open source short listés sur un périmètre de fonctionnalités simples. La 3^ème étape sélectionne l’ESB open source avec lequel démarrer. La 4^ème étape n’est engagée que si un besoin déclencheur survient (médiation complexe, SLA, BAM, BPM, CEP) dans une phase amont au développement. Elle mène un POC sur chacun des 2 ESB commerciaux short listés sur le nouveau périmètre de fonctionnalités. Au final, la 5^ème étape sélectionne l’ESB sur lequel évoluer.

Les 5 étapes de la démarche de sélection de l’ESB initial et évolutif se détaillent ainsi :

• Short lister 4 produits : 2 Open Source (OS) et 2 commerciaux. Les produits à short lister sont retenus parmi les produits étudiés par le Gartner et / ou Forrester, complétée par des retours d’expériences sur d’autres produits si pertinents. La grille d’évaluation sert de guide de lecture des fonctionnalités à évaluer. Les éditeurs sont rencontrés par l’intermédiaire d’un intégrateur pour fournir les éléments d’évaluation. Pour les 2 OS, l’intégrateur seul réunit les éléments,
• Faire un POC pour les produits OS retenus : l’intégrateur et le client s’engagent dans un POC sur un périmètre de fonctionnalités représentatives extraites de la grille. Les POC estiment en plus du résultat, le temps nécessaire, la qualité de la documentation, le confort… des outils. Un jeu très réduit de services bouchonnés est imaginé et implémenté en prérequis des POC,
• Choisir le produit initial : le classement a priori de la grille d’évaluation, les retours d’expérience a posteriori des POC, la possibilité d’un support commercial et / ou interne au client sont combinés pour départager les 2 ESB OS et s’engager sur un ESB initial,
• Sur besoin déclencheur, faire un POC pour les 2 produits commerciaux retenus : l’intégrateur, le client et les éditeurs s’engagent dans un POC sur un périmètre de fonctionnalités complémentaires. Les POC estiment en plus du résultat, le temps nécessaire, la qualité de la documentation, le confort… des outils. Un jeu très complet de services réels est sélectionné et implémenté en prérequis des POC,

Choisir le produit évolutif : le classement a priori de la grille d’évaluation, les retours d’expérience a posteriori des POC, la possibilité d’une négociation et d’un support interne sont combinés pour départager les 2 ESB commerciaux et s’engager sur un ESB évolutif.

Filed under: Articles