EDF mise sur le BPM à grande échelle

La branche distribution d'EDF a refondu sa plate-forme SGE qui fait l'interface avec les opérateurs d'électricité. Elle a misé sur des technologies BPM et SOA.

Le 1^er juillet 2007 sera à marquer d'une croix dans l'histoire d'EDF. C'est à cette date, en effet, que s'achèvera l'ouverture du marché de l'énergie. Cet événement influencera de manière significative le système d'information de la branche distribution du groupe. Il devra encaisser des échanges d'informations multipliés par 100, et les traiter de façon non discriminatoire, qu'ils proviennent d'EDF ou de ses concurrents, comme Poweo. Comment s'y préparer ? En développant un portail de services garantissant une même qualité de prestation à tous et en automatisant autant que possible le traitement des affaires.Initié en 2005, le projet de refonte de SGE (Système de gestion des échanges) a pour ambition de répondre à ce double objectif. Il est porté par ERD (EDF Réseau Distribution), l'une des deux directions qui, avec EGD (EDF-GDF Service), constituent la banche distribution du groupe. SGE version 2 fait appel à plusieurs des solutions de gestion de processus métier (BPM) et à des briques d'infrastructure orientées services (SOA) de BEA. Néanmoins, les difficultés sont à la hauteur des enjeux : répondre à des contraintes drastiques de traçabilité, de confidentialité et de qualité de service. Ceci, tout en gérant 12 000 utilisateurs (dont 7 000 en interne), en s'interfaçant avec les systèmes d'information des autres opérateurs, via des liens B to B et en interopérant avec des applications métier, elles-mêmes appelées à s'adapter à un contexte métier en pleine mutation.

Une phase rigoureuse de prototypage

Mais ERD n'est pas partie d'une feuille blanche en 2005 pour concevoir sa plate-forme de services de nouvelle génération. L'équipe du projet s'est appuyée sur les travaux menés en 2003 et 2004 pour la première version de SGE. A l'époque, il s'agissait de préparer l'ouverture de la totalité du marché professionnel (soit 3,2 millions de clients) fixée au 1^er juillet 2004. SGE v.1 avait été développé sur la base du moteur de workflow du Français W4 et du serveur d'applications de BEA. Sa mise en production avait été douloureuse, l'application ayant souffert de son hétérogénéité et de problèmes de qualité et d'intégration. Cette première expérience servira donc de support de réflexion pour préparer le cahier des charges d'un portail de deuxième génération, taillé pour répondre aux besoins de 2007. L'orchestrateur BPM allait devoir traiter tous les jours plus de 10 000 flux.Afin d'améliorer la performance opérationnelle du distributeur, il allait falloir automatiser bien plus qu'auparavant. A la fin de l'année, environ 80 processus auront ainsi été implantés dans SGE. De façon à s'assurer que les choix techniques répondraient à ces exigences de flexibilité et de montée en charge, l'équipe s'était donc lancée dans une phase rigoureuse de prototypage. Un premier prototype avait été monté pour mettre en concurrence les solutions de BPM de W4, de Webmethods, et de BEA. La solution W4 a été vite écartée car elle n'aurait pu respecter, en l'état, les prérequis du nouveau projet. En définitive, Weblogic Integration (WLI), de BEA, a été sélectionné en raison de sa bonne tenue lors des tests de charge, mais aussi pour la rapidité de développement des processus et sa gestion des transactions distribuées. Un deuxième prototype s'est intéressé plus précisément aux couches de middleware. C'est ainsi qu'Aqualogic Service Bus (ALSB), de BEA, a été retenu pour ses capacités d'interopérabilité avec le back office de la branche distribution d'EDF et avec les systèmes d'information des opérateurs. Webmethods, déjà exploité par ERD, n'a été utilisé, dans le cadre de SGE v.2, que pour certains types de transferts de fichiers. Le prototypage et le cadrage général ayant été achevés à la fin 2005, la réalisation proprement dite a pu alors prendre le relais.Vu l'envergure du projet - il a mobilisé jusqu'à 180 intervenants en maîtrises d'?"uvre et d'ouvrage - la question de l'approche méthodologique ne pouvait être évacuée. L'équipe ERD avait opté pour une démarche en W, aboutissant à découper le projet en deux phases en V. ' La première phase s'était intéressée au maquettage, à la constitution d'un socle technique et méthodologique, au test de performance de ce socle, et à la recette des tests de performance, détaille Denis Rouaud, le chef de projet MOA. La deuxième phase, quant à elle, a porté sur la réalisation des processus, leur test, et l'industrialisation des développements. Nous avons également revu le socle lors de cette étape. ' Ce n'est donc qu'à la mi 2006, une fois réalisée la première ébauche du routeur BPM, que le travail sur les processus est monté en puissance.

