Messe-Zulaufsteuerung Informationsarchitektur

Aus IVS-Wiki
Zur Navigation springen Zur Suche springen

Datenarchitektur

Referenzmodelle und Werkzeuge

Siehe IVS-Referenzmodelle und Werkzeuge.

Ausgangssituation der Datenarchitektur

Für die Übertragung der Verkehrslagedaten werden existierende Schnittstellen (DATEX II und OCIT-C) verwendet. Für die Slotinformationen (Anforderung eines Slots bzw. Beschreibung eines Slots) sind noch keine Datenformate vorhanden. UML wird verwendet, um ein plattformunabhängiges Datenmodell zu entwickeln.

Zielsituation der Datenarchitektur

In der folgenden Liste sind die auszutauschenden Daten mit den verwendeten Datenformaten aufgelistet:

Daten Datenformat Beschreibung
Verkehrslage (außerorts) DATEX II Verkehrslageinformationen können in DATEX II je nach Inhalt als ElaboratedDataPublication, als MeasuredDataPublication oder als SituationPublication übertragen werden.
Verkehrslage (innerorts) OCIT-C Die städtische Verkehrslage wird mit OCIT-C übertragen.
Slotdaten UML Das Datenmodell zur Beschreibung eines Be- bzw. Entladeslots wird neu entwickelt. Die Daten werden in UML modelliert. Das Datenübertragungsformat wird zu einem späteren Zeitpunkt festgelegt.
Slotanforderung UML Das Datenmodell zur Anforderung eines (neuen) Slots wird ebenfalls neu entwickelt. Die Daten werden in UML modelliert. Das Datenübertragungsformat wird zu einem späteren Zeitpunkt festgelegt.

Gap Analyse

Die vertikale Achse der folgenden Tabelle enthält die bereits vorhandenen Datenformate, die horizontale Achse die benötigten Formate:

DATEX II OCIT-C Slotdaten Slotanforderung Ausgeschieden
DATEX II inbegriffen
OCIT-C inbegriffen
Neu neu neu

Roadmap Komponenten

Die folgende Tabelle enthält die Priorisierung für die neu zu entwickelnden Datenarchitektur-Komponenten in einer Skale von 1-3 (1 = höchste Priorität, 3 = niedrigste Priorität):

Komponenten Priorität
Slotdaten 1
Slotanforderung 2

Auswirkung auf die Architekturlandschaft

Dieser Punkt kann für das Beispiel nicht sinnvoll durchgeführt werden, da der Kontext fehlt. Normalerweise werden an diesem Punkt andere Architektur Artefakte in der Architektur Landschaft untersucht , um zu identifizieren:

  • Hat die Datenarchitektur Auswirkungen auf bereits existierende Architekturen?
  • Wurden jüngst Änderungen ausgeführt, die Auswirkungen auf die Datenarchitektur haben?
  • Gibt es Möglichkeiten, Arbeiten die innerhalb der Datenarchitektur verrichtet wurden in anderen Bereichen zu nutzen?
  • Hat die Datenarchitektur Auswirkungen auf andere Projekte (einschließlich der Geplanten sowie diejenigen, die derzeit im Gange sind)?
  • Wird die Datenarchitektur von anderen Projekten beeinflusst (einschließlich der Geplanten sowie diejenigen, die derzeit im Gange sind)?

Im Rahmen einer Referenzarchitektur könnte z.B. geklärt werden, ob die neu zu entwickelnden Datenmodelle mittel- bis langfristig in eines der bestehenden Datenmodelle aufgenommen werden sollen (z.B. als Level-B-Erweiterung in DATEX II)

Stakeholder Review

An dieser Stelle sollten die relevanten Informationen und Entscheidungen an die Stakeholder kommuniziert werden. Insbesondere die direkt von den Änderungen/Erweiterungen betroffenen Stakeholder (in unserem Beispiel Garmin und die Messegesellschaft Frankfurt) müssen involviert werden.

Finalisierung der Datenarchitektur

An dieser Stelle werden die Rückmeldungen aus den Stakeholder-Reviews eingearbeitet und nochmals mit der Geschäftsarchitektur abgeglichen. Die Ergebnisse der Stakeholder-Reviews werden zum Zweck der Rückverfolgbarkeit dokumentiert. Ebenso werden alle Bausteine vollständig dokumentiert.

Dokumentation der Datenarchitekturdefinition

Die Datenarchitekturdefinitionen werden im Repository abgelegt.

Anwendungsarchitektur

Referenzmodelle und Werkzeuge

Ausgangssituation der Anwendungsarchitektur

Zielsituation der Anwendungsarchitektur

Gap Analyse

Roadmap Komponenten

Auswirkung auf die Architekturlandschaft

Stakeholder Review

Finalisierung der Anwendungsarchitektur

Dokumentation der Anwendungsarchitekturdefinition