IVS-Referenzarchitektur Verkehrsinformation Individualverkehr 1.0: Unterschied zwischen den Versionen

Aus IVS-Wiki
Zur Navigation springen Zur Suche springen
Zeile 37: Zeile 37:
 
<u>Ergebnis</u>: Link
 
<u>Ergebnis</u>: Link
  
=== Architekturprinzipien ===
+
=== ===
  
Prinzipien stellen Grundsätze dar, die nicht nur dauerhaft gelten, sondern auch selten geändert werden sollten. Sie beschreiben die Art und Weise, wie eine davon betroffene Organisation ihre Aufgaben zu erfüllen hat. Prinzipien können für verschiedene Ebenen entwickelt und definiert werden.
+
----
  
Zur Detaillierung werden IVS-Architekturprinzipien gemäß den Ebenen von IVS-Architektur in folgende Untergruppen aufgeteilt:
+
== Phase Architekturvision ==
  
*Geschäftsprinzip
+
In der TOGAF Phase A – Architekturvision erfolgen gemäß IVS-Rahmenarchitektur der Projektaufbau und der Anstoß einer Iteration des Architekturentwicklungszyklus zusammen mit der Festlegung von Wirkungsbereich, Rahmenbedingungen, Rollen und Erwartungen. Diese Phase ist notwendig, um den Geschäftskontext zu validieren und einen abgestimmten Auftrag für Architekturarbeit zu erstellen.
*Daten-/Informationsprinzip
 
*Anwendungsprinzip
 
*Technologieprinzip
 
  
<u>Ergebnis</u>: Link
+
=== Aufsetzen eines Architekturprojekts ===
 
 
----
 
  
== Phase Architektur Vision ==
+
Zu Beginn eines IVS-Architekturprojekts muss der eigentliche IVS-Betrachtungsgegenstand, für den spezifisches IVS-Architekturwissen entwickelt und zur Anwendung gebracht werden soll, in für alle Beteiligten verständlicher und nachvollziehbarer Weise festgelegt und umrissen werden. Dabei besteht die wesentliche Aufgabe darin,
  
=== Aufsetzen eines Architekturprojekts ===
+
*den IVS-Betrachtungsgegenstand semantisch zu beschreiben (was ist der IVS-Betrachtungsgegenstand) und
 +
*klare Grenzen zu ähnlichen bzw. angrenzenden IVS-Betrachtungsgegenständen zu ziehen und festzulegen (was wird betrachtet, was nicht).
  
Zu Beginn eines IVS-Architekturprojekts für Verkehrsinformation im Individualverkehr muss der eigentliche IVS-Betrachtungsgegenstand, für den spezifisches IVS-Architekturwissen entwickelt und zur Anwendung gebracht werden soll, in für alle Beteiligten verständlich und nachvollziehbar Weise festgelegt und umrissen werden. Dabei besteht die wesentliche Aufgabe darin,
 
  
*den IVS-Betrachtungsgegenstand "Verkehrsinformation im Individualverkehr" semantisch zu beschreiben (was <u>ist</u> der IVS-Betrachtungsgegenstand <u>Verkehrsinformation im Individualverkehr</u>) und
 
*klare Grenzen zu ähnlichen bzw. angrenzenden IVS-Betrachtungsgegenständen der Verkehrsinformation im Individualverkehr zu ziehen und festzulegen ('''was ist drin, was ist nicht drin''').
 
  
 
In Abhängigkeit davon, ob eine generische IVS-Referenzarchitektur für eine IVS-Dienstekategorie der Verkehrsinformation im Individualverkehr oder eine IVS-Architektur für einen realen IVS-Dienst der Verkehrsinformation im Individualverkehr entwickelt werden soll, kann der IVS-Betrachtungsgegenstand gröber oder muss detaillierter beschrieben und abgegrenzt werden:
 
In Abhängigkeit davon, ob eine generische IVS-Referenzarchitektur für eine IVS-Dienstekategorie der Verkehrsinformation im Individualverkehr oder eine IVS-Architektur für einen realen IVS-Dienst der Verkehrsinformation im Individualverkehr entwickelt werden soll, kann der IVS-Betrachtungsgegenstand gröber oder muss detaillierter beschrieben und abgegrenzt werden:
  
