EAI De l intégration à l e-business François Rivard consultant senior Tél : +33 1 53 24 67 80 frivard@cosmosbay.com Novembre 2000 Jean-Christophe Bernadac directeur technique Tél : +33 4 72 65 21 00 jcbernadac@cosmosbay.com François Knab vice-président Tél : +33 1 53 24 67 80 fknab@cosmosbay.com Avec le concours de François Bourcier
EAI De l intégration à l e-business
EAI De l intégration à l e-business / Table des matières Table des matières 1 Table des matières... 4 VUE D ENSEMBLE : LE SYSTÈME D INFORMATION E-BUSINESS 7 Fédérer, unifier, s adapter... 8 Mettre en œuvre un système intégré... 9 Recréer un système d information intégré... 9 Généraliser les passerelles interapplicatives... 9 Fédérer les systèmes... 10 Domaines d application... 11 Gestion de la chaîne logistique... 11 Gestion de la relation client... 11 e-marketplaces... 12 2 De l intégration à l e-business... 13 LE MODÈLE EAI 16 Transport : un middleware pour les données... 16 Définition... 16 Fonctionnalités et technologies... 16 Couche plate-forme et EAI... 19 4 Données : les adaptateurs applicatifs... 19 Définition... 19 Fonctionnalités et technologies... 20 Couche données et EAI... 20 Composants : appliquer la logique d entreprise... 21 Moteur d intégration : le cœur du système d e-business... 23 Définition... 23 Fonctionnalités... 23 Technologies : les message brokers... 24 Couche moteur d intégration et EAI... 26 3 DE L EAI À L INTÉGRATION ÉTENDUE 27 Processus : modélisation métier... 27 Définition... 27 Fonctionnalités et technologies... 28 Couche processus et eai... 29 B2B : eai ou l intégration étendue... 29 Définition... 29 Fonctionnalités et technologies... 30 Couche B2B et eai... 31 4 XML ET L EAI 33 XML et les six couches du modèle eai... 33 XML et transport... 33 XML et connecteurs... 34 XML et composants... 34 XML et moteur d intégration : les serveurs d applications... 34 XML, composants métier et workflow... 36 XML et B2B... 37 XML, langage privilégié de l échange B2B... 37 cxml, d Ariba Software... 38 xcbl, de Commerce One... 38 OBI, de CommerceNet... 38 eco, de CommerceNet... 39 ebxml, de l UN/Cefact et Oasis... 39 BizTalk, de Microsoft... 41 RosettaNet... 42 Autres initiatives... 43 En résumé... 43 Une architecture alternative d EAI bâtie sur XML... 43 Applications front-office... 44
Table des matières Sources de données... 45 Moteur d intégration... 46 Référentiel de synchronisation... 46 5 MARCHÉ DE L EAI ET OFFRES DES ÉDITEURS 48 Panorama du marché de l EAI... 48 Quelques chiffres... 48 Tendances... 48 Les offres... 49 Organisation des fiches produits... 49 Candle... 51 Présentation de la société... 51 Architecture technique du produit... 51 Le modèle EAI de Candle... 52 Synthèse... 54 Constellar... 55 Présentation de la société... 55 Présentation du produit... 55 Le modèle EAI de Constellar... 56 Synthèse... 58 Level 8... 59 Présentation de la société... 59 Architecture technique du produit... 59 Le modèle EAI de Level 8... 60 Synthèse... 62 5 Mercator Software... 63 Présentation de la société... 63 Présentation du produit... 63 Le modèle EAI de Mercator... 64 Synthèse... 66 Neon (New Era of Networks)... 67 Présentation de la société... 67 Architecture technique du produit... 67 Le modèle EAI de Neon... 68 Synthèse... 70 STC (Software Technology Corporation)... 71 Présentation de la société... 71 Architecture technique du produit... 71 Le modèle EAI de STC e*gate 4... 72 Synthèse... 75 Tibco Software... 76 Présentation de la société... 76 Architecture technique du produit... 76 Le modèle EAI de Tibco... 77 Synthèse... 79 Viewlocity... 80 Présentation de la société... 80 Architecture technique du produit... 80 Le modèle EAI de Viewlocity... 81 Synthèse... 82 Vignette-OnDisplay... 83 Présentation de la société... 83 Architecture technique du produit... 83 Le modèle EAI de Vignette-OnDisplay... 84 Synthèse... 85 webmethods... 86 Présentation... 86 Le modèle EAI de webmethods... 87 Synthèse... 89 6 CONCLUSION 90
6
Vue d ensemble CHAPITRE 1 Vue d ensemble Le système d information e-business Dans l entreprise, les développements ont longtemps été pensés et budgétés à un niveau départemental. Cette situation correspondait au succès des technologies client-serveur et au besoin de constituer des applications légères s appuyant sur leur propre base de données et sachant exploiter le confort procuré par un réseau local. Les réponses apportées aux besoins de l entreprise en matière de système d information et de traitement des données étaient en partie guidées par les possibilités technologiques disponibles au moment de la conception de ces systèmes départementaux. Depuis quelques années déjà, Internet met ce modèle en cause. Plusieurs facteurs récents définissent de nouveaux enjeux et élargissent le périmètre du besoin : La mondialisation de l économie Les changements incessants de la nature des marchés, des pratiques commerciales, des législations nécessitent une réactivité accrue de la part de l entreprise à tous les niveaux de son organisation. La réduction du time-to-market et l avantage concurrentiel procuré par le fait d être le first-to-market Devant la banalisation des produits et l érosion de la fidélité des clients, la stratégie Internet d une entreprise devient un facteur non négligeable de sa réussite commerciale et doit être focalisée sur la fidélisation de sa clientèle et sur la différenciation de sa marque. La croissance externe et les stratégies de partenariat Elle sont précédées d études désormais stratégiques sur la flexibilité du système d information des entreprises concernées. Lorsque deux systèmes d information fusionnent, il est indispensable de maintenir un existant opérationnel tout en amorçant la transition vers une consolidation des données. Les acteurs disposent ainsi d informations fédérées d aide à la décision assurant la cohérence d une stratégie partenariale et accompagnant la démarche commerciale et opérationnelle. Ces nouveaux enjeux convergent tous vers la généralisation des besoins d intégration. Qu il s agisse de la production (ERP, Enterprise Resource Planning), de la logistique (SCM, Supply Chain Management) ou de la relation client (CRM, Customer Relationship Management), la chaîne de valeur d une entreprise se conçoit dans sa globalité et non plus au niveau départemental. L ensemble des données d une entreprise (clients, fournisseurs, produits, utilisateurs, etc.) doivent pouvoir évoluer en offrant la garantie de leur cohérence. Cet objectif conduit naturellement à la mise en œuvre de référentiels d entreprise : l émergence des métaannuaires l illustre parfaitement. Pour autant, il n est pas concevable de se lancer dans une refonte globale du système d information. D une part, l expérience a prouvé que bon nombre de projets aussi volumineux présentaient un risque d échec important s ils n étaient pas découpés en sousprojets de taille plus raisonnable, chacun d eux étant mis en œuvre progressivement. D autre part, la réduction du cycle de vie des projets, liée au modèle économique d Internet, et le besoin de mettre rapidement en application une politique d e-business nécessitent de s appuyer sur tout ou partie du système d information existant. Cette exploitation des données et des applications de l entreprise doit s affranchir des rigidités inhérentes aux spécificités de ces systèmes et à leur hétérogénéité. Le système résultant doit être en mesure de réagir efficacement au changement, qui est le nouveau défi permanent lancé à l entreprise. Toute modification du contexte économique et concurrentiel doit être absorbée sereinement par le système d information de l entreprise. Les travaux d adaptation et d évolution ne doivent entraîner aucune instabilité, même temporaire, car le facteur Internet impose la disponibilité permanente des systèmes de commerce électronique. 7
EAI De l intégration à l e-business / Vue d ensemble Ayant été conçu sans une vision d ensemble des besoins de l entreprise, un système départemental ne peut pas servir de fondement à un projet d e-business : le système d information doit désormais être pensé à l échelle de l entreprise, afin d atteindre une logique d unification et de communication globale. Bien sûr, tout au long de cette démarche, il faut accorder un soin particulier à la flexibilité et à l interopérabilité des éléments d infrastructure qui constitueront le système fédéré. Les principales technologies mises en œuvre dans les projets d intégration répondent à ces exigences et s appuient aujourd hui, pour étendre l intégration aux partenaires de l entreprise, sur l apport des technologies d Internet, notamment de leur champion : XML (extensible Markup Language). 8 Fédérer, unifier, s adapter Les mots-clés régissant l infrastructure d un système intégré sont fédération, unification et adaptation. La fédération est la démarche qui privilégie la réutilisation des sources de données et des règles métier existant dans l entreprise. L unification est la mise en place de processus métier d entreprise coordonnant les sources de données et les applications entre elles. L adaptation est la capacité du système à prendre en compte de nouveaux processus métier ou de nouvelles applications et à modifier les processus et les applications existants. Un système conçu dans cet esprit peut être qualifié de système d e-business. Examinons à l aide d un exemple les bénéfices de cette démarche d intégration. L entreprise Brique et Mortier étend son activité au Web dans le but d y vendre ses produits. Après chaque commande effectuée en ligne par un internaute, les opérateurs du site reçoivent l information par e-mail et éditent un bon de commande papier. Ce bon de commande est transmis par courrier interne au responsable logistique, qui vérifie l état des stocks au moyen de l interface de son progiciel de gestion intégré (ERP). Constatant l indisponibilité du produit, il décide de s adresser à son fournisseur par le biais du logiciel d approvisionnement spécifique qu il utilise depuis plusieurs années. Le fournisseur transmet la date de réception du produit aux opérateurs du site web, qui se chargent d en informer le client en répondant à son e-mail de commande après y avoir ajouté le délai de livraison. Dans cet exemple, les intermédiaires et les sources de données se multiplient, et donc les incohérences et les sources d erreur aussi. Par exemple, les désignations des produits sont en théorie identiques dans l ERP et dans le logiciel d approvisionnement spécifique, mais dans la pratique un contrôle humain est indispensable pour garantir la cohérence. Dans ce contexte, il est difficile de tenir les engagements pris auprès des clients sur les délais de livraison. Ce scénario illustre les limites d une approche départementale cloisonnée ; il montre que l entreprise doit s interroger sur les moyens à mobiliser pour prolonger efficacement son activité sur le Web. Pour Brique et Mortier, les enjeux sont l amélioration de la coordination entre ses différents départements et l optimisation de la relation avec ses fournisseurs. Cela implique une communication «dématérialisée» entre les applications engagées dans le processus de vente en ligne. Une démarche d intégration du système d information est indispensable pour doter Brique et Mortier d une infrastructure informatique capable d accompagner sa stratégie e-business. Envisageons maintenant un système dans lequel les applications sont interconnectées. L arrivée d une commande en provenance du site Internet déclenche un processus métier pilotant l interrogation de l application logistique pour vérifier la disponibilité des produits, puis la transmission des informations à l application d approvisionnement pour alimentation automatique du stock. Lorsque le stock doit être reconstitué, le fournisseur contacté transmet en retour le délai d approvisionnement. L internaute est alors informé du meilleur délai de livraison qui peut lui être proposé. Dans le même esprit, plusieurs fournisseurs peuvent être mis en concurrence pour servir la demande de l internaute. Le rapport délais-coût est ainsi optimisé. Enfin, chaque fournisseur doit pouvoir informer le site marchand de la disponibilité de ses produits et de ses offres promotionnelles pour agencer au mieux le catalogue en ligne proposé aux internautes. L automatisation complète reste une hypothèse de travail car dans la pratique, une intervention humaine demeure indispensable en certains points du processus de vente et de livraison. Les bénéfices sont néanmoins réels : on observe en effet que la mise en œuvre de systèmes d achats intégrés peut réduire de 85 % les coûts habituellement liés à ces opérations.
Vue d ensemble Mettre en œuvre un système intégré Les trois logiques suivantes peuvent guider la démarche d implémentation d un système intégré : récréer un système d information intégré ; généraliser les passerelles interapplicatives ; fédérer les systèmes. Recréer un système d information intégré Cette approche conduit habituellement en une migration de l existant vers un nouveau système et a donc des conséquences importantes sur les coûts et les délais. Face aux changements permanents et aux fortes contraintes du marché, la refonte d un système d information se justifie en général plus par son obsolescence que par le seul besoin d intégration. Cette logique mène naturellement à la mise en œuvre de progiciels qui sont intégrés par essence et qui disposent d ouvertures sur les technologies Internet nécessaires à l implémentation de services d e-business. Le tout-intégré est séduisant car il libère de l hétérogénéité des systèmes et garantit l interopérabilité des différents services métier offerts, dont la gestion de production (ERP), l optimisation de la chaîne logistique (SCM) et la gestion de la relation client (CRM). Cette approche rend cependant l évolutivité du système d information dépendante des services et des technologies Internet définis dans la stratégie produit de l éditeur du progiciel. Cette démarche d intégration n incite pas à la réalisation d un système flexible susceptible, le cas échéant, de coopérer facilement avec les outils concurrents adoptés par les partenaires de l établissement. L entreprise qui prend la décision de recréer un système d information intégré doit veiller à garantir l ouverture et la flexibilité des applications mises en œuvre en vue d en assurer la pérennité. 9 Généraliser les passerelles interapplicatives Les entreprises disposant d un existant pérenne peuvent être tentées de résoudre leur problématique d intégration en mettant en œuvre des passerelles point à point, en général à travers un développement spécifique fondé sur un middleware adapté. Les problématiques d intégration ont souvent été résolues par ce type de développements. L interconnexion de systèmes départementaux qui en résulte aboutit rarement à un système d information global et cohérent, pour des raisons de temps, de coûts et parfois de faisabilité technique. Dans de nombreux cas, le résultat final de cette démarche est une écrasante complexité et une totale opacité. Les projets sont difficiles à terminer, puis à maintenir. La solution apportée freine les possibilités d intégration de nouvelles fonctionnalités ou de remplacement des briques existantes. Le Gartner Group qualifie ce type de solution de système «spaghetti». Applications légataires Applications spécifiques SCM CRM ERP E-commerce Figure 1 Système «spaghetti»
EAI De l intégration à l e-business / Vue d ensemble Par rapport à la logique de développement d un nouveau système, cette implémentation a l avantage de s appuyer sur l existant. En revanche, la solution résultante est rigide, ses frais de maintenance et ses coûts totaux de changement (TCC, Total Cost of Change) explosent rapidement. Si n est le nombre d applications à interconnecter, le nombre de passerelles bidirectionnelles à développer pour aboutir à un système complètement communicant est n (n 1). Pour 6 applications, il faut donc 30 passerelles De plus, le remplacement d une application par une nouvelle version ou par une application d un autre éditeur risque fort de rendre la passerelle obsolète ou d entraîner des travaux de maintenance complexes et coûteux : l équipe de développement initiale n est plus forcément disponible et la documentation technique est parfois insuffisante pour permettre la reprise des développements. Dans certains cas, la passerelle devient incontournable et retarde le remplacement de l application obsolète. En résumé et d après le cabinet Forrester Research, les entreprises confrontées à un environnement en constant changement consacrent jusqu à 40 % de leur budget informatique annuel au remodelage des flux d informations entre leurs différents systèmes et applications. Le chantier d intégration est donc un poste important du budget informatique des entreprises ; sa bonne utilisation doit privilégier la flexibilité et la pérennité du système intégré. Fédérer les systèmes 10 Préserver l existant tout en assurant la flexibilité et l évolutivité du système intégré sont les fondements des plates-formes d intégration. Ces plates-formes proposent des outils capables de se connecter aux sources de données et aux applications existantes d une entreprise et d échanger des informations de l une à l autre. Ces outils autorisent la mise en application d une démarche de fédération du système d information nommée EAI (Enterprise Application Integration, intégration des applications d entreprise). L EAI est un processus graduel, logique et répétitif qui permet à une entreprise de passer du système «spaghetti» à une architecture modulaire dans laquelle les applications peuvent être modifiées séparément sans impact sur le système existant. La démarche d EAI permet de mettre le client au centre du système d information en lui fournissant l ensemble des fonctionnalités et des données dont il a besoin en temps et en heure. On parle d architecture hub-and-spokes (à moyeu et à rayons) ou d architecture soleil. Applications légataires Applications spécifiques Solution d'eai SCM ERP CRM E-commerce Applications packagées Figure 2 Système d e-business hub-and-spokes (à moyeu et à rayons)
Vue d ensemble La concrétisation d une démarche d EAI peut représenter un défi technique au coût non négligeable. Mais les avantages procurés par ces outils dans la mise en œuvre du système d e-business (fluidification des échanges d information, modélisation des processus métier, flexibilité et réactivité au changement) et l évolutivité de ces plates-formes dans le cadre de l intégration de nouvelles applications garantissent un retour sur investissement très rapide en général après quelques mois d exploitation. Les plates-formes d EAI conduisent également à une industrialisation des processus de conception, de développement et de déploiement des applications, gage de la pérennité des systèmes intégrés ainsi réalisés. En résumé, tout concourt à privilégier la démarche d EAI dans le processus d évolution d un système d information vers l e-business. Domaines d application Les bénéfices de la démarche d EAI couvrent toute la chaîne de valeur de l entreprise et l accompagnent dans l application de sa stratégie d e-business. Cette démarche est un facteur de réussite important dans les domaines de la gestion de la chaîne logistique (SCM), de la gestion de la relation client (CRM) et des places de marché sur Internet (e-marketplaces). Gestion de la chaîne logistique La gestion de la chaîne logistique (SCM) désigne un ensemble d échanges entre partenaires et leur coordination. Il s agit d une approche globale qui couvre tous les aspects logistiques de l entreprise, depuis la planification des ressources jusqu à la livraison des produits, en passant par les prévisions, la conception et la fabrication. Ce type de besoin concerne tout particulièrement les entreprises dont la croissance s est effectuée par fusions ou acquisitions et qui ne disposent pas d une infrastructure informatique centralisée. Il émane aussi d entreprises soucieuses, dans une optique d entreprise étendue, d intensifier leur collaboration avec leurs partenaires. Une chaîne logistique intégrée est un facteur important d amélioration du délai de mise sur le marché d un produit ou d un service. Cette intégration permet un gain de temps dans les procédures d achat et dans les prévisions de fabrication, grâce à un meilleur contrôle du processus global de production. Cette démarche conduit naturellement à une meilleure productivité, à une réduction des coûts et, parallèlement, à l amélioration de la qualité du service rendu au client. Une chaîne logistique intégrée rend possible le pilotage de la production par la demande. C est le modèle build-to-order, qui permet à une entreprise de réduire ses coûts de stockage et d inventaire et de s adapter sans difficulté à une modification imprévue de la demande. L organisation doit bien sûr refléter ce modèle de flexibilité pour en garantir l efficacité et assurer la satisfaction du client final par une offre synchronisée à la demande. Le modèle du build-to-order est l illustration du lien étroit qui existe entre la gestion de la chaîne logistique et celle de la relation client. Le projet d intégration répond alors pleinement à une problématique globale d entreprise. 11 Gestion de la relation client La gestion de la relation client (CRM) a pour objectif d améliorer la satisfaction et la fidélité des clients. Le développement d applications CRM nécessite une démarche d unification des informations dispersées dans l entreprise pour constituer le référentiel client (voir l encadré «Le référentiel client»). Ce dernier s enrichit d informations fournies par des services traditionnellement mis en œuvre au sein du back-office. Il faut donc bien penser l intégration du projet CRM au système d information et qualifier avec soin les données qui constitueront le référentiel client. Le besoin d intégration se fait particulièrement sentir sur le plan de l alimentation des services de gestion de la relation client. En effet, le système CRM, situé à la croisée de domaines tels que la vente, le marketing et le support client, est un consommateur avide d informations consolidées. En aval, il peut également s intégrer avec les applications de facturation et de comptabilité ou avec des systèmes décisionnels.
EAI De l intégration à l e-business / Vue d ensemble Cette démarche d intégration des informations client élargit le potentiel de personnalisation des services offerts. Ce potentiel se manifeste lors de l extension des activités de l entreprise sur Internet. La personnalisation du contenu et des services est une stratégie payante en matière de fidélisation des clients ; cette démarche rend possible la collecte d un ensemble d informations indispensables à la connaissance du profil des internautes visitant le site. Cette application devient en effet un point de contact privilégié avec des clients que l entreprise ne verra peut-être jamais physiquement. L e-business est une forme d intermédiation dans laquelle les informations sont présentées au client sans le concours des collaborateurs du front-office. Ceux-ci, de par leur connaissance du métier, savent masquer la complexité des processus d entreprise et ont une appréhension «physique» du client qu une application Internet ne peut pas avoir. L application Internet doit comporter des mécanismes permettant de créer cette connaissance à partir des informations fournies sur le site par le client. Le référentiel client Chaque application à intégrer (CRM, ERP, applications légataires, etc.) dispose d une vue différente de l entité client. La constitution d un référentiel client unifié est bien plus qu une problématique technique car elle influe sur la définition même du client et des processus métier qui l utilisent. La fiabilité des informations échangées dépend à la fois du format des données et de l application des règles métier. Pour assurer la cohérence, il faut construire une vue unifiée du client en temps réel. Cette vue unifiée constitue le référentiel client, indispensable aux applications CRM et point central des applications d e-business construites sur le nouveau système. 12 e-marketplaces Une place de marché est un point de liaison central destiné à réunir des centaines d acheteurs et de vendeurs. Sur Internet, le concept de place de marché se traduit par la mise en relation des systèmes d information des entreprises au travers d une intégration «métier». Ces places de marché sont généralement spécifiques à des industries, mais les besoins d intégration sont similaires et convergent aujourd hui vers un certain nombre d initiatives de normalisation. Ce nouveau modèle économique impose la prise en compte de trois dimensions : La gestion des transactions, de la sécurité (cryptage et authentification des parties) et de l infrastructure réseau Techniquement, les besoins sont proches de ceux de l EAI interne à une entreprise : messaging, non-répudiation et sécurité. La gestion des fournisseurs et des catalogues Il s agit de la capacité à recruter des vendeurs, à collecter les catalogues (sous tous formats, y compris papier) et à générer des catalogues normalisés. L offre de services à valeur ajoutée Ce sont des enchères, des appels d offres, ou encore les services de logistique ou de facturation électronique. La différenciation concurrentielle tient à l originalité du modèle de services et à sa qualité. La participation financière des acteurs pourra être fixée au mois ou à la transaction. On retrouve différents acteurs sur ce marché : Des éditeurs d applications d e-marketplace, comme i2 Technology et son produit TradeMatrix. Des éditeurs de progiciels comme SAP, avec mysap.com ou Oracle, avec Oracle Exchange. La spécificité de ces offres est de se connecter à leurs propres environnements logiciels. Des acteurs du B2B, comme Ariba Software ou Commerce One. Des acteurs de l EAI qui, comme Tibco, enrichissent leur offre d EAI initiale de modules complémentaires d EIP (Enterprise Information Portal) et de B2B. Les solutions de places de marché sont en général créées à partir de technologies complémentaires. Par exemple, e2open.com est une place de marché reliant les acteurs des industries informatique et électronique fondée sur B2B Commerce Platform, d Ariba Software, sur l application d e-marketplace TradeMatrix, d i2 Technology, et sur WebSphere Commerce Suite, d IBM. EAI et EIP La distinction entre EAI et EIP (Entreprise Information Portal) peut paraître floue dans la mesure où ces deux types de solutions se connectent à des systèmes hétérogènes et à des sources de données variées. Cependant, l EAI a pour objectif l échange de données entre applications, alors que l EIP agrège les informations pour une application cible qui va se charger de les présenter à l utilisateur final. L EIP a donc une finalité front-end marquée, alors que l EAI est orientée back-end. En règle générale, ces deux solutions sont complémentaires et l application d EIP constitue le front-end du système d information dont les données proviennent en partie de la plate-forme d EAI. L e-marketplace est un réseau à valeur ajoutée dont la matérialisation tient autant de l EIP que de l eai (l extension sur Internet de l intégration d applications).
Vue d ensemble De l intégration à l e-business Parmi les trois démarches de conception d un système intégré que nous avons décrites précédemment, la démarche d EAI est celle qui permet de s appuyer sur les applications existantes en se focalisant sur la flexibilité et l adaptabilité du système résultant. Par définition, la démarche d EAI est un processus d intégration d applications développées indépendamment, utilisant des technologies incompatibles et devant continuer à être gérées séparément. La flexibilité, l évolutivité et l adaptabilité, aujourd hui indispensables au maintien de la compétitivité de l entreprise, sont également des bénéfices stratégiques qui découlent de la mise en œuvre de ces solutions. Ainsi, non seulement une démarche d intégration permet d orienter les systèmes d information vers l e-business, mais elle est aussi la plus apte à assurer leur pérennité face aux besoins d évolution. Cette réactivité couvre la possibilité d accueillir facilement de nouvelles applications au sein de l entreprise conçue dans sa globalité, c est-à-dire étendue aux systèmes de ses partenaires. Pour répondre à de telles exigences, les plates-formes d EAI imbriquent des technologies très variées. Afin d en aborder la richesse et d en comprendre l évolution, examinons les différentes briques qui constituent aujourd hui les solutions d intégration. La première génération de plates-formes d EAI, dédiée à la libération des flux d information au sein de l entreprise, est dotée d une organisation, que nous qualifierons de modèle EAI, construite sur quatre briques techniques : Le transport des données Potentiellement sécurisé, il passe par des files d attente de messages qui encapsulent l information et la stockent jusqu à son exploitation. L extraction d informations depuis les applications et l insertion de nouvelles informations dans ces applications Cette opération est réalisée par l utilisation de connecteurs qui se «branchent» sur les applications. Les composants Ils permettent d effectuer des traitements métier complémentaires sur les données extraites. Ils enrichissent et étendent l intelligence de la plate-forme d intégration. Le moteur d intégration Il administre les règles de transformation et de routage des données. Cœur du système, il fournit également un ensemble de services complémentaires d administration, de surveillance et d analyse de l activité du système. Ce modèle est représenté graphiquement par la figure 3. 13 Moteur d'intégration Composants Données Transport Figure 3 - Modèle EAI
EAI De l intégration à l e-business / Vue d ensemble 14 Lors d une extraction de données, l information est recueillie par les connecteurs applicatifs, puis empaquetée dans un message placé et conservé dans des files d attente. Le moteur d intégration, alerté par l arrivée d un message, traduit les données pour les router vers l application destinataire. Les composants peuvent être sollicités pour vérifier certaines règles métier et influencer le comportement du moteur d intégration. En dernier lieu, les données sont transmises, via la couche transport, au connecteur branché sur l application destinataire et chargé d opérer la mise à jour des données. Ce modèle est extrêmement flexible, car il existe des connecteurs applicatifs pour un grand nombre d applications standard du marché. Il devient dès lors plus facile de remplacer une application obsolète par une application exploitant de nouvelles fonctionnalités et de nouvelles technologies. De plus, l intégration d une application au système d EAI s opère par simple abonnement de celleci aux files d attente de messages, configurées depuis le moteur d intégration. Le système d information bénéficiant de l apport d une plate-forme d EAI devient un système modulaire dont l évolution n est pas source d instabilité. La deuxième génération est tournée vers les processus métier et les échanges interentreprises : elle prend en compte les nouveaux modèles économiques créés et promus par Internet et ses technologies (TCP/IP, SMTP, HTTP, FTP, XML, etc.). Cette deuxième génération de plates-formes d eai dispose d une architecture enrichie, qualifiée désormais d eai, offrant un modèle d intégration étendu à ses partenaires. Les technologies qui viennent se greffer sur le modèle initial sont : Un moteur de workflow Il sert à modéliser et à mettre en œuvre au sein de la plate-forme d intégration les processus métier de l entreprise. Une infrastructure d échange B2B Elle permet aux entreprises de communiquer. Le moteur de workflow complète le travail des composants dans l organisation de la logique métier. Concrètement, les processus métier modélisés au sein du moteur de workflow sont implémentés par ces composants. Leur exécution s enrichit de mécanismes de synchronisation ou de rendez-vous, prend en compte l intervention humaine à travers des notifications et encapsule des transactions longues avec possibilité de restaurer les données dans leur état initial. La brique d échange B2B ouvre la plate-forme vers l extérieur. Cette ouverture s appuie sur un échange des données formatées dans des langages normalisés construits sur XML. Cet échange s intègre dans un processus métier workflow, lui-même normalisé par les travaux d organismes fédérateurs que nous présentons plus loin dans ce livre blanc. Seront ainsi distingués les processus privés, internes à l entreprise, et les processus publics, partagés avec les partenaires. Ces deux nouvelles briques viennent se superposer au modèle initial pour définir la topologie à six couches représentée graphiquement par la figure 4. B2B Processus Moteur d'intégration Composants EAI eai Données Transport Figure 4 - Modèle eai
Vue d ensemble Ce modèle complet a été initialement introduit par le Hurwitz Group, cabinet de conseil de Boston. On constate que les services initiaux du modèle EAI sont toujours présents et constituent les fondations du modèle étendu. Des fonctionnalités complémentaires sont intégrées, mais le mode de fonctionnement de la plate-forme est inchangé. La flexibilité est toujours présente ; elle s étend aux partenaires de l entreprise. Il est ainsi aisé d intégrer de nouveaux partenaires aux processus d échanges sur la base des normes établies. Chaque couche dispose de sa propre technologie. La plate-forme d eai est la concrétisation de la cohabitation réussie de ces technologies. Le modèle reflète bien la nature profonde de l eai : un domaine où des composants essentiellement technologiques (le middleware, les connecteurs, etc.) côtoient des éléments d un haut niveau d abstraction (modélisation des processus métier) pour aligner la stratégie du système d information sur celle de l entreprise. Ainsi, si une intégration efficace des technologies détermine les performances de l ensemble de la plate-forme, la capacité de celleci à traduire les aspects fonctionnels en éléments techniques en validera la viabilité en tant que solution d entreprise. Nous aborderons dans la suite de ce livre blanc le détail des technologies mises en œuvre par le modèle EAI et son évolution vers l eai. 15
EAI De l intégration à l e-business / Le modèle EAI CHAPITRE 2 Le modèle EAI Ce chapitre reprend les couches décrites dans la vue d ensemble : transport ; données ; composants ; moteur d intégration. 16 Transport : un middleware pour les données Définition Les services de transport assurent la livraison des données aux applications via le moteur d intégration, tout comme l appareil circulatoire alimente en sang chaque organe du corps. Dans la pratique, toutes les solutions d EAI reposent sur une couche plateforme, ou middleware, soit propriétaire, soit fournie par un éditeur partenaire. Plus généralement, une solution d EAI doit savoir se connecter à tout middleware existant et doit proposer des passerelles entre les middlewares hétérogènes présents dans l entreprise. L intégration s opère ainsi à tous les niveaux : applications, données et middlewares. Fonctionnalités et technologies Le middleware de l EAI par excellence est asynchrone. Il est constitué de files d attente de messages (message queues). Ces solutions sont regroupées sous la dénomination de MOM (Message Oriented Middleware). La plus connue est sans conteste MQSeries, d IBM ; Microsoft propose MSMQ, sa propre solution. Les MOM sont une couche de transport et ont besoin pour fonctionner d un outil d administration des messages transportés : le message broker. Dans une solution d EAI, ce dernier tient le rôle de moteur d intégration. Deux autres middlewares synchrones sont également utilisés dans une logique d intégration : les ORB (Object Request Brokers), qui correspondent à la fois au middleware sur lequel reposent certaines solutions d EAI et au middleware constitutif de l existant d une entreprise qu il faut savoir intégrer ; TCP/IP et HTTP (HyperText Transfer Protocol), protocoles standard de l Internet, en passe de devenir le middleware de référence de l échange workflow. Retenons pour l instant qu avec un middleware asynchrone, il n est pas nécessaire de s assurer de la disponibilité de l application destinataire, alors qu un middleware synchrone va l exiger. Or, tout progiciel connaît régulièrement des phases d indisponibilité, correspondant au lancement de traitements de masse ou à des opérations de maintenance. Les middlewares sont donc plutôt des technologies complémentaires qu une plate-forme d EAI doit savoir intégrer et faire communiquer avec le système de MOM sur lequel elle repose.
Le modèle EAI Middleware asynchrone : les MOM Les MOM désignent les technologies d échange des messages stockés dans des files d attente. Le MOM est un routeur de flux interapplicatifs reposant sur une logique asynchrone : le message est envoyé sans que le processus émetteur attende une quelconque réponse avant de poursuivre son exécution. La disponibilité de la file d attente n implique pas la disponibilité de l application à laquelle le message est destiné, ni la fiabilité du réseau par lequel le message doit être véhiculé. Le couplage entre applications est un couplage lâche et non intrusif réalisé par l intermédiaire des files d attente. Voici une liste des services traditionnellement délivrés par les MOM : Gestion des priorités Les messages peuvent être traités selon un ordre déterminé grâce à l affectation d un niveau de priorité. Gestion événementielle La réception d un message, ou sa délivrance, sont des événements dont la réalisation peut en déclencher un ou plusieurs autres : création automatique de messages immédiatement postés dans les files d attente, invocation de méthodes sur les composants métier, etc. Sécurité des échanges Les échanges sont sécurisés par : - la garantie de délivrance : un message n est jamais perdu ; s il ne peut être remis, il est placé dans une file intermédiaire gérée par un administrateur ; - la garantie d unicité : un message est traité une et une seule fois. Sécurité d accès Elle couvre la gestion des profils utilisateurs et la gestion des profils applicatifs (restriction de l accès à certaines files d attente). Le modèle de communication de ce type le plus répandu est le publish and subscribe. Les programmes enregistrés «s abonnent» à un sujet (une file de messages) et peuvent alors y poster des messages ou y recueillir les messages publiés. 17 Rules Publisher Agent Topic subscribe registrer Subscriptions Subject, Channel receive notification/ message Subscriber Agent Figure 5 Modèle publish and subscribe
EAI De l intégration à l e-business / Le modèle EAI 18 Middlewares synchrones : les ORB et HTTP Les ORB Les ORB peuvent être considérés comme une évolution structurée des mécanismes de RPC (Remote Procedure Calls). Dans les deux cas, le principe est l invocation synchrone de fonctions applicatives sur des serveurs distants. A la suite de l appel, le client attend un message l informant de l issue de l exécution de la fonction. Ce type de fonctionnement est difficilement compatible avec une logique d intégration, selon laquelle les applications autonomes doivent continuer à s exécuter indépendamment les unes des autres. Rendre le système intercommunicant ne signifie pas le rendre interdépendant ; dans une perspective d intégration, l interdépendance forte des systèmes est à éviter. Notons de plus qu un système fondé sur ces mécanismes nécessite une bande passante élevée pour faire face au trafic réseau requis par les nombreux échanges de messages interapplicatifs. Si on peut difficilement placer les ORB au centre d une plate-forme d intégration, on peut néanmoins les rencontrer parmi les technologies à intégrer, notamment pour réutiliser les services métier fournis par des composants placés sur un bus ORB. Nous allons brièvement décrire les mécanismes ORB et ses implémentations les plus fréquemment rencontrées dans l entreprise. Un ORB forme un bus logique sur lequel se trouvent des composants métier qui fournissent des services. L ORB traite l arrivée des requêtes, localise le composant appelé et retourne le résultat de l appel. Un référentiel (interface repository) est nécessaire pour connaître les interfaces de tous les composants disponibles. Les ORB sont conçus pour être utilisés dans des projets utilisant une véritable approche orientée objet. Les implémentations d ORB disponibles sur le marché sont Corba (Common Object Request Broker Architecture), de l OMG (Object Management Group), DCOM (Distributed Component Object Model), de Microsoft et les EJB (Enterprise JavaBeans), de Sun Microsystems. Corba L OMG, groupement de plusieurs centaines de membres, a défini dans les années 90 un standard pour le monde des ORB : Corba. Ce standard est un ensemble de spécifications laissant le choix de l implémentation aux éditeurs. Des incompatibilités entre les API et entre les ORB en ont résulté. Corba est avant tout un mouvement qui a amené les vendeurs à une meilleure reconnaissance et a facilité les développements. Deux grandes étapes ont marqué la vie de ce standard : - La création d IDL (Interface Definition Language), langage de description des interfaces de composants logiciels. - La définition, en 1996, du protocole IIOP (Internet Inter-ORB Protocol), qui a été un pas important pour la communication inter-orb. Ce protocole a ensuite été étendu à des ORB ne s alignant pas sur Corba, comme RMI (Remote Method Invocation), de Sun Microsystems, et par conséquent au modèle EJB. DCOM DCOM est une évolution du modèle de composants propriétaires COM, de Microsoft. Cet ORB utilise le protocole ORPC (Object Remote Procedure Call) et fonctionne essentiellement sous le système d exploitation Windows. Son avantage est d être plus accessible que la technologie Corba car globalement moins complexe. Des éditeurs tiers fournissent des services COM sur différentes plates-formes. Les services offerts par DCOM sont plus limités que ceux proposés par les spécifications Corba, mais ils s améliorent avec COM+ ou avec l adjonction d autres technologies Microsoft. EJB Le monde Java propose une solution de rechange émergente, reposant sur RMI et sur le modèle de composants métier EJB couplé au référentiel JNDI (Java Naming Directory Interface). Grâce à l apport de la spécification EJB 1.0 puis 1.1, les architectures Java disposent désormais d un ORB capable de communiquer avec des ORB Corba. Malheureusement, des spécifications non exhaustives ont, comme pour Corba, obligé les éditeurs à effectuer leurs propres implémentations du modèle, rendant les composants EJB peu portables. La spécification 2.0 vise à combler ces lacunes.
Le modèle EAI HTTP Nous avons évoqué les raisons pour lesquelles un middleware synchrone paraît inadapté à une architecture d intégration. HTTP semble pourtant y avoir sa place, mais peut-être davantage dans le modèle eai que dans le modèle EAI. En effet, en plus de sa nature synchrone, HTTP propose des performances moyennes comparées à celles des MOM, ce qui semble lui barrer la route de l intégration intra-entreprise. Il permet en revanche un couplage faible et non intrusif entre les systèmes d information d entreprises autonomes, rendant l échange possible sans qu il soit nécessaire de connaître les technologies utilisées chez les partenaires. De plus, HTTP est un standard véhiculé par un autre standard, le réseau Internet, qui permet d élargir facilement la gamme des services offerts, là où Edifact et X.12, protocoles de l EDI, sont nettement plus fermés. HTTP peut devenir, en tant que couche de transport de messages métier XML, le middleware de l échange interentreprise. Ce middleware se superpose à celui utilisé en interne par la plate-forme d intégration : le message provenant d un partenaire est transmis à une file d attente qui assure la jointure entre les parties internes et externes du système d e-business. Certaines discussions concernent aujourd hui la généralisation de HTTP dans une architecture d intégration en vue de créer des systèmes d e-business «temps réel» entièrement fondés sur un protocole synchrone. Couche plate-forme et EAI Aujourd hui, le middleware prédominant dans les offres d EAI du marché est bien le MOM ; le couple MOM/message broker est le noyau d intégration majoritaire dans les offres des éditeurs. Il est d ailleurs intéressant de noter que certaines entreprises d EAI, telles que Level 8 ou Neon Software, ont été créées par des ingénieurs ayant précédemment participé aux spécifications ou au développement de solutions de message queuing parmi les plus renommées (citons MQSeries et MSMQ). De par leur rôle et leur position, ils ont su saisir toute l importance de cette technologie et les développements qu elle était susceptible de susciter et de supporter. Leur approche est qualifiée de bottom-up. Certaines offres d EAI bénéficient de la présence d un middleware propriétaire. C est le cas de Geneva MQ, de Level 8, de TIB/Rendezvous, de Tibco, ou des Intelligent Queues, de STC. Les offres d EAI utilisent généralement un message broker qui a besoin de ce type d infrastructure, qui garantit un bon niveau de performances sur son architecture propre. Lorsque l éditeur ne propose pas de solution, la plate-forme est généralement conçue pour reposer sur un des MOM du marché, parmi lesquels figurent en bonne place MQSeries et MSMQ. D autres grands acteurs présents sur le segment de marché des MOM ou sur celui des message brokers (sans qu il s agisse pour autant de leur unique activité) ont aussi évolué vers l ouverture de leurs solutions à l intégration d applications. IBM a pu s y consacrer grâce à son MOM MQSeries, aujourd hui réputé et très répandu, et Oracle a profité de son offre AQ (Advanced Queues) pour présenter OIS (Oracle Integration Server). 19 Données : les adaptateurs applicatifs Définition Les données de chaque application doivent être conservées dans leur format natif et sur leur support d origine, en vue de permettre à l application qui les héberge de continuer à assurer les services fournis avec le même niveau de performances et d éviter les coûts liés à leur migration d un référentiel vers un autre. Les adaptateurs applicatifs (ou connecteurs) vont extraire ces données en fonction des besoins (événements déclenchés par l arrivée d un message, étape d un processus métier) et les diriger vers l application destinataire. Les connecteurs assurent la communication entre la plate-forme d EAI et les applications ou les services applicatifs du système d information. Un adaptateur applicatif est un composant logiciel qui offre la connectivité nécessaire à l interfaçage avec les applications et les sources de données, avec ou sans intelligence métier. Cette couche logicielle masque à l utilisateur la complexité de la communication entre l API du moteur d intégration et celle de l application.
EAI De l intégration à l e-business / Le modèle EAI Fonctionnalités et technologies 20 Les connecteurs doivent être des systèmes non intrusifs (on n introduit pas de portions de codes dans les systèmes sources ou cibles). Ils peuvent fournir des services complémentaires tels que la gestion des exceptions ou des mécanismes de remontée d erreurs. Ils doivent donc être dotés de l intelligence nécessaire à l interprétation de ces messages. Il faut également que la plate-forme d intégration soit capable d interpréter les messages d erreur en tant que tels. Typologie des adaptateurs Il existe aujourd hui un grand nombre d adaptateurs, qui correspondent aux différents types d applications que l on peut rencontrer. Le nombre d adaptateurs fournis avec chaque solution est d ailleurs un argument de vente des éditeurs d EAI. Pour décrire les offres d EAI, nous adopterons dans ce livre blanc la classification suivante : SGBD DB2, SQL Server, Informix, Oracle, Sybase, Lotus Notes, ODBC, JDBC, etc. ; ERP PeopleSoft, SAP, Oracle Applications, JDEdwards, Siebel, etc. ; CRM Vantive, Siebel, Clarify, BroadVision, etc. ; SCM i2 Technology, etc. ; Mainframes SNA, CICS, IMS, OSI TP, VSAM, EBCDIC, 3270, OS/390, etc. ; MOM MQSeries, MSMQ, etc. ; ORB Corba, DCOM, Java, etc. ; Protocoles Internet HTTP, XML, SMTP, etc. ; B2B Swift, Edifact, X.12, XML (RosettaNet, BizTalk), etc. Applications spécifiques Il y a, dans une entreprise, un ensemble d applications spécifiques légataires pour lesquelles il ne peut exister d adaptateur standard sur le marché. Pour cette raison, les éditeurs fournissent généralement avec leur plate-forme un kit de développement. Il guide la mise en œuvre de connecteurs et masque une partie de la complexité technique propriétaire, notamment la communication avec les files d attente. Les kits de développement (SDK, Software Development Kit), la documentation sur les API existantes et la formation dessinent la panoplie du développeur de connecteurs. Il est donc important, lors de la recherche d une plate-forme d EAI, de vérifier si des formations sont assurées, éventuellement sur site et, au besoin, si elles sont dispensées en français. Généralement, l éditeur propose aussi des prestations de conseil et d ingénierie pour la réalisation des adaptateurs ou délègue ces missions à des intégrateurs partenaires. Couche données et EAI La technologie des adaptateurs est un point sur lequel les éditeurs insistent fortement lors de la promotion de leurs plates-formes. Le nombre d adaptateurs fournis et la qualité de la technologie et des services pris en charge sont des critères différenciateurs entre deux offres. En effet, la technologie des connecteurs a énormément évolué depuis les débuts de l EAI. Nous allons en tracer un bref historique pour mieux présenter les technologies disponibles. De l adaptateur «léger» à l adaptateur «riche» Les adaptateurs «légers» effectuent une simple translation d API pour offrir une interface commune au message broker. Cependant, l ajout d une interface de programmation intermédiaire pénalise les performances sans réellement fournir de nouvelles fonctionnalités. De plus, le connecteur n est pas utilisable en mode natif : il faut nécessairement programmer pour accéder à ses services, tâche compliquée par la nécessité d être familier avec l API du message broker, probablement propriétaire. Les adaptateurs «riches» rendent la programmation très aisée, voire inutile. Dans de nombreux cas, l utilisateur emploie une interface graphique pour connecter les systèmes sans recourir à la programmation. Ces adaptateurs fournissent également une qualité de service supérieure, comme la prise en compte d une partie de la montée en charge par multithreading statique ou dynamique.