Résumer cet article avec l'IA
Table des matières

Nouveau
guide disponible

Retour d’expérience et clés d’arbitrage entre ETL et iPaaS

évolution des besoins et coexistence des modèles d’intégration

Faire évoluer une plateforme d’intégration lorsqu’elle supporte plusieurs centaines de flux est un enjeu à la fois technique et architectural.

C’est dans ce contexte que plus de 300 flux hébergés sur une solution ETL historique doivent être progressivement migrés vers une plateforme iPaaS Cloud. Le parc existant regroupe des traitements de nature différente : des flux batch exécutés à fréquence régulière (quotidiennement ou toutes les heures) et des flux temps réel, déclenchés à la réception d’un appel d’API ou d’un message.

Cette coexistence est importante pour comprendre les choix effectués lors de la migration. Tous les flux ne répondent pas aux mêmes contraintes et nécessitent des  mécanismes techniques différents.

Talend et Boomi proposent deux approches différentes de l’intégration.

Talend s’inscrit historiquement dans une logique ETL, particulièrement adaptée à la manipulation et à la transformation de données structurées.

Boomi adopte une approche iPaaS, avec une plateforme accessible depuis le Web et orientée vers l’interconnexion des applications, les échanges de documents et les flux temps réel.

L’objectif est ainsi d’identifier les principaux écarts entre les deux environnements et de comprendre dans quels cas certaines approches sont plus adaptées que d’autres.

Modèle économique & architecture : deux visions complémentaires

Un modèle de facturation différent

La première différence concerne le modèle économique.

  • Talend fonctionne avec une logique de licences, qui prend en compte les utilisateurs/développeurs disposant d’un accès à la plateforme.
  • Boomi repose sur une logique de connecteurs et de capacités d’intégration.

Chaque système avec lequel une communication doit être établie peut nécessiter le connecteur adapté. La connexion à une base data constitue par exemple un élément à prendre en compte dans le dimensionnement de la plateforme.

Ces deux modèles impliquent donc des critères de coût différents.

Dans un environnement comportant un nombre important de développeurs, la logique de licences peut être déterminante. À l’inverse, dans un système d’information composé d’un grand nombre d’applications et de services à interconnecter, le nombre et la nature des connecteurs deviennent des paramètres importants.

Le choix doit être réalisé en fonction du paysage applicatif et des usages prévus, plutôt qu’à partir du seul coût d’une licence ou d’un connecteur.

Studio local et plateforme Web

L’environnement de travail constitue une autre différence structurante.

Talend s’appuie sur un Studio installé localement, ce qui fournit un environnement de développement particulièrement adapté aux traitements ETL complexes.

Boomi adopte une approche différente : la plateforme est accessible directement depuis le Web et aucun client « lourd » n’est nécessaire pour développer les processus.

Cette architecture apporte une certaine simplicité dans la gestion de l’environnement de développement. L’accès étant centralisé, aucune installation spécifique du Studio n’est nécessaire sur le poste du développeur.

L’interface Web de Boomi offre une simplicité d’accès, tandis que le Studio local de Talend constitue un environnement de développement dédié et robuste, offrant un contrôle total et une grande puissance de calcul, idéale pour concevoir des pipelines de données complexes.

Ces différences ne permettent toutefois pas de conclure qu’un modèle est systématiquement supérieur à l’autre.

Le Studio local peut répondre à des besoins de développement complexes, tandis que la plateforme Web est particulièrement adaptée lorsqu’une accessibilité et une centralisation importantes sont recherchées.

Gestion des environnements

Les deux plateformes proposent des mécanismes permettant de gérer les différences de configuration entre les environnements :

  • Talend s’appuie sur les variables de contexte.
  • Boomi utilise les Process Properties et les Extensions.

Dans Boomi, les propriétés utilisées par un processus peuvent être définies puis étendues pour chaque environnement. Les valeurs peuvent ainsi être différentes entre le développement, l’intégration et la production sans modifier le processus lui-même.

