Avis de décès des SOA : réaction de l’Open Group
janvier 14, 2009 6:32 Architecture/MiddlewareVoilà des années qu’on rabache que les architectures orientées services sont avant tout… une question d’architecture. Or l’architecture des SI est une discipline qui existait avant que ne soit forgé le terme SOA et qui lui survivra. Fallait-il obligatoirement ce buzz déclenché par Ann Thomas Manes avec son "SOA is dead" pour qu’on en arrive à réaffirmer cette évidence ? En tout cas, cela sonne comme une revanche des architectes, et la réaction d’Eric Boulay, représentant de l’Architecture Forum de l’Open Group en France, le montre bien !
En tant que représentant de l’architecture forum de l’Open Group, je tenais à réagir très positivement au message d’Ann Thomas Manes.
L’article d’Ann Thomas Manes a le mérite de mettre le doigt là où ça fait mal et de proposer le bon remède : les SI ont besoin de réflexion architecturale.
1- peut-on considérer que le rôle de la DSI est uniquement de développer consciencieusement une solution (un projet) en réponse à un métier qui en apporte le financement et l’expression de besoin ?
2- tout projet transverse est-il devenu impossible faute de financement ?
La réponse à ces deux questions est bien évidemment non …pour autant les directions générales et les directions métiers ne donnent pas un blanc-seing aux DSI. Elles expriment de nouveaux besoins d’offres croisées, de sécurité ou de mise en conformité, de partages de données, de mutualisation de services… ou de coopérations entre services, entre filiales ou avec des partenaires.
Chacun de ces besoins et bien d’autres (rationalisation, déploiement massif et économies d’échelle) passent par une transformation et une analyse d’impact reposant sur les vues architecturales du SI … elle passe surtout par l’organisation efficace de la coopération entre des personnes qui ont chacune un avis, un intérêt ou un besoin.
C’est le propre de la démarche d’architecture d’entreprise sur laquelle l’Open Group travaille depuis 10 ans de faire en sorte que SOA, l’urbanisme et l’architecture ne soient plus considérés uniquement comme des débats ou des querelles d’experts techniques mais comme une voie de management qui organise la coopération et la bonne compréhension de toutes les parties prenantes du SI. A la clé, le bon usage des réflexions architecturales pour prendre en compte l’intérêt de l’entreprise dans les phases de décision de lancement de projets et dans la gouvernance et le pilotage de ces projets.
La question n’est donc pas d’arrêter le SOA mais de penser et de construire l’évolution des SI en prenant en compte l’ensemble des points de vues fonctionnels, applicatifs et techniques… c’est un enjeu de management pour lequel les technologies SOA et les modèles d’urbanisme et d’architecture seront bien utiles.
Sur le même sujet, voir aussi la réaction de Scort et celle de Vistali .
janvier 15th, 2009 at 17:50
Bonjour Olivier, Eric (Arismore) et Marc (Vistali)
On peut pas dire que j’avais pas prévenu… Honte à nos cabinets de conseil qui sont aussi médiocres que la moyenne de la profession. Je ne suis pas donneur de leçon mais quand même ! Qui pouvait croire qu’une dose de services et de BPM sur des legacy en fin de vie allait changer la donne (voir notre approche S-IT-A avec SOA de surface et de refonte). Quand j’osai prononcer le mot de refonte on me regardait de manière louche… Et que dire de ces méthodes propriétaires que la plupart des cabinets de conseil s’acharnent à proposer et qui freinent inutilement notre profession. Honte à eux qu’il soit petit ou grand cabinet !
Maintenant c’est l’EA qui fait surface… Honte à nous si nous pensons que l’EA est la réponse. Si le TOGAF et l’Open Group est la solution nous allons droit dans le mur : des meilleurs pratiques techniques en vrac et le tour serait joué ?
Une seule posture est possible pour reprendre en mains les SI. Il faut se poser la question de la valorisation patrimoniale du système d’information, c’est à dire ses actifs incarnés par les données de référence (MDM), les règles métier (BRMS) et les processus (BPM). L’EA est de l’ordre de l’action tactique à la main des informaticiens, les référentiels sont stratégiques à la main des métiers.
Tant que les informaticiens continueront à coder en dur les données de référence, les règles et les processus rien ne changera.
La communauté Sustainable IT Architecture se réunit le 30 Avril prochain sur ce thème et mettra une fois de plus les pieds dans le plat.
Amicalement
Pierre Bonnet
pierre.bonnet@orchestranetworks.com
janvier 16th, 2009 at 12:56
Bonjour
Je suis d’accord avec la première partie du commentaire d’Eric boulay. La prise en main des entreprises par des financiers nous empèche de faire notre travail d’architecte d’entreprise (urbanisation au niveau fonctionnel, applicatif et technique).
Enterprise est basée sur des processus transverses, mais la DSi à trop souvent des budgets en silos, par projets, par BU. D’ailleurs, si on pousse le raisonnement jusqu’au bout, le fait même qu’il existe une DSi est un problème en soi. cela induit un fossé entre ce qui est informatique ou pas, entre MOA et MOE.
Aucune BU ne veut payer le MDM, ni les etudes d’urbanisation et de refonte. Sauf si c’est au coeur de leur Metier, ou qu’ils n’ont plus le choix.
Donc les architectes fontt ce qu’ils peuvent avec les moyens du bord. On utilise trop les EAI, les ETL et … les batchs. Et on laisse coder, beaucoup, car des codeurs on en a sous la main. Des experts MDM moins.
Les projets sont agiles, les budgets sont frigides (réduits, aléatoires, annuels).
L’EA n’est pas de l’ordre du tactique! Ni le SOA! Mais les financiers, CEO, regardent à six mois, voir un an.
Quand aux sociétés de conseil, elles sont souvent contraintes par leurs clients … Donc je ne serais pas aussi catégorique que Pierre sur ce sujet.
J’aimerais que les actifs numériques de l’entreprise soient considérés à leur juste valeur. Je me demande enfin s’il ne faut pas trouver des nouvelles organisations plus agiles et plus intégrées au business pour rempalcer la sacro-sainte DSI.
janvier 16th, 2009 at 14:49
Il est difficile de résister au plaisir, pour les pros du sujet, de dire “je l’avais déjà dit” - exemple tiré de mon blog.
“I fear for those who will promise agility from the sole technical merits of a SOA architecture.”
Et je vous épargne les citations de mes bouquins
Sur le fond il a consensus: ce n’est pas une question de technologie, c’est une question d’architecture de service … donc de métier !
“SOA global” n’est surement pas mort, au contraire, c’est ce que préconise Ann Thomas Manes. Ce qui “serait mort”, c’est la vision limitée et technique. Si c’est vrai, c’est une bonne nouvelle (c’est comme cela que je lis la réaction d’Eric Boulay) mais mes cheveux gris me rendent septique …
“(Dumb) SOA is dead” ? You wished
Maintenant le fond du sujet, c’est que produire une architecture de services métier, c’est du travail … et qu’organiser ses données métiers c’est plus difficile que de mettre en place un ESB.
janvier 18th, 2009 at 20:42
[…] réaction mesurée d’Éric Boulay, représentant de l’Architecture Forum de l’Open Group en France, est de nature à nous […]
janvier 23rd, 2009 at 23:23
Les espoirs déçus du SOA et la fonction manquante (en bref)- comparaison :
Au moment de l’introduction de l’OO et des composants distribués existait un gap énorme entre analyse et programmation, aujourd’hui normalement comblé par la mise en place des architectes techniques.
Au moment de l’introduction du SOA existe un gap énorme entre les espoirs de la DSI sur la réutilisation et l’agilité et les architectes techniques.
Il nous manque les architectes métier qui vont décliner les besoins du business en termes de processus et services.
Arrêtons de parler du SOA, des ESBs, BPMs et autres acronymes.
Mettons en place les business analysts ( architectes métier) qui, en s’appuyant sur une méthodologie adaptée, vont définir les processus et services dans le respect d’une typologie (caractéristiques) et d’une taxonomie (origine / domaine métier). A eux aussi d’identifier les règles et paramètres volatils qu’il sera souhaitable d’externaliser du code en dur, et les données de référence dont il faudra recentraliser la gestion.
Ceci fait, les moyens pour implémenter suivront. Ils sont déjà là pour la plupart mais ne sont pas encore entrer dans les habitudes par crainte des problèmes potentiels en exploitation. C’est le moment de réaliser des POCs pour convaincre.
Le nouveau “fonds de commerce” des SSII sera, je n’en doute pas, après les legacy, le client-serveur et le développement web qui commence tout doucement à s’”essoufler”, la mise en place des processus métier de manière agile (activités dans les processus satisfaites par des services aux comportements aisément modifiables, pour partie en tous les cas, grâce aux technologies de l’agilité). Il est temps de préparer nos équipes pour être présents en temps utile (en sortie de crise ?).
février 19th, 2009 at 17:21
Bonjour Pierre,
J’apprécie à sa juste mesure ta réaction proposant d’oublier les démarches techniques, je me frotte les yeux après t’avoir vu défendre de façon extrement technique SOA et Praxeme !!! pour ce qui est de tirer à boulet rouge sur TOGAF, je t’engage à considérer le travail considérable réalisé par les membres de l’Architecture Forum (les petites et les grandes sociétés … clients ou offreurs IBM, SAP, EDS, Cap, SUN, HP, Infosys, Getronics, … ) et tu comprendras que TOGAF9 est une approche d’architecture d’entreprise qui repose sur un volet descriptif (pas majeur vers la standardisation de l’architecture reposant sur des meta modèles décrivant tous les artefacts intéressant toutes les parties prenantes DG, métiers et SI) et surtout un volet de management qui touche le processus de transformation d’un SI dans lequel les réflexions d’architecture et de gouvernance de la donnée par exemple sont traitées. Ce dernier volet requiert des soft skills et du leadership que certains croient pouvoir remplacer un peu vite par des avis d’expert définitifs.
A ta disposition pour t’éclairer sur ce sujet.
Eric
avril 16th, 2009 at 16:32
Suivant Praxeme depuis le début et TOGAF depuis sa version 7 , je dois reconnaitre que Pierre n’est pas loin de la réalité, mais il est vrai que TOGAF dans sa version 9 contient un volet sur la SOA (très pauvre et assez arrogant) ni technique ni métier.
Sinon “en prenant en compte l’ensemble des points de vues fonctionnels, applicatifs et techniques” c’est vrai lorsque l’on fait des BTP mais force est de constater du haut de ma courte expérience que le SI c’est un ensemble d’outils pour acceler le business si l’on réflechit trois ans pour faire un système de PLM quand un produit reste sur le marché 6 mois c’est dommage. La SOA n’est pas prête de mourrir au contraire mais le legacy non-plus…
avril 18th, 2009 at 10:33
Cela ne va pas de SOA : une mode ou un mode ?
Je suis enseignant en informatique qui essaye de vous suivre et espère que le jargon que vous employez n’est pas là pour
cacher une pauvreté conceptuelle, comme un bel habit mercatique.
<q cite=”http://blog1.lemondeinformatique.fr/ingenierie_logicielle/2009/01/avis-de-deces-des-soa-reaction-de-lopen-group.html#comment-4040″” Arrêtons de parler du SOA, des ESBs, BPMs et autres acronymes
… mais plus loin “POCs”, “legacy”, “soft skills”, “BTP”, “PLM” avant un “gap énorme” émaillent le propos.
Des fossés culturels existent entre certains spécialistes mais ne vous plaignez pas que les directions d’entreprises vous
regardent comme des martiens. Mais tel n’est pas mon propos …
Il était une fois la Fonction (ou la procédure) qui a est à la base
de tout cet empilement. ELle nous a rendu de fiers services (systèmes
d’exploitations UNIX, Windows, Logiciels tels que Word …).
Elle a été créée pour rendre des services et factoriser du code.
On s’est rendu compte qu’hormis certaines fonctions comme sqrt()
les autres n’étaient pas réutilisables.
C’est alors qu’est venu l’Objet. Quand j’explique l’objet je pars de l’expérience
Minutemann (missiles américains) : ce machin logiciel des années 50 était conçu comme des modules autonomes qui s’envoyaient des messages. Le grand SmallTalk a repris le flambeau et eu beaucoup de descendance …
On nous a expliqué que l’objet était stable, réutilisable etc etc. LA panacée.
Mais non, en fait.
Puis est né le Composant logiciel, de plus grande granularité espérant enfin reprendre à son compte la vie des composants industriels …
Manque d’interopérabilité ? Cela ne marche pas bien.
La construction est devenue complexe, ingérable, pas évolutive … tout le contraire
de l’agilité. Que se passe t-il dans le bâtiment quand une construction n’est pas dans les normes et ne peut évoluer ?
C’est alors qu’est arrivé le SOA ou la SOA. Qui va révolutionner tout ça. Mais pas tout de suite, dans 10 ans, quand tout ce chantier sera terminé,
avant le prochain mode de fonctionnement ou la prochaine mode,qui sera peut être des composants distribués parce que l’entité service du SOA
n’aura pas eu une granularité assez forte …
Or, pour moi, le service SOA n’est finalement qu’une Pure Fonction :
bien documentée, avec des paramètres aux types bien définis, qui peut resservir, qui est autonome … Qui est installée dans des bibliothèques partageables, visibles
etc etc..
Voilà enfin mes questions, pour vous les spécialistes :
La boucle est bouclée, nous ressert-on du réchauffé ?
A t-on réellement des exemples d’entreprises qui fonctionnent à 80% SOA avec des retours chiffrés ? Un mode de fonctionnement ou une nouvelle mode ?
Je me demande aussi ce qui se passe au niveau des entreprises en création
(ou alors des entités nouvelles et autonomes de grands groupes) :
peuvent elles passer tout de suite au SOA sachant que pour modéliser,
coder, etc il leur faudra 5 ans ??? Ou bien doivent t-elles
repartir comme leurs ainées : monter un SI classique en “silos” puis bâtir là -dessus un SOA dans 20 ans ?
Faire table rase ?
décembre 27th, 2009 at 1:38
Merci M. Pamart, je suis un ancien étudiant de l’informatique aujourd’hui proche de la retraite. J’essayais de suivre ces propos de martiens et j’ai faillit arrêter ma lecture quand j’ai vu votre intervention. Je vous en remercie, j’y pige enfin quelque chose. Sauf que votre commentaire date de février 2009, on est en décembre 2009 et aucun autre expert ne semble avoir répondu à vos questions…