Partager via

Définition de la vision

  • Article

 

Mary Kirtland
Microsoft Corporation

10 janvier 2001

Dans la colonne de la semaine dernière, j’ai présenté l’équipe de conseils sur les services web et notre mission : la création, le déploiement et l’exploitation d’exemples de services Web pour illustrer les types de problèmes que vous devez prendre en compte lorsque vous faites de même. J’ai également présenté notre premier exemple de projet, le service Favoris.

Merci à tous pour vos commentaires et commentaires. Nous faisons le suivi des problèmes que vous soulevez, alors continuez à venir !

Quelqu’un a demandé pourquoi il nous faudrait trois mois pour publier l’exemple et pourquoi nous n’avions pas commencé à l’utiliser avant d’annoncer l’idée. En fait, nous travaillons sur favoris à temps plein depuis deux mois. La plupart des fonctionnalités sont, eh bien, fonctionnent... mais il y a encore un peu de travail à faire avant que tout soit empaqueté et soigné dans un exemple que vous pouvez installer sur vos propres machines ou essayer sur Internet. La rédaction, la révision technique, la modification et le traitement de tous les articles que nous voulons expédier avec nos exemples de sources prend également du temps. C’est pourquoi nous visons des cycles de projet de trois mois. Nous croisons les doigts pour que nous puissions obtenir la première version de Favoris en février. (Au fur et à mesure que j’écris ceci, l’équipe effectue un exercice de planification pour obtenir une meilleure estimation de la date de publication.)

Certains commentaires supposent également que nous utilisons le .NET Framework pour développer cet exemple. Ce n’est pas nécessairement le cas. Nous utiliserons toutes les technologies que nous pensons être les meilleures pour le travail. Et le meilleur ne signifie pas toujours techniquement supérieur, plus facile à utiliser, ou la plupart des actualités. Quel que soit notre choix, nous vous expliquerons pourquoi et nous vous expliquerons quels problèmes nous avons rencontrés lorsque nous avons essayé de l’utiliser.

Cette semaine, nous allons commencer à examiner les problèmes rencontrés par notre équipe lors de la création du service Favoris. Il y a beaucoup de retard, mais nous allons commencer par le début: déterminer les buts et les objectifs du projet.

Mise en route

Dans le modèle de processus Microsoft Solution Framework , la première phase d’un projet est la phase de planification. Pendant la phase de planification, l’équipe de projet et les clients créent une vue d’ensemble des objectifs et des contraintes du projet. Le livrable principal de cette phase est un document de vision, qui contient une analyse du problème métier, une description des objectifs du produit, un plan du concept de solution, des profils des utilisateurs du produit, des objectifs de conception et une définition de l’étendue du projet. La phase de conception aboutit à l’étape approuvée par la vision/l’étendue .

Notre équipe est partie d’un point de départ inhabituel : nous savions que nous voulions écrire un service web, mais nous n’avions pas de domaine problématique particulier à l’esprit, et nous n’avions pas d’applications existantes que nous devions utiliser. Ainsi, la première chose que nous devions faire était de proposer un scénario d’entreprise raisonnablement réaliste qui pourrait justifier la création d’un système évolutif, fiable, etc., etc., etc. Service web.

Nous avons commencé par enfermer un groupe de personnes dans une salle et réfléchir à des entreprises ou des industries potentielles, des services et des problèmes techniques qui constitueraient de bons sujets à guider. En cours de route, nous avons trouvé quelques raisons pour lesquelles vous pourriez vouloir créer des services web :

  • Vous êtes une source de données sensibles au temps ou paramétrables que les utilisateurs finaux ou d’autres entreprises souhaitent utiliser. Si les données ne changent pas souvent et que les clients veulent presque toujours toutes les données, vous pouvez tout simplement publier un document XML sur votre site web. Mais si les clients souhaitent exécuter des requêtes sur vos données, un service web est très logique. Si vous souhaitez envoyer des données aux clients, les opérations d’abonnement et de notification sont également des services web potentiels.
  • Vous implémentez des algorithmes que d’autres entreprises ne peuvent pas ou ne veulent pas implémenter eux-mêmes. Dans ce cas, chaque algorithme est un service web potentiel : les clients transmettent les données, vous répondez avec la réponse.
  • Vous agrégez plusieurs autres services pour fournir un service de niveau supérieur. Dans ce cas, les clients utilisent votre service, car il fournit la combinaison d’informations qu’ils souhaitent, ce qui leur évite de combiner les services existants eux-mêmes.
  • Vous souhaitez intégrer vos processus d’entreprise à des partenaires. Chaque étape du processus métier qui traverse une limite d’entreprise est une opération potentielle de service web ou de service web.
  • Vous disposez d’une architecture d’entreprise hétérogène et/ou géographiquement distribuée, dans laquelle l’utilisation de réseaux privés ou de protocoles étroitement couplés pour l’intégration d’applications n’est pas pratique. L’API de chaque application que vous souhaitez intégrer est un service web potentiel.
  • Vous fournissez des services d’infrastructure (« plomberie ») pour d’autres développeurs d’applications web et de services web, par exemple un service d’identité ou un service de facturation. Au lieu de créer des bibliothèques d’API personnalisées pour chaque plateforme cliente, vous pouvez exposer votre API en tant que service web.

