Messe-Zulaufsteuerung Informationsarchitektur: Unterschied zwischen den Versionen
Zur Navigation springen
Zur Suche springen
| (9 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
| Zeile 4: | Zeile 4: | ||
=== Ausgangssituation der Datenarchitektur === | === Ausgangssituation der Datenarchitektur === | ||
| − | Für die Übertragung der Verkehrslagedaten | + | Für die Übertragung der Verkehrslagedaten existieren Schnittstellen ([http://www.datex2.eu/ DATEX II] und [http://www.ocit.org/downloadOCIT-C.htm OCIT-C]). |
| + | |||
| + | {| class="wikitable" | ||
| + | !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. | ||
| + | |} | ||
=== Zielsituation der Datenarchitektur === | === Zielsituation der Datenarchitektur === | ||
| Zeile 24: | Zeile 38: | ||
|Slotdaten | |Slotdaten | ||
|UML | |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. | + | |Das Datenmodell zur Beschreibung eines Be- bzw. Entladeslots wird neu entwickelt. Die Daten werden als plattformunabhängiges Modell in UML modelliert. Das Datenübertragungsformat (plattformspezifisches Modell) wird zu einem späteren Zeitpunkt festgelegt. |
|- | |- | ||
|Slotanforderung | |Slotanforderung | ||
|UML | |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. | + | |Das Datenmodell zur Anforderung eines (neuen) Slots wird ebenfalls neu entwickelt. Die Daten werden als plattformunabhängiges Modell in UML modelliert. Das Datenübertragungsformat (plattformspezifisches Modell) wird zu einem späteren Zeitpunkt festgelegt. |
|} | |} | ||
| Zeile 35: | Zeile 49: | ||
{| class="wikitable" | {| class="wikitable" | ||
! | ! | ||
| − | ! | + | !Verkehrslage (außerorts) |
| − | ! | + | !Verkehrslage (innerorts) |
!Slotdaten | !Slotdaten | ||
!Slotanforderung | !Slotanforderung | ||
!Ausgeschieden | !Ausgeschieden | ||
|- | |- | ||
| − | ! scope="row"| | + | ! scope="row"| Verkehrslage (außerorts) |
|inbegriffen | |inbegriffen | ||
| | | | ||
| Zeile 48: | Zeile 62: | ||
| | | | ||
|- | |- | ||
| − | ! scope="row"| | + | ! scope="row"| Verkehrslage (innerorts) |
| | | | ||
| inbegriffen | | inbegriffen | ||
| Zeile 64: | Zeile 78: | ||
=== Roadmap Komponenten === | === 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): | + | 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): |
{| class="wikitable" | {| class="wikitable" | ||
!Komponenten | !Komponenten | ||
| Zeile 90: | Zeile 104: | ||
=== Finalisierung der Datenarchitektur === | === 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 === | === Dokumentation der Datenarchitekturdefinition === | ||
| + | Die Dokumentation der Datenarchitekturdefinitionen wird im Repository abgelegt. | ||
== Anwendungsarchitektur == | == Anwendungsarchitektur == | ||
Aktuelle Version vom 15. April 2016, 09:53 Uhr
Inhaltsverzeichnis
- 1 Datenarchitektur
- 1.1 Referenzmodelle und Werkzeuge
- 1.2 Ausgangssituation der Datenarchitektur
- 1.3 Zielsituation der Datenarchitektur
- 1.4 Gap Analyse
- 1.5 Roadmap Komponenten
- 1.6 Auswirkung auf die Architekturlandschaft
- 1.7 Stakeholder Review
- 1.8 Finalisierung der Datenarchitektur
- 1.9 Dokumentation der Datenarchitekturdefinition
- 2 Anwendungsarchitektur
- 2.1 Referenzmodelle und Werkzeuge
- 2.2 Ausgangssituation der Anwendungsarchitektur
- 2.3 Zielsituation der Anwendungsarchitektur
- 2.4 Gap Analyse
- 2.5 Roadmap Komponenten
- 2.6 Auswirkung auf die Architekturlandschaft
- 2.7 Stakeholder Review
- 2.8 Finalisierung der Anwendungsarchitektur
- 2.9 Dokumentation der Anwendungsarchitekturdefinition
Datenarchitektur
Referenzmodelle und Werkzeuge
Siehe IVS-Referenzmodelle und Werkzeuge.
Ausgangssituation der Datenarchitektur
Für die Übertragung der Verkehrslagedaten existieren Schnittstellen (DATEX II und OCIT-C).
| 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. |
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 als plattformunabhängiges Modell in UML modelliert. Das Datenübertragungsformat (plattformspezifisches Modell) wird zu einem späteren Zeitpunkt festgelegt. |
| Slotanforderung | UML | Das Datenmodell zur Anforderung eines (neuen) Slots wird ebenfalls neu entwickelt. Die Daten werden als plattformunabhängiges Modell in UML modelliert. Das Datenübertragungsformat (plattformspezifisches Modell) 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:
| Verkehrslage (außerorts) | Verkehrslage (innerorts) | Slotdaten | Slotanforderung | Ausgeschieden | |
|---|---|---|---|---|---|
| Verkehrslage (außerorts) | inbegriffen | ||||
| Verkehrslage (innerorts) | 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 Dokumentation der Datenarchitekturdefinitionen wird im Repository abgelegt.
