KAI ou la mesure de l'agilité

Dans le cadre du SOA Forum, je participais jeudi à une table ronde sur l'agilité. Voilà une notion terriblement tendance. Pendant longtemps, elle est restée impalpable, instinctive. On la comprenait de façon abstraite, intuitive, et chacun, en fonction de sa politique marketing, était libre de la décliner à sa guise et de la concrétiser selon ses forces propres.

Interrogé sur ma définition de l'agilité, je la présentais comme l'ensemble des moyens à mettre en oeuvre pour accélérer l'application des changements métier plus rapidement qu'auparavant avec un corrollaire inévitable au niveau du système d'information et de sa performance propre.

En bref, on mesure le temps passé à déployer une nouvelle fonctionnalité, changer un processus métier, créer un nouveau produit et le mettre en ligne... et on le compare au temps nécessaire pour obtenir le même résultat avec un nouveau socle technologique, par exemple, ou avec d'autres méthodes de fonctionnement. L'apport des Nouvelles Solutions Systèmes d'Information dans ce gain est crucial, et notamment les mécanismes d'assemblage offerts par les Architectures Orientées Services dans le gain de temps obtenu.


L'intérêt est d'avoir des indicateurs traductibles en éléments financiers et non abstraits, donc difficiles à comparer les uns avec les autres et à consolider. Par exemple, si je peux mettre un nouveau produit sur le marché en 5 jours plutôt qu'en 5 semaines, alors les 4 semaines de temps gagnées doivent pouvoir se répercuter financièrement sur la performance économique de la société, via son aptitude à s'aligner plus efficacement au contexte concurrentiel dans lequel elle évolue.

En utilisant ce principe, IBM a introduit un élément décisif dans la quête vers l'agilité : le Key Agility Indicator (KAI) ou Indicateur Clé d'Agilité. Depuis 2007, IBM a ainsi recensé plus de 300 KAIs répartis sur 17 secteurs verticaux ou lignes horizontales d'activité comme la supply chain.

L'agilité se mesure donc. Couplés à des indicateurs de mesure de la performance, les KAI permettent d'orienter les décisions d'investissement, de renouvellement de socle technologique, potentiellement vers les architectures SOA et vers les autres NSSI. Une notion que l'on pourra appliquer à des frameworks de gouvernance tels que ValIT pour enrichir la prise de décision.

Une méthode de conception visuelle et pratique

Comme chaque année, le retour de Barcelone est difficile à gérer. Après avoir passé quelques jours sur les hauteurs, il faut consentir à redescendre et se remettre au travail. En tout cas, à une autre forme de travail, moins prospective, plus pragmatique.

En ce qui me concerne, j'ai repris ma place en tant que directeur technique de la construction d'une architecture NSSI pour une entreprise du secteur de l'assurance. L'objectif est d'industrialiser et sécuriser la conduite des processus métier. Dans l'assurance, cet objectif se traduit généralement par la combinaison d'une gestion électronique des documents et d'un nouveau poste de travail, autour d'un moteur de workflow. C'est effectivement le cas ici.

De plus, il faut établir une communication avec les principaux systèmes de gestion existants et briser les barrières entre les différents silos. Ces silos ayant été réalisés sur des technologies différentes, les abrrières sont d'abord d'ordre technologique. Il importe de normaliser l'accès aux technologies et de masquer leur hétérogeneité en élaborant un modèle métier d'entreprise. Ici apparaît la SOA, en tant que levier d'urbanisation.

D'une manière générale, et à plus large échelle, c'est tout le socle que nous concevons qui est architecturé autour de la notion de service. Services documentaires, services collaboratifs, services de gestion d'activité, services de pilotage, services d'accès aux données référentielles, services de traitement... : la moindre fonctionnalité est présentée sous cette forme.

Ces façons de concevoir et de représenter ont deux grands avantages :
- le premier est de faire figurer sur une feuille A3 l'ensemble des fonctionnalités remplies par le socle, compilation plus simple, pour partager et communiquer en interne avec les équipes du programme, que les plusieurs centaines de pages de documents disponibles à notre arrivée.
- le second est de montrer le socle sous l'angle des services qu'il expose. Le consultant qui opère plus spécifiquement sur la partie Poste de Travail voit immédiatement les services qu'il doit assembler pour l'utilisateur. De son côté, le fournisseur de la solution GED ou BPM comprend immédiatement ce qui est attendu de ses produits, quelle envergure fonctionnelle il couvre, et comment sa solution va s'articuler avec les autres briques du socle.

La SOA, méthode de conception visuelle et outil de communication ? Cela ne date pas d'hier, mais on l'avait perdu de vue. Aujourd'hui, on retrouve cet usage sur des projets de plus en plus nombreux.

La tête dans le nuage

