3 experts échangent sur les enjeux de l’intégration hybride

François RIVARD Président-Fondateur

Astrakhan

Alessandro GANCI Technical Leader

TIBCO Software

Renaud FLANDRESenior Solutions Consultant

TIBCO Software

INTERVIEW CROISÉE

PLATEFORMES D’INTEGRATION, MICROSERVICES, API

1

En quoi l’integration est-elle en 2017 la pierre angulaire du systeme d’information et le socle de la digitalisation, du big data, de l’IoT ?

Alessandro GANCI L’intégration a été, est et restera un

pilier fondamental du système d’information. Quelle que

soit sa stratégie à court, moyen ou long terme, toute

entreprise se doit de traiter ce sujet avec l’importance qu’il

mérite et d’en faire au moins un facilitateur, au mieux un

vrai levier stratégique de croissance et d’innovation. Nous

avons souvent tendance à réduire une stratégie digitale à

la seule amélioration de l’expérience client. C’est certes

important mais pas suffisant. Les leaders digitaux de

demain se distingueront surtout par leur capacité à utiliser

le numérique pour promouvoir et accélérer l’innovation en

exploitant les ressources internes et externes à l’entreprise.

Combien de temps faut-il pour créer une nouvelle

application mobile innovante ? En combien de temps puis-

je intégrer un nouveau partenaire ? Telles sont les questions

qui nécessitent de revoir la stratégie d’intégration pour en

faire un vrai catalyseur d’innovation avec un impact réel

sur le métier.

Renaud FLANDRE On parle beaucoup du monde du

« tout connecté » avec la montée en puissance de l’IoT et

du Big Data ; cela suppose que les entreprises arrivent à

tirer parti de cet immense gisement de données et de

valeur pour se différencier et innover. Pour y parvenir, on

doit remettre l’intégration au cœur des problématiques et

faire en sorte que ces initiatives viennent enrichir le

patrimoine IT existant et non pas, comme on le voit trop

souvent, se structurer à l’extérieur du SI traditionnel de

façon tactique et court-termiste.

Comment definir en quelques mots le concept d’architecture hybride ?

Renaud FLANDRE C’est une architecture d’intégration

capable de s’adapter à différents patterns de déploiements

et qui peut être proposée en interne (on-premise) ou en

mode cloud (PAAS public ou privé et IPAAS).

Alessandro GANCI Pour synthétiser, je dirais qu’il s’agit

d’une architecture qui associe des ressources internes et

externes à l’entreprise avec des mécanismes d’intégration

qui relient les deux mondes.

L’intégration est un pilier fondamental du système

d’information.

La transformation numérique modifie en profondeur le paysage industriel et fait émerger de

nouveaux modèles économiques. Les services dans le cloud, les appareils mobiles et l’Internet

des objets conduisent a un éclatement du SI au-dela de ses frontières naturelles et induisent des

architectures dites « hybrides » pour appréhender la diversité de ces nouveaux écosystèmes.

Comment s’adapter a cette nouvelle donne ? Quels sont les composants essentiels d’une architecture

d’intégration « hybride », capable d’intégrer de manière transparente les systèmes legacy internes avec les

nouvelles plateformes et applications Cloud (SaaS…) ? Comment déployer ce type d’architecture ? Quel est

le rôle de l’API management ? Qu’est-ce qu’un microservice ? Découvrez les retours d’expérience de trois

consultants spécialisés dans la mise en œuvre de plateformes d’intégration hybride.

2

François RIVARD J’ajouterais que cette architecture

hybride découle d’une prise de conscience de la nécessité

des échanges d’information à l’ère du digital.

Quels sont les principaux enjeux operationnels autour de l’integration hybride ?

FR Prenons l’exemple d’une application CRM de type

salesforce en mode SaaS qui a besoin de communiquer

avec une application de fidélisation et de distribution de

coupons, également en mode SaaS. Nous sommes dans

une hypothèse ou l’échange d’information est essentiel,

car le CRM a par essence besoin d’échanger pour améliorer