*Eine IVS-Referenzarchitektur soll verschiedene Gestaltungskonzepte für eine IVS-Dienstekategorie vorweisen.
+
*IVS-Referenzarchitektur: Gestaltungskonzepte für eine IVS-Dienstekategorie  
*Bei der IVS-Architektur eines realen IVS-Dienstes müssen verschiedene Implementierungskonzepte für einen spezifischen IVS-Dienst erstellt werden.  
+
*IVS-Architektur eines realen IVS-Dienstes: Implementierungskonzepte für einen spezifischen IVS-Dienst  
 +
 
 +
Für das Aufsetzen des Architekturprojekts&nbsp;wurde das Artefakt IVS-Domäne&nbsp;der IVS Rahmenarchitektur verwendet.
  
 
<u>Ergebnisse:</u>
 
<u>Ergebnisse:</u>
Zeile 70: Zeile 65:
 
Links
 
Links
  
=== Erfassen und Beschreibung von IVS-Rollen ===
+
=== Identifizierung der IVS-Rollen mit deren Anliegen und&nbsp;Geschäftsanforderungen ===
 
 
Für die Entwicklung einer IVS-Referenzarchitektur oder der IVS-Architektur eines realen IVS-Dienstes&nbsp;müssen in diesem Schritt die IVS-Rollen&nbsp;in die IVS-Wertschöpfung zu involvierenden IVS-Akteure und die zu beteiligenden IVS-Stakeholder erfasst und beschrieben werden.
 
 
 
Dazu ist es nützlich - in Vorbereitung für den Schritt Entwicklung einer IVS-Architekturvision - eine erste Vorstellung für den IVS-Dienst/die IVS-Dienstekategorie zugrunde zu legen und darüber die erforderlichen IVS-Rollen in der IVS-Wertschöpfungskette/im IVS-Wertschöpfungsnetzwerk zu veranschaulichen.
 
  
Zur Ergebnisdarstellung werden zwei IVS-Bausteine verwendet:
+
Für die Identifizierung der IVS-Rollen mit deren Anliegen und Geschäftsanforderungen werden die Artefakte
  
*Der Baustein IVS-Rollen-Map, mit dem Stereotype&nbsp;von IVS-Akteuren und IVS-Stakeholdern deklariert, mit ihren Geschäftsanliegen und IVS-Rollen beschrieben und die Bedeutung von IVS-Akteuren und IVS-Stakeholdern gemäß "Power-Grid" klassifiziert werden.
+
*IVS-Rollen-Map und  
 +
*der Katalog IVS-Rollen  
  
*Der Baustein IVS-Rolle, mit dem Stereotype&nbsp;von IVS-Fähigkeiten und IVS-Verantwortlichkeiten, die für die Bereitstellung und den Betrieb von IVS-Diensten typisch und erforderlich sind, bezeichnet und semantisch beschrieben werden.  
+
der IVS-Rahmenarchitektur verwendet. Weiterhin wird eine Übersichtsgraphik über die technischen Rollen vorangestellt.
  
 
<u>Ergebnisse:</u>
 
<u>Ergebnisse:</u>

Version vom 13. März 2018, 18:44 Uhr

Inhaltsverzeichnis

Einleitung

Die im Ergebnis des Forschungsprojektes entstandene IVS-Referenzarchitektur konkretisiert das von der nationalen IVS-Rahmenarchitektur vorgegebene Rahmenwerk zur Entwicklung von IVS-Architekturen für die IVS-Dienstekategorie Verkehrsinformation im Individualverkehr.

Gegenstand der IVS-Referenzarchitektur für Verkehrsinformation im Individualverkehr sind alle auf Straßenverkehrsteilnehmer unmittelbar wirkenden On-Trip Verkehrsinformationen, unabhängig vom Kommunikationsmedium. Dies umfasst z.B. über Funkkommunikation (Rundfunk, WLAN, Mobilfunk, etc.) in Endgeräte der Verkehrsteilnehmer übertragene Informationen inkl. C2X sowie Informationen auf dynamischer Beschilderung.