Indubitablement, l'un des sujets les plus en vue cette année est le Cloud Computing. Il fait l'objet d'au moins une conférence par jour : "31D - Cloud Computing myths, magic and mayhem", "43C - Alternative delivery models : IT as a service", "44A - Web plaforms : business in the cloud", sans compter la session sur les "10 most disruptive technologies". L'audience partage-t-elle cet engouement ? Le bilan est mitigé.

Après moults échanges et discussions sur site, le Cloud Computing, selon que l'on voie le verre à moitié vide ou à moitié plein, est la dernière hype pour faire du neuf avec du vieux, ou bien le signe que l'industrie se structure et s'organise autour de la notion "Everything as a Service" : infrastructure, applications, information, processus, et j'en passe. N'a-t-on pas un peu tendance à transformer ce brave nuage en un écran de fumée ? Est-il réellement "disruptif" ? Et, au juste, de quoi parlons-nous ?

Pour bien comprendre en face de quel objet nous nous trouvons, reprenons la définition qu'en donne Daryl Plummer, analyste du Gartner : "a style of computing where massively scalable IT-related capabilities are provided as a service to multiple customers over the Internet". Pour faire bref, j'utilise Internet pour accéder à des services de type logiciel, infrastructure, processus, etc. Les exemples les plus abondamment cités sont GMail ou salesforce.com : délivrés via Internet, ces services changent le modèle économique entre consommateur et producteur de service, en cela que le producteur s'engage à respecter une prestation caractérisée par une qualité de service.

Lorsque l'on acquiert un logiciel, lorsque l'on investit dans de l'infrastructure, jusqu'à quel point s'engage réellement le fournisseur avec lequel vous contractualisez ? Probablement moins que ce que vous souhaiteriez. Les impacts les plus forts sont forcément à attendre du côté du sourcing et de la gestion du portefeuille d'applications. En effet, les modèles économiques vont probablement différer des modèles traditionnels de licensing. On le voit avec salesforce : you "pay as you go". Ce modèle a le vent en poupe : il se développe dans l'économie "réelle" : Michelin facture à la quantité de gomme effectivement consommée, et le secteur de l'assurance propose aux jeunes conducteurs de régler leurs prestations en fonction du kilométrage effectué et de l'heure à laquelle a eu lieu la conduite (globalement : les sorties de boîte de nuit vont coûter cher, mais ceci est un autre sujet). Il est vrai que plusieurs de mes clients ont manifesté récemment le souhait de ne plus payer des packages logiciels complets, mais uniquement les fonctionnalités réellement utilisées.

Cela va dans le sens d'un éclatement des applications en services. Si ces services sont fournis via un prestataire extérieur, sur Internet, et que la facturation s'effectue sur la base de la consommation réelle, alors la politique de sourcing d'une entreprise est susceptible d'être modifiée en profondeur. Les investissement logiciels, considérés comme du capital (Capex) se déplacent vers de l'opérationnel (Opex). La gestion du portefeuille d'applications demande de tenir compte de ces attributs. Des courtiers vont émerger, qui arbitreront entre des services similaires pour maintenir vivace une concurrence de prestation, de prix et de qualité, au bénéfice des entreprises.

Jusqu'à présent, tacitement, les entreprises considéraient que les coûts élevés de migration d'applications et de renouvellement d'infrastructure pouvaient se justifier par le fait que, finalement, les fournisseurs assurent la R&D que les entreprises ne peuvent se permettre de mener pour leur propre compte. Le Cloud Computing remet ce modèle en cause, en fournissant une alternative agile : toute mise à jour du modèle fourni peut bénéficier quasi immédiatement à l'ensemble des consommateurs qui en auraient le besoin et l'utilité. Elles vont aussi dans le sens d'une plus grande industrialisation de l'économie et de la technologie Internet.

L'observation des mouvements du marché montre clairement que le Cloud Computing, ce n'est pas du vent. Si certains n'ont pas encore saisi la portée du modèle, d'autres manifestent un intérêt qui confine à la décision stratégique. Ainsi, la trajectoire de Microsoft, le plus grand fournisseur d'applications bureautiques au monde, s'incurve singulièrement dans cette direction, prouvant, s'il en était besoin, la capacité du géant de Seattle à se renouveler, dans le sillage de Google, pour s'acheter un coin de nuage.

Gartner Megatrends : vertige du futur

