Definieren der Vision

 

Mary Kirtland
Microsoft Corporation

10. Januar 2001

In der Spalte der letzten Woche habe ich das Web Services Guidance-Team und unsere Mission vorgestellt: Erstellen, Bereitstellen und Betreiben von Beispielwebdiensten, um die Arten von Problemen zu veranschaulichen, die Sie berücksichtigen müssen, wenn Sie dasselbe tun. Außerdem habe ich unser erstes Beispielprojekt vorgestellt, den Favoritendienst.

Vielen Dank an alle für Ihre Kommentare und Ihr Feedback. Wir verfolgen die Von Ihnen angesprochenen Probleme, also kommen Sie weiter!

Jemand fragte, warum es drei Monate dauern würde, bis wir das Beispiel veröffentlicht haben, und warum wir nicht damit begonnen hatten, bevor wir die Idee angekündigt haben. In der Tat haben wir in den letzten zwei Monaten fast vollzeit an Favoriten gearbeitet. Ein Großteil der Funktionalität ist, naja, funktioniert... aber es gibt noch ein bisschen Arbeit zu tun, bevor alles schön und ordentlich in ein Beispiel verpackt ist, das Sie auf Ihren eigenen Computern installieren oder über das Internet ausprobieren können. Es dauert auch einige Zeit, um alle Artikel zu schreiben, zu überprüfen, zu bearbeiten und zu verarbeiten, die wir mit unseren Beispielquellen ausliefern möchten. Deshalb streben wir dreimonatige Projektzyklen an. Wir drücken die Daumen, dass wir irgendwann im Februar das erste Release der Favoriten herausholen können. (Während ich dies schreibe, durchläuft das Team eine Planungsübung, um eine bessere Schätzung des Veröffentlichungsdatums zu erhalten.)

Einige der Kommentare gehen auch davon aus, dass wir die .NET Framework verwenden, um dieses Beispiel zu entwickeln. Das ist nicht unbedingt der Fall. Wir verwenden alle Technologien, die wir für die arbeit am besten halten. Und das Beste bedeutet nicht immer technisch überlegen, einfacher zu bedienen oder am meisten in den Nachrichten. Was auch immer wir auswählen, wir sagen Ihnen, warum und wir werden Ihnen sagen, welche Probleme aufgetreten sind, als wir versucht haben, es zu verwenden.

Diese Woche beginnen wir mit den Problemen, die unser Team beim Erstellen des Favoritendiensts aufgetreten ist. Es gibt einen ziemlichen Rückstand, aber wir beginnen am Anfang: die Ermittlung der Ziele und Ziele für das Projekt.

Erste Schritte

Im Microsoft Solution Framework-Prozessmodell ist die erste Phase in einem Projekt die Planungsphase. Während der Planungsphase erstellen das Projektteam und die Kunden eine allgemeine Ansicht der Ziele und Einschränkungen des Projekts. Der primäre Lieferumfang aus dieser Phase ist ein Vision-Dokument, das eine Analyse des Geschäftsproblems, eine Beschreibung der Ziele für das Produkt, eine Gliederung des Lösungskonzepts, Profile der Benutzer des Produkts, Designziele und eine Definition des Projektumfangs enthält. Die Planungsphase gipfelt in dem vision/scope genehmigten Meilenstein.

Unser Team begann mit einem ungewöhnlichen Ausgangspunkt: Wir wussten, dass wir einen Webdienst schreiben wollten, aber wir hatten keine bestimmte Problemdomäne im Blick und hatten auch keine vorhandenen Anwendungen, die wir verwenden mussten. Das erste, was wir tun mussten, war, ein einigermaßen realistisches Geschäftsszenario zu entwickeln, das den Aufbau eines skalierbaren, zuverlässigen usw. usw. rechtfertigen könnte. Webdienst.

Wir begannen damit, eine Reihe von Personen in einem Raum einzusperren und potenzielle Unternehmen oder Branchen, Dienstleistungen und technische Probleme zu brainstormen, die gute Themen als Orientierungshilfe darstellen würden. Im Übrigen haben wir einige Gründe für die Erstellung von Webdiensten:

• Sie sind eine Quelle für zeitkritische oder parametrisierte Daten, die Endbenutzer oder andere Unternehmen verwenden möchten. Wenn sich die Daten nicht häufig ändern und Clients fast immer alle Daten möchten, können Sie auch einfach ein XML-Dokument auf Ihrer Website veröffentlichen. Wenn Clients jedoch Abfragen für Ihre Daten ausführen möchten, ist ein Webdienst sehr sinnvoll. Wenn Sie Daten per Push an Clients übertragen möchten, sind die Abonnement- und Benachrichtigungsvorgänge auch potenzielle Webdienste.
• Sie implementieren Algorithmen, die andere Unternehmen nicht selbst implementieren können oder wollen. In diesem Fall ist jeder Algorithmus ein potenzieller Webdienst: Clients übergeben die Daten, Sie antworten mit der Antwort.
• Sie aggregieren mehrere andere Dienste, um einen Dienst auf höherer Ebene bereitzustellen. In diesem Fall verwenden Clients Ihren Dienst, da er die gewünschte Kombination von Informationen bereitstellt, wodurch ihnen die Arbeit erspart wird, die vorhandenen Dienste selbst zu kombinieren.
• Sie möchten Ihre Unternehmensprozesse in Partner integrieren. Jeder Schritt des Geschäftsprozesses, der eine Unternehmensgrenze überschreitet, ist ein potenzieller Webdienst- oder Webdienstvorgang.
• Sie verfügen über eine heterogene und/oder geografisch verteilte Unternehmensarchitektur, in der die Verwendung privater Netzwerke oder eng gekoppelter Protokolle für die Anwendungsintegration nicht praktikabel ist. Die API jeder Anwendung, die Sie integrieren möchten, ist ein potenzieller Webdienst.
• Sie stellen Infrastrukturdienste ("Sanitäranlagen") für andere Webanwendungs- und Webdienstentwickler bereit, z. B. einen Identitätsdienst oder einen Abrechnungsdienst. Anstatt benutzerdefinierte API-Bibliotheken für jede Clientplattform zu erstellen, können Sie Ihre API als Webdienst verfügbar machen.

Natürlich müssen Sie aus einem dieser Gründe auch überlegen, ob es eine ausreichende Anzahl potenzieller Kunden für Ihren Dienst gibt, um die Kosten für die Implementierung und den Betrieb zu rechtfertigen.

Wir haben auch schnell festgestellt, dass beim Erstellen von Beispieldiensten für die Schulung einer allgemeinen Entwicklergruppe einige andere Überlegungen zur Verfügung standen. Erstens sollten die Geschäftsszenarien keine umfassenden Kenntnisse einer bestimmten Branche erfordern. Zweitens möchten wir, dass Sie die Beispiele auf Ihren eigenen Computern installieren und ausführen können. Drittens erfordern viele interessante Szenarien einen oder mehrere Datenspeicher oder Feeds. Es gibt viele Probleme beim Versand von Beispielquellcode, der zeigt, wie Sie auf Datenquellen zugreifen können, die wir nicht besitzen. Und wir besitzen keine Datenquellen... zumindest nicht, dass es uns erlaubt ist, eine Probe zu verschenken.

Dies führte uns weg von Szenarien wie Online-Banking, Steuern des digitalen Videorekorders zu Hause, Check Flight status oder täglichen Comics-Server zu etwas mehr entlang der Art eines Infrastrukturdiensts. Wir haben über die Arten von Webdiensten nachgedacht, die MSDN bereitstellen könnte (echte Dienste, keine Beispiele). Eine Idee, die den Leuten wirklich gefallen hat, war eine Möglichkeit, MSDN-Artikel nachzuverfolgen, die sie wieder finden wollten, unabhängig davon, welchen Computer sie für den Zugriff auf MSDN verwendet haben. Das führte uns zur Idee serverseitiger Favoriten.

