SOBA et SODA sont dans un bateau

J’avais envie de commenter deux acronymes en apparence anodins, voire inoffensifs, portés depuis un certain temps déjà par le Gartner Group pour désigner deux périmètres très distincts et pourtant fortement liés du champ des Architectures Orientées Services : SOBA (Service-Oriented Business Applications) et SODA (Service-Oriented Development Application). Deux acronymes qui regroupent en réalité à eux deux des préoccupations très actuelles des architectures orientées services.

SOBA désigne un processus en cours chez la majorité des vendeurs de logiciels : le fait qu’une application métier ne soit plus une sorte de conteneur monolithique mais un assemblage de services savamment orchestrés. C’est le pari majeur fait par SAP avec sa stratégie eSOA et son bouquet de solutions Netweaver (on se demandera au passage comment cette stratégie va se poursuivre maintenant que son grand inspirateur, Shai Agassi, a décidé prématurément de quitter le navire SAP), c’est également le choix d’Oracle avec AIA (Application Integration Architecture), de Microsoft avec .NET et d’IBM. Autant de grands noms qui montrent une inhabituelle convergence de vision. Toute application métier va exposer un ensemble de service qui la rendra autant accessible via son habituelle interface utilisateur que via un modèle de services exposés en accès arrière (back-door). Cela pose la question de la définition de ce modèle de service, cela pose également la question de l’accroissement du volume de transactions supporté par ces applications. Par exemple, si l’objectif de l’exposition de service est de permettre une gestion cohérente d’un catalogue sur plusieurs canaux (Web, accès externe fournisseurs, magasins, papier…), il est nécessaire que les services d’accès à l’information soient disponibles en tout temps, en tout lieu, avec le cadencement souhaité par chacun des canaux, avec le niveau de sécurité et d’habilitation nécessaire… Chez Microsoft, l’exposition de services MS Dynamics AX (ex-Axapta) se traduit d’un point de vue architectural par la constitution d’une ferme de serveurs destinés à gérer les back-doors avec un niveau de performance et de fiabilité digne des enjeux. SOBA désigne ni plus ni moins qu’un modèle d’ouverture des ERP à une échelle encore jamais atteinte auparavant.

SODA concerne le développement de ces applications, ou comment passer du développement d’application par production de logique métier à un mode de réalisation basé sur l’assemblage de services. Cela pose de nombreuses questions et soulève de nombreux problèmes. Lorsque l’on raisonne par assemblage de service, on peut aboutir à une forte taylorisation du travail. Le chef de projet n’est plus seul maître à bord : il dépend du travail passé et en cours sur d’autres projets pour exploiter les services dont lui-même aura besoin dans le cadre de sa propre application. Même si cela peut être frustrant, il faudra renoncer à la tentation de refaire ce qui existe déjà (le syndrome « not invented here », ou « si ce n’est pas moi qui l’ai fait, alors je le refais ») car cette attitude est difficilement compatible avec la recherche de réutilisation et de mutualisation que porte la SOA. Mais cela peut être plus difficile qu’il n’y paraît. Pour travailler par assemblage de service, il faut disposer d’outils adéquats, permettant d’accéder à une liste des services existants, de mesurer le taux de réutilisabilité, de procéder à l’analyse d’impact, puis de réaliser l’application. Cela suppose un référentiel de service, et en la matière, on n’en est qu’au tout début de la démarche, du moins en France. Cela suppose aussi logiquement un lien entre les outils de modélisation et de référencement des services, et les outils de développement : et là, on est encore plus en amont dans la démarche. Les premiers plug-ins entre IDS Scheer Aris et les principales plates-formes du marché sont encore en cours de réalisation. Enfin, cela implique que dès l’école, les ingénieurs soient formés pour concevoir et construire une application sur un mode d’assemblage de services, et je doute que la méthode soit tellement bien finalisée aujourd’hui qu’elle puisse réellement être enseignée, à fortiori à l’heure où les outils se cherchent encore.

Là où SOBA élargit le champ des promesses, SODA ne circonscrit à l’heure actuelle qu’un champ de limites. J’oserai une comparaison : les meilleurs jeux sur PS3 ne sont ceux disponibles au moment où la console est sortie, mais ceux auxquels nous jouerons après deux ou trois ans de programmation intensive. Les grandes manœuvres des éditeurs nous poussent tous à adopter les technologies orientées services, mais il faudra du temps pour digérer les pratiques qui en découlent. Laissons à SODA le temps de prendre de la bouteille.

BPM ou SOA : qui tient réellement la corde ?