Als Vorgehensmodell zur Erarbeitung der IVS-Referenzarchitektur wurde gemäß IVS-Rahmenarchitektur das TOGAF-The Open Group Architecture Framework angewendet. Folgende Schritte wurden dabei durchlaufen:

  1. Vorbereitungsphase
  2. TOGAF A: Architekturvision
  3. TOGAF B: Geschäftsarchitektur
  4. TOGAF C: Informationssystemarchitektur bestehend aus Datenarchitektur und Anwendungsarchitektur


Vorbereitungsphase

Expertenbefragung im Rahmen der Bestands- und Anforderungsanalyse

Zu Beginn des Projekts wurde eine Bestands- und Anforderungsanalyse durchgeführt, um einerseits die Domäne der Architekturarbeit genauer einzugrenzen und andererseits, bereits in einer frühen Projektphase, die Ausprägung von Architekturelementen zu erfassen, deren Kenntnis für die Definition und Beschreibung einer Referenzarchitektur essentiell sind. Zur Bestandsanalyse wurden bestehende Systeme, Anwendungen, Standards, Normen, Komponenten und Architekturen untersucht und eingeordnet. Dazu wurde in großem Umfang externes Fachwissen einbezogen, indem Stakeholder von öffentlichen Institutionen und privaten Wirtschaftsunternehmen anhand speziell entwickelter Fragebögen befragt und darüber hinaus Erkenntnisse aus aktuellen thematisch entsprechenden Forschungsprojekten einbezogen wurden, in denen Bestandsaufnahmen real existierender Systeme durchgeführt wurden, die zu eigenen Architekturentwürfen geführt haben. Zur der Bestandsanalyse gehörte auch die Untersuchung des aktuellen Stands und der Relevanz von Standards aus dem Verkehrsbereich, aus dem IT-Bereich insbesondere der Webtechnologien sowie Bereich des Geodatenmanagements.

Einen breiten Raum nahm die Zusammenarbeit mit dem Anwenderkreis „Intelligente Verkehrssysteme“ der OCA e.V. Open Traffic City Association als ein im Jahre 1999 gegründeter Verband öffentlicher Baulastträger und Betreiber in der Straßenverkehrstechnik, der die Belange aller öffentlichen Verwaltungen bei der Entwicklung offener Standards für Lichtsignalanlagen, Verkehrsrechner und Verkehrsleitzentralen nachhaltig vertritt. In regelmäßig durchgeführten Treffen mit den Mitgliedern des Anwenderkreises aus den Städten Hamburg, Frankfurt, Stuttgart, Kassel und München wurden die vom Konsortium erarbeiteten Zwischenergebnisse einer ausführlichen Bewertung und Diskussion unterzogen, die zu einer wertvollen weiteren Qualifikation der Bearbeitungsresultate geführt hat.

IVS-Glossar

Das IVS-Glossar ist ein IVS-Architekturdeliverable, mit dem die "Grundlage für gemeinsames Verstehen" in einem IVS-Architekturprojekt gelegt wird und welches folgende Bestandteile hat:

  • "Begriffsbestimmungen für IVS-Architektur", über die ein allgemeines Verständnis von IVS-Architektur hergestellt werden soll und
  • "Allgemeine Begriffe aus Verkehr, Transport und Mobilität", die keine spezifische IVS-Architektur-Semantik repräsentieren.

Für das Glossar für Verkehrsinformation im Individualverkehr gilt:

Ergebnis: Link


Phase Architekturvision

In der TOGAF Phase A – Architekturvision erfolgen gemäß IVS-Rahmenarchitektur der Projektaufbau und der Anstoß einer Iteration des Architekturentwicklungszyklus zusammen mit der Festlegung von Wirkungsbereich, Rahmenbedingungen, Rollen und Erwartungen. Diese Phase ist notwendig, um den Geschäftskontext zu validieren und einen abgestimmten Auftrag für Architekturarbeit zu erstellen.

Aufsetzen eines Architekturprojekts

