Le style d’architecture SOA

Invité comme conférencier à la réunion annuelle des directions informatiques du Ministère de l’Éducation Nationale qui se tenait à Cannes, j’ai pu mesurer – une fois de plus – le fossé qui se creuse entre d’une part la manière dont on parle des systèmes d’information, dont on vend des projets informatiques, et d’autre part la manière dont on réalise les projets informatiques.


Le conférencier externe qui me précédait lors de cet événement venait parler de la SOA (Service Oriented Architecture). Quant à moi, je parlais juste après lui des architectures ROA, de REST et du Cloud Computing. Autant dire que, sur beaucoup de points, nos discours étaient dissonants voire contradictoires pour l’auditoire.
Aussi, la question qui revenait au moment du déjeuner était :

« Mais alors, faut-il faire de la SOA ou pas ? »

Ma conviction est que la seule chose que propose une démarche SOA c’est un dessin, celui des sempiternels blocs qui s’agencent sur un socle EAI ou ESB, avec un moteur de règle magique qui traîne dans un coin. Ce dessin est une sorte de fantasme récurrent depuis plus d’une décennie dans le mode de l’informatique de gestion d’entreprise. L’illusion repose sur ce principe très simple que, pour masquer une complexité, il faut la mettre dans une boîte. Bien sûr, cela ne résout rien, mais cela repose l’œil de voir toutes ces petites cases qui s’agencent à merveille dans le format d’un slide de power point. A un tel point que je ne suis pas loin de penser que la SOA, qui n’est pas une architecture au sens strict, relève plutôt d’une « architecture power point » : comme si le support et le format de communication conditionnait l’avenir d’un système d’information.

Je suis donc de plus en plus convaincu que la SOA est finalement un style d’architecture, pour reprendre l’expression de Fielding, mais dont les contraintes qui s’expriment n’ont rien à voir avec la réalité d’un système d’information mais bien plutôt avec les contraintes du support de présentation qu’est le slide de power point.

Pour éclairer ce point, il faut jeter un regard en arrière sur les schèmes utilisés par les vendeurs de logiciels, et qui sont toujours utilisés, encore aujourd’hui.

Ainsi, lorsqu’il y a plusieurs années, les premiers éditeurs proposant des solutions d’EAI (Entreprise Application Integration) venaient présenter les bénéfices de leur logiciel aux Directions des Systèmes d’information, voici ci-après les schémas qu’ils utilisaient.

Tout d’abord ils présentaient les flux de données que s’échangent les applications entre elles :

Forcément, ce plat de spaghetti est le cauchemar des responsables des systèmes d’information : çà part de tous les côtés et, pour maintenir en état et gérer tous ces échanges, ce n’est pas une sinécure.
Mais tout çà c’était avant ! Avant que les solutions d’EAI (aujourd’hui marketée en ESB : Enterprise Service Bus, dans le cadre des démarches SOA) n’arrivent en vous présentant cette formidable image :

(j’ai pris ces images au hasard, il y en a des milliers similaires sur le Web)

Avec une telle représentation c’est le calme, l’apaisement et la rationnalité qui s’imposent enfin. Le bus d’entreprise (ESB) permet « simplement » de brancher (to plug, comme plug and play) chaque application du système d’information afin qu’elle puisse dialoguer simplement avec le reste du système d’information.

Le couple formé par ces deux images possède un pouvoir de conviction et d’adhésion qui me surprend toujours. Il semble inusable. Il a été décliné initialement avec Tuxedo pour les middleware orientés transactionnel, puis avec MQseries pour les Middleware orientés Message, puis avec les solutions d’EAI, et après par les Solutions de SOA, il est en train d’être repris au niveau des données avec les démarches de Master Data Management, on le retrouve dans l’UIMA de IBM pour le Text Mining et, pour finir, Google vient de nous le resservir avec son API (pas) OPEN Social :

Mais, en vérité, le fondement de l’interopérabilité, dans un système d’information, ce n’est pas tant que les applications ou les services se parlent, c’est que les données soient ouvertes. Si les données n’étaient pas encapsulées dans les applications, l’image magique du Bus et des démarches orientées services perdraient tout leur intérêt.

Le principe de ce schéma est toujours le même : placer à la périphérie les éléments du système d’informations (applications, services, données, réseaux sociaux, etc), puis poser la pièce maîtresse au centre, le rouage ultime, qui va permettre d’articuler tout ce petite monde. En cela le schéma va plonger dans notre subconscient, reproduisant ici le système solaire, ou là le moyeux la roue. Parfois aussi le temple ou la pyramide, quand on fait appel à des modèles non concentriques.

