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