Talend propose également des mécanismes de gestion des connexions et des contextes. Dans l’environnement considéré, la configuration des extensions Boomi a toutefois été jugée plus simple à administrer, notamment pour faire varier les paramètres selon les environnements.

Traitement de la donnée & expérience développeur

Deux modèles de représentation des données

La différence entre les deux plateformes devient visible dans la manière dont les données circulent dans les processus :

Talend s’appuie sur une représentation tabulaire (lignes et colonnes). Ce modèle demeure la référence en matière de performance pour le traitement de volumes massifs et les transformations structurées complexes.

Sur Boomi, les données sont manipulées sous forme de documents correspondant à différents formats (XML,JSON). Des Profiles permettent de définir la structure de ces documents et de les utiliser dans les étapes du processus.

Cette approche se prête aux échanges entre applications, aux API et aux messages.

La différence est donc moins une opposition entre deux technologies qu’un changement de modèle mental : les data sont traitées comme des ensembles tabulaires dans un cas et comme des documents circulant dans un processus dans l’autre.

Ajouter du contexte avec les propriétés de document

Boomi permet d’associer des Dynamic Document Properties aux documents qui traversent le processus.

Ces propriétés permettent d’ajouter du contexte sans modifier nécessairement le contenu ou la structure du document.

Par exemple, une propriété peut être utilisée pour catégoriser un document, déterminer une destination ou fournir une information qui sera exploitée par une étape ultérieure.

Les composants peuvent ensuite récupérer cette valeur afin d’effectuer une condition ou d’orienter le document vers une branche particulière, évitant de modifier la structure des données uniquement pour transporter des informations techniques utiles au traitement.

Dans un modèle en colonnes, l’ajout d’une information impose une nouvelle colonne. Avec les propriétés du document, elle est conservée hors du schéma initial.

Une expérience de développement différente

Les deux plateformes reposent sur une construction graphique des flux :

  • Boomi et son interface Web permettent de subdiviser les processus et de regrouper les éléments nécessaires à leur fonctionnement.
  • Talend offre un environnement de développement plus complet, avec un grand nombre de composants et de configurations.

Supervision des processus

Boomi propose le Process Reporting, qui permet de consulter les exécutions des processus et leur état, de suivre les traitements et d’identifier rapidement les erreurs.

Talend dispose également d’une console Web permettant de suivre l’exécution des flux. Les deux plateformes proposent donc des capacités de supervision, avec des interfaces et des expériences d’utilisation différentes.

Cas d’usage complexes et flexibilité : la complémentarité des outils

Les transformations avancées

La migration fait apparaître certaines différences de couverture fonctionnelle. En effet, Talend dispose de composants dédiés à des opérations avancées sur les données, notamment tNormalize et tDenormalize.

Ces composants permettent de réaliser des opérations de normalisation et de dénormalisation directement dans le flux.

Boomi propose de son côté le composant Data Process, qui couvre de nombreux traitements sur les documents.

Il peut notamment être utilisé pour combiner ou séparer des documents, effectuer certaines transformations de contenu, gérer du Base64, compresser ou décompresser des données, ou encore rechercher et remplacer des valeurs.

Certaines opérations plus spécifiques, notamment celles liées à la normalisation et à la dénormalisation, ne sont cependant pas disponibles de manière aussi directe dans le Data Process.

Cela constitue un point de vigilance lors d’une migration : un composant Talend peut parfois correspondre à plusieurs éléments dans Boomi, voire nécessiter une implémentation spécifique.

Le scripting pour compléter les fonctionnalités natives

Lorsque les composants standards ne permettent pas de répondre au besoin, du code peut être intégré dans les processus Boomi, comme le Groovy pour développer des traitements spécifiques. Permettant ainsi de reproduire des fonctionnalités qui ne disposent pas d’équivalent natif dans la plateforme.

Talend s’appuie de son côté sur Java pour les développements spécifiques.

La différence tient surtout à la manière dont le code est intégré.

Le mapping : un arbitrage entre simplicité et personnalisation

