Comment entreprendre la modernisation de son SI avec un ESB ?

La modernisation du système d’information est un défi stratégique important pour toute entreprise voulant le relever. Pour y parvenir, l’adoption d’une architecture orientée service (SOA) avec un Enterprise Service Bus (ESB) semble constituer une solution plus qu’intéressante. De l’évaluation des besoins à la mise en place progressive, découvrez les étapes clés nécessaires à une migration de vos données vers une architecture agile. Une architecture dont l’ESB constitue le cœur, offrant une vision intégrée et simplifiée du système d’information.

Le rôle crucial de l’ESB

La mise en place d’un middleware de type ESB permet de faciliter l’échange de données entre les applications du système d’information. Mais également de traiter des échanges en dehors de celui-ci (fournisseurs, clients, partenaires…).

Opter pour un ESB, c’est opter pour la mise en place un outil central d’unification des applications avec une architecture orientée service (ou SOA). Ce type d’architecture sur les flux de données de votre SI se base sur la mise en place de composants d’échanges – les services – réutilisables. Ils permettent ainsi, à la différence d’une architecture point à point, où chaque interface est (re)développée pour chaque application de façon spécifique, de rationaliser le nombre de flux et de simplifier la maintenance et la mise à jour des applications.

Un exemple concret de service très simple sur un flux de synchronisation client à sens unique d’un ERP vers un outil de CRM et un outil e-commerce.

Avec un ESB :

• L’ERP utilise le service “Synchronisation client” pour mettre à jour les informations client à chaque modification sur sa fiche ou nouvelle commande – si le service partage par exemple un champ “date de dernière commande”.
• Le CRM et l’e-commerce s’appuient sur ce service pour enrichir leurs profils et informations client avec les données provenant de l’ERP dont ils ont besoin.

Une cohérence des données

On obtient alors une cohérence des données sur tous les systèmes, l’ajout ou la modification d’attributs sera géré sur le service sans impacter individuellement chaque application.

Avec une architecture sans ESB, – point à point – le processus correspondrait plutôt à :

• Un flux de données de l’ERP vers l’outil CRM via une interface directe listant chaque champ spécifique à destination du CRM. Sur un format spécifique à l’interface.
• Un flux de données de l’ERP vers l’outil e-commerce via une interface directe listant de nouveau chaque champ spécifique à destination de l’e-commerce. Sur un format spécifique à l’interface.

Avec cet exemple simple, on constate une certaine complexité dans l’échange de données avec non pas un unique service issu de l’ERP mais bien deux interfaces à maintenir de manière spécifique. Plusieurs difficultés subsistent alors :

• Chaque interface gère sa propre fréquence de synchronisation – pouvant entraîner des incohérences entre les données des applications.
• Le code est redondant – et donc plus complexe à maintenir.
• Tout changement côté ERP a un double impact – augmentant ainsi le risque d’erreur.
• Enfin, il n’y a pas de vue centralisée permettant de surveiller les échanges de données.

Après avoir illustré les avantages de l’ESB grâce à cet exemple simplifié d’interface, voyons par quelles étapes passe la mise en place d’un ESB.

Les étapes de migration vers un ESB

Évaluer / cartographier l’existant

La première étape consiste à lister toutes les interfaces existantes au sein de votre SI, celles que vous devez conserver, celles qui n’auront plus lieu d’être demain et celles qui doivent être créées.

Afin d’avoir une vue exhaustive des flux, il est nécessaire de cartographier les briques applicatives qui composent votre SI :

• De la finance, au RH, aux ventes et à la logistique, identifier toutes les applications existantes dans le SI.
• Quelles interactions de données existent entre ces applications ? Comment et par qui sont traités ces échanges actuellement (APIs, fichiers…) ?
• Quelle application est maître de quelles données ?
• Qui sont les responsables fonctionnels et techniques de chaque application – voire interface ?
• Existe-t-il des points de frictions sur les échanges existants – cohérence, fiabilité…?

Lors de cette phase, il conviendra d’établir une analyse en considérant à la fois les besoins des équipes techniques et les besoins des équipes métiers afin de bien comprendre l’actuel et le futur du SI. Il sera alors utile, dès cette phase, de définir les priorités globales en fonction des besoins de chacun. C’est à ce moment qu’il faut prioriser les urgences entre par exemple le décommissionnement d’interfaces obsolètes – pouvant constituer des failles de sécurité – ou l’alimentation de nouvelles briques du SI en vue du déploiement d’une stratégie business.

Définir l’architecture et les interfaces

Après avoir cartographié l’existant, vous avez une vision globale qui devrait vous permettre d’avoir une vision de l’architecture finale que vous allez pouvoir mettre en place, en ayant notamment une vision des connexions de données et les services qui seront réutilisables d’une interface à l’autre.

Vous allez alors pouvoir débuter selon vos priorités par la définition détaillée des interfaces d’un premier lot à déployer. En fonction de votre contexte, les lots sont généralement découpés par axe métier ou par application cible.

Pour chaque interface, vous allez devoir :

• Lister les champs attendus par la cible et le format.
• Lister les champs en entrée, leurs différentes sources et formats.
• Définir les éventuels mappings et transformations à apporter.
• Détailler, le cas échéant, le format des fichiers sources et cibles et/ou les appels APIs et/ou les requêtes en base de données à mettre en place.
• Définir les fréquences de mise à jour ou les déclencheurs des flux.
• Lister les différents cas d’erreurs techniques ou fonctionnelles pouvant se produire et la procédure à mettre en place le cas échéant – valeurs par défaut, rejeux, alertes mails (à qui?), etc.).
• Spécifier les cas et les scénarios de rejeux des flux en cas d’erreur.
• Se questionner sur le positionnement de l’interface au sein de l’architecture globale du bus applicatif.

La mise en place progressive

Vous l’aurez compris, nous préconisons un déploiement de l’ESB par lot de services – interfaces – en fonction de vos priorités. Cela vous permettra de réaliser les tests d’intégration sur des jeux de données maîtrisés au fur et à mesure… Et de décomisionner les flux existants les uns après les autres.

Si la phase de cartographie a été menée avec précision et sur l’ensemble du SI, vous devriez désormais être capable de mesurer l’impact de chaque migration d’interfaces une à une. Et ainsi de jongler avec l’ordonnancement le plus pertinent.

Et après ?

Une architecture SOA vit quotidiennement et demande une supervision facilitée par les outils du marché. L’ESB deviendra petit à petit central. Et aucune application n’intègrera votre SI demain sans que vous vous posiez la question de sa synchronisation avec les messages existants au sein de votre bus. Une fois vos intégrations de données prise en charge avec succès via l’ESB, vous pourrez poursuivre la modernisation de votre SI… Tout en assurant la gouvernance et la qualité de vos données avec une synergie entre ESB et MDM (Master Data Management).

Vous voulez entreprendre la modernisation de votre SI avec un ESB ? Contactez nos experts !

Je prends contact