Definizione della visione

 

Mary Kirtland
Microsoft Corporation

10 gennaio 2001

Nella colonna della scorsa settimana ho introdotto il team di linee guida dei servizi Web e la nostra missione: creazione, distribuzione e funzionamento di servizi Web di esempio per illustrare i tipi di problemi da considerare quando si esegue la stessa operazione. Ho anche introdotto il nostro primo progetto di esempio, il Servizio Preferiti.

Grazie a tutti per i commenti e i suggerimenti. Stiamo tenendo traccia dei problemi che hai sollevato, quindi continua a venire!

Qualcuno ha chiesto perché ci vorrebbero tre mesi per rilasciare l'esempio e perché non eravamo stati avviati prima di annunciare l'idea. Infatti, stiamo lavorando sui Preferiti praticamente a tempo pieno negli ultimi due mesi. Molte delle funzionalità sono, beh, funzionanti... ma c'è ancora un po 'di lavoro da fare prima che tutto sia in pacchetto bello e pulito in un esempio che è possibile installare nei propri computer o provare su Internet. La scrittura, la revisione tecnica, la modifica e l'elaborazione di tutti gli articoli da fornire con le origini di esempio richiedono tempo. Ecco perché stiamo puntando a cicli di progetto di tre mesi. Stiamo tenendo le dita incrociate che saremo in grado di ottenere la prima versione di Preferiti fuori qualche tempo a febbraio. Durante la scrittura, il team sta attraversando un esercizio di pianificazione per ottenere una stima migliore della data di rilascio.

Alcuni dei commenti presuppongono anche l'uso di .NET Framework per sviluppare questo esempio. Questo non è necessariamente il caso. Useremo tutte le tecnologie che pensiamo siano migliori per il lavoro. E il meglio non sempre significa tecnicamente superiore, più facile da usare, o la maggior parte delle notizie. Qualunque cosa scegliamo, ti diremo perché e ti diremo quali problemi abbiamo provato a quando abbiamo provato a usarlo.

Questa settimana inizieremo a esaminare i problemi riscontrati dal team durante la creazione del servizio Preferiti. C'è un backlog, ma inizieremo all'inizio: capire gli obiettivi e gli obiettivi per il progetto.

Introduzione

Nel modello di processo di Microsoft Solution Framework , la prima fase in qualsiasi progetto è la fase di progettazione. Durante la fase di progettazione, il team di progetto e i clienti creano una panoramica generale degli obiettivi e dei vincoli del progetto. Il risultato finale principale di questa fase è un documento di visione, che contiene un'analisi del problema aziendale, una descrizione degli obiettivi per il prodotto, una descrizione del concetto di soluzione, profili degli utenti del prodotto, obiettivi di progettazione e una definizione dell'ambito del progetto. La fase di concezione culmina nell'attività cardine approvata dalla visione/ambito .

Il nostro team ha iniziato da un punto di partenza insolito: sapevamo che volevamo scrivere un servizio Web, ma non avevamo alcun particolare dominio di problema, né avevamo applicazioni esistenti che dovevamo usare. Quindi la prima cosa da fare era un scenario aziendale ragionevolmente realistico che potrebbe giustificare la creazione di una scalabilità, affidabile, ecc., ecc., ecc. Servizio Web.

Abbiamo iniziato bloccando un gruppo di persone in una stanza e brainstorming potenziali aziende o settori, servizi e problemi tecnici che renderebbero buoni argomenti per indicazioni. Nel corso della procedura sono stati illustrati alcuni motivi per cui è possibile creare servizi Web:

