Les promesses non tenues des projets SOA
Les promesses non tenues des projets SOA
Les promesses non tenues des projets SOA
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
Architecture <strong>SOA</strong> – Module IVa<br />
Reproduction de l’article de 01-Informatique publié sur le site du journal à l’adresse :<br />
http://www.01informatique.fr/infrastructures-stockage-serveurs-116/<strong>projets</strong>-soa-45499/<br />
Enquête de Vincent Berdot, 4 février 2009.<br />
<strong>Les</strong> <strong>promesses</strong> <strong>non</strong> <strong>tenues</strong> <strong>des</strong> <strong>projets</strong> <strong>SOA</strong><br />
Une fois mises en œuvre, les architectures orientées<br />
services ont peu à voir avec les espoirs qu’elles<br />
avaient suscités. Elles restent surtout cantonnées à<br />
<strong>des</strong> <strong>projets</strong> d’intégration technique.<br />
Ce qui marche ou pas<br />
<strong>Les</strong> points de satisfaction<br />
• Maturité de l’infrastructure technique Soap, UDDI, WSDL... la « quincaillerie »<br />
technique proposée par les suites d’infrastructure est mûre pour l’intégration d’applications<br />
standardisée.<br />
• Des <strong>projets</strong> tactiques : ils s’appliquent avec succès dans <strong>des</strong> <strong>projets</strong> locaux. C’est là que la<br />
transposition d’objets métier en services métier est la moins complexe.<br />
<strong>Les</strong> points d'achoppement<br />
• L’approche service sans l’urbanisation : la conception de services métier réutilisables<br />
devient plus complexe lorsque le SI n’a pas été catalogué.<br />
• Un ROI encore à démontrer : difficile à calculer.<br />
• Une réorganisation <strong>des</strong> équipes IT relativement lourde : la mise à jour <strong>des</strong> services<br />
exige la mobilisation d’un très grand nombre de personnes.<br />
Avec son billet publié sur son blog, an<strong>non</strong>çant la mort <strong>des</strong> architectures orientées services<br />
(<strong>SOA</strong>), Anne Thomas Manes, vice-présidente de Burton Group, a déclenché une avalanche de<br />
réactions. Selon elle, ces <strong>SOA</strong>, uniquement appréhendées sous l’angle de la technologie,<br />
mériteraient de disparaître.<br />
Il est vrai que la cote <strong>des</strong> architectures <strong>SOA</strong> a baissé avec les valeurs boursières. Il y a encore<br />
un an, tous les acteurs de l’informatique s’étaient emparés du terme – à défaut de s’en<br />
approprier les concepts – et le déclinaient à l’envi dans leurs présentations et leurs lancements<br />
de produits. Cette époque est révolue.<br />
Ce terme serait devenu une coquille vide voire un gros mot. Qu’on se rassure, c’est bien<br />
l’utilisation de cet acronyme (Service-oriented architecture) qui est remis en cause, et <strong>non</strong> son<br />
principe. Le débat lancé par Anne Thomas Manes a le mérite de révéler un malaise qui<br />
couvait depuis plusieurs mois. Il tient du décalage trop criant entre les <strong>promesses</strong><br />
révolutionnaires avancées par les promoteurs de ce type d’architecture et les résultats sur le<br />
terrain. En effet, qu’ils se soient soldés par <strong>des</strong> succès ou <strong>des</strong> échecs, ces <strong>projets</strong> ne font pas,<br />
ou si peu, appel à <strong>des</strong> « processus transversaux », à <strong>des</strong> « services métiers réutilisables »,<br />
- 1 / 4 -
encore moins à <strong>des</strong> « architectures évolutives ». Ces éléments étaient pourtant au cœur <strong>des</strong><br />
<strong>promesses</strong>. <strong>Les</strong> architectures orientées services devaient casser les approches par silos,<br />
autrement dit la logique applicative, et les remplacer par <strong>des</strong> processus faisant intervenir <strong>des</strong><br />
composants métier mutualisés par les différentes divisions de l’entreprise. Elles promettaient<br />
également de dissocier cette logique métier de la cuisine technique qui sert à les mettre en<br />
œuvre.<br />
Seulement, dans la pratique, ces architectures répondent la plupart du temps à une logique<br />
avant tout… technique. Quoi de plus naturel puisqu’elles ont d’abord été promues par <strong>des</strong><br />
fournisseurs de middleware. « <strong>Les</strong> entreprises exploitent surtout les fondements techniques<br />
<strong>des</strong> architectures <strong>SOA</strong>. Elles ont la même approche qu’avec l’EAI (intégration d’applications<br />
d’entreprise), sauf qu’elles remplacent leurs connecteurs propriétaires par <strong>des</strong> services<br />
web », explique Stéphane Dao, consultant chez Devoteam. Souvent réalisés dans l’urgence,<br />
ces <strong>projets</strong> sont avant tout constitués de services techniques développés sans réel souci de<br />
réutilisation. Mais ils ont au moins le mérite d’exister et, pour beaucoup, de fonctionner.<br />
Pourquoi cette réutilisation de services métier est-elle si difficile à obtenir ? « Le concept de<br />
mutualisation de composants est apparu bien avant les architectures orientées services,<br />
avance Cyrille Leclerc, consultant chez Xebia, société de conseil spécialisée dans les<br />
middlewares Java. Il existe depuis <strong>des</strong> années avec Corba, les EJB ou les objets<br />
COM/DCOM. Ces modèles, qui s’adressent aux techniciens, restent complexes à mettre en<br />
œuvre. »<br />
Une simplicité aux effets pervers<br />
<strong>Les</strong> architectures de type <strong>SOA</strong> reprennent ces fondements en y apportant deux notions<br />
supplémentaires : la simplicité (à travers la standardisation de Soap, WSDL…) et la globalité.<br />
« Ces architectures, à en croire ses apôtres, ont vocation à être étendues à tout le système<br />
d’information. C’est un argument classique quand on souhaite justifier une innovation : on<br />
joue la carte de la rupture totale », rapporte Olivier Mallassi, consultant chez Octo<br />
Technology. C’est précisément l’effet pervers de cette simplicité qui a donné lieu à bon<br />
nombre de dérives. On ne compte plus les organisations dont les départements ont déployé ici<br />
et là <strong>des</strong> services sans aucune concertation. « Sans même parler de réutilisation, ces mises en<br />
œuvre négligent bien souvent les questions de qualité ou de typologie de services et<br />
connaissent en retour <strong>des</strong> problèmes de volumétrie et de performance », indique Alain<br />
Helaili, ingénieur chez Dynatrace, éditeur de gestion de performance d’application.<br />
De la même façon « beaucoup d’entreprises masquent avec <strong>des</strong> ESB l’imbroglio de leur<br />
architecture, déplore Jacky Manai, architecte chez Pholème. C’est à l’opposé de la démarche<br />
d’urbanisation qui doit être initiée avant tout déploiement <strong>SOA</strong>. Il n’y aura jamais de<br />
mutualisation de services si l’on ne prend pas le temps de définir les domaines fonctionnels<br />
avec leurs objets métier associés ». L’étape suivante consistant à décliner ces objets métier en<br />
services métier. Simple à dire, extrêmement compliqué à réaliser.<br />
En dépit <strong>des</strong> métho<strong>des</strong> existantes (Praxeme, CBM, Soma) et <strong>des</strong> solutions de cartographie, le<br />
passage de relais entre urbanisation et conception de composants reste encore confus. « Après<br />
avoir conçu leur catalogue d’objets métier, très peu d’entreprises parviennent à en déduire<br />
<strong>des</strong> services réutilisables, recomposables et limités en nombre », rapporte Yves Caseau,<br />
directeur général adjoint de Bouygues Telecom, qui a mis l’opérateur sur les rails <strong>des</strong><br />
architectures orientées services. « Autant cette déduction peut être intuitive pour <strong>des</strong> <strong>projets</strong><br />
locaux, autant à l’échelle de l’entreprise la maturité n’est pas au rendez-vous » précise-t-il.<br />
La mutualisation de services métier n’achoppe pas uniquement lors du <strong>des</strong>ign de<br />
- 2 / 4 -
l’architecture. Elle est également complexe à maintenir dans le temps et pose <strong>des</strong> problèmes<br />
organisationnels. « Dans une architecture <strong>SOA</strong>, lorsqu’un service doit être modifié, il faut<br />
réunir les responsables de l’application, du service, et <strong>des</strong> processus qui en subissent<br />
l’impact. Soit une vingtaine de personnes. C’est incompatible avec <strong>des</strong> prises de décisions<br />
rapi<strong>des</strong> », rapporte un autre responsable de Bouygues Telecom, pour qui ce concept reste<br />
pourtant le seul viable.<br />
Une maintenance complexe<br />
Cette maintenance soulève également <strong>des</strong> écueils techniques, liés à la gestion <strong>des</strong> versions <strong>des</strong><br />
services partagés. « Le rythme d’évolution d’un service doit être calé sur celui de ses<br />
différents clients. Car si son contrat est amené à changer, chaque client doit modifier sa<br />
procédure d’appel, détaille Cyrille Leclerc. La solution consiste à générer plusieurs versions<br />
du même service. » Ce qui ne va pas exactement dans le sens de la simplification… Chez<br />
Octo Technology, on pointe également le besoin de coordination : « Ce type d’architecture<br />
implique de gérer <strong>des</strong> équipes de développement en plus grand nombre, et surtout, ayant <strong>des</strong><br />
rythmes différents », avance Dominique Jocal, architecte senior dans ce cabinet spécialisé.<br />
Cette distorsion existe notamment entre les équipes qui gèrent les services frontaux, souvent<br />
exposés à l’extérieur de l’entreprise et celles en charge <strong>des</strong> services back end qui n’ont pas les<br />
mêmes priorités.<br />
En dépit de la difficulté à mutualiser les services, il serait aberrant d’enterrer les architectures<br />
<strong>SOA</strong> après les avoir autant adulées. L’approche big bang ne fonctionne pas, ou mal ? Place<br />
aux approches pragmatiques, à l’échelle d’un département, d’un processus ou d’une petite<br />
entreprise. Des <strong>projets</strong> locaux qui, s’ils connaissent le succès, s’étendront naturellement à<br />
l’échelle de l’entreprise. L’informatique a toujours été rythmée par <strong>des</strong> <strong>promesses</strong><br />
démesurées, revues à la baisse avec le temps. C’est le cas du décisionnel, quand on<br />
envisageait d’entreposer toutes les données de l’entreprise dans un seul lieu. Ou de la gestion<br />
de contenu, pour laquelle les éditeurs poussaient le concept de référentiel unique. Laissons<br />
donc le temps aux fournisseurs d’architecture <strong>SOA</strong> de pondérer leurs ambitions. Elle entre<br />
seulement dans ses premières années d’implémentations.<br />
Interview : Anne Thomas Manes, vice-présidente de Burton Group<br />
Beaucoup vous accusent de remettre en question les principes de l’architecture <strong>SOA</strong>...<br />
ATM : C’est faux. A la fin de mon billet, j’insiste précisément sur l’importance de cette<br />
architecture. Je dis seulement que les gens devraient davantage se focaliser sur les buts. Car<br />
nombre d’organisations ne sont pas parvenues à démontrer la valeur métier de leur projet. Des<br />
<strong>projets</strong> souvent couronnés de succès, mais qui visent à intégrer <strong>des</strong> applications au niveau<br />
local. Dans ces conditions, il y a peu de chance que les directions leur octroient plus de<br />
budget.<br />
Une fois ce type d’architecture choisie, quelles sont les conséquences du passage à la<br />
pratique ?<br />
ATM : La déployer ne commence pas avec le choix d’un ESB, d’un référentiel de services ou<br />
d’un mode de communication. Elle exige en revanche une réelle transformation du système<br />
d’information avec une réduction du nombre d’applications et un bouleversement<br />
organisationnel. Ce qui implique souvent le changement du DSI en place. Car il est plus facile<br />
de tout faire chambouler par un nouvel arrivant dont c’est le mandat. Si vous voulez <strong>des</strong><br />
résultats spectaculaires, vous devez faire <strong>des</strong> changements spectaculaires...<br />
- 3 / 4 -
L'avis de l'éditeur, de l'utilisateur et de l'analyste<br />
L'éditeur : Hubert Lalanne, architecte <strong>SOA</strong> et Distinguished Engineer chez IBM<br />
« L’urbanisation du système passe avant l’architecture <strong>SOA</strong> »<br />
« En quelques années, nous sommes passés d’un monde où les clés du système<br />
d’information étaient confiées aux applications à un modèle reposant sur les<br />
vertus de l’infrastructure et d’une architecture en composants et domaines<br />
applicatifs. De cette urbanisation naît ou <strong>non</strong> la nécessité de <strong>projets</strong> <strong>SOA</strong> pour<br />
gérer les problèmes d’interfaces. <strong>Les</strong> difficultés portent donc sur cette<br />
urbanisation, parfois négligée. Ce type d’architecture connaît les problèmes liés à ses<br />
premières implantations sur le terrain. Des problèmes dus par exemple à la sémantique <strong>des</strong><br />
services ou à leur variabilité. Nous connaissons trois types de <strong>projets</strong>. <strong>Les</strong> uns sont<br />
techniques, liés à <strong>des</strong> changements protocolaires. <strong>Les</strong> autres sont locaux. Ils portent sur la<br />
modification d’un processus. <strong>Les</strong> troisièmes, plus rares, touchent toute l’entreprise. »<br />
L'utilisateur : Christophe Juillet, responsable technique du projet SGE (système de<br />
gestion <strong>des</strong> échanges) d’ERDF<br />
« La redondance de service a un impact sur la maintenance »<br />
« Nous avons débuté notre virage <strong>SOA</strong> en 2005. Il nous fallait à l’époque bâtir<br />
une infrastructure de services dans le cadre de l’ouverture du marché de<br />
l’électricité, effective le 1er juillet 2007. Le projet a été achevé dans les temps,<br />
mais dans l’urgence. Avec plus de délai, nous aurions mieux modélisé notre<br />
système d’information. Nous avons commencé la phase de développement<br />
alors même que les métiers n’avaient pas fini leurs spécifications. Par ailleurs, les équipes<br />
techniques travaillaient en parallèle sans trop se concerter sur la granularité et la dépendance<br />
<strong>des</strong> services. Ceci n’a pas eu d’incidence sur la mise en production et le fonctionnement. En<br />
revanche, cette redondance de services représente un surcoût en termes de maintenance. Nous<br />
réajustons le tir progressivement. »<br />
L'analyste : Massimo Pezzini, analyste chez Gartner<br />
« Cette discussion sur la mort supposée <strong>des</strong> <strong>SOA</strong> n’a pas de sens »<br />
« La dernière étude que nous avons réalisée sur ce sujet indique qu’en Europe,<br />
65 % <strong>des</strong> entreprises, quelle que soit leur taille, ont déployé <strong>des</strong> <strong>projets</strong> <strong>SOA</strong>,<br />
techniques ou métier. Même si ces chiffres ont été obtenus avant la crise, ils<br />
témoignent de la forte pénétration de ce type d’architecture. Son problème<br />
fondamental est son retour sur investissement, incontestable mais qui prend<br />
souvent beaucoup de temps. Peut-être a-t-on pris conscience <strong>des</strong> difficultés <strong>des</strong> architectures<br />
orientées services avec les premières implémentations. Peut-être également que les éditeurs<br />
ont survendu leur middleware. Je ne vois aucune raison pour remettre en cause ces <strong>projets</strong><br />
<strong>SOA</strong>. Chaque technologie aujourd’hui passée dans les mœurs, a connu une phase de doute.<br />
Ce fut le cas pour XML ou Java, par exemple. »<br />
- 4 / 4 -