FICHE CONCEPT 02 EAI (ENTERPRISE APPLICATION INTEGRATION) ET ESB (ENTREPRISE SERVICE BUS)

FICHE CONCEPT 02 EAI (ENTERPRISE APPLICATION INTEGRATION) ET ESB (ENTREPRISE SERVICE BUS) BIEN GERER SES REFERENTIELS DE DONNEES : UN ENJEU POUR MIEUX PILOTER LA PERFORMANCE DE SON ETABLISSEMENT octobre 2008 GMSIH 44, Rue de Cambronne 75015 Paris. Tel : 01 48 56 72 70. Fax : 01 48 56 07 70

Copyright 2008 GMSIH Permission vous est donnée de copier et distribuer ce document selon les termes de la Licence D-GMSIH, Version 2.0 ou ultérieure publiée par le GMSIH. Une copie de cette licence peut être consultée à l adresse : http://www.gmsih.fr/fre/nos_publications/licences_gmsih Versions du document : Date Version Commentaires Statut Octobre 2008 1.0 Publication de l étude Validé 08/10/08 2/9

Sommaire 1. Description du concept et des outils associés...5 1.1 Préambule...5 1.2 Qu est-ce qu un EAI?...5 1.3 ETL, EAI et ESB...5 1.4 Choix d un outil...6 1.5 Le marché...6 2. Principaux enjeux pour les s de santé...8 3. Mise en œuvre...9 08/10/08 3/9

Projet : P132 Référentiels SID dans les ES Fiche concept 02 EAI et ESB Définition Un EAI (Entreprise Architecture Integration) est un composant technique du système d information destiné à industrialiser et à normaliser les échanges entre applications. Les flux de données organisés de "point à point", c est à dire directement d une application à une autre, sont remplacés par des échanges dans des formats pivots entre chaque application et un médiateur : l EAI. La mise en œuvre d un EAI est une solution de la démarche d urbanisation du système d information permettant de structurer et normaliser les échanges de données. Notons que l adoption des architectures orientées service (SOA) a permis l émergence d un nouveau type de solution : l ESB (Entreprise Service Bus), qui répond aux mêmes objectifs qu un EAI, mais dans une architecture légèrement différente. Schéma explicatif 1 - Les échanges d informations se font "point à point". Un flux de données est par exemple constitué des informations relatives à l identification d un patient. 2 - L EAI permet d organiser les échanges entre ces applications de façon à minimiser les interfaces. Il n y a par exemple qu un seul flux de création de patient l EAI se charge de transmettre l information à l ensemble des applications clientes. 3 - L ESB est une variante de la solution EAI, dans une architecture distribuée. Les différences entre EAI et ESB sont expliquées plus loin dans cette fiche. Fonctionnalités et outils associés Gestion des interactions entre applications : l EAI réagit à des évènements survenus à l intérieur d une application, ou est sollicité par des requêtes en provenance d une application il gère donc des échanges de messages entre applications, et est capable de supporter de véritables transactions inter-applicatives il peut solliciter une action humaine avant de poursuivre le traitement d un message (par exemple une validation) Fonctionnalités liées au développement : les EAI disposent de connecteurs capables de traiter des formats de messages standards comme HL7 ou de communiquer de façon simplifiée avec des progiciels un atelier de développement permet de paramétrer visuellement sur un écran le circuit de l information et les transformations à effectuer cet atelier autorise le travail collaboratif entre développeurs, et la gestion des versions des composants Fonctionnalités liées à l administration et à l infrastructure : monitoring et traçabilité des flux haute disponibilité et possibilité de reprise sur incident Exemples d outils du marché Coûts macroscopiques État des lieux (2008) IBM Websphere Process Server, Intersystem Ensemble, Microsoft Biztalk, Oracle (BEA) WebLogic, Quovadx Cloverleaf, Wraptor Jeebop, etc. (Une liste plus complète est présentée plus loin dans cette fiche.) De plusieurs dizaines de milliers d euros à un million d euros pour les solutions haut de gamme. Tarification au nombre de processeurs, au nombre de connecteurs, à la taille de l, etc Souvent rencontré en de santé Parfois rencontré en de santé Rare en de santé 08/10/08 4/9

