Et les mashups dans tout ça ?

Certains billets récents lus au gré des blogs affirment que la SOA serait une discipline désormais rendue complexe par le jeu d'insidieux cabinets de conseil soucieux de récupération à des fins purement mercantiles (j'écris "purement" et non "bassement" car, jusqu'à preuve du contraire, ces sociétés, comme beaucoup d'autres, ont aussi besoin de gagner de l'argent pour continuer à exister). En résumé : le sujet se complique, plus personne n'y comprend rien (d'ailleurs plus personne ne sait l'expliquer), et les fumistes sont les rois du monde. Hum... ce serait faire injure à l'intelligence des DSI de bon nombre d'entreprises, et non des moindres.

L'argument qui revient souvent consiste à prétendre : "Regardez Amazon, eBay, Yahoo. Voilà le modèle à suivre. Simple, pas cher, avec des technologies complètement démystifiées, et des investissements inutiles évités". D'abord, ces entreprises sont parties de rien : pure-players du Web, je pense qu'elles n'avaient pas d'existant à intégrer et donc peu de compromis à faire par rapport à leur vision. C'est plus simple de rester simple. Et puis je serais bien curieux de rencontrer les CIO de ces entreprises pour faire un bilan des investissements et coûts de l'IT après 8 ou 9 ans d'existence, a fortiori quand l'IT est leur unique moyen d'exister. Enfin, ces entreprises sont de grandes communicantes, qui savent vulgariser leur pratique. Cela ne signifie pas que leur pratique est simple.

Regardez le viaduc de Millau. Personne ne contestera la formidable dose d'ingénierie et d'expertise qu'il est nécessaire de cumuler pour réussir une telle construction. Personne ne crie au scandale devant les coûts d'un tel chantier. Pourquoi n'en serait-il pas de même en IT ? Certaines constructions SOA sont complexes et coûteuses. C'est inévitable, quand vous cherchez, comme un grand producteur d'énergie en France, à réguler en temps réel production et consommation pour faire face à toutz variation d'activité, en intégrant client riche .Net et gestionnaire de processus J2EE, "servicisation" de modules Fortran... Il faut de la méthode et de l'ingénierie. Comment faire autrement ? Qui accepterait de se lancer tête baissée dans une telle construction ? Est-ce réellement ce qu'ont fait Amazon, eBay et consorts ?

La dernière tendance en date consiste à dire "les mashups constituent le moyen de rester simple face à une SOA qui perd son âme", donc de faire de la SOA facile et "low cost" (voir à ce sujet le point de vue argumenté d'Olivier Rafal qui s'oppose à cette vision(http://blog1.lemondeinformatique.fr/ingenierie_logicielle/2006/10/pourquoi_oppose.html).
Sur les missions de Visioning où j'étudie avec mes clients les apports de la SOA à leur stratégie et à leur métier, nous menons un atelier de présentation des mashups et nous étudions leur adoption dans le contexte de ce que le client souhaite construire. Les mashups sont une pièce du puzzle SOA. Et l'avenir nous dira si cette pièce a réellement simplifié le domaine ou si elles l'a au contraire rendu encore un petit peu plus complexe.

Le métier d'abord (ne pas se tromper d'ordre)

Je prends l'encart central du Monde Informatique du 5 octobre, consacré aux SOA, à la page III. Paroles d'expert, consacrées à la méthodologie. "Deux approches sont possibles, technique et métier. Dans le premier cas, on cherche à rénover son SI, dans le second, on répond à un besoin d'utilisateurs en couvrant un périmètre en général orienté e-business".

Aïe ! Il me semble que c'est généralement le métier qui tire l'investissement d'innovation. S'il faut donc "premièrement" répondre à quelque chose, c'est d'abord à un besoin métier. La pérénnité d'une technologie, la force d'une organisation, l'émergence d'autres besoins couverts par cette même technologie, enracinent alors celle-ci dans le système informatique et pérénnisent l'investissement.

Heureusement, notre expert se rattrape in extremis. "Quelle que soit la démarche, le moteur doit rester le métier"... c'est bien ce que nous disions. Mais alors, quid des deux approches ? SOA n'est pas une démarche technicienne, mais une démarche portée par l'IT. C'est d'abord au métier qu'elle rend des services. Si la valeur apportée au métier profite ensuite à l'IT, parce qu'elle urbanise notamment le SI, très bien. Mais il ne faut pas se tromper d'ordre : les deux approches sont en réalité complémentaires.

"La première étape [de mise en oeuvre des SOA] relève avant tout de la communication : il faut réunir autour de la table les fonctionnels et les équipes informatiques pour cerner les objectifs, voir comment SOA peut y répondre et voir comment procéder."

Encore un problème d'ordre ! S'agit-il réellement de la "première étape" ? Quels "fonctionnels" vont accepter de s'asseoir "autour de la table" pour discuter de SOA ? Pour quoi faire ? S'il s'agit réellement de "communication" (personnellement j'appellerais cela du conseil), ce ne sont pas les fonctionnels qu'il faut convaincre, mais leurs patrons ! S'il s'agit du démarrage d'un projet, ce n'est certainement pas la "première étape".