Bien sûr, pour l’une de ces raisons, vous devez également déterminer s’il existe un nombre suffisant de clients potentiels pour votre service pour justifier les coûts de son implémentation et de son exploitation.

Nous avons également rapidement réalisé qu’il existait d’autres considérations lors de la création d’exemples de services pour l’éducation d’un public de développeurs en général. Tout d’abord, les scénarios métier ne doivent pas nécessiter une connaissance approfondie d’un secteur donné. Deuxièmement, nous voulons que vous puissiez installer et exécuter les exemples sur vos propres ordinateurs. Troisièmement, de nombreux scénarios intéressants nécessitent un ou plusieurs magasins de données ou flux. Il existe de nombreux problèmes lorsqu’il s’agit d’envoyer un exemple de code source qui montre comment accéder aux sources de données que nous ne possédons pas. Et nous ne possédons aucune source de données... du moins pas que nous sommes libres de donner un échantillon.

Cela nous a conduits loin de scénarios tels que la banque en ligne, l’enregistreur vidéo numérique de contrôle à domicile, case activée status de vol ou le serveur de bandes dessinées quotidiennes à quelque chose plus semblable à celui d’un service d’infrastructure. Nous avons commencé à réfléchir aux types de services web que MSDN pouvait fournir (des services réels, pas des exemples). Une idée que les gens ont vraiment aimé était un moyen de suivre les articles MSDN qu’ils voulaient retrouver, quelle que soit la machine qu’ils utilisaient pour accéder à MSDN. Cela nous a conduits à l’idée de favoris côté serveur.

The Vision, Rev 1

Une fois que nous avons eu une idée approximative du service que nous voulions créer, nous avons créé un scénario métier autour de celui-ci :

  • Nous cherchons des moyens d’élargir notre base de clients pour notre pratique de développement web et de générer un flux de revenus régulier. Nous croyons que nous pouvons atteindre ces deux objectifs en fournissant des services Web de haute qualité que les sites Web voudront utiliser. Étant donné que les services web sont un nouveau concept, nous pensons que les clients potentiels devront être convaincus qu’ils peuvent parier une partie de leur entreprise sur nos services. Nous avons donc besoin d’un service web teaser qui :
    • Offre une valeur évidente aux sites Web des clients potentiels.
    • Ne fournit pas de service stratégique.
    • Montre la qualité de nos pratiques de développement et d’exploitation.
    • Peut être implémenté et déployé à un coût raisonnable pour nous.

Voici la première étape de notre vision du projet :

  • The server-side Favorites Service will enable Web surfers to store their favorite links in a safe, secure, central location, so their favorites are accessible anywhere, any time. We will offer the service free of charge to all users; however because we want to protect each user's privacy, users will need to be authenticated to access their favorites. By using the service through a client Web site, users agree that we may use their favorite lists after all personally identifying information is stripped from the data. Dans la deuxième phase de ce projet, nous allons obtenir des licences sur des services supplémentaires pour des sites Web. Par exemple :
    • Statistiques sur les pages de leurs sites qui sont mises en signet.
    • Liens recommandés basés sur une analyse d’affinité de tous les favoris utilisateur.

