Definición de la visión

Mary Kirtland
Microsoft Corporation

10 de enero de 2001

En la columna de la semana pasada, introdujo el equipo de instrucciones de servicios web y nuestra misión: compilar, implementar y operar servicios web de ejemplo para ilustrar los tipos de problemas que debe tener en cuenta al hacer lo mismo. También introdujo nuestro primer proyecto de ejemplo, el servicio Favoritos.

Gracias a todos por sus comentarios y comentarios. Estamos realizando un seguimiento de los problemas que usted plantea, así que mantenlos en camino!

Alguien preguntó por qué tardaría tres meses en publicar la muestra y por qué no habíamos empezado antes de anunciar la idea. De hecho, hemos estado trabajando en Favoritos bastante tiempo completo durante los últimos dos meses. Una gran cantidad de la funcionalidad es, bien, funcionando... pero todavía hay un poco de trabajo que hacer antes de que todo se empaqueta agradable y ordenado en una muestra que puede instalar en sus propias máquinas o probar a través de Internet. También se tarda algún tiempo en escribir, revisar, editar y procesar todos los artículos que queremos enviar con nuestros orígenes de ejemplo. Por eso estamos apuntando a ciclos de proyecto de tres meses. Estamos manteniendo los dedos cruzados que podremos obtener la primera versión de Favoritos en algún momento en febrero. (Al escribir esto, el equipo pasa por un ejercicio de programación para obtener una mejor estimación de la fecha de lanzamiento).

Algunos de los comentarios también asumen que estamos usando .NET Framework para desarrollar este ejemplo. Eso no es necesariamente el caso. Usaremos las tecnologías que creemos que son mejores para el trabajo. Y lo mejor no siempre significa técnicamente superior, más fácil de usar o la mayoría de las noticias. Lo que elijamos, le diremos por qué y le diremos qué problemas se han ejecutado al intentar usarlo.

Esta semana, empezaremos a examinar los problemas que ha encontrado nuestro equipo al crear el servicio Favoritos. Hay bastante trabajo pendiente, pero empezaremos al principio: averiguar los objetivos y objetivos del proyecto.

Introducción

En el modelo de proceso de Microsoft Solution Framework , la primera fase de cualquier proyecto es la fase de aprovisionamiento. Durante la fase de aprovisionamiento, el equipo del proyecto y los clientes crean una vista general de los objetivos y restricciones del proyecto. La entrega principal de esta fase es un documento de visión, que contiene un análisis del problema empresarial, una descripción de los objetivos del producto, un esquema del concepto de solución, perfiles de los usuarios del producto, objetivos de diseño y una definición del ámbito del proyecto. La fase de aprovisionamiento culmina en el hito aprobado de visión y ámbito .

Nuestro equipo comenzó desde un punto de partida inusual: sabíamos que queríamos escribir un servicio web, pero no teníamos ningún dominio de problema en particular, ni teníamos aplicaciones existentes que teníamos que usar. Por lo tanto, lo primero que necesitábamos hacer era un escenario empresarial razonablemente realista que podría justificar la creación de un escalable, confiable, etc., etc. Servicio web.

Empezamos por bloquear un montón de personas en una sala y lluvia de ideas de posibles empresas o sectores, servicios y problemas técnicos que harían buenos temas para obtener instrucciones. A lo largo del proceso, hemos llegado a algunos motivos por los que es posible que quiera compilar servicios web:

• Es un origen de datos con parámetros o sensibles a la hora que los usuarios finales u otras empresas quieren usar. Si los datos no cambian a menudo y los clientes casi siempre quieren todos los datos, es posible que también publique un documento XML en el sitio web. Pero si los clientes quieren ejecutar consultas en los datos, un servicio web tiene mucho sentido. Si desea insertar datos en los clientes, las operaciones de suscripción y notificación también son posibles servicios web.
• Implementa algoritmos que otras empresas no pueden o no quieren implementar por sí mismos. En este caso, cada algoritmo es un posible servicio web: los clientes pasan los datos, responde con la respuesta.
• Se agregan otros servicios para proporcionar un servicio de nivel superior. En este caso, los clientes usan el servicio porque proporciona la combinación de información que desean, lo que les guarda el trabajo de combinar los propios servicios existentes.
• Quiere integrar los procesos empresariales con asociados. Cada paso del proceso de negocio que atraviesa un límite empresarial es una posible operación de servicio web o servicio web.
• Tiene una arquitectura empresarial heterogénea o distribuida geográficamente, en la que el uso de redes privadas o protocolos estrechamente acoplados para la integración de aplicaciones no es práctico. La API de cada aplicación que desea integrar es un posible servicio web.
• Puede proporcionar servicios de infraestructura ("fontanería") para otros desarrolladores de aplicaciones web y servicios web, por ejemplo, un servicio de identidad o un servicio de facturación. En lugar de crear bibliotecas de API personalizadas para cada plataforma cliente, puede exponer la API como un servicio web.

Por supuesto, por cualquiera de estas razones, también debe tener en cuenta si hay un número suficiente de clientes potenciales para su servicio para justificar los costos de implementación y funcionamiento de él.

También nos dimos cuenta rápidamente de que había otras consideraciones al crear servicios de ejemplo para educar a un público general para desarrolladores. En primer lugar, los escenarios empresariales no deben requerir un amplio conocimiento de un sector determinado. En segundo lugar, queremos que pueda instalar y ejecutar los ejemplos en sus propias máquinas. En tercer lugar, muchos escenarios interesantes requieren uno o varios almacenes de datos o fuentes. Hay muchos problemas cuando se trata de enviar código fuente de ejemplo que muestra cómo acceder a orígenes de datos que no poseemos. Y no poseemos orígenes de datos... al menos no estamos a la libertad de dar una muestra.

Esto nos llevó fuera de escenarios como la banca en línea, controlar la grabadora de vídeo digital en casa, comprobar el estado del vuelo o el servidor de cómics diarios a algo más a lo largo de las líneas de un servicio de infraestructura. Empezamos a pensar en los tipos de servicios web que MSDN podría proporcionar (servicios reales, no ejemplos). Una idea de que realmente le gustaba a las personas era una manera de realizar un seguimiento de los artículos de MSDN que quería encontrar de nuevo, independientemente de la máquina que usaran para acceder a MSDN. Eso nos llevó a la idea de favoritos del lado servidor.

La visión, Rev 1

Una vez que tuvimos una idea aproximada del servicio que queríamos construir, creamos un escenario empresarial en torno a él:

• Estamos buscando formas de expandir nuestra base de clientes para nuestra práctica de desarrollo web y generar un flujo de ingresos normales. Creemos que podemos lograr ambos objetivos proporcionando servicios web de alta calidad que los sitios web querrán usar. Dado que los servicios web son un nuevo concepto, creemos que los clientes potenciales deberán estar convencidos de que pueden apostar parte de su negocio en nuestros servicios. Por lo tanto, necesitamos un servicio web teaser que:
  • Ofrece un valor obvio a los sitios web de los clientes potenciales.
  • No proporciona un servicio crítico.
  • Muestra la calidad de nuestras prácticas de desarrollo y operaciones.
  • Se puede implementar e implementar a un costo razonable para nosotros.

Este es el primer corte de nuestra visión para el proyecto:

• 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. En la fase dos de este proyecto, se concederán licencias de servicios adicionales a sitios web. Por ejemplo:
  • Estadísticas en las que se marcan las páginas de sus sitios.
  • Vínculos recomendados basados en un análisis de afinidad de todos los favoritos del usuario.

Desde una perspectiva técnica, este escenario parecía que abordaría muchas de las preguntas que habíamos escuchado de los clientes. La lógica de negocios no parecía demasiado difícil de implementar, o demasiado difícil de explicar a nuestros lectores. Pero una vez que la declaración de visión se escribió para que todo el mundo mirara, se levantaron algunas grandes banderas rojas:

• Necesitaríamos un esquema de identificación de usuario global, un esquema lo suficientemente común como para que los sitios web pudieran pasar el identificador de usuario a nuestro servicio.
• ¿Cómo autenticaríamos al usuario final cuando las solicitudes proceden de un sitio web en lugar de directamente del usuario final? Parece que necesitaríamos delegación o tendríamos que confiar en los sitios web para que solo realicen solicitudes en nombre de un usuario cuando el usuario final use realmente su sitio.
• ¿Se debe permitir que algún sitio web recupere los favoritos de un usuario final que se agregaron desde otro sitio web? Si es así, ¿deseamos permitir que cualquier sitio web use nuestro servicio, o deberíamos restringir el acceso al servicio a sitios con licencia? Permitir que cualquier sitio tenga acceso a cualquiera y todos los datos almacenados en el servicio Favoritos sin ningún tipo de entrada del usuario final suena como un problema de privacidad enorme.
• Del mismo modo, ¿qué ocurre si nuestro servicio web proporcionó métodos de actualización para mantener la información favorita del usuario? ¿Se debe permitir que un sitio web modifique los favoritos de un usuario final agregado desde otro sitio web?
• ¿Los usuarios finales no gritarían y gritaban si descubriéramos que hacíamos cosas como el análisis de afinidad en sus datos recopilados de varios sitios web? ¿Cómo sabrían incluso que estos sitios estaban usando nuestro servicio? ¿Tendríamos que hacer algo parecido a requerir que un usuario final se registre con nuestro servicio y establezca sus preferencias de privacidad antes de que cualquier sitio pueda acceder a sus datos? ¿Cómo sabría el usuario final registrarse con nosotros?

Quizás alguna investigación adicional estaba en orden.

La visión, Rev 2

Después de revisar todo lo que podía encontrar sobre la privacidad del usuario, pasé un par de horas con un miembro del Grupo de privacidad corporativa de Microsoft que analizaba los escenarios potencialmente habilitados por nuestro servicio y las implicaciones de privacidad. Tomé una página después de la página de notas, y todavía había algunos problemas abiertos. Sin embargo, los escenarios en los que un sitio podía acceder o modificar los datos agregados desde otro sitio sonaba terriblemente dado desde una perspectiva de privacidad. No se debe decir que no deben permitirse, solo que es más difícil escribir una directiva de privacidad precisa pero comprensible para cubrir estos escenarios, y es posible que los usuarios finales no se sientan cómodos con los escenarios.

También hicimos algunas investigaciones preliminares sobre el problema de autenticación. Realmente no hay una buena manera de identificar y autenticar globalmente a los usuarios a través de Internet cuando hay una aplicación en el medio. Microsoft Passport funciona bien cuando un usuario interactúa con un sitio web a través de un explorador. Pero no hay ninguna manera segura de que el sitio web pase las credenciales del usuario a otro sitio web. ¿Qué ocurre con la característica de inicio de sesión único de Passport, donde los usuarios no necesitan volver a escribir sus nombres de usuario y contraseñas cuando se trasladan a otro sitio habilitado para Passport? Que usa redireccionamientos del lado cliente. Y nuestro servicio web nunca se comunica directamente con la máquina del usuario final.

En función de esta investigación preliminar, decidimos implementar Favoritos en fases. Esto nos daría más tiempo para ordenar las implicaciones de privacidad, y quizás el servicio web de identidad que se mencionó varias veces en el PDC del año pasado estaría disponible en el momento en que necesitábamos un esquema de identidad global.

Nuestra visión revisada tiene este aspecto:

• Implementaremos e implementaremos un servicio web favoritos durante CY2001 que permitirá a los usuarios finales marcar páginas seleccionadas de sitios web para el acceso posterior. Estos favoritos serán almacenados por el Servicio favoritos, por lo que son accesibles desde cualquier máquina o dispositivo que use el usuario final.
• El Servicio Favoritos se usará para anunciar a clientes potenciales y, por lo tanto, debe ser un servicio seguro, escalable y de alta disponibilidad que muestre el compromiso de la empresa con la calidad y la privacidad personal.

Los puristas pueden discutir que esto es demasiado largo para ser una declaración de visión. Sin embargo, lo importante es que todo el mundo lo entienda, lo que quieras llamarlo.

Hemos definido las fases como esta:

• En la fase uno, implementaremos e implementaremos un servicio web favoritos que se puede conceder a los desarrolladores de sitios web para usarlos en segundo plano para administrar los favoritos de sus clientes. (De hecho, cada licencia tiene un almacén de datos privado de favoritos de usuario). También proporcionaremos un ejemplo que muestra cómo integrar el servicio Favoritos en un sitio web. El servicio y el ejemplo estarán disponibles para las licencias antes del 1 de marzo de 2001. Nuestro objetivo es conceder licencias al servicio el 1 de marzo de 2001 a cinco a 10 sitios que representan aproximadamente 10.000 nuevos usuarios finales al mes. (Creemos que se trata de una tasa de crecimiento manejable, dada nuestra plantilla actual).
• En la fase dos, implementaremos extensiones de explorador para Internet Explorer y Netscape Navigator que proporcionarán a los usuarios finales una manera segura y segura de administrar sus favoritos en cualquier sitio web, de la misma manera que administran los favoritos del lado cliente hoy en día. También implementaremos e implementaremos un sitio web que los usuarios finales pueden usar para administrar sus favoritos, leer nuestra declaración de privacidad, establecer opciones de perfil de usuario con respecto al uso de su información personal y descargar extensiones del explorador. Las extensiones del explorador y el sitio web se entregarán el 1 de mayo de 2001. Nuestro objetivo es alcanzar 1000 nuevos usuarios finales al mes.
• En la fase tres, ampliaremos el servicio web favoritos para que los usuarios finales puedan ver ambos favoritos que han guardado directamente (a través del complemento del explorador o el sitio web favoritos) y favoritos que se han almacenado a través de licencias del servicio Favoritos. Las licencias tendrán la opción de mostrar un logotipo especial que permita a los usuarios finales saber que se está usando el Servicio de favoritos de consultoría (y, por tanto, estos favoritos también serán accesibles a través del complemento del explorador o el sitio web favoritos). Las licencias también pueden seguir usando el Servicio favoritos en segundo plano, en cuyo caso los favoritos almacenados a través de ese sitio no estarán disponibles a través del complemento del explorador o el sitio web favoritos. La fase tres se entregará el 1 de junio de 2001.
  La fase tres ofrece una base para futuros servicios web. Por ejemplo, si un usuario visita una página web, el sitio podría mostrar una lista de páginas web a las que también le gustaban otras personas que les gustaba la página. El sitio web recuperaría la lista de páginas de un servicio web. Todavía no hemos decidido si implementar este tipo de servicio de generación de perfiles.

Con eso en su lugar, podríamos dar forma al resto del documento vision.

El siguiente paso era definir algunos perfiles de usuario. Es importante pensar cuidadosamente sobre quiénes son todos los usuarios al definir la visión de un proyecto de servicio web. Las categorías de usuario que hemos identificado durante la fase de aprovisionamiento son:

• Usuarios finales: cualquier persona que use un explorador web para visitar sitios web.
• Licencias: cualquier negocio con un sitio web que use el servicio Favoritos.
• Desarrolladores de licencias: desarrolladores que crean el sitio web de un licenciatario.
• Operadores de licencia: operadores del sitio web de un licenciatario.
• Operadores: las personas responsables de operar el servicio Favoritos.