Asseyons-nous autour d'une table pour voir si SOA est la bonne techno pour votre projet, non. Comment SOA peut apporter une valeur différenciante à un métier et à une stratégie, oui. Mais à ce stade et compte tenu du public, mieux vaut ne pas parler de SOA, parce qu'un choix technologique n'aura finalement que peu d'intérêt pour les "fonctionnels".

J'achève ces jours-ci pour un DSI une mission dont l'intitulé est "Comment SOA peut permettre à mon entreprise de doubler les ventes de son canal e-Commerce". Ce DSI ira ensuite voir sa direction financière pour la convaincre de l'importance de cette innovation. Alors seulement démarreront peut-être des projets, et alors seulement nous nous assoierons entre gens de bonne compagnie, métier et IT, autour d'une table, pour concrétiser la vision. Mais il ne faut pas se tromper d'ordre.

Je concluerais en citant Werner Vogels, vice-president, worldwide architecture executive et CTO d'Amazon.com, dont on peut diffilement douter de la pertinence du propos lorsqu'il parle de B2C et de SOA : "It doesn’t matter if a partner uses REST or SOAP. Our developers don’t care if it’s REST or SOAP. It’s all about customers" (http://blogs.zdnet.com/service-oriented/?p=648).

Définissons les SOA !!!

Au SOA Forum, il a parfois été difficile de donner une définition simple et complète de ce que sont précisément les Architectures Orientées Services. Olivier Rafal, organisateur de l'évènement et rédacteur en chef du Monde Informatique Web, indique ainsi dans l'encart central "Guide des solutions SOA" du numéro de cette semaine que c'est une "chose que les meilleurs esprits ont du mal à faire". Henri Peyret de Forrester Research a indiqué donner des SOA une "définition volontairement vague". J'ai moi-même contribué à ce flou artistique pendant la table ronde où je participais. D'autres préfèrent adopter une vision (très très) large au risque d'inclure par extension des sujets plutôt... connexes. Il est ainsi difficilement compréhensible de voir figurer, en 11e position du classement de Pierre Audoin Consultants sur le sujet, l'éditeur Systar, notoirement spécialisé sur le Business Activity Monitoring (BAM) et que l'on pressent pour le moins éloigné du sujet SOA (posez-leur la question).

Comment donner une définition ? Peut-être en se concentrant sur les principes et non sur une définition trop formelle ou une vision biaisée par les outils.

Abordons par exemple le sujet du BAM, justement. De quoi s'agit-il ? D'excellence opérationnelle, grâce à une supervision temps réel de processus métier. La société dans laquelle je travaille, Unilog Management, a mis en place une supervision du processus de passage d'ordres boursiers pour le Crédit Lyonnais en 2003. Nous ne parlions pas de BAM à ce moment-là. Nous ne connaissions d'ailleurs pas les outils... Nous avons procédé à un petit développement spécifique. Pas d'outils donc, mais les principes : temps réel, alertes à l'utilisateur. Il n'est nul besoin de structurer sa vision par les fonctionnalités d'un outil - même si celui-ci a une forte valeur ajoutée par rapport à un développement spécifique, ne me faites pas dire...

Autre exemple évocateur : une célèbre compagnie aérienne française utilise depuis 1984 une plate-forme centralisée pour ses échanges inter-applicatifs. Il s'agit également d'une application spécifique, réalisée en Assembleur et en Cobol, dans laquelle on retrouve tous les principes de ce que Gartner Group a appelé EAI... un beau jour de 1998.

Alors, quels sont les principes fondateurs des SOA ? Je serai tenté d'en voir deux : assemblage et flexibilité. L'assemblage de services améliore la réutilisation et la productivité de réalisation des applications. La flexibilité, c'est l'assurance de personnaliser cet assemblage rapidement, à moindre frais. Un peu abscons ? Je prends un exemple.

Une société française de distribution B2B souhaite déployer une plate-forme e-Commerce dans les 23 pays où elle est présente. Elle crée un socle de services : passage de commandes, suivi des livraisons en temps réel, pricing dynamique, consultation des stocks... Le socle créé en France est réutilisable. Il est également flexible : chaque pays peut mettre en oeuvre les services dans l'ordre où il le souhaite, en fonction de ses besoins et de son marché.
D'autre part, cette société souhaite rendre possible la consultation en ligne des catalogues de ses partenaires, afin d'accroître son offre en ligne et de devenir une plate-forme communautaire de social shopping pour ses clients. Elle a donc besoin de pouvoir "brancher" rapidement et régulièrement de nouveaux partenaires, puis de synchroniser dynamiquement les catalogues et les prix. 1 - assemblage rapide de nouveaux partenaires, 2 - flexibilité quant aux formats des catalogues et protocoles de communication.

Assemblage et flexibilité. Dans un environnement changeant, il faut savoir faire vite, sous peine d'obsolescence. Il faut s'adapter rapidement, montrer et proposer ces capacités aux clients et aux partenaires. Les Architectures Orientées Services ne font pas qu'y contribuer. Elles rénovent le système d'information dans le sens de cet alignement accéléré. C'est leur principale qualité.

Ces deux principes forment une base stable de construction des SOA. En les gardant à l'esprit, on évitera de s'exposer à des attentes trop grandes et à des promesses déçues.

Lancement du blog

Jeudi 5 octobre s'est tenu le 1er SOA Forum organisé par Le Monde Informatique/CIO. Une journée entière consacrée au sujet, un formidable lieu de rencontre et de discussion, et, comme toujours, une foule d'interrogations aux réponses encore incomplètes.

Les Architectures Orientées Services (SOA) sont une véritable innovation, en cela qu'elles mettent en lumière des besoins nouveaux et des réponses adaptées tant d'un point de vue :

• métier : qu'apportent les SOA au métier de mon entreprise (adaptation & agilité, time to market accéléré, meilleure intégration des partenaires, satisfaction client accrue...) ?
• techologique : quelles technologies permettent de construire ces modèles (web services, orchestrateur, business service manager...) ?
• organisationnel : quelle animation spécifique autour de ces nouvelles plates-formes (modèle matriciel, Centre de Compétences transversal...) ?
• financier : quel impact sur le mode de fonctionnement d'une direction informatique avec ses directions métier (pay-per-use, SaaS...) ?

Vous l'avez compris, les impacts sont nombreux et les domaines de réflexion ne manquent pas. C'est l'objet de ce blog que de mettre en lumière les nombreux impacts (autour des SOA et, de façon plus générale, autour des NSSI, ces Nouvelles Solutions Système d'Information qui permettent à l'entreprise de travailler sur son véritable patrimoine), d'en discuter et de faire progresser le domaine.