| Grégory Weinbach
(Objet Direct (Homsys Group)) : "L'urbanisme, c'est découpler les applications" Par JDNet Solutions (Benchmark Group) URL : http://www.journaldunet.com/solutions/itws/030530_it_weinbach.shtml SSII regroupant 250 personnes à Paris et dans plusieurs grandes villes françaises, réalisant en 2002 un CA de 18 millions d'euros, Homsys Group se divise en trois branches, la première - Kedros - centrée sur les systèmes et réseau, la seconde - Homsys - ciblant le décisionnel (BI) et les portails, et la troisième - Object Direct - dont le métier est d'assurer l'évolution des architectures. Pour cette dernière structure, 2003 a coincider avec une reprise nette des projets de refonte d'applications existantes autour de nouvelles plates-formes comme J2EE. L'occasion pour Grégory Weinbach d'aborder le thème de l'urbanisation du SI, des processus métiers à l'EAI. Propos recueillis par Jérôme Morlon le 30/05/2003
Grégory Weinbach. Le but d'une démarche d'urbanisme n'est pas d'unifier: on sait très bien faire dialoguer ensemble des applications, avec par exemple un MOM [NDLR: Message Oriented Middleware] type MQSeries, mais si on se focalise sur l'intégration technique, on peut investir beaucoup d'argent dans quelque chose qui ne répond pas aux besoins de l'entreprise. L'objectif ultime est de permettre au SI d'évoluer facilement, de faire par exemple migrer une application progicielle vers du spécifique ou l'inverse, d'intégrer un nouveau service, etc. Pour cela, l'essentiel est de pouvoir remplacer une application par une autre sans toucher au reste: il s'agit de découpler les applications, s'assurer notamment qu'un message est indépendant techniquement de sa source et de sa destination, ce qu'une approche EAI n'effectue que vu de l'extérieur. Il s'agit d'un projet à étapes. D'abord, il est nécessaire d'identifier ce qui constitue la chaîne de valeur ajourée de l'entreprise, les processus métier: comment intéragissent les systèmes, quels sont les flux qui sont échangés, etc. Ceci permet de bâtir un référentiel métier qui modélise une cible proche de l'existant, destinée à évoluer, dynamique, itérative. Prendre en compte cette dimension fonctionnelle, c'est conserver de la souplesse de son SI afin de mettre en oeuvre un lien objectif entre les décisions stratégiques et leurs projections sur l'infrastructure technique. Il est important de note que le processus d'urbanisation est un projet d'entreprise qui s'inscrit dans la durée, et qui est impliquant: la décision émanant généralement de la direction générale, nécessite des budgets importants, la création d'une structure fonctionnelle de liaison... La notion de processus est mise en avant par les acteurs du monde des progiciels comme SAP, PeopleSoft ou Siebel, Cela répond-il à la problématique d'urbanisation ? L' approche progicielle n'est pas urbanisée pour la raison suivante: ce que nous définissons comme des blocs d'urbanisme découplés sont au contraire fortement couplés dans un progiciel, où il est difficile de faire évoluer un module sans faire évoluer le reste. On ne maîtrise pas ses processus, on ne peut pas, par exemple, externaliser un bloc d'urbanisme. Par contre, la démarche progicielle est pertinente si on veut déléguer la gestion de ses processus, et à l'inverse, il n'est pas interdit dans une démarche d'urbanisme d'utiliser des éléments progiciels comme choix d'implémentation technique. Comment s'organise la modélisation et l'évolution du projet d'urbanisation ? Prenons l'exemple de notre client Bouygues Telecom, pour lequel nous avons mis en place une démarche d'urbanisme fin 99 début 2000 avec la construction d'un référentiel métier ciblant le SI commercial, mais ayant un impact sur l'ensemble du réseau de l'entreprise. Nous avons procéder par des entretiens avec les acteurs de la maîtrise d'ouvrage, puis par validation et prototypage de spécifications formelles: par le biais d'enchaînement d'écrans, de scénarios concrets de manipulation de données réelles, nous avons pu obtenir un retour sur des simulation de processus. Par ailleurs, il fallait favoriser l'appropriation du formalisme de notre référentiel par les acteurs, ce qui est un aspect fondamental: sans un transfert de compétence et une bonne communication, on court le risque que les travaux restent lettres mortes faute d'une maîtrise d'un vocabulaire pivot.
Nous aimons travailler avec l'UML, qui est un outil standard bien adapté à la modélisation de bout en bout, mais n'est pas obligatoire. Les entreprises ont souvent des outils de BPM avec leur formalisme propriétaire ou non, qui permettent de faire beaucoup de chose. Cela dit, le BPM ne permet pas de décrire le contenu fonctionnel des flux, au contraire d'UML. Pour tout problème de consultation, écrivez au Webmaster Copyrights et reproductions . Données personnelles Copyright 2006 Benchmark Group - 69-71 avenue Pierre Grenier 92517 Boulogne Billancourt Cedex, FRANCE |
|