le parcours utilisateur.

Si l’on souhaite faire converser ces deux applications avec

un ESB et de l’API management installé on premise, cela

revient à établir une conversation entre 2 applications

cloud en passant par le système d’information, ce qui n’est

pas optimisé du point de l’architecture du SI. L’idée est

donc de déployer dans le cloud des techniques qui

permettent à ces deux applications de discuter

naturellement entre-elles, en mode cloud to cloud, sans

passer par toutes les couches de sécurité du SI interne.

Dès lors, on aboutit à des échanges « hybrides », c’est-à-

dire d’un côté des échanges dans le cloud uniquement et

d’un autre côté des échanges traditionnels, en mode

« application to application » au sein du SI. À cela viendront

s’ajouter des échanges « cloud to on-premise » ou

inversément, de l’interne vers l’externe. L’enjeu est de faire

en sorte que l’ensemble de ces patterns se mettent en

place sans avoir besoin de se demander où se trouve l’outil

qui assure la communication entre les différentes briques.

RF Il faudra également être en capacité de synchroniser

ces différentes briques afin d’obtenir une vision complète

de la plateforme d’échange, et ne pas se limiter à une

vision morcelée qui oblige à rechercher l’information en

permanence dès lors qu’on souhaite procéder à un

monitoring des échanges.

Quelles problematiques d’integration constatez-vous le plus souvent sur le terrain ?

AG Nous sommes toujours confrontés à des entreprises

organisées en silos métier, chaque silo ayant pour objectif

de soutenir son activité métier spécifique. L’intégration est

donc souvent négligée et perçue comme un centre de

coût plutôt qu’un support indispensable à l’activité métier

dans sa globalité. Les organisations feront un grand pas en

avant si elles réussissent à mettre en place une organisation

qui favorise l’intégration. Quoi qu’il en soit, j’ai envie de

dire qu’elles n’auront pas le choix : l’intégration est devenue

un passage obligé.

FR Je rejoins Alessandro sur l’origine organisationnelle

des problèmatiques d’intégration. Le Digital a provoqué

une profusion technologique et les nouvelles directions

digitales s’y sont engouffrées sans réellement prendre en

© Copyright 2000–2017 TIBCO Software Inc.

TIBCO ActiveMatrix BusinessWorks™:Fastest time to results A true zero-code integration with Eclipse user interface

•  Graphical modeling and mapping

•  Visual process debugger

•  Download plug-ins from Eclipse

Les problématiques d’intégration ont souvent une origine

organisationnelle.

compte la nécessité d’intégrer. On pourrait même penser

que les responsables digitaux se sont volontairement

désintéressés de l’aspect intégration, leur objectif premier

étant de construire un système d’information ad-hoc afin

de répondre aux enjeux du digital. Par conséquent, le

recours aux applications en mode SaaS a été massif, ce qui

explique aujourd’hui la nécessité d’urbaniser, de rationaliser

et de se connecter aux informations présentes

historiquement dans le SI de l’entreprise.

RF On constate surtout des difficultés dans le cadre des

projets SaaS qui nécessitent la mise en oeuvre de nouvelles

organisations, car la mise en place de ce type de

plateforme est souvent impulsée par les métiers. Ces

derniers choisissent un outil en fonction de leurs besoins,

sans prêter suffisamment d’attention aux problématiques

d’intégration. Comment les données seront récupérées, à

quelle fréquence, quel niveau de sécurité mettre en place ?

Cette phase de définition des besoins est souvent négligée

et l’intégration reste le parent pauvre du choix d’un logiciel

en mode SaaS. Au bout de quelques temps, le constat est

sans appel : on ne parvient pas à assumer la charge, des

problèmes de fiabilité des données apparaissent, le

système manque de résilience… C’est pourquoi trouver les

outils qui satisfont les besoins métiers et les contraintes

techniques constitue un vrai défi.

Quels sont les impacts d’une integration ratee ?

FR Le risque est de raisonner sur des informations

partielles, ce qui peut se traduire par de mauvaises