• Si è un'origine di dati sensibili al tempo o con parametri che gli utenti finali o altre aziende vogliono usare. Se i dati non cambiano spesso e i client richiedono quasi sempre tutti i dati, è anche possibile pubblicare un documento XML nel sito Web. Tuttavia, se i client vogliono eseguire query sui dati, un servizio Web ha molto senso. Se si desidera eseguire il push dei dati ai client, le operazioni di sottoscrizione e notifica sono anche potenziali servizi Web.
• Si implementano algoritmi che altre aziende non possono o non vogliono implementare se stessi. In questo caso, ogni algoritmo è un potenziale servizio Web: i client passano i dati, rispondono con la risposta.
• È possibile aggregare diversi altri servizi per fornire un servizio di livello superiore. In questo caso, i client usano il servizio perché fornisce la combinazione di informazioni desiderate, salvando il lavoro di combinare i servizi esistenti stessi.
• Si vuole integrare i processi aziendali con i partner. Ogni passaggio del processo aziendale che supera un limite aziendale è un'operazione potenziale del servizio Web o del servizio Web.
• Si dispone di un'architettura aziendale eterogenea e/o geograficamente distribuita, in cui l'uso di reti private o protocolli strettamente associati per l'integrazione delle applicazioni non è pratico. L'API di ogni applicazione che si vuole integrare è un potenziale servizio Web.
• Si forniscono servizi di infrastruttura ("plumbing") per altri sviluppatori di applicazioni Web e servizi Web, ad esempio un servizio di gestione delle identità o un servizio di fatturazione. Anziché creare librerie API personalizzate per ogni piattaforma client, è possibile esporre l'API come servizio Web.

Naturalmente, per uno di questi motivi, è necessario considerare anche se esistono un numero sufficiente di potenziali client per il servizio per giustificare i costi di implementazione e gestione.

Ci sono state anche alcune altre considerazioni per la creazione di servizi di esempio per la formazione di un pubblico di sviluppatori generale. In primo luogo, gli scenari aziendali non devono richiedere una conoscenza approfondita di un determinato settore. In secondo luogo, si vuole essere in grado di installare ed eseguire gli esempi nei propri computer. In terzo luogo, molti scenari interessanti richiedono uno o più archivi dati o feed. Esistono molti problemi quando si tratta di distribuire codice sorgente di esempio che illustra come accedere alle origini dati non di proprietà. E non siamo proprietari di origini dati... almeno non che siamo liberi di dare via con un campione.

Questo ci ha portato lontano da scenari come online banking, controllare home videoregistratore digitale, controllare lo stato dei voli, o server fumetti giornalieri a qualcosa di più lungo le linee di un servizio infrastruttura. Abbiamo iniziato a pensare ai tipi di servizi Web che MSDN potrebbe fornire (servizi reali, non esempi). Un'idea che gli utenti piacevano davvero era un modo per tenere traccia degli articoli MSDN che volevano trovare di nuovo, indipendentemente dal computer usato per accedere a MSDN. Questo ci ha portato all'idea dei preferiti sul lato server.

Visione, Rev 1

Dopo aver avuto un'idea approssimativa del servizio che si voleva creare, è stato creato uno scenario aziendale intorno a esso:

• Stiamo cercando modi per espandere la base clienti per la nostra pratica di sviluppo Web e per generare un flusso di ricavi regolare. Riteniamo che sia possibile raggiungere entrambi gli obiettivi fornendo servizi Web di alta qualità che i siti Web vorranno usare. Poiché i servizi Web sono un nuovo concetto, riteniamo che i potenziali clienti debbano essere convinti che possano scommettere parte della loro attività sui nostri servizi. È quindi necessario un servizio Web teaser che:
  • Offre un valore ovvio per i siti Web dei clienti potenziali.
  • Non fornisce un servizio cruciale.
  • Mostra la qualità delle procedure operative e di sviluppo.
  • Può essere implementata e distribuita a costi ragionevoli.

Ecco il primo taglio alla nostra visione per il progetto:

• 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. Nella seconda fase di questo progetto verranno concessi in licenza servizi aggiuntivi ai siti Web. Ad esempio:
  • Statistiche sulle pagine dei siti in cui vengono inseriti i segnalibri.
  • Collegamenti consigliati in base a un'analisi di affinità di tutti i preferiti degli utenti.

