 |
|
|
| |
| Infrastructure/Chantiers |
| ROI
des Web Services: les erreurs à ne pas commettre |
| Les risques liés à la technologie d'intégration rendent difficile le calcul du retour sur investissement. Récapitulatif des points à prendre en compte avant de se lancer dans l'aventure. (Lundi 6 janvier 2003) |
 |
Est-il envisageable d'élaborer
une formule pour calculer le retour sur investissement
(ROI) d'une application à base de Web Services ?
Pour beaucoup d'analystes, cet exercice demeure des plus
difficile. Classiquement, cette équation doit avant
tout prendre en compte les problématiques métier
auxquelles est censé répondre un tel projet,
et ceci sans omettre les spécificités de
l'entreprise dans laquelle ce dernier est mise en oeuvre.
Dans le cas des solutions Web Services, il est vrai qu'une
question de taille fait obstacle à cette opération :
la technologie d'intégration inter-applicative
du même nom, dont SOAP et WSDL font figure de socle,
affiche encore de nombreuses incertitudes.
Du
manque de sécurité à l'immaturité
des standards
Dans son ouvrage
intitulé Web Services Business Strategies and
Architectures, Gunjan Samtani cerne plusieurs risques
inhérents au lancement d'une telle initiative :
-
Un niveau de compatibilité insuffisant. Malgré
le support quasi général des Web Services
affiché par la plupart des serveurs d'applications
du marché, Samtani note d'emblée que les
fonctions offertes par les interfaces actuelles ne peuvent
prétendre soutenir le déploiement de composants
applicatifs critiques. Force est de constater en effet
que SOAP et WSDL demeurent incapables de gérer
les transactions longues et complexes.
- Une technologie
en perpétuelle évolution. Disponibles
depuis 2001, les premiers outils et autres serveurs d'intégration
labélisés "Web Services" s'arrêtent
aux simples actions de requête/réponse (offertes
par SOAP et WSDL). "Cet état qui illustre
bien le chemin à parcourir avant d'aboutir à
une infrastructure d'intégration standardisée
à tous les étages présente pour principale
conséquence de rendre mouvantes les solutions en
question", commente Samtani.
- Des standards immatures. Cette difficulté
serait d'autant plus vrai que les quelques langages d'ores
et déjà définis sur le terrain des
Web Services, qu'ils soient en version finalisée
ou non, demandent pour la plupart à être
encore optimisés. Samtani n'hésitant pas
à citer le cas de WSDL et des spécifications
de l'annuaire UDDI...
- Un manque de sécurité. Autre risque
pointé du doigt : le danger lié aux
défauts des services Web en matière de sécurité.
Selon Samtani, il s'agirait d'un des principaux facteurs
présidant à l'adoption ou la non-adoption
de la méthode d'invocation. Parmi les éléments
fondamentaux de ce domaine, figureraient notamment l'authentification,
l'autorisation, mais également la protection et
la non-répudiation des données.
- La qualité de services externes. Pour
finir, Samtani évoque la nécessité
de garantir une certaine qualité aux Web Services
exploités en environnement BtoB. Entendez par qualité,
une exigence de sécurité mais aussi de performance
des accès au sens large - ce qui inclut le taux
de disponibilité et le temps de réponse
principalement.
Les
projets pilotes sur des périmètres restreints
ouvrent la voie
Comment réduire au
minimum l'ensemble de ces risques ? "Il
est conseillé de commencer par implémenter
une couche de Web Services autour d'une application pilote,
le tout en suivant une méthode de suivi de projet
traditionnelle (choix des solutions, implémentation,
etc.), explique Samtani.
Cette première expérience permettra de définir
une première liste de règles de bonne conduite,
correspondant à la culture de l'entreprise et ainsi
qu'à son système d'information... qui pourront
être appliquées par la suite à un
périmètre plus large."
|
|
|
|
|
|
|
[