prises de décision.

RF Dans les cas les moins graves, une mauvaise

intégration va limiter la pertinence du projet.

Concrètement, les données ne seront pas mises à jour

en temps réel, les interactions avec les clients seront

moins rapides, on aura plus de mal à obtenir une vision

des stocks en temps réel, etc.

Dans le pire des cas, rater son intégration peut conduire

à l’échec total du projet, avec une infrastructure qui

plante et tous les risques que cela engendre en perte

d’image et en mécontentement des clients.

AG En effet, une intégration ratée perturbe fortement

les activités métiers. Dans certains cas, cela force les

utilisateurs à réaliser manuellement un grand nombre

d’actions pour compenser les déficiences de l’intégation.

Il y a donc un fort ROI autour de l’intégration. Il faudra

veiller à une mise en œuvre de qualité pour libérer les

équipes du stress quotidien et leur permettre de se

concentrer sur des tâches innovantes et à plus forte

valeur ajoutée. Il n’y aura pas d’innovation dans

l’entreprise sans une intégration réussie des assets

métiers et techniques.

Quelle demarche adopter pour resoudre les problematiques d’integration ? Comment situez-vous la demarche de TIBCO vis-à-vis de ses concurrents ?

AG Sachant que les problèmes les plus importants sont

souvent liés à l’organisation de la DSI, TIBCO peut dans

une première phase intervenir en tant que conseil pour

fournir des retours d’expérience, alimenter la réflexion

dans l’organisation concernée, etc.

Mais c’est surtout sur le plan technologique que

l’accompagnement sera décisif, avec un fil conducteur

important : fournir des plateformes d’intégration qui

masquent la complexité technique ! Pour y parvenir,

TIBCO utilise le même socle technologique d’intégration

sur le cloud et on-premise. Ainsi, l’organisation qui opte

pour la plateforme TIBCO en mode on-premise pourra

réutiliser ses développements en cas de passage sur une

architecture hybride ou full cloud.

Une bonne plateforme d’intégration doit masquer la

complexité technique.

3

FR Si l’on devait dresser un panorama du marché de

l’intégration hybride, je dirais qu’il y a 3 types d’acteurs :

• Dans la sphère digitale, le réflexe est plutôt de

simplifier au maximum les outils pour les mettre à la

portée des non-techniciens. On va parler d’ad-hoc

integration et d’outils de citizen integration, à savoir

des outils qui permettront à des non-techniciens de

mettre en place des échanges applicatifs tel que

nous les avons évoqués précédemment.

• On trouve ensuite des outils qui se situent entre les

deux publics, et qui conviennent à des techniciens

comme à des publics plus llarges.

• Puis vient une démarche radicalement différente :

celle de TIBCO. Il faut déjà souligner l’historique de

TIBCO, qui est originellement un expert du monde de

l’intégration et qui possède une véritable « culture de

plateforme ». En mettant à disposition des outils

d’intégration dans le cloud, TIBCO a souhaité

conserver cet ADN.

RF Dans sa démarche, TIBCO fait en sorte que l’outil

utilisé pour réaliser les flux d’intégration reste toujours le

même. Que l’on soit en mode on-premise, dans une

stratégie de conteneurisation ou en mode SaaS, les

personnes historiquement en charge de l’intégration

réutilisent leurs connaissances : la démarche est

totalement transparente. C’est le principe du « develop

once, deploy everywhere ».

Comme le précise François, cette approche est orientée

développeur, mais elle a été complétée par des outils de

citizen intégration afin de permettre aux métiers de faire

eux-mêmes de l’intégration sans solliciter les équipes IT.

On parle de plus en plus de WOA (Web Oriented Architecture). Le SOA est-il mort pour laisser place à des microservices ?

AG Commençons par distinguer les deux notions. Le

SOA est une démarche associée à de nombreux standards,

qui amène à une architecture orientée services alors que le

concept de microservices désigne plutôt une manière de

concevoir les applications pour répondre aux nouveaux

enjeux de l’ouverture du SI sur le web.