Zu Beginn eines IVS-Architekturprojekts muss der eigentliche IVS-Betrachtungsgegenstand, für den spezifisches IVS-Architekturwissen entwickelt und zur Anwendung gebracht werden soll, in für alle Beteiligten verständlicher und nachvollziehbarer Weise festgelegt und umrissen werden. Dabei besteht die wesentliche Aufgabe darin,

  • den IVS-Betrachtungsgegenstand semantisch zu beschreiben (was ist der IVS-Betrachtungsgegenstand) und
  • klare Grenzen zu ähnlichen bzw. angrenzenden IVS-Betrachtungsgegenständen zu ziehen und festzulegen (was wird betrachtet, was nicht).


In Abhängigkeit davon, ob eine generische IVS-Referenzarchitektur für eine IVS-Dienstekategorie der Verkehrsinformation im Individualverkehr oder eine IVS-Architektur für einen realen IVS-Dienst der Verkehrsinformation im Individualverkehr entwickelt werden soll, kann der IVS-Betrachtungsgegenstand gröber oder muss detaillierter beschrieben und abgegrenzt werden:

  • IVS-Referenzarchitektur: Gestaltungskonzepte für eine IVS-Dienstekategorie
  • IVS-Architektur eines realen IVS-Dienstes: Implementierungskonzepte für einen spezifischen IVS-Dienst

Für das Aufsetzen des Architekturprojekts wurde das Artefakt IVS-Domäne der IVS Rahmenarchitektur verwendet.

Ergebnisse:

Links

Identifizierung der IVS-Rollen mit deren Anliegen und Geschäftsanforderungen

Für die Identifizierung der IVS-Rollen mit deren Anliegen und Geschäftsanforderungen werden die Artefakte

  • IVS-Rollen-Map und
  • der Katalog IVS-Rollen

der IVS-Rahmenarchitektur verwendet. Weiterhin wird eine Übersichtsgraphik über die technischen Rollen vorangestellt.

Ergebnisse:

Links

IVS-Leitbilder

Text

Ergebnis: Link

IVS-Geschäftsziele

Text

Ergebnis: Link

IVS-Capabilities

Im Sinne von IVS repräsentiert IVS-Capability einen Satz von Fähigkeiten, die ein IVS-Akteur als Bestandteil einer IVS-Prozesskette (IVS-Wertschöpfungskette/IVS-Wertschöpfungsnetzwerk) mitbringen muss, damit am Ende der potentielle Nutzen des IVS-Dienstes verwirklicht werden kann.

Dabei werden Anforderungen der End-Nutzer an den Nutzen von IVS-Diensten immer umfangreicher und komplexer. Daraus resultiert, dass die meisten IVS-Dienste nur über Kooperation, d.h. die Vernetzung und das Zusammenwirken verschiedener IVS-Akteure mit ganz spezifischen Fähigkeiten und Nutzenbeiträgen entstehen können. Alle Lösungen im Bereich von IVS, d.h. technische Produkte oder Dienstangebote etc., müssen dem Anspruch genügen, dass sie auch als Bestandteil einer Wertschöpfungskette bzw. eines Wertschöpfungsnetzwerks darstellbar sind.

Text

Vor diesem Hintergrund muss sich jeder einzelne IVS-Akteur, der sich an einer IVS-Wertschöpfungskette/einem IVS-Wertschöpfungsnetzwerk beteiligen will, die Frage stellen:

  • über welche Capabilities (Fähigkeiten) er verfügen oder welche er noch entwickeln muss, damit eine erfolgreiche Kooperation und Wertschöpfung zustande kommen kann und
  • welche Capability-Dimensionen die Entwicklung der Capabilities auf Menschen, Organisation, Prozesse und Technologien seiner Institution/seines Unternehmens haben werden.

Ergebnis: Link

IVS-Architektur Vision

Mit dem Schritt der Erstellung der IVS-Architekturvision sollen im Hinblick auf das Geschäftsmodell sowie der erforderlichen Informationssysteme und Technologien die ersten, high-level Ausstattungsmerkmale für den IVS-Dienst festgelegt werden. In dieser Phase kommt es vor allem darauf an, sich auf wesentliche Grundsätze und Prinzipien, die sich eher selten ändern, zu fokussieren.

Insofern sind die wesentlichen inhaltlichen Bestandteile einer IVS-Architektur-Vision:

  • Die Idee (für den IVS-Dienst),
