EAI versus ETL : que choisir ?

Un livre blanc signé Acta s'essaie à la comparaison entre

les formes courantes d'intégration des données applicatives. Evidemment orientée,
l'analyse produite prêche pour l'offre de de l'éditeur, mais permet de mieux saisir les
recoupements entre des notions parfois complexes. (Jeudi 14 mars 2002)

Intégrer des applications les unes avec les autres revient à rendre possible un dialogue entre
elles, alors qu'au départ aucune ne parle le même langage. Partant de là, plusieurs options de
médiation, ou middleware, s'offrent à l'entreprise qui souhaite se lancer dans un tel chantier.
Parmi celles-ci : l'ETL (extraction transformation loading), l'EAI (enterprise application
integration), et dans le prolongement de ce dernier, l'intégration des processus b-to-b avec les
partenaires, clients et fournisseurs de l'entreprise. Or, il s'agit bel et bien de trois étages
complémentaires : les données, puis les transactions en interne, et enfin avec l'extérieur.

Prêchant pour sa propre paroisse, le dernier livre blanc d'Acta, intitulé "Data Integration" se
livre au difficile exercice de mettre en concurrence les différentes méthodes existantes
d'intégration des données, tout du moins au niveau des deux premières catégories.
Traditionnellement issu du monde ETL, l'éditeur montre que de génération en génération,
ces outils - en particulier les siens - ont évolué jusqu'à concurrencer l'EAI sur son propre
terrain, le A-to-A (application to application). Pour cela, un certain nombre de conditions
doivent être réunies selon Acta, comme la faculté d'interopérer en temps réel et de façon bi-
directionnelle.

L'EAI n'est pas l'ETL, et vice-versa

Temps réel : le mot est lancé. D'un point de vue historique, les progiciels d'ETL collent en
effet davantage à l'image du différé, notamment du fait qu'ils brassent d'importantes quantités
de données. Or, provoquer des allers-retours volumineux et incessants entre applications et/ou
bases de données aurait comme effet de saturer des ressources vitales pour l'entreprise,
comme la bande passante des réseaux. C'est pourquoi la fonction de gestion de la production
de la DSI se charge généralement de paramétrer son ETL afin qu'il effectue ses opérations de
nuit, ou en tout cas pendant les heures creuses.

En parallèle, le middleware EAI a pour fonction de passer des messages d'une application à
l'autre, contenant de petites quantités de données. En l'occurrence, juste ce qu'il faut pour que
le système puisse assurer sa fonction dans son ensemble. Dans ce cadre, le temps réel, ou
quasi-temps réel est une caractéristique de base. D'autre part, si une application n'est plus
disponible, les messages sont stockés dans une file d'attente le temps que celle-ci se libère.
C'est le "message queuing" généralement pris en charge par des technologies de type
MQSeries (IBM), JMS (Java message service) ou MSMQ (Microsoft).

Mais la comparaison ne s'arrête pas là. Alors qu'un EAI s'appuie sur un référentiel de règles
métier, un ETL s'attache à faire correspondre des schémas de données non compatibles, en
fonction des métadonnées ou descriptions de champs fournies par les applications. Au
"comment mes applications peuvent-elles communiquer entre elles ?", s'oppose le "comment
harmoniser les échanges de données entre ces applications ?". Du côté ETL, ce dernier point
suppose l'extraction des données de l'application A, leur transformation en cours de route, et
leur chargement dans l'application B. Concernant l'EAI, les messages suivent sans
modifications un chemin défini d'une application à l'autre suivant le même principe qu'un
workflow, d'où l'importance d'une extraction approfondie des règles métiers au niveau de la
couche applicative.
Cinq générations d'outils ETL
Sommairement esquissée, cette trame de différences ne permet pas, au premier abord, de
comprendre comment un progiciel ETL pourrait se subtiliser à un EAI. C'est pourquoi le livre
blanc d'Acta décrit plus précisément les cinq générations d'outils ETL qui se sont succédées
dans le temps.

Génération 1 : au départ, à l'époque des mainframes en tant que coeurs des systèmes
d'informations, les outils ETL généraient du code Cobol à partir des données extraites.
Coûteuses, ces solutions étaient de plus encombrantes et nécessitaient parfois une intervention
humaine lors de l'extraction.

Génération 2 : puis, avec l'avènement du client/serveur dans le cadre d'applications