Dans une démarche SOA, on expose des services

réutilisables par une ou plusieurs applications et conçus

comme des grands monolithes (intégralement en JAVA ou

en langage C++, ...). Les objectifs principaux de la

démarche sont la réutilisation des services au sein des

applications d’un SI, l’utilisation des standards SOA pour la

définition des interfaces et la communication entre

applications, ainsi que la composition des services

élémentaires dans des services à plus haute valeur ajoutée.

Les microservices remettent en cause cette approche

monolithique. Pour expliquer la démarche, on peut dire

que les applications sont constituées de plusieurs modules

fonctionnels. Chaque module (microservice) gère un

périmètre métier limité, mais de manière très performante

et scalable. En réalité, le « microservice » n’est pas aussi

micro que son nom l’indique... L’intérêt est d’obtenir une

certaine granularité dans la gestion de l’application et

d’optimiser les modules au cas par cas afin de rendre

l’application plus simple, scalable et performante, tout en

réduisant les coûts de maintenance.

Au final, on ne peut pas dire que le SOA est mort pour

laisser la place aux microservices. Les entreprises qui

réussiront sont celles qui auront su trouver le bon équilibre

entre les deux démarches.

RF Je pense également qu’il n’y a pas de rupture nette :

nous sommes passés progressivement du SOA au WOA

(Web Oriented Architecture). Il s’agit de services plus

autonomes, indépendants, et reposant sur des

architectures modulaires. Ils permettent de déployer de

nouveaux services beaucoup plus rapidement et sont

également plus intéressants en termes de scalabilité, ce

qui est désormais une nécessité.

Mais ce n’est pas une révolution ni un changement de

paradigme, c’est une nouvelle étape qui s’inscrit dans le

prolongement du SOA et qui nous amène à tirer parti des

technologies REST, du cloud, des containers… Je pense

que les entreprises qui réussissent sont celles qui

s’adaptent aux nouvelles technologies sans remettre en

cause ce qui fonctionne.

SOA et microservices sont des démarches complémentaires.

4

FR La presse et les services marketing sont friands de

nouveaux concepts. Il est tentant d’évoquer la mort d’une

notion ou la naissance d’une nouvelle ère. La réalité est

souvent bien plus subtile. Je ne dirais pas que le SOA est

mort, mais qu’il s’est transformé. Les approches liées aux

protocoles de communication et aux technologies de la

précédente décennie ont effectivement évolué vers plus

de modularité, de flexibilité, moins de contraintes

technologiques, plus d’ouverture. Mais pour quelle raison ?

D’où vient cette évolution ?

Il faut déjà bien comprendre que le SI d’une entreprise a sa

propre logique. Hier, il imposait des contraintes que l’on

retrouvait naturellement dans la façon dont le SOA était

structuré. Aujourd’hui, les choses ont changé, l’avènement

du cloud et du digital impose nécessairement une

ouverture : on parle d’open data, d’open APIs, etc. Nous

avons donc besoin d’une flexibilité et d’une souplesse dont

nous n’avions pas besoin il y a dix ans. C’est désormais

cette flexibilité qui prévaut lorsque l’on souhaite établir de

la communication inter-applicative. On s’est donc orienté

vers des protocoles plus adaptés au web et moins

contraignants dans leur utilisation. C’est ce que l’on a

appelé les architectures modulaires, Web Oriented

Architecture ou microservices…

A bien observer cette évolution, nous sommes passé du

SOA orchestré par de l’ESB en interne à un monde WOA

qui s’organise autour d’outils d’API management,

essentiellement en externe. Ce n’est pas pour rien que les

leaders du SOA d’hier sont les acteurs principaux du WOA

aujourd’hui. Il n’y a pas de changement total de paradigme,

mais simplement une évolution. Un acteur comme TIBCO

a évolué de l’ESB vers des outils d’API management et

d’IpaaS, mais l’essentiel de l’expertise est toujours la même.

Quels changements implique l’adoption d’une demarche axee sur les microservices ? Cette demarche est-elle à la portee de toutes les entreprises ?