Plus les entreprises doivent s’adapter rapidement, plus la distance entre le métier et l’IT doit se réduire, afin que tout nouveau besoin métier puisse être traité rapidement. C’est le sens de l’histoire, et les résultats de l’étude Gartner CIO 2006, à laquelle ont répondu plusieurs centaines de directeurs informatiques, indiquent que ce cap risque d’être fermement maintenu pendant un certain temps. Souhaiteriez-vous quelques preuves ? Cette enquête en regorge.

Préoccupation première des DSI pour répondre aux tendances métier ? Améliorer les processus. Première priorité stratégique ? Fournir des projets qui alimentent la croissance de l’entreprise. La seconde ? Aligner la stratégie et les plans IT à ceux du métier. Premier investissement technologique ? La Business Intelligence.

La SOA occupe un champ extrêmement large du discours IT depuis plusieurs mois maintenant. Pourtant, à en croire les DSI, c’est pourtant le métier qui prend toute la place. Est-ce à dire que la SOA n’est pas une préoccupation de DSI, ou bien que la SOA est intrinsèquement liée au métier. En fait, les deux assertions sont vraies.

D’abord, la SOA ne préoccupe pas frontalement les DSI. C’est un besoin d’architecte d’entreprise, ou d’urbaniste, identifié comme un moyen pour réorganiser le système d’information en vue d’en faire un levier de croissance pour l’entreprise. C’est l’innovation au service de la croissance. A aller parler SOA dans le texte avec un DSI, on en garde parfois un cuisant souvenir. De plus, il n’est pas rare que les entreprises soient plus promptes à identifier les services techniques que les services métier. Cela s’explique par le fait que c’est l’IT qui construit généralement une SOA, et le service technique est une zone de confort où les services sont plus faciles à identifier : on voit tout de suite ce qui peut se mutualiser. En revanche, identifier les services métier demande une analyse de plus haut niveau, telles que celle que peut délivrer un travail d’EA (Enterprise Architecture), donc une démarche plus importante, plus longue à porter ses fruits, dans laquelle l’IT, si elle est candidate, se sent parfois moins à l’aise.

En résumé, le DSI ne voit pas le lien entre service et croissance, et ses équipes peinent à lui démontrer : c’est donc le processus métier qui tient la corde. C’est à lui qu’on confère le droit et le mérite d’assurer un lien naturel, une flexibilité et un alignement entre le métier et l’IT. C’est en améliorant les processus métier que l’on nourrit la croissance. Alors, comme ils sont parés de tous les mérites, passons sur les réserves qu’on nourrit vis-à-vis d’eux de ce côté-ci de la Manche ou de l’Atlantique. La majorité d’entre elles s’estompent, d’ailleurs, et la démarche d’EA, qui se généralise, identifie bien ces processus d’entreprise dont le rôle est souvent différenciant, critique et stratégique. Et le service dans tout cela, alors ? Non désiré par les DSI, et ravalé à un rang technique ? Déjà has-been ?

Bien sûr que non. Les Architectures Orientées Service (SOA) participent de façon naturelle à cette orientation vers le métier évoquée ci-dessus : s’il persistera bien toujours ça et là quelques services de nature technique, l’avantage d’une SOA est de promouvoir des services sémantiquement orientés métier, qui exposent un ensemble de fonctions, généralement identifiées dans une architecture d’entreprise. On parle même de Service-Oriented Enterprise (SOE) pour affirmer la force de ce lien entre service et métier. Et identifier les services métier, on l’a vu, fait également partie des démarches d’Enterprise Architecture.

De plus, c'est devenu une banalité que d'affirmer que l'orchestration des processus est consommatrice de service. Toute activité est susceptible d’être un service. Celle-ci peut s’effectue entre les silos métier, sur toute la chaîne de valeur de l’entreprise étendue : dans ce cas, le processus est dit transversal. Comme les applications sont généralement liées à un silo métier, aucune n’est en mesure d’en assurer seule l’exécution. Donner de la visibilité à ces processus en les modélisant, en assurant leur exécution par une plate-forme dédiée et en mesurant leur performance opérationnelle, est un autre moyen de créer de la valeur, de réduire le fossé entre métier et IT. Coup double : c’est le champ du Business Process Management (BPM).

Mais la transversalité n'est pas obligatoire. On peut citer, dans la banque notamment, le cas d'entreprises organisant des orchestrations de façon extrêmement large au sein d'une même entité.

Tout comme la SOA, le Business Process Management occupe un terrain plus ou moins en friche entre les applications du système d’information. A l’heure actuelle, ce terrain s’organise, se construit, et l’entreprise prend la mesure des réels enjeux qui pèsent sur son occupation. Organiser les données, les services, les processus, les échanges n’est pas l’expression d’un souci maniaque, mais plutôt l’affirmation d’une conscience que les gisements de croissance ne pourront être exploités sans la mise en place d’innovations qui organisent le patrimoine d’information de l’entreprise.

