Das Modell besteht aus fünf verschiedenen Sichtweisen auf ein Projekt, welche sich untereinander beeinflussen. Jede dieser Sichtweisen spiegelt einen Planungsschritt wider und zielt auf einen anderen Aspekt in der Planungskette ab. Nach dem ISO 10746 Standard gibt es die folgenden Sichtweisen auf ein System: Enterprise viewpoint, Information viewpoint, Computational viewpoint, Engineering viewpoint und Technology viewpoint. Sie können dabei in verschiedener Reihenfolge behandelt werden, es wird folgendes Ablaufschema (Abbildung 9) vorgeschlagen:

Die verschiedenen Viewpoints werden im Folgenden anhand eines fiktiven Projekts im Detail erklärt. Im ersten Abschnitt eines Projekts zum Aufbau einer Dateninfrastruktur für Smarte Städte und Regionen wurden von einer Stadt die folgenden Herausforderungen identifiziert: Nutzung erneuerbarer Energien fördern und Klima-Resilienz stärken. Im Rahmen eines Stadtumbauprojekts wurden daher zwei Use Cases definiert:

• Nutzung von Solarenergie für einen geplanten Gebäudekomplex der Stadtverwaltung. Es soll mittels digitaler Modelle verschiedener Varianten des geplanten Gebäudekomplexes diejenige ermittelt werden, die den besten Kompromiss aus Kosten und erzeugter Solarenergie darstellt. Die für diesen Use Case zu entwickelnde Dateninfrastruktur soll langfristig für alle Bauvorhaben im Stadtgebiet genutzt werden können.
• Entwicklung von Plänen für eine grünere, attraktivere und klimaresiliente Innenstadt. Es soll mittels digitaler Modelle eines geplanten Gebäudekomplexes diejenige Variante ermittelt werden, die aus Sicht des Stadtklimas (d.h. Vermeidung von Hitzeinseln, hohe Aufenthaltsqualität für Passanten, Kühlung der Gebäude und ihrer direkten Umgebung bis hin zur Nahrungsmittelproduktion auf den Dächern) den besten Kompromiss darstellt.

Für beide Use-Cases soll die Umgebung des geplanten Gebäudekomplexes in die Untersuchungen einbezogen werden. Abbildung 10 zeigt die Struktur des geplanten Projekts und die beiden geplanten Use Cases mitsamt ihren benötigten Daten und erwarteten Ergebnissen.

In Workshops mit den Akteuren wurden im ersten Schritt die unter dem Kapitel 2. erwähnten Kriterien erarbeitet. Die folgenden Abschnitte beschreiben nun das Vorgehen zum Aufbau der Dateninfrastruktur innerhalb der einzelnen Viewpoints.

Um die verschiedenen Akteure besser einordnen zu können empfiehlt sich die Verwendung einer Stakeholder-Matrix. Diese ist in den SSD-Regionen bereits zum Einsatz gekommen und hat sich als sinnvolles Hilfsmittel bewährt. Die Stakeholder-Matrix ist ein 2-Achsen-Diagramm mit dem bekundeten Interesse eines Akteurs auf der horizontalen Achse und seinem Einfluss auf das Projekt in der vertikalen Achse. Jeder Stakeholder wird nun entsprechend seiner Involviertheit in diesem Diagramm frei platziert, je nachdem wie stark oder schwach seine Zugehörigkeit zu den beiden Achsen des Diagramms ist. Im Anschluss können die Stakeholder nun in vier Kategorien unterteilt werden:

• Zufrieden halten: Stakeholder mit generell wenig Interesse aber hohem Einfluss, z.B. die Eigentümer wichtiger Daten für das Projekt, sollten gut mit Informationen über den Fortgang des Projekts versorgt und zufrieden gehalten werden, da viel von ihnen abhängt. Dies kann zum Beispiel geschehen, in dem der Nutzen des Use Case für sie transparent gemacht und ihr Beitrag zum Use Case öffentlichkeitswirksam dargestellt wird.
• Stark zusammenarbeiten: Stakeholder die sowohl viel Einfluss als auch großes Interesse an einem Projekt haben sind die stärksten Partner. Mit ihnen ist eine enge Zusammenarbeit unabdingbar. Bei einer Steigerung der Attraktivität des ÖPNV-Netzes wären dies z.B. der ÖPNV-Netzbetreiber selbst oder Telekommunikationsanbieter.
• Im Auge behalten: Akteure mit geringem Interesse und Einfluss erweisen sich kurzfristig gesehen vielleicht nicht als großer Gewinn, bringen zu einem späteren Zeitpunkt jedoch vielleicht neue Ideen ein oder gewinnen an Relevanz, wenn es zu neuen Entwicklungen kommt. Sie sollten während der Planung und Umsetzung im Auge behalten werden. Als Beispiel dienen hier Bürger aus anderen Gemeinden oder kleinere Dienstleister, welche nur am Rande in das Projekt involviert sind.
• Informiert halten: Stakeholder mit viel Interesse aber wenig Einfluss, z.B. Anwohner, sollten über die weiteren Schritte informiert bleiben, um ihre Interessen und Anregungen vorbringen zu können.

Neben der Einteilung der Akteure nach Einfluss und Interesse an einem bestimmten Use Case ist auch eine Festlegung von Rollen für die tatsächliche Umsetzung eines Use Case sehr hilfreich. Die Akteure nehmen dabei im Gesamtprojekt und in den Use Cases unterschiedliche Rollen ein. Ein und derselbe Akteur kann so in verschiedenen Rollen im Gesamtprojekt und in den einzelnen Use Cases auftreten Abbildung 12 stellt diesen Zusammenhang in vereinfachter Form anhand des Beispiel-Projekts dar.

Um sicherzugehen, dass jede Rolle in der Umsetzung eines Projektes mit mindestens einem Stakeholder besetzt ist, empfiehlt es sich für jeden Use Case die vorhandenen Rollen aufzulisten und die vorhandenen Akteure darauf aufzuteilen. Um eine SDDI-Instanz umsetzen zu können, werden im SDDI-Prozess folgende Rollen besetzt. Es kann dabei zwischen Use-Case-unabhängigen Rollen und Use-Case-spezifischen Rollen unterschieden werden:

• Rollen für das Bereitstellen der zentralen Dateninfrastruktur:
  • Fachlicher Experte für Datenintegration: Der fachliche Experte für  Datenintegration hat einen Überblick über alle im Gesamtprojekt  verwendeten Daten und über standardisierte Datenmodelle.
  • Projektleiter: Treiber des Gesamtprozesses der Umsetzung
  • Mentor: Entscheidungsträger in der Gebietskörperschaft, der das Tun des Projektleiters auf strategischer Ebene / politisch unterstützt
  • Basisdatenlieferant für das virtuelle Distriktmodell: Zur Umsetzung und zur Aktualisierung des -->Virtuellen Distriktmodells werden Basisdaten benötigt, zum Beispiel 3D-Gebäudemodelle und ein Digitales Geländemodell. Anbieter dieser Daten ist meist die zuständige Geodatenverwaltung.
  • Betreiber des virtuellen Distriktmodells: Neben den Basisdaten und den spezifischen Fachdaten des Use Cases benötigt das virtuelle Distriktmodell auch eine Person oder einen Dienstleister,  von dem das Hosting inkl. Einspielen von aktualisierten Daten übernommen wird. Dies erfordert meist den Betrieb eines (3D-)GIS bzw. einer Geodatenbank mit entsprechendem Datenmodell und entsprechenden offenen, standardisierten Schnittstellen.
  • Betreiber und Redakteure des Geovisualisierungsplattform: Die Geovisualisierungsplattform dient der Visualisierung und Exploration des virtuellen Distriktmodells. Während der Betreiber für die Bereitstellung und den Betrieb der Visualisierungsplattform zuständig ist, konfiguriert der Redakteur die Plattform so, dass sie die für die Use-Cases benötigten Inhalte visualisiert werden können.
  • Betreiber und Redakteure der Katalogplattform: Die zentrale Katalogplattform muss von einem Akteur bzw. Dienstleister betrieben werden[1]. Ebenfalls bedarf es Personen mit Erfahrung in der Bedienung des Katalogs (hier „Redakteure“ genannt), um dem Use Case entsprechend Einträge vorzunehmen und Akteuren beim Eintragen ihrer Informations-Ressourcen zu unterstützen.
  • Fachlicher Experte für Sensoren / IoT: Der fachliche Experte für  Sensoren / IoT bringt Expertise im Bereich Sensoren / IoT /  Sensordatenplattformen und -Schnittstellen ein.
  • Fachlicher Experte für Interoperabilität und verteilten Systeme: Für die Verknüpfung verschiedener Systeme wird gegebenenfalls  ein eigener Experte benötigt. Dieser kümmert sich darum, dass die  einzelnen Komponenten des Projekts auf technischer Ebene, im  SDDI-Kontext also auf der Ebene von Web Services, miteinander reibungslos kommunizieren können.
