Les promesses non tenues des projets SOA

Architecture SOA – Module IVa
Reproduction de l’article de 01-Informatique publié sur le site du journal à l’adresse :
http://www.01informatique.fr/infrastructures-stockage-serveurs-116/projets-soa-45499/
Enquête de Vincent Berdot, 4 février 2009.
Les promesses non tenues des projets SOA
Une fois mises en œuvre, les architectures orientées
services ont peu à voir avec les espoirs qu’elles
avaient suscités. Elles restent surtout cantonnées à
des projets d’intégration technique.
Ce qui marche ou pas
Les points de satisfaction
• Maturité de l’infrastructure technique Soap, UDDI, WSDL... la « quincaillerie »
technique proposée par les suites d’infrastructure est mûre pour l’intégration d’applications
standardisée.
• Des projets tactiques : ils s’appliquent avec succès dans des projets locaux. C’est là que la
transposition d’objets métier en services métier est la moins complexe.
Les points d'achoppement
• L’approche service sans l’urbanisation : la conception de services métier réutilisables
devient plus complexe lorsque le SI n’a pas été catalogué.
• Un ROI encore à démontrer : difficile à calculer.
• Une réorganisation des équipes IT relativement lourde : la mise à jour des services
exige la mobilisation d’un très grand nombre de personnes.
Avec son billet publié sur son blog, annonçant la mort des architectures orientées services
(SOA), Anne Thomas Manes, vice-présidente de Burton Group, a déclenché une avalanche de
réactions. Selon elle, ces SOA, uniquement appréhendées sous l’angle de la technologie,
mériteraient de disparaître.
Il est vrai que la cote des architectures SOA a baissé avec les valeurs boursières. Il y a encore
un an, tous les acteurs de l’informatique s’étaient emparés du terme – à défaut de s’en
approprier les concepts – et le déclinaient à l’envi dans leurs présentations et leurs lancements
de produits. Cette époque est révolue.
Ce terme serait devenu une coquille vide voire un gros mot. Qu’on se rassure, c’est bien
l’utilisation de cet acronyme (Service-oriented architecture) qui est remis en cause, et non son
principe. Le débat lancé par Anne Thomas Manes a le mérite de révéler un malaise qui
couvait depuis plusieurs mois. Il tient du décalage trop criant entre les promesses
révolutionnaires avancées par les promoteurs de ce type d’architecture et les résultats sur le
terrain. En effet, qu’ils se soient soldés par des succès ou des échecs, ces projets ne font pas,
ou si peu, appel à des « processus transversaux », à des « services métiers réutilisables »,
- 1 / 4 -