Sept jours pour changer de fournisseur

Restait à définir les processus à automatiser. Dans un premier temps, ceux qui devront être obligatoirement opérationnels au 1^er juillet 2007. Bien évidemment, souligne Ayhan Yildiz, l'un des responsables du projet SGE, ' si la procédure est atypique et nécessite un contrôle humain, il n'est pas question de l'automatiser. Mais si l'étude détaillée fait apparaître que les étapes humaines n'ont plus de raisons d'être, le processus devient automatisable '. Les processus ajoutés dans le nouveau SGE bénéficient du renforcement du couplage entre systèmes d'information. ' Les demandes de fournisseurs étaient auparavant traitées manuellement. Désormais, ces requêtes pourront être véhiculées depuis les systèmes d'information des fournisseurs, via des liens B to B. ' Cela étant, la réalisation n'a rien eu d'un long fleuve tranquille. Les processus en jeu sont souvent d'une grande complexité. Une simple demande de changement de fournisseur, par exemple, ne peut être conclue en moins de sept jours (durée légale de la période d'opposition à cette demande). Le processus instancié doit gérer plusieurs allers et retours entre les systèmes d'information des partenaires. Et pour des questions d'intégrité transactionnelle, les référentiels de données impliqués doivent tous être mis à jour avant l'acquittement de l'opération. La reprise des processus et des données de SGE v.1 est une opération très délicate. Le travail de spécification des années 2003 et 2004 n'était pas assez détaillé pour être repris tel quel dans le cadre du nouveau projet. Par ailleurs, le changement de moteur de BPM posait évidemment problème, car les processus de W4 n'étaient pas importables dans WLI. Qui plus est, la logique d'ordonnancement des étapes des processus pouvait différer d'une version à l'autre de SGE. D'où, explique Denis Rouaud, une difficulté supplémentaire pour reprendre les affaires traitées dans SGE v.1. ' Dans certains cas, nous avons dû définir des règles de conversion des données métier. Cela demandait de disposer de ressources connaissant les deux versions de SGE. Nous avions constitué une maquette pour simuler le comportement de processus de SGE V1 tels qu'ils seraient exécutés dans SGE V2 '. Mais, bien que la migration des données ait pu être conduite en quinze jours pour préparer le lancement de SGE v.2.0, le 15 janvier dernier, il a ensuite fallu retravailler ces données en fonction des problèmes remontés par les chargés d'affaire. L'intégration avec les applications métier d'ERD et d'EGD, certaines sur mainframe, d'autres de type client-serveur, a parfois aussi été source de complications techniques, en raison notamment de différences de logiques d'ordonnancement.

Intégrer petit à petit les cas particuliers