• Use Case spezifische Rollen:
  • Anwender: Der Anwender ist eine Person, die eine SDDI-Anwendung nutzt und Nutzen daraus zieht.
  • Entwickler der Anwendung / App: Für die Entwicklung einer Use Case spezifischen Anwendung, zum Beispiel einer Smartphone-App, wird ein entsprechender Entwickler benötigt. Dies kann entweder eine Einzelperson oder ein externer Dienstleister sein
  • Lieferant von urbanen Analysewerkzeugen: Der Lieferant von  urbanen Analysewerkzeugen ist meist ein externer  Softwareanbieter, der bestimmte, für den Use Case relevante,  Werkzeuge bereitstellt. Dabei muss es sich nicht zwingend um  Software handeln, sondern es kann z.B. kann auch eine bestimmte  Methode zur Einbindung der Bevölkerung ein wertvolles urbanes  Analysewerkzeug sein.
  • Lieferant von Use-Case-spezifischen IoT-Sensordaten: die Person, die zuständig ist für die Bereitstellung von IoT oder Sensordaten.
  • „Pate“ des Use Cases: In jedem Use Case wird ein sogenannter „Pate“ (Use Case Owner) benötigt, der die Organisation übernimmt und für einen reibungslosen Ablauf sorgt. Der Pate muss selbst kein Experte auf jedem einzelnen Teilgebiet sein, das von dem Use Case tangiert wird, sollte jedoch genug Vorwissen mitbringen, um einen Überblick über alle Teilbereiche eines Projekts zu erlangen.
  • Fachlicher Experte für den Use Case: Der fachliche Experte für den Use Case kann sowohl ein eine Person mit entsprechendem Knowhow als auch ein externer Berater sein. Wichtig ist ein umfassendes Wissen im Bereich des Projekts, hierfür können auch mehrere Personen in einem Expertenkreis zusammengefasst werden.
  • Lieferant von Use Case spezifischen statischen Domänendaten: Neben den  genannten Basisdaten sind oft spezifische Daten für einzelne Use  Cases erforderlich. Dies könnten zum Beispiel Daten über  Versorgungsnetze, ÖPNV-Verkehrsnetze oder Anwohnerdaten sein. Diese Informationen können mit dem virtuellen Distriktmodell verknüpft werden, um dessen anzureichern.

Für jede einzelne dieser Rollen sollte eine Stakeholder-Matrix aufgesetzt und mit den verschiedenen Stakeholdern befüllt werden. Somit entstehen verschiedene Diagramme, welche die verschiedenen Interessens- und Einflusslagen der Akteure widerspiegeln. Es ist dabei möglich, dass ein Stakeholder in einer der Rollen starkes Interesse zeigt, in einer anderen jedoch nur geringes oder andersherum. Die Ergebnisse können in einer gemeinsamen Tabelle kombiniert werden, und so übersichtlich darstellen welche Personen, Dienstleister, Behörden, usw. in welcher Art an dem Use Case mitwirken.