die die Kernaufgabe, die Nutzung und die Schnittstellen, das heißt den Kontext des zu erstellenden IVS-Dienstes aufzeigt.
  • Einflussfaktoren und Randbedingungen
wie funktionale und nicht-funktionale Anforderungen, organisatorische und technische Einflüsse.
  • Lösungsstrategien
halten die ersten Entscheidungen, wesentliche Architektur-Muster und Konzepte fest. Erste Architektursichten können entstehen, um die Lösungsstrategien zu verdeutlichen.

Ergebnis: Link

Wertbeitrag und KPI's von IVS-Architektur

Um einen IVS-Dienst im Bereich der "Verkehrsinformation im Individualverkehr" realisieren zu können, ... Somit hängt die Interoperabilität von IVS-Akteuren eines IVS-Dienstes im Bereich der "Verkehrsinformation im Individualverkehr" im Wesentlichen davon ab, wie nahtlos diese zusammenarbeiten bzw. wie interoperabel diese ihre IVS-Geschäftsfähigkeiten gestalten können. Interoperabilität wird somit in den Mittelpunkt der architekturellen Bemühungen gestellt und die Bereitstellung von Interoperabilitäts-Bausteinen zum Kernziel von IVS-Architektur.

Ergebnis: Link

Risiken der Einführung einer IVS-Referenzarchitektur für Verkehrsinformation im Individualverkehr

Die Einführung einer IVS-Architektur birgt auch Risiken. Das Risikomanagement soll genutzt wer-den, um die Risiken Einführung einer IVS-Referenzarchitektur für Verkehrsinformation im Individualverkehr zu erkennen, zu beurteilen und handzuhaben.

Ergebnis: Link


Ergebnisse Geschäftsarchitektur

Hilfsmittel, Sichten und Werkzeuge für IVS-Geschäftsarchitektur

Für die Beschreibung und Visualisierung der IVS-Geschäftsarchitektur macht die IVS-Rahmenarchitektur keinerlei formatgebundene Vorgaben. In Abhängigkeit des fachlichen Hintergrunds und der an der Architekturarbeit Beteiligten eignet sich jede Art von:

  • Textlichen Beschreibungen (z. B. erstellt mit MS-Word ...)
  • Tabellen (z. B. erstellt mit MS-Excel ...)
  • Grafiken (z. B. erstellt mit MS-PowerPoint oder MS-Visio ...)
  • Artefakten, die mit Hilfe spezieller Tools erstellt werden (IBM-Rational System Architect, Enterprise Architect ...)

Dennoch gibt es bereits bewährte Beschreibungs- und Visualisierungsmuster, die von der IVS-Rahmenarchitektur empfohlen werden:

  • für die Sicht "IVS-Wertschöpfungskette/IVS-Wertschöpfungsnetzwerk"
  • für die Sicht "IVS-Governance"
Für die Darstellung wird ein Textdokument empfohlen. Eine Beschreibungsstruktur findet sich hier.
  • für die Sicht "IVS-Geschäftsprozesse"
für die Darstellung und Visualisierung der IVS-Geschäftsprozessarchitektur wird grundsätzlich ein Prozessmodellierungs-Ansatz gewählt. Durch das Aufschlüsseln von Geschäftsfunktionen und Geschäftsdiensten mit Hilfe der Prozessmodellierung wird die Identifizierung der Schlüssel-Prozesse und der nachgeordneten Dienste und Funktionen ermöglicht.
  • Ein Template zur Beschreibung von Geschäftsprozessen findet sich hier.
  • Zur Modellierung von Geschäftsprozessen und Geschäftsfunktionen wird die Spezifikationssprache Business Process Model and Notation (BPMN) verwendet. Eine Anleitung findet sich hier.

Ergebnis: Link

Ausgangssituation der IVS-Geschäftsarchitektur

Da es bei der Beschreibung einer IVS-Referenzarchitektur oft nicht möglich ist den Ausgangszustand zu beschreiben, wird stattdessen eine Bestandsaufnahme der aktuellen Situation mit Schwerpunkt auf der Identifikation und Beschreibung von Sachverhalten, die eine Umsetzung der IVS-Geschäftsarchitekturvision behindern, vorgeschlagen.

  • Sicht "IVS-Wertschöpfungsketten und -netzwerke"
