Depuis plus de trente ans, les applications se déposent comme autant de strates pour constituer le système d’information des entreprises. Aujourd’hui, le mythe de l’ERP (Enterprise resource planning) généralisé, capable de prendre en charge la totalité des besoins d’automatisation de la gestion de l’entreprise, est révolu. Dans nombre de centres de production, les bons vieux mainframes continuent à héberger les vieilles applications toujours en activité.
Les applications doivent communiquer entre elles, surtout au niveau du contenu
De leur côté, les systèmes ouverts ont proliféré, pour prendre en compte de nouveaux besoins : GED (gestion électronique des documents) et workflow, messagerie et groupware, gestion de la logistique, commerce électronique et gestion de la relation clients.
Il fut un temps, pas si lointain, où la mise en place d’une nouvelle application justifiait celle d’un nouveau serveur. Aujourd’hui, les constructeurs lancent des programmes de consolidation dont l’objectif est de regrouper les applications réparties sur un seul et même système de haut de gamme. Le résultat de ces différentes évolutions est un enchevêtrement de systèmes et d’applications qui doivent absolument communiquer entre eux. A quoi servirait, par exemple, une application de commerce électronique si l’entreprise ne disposait pas d’une gestion de la logistique capable de livrer le client dans les meilleurs délais ? Une liaison étroite entre les deux est évidemment indispensable. Le middleware est souvent comparé à la ” colle ” permettant à tous les éléments du puzzle constituant le système d’information de communiquer. ” Les plates-formes Java, et leurs corollaires ?” EJB, Corba ou DCOM ?”, ont été présentées comme une option miracle étant susceptible de résoudre, à elle seule, les problèmes d’intégration d’entreprise, estime Claude Campanaro, responsable senior e-solutions d’Osis, cabinet de conseil et intégrateur. Elles ont au moins donné la possibilité d’homogénéiser les plates-formes de développement et de faciliter ainsi les communications interapplicatives, mais à bas niveau. La problématique se situe ailleurs. Il ne suffit pas de parler la même langue pour traiter des mêmes sujets. “
Toutes ces applications doivent communiquer entre elles au niveau informationnel, c’est-à-dire au niveau du contenu. Longtemps, ce problème a été résolu par des développements spécifiques, le plus souvent des interfaces point à point. Le transport des données était alors assuré par des mécanismes de transfert de fichier. Mais la complexité du problème augmente de manière exponentielle avec le nombre d’applications à interconnecter. C’est ce que le GartnerGroup appelle le ” système spaghetti “. Un nouveau segment du middleware est alors apparu, recevant l’appellation d’EAI (Enterprise application integration), ou logiciel d’intégration des applications d’entreprise, ou encore, comme l’a baptisé le cabinet IDC, BusinessWare. Savoir jusqu’à quel point l’EAI appartient à la catégorie des produits de middleware est une discussion de puristes, comparable à celle visant à déterminer si le navigateur Web fait partie ou pas du système d’exploitation. Selon le cabinet Ovum, qui a publié récemment une étude sur le middleware, ” l’EAI n’est pas du middleware, ni du workflow, ni de la transformation de données, c’est une combinaison des trois : services de connectivité du premier, gestion des processus du deuxième et transformation des données issues des produits ETL (Extract, transform, loading) du troisième “. Affirmation reprise par Osis : ” L’EAI est la mise en ?”uvre coordonnée des technologies middleware, ETL, workflow et XML (Extensible markup language), afin d’intégrer et d’harmoniser des systèmes d’information hétérogènes. “
Le transport, fonction de base, s’appuie sur les MOM
Claude Campanaro, d’Osis, quant à lui, déclare : ” Les problèmes d’intégration se répartissent en deux grandes catégories. Il s’agit, d’une part, d’assurer la conversion sémantique des données tout en maintenant leur intégrité et en gérant le référentiel, et, d’autre part, de réaliser le contrôle des flux entre les traitements. “
Pour ce qui est des données, les méthodes d’échange consistent en des transferts de fichiers FTP, CFT (Cross file transfer) et Inter.Perl., mais également en une extraction telle qu’elle est pratiquée dans l’informatique décisionnelle pour acheminer des données à partir des systèmes de production ou des bases de données intermédiaires vers un datawarehouse. Les mécanismes de réplication de bases de données entrent aussi dans cette catégorie. Ces outils n’apportent toutefois qu’une réponse incomplète, car ” les seuls outils capables de fournir à la fois les fonctions de référentiel de métadonnées et de règles métiers sont les Message brokers, estime Pierre Pezzardi, directeur technique d’Octo Technology, un cabinet d’architecture en système d’intégration. Les ORB, longtemps positionnés comme solutions d’interopérabilité, ne permettent pas de répondre correctement à cette problématique. Ils exploitent un mode de communication synchrone et ne proposent aucun service au-delà du transport tel que le routage, les transformations et les connecteurs. C’est contraignant et assez peu réaliste “. Le transport est la fonction de base de l’EAI. Elle est, le plus souvent, assurée par des produits de type MOM. IBM fut l’un des pionniers de ce type de middleware en proposant MQSeries, en 1993, le produit leader du marché disponible aujourd’hui sur une quinzaine de plates-formes avec plus de cinq mille références. Les MOM gèrent des files d’attente afin d’éviter que les messages ne soient perdus lorsqu’un applicatif n’est pas disponible pour recevoir les données. Le MOM est une couche logicielle non bloquante : l’application qui lui transmet un flux d’information ne doit pas attendre que l’application destinataire l’ait reçu, quel que soit le type de message envoyé. En revanche, avec les RPC, une communication qui fonctionne en mode requête-réponse bloquera l’émetteur tant que le destinataire n’aura pas répondu.
XML va favoriser les échanges interapplicatifs
A mi-chemin, on trouve le CPI-C (Common programming interface-Communications), un standard de communication entre processus proposé par IBM pour les traitements coopératifs. Le mode de communication est conversationnel et fonctionne par séquences de requête et de réponse. Le destinataire doit être disponible, mais l’appel est non bloquant.
Au-delà du transport, un second niveau traduit les messages dans des formats compréhensibles par les applications qui vont les recevoir. Le transfert d’une commande est, à cet égard, un cas très simple. Celle-ci doit être éclatée et routée vers différentes applications (facturation, comptabilité, et logistique), et, dans le cas de fabrication à la demande, vers la gestion de production. Les applications de commerce électronique favoriseront ce mode de fabrication, où la demande précède l’offre. Ces quatre applications n’ont pas besoin des mêmes données. La fonction de transformation récupérera les données nécessaires à chacune d’entre elles et les adaptera aux divers formats correspondants. C’est ce que font les outils d’EDI (Electronic data interchange, échange électronique de données) depuis longtemps, mais avec un succès limité, compte tenu de leur lourdeur. Le standard XML se révèle alors indéniablement une technologie très prometteuse et largement soutenue par l’industrie. Comparé à HTML, ce langage présente l’avantage d’autoriser l’envoi des informations accompagnées des éléments permettant de les comprendre. Les balises utilisées par XML décortiquent l’information en différents éléments compréhensibles par les applications.
Standardiser les procédures et gérer l’organisation des flux
Au contraire de HTML, XML ne s’embarrasse pas de balises concernant la présentation du document. Microsoft a décidé de lancer une initiative, dénommée BizTalk, pour que les applications communiquent en XML. Un consortium, qui regroupe des constructeurs informatiques, des éditeurs de logiciels et des grandes entreprises, a été constitué pour en assurer le développement. Parmi eux figurent Baan, Boeing, BP Amoco, PeopleSoft, Procter & Gamble, SAP et UPS. Les premières spécifications ont été dévoilées en juin 1999 et sont disponibles sur le site du consortium (www.biztalk.com). BizTalk est issu de la plate-forme Commerce Server, de Microsoft.
Les spécifications définissent la structure des messages au format XML, les règles de transformation, à la fois syntaxiques (grammaire) et sémantiques (contenu), ainsi que les règles de routage et de workflow pouvant être appliquées à un message. Bien sûr, eu égard à son promoteur, BizTalk s’appuie sur l’environnement Windows 2000, sur le serveur d’applications MTS, sur le serveur Web Internet Information Server ainsi que sur le middleware à messages MSMG. Les procédures de transformation peuvent être systématisées lorsque les applications en émission et en réception sont des progiciels standards. C’est le cas de progiciels horizontaux largement employés tels que les ERP comme Baan, PeopleSoft, SAP R/3, ou des applications sectorielles. Ainsi, le secteur de la finance recourt à des formats d’échange standardisés depuis longtemps : Swift, Fix ou Euroclear. Edifact est également assez largement utilisé dans l’industrie. Il s’agit de ce que l’on appelle les connecteurs.
Un marché et des acteurs qui évoluent au gré des besoins
Afin d’assurer la nécessaire intégration au système d’information existant, une solution d’EAI devra offrir des passerelles vers des éléments aussi variés que des SGBD, des moniteurs transactionnels, des serveurs d’applications, ou encore, d’autres middlewares. Il lui faudra aussi s’interfacer avec les fonctions de transfert de fichier, qui représentent, encore aujourd’hui, la majorité des flux d’information. ” Un outil d’EAI doit intégrer ces mécanismes, mais aussi être capable de passer du fichier au message. Un fichier doit pouvoir être décomposé en plusieurs messages ou l’inverse, explique Pierre Pezzardi, d’Octo Technology. Des produits comme Bus Applicatif, de Sopra ; Mercator, de TSI ; ou Gate, de STC, permettent une traduction aisée des transferts en mode fichier vers des messages et inversement. Le Message broker est un outil de gestion du changement. “
Enfin, la dernière composante importante de l’EAI est le workflow, qui sert à organiser les traitements. Cette notion est bien connue dans le domaine de la GED, où elle gère le cheminement des documents selon des circuits administratifs en les envoyant aux personnes ad hoc. Un moteur de workflow peut remplir les mêmes fonctions au niveau d’un outil d’EAI. ” Toutefois, commente Pierre Pezzardi, le moteur de workflow devra s’appuyer réellement sur le Message broker, et non directement sur le MOM car, dans ce cas, on perdrait la modélisation de haut niveau, et le moteur de workflow ne verrait que les files d’attente et des objets sans comprendre leur contenu. “
Les éditeurs d’outils d’EAI sont issus d’horizons différents. Les plus anciens viennent du monde du développement. C’est le cas de Forté ou de Template. Les poids lourds comme IBM et Microsoft sont présents dès que de nouveaux espaces stratégiques doivent être couverts. D’autres sont apparus avec ce marché comme Neon (New Era Of Network), CrossWorlds, Tibco et TSI. Neon a été fondé par deux grands noms de la finance (Goldmann Sachs et Merryl Lynch), qui devaient résoudre des problèmes concrets. Ils ont été ensuite amenés à transformer ces développements en produits. Venant également du monde de la finance et créé en 1985, Tibco a, au début, développé des middlewares spécialisés dans les produits pour salles de marché. Son outil TIB/ActiveEnterprise couvre quatre grandes fonctions : messagerie, transformation, routage et notification. De par son appartenance au groupe Reuters, Tibco utilise ses propres technologies pour sa seconde activité, qui consiste à distribuer de l’information. On trouve, enfin, de grands spécialistes du middleware, tel BEA Systems, qui n’a pas hésité à compléter son offre avec des technologies mises au point par d’autres sociétés, en l’occurrence celles de Neon. IBM a également intégré les produits de Neon à MQSeries.
Toutes les entreprises ne sont pas prêtes pour l’EAI
Mais le tableau serait incomplet si l’on ne mentionnait pas la SSII française Sopra, qui fut l’un des pionniers de l’EAI, avec son produit Règle du Jeu. La société a consolidé son offre grâce aux rachats successifs des sociétés Credintrans, Pelican et Technologies Application. ” Aujourd’hui, les produits d’EAI se classent en deux grandes catégories, conclut Claude Campanaro, d’Osis. Les premiers sont orientés données. Il s’agit, en particulier, des outils dérivés des ETL. Les seconds sont orientés processus. La voie d’avenir est aux outils qui sauront concilier ces deux problématiques d’intégration. Certains éditeurs, tels Constellar, Neon ou TSI Software, sont déjà bien placés. “
Le choix d’une nouvelle technologie peut se justifier par les améliorations qu’elle apporte au fonctionnement du système d’information. Comparer la mise en ?”uvre d’un outil d’EAI au développement d’applications spécifiques est, à cet égard, intéressant. Selon le GartnerGroup, le retour sur investissement d’un projet déployé avec un outil d’EAI, par rapport à un développement sans Message broker, serait supérieur à 100 %, dès la première année. L’avantage va en s’accentuant au fil des ans, car l’emploi de solutions standards réduit beaucoup le coût de la maintenance.
Mais les produits d’EAI restent coûteux (plus de 500 000 F ht). Le cabinet Hurwitz propose un test pour aider les entreprises à évaluer le retour sur investissement selon leur profil. Réalisé par David Kelly, analyste dans ce cabinet, ce test couvre, en une vingtaine de questions, les aspects d’adaptabilité de l’architecture technique et applicative, ainsi que les processus et la capacité de capitaliser les ressources existantes (humaines, applicatives et techniques). Trois catégories d’entreprises se dégagent alors : celles qui pourront facilement intégrer un produit d’EAI ; celles qui devront combiner des middlewares avec des solutions d’EAI ; et celles pour qui la mise en place d’une solution d’EAI n’est pas adaptée. Ce peut être le cas quand les besoins de communication sont limités ou, au contraire, quand ils sont si complexes qu’ils imposent des développements spécifiques.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
