Sdílet prostřednictvím

Definování vize

  • Článek

 

Mary Kirtland
Microsoft Corporation

úterý 10. ledna 2001

Ve sloupci z minulého týdne jsme představili tým s pokyny k webovým službám a naše poslání: vytváření, nasazování a provozování ukázkových webových služeb, abychom ilustrovali typy problémů, které je potřeba vzít v úvahu, když to samé uděláte. Představil jsem také náš první ukázkový projekt, službu Favorites Service.

Děkujeme všem za vaše komentáře a zpětnou vazbu. Sledujeme problémy, které vám nastolujete, tak je mějte na cestě!

Někdo se zeptal, proč by vydání ukázky trvalo tři měsíce a proč jsme s ní nezačali před oznámením nápadu. Ve skutečnosti jsme poslední dva měsíce pracovali na Oblíbených téměř na plný úvazek. Hodně funkcí je, no, fungování... ale ještě je tu trochu práce, než je všechno zabaleno pěkně a úhledně do ukázky, kterou si můžete nainstalovat na vlastní počítače nebo vyzkoušet přes internet. Nějakou dobu také trvá napsat, zkontrolovat, upravit a zpracovat všechny články, které chceme dodávat s našimi ukázkovými zdroji. Proto se snažíme o tříměsíční projektové cykly. Držíme palce, abychom mohli dostat první vydání Oblíbených někdy v únoru. (Jak to píšu, tým prochází plánovacím cvičením, aby získal lepší odhad data vydání.)

Některé komentáře také předpokládají, že k vývoji této ukázky používáme rozhraní .NET Framework. To nemusí být nutně případ. Použijeme technologie, o které si myslíme, že jsou pro tuto úlohu nejlepší. A to nejlepší neznamená vždy technicky lepší, jednodušší použití nebo většinu zpráv. Ať už zvolíme cokoli, řekneme vám proč, a řekneme vám, na jaké problémy jsme narazili, když jsme se ho snažili použít.

Tento týden se začneme zabývat problémy, se kterými se náš tým setkal při vytváření služby Oblíbené položky. Je tu docela nevyřízených položek, ale začneme od začátku: zjišťujeme cíle a cíle projektu.

začínáme

V procesním modelu Microsoft Solution Framework je první fází každého projektu fáze plánování. Během fáze plánování vytvoří projektový tým a zákazníci přehled o cílech a omezeních projektu na nejvyšší úrovni. Primárním výstupem této fáze je dokument s vizí, který obsahuje analýzu obchodního problému, popis cílů produktu, osnovu konceptu řešení, profily uživatelů produktu, cíle návrhu a definici rozsahu projektu. Fáze plánování vyvrcholí ve schváleném milníku vize/rozsahu .

Náš tým začal z neobvyklého výchozího bodu: Věděli jsme, že chceme napsat webovou službu, ale neměli jsme na mysli žádnou konkrétní problémovou doménu, ani jsme neměli existující aplikace, které jsme museli použít. Takže první věc, kterou jsme potřebovali udělat, bylo přijít s přiměřeně realistickým obchodním scénářem, který by mohl ospravedlnit vytvoření škálovatelného, spolehlivého atd. atd. Webová služba.