Die IVS-Rollenmatrix, in der bestehende Kommunikationswege eingezeichnet sind, ist ein geeignetes Instrument, um Aspekte der Zusammenarbeit im Rahmen von bestehenden IVS-Wertschöpfungsketten/-netzwerken zu identifizieren, die eine sinnvolle Umsetzung der Vision von einer IVS-Geschäftsarchitektur behindern.
  • Sicht "IVS-Governance"
Fehlende Governance bzw. fehlende oder hinderliche Teilelemente einer funktionierenden Governance sind sehr häufig die Ursache für das Nicht-Erreichen der IVS-Geschäftsarchitekturvision. So können z. B. (gesetzliche) Regelungen, die eine Einführung bzw. Umsetzung von IVS-Diensten be- oder verhindern.
  • Sicht "IVS-Geschäftsprozesse"
IVS-Wertschöpfungsketten/-netzwerke, die auf der Geschäftsprozessebene auf Grund fehlender Kern- oder Supportprozesse nicht in der erforderlichen Qualität operationalisiert werden können, sind häufig die Ursache für eine fehlende Umsetzbarkeit der IVS-Geschäftsarchitekturvision.

Ergebnisse:

Links

Zielsituation der IVS-Geschäftsarchitektur

Die Beschreibung der Ziel-IVS-Geschäftsarchitektur erfolgt über den Aufbau von Sichten auf die Zusammenarbeit der IVS-Akteure, die einen IVS-Dienst als "Geschäft" betreiben. "Sichten auf geschäftliche Aspekte eines IVS-Dienstes" dienen der Strukturierung und Darstellung/Beschreibung der Zusammenarbeitsbeziehungen von IVS-Akteuren:

Identifizierung, Darstellung und Beschreibung, über welche Bestandteile (Teildienste) der IVS-Dienst gebildet wird, welche IVS-Rollen daran beteiligt sein müssen und welche Anforderungen (IVS-Capabilities) an diese gestellt werden.
Beschreibung, auf welcher gesetzlichen, rechtlichen und vertraglichen Grundlage der IVS-Dienst und die Zusammenarbeit der IVS-Akteure zustande kommen und wie letztere operativ geführt und gesteuert wird.
Darstellung und Beschreibung, über welche Schlüssel-Geschäftsprozesse der IVS-Dienst operationalisiert wird.

Weitere Sichten können projektspezifisch aufgebaut und beschrieben werden.

Ergebnisse:

Links

Gap-Analyse für die IVS-Geschäftsarchitektur

Über eine Gap-Analyse werden die Unterschiede zwischen der bestehenden und der gewünschten IVS-Geschäftsarchitektur herausgearbeitet.

Die IVS-Rahmenarchitektur macht für die Gap-Analyse keine formatgebundenen Vorgaben. Es empfiehlt sich allerdings diejenigen Darstellungsmittel zu verwenden, die für die Beschreibung der Ausgangssituation der IVS-Geschäftsarchitektur und der Ziel-IVS-Geschäftsarchitektur verwendet wurden.

Ergebnisse der Gap-Analyse sind mögliche IVS-Geschäftsarchitekturkandidaten, die im nächsten Schritt der Phase B (siehe Schritt 5) unter dem Abschnitt "IVS-Geschäftsarchitektur" in die IVS-Architektur-Roadmap Eingang finden.

Ergebnisse:

  • Links

IVS-Geschäftsarchitekturkandidaten für die IVS-Architektur-Roadmap

Aus der Gap-Analyse resultieren IVS-Geschäftsarchitekturbausteine, die als IVS-Geschäftsarchitektur-Kandidaten für die IVS-Architektur-Roadmap aufgefasst und deklariert werden können und deren Umsetzungsarbeitsschritte über die IVS-Architektur-Roadmap beschrieben und geplant werden können.

Zur Beschreibung der einzelnen Arbeitsschritte sowie zur Festlegung von zeitlichen und inhaltlichen Abhängigkeiten zwischen den einzelnen Arbeitsschritten wird der Katalog Architektur-Roadmap verwendet.

Ergebnis: Link


Ergebnisse IVS-Datenarchitektur