1. DESCRIPTION DU CONCEPT ET DES OUTILS ASSOCIES 1.1 PREAMBULE L intégration des applications est une problématique ancienne des systèmes d information. Les solutions logicielles ainsi que les principes d architecture ont considérablement évolués depuis le milieu des années 90 et ne sont pas encore complètement stabilisés. On constate aujourd hui une convergence de différentes solutions vers de véritables "suite d intégration", mais le marché est encore en cours de maturation : rachats importants (BEA par Oracle, Webmethods par Software AG, Seebeyond par Sun, ), rationalisation des offres, définition et adoption progressive de standards, etc. De plus, il y a aujourd hui peu de convention au niveau de la dénomination des produits d où parfois un manque de lisibilité des offres. Une nouvelle tendance est l adoption des architectures orientées service (SOA) et d outils d intégration conçus pour supporter ce type d architecture : les ESB (Enterprise Service Bus). Le marché des ESB est naissant (il n y a notamment pas de référence connue en de santé) mais en forte croissance comparé au marché des EAI "traditionnels", qui dominent mais progressent peu (au niveau mondial, et tous secteurs d activité confondus). 1.2 QU EST-CE QU UN EAI? Un évènement (enregistrement d un patient ou demande d acte par exemple) saisi dans le cache d une application donnée est transmis à l EAI ou est capturé par l EAI. Ce message est mis à disposition ou distribué aux autres applications utilisatrices de l information. Les données peuvent faire l objet de transformations et plusieurs messages en provenance de différentes applications peuvent être combinés. Un retour d information peut-être envoyé à l application émettrice afin de clore une transaction par exemple. On aboutit alors à la construction de véritables processus. Des interventions humaines peuvent être insérées dans les processus. On peut ainsi mettre en place des workflow complexes. On distingue le mode "évènement" dans lequel des messages sont produits automatiquement suite à un événement donné et le mode "requête/ réponse" dans lequel une application cliente fait une demande d information. Certains EAI possède une fonction de screen scraping (permettant de simuler un utilisateur), ce qui évite d avoir à comprendre le fonctionnement interne de l application, qui reste une boîte noire à laquelle on accède par des interfaces utilisateurs connues. Cette fonction peut par exemple être utilisée comme outil permettant de rejouer indéfiniment des scénarii de tests dans le cadre de recette applicative ou encore pour simuler une action humaine au sein d'un processus informatisé. 1.3 ETL, EAI ET ESB Il ne faut pas confondre un EAI et un ETL: un ETL répond à des besoins d intégration de données notamment lors de traitements massifs de données (par exemple, transfert mensuel des informations de paie dans l outil de comptabilité). En revanche, un EAI permet de répondre à des besoins de gestion de transactions, de processus, ou d implémentation de règles métiers. L EAI ne sera en revanche pas performant pour les flux massifs (par exemple, transfert ou mise à jour de 5000 actes). De la même façon, la distinction entre EAI et ESB n est pas toujours claire, d autant plus que ces acronymes peuvent désigner à la fois des principes d architecture et des outils. EAI et ESB poursuivent les mêmes objectifs car ils répondent aux mêmes besoins mais selon un fonctionnement différent. 08/10/08 5/9

La montée en puissance des ESB est liée à l adoption des architectures SOA, les ESB ayant été conçus pour ces architectures et notamment pour travailler avec les Web Service, contrairement aux EAI "classiques" qui sont plus anciens et qui s intègrent donc de façon moins native dans ce type de configuration. L autre différence essentielle entre un outil EAI classique et un ESB réside dans l aspect décentralisé de l ESB, autorisé par la mise en place d une architecture orientée service: alors que l EAI est un hub central (tous les échanges passent par ce centre de traitement, qui porte l ensemble des tâches d intégration et qui nécessite donc une puissance importante), l ESB s appuie sur des services qui sont distribués dans le SI. Un certain nombre de tâches sont donc déportées au plus près des applications sources qui exposent leurs services. L EAI se positionne pour répondre à des besoins très complexes dans des environnements très critiques 1. En revanche, un ESB a la capacité de répondre à la plupart des besoins d intégration, de façon plus simple et moins coûteuse mais il nécessite la mise en place d une architecture SOA et de la démarche associée. 1.4 CHOIX D UN OUTIL Le choix d un outil d intégration est principalement dicté par : 1) L adéquation des possibilités de l outil aux besoins d intégration (connecteurs, cohérence avec l existant de l, possibilités d orchestration, ) et au niveau de criticité à supporter 2) Le prix d acquisition et de mise en œuvre 3) Les compétences disponibles sur le marché ou en interne, et donc le niveau de maitrise possible de la technologie 4) La pérennité de la solution. Pour l évaluer dans un marché en pleine mutation, on s intéressera au nombre de sites en production, qui est un bon indicateur et qui donne des garanties même en cas de rachat de l éditeur. 5) L existence de standards d échange. 1.5 LE MARCHE On peut distinguer deux grands types d éditeurs : Les spécialistes de la santé : Ils proposent des solutions ciblées sur ce secteur mais par conséquent généralement moins répandues que les solutions non spécialisées. Les compétences sont donc rares en dehors des consultants que l éditeur peut proposer. En revanche, les solutions sont plus pragmatiques, potentiellement plus légères et adaptables aux particularités du monde de la santé (connecteurs performants et souples) que les solutions généralistes. Exemples : Siemens OpenLink, SIB Touline, Quovadx Cloverleaf, Wraptor Jeebop, Enovacom Antares, Intersystem Ensemble. Les éditeurs d offres non spécialisées sur un secteur d activité : 1 En général, la mise en place d'une solution d'intégration de type EAI est motivée par un Système d'informations à l'image des logiciels au code "spaghetti" : difficile à maintenir. 08/10/08 6/9

