Interview : La distinction ESB vs ETL n’a plus de sens face aux besoins métiers !

EAI : Outils ETL vs ESB

ETL, ESB, EAI, EDI, SOA, APIM… il existe de multiples acronymes liés à la gestion des flux de données et il est facile de s’y perdre. Certains acronymes ont des périmètres similaires, d’autres complémentaires, d’autres encore se recouvrent partiellement.

Dans cette interview, Edouard Cante, Directeur des Opérations de Blueway, nous partage sa vision et ses convictions sur la distinction ETL vs ESB, et ses conséquences pour les entreprises. Face aux besoins métiers, est-ce vraiment le bon débat ?

Dans un précédent article, nous avions conclu que l’ESB et la gestion des API étaient deux faces d’une même pièce. Est-ce la même chose pour l’ESB et l’ETL ?

Edouard Cante : Non, leurs périmètres se recouvrent en partie : ils se positionnent tous les deux sur le transport et la transformation de la donnée au sein du système d’information. Par nature, on pourrait considérer qu’il y a un choix à faire selon les types de flux. Ce n’était pas le cas entre ESB et APIM qui sont complémentaires.

Les différences historiques reposent surtout sur la dimension architecturelle. Pour des personnes qui ne sont pas expertes du data management, percevoir les spécificités de l’ETL et de l’ESB n’est pas aisée. A cela s’ajoute que les contours ont évolué ces dernières années.

De manière historique et un peu caricaturale, l’ETL va être performant pour gérer de très fortes volumétries avec des enjeux de performance, mais pour un nombre limité d’échanges. Il va traiter la donnée de manière ensembliste. Par exemple, si on souhaite obtenir la somme du chiffre d’affaires ventilé par client, l’ETL va agréger toutes les lignes, et appliquer un traitement sur la totalité. Cette approche ensembliste est en particulier adaptée pour la Business Intelligence et le Data Warehousing.

A l’opposé, l’ESB va être efficace pour traiter un nombre et une fréquence élevés d’échanges avec une volumétrie limitée de données associée à une dimension algorithmique des opérations. Il va avoir toute sa place pour décloisonner l’information et accompagner une Architectures Orientée Services en se positionnant comme un bus d’échange sécurisé et transversal à tout le SI.

 Si on résume à l’extrême, l’ETL, c’est l’outil pour construire son data Warehouse depuis son ERP et son CRM. L’ESB, c’est pour la personne qui souhaite exposer au travers de demi-interfaces les devis, commandes et clients depuis son CRM par exemple et permettre aux autres applications d’aller chercher ces informations en se connectant au bus applicatif de données.

Edouard CANTE

Cependant, ma conviction, c’est que ces différences historiques frôlent maintenant la caricature ! Qui peut dire aujourd’hui qu’il achète un outil ETL uniquement pour de la BI ?

Pourquoi cette conviction que cette distinction entre outils ESB et ETL n’est plus adaptée ?

E.C : Une autre différence souvent mise en avant est que l’ETL est une technologie Pull, à la demande, alors que l’ESB est une technologie push, à la production des messages. Mais, côté client, peut-on vraiment ne faire que du pull ou que du push ? Quand une entreprise a mis un place un ETL, et doit faire du push, cela ne peut pas reposer sur chaque application ! Cela demande des développements spécifiques et fait ressortir le problème au cœur de cette distinction.

Si ce cloisonnement entre ESB et ETL avait lieu d’être il y a 10 ans, ma conviction, c’est qu’il n’est plus d’actualité du point de vue métier. Des concepts différents ne doivent pas sous-entendre des solutions différentes ! Demander au DSI de choisir entre deux outils différents selon ce qu’il veut exposer ou faire interagir, c’est prendre le problème du mauvais côté. On ne contraint pas le besoin métier par les enjeux techniques !

Pour la majorité des entreprises, il n’y a aucun ROI à s’équiper d’un côté d’un pur ETL et de l’autre d’un pur ESB.

Edouard CANTE

ESB et API Management :
deux réponses complémentaires pour soutenir votre transformation business

Comment le marché a évolué depuis l’apparition de ces concepts d’ETL et d’ESB ?

E.C : A l’origine, il y avait de vraies différences technologiques. Les marchés se sont scindés et ont évolué. Certains éditeurs d’ETL ont marché sur les plates-bandes des éditeurs d’ESB et réciproquement pour gagner des parts de marché. En même temps, certains discours marketing ont cloisonné les besoins en fonction des technologies pour affirmer leur positionnement. Des éditeurs d’ESB ont aussi cherché à se définir comme puristes.

Le débat a été principalement mené sur le front de la technologie et non pas vis-à-vis des besoins finaux. C’est une erreur !