Bataille pour un nom de domaine

Un événement survenu ces derniers jours n'aura pas manqué d'attirer l'attention des scrutateurs du marché des SOA. Solucom a racheté Vistali, et la nouvelle entité, constituée notamment de Dreamsoft, se présente désormais comme le numéro 1 du marché des SOA en France d'après Pierre Audoin Consultants (PAC). Passons sur la polémique (les termes de PAC auraient été mal reproduits dans le communiqué de presse) pour mieux nous concentrer sur le fond : une fois de plus, qu'appelle-t-on SOA ?

Pour faire suite à mon dernier article, on sait que SOA, c'est a minima l'EAI. Vistali, spécialiste de l'orchestration des systèmes d'information, est initialement intégrateur des solutions EAI de webMethods et Microsoft. Le jour où l'industrie IT a estimé que la SOA englobait le marché de l'EAI, Vistali est devenu mécaniquement spécialiste SOA.

Raccourci un peu simpliste : le domaine de la SOA est bien plus large. Il demande d'appréhender de nouvelles technologies et de développer des méthodes adaptées. Il est souvent dans les discours lié aux champs du Master Data Management, du Business Process Management ou encore du Business Activity Monitoring. C'est ce qui a permis à Unilog Management, tout aussi mécaniquement requalifié de l'EAI à la SOA, de rayonner sur ce marché en 2005.

Ce domaine peut ainsi être résumé par une formule pratique, mais que l'on retrouve malheureusement de plus en plus souvent :

SOA =
BPM pour l'orchestration des services
+ BAM pour la mesure de la performance
+ EAI pour toutes les raisons déjà évoquées
+ MDM pour l'exposition de services donnant accès à des vues des données
+ (quand même un peu de) vrai domaine spécifique à la SOA
+ encore un petit bout de portail
+ pourquoi pas un peu de serveur d'applications avec lequel on crée et on expose certains services Web.

Si l'on considère cette formule telle quelle, on a surtout l'impression que la SOA, c'est l'inventaire à la Prévert, et que sur une telle base, on en vient rapidement à estimer que c'est par addition de choux et de carottes que les leaders du secteur se font.

Je préfère pour ma part réduire la formule à sa plus simple expression :

SOA = (vrai domaine spécifique à la) SOA.

On peut aussi estimer qu'un tel amalgame peut niveller la compréhension des spécificités de chacun des domaines.
Le MDM ? Il y a bien quelques points de connexion, lorsqu'on expose sous forme de services des vues sur les données, , mais c'est un domaine qui a sa spécificité : création de modèle sémantique d'entreprise, définition des workflows de composition des données, mécanismes de dédouiblonnage et d'analyse matricielle...

Le BPM ? Il y a aussi des points de connexion, lorsqu'il s'agit de définir des processus métier par orchestration de services, mais là aussi, il y a des spécificités : identification de règles métier à mettre à disposition de l'utilisateur et gestion dynamique de ces règles via un moteur idoine qui les expose à l'utilisateur, composition dynamique de processus et late-binding... où sont les SOA ici ?

Plus drôle : le BAM ? On cherche encore les liens avec la SOA. Pourtant, les éditeurs de solutions de BAM font partie des classements SOA.

Et pour faire bonne mesure, pourquoi ne pas ajouter à la formule d'autres domaines consommateurs de services tels que le client riche, le Web 2.0, et le RFID tant qu'on y est, histoire de créer une bonne grosse friandise bien indigeste ?

Ne cédons pas à la tentation. La SOA est un domaine qui en tire bien d'autres mais qui ne peut les englober ni même s'identifier à eux. C'est pour cette raison que j'ai préféré pour ce blog titrer sur les Nouvelles Solutions Systèmes d'Information, dont la SOA fait partie, et dont la vocation commune est d'optimiser le patrimoine d'information de l'entreprise.

J'ai moi aussi ma petite formule maison : NSSI = SOA + MDM + BPM + BAM + EAI
Une formule un peu propriétaire certes, qui vaut ce qu'elle vaut, qui peut même évoluer dans le temps, mais qui me simplifie la lecture. On aura peut-être un peu plus de difficulté à savoir qui est leader de chacun de ces segments et du tout. Mais on évitera surtout les identités fausses (ou absurdes, c'est selon) telles que : SOA = SOA + plein d'autres choses.

Un point sur la maturité des solutions SOA

