L’Industrie 4.0 et l'Internet des Objets offrent de nouvelles possibilités de digitalisation qui sont également à la portée des PME. Il est important pour elles d’y avoir recours et une première étape pourrait consister à intégrer entre elles les applications d’entreprise existantes, acquérant ainsi les connaissances nécessaires dans ce domaine.
Les nouvelles possibilités de digitalisation ne cessent de gagner en importance, y compris pour les PME qui, à défaut de prendre le train en marche, auront laissé passer leur chance d’intégrer la ‘supply chain’, perdant des parts de marché au passage. Dans un premier temps, il est de la plus haute importance d’intégrer entre elles les applications d’entreprise existantes, en utilisant les techniques modernes de 'Enterprise Application Integration' (EAI). Quelles sont ces possibilités et à quoi faut-il s’attendre à l’avenir ?
Vue d'ensemble
Aujourd’hui, il est clair qu’un seul ‘backbone’ d’intégration n’est plus suffisant en cette ère d’intégration. Les architectures d’intégration d’applications possibles sont les suivantes :
Plate-forme hybride pour les services de base et périphériques
Le terme ‘plate-forme d’intégration hybride’ (‘Hybrid Integration Platform’ - HIP) décrit différentes composantes d’une architecture d’intégration moderne. Le recours à une architecture d’intégration hybride bien conçue permet aux différentes parties prenantes d’une entreprise de réagir rapidement à de nouvelles exigences. Les processus métiers critiques (ou ‘core services’) restent gérés par un département informatique central. De ces services dépend le fonctionnement de l’entreprise, et ils changent assez rarement.
Par ailleurs, une architecture d’intégration hybride est nécessaire en tant qu’unité opérationnelle pour tester rapidement et de manière flexible (‘agile’) de nouveaux processus métier ou pour adapter les processus existants, sans avoir à utiliser les règles et processus du département IT central, qui peuvent avoir un effet de ralentissement. L’innovation par le biais d’une stratégie ‘fail-fast’ et la création de ‘services périphériques’ (‘edge services’) gagnent sans cesse en importance pour améliorer ou ébranler les modèles économiques existants et ainsi modifier les activités économiques.
Intégration d’applications à l’aide d’un ‘enterprise service bus’ (ESB)
Les ESB sont généralement utilisés dans les projets informatiques de plus grande envergure où des processus métier critiques doivent être intégrés, caractérisés par un besoin élevé de disponibilité, de fiabilité et de performance au sein de l’entreprise (‘core services’). Ce n’est pas sans effet sur plusieurs technologies et applications qui permettent d’intégrer dans le cloud des logiciels standard, des systèmes en place, des applications personnalisées ou des services externes.
Des spécialistes de l’intégration implémentent des clusters ESB pour améliorer les performances, la disponibilité, la tolérance aux erreurs et garantir la livraison de transactions. La plus grande partie de l’intégration se fait en interne dans un datacenter privé. Vous pouvez utiliser le cloud, mais il est alors davantage question d’introduction et d’exploitation avec une couche de cloud par-dessus (‘cloud-washed’) que de ‘cloud native’ : une application existante est simplement déployée dans le cloud. Cela se justifie par exemple dans des situations de test ou pour utiliser des capacités IaaS (infrastructure-as-a-service) sans utiliser de fonctionnalités cloud-native.
Un ESB comprend des produits tels que MuleSoft Anypoint Platform, Talend ESB, WSO2 ESB, TIBCO ActiveMatrix BusinessWorks ou Oracle Service Bus. Une solution alternative basée sur le code pur est l’utilisation d’un cadre d’intégration open-source, comme Apache Camel ou Spring Integration.
Intégration d’applications cloud-native
L’intégration dans un environnement cloud-native est très différente de l’approche traditionnelle de l’intégration d’applications. Typiquement, Cloud Foundry, Kubernetes, OpenShift ou Apache Mesos sont des platforms-as-a-service (PaaS). Les applications créées au moyen de ces outils cloud-native d’intégration d’applications sont de nature variable au sein de ces environnements PaaS et profitent ainsi des fonctionnalités offertes par ces plates-formes, dont la mise à disposition d’infrastructures, la découverte de services, le load balancing, l’élasticité, le cluster management ou fail-over, et ce, out-of-the-box. Cela permet également un développement plus agile pour implémenter, incorporer et faire évoluer rapidement et efficacement de nouvelles fonctionnalités ou innovations.
Pour ce faire, le développement et l’architecture des applications doivent être adaptés aux concepts cloud-native. Il s’agit principalement d’appliquer des concepts en suivant les principes de la méthodologie de la ‘Twelve-Factor App’, qui recommande des meilleures pratiques pour les applications cloud-native, telles que les stateless services, l’automatisation via DevOps ou les services de support indépendants des environnements. Des conteneurs indépendants sont souvent mis à contribution (Docker, CoreOS ou Cloud Foundry’s Warden) pour construire des applications ou des micro-services cloud-native.
L’équipe informatique de base applique ces plates-formes PaaS, mais elle le fait pour accroître l’agilité de tous les développeurs afin que les équipes d’intégration traditionnelles et les développeurs du secteur puissent bénéficier de ces plates-formes et des capacités des technologies d’intégration.
Le champ d’application des PaaS est très large : en interne, dans le cloud public ou comme implémentations hybrides. Cependant, de nombreuses entreprises ne disposent pas encore d’une stratégie complète à long terme pour les architectures d’implémentation dans le cloud ou hybrides. Il est donc important de développer des services d’intégration neutres, qui peuvent être déplacés d’une plate-forme à l’autre sans grand effort ni redéveloppement.
Le middleware devrait également prendre en charge et intégrer des cadres open-source matures pour les environnements cloud-native, tels que Spring Cloud Configuration, Consul, Eureka de Netflix ou Hystrix, au lieu d’ajouter de la complexité.
TIBCO BusinessWorks Container Edition et WSO2 sont des exemples de middleware d’intégration neutres qui prennent en charge diverses plates-formes PaaS et conteneurs, comme Cloud Foundry, Docker, Kubernetes et AWS ECS. JBoss Middleware Services permet l’implémentation de ses applications « middleware» dans OpenShift.
Integration platform-as-a-service (IPaaS)
Le middleware pour l’intégration dans le cloud iPaaS est proposé sous la forme d’un cloud purement public hébergé par un fournisseur spécifique. L’utilisation d’iPaaS permet à l’industrie de répondre rapidement à de nouvelles exigences ou à des idées novatrices sans avoir à se soucier de l’équipe informatique centrale et de ses longs processus de gestion des versions et de la qualité. Les iPaaS peuvent être utilisés pour des processus de base critiques, ainsi que pour des services périphériques innovants.
Le fournisseur offre des fonctionnalités cloud-native, telles que l’infrastructure, l’élasticité et le multi-tenant (1 application dessert plusieurs utilisateurs). Il doit s’agir d’un véritable runtime cloud-native au niveau de l’entreprise, et pas seulement d’une offre avec une couche de cloud par-dessus. Dans le cas contraire, il n’est pas possible de développer rapidement et facilement les services d’intégration tout en répondant aux exigences élevées de stabilité et de résilience qui leur sont imposées.
Le public cible des iPaaS n’est pas nécessairement le spécialiste de l’intégration ayant une vaste expérience technique. Les iPaaS permettent également à des collaborateurs moins expérimentés (‘intégrateurs ad hoc’) de définir, implémenter et contrôler des services et API ayant une politique correspondante. Les intégrateurs ad hoc n’utilisent généralement pas le puissant environnement de développement intégré, mais une interface utilisateur conviviale sur Internet.
Les iPaaS doivent bien fonctionner avec d’autres solutions d’intégration. L’interopérabilité des différentes solutions d’intégration dépend du fournisseur. Il est conseillé de vérifier si le redéveloppement de services existants est nécessaire, si des modifications peuvent être ajoutées via une interface utilisateur sur Internet et si différents produits cohabitent (support commercial inclus).
Aujourd’hui, le marché des iPaaS n’a fait qu’entamer sa croissance. Quelques exemples : Dell Boomi, Informatica Cloud, MuleSoft Anypoint Platform, SnapLogic, Jitterbit et TIBCO Cloud Integration.
Integration software-as-a-service (iSaaS)
Les intégrations avec iSaaS sont utilisées pour les services périphériques (‘edge services’), qui ne sont pas stratégiques ou critiques pour l’entreprise, mais très pertinents pour l’utilisateur professionnel spécifique. Par exemple, un tel utilisateur crée un flux automatique quotidien pour synchroniser des données, éliminant ainsi la nécessité d’intégrer ces mises à jour manuellement sur une base journalière.
Les iSaaS sont hébergés et pilotés par le fournisseur. Contrairement aux composants ci-dessus, les iSaaS se concentrent sur les utilisateurs professionnels (‘citizen integrators’). Ils peuvent créer des flux d’intégration élémentaires qui répondent aux besoins personnels ou des départements dans une interface utilisateur très intuitive sur Internet, sans aucune connaissance technique.
Exemples de solutions iSaaS : SnapLogic, TIBCO Simplr et IFTTT (If This Then That).
Passerelle d’intégration IoT
L’Internet des Objets (IoT) modifie le rôle de l’intégration périphérique. Il apporte avec lui nombre de nouveaux défis qui ne sont pas pertinents pour l’intégration d’applications classique, tels que la faible bande passante et le manque de fiabilité de la connectivité.
Dans ce cas, il est nécessaire d’intégrer les données directement sur les périphériques, car toutes les données ne doivent pas être envoyées au centre de données privé ou au cloud public. Par exemple, les données des capteurs d’une ligne de production peuvent être collectées et filtrées, après quoi seules les informations pertinentes (telles que les alarmes) sont envoyées à des interfaces externes. Une passerelle d’intégration IoT relie tous les appareils entre eux via différents standards spécifiques à l’Internet des Objets, comme MQTT, CoAP, WebSockets, Bluetooth ou RFID.
Les spécialistes de l’intégration utilisent une passerelle d’intégration IoT afin de réaliser l’intégration périphérique sur l’Internet des Objets. Le développement peut se faire par cryptage ou au moyen d’une interface utilisateur intuitive sur Internet et d’une connectivité prête à l’emploi, conformément à divers standards spécifiques à l’Internet des Objets.
Il existe des passerelles matérielles chez des fournisseurs tels qu’Intel, ARM et Eurotech ou des cadres open-source pour passerelles d’intégration IoT, tels que NodeRED d’IBM ou Flogo de TIBCO.
API management
Nous évoluons vers une économie d’API ouverte, dans laquelle les services tels que les API sont appliqués à d’autres départements internes, partenaires et développeurs publics. On peut par exemple citer PayPal, dont l’API est intégrée dans presque toutes les boutiques en ligne comme option de paiement, ou Google Maps, dont l’API est utilisée par presque tous les sites web qui fournissent des itinéraires.
Le public cible est le secteur qui utilise des portails API pour créer de nouveaux produits numériques qui augmentent les revenus et répondent aux besoins des clients. Une des clés du succès d’une architecture d’intégration hybride est une bonne collaboration entre la gestion des API et les différentes solutions d’intégration. Cela permet aux développeurs de réutiliser des services pour se concentrer sur de nouvelles fonctionnalités, un délai de mise sur le marché plus court et l’innovation, plutôt que de recréer des services existants.
Exemples de solutions de gestion des API : Apigee, Akana, Mashery et 3scale. Parfois, une passerelle API matérielle telle qu’IBM DataPower Gateway est utilisée pour remplacer ou compléter la passerelle API logicielle.
Nécessité d’une architecture d’intégration hybride
Une plate-forme d’intégration unique ne suffit donc plus à l’ère du cloud, du mobile, des big data et de l’IoT. Faire la différence entre les services de base, destinés à maintenir les opérations en cours, et les services périphériques, destinés à changer les opérations, constitue une étape importante vers une plate-forme d’intégration hybride. Le développement et l’implémentation en interne (‘on-premise’) par opposition au développement et à l’implémentation dans le cloud constituent un deuxième aspect important.
Nouvelles fonctionnalités et tendances en matière d’intégration libre-service
L’automatisation de plus en plus largement appliquée garantit que l’approche libre-service est de plus en plus largement acceptée dans divers domaines informatiques. De nouvelles exigences en matière d’outils d’intégration de données et d’applications émergent, l’approche du libre-service se retrouvant aussi bien du côté informatique que non informatique. Parmi les utilisateurs de l’industrie, les deux exigent un nouvel ensemble de compétences en intégration.
Développement de l’intégration en libre-service dans les technologies de l’information
La demande d’intégration de données en libre-service, incluant tous les aspects de la préparation (visualisation, exploration et même monitoring), n’est pas vraiment nouvelle et a déjà été reconnue par de nombreux spécialistes en intégration. En conséquence, les outils d’intégration de données et d’applications sont devenus plus conviviaux et offrent davantage de fonctionnalités pour gérer le chargement, la transformation et le traitement en tant que tel des données, ainsi que les corrections d’erreur sans aide extérieure. Cela revient au concept de ‘integration platform as-a-service’ (iPaaS).
Aujourd’hui, la norme de l’industrie est que les fournisseurs iPaaS offrent ou adaptent des connecteurs préconfigurés pour différents systèmes, sur site et dans le cloud, par exemple pour les ERP tels que Dynamics Navision ou SAP ByDesign, ou pour les CRM tels que Sugar ou Salesforce. Il n’est pas rare que les adaptateurs d’intégration prévus manquent d’une certaine logique métier ; après tout, il s’agit souvent de connecteurs standardisés qui, par définition, ne peuvent absolument pas couvrir tous les scénarios d’intégration de données.
Il est bien sûr possible de commander un adaptateur personnalisé auprès d’un fournisseur iPaaS ou de réécrire l’adaptateur existant. La première solution, cependant, implique des coûts supplémentaires, tandis que la seconde, si possible pour un développeur, ne fonctionne souvent pas tout à fait comme prévu en raison de la qualité médiocre des fonctionnalités qui sont responsables de la migration des jobs d’un environnement à un autre.
Modèles pour connecteurs d’intégration et SDK
Dans ce contexte, certains fournisseurs iPaaS ont commencé à proposer des connecteurs d’intégration comme modèles de connecteurs, disponibles pour une configuration et une personnalisation ultérieures. Des développeurs d’intégration ont eu facilement accès au code source des connecteurs et ont reçu du fournisseur les outils et le flux de travail nécessaires au développement, au test et au déploiement de connecteurs adaptés en production, sans trop de travail manuel.
En outre, la très grande variété d’applications à la disposition des entreprises entraîne une demande accrue d’outils conviviaux et en libre-service pour les spécialistes de l’intégration, leur permettant de construire leurs propres connecteurs d’intégration. De préférence avec la prise en charge de différents langages de programmation.
Bien entendu, les software development kits (SDK) doivent permettre de développer, tester et produire facilement de nouveaux connecteurs, comme c’est le cas pour le changement de connecteurs existants.
Ces fonctionnalités profitent non seulement aux spécialistes de l’intégration qui sont responsables des projets critiques, mais aussi à d’autres acteurs informatiques tels que les intégrateurs ad hoc. Ces capacités aident à réaliser des projets de développement rapide qui peuvent avoir une courte durée de vie, mais qui sont tout aussi nécessaires.
Marchés pour l’intégration en libre-service pour les non-informaticiens
La plupart des analystes s’accordent aujourd'hui à dire qu’une offre iPaaS moderne devrait également inclure des capacités d’intégration en libre-service pour les utilisateurs non professionnels (‘citizen integrators’). Bien qu’un département IT central ne soit généralement pas mis en place dans l’idée que les utilisateurs du cœur de métier d’une entreprise (‘line-of-business users’, LOB) puissent développer et implémenter eux-mêmes des intégrations, il existe sur le marché suffisamment d’outils d’automatisation de tiers qui, en quelques clics, permettent des intégrations entre les outils LOB les plus populaires, et les non-informaticiens en font probablement déjà pleinement usage.
L’élément moteur de cette tendance est que, d’une part, les utilisateurs LOB modernes sont davantage versés dans le numérique qu’auparavant. Cela ne signifie pas nécessairement qu’ils savent programmer, mais une offre SaaS est dans 99 % des cas très facile à implémenter et à utiliser sans connaissances en programmation. D’autre part, la plupart des entreprises qui subissent une transformation numérique ont besoin de rendre l’information relative aux applications et aux systèmes informatiques disponible pour toute activité commerciale à travers l’organisation, parfois même à des organisations externes dans des scénarios B2B. Il est crucial que cela se fasse rapidement, alors qu’un département informatique central prend en moyenne 2-3 mois pour ajouter une nouvelle application logicielle à l’environnement informatique existant.
Solutions d’intégration prêtes à l’emploi
Pour répondre à cette tendance, il est important que l’IT mette en place une gamme d’outils d'intégration permettant de créer des marchés d’intégration conviviaux pour les utilisateurs LOB. Un tel marché fournirait des connecteurs pour les applications et les systèmes d’entreprise qui cartographient la logique commerciale et permettraient une installation et une configuration faciles.
Un exemple en est l’intégrateur de systèmes néerlandais Apora, qui a implémenté les solutions Zoho pendant six ans et s’est récemment associé à Oracle pour l’implémentation et l’intégration de son Oracle Sales Cloud. L’entreprise est passée par sa filiale Aplynk pour transférer ses nombreuses années d’expérience en intégration de systèmes dans des progiciels d’intégration libre-service, offerts dans le cadre d’un marché d’intégration libre-service.
Bien sûr, une telle innovation exige un certain investissement, tant en termes de temps que d’argent, mais elle s’amortit d’elle-même à long terme. Même si une telle approche en libre-service pour les non-informaticiens ne devrait pas réduire le nombre de projets d’intégration, elle libérera le département informatique d’une grande quantité de travail et aidera à circonscrire les coûts (pas besoin de personnel informaticien supplémentaire), tout en gardant la maîtrise de la visibilité et du contrôle des données.
L’avantage est que les utilisateurs LOB feront ce qu’ils faisaient auparavant, à savoir de l’intégration en libre-service, mais en utilisant les propres outils de l’entreprise au lieu de services tiers, donc sans risquer d’exposer des informations sensibles à toute personne qui ne devrait pas en être destinataire.
Sources: Internet - Veille technologique Sirris
