| |
Solutions dite d'ESB (Enterprise Service Bus), de BPM (Business Process Management)
ou encore framework
de Web Services… Chaque mois de nouvelles catégories
de solutions semblent faire leur apparition au rayon
de l'intégration. De nouveaux techno-concepts
et de nouvelles abréviations qui représentent,
pour les utilisateurs, autant d'occasions de ne plus
y comprendre grand chose. Comme à l'habitude
en informatique, il suffit pourtant de se pencher sur
l'origine de ces solutions pour saisir ce qu'il est
réellement raisonnable d'en attendre. C'est l'exercice
auquel nous vous convions ici. Un exercice en forme
d'introduction à des évaluations plus
poussées des offres qui seront publiées
courant 2004.
Les
solutions de type ESB
Leur origine
Qui sont ces pure-players de l'ESB qui se présentent
comme les nouveaux challengers de l'intégration
? Pour répondre, il suffit de se pencher sur
le cas de deux de ses principaux représentants,
à savoir Sonic et Fiorano. Des éditeurs
connus historiquement pour leurs technologies de middleware
orientée message (MOM). Ces éditeurs ont
su capitaliser sur les technologies XML pour étoffer
leurs MOM de briques techniques capable d'assumer des
fonctions de transformation, de routage, voire d'orchestration
de processus. Et c'est cet ensemble (MOM + moteur d'intégration
XML) que ces éditeurs présentent aujourd'hui
sous l'étiquette ESB. Notons que les solutions
ESB ne sont plus l'apanage de ces seuls éditeurs.
Les acteurs de l'EAI (webMethods et Seebeyond notamment)
comme des éditeurs plus généralistes
(IBM) proposent (ou sont sur le point de le faire) eux
aussi leurs propres solutions ESB. Autrement dit, le
terme désigne moins une nouvelle catégorie
d'acteurs qu'un "nouveau" type de plate-forme
d'intégration.
Leur argument marketing
Moins chères, plus standards, plus faciles à déployer,
adaptées à des projets plus tactiques que stratégiques…
Sans ambiguïté, les pure-players de l'ESB positionnent leurs solutions
de façon à se démarquer de l'EAI et des retours d'expérience
associés. Leur argumentaire est pour l'essentiel centré sur les
atouts que seraient susceptibles d'apporter les standards tels que XML et J2EE.
Le message subliminal est en substance celui-ci : "Les plates-formes d'EAI
de première génération souffraient de leur caractère
propriétaire et des coûts associés. Parce qu'elles s'appuient
sur des standards, les solutions d'ESB permettent d'être mises en œuvre
avec des compétences plus banalisés, mieux maîtrisées
et plus abordables". L'argument est recevable. On notera seulement que depuis
4 ans les solutions d'EAI ont été largement ré-écrites
autour de ces mêmes standards. Ce qui permet assez naturellement aux éditeurs
de plates-formes EAI de proposer des solutions ESB. Qui sont, dans les faits,
des versions basiques de leurs offres EAI, dont le positionnement commercial correspond
à des projets plus tactiques que stratégiques.
Leur réalité technique
On l'aura compris, les solutions de type ESB remettent moins en cause le
modèle de l'EAI qu'elles ne le revisitent par les standards : JMS pour
le transport, JCA et les Web Services pour la connectique applicative, XML et
ses dérives pour la transformation et le routage. Cet adossement aux standards
permettra-t-il à lui seul de mieux maîtriser les projets d'intégration
? De déployer et d'exploiter de telles plates-formes à moindre coût
? Répondre d'emblée par l'affirmative reviendrait à estimer
que les difficultés des projets EAI sont principalement de nature technique.
Or, dans les faits, les raisons de l'enlisement de certains projets sont plutôt
d'ordre fonctionnel et culturel.
Les solutions de type BPM
De quoi parle-t-on ?
L'abréviation BPM pose un réel souci car elle ne renvoie pas aux
mêmes solutions en fonction du côté de l'Atlantique où
l'on se trouve. En Europe, et en France notamment, cette étiquette de "solutions
de BPM" a été utilisée principalement par les éditeurs
de solutions de workflow, autrement dit, d'automatisation de circuits de validation.
Des solutions proposées par des acteurs tels que Akazi, Staffware ou encore
W4. Aux Etats-Unis, l'appellation "solutions de BPM" fait référence
davantage à des solutions dite "d'intégration par les processus"
présentées par des acteurs tels qu'Intalio ou encore Savvion. C'est
bien cette dernière catégorie de solutions que nous évoquons
ici. Des plates-formes destinées à des projets d'intégration
de type "Top down" (par le haut) et dont les principaux concurrents
sont, a priori, les outils d'EAI.
Leur argument marketing
Sans surprise, l'argument de ces acteurs est celui
d'un pure-player du BPM pour qui, en substance, "seule
une solution nativement conçue pour intégrer
par les processus peut atteindre un tel objectif".
Ces plates-formes se destinent donc en priorité
aux entreprises matures sur la question de la gestion
des processus métier et/ou en quête d'une
capacité à reconfigurer avec réactivité
ces processus. Assez naturellement, ces solutions se
positionnent aussi sur le BAM (Business Activity Monitoring),
autrement dit, sur leur capacité à superviser
les processus et à automatiser le déclenchement
d'actions en fonction d'indicateurs directement dérivés
des processus. Si ces éditeurs ont parfois tendance
à se présenter comme des concurrents de
l'EAI, la réalité technique des solutions
conduit cependant à nuancer ce positionnement.
Leur réalité technique
Très centrées sur l'exécution et la supervision des
processus métier, ces offres le sont inévitablement moins sur les
services plus techniques de l'intégration (transformation et routage des
données, transport, connectique). La réalité des projets
semblent confirmer que ces solutions sont plus complémentaires que concurrentes
des offres EAI puisque des études ou des déploiements en cours se
soldent par la cohabitation de deux plates-formes (de BPM et d'EAI).
Les solutions type "Framework de Web
Services"
Leur origine
Il y a quelques mois encore, le domaine des Web Services était avant tout
l'apanage d'éditeurs très spécialisés. Aujourd'hui,
ces acteurs semblent suivre principalement deux voies : celle de la fusion/acquisition
(par un concurrent ou un acteur plus généraliste) et celle de l'élargissement
de la couverture fonctionnelle. Dans le second cas, cet élargissement conduit
souvent ces acteurs à élaborer une solution d'intégration
fondée sur les Web Services. C'est le cas par exemple d'acteurs tels que
Cape Clear ou encore Systinet (Note : Il y a quelques semaines, nous aurions pu
ajouter à cette liste The Mind Electric, éditeur du framework Glue.
Mais entre-temps The Mind Electric a été acquis par l'éditeur
EAI webMethods) dont les offres s'étoffent peu à peu pour constituer
in fine ce qui ressemble bel et bien à une plate-forme couvrant l'essentiel
des services d'intégration : connectique, transformation, routage, etc.
Leur argument marketing
"Les standards, et rien que les standards",
tel pourrait être la devise de ces solutions développées
autour d'un framework dédié aux Web Services.
Un caractère standard qui serait synonyme d'ouverture
et d'interopérabilité. En substance, ces
solutions laissent entrevoir un avenir où il
deviendrait possible de combiner au sein d'une même
plate-forme des services d'intégration fournis
par des éditeurs distincts. Autre argument affiché
par ces solutions, leur aptitude à s'inscrire
dans des architectures orientées services puisque,
fondamentalement, elles n'opèrent que sur des
objets techniques exposés (sous forme donc de
Web
Services). Notons que ces solutions sont généralement
assez agnostiques en ce qui concerne la couche transport
et cohabite sans difficultés par exemple avec
des MOM (IBM MQSeries, Tibco RendezVous ou autre…).
Leur réalité technique
C'est un fait, ces offres bâties autour des Web Services évoluent
actuellement à une vitesse impressionnante. A un point tel qu'il devient
possible aujourd'hui d'évaluer des plates-formes couvrant l'essentiel des
services d'intégration (exposition, transformation, routage, orchestration)
et s'appuyant sur une palette conséquentes d'outils (moteurs, référentiels,
consoles d'administration etc.). Des évaluations que nous mènerons
donc à partir du début de l'année prochaine.
|