propriétaires et sur-mesure, le langage de requêtes SQL a remplacé le Cobol comme format de
destination. Mais ces outils ont rencontré leurs limites avec l'avènement d'applications
packagées comme les progiciels de gestion, tels SAP, Peoplesoft ou Oracle côté ERP, ou
même Siebel côté CRM. Pour coller du mieux possible au modèle des données stockées dans
la base relationnelle, il fallait aussi extraire la logique métier au niveau de la couche
applicative.

Génération 3 : comme chacune des applications citées gère différemment cette logique
métier par dessus des modèles de données spécifiques, les outils ETL ont du être livrés avec
des adaptateurs spécifiques. Leur rôle : fournir une intégration plus étroite avec ces
applications. Déjà apparues au cours de la deuxième génération, les interfaces permettant de
modéliser graphiquement les échanges et les changements sous-jacents se sont imposés, tout
comme la console d'administration centralisée. Il fallait alors tenir compte de la nouvelle
complexité engendrée par la transition vers les systèmes d'informations hétérogènes, tout en
accueillant les technologies web dans l'entreprise. Acta qualifie cette troisième génération
d'ETL+.

Génération 4 : avec la nécessité d'être plus réactif dans un environnement concurrentiel très
dynamique, les processus de décision se raccourcissent dans le temps. C'est pourquoi ces
outils ETL sont désormais capables de gérer simultanément des flux de données en temps réel
et en différé. Pour introduire cette dose de temps réel, une série de composants veille en
attendant l'arrivée des requêtes pour les traiter. Dans le même temps, l'ETL se dote d'un
distributeur de messages, et empiète déjà un peu sur l'EAI. Dans ce cadre, XML joue aussi un
rôle clef grâce notamment au recours à sa technologie soeur XSLT qui permet d'effectuer les
transformations à la volée. A noter : lorsqu'elles n'en sont pas resté à la troisième génération,
la plupart des entreprises n'ont pas encore, à l'heure qu'il est, dépassé la quatrième.

Génération 5 : les précédentes générations d'outils se destinaient essentiellement à une

exploitation des données dans un cadre décisionnel avec un entrepôt de données centralisé,
localisé (datamart) ou généraliste (datawarehouse). La cinquième, de son côté, présente une
vocation plus large. Les adaptateurs, API (Application programming interface) ou autres, sont
bi-directionnels : ils sont capables à la fois de lire et d'écrire tout autant dans l'application A
que B. Et le "message broker" avec des fonctions de file d'attente est désormais devenu
indispensable. Les données exploitées à des fins décisionnelles analytiques restent mises à
jour en différé, du fait de leur volume important. Mais celles à caractère opérationnel, dont les
applications ont besoin pour rendre compte de la situation présente de l'activité, sont injectées
en temps réel ou quasi-temps réel dans l'application de destination.
L'ETL n'est toujours pas l'EAI
Dans une grande entreprise, il va de soi qu'en présence de milliers de systèmes hétérogènes,
d'anciennetés variées, les cinq générations d'outils ETL se côtoient. Et, comme l'on pouvait s'y
attendre, l'éditeur Acta déclare les recouvrir toutes les cinq avec son offre. En attendant, à la
cinquième génération, peut-on encore parler de clivage entre l'EAI et l'ETL ? Comme les
données sont toujours nettoyées, consolidées et transformées en cours de route, il s'agit bien
d'ETL. Mais comme les API et le message broker font désormais partie de la panoplie, l'EAI
n'est plus très loin.

Dans tous les cas, ne nous méprenons pas : ce sont des données qui sont échangées. Et ce,
qu'elles transitent par une base centralisée, qu'elles soient contenues dans des messages
applicatifs, ou adoptent une forme plus évoluée. Il n'empêche que si ce domaine est celui de
l'ETL, ce n'est pas seulement celui de l'EAI. Et si les discours marketing des éditeurs portent
souvent à confusion sur des offres qui feraient tout (même la vaisselle ?), Acta lui-même
rappelle une notion fondamentale. L'EAI rentre dans la couche transactionnelle. Au delà du
fait d'échanger des données nécessaires à la transaction, mais pas dans des volumes prohibant
le temps réel, il permet à une application de commander l'éxécution d'une tâche à une autre
selon le processus métier défini dans le référentiel de règles. Et cela, l'ETL ne le fait pas.

http://www.journaldunet.com/solutions/0203/020314_eai_vs_etl.shtml