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)[e-mail]

Les annonces des géants de l'infrastructure

Big Blue lance un serveur de mashup (Mashup Maker). Son Process Server devient par ailleurs capable de modéliser les interactions humaines dans les processus. Enfin, son référentiel métier SOA (Websphere Fabric) digère les métadonnées techniques que lui envoie WSRR, son autre annuaire SOA.

Avec la dernière version de BPMA Suite, la modélisation métier d'IDS Scheer (embarqué par Oracle) et le moteur BPM d'Oracle partagent une même couche de métadonnées. Les modifications des données techniques sont alors retranscrites dans la modélisation métier.

Le projet Genesis, prévu pour la mi-2008, repose sur un environnement d'assemblage d'applications destinées à plusieurs profils de concepteurs, métier ou techniques. Il associe ESB, BPM, référentiels de service, et réseaux sociaux.

La nouvelle version de Biztalk rattrape son retard en gouvernance SOA. Elle s'appuie maintenant sur les référentiels de HP/Systinet et de SOA Software qui proposent des politiques de gestion des services fondées sur des règles métier.

Ce qu'ils en pensent : Bruno Rizzi (Sogeti) : ' les métiers s'investissent dans les projets SOA '

' Cette remontée du SOA vers les couches métier s'exprime aussi bien au niveau des nouvelles offres du marché que celui de l'organisation des projets dans les entreprises. De plus en plus d'instances mixtes se forment, au sein desquelles fonctionnels et techniciens collaborent autour du design des services et des processus qu'ils sous-tendent. Nous constatons, par ailleurs, une différence de maturité entre les couches basses du SOA ?" ESB, BPM notamment ?" et les nouvelles interfaces web 2.0 pour lesquelles les standards d'interopérabilité et de sécurité sont en cours de développement. '

Ce qu'ils en pensent : Philippe Mougin (Octo Technology) : ' le BPM n'est pas si indispensable '

' Nous ne pouvons que nous satisfaire de cette vague du web 2.0, mais il est encore difficile de réaliser des applications stables en Ajax. Les outils de débogage en Javascript présentent encore des faiblesses, et les résultats diffèrent selon les navigateurs. Autre bémol au concept d'application dynamique : le moteur d'orchestration de processus. Nous aurions tort d'en faire un élément indispensable. Dans bien des cas, les méthodes de développement agile suffisent pour assurer un niveau de test et de modification suffisant. Au contraire, le langage BPEL, qui décrit l'orchestration de services via des tags en XML, est souvent mal outillé pour le débogage et le test. Sans compter que l'ajout d'un moteur BPEL provoque une rupture de plate-forme quand celle-ci repose par exemple sur Java. '

Ce qu'ils en pensent : Bernard (Debauche Axway) : ' une utilisation dévoyée du BPM '

' Le BPM, au c?"ur des applications composites, a perdu la composante métier qui le définissait. Donnez à un fonctionnel un outil de modélisation BPEL, il ne pourra rien en faire. Trop technique. Il est indispensable de bien dissocier le design de processus de leur exécution technique. Or, ces deux opérations s'effectuent avec des familles d'outils différents encore mal intégrés. Dans la même idée, le BPM doit être délesté de métadonnées trop techniques. Certains produits du marché exigent de spécifier l'invocation aux services techniques, alors que cette fonction devrait plutôt être confiée aux outils d'intégration tels les EAI ou ESB. '

Ce qu'ils en pensent : Henry Peyret (Forrester) : ' rendre le pouvoir aux métiers '

' Après Dbase 3, puis Visual Basic et le client-serveur, les applications dynamiques constituent la troisième vague de l'informatique concourant à donner plus de pouvoir et d'autonomie aux utilisateurs métier. En connectant les outils de type web 2.0 à l'infrastructure de l'entreprise, les cycles de développement vont considérablement se raccourcir. S'ils se comptaient en années, ils se réduisent déjà en mois avec les méthodes agiles. Nous parlons maintenant de semaines. L'un des enjeux sera de transposer en entreprise les usages des outils communautaires relevant pour l'heure du privé. '