Dal punto di vista tecnico, questo scenario sembrava risolvere molte delle domande che avremmo sentito dai clienti. La logica di business non sembrava troppo difficile da implementare o troppo difficile da spiegare ai lettori. Ma una volta che la dichiarazione di visione è stata scritta per tutti a guardare, alcune grandi bandiere rosse sono salite:

• Sarebbe necessario uno schema di identificazione utente globale, uno schema abbastanza comune che i siti Web sarebbero in grado di passare l'identificatore utente al servizio.
• Come si autentica l'utente finale quando le richieste provengono da un sito Web anziché direttamente dall'utente finale? Sembra che sia necessaria la delega oppure è necessario considerare attendibili i siti Web per effettuare richieste solo per conto di un utente quando l'utente finale usa effettivamente il proprio sito.
• È consigliabile consentire a un sito Web di recuperare i preferiti di un utente finale aggiunti da un altro sito Web? In tal caso, è consigliabile consentire a un sito Web di usare il servizio o limitare l'accesso al servizio ai siti con licenza? Consentire a qualsiasi sito di avere accesso a tutti i dati archiviati nel servizio Preferiti senza alcun tipo di input dell'utente finale sembra un problema di privacy enorme.
• Analogamente, cosa accade se il servizio Web ha fornito metodi di aggiornamento per mantenere le informazioni preferite dell'utente. È consigliabile consentire a un sito Web di modificare i preferiti di un utente finale aggiunti da un altro sito Web?
• Gli utenti finali non urlano e urlano se hanno scoperto che stavamo facendo cose come l'analisi di affinità sui dati raccolti da più siti Web? Come possono anche sapere che questi siti usano il nostro servizio? È necessario eseguire operazioni come richiedere a un utente finale di registrarsi con il servizio e impostare le preferenze di privacy prima che qualsiasi sito possa accedere ai propri dati? In che modo l'utente finale sa registrarsi?

Forse alcune ricerche aggiuntive erano in ordine.

Visione, Rev 2

Dopo aver esaminato tutto ciò che ho potuto trovare sulla privacy degli utenti, ho trascorso un paio di ore con un membro del gruppo privacy aziendale di Microsoft che discute gli scenari potenzialmente abilitati dal nostro servizio e le implicazioni per la privacy. Ho preso pagina dopo la pagina delle note, e ci sono stati ancora alcuni problemi aperti. Tuttavia, gli scenari in cui un sito può accedere o modificare i dati aggiunti da un altro sito suonavano terribilmente dadi dal punto di vista della privacy. Questo non significa che non dovrebbero essere consentiti, solo che è più difficile scrivere un criterio di privacy accurato ma comprensibile per coprire questi scenari e gli utenti finali potrebbero non essere a proprio agio con gli scenari.

Sono state anche svolte alcune ricerche preliminari sul problema di autenticazione. Attualmente non esiste un buon modo per identificare e autenticare a livello globale gli utenti tramite Internet quando c'è un'app al centro. Microsoft Passport funziona perfettamente quando un utente interagisce con un sito Web tramite un browser. Tuttavia, non esiste un modo sicuro per consentire al sito Web di passare le credenziali dell'utente a un altro sito Web. Qual è la funzionalità di accesso singolo di Passport, in cui gli utenti non devono immettere nuovamente i nomi utente e le password quando passano a un altro sito abilitato per Passport? Che usa i reindirizzamenti lato client. E il servizio Web non comunica mai direttamente con il computer dell'utente finale.

Sulla base di questa ricerca preliminare, abbiamo deciso di implementare Preferiti in fasi. Questo ci darebbe più tempo per ordinare le implicazioni sulla privacy, e forse il servizio Web di identità menzionato più volte nel PDC dell'anno scorso sarebbe disponibile dal momento in cui era necessario uno schema di identità globale.

La nostra visione rivista ha un aspetto simile al seguente:

• Verrà implementato e distribuito un servizio Web Preferiti durante CY2001 che consentirà agli utenti finali di aggiungere segnalibri alle pagine selezionate dai siti Web per un accesso successivo. Questi preferiti verranno archiviati dal servizio Preferiti, in modo che siano accessibili da qualsiasi computer o dispositivo usato dall'utente finale.
• Il servizio Preferiti verrà usato per annunciare ai potenziali clienti e pertanto deve essere un servizio sicuro, scalabile e a disponibilità elevata che mette in mostra l'impegno dell'azienda a garantire la qualità e la privacy personale.