D’un point de vue technique, ce scénario semblait répondre à la plupart des questions que nous avions entendus de la part des clients. La logique métier n’a pas été trop difficile à implémenter ou trop difficile à expliquer à nos lecteurs. Mais une fois que l’énoncé de vision a été écrit pour tout le monde à regarder, quelques grands drapeaux rouges sont montés:

  • Nous aurions besoin d’un schéma d’identification utilisateur global, un schéma suffisamment commun pour que les sites Web puissent transmettre l’identificateur d’utilisateur à notre service.
  • Comment authentifier l’utilisateur final lorsque les demandes proviennent d’un site Web plutôt que directement de l’utilisateur final ? On dirait que nous aurions besoin d’une délégation ou que nous aurions besoin d’approuver les sites Web pour effectuer des requêtes au nom d’un utilisateur uniquement lorsque l’utilisateur final utilise réellement son site.
  • Un site web doit-il être autorisé à récupérer les favoris d’un utilisateur final qui ont été ajoutés à partir d’un autre site Web ? Si c’est le cas, aimerions-nous laisser un site Web utiliser notre service, ou devrions-nous restreindre l’accès au service aux sites sous licence ? Permettre à n’importe quel site d’accéder à toutes les données stockées dans le service Favoris sans aucune sorte d’entrée de l’utilisateur final semble être un énorme problème de confidentialité.
  • De même, que se passe-t-il si notre service web a fourni des méthodes de mise à jour pour gérer les informations favorites de l’utilisateur. Un site web doit-il être autorisé à modifier les favoris d’un utilisateur final ajoutés à partir d’un autre site Web ?
  • Les utilisateurs finaux ne crieraient-ils pas et crier s’ils découvraient que nous faisions des choses comme l’analyse des affinités sur leurs données collectées à partir de plusieurs sites Web ? Comment sauraient-ils même que ces sites utilisaient notre service ? Devrions-nous faire quelque chose comme exiger qu’un utilisateur final s’inscrive auprès de notre service et définisse ses préférences de confidentialité avant qu’un site puisse accéder à ses données ? Comment l’utilisateur final sait-il s’inscrire auprès de nous ?

Peut-être que des recherches supplémentaires étaient en ordre.

The Vision, Rev 2

Après avoir passé en revue tout ce que je pouvais trouver sur la confidentialité des utilisateurs, j’ai passé quelques heures avec un membre du groupe de confidentialité d’entreprise de Microsoft à discuter des scénarios potentiellement activés par notre service et des implications en matière de confidentialité. J’ai pris page après page de notes, et il y avait encore quelques problèmes ouverts. Toutefois, les scénarios dans lesquels un site pourrait accéder ou modifier des données ajoutées à partir d’un autre site semblaient terriblement désordonnées du point de vue de la confidentialité. Cela ne veut pas dire qu’ils ne devraient pas être autorisés, simplement qu’il est plus difficile d’écrire une politique de confidentialité précise mais compréhensible pour couvrir ces scénarios, et les utilisateurs finaux peuvent ne pas être à l’aise avec les scénarios.

Nous avons également effectué des recherches préliminaires sur le problème d’authentification. Il n’existe vraiment pas de bon moyen aujourd’hui d’identifier et d’authentifier globalement les utilisateurs sur Internet lorsqu’il y a une application au milieu. Microsoft Passport fonctionne très bien lorsqu’un utilisateur interagit avec un site Web via un navigateur. Mais il n’existe aucun moyen sécurisé pour le site Web de transmettre les informations d’identification de l’utilisateur à un autre site Web. Qu’en est-il de la fonctionnalité de connexion unique de Passport, où les utilisateurs n’ont pas besoin d’entrer à nouveau leurs noms d’utilisateur et mots de passe lorsqu’ils se déplacent vers un autre site avec Passport ? Qui utilise des redirections côté client. Et notre service web ne parle jamais directement à l’ordinateur de l’utilisateur final.

Sur la base de cette recherche préliminaire, nous avons décidé d’implémenter les favoris par phases. Cela nous donnerait plus de temps pour régler les implications en matière de confidentialité, et peut-être que le service Web d’identité mentionné à plusieurs reprises lors du PDC de l’année dernière serait disponible au moment où nous avions besoin d’un schéma d’identité global.