Puede leer los perfiles de usuario completos en el documento De visión favoritos que acompaña a esta columna. Resulta que perdimos un par de categorías: administradores y administradores de licencias. Estos se recortaron cuando empezamos a pensar en los requisitos de informes. Probablemente deberíamos haber dividido también evaluadores como una categoría independiente. Esta lista debe proporcionar un buen punto de partida para la mayoría de los proyectos de servicio web.

También pasamos un poco de tiempo pensando en los objetivos empresariales y los objetivos de diseño. Una de las preguntas principales es: ¿Por qué está creando el servicio web? ¿Estás tratando de ganar dinero? ¿Intenta simplificar los procesos empresariales? ¿O algo más? Sea cual sea su decisión, es probable que tenga un impacto en sus requisitos. Por ejemplo, los objetivos principales del servicio Favoritos son:

• Presentar nuestro compromiso con los productos de calidad.
• Evite la mala prensa debido a problemas de seguridad, problemas de seguridad o problemas de privacidad personal.

Esta combinación de objetivos agregó un número significativo de requisitos en nuestro servicio, especialmente en las áreas de licencias y los requisitos de capacidad (escalabilidad, disponibilidad, etc.). Pero ganar dinero es un objetivo completo para este proyecto. Si fuera un objetivo, muchos de nuestros requisitos de licencia habrían salido un poco diferente.

Desde una perspectiva de diseño, debe pensar en su filosofía general sobre la privacidad del usuario, la seguridad y otros requisitos no funcionales. También debe tener en cuenta si los clientes de todo el mundo usarán el servicio web y lo que esto implica sobre la globalización y la localización. Por ejemplo, un par de nuestros objetivos de diseño son:

• Entrega de una solución mundial. El servicio y todas las aplicaciones auxiliares deben globalizarse.
• Ofrezca un servicio confiable y seguro. El servicio debe ser de alta disponibilidad, no debe perder datos y solo debe permitir el acceso de los usuarios autorizados.

Puede encontrar el resto de nuestros objetivos empresariales y objetivos de diseño en el documento Favorites Vision.

Conclusión

Siempre es más fácil saber cuándo ha terminado con un proyecto si el equipo del proyecto y los clientes han acordado los objetivos generales, los objetivos y el ámbito por adelantado. Incluso si cree que simplemente va a agregar un front-end de servicio web a un sitio web existente, merece la pena tomar el tiempo para escribir un documento de visión. ¿Por qué va a agregar el front-end? ¿A quién esperas usarlo? ¿Cuánta carga adicional va a colocar en el sitio que los usuarios de las operaciones no esperan?

Escribir el documento de visión para Favoritos fue un ejercicio valioso para nosotros. Sin ella, habríamos perdido al menos la mitad de los requisitos que terminaron en nuestra especificación funcional. Por ejemplo, probablemente no habríamos reconocido los problemas de privacidad y seguridad hasta mucho más adelante en el juego. El documento Vision también hace otras cosas para nosotros. Nos proporciona un palo para evaluar las solicitudes de características y priorizar los requisitos. El documento nos recuerda lo que queremos hacer en futuras fases: podemos tener en cuenta eso en el diseño de ejemplo, por lo que no es necesario reescribir completamente las cosas por el camino.

La próxima semana, veremos los problemas de privacidad mencionados aquí con más detalle. Le diré lo que aprendí de nuestro grupo de privacidad corporativa, hablaré sobre los problemas difíciles que hemos diferido y discutiremos los problemas de privacidad que permanecen en la fase uno y cómo estos tienen un impacto en nuestro diseño e implementación.

¡Vete entonces!

Mary Kirtland es el arquitecto del equipo de instrucciones de servicios web de MSDN, donde hace todo, pero codifica, prueba o operaciones, incluyendo intentar mantener actualizadas las especificaciones, escribiendo todo lo que el equipo ha aprendido en artículos para MSDN, haciendo preguntas molestas durante las revisiones y ordenando el almuerzo.