Hilfsmittel, Sichten und Werkzeuge für IVS-Datenarchitektur

In der Datenarchitektur werden die Daten zusammen mit ihren Beziehungen, die für die Durchführung der Geschäftsprozesse benötigt werden, identifiziert und beschrieben. Dies erfolgt in einem Modell und einer Darstellungsform, die stabil, vollständig, konsistent und für alle Beteiligten verständlich ist.

Bei der Festlegung auf Hilfsmittel und Werkzeuge muss beachtet werden, dass derzeit viele unterschiedliche, domänenspezifische IVS-Datenmodelle existieren, und daher eine Vereinheitlichung nur schwer zu erreichen ist. Somit werden seitens der IVS-Rahmenarchitektur keine konkreten Vorgaben getätigt. Für die Festlegung von Hilfsmitteln und Werkzeugen der IVS-Datenarchitektur im Rahmen der Verkehrsinformation im Individualverkehr wird eine projektspezifische Lösung entwickelt und auf die bereits verwendete Modelle und Darstellungsformen zurückgegriffen.

Ergebnis: Link

Ausgangssituation der IVS-Datenarchitektur

Da es bei der Beschreibung einer IVS-Referenzarchitektur oft nicht möglich ist den Ausgangszustand zu beschreiben, wird eine Bestandsaufnahme der aktuellen Situation in der Verkehrsinformation im Individualverkehr mit Schwerpunkt auf der Identifikation und Beschreibung von Sachverhalten, die eine Einführung der Architektur behindern, durchgeführt. Ziel der Beschreibung der Ausgangssituation der Datenarchitektur ist es, diese Sachverhalte zu benennen und so detailliert zu beschreiben, sodass die gewünschten Änderungen in späteren Schritten geplant werden können.

Ergebnisse - Kataloge:

  • Links

Ergebnisse - Matrizen:

  • Links

Zielsituation der IVS-Datenarchitektur

Im Rahmen der Darstellung der Zielsituation der IVS-Datenarchitektur im Bereich der Verkehrsinformation im Individualverkehr wird ein Katalog von zukünftig notwendigen IVS-Informationsobjekten, IVS-Datenmodellen und IVS-Ortsreferenzierungssystemen erstellt. Dazu kann aus dem Katalog der zukünftig benötigten Geschäftsprozesse im Bereich der Verkehrsinformation im Individualverkehr jeweils ermittelt werden, welcher Input bzw. Output, welche Datenmodelle bzw. welche  Ortsreferenzierungssysteme zur Umsetzung dieser Geschäftsprozesse benötigt werden.

Basierend auf diesen Katalogen können dann Matrizen, die die Zuordnung zwischen den IVS-Informationsobjekten und IVS-Datenmodellen bzw. IVS-Datenmodellen und IVS-Ortsreferenzierungssystemen beschreiben, erstellt werden.

Ergebnisse - Kataloge:

  • Links

Ergebnisse - Matrizen:

  • Links

Gap-Analyse für die IVS-Datenarchitektur

Ziel der Gap-Analyse der Datenarchitektur ist es, die Änderungen an den IVS-Informationsobjekten, den IVS-Datenmodellen und den IVS-Ortsreferenzierungssystemen herauszuarbeiten, die für die Umsetzung der IVS-Ziel-Datenarchitektur benötigt werden.

Ergebnisse:

  • Links

IVS-Datenarchitekturkandidaten für die IVS-Architektur-Roadmap

Aus der Gap-Analyse resultieren IVS-Informationsobjekte, IVS-Datenmodelle und IVS-Ortsreferenzierungssysteme, die als IVS-Datenarchitekturkandidaten für die IVS-Architektur-Roadmap deklariert werden können und deren Umsetzungsarbeitsschritte über die Roadmap beschrieben sowie geplant werden können.

Ergebnis: Link


Ergebnisse IVS-Anwendungsarchitektur

Hilfsmittel, Sichten und Werkzeuge für IVS-Anwendungsarchitektur