[1] im Rahmen der ZD.B-Themenplattform „Smart Cities and Regions“ wird eine Katalogplattform („Masterkatalog“) zentral gehostet und bayernweit zur Verfügung gestellt. Für regionale Kataloginstanzen wird eigene Hardware sowie eine zuständige Person oder ein Dienstleister benötigt.

Für den Use Case (A) ergab sich im Zuge des Abschnitts 1 (SDDI-Readiness) die folgende Stakeholder-Matrix. Als erster Schritt im Rahmen des Enterprise Viewpoint wurden vom Gesamtprojektleiter anhand der Matrix und in Gesprächen mit den potenziellen Stakeholdern diejenigen identifiziert, die für die Umsetzung des Use Case wichtig sind (in Abbildung 12 rot markiert). Im Zuge dessen wurde auch der “Pate” (Use Case Owner) für den Use Case bestimmt (in Abbildung 12 grün markiert).

In einem anschließenden Workshop mit den ausgewählten Akteuren wurden die technischen Anforderungen und die Anforderungen an die Daten erarbeitet. Die SDDI, sowie dieser Leitfaden beinhaltet dabei ausschließlich Aspekte der Datenintegration, und nicht andere domänenspezifischen Aspekte, wie zum Beispiel Energieversorgung oder Mobilität.

Im Workshop entstanden die folgenden Tabellen, die für jeden Use Case die erforderlichen Informations-Ressourcen und die möglichen Bezugsquellen enthalten. Dabei wurde in der zentralen Katalogplattform recherchiert ob diese Informations-Ressourcen im Gesamtprojekt bereits an anderer Stelle genutzt werden. Im Workshop wurden auch alle Konflikte und Probleme bei der Bereitstellung der Daten identifiziert und dokumentiert. Mögliche Alternativen zur Konfliktlösung wurden ebenfalls erörtert. Für Use Case (A) ergaben sich die folgenden Tabellen, mit dem Ziel, das Solarpotenzial für die verschiedenen Gebäudevarianten zu ermitteln. Das Solarpotenzial wird mit zwei Urbanen Analysewerkzeugen ermittelt. Werkzeug 1 schätzt die solare Einstrahlungsenergie, Werkzeug 2 berechnet daraus den potenziellen Strom-Ertrag unter Berücksichtigung der Spezifikation unterschiedlicher Photovoltaik-Module. Beispielhaft stellt Tabelle 1 die benötigten Daten für Werkzeug 1 den Bezugsquellen gegenüber. Mit Symbolen wird die Verfügbarkeit der Daten näher beschrieben. So wird mit ( ) angezeigt, dass die Daten verfügbar sind und (!) deutet an, dass es im Anschluss an den Workshop noch Klärungsbedarf gibt. (x) bedeutet, dass benötigte Daten nicht verfügbar sind. Ein Muster für eine derartige Tabelle befindet sich im Anhang.

Nachdem die benötigten Informations-Ressourcen (im Beispiel die benötigten Daten und Urbanen Analysewerkzeuge) feststehen, aktualisiert der Datenintegrationsexperte zusammen mit dem “Paten” des Use Case in Abstimmung mit dem Gesamtprojektleiter die folgenden Informationen (zum Beispiel wird die Vermessungsverwaltung als wichtiger Datenbereitsteller für den Use Case in die Liste der Akteure aufgenommen) und fasst sie in einer weiteren Tabelle zusammen (Vorlage siehe Anhang):

• Beteiligte Akteure und deren Rollen mit Ansprechpersonen
• Verfügbarkeit von Daten und Werkzeugen

