Les métiers contrôlent les développements applicatifs

La gestion de processus (BPM) n'a pas permis aux métiers de répercuter leurs exigences sur l'informatique. Les applications dynamiques prônées par IBM et BEA le leur promettent.

' Conçu par les gens, bâti pour le changement (design by people, build for change) '. Telle est la formule choisie par Forrester pour expliquer les applications dynamiques. Le concept que le cabinet d'analyse a introduit il y a un an est aujourd'hui repris par les géants de l'infrastructure, en particulier IBM et BEA. Comme les applications composites (dont elles sont une sous-partie), les applications dynamiques consomment des services. Mais ce qui les caractérise avant tout, c'est l'autonomie qu'elles procurent aux utilisateurs métier dans le design et l'assemblage de leur environnement.Encore au stade de balbutiement, ces applications dynamiques exigent en théorie une interaction entre, d'une part, les nouveaux frontaux logiciels (environnement Ajax, réseaux sociaux, mashup...) axés sur la manipulation de composants et, d'autre part, la gestion de processus, l'orchestration et l'accès aux services. Elles portent finalement les mêmes promesses que celles non tenues par le BPM (Business Process Management), censé apporter aux fonctionnels des outils de reconfiguration rapide de leur processus de gestion.Annoncé à la mi-septembre, livré dans sa première mouture à la mi-2008, le projet Genesis de BEA prend cette orientation. Il est centré sur l'assemblage de composants applicatifs, repose sur le partage de métadonnées communes entre les trois grandes couches de son infrastructure (ESB, BPM et environnement web 2.0), et cible plusieurs profils dans l'entreprise.Les dernières avancées d'IBM renforcent aussi l'autonomie des fonctionnels. Il lance un outil de création de mashup et prend désormais en compte les interactions humaines (qui jusque-là ne pouvaient être traduites que lors des phases techniques d'assemblage et d'orchestration de services) dans son environnement de modélisation de processus. Il place également son nouveau référentiel métier (issue de l'acquisition de Webify) au c?"ur de son infrastructure SOA. Sa vocation : conditionner l'usage de services techniques par des règles métier.L'engouement pour ces applications dynamiques tient à la conjonction d'au moins trois constats : d'abord, la poussée en entreprise du web 2.0 (flux RSS, wiki, blog), largement adopté dans les usages personnels ; ensuite, la nécessité de raccourcir les cycles de développement et d'évolution des applications ; et enfin, la volonté de mieux exploiter les infrastructures SOA naissantes, dont la flexibilité reste encore inexploitées par les frontaux applicatifs.' Les logiciels organisés en silos continueront bien entendu d'exister. Mais, à terme, 50 % des frontaux seront conçus sur la base d'applications composites ', prévoit Henry Peyret, analyste au Forrester. Avant de voir le jour, ces applications devront néanmoins répondre à deux problématiques. L'une porte sur le délicat passage de relais entre les exigences métier et leurs réalisations techniques, et vice-versa. C'est précisément à ce niveau que le BPM est perfectible. Les serveurs de processus d'Oracle (BPMA Suite) ou d'IBM (Process Server) sont, en effet, capables de récupérer et d'exécuter les données issues de la modélisation de processus. Mais, jusqu'à peu, ils ne savaient pas réinjecter dans les modèles les modifications effectuées par les équipes techniques. Autre problématique : prévoir les changements d'exigences dès la phase de design de l'application.

Prendre en compte l'intégrité des données

' A ce stade, il s'agit d'identifier les changements qui relèveront des responsables métier, sans mettre en péril le système ', poursuit Henry Peyret. Par exemple, si l'on autorise un fonctionnel à mettre à jour des applications par le biais de mashup, qu'en est-il de l'intégrité des données en cas de plantage du navigateur ? L'opération ne doit-elle pas plutôt être assurée par un ESB ou un EAI, et donc confiée aux équipes techniques ?Les produits des éditeurs s'articulent par conséquent autour de ces deux contraintes ?" gestion du changement et passage de relais entre métier et informatique. Dans la stratégie Genesis de BEA, le futur environnement d'assemblage ou de composition (Workspace 360) se destine autant aux développeurs et aux architectes qu'aux analystes métier et aux utilisateurs finals. Les composants réutilisables mis à disposition apparaîtront sous différentes vues (techniques ou métier) selon les profils qui les exploitent. ' Notre environnement de design s'appuiera sur l'assemblage de services, sous la forme de widgets, indique Ajay Gandhi, responsable des réseaux sociaux chez BEA. Il s'agira, par exemple, d'un processus, d'un accès à des données, ou d'un rôle. Des éléments aussi bien métier que techniques donc. L'interaction entre ces composants sera conditionnée par l'échange de métadonnées '. Et cet échange se matérialisera en présence d'un référentiel unique stockant les différentes définitions des widgets. En l'occurrence, le référentiel de Flashline, société rachetée par BEA. Son gestionnaire d'actifs SOA sera partagé par les nouvelles applications web 2.0 de l'éditeur (Ensemble, Pathways et Page), son portail, son BPM, son serveur d'applications ou encore son bus de service. ' Nous travaillons actuellement sur la définition des schémas et des modèles des métadonnées ', précise Ajay Gandhi.Chez IBM, la vision produit est plus touffue, tant son portefeuille SOA est pléthorique. Mais l'on retrouve la même volonté de garantir aux métiers une meilleure emprise sur les services. Son architecture SOA s'articule autour de son référentiel métier (Websphere Fabric, issu de Webify), qui concentre, outre la gestion des droits et du cycle de vie des services, des règles d'exploitation desdits services soumis à des paramètres métier (profils d'utilisateurs, canal de diffusion...). Fabric tend à devenir une pièce maîtresse du design d'application. Le BPM accède ainsi aux ressources du référentiel. ' Nous proposons le même environnement de conception, pour le design des règles métier, la modélisation de processus, et enfin l'assemblage et l'orchestration de services qui résultent de cette modélisation ', rapporte Jean-Marc Langé, Architecte SOA chez IBM. A noter également que Fabric, pour appliquer ses règles métier, devra récupérer certaines des métadonnées techniques (version d'un service, temps de réponse...) stocké dans WSRR, le référentiel de définition des services web d'IBM, qui centralise notamment les informations WSDL et les composants SCA.

Les petits acteurs ont aussi leur mot à dire

Ces dernières avancées de Big Blue vont clairement dans le sens d'un meilleur alignement des processus informatiques sur les exigences métier. Mais cette architecture reste encore décorrélée des frontaux utilisateurs. Notamment de Mashup Maker, le nouvel outil d'assemblage de widgets de Big Blue, ou de Portlet Factory, l'outil de composition de portlets Java. Même si ces deux outils sont capables de récupérer des séquences de processus via des services web.IBM et BEA, tout comme Oracle et SAP, ont aujourd'hui tous les composants indispensables aux applications dynamiques. Mais une multitude d'autres plus petits acteurs ont également une carte à jouer. ' Notamment Optimus ou Lombardi, dont le BPM est très flexible. Du moins si on le compare à celui d'IBM, qui privilégie la volumétrie à la souplesse ', précise Henry Peyret. D'où, souligne-t-il, l'émergence de groupe d'intérêts formés des acteurs du workflow et des éditeurs de frontaux de nouvelle génération. Retenons le ' think tank ' français constitué de W4 (BPM), Xsarnet (gestion de flux métier), Twinsoft (serveur de mashup), et Dreamface Interactive (mashup et outils décisionnels open source).v.berdot@01informatique.presse.fr