Die IVS-Anwendungsarchitektur fokussiert IVS-Anwendungen und deren IVS-Schnittstellen, die im Bereich der Verkehrsinformation im Individualverkehr für IVS-Geschäftsprozesse erforderlich sind.

  • IVS-Anwendungen sind Computeranwendungen oder IT-Services, die genutzt werden, um Anwendungsfunktionen zu automatisieren bzw. computergestützt umzusetzen. Die technischen Aktivitäten eines IVS-Geschäftsprozesses werden in IVS-Anwendungen realisiert.
  • Über IVS-Schnittstellen kommunizieren IVS-Anwendungen. IVS-Schnittstellen beinhalten das mit Hilfe der IVS-Datenmodelle kodierten IVS-Informationsobjekt und das Schnittstellenprotokoll zum Datenaustausch.

Für die Darstellung der Anwendungsarchitektur im Bereich der Verkehrsinformation im Individualverkehr schlägt die IVS-Rahmenarchitektur folgende Modellierungsprinzipien bzw. -werkzeuge vor:

  • Verwendung von Standards als IVS-Schnittstellen
  • Verwendung einer serviceorientierten Architektur (SOA)
  • Modellierung mittels Komponentendiagramme in UML

Ergebnis: Link

Ausgangssituation der IVS-Anwendungsarchitektur

Da es bei der Beschreibung einer IVS-Referenzarchitektur oft nicht möglich ist den Ausgangszustand zu beschreiben, wird eine Bestandsaufnahme der aktuellen Situation im Bereich der Verkehrsinformation im Individualverkehr mit Schwerpunkt auf der Identifikation und Beschreibung von Sachverhalten, die eine Einführung der Architektur behindern, durchgeführt. Ziel der Beschreibung der Ausgangssituation der Anwendungsarchitektur ist es, diese Sachverhalte zu benennen und so detailliert zu beschreiben, sodass die gewünschten Änderungen in späteren Schritten geplant werden können.

Ergebnis: Link

Zielsituation der IVS-Anwendungsarchitektur

Im Rahmen der Darstellung der Zielsituation der IVS-Anwendungsarchitektur im Bereich der Verkehrsinformation im Individualverkehr wird ein Katalog von zukünftig notwendigen IVS-Anwendungen und IVS-Schnittstellen erstellt. Dazu kann im Bereich der Verkehrsinformation im Individualverkehr auf den von Los 1 bereitgestellten Katalogen aufgebaut und weitere notwendige IVS-Anwendungen und IVS-Schnittstellen ergänzt werden.

Basierend auf diesen Katalogen kann dann eine Matrix, die die Zuordnung zwischen den IVS-Anwendungen und IVS-Schnittstellen beschreibt, erstellt werden.

Ergebnis: Link

Gap-Analyse für die IVS-Anwendungsarchitektur

Ziel der Gap-Analyse der Anwendungsarchitektur ist es, die Änderungen an den IVS-Anwendungen sowie IVS-Schnittstellen herauszuarbeiten, die für die Umsetzung der IVS-Ziel-Anwendungsarchitektur benötigt werden.

Ergebnis: Link

IVS-Anwendungsarchitekturkandidaten für die IVS-Architektur-Roadmap

Aus der Gap-Analyse resultieren IVS-Anwendungen und IVS-Schnittstellen, die als IVS-Anwendungsarchitekturkandidaten für die IVS-Architektur-Roadmap deklariert werden können und deren Umsetzungsarbeitsschritte über die Roadmap beschrieben sowie geplant werden können.

Ergebnis: Link


Ergebnisse IVS-Technologiearchitektur

Der Fokus im vorliegenden Projekt liegt auf den TOGAF Architekturebenen B und C (Geschäfts-, Daten- und Anwendungsarchitektur). Deswegen wird auf Technologiearchitektur der IVS-Referenzarchitektur für Verkehrsinformation im Individualverkehr hier nicht näher eingegangen.

Literaturverzeichnis


<< Zurück zur Hauptseite

  1. Kieslich, Wolfgang; Albrecht, Hanfried; Dinkel, Alexander u.a. (2014): Entwicklung einer für ÖV-IVS-Architektur in Deutschland unter Einbindung Europäischer IVS-Richtlinien mit ÖPNV-Relevanz. Schlussbericht. Im Auftrag des Bundesministeriums für Verkehr und digitale Infrastruktur. München.