Depuis le mois de janvier, l'équipe ERD a entamé un compte à rebours à haute tension, car il lui faut disposer pour le début du mois de juin d'une plate-forme opérationnelle à même de répondre aux obligations réglementaires qui entreront en vigueur au 1^er juillet. Ces quelques mois de peaufinage l'ont conduit à optimiser SGE (avec la sortie d'une version 2.1) et à poursuivre l'ajout du corpus de processus (notamment dans SGE version 2.5 qui sera livré ce mois-ci). Cette date fatidique ne marquera pas pour autant la conclusion du projet. L'équipe s'est engagée dans une logique de montées en palier régulières. Il s'agira de coller aux évolutions des applications métier interfacées avec SGE, de tenir compte du retour d'expérience des premiers mois, et, aussi, d'enrichir le référentiel de processus afin d'englober autant que possible une multitude de cas particuliers, produits de soixante ans d'engagements contractuels. Jusqu'à quel point le BPM continuera-t-il de traduire la complexe réalité de l'entreprise ? C'est une question que le distributeur filialisé, qui verra le jour au 1^er janvier 2008, suite au regroupement des directions ERD et EGD, aura largement le loisir d'[e-mail]

Le portail SGE (gestion des échanges) en chiffres

80 processus métier.
500 interfaces homme/machine.
10 000 flux journaliers.
12 000 utilisateurs.

La déréglementation pousse à l'automatisation

1999 : aux grandes entreprises.
2004 : aux professionnels, PME-PMI et collectivités. A ce stade, 70 % de l'énergie (électricité et gaz) consommée est libéralisée.
2007 : à partir du 1^er juillet, les particuliers pourront changer de fournisseur d'électricité. Tout le marché sera alors libéralisé.

2004 : mise en place d'un portail SGE (Système de gestion des échanges) ouvert aux fournisseurs d'électricité concurrents d'EDF. Début d'automatisation des processus métier.
2007 : refonte de la plate-forme SGE. Sa capacité de montée en charge est renforcée et de nouveaux processus sont automatisés.

Derrière le portail : SOA

2005 : La question SOA ne s'est pas posée au démarrage. Mais une fois définie la plate-forme cible, il est apparu que celle-ci répondait à une architecture orientée services.

2006 : Le développement des services Java-Soap s'est appuyé sur un canevas de bonnes pratiques, des modèles de spécification et des guides de déploiement et d'exploitation. La taille optimale des services s'est révélée délicate à estimer. Parfois, la granularité trop fine des services a occasionné des développements redondants.

2007 : Avec la préparation de l'ouverture, la flexibilité de l'approche SOA est appréciée. Pour Emmanuelle Ruget, responsable du département de pilotage des programmes et projets de ERD, ' la situation actuelle est très dynamique. Avec SGE v.2, nous modifions vite les processus et les écrans, ce qui n'était pas le cas avec SGE v.1 '.

Demain : Reste à EDF à capitaliser sur cette expérience pilote de déploiement SOA. Une cellule de réflexion avait été mise sur pied. Entre autres interrogations : le référencement et l'administration des services.

Weblogic Integration, le grand orchestrateur des services et processus

