Rechercher
Fermer ce champ de recherche.

Mettre en place une solution ESB (Enterprise Services Bus) comme colonne de votre SI

L’Enterprise Service Bus : le cœur pour orchestrer, simplifier et accélérer les échanges entre vos logiciels et systèmes. Transformez votre SI en un écosystème intégré et réactif. Libérez la synergie de vos applications !

Ce contenu sur l’Enterprise Service Bus fait partie de notre dossier sur l’Intéropérabilité et les flux de données.

L’enjeu de communication inter applicative au cœur des démarches ESB

L’ESB (Enterprise Service Bus) est une solution technologique, aussi nommé outil informatique middleware, qui facilite l’interaction entre les applications et la circulation de l’information dans un écosystème: dans votre système d’information bien sûr, mais également avec celui des fournisseurs, partenaires, clients…

Ce bus applicatif agit comme une colonne d’intégration à travers laquelle les applications interagissent sans contraintes de format ou de temporalité. Il a un rôle de médiation et de communication entre les applications, bases de données, fichiers Excel… C’est ainsi l’outil principal pour mettre en pratique des principes d’urbanisation comme l’architecture orientée Services (SOA) !

Au-delà de sa perception d’outil middleware et donc back-office, l’Enterprise Services Bus participe à apporter des solutions à des usages métiers. En voici quelques exemple pour apporter des illustrations pragmatiques :

  • Intégration du portail de GRU (Gestion de la Relation Usager) avec le reste du Système d’Information
  • Récupération et envoi de données entre le parafeur électronique, la GED, le coffre numérique
  • Alimentation du référentiel matériel dans les collectivités territoriales
  • Orchestration des services internes pour faciliter l’exposition de données au travers d’une démarche d’API Management
  • Transversalité du processus d’entrée/sortie d’un nouvel agent
  • Mise en place de nouveaux indicateurs de pilotage des ressources humaines, grâce à l’alimentation de votre entrepôt depuis différentes sources
  • Lien entre le SIRH et SI finance
  • Agilisation du SI dans un environnement SAP
  • Dématérialisation d’un flux financier
  • Préparation d’une évolution structurelle du SI (migration d’ERP…)

L’Enterprise Service Bus est souvent représenté sous la forme d’un canal central ou d’un bus applicatif, qui se connecte avec les différentes applications et logiciels du système d’information. Si cette représentation est assez classique, elle a le mérite de faire comprendre le concept !

 

Pour être plus précis, c’est la notion de “services” – un service est une unité autonome de fonctionnalité(s) logicielle(s) – qui est au cœur du concept d’ESB, comme le veulent les modèles d’architecture orientée services (SOA). Les applications du Système d’Information vont proposer leurs “services” à l’ESB, qui va les publier dans son registre afin de les mettre à disposition de toutes les applications, qui peuvent s’y abonner. Les applications sont donc à la fois fournisseurs et consommatrices de services.

 

Le second principe clé repose sur la normalisation de la structure d’échange au travers d’un format pivot : les applications cibles n’ont pas besoin de parler le même langage que l’application sources ou de connaître leur format technique, la codification.

L’iPaaS et l’ESB ont le même objectif : l’intégration des systèmes et des logiciels d’entreprise. De notre point de vue, et pour simplifier, l’iPaaS :

  • Est à 75% une solution ESB dans le Cloud, avec tous les avantages que cela apporte : scalabilité, évolutivité horizontale…
  • A 25% présente des bénéfices spécifiques avec la capacité à déporter l’exécution des traitements au plus proche des éléments et à raisonner dans des zones de computing différentes, tout en assurant une supervision consolidée. L’architecture multi-tenant en est un autre. Cela dépasse le simple ESB hébergé donc !

Bénéfices : la circulation de l’information comme fondation d’un SI plus efficient et au service des métiers

Bien entendu, les démarches d’implémentation d’un Enterprise Services Bus ne doivent pas être appréhendées uniquement selon un objectif de transmission de l’information et de circulation des flux. Elles doivent viser à faciliter l’exploitation des données selon les besoins métiers et stratégiques de l’entreprise, et permettre de rationaliser le SI grâce à :

ic-idee-1

L’interopérabilité du Système d’Information et une indépendance plus forte vis à vis des applicatifs

ic-idee-2

La simplification de l’intégration de nouveaux processus et applications (ou leur décommissionnement)

ic-idee-3

L’agilité du Système d’information en limitant les contraintes techniques

ic-idee-4

La diminution du TCO (Total Cost of Ownership)

