Pendant cinq ans, Bouygues Telecom a paré au plus pressé : pour faire face à une croissance importante, l’opé- rateur de téléphonie mobile a développé à tour de bras des applications monolithiques sur la base de technologies propriétaires. Résultat : elle dispose aujourd’hui d’un système d’information massif, difficile à faire évoluer et qui lui revient cher en maintenance. Pour diminuer les coûts de son budget informatique et favoriser une meilleure réactivité, la société n’a donc pas hésité. Reprenant tout à zéro, elle a découpé les applications existantes en services fonctionnels sous forme de composants métiers EJB (Enterprise JavaBeans). Mais cette fois-ci, comme le souligne Alain Delahaye, directeur du pôle composants communs de Bouygues Telecom, “avec une approche normalisée et structurée.”
C’est avant tout l’ouverture de la plate-forme de Sun qui est à l’origine du choix du type de composant : “Les EJB sont réutilisables, ils favorisent donc une réduction des coûts mais également des délais de développement. Or, dans un domaine très concurrentiel comme le nôtre, la réactivité du service informatique est mise à rude épreuve”, explique Alain Delahaye.
Des gains à long terme
Faute d’outils adaptés et surtout de méthodologies, le découpage des applications en services fonctionnels a entraîné un long travail de réflexion : “Les outils de modélisation en UML de Rational Rose sont globalement d’un piètre secours :ils permettent tout au plus d’établir une cartographie des applications. Il leur manque en fait une fonction qui permettrait de faire la liaison entre l’analyse et la génération des composants EJB. La méthodologie pour déterminer la bonne granularité, les différents niveaux de composants et les relations entre eux, nous l’avons élaborée en amont sur la base de notre réflexion uniquement.”
En ce qui concerne le déploiement, Alain Delahaye regrette également l’absence d’outils de simulation, prenant en compte les trois niveaux de l’architecture, qui auraient facilité la répartition des composants entre le client, le serveur ou la base, et permis d’effectuer des tests de charge. Enfin, l’administration n’est pas mieux lotie. Les architectures de ce type nécessitent des outils capables de tracer le fonctionnement des composants, de les identifier, de les localiser en cas de dysfonctionnement, outils qui font aujourd’hui encore défaut sur le marché.
“Nous avons investi sur le long terme, reconna”t Alain Delahaye qui ne regrette pas ce choix technologique. Le marché des EJB est jeune, ce qui explique l’absence d’outils pour gérer des architectures qui sont beaucoup plus complexes que celles qu’on créait avec des environnements client-serveur. En outre, les gains sur ce type d’architecture ne se voient qu’à partir de la deuxième ou troisième génération des applications, quand on commence réellement à réutiliser les composants.”
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