Edouard CANTE

En conséquence, les frontières sont devenues floues du point de vue client et cela a mené à des positions caricaturales. Les interlocuteurs ont généralement mal compris ce qu’était un ESB et son potentiel. On résumait parfois l’ESB au déplacement de données en négligeant son rôle pour organiser toute la circulation de l’information. Résultat : de nombreux projets ont échoué à cause de ces approches dogmatiques !

J’ai l’exemple d’un retailer où le projet a démarré par une cartographie théorique des flux avec de superbes schémas pour défendre une approche 100% ESB. Finalement, quand le projet a été lancé, cette position extrême s’est heurtée à la réalité : certaines applications ne pouvaient pas faire du temps réel. Le projet a été un échec complet.

Si opposer ETL et ESB est une erreur, quel est le vrai enjeu ?

E.C : Le vrai enjeu, c’est d’inverser le point de vue. C’est à cause de ces questions marketing « ESB ou ETL » qu’on arrive à ces échecs ! Cette dichotomie n’a plus de sens dans la majorité des cas.

Le DSI se retrouve à devoir choisir entre deux outils alors que son besoin a lui est commun : dans la majorité des cas, il souhaite décloisonner et faire circuler l’information entre les applications de son SI, réaliser un peu de BI, et centraliser les informations dans un MDM. Faire correspondre chaque concept à une solution différente, l’oblige à séparer son besoin métier sans que cela ait de bénéfice pour lui.

Il faut faire le pont entre les deux. La solution doit répondre au besoin métier, et non à un dogme technologique !

Edouard CANTE

Ce défi se retrouve même au sein des utilisateurs qui ont une compétence sur des outils plus que sur les concepts. Les utilisateurs prennent alors moins de recul sur la gestion des flux en tant quel tel. C’est en comprenant les concepts que les utilisateurs pourront monter en compétences, et adopter plus facilement des outils différents.

L’interopérabilité entre processus et données : le cœur d’une entreprise agile

Si la question n’est pas ETL ou ESB, quelles sont les questions à se poser pour mener à bien son projet d’urbanisation ?

E.C : Il faut déjà commencer par accepter et prendre en compte la réalité ! S’il est important de cartographier ses processus et de prendre du recul, il ne faut pas se contenter d’une vision théorique : « tout sera SOA » « tout communiquera via des API ». La vision du futur, c‘est bien, mais dans la réalité, il faut que les applications puissent communiquer dès maintenant !

C’est aux outils de converger pour s’adapter au métier et non l’inverse : l’objectif est d’unifier la collaboration dans l’organisation.

La guerre ETL ESB n’a plus de sens ! Pour répondre aux besoins des DSI, ils ne doivent plus être dissociés. La distinction porte maintenant sur la transformation et le transport des données d’un côté, et de l’autre sur son exploitation.

Edouard CANTE

Si une différence doit exister, je la positionnerai à un autre niveau. On peut différencier les solutions de data transformation qui assurent une circulation sécurisée et mettent à disposition les données pour des outils de data préparation très fonctionnels, dédiés aux métiers : data scientist, BI…

Les métiers ont ainsi accès à des outils très fonctionnels, qui leur sont dédiés, et le Data Manager conserve son rôle central pour garantir la qualité, la transformation et la mise à disposition des données. Ce sont ces outils de data preparation qui font évoluer le marché ! L’autonomie des métiers prend tout son sens, sans pour autant que cela implique qu’ils agissent sur la circulation de l’information. Celle-ci doit en effet répondre à des enjeux critiques de performance et de légalité.

La circulation des informations doit donc être appréhendée dans sa globalité, quel que soit le « mode de transport » pour répondre aux enjeux métier. La vraie différence au niveau des outils repose maintenant entre la data transformation et la data préparation !

Edouard CANTE

Je suis donc convaincu qu’il faut à la fois répondre aux standards actuels, mais aussi respecter la fameuse Legacy du Système d’Information. Les clients qui utilisent les solutions ETL/ESB/EAI doivent faire avec cet actif, ils n’ont pas le choix ! En tant qu’éditeur, c’est donc aussi notre rôle. Nous devons être la boîte à outils qui permette aux clients de faire circuler l’information.

Chez Blueway, nous n’avons jamais cultivé la différence ESB vs ETL. Notre souhait et de pouvoir répondre globalement à l’enjeu d’urbanisation du SI avec une plateforme modulaire qui réunifie les concepts autour des enjeux métiers et humains. Il existe des cas extrêmes où un super outil ETL serait nécessaire, mais on le rencontre très peu dans la réalité !

Vous souhaitez échanger directement avec Edouard Cante ? Prenez rendez-vous dès maintenant !

Echangeons !