Les années se suivent et se ressemblent quelque peu à Gartnerland. Il y a la plénière d'ouverture, avec le boss, Gene Hall,
qui vient délivrer ses quelques mots de bienvenue ; paroles il est vrai rendues cette année bien moroses par un contexte
économique guère flamboyant que Gene Hall se plaît à souligner... pour mieux marteler que c'est dans la récession que se
prépare la croissance. Aussi il est important de ne pas se relâcher et de poursuivre inlassablement une mission centrale,
la mission ultime de l'IT : innover. Le voilà, le maître mot, il est lâché et tombe sur un parterre d'auditeurs pris par surprise au petit matin, sans avoir parfois eu le temps de descendre un café.
Le rôle de l'IT, plus que jamais, est de porter l'innovation, et de la porter au coeur du métier. Prendre des risques, dépasser les limites, casser les règles du jeu : il est urgent d'écouter le leader qui sommeille en nous. J'ironise un peu, mais il faut reconnaître que ce discours extrêmement volontariste regonfle le moral. Il s'agit aussi d'adopter une attitude
responsable vis-à-vis des actifs du système d'information : actifs technologiques certes, mais aussi actifs métier et actifs humains. La gestion et la gouvernance des actifs sur la durée, en cassant la logique de silo imposée par le traditionnel exrecice budgétaire, est une preuve de maturité. C'est dans la transversalité qu'elle se construit et le rôle
de l'Entreprise Architect est, encore une fois, crucial dans ce dispositif responsable. Je crois profondément en ces thèmes que nous reprenons à notre compte dans l'ouvrage à paraître début juin et qui s'intitule... le système d'information transverse.

Deux autres principaux sujets sont lâchés par Peter Sondegaard, le patron de la recherche : Green IT et people. Le développement durable et le respect des contraintes environnementales vont se renforcer dans le quotidien des entreprises. C'est effectivement un thème qui a pris de l'ampleur depuis le symposium 2007. Nous apprendrons un peu plus tard dans
l'après-midi que la France se situe au 1er rang des pays intégrant cette contrainte dans leur politique IT (15% des décideurs en tiennent compte, contre 9% en Amérique du Nord et une moyenne générale de 11%). Saviez-vous que, dans le secteur IT, les plus soucieux de l'environnement et les plus créatifs sont les constructeurs (HP, IBM, Ericsson) ? Les plus
attardés ? Sans nul doute les sociétés de service. Gartner confessera n'avoir pas répondu à sa propre enquête en raison de ce positionnement délicat. Microsoft non plus n'a pas répondu. Quand à Google, c'est quasiment un bonnet d'âne qui lui est décerné. Commentaire de WWF, qui co-présentait cette session : "Ceux qui parlent le plus en font clairement le moins.
Comment imaginer que Google, entreprise modèle et futur de notre économie pour beaucoup de jeunes, puisse être aussi conservateur et rétrograde sur un sujet lié à l'avenir de la planète" ?

Concernant les "people", le constat est celui d'une carence cruelle des compétences nécessaires pour mettre en place et maintenir les technologies émergentes. A titre d'exemple : l'arrivée des processeurs hybrides et multi-coeurs implique le parallélisme des traitements, et des développeurs capables de l'implémenter dans leurs réalisations. Ils sont encore rares. Je partage ce constat : sur les technologies NSSI, Logica forme énormément, car les compétences souhaitées sont rares sur le marché, et la tension est forte pour les recruter. De plus, la détection des talents se diversifie. Il ne suffit plus de trouver de bonnes compétences technologiques. Il faut de nouvelles qualités : de l'écoute, de la créativité, un sens plus marqué du métier, la capacité à gérer des réseaux de partenaires... Pourquoi ce dernier point, me direz-vous ? En raison notamment de l'émergence réaffirmée du Cloud Computing : la gestion du sourcing va toucher des publics beaucoup plus variés qu'aujourd'hui. Et tous ces talents ne se retrouvent pas (encore) dans les modèles offshore proposés par les pays émergents.

L'impact des pays émergents est précisément l'un des nombreux autres sujets abordés pendant la plénière, au même titre que l'effervescence autour des réseaux sociaux ou les nouveaux préceptes de la mobilité (vous connaissez le WINYWYG ?). Sujets auxquels nous reviendrons dans un tout proche bulletin.

En direct de Gartnerland

Dans une ville de Barcelone éteinte en ce lundi de Pentecôte férié et maussade, le symposium Gartner débute par la traditionnelle après-midi de mise en bouche. Quatre conférences pour lancer ce qui devient officiellement le congrès des tendances émergentes (comparativement à celui de Cannes, en novembre, qui sera le véritable grand raout annuel tous azimuts).

Et qu'avons-nous vu émerger, en ce début d'après-midi ? La moustache de Massimo Pezzini himself, la superstar incontournable de la planète SOA, son accent impayable ("as you may hear, I'm Italian") et son humilité certes improbable mais pas factice ("I will try to give you the answer"), pour une présentation virtuose sur le thème "Front-End vs. Back-end composite applications". Un panorama magistral, du Cloud Computing aux Mashups, une analyse de marché complète même si sans grande révélation : un Massimo visiblement très fatigué mais malgré tout impeccable, qui prédit en roue libre l'avènement du "end-user compositing".