Weblogic Portal fait appel aux services de façade (création, synchronisation, annulation d'instance de processus, etc.). Ils travaillent de façon déconnectée de l'interface homme-machine, et se chargent d'activer le routeur BPM.

Cet orchestrateur lance un processus et initialise le traitement de l'affaire qui est orientée en fonction des profils d'habilitation des gestionnaires. A chaque type de processus est associé un canal de publication-abonnement, géré par Weblogic Integration.

Appel des services métier communs, mise à jour des bases de données (notamment le référentiel des données contractuelles), et attente des résultats par le processus.

Appel des services d'intégration et d'extraction de données pour les échanges avec des partenaires ou avec des applications métier du pôle de distribution (notamment pour tout ce qui relève de la facturation et de la reconstitution des flux d'énergie). L'essentiel du travail est réalisé par Aqualogic Service Bus. L'outil de Webmethods est réservé au transfert de certains fichiers.

La requête du partenaire n'est pas saisie dans le portail mais véhiculée par des liens B to B. Comme à l'étape 1, elle se traduit par l'invocation des services de façade.

Passage à l'étape suivante et mise à jour du statut des traitements.

Mise à jour des référentiels de données (de façon similaire à l'étape 3).

(source : ERD et Unilog)

Les quatre principaux modules

Logiciel : Weblogic Portal

Version : 8.1

Domaines fonctionnels :
Services d'exploitation et d'administration des portails. Gestion du cycle de vie des portails. Référencement des contenus.

Logiciel : Weblogic Integration (WLI)

Version : 8.1

Domaines fonctionnels :
Services d'intégration EAI.
Modélisation, orchestration et analyse des processus métier.
Administration des flux de messages et des processus.

Logiciel : Weblogic Server (WLS)

Version : 8.1

Domaines fonctionnels :
Plate-forme d'exécution d'applications J2EE et SOA.
Services de gestion transactionnelle des applications SOA.
Services d'administration et de gestion des clusters.

Logiciel : Aqualogic Service Bus (ALSB)

Version : 2.1

Domaines fonctionnels :
Services d'intégration EAI et de médiation entre applications grands systèmes, Java, .Net et à base de services web.
Gestion des interactions entre services au sein d'une SOA.

Questions/Réponses

Est-ce qu'une instance externe à EDF suit le projet ?
Oui, la Commission de régulation de l'énergie (CRE) avait émis des recommandations quant aux évolutions à apporter aux systèmes d'information de la branche distribution d'EDF, et plus spécifiquement à SGE. Le cadrage portait notamment sur la mise en place de traitements non discriminatoires entre les fournisseurs d'électricité, l'automatisation des processus, et la qualité de service. L'échéancier des évolutions susceptibles d'être apportées à SGE court jusqu'en 2009.

Comment les lots ont-ils été répartis entre prestataires ?
Le projet avait été subdivisé en trois lots : la gestion de processus métiers a été attribuée à Unilog, les échanges B to B à Capgemini, ainsi que le lot portail et services métier. Quatre consultants BEA sont intervenus sur le projet.

Quelle plate-forme système a été retenue ?
Deux domaines Weblogic ont été définis, servis chacun par un couple de serveurs Sun Fire V490 quadriprocesseurs sous Solaris 10. Les serveurs sont hébergés dans les centres de données d'EDF, mais sont exploités par ERD.

Un tel projet coûte-t-il cher ?
Selon nos estimations, le budget global s'établirait aux alentours de 30 millions d'euros. Ce qui, comparé aux investissements consacrés par EDF dans le domaine des PGI, reste assez modeste.

Quelles leçons retenir ?
Qu'il est possible d'associer BPM et SOA pour une application critique à condition de découpler et de bien connaître les interactions entre les composants, de ne pas négliger le monitoring, de synchroniser les montées en version des composants, etc.

www.01blog.fr/1904

Ayhan Yildiz (ERD) : ' la performance est l'un des grands enjeux du projet '

Que prévoyait le cahier des charges en matière de performances ?
Ayhan Yildiz : Nous avions défini des critères qui précisaient le volume de transactions qu'il convenait de gérer, mais aussi les temps de réponse maximaux. Notre objectif était de garantir la performance globale des chaînes et pas seulement celles des briques élémentaires. Les temps de réponse aux requêtes sur notre réseau interne ne devaient pas dépasser 2,5 à 3 secondes.

Quelle a été la place du test dans le cycle de développement ?
A.Y. : Les moteurs de workflow ont été testés à l'occasion du prototypage. Lors du développement, nous avions constitué avec nos partenaires une équipe de test mutualisée, ceci pour des questions de délais. Dès le développement des premières briques, nous avons lancé des campagnes de test sous Load Runner de Mercury.

Qu'aviez-vous envisagé en termes de supervision ?
A.Y. : Nous avons mis sur pied une équipe spécifique à la conduite de SGE. Celle-ci dispose, outre le classique logiciel de supervision Patrol, d'outils spécifiques de reporting et de suivi de performances. A l'avenir, nous pourrions nous intéresser à une supervision de type BAM, qui nous apporterait une vision plus transverse. Nous nappréciions pas forcément bien la signification fonctionnelle des remontées techniques. Nous aimerions par conséquent établir un meilleur lien entre les deux niveaux.