encore moins à des « architectures évolutives ». Ces éléments étaient pourtant au cœur des
promesses. Les architectures orientées services devaient casser les approches par silos,
autrement dit la logique applicative, et les remplacer par des processus faisant intervenir des
composants métier mutualisés par les différentes divisions de l’entreprise. Elles promettaient
également de dissocier cette logique métier de la cuisine technique qui sert à les mettre en
œuvre.
Seulement, dans la pratique, ces architectures répondent la plupart du temps à une logique
avant tout… technique. Quoi de plus naturel puisqu’elles ont d’abord été promues par des
fournisseurs de middleware. « Les entreprises exploitent surtout les fondements techniques
des architectures SOA. Elles ont la même approche qu’avec l’EAI (intégration d’applications
d’entreprise), sauf qu’elles remplacent leurs connecteurs propriétaires par des services
web », explique Stéphane Dao, consultant chez Devoteam. Souvent réalisés dans l’urgence,
ces projets sont avant tout constitués de services techniques développés sans réel souci de
réutilisation. Mais ils ont au moins le mérite d’exister et, pour beaucoup, de fonctionner.
Pourquoi cette réutilisation de services métier est-elle si difficile à obtenir ? « Le concept de
mutualisation de composants est apparu bien avant les architectures orientées services,
avance Cyrille Leclerc, consultant chez Xebia, société de conseil spécialisée dans les
middlewares Java. Il existe depuis des années avec Corba, les EJB ou les objets
COM/DCOM. Ces modèles, qui s’adressent aux techniciens, restent complexes à mettre en
œuvre. »
Une simplicité aux effets pervers
Les architectures de type SOA reprennent ces fondements en y apportant deux notions
supplémentaires : la simplicité (à travers la standardisation de Soap, WSDL…) et la globalité.
« Ces architectures, à en croire ses apôtres, ont vocation à être étendues à tout le système
d’information. C’est un argument classique quand on souhaite justifier une innovation : on
joue la carte de la rupture totale », rapporte Olivier Mallassi, consultant chez Octo
Technology. C’est précisément l’effet pervers de cette simplicité qui a donné lieu à bon
nombre de dérives. On ne compte plus les organisations dont les départements ont déployé ici
et là des services sans aucune concertation. « Sans même parler de réutilisation, ces mises en
œuvre négligent bien souvent les questions de qualité ou de typologie de services et
connaissent en retour des problèmes de volumétrie et de performance », indique Alain
Helaili, ingénieur chez Dynatrace, éditeur de gestion de performance d’application.
De la même façon « beaucoup d’entreprises masquent avec des ESB l’imbroglio de leur
architecture, déplore Jacky Manai, architecte chez Pholème. C’est à l’opposé de la démarche
d’urbanisation qui doit être initiée avant tout déploiement SOA. Il n’y aura jamais de
mutualisation de services si l’on ne prend pas le temps de définir les domaines fonctionnels
avec leurs objets métier associés ». L’étape suivante consistant à décliner ces objets métier en
services métier. Simple à dire, extrêmement compliqué à réaliser.
En dépit des méthodes existantes (Praxeme, CBM, Soma) et des solutions de cartographie, le
passage de relais entre urbanisation et conception de composants reste encore confus. « Après
avoir conçu leur catalogue d’objets métier, très peu d’entreprises parviennent à en déduire
des services réutilisables, recomposables et limités en nombre », rapporte Yves Caseau,
directeur général adjoint de Bouygues Telecom, qui a mis l’opérateur sur les rails des
architectures orientées services. « Autant cette déduction peut être intuitive pour des projets
locaux, autant à l’échelle de l’entreprise la maturité n’est pas au rendez-vous » précise-t-il.
La mutualisation de services métier n’achoppe pas uniquement lors du design de
- 2 / 4 -

l’architecture. Elle est également complexe à maintenir dans le temps et pose des problèmes
organisationnels. « Dans une architecture SOA, lorsqu’un service doit être modifié, il faut
réunir les responsables de l’application, du service, et des processus qui en subissent
l’impact. Soit une vingtaine de personnes. C’est incompatible avec des prises de décisions
rapides », rapporte un autre responsable de Bouygues Telecom, pour qui ce concept reste
pourtant le seul viable.
Une maintenance complexe
Cette maintenance soulève également des écueils techniques, liés à la gestion des versions des
services partagés. « Le rythme d’évolution d’un service doit être calé sur celui de ses
différents clients. Car si son contrat est amené à changer, chaque client doit modifier sa
procédure d’appel, détaille Cyrille Leclerc. La solution consiste à générer plusieurs versions
du même service. » Ce qui ne va pas exactement dans le sens de la simplification… Chez
Octo Technology, on pointe également le besoin de coordination : « Ce type d’architecture
implique de gérer des équipes de développement en plus grand nombre, et surtout, ayant des
rythmes différents », avance Dominique Jocal, architecte senior dans ce cabinet spécialisé.
Cette distorsion existe notamment entre les équipes qui gèrent les services frontaux, souvent
exposés à l’extérieur de l’entreprise et celles en charge des services back end qui n’ont pas les
mêmes priorités.
En dépit de la difficulté à mutualiser les services, il serait aberrant d’enterrer les architectures
SOA après les avoir autant adulées. L’approche big bang ne fonctionne pas, ou mal ? Place
aux approches pragmatiques, à l’échelle d’un département, d’un processus ou d’une petite
entreprise. Des projets locaux qui, s’ils connaissent le succès, s’étendront naturellement à
l’échelle de l’entreprise. L’informatique a toujours été rythmée par des promesses
démesurées, revues à la baisse avec le temps. C’est le cas du décisionnel, quand on
envisageait d’entreposer toutes les données de l’entreprise dans un seul lieu. Ou de la gestion
de contenu, pour laquelle les éditeurs poussaient le concept de référentiel unique. Laissons
donc le temps aux fournisseurs d’architecture SOA de pondérer leurs ambitions. Elle entre
seulement dans ses premières années d’implémentations.
Interview : Anne Thomas Manes, vice-présidente de Burton Group
Beaucoup vous accusent de remettre en question les principes de l’architecture SOA...
ATM : C’est faux. A la fin de mon billet, j’insiste précisément sur l’importance de cette
architecture. Je dis seulement que les gens devraient davantage se focaliser sur les buts. Car
nombre d’organisations ne sont pas parvenues à démontrer la valeur métier de leur projet. Des
projets souvent couronnés de succès, mais qui visent à intégrer des applications au niveau
local. Dans ces conditions, il y a peu de chance que les directions leur octroient plus de
budget.
Une fois ce type d’architecture choisie, quelles sont les conséquences du passage à la
pratique ?
ATM : La déployer ne commence pas avec le choix d’un ESB, d’un référentiel de services ou
d’un mode de communication. Elle exige en revanche une réelle transformation du système
d’information avec une réduction du nombre d’applications et un bouleversement
organisationnel. Ce qui implique souvent le changement du DSI en place. Car il est plus facile
de tout faire chambouler par un nouvel arrivant dont c’est le mandat. Si vous voulez des
résultats spectaculaires, vous devez faire des changements spectaculaires...
- 3 / 4 -