Autre sujet très "end-user" : l'état de l'art du Business Rules Management System, par Marc Kerremans, nettement moins en verve que son prédécesseur. Il incite pourtant à réfléchir sur les notions comparées de flexibilité (planifiée) vs. adaptabilité (inattendue) - qui s'était déjà penché sur cette distinction ? - et sur le rapprochement qui continue de s'opérer entre IT et business via la capacité pour l'utilisateur final de modifier dynamiquement des règles. Autonomie d'un côté, externalisation de l'autre : cela ne manquera pas d'alimenter le débat sur la réorganisation et la mutation des DSI.

S'ensuivit un sujet véritablement hype et drainant d'ailleurs la grande majorité de l'audience : comment justifier auprès des business leaders d'investissements dans les technologies émergentes ? Brian Burke formule maintes propositions pour structurer l'intégration de l'innovation, réfléchit sur les conditions de réussite de cette intégration, réaffirme le rôle de l'Enterprise Architecture dans cette industrialisation : on est dans le vif du sujet.

Enfin, Myriam Burt clôt l'après-midi en caractérisant les comportements des Digital Natives, soit toutes les personnes nées après 1980. En comparaison, étant né en 1971, je suis pour ma part un Digital Immigrant : je fais de mon mieux pour m'en sortir dans un monde qui n'est pas le mien. (ma présence à ce symposium en témoigne). Robots, avatars des mondes virtuels et des immersive workspaces, habitudes de consommation mobiles et multi-canal : une revue de détail en accéléré, qui nous invite à nous détourner de Second Life, empire désert et jugé trop vaste, pour mieux nous concentrer sur Kaneva (http://www.kaneva.com/), nous fait rêver un moment en rappelant la promesse Microsoft Surface, et provoque ensuite le scepticisme de l'assemblée en anticipant pied au plancher sur les nano-technologies (NOKIA Morph). Un chiffre ? Seuls 18% des Digital Natives envisagent d'utiliser leur terminal mobile pour un achat : le mobile reste un outil d'échange et d'accès à l'information, mais pas encore l'outil de mCommerce rêvé.

L'après-midi s'achève sur cette maxime fort à propos : la seule technologie réussie, on ne la voit plus, car elle s'est fondue dans notre quotidien. C'est donc aussi celle dont on ne parle plus ! Bonne nuit.

Back !

De retour après un année de silence, une année chargée, diversifiée, bien occupée - ce qui explique au passage mes difficultés récurrentes à alimenter ce blog avec rigueur, jusqu'à le laisser se couvrir de poussière un bon moment. Je ne ferai pas de promesse sur ma régularité à long terme, mais je vais d'ores et déjà ouvrir les fenêtres et ôter quelques toiles d'araignée.

Pourquoi une si longue interruption ? En raison d'une activité musclée ! Cette année fut notamment occupée :