Mais ce que ne dit pas ce schème de représentation, c’est précisément ce qu’il exclut :

  • il ne dit pas que la solution est loin d’être magique : à défaut de « solution » on a plutôt une boîte à outil qui permet de relier les fils entre eux, mais il faut se taper tout le boulot.
  • il ne dit pas qu’il exclut de facto tout ce qui n’est pas relié au bus. En reliant des applications au service, on enferme encore plus ses applications, ce qui rend le système d’information endogène : l’intégration interne se paye par une exclusion de l’entreprise aux données et aux services externes.

Mon sentiment peut paraître surprenant mais, eu égard à ces schémas de représentations, je pense que le schéma des spaghetti n’est pas une mauvaise chose en soi. Voilà pourquoi :

  • parce qu’on ne voit que les machines et pas les acteurs et les utilisateurs dans ce schéma. Ou sont les utilisateurs ?
  • on cherche à faire parler toutes les applications avec toutes les autres applications, mais pourquoi donc ? C’est comme si l’on s’épuisait à imaginer tout le champ des possibles en s’imposant cette contrainte un peu folle de vouloir tout connecter avec tout.
  • les données échangées ne sont comprises qu’au niveau des serveurs et pas au niveau des clients, la logique des mash-up, qui marche, permet les échanges au niveau des postes clients et pas au niveau des serveurs et des applications elles-mêmes. Les clients légers ou riches des architectures actuelles sont purement absents.

Ce qui se dégage de toute cette histoire c’est que le Business Model du software est très souvent un modèle qui consiste à identifier une douleur dans le Système d’Information  pour proposer une solution logicielle à cette douleur. Le logiciel joue ici son rôle de pharmakon, de médicament. Et son périmètre dans le système d’information est proportionnel à la taille de la tumeur qu’il est sensé traiter. Il est généralement vendu et « marketé » comme une boîte noire avec en entrée les problèmes et en sortie les solutions. Mais entre ? Que se passe-t-il ? Ouvrons le capot et regardons : que voit-on ? Tout d’abord que la source du mal n’a pas été éradiquée, elle est toujours là. On ne soigne que les symptômes du mal, pas le mal lui-même.

A force de reproduire ce schéma depuis des années, les grands systèmes d’information deviennent, bien souvent, proprement monstrueux. Car plus de logiciel demande toujours plus de logiciel : le code appelle le code. Mais qu’est ce qui a accéléré ce mouvement ? Un défaut initial , ou une négligence d’encodage des données manipulées par le code, c’est à dire un défaut d’architecture des données, de la on assiste à une excroissance du code : comme une huître faisant sa perle autour d’une poussière, mais malheureusement la perle en question est ici une tumeur.

Ceux qui prônent les démarches SOA ne sont pas idiots pour autant : ils reconnaissent qu’il n’y a pas vraiment de références significatives sur la mise en oeuvre d’une telle démarche, prennent d’infinies précautions en instant sur le fait qu’une telle démarche prend, à minima, une décennie avant d’aboutir réellement, et admettent que la plupart des projets SOA sont des échecs.

Ce qu’il y a d’intéressant dans leurs discours, c’est qu’ils soutiennent qu’il y a une « SOA de surface », celle qui consiste à croire qu’un logiciel miracle va orchestrer les services web pour « aligner l’IT sur le métier », qui est la cause de la plupart des échecs en matière de SOA. Comment donc appréhender une démarche de SOA afin d’éviter cet écueil ?

« Il ne faut pas commencer par les process et les services mais par les données, disent-ils. La SOA est une chaine de valeur qui commence avec la qualité des données, si ce maillon ne donne pas satisfaction il est illusoire qu’une SOA puisse se mettre en place ».

Étonnante rhétorique pour une démarche d’architecture orientée services qui affirme qu’il faut d’abord commencer par une architecture orienté ressources et données pour arriver à sortir quelque chose qui tient la route ! Pourquoi ne pas commencer directement par la ROA (Architecture Orientée Ressource) comme démarche d’architecture dérivée du style d’architecture REST ?

La raison vient de ce que la finalité des démarches SOA se place toujours sous l’injonction « d’aligner l’IT sur le Business », la SOA est comme prisonnière de ce slogan. Ce qui n’est pas le cas de la ROA dont l’ambition est beaucoup plus pragmatique puisqu’il s’agit simplement d’aligner l’IT sur le Web : ses architectures, ses normes ainsi que ces usages et ses pratiques.

Quand on voit que ce sont essentiellement le secteur des banques et assurances qui s’essaient à ce type de démarche, je suis tenté de penser que la SOA est à l’IT ce que les subprimes ont été à la finance. Et la SOA serait finalement une démarche de titrisation de la piètre qualité des données dans les systèmes d’information pour valoriser des approches abracadabrantesques. Pourquoi vend-on de la SOA finalement, et pourquoi – parfois – çà marche ? Parce que c’est énorme et, comme pour les mensonges, plus c’est énorme et plus çà a de chances de passer.
Cela éclaire également la remarque de Fielding que j’évoquais récemment et que je traduirais volontiers de la manière suivante :