Notre vision révisée ressemble à ceci :

  • Nous allons implémenter et déployer un service web favoris au cours de CY2001 qui permettra aux utilisateurs finaux de marquer des pages sélectionnées à partir de sites web pour un accès ultérieur. Ces favoris seront stockés par le service Favoris, afin qu’ils soient accessibles à partir de n’importe quel ordinateur ou appareil utilisé par l’utilisateur final.
  • Le service Favoris sera utilisé pour faire de la publicité auprès de clients potentiels et doit donc être un service hautement disponible, évolutif et sécurisé qui illustre l’engagement de l’entreprise envers la qualité et la confidentialité personnelle.

Les puristes peuvent soutenir que c’est beaucoup trop long pour être un énoncé de vision. L’important, cependant, c’est que tout le monde le comprenne, quel que soit votre nom.

Nous avons défini les phases suivantes :

  • Dans la première phase, nous allons implémenter et déployer un service web Favoris qui peut être concédé sous licence aux développeurs de sites web pour une utilisation en arrière-plan pour gérer les favoris de leurs clients. (En fait, chaque titulaire de licence dispose d’un magasin de données privé de favoris utilisateur.) Nous fournirons également un exemple qui montre comment intégrer le service Favoris à un site Web. Le service et l’exemple seront disponibles pour les licences d’ici le 1er mars 2001. Notre objectif est de donner une licence au service d’ici le 1er mars 2001 à cinq à 10 sites qui représentent environ 10 000 nouveaux utilisateurs finaux par mois. (Nous pensons qu’il s’agit d’un taux de croissance gérable, compte tenu de notre personnel actuel.)
  • Dans la deuxième phase, nous allons implémenter des extensions de navigateur pour Internet Explorer et Netscape Navigator, qui offriront aux utilisateurs finaux un moyen sûr et sécurisé de gérer leurs favoris sur n’importe quel site Web, de la même façon qu’ils gèrent les favoris côté client aujourd’hui. Nous allons également implémenter et déployer un site web que les utilisateurs finaux peuvent utiliser pour gérer leurs favoris, lire notre déclaration de confidentialité, définir des options de profil utilisateur concernant l’utilisation de leurs informations personnelles et télécharger les extensions de navigateur. Les extensions de navigateur et le site Web seront livrés d’après le 1er mai 2001. Notre objectif est d’atteindre 1 000 nouveaux utilisateurs finaux par mois.
  • Dans la phase 3, nous allons étendre le service Web Favoris afin que les utilisateurs finaux puissent voir les favoris qu’ils ont enregistrés directement (via le complément de navigateur ou le site Web Favoris) et les favoris qui ont été stockés via les titulaires de licence du service Favoris. Les titulaires de licence auront la possibilité d’afficher un logo spécial qui permet aux utilisateurs finaux de savoir que le service Favoris de consultation est utilisé (et par conséquent, ces favoris seront également accessibles via le complément de navigateur ou le site Web Favoris). Les titulaires de licence peuvent également continuer à utiliser le service Favoris en arrière-plan, auquel cas les favoris stockés via ce site ne seront pas disponibles via le complément de navigateur ou le site Web Favoris. La phase 3 sera livrée le 1er juin 2001.
    La troisième phase fournit une base pour les futurs services Web. Par exemple, si un utilisateur visite une page Web, le site peut afficher une liste de pages Web que d’autres personnes qui ont aimé la page ont également aimé. Le site Web récupère la liste des pages à partir d’un service web. Nous n’avons pas encore décidé d’implémenter ce type de service de profilage.

Une fois cela en place, nous pourrions étoffer le reste du document Vision.

L’étape suivante a été de définir certains profils utilisateur. Il est important de réfléchir soigneusement à qui sont tous vos utilisateurs lorsque vous définissez la vision d’un projet de service web. Les catégories d’utilisateurs que nous avons identifiées pendant la phase de planification sont les suivantes :

  • Utilisateurs finaux : toute personne qui utilise un navigateur Web pour visiter des sites Web.
  • Titulaires de licence : toute entreprise disposant d’un site web qui utilise le service Favoris.
  • Développeurs titulaires de licence : développeurs qui créent le site Web d’un titulaire de licence.
  • Exploitants titulaires de licence : exploitants du site Web d’un titulaire de licence.
  • Opérateurs : les personnes responsables de l’exploitation du service Favoris.

