Mercury présente les fruits de son mariage avec Systinet

Le mariage entre Mercury, spécialiste du test et des outils de gouvernance du système d'information, et Systinet, éditeur de l'annuaire de services le plus utilisé par les fournisseurs de solutions middleware pour la mise en oeuvre d'architectures orientées services (SOA), vient de donner ses premiers fruits. Mercury, qui a acquis Systinet en janvier dernier, a annoncé à sa conférence utilisateurs Mercury World la sortie de Systinet v2, ainsi que de nouveaux produits de test intégrés à l'annuaire. La version 2 de Systinet se veut à la fois un annuaire référençant les services et un référentiel de métadonnées sur le système d'information. Entre autres nouveautés, le logiciel inclut désormais un tableau de bord pour repérer et suivre ces données et gérer le cycle de vie de ces services (demandes d'approbation, déploiement, disponibilité...). Des rapports prêts à l'emploi sont prévus pour le reporting sur ces services. Les outils de test intégrés à l'annuaire de services La gamme d'outils de test a également été remaniée afin de mieux prendre en compte les caractéristiques des SOA. Elle s'enrichit de Mercury Service Test Management, qui peut s'appuyer sur l'annuaire Systinet répertoriant les services pour élaborer des scénarios de test. Autre nouveauté, Mercury Service Test offre notamment de tester les services dépourvus d'interface utilisateur, sur le plan fonctionnel comme pour la montée en charge (avec sa technologie historique LoadRunner). Parmi les fonctionnalités spécifiques à la SOA ajoutées aux produits Mercury, notons encore dans le module Business Availability Center la capacité de détecter les services non enregistrés (« rogue services »), soit parce qu'ils existaient avant la mise en place d'une procédure d'enregistrement, soit parce qu'ils auraient proliféré de façon incontrôlée. Ils peuvent alors être supervisés au même titre que les autres : relations avec les autres services, performance, etc. Le module est intégré à LoadRunner afin de corréler les données issues des tests et celles issues de la phase de production, pour aider à la résolution des problèmes. Cet ensemble d'outils de bonne gouvernance des SOA ne vaut bien sûr que si l'on s'en sert (intégration des tests plus tôt dans la phase de développement, respect de la procédure d'enregistrement des services, etc.), or rien ne dit que les directions informatiques soient prêtes pour une telle démarche. Comme l'admet Elie Kanaan, vice-président marketing EMEA de l'éditeur, « ce n'est pas parce qu'on vend des machines à écrire qu'on aura de bons auteurs ; là, c'est pareil ». La fusion avec HP devrait conduire à une CMDB fédérée Un autre élément pourrait retarder l'adoption de ces outils de qualité pour les SOA : la prochaine fusion annoncée avec HP (voir l'encadré ci-dessous). L'éditeur de la plate-forme de supervision Openview dispose en effet déjà d'une base répertoriant les éléments matériels et logiciels de l'infrastructure informatique (une CMDB, configuration management database). Pour Elie Kanaan, à y regarder de plus près, cela ne pose pas vraiment de souci : « La CMDB de HP est héritée en fait du rachat de Peregrine, or nous avions commencé à nous intégrer avec Peregrine. Nous avons donc rouvert ce canal. » Et conclu que la meilleure solution consistait à créer une CMDB non pas unique mais fédérée, s'appuyant sur deux CMDB, l'une répertoriant les éléments d'infrastructure, l'autre les services et applications. « Elles fonctionnent sur des critères différents, comme le type ou la fréquence des changements. » Côté gestion d'applications, Elie Kanaan juge également Mercury et HP parfaitement complémentaires, « le premier avec son approche top-down, le second bottom-up ». Selon lui, HP et Mercury partagent beaucoup de clients pour lesquels il fallait réaliser des intégrations au cas par cas. Désormais, ils n'auront qu'un fournisseur, et l'intégration sera déjà faite.