• par la création de la Web TV de Logica Management Consulting, Your Potential TV (http://www.yourpotential.tv/) - dont je ne peux résister à l'envie de glisser ci-dessous un lien vers un sujet d'actualité : réussir l'outillage méthodologique de la SOA,
• par la rédaction d'un nouvel ouvrage, à paraître début juin chez Hermès Lavoisier (sur les mêmes sujets que ceux traités dans ce blog),
• par ma participation à un programme d'envergure dans la création d'un socle NSSI complet faisant intervenir SOA, BPM et BAM, et la conception du socle de pilotage temps réel de toute l'activité de détail d'une grande banque française.

Pas de quoi s'ennuyer, et c'est au moment où je lève le pied quelques jours que je reprends la plume. Je pars en effet ce soir pour Barcelone afin d'assister dès lundi au symposium annuel du Gartner Group, le cabinet que l'on adore détester, que l'on raille autant qu'on le respecte, que l'on ne peut bon gré mal gré s'empêcher d'écouter. Je m'astreindrai à publier chaque soir sur ce blog les principales informations de la journée.

A l'issue de ce congrès, je retournerai diriger la construction du socle d'un nouveau programme NSSI, que j'aurai l'opportunité de présenter dans ces pages plus en détail.

Pas de promesse donc, mais de l'envie. Nous verrons bien où tout cela nous mène !

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.

Software as a Service : quelle(s) évolution(s) (2/2)

L’hébergement des applications et leur prise en charge par des maîtrises d’œuvre externes spécialisées permet d’éviter à disposer soi-même de ces compétences. C’est un peu comme faire appel à une société de services en informatique, sauf que là, la frontière entre le métier d’éditeur de logiciel et celui de prestataire de service devient floue. Rien n’interdit à une SSII de proposer ses propres solutions en SaaS, rien n’interdit non plus à un éditeur de considérer que ses équipes sont les mieux placées pour définir les spécificités fonctionnelles d’une application ou son architecture. Après tout, qui connaît mieux l’application, les forces et les limites de son modèle fonctionnel, ou la façon dont elle est mutualisée entre plusieurs clients ?

Dernièrement, j’ai trouvé que cette tendance se développait franchement. Nombre de mes clients ont fait appel en direct aux équipes des éditeurs après avoir choisi une solution… et nombre d’entre eux s’en sont d'ailleurs mordu les doigts : absence de méthode, ingénierie défaillante, incapacité à s’engager au forfait, ont allègrement conduit des projets stratégiques vers d'insondables abysses. La criticité stratégique des sujets avait laissé penser que seules les équipes des éditeurs proposeraient le niveau de maîtrise suffisant pour garantir le succès des projets. C’est l’inverse qui s’est produit.

Mais, comme vous l’avez peut-être déjà très justement remarqué, ces projets n’ont pas été opérés en mode SaaS. En mode SaaS, on fournit d’abord un socle fonctionnel et technique déjà existant. Les équipes ne se déplacent pas pour réaliser un logiciel : celui-ci existe déjà et il est éventuellement personnalisé pour les besoins d’une entreprise. Et c’est là que l’on peut se demander qui a besoin d’applications en mode SaaS.

En effet, à l’heure où nos clients nous demandent de tenir compte de façon de plus en plus précise des spécificités de leurs modèles métier, de contextualiser encore davantage nos études et nos réalisations, le modèle SaaS fournit davantage du prêt-à-porter que de la haute couture. Alors, à qui s’adresse le SaaS ? A de grandes entreprises qui voient là une manière efficace de sous-traiter des processus non stratégiques (du Business Process Outsourcing) ? A des PME qui n’ont qu’un intérêt limité pour le custom et trouvent plus commode de disposer d’applications clés en main ?

Tout dépend de ce que l’on nomme réellement SaaS. La volonté du SaaS, c’est précisément de s’affranchir de l’ASP, et de la notion d'application (comme, d'ailleurs, la SOA), ce dont il n’a pas encore les moyens économiques et technologiques (on se cherche encore beaucoup dans le SaaS, et Google est un peu l’arbre qui cache le désert). On différencierait alors l’ASP du SaaS en n’hébergeant pas des applications, mais des processus ou des services, graphiques ou non, prêts à être assemblés pour former des interfaces personnalisées, des processus modulaires. Le SaaS serait davantage un ensemble de ressources éventuellement "annuairisées" (que fait Google, finalement). On reparlerait sérieusement du mashup dans le monde de l'entreprise. Celle-ci trouverait là la voie du custom et de différenciation. Les modèles économiques se développeraient en conséquence, avec une facturation à la ressource consommée, la ressource pouvant avoir une signification sémantique métier pour l’entreprise (un client, une commande, une vérification Sarbanes-Oxley…).

Délire enfiévré ou boule de cristal, je n’ai pas la capacité à prédire l’avenir, et mes tristes scores à l'Euromillions me le rappellent régulièrement. Mais il n’est qu’à regarder les grandes manœuvres de SAP, IBM et Microsoft pour comprendre que si tout reste encore à faire, la vision est là.

Reste alors à régler la question de la relation entre éditeur de logiciels, société de service et cabinets de conseil. Si je prêchais pour ma paroisse, je dirais que la SaaS ouvre la porte à un modèle vertueux entre éditeur de logiciels et société de service, au service du client et de la création de valeur, pour définir des business cases, les modalités d’applications du custom, aider les entreprises à définir si le modèle SaaS est adapté pour elles et choisir la meilleure solution à leurs besoins.

Alors je me rendrais compte que tout compte fait, sur ce point-là en tout cas, le SaaS ne change pas grand-chose à nos métiers respectifs.

Software as a Service : quelle(s) évolution(s) ? (1/2)

Cette semaine, un think tank d’Unilog Management a regroupé quelques consultants pour débattre de domaines en voie de développement. Celui auquel j’ai participé portait sur le SaaS. SaaS (Software as a Service) évoque l’externalisation par les entreprises de processus métier auprès de partenaires chargés d’héberger la solution IT qui orchestre ces processus et d’assurer la prestation de services qui l’accompagne. Contrairement aux rumeurs, SaaS n’est donc pas la version flamande d’un populaire mâle espion engendré par Gérard de Villiers (pas plus d’ailleurs que l’acronyme OSS en son temps n’évoquait les prouesses à venir de Jean Dujardin).

SaaS se présente comme un nouveau modèle de facturation des logiciels : ce sont d’ailleurs principalement les éditeurs qui font du SaaS : les plus visibles sont SAP, Microsoft, IBM ou encore Oracle, mais de nombreux pure-players opèrent également, tels que salesforce.com. Par ailleurs, la concentration a déjà commencé, avec l’acquisition récente de Nsite par Business Objects pour proposer un modèle SaaS dans le champ du décisionnel. Au lieu d’investir dans une licence plus ou moins perpétuelle, les entreprises dépensent en « pay as you go » et « pay as you grow » : un montant forfaitaire, ou dégressif, par utilisateur ou par nombre d’objets manipulés. Ainsi, Salesforce.com facture les entreprises au nombre de clients stockés dans sa base de CRM (Customer Relationship Management).