Les spécialistes de l intégration : leur cœur de métier est l intégration d applications. Leurs offres sont cohérentes, ouvertes et souvent technologiquement en avance. Cependant, elles peuvent nécessiter un travail d adaptation au secteur de la santé. Exemples: Software AG WebMethods (et Service Orchestrator pour la partie ESB), Cross Database Technology DataExchanger, BEA (racheté par Oracle) WebLogic (Aqualogic Service Bus pour la partie ESB), Axway Synchrony, SUN Seebeyond (CAPS ESB pour la partie ESB), Open Adaptator (Open Source), Petals (ESB Open Source) Les éditeurs généralistes: ils vendent aussi des SGBDR, des serveurs d application, des progiciels, etc. Par rapport à la santé, leurs offres sont généralement moins avancées et moins lisibles du fait de rachats multiples, mais ils sont rassurants sur leur capacité à apporter du service et des solutions à tous les besoins. Ils ont progressivement constitué, souvent par des rachats, des "suites d intégration" très complètes, avec des briques ETL, EAI, serveur d application, atelier de développement de services et de portails, outils de supervision de processus, annuaires, MDM, etc Ces briques sont souvent optimisées pour fonctionner ensemble d où un risque de dépendance. Exemples : IBM Websphere Process Server et Websphere Message Broker (Websphere ESB pour la partie ESB), Microsoft Biztalk, Oracle Integration (Oracle ESB pour la partie ESB), SAP Netweaver XI Les solutions dédiées à la santé sont les plus répandues dans les s de santé, mais on rencontre aussi des solutions non spécialisées qui ont su répondre aux besoins. Nous n avons à ce jour pas rencontré d ayant mis en œuvre un outil ESB. 08/10/08 7/9

2. PRINCIPAUX ENJEUX POUR LES ETABLISSEMENTS DE SANTE Par rapport à un système traditionnel d échanges "point à point", les principaux apports d un EAI sont les suivants : Réduction des coûts de mise en œuvre et de maintenance : réduction du nombre d interfaces (fin de "l architecture spaghetti"), outil de développement graphique, gestion centralisée et documentée des développements, réduction du nombre de technologies à maîtriser, connectivité fournie, réduction des impacts lors du changement d une application, utilisation de standards, meilleure maîtrise du paramétrage applicatif ; Amélioration de la qualité des données : la mise en œuvre d un EAI favorise (et nécessite ) le développement d un langage commun, de formats pivots et de façon générale une urbanisation du SIH, les développements sont normalisés et industrialisés, les échanges se font au fil de l eau ; Performances technique : gestion simplifiée de la "parallélisation" et de la répartition de charge, haute disponibilité et scalabilité ; Performance métier : donne la possibilité de piloter les processus (Business Process Management), avec possibilité de monitoring en temps réel (Business Activity Management); Ouverture : fourniture de services à des partenaires (réseaux de santé par exemple). Quels que soient les outils retenus, la problématique de fond reste la même, et elle n est pas que technique : définir des interfaces qui seront réutilisables. Sans une véritable gestion de projet et l inscription dans une démarche d urbanisation, de définition de référentiels de données transverses et de formats pivots (voir fiche concept MDM), la mise en place d un EAI ne garantira pas la simplification des échanges. 08/10/08 8/9

3. MISE EN ŒUVRE Un qui souhaite s engager dans une démarche d intégration de logiciels, en mettant en place un EAI, doit s inscrire au préalable dans une véritable démarche d urbanisation de son système d information. Sans quoi l EAI risque de créer plus d inconvénients que d avantages avec un risque de non adéquation avec l organisation mise en place dans l de santé. La mise en œuvre pourra être progressive et l devra mettre en place des outils et procédures permettant de gérer la maintenance des interfaces. L interopérabilité des applications passe de plus part la définition et la mise en œuvre de référentiels transverses. Si l de santé ne dispose pas des compétences et de l expertise nécessaires pour mener à bien ce type de projet, il est envisageable de mutualiser des ressources avec d autres s disposant du même type de solution ou de faire appel à une prestation externe. 08/10/08 9/9