Začali jsme tím, že jsme zamkli skupinu lidí v místnosti a debatovali o potenciálních firmách nebo odvětvích, službách a technických problémech, které by mohly být dobrými tématy pro vedení. Během této cesty jsme přišli na několik důvodů, proč byste mohli chtít vytvářet webové služby:

  • Jste zdrojem časově citlivých nebo parametrizovaných dat, která chtějí používat koncoví uživatelé nebo jiné firmy. Pokud se data často nemění a klienti téměř vždy chtějí všechna data, můžete také jednoduše publikovat dokument XML na webu. Pokud ale klienti chtějí provádět dotazy na vaše data, dává webová služba velký smysl. Pokud chcete odesílat data klientům, jsou potenciálními webovými službami také operace odběru a oznámení.
  • Implementujete algoritmy, které jiné firmy nemůžou nebo nechtějí implementovat samy. V tomto případě je každý algoritmus potenciální webovou službou: Klienti předávají data, vy odpovíte odpovědí.
  • Agregujete několik dalších služeb, abyste mohli poskytovat služby vyšší úrovně. V takovém případě klienti používají vaši službu, protože poskytují kombinaci požadovaných informací, což jim ušetří práci při kombinování samotných existujících služeb.
  • Chcete integrovat své obchodní procesy s partnery. Každý krok obchodního procesu, který prochází přes hranici podniku, je potenciální operací webové služby nebo webové služby.
  • Máte heterogenní nebo geograficky distribuovanou podnikovou architekturu, ve které není použití privátních sítí nebo úzce propojených protokolů pro integraci aplikací praktické. Rozhraní API každé aplikace, kterou chcete integrovat, je potenciální webová služba.
  • Poskytujete služby infrastruktury ("instalatérství") pro jiné webové aplikace a vývojáře webových služeb, například službu identit nebo fakturační službu. Místo vytváření vlastních knihoven rozhraní API pro každou klientskou platformu můžete rozhraní API vystavit jako webovou službu.

Samozřejmě, z jakéhokoli z těchto důvodů, musíte také zvážit, zda existuje dostatečný počet potenciálních klientů pro vaši službu k odůvodnění nákladů na jeho implementaci a provoz.

Také jsme si rychle uvědomili, že při vytváření ukázkových služeb pro vzdělávání široké cílové skupiny vývojářů existují další aspekty. Zaprvé, obchodní scénáře by neměly vyžadovat rozsáhlé znalosti daného odvětví. Za druhé chceme, abyste mohli nainstalovat a spustit ukázky na vlastních počítačích. Za třetí, mnoho zajímavých scénářů vyžaduje jedno nebo více úložišť dat nebo informačních kanálů. Při odesílání ukázkového zdrojového kódu dochází k mnoha problémům, které ukazují, jak získat přístup ke zdrojům dat, které nevlastníme. A nevlastníme žádné zdroje dat... aspoň ne, že bychom mohli darovat vzorek.

To nás vedlo od scénářů, jako je online bankovnictví, ovládání domácího digitálního videorekordéru, kontrola stavu letu nebo denní komiksový server k něčemu dalšímu v rámci služby infrastruktury. Začali jsme přemýšlet o typech webových služeb, které může MSDN poskytovat (skutečné služby, ne ukázky). Jedním z nápadů, které se lidem líbily, byl způsob, jak sledovat články na webu MSDN, které chtěli znovu najít, bez ohledu na to, na kterém počítači se k msdn dostanou. To nás vedlo k myšlence oblíbených položek na straně serveru.

Vize, Rev 1

Jakmile jsme měli hrubou představu o službě, kterou chceme vytvořit, vytvořili jsme kolem ní obchodní scénář:

  • Hledáme způsoby, jak rozšířit naši klientskou základnu pro náš vývoj webů a vygenerovat pravidelný tok výnosů. Věříme, že oba cíle můžeme dosáhnout poskytováním vysoce kvalitních webových služeb, které budou weby chtít používat. Vzhledem k tomu, že webové služby představují nový koncept, domníváme se, že potenciální zákazníci budou muset být přesvědčeni, že mohou vsadit část svého podnikání na naše služby. Proto potřebujeme webovou službu, která:
    • Nabízí zjevnou hodnotu pro weby potenciálních zákazníků.
    • Neposkytuje kritickou službu.
    • Ukazuje kvalitu našich postupů vývoje a provozu.
    • Je možné ji implementovat a nasadit za rozumnou cenu.

Tady je první řez naší vize projektu:

  • 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. Ve fázi 2 tohoto projektu budeme licencovat další služby pro weby. Příklad:
    • Statistika, které stránky z jejich webů jsou záložky.
    • Doporučené odkazy založené na analýze spřažení všech oblíbených položek uživatelů

