Partilhar via

Definindo a Visão

  • Artigo

 

Mary Kirtland
Microsoft Corporation

10 de janeiro de 2001

Na coluna da semana passada, apresentei a equipe de Diretrizes de Serviços Web e nossa missão: criar, implantar e operar serviços Web de exemplo para ilustrar os tipos de problemas que você precisa considerar ao fazer o mesmo. Também apresentei nosso primeiro projeto de exemplo, o Serviço de Favoritos.

Obrigado a todos por seus comentários e comentários. Estamos acompanhando os problemas que você levanta, então mantenha-os chegando!

Alguém perguntou por que levaria três meses para liberarmos o exemplo e por que não tínhamos começado antes de anunciarmos a ideia. Na verdade, temos trabalhado em Favoritos praticamente em tempo integral nos últimos dois meses. Grande parte da funcionalidade está funcionando... mas ainda há um pouco de trabalho a fazer antes que tudo seja empacotado bem e limpo em um exemplo que você pode instalar em seus próprios computadores ou experimentar pela Internet. Também leva algum tempo para escrever, revisar, editar e processar todos os artigos que queremos enviar com nossas fontes de exemplo. Portanto, é por isso que estamos buscando ciclos de projeto de três meses. Estamos mantendo os dedos cruzados para que possamos obter o primeiro lançamento de Favoritos em algum momento de fevereiro. (Enquanto escrevo isso, a equipe está passando por um exercício de agendamento para obter uma estimativa melhor da data de lançamento.)

Alguns dos comentários também pressupõem que estamos usando o .NET Framework para desenvolver este exemplo. Esse não é necessariamente o caso. Usaremos as tecnologias que acharmos melhores para o trabalho. E o melhor nem sempre significa tecnicamente superior, mais fácil de usar, ou a maioria nas notícias. O que escolhermos, diremos por quê e diremos a você quais problemas tivemos quando tentamos usá-lo.

Esta semana, começaremos a examinar os problemas que nossa equipe encontrou ao criar o Serviço de Favoritos. Há uma grande lista de pendências, mas começaremos no início: descobrir as metas e os objetivos do projeto.

Introdução

No modelo de processo do Microsoft Solution Framework , a primeira fase em qualquer projeto é a fase de previsão. Durante a fase de previsão, a equipe de projeto e os clientes criam uma exibição de alto nível das metas e restrições do projeto. A principal entrega dessa fase é um documento de visão, que contém uma análise do problema de negócios, uma descrição das metas para o produto, uma estrutura de tópicos do conceito de solução, perfis dos usuários do produto, metas de design e uma definição do escopo do projeto. A fase de previsão culmina no marco aprovado pela visão/escopo .

Nossa equipe começou de um ponto de partida incomum: sabíamos que queríamos escrever um Serviço Web, mas não tínhamos nenhum domínio de problema específico em mente, nem tínhamos aplicativos existentes que tínhamos que usar. Então, a primeira coisa que precisávamos fazer era criar um cenário de negócios razoavelmente realista que pudesse justificar a construção de um escalonável, confiável, etc., etc., etc. Serviço Web.

Começamos trancando um monte de pessoas em uma sala e debatendo potenciais empresas ou indústrias, serviços e questões técnicas que fariam bons tópicos para orientação. Ao longo do caminho, descobrimos alguns motivos pelos quais talvez você queira criar serviços Web:

  • Você é uma fonte de dados com diferenciação de tempo ou parametrizados que os usuários finais ou outras empresas desejam usar. Se os dados não forem alterados com frequência e os clientes quase sempre desejarem todos os dados, você também pode apenas postar um documento XML em seu site. Mas se os clientes quiserem executar consultas em seus dados, um serviço Web fará muito sentido. Se você quiser enviar dados por push para clientes, as operações de assinatura e notificação também serão possíveis Serviços Web.
  • Você implementa algoritmos que outras empresas não podem ou não querem implementar. Nesse caso, cada algoritmo é um serviço Web potencial: os clientes passam os dados, você responde com a resposta.
  • Você agrega vários outros serviços para fornecer um serviço de nível superior. Nesse caso, os clientes usam seu serviço porque ele fornece a combinação de informações desejadas, salvando-os no trabalho de combinar os próprios serviços existentes.
  • Você deseja integrar seus processos de negócios a parceiros. Cada etapa do processo de negócios que passa por um limite empresarial é uma possível operação de Serviço Web ou Serviço Web.
  • Você tem uma arquitetura corporativa heterogênea e/ou distribuída geograficamente, na qual o uso de redes privadas ou protocolos firmemente acoplados para integração de aplicativos não é prático. A API de cada aplicativo que você deseja integrar é um serviço Web em potencial.
  • Você fornece serviços de infraestrutura ("encanamento") para outros desenvolvedores de aplicativo Web e serviço Web, por exemplo, um serviço de identidade ou um serviço de cobrança. Em vez de criar bibliotecas de API personalizadas para cada plataforma cliente, você pode expor sua API como um Serviço Web.