L'avis de l'éditeur, de l'utilisateur et de l'analyste
L'éditeur : Hubert Lalanne, architecte SOA et Distinguished Engineer chez IBM
« L’urbanisation du système passe avant l’architecture SOA »
« En quelques années, nous sommes passés d’un monde où les clés du système
d’information étaient confiées aux applications à un modèle reposant sur les
vertus de l’infrastructure et d’une architecture en composants et domaines
applicatifs. De cette urbanisation naît ou non la nécessité de projets SOA pour
gérer les problèmes d’interfaces. Les difficultés portent donc sur cette
urbanisation, parfois négligée. Ce type d’architecture connaît les problèmes liés à ses
premières implantations sur le terrain. Des problèmes dus par exemple à la sémantique des
services ou à leur variabilité. Nous connaissons trois types de projets. Les uns sont
techniques, liés à des changements protocolaires. Les autres sont locaux. Ils portent sur la
modification d’un processus. Les troisièmes, plus rares, touchent toute l’entreprise. »
L'utilisateur : Christophe Juillet, responsable technique du projet SGE (système de
gestion des échanges) d’ERDF
« La redondance de service a un impact sur la maintenance »
« Nous avons débuté notre virage SOA en 2005. Il nous fallait à l’époque bâtir
une infrastructure de services dans le cadre de l’ouverture du marché de
l’électricité, effective le 1er juillet 2007. Le projet a été achevé dans les temps,
mais dans l’urgence. Avec plus de délai, nous aurions mieux modélisé notre
système d’information. Nous avons commencé la phase de développement
alors même que les métiers n’avaient pas fini leurs spécifications. Par ailleurs, les équipes
techniques travaillaient en parallèle sans trop se concerter sur la granularité et la dépendance
des services. Ceci n’a pas eu d’incidence sur la mise en production et le fonctionnement. En
revanche, cette redondance de services représente un surcoût en termes de maintenance. Nous
réajustons le tir progressivement. »
L'analyste : Massimo Pezzini, analyste chez Gartner
« Cette discussion sur la mort supposée des SOA n’a pas de sens »
« La dernière étude que nous avons réalisée sur ce sujet indique qu’en Europe,
65 % des entreprises, quelle que soit leur taille, ont déployé des projets SOA,
techniques ou métier. Même si ces chiffres ont été obtenus avant la crise, ils
témoignent de la forte pénétration de ce type d’architecture. Son problème
fondamental est son retour sur investissement, incontestable mais qui prend
souvent beaucoup de temps. Peut-être a-t-on pris conscience des difficultés des architectures
orientées services avec les premières implémentations. Peut-être également que les éditeurs
ont survendu leur middleware. Je ne vois aucune raison pour remettre en cause ces projets
SOA. Chaque technologie aujourd’hui passée dans les mœurs, a connu une phase de doute.
Ce fut le cas pour XML ou Java, par exemple. »
- 4 / 4 -