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é .

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.