Vous pouvez lire les profils utilisateur complets dans le document de vision Favoris qui accompagne cette colonne. Il s’avère que nous avons manqué quelques catégories : les gestionnaires et les gestionnaires de titulaires de licences. Celles-ci se sont recadrées lorsque nous avons commencé à réfléchir aux exigences de création de rapports. Nous devrions probablement également diviser les testeurs en tant que catégorie distincte. Cette liste doit fournir un bon point de départ pour la plupart des projets de service web.

Nous avons également passé un peu de temps à réfléchir aux objectifs de l’entreprise et aux objectifs de conception. L’une des main questions est la suivante : Pourquoi créez-vous le service web ? Essayez-vous de gagner de l’argent ? Vous essayez de simplifier les processus métier ? Ou quelque chose d’autre ? Quoi que vous décidiez, cela aura probablement un impact sur vos besoins. Par exemple, les principaux objectifs du service Favoris sont les suivants :

  • Mettez en valeur notre engagement envers des produits de qualité.
  • Évitez les mauvaises presses en raison d’un service peu fiable, de problèmes de sécurité ou de confidentialité personnelle.

Cette combinaison d’objectifs a ajouté un nombre important d’exigences à notre service, en particulier dans les domaines des licences et des exigences de capacité (scalabilité, disponibilité, etc.). Mais gagner de l’argent est un objectif non-objectif complet pour ce projet. S’il s’agissait d’un objectif, bon nombre de nos exigences en matière de licence auraient été un peu différentes.

Du point de vue de la conception, vous devez réfléchir à votre philosophie globale en matière de confidentialité des utilisateurs, de sécurité et d’autres exigences non fonctionnelles. Vous devez également déterminer si les clients du monde entier utiliseront votre service web et ce que cela implique en matière de globalisation et de localisation. Par exemple, quelques-uns de nos objectifs de conception sont les suivants :

  • Fournissez une solution mondiale. Le service et toutes les applications de prise en charge doivent être globalisés.
  • Fournissez un service fiable et sécurisé. Le service doit être hautement disponible, ne doit pas perdre de données et doit uniquement autoriser l’accès par les utilisateurs autorisés.

Vous trouverez le reste de nos objectifs métier et objectifs de conception dans le document Favorites Vision.

Conclusion

Il est toujours plus facile de savoir quand vous avez terminé un projet si l’équipe de projet et vos clients ont convenu des objectifs généraux, des objectifs et de l’étendue à l’avance. Même si vous pensez simplement ajouter un serveur frontal de service web à un site Web existant, il est utile de prendre le temps d’écrire un document de vision. Pourquoi ajoutez-vous le front-end ? À qui s’attendez-vous à l’utiliser ? Combien de charge supplémentaire cela va-t-il mettre sur votre site que vos ops les gens n’attendent pas ?

La rédaction du document de vision pour Favoris a été un exercice précieux pour nous. Sans elle, nous aurions manqué au moins la moitié des exigences qui se sont retrouvées dans notre spécification fonctionnelle. Par exemple, nous n’aurions probablement pas reconnu les problèmes de confidentialité et de sécurité avant bien plus tard dans le jeu. Le document Vision fait d’autres choses pour nous aussi. Il nous donne un critère pour évaluer les demandes de fonctionnalités et hiérarchiser les exigences. Le document nous rappelle ce que nous voulons faire dans les prochaines phases: nous pouvons en tenir compte dans l’exemple de conception afin de ne pas avoir à réécrire complètement les choses en cours de route.

La semaine prochaine, nous examinerons plus en détail les questions de confidentialité mentionnées ici. Je vais vous faire part de ce que j’ai appris de notre groupe de protection de la vie privée d’entreprise, parler des problèmes difficiles que nous avons différés et discuter des questions de confidentialité qui subsistent dans la première phase et de la façon dont ils ont un impact sur notre conception et notre mise en œuvre.

Rendez-vous alors !

Mary Kirtland est l’architecte de l’équipe MSDN Web Services Guidance, où elle fait tout sauf du codage, des tests ou des opérations, y compris essayer de maintenir les spécifications à jour, écrire tout ce que l’équipe a appris dans des articles pour MSDN, poser des questions ennuyeuses pendant les révisions et commander le déjeuner.