Z technického hlediska tento scénář vypadal, jako by řešil řadu otázek, které jsme vyslechli od zákazníků. Obchodní logika nevypadala příliš složitě na implementaci – nebo příliš složitě na to, aby se našim čtenářům vysvětlovala. Ale jakmile bylo prohlášení o vizi zapsáno, aby se na ně všichni podívali, některé velké červené vlajky se rozlehly:

  • Potřebovali bychom globální identifikační schéma uživatelů, které je dostatečně běžné, aby weby dokázaly předat identifikátor uživatele naší službě.
  • Jak bychom ověřili koncového uživatele, když požadavky pocházejí z webu, a ne přímo od koncového uživatele? To zní, jako bychom potřebovali delegování, nebo bychom webům museli důvěřovat, že budou za uživatele posílat žádosti jenom v případě, že koncový uživatel skutečně používá svůj web.
  • Má mít některý web povoleno načítat oblíbené položky koncového uživatele, které byly přidány z jiného webu? Pokud ano, chceme, aby naše služby používal jakýkoli web, nebo bychom měli omezit přístup ke službě na licencované weby? Umožnit libovolnému webu přístup ke všem datům uloženým ve službě Oblíbené položky bez jakéhokoliv vstupu od koncového uživatele zní jako obrovský problém s ochranou osobních údajů.
  • Podobně platí, co když naše webová služba poskytla metody aktualizace pro zachování oblíbených informací uživatele. Má mít jeden web povoleno upravovat oblíbené položky koncového uživatele přidané z jiného webu?
  • Nemohli by koncoví uživatelé křičet a křičet, kdyby zjistili, že provádíme věci, jako je analýza vztahů, na jejich datech shromážděných z více webů? Jak by vůbec věděli, že tyto weby používají naši službu? Potřebovali bychom něco jako požadovat, aby se koncový uživatel zaregistroval v naší službě a nastavil předvolby ochrany osobních údajů, než bude mít jakýkoliv web přístup k jeho datům? Jak by koncový uživatel věděl, že se u nás může zaregistrovat?

Možná byl v pořádku nějaký další výzkum.

Vize, Rev 2

Poté, co jsem si prostudoval všechno, co jsem mohl najít o ochraně osobních údajů uživatelů, jsem strávil několik hodin se členem skupiny Microsoftu pro firemní ochranu osobních údajů a probírali jsme scénáře, které naše služba může potenciálně povolit, a důsledky pro ochranu osobních údajů. Vzal jsem stránku za stránkou poznámek a stále bylo několik otevřených problémů. Scénáře, kdy jeden web mohl přistupovat k datům přidaným z jiného webu nebo je upravovat, ale z hlediska ochrany osobních údajů zněly hrozně divně. To neznamená, že by neměly být povoleny, jen že je obtížnější napsat přesné, ale srozumitelné zásady ochrany osobních údajů, které by tyto scénáře pokryly, a koncovým uživatelům nemusí být scénáře vhodné.

Provedli jsme také předběžný průzkum problému s ověřováním. Ve skutečnosti neexistuje dobrý způsob, jak dnes globálně identifikovat a ověřovat uživatele přes internet, když je uprostřed nějaká aplikace. Microsoft Passport funguje skvěle, když uživatel komunikuje s webem prostřednictvím prohlížeče. Neexistuje ale bezpečný způsob, jak web předat přihlašovací údaje uživatele na jiný web. A co funkce jednotného přihlášení služby Passport, kdy uživatelé nemusí znovu zadávat svá uživatelská jména a hesla, když přejdou na jiný web s podporou služby Passport? Používá přesměrování na straně klienta. A naše webová služba nikdy nemluví přímo s počítačem koncového uživatele.

Na základě tohoto předběžného výzkumu jsme se rozhodli implementovat oblíbené položky ve fázích. To by nám poskytlo více času na řešení dopadů na ochranu osobních údajů a možná by webová služba identity, která byla několikrát zmíněna v primárním řadiči domény v minulém roce, k dispozici v době, kdy jsme potřebovali globální schéma identit.