É claro que, por qualquer um desses motivos, você também precisa considerar se há um número suficiente de clientes potenciais para seu serviço para justificar os custos de implementação e operação dele.

Também percebemos rapidamente que havia algumas outras considerações ao criar serviços de exemplo para educar um público geral de desenvolvedores. Primeiro, os cenários de negócios não devem exigir amplo conhecimento de um determinado setor. Em segundo lugar, queremos que você possa instalar e executar os exemplos em seus próprios computadores. Em terceiro lugar, muitos cenários interessantes exigem um ou mais armazenamentos de dados ou feeds. Há muitos problemas quando se trata de enviar código-fonte de exemplo que mostra como acessar fontes de dados que não temos. E não temos nenhuma fonte de dados... pelo menos não que estejamos em liberdade para dar com uma amostra.

Isso nos afastou de cenários como banco online, gravador de vídeo digital da casa de controle, marcar status de voo ou servidor diário de quadrinhos para algo mais nos moldes de um serviço de infraestrutura. Começamos a pensar nos tipos de Serviços Web que o MSDN poderia fornecer (serviços reais, não exemplos). Uma ideia que as pessoas realmente gostavam era uma maneira de acompanhar os artigos do MSDN que queriam encontrar novamente, independentemente de qual computador eles usavam para acessar o MSDN. Isso nos levou à ideia de favoritos do lado do servidor.

A Visão, Rev 1

Depois que tivemos uma ideia aproximada do serviço que queríamos criar, criamos um cenário de negócios em torno dele:

  • Estamos procurando maneiras de expandir nossa base de clientes para nossa prática de desenvolvimento na Web e gerar um fluxo de receita regular. Acreditamos que podemos alcançar ambos os objetivos fornecendo serviços Web de alta qualidade que os sites desejarão usar. Como os Serviços Web são um novo conceito, achamos que os clientes potenciais precisarão estar convencidos de que podem apostar parte de seus negócios em nossos serviços. Portanto, precisamos de um serviço Web teaser que:
    • Oferece um valor óbvio para sites de clientes potenciais.
    • Não fornece um serviço crítico.
    • Mostra a qualidade de nossas práticas de desenvolvimento e operações.
    • Pode ser implementado e implantado a um custo razoável para nós.

Aqui está o primeiro corte em nossa visão para o projeto:

  • 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. Na fase dois deste projeto, licenciaremos serviços adicionais para sites da Web. Por exemplo:
    • Estatísticas sobre quais páginas de seus sites estão sendo marcadas.
    • Links recomendados com base em uma análise de afinidade de todos os favoritos do usuário.

Do ponto de vista técnico, esse cenário parecia que abordaria muitas das perguntas que estávamos ouvindo dos clientes. A lógica de negócios não parecia muito difícil de implementar — ou muito difícil de explicar aos nossos leitores. Mas uma vez que a declaração de visão foi escrita para todos olharem, algumas grandes bandeiras vermelhas subiram:

  • Precisaríamos de um esquema de identificação de usuário global, um esquema comum o suficiente para que os sites pudessem passar o identificador de usuário para nosso serviço.
  • Como autenticar o usuário final quando as solicitações vêm de um site e não diretamente do usuário final? Parece que precisamos de delegação, ou precisamos confiar nos sites da Web para fazer solicitações apenas em nome de um usuário quando o usuário final estiver realmente usando seu site.
  • Algum site da Web deve ter permissão para recuperar os favoritos de um usuário final que foram adicionados de outro site? Nesse caso, gostaríamos de permitir que qualquer site use nosso serviço ou devemos restringir o acesso ao serviço a sites licenciados? Permitir que qualquer site tenha acesso a qualquer e a todos os dados armazenados no Serviço de Favoritos sem qualquer tipo de entrada do usuário final soa como um enorme problema de privacidade.
  • Da mesma forma, e se nosso Serviço Web forneceu métodos de atualização para manter as informações favoritas do usuário. Um site deve ter permissão para modificar os favoritos de um usuário final adicionados de outro site?
  • Os usuários finais não gritariam e gritariam se descobrissem que estávamos fazendo coisas como análise de afinidade em seus dados coletados de vários sites? Como eles saberiam que esses sites estavam usando nosso serviço? Precisamos fazer algo como exigir que um usuário final se registre em nosso serviço e defina suas preferências de privacidade antes que qualquer site possa acessar seus dados? Como o usuário final saberia se registrar conosco?