« La conclusion raisonnable de ceci est que la SOA n’est ni style ni une architecture, mais un ensemble d’objectifs qui peuvent être vendus à des DSI dépassés eut égard aux architectures qui seront réellement implémentées. »

In fine, là où je me désolidarise de Fielding c’est que je crois que la SOA est bien un style d’architecture, c’est le style d’architecture documentaire du power point. Certes, cela n’a plus grand chose à voir avec l’informatique, celle qu’on aime, celle qui marche et qui nous donne satisfaction.

C’est *très* bien vu. Deux remarques.

Tout d’abord, je nuancerais le portrait un peu trop manichéen qui ne place dans le paysage que DSI vs commerciaux. Un DSI est conseillé en interne par des gens parfois très compétents qui viennent « du terrain ». Sans prendre la défense de la SOA, loin de là, ROA et REST posent aussi leurs problèmes. Par exemple, ROA et REST sont interdits en tant que Middleware d’un groupe bancaire que je connais un peu, simplement du fait qu’entre le web et les couches basses du SI, la sécurité impose une rupture protocolaire : le même protocole de bout en bout (http) fragiliserai l’ensemble. Il faut aussi écouter ces arguments.

Ensuite, je trouve un peu court (et pas vendeur) de dire que ROA et REST ont l’ambition « simplement d’aligner l’IT sur le Web : ses architectures, ses normes ainsi que ces usages et ses pratiques. » C’est vrai mais ça ne dit pas pourquoi c’est si important. J’avais imaginé un moment la notion d’entreprise sémantique pour tenter d’expliquer ça mais ce n’est pas assez lisible. Il faudrait trouver quelques formules qui expliquent simplement pourquoi c’est fondamental. (C’est une commande pour ton prochain article 😉

[Reply]

C’est de la marketecture.

Tu sais ce qu’il a dans le jolie rectangle nommé ESB au milieu de ton 2eme schéma ? Le premier schéma 😉

[Reply]

@ Charles : Qu’il y ait des architectures de service middleware qui ne se « soumettent » pas à HTTP est tout à fait normal. Aurélien Pelletier avait fait une matrice simple et lisible du positionnement de chacune des architectures :

[Reply]

8 Oct 2008, 10:56
by PONDAVEN Yves-Marie

reply

l’article est très bien.
quelques petits commentaires.

sur le schéma spaghetti, l’erreur des editeurs (et parfois d’autres…) est de tout mélanger : flux au sens fonctionnel et techniques, réseau… et de comparer avec un schéma technique. Le schéma ‘bus’ ou ‘point central’ est vrai du point de vue du réseau mais fonctionnellement j’ai autant de flux (la mutualisation est assez rare en informatique de gestion, ca peut arriver dans l’industrie mais dans ces cas la c’est traitable autrement). J’ai même plus de flux (exemple au lieu de créer mes users dans peoplesoft RH et les envoyer vers l’annuaire donc un flux, j’en ai un de PS vers l’EAI puis de l’EAI vers l’annuaire donc 2 flux !)
Les 2 schémas ne sont pas au même niveau …

pour ce qui concerne le commentaire sur la sécurité… c’est une grave erreur :
1- sur quoi se base t-on pour dire qu’une rupture de protocole améliore la sécurité ? quelle étude ? une référence ? rien …
2 – il vaut mieux un bon protocole sécurisé que n protocoles
3 – la bonne sécurité ne devrait pas consister a complexifier artificiellement mais a faire simple sur des protocoles sécurisés.

[Reply]

@ Yves-Marie : très juste de préciser qu’il y a un empilement d’architectures techniques, applicatives, fonctionnelles, réseaux, etc.
D’accord également avec toi sur l’importance toute relative de la rupture de protocole.

Autre problème avec les architecture de services : elles veulent centraliser tous les services or, avec les web services le nombre de message devient exponentiel, car plus petits et plus discrétisés, et cela devient impossible de les gérer par manque d’interface uniforme comme le permet HTTP.

[Reply]

Il ne faut pas se limiter aux discours marketing de vendeur d’ESB. Il y a vraiment des concepts intéressants à la fois dans le pattern d’architecture SOA et dans la démarche SOA qui est permet une certaine approche du SI. La différence entre ces deux notions pattern SOA et démarche SOA n’est pas souvent faite et est source de beaucoup d’ambiguïtés.

[Reply]

gl3am : pour la discussion sur les patterns SOA, voir la reference:
http://www.eaipatterns.com/docs/SoaPatterns.pdf

Ce qui manque le plus désormais, c’est une démarche REST pour le SI. Qui publie le premier billet sur le sujet ? 😉

[Reply]

10 Oct 2008, 10:01
by Cyril Gambis

reply

C’est intéressant d’avoir une autre vision, mais je suis assez d’accord avec gl3am: il y a des concepts derrière une architecture orientée services qui vont au delà de la présentation d’un vendeur d’ESB.

A mon humble avis, il n’y a pas besoin d’ESB, et on peut utiliser du REST pour une architecture SOA, si l’on parle de SOA dans le sens conceptuel (une application devenant une sorte de « mashup » qui fait appel à d’autres entités/modules pour offrir toutes ses fonctionnalités, par opposition aux applications legacy à base de batch et de bases de données centralisées).

REST/SOAP/JMS ou autre, c’est technique; SOA représente aussi une manière d’organiser ses applications (par exemple remise en cause de l’encapsulation pour les langages objets, avec traitements et règles métiers dans les services et échanges de POJO entre services).

[Reply]

Article très intéressant. Je suis d’accord avec Aurélien a propos que l’ESB cache le plat de spagetti. A ce propos, regarder cette vidéo sur le sujet de Martin Fowler: http://www.infoq.com/presentations/soa-without-esb .
A mon avis, tout cela résulte d’une incompréhension et que il n’existe pas de technologie all-in-one (ou one-fit-all) pour une bonne intégration des SI. Il faut utiliser les différentes techologies (SOA/REST/MVC) là ou elles sont efficaces et appropriées. Un petit avantage à REST pour sa simplicité (apparente) et à SOA qui va un peu plus loin que ‘juste’ une technologie comme le souligne à juste titre Cyril.

[Reply]

@Cyril Gambis (et globalement tous les défenseurs de SOA) La différence que relève Christian entre SOA et REST ne repose pas uniquement sur le style d’architecture, mais aussi sur le soin particulier qu’il faut accorder à l’architecture des données indépendamment de tous processus.

SOA est massivement orienté processus et application, le problème de cette approche réside dans le fait qu’il est difficile de faire évoluer le SI en cas d’évolution du modèle de données ou de mashup très complexe entre les données (la démonstration de Christian aurait tout aussi bien pu s’appliquer à un ERP et autre BI). L’ESB ne résoud rien, il ne constitue qu’une verrue, un patch pour essayer de résoudre le problème en continuant de le voir du point de vue des processus.

REST est orienté « ressource », il impose donc par nature une réflexion minimum sur les données en dehors des processus qui exploitent les données (cela ne suffit pas, mais c’est un début).

Le défaut de SOA (et globalement de toutes les conceptions du SI depuis très longtemps) réside dans le peu d’attention qui est portée aux données elles-mêmes. Vous adaptez les données aux besoins, alors qu’une ressource (et pas un objet au sens langage de programmation, je vous en supplie !) a des attributs/propriétés en dehors de toutes utilisations. Le SI de demain, son évolutivité, sa maintenance voire sa pérennisation passe par une séparation entre les données et les applications.

J’ai bien conscience qu’il va falloir désapprendre et que la conception est différente, mais ce changement est plus que nécessaire !!

PS pour Christian : c’est amusant de constater que, sans même se voir, on continue à rester en phase pratiquement à la phrase près…

[Reply]

Bonjour;
Merci pour cet article tres important.
Je voudrai savoir qu’elles sont les autres styles d’architeture logicielles qui existe à part SOA?

[Reply]

[…] (Service Oriented Archtitecture) en privilégiant une archtiecture technique s’appuyant sur SOAP et les Web Services plutôt que sur un style d’archtiecture […]

[…] ce qui a produit le monstre du tunnelling Http et des normes WS-*, et tout cela a culminé avec le matraquage marketing autour de la SOA.La raison en est que, à chaque fois, les DSI appréhendaient les technologies relationnelles comme […]

[…] détecté. Il se produit alors une « excroissance du code », comme le note Christian Fauré6, la technique étant perçue comme un palliatif, un remède qui soigne mais ne guérit pas vraiment […]

16 Jan 2014, 10:20
by JMarc Gomes

reply

Bonjour,

Même si votre exposé date un peu, il est tout a fait d’actualité. Je me bats contre ce faut semblant de simplicité autur de moi, car cela arrange certain de faire comme si cela était simple. D’un point de vue budget et délai du projet, c’est simple aussi leur semble t’il 😉
Je voudrais m’appuyer sur votre article pour faire entendre ce faut semblant de simplicité véhiculé.
Vos images n’apparaisent plus pourriez vous remédier à cela svp. Ou me dire, ou puis je les retrouver.
Merci

[Reply]

Voilà pour les images Jean-Marc, merci de me l’avoir signalé.

[Reply]

[…] enfin, les éditeurs hégémoniques se sont empressés de vendre des implémentations illusoires « clé en… (ritournelle qui est en train d’être rejouée à l’identique pour la WOA et l’API via des […]

 

Répondre à JMarc Gomes Annuler la réponse

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.