Comment cadrer, déployer et tirer le maximum de valeur de votre solution d’ESB ?

Ces projets sont l’occasion de rassembler les services métiers et IT autour d’ob­jectifs communs ! Inclure les parties prenantes en amont du projet favorise l’adop­tion et maximise la valeur finale. La convergence des différents points de vue se fait autour de la circulation de l’information dans l’organisation. Sa modélisation révèle le rôle des intervenants humains et permet à chacun de s’accorder sur la vision commune du qui, quoi, comment, quand… Il s’agit donc de :

  • Prendre conscience des processus et des données qui transitent, ce qu’on peut échanger, modéliser, urbaniser, leur criticité…
  • Et ensuite seulement mettre en place une architecture informatique qui permette de mettre en œuvre les flux et d’assainir les données.

 

1er conseil

Bien cadrer votre projet de mise en place d’un ESB

Nous conseillons d’étudier et de prendre du recul sur certains aspects afin de mieux cadrer votre projet et définir vos attentes selon le contexte de votre organisation :

  • La granularité des services. Il faut trouver un juste milieu entre trop atomisés et trop regroupés. Le service doit être facilement réutilisable tout en ne nécessitant pas de reconstruire systématiquement des enchainements de services.
  • Le temps réel. Par défaut, mieux vaut privilégier le temps réel en anticipation : même s’il n’est pas nécessaire maintenant, il pourra le devenir. Cependant, inutile de forcer à tout prix les applications qui n’en sont pas capables !
  • La supervision. Tous les services transverses doivent être normalisés et supervisés. Toute erreur doit être identifiée, avec son contexte, immédiatement.
  • La connaissance de ses flux. Une cartographie approfondie et partagée est la meilleure façon de ne pas oublier d’étape et d’identifier tous les leviers de valeur.
  • L’anticipation. L’urbanisation du SI a pour objectif de renforcer votre agilité. Vous devez pouvoir facilement modifier les sources et les cibles des flux sans développement spécifique.
2ème conseil

Quelles études mener en amont du projet ?

Voici une liste non exhaustive des études à réaliser en amont :
  • La cartographie des flux du point de vue de l’organisation et des métiers et en remettant si nécessaire en cause l’existant !
  • La cartographie du parc applicatif afin de partager une vision globale du SI
  • Pour chaque flux, les indicateurs de volumétrie, de criticité des échanges, de fréquence, et la nécessité ou non du temps réel.
  • Un glossaire pour tous les intervenants du projet afin de partager le même vocabulaire
3ème conseil

Les critères et fonctions clés à intégrer dans son cahier des charges

Voici quelques critères essentiels à intégrer dans sa liste d’exigences :
  • Médiation et routage intelligent : pouvoir dispatcher la bonne donnée au bon endroit
  • Transformation : les messages sont convertis dans un format standard
  • Rétention et persistance : la distribution peut être réalisée en mode synchrone ou asynchrone si l’application cible n’est pas disponible, sans bloquer l’acheminement vers les autres applications
  • Convergence : plusieurs sources peuvent aller au même endroit
  • Supervision : une vision consolidée des flux et de leur bon déroulement
  • Enrichissement : capacité d’enrichir les messages au travers de circuits de distribution intermédiaires MDM (Référentiel de données)
De plus, les matrices d’exigences au sein des cahiers des charges des plateformes d’intégration de données prennent généralement au moins en compte ces catégories : Connectique, Protocole d’échanges et déclencheurs, Transformation, Médiation et routage, Supervision et monitoring, Sécurité, Ouverture et exposition de services, Ergonomie et grands principes, Hébergement, Plateforme Technique, Architecture, Modèle de tarification, Planning & Projet.

Choisissez notre Module Data Foundation pour soutenir votre démarche d’Enterprise services Bus et votre stratégie d’urbanisation !

Le module Data Foundation de notre plateforme Phoenix est une solution ESB (nommée Viaduc  dans notre gamme Blueway Secteur Public) permettant de mettre en place les meilleures pratiques SOA (Service-Oriented Architecture). D’ailleurs, c’est parce que nous sommes convaincus du rôle fondamental du traitement, du transport, de la manipulation et du contrôle de la donnée que ce socle s’appelle “Data Foundation” ! Ce socle intègre toutes les fonctionnalités évoquées précédemment et apporte également des atouts pour accélérer vos projets et renforcer votre autonomie.

 

Nos atouts pour la mise en place de votre stratégie d’urbanisation

Low-code et intuitif

