Les deux dernières années ont été terribles pour le monde de l’informatique habitué à des taux de croissances confortables : les clients ont réduit leurs dépenses destinées aux nouveaux systèmes de 15 à 20 % en moyenne alors qu’ils avaient investi massivement lors de la dernière décennie (avec des augmentations annuelles des dépenses d’investissement de l’ordre de 5 à 10 %).
Pire, c’est maintenant les dépenses nettes en matière de systèmes d’information qui vont être touchées (et donc pas seulement l’investissement sur les nouveaux systèmes). Une étude récente publiée par Goldman Sachs menée auprès de 100 grandes compagnies américaines révèle que les dépenses liées aux systèmes d’information vont baisser de 1 % en 2003… C’est un recul sans précédent depuis plus de vingt ans dans cette industrie !
Déception aussi du côté des « packages miracles »
Ce contexte morose n’est pas vraiment surprenant : non seulement l’éclatement de la bulle Internet a « coupé les jambes » des projets de sites Web et d’Internetisation mais les déceptions ont également été nombreuses dans des domaines en vogue comme le CRM ou les ERP.
Une étude du Gartner Group menée en 2002 démontrait que plus de la moitié des projets de CRM n’avaient pas apporté les avantages promis (manière diplomatique de dire que ces projets avaient échoué !)… un constat partagé par une enquête similaire menée au même moment par Merrill Lynch[ [Merrill Lynch ]]. Dans un passé récent, on a connu les mêmes taux d’échec (voire pire) pour les projets de mise en place d’ERP.
Fin de la période « investissement frénétique »
Tout cela combiné a provoqué une crise de confiance qui s’est traduite par un coup d’arrêt radical dans les dépenses. Comme si tous les directeurs informatique s’étaient passés le mot en même temps : j’arrête d’acheter !
Tous les responsables informatique, interlocuteurs des acteurs du marché répètent maintenant le même cri du coeur : ne me vendez pas de nouveaux systèmes, aidez-moi plutôt à faire marcher ceux que vous m’avez déjà vendus… C’est un retournement de marché qui est radical et sans doute durable. Car, même en baisse, les dépenses informatiques sont tout de même là, pas pour des nouveaux projets mais seulement pour entretenir l’existant et il y en a !
Il est temps de s’occuper de l’existant…
En effet, le parc de legacy systems a considérablement augmenté depuis 10/15 ans. Il y a quinze ans, le paysage informatique était assez simple dans le domaine de la gestion : les grands comptes étaient équipés de mainframes, les PME de mini-ordinateurs (type AS/400) et toutes ces entreprises utilisaient des applications (la plupart du temps développées en interne) en mode centralisé. C’est l’irruption du client-serveur qui a introduit une première rupture, l’arrivée de l’Internet, du Web et de l’Intranet a achevé de bouleverser habitudes et architectures.
Couche sur couche sans attendre et sans finir
Pendant les années 90, les entreprises ont ajouté des vagues de nouvelles technologies, démarrant souvent des nouveaux projets avant même d’avoir achevé les précédents, le tout avec des résultats décevants mais la frénésie était telle qu’on remettait à plus tard bilans et examens. Cette période a atteint son point culminant à la fin des années 90 avec la notion de « temps Internet » qui justifiait de développer « vite fait-mal fait » des projets sans objectif, sans stratégie et sans résultat mesurable.
Maintenant que cette effervescence est retombée, le bilan est lourd : on est passé d’une époque où la notion de Legacy System concernait surtout l’ordinateur central et ses applications à une situation où presque tout doit être revu et corrigé afin d’avoir un système d’informations cohérent…
La vague de l’EAI
Depuis la fin de la bulle Internet, les opérations d’EAI sont devenues une priorité évidente pour la plupart des entreprises afin de retrouver un minimum de cohérence. C’est ainsi que nous sommes entrés pour au moins deux ans dans une période caractérisée par la volonté de consolider, d’intégrer et d’optimiser l’existant.
L’EAI, ce n’est pas seulement pour éviter les double saisies ou faciliter les transferts de données, c’est aussi la mise en place d’un socle homogène pour les prochaines applications. En effet, pour faciliter l’appel des processus existants (et ainsi éviter d’avoir à les réécrire), il parait sain de s’appuyer sur une structure d’intégration qui englobe l’ensemble des processus utiles.
C’est pourquoi General Motors s’est lancé dans une vaste opération d’intégration entre ses différentes unités qui sont équipées de solutions diverses (SAP, Siebel, etc.) en utilisant l’EAI Toolset de Seebeyond (un des leaders de cette spécialité avec Tibco et WebMethods entre autres).
Le mouvement semble fondé et les perspectives sont brillantes : d’après le Gartner Group, le marché EAI va passer de $5.1 Milliard en 2001 à $10.5 Milliard en 2006…
Malheureusement, la vague EAI a provoqué elle aussi son lot de déceptions. D’après un rapport récent du Butler Group, les solutions des acteurs principaux de ce domaine sont décrites comme lourdes, coûteuses et demandant beaucoup d’efforts pour être déployées. Les solutions techniques des acteurs spécialisés ont été critiquées d’autant que les poids lourds de l’informatique sont entrés dans la danse… Comprenant que le domaine de l’EAI faisait partie des questions d’infrastructure, les grands acteurs mettent tous en avant leurs propres solutions. Ils se sont tous plus ou moins alignés sur l’utilisation des technologies XML pour les opérations d’EAI car ce choix présentait deux avantages : tout d’abord, c’est à la mode, ensuite, cela permet de présenter « quelque chose » rapidement !
Même les éditeurs d’applications s’y sont mis comme SAP qui, dernièrement, a choisi les Web Services afin d’offrir un accès à ces processus sans avoir à choisir entre J2EE et dotNet… En conséquence, les Web Services ont été mis en avant comme l’alternative légère et idéale pour les opérations d’EAI…
Les Web Services pour une EAI « light » ?
Le fait que les Web Services se soient retrouvés mis en vedette dans le cadre de l’EAI n’est pas surprenant : les Web Services basés sur le protocole SOAP se révèlent être une technique peu intrusive et donc relativement facile à mettre en place, surtout si l’on compare aux autres solutions de middleware qui ont précédé les Web services comme DCOM ou CORBA (après tout, il ne s’agit que d’une RPC légère reposant sur XML) …
Le problème du synchronisme transactionnel en environnement distribué…
Ceci dit, utiliser des RPC synchrones n’est pas forcément la bonne démarche pour tenter d’harmoniser des systèmes qui fonctionnent indépendamment les uns des autres (cela revient à essayer de faire du transactionnel distribué, un exercice délicat !). Depuis vingt ans, on sait que le transactionnel distribué entre systèmes autonomes est une entreprise difficile. Tout un spectre de techniques ont été expérimentées dans ce sens avec de fortes contraintes de mise en œuvre (du commit à deux phases à la gestion d’objets distribués).
Enfin, les Web Services manquent encore des mécanismes d’authentification nécessaires dans un cadre strictement transactionnel (le standard est encore en phase d’évolution et tout ce qui concerne le domaine de la sécurité avait été un peu mis de côté jusqu’à il y a peu…).
On redécouvre l’asynchrone
Pour établir un dialogue entre des applications, les avantages du fonctionnement asynchrone sont ceux du courrier électronique par rapport au téléphone.
L’application « cliente » envoie un message à un service désigné par un nom (plutôt qu’une adresse ou une localisation), sans se soucier de sa disponibilité. L’envoyeur a de la part du middleware sous-jacent qu’une garantie de qualité de service réduite (certitude de remise au destinataire, délai de remise par exemple). La grande souplesse qu’apporte ce mécanisme se double d’une grande simplicité puisque les API des middleware orientés messages (MOM) reposent généralement sur deux verbes seulement : envoyer et recevoir. Ces avantages se payent a priori d’un manque de contrôle sur le délai d’obtention d’une réponse.
En revanche, en appliquant la technique store-and-forward (stocker et propager) également utilisée par les messageries électroniques, on assure que le service appelé sera exécuté une et une seule fois, ce qui est très fondamental dans la plupart des applications (financières par exemple).
Enfin dans certaines solutions de messagerie applicative asynchrone (on parle alors de message queuing), le contrôle que l’on effectue sur le middleware peut permettre de simuler le synchronisme ou les conversations, grâce aux notions de priorités ou de gestion de files d’attente par des événements.
Or, les middlewares orientés messages ont déjà fait leurs preuves depuis quelques temps déjà (comme l’offre MQSeries d’IBM disponible depuis au moins quinze ans). Ils connaissent un renouveau depuis que l’infrastructure Java intègre son propre MOM avec JMS (Java Messages Services) et que MSMQ est fortement fortement intégré à la plateforme dotNet.
Des start-up et un nouveau concept
On assiste en ce moment à l’apparition d’une nouvelle offre de solutions mixant les avantages des Web Services, des connecteurs (comme JCA), des middlewares messages (comme JMS) et combinant le tout dans une infrastructure d’intégration et de gestion appelée ESB pour Enterprise Services Bus. Cette nouvelle offre est évidemment portée par une nouvelle génération de start-ups comme Cape Clear, Sonic Software, Kenemea, SpiritSoft … (mais on retrouve aussi des éditeurs connus comme Iona et Software AG dans ce nouveau wagon).
Les partisans de cette nouvelle approche insistent sur les avantages en terme de montée en charge et de tolérance aux pannes d’une structure organisée en bus (les modules sont présents sur chaque serveur du système d’information et fonctionnent de manière décentralisée) par opposition au principe du hub qui caractérise les solutions des acteurs habituels de l’EAI. D’autres acteurs bien établis comme IBM ont déjà annoncé leurs intentions de se lancer eux aussi dans l’offre de solutions ESB et le Gartner Group présente l’ESB comme une vague de fond.
La question du « middleware d’entreprise » en passe d’être résolue ?
Au-delà de la problématique d’EAI, la question du middleware permettant de « fluidifier » les échanges entre serveurs s’est toujours posée et a suscité de nombreux affrontements par le passé, tant sur le plan des offres que sur les architectures.
Aujourd’hui, il semble bien que la combinaison des Web Services et des MOMs permettent enfin de déboucher sur une solution simple et utilisable à l’intérieur du firewall. Reste à trouver celle qui permettra de faire de même à l’extérieur du firewall …