Die Vision, Rev 1

Nachdem wir eine grobe Vorstellung von dem Dienst hatten, den wir erstellen wollten, haben wir ein Geschäftsszenario erstellt:

• Wir suchen nach Möglichkeiten, unseren Kundenstamm für unsere Webentwicklungspraxis zu erweitern und einen regelmäßigen Umsatz zu generieren. Wir glauben, dass wir beide Ziele erreichen können, indem wir qualitativ hochwertige Webdienste bereitstellen, die Websites verwenden möchten. Da Webdienste ein neues Konzept sind, müssen potenzielle Kunden überzeugt werden, dass sie einen Teil ihres Geschäfts auf unsere Dienstleistungen setzen können. Daher benötigen wir einen Teaser-Webdienst, der:
  • Bietet offensichtlichen Nutzen für die Websites potenzieller Kunden.
  • Stellt keinen unternehmenskritischen Dienst bereit.
  • Zeigt die Qualität unserer Entwicklungs- und Betriebspraktiken.
  • Kann zu angemessenen Kosten für uns implementiert und bereitgestellt werden.

Hier ist der erste Schnitt unserer Vision für das Projekt:

• 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. In Phase 2 dieses Projekts werden zusätzliche Dienste für Websites lizenziert. Zum Beispiel:
  • Statistiken zu den Seiten ihrer Websites, die mit Lesezeichen versehen werden.
  • Empfohlene Links basierend auf einer Affinitätsanalyse aller Benutzerfavoriten.

Aus technischer Sicht sah dieses Szenario so aus, als würde es viele der Fragen beantworten, die wir von Kunden gehört haben. Die Geschäftslogik sah nicht so schwer zu implementieren aus – oder zu schwer, um unseren Lesern zu erklären. Aber sobald die Vision-Erklärung geschrieben wurde, damit alle sich ansehen konnten, gingen einige große rote Flaggen hoch:

• Wir benötigen ein globales Benutzeridentifikationsschema, ein Schema, das so üblich ist, dass Websites die Benutzer-ID an unseren Dienst übergeben können.
• Wie würden wir den Endbenutzer authentifizieren, wenn Anforderungen von einer Website und nicht direkt vom Endbenutzer stammen? Klingt so, als müssten wir delegieren, oder wir müssten den Websites vertrauen, nur im Namen eines Benutzers Anforderungen zu stellen, wenn der Endbenutzer seine Website tatsächlich verwendet.
• Sollte eine Website die Favoriten eines Endbenutzers abrufen dürfen, die von einer anderen Website hinzugefügt wurden? Wenn dies der Fall ist, möchten wir es jeder Website erlauben, unseren Dienst zu nutzen, oder sollten wir den Zugriff auf den Dienst auf lizenzierte Websites beschränken? Jeder Website Zugriff auf alle im Favoritendienst gespeicherten Daten ohne jegliche Eingabe des Endbenutzers zu gewähren, klingt nach einem großen Datenschutzproblem.
• Ähnlich verhält es sich, wenn unser Webdienst Updatemethoden zur Verwaltung von benutzerfavoriten Informationen bereitstellt. Sollte es einer Website gestattet sein, die Favoriten eines Endbenutzers zu ändern, die von einer anderen Website hinzugefügt wurden?
• Würden Endbenutzer nicht schreien und schreien, wenn sie herausfinden würden, dass wir Dinge wie Affinitätsanalysen für ihre von mehreren Websites gesammelten Daten durchführen würden? Wie würden sie überhaupt wissen, dass diese Websites unseren Dienst nutzen? Müssten wir beispielsweise verlangen, dass sich ein Endbenutzer bei unserem Dienst registriert und seine Datenschutzeinstellungen festlegen muss, bevor eine Website auf ihre Daten zugreifen kann? Wie würde der Endbenutzer wissen, sich bei uns zu registrieren?

Vielleicht waren einige zusätzliche Untersuchungen in Ordnung.

Die Vision, Rev 2