Un débat anime actuellement les experts du Centre d'Excellence SOA d'Unilog Management. Ce groupe, constitué d'experts internationaux (UK, Pays-Bas, Danemark, Finlande, Allemgne, France) se demande s'il est préférable d'être rattaché à la direction de l'innovation ou à la direction du marketing. Intéressante question qui peut être formulée en d'autres termes : les Architectures Orientées Services forment-elles un domaine que l'on peut qualifier de mature ?

A la lumière d'une récente mission menée pour l'un de nos clients du monde de la fabrication/distribution, il semble nécessaire de compléter cette question d'une autre : à quel degré les entreprises ont-elles aujourd'hui besoin d'adopter les Architectures Orientées Services ? Cette entreprise souhaite construire une plate-forme permettant à ses applications de mieux communiquer entre elles. Il y a encore deux ou trois ans, une étude de ce type aurait abouti à un choix proche d'une plate-forme combinant intégration en mode message (EAI) et intégration batch (ETL), avec quelques touches d'orchestration en fonction du degré d'orientation processus décidée par l'entreprise. Aujourd'hui, c'est plus compliqué. Parler d'EAI peut vous conduire à vous sentir has-been.

Pourquoi ? Parce que les éditeurs de logiciel ont tout misé sur la SOA. D'un point de vue marketing tout d'abord : qui trouve encore la trace du mot EAI quelque part ? Pourtant, le domaine n'a pas disparu. Il a été tout bonnement et tout simplement "absorbé" par le mot-clé "SOA" dont il constitue une partie, mais pas le tout. Mais on a toujours besoin, plus que jamais, d'intégrer les SI et d'exploiter efficacement ces grandes friches inter-aplicatives que les entreprises ne peuvent plus se permettre de négliger.

D'un point de vue technologique ensuite : pour marquer leur engagement SOA, certains éditeurs n'ont pas hésité à privilégier une logique de rupture de leurs offres, via de nouvelles plates-formes centrées notamment sur l'orchestration de services. De nouveaux produits, faits maison ou issus de rachats de pure-players. Dans certains domaines, comme celui de la gouvernance des services, cela peut être très positif : ces produits n'existant pas auparavant, ils créent quelque chose de nouveau, une innovation à laquelle on doit laisser le temps de se développer (car le besoin est là, nous en reparlerons prochainement).

Dans le domaine de l'intégration inter-applicative (relookée SOA), c'est beaucoup moins clair. On dispose de solutions performantes, déployées depuis plus de 10 ans. Les casser au profit d'une refonte SOA, absorber un pure-player à la couverture fonctionnelle fatalement moindre, c'est prendre le risque de régresser, par exemple en matière de supervision fonctionnelle ou de connectivité aux systèmes existants. Même s'ils aboutiront au final à des solutions d'envergure réelle capables d'adresser l'ensemble d'un périmètre SOA, ces choix sont discutables à court terme car l'apport des SOA à l'intégration inter-applicative est une évolution et certainement pas une rupture.

Ce qui nous conduit, dans le cadre de la mission mentionnée précédemment, à préconiser des produits a minima orientés EAI, n'ayant pas subi de rupture technologique forte depuis plusieurs années et en cours d'évolution tranquille vers une logique de plate-forme SOA/BPM, dont la maturité coincidera probablement avec celle des entreprises en la matière. Ils nous semble que des solutions telles que celles de BEA, Microsoft, Tibco ou webMethods répondent à cette logique. Parce qu'il est aujourd'hui nécessaire, lorsque l'on crée une plate-forme d'échange d'entreprise, de faire cohabiter le mode batch/fichier, le mode fil de l'eau/message et l'invocation de services, notamment pour gérer la bascule progressive d'un mode d'échange à l'autre.

Quant à ceux ayant privilégié des approches de refonte lourdes, ils devront se rappeller encore quelque temps que, oui, décidément, rien ne sert de courir et que oui, c'est vrai, les entreprises, après 10 ans de solutions d'intégration inter-applicatives dans le paysage, s'attendent à des produits industriels, des méthodes rôdées, des solutions qui fonctionnent bien et dont la couverture fonctionnelle est large.

Si on en trouve à l'heure actuelle, il me semble personnellement que la SOA en demeure à un stade innovant où se dessinent encore les réponses technologiques, le marché et les méthodes. C'est d'autant plus vrai que son champ est vaste. j'en profiterai pour ajouter que la disparition ou l'absorption rapide des pure-players SOA n'est pas un service rendu à ce marché. Et je concluerai au passage par une franche affirmation : parler d'intégration EAI en 2007 n'a rien de has-been. Ce sont les entreprises qui le demandent.