| |
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.
|