Data Foundation vous permet de traiter « à la souris », au sein d’une interface graphique dédiée, l’ensemble de vos services entre applications. De plus, notre solution est accessible en mode client léger et tout peut être réalisé au travers d’un navigateur.

Console de supervision

Vous avez tous les éléments de monitoring au même endroit. Plus besoin de naviguer entre différentes interfaces pour diagnostiquer un problème et mettre en place les traitements associés.

Outils d’industrialisation

Vous maîtrisez mieux la multiplicité des environnements. Les chaînes de connexion s’adaptent à l’environnement : vos équipes peuvent directement dans la plateforme faire un développement et le déployer en production par un simple bouton. Les modifications, passages en production… sont bien sûrs tracés.

Bibliothèque de contextes et pré paramétrage

Vous accélérez le démarrage de vos projets en capitalisant sur une bibliothèque d’exemples de processus techniques et fonctionnels ainsi que de référentiels.

Complémentarité ESB et ETL

Vous répondez globalement à l’enjeu de circulation des données dans le SI. Selon nous, c’est aux outils de converger pour s’adapter au métier et non l’inverse !

Une plateforme de données : phoenix de Blueway
ESB & BPM
  • Automatiser les processus avec la vision ESB, c’est se concentrer sur la vision technique.
    Intégrer de l’humain au cœur des processus implique d’ouvrir la porte au BPM (Business Process Management) !
  • L’association des deux solutions garantit que les processus métiers soient adhérents au Système d’Information et que les humains soient acteurs à part entière de la chaîne (IHM, capacité d’actions, séquencement métier, gestion des rôles…).
ESB & MDM
  • Si vous décloisonnez l’information grâce à l’ESB, vous avez intérêt à centraliser et mettre en qualité les données transversales dans un référentiel unique qui sera mis à profit du reste du Système d’information. D’un point de vue de la gouvernance des données, cela repose sur un MDM (Master Data Management).
ESB & APIM
  • Vous êtes satisfait de la standardisation des échanges apportés par l’ESB ? Il est alors temps de renforcer les interactions avec vos partenaires externes ! Face à la multiplication des contrats d’interfaces, l’API Management vous assure de gouverner les échanges avec l’extérieur et d’industrialiser l’exposition de vos APIs (Application Programming Interface)
ESB & Data Catalog
  • Pour intégrer et faire circuler vos données, encore faut-il connaître et maîtriser son patrimoine de données ! MyDataCatalogue vous permet de Cartographier et cataloguer toutes les données présentes au sein de votre organisation.

… et au-delà, mettez à profit la complémentarité ESB, BPM, MDM, APIM et Data Catalogue avec la plateforme Phoenix

Chez Blueway, nous sommes persuadés que, pour chaque besoin métier, il faut avoir une vision globale et partagée des processus et des données, et donc des différentes dimensions de la gouvernance de données.

C’est pour cela que nous avons bâti notre Data Platform Phoenix sur la réunification des usages des BPM, MDM, ESB, API Management, cartographie des données, autour de vos enjeux métiers et humains.

Vous souhaitez échanger sur vos enjeux d’interopérabilité et d’urbanisation ?

Prenez rendez-vous dès maintenant pour un échange ou une démo !

Nos prises de parole autour de l’Enterprise Service Bus

Notre FAQ autour de l’Enterprise Services Bus

Les deux approches ESB et APIM sont complémentaires : l’ESB se positionne comme l’orchestrateur des services de votre Système d’Information et l’APIM sur la gouvernance des échanges avec l’extérieur (piloter l’accès et l’utilisation des APIs, contrôler l’usage, standardiser les API pour assurer leur scalabilité…).

Les périmètres de l’ETL (Extract-transform-load) et l’ESB se recouvrent partiellement. 

Historiquement, on considère que l’ETL est capable de traiter des volumétries de données très fortes, pour un nombre limité d’échanges et que l’ESB sera plus adapté pour piloter des échanges avec une fréquence élevée, mais une volumétrie de données plus restreinte.

Notre conviction, c’est que ce cloisonnement ESB vs ETL n’est plus pertinent aujourd’hui :  la solution technique doit s’adapter aux enjeux métiers et sortir de ces visions conceptuelles.

On ne se place pas au même niveau sur ces deux notions : l’ESB est un outil d’intégration alors que les microservices sont des petits composants de services qui peuvent se combiner pour créer une application.

Les architectures microservices sont ainsi composées de plein de services spécialisés utilisés pour construire les fonctionnalités des applications. Ces architectures permettent un développement plus agile et d’ajouter facilement des nouvelles fonctionnalités. La granularité est plus fine mais engendre également plus de complexité.