AG Une telle démarche demande un changement culturel

et organisationnel profond qui contribue largement au

succès ou à l’échec de la transformation. Toutes les

organisations n’ont pas le même modèle de business, les

volumes et les moyens financiers d’une entreprise telle

qu’Amazon. Le risque d’échec avec les microservices est

donc souvent proportionnel à l’enthousiasme aveugle avec

laquelle certaines entreprises s’y lancent.

Mais attention, cela ne doit pas restreindre pour autant la

démarche microservices à une population élitiste : au

contraire, un grand nombre d’entreprises pourront tirer

parti d’une architecture de type core/edge. La partie core

(SOA/ESB) continuera à être le support principal pour les

activités historiques de l’entreprise alors que la partie edge

soutiendra les activités à forte vélocité, avec des

contraintes de performance importantes et beaucoup de

turn-over.

RF Je pense que le maître mot est le pragmatisme. Pour

résumer, la démarche la plus adaptée se décompose en 3

étapes :

• Bien exploiter l’existant et s’appuyer sur l’architecture

REST pour créer des services plus simples à utiliser ;

• Mettre en place davantage d’outils DevOps et essayer

d’automatiser au maximum les chaînes de déploiement

pour gagner en vélocité ;

• En termes d’infrastructure, s’orienter vers davantage

de technologies autour du PaaS (containeurisation,

Docker, cloud foundry) pour favoriser l’indépendance

et l’autonomie.

Les API soulevent des interrogations sur la securite et la confidentialite des donnees echangees. Qu’est-ce qui a veritablement change ? Ces craintes sont-elles fondees ?

AG Il faut relativiser les questions de sécurité en rapport

avec les API et se poser les bonnes questions. Les craintes

autour de la sécurité viennent d’une mauvaise

compréhension de l’API management. Nous sommes dans

un domaine où l’exposition des données à l’extérieur de

l’entreprise est cruciale pour augmenter les revenus,

L’approche microservices exige avant-tout du

pragmatisme et une bonne capacité à exploiter l’existant.

65

réduire les frais de communication avec les partenaires

(fournisseur, clients, etc..) et digitaliser le SI.

Si l’on se trouve dans un contexte d’échanges B2B, qui

implique la communication d’informations sensibles pour

le cœur de métier dans un cercle restreint d’intervenants, il

est normal de prêter une grande attention aux questions

de sécurité. Mais dans cette configuration, nous ne

parlerons plus d’API management.

En exposant des services via les API, on doit forcément se

préparer à gérer un grand nombre d’utilisateurs potentiels.

Dès lors, les techniques de sécurité appliquées dans des

contextes B2B ne seront plus adaptées. Mais cela ne pose

aucun problème dans la mesure où les données exposées

ne représentent pas des secrets industriels. J’ose imaginer

qu’aucune entreprise ne sera jamais assez audacieuse

pour exposer ses secrets industriels par le biais d’un

portail API accessible par tout le monde. Il faut donc

relativiser la question de sécurité et de confidentialité des

données.

RF Je rejoins totalement Alessandro à ce sujet. Cela dit,

l’élément primordial est de savoir s’appuyer sur les équipes

et les infrastructures déjà en place, (firewall, WAF, …). Il est

également indispensable d’utiliser des mécanismes

standards d’authentification orientés « API management »

comme les API Key ou OAuth, avec des protocoles web

sécurisés.

On note par ailleurs un vrai besoin de certification pour

sécuriser les échanges entre partenaires, clients et

développeurs internes. A ce niveau, se diriger vers une

plateforme qui dispose déjà de certifications simplifie les

démarches. Il faut également s’orienter vers de nouvelles

méthodes de sécurité plus simples à mettre en œuvre afin

de communiquer rapidement avec les nouveaux

partenaires, tout en s’adaptant à un écosystème de

sécurité varié.

FR Les plateformes d’API management s’inscrivent dans

la continuité de l’ESB, à savoir des outils capables de gérer