I puristi possono sostenere che questo è troppo lungo per essere una dichiarazione di visione. La cosa importante, tuttavia, è che tutti lo capiscono, qualunque cosa tu voglia chiamarla.

Sono stati definiti i passaggi seguenti:

• Nella prima fase, verrà implementato e distribuito un servizio Web Preferiti che può essere concesso in licenza agli sviluppatori di siti Web per l'uso in background per gestire i preferiti dei clienti. Ogni licenziatario ha in effetti un archivio dati privato dei preferiti degli utenti. Verrà inoltre fornito un esempio che illustra come integrare il servizio Preferiti in un sito Web. Il servizio e l'esempio saranno disponibili per le licenze entro il 1° marzo 2001. L'obiettivo è quello di concedere in licenza il servizio entro il 1° marzo 2001 da cinque a 10 siti che rappresentano circa 10.000 nuovi utenti finali al mese. (Riteniamo che questo sia un tasso gestibile di crescita, dato il nostro attuale personale).
• Nella fase due verranno implementate le estensioni del browser per Internet Explorer e Netscape Navigator che offriranno agli utenti finali un modo sicuro e sicuro per gestire i preferiti in qualsiasi sito Web, allo stesso modo in cui gestiscono i preferiti sul lato client oggi. Verranno inoltre implementati e distribuiti gli utenti finali di un sito Web per gestire i preferiti, leggere l'informativa sulla privacy, impostare le opzioni del profilo utente relative all'uso delle informazioni personali e scaricare le estensioni del browser. Le estensioni del browser e il sito Web verranno recapitati entro il 1° maggio 2001. L'obiettivo è raggiungere 1.000 nuovi utenti finali al mese.
• Nella fase 3 si estenderà il servizio Web Preferiti in modo che gli utenti finali possano visualizzare entrambi i preferiti che hanno salvato direttamente (tramite il componente aggiuntivo del browser o il sito Web Preferiti) e preferiti archiviati tramite licenze del servizio Preferiti. Le licenze avranno la possibilità di visualizzare un logo speciale che consente agli utenti finali di sapere che è in uso il servizio Preferiti di consulenza (e quindi questi preferiti saranno accessibili anche tramite il componente aggiuntivo del browser o il sito Web Preferiti). Le licenze possono anche continuare a usare il servizio Preferiti in background, nel qual caso i preferiti archiviati tramite tale sito non saranno disponibili tramite il componente aggiuntivo del browser o il sito Web Preferiti. La fase 3 verrà consegnata entro il 1° giugno 2001.
  La fase 3 offre una base per i servizi Web futuri. Ad esempio, se un utente visita una pagina Web, il sito potrebbe visualizzare un elenco di pagine Web a cui sono piaciute anche altre persone che hanno apprezzato la pagina. Il sito Web recupera l'elenco di pagine da un servizio Web. Non è stato ancora deciso se implementare questo tipo di servizio di profilatura.

In questo modo, potremmo mettere in atto il resto del documento visione.

Il passaggio successivo consiste nel definire alcuni profili utente. È importante considerare attentamente chi sono tutti gli utenti quando si definisce la visione per un progetto di servizio Web. Le categorie di utenti identificate durante la fase di progettazione sono:

• Utenti finali: chiunque usi un Web browser per visitare i siti Web.
• Licenze: qualsiasi azienda con un sito Web che usa il servizio Preferiti.
• Sviluppatori licenze: sviluppatori che creano un sito Web di un licenziatario.
• Operatori licenze: operatori del sito Web di un licenziatario.
• Operatori: le persone responsabili del funzionamento del servizio Preferiti.