Talvez algumas pesquisas adicionais estivessem em ordem.

A Visão, Rev 2

Depois de examinar tudo o que pude encontrar sobre a privacidade do usuário, passei algumas horas com um membro do Grupo de Privacidade Corporativa da Microsoft discutindo os cenários potencialmente habilitados pelo nosso serviço e as implicações de privacidade. Peguei página após página de anotações, e ainda havia alguns problemas em aberto. Mas os cenários em que um site podia acessar ou modificar dados adicionados de outro site soava muito arriscados de uma perspectiva de privacidade. Isso não quer dizer que eles não devem ser permitidos, apenas que é mais difícil escrever uma política de privacidade precisa, mas compreensível para cobrir esses cenários, e os usuários finais podem não estar confortáveis com os cenários.

Também fizemos algumas pesquisas preliminares sobre a questão da autenticação. Não há realmente uma boa maneira de identificar e autenticar globalmente os usuários pela Internet quando há um aplicativo no meio. O Microsoft Passport funciona muito bem quando um usuário está interagindo com um site por meio de um navegador. Mas não há uma maneira segura de o site passar as credenciais do usuário para outro site. E o recurso de logon único do Passport, em que os usuários não precisam inserir novamente seus nomes de usuário e senhas quando migram para outro site habilitado para Passport? Isso usa redirecionamentos do lado do cliente. E nosso Serviço Web nunca fala diretamente com o computador do usuário final.

Com base nesta pesquisa preliminar, decidimos implementar favoritos em fases. Isso nos daria mais tempo para resolver as implicações de privacidade, e talvez o Serviço Web de Identidade mencionado várias vezes no PDC do ano passado estaria disponível no momento em que precisávamos de um esquema de identidade global.

Nossa visão revisada tem esta aparência:

  • Implementaremos e implantaremos um Serviço Web favoritos durante o CY2001 que permitirá que os usuários finais marquem páginas selecionadas de sites para acesso posterior. Esses favoritos serão armazenados pelo Serviço de Favoritos, para que possam ser acessados em qualquer computador ou dispositivo que o usuário final esteja usando.
  • O Serviço favoritos será usado para anunciar a clientes potenciais e, portanto, deve ser um serviço altamente disponível, escalonável e seguro que mostre o compromisso da empresa com a qualidade e a privacidade pessoal.

Os puristas podem argumentar que isso é muito longo para ser uma declaração de visão. O importante, no entanto, é que todos entendam, como você quiser chamá-lo.

Definimos as fases como esta:

  • Na fase um, implementaremos e implantaremos um Serviço Web de Favoritos que pode ser licenciado para desenvolvedores de sites para uso nos bastidores para gerenciar os favoritos de seus clientes. (Efetivamente, cada licenciado tem um armazenamento de dados privado de favoritos do usuário.) Também forneceremos um exemplo que mostra como integrar o Serviço de Favoritos a um site. O serviço e o exemplo estarão disponíveis para licenciamento até 1º de março de 2001. Nossa meta é licenciar o serviço até 1º de março de 2001 para cinco a dez sites que representam aproximadamente 10.000 novos usuários finais por mês. (Acreditamos que esta é uma taxa gerenciável de crescimento, dada a nossa equipe atual.)
  • Na fase dois, implementaremos extensões de navegador para Internet Explorer e Netscape Navigator que fornecerão aos usuários finais uma maneira segura e segura de gerenciar seus favoritos para qualquer site, da mesma forma que gerenciam os favoritos do lado do cliente hoje. Também implementaremos e implantaremos um site que os usuários finais podem usar para gerenciar seus favoritos, ler nossa política de privacidade, definir opções de perfil do usuário sobre o uso de suas informações pessoais e baixar extensões do navegador. As extensões do navegador e o site serão entregues até 1º de maio de 2001. Nossa meta é alcançar 1.000 novos usuários finais por mês.
  • Na fase três, estenderemos o Serviço Web favoritos para que os usuários finais possam ver os favoritos que salvaram diretamente (por meio do suplemento do navegador ou do site Favoritos) e os favoritos que foram armazenados por meio de licenças do Serviço de Favoritos. Os licenciados terão a opção de exibir um logotipo especial que permite que os usuários finais saibam que o Serviço de Favoritos de Consultoria está sendo usado (e, portanto, esses favoritos também estarão acessíveis por meio do suplemento do navegador ou do site Favoritos). Os licenciados também podem continuar a usar o Serviço de Favoritos nos bastidores, caso em que os favoritos armazenados por meio desse site não estarão disponíveis por meio do suplemento do navegador ou do site favoritos. A fase três será entregue até 1º de junho de 2001.
    A fase três fornece uma base para futuros Serviços Web. Por exemplo, se um usuário visitar uma página da Web, o site poderá exibir uma lista de páginas da Web que outras pessoas que gostaram da página também gostaram. O site recuperaria a lista de páginas de um serviço Web. Ainda não decidimos se devemos implementar esse tipo de serviço de criação de perfil.

