iPaaS : quelques cas d’usages à considérer

Les DSI doivent répondre à différents cas d’usages d’intégration, auxquels le Cloud est lié: des applications Cloud à intégrer entre elles ou avec le SI interne, une intégration avec des partenaires ou filiales et enfin un débordement du SI vers le Cloud.

Ces cas d’usages se traduisent par des besoins d’échanges de fichiers de grandes tailles en différés, de messages au fil de l’eau, d’appels de services synchrones… Les systèmes d’échanges assurant alors les fonctions de transfert, routage, transformation et connectivité aux applications dans le Cloud et dans le SI interne.

Trois typologies de déploiement permettent de supporter ces cas d’usages

Le plus naturel consiste à utiliser un système d’échange existant on-premise (SI interne). L’intégration avec les applications dans le Cloud est faite via des connecteurs spécifiques (particulièrement pour le SaaS). Mis en œuvre initialement pour une intégration majoritairement interne au SI, le système d’échange est utilisé pour l’intégration avec le Cloud. Ce choix n’est pertinent que pour un nombre restreint d’applications Cloud, sans échanges importants entre elles.

Avoir une plateforme unique d’échange dans le Cloud public est une autre typologie possible. Elle sera alors principalement utilisée pour l’intégration entre applications dans le Cloud.  Elle peut également être utilisée pour devenir le point unique d’échanges avec des partenaires et filiales. Toutefois, le passage systématique par le système d’échange dans le Cloud pour l’intégration d’applications internes au SI peut être rédhibitoire (volume, latence…). Ce peut être un choix uniquement tactique, pour une adoption rapide.

L’utilisation de deux systèmes d’échanges en « miroir », un dans le SI (potentiellement existant) et un autre dans le Cloud, est la typologie la plus avancée. Il n’y a alors qu’un lien unique entre les deux plateformes, donc un seul point d’entrée dans le SI interne sur lequel la sécurité est renforcée. Elle permet de couvrir efficacement l’ensemble des échanges internes et Cloud.  Une gouvernance des échanges est ici indispensable pour maîtriser leur répartition entre les deux plateformes. Des réponses doivent également être apportées pour assurer la consolidation de la supervision, le déploiement des flux…

Au final, le choix de typologie dépend avant tout de l’existence de systèmes d’échanges au sein du SI et du nombre d’applicatifs dans le Cloud à la cible.

Un marché de l’iPaaS hétérogène

L’iPaaS est une suite de services Cloud supportant ses caractéristiques principales : self-service, élasticité, mesurable et mutualisation des ressources. Il permet l’intégration entre des éléments du Cloud et on-premise et peut assurer différentes typologies d’intégration : processus (BPM, workflow…), services (ESB / SOA), applications et données (ETL).

Dans les faits, les solutions iPaaS n’ont pas toutes ces caractéristiques clés, et peuvent être de différentes natures :

D’un côté, il y a les pure players de l’intégration Cloud. Leurs solutions sont construites sur le modèle du Cloud, ils en respectent les préceptes. Leur maturité est cependant encore à challenger dans un marché qui n’est pas encore entièrement consolidé. De l’autre, il existe des solutions n’ayant aucune caractéristique Cloud mais ayant des connecteurs vers les grands noms du SaaS (Salesforce, WorkDay…). Elles servent avant tout d’accélérateur pour une connexion simplifiée. Mais il ne faut pas non plus mettre de côté les solutions classiques on-premise d’éditeurs historiques de l’intégration directement déployées sur une offre PaaS. Ces solutions ont pour elles leur maturité acquise dans l’intégration interne au SI. En revanche les caractéristiques du Cloud ne sont pas toutes assurées…

Il est donc nécessaire de prendre en compte son existant afin de faire les choix les plus pertinents.

Quel chemin emprunter pour aller vers le Cloud ?

Le chemin vers l’intégration Cloud peut prendre différentes voies selon l’existant en termes d’échanges au sein du SI de l’entreprise. Pour un SI déjà outillé avec une ou plusieurs plateformes d’échanges, ce qui est le cas chez les grands comptes, il est important de capitaliser sur celles-ci en se concentrant sur deux problématiques clés. La première : est-ce que la solution propose des connecteurs Cloud vers les applications SaaS utilisées, ou même un framework de développement pour s’adapter à toute application SaaS ? La seconde : est-ce que la solution est proposée par l’éditeur dans une version iPaaS ? Cela permet de mettre en œuvre une typologie de déploiement en miroir, tout en conservant les mêmes compétences internes.

Si l’extension du SI vers le Cloud n’entraîne pas une rupture des architectures d’échanges inter-applicatifs déjà en place (SOA, EDA…), il sera cependant nécessaire de décliner les patterns établis afin de tirer entièrement parti des promesses du Cloud et de prendre en considération ses contraintes.

Cet article L’iPaaS, pourquoi ne peut-on pas faire l’impasse ? est apparu en premier sur RiskInsight.