la communication inter-applicative, mais davantage

orientés vers l’extérieur. Cette ouverture implique des

capacités de monitoring et de sécurité qui n’avaient pas

lieu d’être auparavant. Aujourd’hui, on doit être capable de

lisser les éventuels pics de charge provenant de l’extérieur.

On y parvient grâce à l’élasticité propre au cloud ou par la

mise en œuvre de fonctionnalités telles que le throttling.

EN SAVOIR PLUS

http://tibco.com

© Copyright 2000–2017 TIBCO Software Inc.

A better IoT integration blueprint Where appropriate, move application logic and integration out to the devices

Devices

Gateway Cloud Sensor Events

Control

Events

Control

Business microservices

go here

Edge microservices

go here

Edge microservices

logic could also run here

Benefits of edge integration & event processing • Local control = more reliable

• Less bandwidth & lower TCO

• Fewer hops, less latency

La plupart des entreprises ont intérêt à exploiter une architecture

de type core/edge.

6

Renaud FLANDRE

Senior Solutions Consultant, TIBCO Software

François RIVARD

Managing Partner Astrakhan Consulting

Alessandro GANCI

Technical Leader TIBCO Software

Renaud Flandre a débuté sa carrière dans le conseil avant de s’orienter vers le

monde de l’édition et de l’intégration depuis 2002. Il y a occupé divers postes de

chef de projet, participant ainsi à la mise en œuvre de projets notamment dans

le B2B, et de product manager, ce qui lui a permis d’appréhender les différentes

facettes du métier du logiciel. Depuis maintenant 3 ans, il a rejoint TIBCO Software

comme Solutions Consultant afin de se spécialiser dans la mise en œuvre de

plateformes d’intégration hybride.

François Rivard est président-fondateur d’Astrakhan, cabinet de conseil en

Management, Innovation et Systèmes d’Information. Il accompagne les entreprises en

France et à l’international dans le domaine de l’intégration. Certifié en management

3.0, il est expert des méthodes de management agile et de conduite de projet. Il a

publié trois ouvrages sur l’intégration, dont un primé.

Alessandro cumule 20 ans d’expérience dans le domaine de l’intégration des

systèmes d’information. Les mutliples postes occupés au cours de son parcours

professionnel lui ont permis d’appréhender les réalités terrain de la production,

du développement, du conseil et de la gestion des équipes informatiques, afin

de se forger une vision à 360° des systèmes d’information modernes et de

leurs problématiques. Depuis 3 ans au sein de l’équipe avant-vente TIBCO, il

accompagne les grands comptes dans le domaine de la finance et de l’assurance

dans leur stratégie d’innovation de l’intégration au sens large.

À propos des experts

francois.rivard@astrakhan.fr

rflandre@tibco.com

aganci@tibco.com

7

TIBCO Software France

25 rue Balzac 75008 Paris +33 1 44 51 45 88 www.tibco.com

TIBCO Software accompagne les entreprises dans leur transformation digitale en interconnectant les différents éléments de leurs systèmes d’information et en augmentant l’intelligence des décisions basées sur la donnée. Cette combinaison garantit des réponses plus rapides, de meilleures décisions et des actions plus pertinentes. Depuis 20 ans, TIBCO met à la disposition des solutions et services innovants qui s’adressent aux opérationnels, aux développeurs ainsi qu’aux data scientists. Des milliers de clients de par le monde se démarquent en faisant confiance à TIBCO pour concevoir des business modèles innovants et offrir des expériences clients convaincantes. Pour en savoir plus www.tibco.com.

© 2017, TIBCO Software Inc. Tous droits réservés. TIBCO, le logo TIBCO, TIBCO Software et TIBCO Spotfire sont des marques commerciales ou des marques déposées de TIBCO Software Inc. ou de ses filiales aux Etats-Unis et/ou dans d’autres pays. Tous les autres noms de produits, d’entreprises et de marques figurant dans ce document appartiennent à leur propriétaire respectif et ne sont mentionnés qu’à des fins d’identification. 02/17