Com isso em vigor, poderíamos elaborar o resto do documento de Visão.

A próxima etapa foi definir alguns perfis de usuário. É importante pensar cuidadosamente sobre quem são todos os usuários quando você define a visão para um projeto de Serviço Web. As categorias de usuário que identificamos durante a fase de previsão são:

  • Usuários Finais — qualquer pessoa que usa um navegador da Web para visitar sites.
  • Licenciados – qualquer empresa com um site que usa o Serviço de Favoritos.
  • Desenvolvedores licenciados – desenvolvedores que criam o site de um licenciado.
  • Operadores licenciados – operadores do site de um licenciado.
  • Operadores – as pessoas responsáveis por operar o serviço Favoritos.

Você pode ler os perfis de usuário completos no documento de visão Favoritos que acompanha esta coluna. Acontece que perdemos algumas categorias: gerentes e gerentes de licenciados. Elas surgiram quando começamos a pensar em requisitos de relatório. Provavelmente deveríamos ter dividido testadores como uma categoria separada também. Essa lista deve fornecer um bom ponto de partida para a maioria dos projetos de Serviço Web.

Também passamos um pouco de tempo pensando em metas de negócios e metas de design. Uma das perguntas main é: Por que você está criando o Serviço Web? Você está tentando ganhar dinheiro? Tentando simplificar os processos de negócios? Ou outra coisa completamente diferente? Seja lá o que você decidir, é provável que tenha um impacto em seus requisitos. Por exemplo, as principais metas para o Serviço de Favoritos são:

  • Mostre nosso compromisso com produtos de qualidade.
  • Evite a má imprensa devido a problemas de serviço, segurança ou privacidade pessoal não confiáveis.

Essa combinação de metas adicionou um número significativo de requisitos em nosso serviço, especialmente nas áreas de licenciamento e nos requisitos de capacidade (escalabilidade, disponibilidade etc.). Mas ganhar dinheiro não é uma meta completa para este projeto. Se fosse uma meta, muitos de nossos requisitos de licenciamento teriam saído um pouco diferente.

Do ponto de vista do design, você deve pensar em sua filosofia geral sobre privacidade, segurança e outros requisitos não funcionais do usuário. Você também deve considerar se os clientes em todo o mundo usarão seu Serviço Web e o que isso implica sobre globalização e localização. Por exemplo, algumas de nossas metas de design são:

  • Entregar uma solução mundial. O serviço e todos os aplicativos de suporte devem ser globalizados.
  • Fornecer um serviço confiável e seguro. O serviço deve estar altamente disponível, não deve perder dados e só deve permitir o acesso de usuários autorizados.

Você pode encontrar o restante de nossas metas de negócios e metas de design no documento visão de favoritos.

Conclusão

É sempre mais fácil saber quando você termina um projeto se a equipe do projeto e seus clientes concordaram com as metas gerais, os objetivos e o escopo antecipadamente. Mesmo que você pense que está apenas adicionando um front-end do Serviço Web a um site existente, vale a pena ter tempo para escrever um documento de visão. Por que você está adicionando o front-end? Quem você espera usar? Quanto carregamento adicional isso vai colocar em seu site que as pessoas de operações não estão esperando?

Escrever o documento de visão para Favoritos foi um exercício valioso para nós. Sem ele, teríamos perdido pelo menos metade dos requisitos que acabaram em nossa especificação funcional. Por exemplo, provavelmente não teríamos reconhecido os problemas de privacidade e segurança até muito mais tarde no jogo. O documento visão também faz outras coisas para nós. Ele nos dá um parâmetro para avaliar solicitações de recursos e priorizar requisitos. O documento nos lembra o que queremos fazer em fases futuras— podemos considerar isso no design de exemplo para que não precisemos reescrever completamente as coisas no caminho.

Na próxima semana, examinaremos as questões de privacidade mencionadas aqui com mais detalhes. Vou informá-lo sobre o que aprendi com nosso Grupo de Privacidade Corporativa, falar sobre os problemas difíceis que adiamos e discutir as questões de privacidade que permanecem na fase um e como elas têm impacto em nosso design e implementação.

Até lá!

Mary Kirtland é a arquiteta da equipe de Diretrizes de Serviços Web do MSDN, onde ela faz tudo, menos codificação, teste ou operações, incluindo tentar manter as especificações atualizadas, anotar tudo o que a equipe aprendeu em artigos para MSDN, fazer perguntas irritantes durante as revisões e pedir almoço.