En comparaison de l’acquisition d’une licence, les analystes estiment que le modèle SaaS est moins onéreux les trois premières années. Au-delà de trois ans d’utilisation d’une même version d’un logiciel, il vaut mieux investir dans une licence. Mais les avantages sont ailleurs. Evolutions et nouvelles fonctionnalités peuvent être régulièrement mises en ligne, sans forcément d’importants coûts de migration (même si les évolutions majeures deviennent du coup plus difficiles à appliquer). Et puis, il n’est plus nécessaire d’investir dans l’infrastructure ou dans les compétences : elles sont chez le partenaire. Par conséquent, une des réels points d'impact du modèle SaaS pourrait être son impact sur l’organisation des DSI.

En déléguant une partie des compétences et des socles techniques, les DSI vont pouvoir mieux se concentrer sur ce qu’elles cherchent à faire aujourd’hui : accroître l’efficacité de la relation entre maîtrises d’ouvrage et maîtrises d'oeuvre pour ajuster les relations avec le métier et accélérer l’alignement. Mécaniquement, c’est ce que doit provoquer l’externalisation d’une partie de la maîtrise d’œuvre. Avec une relation nécessairement contractuelle, il est probable que l'efficacité s'accroisse et que le temps de delivery de nouvelles fonctionnalités soit en moyenne considérablement réduit à l'avenir.

Mais on peut s’interroger sur la portée de ce modèle : s’agit-il d’un revival de l’ASP (Application Service Provider) ou d’un réel nouveau modèle ?

Les urbanistes ? Ils reviennent et ils sont très contents

En 2004, nous nous étions penchés, chez Unilog Management, sur la revalorisation de la fonction de l'urbaniste de système d'information. Nous observions que les travaux d'urbanisme n'étaient pas toujours utilisés, voire, malheureusement, utiles. La mission de l'urbaniste apparaissait dans certains cas déconnectée des préoccupations du commun des mortels, en apesanteur (règles d'urbanisme mal vécues car jamais au bon moment et rarement pour aider), qui plus est parfois teintée d'une forme d'autoritarisme bureaucratique qui ne rendait guère sympathique cette caste d'intouchables, protégée mais sans réel pouvoir et finalement sans écoute. Coûteux et sans pression du resultat, voilà quelle était l'opinion de l'homme de la rue IT en 2003 à ce sujet. Alors pourquoi vouloir ainsi prestement "revaloriser" une fonction en nette perte de vitesse ?

Parce qu'à ce moment-là, en 2004, en pleine euphorie EAI (flux de données transversaux), avec l'émergence des SOA (services mutualisés), avec la tendance au MDA (Model-Driven Architecture) qui se dessinait dans les solutions, il nous a semblé qu'au contraire, l'urbaniste était un témoin privilégié du système d'information. A la croisée du métier et de la technologie. il occupe une place de choix, unique. Disposant d'une vision réellement transversale, il est l'élément de gouvernance qui maintient la cohérence du système d'information.

Nous avons ainsi créé une offre d'Accostage à l'urbanisation, destinée à rapprocher les décisions de l'urbaniste du théâtre des opérations. Cette offre n'a jamais réellement vu le jour. En effet, nous ne faisions qu'anticiper, sans le savoir, ce que les Architectures Orientées Services allaient confirmer.

Dans un contexte SOA, on ne travaille plus uniquement sur des projets, mais aussi, et de plus en plus, sur des programmes. Sur ces programmes, une vision transversale est indispensable : pour délivrer la réutilisation et la mutualisation attendues, pour définir la granularité de services qui mène à l'état stable, pour définir les responsabilités sur les données référentielles, sur les services, les échanges et les processus transversaux. L'urbaniste est désormais directement embarqué dans les équipes projet (programme) et responsabilisé. Sa contribution est directement perceptible, concrète, appliquée au contexte, et capitale puisqu'intervenant en amont de bon nombre de décisions. Et il reste le mieux placé pour être le correspondant des urbanistes "centraux" et travailler parallèlement au maintien de la cohérence.

Je dirai même, et c'était l'un des objectifs de l'accostage, que le centre peut directement bénéficier des apports du terrain pour remodeler et ajuster sa conception, là où les précédents modèles de gouvernance étaient plutôt monodirectionnels et "météoriques" (en provenance unique d'un ciel qui vous tombait alors sur la tête).

Contrairement à ce que prétendent ceux qui crient à la réappropriation de la SOA par des cabinets avides d'opacité et de profit, les SOA ne sont pas le théâtre d'un putsch des urbanistes. Elles sont le théâtre de leur retour en grâce.

L'état SOA stable au service du ROI

Lu ce jour sur la lettre IT2IT publiée par BEA.