Nachdem ich alles über den Datenschutz von Benutzern finden konnte, verbrachte ich einige Stunden mit einem Mitglied der Microsoft Corporate Privacy Group und diskutierte die Szenarien, die möglicherweise durch unseren Dienst ermöglicht werden, und die Auswirkungen auf den Datenschutz. Ich nahm Seite für Seite Notizen, und es gab noch ein paar offene Probleme. Die Szenarien, in denen eine Website auf Daten zugreifen oder diese ändern konnte, die von einer anderen Website hinzugefügt wurden, klangen aus Datenschutzsicht jedoch schrecklich unerhört. Das heißt nicht, dass sie nicht zugelassen werden sollten, nur dass es schwieriger ist, eine genaue, aber verständliche Datenschutzrichtlinie zu schreiben, um diese Szenarien abzudecken, und Endbenutzer sind möglicherweise mit den Szenarien nicht vertraut.

Wir haben auch einige vorläufige Recherchen zum Authentifizierungsproblem gemacht. Es gibt heute wirklich keine gute Möglichkeit, Benutzer global über das Internet zu identifizieren und zu authentifizieren, wenn sich eine App in der Mitte befindet. Microsoft Passport funktioniert hervorragend, wenn ein Benutzer über einen Browser mit einer Website interagiert. Es gibt jedoch keine sichere Möglichkeit für die Website, die Anmeldeinformationen des Benutzers an eine andere Website zu übergeben. Was ist mit der Single Login-Funktion von Passport, bei der Benutzer ihre Benutzernamen und Kennwörter nicht erneut eingeben müssen, wenn sie zu einer anderen Passport-fähigen Website wechseln? Dabei werden clientseitige Umleitungen verwendet. Und unser Webdienst kommuniziert nie direkt mit dem Computer des Endbenutzers.

Basierend auf dieser Vorforschung haben wir uns entschieden, Favoriten in Phasen zu implementieren. Dies würde uns mehr Zeit geben, die Auswirkungen auf den Datenschutz zu klären, und vielleicht wäre der Identitätswebdienst, der bei der PDC im letzten Jahr mehrmals erwähnt wurde, verfügbar, wenn wir ein globales Identitätsschema benötigten.

Unsere überarbeitete Vision sieht wie folgt aus:

• Wir implementieren und stellen während cy2001 einen Favoritenwebdienst bereit, mit dem Endbenutzer ausgewählte Seiten von Websites für späteren Zugriff mit Lesezeichen versehen können. Diese Favoriten werden vom Favoritendienst gespeichert, sodass sie von jedem Computer oder Gerät aus zugänglich sind, den der Endbenutzer verwendet.
• Der Favorites Service wird verwendet, um potenziellen Kunden zu werben und muss daher ein hochverfügbarer, skalierbarer und sicherer Dienst sein, der das Engagement des Unternehmens für Qualität und persönliche Privatsphäre unter Beweis stellt.

Puristen mögen argumentieren, dass dies viel zu lang ist, um eine Vision zu sein. Wichtig ist jedoch, dass es jeder versteht, wie man es nennen will.

Die Phasen wurden wie folgt definiert:

• In Phase 1 implementieren und stellen wir einen Favoriten-Webdienst bereit, der für Websiteentwickler lizenziert werden kann, um die Favoriten ihrer Kunden im Hintergrund zu verwalten. (Im Grunde verfügt jeder Lizenznehmer über einen privaten Datenspeicher mit Benutzerfavoriten.) Wir stellen auch ein Beispiel bereit, das zeigt, wie sie den Favoritendienst in eine Website integrieren. Der Dienst und das Beispiel stehen bis zum 1. März 2001 zur Lizenzierung zur Verfügung. Unser Ziel ist es, den Dienst bis zum 1. März 2001 an fünf bis 10 Websites zu lizenzieren, die etwa 10.000 neue Endbenutzer pro Monat darstellen. (Wir glauben, dass dies angesichts unserer aktuellen Mitarbeiter ein überschaubares Wachstum ist.)
• In Phase 2 implementieren wir Browsererweiterungen für Internet Explorer und Netscape Navigator, die Endbenutzern eine sichere Möglichkeit bieten, ihre Favoriten auf jeder Website auf die gleiche Weise zu verwalten, wie sie heute clientseitige Favoriten verwalten. Wir werden auch eine Website implementieren und bereitstellen, die Endbenutzer verwenden können, um ihre Favoriten zu verwalten, unsere Datenschutzerklärung zu lesen, Benutzerprofiloptionen für die Verwendung ihrer persönlichen Informationen festzulegen und Browsererweiterungen herunterzuladen. Die Browsererweiterungen und die Website werden bis zum 1. Mai 2001 bereitgestellt. Unser Ziel ist es, jeden Monat 1.000 neue Endbenutzer zu erreichen.
• In Phase 3 erweitern wir den Favoriten-Webdienst, sodass Endbenutzer sowohl die favoriten, die sie direkt (über das Browser-Add-In oder die Favoriten-Website) gespeichert haben, als auch Favoriten sehen können, die über Lizenznehmer des Favoritendiensts gespeichert wurden. Lizenznehmer haben die Möglichkeit, ein spezielles Logo anzuzeigen, das Endbenutzern mitteilen kann, dass der Consulting Favorites Service verwendet wird (und daher sind diese Favoriten auch über das Browser-Add-In oder die Favoriten-Website zugänglich). Lizenznehmer können auch weiterhin den Favoritendienst im Hintergrund verwenden. In diesem Fall sind die über diese Website gespeicherten Favoriten nicht über das Browser-Add-In oder die Favoriten-Website verfügbar. Phase 3 wird bis zum 1. Juni 2001 bereitgestellt.
  Phase 3 bietet eine Grundlage für zukünftige Webdienste. Wenn ein Benutzer beispielsweise eine Webseite besucht, kann die Website eine Liste von Webseiten anzeigen, die anderen Personen, denen die Seite gefällt, ebenfalls gefallen haben. Die Website ruft die Liste der Seiten aus einem Webdienst ab. Wir haben noch nicht entschieden, ob diese Art von Profilerstellungsdienst implementiert werden soll.

Damit könnten wir den Rest des Vision-Dokuments konkretieren.

Der nächste Schritt bestand im Definieren einiger Benutzerprofile. Wenn Sie die Vision für ein Webdienstprojekt definieren, ist es wichtig, sorgfältig darüber nachzudenken, wer alle Ihre Benutzer sind. Die Benutzerkategorien, die wir während der Planungsphase identifiziert haben, sind:

• Endbenutzer: Jeder, der einen Webbrowser verwendet, um Websites zu besuchen.
• Lizenznehmer– jedes Unternehmen mit einer Website, die den Favoritendienst verwendet.
• Lizenzentwickler: Entwickler, die die Website eines Lizenznehmers erstellen.
• Lizenznehmer: Betreiber der Website eines Lizenznehmers.
• Operatoren: Die Personen, die für den Betrieb des Favoritendiensts verantwortlich sind.

Sie können die vollständigen Benutzerprofile im Dokument Favoriten-Vision lesen, das dieser Spalte beigefügt ist. Es stellt sich heraus, dass wir ein paar Kategorien verpasst haben: Manager und Manager von Lizenznehmern. Diese sind aufgelaufen, als wir anfingen, über Berichtspflichten nachzudenken. Wir sollten tester wahrscheinlich auch als separate Kategorie aufteilen. Diese Liste sollte einen guten Ausgangspunkt für die meisten Webdienstprojekte bieten.

Wir haben auch ein wenig Zeit damit verbracht, über Geschäftsziele und Designziele nachzudenken. Eine der Standard Fragen ist: Warum erstellen Sie den Webdienst? Versuchen Sie, Geld zu verdienen? Versuchen Sie, Geschäftsprozesse zu optimieren? Oder etwas ganz anderes? Unabhängig davon, wie Sie sich entscheiden, hat dies wahrscheinlich Auswirkungen auf Ihre Anforderungen. Beispielsweise sind die primären Ziele für den Favoritendienst:

• Zeigen Sie unser Engagement für Qualitätsprodukte.
• Vermeiden Sie schlechte Presse aufgrund von unzuverlässigem Dienst, Sicherheitsproblemen oder Persönlichen Datenschutzproblemen.

Diese Kombination der Ziele hat eine erhebliche Anzahl von Anforderungen an unseren Dienst hinzugefügt, insbesondere in den Bereichen Lizenzierung und Fähigkeitsanforderungen (Skalierbarkeit, Verfügbarkeit usw.). Aber Geld verdienen ist ein vollständiges Nicht-Ziel für dieses Projekt. Wenn es ein Ziel wäre, wären viele unserer Lizenzierungsanforderungen etwas anders herausgekommen.

Aus Entwurfssicht sollten Sie über Ihre allgemeine Philosophie in Bezug auf Datenschutz, Sicherheit und andere nicht funktionale Anforderungen nachdenken. Sie sollten auch überlegen, ob Clients auf der ganzen Welt Ihren Webdienst verwenden und was dies über Globalisierung und Lokalisierung bedeutet. Beispielsweise lauten einige unserer Designziele:

• Stellen Sie eine weltweite Lösung bereit. Der Dienst und alle unterstützenden Anwendungen müssen globalisiert werden.
• Bereitstellen eines zuverlässigen, sicheren Diensts. Der Dienst muss hochverfügbar sein, darf keine Daten verlieren und darf nur autorisierten Benutzern den Zugriff erlauben.

Die restlichen Geschäftsziele und Designziele finden Sie im Dokument Favoritenvision.

Zusammenfassung

Es ist immer einfacher zu wissen, wann Sie mit einem Projekt fertig sind, wenn das Projektteam und Ihre Kunden den allgemeinen Zielen, Zielen und Umfang im Voraus zugestimmt haben. Auch wenn Sie denken, dass Sie nur ein Webdienst-Front-End zu einer vorhandenen Website hinzufügen, lohnt es sich, sich die Zeit zu nehmen, ein Vision-Dokument zu schreiben. Warum fügen Sie das Front-End hinzu? Von wem erwarten Sie, dass sie verwendet wird? Wie viel zusätzliche Last wird dadurch auf Ihrer Website entstehen, die Ihre Mitarbeiter nicht erwarten?

Das Schreiben des Vision-Dokuments für Favoriten war eine wertvolle Übung für uns. Ohne sie hätten wir mindestens die Hälfte der Anforderungen verpasst, die in unserer Funktionsspezifikation gelandet sind. Beispielsweise hätten wir die Datenschutz- und Sicherheitsprobleme wahrscheinlich erst viel später im Spiel erkannt. Das Dokument Vision tut auch andere Dinge für uns. Sie gibt uns einen Maßstab für die Bewertung von Featureanforderungen und die Priorisierung von Anforderungen. Das Dokument erinnert uns daran, was wir in zukünftigen Phasen tun möchten – wir können dies im Beispielentwurf berücksichtigen, damit wir die Dinge nicht vollständig neu schreiben müssen.

In der nächsten Woche werden wir uns die hier erwähnten Datenschutzprobleme genauer ansehen. Ich werde Ihnen mitteilen, was ich von unserer Corporate Privacy Group gelernt habe, über die schwierigen Probleme sprechen, die wir zurückgestellt haben, und die Datenschutzprobleme besprechen, die in Phase 1 verbleiben und wie sich diese auf unser Design und unsere Implementierung auswirken.

Wir sehen uns an!

Mary Kirtland ist die Architektin für das MSDN Web Services Guidance-Team, in dem sie alles außer Programmieren, Testen oder Vorgängen erledigt, einschließlich des Versuchs, die Spezifikationen auf dem neuesten Stand zu halten, alles aufzuschreiben, was das Team in Artikeln für MSDN gelernt hat, während Der Überprüfungen lästige Fragen stellt und das Mittagessen bestellt.