Als letzter Schritt im Rahmen des Enterprise Viewpoint, werden grundlegende Informationen in die Katalogplattform (siehe Kapitel „Der Katalogdienst – Die zentrale Plattform für alle Informations-Ressourcen“) des Projekts eingetragen. Dies kann zum Beispiel durch den Datenintegrationsexperten, oder durch die jeweiligen Bereitsteller der Informations-Ressourcen erfolgen.

Ausgehend von den fünf Eingangsdatenquellen, welche im Kapitel „Der Enterprise Viewpoint am Beispiel“ festgelegt wurden, soll ein anwenderfreundlicher 3D Web Map Client entstehen, der das Geländemodell, die Vegetation, die Bestandsgebäude, sowie die berechneten Solarwerte für Dachflächen geplanter Gebäude aufzeigt. Der 3D Web Map Client soll die Funktionalität bieten, ein geplantes Gebäude zu laden (ggf. bestehende Gebäude am Ort des geplanten Gebäudes auszublenden) und die Solarpotentialanalyse für das geplante Gebäude anzustoßen. Hierfür wurden die in der Abbildung 13 als blaue Kästchen dargestellten Systemkomponenten identifiziert. Die ockerfarbenen Kästchen zeigen Prozessierungsschritte auf, die grünen Pfeile verbinden die Systemkomponenten. Die Darstellung erfolgt auf konzeptueller Ebene. Das heißt, dass die Systemkomponenten unabhängig von einem bestimmten Softwareprodukt beschrieben werden. Fest stehen an dieser Stelle lediglich die im Information Viewpoint definierten Datenmodelle (im Beispiel CityGML für das VDM und Observations&Measurements für die Wetterdaten).

Ziel des Engineering Viewpoints ist es zu dem im vorherigen Schritt entstandenen Use Case Modell in den einzelnen Komponenten die richtigen (Web-Service) Schnittstellen zu finden, um so Interoperabilität zu ermöglichen. Wo immer möglich sollte bei der Wahl der Schnittstellen auf internationale Standards zurückgegriffen werden. Im Beispiel handelt es sich hierbei um den Sensor Observation Service (SOS), sowie um die Web Map Service (WMS) und die transactional Web Feature Service (WFS-T) Schnittstelle.

Im Technology Viewpoint werden die benötigten Hardware- und Software Komponenten für die Umsetzung des Use Cases ermittelt. Abbildung 16 zeigt die technische Umsetzung des im Kapitel „Der Computational Viewpoint am Beispiel“ aufgezeigten Arbeitsflusses in einem kleineren Ausschnitt. In Rot sind die neuen Komponenten markiert. Sämtliche Transformationen der ursprünglichen Daten in CityGML konforme Datenmodelle erfolgen in unserem Beispiel mittels der Software FME. Die Open Source Software 3DCityDB zur Verwaltung des Virtuellen Distriktmodells wird von einem Dienstleister aufgesetzt und verwaltet. Ein Hochleistungsrechner des Experten für Solarpotentialanalysen übernimmt die Berechnung der Sonneneinstrahlungswerte auf die jeweiligen Dachflächen und reichert die Objekte in der 3DCityDB über die WFS-T-Schnittstelle mit den Berechnungsergebnissen an. Anschließend werden die konkreten Instanzen der Systemkomponenten (z.B. Web Feature Service für den Zugriff auf das Virtuelle Distriktmodell mit Web-Adresse unter der dieser Dienst erreichbar ist) in die Katalogplattform eingetragen, um sie für das Gesamtprojekt und darüber hinaus sichtbar zu machen. Da an dieser Stelle alle benötigten Systemkomponenten und ihre Schnittstellen bekannt sind, eignen sich vorliegenden Ergebnisse des SDDI-Prozesses auch zur Erstellung von Ausschreibungsunterlagen für die Implementierung des Use Case. Da die verschiedenen Use Cases in einem Projekt auf die gleichen Ressourcen und ähnliche Prozesschritte zurückgreifen können, ist es oft sinnvoll sämtliche Komponenten eines Projekts zeitgleich zu betrachten.