Dans Boomi, le mapping s’appuie sur des profils visuels lisibles et rapides à configurer, mais toute transformation spécifique impose la création d’une fonction dédiée. À l’inverse, Talend autorise l’injection directe de code dans le mapping pour traiter la logique ponctuelle ou complexe.

Lors d’une migration de Talend vers Boomi, une règle métier intégrée directement dans Talend devra être réisolée dans une fonction spécifique. L’effort de migration d’un flux complexe ne se mesure donc pas au nombre de composants graphiques, mais au volume de logique personnalisée qu’il contient.

Cartographier avant de migrer

Avant de lancer une migration de plusieurs centaines de flux, une cartographie détaillée doit être réalisée.

Pour chaque flux, il est nécessaire d’identifier :

  • son volume de données ;
  • sa fréquence d’exécution ;
  • son caractère batch ou temps réel ;
  • ses sources et ses cibles ;
  • les transformations utilisées ;
  • les composants spécifiques mis en œuvre ;
  • les dépendances avec les autres flux ;
  • les fonctionnalités qui pourront être reprises nativement ;
  • celles qui nécessiteront une adaptation ou du scripting.

Cette étape permet d’éviter une approche de migration basée uniquement sur une correspondance « composant Talend → composant Boomi ».

Certains flux pourront être transposés relativement simplement. D’autres nécessiteront une adaptation de leur architecture ou de leur logique de traitement.

Conclusion : les clés pour réussir son projet d’intégration

Le choix entre Talend et Boomi dépend avant tout du contexte dans lequel vous devez utiliser la plateforme, avec en premier critère le type de flux, ainsi que le paysage applicatif.

Les traitements ETL fortement orientés data peuvent tirer parti des fonctionnalités proposées par Talend. Les flux d’intégration orientés API, messages et échanges entre applications peuvent quant à eux bénéficier de l’approche documentaire et de l’environnement iPaaS proposés par Boomi.

La proportion de systèmes Cloud et On-Premise, le nombre d’applications à connecter, les technologies utilisées et les contraintes d’architecture doivent être intégrés à la réflexion.

Au-delà des aspects techniques, le coût global dépend du modèle économique de chaque solution, influencé par le nombre de développeurs, les connecteurs requis et l’évolution de l’infrastructure.

Le bon arbitrage consiste à choisir l’approche la plus adaptée au paysage applicatif, aux types de flux et aux objectifs d’évolution de votre entreprise.

Un projet de migration ETL vers iPaaS en perspective ?

Quelle est la principale différence entre une approche ETL et iPaaS ?


Talend repose sur une logique ETL axée sur la manipulation de volumes importants de données structurées et tabulaires sous forme de lignes et de colonnes. À l’inverse, Boomi adopte une approche iPaaS centrée sur la circulation de documents, l’interconnexion d’applications en temps réel et la gestion des flux d’API via une plateforme Web accessible sans installation locale.

Pourquoi le nombre de flux ne suffit-il pas pour évaluer l’effort de la migration ?


L’effort de migration dépend principalement de la complexité de la logique métier personnalisée intégrée dans vos flux existants. Alors que Talend autorise l’injection directe de code dans le mapping, Boomi nécessite d’isoler chaque règle spécifique dans une fonction dédiée, ce qui demande une réarchitecture de certaines étapes de traitement.

Comment choisir entre une facturation par licence ou connecteur ?


Le choix du modèle économique dépend de la structure de votre système d’information et de vos équipes. Un modèle par licence s’avère plus avantageux si vous avez un nombre limité d’applications mais de nombreux développeurs, tandis qu’un modèle par connecteur est à privilégier pour interconnecter une grande diversité d’applications avec des équipes de développement restreintes.

Victor Faure

Victor Faure

Jeune consultant data, Victor a su démontrer au travers de ses missions sa capacité à monter en compétence sur des solutions techniques telles que Talend mais également à s’approprier les enjeux de l’interopérabilité.
Facebook
LinkedIn
Reddit
Email