Quand passer sur une architecture ESB ?
Comme on l'a vu ici, les entreprises adoptent de plus en plus de solutions Cloud.
Que ce soit de l'ERP, du CRM, du PIM etc etc.
Le cloud apporte de nombreux avantages, mais aussi de nouveaux défis, notamment en matière d'intégration de données.
L'Enterprise Service Bus (ESB) se présente comme une solution robuste pour simplifier cette intégration et augmenter l'efficacité opérationnelle.
Mais quand est-il vraiment temps de considérer une transition vers l'ESB ?
Damien Albagnac, un architecte Data indépendant, avec une spécialisation en solutions ESB, nous a partagé son avis sur ce sujet.
ESB != ETL
Souvent, les ESN et les éditeurs de logiciels, comme Talend, vantent la simplicité de passer de ETL traditionnel à des solutions de médiation basées sur l'ESB.
Ils prétendent que, pour ceux qui connaissent déjà Talend, la transition vers l'ESB serait "easy". Toutefois, ce discours semble beaucoup trop simpliste.
Bien que les outils puissent être similaires, la philosophie derrière l'ESB est fondamentalement différente et demande une compréhension approfondie des processus d'intégration et de médiation.
Quand investir sur une architecture ESB ?
La question que j'ai posé à Damien, et qu'on m'a posé dans le cadre de ma mission actuelle :
Quand passer sur une architecture ESB ?
Architecture Cloud : Si votre entreprise adopte une architecture cloud, l'utilisation d'un broker de messages devient indispensable pour gérer les communications entre services. L'ESB permet d'orchestrer ces échanges de manière fluide et sécurisée.
Flexibilité et Évolutivité : Lorsque vous avez besoin d'ajouter rapidement de nouvelles sources ou cibles de données, l'ESB fournit la flexibilité nécessaire pour intégrer ces nouvelles composantes sans perturber les systèmes existants.
Gestion des Abonnements et Applications : Dans les environnements où les applications ne sont pas modifiables à volonté, comme les services SaaS pour lesquels vous payez un abonnement, l'ESB permet de personnaliser les interactions sans nécessiter de modifications directes du code source.
Exemple d'Application : Le Broker de Messages
Prenons l'exemple d'une entreprise utilisant un CRM en cloud.
Sans un ESB, chaque mise à jour dans le CRM nécessiterait des ajustements manuels (ou de point à point, comme l'a vu ici) dans d'autres systèmes comme l'ERP ou les plateformes de marketing.
Avec un ESB et un broker de messages, toutes les mises à jour sont automatiquement synchronisées à travers tous les systèmes pertinents.
Le broker de messages agit comme un intermédiaire, stockant les messages et les distribuant à la demande, assurant ainsi que les mises à jour sont distribuées efficacement et à moindre coût.
En conclusion
Dès que la notion de Cloud devient de plus en plus présente dans un SI, le broker va radicalement fluidifier l'intégration de données inter-applicatifs.
Les questions suivantes doivent donc se poser :
- Est-ce que je veux faire du temps réel ?
- Est-ce que j'ai besoin de faire de la synchronisation ?
- Est-ce que j'ai besoin d'utiliser des API entre mes systèmes ?
Pour aller plus loin sur la présentation es concepts (broker de messages, demi-pivots etc), je vous conseille d'écouter Damien en entier ici.
À PROPOS
Le collectif de freelances experts en intégration de données.
Créé avec © systeme.io