Naše revidovaná vize vypadá takto:

  • Během CY2001 implementujeme a nasadíme webovou službu Oblíbené položky, která koncovým uživatelům umožní vytvořit záložky vybraných stránek z webů pro pozdější přístup. Tyto oblíbené položky budou uloženy službou Oblíbené položky, aby byly přístupné z libovolného počítače nebo zařízení, které koncový uživatel používá.
  • Služba Oblíbené položky bude sloužit k inzerování potenciálním zákazníkům, a proto musí být vysoce dostupnou, škálovatelnou a zabezpečenou službou, která demontuje závazek společnosti ke kvalitním a osobním údajům.

Puristé mohou namítat, že je to příliš dlouhá doba na to, aby bylo prohlášením o vizi. Důležité ale je, aby mu všichni rozuměli, ať už tomu chcete říkat jakkoliv.

Fáze jsme definovali takto:

  • Ve fázi 1 implementujeme a nasadíme webovou službu Oblíbené položky, kterou můžou vývojáři webů licencovat, aby mohli na pozadí spravovat oblíbené položky svých zákazníků. (Každý držitel licence má vlastně soukromé úložiště dat s oblíbenými uživateli.) Poskytneme také ukázku, která ukazuje, jak integrovat službu Oblíbené položky do webu. Služba a ukázka budou k dispozici pro licencování do 1. března 2001. Naším cílem je licencovat službu do 1. března 2001 na pět až 10 webů, které představují přibližně 10 000 nových koncových uživatelů měsíčně. (Vzhledem k našim současným zaměstnancům se domníváme, že jde o zvládnutelnou míru růstu.)
  • Ve fázi 2 implementujeme rozšíření prohlížeče pro Internet Explorer a Netscape Navigator, která koncovým uživatelům poskytnou bezpečný a bezpečný způsob správy oblíbených položek na libovolném webu stejným způsobem, jakým dnes spravují oblíbené položky na straně klienta. Implementujeme a nasadíme web, který koncoví uživatelé můžou používat ke správě oblíbených položek, přečíst si naše prohlášení o zásadách ochrany osobních údajů, nastavit možnosti profilu uživatele týkající se použití jejich osobních údajů a stáhnout rozšíření prohlížeče. Rozšíření prohlížeče a web budou dodány do 1. května 2001. Naším cílem je oslovit 1 000 nových koncových uživatelů měsíčně.
  • Ve fázi 3 rozšíříme webovou službu Oblíbené položky tak, aby koncoví uživatelé viděli oblíbené položky, které si uložili přímo (prostřednictvím doplňku prohlížeče nebo webu Oblíbené), i oblíbené položky, které byly uloženy prostřednictvím držitelů licence služby Oblíbené položky. Držitelé licence budou mít možnost zobrazit speciální logo, které koncovým uživatelům umožní zjistit, že se používá konzultační služba Oblíbených položek (a proto budou tyto oblíbené položky přístupné také prostřednictvím doplňku prohlížeče nebo webu Oblíbené). Držitelé licence také mohou dál používat službu Oblíbené položky na pozadí. V takovém případě nebudou oblíbené položky uložené prostřednictvím daného webu dostupné prostřednictvím doplňku prohlížeče nebo webu Oblíbené položky. Třetí fáze bude dodána do 1. června 2001.
    Třetí fáze představuje základ budoucích webových služeb. Pokud například uživatel navštíví webovou stránku, může web zobrazit seznam webových stránek, které se líbí i ostatním uživatelům, kterým se stránka líbila. Web načte seznam stránek z webové služby. Zatím jsme se nerozhodli, jestli tento typ služby profilace implementovat.

S tím, že bychom mohli zmasírovat zbytek dokumentu Vision.

Dalším krokem bylo definování některých profilů uživatelů. Při definování vize projektu webové služby je důležité pečlivě zvážit, kdo jsou všichni vaši uživatelé. Kategorie uživatelů, které jsme identifikovali během fáze vytváření projektu, jsou:

  • Koncoví uživatelé – každý, kdo používá webový prohlížeč k návštěvě webů.
  • Držitelé licencí – všechny firmy s webem, který používá službu Oblíbené položky.
  • Vývojáři pro držitele licence – vývojáři vytvářející web držitele licence.
  • Operátoři držitele licence – operátoři webu držitele licence.
  • Operátory – osoby zodpovědné za provoz služby Oblíbené položky.