È possibile leggere i profili utente completi nel documento visione Preferiti che accompagna questa colonna. Si scopre che abbiamo perso un paio di categorie: manager e manager di licenze. Questi elementi vengono ritagliati quando si è iniziato a pensare ai requisiti di creazione di report. Probabilmente avremmo dovuto suddividere i tester anche come categoria separata. Questo elenco dovrebbe fornire un buon punto di partenza per la maggior parte dei progetti di servizio Web.

Abbiamo anche dedicato un po' di tempo a pensare agli obiettivi aziendali e agli obiettivi di progettazione. Una delle domande principali è: Perché si sta creando il servizio Web? Stai cercando di fare soldi? Provare a semplificare i processi aziendali? O qualcos'altro? Qualunque cosa si decida, è probabile che abbia un impatto sui requisiti. Ad esempio, gli obiettivi principali per il servizio Preferiti sono:

• Presentare il nostro impegno nei prodotti di qualità.
• Evitare problemi di stampa non affidabili a causa di problemi di sicurezza, sicurezza o privacy personale.

Questa combinazione di obiettivi ha aggiunto un numero significativo di requisiti per il servizio, soprattutto nelle aree di licenza e nei requisiti di capacità (scalabilità, disponibilità e così via). Ma fare soldi è un obiettivo non completo per questo progetto. Se fosse un obiettivo, molti dei nostri requisiti di licenza sarebbero usciti un po'diversamente.

Dal punto di vista della progettazione, è consigliabile considerare la filosofia generale sulla privacy dell'utente, sulla sicurezza e su altri requisiti non funzionali. È anche consigliabile valutare se i client in tutto il mondo useranno il servizio Web e ciò che implica la globalizzazione e la localizzazione. Ad esempio, un paio di obiettivi di progettazione sono:

• Offrire una soluzione a livello mondiale. Il servizio e tutte le applicazioni di supporto devono essere globalizzati.
• Offrire un servizio affidabile e sicuro. Il servizio deve essere a disponibilità elevata, non deve perdere i dati e deve consentire l'accesso solo agli utenti autorizzati.

È possibile trovare il resto degli obiettivi aziendali e degli obiettivi di progettazione nel documento Visione preferiti.

Conclusione

È sempre più facile sapere quando si ha finito con un progetto se il team di progetto e i clienti hanno accettato gli obiettivi, gli obiettivi generali e l'ambito iniziale. Anche se si pensa di aggiungere un front-end del servizio Web a un sito Web esistente, vale la pena prendere il tempo necessario per scrivere un documento di visione. Perché si aggiunge il front-end? Chi ci si aspetta di usarlo? Quanto carico aggiuntivo sta per mettere sul tuo sito che le tue operazioni non si aspettano?

Scrivere il documento di visione per Preferiti è stato un esercizio prezioso per noi. Senza di esso, avremmo perso almeno la metà dei requisiti che sono finiti nella nostra specifica funzionale. Ad esempio, probabilmente non avremmo riconosciuto i problemi di privacy e sicurezza fino a molto più avanti nel gioco. Il documento Visione esegue anche altre operazioni per noi. Offre un criterio per la valutazione delle richieste di funzionalità e la definizione delle priorità dei requisiti. Il documento ci ricorda cosa si vuole fare nelle fasi future, è possibile tenere conto di ciò nella progettazione di esempio, in modo da non dover riscrivere completamente le cose in fondo alla strada.

La prossima settimana esamineremo i problemi di privacy indicati qui in modo più dettagliato. Vi farò sapere cosa ho appreso dal nostro gruppo di privacy aziendale, parlare dei problemi difficili che abbiamo posticipato e discutere i problemi di privacy che rimangono in fase uno e come questi hanno un impatto sulla nostra progettazione e implementazione.

Vedi, allora!

Mary Kirtland è l'architetto del team MSDN Web Services Guidance, in cui esegue tutte le operazioni, ma codifica, test o operazioni, incluso il tentativo di mantenere aggiornate le specifiche, scrivere tutto ciò che il team ha imparato negli articoli per MSDN, porre domande fastidiose durante le recensioni e ordinare il pranzo.