« Les initiatives SOA sont généralement motivées par le besoin de réaliser, de soutenir et de gérer des changements plus fréquents (et souvent imprévus) », indique un rapport Gartner de mai 2006 intitulé Key Metrics Can Help Justify Investments in SOA (Les indicateurs clés peuvent permettre de justifier l'investissement dans la SOA).

Complètement d'accord avec cela.

En effet, concrètement, dans quel sens souffle le vent de l'industrie et de la relation métier/IT ? Vers des cycles de livraison d'application de plus en plus courts (pour gérer ce fameux changement permanent dont on vous rebat constamment les oreilles).
Gartner estime que d'ici quelques années, le temps nécessaire pour livrer une nouvelle fonctionnalité se comptera en jours. Fumisterie ? Peut-être.

Ou peut-être pas ! Ce temps s'est déjà considérablement réduit. Le temps moyen d'un premier delivery SOA est de 3 à 4 mois pour les grands projets. Et ce delivery "n'est qu'un" socle à partir duquel de nouvelles demandes métier pourront être intégrées encore plus rapidement, sur la base de la réutilisation des services, des technologies et des pratiques.

Et là est toute l'essence de SOA : quel est le socle de services qui me permet de décrire un état stable de mon système d'information, à partir duquel toute nouvelle demande pourra être intégrée rapidement et à moindre coût (cela revient notamment à poser la question de la granularité des services et des liens avec les référentiels de données, mais c'est une autre histoire) ? C'est précisément ce que nous faisons chez nos clients : rechercher l'état stable, la bonne granularité qui assure l'évolutivité. On voit immédiatement les liens avec l'architecture d'entreprise et avec des initiatives telles que Praxeme (http://praxime.club-blog.fr/praxime/2006/05/praxeme_et_soa.html).

Ce qui cloche dans l'article du Gartner, en revanche, c'est sa conclusion.

« Par conséquent, mesurer les avantages de la SOA par le biais d'approches traditionnelles du ROI ne suffit pas (c'est même impossible dans certains cas) car le projet reste une cible mobile. »

Je ne sais pas ce qu'est une approche traditionnelle du ROI. Par contre, je pense qu'une fois l'état stable atteint, le projet ne constitue pas une cible mobile mais bien un socle à partir duquel il devient très aidée de chiffrer les nouvelles demandes et les bénéfices à en attendre. C'est tout l'objet des études de cadrage que d'arriver à déterminer en amont ces éléments essentiels.

Le cadrage SOA : un vent qui souffle

Bienvenue en 2007 et meilleurs voeux à tous.

Cette année voit se lancer un certain nombre d'études de cadrage SOA chez des entreprises de tous les secteurs. Nous avons passé la période des fêtes à répondre à de nombreux appels d'offres envoyés courant décembre. Pour ma part, j'ai répondu à quatre d'entre eux : deux pures missions de cadrgae SOA et deux mixtes (système d'échange d'entreprise incluant SOA). Même si nous aurions préféré passer davantage de temps en agapes (quoique, la saturation guette), ces multiples sollicitations témoignent de bien plus qu'un simple intérêt. Il se confirme ce que nous avions tous ressenti à la rentrée 2006 : les opérations sont lancées. Le SOA est peut-être bien ce 'chantier ouvert pour 10 ans" dont parle l'un des derniers numéros de 01 DSI.

Que recherchent les entreprises au travers de ces études ? Fondamentalement, deux choses, toujours plus ou moins les mêmes :
- SOA : pour quoi faire ? Pour quels bénéfices ?
- Quels impacts sur mon système d'information et sur l'organisation de ma DSI ?

On constate que ce sont des drivers métier qui pilotent la démarche : comment accroître les ventes sur un site e-Commerce ? Comment intégrer rapidement et à peu de frais un nouveau fournisseur ou un nouveau produit ? Comment fournir à mes client un nouveau service, de façon homogène à l'international ? Autant de drivers qui impliquent dans des études de cadrage parfois remises aux dirigeants (pas seulement IT) des entreprises d'évaluer le ROI. Mais ce ne sont pas les seuls. Le passage vers les NSSI se fait parfois à marche forcée.

Ainsi, l'arrêt du support de versions d'EAI à court/moyen terme (18 mois) par certains éditeurs du marché pousse les entreprises vers la migration obligée. Et cette migration vers les nouvelles versions des produits passe obligatoirement par la case SOA, structure de base de ces nouvelles constructions. Ce qui peut s'avérer gênant lorsque l'on constate que les produits ne sont pas encore tout à fait prêts - ou en tout cas, que l'avance prise par le marketing sur la technique dépasse les 6 mois traditionnellement admis.

On pourra alors réfléchir brièvement sur les bienfaits de l'innovation quand celle-ci est simultanément imparfaite et dictée. C'est toute la singularité de notre industrie que de voir les responsables Innovation si peu libres de leurs choix, voire otage. Or cette fonction, autrefois déconsidérée, tend à revenir fortement au goût du jour dans l'rganigramme des DSI (c'est d'ailleurs l'une des conclusions de notre prochain livre blanc qui sort le 22 janvier). On ne sera alors pas surpris de constater que certaines migrations forcées conduisent des entreprises à adjoindre à leurs études de cadrage une intéressante phase d'étude de choix de produit. Une façon comme une autre de se libérer de certains pesants carcans.

SOA : Next Steps for 2007

Le temps passe si vite et l'espace entre deux messages se creuse... comment être régulier ? Peut-être en réagissant davantage à ce que je lis ici et là. La newsletter de TV4IT cite une intervention d'un chief architect, qui précise sans rire qu'il faut se méfier des architectes littéraires. Diantre ! Dois-je me sentir visé ? Promis, en 2007, j'écris plus mal.

2007, justement, parlons-en. Quels sont les SOA Next Steps de l'année à venir ? Après trois années passées à introduire les concepts et les standards, mesurer les impacts sur la conception des systèmes d'information et des applications, parler méthodes et organisation, il semble que le sujet se réoriente radicalement vers la technologie : virtualisation, grid, sécurité et exploitation sont des sujets qui devraient faire tanguer la planète SOA.

• Virtualisation et grid, voilà qui perpétue la logique de découplage et de granularité chère aux SOA.
• Sécurité car c'est un sujet qui se renouvelle et se renforce constamment et l'arrivée des SOA dans le périmètre en est un à part entière.
• Exploitation car il va notamment s'agir d'éclairer plus fort en 2007 le sujet central du Business Service Management.

Voilà semble-t-il les champs d'investigation de l'innovation SOA (en parallèle de sujets plus traditionnels dont le développement se ralentit certes mais sans toutefois s'interrompre). Oracle, HP et Intel ne s'y sont pas trompés en organisant conjointement un roadshow fin 2006 où tous ces sujets (les nouveaux et les plus "familiers") étaient à l'honneur.

Un autre sujet sur lequel il faudra peut-être statuer à nouveau est celui de la liaison plus ou moins dangereuse qui existe entre SOA et Web Services (ou n'existe pas, d'ailleurs). Je crois que l'arrivée sur le devant de la scène des sujets listés ci-dessus risque de montrer que SOA et Web Services, au risque de susciter l'émoi, c'est peut-être bien la même chose. Mais cela sera l'objet d'un prochain billet, qui je l'espère sincèrement, n'attendra pas un mois pour sortir...

Les Nouvelles Solutions Système d'Information

Après une petite interruption (presque un mois, tout de même) dûe à une forte intensité d'activité, il est temps de reprendre du service. Et peut-être de profiter de cette petite pause pour éclairer un sujet que je souhaite traiter ici. J'ai en effet mentionné initialement que le blog était dédié aux NSSI, les Nouvelles Solutions Système d'Information. Qu'est-ce donc ?

Les NSSI sont une catégorie de solutions IT d'entreprise permettant à l'entreprise de mieux utiliser son patrimoine d'information, et d'améliorer l'alignement et l'adaptabilité du système d'information. Bigre ! Que de termes pompeux. Et que cela signifie-t-il ? Eh bien, reprenez les billets précédents rédigés ici et vous en aurez une illustration par les Architectures Orientées Services, par leurs principes, et par les exemples qui l'illustrent. Mais si les SOA sont une clé de voûte de la construction, elles n'en sont pas pour autant le seul élément. Des principes complémentaires viennent renforcer leur impact.

Ainsi, mutualiser des services aura plus de force si un travail préliminaire est également effectué sur les données : travail de centralisation physique ou virtuel regroupant les données référentielles. Il en résultera une homogéneité accrue de l'information.

De même, l'orchestration de processus transversaux aura davantage de sens si elle se concçoit par assemblage de services, découplant le processus de la localisation et de l'implémentation du service. Le déploiement d'applications à l'international cité ici dans un précédent article est un bon exemple.

Données, Services, Processus : trois actifs à mieux exploiter, trois actifs qui constituent le patrimoine d'information de l'entreprise. Les NSSI permettent de se recentrer sur leur meilleure exploitation, enjeu devenu majeur suite au rôle pris par les DSI dans la croissance de leur entreprise, et enjeu nouveau. En effet, pendant les années de grisaille économique qui ont suivi le 11 septembre, la priorité était plutôt sur la réduction des coûts. Les chantiers des DSI étaient davantage des chantiers de rationalisation du système informatique : réduire le nombre d'ERP présents dans l'entreprise, créer un poste de travail normalisé, standardiser les infrastructures... Aujourd'hui, les nouveaux enjeux demandent également des actions significatives sur le système d'information.

C'est le rôle des NSSI d'y contribuer : SOA donc, mais aussi Master Data Management et Business Process Management. Nous aurons l'occasion d'y revenir dans de prochains bulletins. D'ici là, un livre blanc sera publié dans les prochains jours pour préciser le rôle joué par les NSSI dans la gouvernance IT. Il sera disponible en ligne sur le site d'Unilog Management. Vous pouvez également m'en faire la demande ici.

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.