Dans leur grande majorité, les promesses des architectures orientées services (SOA) ne se sont pas encore concrétisées. La faute reposant en partie sur le fossé qui existe entre directions métier et directions informatiques. Voilà, en résumé, les propos tenus par Donald Rippert, directeur technique d'Accenture, lors d'un séminaire chez BEA à l'occasion de l'ouverture du « Accenture Innovation Center for BEA ». Ce centre d'innovation, sis au siège de l'éditeur, a justement pour but d'aider les entreprises à combler ce fossé. Et cela doit être fait dans les 18 mois, a prévenu Donald Rippert, pour que les SOA ne connaissent pas le destin éphémère du hula hoop. Alfred Chuang, le PDG de BEA, a souligné de son côté avoir recherché cette association avec Accenture, car « de toute évidence, personne n'a conduit autant de changements technologiques qu'Accenture ». Le CTO d'Accenture fonde son analyse sur une vision de l'implémentation des SOA en quatre phases : commencer par écrire les interfaces à l'aide de XML, puis exposer l'existant sous forme de services Web, ensuite connecter ces services avec un ESB (Enterprise service bus), et enfin recourir au langage BPEL (Business process execution language for Web services) afin de pouvoir modifier le comportement d'une application sans entrer dans le code. Et pour Donald Rippert, les projets SOA sont aujourd'hui coincés à la phase deux. Difficile de contredire Donald Rippert quand il explique que les retours d'expérience en SOA ne sont pas encore légion, ou que toutes les promesses n'ont pas été tenues. Néanmoins, on pourra objecter que sa vision est extrêmement réductrice : des SOA sans XML, services Web ou ESB peuvent exister ; de même, baser systématiquement un projet SOA sur l'existant n'est pas forcément une bonne idée. Comme le préconisait le directeur du conseil d'Orchestra Networks lors de notre SOA Forum, il vaut mieux partir sur un projet avec l'idée de tout refondre à terme, car la valeur d'une SOA dépend de la valeur de l'existant informatique - si on se base dessus. Or, soulignait l'organisateur du symposium architectes de Capgemini il y a quelques jours, construire un système à partir des transactions existantes est un non-sens qui risque de mener les projets dans une impasse.