Kompletní profily uživatelů si můžete přečíst v dokumentu s obrazem Oblíbené, který doprovází tento sloupec. Ukázalo se, že jsme vynechali několik kategorií: manažeři a manažeři licencí. Ty se ořízly, když jsme začali uvažovat o požadavcích na vytváření sestav. Pravděpodobně bychom měli mít rozdělené testery jako samostatnou kategorii. Tento seznam by měl být dobrým výchozím bodem pro většinu projektů webové služby.

Také jsme strávili trochu času přemýšlením o obchodních cílech a cílech návrhu. Jednou z hlavních otázek je, proč vytváříte webovou službu? Snažíš se vydělat peníze? Snažíte se zjednodušit obchodní procesy? Nebo něco úplně jiného? Bez ohledu na to, co se rozhodnete, bude to mít pravděpodobně vliv na vaše požadavky. Například primární cíle služby Oblíbené položky jsou:

  • Předveďte náš závazek ke kvalitním produktům.
  • Vyhněte se špatnému tisku kvůli nespolehlivé službě, problémům se zabezpečením nebo osobním problémům s ochranou osobních údajů.

Tato kombinace cílů přidala významný počet požadavků na naši službu, zejména v oblastech licencování a požadavků na schopnosti (škálovatelnost, dostupnost atd.). Ale vydělat peníze je pro tento projekt zcela necílový. Pokud by to byl cíl, řada našich licenčních požadavků by vyšla trochu jinak.

Z hlediska návrhu byste měli uvažovat o celkové filozofii ochrany osobních údajů, zabezpečení a dalších nefunkčních požadavků uživatelů. Měli byste také zvážit, jestli vaši webovou službu budou používat klienti po celém světě a co to znamená o globalizaci a lokalizaci. Mezi naše cíle návrhu patří například:

  • Doručte celosvětové řešení. Služba a všechny podpůrné aplikace musí být globalizované.
  • Poskytovat spolehlivou a zabezpečenou službu. Služba musí být vysoce dostupná, nesmí ztratit data a musí povolit přístup pouze autorizovaným uživatelům.

Zbývající obchodní cíle a cíle návrhu najdete v dokumentu Oblíbené obrazy.

Závěr

Vždy je jednodušší zjistit, kdy máte projekt hotový, pokud se projektový tým a vaši zákazníci předem dohodli na celkových cílech, cílech a rozsahu. I když si myslíte, že právě přidáváte front-end webové služby na existující web, stojí za to napsat dokument s vizí. Proč přidáváte front-end? U koho očekáváte, že ho budete používat? Kolik dalšího zatížení to bude dát na váš web, že vaše operace lidé neočekávají?

Vytvoření vizuálního dokumentu pro Oblíbené pro nás bylo cenným cvičením. Bez ní bychom vynechali alespoň polovinu požadavků, které skončily v naší funkční specifikaci. Například jsme pravděpodobně nerozpoznali problémy s ochranou osobních údajů a zabezpečením až mnohem později ve hře. Dokument Vision za nás dělá i další věci. Poskytuje nám měřítko pro vyhodnocení žádostí o funkce a stanovení priorit požadavků. Dokument nám připomíná, co chceme dělat v budoucích fázích – můžeme to zohlednit v ukázkovém návrhu, abychom nemuseli všechno úplně přepisovat.

Příští týden se podrobněji podíváme na zde uvedené problémy s ochranou osobních údajů. Řeknu vám, co jsem se naučil od naší firemní skupiny ochrany osobních údajů, promluvím si o těžkých problémech, které jsme odložili, a probereme problémy týkající se ochrany osobních údajů, které zůstávají ve fázi 1, a jejich dopad na náš návrh a implementaci.

Tak se uvidíme!

Mary Kirtland je architektkou týmu msdn Web Services Guidance, kde dělá všechno kromě kódování, testování nebo operací, včetně toho, že se snaží udržovat specifikace aktuální, zapisuje všechno, co se tým naučil v článcích pro MSDN, klade otravné otázky během kontrol a objednává oběd.