IVS-Wiki - Benutzerbeiträge [de]

Kap. 11 Entwicklung von Unternehmensarchitekturplänen

2016-06-20T09:53:50Z

Weber: /* Entwicklung von Unternehmensarchitekturplänen und Aufträgen für die Architekturarbeit, Sichern der Zustimmung */

== Entwicklung von Unternehmensarchitekturplänen und Aufträgen für die Architekturarbeit, Sichern der Zustimmung ==

Grundlage für das Kapitel 11 bildet das Angebot von Los 4 (Ressourcenplanung, Liefergegenstände, Umfang etc.). Die Vertiefung hierzu findet noch in den weiteren Meetings mit Los 1 (TOGAF Workshop) bzw. dem Auftraggeber nach dem Meilenstein 1 statt.

''Diese Punkte werden im geplanten TOGAF-Workshop im Juni 2016 zum aktuellen Stand besprochen.''

Kap. 10 Risiken einer Geschäftstransformation

2016-06-20T09:52:56Z

Weber: /* Identifizierung der Risiken einer Geschäftstransformation und der Aktivitäten zur Risikominimierung */

== Identifizierung der Risiken einer Geschäftstransformation und der Aktivitäten zur Risikominimierung ==

Im Folgenden beschreibt die Risikomatrix die Risikoquellen, welche anhand einer Bewertung klassifiziert werden:

[[Datei:Risikomatrix_Konsortium MRK-AMADEUS.JPG|500px|]]

'''Matrix 4''': Risikokategorie, Quelle und Bewertung für die IVS-Referenzarchitektur

Für Risiken mit einer Risikokennzahl von über 15 wird das Konsortium folgende Gegenmaßnahmen treffen:

* '''Geringe Beachtung Datenschutz/Nationale Vorgaben (Nr. 4 & 14):'''
** Verstärkter Fokus bei der Ausarbeitung der Referenzarchitektur auf das Thema Datenschutz im Hinblick auf technische und juristische Belange
** Beachtung der deutschen Datenschutzvorgaben in den Ausführungen zur Architektur
* '''Fehlende Umsetzung auf Arbeitsebene (Nr. 6):'''
** Verständliche Beschreibung der Referenzarchitektur
** Verbesserung der Akzeptanz mit den umsetzenden Stellen, z.B. auf den öffentlichkeitswirksamen Terminen mit dem AG
** Ausrichtung des Migrationsplans im Hinblick auf die umsetzenden Räume/zuständigen Stellen
* '''Umgehen der IVS-Referenzarchitektur durch Lieferanten (Nr. 16):'''
** Herausarbeiten des Nutzen der Architektur für die Lieferanten
** Implementierung der Ergebnisse der Architektur in die zukünftige Förder- und Vergabelandschaft in Deutschland
* '''Finanzierung der Architekturüberwachung (Nr. 20):'''
** Sensibilisierung des Auftraggebers bzw. des BMVI für den Bedarf der Bereitstellung von Betriebsmitteln
** Aufzeigen des Nutzens und der Finanzierungsspielräume in der Migrationsplanung

Kap. 10 Risiken einer Geschäftstransformation

2016-06-20T09:51:52Z

Weber: /* Identifizierung der Risiken einer Geschäftstransformation und der Aktivitäten zur Risikominimierung */

== Identifizierung der Risiken einer Geschäftstransformation und der Aktivitäten zur Risikominimierung ==

Im Folgenden beschreibt die Risikomatrix die Risikoquellen, welche anhand einer Bewertung klassifiziert werden:

[[Datei:Risikomatrix_Konsortium MRK-AMADEUS.JPG|500px|]]

'''Matrix 4''': Risikokategorie, Quelle und Bewertung für die IVS-Referenzarchitektur

Für Risiken mit einer Risikokennzahl von über 15 wird das Konsortium folgende Gegenmaßnahmen treffen:

* '''Geringe Beachtung Datenschutz/Nationale Vorgaben (Nr. 4 & 14):'''
** Verstärkter Fokus bei der Ausarbeitung der Referenzarchitektur auf das Thema Datenschutz im Hinblick auf technische und juristische Belange
** Beachtung der deutschen Datenschutzvorgaben in den Ausführungen zur Architektur
* '''Fehlende Umsetzung auf Arbeitsebene (Nr. 6):'''
** Verständliche Beschreibung der Referenzarchitektur
** Verbesserung der Akzeptanz mit den umsetzenden Stellen, z.B. auf den öffentlichkeitswirksamen Terminen mit dem AG
** Ausrichtung des Migrationsplans im Hinblick auf die umsetzenden Räume/zuständigen Stellen
* '''Umgehen IVS-Referenzarchitektur durch Lieferanten (Nr. 16):'''
** Herausarbeiten des Nutzen der Architektur für die Lieferanten
** Implementierung der Ergebnisse der Architektur in die zukünftige Förder- und Vergabelandschaft in Deutschland
* '''Finanzierung der Architekturüberwachung (Nr. 20):'''
** Sensibilisierung des Auftraggebers bzw. des BMVI für den Bedarf der Bereitstellung von Betriebsmitteln
** Aufzeigen des Nutzens und der Finanzierungsspielräume in der Migrationsplanung

Kap. 10 Risiken einer Geschäftstransformation

2016-06-20T09:50:15Z

Weber: /* Identifizierung der Risiken einer Geschäftstransformation und der Aktivitäten zur Risikominimierung */

== Identifizierung der Risiken einer Geschäftstransformation und der Aktivitäten zur Risikominimierung ==

Im Folgenden beschreibt die Risikomatrix die Risikoquellen, welche anhand einer Bewertung klassifiziert werden:

[[Datei:Risikomatrix_Konsortium MRK-AMADEUS.JPG|500px|]]

'''Matrix 4''': Risikokategorie, Quelle und Bewertung für die IVS-Referenzarchitektur

Für Risiken mit einer Risikokennzahl von über 15 wird das Konsortium folgende Gegenmaßnahmen treffen:

* '''Geringe Beachtung Datenschutz/Nationale Vorgaben (Nr. 4 & 14):'''
** Verstärkter Fokus bei der Ausarbeitung der Referenzarchitektur auf das Thema Datenschutz im Hinblick auf technische und juristische Belange
** Beachtung der deutschen Datenschutzvorgaben in den Ausführungen zur Architektur
* '''Fehlende Umsetzung auf Arbeitsebene (Nr. 6):'''
** Verständliche Beschreibung der Referenzarchitektur
** Verbesserung der Akzeptanz mit den umsetzenden Stellen, z.B. auf den öffentlichkeitswirksamen Terminen mit dem AG
** Ausrichtung der Migrationsplan im Hinblick auf die umsetzenden Räume/zuständigen Stellen
* '''Umgehen IVS-Referenzarchitektur durch Lieferanten (Nr. 16):'''
** Herausarbeiten des Nutzen der Architektur für die Lieferanten
** Implementierung der Ergebnisse der Architektur in die zukünftige Förder- und Vergabelandschaft in Deutschland
* '''Finanzierung der Architekturüberwachung (Nr. 20):'''
** Sensibilisierung des Auftraggebers bzw. des BMVI für den Bedarf der Bereitstellung von Betriebsmitteln
** Aufzeigen des Nutzens und der Finanzierungsspielräume in der Migrationsplanung

Kap. 9 Wertbeitrag der Zielarchitektur

2016-06-20T09:40:42Z

Weber: /* Definition des Wertbeitrags der Zielarchitektur und der KPIs */

== Definition des Wertbeitrags der Zielarchitektur und der KPIs ==

Die Wertschöpfungskette für multimodale Verkehrsinformationen ist komplex und wird nur durch eine Kooperation verschiedener Stakeholdergruppen abgedeckt. Hierbei ist derzeit in der Regel keine klare Stakeholdersegmentierung gegeben, denn Stakeholder können verschiedene Rollen entlang der Wertschöpfungskette besetzen.

Stark vereinfacht besteht die Wertschöpfungskette aus den Elementen ''Inhalteanbieter'', ''Dienstbetreiber'', ''Dienstanbieter'' und ''Endnutzer'', etwas detaillierter erbringt ein
* Inhalteanbieter die Wertschöpfungen Datenerfassung, Datenverarbeitung und Datenproviding;
* Dienstbetreiber die Wertschöpfungen Datenempfang, Datenfusion, Diensterzeugung und Dienstproviding;
* Dienstanbieter die Wertschöpfungen Dienstempfang, Dienstvisualisierung und Dienstpräsentation.

Die Stakeholdergruppen „Öffentliche Hand“ und „Verkehrsunternehmen“ treten z.B. in Teilbereichen der Datenerfassung, des Datenprovidings, der Diensterzeugung und des Dienstprovidings, der Dienstvisualisierung und der Dienstpräsentation auf, wie die Beispiele „IV-Verkehrsinformationen“ oder „Fahrgastinformationen“ verdeutlichen. Wertschöpfungsstufen können also einzelnen Stakeholdern nicht eindeutig zugeordnet werden. Auch eine Trennung zwischen Individualverkehr und öffentlichem Verkehr ist nicht zielführend. Die Automobilindustrie, die dem Bereich „Individualverkehr“ zuzuordnen ist, bietet z.B. mit ihren Partnern aus der Zuliefererindustrie (hier Hersteller von Navigationsgeräten) IV- und ÖV-Verkehrsinformationen auf dem gleichen Endgerät an.

Der Business Case des einzelnen Stakeholders orientiert sich an den Rollen, die dieser Stakeholder in der Wertschöpfungskette einnimmt und ist somit immer individuell und nicht generalisiert beschreibbar.

Der Wertschöpfungsbetrag (value proposition) kann allerdings den o.g. Elementen der Wertschöpfungskette für multimodale Verkehrsinformationen zugeordnet werden, dagegen kaum den Stakeholdergruppen (ein Gerätehersteller, z.B. TomTom, tritt in einer geschlossenen Wertschöpfungskette als Inhalteanbieter, Dienstbetreiber und Dienstanbieter auf). Die Zuordnung des Wertschöpfungsbetrags zu den Wertschöpfungsstufen kann dann allerdings mit den Stakeholdergruppen besprochen werden, um Transparenz und ein gemeinsames Verständnis darüber zu erzeugen, welchen Beitrag ein Stakeholder zu erbringen hat, wie seine Kooperationsrolle technisch, rechtlich und organisatorisch zu gestalten ist, und wie ein typischer Business Case aussehen kann, wenn dieser Stakeholder eine definierte Rolle in der Wertschöpfungskette einnehmen will (TOGAF-Aktivität „review and agree the value propositions with the sponsors and stakeholders concerned“).

Die Beschaffungs- und Lieferbedingungen (procurement requirements) sind ebenfalls den Elementen der Wertschöpfungskette zuordbar, wobei es die typischen Bedingungen für die Privatwirtschaft und für die öffentliche Hand zu beachten gilt.

Das Thema KPIs (TOGAF-Aktivität “define the performance metrics and measures to be built into the enterprise architecture to meet the business needs and assess the business risks”) kann in der jetzigen Projektstufe noch nicht bearbeitet werden und wird noch abgestimmt.

Kap. 9 Wertbeitrag der Zielarchitektur

2016-06-20T09:39:44Z

Weber: /* Definition des Wertbeitrags der Zielarchitektur und der KPIs */

== Definition des Wertbeitrags der Zielarchitektur und der KPIs ==

Die Wertschöpfungskette für multimodale Verkehrsinformationen ist komplex und wird nur durch eine Kooperation verschiedener Stakeholdergruppen abgedeckt. Hierbei ist derzeit in der Regel keine klare Stakeholdersegmentierung gegeben, denn Stakeholder können verschiedene Rollen entlang der Wertschöpfungskette besetzen.

Stark vereinfacht besteht die Wertschöpfungskette aus den Elementen ''Inhalteanbieter'', ''Dienstbetreiber'', ''Dienstanbieter'' und ''Endnutzer'', etwas detaillierter erbringt ein
* Inhalteanbieter die Wertschöpfungen Datenerfassung, Datenverarbeitung und Datenproviding;
* Dienstbetreiber die Wertschöpfungen Datenempfang, Datenfusion, Diensterzeugung und Dienstproviding;
* Dienstanbieter die Wertschöpfungen Dienstempfang, Dienstvisualisierung und Dienstpräsentation.

Die Stakeholdergruppen „Öffentliche Hand“ und „Verkehrsunternehmen“ treten z.B. in Teilbereichen der Datenerfassung, des Datenprovidings, der Diensterzeugung und des Dienstprovidings, der Dienstvisualisierung und der Dienstpräsentation auf, wie die Beispiele „IV-Verkehrsinformationen“ oder „Fahrgastinformationen“ verdeutlichen. Wertschöpfungsstufen können also einzelnen Stakeholdern nicht eindeutig zugeordnet werden. Auch eine Trennung zwischen Individualverkehr und öffentlichem Verkehr ist nicht zielführend. Die Automobilindustrie, die dem Bereich „Individualverkehr“ zuzuordnen ist, bietet z.B. mit ihren Partnern aus der Zuliefererindustrie (hier Hersteller von Navigationsgeräten) IV- und ÖV-Verkehrsinformationen auf dem gleichen Endgerät an.

Der Business Case des einzelnen Stakeholders orientiert sich an den Rollen, die dieser Stakeholder in der Wertschöpfungskette einnimmt und ist somit immer individuell und nicht generalisiert beschreibbar.

Der Wertschöpfungsbetrag (value proposition) kann allerdings den o.g. Elementen der Wertschöpfungskette für multimodale Verkehrsinformationen zugeordnet werden, dagegen kaum den Stakeholdergruppen (ein Gerätehersteller, z.B. TomTom, tritt in einer geschlossenen Wertschöpfungskette als Inhalteanbieter, Dienstbetreiber und Dienstanbieter auf). Die Zuordnung des Wertschöpfungsbetrags zu den Wertschöpfungsstufen kann dann allerdings mit den Stakeholdergruppen besprochen werden, um Transparenz und ein gemeinsames Verständnis darüber zu erzeugen, welchen Beitrag ein Stakeholder zu erbringen hat, wie seine Kooperationsrolle technisch, rechtlich und organisatorisch zu gestalten ist, und wie ein typischer business case aussehen kann, wenn dieser Stakeholder eine definierte Rolle in der Wertschöpfungskette einnehmen will (TOGAF-Aktivität „review and agree the value propositions with the sponsors and stakeholders concerned“).

Die Beschaffungs- und Lieferbedingungen (procurement requirements) sind ebenfalls den Elementen der Wertschöpfungskette zuordbar, wobei es die typischen Bedingungen für die Privatwirtschaft und für die öffentliche Hand zu beachten gilt.

Das Thema KPIs (TOGAF-Aktivität “define the performance metrics and measures to be built into the enterprise architecture to meet the business needs and assess the business risks”) kann in der jetzigen Projektstufe noch nicht bearbeitet werden und wird noch abgestimmt.

Kap. 9 Wertbeitrag der Zielarchitektur

2016-06-20T09:39:15Z

Weber: /* Definition des Wertbeitrags der Zielarchitektur und der KPIs */

== Definition des Wertbeitrags der Zielarchitektur und der KPIs ==

Die Wertschöpfungskette für multimodale Verkehrsinformationen ist komplex und wird nur durch eine Kooperation verschiedener Stakeholdergruppen abgedeckt. Hierbei ist derzeit in der Regel keine klare Stakeholdersegmentierung gegeben, denn Stakeholder können verschiedene Rollen entlang der Wertschöpfungskette besetzen.

Stark vereinfacht besteht die Wertschöpfungskette aus den Elementen ''Inhalteanbieter'', ''Dienstbetreiber'', ''Dienstanbieter'' und ''Endnutzer'', etwas detaillierter erbringt ein
* Inhalteanbieter die Wertschöpfungen Datenerfassung, Datenverarbeitung und Datenproviding;
* Dienstbetreiber die Wertschöpfungen Datenempfang, Datenfusion, Diensterzeugung und Dienstproviding;
* Dienstanbieter die Wertschöpfungen Dienstempfang, Dienstvisualisierung und Dienstpräsentation.

Die Stakeholdergruppen „Öffentliche Hand“ und „Verkehrsunternehmen“ treten z.B. in Teilbereichen der Datenerfassung, des Datenprovidings, der Diensterzeugung und des Dienstprovidings, der Dienstvisualisierung und der Dienstpräsentation auf, wie die Beispiele „IV-Verkehrsinformationen“ oder „Fahrgastinformationen“ verdeutlichen. Wertschöpfungsstufen können also einzelnen Stakeholdern nicht eindeutig zugeordnet werden. Auch eine Trennung zwischen Individualverkehr und öffentlichem Verkehr ist nicht zielführend. Die Automobilindustrie, die dem Bereich „Individualverkehr“ zuzuordnen ist, bietet z.B. mit ihren Partnern aus der Zuliefererindustrie (hier Hersteller von Navigationsgeräten) IV- und ÖV-Verkehrsinformationen auf dem gleichen Endgerät an.

Der business case des einzelnen Stakeholders orientiert sich an den Rollen, die dieser Stakeholder in der Wertschöpfungskette einnimmt und ist somit immer individuell und nicht generalisiert beschreibbar.

Der Wertschöpfungsbetrag (value proposition) kann allerdings den o.g. Elementen der Wertschöpfungskette für multimodale Verkehrsinformationen zugeordnet werden, dagegen kaum den Stakeholdergruppen (ein Gerätehersteller, z.B. TomTom, tritt in einer geschlossenen Wertschöpfungskette als Inhalteanbieter, Dienstbetreiber und Dienstanbieter auf). Die Zuordnung des Wertschöpfungsbetrags zu den Wertschöpfungsstufen kann dann allerdings mit den Stakeholdergruppen besprochen werden, um Transparenz und ein gemeinsames Verständnis darüber zu erzeugen, welchen Beitrag ein Stakeholder zu erbringen hat, wie seine Kooperationsrolle technisch, rechtlich und organisatorisch zu gestalten ist, und wie ein typischer business case aussehen kann, wenn dieser Stakeholder eine definierte Rolle in der Wertschöpfungskette einnehmen will (TOGAF-Aktivität „review and agree the value propositions with the sponsors and stakeholders concerned“).

Die Beschaffungs- und Lieferbedingungen (procurement requirements) sind ebenfalls den Elementen der Wertschöpfungskette zuordbar, wobei es die typischen Bedingungen für die Privatwirtschaft und für die öffentliche Hand zu beachten gilt.

Das Thema KPIs (TOGAF-Aktivität “define the performance metrics and measures to be built into the enterprise architecture to meet the business needs and assess the business risks”) kann in der jetzigen Projektstufe noch nicht bearbeitet werden und wird noch abgestimmt.

Kap. 8 Entwicklung der Architekturvision

2016-06-20T09:32:49Z

Weber: /* Entwicklung der Architekturvision */

== Entwicklung der Architekturvision ==

Aufbauend auf dem Wirkungsbereich für die IVS-Referenzarchitektur „Multimodale Reiseinformation“ können für die Beschreibung der Architekturvision der „Multimodalen Reiseinformation“ (Blauer Bereich in Abbildung 2)

* die maßgebenden Komponenten sowie
* ihre Beiträge zur Zielerreichung einer funktionsfähigen „Multimodalen Reiseinformation“ in Deutschland

identifiziert und beschrieben werden.

[[Datei:Komponenten der IVS-Referenzarchitektur Multimodale Reiseinformation_Konsortium MRK-AMADEUS.JPG|700px|thumb|centre]]

'''Abbildung 2''' Komponenten der IVS-Referenzarchitektur „Multimodale Reiseinformation“

'''API-Datenanbindung'''

Die Komponente (IT-Schicht) „API-Datenanbindung“ schließt über diverse technische Transportprotokolle die Systeme der Inhalteanbieter mit dem Zweck der Zustellung von Daten und Informationen an den für ein definiertes Gebiet zuständigen und neutralen Dienstbetreiber der „Multimodalen Reiseinformation“ (z.B. moveBW in Baden-Württemberg, VAO in Österreich) an. Ein Inhalteanbieter kann auch als Aggregator eigene Datenbestände als Informationen (z.B. Fahrplanauskunft eines Verkehrsverbunds, MDM) an der „API-Datenanbindung“ mit einem gewissen Normierungsstand zur Verfügung stellen. Der Inhalteanbieter bestimmt das Exportformat.

Der Datenzugriff erfolgt nach Absprache wahlweise im Pull- oder auch im Push-Mechanismus, um einen Abgleich des gesamten Datenbestands als Vollupdate oder inkrementelles Update sicherzustellen. Die Akteure stimmen untereinander einen geeigneten Updatezyklus ab.

Im Anschluss an den Datenimport aus den Lieferantensystemen der Inhalteanbieter erfolgt beim Dienstbetreiber die Transformation in ein normiertes, übergreifendes Datenformat, um die Leistungen der verschiedenen Träger miteinander in Beziehung zu bringen.

Von Inhalteanbietern muss an Dienstbetreiber u.a. geliefert werden:
* Fahr-, Reisezeiten,
* Aufenthaltsdauern, Umsteigezeiten,
* Tarife, Aktionsangebote/Klassen,
* Produkte und Produkteigenschaften (u.a. Größe, Strecken, Standorte, Verfügbarkeiten/Anzahl freie Plätze, Incidents vorhersehbar/nicht vorhersehbar).

Es müssen u.a. folgende Inhalteanbieter Daten und Informationen liefern:

Bahnunternehmen, Schienennetzbetreiber, Busunternehmen, Flug, Charter, Fahrradverkehr, Automobilunternehmen, Autoinformationssysteme, Mietwagen, Taxi, Transferservice, Parkhäuser, Fähren, Versicherungen, Kommunen, Länder (Vorzugsnetz für LKW, Baustellen, Sperrungen, …), Wetterdienste, Feuerwehr, Rettungsdienste, Polizei, Straßenämter, Behörden, Umweltämter, Geodatenbanken, ADAC/ADFC-Verkehrsprognosen, Mobil funkunternehmen, Informationsdienste (Google, Yahoo, Bing, …), POI (TomTom, …), Energieunternehmen, Unterkünfte etc.

Dabei ist es unerlässlich, dass die Inhalteanbieter Daten und Informationen kontinuierlich in höchstmöglicher Qualität innerhalb eines Servicestandards an den Dienstbetreiber der „Multimodalen Reiseinformation“ liefern, um eine dauerhafte Akzeptanz bei der Zielgruppe zu sichern. Die Dienstbetreiber sind dafür zuständig, mit ihrer Komponente „Informationslogik“ die vorhandenen Daten und Informationen für die Zielgruppen so aufzubereiten, dass über eine komplette Reisekette einer Zielperson über beliebige Medien hinweg in sich stimmige Informationen über beliebige Dienstanbieter (Informations- und Vertriebsdienste) an die Zielgruppe gebracht werden können.

Im Fall eines Vertriebs (Buchen, Verkaufen) von Produkten und Dienstleistungen der Inhalteanbieter über die „Multimodale Reiseinformation“ muss von der Komponente „API-Datenanbindung“ unabhängig von den angeschlossenen Dienstanbietern (mobility services wie z.B. Reisebüro, e-Ticket eines Verbunds, Autonavigationssystem) die Datenvalidierung zu
* Verkaufsinformationen, Validierung und Verfügbarkeit von Produkten und Dienstleistungen,
* gekauften Produkten und Dienstleistungen im Warenkorb,
* sicheren Bezahlungsmethoden für Nutzer und Leistungserbringer (Inhalteanbieter) und das
* Verkaufsbelegmanagement zwischen Inhalteanbieter und Kunde (Zielgruppe)
unterstützt werden.

Dies erreicht man am besten durch Nutzung von dedizierten Kundenprofilen, die den nationalen und internationalen Datenschutzstandards entsprechen.

'''API-Serviceanbindung'''

Die Komponente „API-Serviceanbindung“ ist die Schnittstelle vom neutralen Dienstbetreiber der „Multimodalen Reiseinformation“ für ein definiertes Gebiet (z.B. moveBW in Baden-Württemberg, VAO in Österreich) zu Dienstanbietern von Informations- und Vertriebskanälen (mobility services).

Die Komponente (IT-Schicht) „API-Serviceanbindung“ stellt den Dienstanbietern von Informations- und Vertriebsdiensten den Zugriff auf Information und Buchung zur Verfügung. Dabei werden verschiedenste, teilweise vom Nutzer individuell parametrisierbare und reiseabhängige Kriterien berücksichtigt, wie die
* Zeit-/Reisedauer,
* anfallende Kosten und Incentives,
* öffentliche Strategien (Umwelt, Verkehrssteuerung usw.),
* Kontext sowie
* Komforteigenschaften.

Weiterhin gibt es Zielgruppen, für die besondere Kriterien dauerhaft Anwendung finden müssen, wie gesundheitliche Aspekte oder firmenrelevante Interessen (Reiserichtlinien).

Bei der Bedienung der Dienstanbieter mit Informationen aus der „Multimodalen Reiseinformation“ muss darauf geachtet werden, dass neben der Reisemöglichkeit bezogen auf den individuellen Reisewunsch der Zielgruppe auch alternative Angebote (Fußgänger, ÖV, IV) dem Dienstanbietern über die „API-Serviceanbindung“ übergeben werden müssen, wenn öffentliche Strategien es verlangen. Die Auswahl der Reiseroute und -modalitäten obliegt aber weiterhin der Zielgruppe (Kunde).

Ein besonderer Mehrwert stellt generell die Übermittlung von Informationen aus dem Störfallmanagement (Incident Handling) über den zuständigen Dienstbetreiber der „Multimodalen Reiseinformation“ an die Dienstbetreiber von Informations- und Vertriebskanäle dar. Für diese Dienstanbieter gilt hier generell eine besondere Verantwortung für die Reisenden, sowohl
* bei Unfällen oder (Umwelt-)Katastrophen,
* bei Veranstaltungen und Events, wo Sicherheitsvorkehrungen und die Steuerung der Auslastungsverteilung in der Verantwortung der öffentlichen Hand liegen als auch
* bei Krisen oder Krieg.

Durch Informationen aus den Hochrechnungen und Vorhersagen der Inhalteanbieter zur kurz-, mittel- und langfristigen Verkehrsentwicklung in einem Gebiet können von dem Dienstbetreiber der „Multimodalen Reise“ abgestimmt mit den regionalen und überregionalen Strategien (ermittelt aus der Komponente „Informationslogik“) Informationen hinsichtlich zu erwartender Staus, Störungen und Überlastungen über die „API-Serviceanbindung“ an die Dienstanbieter übergeben werden. Damit können frühzeitig die Zielgruppen von den Informations- und Vertriebsdiensten angesprochen und informiert sowie Änderungen im Mobilitätsverhalten der Zielgruppen motiviert werden. Die Rückmeldung der Akzeptanz der Zielgruppen auf die Informationen erfolgt ebenso über die „API-Serviceanbindung“ an den Dienstbetreiber der „Multimodalen Reiseinformation“ zur Verwendung in den Komponenten Informations- und Vertriebslogik.

Über die Erstellung von Statistiken bzw. Business Intelligence (BI)-Auswertungen werden sowohl
* die Institutionen der öffentliche Hand (z.B. Verkehrsplanung, Verkehrsleitzentralen) in die Lage versetzt, ihre öffentlichen Strategien bei Planung und Betrieb zu optimieren, als auch
* die Inhalteanbieter (z.B. Veranstalter, Verkehrsunternehmen) und Dienstanbieter in die Lage versetzt, ihre Produkte und Dienste auf die Gegebenheiten eines dynamischen Verkehrsablaufs situativ anzupassen und damit ihren Vertrieb zu optimieren.

'''Informationslogik'''

Die Komponente (IT-Schicht) „Informationslogik“ verarbeitet
* die Daten und Informationen der unterschiedlichen Inhalteanbieter,
* unter Beachtung der regionalen und überregionalen geltenden öffentlichen Strategien der Gebietskörperschaften,
* situative Meldungen an spezifischen Punkten der Reisekette und
* relevante Faktoren aus dem Vertrieb (z. B. Inzentivs) sowie
* die aktuellen Erkenntnisse aus den Informations- und Vertriebsdiensten der Dienstanbieter hinsichtlich der Akzeptanz von Informationen aus der „Multimodalen Reiseinformation“.

Ein Ziel der Informationslogik ist es, optimierte Reiseketten, welche nutzerspezifische Präferenzen sowie unterschiedliche Verkehrsmittel berücksichtigen, zu berechnen und diese Informationen in vergleichbarer, integrativer und nachvollziehbarer Weise den unterschiedlichen Zielgruppen zur Verfügung zu stellen. Die Zielgruppen werden über regionale und globale Dienstanbieter (mobility services) angesprochen.

Aufgrund der Vielzahl an Akteuren und Systemen im Verkehr bzw. der Reisebranche sowie ihrer Differenzierung nach Räumen muss mit einer „Multimodalen Reiseinformation“ in Deutschland auch eine intelligente Vernetzung der zuständigen Teilsysteme (der Akteure im Wirkungsraum) realisiert werden. Hierzu benötig die Komponente der „Informationslogik“ folgende serverseitig ausgeführten Teilkomponenten.

Die ''Intermodale Logik'' integriert die aus der Nutzerschnittstelle übergebenen Daten, Informationen und Parameter (z.B. Fahrplanauskunft / Tarifauskunft, Verkehrsmeldungen und Steuerungsstrategien öffentlicher Partner, Landkreise, Gemeinden, regionaler Strategiemanager, Floating-Car-Daten, API) über die „API-Datenanbindung“. Aus den regionalen Daten und Verkehrsmanagementstrategien werden auf den Verkehrsnetzen Streckenwiderstände modelliert, die die Grundlage für das modale und intermodale Routing sind. Hierzu muss die Verkehrslage situationsabhängig berechnet und prognostiziert werden. Bei der Aktivierung einer Strategie (z.B. Umleitungsempfehlung oder P+R-Nutzung) werden in der intermodalen Logik die relevanten Netzelemente des strategischen Netzes in der Routenberechnung attraktiver gewichtet.

Die Intermodale Logik berechnet auf der Grundlage der aggregierten modalen Reisewege der externen ÖV-Router, der relevanten MIV-, Fahrrad- und Fußgänger-Router sowie auf Basis von Tarifinformationen der jeweiligen Verkehrsmittel, somit Verfügbarkeiten. Sie ermittelt daraufhin nach nutzerspezifischen Reisepräferenzen und öffentlichen Strategien eine optimierte intermodale Reisekette. Die intermodale Reiseplanung kann unter Berücksichtigung situativer zielgruppenspezifischer Bedürfnisse erfolgen wie z.B. die schnellste, günstigste oder ökologischste, emissionsfreieste bzw. verkehrsoptimalste Route. Die Berechnungsergebnisse der Intermodalen Logik werden über die API „Serviceanbindung“ den Dienstanbietern zur Verfügung gestellt, sodass regionale Partner und Aufgabenträger auch die Steuerungsstrategien in ihren Systemen weiterverarbeiten können.

Der ''POI- und Adressservice'' integriert dazu alle punktbezogenen Informationen wie Adressen, Standorte von Sharing-Angebote, Haltestellen, Parkgaragen / P+R, Ladestationen etc., die an die „API-Datenanbindung“ angeschlossen sind, in ein einheitliches Datenformat und stellt diese über Web-Service-Schnittstellen internen und externen Diensten zur Verfügung (z.B. BW API „Serviceanbindung“). Die Zusammenführung, Harmonisierung und Referenzierung aller Daten muss auf einer gleichen Netzgrundlage, dem bundesweiten Integrationsnetz Straße stattfinden. Es bildet somit die Grundlage für die bundesweite Weiterverarbeitung regionaler Daten und Strategien.

Mit der Anbindung der gebietsspezifischen Dienstanbieter für die „Multimodale Reiseinformation“ an den Mobilitätsdatenmarktplatz MDM der Bundesanstalt für Straßenwesen über die „API-Serviceanbindung“ wird sichergestellt, dass Verkehrsmeldungen und Strategien aus dezidierten Gebieten an den MDM weitergeleitet und damit ausgetauscht werden können. Hier entsteht somit ein weiterer Mehrwert im Bereich der Datenverwendung auf bundesweiter Ebene. Die Anbindung an den MDM muss dabei in Abstimmung mit den Inhalteanbietern festgelegt werden.

Auf regionaler Ebene müssen ''Pflegewerkzeuge'' (Client) die Erfassung, Verortung von Verkehrsmeldungen und Verkehrslenkungs- und Steuerungsstrategien ermöglichen. Die Pflegewerkzeuge müssen mandantenfähig sein, so dass jeder Akteur des regionalen Verkehrsmanagements seine Strategien selber einpflegen kann. Pflegewerkzeuge sind damit eine wichtige Teilkomponente zur Etablierung eines regionalen (dynamischen) Verkehrsmanagements.

Damit wird es im Rahmen der „Informationslogik“ möglich, dass die von der Intermodalen Logik unter Berücksichtigung regionaler und individueller Strategien berechnete multimodale Reise von den eigenen Routerinstanzen der Dienstleister (App-Service, Autonavigationsgerät) übernommen wird und in ihr Routing unverfälscht eingebunden wird. Damit kann der Einwirkungsbereich auf das Mobilitätsverhalten aller Zielgruppen vergrößert werden.

'''Vertriebslogik'''

Die Komponente (IT-Schicht) „Vertriebslogik“ verarbeitet Buchungs-, Stornierungs- und Bezahlvorgänge von Produkten, Dienstleistungen oder Auskünften (Informationen) der Inhalteanbieter.

Aus Sicht der öffentlichen Hand (Auskunftspflicht) bedeutet „Multimodale Reiseinformation“ die alleinige Realisierung aller Komponenten in der Infor mationslogistik. Eine Akzeptanz und dauerhafte Nutzung der IVS-Referenzarchitektur „Multimodale Reiseinformation“ wird sich nach heutigen Erkenntnissen (z.B. VAO) nur einstellen, wenn sich die angezeigten Verkehrsanbindungen auch einfach und verlässlich buchen lassen. Dies ist notwendig, um
* eine Verbindlichkeit mit der Reiseinformation zu verknüpfen (z.B. Umstieg auf den ÖPNV am P+R-Platz durch Kauf der Fahrberechtigung im ÖPNV und des Einfahrtberechtigung in den P+R-Platz vor oder während der Reise),
* die freie Wirtschaft zu endkundenorientierten Angeboten und Lösungen zu bewegen und
* um die Prozesse rund um die Dienstreise und deren Abrechnung zu automatisieren bzw. zu optimieren.

Um entlang von Reiseketten nicht nur diskriminierungsfrei alle Informationen über die möglichen Produkte und Dienstleistungen anbieten zu können, muss auch die Buchung und der Kauf dieser angebotenen Produkte und Dienstleistungen diskriminierungsfrei für alle Zielgruppen möglich sein. In Anbetracht von z.B. einem unerwarteten Ereignis auf einer Reise wird damit gewährleistet, dass der Kunde nicht nur Alternativen aufgezeigt bekommt, sondern diese auch direkt wahrnehmen kann, ohne einen Medienbruch und damit neue Unsicherheiten auf sich zu nehmen. Die Zielgruppen (Nutzer) sparen Zeit, sie bekommen vereinfachte Prozesse vor und während der Reise und somit Vertrauen und Sicherheit in die „Multimodale Reiseinformation“.

Des Weiteren können durch die Einbindung der Komponente „Vertriebslogik“ in die Architekturvision der „Multimodalen Reiseinformation“ auch kommerzielle Elemente wie Inzentivierung, Gamification oder Anreizprogramme zur Unterstützung der Akzeptanz öffentlicher Strategien (z.B. Umsteigen auf den Öffentlichen Verkehr) bei Zielgruppen genutzt werden. In der weiteren Folge lassen sich damit BI-Möglichkeiten zur Erstellung von Statistiken über Reisekosten und deren Veränderung über die Jahre (Kostensteigerung) abbilden. Damit können die Zielgruppen finanzielle und zeitliche Steuerungsmaßnahmen für sich und ihr Mobilitätsverhalten einfach erkennen und ableiten.

Eine IVS-Referenzarchitektur „Multimodale Reiseinformation“ darf sich daher nicht nur auf die Informationslogik zurückziehen, sondern muss auch bei der Komponente „Vertriebslogik“ einen diskriminierungsfreien Einsatz angemessen vorsehen und beschreiben.

'''Data Hub'''

Die Komponente (IT-Schicht) „Data Hub“ stellt die serverseitige Organisationseinheit der Komponenten der „Multimodalen Reiseinformation“ dar. Es beinhaltet u.a.
* Datenmanagement und Datensicherheit (Überlassung, Weitergabe, Nutzung, Regeln, Status)
* Schnittstellenmanagement (Status, Version)
* System Management (Speicher, Verteilung)
* Lastmanagement (Anfragen, Verteilung)
* Hazardmanagement (Angriffe)
* Protokollwesen (LOG-Files, BI-Nutzung)

Der Data Hub erlaubt die kontrollierte Anbindung an die Big-Data-Analystik und an Data-Ware-Houses durch Tracing- und Tracking-Prozesse des Datenflusses über den/die neutralen Dienstbetreiber „Multimodale Reiseinformation“. Dadurch können zukünftig auf Seiten der
* öffentlichen Hand Planungs- und Verkehrssteuerungsprozesse optimiert und auf Seiten der
* Privatwirtschaft Mehrwertdienste entwickelt und an den Endnutzer verkauft werden.

Kap. 8 Entwicklung der Architekturvision

2016-06-20T09:30:47Z

Weber: /* Entwicklung der Architekturvision */

== Entwicklung der Architekturvision ==

Aufbauend auf dem Wirkungsbereich für die IVS-Referenzarchitektur „Multimodale Reiseinformation“ können für die Beschreibung der Architekturvision der „Multimodalen Reiseinformation“ (Blauer Bereich in Abbildung 2)

* die maßgebenden Komponenten sowie
* ihre Beiträge zur Zielerreichung einer funktionsfähigen „Multimodalen Reiseinformation“ in Deutschland

identifiziert und beschrieben werden.

[[Datei:Komponenten der IVS-Referenzarchitektur Multimodale Reiseinformation_Konsortium MRK-AMADEUS.JPG|700px|thumb|centre]]

'''Abbildung 2''' Komponenten der IVS-Referenzarchitektur „Multimodale Reiseinformation“

'''API-Datenanbindung'''

Die Komponente (IT-Schicht) „API-Datenanbindung“ schließt über diverse technische Transportprotokolle die Systeme der Inhalteanbieter mit dem Zweck der Zustellung von Daten und Informationen an den für ein definiertes Gebiet zuständigen und neutralen Dienstbetreiber der „Multimodalen Reiseinformation“ (z.B. moveBW in Baden-Württemberg, VAO in Österreich) an. Ein Inhalteanbieter kann auch als Aggregator eigene Datenbestände als Informationen (z.B. Fahrplanauskunft eines Verkehrsverbunds, MDM) an der „API-Datenanbindung“ mit einem gewissen Normierungsstand zur Verfügung stellen. Der Inhalteanbieter bestimmt das Exportformat.

Der Datenzugriff erfolgt nach Absprache wahlweise im Pull- oder auch im Push-Mechanismus, um einen Abgleich des gesamten Datenbestands als Vollupdate oder inkrementelles Update sicherzustellen. Die Akteure stimmen untereinander einen geeigneten Updatezyklus ab.

Im Anschluss an den Datenimport aus den Lieferantensystemen der Inhalteanbieter erfolgt beim Dienstbetreiber die Transformation in ein normiertes, übergreifendes Datenformat, um die Leistungen der verschiedenen Träger miteinander in Beziehung zu bringen.

Von Inhalteanbietern muss an Dienstbetreiber u.a. geliefert werden:
* Fahr-, Reisezeiten,
* Aufenthaltsdauern, Umsteigezeiten,
* Tarife, Aktionsangebote/Klassen,
* Produkte und Produkteigenschaften (u.a. Größe, Strecken, Standorte, Verfügbarkeiten/Anzahl freie Plätze, Incidents vorhersehbar/nicht vorhersehbar).

Es müssen u.a. folgende Inhalteanbieter Daten und Informationen liefern:

Bahnunternehmen, Schienennetzbetreiber, Busunternehmen, Flug, Charter, Fahrradverkehr, Automobilunternehmen, Autoinformationssysteme, Mietwagen, Taxi, Transferservice, Parkhäuser, Fähren, Versicherungen, Kommunen, Länder (Vorzugsnetz für LKW, Baustellen, Sperrungen, …), Wetterdienste, Feuerwehr, Rettungsdienste, Polizei, Straßenämter, Behörden, Umweltämter, Geodatenbanken, ADAC/ADFC-Verkehrsprognosen, Mobil funkunternehmen, Informationsdienste (Google, Yahoo, Bing, …), POI (TomTom, …), Energieunternehmen, Unterkünfte etc.

Dabei ist es unerlässlich, dass die Inhalteanbieter Daten und Informationen kontinuierlich in höchstmöglicher Qualität innerhalb eines Servicestandards an den Dienstbetreiber der „Multimodalen Reiseinformation“ liefern, um eine dauerhafte Akzeptanz bei der Zielgruppe zu sichern. Die Dienstbetreiber sind dafür zuständig, mit ihrer Komponente „Informationslogik“ die vorhandenen Daten und Informationen für die Zielgruppen so aufzubereiten, dass über eine komplette Reisekette einer Zielperson über beliebige Medien hinweg in sich stimmige Informationen über beliebige Dienstanbieter (Informations- und Vertriebsdienste) an die Zielgruppe gebracht werden können.

Im Fall eines Vertriebs (Buchen, Verkaufen) von Produkten und Dienstleistungen der Inhalteanbieter über die „Multimodale Reiseinformation“ muss von der Komponente „API-Datenanbindung“ unabhängig von den angeschlossenen Dienstanbietern (mobility services wie z.B. Reisebüro, e-Ticket eines Verbunds, Autonavigationssystem) die Datenvalidierung zu
* Verkaufsinformationen, Validierung und Verfügbarkeit von Produkten und Dienstleistungen,
* gekauften Produkten und Dienstleistungen im Warenkorb,
* sicheren Bezahlungsmethoden für Nutzer und Leistungserbringer (Inhalteanbieter) und das
* Verkaufsbelegmanagement zwischen Inhalteanbieter und Kunde (Zielgruppe)
unterstützt werden.

Dies erreicht man am besten durch Nutzung von dedizierten Kundenprofilen, die den nationalen und internationalen Datenschutzstandards entsprechen.

'''API-Serviceanbindung'''

Die Komponente „API-Serviceanbindung“ ist die Schnittstelle vom neutralen Dienstbetreiber der „Multimodalen Reiseinformation“ für ein definiertes Gebiet (z.B. moveBW in Baden-Württemberg, VAO in Österreich) zu Dienstanbietern von Informations- und Vertriebskanälen (mobility services).

Die Komponente (IT-Schicht) „API-Serviceanbindung“ stellt den Dienstanbietern von Informations- und Vertriebsdiensten den Zugriff auf Information und Buchung zur Verfügung. Dabei werden verschiedenste, teilweise vom Nutzer individuell parametrisierbare und reiseabhängige Kriterien berücksichtigt, wie die
* Zeit-/Reisedauer,
* anfallende Kosten und Incentives,
* öffentliche Strategien (Umwelt, Verkehrssteuerung usw.),
* Kontext sowie
* Komforteigenschaften.

Weiterhin gibt es Zielgruppen, für die besondere Kriterien dauerhaft Anwendung finden müssen, wie gesundheitliche Aspekte oder firmenrelevante Interessen (Reiserichtlinien).

Bei der Bedienung der Dienstanbieter mit Informationen aus der „Multimodalen Reiseinformation“ muss darauf geachtet werden, dass neben der Reisemöglichkeit bezogen auf den individuellen Reisewunsch der Zielgruppe auch alternative Angebote (Fußgänger, ÖV, IV) dem Dienstanbietern über die „API-Serviceanbindung“ übergeben werden müssen, wenn öffentliche Strategien es verlangen. Die Auswahl der Reiseroute und -modalitäten obliegt aber weiterhin der Zielgruppe (Kunde).

Ein besonderer Mehrwert stellt generell die Übermittlung von Informationen aus dem Störfallmanagement (Incident Handling) über den zuständigen Dienstbetreiber der „Multimodalen Reiseinformation“ an die Dienstbetreiber von Informations- und Vertriebskanäle dar. Für diese Dienstanbieter gilt hier generell eine besondere Verantwortung für die Reisenden, sowohl
* bei Unfällen oder (Umwelt-)Katastrophen,
* bei Veranstaltungen und Events, wo Sicherheitsvorkehrungen und die Steuerung der Auslastungsverteilung in der Verantwortung der öffentlichen Hand liegen als auch
* bei Krisen oder Krieg.

Durch Informationen aus den Hochrechnungen und Vorhersagen der Inhalteanbieter zur kurz-, mittel- und langfristigen Verkehrsentwicklung in einem Gebiet können von dem Dienstbetreiber der „Multimodalen Reise“ abgestimmt mit den regionalen und überregionalen Strategien (ermittelt aus der Komponente „Informationslogik“) Informationen hinsichtlich zu erwartender Staus, Störungen und Überlastungen über die „API-Serviceanbindung“ an die Dienstanbieter übergeben werden. Damit können frühzeitig die Zielgruppen von den Informations- und Vertriebsdiensten angesprochen und informiert sowie Änderungen im Mobilitätsverhalten der Zielgruppen motiviert werden. Die Rückmeldung der Akzeptanz der Zielgruppen auf die Informationen erfolgt ebenso über die „API-Serviceanbindung“ an den Dienstbetreiber der „Multimodalen Reiseinformation“ zur Verwendung in den Komponenten Informations- und Vertriebslogik.

Über die Erstellung von Statistiken bzw. Business Intelligence (BI)-Auswertungen werden sowohl
* die Institutionen der öffentliche Hand (z.B. Verkehrsplanung, Verkehrsleitzentralen) in die Lage versetzt, ihre öffentlichen Strategien bei Planung und Betrieb zu optimieren, als auch
* die Inhalteanbieter (z.B. Veranstalter, Verkehrsunternehmen) und Dienstanbieter in die Lage versetzt, ihre Produkte und Dienste auf die Gegebenheiten eines dynamischen Verkehrsablaufs situativ anzupassen und damit ihren Vertrieb zu optimieren.

'''Informationslogik'''

Die Komponente (IT-Schicht) „Informationslogik“ verarbeitet
* die Daten und Informationen der unterschiedlichen Inhalteanbieter,
* unter Beachtung der regionalen und überregionalen geltenden öffentlichen Strategien der Gebietskörperschaften,
* situative Meldungen an spezifischen Punkten der Reisekette und
* relevante Faktoren aus dem Vertrieb (z. B. Inzentivs) sowie
* die aktuellen Erkenntnisse aus den Informations- und Vertriebsdiensten der Dienstanbieter hinsichtlich der Akzeptanz von Informationen aus der „Multimodalen Reiseinformation“.

Ein Ziel der Informationslogik ist es, optimierte Reiseketten, welche nutzerspezifische Präferenzen sowie unterschiedliche Verkehrsmittel berücksichtigen, zu berechnen und diese Informationen in vergleichbarer, integrativer und nachvollziehbarer Weise den unterschiedlichen Zielgruppen zur Verfügung zu stellen. Die Zielgruppen werden über regionale und globale Dienstanbieter (mobility services) angesprochen.

Aufgrund der Vielzahl an Akteuren und Systemen im Verkehr bzw. der Reisebranche sowie ihrer Differenzierung nach Räumen muss mit einer „Multimodalen Reiseinformation“ in Deutschland auch eine intelligente Vernetzung der zuständigen Teilsysteme (der Akteure im Wirkungsraum) realisiert werden. Hierzu benötig die Komponente der „Informationslogik“ folgende serverseitig ausgeführten Teilkomponenten.

Die ''Intermodale Logik'' integriert die aus der Nutzerschnittstelle übergebenen Daten, Informationen und Parameter (z.B. Fahrplanauskunft / Tarifauskunft, Verkehrsmeldungen und Steuerungsstrategien öffentlicher Partner, Landkreise, Gemeinden, regionaler Strategiemanager, Floating-Car-Daten, API) über die „API-Datenanbindung“. Aus den regionalen Daten und Verkehrsmanagementstrategien werden auf den Verkehrsnetzen Streckenwiderstände modelliert, die die Grundlage für das modale und intermodale Routing sind. Hierzu muss die Verkehrslage situationsabhängig berechnet und prognostiziert werden. Bei der Aktivierung einer Strategie (z.B. Umleitungsempfehlung oder P+R-Nutzung) werden in der intermodalen Logik die relevanten Netzelemente des strategischen Netzes in der Routenberechnung attraktiver gewichtet.

Die Intermodale Logik berechnet auf der Grundlage der aggregierten modalen Reisewege der externen ÖV-Router, der relevanten MIV-, Fahrrad- und Fußgänger-Router sowie auf Basis von Tarifinformation der jeweiligen Verkehrsmittel, somit Verfügbarkeiten. Sie ermittelt darauf nach nutzerspezifischen Reisepräferenzen und öffentlichen Strategien eine optimierte intermodale Reisekette. Die intermodale Reiseplanung kann unter Berücksichtigung situativer zielgruppenspezifischer Bedürfnisse erfolgen wie z.B. die schnellste, günstigste oder ökologischste, emissionsfreieste bzw. verkehrsoptimalste Route. Die Berechnungsergebnisse der Intermodalen Logik werden über die API „Serviceanbindung“ den Dienstanbietern zur Verfügung gestellt, so dass regionale Partner und Aufgabenträger auch die Steuerungsstrategien in ihren Systemen weiterverarbeiten können.

Der ''POI- und Adressservice'' integriert dazu alle punktbezogenen Informationen wie Adressen, Standorte von Sharing-Angebote, Haltestellen, Parkgaragen / P+R, Ladestationen etc., die an die „API-Datenanbindung“ angeschlossen sind, in ein einheitliches Datenformat und stellt diese über Web-Service-Schnittstellen internen und externen Diensten zur Verfügung (z.B. BW API „Serviceanbindung“). Die Zusammenführung, Harmonisierung und Referenzierung aller Daten muss auf einer gleichen Netzgrundlage, dem bundesweiten Integrationsnetz Straße stattfinden. Es bildet somit die Grundlage für die bundesweite Weiterverarbeitung regionaler Daten und Strategien.

Mit der Anbindung der gebietsspezifischen Dienstanbieter für die „Multimodale Reiseinformation“ an den Mobilitätsdatenmarktplatz MDM der Bundesanstalt für Straßenwesen über die „API-Serviceanbindung“ wird sichergestellt, dass Verkehrsmeldungen und Strategien aus dezidierten Gebieten an den MDM weitergeleitet und damit ausgetauscht werden können. Hier entsteht somit ein weiterer Mehrwert im Bereich der Datenverwendung auf bundesweiter Ebene. Die Anbindung an den MDM muss dabei in Abstimmung mit den Inhalteanbietern festgelegt werden.

Auf regionaler Ebene müssen ''Pflegewerkzeuge'' (Client) die Erfassung, Verortung von Verkehrsmeldungen und Verkehrslenkungs- und Steuerungsstrategien ermöglichen. Die Pflegewerkzeuge müssen mandantenfähig sein, so dass jeder Akteur des regionalen Verkehrsmanagements seine Strategien selber einpflegen kann. Pflegewerkzeuge sind damit eine wichtige Teilkomponente zur Etablierung eines regionalen (dynamischen) Verkehrsmanagements.

Damit wird es im Rahmen der „Informationslogik“ möglich, dass die von der Intermodalen Logik unter Berücksichtigung regionaler und individueller Strategien berechnete multimodale Reise von den eigenen Routerinstanzen der Dienstleister (App-Service, Autonavigationsgerät) übernommen wird und in ihr Routing unverfälscht eingebunden wird. Damit kann der Einwirkungsbereich auf das Mobilitätsverhalten aller Zielgruppen vergrößert werden.

'''Vertriebslogik'''

Die Komponente (IT-Schicht) „Vertriebslogik“ verarbeitet Buchungs-, Stornierungs- und Bezahlvorgänge von Produkten, Dienstleistungen oder Auskünften (Informationen) der Inhalteanbieter.

Aus Sicht der öffentlichen Hand (Auskunftspflicht) bedeutet „Multimodale Reiseinformation“ die alleinige Realisierung aller Komponenten in der Infor mationslogistik. Eine Akzeptanz und dauerhafte Nutzung der IVS-Referenzarchitektur „Multimodale Reiseinformation“ wird sich nach heutigen Erkenntnissen (z.B. VAO) nur einstellen, wenn sich die angezeigten Verkehrsanbindungen auch einfach und verlässlich buchen lassen. Dies ist notwendig, um
* eine Verbindlichkeit mit der Reiseinformation zu verknüpfen (z.B. Umstieg auf den ÖPNV am P+R-Platz durch Kauf der Fahrberechtigung im ÖPNV und des Einfahrtberechtigung in den P+R-Platz vor oder während der Reise),
* die freie Wirtschaft zu endkundenorientierten Angeboten und Lösungen zu bewegen und
* um die Prozesse rund um die Dienstreise und deren Abrechnung zu automatisieren bzw. zu optimieren.

Um entlang von Reiseketten nicht nur diskriminierungsfrei alle Informationen über die möglichen Produkte und Dienstleistungen anbieten zu können, muss auch die Buchung und der Kauf dieser angebotenen Produkte und Dienstleistungen diskriminierungsfrei für alle Zielgruppen möglich sein. In Anbetracht von z.B. einem unerwarteten Ereignis auf einer Reise wird damit gewährleistet, dass der Kunde nicht nur Alternativen aufgezeigt bekommt, sondern diese auch direkt wahrnehmen kann, ohne einen Medienbruch und damit neue Unsicherheiten auf sich zu nehmen. Die Zielgruppen (Nutzer) sparen Zeit, sie bekommen vereinfachte Prozesse vor und während der Reise und somit Vertrauen und Sicherheit in die „Multimodale Reiseinformation“.

Des Weiteren können durch die Einbindung der Komponente „Vertriebslogik“ in die Architekturvision der „Multimodalen Reiseinformation“ auch kommerzielle Elemente wie Inzentivierung, Gamification oder Anreizprogramme zur Unterstützung der Akzeptanz öffentlicher Strategien (z.B. Umsteigen auf den Öffentlichen Verkehr) bei Zielgruppen genutzt werden. In der weiteren Folge lassen sich damit BI-Möglichkeiten zur Erstellung von Statistiken über Reisekosten und deren Veränderung über die Jahre (Kostensteigerung) abbilden. Damit können die Zielgruppen finanzielle und zeitliche Steuerungsmaßnahmen für sich und ihr Mobilitätsverhalten einfach erkennen und ableiten.

Eine IVS-Referenzarchitektur „Multimodale Reiseinformation“ darf sich daher nicht nur auf die Informationslogik zurückziehen, sondern muss auch bei der Komponente „Vertriebslogik“ einen diskriminierungsfreien Einsatz angemessen vorsehen und beschreiben.

'''Data Hub'''

Die Komponente (IT-Schicht) „Data Hub“ stellt die serverseitige Organisationseinheit der Komponenten der „Multimodalen Reiseinformation“ dar. Es beinhaltet u.a.
* Datenmanagement und Datensicherheit (Überlassung, Weitergabe, Nutzung, Regeln, Status)
* Schnittstellenmanagement (Status, Version)
* System Management (Speicher, Verteilung)
* Lastmanagement (Anfragen, Verteilung)
* Hazardmanagement (Angriffe)
* Protokollwesen (LOG-Files, BI-Nutzung)

Der Data Hub erlaubt die kontrollierte Anbindung an die Big-Data-Analystik und an Data-Ware-Houses durch Tracing- und Tracking-Prozesse des Datenflusses über den/die neutralen Dienstbetreiber „Multimodale Reiseinformation“. Dadurch können zukünftig auf Seiten der
* öffentlichen Hand Planungs- und Verkehrssteuerungsprozesse optimiert und auf Seiten der
* Privatwirtschaft Mehrwertdienste entwickelt und an den Endnutzer verkauft werden.

Kap. 8 Entwicklung der Architekturvision

2016-06-20T09:28:13Z

Weber: /* Entwicklung der Architekturvision */

== Entwicklung der Architekturvision ==

Aufbauend auf dem Wirkungsbereich für die IVS-Referenzarchitektur „Multimodale Reiseinformation“ können für die Beschreibung der Architekturvision der „Multimodalen Reiseinformation“ (Blauer Bereich in Abbildung 2)

* die maßgebenden Komponenten sowie
* ihre Beiträge zur Zielerreichung einer funktionsfähigen „Multimodalen Reiseinformation“ in Deutschland

identifiziert und beschrieben werden.

[[Datei:Komponenten der IVS-Referenzarchitektur Multimodale Reiseinformation_Konsortium MRK-AMADEUS.JPG|700px|thumb|centre]]

'''Abbildung 2''' Komponenten der IVS-Referenzarchitektur „Multimodale Reiseinformation“

'''API-Datenanbindung'''

Die Komponente (IT-Schicht) „API-Datenanbindung“ schließt über diverse technische Transportprotokolle die Systeme der Inhalteanbieter mit dem Zweck der Zustellung von Daten und Informationen an den für ein definiertes Gebiet zuständigen und neutralen Dienstbetreiber der „Multimodalen Reiseinformation“ (z.B. moveBW in Baden-Württemberg, VAO in Österreich) an. Ein Inhalteanbieter kann auch als Aggregator eigene Datenbestände als Informationen (z.B. Fahrplanauskunft eines Verkehrsverbunds, MDM) an der „API-Datenanbindung“ mit einem gewissen Normierungsstand zur Verfügung stellen. Der Inhalteanbieter bestimmt das Exportformat.

Der Datenzugriff erfolgt nach Absprache wahlweise im Pull- oder auch im Push-Mechanismus, um einen Abgleich des gesamten Datenbestands als Vollupdate oder inkrementelles Update sicherzustellen. Die Akteure stimmen untereinander einen geeigneten Updatezyklus ab.

Im Anschluss an den Datenimport aus den Lieferantensystemen der Inhalteanbieter erfolgt beim Dienstbetreiber die Transformation in ein normiertes, übergreifendes Datenformat, um die Leistungen der verschiedenen Träger miteinander in Beziehung zu bringen.

Von Inhalteanbietern muss an Dienstbetreiber u.a. geliefert werden:
* Fahr-, Reisezeiten,
* Aufenthaltsdauern, Umsteigezeiten,
* Tarife, Aktionsangebote/Klassen,
* Produkte und Produkteigenschaften (u.a. Größe, Strecken, Standorte, Verfügbarkeiten/Anzahl freie Plätze, Incidents vorhersehbar/nicht vorhersehbar).

Es müssen u.a. folgende Inhalteanbieter Daten und Informationen liefern:

Bahnunternehmen, Schienennetzbetreiber, Busunternehmen, Flug, Charter, Fahrradverkehr, Automobilunternehmen, Autoinformationssysteme, Mietwagen, Taxi, Transferservice, Parkhäuser, Fähren, Versicherungen, Kommunen, Länder (Vorzugsnetz für LKW, Baustellen, Sperrungen, …), Wetterdienste, Feuerwehr, Rettungsdienste, Polizei, Straßenämter, Behörden, Umweltämter, Geodatenbanken, ADAC/ADFC-Verkehrsprognosen, Mobil funkunternehmen, Informationsdienste (Google, Yahoo, Bing, …), POI (TomTom, …), Energieunternehmen, Unterkünfte etc.

Dabei ist es unerlässlich, dass die Inhalteanbieter Daten und Informationen kontinuierlich in höchstmöglicher Qualität innerhalb eines Servicestandards an den Dienstbetreiber der „Multimodalen Reiseinformation“ liefern, um eine dauerhafte Akzeptanz bei der Zielgruppe zu sichern. Die Dienstbetreiber sind dafür zuständig, mit ihrer Komponente „Informationslogik“ die vorhandenen Daten und Informationen für die Zielgruppen so aufzubereiten, dass über eine komplette Reisekette einer Zielperson über beliebige Medien hinweg in sich stimmige Informationen über beliebige Dienstanbieter (Informations- und Vertriebsdienste) an die Zielgruppe gebracht werden können.

Im Fall eines Vertriebs (Buchen, Verkaufen) von Produkten und Dienstleistungen der Inhalteanbieter über die „Multimodale Reiseinformation“ muss von der Komponente „API-Datenanbindung“ unabhängig von den angeschlossenen Dienstanbietern (mobility services wie z.B. Reisebüro, e-Ticket eines Verbunds, Autonavigationssystem) die Datenvalidierung zu
* Verkaufsinformationen, Validierung und Verfügbarkeit von Produkten und Dienstleistungen,
* gekauften Produkten und Dienstleistungen im Warenkorb,
* sicheren Bezahlungsmethoden für Nutzer und Leistungserbringer (Inhalteanbieter) und das
* Verkaufsbelegmanagement zwischen Inhalteanbieter und Kunde (Zielgruppe)
unterstützt werden.

Dies erreicht man am besten durch Nutzung von dedizierten Kundenprofilen, die den nationalen und internationalen Datenschutzstandards entsprechen.

'''API-Serviceanbindung'''

Die Komponente „API-Serviceanbindung“ ist die Schnittstelle vom neutralen Dienstbetreiber der „Multimodalen Reiseinformation“ für ein definiertes Gebiet (z.B. moveBW in Baden-Württemberg, VAO in Österreich) zu Dienstanbietern von Informations- und Vertriebskanälen (mobility services).

Die Komponente (IT-Schicht) „API-Serviceanbindung“ stellt den Dienstanbietern von Informations- und Vertriebsdiensten den Zugriff auf Information und Buchung zur Verfügung. Dabei werden verschiedenste, teilweise vom Nutzer individuell parametrisierbare und reiseabhängige Kriterien berücksichtigt, wie die
* Zeit-/Reisedauer,
* anfallende Kosten und Incentives,
* öffentliche Strategien (Umwelt, Verkehrssteuerung usw.),
* Kontext sowie
* Komforteigenschaften.

Weiterhin gibt es Zielgruppen, für die besondere Kriterien dauerhaft Anwendung finden müssen, wie gesundheitliche Aspekte oder firmenrelevante Interessen (Reiserichtlinien).

Bei der Bedienung der Dienstanbieter mit Informationen aus der „Multimodalen Reiseinformation“ muss darauf geachtet werden, dass neben der Reisemöglichkeit bezogen auf den individuellen Reisewunsch der Zielgruppe auch alternative Angebote (Fußgänger, ÖV, IV) dem Dienstanbietern über die „API-Serviceanbindung“ übergeben werden müssen, wenn öffentliche Strategien es verlangen. Die Auswahl der Reiseroute und -modalitäten obliegt aber weiterhin der Zielgruppe (Kunde).

Ein besonderer Mehrwert stellt generell die Übermittlung von Informationen aus dem Störfallmanagement (Incident Handling) über den zuständigen Dienstbetreiber der „Multimodalen Reiseinformation“ an die Dienstbetreiber von Informations- und Vertriebskanäle dar. Für diese Dienstanbieter gilt hier generell eine besondere Verantwortung für die Reisenden, sowohl
* bei Unfällen oder (Umwelt-)Katastrophen,
* bei Veranstaltungen und Events, wo Sicherheitsvorkehrungen und die Steuerung der Auslastungsverteilung in der Verantwortung der öffentlichen Hand liegen als auch
* bei Krisen oder Krieg.

Durch Informationen aus den Hochrechnungen und Vorhersagen der Inhalteanbieter zur kurz-, mittel- und langfristigen Verkehrsentwicklung in einem Gebiet können von dem Dienstbetreiber der „Multimodalen Reise“ abgestimmt mit den regionalen und überregionalen Strategien (ermittelt aus der Komponente „Informationslogik“) Informationen hinsichtlich zu erwartender Staus, Störungen und Überlastungen über die „API-Serviceanbindung“ an die Dienstanbieter übergeben werden. Damit können frühzeitig die Zielgruppen von den Informations- und Vertriebsdiensten angesprochen und informiert sowie Änderungen im Mobilitätsverhalten der Zielgruppen motiviert werden. Die Rückmeldung der Akzeptanz der Zielgruppen auf die Informationen erfolgt ebenso über die „API-Serviceanbindung“ an den Dienstbetreiber der „Multimodalen Reiseinformation“ zur Verwendung in den Komponenten Informations- und Vertriebslogik.

Über die Erstellung von Statistiken bzw. Business Intelligence (BI)-Auswertungen werden sowohl
* die Institutionen der öffentliche Hand (z.B. Verkehrsplanung, Verkehrsleitzentralen) in die Lage versetzt, ihre öffentlichen Strategien bei Planung und Betrieb zu optimieren, als auch
* die Inhalteanbieter (z.B. Veranstalter, Verkehrsunternehmen) und Dienstanbieter in die Lage versetzt, ihre Produkte und Dienste auf die Gegebenheiten eines dynamischen Verkehrsablaufs situativ anzupassen und damit ihren Vertrieb zu optimieren.

'''Informationslogik'''

Die Komponente (IT-Schicht) „Informationslogik“ verarbeitet
* die Daten und Informationen der unterschiedlichen Inhalteanbieter,
* unter Beachtung der regionalen und überregionalen geltenden öffentlichen Strategien der Gebietskörperschaften,
* situativer Meldungen an spezifischen Punkten der Reisekette und
* relevanten Faktoren aus dem Vertrieb (z. B. Inzentivs) sowie
* den aktuellen Erkenntnissen aus den Informations- und Vertriebsdiensten der Dienstanbieter hinsichtlich der Akzeptanz von Informationen aus der „Multimodalen Reiseinformation“.

Ein Ziel der Informationslogik ist es, optimierte Reiseketten, welche nutzerspezifische Präferenzen sowie unterschiedliche Verkehrsmittel berücksichtigen, zu berechnen und diese Informationen in vergleichbarer, integrativer und nachvollziehbarer Weise den unterschiedlichen Zielgruppen zur Verfügung zu stellen. Die Zielgruppen werden über regionale und globale Dienstanbieter (mobility services) angesprochen.

Aufgrund der Vielzahl an Akteuren und Systemen im Verkehr bzw. der Reisebranche sowie ihrer Differenzierung nach Räumen muss mit einer „Multimodalen Reiseinformation“ in Deutschland auch eine intelligente Vernetzung der zuständigen Teilsysteme (der Akteure im Wirkungsraum) realisiert werden. Hierzu benötig die Komponente der „Informationslogik“ folgende serverseitig ausgeführten Teilkomponenten.

Die ''Intermodale Logik'' integriert die aus der Nutzerschnittstelle übergebenen Daten, Informationen und Parameter (z.B. Fahrplanauskunft / Tarifauskunft, Verkehrsmeldungen und Steuerungsstrategien öffentlicher Partner, Landkreise, Gemeinden, regionaler Strategiemanager, Floating-Car-Daten, API) über die „API-Datenanbindung“. Aus den regionalen Daten und Verkehrsmanagementstrategien werden auf den Verkehrsnetzen Streckenwiderstände modelliert, die die Grundlage für das modale und intermodale Routing sind. Hierzu muss die Verkehrslage situationsabhängig berechnet und prognostiziert werden. Bei der Aktivierung einer Strategie (z.B. Umleitungsempfehlung oder P+R-Nutzung) werden in der intermodalen Logik die relevanten Netzelemente des strategischen Netzes in der Routenberechnung attraktiver gewichtet.

Die Intermodale Logik berechnet auf der Grundlage der aggregierten modalen Reisewege der externen ÖV-Router, der relevanten MIV-, Fahrrad- und Fußgänger-Router sowie auf Basis von Tarifinformation der jeweiligen Verkehrsmittel, somit Verfügbarkeiten. Sie ermittelt darauf nach nutzerspezifischen Reisepräferenzen und öffentlichen Strategien eine optimierte intermodale Reisekette. Die intermodale Reiseplanung kann unter Berücksichtigung situativer zielgruppenspezifischer Bedürfnisse erfolgen wie z.B. die schnellste, günstigste oder ökologischste, emissionsfreieste bzw. verkehrsoptimalste Route. Die Berechnungsergebnisse der Intermodalen Logik werden über die API „Serviceanbindung“ den Dienstanbietern zur Verfügung gestellt, so dass regionale Partner und Aufgabenträger auch die Steuerungsstrategien in ihren Systemen weiterverarbeiten können.

Der ''POI- und Adressservice'' integriert dazu alle punktbezogenen Informationen wie Adressen, Standorte von Sharing-Angebote, Haltestellen, Parkgaragen / P+R, Ladestationen etc., die an die „API-Datenanbindung“ angeschlossen sind, in ein einheitliches Datenformat und stellt diese über Web-Service-Schnittstellen internen und externen Diensten zur Verfügung (z.B. BW API „Serviceanbindung“). Die Zusammenführung, Harmonisierung und Referenzierung aller Daten muss auf einer gleichen Netzgrundlage, dem bundesweiten Integrationsnetz Straße stattfinden. Es bildet somit die Grundlage für die bundesweite Weiterverarbeitung regionaler Daten und Strategien.

Mit der Anbindung der gebietsspezifischen Dienstanbieter für die „Multimodale Reiseinformation“ an den Mobilitätsdatenmarktplatz MDM der Bundesanstalt für Straßenwesen über die „API-Serviceanbindung“ wird sichergestellt, dass Verkehrsmeldungen und Strategien aus dezidierten Gebieten an den MDM weitergeleitet und damit ausgetauscht werden können. Hier entsteht somit ein weiterer Mehrwert im Bereich der Datenverwendung auf bundesweiter Ebene. Die Anbindung an den MDM muss dabei in Abstimmung mit den Inhalteanbietern festgelegt werden.

Auf regionaler Ebene müssen ''Pflegewerkzeuge'' (Client) die Erfassung, Verortung von Verkehrsmeldungen und Verkehrslenkungs- und Steuerungsstrategien ermöglichen. Die Pflegewerkzeuge müssen mandantenfähig sein, so dass jeder Akteur des regionalen Verkehrsmanagements seine Strategien selber einpflegen kann. Pflegewerkzeuge sind damit eine wichtige Teilkomponente zur Etablierung eines regionalen (dynamischen) Verkehrsmanagements.

Damit wird es im Rahmen der „Informationslogik“ möglich, dass die von der Intermodalen Logik unter Berücksichtigung regionaler und individueller Strategien berechnete multimodale Reise von den eigenen Routerinstanzen der Dienstleister (App-Service, Autonavigationsgerät) übernommen wird und in ihr Routing unverfälscht eingebunden wird. Damit kann der Einwirkungsbereich auf das Mobilitätsverhalten aller Zielgruppen vergrößert werden.

'''Vertriebslogik'''

Die Komponente (IT-Schicht) „Vertriebslogik“ verarbeitet Buchungs-, Stornierungs- und Bezahlvorgänge von Produkten, Dienstleistungen oder Auskünften (Informationen) der Inhalteanbieter.

Aus Sicht der öffentlichen Hand (Auskunftspflicht) bedeutet „Multimodale Reiseinformation“ die alleinige Realisierung aller Komponenten in der Infor mationslogistik. Eine Akzeptanz und dauerhafte Nutzung der IVS-Referenzarchitektur „Multimodale Reiseinformation“ wird sich nach heutigen Erkenntnissen (z.B. VAO) nur einstellen, wenn sich die angezeigten Verkehrsanbindungen auch einfach und verlässlich buchen lassen. Dies ist notwendig, um
* eine Verbindlichkeit mit der Reiseinformation zu verknüpfen (z.B. Umstieg auf den ÖPNV am P+R-Platz durch Kauf der Fahrberechtigung im ÖPNV und des Einfahrtberechtigung in den P+R-Platz vor oder während der Reise),
* die freie Wirtschaft zu endkundenorientierten Angeboten und Lösungen zu bewegen und
* um die Prozesse rund um die Dienstreise und deren Abrechnung zu automatisieren bzw. zu optimieren.

Um entlang von Reiseketten nicht nur diskriminierungsfrei alle Informationen über die möglichen Produkte und Dienstleistungen anbieten zu können, muss auch die Buchung und der Kauf dieser angebotenen Produkte und Dienstleistungen diskriminierungsfrei für alle Zielgruppen möglich sein. In Anbetracht von z.B. einem unerwarteten Ereignis auf einer Reise wird damit gewährleistet, dass der Kunde nicht nur Alternativen aufgezeigt bekommt, sondern diese auch direkt wahrnehmen kann, ohne einen Medienbruch und damit neue Unsicherheiten auf sich zu nehmen. Die Zielgruppen (Nutzer) sparen Zeit, sie bekommen vereinfachte Prozesse vor und während der Reise und somit Vertrauen und Sicherheit in die „Multimodale Reiseinformation“.

Des Weiteren können durch die Einbindung der Komponente „Vertriebslogik“ in die Architekturvision der „Multimodalen Reiseinformation“ auch kommerzielle Elemente wie Inzentivierung, Gamification oder Anreizprogramme zur Unterstützung der Akzeptanz öffentlicher Strategien (z.B. Umsteigen auf den Öffentlichen Verkehr) bei Zielgruppen genutzt werden. In der weiteren Folge lassen sich damit BI-Möglichkeiten zur Erstellung von Statistiken über Reisekosten und deren Veränderung über die Jahre (Kostensteigerung) abbilden. Damit können die Zielgruppen finanzielle und zeitliche Steuerungsmaßnahmen für sich und ihr Mobilitätsverhalten einfach erkennen und ableiten.

Eine IVS-Referenzarchitektur „Multimodale Reiseinformation“ darf sich daher nicht nur auf die Informationslogik zurückziehen, sondern muss auch bei der Komponente „Vertriebslogik“ einen diskriminierungsfreien Einsatz angemessen vorsehen und beschreiben.

'''Data Hub'''

Die Komponente (IT-Schicht) „Data Hub“ stellt die serverseitige Organisationseinheit der Komponenten der „Multimodalen Reiseinformation“ dar. Es beinhaltet u.a.
* Datenmanagement und Datensicherheit (Überlassung, Weitergabe, Nutzung, Regeln, Status)
* Schnittstellenmanagement (Status, Version)
* System Management (Speicher, Verteilung)
* Lastmanagement (Anfragen, Verteilung)
* Hazardmanagement (Angriffe)
* Protokollwesen (LOG-Files, BI-Nutzung)

Der Data Hub erlaubt die kontrollierte Anbindung an die Big-Data-Analystik und an Data-Ware-Houses durch Tracing- und Tracking-Prozesse des Datenflusses über den/die neutralen Dienstbetreiber „Multimodale Reiseinformation“. Dadurch können zukünftig auf Seiten der
* öffentlichen Hand Planungs- und Verkehrssteuerungsprozesse optimiert und auf Seiten der
* Privatwirtschaft Mehrwertdienste entwickelt und an den Endnutzer verkauft werden.

Kap. 8 Entwicklung der Architekturvision

2016-06-20T09:26:59Z

Weber: /* Entwicklung der Architekturvision */

== Entwicklung der Architekturvision ==

Aufbauend auf dem Wirkungsbereich für die IVS-Referenzarchitektur „Multimodale Reiseinformation“ können für die Beschreibung der Architekturvision der „Multimodalen Reiseinformation“ (Blauer Bereich in Abbildung 2)

* die maßgebenden Komponenten sowie
* ihre Beiträge zur Zielerreichung einer funktionsfähigen „Multimodalen Reiseinformation“ in Deutschland

identifiziert und beschrieben werden.

[[Datei:Komponenten der IVS-Referenzarchitektur Multimodale Reiseinformation_Konsortium MRK-AMADEUS.JPG|700px|thumb|centre]]

'''Abbildung 2''' Komponenten der IVS-Referenzarchitektur „Multimodale Reiseinformation“

'''API-Datenanbindung'''

Die Komponente (IT-Schicht) „API-Datenanbindung“ schließt über diverse technische Transportprotokolle die Systeme der Inhalteanbieter mit dem Zweck der Zustellung von Daten und Informationen an den für ein definiertes Gebiet zuständigen und neutralen Dienstbetreiber der „Multimodalen Reiseinformation“ (z.B. moveBW in Baden-Württemberg, VAO in Österreich) an. Ein Inhalteanbieter kann auch als Aggregator eigene Datenbestände als Informationen (z.B. Fahrplanauskunft eines Verkehrsverbunds, MDM) an der „API-Datenanbindung“ mit einem gewissen Normierungsstand zur Verfügung stellen. Der Inhalteanbieter bestimmt das Exportformat.

Der Datenzugriff erfolgt nach Absprache wahlweise im Pull- oder auch im Push-Mechanismus, um einen Abgleich des gesamten Datenbestands als Vollupdate oder inkrementelles Update sicherzustellen. Die Akteure stimmen untereinander einen geeigneten Updatezyklus ab.

Im Anschluss an den Datenimport aus den Lieferantensystemen der Inhalteanbieter erfolgt beim Dienstbetreiber die Transformation in ein normiertes, übergreifendes Datenformat, um die Leistungen der verschiedenen Träger miteinander in Beziehung zu bringen.

Von Inhalteanbietern muss an Dienstbetreiber u.a. geliefert werden:
* Fahr-, Reisezeiten,
* Aufenthaltsdauern, Umsteigezeiten,
* Tarife, Aktionsangebote/Klassen,
* Produkte und Produkteigenschaften (u.a. Größe, Strecken, Standorte, Verfügbarkeiten/Anzahl freie Plätze, Incidents vorhersehbar/nicht vorhersehbar).

Es müssen u.a. folgende Inhalteanbieter Daten und Informationen liefern:

Bahnunternehmen, Schienennetzbetreiber, Busunternehmen, Flug, Charter, Fahrradverkehr, Automobilunternehmen, Autoinformationssysteme, Mietwagen, Taxi, Transferservice, Parkhäuser, Fähren, Versicherungen, Kommunen, Länder (Vorzugsnetz für LKW, Baustellen, Sperrungen, …), Wetterdienste, Feuerwehr, Rettungsdienste, Polizei, Straßenämter, Behörden, Umweltämter, Geodatenbanken, ADAC/ADFC-Verkehrsprognosen, Mobil funkunternehmen, Informationsdienste (Google, Yahoo, Bing, …), POI (TomTom, …), Energieunternehmen, Unterkünfte etc.

Dabei ist es unerlässlich, dass die Inhalteanbieter Daten und Informationen kontinuierlich in höchstmöglicher Qualität innerhalb eines Servicestandards an den Dienstbetreiber der „Multimodalen Reiseinformation“ liefern, um eine dauerhafte Akzeptanz bei der Zielgruppe zu sichern. Die Dienstbetreiber sind dafür zuständig, mit ihrer Komponente „Informationslogik“ die vorhandenen Daten und Informationen für die Zielgruppen so aufzubereiten, dass über eine komplette Reisekette einer Zielperson über beliebige Medien hinweg in sich stimmige Informationen über beliebige Dienstanbieter (Informations- und Vertriebsdienste) an die Zielgruppe gebracht werden können.

Im Fall eines Vertriebs (Buchen, Verkaufen) von Produkten und Dienstleistungen der Inhalteanbieter über die „Multimodale Reiseinformation“ muss von der Komponente „API-Datenanbindung“ unabhängig von den angeschlossenen Dienstanbietern (mobility services wie z.B. Reisebüro, e-Ticket eines Verbunds, Autonavigationssystem) die Datenvalidierung zu
* Verkaufsinformationen, Validierung und Verfügbarkeit von Produkten und Dienstleistungen,
* gekauften Produkten und Dienstleistungen im Warenkorb,
* sicheren Bezahlungsmethoden für Nutzer und Leistungserbringer (Inhalteanbieter) und das
* Verkaufsbelegmanagement zwischen Inhalteanbieter und Kunde (Zielgruppe)
unterstützt werden.

Dies erreicht man am besten durch Nutzung von dedizierten Kundenprofilen, die den nationalen und internationalen Datenschutzstandards entsprechen.

'''API-Serviceanbindung'''

Die Komponente „API-Serviceanbindung“ ist die Schnittstelle vom neutralen Dienstbetreiber der „Multimodalen Reiseinformation“ für ein definiertes Gebiet (z.B. moveBW in Baden-Württemberg, VAO in Österreich) zu Dienstanbietern von Informations- und Vertriebskanälen (mobility services).

Die Komponente (IT-Schicht) „API-Serviceanbindung“ stellt den Dienstanbietern von Informations- und Vertriebsdiensten den Zugriff auf Information und Buchung zur Verfügung. Dabei werden verschiedenste, teilweise vom Nutzer individuell parametrisierbare und reiseabhängige Kriterien berücksichtigt, wie die
* Zeit-/Reisedauer,
* anfallende Kosten und Incentives,
* öffentliche Strategien (Umwelt, Verkehrssteuerung usw.),
* Kontext sowie
* Komforteigenschaften.

Weiterhin gibt es Zielgruppen, für die besondere Kriterien dauerhaft Anwendung finden müssen, wie gesundheitliche Aspekte oder firmenrelevante Interessen (Reiserichtlinien).

Bei der Bedienung der Dienstanbieter mit Informationen aus der „Multimodalen Reiseinformation“ muss darauf geachtet werden, dass neben der Reisemöglichkeit bezogen auf den individuellen Reisewunsch der Zielgruppe auch alternative Angebote (Fußgänger, ÖV, IV) dem Dienstanbietern über die „API-Serviceanbindung“ übergeben werden müssen, wenn öffentliche Strategien es verlangen. Die Auswahl der Reiseroute und -modalitäten obliegt aber weiterhin der Zielgruppe (Kunde).

Ein besonderer Mehrwert stellt generell die Übermittlung von Informationen aus dem Störfallmanagement (Incident Handling) über den zuständigen Dienstbetreiber der „Multimodalen Reiseinformation“ an die Dienstbetreiber von Informations- und Vertriebskanäle dar. Für diese Dienstanbieter gilt hier generell eine besondere Verantwortung für die Reisenden, sowohl
* bei Unfällen oder (Umwelt-)Katastrophen,
* bei Veranstaltungen und Events, wo Sicherheitsvorkehrungen und die Steuerung der Auslastungsverteilung in der Verantwortung der öffentlichen Hand liegen als auch
* bei Krisen oder Krieg.

Durch Informationen aus den Hochrechnungen und Vorhersagen der Inhalteanbieter zur kurz-, mittel- und langfristigen Verkehrsentwicklung in einem Gebiet können von dem Dienstbetreiber der „Multimodalen Reise“ abgestimmt mit den regionalen und überregionalen Strategien (ermittelt aus der Komponente „Informationslogik“). Informationen hinsichtlich zu erwartender Staus, Störungen und Überlastungen über die „API-Serviceanbindung“ an die Dienstanbieter übergeben werden. Damit können frühzeitig die Zielgruppen von den Informations- und Vertriebsdiensten angesprochen und informiert sowie Änderungen im Mobilitätsverhalten der Zielgruppen motiviert werden. Die Rückmeldung der Akzeptanz der Zielgruppen auf die Informationen erfolgt ebenso über die „API-Serviceanbindung“ an den Dienstbetreiber der „Multimodalen Reiseinformation“ zur Verwendung in den Komponenten Informations- und Vertriebslogik.

Über die Erstellung von Statistiken bzw. Business Intelligence (BI)-Auswertungen werden sowohl
* die Institutionen der öffentliche Hand (z.B. Verkehrsplanung, Verkehrsleitzentralen) in die Lage versetzt, ihre öffentlichen Strategien bei Planung und Betrieb zu optimieren, als auch
* die Inhalteanbieter (z.B. Veranstalter, Verkehrsunternehmen) und Dienstanbieter in die Lage versetzt, ihre Produkte und Dienste auf die Gegebenheiten eines dynamischen Verkehrsablaufs situativ anzupassen und damit ihren Vertrieb zu optimieren.

'''Informationslogik'''

Die Komponente (IT-Schicht) „Informationslogik“ verarbeitet
* die Daten und Informationen der unterschiedlichen Inhalteanbieter,
* unter Beachtung der regionalen und überregionalen geltenden öffentlichen Strategien der Gebietskörperschaften,
* situativer Meldungen an spezifischen Punkten der Reisekette und
* relevanten Faktoren aus dem Vertrieb (z. B. Inzentivs) sowie
* den aktuellen Erkenntnissen aus den Informations- und Vertriebsdiensten der Dienstanbieter hinsichtlich der Akzeptanz von Informationen aus der „Multimodalen Reiseinformation“.

Ein Ziel der Informationslogik ist es, optimierte Reiseketten, welche nutzerspezifische Präferenzen sowie unterschiedliche Verkehrsmittel berücksichtigen, zu berechnen und diese Informationen in vergleichbarer, integrativer und nachvollziehbarer Weise den unterschiedlichen Zielgruppen zur Verfügung zu stellen. Die Zielgruppen werden über regionale und globale Dienstanbieter (mobility services) angesprochen.

Aufgrund der Vielzahl an Akteuren und Systemen im Verkehr bzw. der Reisebranche sowie ihrer Differenzierung nach Räumen muss mit einer „Multimodalen Reiseinformation“ in Deutschland auch eine intelligente Vernetzung der zuständigen Teilsysteme (der Akteure im Wirkungsraum) realisiert werden. Hierzu benötig die Komponente der „Informationslogik“ folgende serverseitig ausgeführten Teilkomponenten.

Die ''Intermodale Logik'' integriert die aus der Nutzerschnittstelle übergebenen Daten, Informationen und Parameter (z.B. Fahrplanauskunft / Tarifauskunft, Verkehrsmeldungen und Steuerungsstrategien öffentlicher Partner, Landkreise, Gemeinden, regionaler Strategiemanager, Floating-Car-Daten, API) über die „API-Datenanbindung“. Aus den regionalen Daten und Verkehrsmanagementstrategien werden auf den Verkehrsnetzen Streckenwiderstände modelliert, die die Grundlage für das modale und intermodale Routing sind. Hierzu muss die Verkehrslage situationsabhängig berechnet und prognostiziert werden. Bei der Aktivierung einer Strategie (z.B. Umleitungsempfehlung oder P+R-Nutzung) werden in der intermodalen Logik die relevanten Netzelemente des strategischen Netzes in der Routenberechnung attraktiver gewichtet.

Die Intermodale Logik berechnet auf der Grundlage der aggregierten modalen Reisewege der externen ÖV-Router, der relevanten MIV-, Fahrrad- und Fußgänger-Router sowie auf Basis von Tarifinformation der jeweiligen Verkehrsmittel, somit Verfügbarkeiten. Sie ermittelt darauf nach nutzerspezifischen Reisepräferenzen und öffentlichen Strategien eine optimierte intermodale Reisekette. Die intermodale Reiseplanung kann unter Berücksichtigung situativer zielgruppenspezifischer Bedürfnisse erfolgen wie z.B. die schnellste, günstigste oder ökologischste, emissionsfreieste bzw. verkehrsoptimalste Route. Die Berechnungsergebnisse der Intermodalen Logik werden über die API „Serviceanbindung“ den Dienstanbietern zur Verfügung gestellt, so dass regionale Partner und Aufgabenträger auch die Steuerungsstrategien in ihren Systemen weiterverarbeiten können.

Der ''POI- und Adressservice'' integriert dazu alle punktbezogenen Informationen wie Adressen, Standorte von Sharing-Angebote, Haltestellen, Parkgaragen / P+R, Ladestationen etc., die an die „API-Datenanbindung“ angeschlossen sind, in ein einheitliches Datenformat und stellt diese über Web-Service-Schnittstellen internen und externen Diensten zur Verfügung (z.B. BW API „Serviceanbindung“). Die Zusammenführung, Harmonisierung und Referenzierung aller Daten muss auf einer gleichen Netzgrundlage, dem bundesweiten Integrationsnetz Straße stattfinden. Es bildet somit die Grundlage für die bundesweite Weiterverarbeitung regionaler Daten und Strategien.

Mit der Anbindung der gebietsspezifischen Dienstanbieter für die „Multimodale Reiseinformation“ an den Mobilitätsdatenmarktplatz MDM der Bundesanstalt für Straßenwesen über die „API-Serviceanbindung“ wird sichergestellt, dass Verkehrsmeldungen und Strategien aus dezidierten Gebieten an den MDM weitergeleitet und damit ausgetauscht werden können. Hier entsteht somit ein weiterer Mehrwert im Bereich der Datenverwendung auf bundesweiter Ebene. Die Anbindung an den MDM muss dabei in Abstimmung mit den Inhalteanbietern festgelegt werden.

Auf regionaler Ebene müssen ''Pflegewerkzeuge'' (Client) die Erfassung, Verortung von Verkehrsmeldungen und Verkehrslenkungs- und Steuerungsstrategien ermöglichen. Die Pflegewerkzeuge müssen mandantenfähig sein, so dass jeder Akteur des regionalen Verkehrsmanagements seine Strategien selber einpflegen kann. Pflegewerkzeuge sind damit eine wichtige Teilkomponente zur Etablierung eines regionalen (dynamischen) Verkehrsmanagements.

Damit wird es im Rahmen der „Informationslogik“ möglich, dass die von der Intermodalen Logik unter Berücksichtigung regionaler und individueller Strategien berechnete multimodale Reise von den eigenen Routerinstanzen der Dienstleister (App-Service, Autonavigationsgerät) übernommen wird und in ihr Routing unverfälscht eingebunden wird. Damit kann der Einwirkungsbereich auf das Mobilitätsverhalten aller Zielgruppen vergrößert werden.

'''Vertriebslogik'''

Die Komponente (IT-Schicht) „Vertriebslogik“ verarbeitet Buchungs-, Stornierungs- und Bezahlvorgänge von Produkten, Dienstleistungen oder Auskünften (Informationen) der Inhalteanbieter.

Aus Sicht der öffentlichen Hand (Auskunftspflicht) bedeutet „Multimodale Reiseinformation“ die alleinige Realisierung aller Komponenten in der Infor mationslogistik. Eine Akzeptanz und dauerhafte Nutzung der IVS-Referenzarchitektur „Multimodale Reiseinformation“ wird sich nach heutigen Erkenntnissen (z.B. VAO) nur einstellen, wenn sich die angezeigten Verkehrsanbindungen auch einfach und verlässlich buchen lassen. Dies ist notwendig, um
* eine Verbindlichkeit mit der Reiseinformation zu verknüpfen (z.B. Umstieg auf den ÖPNV am P+R-Platz durch Kauf der Fahrberechtigung im ÖPNV und des Einfahrtberechtigung in den P+R-Platz vor oder während der Reise),
* die freie Wirtschaft zu endkundenorientierten Angeboten und Lösungen zu bewegen und
* um die Prozesse rund um die Dienstreise und deren Abrechnung zu automatisieren bzw. zu optimieren.

Um entlang von Reiseketten nicht nur diskriminierungsfrei alle Informationen über die möglichen Produkte und Dienstleistungen anbieten zu können, muss auch die Buchung und der Kauf dieser angebotenen Produkte und Dienstleistungen diskriminierungsfrei für alle Zielgruppen möglich sein. In Anbetracht von z.B. einem unerwarteten Ereignis auf einer Reise wird damit gewährleistet, dass der Kunde nicht nur Alternativen aufgezeigt bekommt, sondern diese auch direkt wahrnehmen kann, ohne einen Medienbruch und damit neue Unsicherheiten auf sich zu nehmen. Die Zielgruppen (Nutzer) sparen Zeit, sie bekommen vereinfachte Prozesse vor und während der Reise und somit Vertrauen und Sicherheit in die „Multimodale Reiseinformation“.

Des Weiteren können durch die Einbindung der Komponente „Vertriebslogik“ in die Architekturvision der „Multimodalen Reiseinformation“ auch kommerzielle Elemente wie Inzentivierung, Gamification oder Anreizprogramme zur Unterstützung der Akzeptanz öffentlicher Strategien (z.B. Umsteigen auf den Öffentlichen Verkehr) bei Zielgruppen genutzt werden. In der weiteren Folge lassen sich damit BI-Möglichkeiten zur Erstellung von Statistiken über Reisekosten und deren Veränderung über die Jahre (Kostensteigerung) abbilden. Damit können die Zielgruppen finanzielle und zeitliche Steuerungsmaßnahmen für sich und ihr Mobilitätsverhalten einfach erkennen und ableiten.

Eine IVS-Referenzarchitektur „Multimodale Reiseinformation“ darf sich daher nicht nur auf die Informationslogik zurückziehen, sondern muss auch bei der Komponente „Vertriebslogik“ einen diskriminierungsfreien Einsatz angemessen vorsehen und beschreiben.

'''Data Hub'''

Die Komponente (IT-Schicht) „Data Hub“ stellt die serverseitige Organisationseinheit der Komponenten der „Multimodalen Reiseinformation“ dar. Es beinhaltet u.a.
* Datenmanagement und Datensicherheit (Überlassung, Weitergabe, Nutzung, Regeln, Status)
* Schnittstellenmanagement (Status, Version)
* System Management (Speicher, Verteilung)
* Lastmanagement (Anfragen, Verteilung)
* Hazardmanagement (Angriffe)
* Protokollwesen (LOG-Files, BI-Nutzung)

Der Data Hub erlaubt die kontrollierte Anbindung an die Big-Data-Analystik und an Data-Ware-Houses durch Tracing- und Tracking-Prozesse des Datenflusses über den/die neutralen Dienstbetreiber „Multimodale Reiseinformation“. Dadurch können zukünftig auf Seiten der
* öffentlichen Hand Planungs- und Verkehrssteuerungsprozesse optimiert und auf Seiten der
* Privatwirtschaft Mehrwertdienste entwickelt und an den Endnutzer verkauft werden.

Kap. 8 Entwicklung der Architekturvision

2016-06-20T09:24:27Z

Weber: /* Entwicklung der Architekturvision */

== Entwicklung der Architekturvision ==

Aufbauend auf dem Wirkungsbereich für die IVS-Referenzarchitektur „Multimodale Reiseinformation“ können für die Beschreibung der Architekturvision der „Multimodalen Reiseinformation“ (Blauer Bereich in Abbildung 2)

* die maßgebenden Komponenten sowie
* ihre Beiträge zur Zielerreichung einer funktionsfähigen „Multimodalen Reiseinformation“ in Deutschland

identifiziert und beschrieben werden.

[[Datei:Komponenten der IVS-Referenzarchitektur Multimodale Reiseinformation_Konsortium MRK-AMADEUS.JPG|700px|thumb|centre]]

'''Abbildung 2''' Komponenten der IVS-Referenzarchitektur „Multimodale Reiseinformation“

'''API-Datenanbindung'''

Die Komponente (IT-Schicht) „API-Datenanbindung“ schließt über diverse technische Transportprotokolle die Systeme der Inhalteanbieter mit dem Zweck der Zustellung von Daten und Informationen an den für ein definiertes Gebiet zuständigen und neutralen Dienstbetreiber der „Multimodalen Reiseinformation“ (z.B. moveBW in Baden-Württemberg, VAO in Österreich) an. Ein Inhalteanbieter kann auch als Aggregator eigene Datenbestände als Informationen (z.B. Fahrplanauskunft eines Verkehrsverbunds, MDM) an der „API-Datenanbindung“ mit einem gewissen Normierungsstand zur Verfügung stellen. Der Inhalteanbieter bestimmt das Exportformat.

Der Datenzugriff erfolgt nach Absprache wahlweise im Pull- oder auch im Push-Mechanismus, um einen Abgleich des gesamten Datenbestands als Vollupdate oder inkrementelles Update sicherzustellen. Die Akteure stimmen untereinander einen geeigneten Updatezyklus ab.

Im Anschluss an den Datenimport aus den Lieferantensystemen der Inhalteanbieter erfolgt beim Dienstbetreiber die Transformation in ein normiertes, übergreifendes Datenformat, um die Leistungen der verschiedenen Träger miteinander in Beziehung zu bringen.

Von Inhalteanbietern muss an Dienstbetreiber u.a. geliefert werden:
* Fahr-, Reisezeiten,
* Aufenthaltsdauern, Umsteigezeiten,
* Tarife, Aktionsangebote/Klassen,
* Produkte und Produkteigenschaften (u.a. Größe, Strecken, Standorte, Verfügbarkeiten/Anzahl freie Plätze, Incidents vorhersehbar/nicht vorhersehbar).

Es müssen u.a. folgende Inhalteanbieter Daten und Informationen liefern:

Bahnunternehmen, Schienennetzbetreiber, Busunternehmen, Flug, Charter, Fahrradverkehr, Automobilunternehmen, Autoinformationssysteme, Mietwagen, Taxi, Transferservice, Parkhäuser, Fähren, Versicherungen, Kommunen, Länder (Vorzugsnetz für LKW, Baustellen, Sperrungen, …), Wetterdienste, Feuerwehr, Rettungsdienste, Polizei, Straßenämter, Behörden, Umweltämter, Geodatenbanken, ADAC/ADFC-Verkehrsprognosen, Mobil funkunternehmen, Informationsdienste (Google, Yahoo, Bing, …), POI (TomTom, …), Energieunternehmen, Unterkünfte etc.

Dabei ist es unerlässlich, dass die Inhalteanbieter Daten und Informationen kontinuierlich in höchstmöglicher Qualität innerhalb eines Servicestandards an den Dienstbetreiber der „Multimodalen Reiseinformation“ liefern, um eine dauerhafte Akzeptanz bei der Zielgruppe zu sichern. Die Dienstbetreiber sind dafür zuständig, mit ihrer Komponente „Informationslogik“ die vorhandenen Daten und Informationen für die Zielgruppen so aufzubereiten, dass über eine komplette Reisekette einer Zielperson über beliebige Medien hinweg in sich stimmige Informationen über beliebige Dienstanbieter (Informations- und Vertriebsdienste) an die Zielgruppe gebracht werden können.

Im Fall eines Vertriebs (Buchen, Verkaufen) von Produkten und Dienstleistungen der Inhalteanbieter über die „Multimodale Reiseinformation“ muss von der Komponente „API-Datenanbindung“ unabhängig von den angeschlossenen Dienstanbietern (mobility services wie z.B. Reisebüro, e-Ticket eines Verbunds, Autonavigationssystem) die Datenvalidierung zu
* Verkaufsinformationen, Validierung und Verfügbarkeit von Produkten und Dienstleistungen,
* gekauften Produkten und Dienstleistungen im Warenkorb,
* sicheren Bezahlungsmethoden für Nutzer und Leistungserbringer (Inhalteanbieter) und das
* Verkaufsbelegmanagement zwischen Inhalteanbieter und Kunde (Zielgruppe)
unterstützt werden.

Dies erreicht man am besten durch Nutzung von dedizierten Kundenprofilen, die den nationalen und internationalen Datenschutzstandards entsprechen.

'''API-Serviceanbindung'''

Die Komponente „API-Serviceanbindung“ ist die Schnittstelle vom neutralen Dienstbetreiber der „Multimodalen Reiseinformation“ für ein definiertes Gebiet (z.B. moveBW in Baden-Württemberg, VAO in Österreich) zu Dienstanbietern von Informations- und Vertriebskanälen (mobility services).

Die Komponente (IT-Schicht) „API-Serviceanbindung“ stellt den Dienstanbietern von Informations- und Vertriebsdiensten den Zugriff auf Information und Buchung zur Verfügung. Dabei werden verschiedenste, teilweise vom Nutzer individuell parametrisierbare und reiseabhängige Kriterien berücksichtigt, wie die
* Zeit-/Reisedauer,
* anfallende Kosten und Incentives,
* öffentliche Strategien (Umwelt, Verkehrssteuerung usw.),
* Kontext sowie
* Komforteigenschaften.

Weiterhin gibt es Zielgruppen, für die besondere Kriterien dauerhaft Anwendung finden müssen, wie gesundheitliche Aspekte oder firmenrelevante Interessen (Reiserichtlinien).

Bei der Bedienung der Dienstanbieter mit Informationen aus der „Multimodalen Reiseinformation“ muss darauf geachtet werden, dass neben der Reisemöglichkeit bezogen auf den individuellen Reisewunsch der Zielgruppe auch alternative Angebote (Fußgänger, ÖV, IV) dem Dienstanbietern über die „API-Serviceanbindung“ übergeben werden müssen, wenn öffentliche Strategien es verlangen. Die Auswahl der Reiseroute und -modalitäten obliegt aber weiterhin der Zielgruppe (Kunde).

Ein besonderer Mehrwert stellt generell die Übermittlung von Informationen aus dem Störfallmanagement (Incident Handling) über den zuständigen Dienstbetreiber der „Multimodalen Reiseinformation“ an die Dienstbetreiber von Informations- und Vertriebskanäle dar. Für diese Dienstanbieter gilt hier generell eine besondere Verantwortung für die Reisenden, sowohl
* bei Unfällen oder (Umwelt-)Katastrophen,
* bei Veranstaltungen und Events, wo Sicherheitsvorkehrungen und die Steuerung der Auslastungsverteilung in der Verantwortung der öffentlichen Hand liegt als auch
* bei Krisen oder Krieg.

Durch Informationen aus den Hochrechnungen und Vorhersagen der Inhalteanbieter zur kurz-, mittel- und langfristigen Verkehrsentwicklung in einem Gebiet können von dem Dienstbetreiber der „Multimodalen Reise“ abgestimmt mit den regionalen und überregionalen Strategien (ermittelt aus der Komponente „Informationslogik“). Informationen hinsichtlich zu erwartender Staus, Störungen und Überlastungen über die „API-Serviceanbindung“ an die Dienstanbieter übergeben werden. Damit können frühzeitig die Zielgruppen von den Informations- und Vertriebsdiensten angesprochen und informiert sowie Änderungen im Mobilitätsverhalten der Zielgruppen motiviert werden. Die Rückmeldung der Akzeptanz der Zielgruppen auf die Informationen erfolgt ebenso über die „API-Serviceanbindung“ an den Dienstbetreiber der „Multimodalen Reiseinformation“ zur Verwendung in den Komponenten Informations- und Vertriebslogik.

Über die Erstellung von Statistiken bzw. Business Intelligence (BI)-Auswertungen werden sowohl
* die Institutionen der öffentliche Hand (z.B. Verkehrsplanung, Verkehrsleitzentralen) in die Lage versetzt, ihre öffentlichen Strategien bei Planung und Betrieb zu optimieren, als auch
* die Inhalteanbieter (z.B. Veranstalter, Verkehrsunternehmen) und Dienstanbieter in die Lage versetzt, ihre Produkte und Dienste auf die Gegebenheiten eines dynamischen Verkehrsablaufs situativ anzupassen und damit ihren Vertrieb zu optimieren.

'''Informationslogik'''

Die Komponente (IT-Schicht) „Informationslogik“ verarbeitet
* die Daten und Informationen der unterschiedlichen Inhalteanbieter,
* unter Beachtung der regionalen und überregionalen geltenden öffentlichen Strategien der Gebietskörperschaften,
* situativer Meldungen an spezifischen Punkten der Reisekette und
* relevanten Faktoren aus dem Vertrieb (z. B. Inzentivs) sowie
* den aktuellen Erkenntnissen aus den Informations- und Vertriebsdiensten der Dienstanbieter hinsichtlich der Akzeptanz von Informationen aus der „Multimodalen Reiseinformation“.

Ein Ziel der Informationslogik ist es, optimierte Reiseketten, welche nutzerspezifische Präferenzen sowie unterschiedliche Verkehrsmittel berücksichtigen, zu berechnen und diese Informationen in vergleichbarer, integrativer und nachvollziehbarer Weise den unterschiedlichen Zielgruppen zur Verfügung zu stellen. Die Zielgruppen werden über regionale und globale Dienstanbieter (mobility services) angesprochen.

Aufgrund der Vielzahl an Akteuren und Systemen im Verkehr bzw. der Reisebranche sowie ihrer Differenzierung nach Räumen muss mit einer „Multimodalen Reiseinformation“ in Deutschland auch eine intelligente Vernetzung der zuständigen Teilsysteme (der Akteure im Wirkungsraum) realisiert werden. Hierzu benötig die Komponente der „Informationslogik“ folgende serverseitig ausgeführten Teilkomponenten.

Die ''Intermodale Logik'' integriert die aus der Nutzerschnittstelle übergebenen Daten, Informationen und Parameter (z.B. Fahrplanauskunft / Tarifauskunft, Verkehrsmeldungen und Steuerungsstrategien öffentlicher Partner, Landkreise, Gemeinden, regionaler Strategiemanager, Floating-Car-Daten, API) über die „API-Datenanbindung“. Aus den regionalen Daten und Verkehrsmanagementstrategien werden auf den Verkehrsnetzen Streckenwiderstände modelliert, die die Grundlage für das modale und intermodale Routing sind. Hierzu muss die Verkehrslage situationsabhängig berechnet und prognostiziert werden. Bei der Aktivierung einer Strategie (z.B. Umleitungsempfehlung oder P+R-Nutzung) werden in der intermodalen Logik die relevanten Netzelemente des strategischen Netzes in der Routenberechnung attraktiver gewichtet.

Die Intermodale Logik berechnet auf der Grundlage der aggregierten modalen Reisewege der externen ÖV-Router, der relevanten MIV-, Fahrrad- und Fußgänger-Router sowie auf Basis von Tarifinformation der jeweiligen Verkehrsmittel, somit Verfügbarkeiten. Sie ermittelt darauf nach nutzerspezifischen Reisepräferenzen und öffentlichen Strategien eine optimierte intermodale Reisekette. Die intermodale Reiseplanung kann unter Berücksichtigung situativer zielgruppenspezifischer Bedürfnisse erfolgen wie z.B. die schnellste, günstigste oder ökologischste, emissionsfreieste bzw. verkehrsoptimalste Route. Die Berechnungsergebnisse der Intermodalen Logik werden über die API „Serviceanbindung“ den Dienstanbietern zur Verfügung gestellt, so dass regionale Partner und Aufgabenträger auch die Steuerungsstrategien in ihren Systemen weiterverarbeiten können.

Der ''POI- und Adressservice'' integriert dazu alle punktbezogenen Informationen wie Adressen, Standorte von Sharing-Angebote, Haltestellen, Parkgaragen / P+R, Ladestationen etc., die an die „API-Datenanbindung“ angeschlossen sind, in ein einheitliches Datenformat und stellt diese über Web-Service-Schnittstellen internen und externen Diensten zur Verfügung (z.B. BW API „Serviceanbindung“). Die Zusammenführung, Harmonisierung und Referenzierung aller Daten muss auf einer gleichen Netzgrundlage, dem bundesweiten Integrationsnetz Straße stattfinden. Es bildet somit die Grundlage für die bundesweite Weiterverarbeitung regionaler Daten und Strategien.

Mit der Anbindung der gebietsspezifischen Dienstanbieter für die „Multimodale Reiseinformation“ an den Mobilitätsdatenmarktplatz MDM der Bundesanstalt für Straßenwesen über die „API-Serviceanbindung“ wird sichergestellt, dass Verkehrsmeldungen und Strategien aus dezidierten Gebieten an den MDM weitergeleitet und damit ausgetauscht werden können. Hier entsteht somit ein weiterer Mehrwert im Bereich der Datenverwendung auf bundesweiter Ebene. Die Anbindung an den MDM muss dabei in Abstimmung mit den Inhalteanbietern festgelegt werden.

Auf regionaler Ebene müssen ''Pflegewerkzeuge'' (Client) die Erfassung, Verortung von Verkehrsmeldungen und Verkehrslenkungs- und Steuerungsstrategien ermöglichen. Die Pflegewerkzeuge müssen mandantenfähig sein, so dass jeder Akteur des regionalen Verkehrsmanagements seine Strategien selber einpflegen kann. Pflegewerkzeuge sind damit eine wichtige Teilkomponente zur Etablierung eines regionalen (dynamischen) Verkehrsmanagements.

Damit wird es im Rahmen der „Informationslogik“ möglich, dass die von der Intermodalen Logik unter Berücksichtigung regionaler und individueller Strategien berechnete multimodale Reise von den eigenen Routerinstanzen der Dienstleister (App-Service, Autonavigationsgerät) übernommen wird und in ihr Routing unverfälscht eingebunden wird. Damit kann der Einwirkungsbereich auf das Mobilitätsverhalten aller Zielgruppen vergrößert werden.

'''Vertriebslogik'''

Die Komponente (IT-Schicht) „Vertriebslogik“ verarbeitet Buchungs-, Stornierungs- und Bezahlvorgänge von Produkten, Dienstleistungen oder Auskünften (Informationen) der Inhalteanbieter.

Aus Sicht der öffentlichen Hand (Auskunftspflicht) bedeutet „Multimodale Reiseinformation“ die alleinige Realisierung aller Komponenten in der Infor mationslogistik. Eine Akzeptanz und dauerhafte Nutzung der IVS-Referenzarchitektur „Multimodale Reiseinformation“ wird sich nach heutigen Erkenntnissen (z.B. VAO) nur einstellen, wenn sich die angezeigten Verkehrsanbindungen auch einfach und verlässlich buchen lassen. Dies ist notwendig, um
* eine Verbindlichkeit mit der Reiseinformation zu verknüpfen (z.B. Umstieg auf den ÖPNV am P+R-Platz durch Kauf der Fahrberechtigung im ÖPNV und des Einfahrtberechtigung in den P+R-Platz vor oder während der Reise),
* die freie Wirtschaft zu endkundenorientierten Angeboten und Lösungen zu bewegen und
* um die Prozesse rund um die Dienstreise und deren Abrechnung zu automatisieren bzw. zu optimieren.

Um entlang von Reiseketten nicht nur diskriminierungsfrei alle Informationen über die möglichen Produkte und Dienstleistungen anbieten zu können, muss auch die Buchung und der Kauf dieser angebotenen Produkte und Dienstleistungen diskriminierungsfrei für alle Zielgruppen möglich sein. In Anbetracht von z.B. einem unerwarteten Ereignis auf einer Reise wird damit gewährleistet, dass der Kunde nicht nur Alternativen aufgezeigt bekommt, sondern diese auch direkt wahrnehmen kann, ohne einen Medienbruch und damit neue Unsicherheiten auf sich zu nehmen. Die Zielgruppen (Nutzer) sparen Zeit, sie bekommen vereinfachte Prozesse vor und während der Reise und somit Vertrauen und Sicherheit in die „Multimodale Reiseinformation“.

Des Weiteren können durch die Einbindung der Komponente „Vertriebslogik“ in die Architekturvision der „Multimodalen Reiseinformation“ auch kommerzielle Elemente wie Inzentivierung, Gamification oder Anreizprogramme zur Unterstützung der Akzeptanz öffentlicher Strategien (z.B. Umsteigen auf den Öffentlichen Verkehr) bei Zielgruppen genutzt werden. In der weiteren Folge lassen sich damit BI-Möglichkeiten zur Erstellung von Statistiken über Reisekosten und deren Veränderung über die Jahre (Kostensteigerung) abbilden. Damit können die Zielgruppen finanzielle und zeitliche Steuerungsmaßnahmen für sich und ihr Mobilitätsverhalten einfach erkennen und ableiten.

Eine IVS-Referenzarchitektur „Multimodale Reiseinformation“ darf sich daher nicht nur auf die Informationslogik zurückziehen, sondern muss auch bei der Komponente „Vertriebslogik“ einen diskriminierungsfreien Einsatz angemessen vorsehen und beschreiben.

'''Data Hub'''

Die Komponente (IT-Schicht) „Data Hub“ stellt die serverseitige Organisationseinheit der Komponenten der „Multimodalen Reiseinformation“ dar. Es beinhaltet u.a.
* Datenmanagement und Datensicherheit (Überlassung, Weitergabe, Nutzung, Regeln, Status)
* Schnittstellenmanagement (Status, Version)
* System Management (Speicher, Verteilung)
* Lastmanagement (Anfragen, Verteilung)
* Hazardmanagement (Angriffe)
* Protokollwesen (LOG-Files, BI-Nutzung)

Der Data Hub erlaubt die kontrollierte Anbindung an die Big-Data-Analystik und an Data-Ware-Houses durch Tracing- und Tracking-Prozesse des Datenflusses über den/die neutralen Dienstbetreiber „Multimodale Reiseinformation“. Dadurch können zukünftig auf Seiten der
* öffentlichen Hand Planungs- und Verkehrssteuerungsprozesse optimiert und auf Seiten der
* Privatwirtschaft Mehrwertdienste entwickelt und an den Endnutzer verkauft werden.

Kap. 8 Entwicklung der Architekturvision

2016-06-20T09:23:12Z

Weber: /* Entwicklung der Architekturvision */

== Entwicklung der Architekturvision ==

Aufbauend auf dem Wirkungsbereich für die IVS-Referenzarchitektur „Multimodale Reiseinformation“ können für die Beschreibung der Architekturvision der „Multimodalen Reiseinformation“ (Blauer Bereich in Abbildung 2)

* die maßgebenden Komponenten sowie
* ihre Beiträge zur Zielerreichung einer funktionsfähigen „Multimodalen Reiseinformation“ in Deutschland

identifiziert und beschrieben werden.

[[Datei:Komponenten der IVS-Referenzarchitektur Multimodale Reiseinformation_Konsortium MRK-AMADEUS.JPG|700px|thumb|centre]]

'''Abbildung 2''' Komponenten der IVS-Referenzarchitektur „Multimodale Reiseinformation“

'''API-Datenanbindung'''

Die Komponente (IT-Schicht) „API-Datenanbindung“ schließt über diverse technische Transportprotokolle die Systeme der Inhalteanbieter mit dem Zweck der Zustellung von Daten und Informationen an den für ein definiertes Gebiet zuständigen und neutralen Dienstbetreiber der „Multimodalen Reiseinformation“ (z.B. moveBW in Baden-Württemberg, VAO in Österreich) an. Ein Inhalteanbieter kann auch als Aggregator eigene Datenbestände als Informationen (z.B. Fahrplanauskunft eines Verkehrsverbunds, MDM) an der „API-Datenanbindung“ mit einem gewissen Normierungsstand zur Verfügung stellen. Der Inhalteanbieter bestimmt das Exportformat.

Der Datenzugriff erfolgt nach Absprache wahlweise im Pull- oder auch im Push-Mechanismus, um einen Abgleich des gesamten Datenbestands als Vollupdate oder inkrementelles Update sicherzustellen. Die Akteure stimmen untereinander einen geeigneten Updatezyklus ab.

Im Anschluss an den Datenimport aus den Lieferantensystemen der Inhalteanbieter erfolgt beim Dienstbetreiber die Transformation in ein normiertes, übergreifendes Datenformat, um die Leistungen der verschiedenen Träger miteinander in Beziehung zu bringen.

Von Inhalteanbietern muss an Dienstbetreiber u.a. geliefert werden:
* Fahr-, Reisezeiten,
* Aufenthaltsdauern, Umsteigezeiten,
* Tarife, Aktionsangebote/Klassen,
* Produkte und Produkteigenschaften (u.a. Größe, Strecken, Standorte, Verfügbarkeiten/Anzahl freie Plätze, Incidents vorhersehbar/nicht vorhersehbar).

Es müssen u.a. folgende Inhalteanbieter Daten und Informationen liefern:

Bahnunternehmen, Schienennetzbetreiber, Busunternehmen, Flug, Charter, Fahrradverkehr, Automobilunternehmen, Autoinformationssysteme, Mietwagen, Taxi, Transferservice, Parkhäuser, Fähren, Versicherungen, Kommunen, Länder (Vorzugsnetz für LKW, Baustellen, Sperrungen, …), Wetterdienste, Feuerwehr, Rettungsdienste, Polizei, Straßenämter, Behörden, Umweltämter, Geodatenbanken, ADAC/ADFC-Verkehrsprognosen, Mobil funkunternehmen, Informationsdienste (Google, Yahoo, Bing, …), POI (TomTom, …), Energieunternehmen, Unterkünfte etc.

Dabei ist es unerlässlich, dass die Inhalteanbieter Daten und Informationen kontinuierlich in höchstmöglicher Qualität innerhalb eines Servicestandards an den Dienstbetreiber der „Multimodalen Reiseinformation“ liefern, um eine dauerhafte Akzeptanz bei der Zielgruppe zu sichern. Die Dienstbetreiber sind dafür zuständig, mit ihrer Komponente „Informationslogik“ die vorhandenen Daten und Informationen für die Zielgruppen so aufzubereiten, dass über eine komplette Reisekette einer Zielperson über beliebige Medien hinweg in sich stimmige Informationen über beliebige Dienstanbieter (Informations- und Vertriebsdienste) an die Zielgruppe gebracht werden können.

Im Fall eines Vertriebs (Buchen, Verkaufen) von Produkten und Dienstleistungen der Inhalteanbieter über die „Multimodale Reiseinformation“ muss von der Komponente „API-Datenanbindung“ unabhängig von den angeschlossenen Dienstanbietern (mobility services wie z. B. Reisebüro, e-Ticket eines Verbunds, Autonavigationssystem) die Datenvalidierung zu
* Verkaufsinformationen, Validierung und Verfügbarkeit von Produkten und Dienstleistungen,
* gekauften Produkten und Dienstleistungen im Warenkorb,
* sicheren Bezahlungsmethoden für Nutzer und Leistungserbringer (Inhalteanbieter) und das
* Verkaufsbelegmanagement zwischen Inhalteanbieter und Kunde (Zielgruppe)
unterstützt werden.

Dies erreicht man am besten durch Nutzung von dedizierten Kundenprofilen, die den nationalen und internationalen Datenschutzstandards entsprechen.

'''API-Serviceanbindung'''

Die Komponente „API-Serviceanbindung“ ist die Schnittstelle vom neutralen Dienstbetreiber der „Multimodalen Reiseinformation“ für ein definiertes Gebiet (z.B. moveBW in Baden-Württemberg, VAO in Österreich) zu Dienstanbietern von Informations- und Vertriebskanälen (mobility services).

Die Komponente (IT-Schicht) „API-Serviceanbindung“ stellt den Dienstanbietern von Informations- und Vertriebsdiensten den Zugriff auf Information und Buchung zur Verfügung. Dabei werden verschiedenste, teilweise vom Nutzer individuell parametrisierbare und reiseabhängige Kriterien berücksichtigt, wie die
* Zeit-/Reisedauer,
* anfallende Kosten und Incentives,
* öffentliche Strategien (Umwelt, Verkehrssteuerung usw.),
* Kontext sowie
* Komforteigenschaften.

Weiterhin gibt es Zielgruppen, für die besondere Kriterien dauerhaft Anwendung finden müssen, wie gesundheitliche Aspekte oder firmenrelevante Interessen (Reiserichtlinien).

Bei der Bedienung der Dienstanbieter mit Informationen aus der „Multimodalen Reiseinformation“ muss darauf geachtet werden, dass neben der Reisemöglichkeit bezogen auf den individuellen Reisewunsch der Zielgruppe auch alternative Angebote (Fußgänger, ÖV, IV) dem Dienstanbietern über die „API-Serviceanbindung“ übergeben werden müssen, wenn öffentliche Strategien es verlangen. Die Auswahl der Reiseroute und -modalitäten obliegt aber weiterhin der Zielgruppe (Kunde).

Ein besonderer Mehrwert stellt generell die Übermittlung von Informationen aus dem Störfallmanagement (Incident Handling) über den zuständigen Dienstbetreiber der „Multimodalen Reiseinformation“ an die Dienstbetreiber von Informations- und Vertriebskanäle dar. Für diese Dienstanbieter gilt hier generell eine besondere Verantwortung für die Reisenden, sowohl
* bei Unfällen oder (Umwelt-)Katastrophen,
* bei Veranstaltungen und Events, wo Sicherheitsvorkehrungen und die Steuerung der Auslastungsverteilung in der Verantwortung der öffentlichen Hand liegt als auch
* bei Krisen oder Krieg.

Durch Informationen aus den Hochrechnungen und Vorhersagen der Inhalteanbieter zur kurz-, mittel- und langfristigen Verkehrsentwicklung in einem Gebiet können von dem Dienstbetreiber der „Multimodalen Reise“ abgestimmt mit den regionalen und überregionalen Strategien (ermittelt aus der Komponente „Informationslogik“). Informationen hinsichtlich zu erwartender Staus, Störungen und Überlastungen über die „API-Serviceanbindung“ an die Dienstanbieter übergeben werden. Damit können frühzeitig die Zielgruppen von den Informations- und Vertriebsdiensten angesprochen und informiert sowie Änderungen im Mobilitätsverhalten der Zielgruppen motiviert werden. Die Rückmeldung der Akzeptanz der Zielgruppen auf die Informationen erfolgt ebenso über die „API-Serviceanbindung“ an den Dienstbetreiber der „Multimodalen Reiseinformation“ zur Verwendung in den Komponenten Informations- und Vertriebslogik.

Über die Erstellung von Statistiken bzw. Business Intelligence (BI)-Auswertungen werden sowohl
* die Institutionen der öffentliche Hand (z.B. Verkehrsplanung, Verkehrsleitzentralen) in die Lage versetzt, ihre öffentlichen Strategien bei Planung und Betrieb zu optimieren, als auch
* die Inhalteanbieter (z.B. Veranstalter, Verkehrsunternehmen) und Dienstanbieter in die Lage versetzt, ihre Produkte und Dienste auf die Gegebenheiten eines dynamischen Verkehrsablaufs situativ anzupassen und damit ihren Vertrieb zu optimieren.

'''Informationslogik'''

Die Komponente (IT-Schicht) „Informationslogik“ verarbeitet
* die Daten und Informationen der unterschiedlichen Inhalteanbieter,
* unter Beachtung der regionalen und überregionalen geltenden öffentlichen Strategien der Gebietskörperschaften,
* situativer Meldungen an spezifischen Punkten der Reisekette und
* relevanten Faktoren aus dem Vertrieb (z. B. Inzentivs) sowie
* den aktuellen Erkenntnissen aus den Informations- und Vertriebsdiensten der Dienstanbieter hinsichtlich der Akzeptanz von Informationen aus der „Multimodalen Reiseinformation“.

Ein Ziel der Informationslogik ist es, optimierte Reiseketten, welche nutzerspezifische Präferenzen sowie unterschiedliche Verkehrsmittel berücksichtigen, zu berechnen und diese Informationen in vergleichbarer, integrativer und nachvollziehbarer Weise den unterschiedlichen Zielgruppen zur Verfügung zu stellen. Die Zielgruppen werden über regionale und globale Dienstanbieter (mobility services) angesprochen.

Aufgrund der Vielzahl an Akteuren und Systemen im Verkehr bzw. der Reisebranche sowie ihrer Differenzierung nach Räumen muss mit einer „Multimodalen Reiseinformation“ in Deutschland auch eine intelligente Vernetzung der zuständigen Teilsysteme (der Akteure im Wirkungsraum) realisiert werden. Hierzu benötig die Komponente der „Informationslogik“ folgende serverseitig ausgeführten Teilkomponenten.

Die ''Intermodale Logik'' integriert die aus der Nutzerschnittstelle übergebenen Daten, Informationen und Parameter (z.B. Fahrplanauskunft / Tarifauskunft, Verkehrsmeldungen und Steuerungsstrategien öffentlicher Partner, Landkreise, Gemeinden, regionaler Strategiemanager, Floating-Car-Daten, API) über die „API-Datenanbindung“. Aus den regionalen Daten und Verkehrsmanagementstrategien werden auf den Verkehrsnetzen Streckenwiderstände modelliert, die die Grundlage für das modale und intermodale Routing sind. Hierzu muss die Verkehrslage situationsabhängig berechnet und prognostiziert werden. Bei der Aktivierung einer Strategie (z.B. Umleitungsempfehlung oder P+R-Nutzung) werden in der intermodalen Logik die relevanten Netzelemente des strategischen Netzes in der Routenberechnung attraktiver gewichtet.

Die Intermodale Logik berechnet auf der Grundlage der aggregierten modalen Reisewege der externen ÖV-Router, der relevanten MIV-, Fahrrad- und Fußgänger-Router sowie auf Basis von Tarifinformation der jeweiligen Verkehrsmittel, somit Verfügbarkeiten. Sie ermittelt darauf nach nutzerspezifischen Reisepräferenzen und öffentlichen Strategien eine optimierte intermodale Reisekette. Die intermodale Reiseplanung kann unter Berücksichtigung situativer zielgruppenspezifischer Bedürfnisse erfolgen wie z.B. die schnellste, günstigste oder ökologischste, emissionsfreieste bzw. verkehrsoptimalste Route. Die Berechnungsergebnisse der Intermodalen Logik werden über die API „Serviceanbindung“ den Dienstanbietern zur Verfügung gestellt, so dass regionale Partner und Aufgabenträger auch die Steuerungsstrategien in ihren Systemen weiterverarbeiten können.

Der ''POI- und Adressservice'' integriert dazu alle punktbezogenen Informationen wie Adressen, Standorte von Sharing-Angebote, Haltestellen, Parkgaragen / P+R, Ladestationen etc., die an die „API-Datenanbindung“ angeschlossen sind, in ein einheitliches Datenformat und stellt diese über Web-Service-Schnittstellen internen und externen Diensten zur Verfügung (z.B. BW API „Serviceanbindung“). Die Zusammenführung, Harmonisierung und Referenzierung aller Daten muss auf einer gleichen Netzgrundlage, dem bundesweiten Integrationsnetz Straße stattfinden. Es bildet somit die Grundlage für die bundesweite Weiterverarbeitung regionaler Daten und Strategien.

Mit der Anbindung der gebietsspezifischen Dienstanbieter für die „Multimodale Reiseinformation“ an den Mobilitätsdatenmarktplatz MDM der Bundesanstalt für Straßenwesen über die „API-Serviceanbindung“ wird sichergestellt, dass Verkehrsmeldungen und Strategien aus dezidierten Gebieten an den MDM weitergeleitet und damit ausgetauscht werden können. Hier entsteht somit ein weiterer Mehrwert im Bereich der Datenverwendung auf bundesweiter Ebene. Die Anbindung an den MDM muss dabei in Abstimmung mit den Inhalteanbietern festgelegt werden.

Auf regionaler Ebene müssen ''Pflegewerkzeuge'' (Client) die Erfassung, Verortung von Verkehrsmeldungen und Verkehrslenkungs- und Steuerungsstrategien ermöglichen. Die Pflegewerkzeuge müssen mandantenfähig sein, so dass jeder Akteur des regionalen Verkehrsmanagements seine Strategien selber einpflegen kann. Pflegewerkzeuge sind damit eine wichtige Teilkomponente zur Etablierung eines regionalen (dynamischen) Verkehrsmanagements.

Damit wird es im Rahmen der „Informationslogik“ möglich, dass die von der Intermodalen Logik unter Berücksichtigung regionaler und individueller Strategien berechnete multimodale Reise von den eigenen Routerinstanzen der Dienstleister (App-Service, Autonavigationsgerät) übernommen wird und in ihr Routing unverfälscht eingebunden wird. Damit kann der Einwirkungsbereich auf das Mobilitätsverhalten aller Zielgruppen vergrößert werden.

'''Vertriebslogik'''

Die Komponente (IT-Schicht) „Vertriebslogik“ verarbeitet Buchungs-, Stornierungs- und Bezahlvorgänge von Produkten, Dienstleistungen oder Auskünften (Informationen) der Inhalteanbieter.

Aus Sicht der öffentlichen Hand (Auskunftspflicht) bedeutet „Multimodale Reiseinformation“ die alleinige Realisierung aller Komponenten in der Infor mationslogistik. Eine Akzeptanz und dauerhafte Nutzung der IVS-Referenzarchitektur „Multimodale Reiseinformation“ wird sich nach heutigen Erkenntnissen (z.B. VAO) nur einstellen, wenn sich die angezeigten Verkehrsanbindungen auch einfach und verlässlich buchen lassen. Dies ist notwendig, um
* eine Verbindlichkeit mit der Reiseinformation zu verknüpfen (z.B. Umstieg auf den ÖPNV am P+R-Platz durch Kauf der Fahrberechtigung im ÖPNV und des Einfahrtberechtigung in den P+R-Platz vor oder während der Reise),
* die freie Wirtschaft zu endkundenorientierten Angeboten und Lösungen zu bewegen und
* um die Prozesse rund um die Dienstreise und deren Abrechnung zu automatisieren bzw. zu optimieren.

Um entlang von Reiseketten nicht nur diskriminierungsfrei alle Informationen über die möglichen Produkte und Dienstleistungen anbieten zu können, muss auch die Buchung und der Kauf dieser angebotenen Produkte und Dienstleistungen diskriminierungsfrei für alle Zielgruppen möglich sein. In Anbetracht von z.B. einem unerwarteten Ereignis auf einer Reise wird damit gewährleistet, dass der Kunde nicht nur Alternativen aufgezeigt bekommt, sondern diese auch direkt wahrnehmen kann, ohne einen Medienbruch und damit neue Unsicherheiten auf sich zu nehmen. Die Zielgruppen (Nutzer) sparen Zeit, sie bekommen vereinfachte Prozesse vor und während der Reise und somit Vertrauen und Sicherheit in die „Multimodale Reiseinformation“.

Des Weiteren können durch die Einbindung der Komponente „Vertriebslogik“ in die Architekturvision der „Multimodalen Reiseinformation“ auch kommerzielle Elemente wie Inzentivierung, Gamification oder Anreizprogramme zur Unterstützung der Akzeptanz öffentlicher Strategien (z.B. Umsteigen auf den Öffentlichen Verkehr) bei Zielgruppen genutzt werden. In der weiteren Folge lassen sich damit BI-Möglichkeiten zur Erstellung von Statistiken über Reisekosten und deren Veränderung über die Jahre (Kostensteigerung) abbilden. Damit können die Zielgruppen finanzielle und zeitliche Steuerungsmaßnahmen für sich und ihr Mobilitätsverhalten einfach erkennen und ableiten.

Eine IVS-Referenzarchitektur „Multimodale Reiseinformation“ darf sich daher nicht nur auf die Informationslogik zurückziehen, sondern muss auch bei der Komponente „Vertriebslogik“ einen diskriminierungsfreien Einsatz angemessen vorsehen und beschreiben.

'''Data Hub'''

Die Komponente (IT-Schicht) „Data Hub“ stellt die serverseitige Organisationseinheit der Komponenten der „Multimodalen Reiseinformation“ dar. Es beinhaltet u.a.
* Datenmanagement und Datensicherheit (Überlassung, Weitergabe, Nutzung, Regeln, Status)
* Schnittstellenmanagement (Status, Version)
* System Management (Speicher, Verteilung)
* Lastmanagement (Anfragen, Verteilung)
* Hazardmanagement (Angriffe)
* Protokollwesen (LOG-Files, BI-Nutzung)

Der Data Hub erlaubt die kontrollierte Anbindung an die Big-Data-Analystik und an Data-Ware-Houses durch Tracing- und Tracking-Prozesse des Datenflusses über den/die neutralen Dienstbetreiber „Multimodale Reiseinformation“. Dadurch können zukünftig auf Seiten der
* öffentlichen Hand Planungs- und Verkehrssteuerungsprozesse optimiert und auf Seiten der
* Privatwirtschaft Mehrwertdienste entwickelt und an den Endnutzer verkauft werden.

Kap. 8 Entwicklung der Architekturvision

2016-06-20T09:21:17Z

Weber: /* Entwicklung der Architekturvision */

== Entwicklung der Architekturvision ==

Aufbauend auf dem Wirkungsbereich für die IVS-Referenzarchitektur „Multimodale Reiseinformation“ können für die Beschreibung der Architekturvision der „Multimodalen Reiseinformation“ (Blauer Bereich in Abbildung 2)

* die maßgebenden Komponenten sowie
* ihre Beiträge zur Zielerreichung einer funktionsfähigen „Multimodalen Reiseinformation“ in Deutschland

identifiziert und beschrieben werden.

[[Datei:Komponenten der IVS-Referenzarchitektur Multimodale Reiseinformation_Konsortium MRK-AMADEUS.JPG|700px|thumb|centre]]

'''Abbildung 2''' Komponenten der IVS-Referenzarchitektur „Multimodale Reiseinformation“

'''API-Datenanbindung'''

Die Komponente (IT-Schicht) „API-Datenanbindung“ schließt über diverse technische Transportprotokolle die Systeme der Inhalteanbieter mit dem Zweck der Zustellung von Daten und Informationen an den für ein definiertes Gebiet zuständigen und neutralen Dienstbetreiber der „Multimodalen Reiseinformation“ (z. B. moveBW in Baden-Württemberg, VAO in Österreich) an. Ein Inhalteanbieter kann auch als Aggregator eigene Datenbestände als Informationen (z.B. Fahrplanauskunft eines Verkehrsverbunds, MDM) an der „API-Datenanbindung“ mit einem gewissen Normierungsstand zur Verfügung stellen. Der Inhalteanbieter bestimmt das Exportformat.

Der Datenzugriff erfolgt nach Absprache wahlweise im Pull- oder auch im Push-Mechanismus, um einen Abgleich des gesamten Datenbestands als Vollupdate oder inkrementelles Update sicherzustellen. Die Akteure stimmen untereinander einen geeigneten Updatezyklus ab.

Im Anschluss an den Datenimport aus den Lieferantensystemen der Inhalteanbieter erfolgt beim Dienstbetreiber die Transformation in ein normiertes, übergreifendes Datenformat, um die Leistungen der verschiedenen Träger miteinander in Beziehung zu bringen.

Von Inhalteanbietern muss an Dienstbetreiber u.a. geliefert werden:
* Fahr-, Reisezeiten,
* Aufenthaltsdauern, Umsteigezeiten,
* Tarife, Aktionsangebote/Klassen,
* Produkte und Produkteigenschaften (u.a. Größe, Strecken, Standorte, Verfügbarkeiten/Anzahl freie Plätze, Incidents vorhersehbar/nicht vorhersehbar).

Es müssen u.a. folgende Inhalteanbieter Daten und Informationen liefern:

Bahnunternehmen, Schienennetzbetreiber, Busunternehmen, Flug, Charter, Fahrradverkehr, Automobilunternehmen, Autoinformationssysteme, Mietwagen, Taxi, Transferservice, Parkhäuser, Fähren, Versicherungen, Kommunen, Länder (Vorzugsnetz für LKW, Baustellen, Sperrungen, …), Wetterdienste, Feuerwehr, Rettungsdienste, Polizei, Straßenämter, Behörden, Umweltämter, Geodatenbanken, ADAC/ADFC-Verkehrsprognosen, Mobil funkunternehmen, Informationsdienste (Google, Yahoo, Bing, …), POI (TomTom, …), Energieunternehmen, Unterkünfte etc.

Dabei ist es unerlässlich, dass die Inhalteanbieter Daten und Informationen kontinuierlich in höchstmöglicher Qualität innerhalb eines Servicestandards an den Dienstbetreiber der „Multimodalen Reiseinformation“ liefern, um eine dauerhafte Akzeptanz bei der Zielgruppe zu sichern. Die Dienstbetreiber sind dafür zuständig, mit ihrer Komponente „Informationslogik“ die vorhandenen Daten und Informationen für die Zielgruppen so aufzubereiten, dass über eine komplette Reisekette einer Zielperson über beliebige Medien hinweg in sich stimmige Informationen über beliebige Dienstanbieter (Informations- und Vertriebsdienste) an die Zielgruppe gebracht werden können.

Im Fall eines Vertriebs (Buchen, Verkaufen) von Produkten und Dienstleistungen der Inhalteanbieter über die „Multimodale Reiseinformation“ muss von der Komponente „API-Datenanbindung“ unabhängig von den angeschlossenen Dienstanbietern (mobility services wie z. B. Reisebüro, e-Ticket eines Verbunds, Autonavigationssystem) die Datenvalidierung zu
* Verkaufsinformationen, Validierung und Verfügbarkeit von Produkten und Dienstleistungen,
* gekauften Produkten und Dienstleistungen im Warenkorb,
* sicheren Bezahlungsmethoden für Nutzer und Leistungserbringer (Inhalteanbieter) und das
* Verkaufsbelegmanagement zwischen Inhalteanbieter und Kunde (Zielgruppe)
unterstützt werden.

Dies erreicht man am besten durch Nutzung von dedizierten Kundenprofilen, die den nationalen und internationalen Datenschutzstandards entsprechen.

'''API-Serviceanbindung'''

Die Komponente „API-Serviceanbindung“ ist die Schnittstelle vom neutralen Dienstbetreiber der „Multimodalen Reiseinformation“ für ein definiertes Gebiet (z.B. moveBW in Baden-Württemberg, VAO in Österreich) zu Dienstanbietern von Informations- und Vertriebskanälen (mobility services).

Die Komponente (IT-Schicht) „API-Serviceanbindung“ stellt den Dienstanbietern von Informations- und Vertriebsdiensten den Zugriff auf Information und Buchung zur Verfügung. Dabei werden verschiedenste, teilweise vom Nutzer individuell parametrisierbare und reiseabhängige Kriterien berücksichtigt, wie die
* Zeit-/Reisedauer,
* anfallende Kosten und Incentives,
* öffentliche Strategien (Umwelt, Verkehrssteuerung usw.),
* Kontext sowie
* Komforteigenschaften.

Weiterhin gibt es Zielgruppen, für die besondere Kriterien dauerhaft Anwendung finden müssen, wie gesundheitliche Aspekte oder firmenrelevante Interessen (Reiserichtlinien).

Bei der Bedienung der Dienstanbieter mit Informationen aus der „Multimodalen Reiseinformation“ muss darauf geachtet werden, dass neben der Reisemöglichkeit bezogen auf den individuellen Reisewunsch der Zielgruppe auch alternative Angebote (Fußgänger, ÖV, IV) dem Dienstanbietern über die „API-Serviceanbindung“ übergeben werden müssen, wenn öffentliche Strategien es verlangen. Die Auswahl der Reiseroute und -modalitäten obliegt aber weiterhin der Zielgruppe (Kunde).

Ein besonderer Mehrwert stellt generell die Übermittlung von Informationen aus dem Störfallmanagement (Incident Handling) über den zuständigen Dienstbetreiber der „Multimodalen Reiseinformation“ an die Dienstbetreiber von Informations- und Vertriebskanäle dar. Für diese Dienstanbieter gilt hier generell eine besondere Verantwortung für die Reisenden, sowohl
* bei Unfällen oder (Umwelt-)Katastrophen,
* bei Veranstaltungen und Events, wo Sicherheitsvorkehrungen und die Steuerung der Auslastungsverteilung in der Verantwortung der öffentlichen Hand liegt als auch
* bei Krisen oder Krieg.

Durch Informationen aus den Hochrechnungen und Vorhersagen der Inhalteanbieter zur kurz-, mittel- und langfristigen Verkehrsentwicklung in einem Gebiet können von dem Dienstbetreiber der „Multimodalen Reise“ abgestimmt mit den regionalen und überregionalen Strategien (ermittelt aus der Komponente „Informationslogik“). Informationen hinsichtlich zu erwartender Staus, Störungen und Überlastungen über die „API-Serviceanbindung“ an die Dienstanbieter übergeben werden. Damit können frühzeitig die Zielgruppen von den Informations- und Vertriebsdiensten angesprochen und informiert sowie Änderungen im Mobilitätsverhalten der Zielgruppen motiviert werden. Die Rückmeldung der Akzeptanz der Zielgruppen auf die Informationen erfolgt ebenso über die „API-Serviceanbindung“ an den Dienstbetreiber der „Multimodalen Reiseinformation“ zur Verwendung in den Komponenten Informations- und Vertriebslogik.

Über die Erstellung von Statistiken bzw. Business Intelligence (BI)-Auswertungen werden sowohl
* die Institutionen der öffentliche Hand (z.B. Verkehrsplanung, Verkehrsleitzentralen) in die Lage versetzt, ihre öffentlichen Strategien bei Planung und Betrieb zu optimieren, als auch
* die Inhalteanbieter (z.B. Veranstalter, Verkehrsunternehmen) und Dienstanbieter in die Lage versetzt, ihre Produkte und Dienste auf die Gegebenheiten eines dynamischen Verkehrsablaufs situativ anzupassen und damit ihren Vertrieb zu optimieren.

'''Informationslogik'''

Die Komponente (IT-Schicht) „Informationslogik“ verarbeitet
* die Daten und Informationen der unterschiedlichen Inhalteanbieter,
* unter Beachtung der regionalen und überregionalen geltenden öffentlichen Strategien der Gebietskörperschaften,
* situativer Meldungen an spezifischen Punkten der Reisekette und
* relevanten Faktoren aus dem Vertrieb (z. B. Inzentivs) sowie
* den aktuellen Erkenntnissen aus den Informations- und Vertriebsdiensten der Dienstanbieter hinsichtlich der Akzeptanz von Informationen aus der „Multimodalen Reiseinformation“.

Ein Ziel der Informationslogik ist es, optimierte Reiseketten, welche nutzerspezifische Präferenzen sowie unterschiedliche Verkehrsmittel berücksichtigen, zu berechnen und diese Informationen in vergleichbarer, integrativer und nachvollziehbarer Weise den unterschiedlichen Zielgruppen zur Verfügung zu stellen. Die Zielgruppen werden über regionale und globale Dienstanbieter (mobility services) angesprochen.

Aufgrund der Vielzahl an Akteuren und Systemen im Verkehr bzw. der Reisebranche sowie ihrer Differenzierung nach Räumen muss mit einer „Multimodalen Reiseinformation“ in Deutschland auch eine intelligente Vernetzung der zuständigen Teilsysteme (der Akteure im Wirkungsraum) realisiert werden. Hierzu benötig die Komponente der „Informationslogik“ folgende serverseitig ausgeführten Teilkomponenten.

Die ''Intermodale Logik'' integriert die aus der Nutzerschnittstelle übergebenen Daten, Informationen und Parameter (z.B. Fahrplanauskunft / Tarifauskunft, Verkehrsmeldungen und Steuerungsstrategien öffentlicher Partner, Landkreise, Gemeinden, regionaler Strategiemanager, Floating-Car-Daten, API) über die „API-Datenanbindung“. Aus den regionalen Daten und Verkehrsmanagementstrategien werden auf den Verkehrsnetzen Streckenwiderstände modelliert, die die Grundlage für das modale und intermodale Routing sind. Hierzu muss die Verkehrslage situationsabhängig berechnet und prognostiziert werden. Bei der Aktivierung einer Strategie (z.B. Umleitungsempfehlung oder P+R-Nutzung) werden in der intermodalen Logik die relevanten Netzelemente des strategischen Netzes in der Routenberechnung attraktiver gewichtet.

Die Intermodale Logik berechnet auf der Grundlage der aggregierten modalen Reisewege der externen ÖV-Router, der relevanten MIV-, Fahrrad- und Fußgänger-Router sowie auf Basis von Tarifinformation der jeweiligen Verkehrsmittel, somit Verfügbarkeiten. Sie ermittelt darauf nach nutzerspezifischen Reisepräferenzen und öffentlichen Strategien eine optimierte intermodale Reisekette. Die intermodale Reiseplanung kann unter Berücksichtigung situativer zielgruppenspezifischer Bedürfnisse erfolgen wie z.B. die schnellste, günstigste oder ökologischste, emissionsfreieste bzw. verkehrsoptimalste Route. Die Berechnungsergebnisse der Intermodalen Logik werden über die API „Serviceanbindung“ den Dienstanbietern zur Verfügung gestellt, so dass regionale Partner und Aufgabenträger auch die Steuerungsstrategien in ihren Systemen weiterverarbeiten können.

Der ''POI- und Adressservice'' integriert dazu alle punktbezogenen Informationen wie Adressen, Standorte von Sharing-Angebote, Haltestellen, Parkgaragen / P+R, Ladestationen etc., die an die „API-Datenanbindung“ angeschlossen sind, in ein einheitliches Datenformat und stellt diese über Web-Service-Schnittstellen internen und externen Diensten zur Verfügung (z.B. BW API „Serviceanbindung“). Die Zusammenführung, Harmonisierung und Referenzierung aller Daten muss auf einer gleichen Netzgrundlage, dem bundesweiten Integrationsnetz Straße stattfinden. Es bildet somit die Grundlage für die bundesweite Weiterverarbeitung regionaler Daten und Strategien.

Mit der Anbindung der gebietsspezifischen Dienstanbieter für die „Multimodale Reiseinformation“ an den Mobilitätsdatenmarktplatz MDM der Bundesanstalt für Straßenwesen über die „API-Serviceanbindung“ wird sichergestellt, dass Verkehrsmeldungen und Strategien aus dezidierten Gebieten an den MDM weitergeleitet und damit ausgetauscht werden können. Hier entsteht somit ein weiterer Mehrwert im Bereich der Datenverwendung auf bundesweiter Ebene. Die Anbindung an den MDM muss dabei in Abstimmung mit den Inhalteanbietern festgelegt werden.

Auf regionaler Ebene müssen ''Pflegewerkzeuge'' (Client) die Erfassung, Verortung von Verkehrsmeldungen und Verkehrslenkungs- und Steuerungsstrategien ermöglichen. Die Pflegewerkzeuge müssen mandantenfähig sein, so dass jeder Akteur des regionalen Verkehrsmanagements seine Strategien selber einpflegen kann. Pflegewerkzeuge sind damit eine wichtige Teilkomponente zur Etablierung eines regionalen (dynamischen) Verkehrsmanagements.

Damit wird es im Rahmen der „Informationslogik“ möglich, dass die von der Intermodalen Logik unter Berücksichtigung regionaler und individueller Strategien berechnete multimodale Reise von den eigenen Routerinstanzen der Dienstleister (App-Service, Autonavigationsgerät) übernommen wird und in ihr Routing unverfälscht eingebunden wird. Damit kann der Einwirkungsbereich auf das Mobilitätsverhalten aller Zielgruppen vergrößert werden.

'''Vertriebslogik'''

Die Komponente (IT-Schicht) „Vertriebslogik“ verarbeitet Buchungs-, Stornierungs- und Bezahlvorgänge von Produkten, Dienstleistungen oder Auskünften (Informationen) der Inhalteanbieter.

Aus Sicht der öffentlichen Hand (Auskunftspflicht) bedeutet „Multimodale Reiseinformation“ die alleinige Realisierung aller Komponenten in der Infor mationslogistik. Eine Akzeptanz und dauerhafte Nutzung der IVS-Referenzarchitektur „Multimodale Reiseinformation“ wird sich nach heutigen Erkenntnissen (z.B. VAO) nur einstellen, wenn sich die angezeigten Verkehrsanbindungen auch einfach und verlässlich buchen lassen. Dies ist notwendig, um
* eine Verbindlichkeit mit der Reiseinformation zu verknüpfen (z.B. Umstieg auf den ÖPNV am P+R-Platz durch Kauf der Fahrberechtigung im ÖPNV und des Einfahrtberechtigung in den P+R-Platz vor oder während der Reise),
* die freie Wirtschaft zu endkundenorientierten Angeboten und Lösungen zu bewegen und
* um die Prozesse rund um die Dienstreise und deren Abrechnung zu automatisieren bzw. zu optimieren.

Um entlang von Reiseketten nicht nur diskriminierungsfrei alle Informationen über die möglichen Produkte und Dienstleistungen anbieten zu können, muss auch die Buchung und der Kauf dieser angebotenen Produkte und Dienstleistungen diskriminierungsfrei für alle Zielgruppen möglich sein. In Anbetracht von z.B. einem unerwarteten Ereignis auf einer Reise wird damit gewährleistet, dass der Kunde nicht nur Alternativen aufgezeigt bekommt, sondern diese auch direkt wahrnehmen kann, ohne einen Medienbruch und damit neue Unsicherheiten auf sich zu nehmen. Die Zielgruppen (Nutzer) sparen Zeit, sie bekommen vereinfachte Prozesse vor und während der Reise und somit Vertrauen und Sicherheit in die „Multimodale Reiseinformation“.

Des Weiteren können durch die Einbindung der Komponente „Vertriebslogik“ in die Architekturvision der „Multimodalen Reiseinformation“ auch kommerzielle Elemente wie Inzentivierung, Gamification oder Anreizprogramme zur Unterstützung der Akzeptanz öffentlicher Strategien (z.B. Umsteigen auf den Öffentlichen Verkehr) bei Zielgruppen genutzt werden. In der weiteren Folge lassen sich damit BI-Möglichkeiten zur Erstellung von Statistiken über Reisekosten und deren Veränderung über die Jahre (Kostensteigerung) abbilden. Damit können die Zielgruppen finanzielle und zeitliche Steuerungsmaßnahmen für sich und ihr Mobilitätsverhalten einfach erkennen und ableiten.

Eine IVS-Referenzarchitektur „Multimodale Reiseinformation“ darf sich daher nicht nur auf die Informationslogik zurückziehen, sondern muss auch bei der Komponente „Vertriebslogik“ einen diskriminierungsfreien Einsatz angemessen vorsehen und beschreiben.

'''Data Hub'''

Die Komponente (IT-Schicht) „Data Hub“ stellt die serverseitige Organisationseinheit der Komponenten der „Multimodalen Reiseinformation“ dar. Es beinhaltet u.a.
* Datenmanagement und Datensicherheit (Überlassung, Weitergabe, Nutzung, Regeln, Status)
* Schnittstellenmanagement (Status, Version)
* System Management (Speicher, Verteilung)
* Lastmanagement (Anfragen, Verteilung)
* Hazardmanagement (Angriffe)
* Protokollwesen (LOG-Files, BI-Nutzung)

Der Data Hub erlaubt die kontrollierte Anbindung an die Big-Data-Analystik und an Data-Ware-Houses durch Tracing- und Tracking-Prozesse des Datenflusses über den/die neutralen Dienstbetreiber „Multimodale Reiseinformation“. Dadurch können zukünftig auf Seiten der
* öffentlichen Hand Planungs- und Verkehrssteuerungsprozesse optimiert und auf Seiten der
* Privatwirtschaft Mehrwertdienste entwickelt und an den Endnutzer verkauft werden.

Kap. 7 Architekturprinzipien und Geschäftsprinzipien

2016-06-20T09:20:28Z

Weber: /* Bestätigung und Ausarbeitung von Architekturprinzipien, einschließlich Geschäftsprinzipien */

== Bestätigung und Ausarbeitung von Architekturprinzipien, einschließlich Geschäftsprinzipien ==

Die Multimodale Reiseinformation stellt mit ihren zahlreichen Aspekten wie z.B.:

* Inhalteanbietern, Dienstbetreibern und Dienstanbietern
* gemein- und privatwirtschaftlichen Akteuren
* Informations- und Vertriebslogistik sowie
* unterschiedlichen Datenmodalitäten (Qualität, Quantität und Intensität der Datenlieferung)

eine sehr komplexe Domäne dar.

Architekturprinzipien helfen dabei diese Komplexität zu beherrschen. Entstanden aus erfolgreichen Strategien, komprimieren Prinzipien Inhalte zu anwendbaren und verständlichen Handlungsempfehlungen. Es ist empfehlenswert, dass alle Prinzipien gleichzeitig berücksichtigt werden, um eine gute IVS-Referenzarchitektur zu erstellen.

Als grundlegende Qualitätsmerkmale für die Architekturprinzipien sollen gelten:

* '''Einfachheit:'''
** Einzelne Elemente der Architektur sollen möglichst einfach sein
** Das Zusammenspiel der Elemente der Architektur soll einfach sein
* '''Klarheit / Verständlichkeit:'''
** Leichte Erkennbarkeit der Aufgaben einzelner Elemente
** Leichte Erkennbarkeit der Interaktion einzelner Elemente
* '''Wirtschaftlichkeit:'''
** Einzelne Elemente sollen möglichst selbst tragfähig sein
** Nicht selbst tragfähige aber notwendige Elemente sollen gemeinwirtschaftlich tragfähig sein
* '''Wartbarkeit und Erweiterbarkeit:'''
** Einzelne Elemente sollen ohne Abhängigkeit zu anderen Elementen gewartet und erweitert werden können
** Die Schnittstellen zwischen einzelnen Elementen sollen standardisiert bzw. offen sein, um auf Erweiterungen einzelner Elemente reagieren zu können
* '''Betreibbarkeit:'''
** Leichter Betrieb der einzelner Elemente
** Leichter Betrieb der Interaktion mit anderen Elementen

Grundlagen einer Entwicklung von Prinzipien sind dabei:
* '''Abstraktion:''' Reduktion von Informationen auf wesentliche Informationen
* '''Modularisierung:''' Gliederung nach Zusammengehörigkeit
* '''Kapselung:''' Implizite und schwer erkennbare Abhängigkeiten reduzieren
* '''Hierarchische Dekomposition:''' Gliederung in Ebenen
* '''Begriffliche Dekomposition:''' Gliederung nach Eigenschaften und Aspekten
* '''Einheitlichkeit:''' Strukturen, Schemata, Muster, Vorgehensweisen beibehalten

bezogen auf die Domäne „Multimodale Reiseinformation“ ergeben sich damit acht anwendbare Architekturprinzipien:
* '''Trennung von Zuständigkeiten:'''
** Jeder Akteur sollte möglichst nur für eine Aufgabe zuständig sein
** Genaue Definition und Abgrenzung von Aufgaben gegenüber anderen Akteuren
* '''Minimierung von Abhängigkeiten:'''
** Minimierung der Abhängigkeiten zwischen den Akteuren und ihren Systemen (z.B. durch Zusammenfassen von Komponenten oder durch Entkoppelung)
** Vermeidung von zyklischen Abhängigkeiten (z.B. Verkauf)
* '''Geheimnisprinzip:'''
** Kapselung von Wissen und Logik in Teilsystemen
** Akteure (Nutzer), die mit einem Teilsystem interagieren, müssen nur das Notwendige kennen, um sich anschließen und interagieren zu können
** Für die korrespondierenden Akteure sollen Teilsysteme eine spezielle Sicht auf die verwendete Funktionalität bereit stellen
* '''Homogenität:'''
** Vergleichbare Problem- und Aufgabenstellungen sind auf ähnliche Weise zu lösen
** Es sollen gleiche Größen und Einheiten sowie Begriffe verwendet werden
* '''Redundanzfreiheit:'''
** In der IVS-Referenzarchitektur sind gleiche Funktionalitäten zu identifizieren, zu verallgemeinern und wieder verwendbar zur Verfügung zu stellen
* '''Schichtenbildung:'''
** Unterteilung der Teilsysteme in Schichten
** Eine Schicht bündelt Teilsysteme mit ähnlichem Aufbau bzw. ähnlicher Grundfunktionalität
** Eine Schicht darf nur mit Systemen innerhalb ihrer eigenen Schicht oder einer nächsten darunter oder darüber liegenden Schicht interagieren
* '''Vertragsbasierter Entwurf:'''
** Vollständige Beschreibung der Interaktion der Teilsysteme und Akteure über Schnittstellen (Typ, Inhalt, Bedingung)
** Schnittstelle ist ein Vertrag zwischen Akteuren (z.B. Anbieter und Abnehmer von Daten, Informationen) und beschreibt alles, was der Abnehmer wissen muss, um mit dem Anbieter zu interagieren.
** Schnittstellen sollten spezifisch wenn nötig und so generell wie möglich beschrieben werden. Schnittstellen müssen den Austausch von Akteuren und Teilsystemen ermöglichen
* '''Datenhoheit:'''
** Festlegung einer einheitlichen Struktur / Modellierung der Daten.
** Festlegung der Verantwortlichkeit über einen Ausschnitt des Datenhaushalts an dezidierte Akteure, die ebenfalls für die Integrität und die Konsistenz dieser Daten sorgen

Kap. 7 Architekturprinzipien und Geschäftsprinzipien

2016-06-20T09:18:43Z

Weber: /* Bestätigung und Ausarbeitung von Architekturprinzipien, einschließlich Geschäftsprinzipien */

== Bestätigung und Ausarbeitung von Architekturprinzipien, einschließlich Geschäftsprinzipien ==

Die Multimodale Reiseinformation stellt mit ihren zahlreichen Aspekten wie z.B.:

* Inhalteanbietern, Dienstbetreibern und Dienstanbietern
* gemein- und privatwirtschaftlichen Akteuren
* Informations- und Vertriebslogistik sowie
* unterschiedlichen Datenmodalitäten (Qualität, Quantität und Intensität der Datenlieferung)

eine sehr komplexe Domäne dar.

Architekturprinzipien helfen dabei diese Komplexität zu beherrschen. Entstanden aus erfolgreichen Strategien, komprimieren Prinzipien Inhalte zu anwendbaren und verständlichen Handlungsempfehlungen. Es ist empfehlenswert, dass alle Prinzipien gleichzeitig berücksichtigt werden, um eine gute IVS-Referenzarchitektur zu erstellen.

Als grundlegende Qualitätsmerkmale für die Architekturprinzipien sollen gelten:

* '''Einfachheit:'''
** Einzelne Elemente der Architektur sollen möglichst einfach sein
** Das Zusammenspiel der Elemente der Architektur soll einfach sein
* '''Klarheit / Verständlichkeit:'''
** Leichte Erkennbarkeit der Aufgaben einzelner Elemente
** Leichte Erkennbarkeit der Interaktion einzelner Elemente
* '''Wirtschaftlichkeit:'''
** Einzelne Elemente sollen möglichst selbst tragfähig sein
** Nicht selbst tragfähige aber notwendige Elemente sollen gemeinwirtschaftlich tragfähig sein
* '''Wartbarkeit und Erweiterbarkeit:'''
** Einzelne Elemente sollen ohne Abhängigkeit zu anderen Elementen gewartet und erweitert werden können
** Die Schnittstellen zwischen einzelnen Elementen sollen standardisiert bzw. offen sein, um auf Erweiterungen einzelner Elemente reagieren zu können
* '''Betreibbarkeit:'''
** Leichter Betrieb der einzelner Elemente
** Leichter Betrieb der Interaktion mit anderen Elementen

Grundlagen einer Entwicklung von Prinzipien sind dabei:
* '''Abstraktion:''' Reduktion von Informationen auf wesentliche Informationen
* '''Modularisierung:''' Gliederung nach Zusammengehörigkeit
* '''Kapselung:''' Implizite und schwer erkennbare Abhängigkeiten reduzieren
* '''Hierarchische Dekomposition:''' Gliederung in Ebenen
* '''Begriffliche Dekomposition:''' Gliederung nach Eigenschaften und Aspekten
* '''Einheitlichkeit:''' Strukturen, Schemata, Muster, Vorgehensweisen beibehalten

bezogen auf die Domäne „Multimodale Reiseinformation“ ergeben sich damit acht anwendbare Architekturprinzipien:
* '''Trennung von Zuständigkeiten:'''
** Jeder Akteur sollte möglichst nur für eine Aufgabe zuständig sein
** Genaue Definition und Abgrenzung von Aufgaben gegenüber anderen Akteuren
* '''Minimierung von Abhängigkeiten:'''
** Minimierung der Abhängigkeiten zwischen den Akteuren und ihren Systemen (z.B. durch Zusammenfassen von Komponenten oder durch Entkoppelung)
** Vermeidung von zyklischen Abhängigkeiten (z.B. Verkauf)
* '''Geheimnisprinzip:'''
** Kapselung von Wissen und Logik in Teilsystemen
** Akteure (Nutzer) die mit einem Teilsystem interagieren, müssen nur das Notwendige kennen, um sich anschließen und interagieren zu können
** Für die korrespondierenden Akteure sollen Teilsysteme eine spezielle Sicht auf die verwendeten Funktionalität bereit stellen
* '''Homogenität:'''
** Vergleichbare Problem- und Aufgabenstellungen sind auf ähnliche Weise zu lösen
** Es sollen gleiche Größen und Einheiten sowie Begriffe verwendet werden
* '''Redundanzfreiheit:'''
** In der IVS-Referenzarchitektur sind gleiche Funktionalitäten zu identifizieren, zu verallgemeinern und wieder verwendbar zur Verfügung zu stellen
* '''Schichtenbildung:'''
** Unterteilung der Teilsysteme in Schichten
** Eine Schicht bündelt Teilsysteme mit ähnlichem Aufbau bzw. ähnlicher Grundfunktionalität
** Eine Schicht darf nur mit Systemen innerhalb ihrer eigenen Schicht oder einer nächsten darunter oder darüber liegenden Schicht interagieren
* '''Vertragsbasierter Entwurf:'''
** Vollständige Beschreibung der Interaktion der Teilsysteme und Akteure über Schnittstellen (Typ, Inhalt, Bedingung)
** Schnittstelle ist ein Vertrag zwischen Akteuren (z.B. Anbieter und Abnehmer von Daten, Informationen) und beschreibt alles, was der Abnehmer wissen muss, um mit dem Anbieter zu interagieren.
** Schnittstellen sollten spezifisch wenn nötig und so generell wie möglich beschrieben werden. Schnittstellen müssen den Austausch von Akteuren und Teilsystemen ermöglichen
* '''Datenhoheit:'''
** Festlegung einer einheitlichen Struktur / Modellierung der Daten.
** Festlegung der Verantwortlichkeit über einen Ausschnitt des Datenhaushalts an dezidierte Akteure, die ebenfalls für die Integrität und die Konsistenz dieser Daten sorgen

Kap. 7 Architekturprinzipien und Geschäftsprinzipien

2016-06-20T09:17:39Z

Weber: /* Bestätigung und Ausarbeitung von Architekturprinzipien, einschließlich Geschäftsprinzipien */

== Bestätigung und Ausarbeitung von Architekturprinzipien, einschließlich Geschäftsprinzipien ==

Die Multimodale Reiseinformation stellt mit ihren zahlreichen Aspekten wie z.B.:

* Inhalteanbietern, Dienstbetreibern und Dienstanbietern
* gemein- und privatwirtschaftlichen Akteuren
* Informations- und Vertriebslogistik sowie
* unterschiedlichen Datenmodalitäten (Qualität, Quantität und Intensität der Datenlieferung)

eine sehr komplexe Domäne dar.

Architekturprinzipien helfen dabei diese Komplexität zu beherrschen. Entstanden aus erfolgreichen Strategien, komprimieren Prinzipien Inhalte zu anwendbaren und verständlichen Handlungsempfehlungen. Es ist empfehlenswert, dass alle Prinzipien gleichzeitig berücksichtigt werden, um eine gute IVS-Referenzarchitektur zu erstellen.

Als grundlegende Qualitätsmerkmale für die Architekturprinzipien sollen gelten:

* '''Einfachheit:'''
** Einzelne Elemente der Architektur sollen möglichst einfach sein
** Das Zusammenspiel der Elemente der Architektur soll einfach sein
* '''Klarheit / Verständlichkeit:'''
** Leichte Erkennbarkeit der Aufgaben einzelner Elemente
** Leichte Erkennbarkeit der Interaktion einzelner Elemente
* '''Wirtschaftlichkeit:'''
** Einzelne Elemente sollen möglichst selbst tragfähig sein
** Nicht selbst tragfähige aber notwendige Elemente sollen gemeinwirtschaftlich tragfähig sein
* '''Wartbarkeit und Erweiterbarkeit:'''
** Einzelne Elemente sollen ohne Abhängigkeit zu anderen Elementen gewartet und erweitert werden können
** Die Schnittstellen zwischen einzelnen Elementen sollen standardisiert bzw. offen sein, um auf Erweiterungen einzelner Elemente reagieren zu können
* '''Betreibbarkeit:'''
** Leichter Betrieb der einzelner Elemente
** Leichter Betrieb der Interaktion mit anderen Elementen

Grundlagen einer Entwicklung von Prinzipien sind dabei:
* '''Abstraktion:''' Reduktion von Informationen auf wesentliche Informationen
* '''Modularisierung:''' Gliederung nach Zusammengehörigkeit
* '''Kapselung:''' Implizite und schwer erkennbare Abhängigkeiten reduzieren
* '''Hierarchische Dekomposition:''' Gliederung in Ebenen
* '''Begriffliche Dekomposition:''' Gliederung nach Eigenschaften und Aspekten
* '''Einheitlichkeit:''' Strukturen, Schemata, Muster, Vorgehensweisen beibehalten

bezogen auf die Domäne „Multimodale Reiseinformation“ ergeben sich damit acht anwendbare Architekturprinzipien:
* '''Trennung von Zuständigkeiten:'''
** Jeder Akteur sollte möglichst nur für eine Aufgabe zuständig sein
** Genaue Definition und Abgrenzung von Aufgaben gegenüber anderen Akteuren
* '''Minimierung von Abhängigkeiten:'''
** Minimierung der Abhängigkeiten zwischen den Akteuren und ihren Systemen (z.B. durch Zusammenfassen von Teilen oder durch Entkoppelung)
** Vermeidung von zyklischen Abhängigkeiten (z.B. Verkauf)
* '''Geheimnisprinzip:'''
** Kapselung von Wissen und Logik in Teilsystemen
** Akteure (Nutzer) die mit einem Teilsystem interagieren, müssen nur das Notwendige kennen, um sich anschließen und interagieren zu können
** Für die korrespondierenden Akteure sollen Teilsysteme eine spezielle Sicht auf die verwendeten Funktionalität bereit stellen
* '''Homogenität:'''
** Vergleichbare Problem- und Aufgabenstellungen sind auf ähnliche Weise zu lösen
** Es sollen gleiche Größen und Einheiten sowie Begriffe verwendet werden
* '''Redundanzfreiheit:'''
** In der IVS-Referenzarchitektur sind gleiche Funktionalitäten zu identifizieren, zu verallgemeinern und wieder verwendbar zur Verfügung zu stellen
* '''Schichtenbildung:'''
** Unterteilung der Teilsysteme in Schichten
** Eine Schicht bündelt Teilsysteme mit ähnlichem Aufbau bzw. ähnlicher Grundfunktionalität
** Eine Schicht darf nur mit Systemen innerhalb ihrer eigenen Schicht oder einer nächsten darunter oder darüber liegenden Schicht interagieren
* '''Vertragsbasierter Entwurf:'''
** Vollständige Beschreibung der Interaktion der Teilsysteme und Akteure über Schnittstellen (Typ, Inhalt, Bedingung)
** Schnittstelle ist ein Vertrag zwischen Akteuren (z.B. Anbieter und Abnehmer von Daten, Informationen) und beschreibt alles, was der Abnehmer wissen muss, um mit dem Anbieter zu interagieren.
** Schnittstellen sollten spezifisch wenn nötig und so generell wie möglich beschrieben werden. Schnittstellen müssen den Austausch von Akteuren und Teilsystemen ermöglichen
* '''Datenhoheit:'''
** Festlegung einer einheitlichen Struktur / Modellierung der Daten.
** Festlegung der Verantwortlichkeit über einen Ausschnitt des Datenhaushalts an dezidierte Akteure, die ebenfalls für die Integrität und die Konsistenz dieser Daten sorgen

Kap. 7 Architekturprinzipien und Geschäftsprinzipien

2016-06-20T09:16:58Z

Weber: /* Bestätigung und Ausarbeitung von Architekturprinzipien, einschließlich Geschäftsprinzipien */

== Bestätigung und Ausarbeitung von Architekturprinzipien, einschließlich Geschäftsprinzipien ==

Die Multimodale Reiseinformation stellt mit ihren zahlreichen Aspekten wie z.B.:

* Inhalteanbietern, Dienstbetreibern und Dienstanbietern
* gemein- und privatwirtschaftlichen Akteuren
* Informations- und Vertriebslogistik sowie
* unterschiedlichen Datenmodalitäten (Qualität, Quantität und Intensität der Datenlieferung)

eine sehr komplexe Domäne dar.

Architekturprinzipien helfen dabei diese Komplexität zu beherrschen. Entstanden aus erfolgreichen Strategien, komprimieren Prinzipien Inhalte zu anwendbaren und verständlichen Handlungsempfehlungen. Es ist empfehlenswert, dass alle Prinzipien gleichzeitig berücksichtigt werden, um eine gute IVS-Referenzarchitektur zu erstellen.

Als grundlegende Qualitätsmerkmale für die Architekturprinzipien sollen gelten:

* '''Einfachheit:'''
** Einzelne Elemente der Architektur sollen möglichst einfach sein
** Das Zusammenspiel der Elemente der Architektur soll einfach sein
* '''Klarheit / Verständlichkeit:'''
** Leichte Erkennbarkeit der Aufgaben einzelner Elemente
** Leichte Erkennbarkeit der Interaktion einzelner Elemente
* '''Wirtschaftlichkeit:'''
** Einzelne Elemente sollen möglichst selbst tragfähig sein
** Nicht selbst tragfähige aber notwendige Elemente sollen gemeinwirtschaftlich tragfähig sein
* '''Wartbarkeit und Erweiterbarkeit:'''
** Einzelne Elemente sollen ohne Abhängigkeit zu anderen Elementen gewartet und erweitert werden können
** Die Schnittstellen zwischen einzelnen Elementen sollen standardisiert bzw. offen sein, um auf Erweiterungen einzelner Elemente reagieren zu können
* '''Betreibbarkeit:'''
** Leichter Betrieb der einzelner Elemente
** Leichter Betrieb der Interaktion mit anderen Elementen

Grundlagen einer Entwicklung von Prinzipien sind dabei:
* '''Abstraktion:''' Reduktion von Informationen auf wesentliche Informationen
* '''Modularisierung:''' Gliederung nach Zusammengehörigkeit
* '''Kapselung:''' Implizite und schwer erkennbare Abhängigkeiten reduzieren
* '''Hierarchische Dekomposition:''' Gliederung in Ebenen
* '''Begriffliche Dekomposition:''' Gliederung nach Eigenschaften und Aspekten
* '''Einheitlichkeit:''' Strukturen, Schemata, Muster, Vorgehensweisen beibehalten

bezogen auf die Domäne „Multimodale Reiseinformation“ ergeben sich damit acht anzuwendende Architekturprinzipien:
* '''Trennung von Zuständigkeiten:'''
** Jeder Akteur sollte möglichst nur für eine Aufgabe zuständig sein
** Genaue Definition und Abgrenzung von Aufgaben gegenüber anderen Akteuren
* '''Minimierung von Abhängigkeiten:'''
** Minimierung der Abhängigkeiten zwischen den Akteuren und ihren Systemen (z.B. durch Zusammenfassen von Teilen oder durch Entkoppelung)
** Vermeidung von zyklischen Abhängigkeiten (z.B. Verkauf)
* '''Geheimnisprinzip:'''
** Kapselung von Wissen und Logik in Teilsystemen
** Akteure (Nutzer) die mit einem Teilsystem interagieren, müssen nur das Notwendige kennen, um sich anschließen und interagieren zu können
** Für die korrespondierenden Akteure sollen Teilsysteme eine spezielle Sicht auf die verwendeten Funktionalität bereit stellen
* '''Homogenität:'''
** Vergleichbare Problem- und Aufgabenstellungen sind auf ähnliche Weise zu lösen
** Es sollen gleiche Größen und Einheiten sowie Begriffe verwendet werden
* '''Redundanzfreiheit:'''
** In der IVS-Referenzarchitektur sind gleiche Funktionalitäten zu identifizieren, zu verallgemeinern und wieder verwendbar zur Verfügung zu stellen
* '''Schichtenbildung:'''
** Unterteilung der Teilsysteme in Schichten
** Eine Schicht bündelt Teilsysteme mit ähnlichem Aufbau bzw. ähnlicher Grundfunktionalität
** Eine Schicht darf nur mit Systemen innerhalb ihrer eigenen Schicht oder einer nächsten darunter oder darüber liegenden Schicht interagieren
* '''Vertragsbasierter Entwurf:'''
** Vollständige Beschreibung der Interaktion der Teilsysteme und Akteure über Schnittstellen (Typ, Inhalt, Bedingung)
** Schnittstelle ist ein Vertrag zwischen Akteuren (z.B. Anbieter und Abnehmer von Daten, Informationen) und beschreibt alles, was der Abnehmer wissen muss, um mit dem Anbieter zu interagieren.
** Schnittstellen sollten spezifisch wenn nötig und so generell wie möglich beschrieben werden. Schnittstellen müssen den Austausch von Akteuren und Teilsystemen ermöglichen
* '''Datenhoheit:'''
** Festlegung einer einheitlichen Struktur / Modellierung der Daten.
** Festlegung der Verantwortlichkeit über einen Ausschnitt des Datenhaushalts an dezidierte Akteure, die ebenfalls für die Integrität und die Konsistenz dieser Daten sorgen

Kap. 7 Architekturprinzipien und Geschäftsprinzipien

2016-06-20T09:15:48Z

Weber: /* Bestätigung und Ausarbeitung von Architekturprinzipien, einschließlich Geschäftsprinzipien */

== Bestätigung und Ausarbeitung von Architekturprinzipien, einschließlich Geschäftsprinzipien ==

Die Multimodale Reiseinformation stellt mit ihren zahlreichen Aspekten wie z.B.:

* Inhalteanbietern, Dienstbetreibern und Dienstanbietern
* gemein- und privatwirtschaftlichen Akteuren
* Informations- und Vertriebslogistik sowie
* unterschiedlichen Datenmodalitäten (Qualität, Quantität und Intensität der Datenlieferung)

eine sehr komplexe Domäne dar.

Architekturprinzipien helfen dabei diese Komplexität zu beherrschen. Entstanden aus erfolgreichen Strategien, komprimieren Prinzipien Inhalte zu anwendbaren und verständlichen Handlungsempfehlungen. Es ist empfehlenswert, dass alle Prinzipien gleichzeitig berücksichtigt werden, um eine gute IVS-Referenzarchitektur zu erstellen.

Als grundlegende Qualitätsmerkmale für die Architekturprinzipien sollen gelten:

* '''Einfachheit:'''
** Einzelne Elemente der Architektur sollen möglichst einfach sein
** Das Zusammenspiel der Elemente der Architektur soll einfach sein
* '''Klarheit / Verständlichkeit:'''
** Leichte Erkennbarkeit der Aufgaben einzelner Elemente
** Leichte Erkennbarkeit der Interaktion einzelner Elemente
* '''Wirtschaftlichkeit:'''
** Einzelne Elemente sollen möglichst selbst tragfähig sein
** Nicht selbst tragfähige aber notwendige Elemente sollen gemeinwirtschaftlich tragfähig sein
* '''Wartbarkeit und Erweiterbarkeit:'''
** Einzelne Elemente sollen ohne Abhängigkeit zu anderen Elementen gewartet und erweitert werden können
** Die Schnittstellen zwischen einzelner Elemente sollen standardisiert bzw. offen sein, um auf Erweiterungen einzelner Elemente angepasst reagieren zu können
* '''Betreibbarkeit:'''
** Leichter Betrieb der einzelner Elemente
** Leichter Betrieb der Interaktion mit anderen Elementen

Grundlagen einer Entwicklung von Prinzipien sind dabei:
* '''Abstraktion:''' Reduktion von Informationen auf wesentliche Informationen
* '''Modularisierung:''' Gliederung nach Zusammengehörigkeit
* '''Kapselung:''' Implizite und schwer erkennbare Abhängigkeiten reduzieren
* '''Hierarchische Dekomposition:''' Gliederung in Ebenen
* '''Begriffliche Dekomposition:''' Gliederung nach Eigenschaften und Aspekten
* '''Einheitlichkeit:''' Strukturen, Schemata, Muster, Vorgehensweisen beibehalten

bezogen auf die Domäne „Multimodale Reiseinformation“ ergeben sich damit acht anzuwendende Architekturprinzipien:
* '''Trennung von Zuständigkeiten:'''
** Jeder Akteur sollte möglichst nur für eine Aufgabe zuständig sein
** Genaue Definition und Abgrenzung von Aufgaben gegenüber anderen Akteuren
* '''Minimierung von Abhängigkeiten:'''
** Minimierung der Abhängigkeiten zwischen den Akteuren und ihren Systemen (z.B. durch Zusammenfassen von Teilen oder durch Entkoppelung)
** Vermeidung von zyklischen Abhängigkeiten (z.B. Verkauf)
* '''Geheimnisprinzip:'''
** Kapselung von Wissen und Logik in Teilsystemen
** Akteure (Nutzer) die mit einem Teilsystem interagieren, müssen nur das Notwendige kennen, um sich anschließen und interagieren zu können
** Für die korrespondierenden Akteure sollen Teilsysteme eine spezielle Sicht auf die verwendeten Funktionalität bereit stellen
* '''Homogenität:'''
** Vergleichbare Problem- und Aufgabenstellungen sind auf ähnliche Weise zu lösen
** Es sollen gleiche Größen und Einheiten sowie Begriffe verwendet werden
* '''Redundanzfreiheit:'''
** In der IVS-Referenzarchitektur sind gleiche Funktionalitäten zu identifizieren, zu verallgemeinern und wieder verwendbar zur Verfügung zu stellen
* '''Schichtenbildung:'''
** Unterteilung der Teilsysteme in Schichten
** Eine Schicht bündelt Teilsysteme mit ähnlichem Aufbau bzw. ähnlicher Grundfunktionalität
** Eine Schicht darf nur mit Systemen innerhalb ihrer eigenen Schicht oder einer nächsten darunter oder darüber liegenden Schicht interagieren
* '''Vertragsbasierter Entwurf:'''
** Vollständige Beschreibung der Interaktion der Teilsysteme und Akteure über Schnittstellen (Typ, Inhalt, Bedingung)
** Schnittstelle ist ein Vertrag zwischen Akteuren (z.B. Anbieter und Abnehmer von Daten, Informationen) und beschreibt alles, was der Abnehmer wissen muss, um mit dem Anbieter zu interagieren.
** Schnittstellen sollten spezifisch wenn nötig und so generell wie möglich beschrieben werden. Schnittstellen müssen den Austausch von Akteuren und Teilsystemen ermöglichen
* '''Datenhoheit:'''
** Festlegung einer einheitlichen Struktur / Modellierung der Daten.
** Festlegung der Verantwortlichkeit über einen Ausschnitt des Datenhaushalts an dezidierte Akteure, die ebenfalls für die Integrität und die Konsistenz dieser Daten sorgen

Kap. 6 Definition des Wirkungsbereichs

2016-06-20T09:13:52Z

Weber: /* Definition des Wirkungsbereichs */

== Definition des Wirkungsbereichs ==

Aufbauend auf der Wertschöpfungskette (siehe z.B. IVS-Rahmenarchitektur im ÖV) und dem damit verbundenen drei Schichtenmodell der Rollen von Akteuren (Inhalteanbieter, Dienstbetreiber, Dienstanbieter) kann für die Domäne „Multimodale Reiseinformation“ eine genaue Zuordnung von Aufgaben und Systemen der Informations- und Vertriebslogistik vorgenommen werden. Die Ausprägung von Aufgaben und Systemen ist dabei von der Rolle und dem Geschäftsmodell des jeweiligen Akteurs abhängig.

Generell muss aber bei der Dimensionierung und Strukturierung des Wirkungsbereichs der IVS-Referenzarchitektur „Multimodale Reiseinformation“ vorgesehen werden, dass drei Strategieebenen in der IVS-Referenzarchitektur Berücksichtigung finden und über unterschiedliche Akteure hinweg vernetzt werden. Diese sind:

* Individuelle Strategien der Zielgruppen auf Ebene der Dienstanbieter (z.B. Autonavigation, private Mobilitäts- und Vertriebsservices für Endkunden wie Online und Offline Reisebüros)
* Öffentliche Strategien auf Ebene der Dienstbetreiber (z.B. Verkehrsmanagement, Mobilitätsmanagement, MDM usw.)
* Betriebliche Strategien auf Ebene der Inhalteanbieter (z.B. Verkehrsunternehmen, Verkehrsleitzentralen, FCD usw.)

Während die Verknüpfung individueller und betrieblicher Strategien seit Jahren zum Status Quo der heutigen Informations- und Vertriebssysteme zählen, ist die Einbindung öffentlicher Strategien aus Stadt und Land in den Informations- und Vertriebssystemen der öffentlichen Hand und der Privaten erst am Anfang. Gerade unter den immer stärker werdenden Aspekten

* der umweltgerechten Verteilung und Durchführung der Mobilität mit multimodalen Verkehrssystemen,
* der wachsenden Notwendigkeit, immer häufiger werdende Verkehrsbehinderungen aufgrund von Umweltkatastrophen (Klimawandel) zu bewältigen, wie auch
* der Notwendigkeit, Verkehrsressourcen aufgrund von wirtschaftlichen und sicherheitsrelevanten Gesichtspunkten besser auszulasten

erfordert eine klare Positionierung und Aufgabenbeschreibung der öffentlichen Hand als maßgebenden Akteur und Mitwirkender bei der „Multimodalen Reiseinformation“. Da diese Rolle hoheitlicher Art ist, grenzt sie sich auch in einer IVS-Referenzarchitektur „Multimodale Reiseinformation“ vertikal von den Rollen der Akteure auf Ebene der Inhalteanbieter und Dienstanbieter ab. Ebenfalls muss aufgrund der mit der öffentlichen Hand ausschließlich verbundenen Auskunftspflicht eine horizontale Trennung der Wirkungsbereiche vorgesehen werden. So müssen Systeme und Prozesse der Informationslogik, die mit der Aufnahme, Verarbeitung und Weiterreichung von öffentlichen Strategien verbunden sind, noch dem Wirkungsbereich der öffentlichen Hand zugesprochen werden. Während Systeme und Prozesse der Vertriebslogik nur im geringen Umfang in den Wirkungsbereich der öffentlichen Hand fallen.

Im Wesentlichen kann zur Definition des Wirkungsbereichs für die IVS-Referenzarchitektur „Multimodale Reiseinformation“ folgendes zentrales Bild (Abbildung 1) herangezogen werden. Es beschreibt generisch die typischen Rollen in einer „Multimodalen Reiseinformation“ unter Beachtung der Einbindung aller Strategien (individuell, öffentlich, betrieblich).

[[Datei:Wirkungsbereich der IVS-Referenzarchitektur Multimodale Reiseinformation_Konsortium MRK-AMADEUS.JPG|700px|thumb|centre]]

'''Abbildung 1''' Wirkungsbereich der IVS-Referenzarchitektur „Multimodale Reiseinformation“ als generische Darstellung von Akteuren und Domänen

So ergeben sich auf der Ebene der Inhalteanbieter die Instanzen, welche Produkte, Dienste und Informationen anbieten (Händler). Auf Ebene der Dienstanbieter stehen alle Akteure, die direkten Kontakt zu den Zielkunden (Reisende) haben, um zu informieren und meist auch, um Produkte und Dienste der Händler zu verkaufen. Allen beiden Ebenen (grün) ist zu Eigen, dass ihre Geschäftsmodelle privat- oder gemeinwirtschaftlich sein können und dass ihre Prozesse und Systeme zu eigenen Domänen mit eigenen Referenzarchitekturen gehören (z.B. Anzeiger – Referenzarchitektur „Fahrgastinformation“ bzw. „Verkehrsinformation Individualverkehr (inkl. C2X)“, Handy/Chip-karte – Referenzarchitektur „Elektronisches Fahrgeldmanagement“).

Damit konzentriert sich der Wirkungsbereich (blau) der IVS-Referenzarchitektur „Multimodale Reiseinformation“ auf die Prozesse und Systeme der Informationslogik der öffentlichen Hand, auf die Schnittstellen zu den Inhalteanbietern (API Datenanbindung) und zu den Dienstanbietern (API Serviceanbindung) sowie auf die Interaktion zur Vertriebslogik von Dritten. Die IVS-Referenzarchitektur „Multimodale Reiseinformation“ ermöglicht somit die direkte Einbindung von regionalen und überregionalen Strategien (rot) der öffentlichen Hand sowie deren situative und kampagnenorientierte Kommunikation (rot) in die Informationsbereitstellung der Dienstanbieter. Gleichzeitig erlaubt die Einbeziehung von Aspekten der Vertriebslogik in die IVS-Referenzarchitektur der öffentlichen Hand auch die indirekte Berücksichtigung von ideellen oder monetären Bonussystemen (rot) zur Inzentivierung öffentlicher Strategien, sowie die Schärfung von öffentlichen Strategien durch das Nutzen von Konsumdaten aus Clearingprozessen oder Big Data Analysen (rot).

Bezogen auf einen realen Umsetzungsraum wie Deutschland wird die IVS-Referenzarchitektur „Multimodale Reiseinformation“ viele Inhalteanbieter (grün) und Dienstanbieter (grün) kennen, die sich über die API Datenanbindung und API Serviceanbindung mit der öffentlichen Hand vernetzen. Bezogen auf die Einbindung öffentlicher Strategien und die Zusammenfassung von Inhalteanbietern auf regionaler Ebene wird es in Deutschland aufgrund der föderalen Struktur territorial gesehen dagegen eher eindeutige Akteure der öffentlichen Hand (blau) geben.

Kap. 6 Definition des Wirkungsbereichs

2016-06-20T09:12:20Z

Weber: /* Definition des Wirkungsbereichs */

== Definition des Wirkungsbereichs ==

Aufbauend auf der Wertschöpfungskette (siehe z.B. IVS-Rahmenarchitektur im ÖV) und dem damit verbundenen drei Schichtenmodell der Rollen von Akteuren (Inhalteanbieter, Dienstbetreiber, Dienstanbieter) kann für die Domäne „Multimodale Reiseinformation“ eine genaue Zuordnung von Aufgaben und Systemen der Informations- und Vertriebslogistik vorgenommen werden. Die Ausprägung von Aufgaben und Systemen ist dabei von der Rolle und dem Geschäftsmodell des jeweiligen Akteurs abhängig.

Generell muss aber bei der Dimensionierung und Strukturierung des Wirkungsbereichs der IVS-Referenzarchitektur „Multimodale Reiseinformation“ vorgesehen werden, dass drei Strategieebenen in der IVS-Referenzarchitektur Berücksichtigung finden und über unterschiedliche Akteure hinweg vernetzt werden. Diese sind:

* Individuelle Strategien der Zielgruppen auf Ebene der Dienstanbieter (z.B. Autonavigation, private Mobilitäts- und Vertriebsservices für Endkunden wie Online und Offline Reisebüros)
* Öffentliche Strategien auf Ebene der Dienstbetreiber (z.B. Verkehrsmanagement, Mobilitätsmanagement, MDM usw.)
* Betriebliche Strategien auf Ebene der Inhalteanbieter (z.B. Verkehrsunternehmen, Verkehrsleitzentralen, FCD usw.)

Während die Verknüpfung individueller und betrieblicher Strategien seit Jahren zum Status Quo der heutigen Informations- und Vertriebssysteme zählen, ist die Einbindung öffentlicher Strategien aus Stadt und Land in den Informations- und Vertriebssystemen der öffentlichen Hand und der Privaten erst am Anfang. Gerade unter den immer stärker werdenden Aspekten

* der umweltgerechten Verteilung und Durchführung der Mobilität mit multimodalen Verkehrssystemen,
* der wachsenden Notwendigkeit, immer häufiger werdende Verkehrsbehinderungen aufgrund von Umweltkatastrophen (Klimawandel) zu bewältigen, wie auch
* der Notwendigkeit, Verkehrsressourcen aufgrund von wirtschaftlichen und sicherheitsrelevanten Gesichtspunkten besser auszulasten

erfordert eine klare Positionierung und Aufgabenbeschreibung der öffentlichen Hand als maßgebenden Akteur und Mitwirkender bei der „Multimodalen Reiseinformation“. Da diese Rolle hoheitlicher Art ist, grenzt sie sich auch in einer IVS-Referenzarchitektur „Multimodale Reiseinformation“ vertikal von den Rollen der Akteure auf Ebene der Inhalteanbieter und Dienstanbieter ab. Ebenfalls muss aufgrund der mit der öffentlichen Hand ausschließlich verbundenen Auskunftspflicht eine horizontale Trennung der Wirkungsbereiche vorgesehen werden. So müssen Systeme und Prozesse der Informationslogik, die mit der Aufnahme, Verarbeitung und Weiterreichung von öffentlichen Strategien verbunden sind, noch dem Wirkungsbereich der öffentlichen Hand zugesprochen werden. Während Systeme und Prozesse der Vertriebslogik nur im geringen Umfang in den Wirkungsbereich der öffentlichen Hand fallen.

Im Wesentlichen kann zur Definition des Wirkungsbereichs für die IVS-Referenzarchitektur „Multimodale Reiseinformation“ folgendes zentrales Bild (Abbildung 1) herangezogen werden. Es beschreibt generisch die typischen Rollen in einer „Multimodalen Reiseinformation“ unter Beachtung der Einbindung aller Strategien (individuell, öffentlich, betrieblich).

[[Datei:Wirkungsbereich der IVS-Referenzarchitektur Multimodale Reiseinformation_Konsortium MRK-AMADEUS.JPG|700px|thumb|centre]]

'''Abbildung 1''' Wirkungsbereich der IVS-Referenzarchitektur „Multimodale Reiseinformation“ als generische Darstellung von Akteuren und Domänen

So ergeben sich auf der Ebene der Inhalteanbieter die Instanzen, welche Produkte, Dienste und Informationen anbieten (Händler). Auf Ebene der Dienstanbieter stehen alle Akteure, die direkten Kontakt zu den Zielkunden (Reisende) haben, um zu informieren und meist auch, um Produkte und Dienste der Händler zu verkaufen. Allen beiden Ebenen (grün) ist zu Eigen, dass ihre Geschäftsmodelle privat- oder gemeinwirtschaftlich sein können und dass ihre Prozesse und Systeme zu eigenen Domänen mit eigenen Referenzarchitekturen gehören (z.B. Anzeiger – Referenzarchitektur „Fahrgastinformation“ bzw. „Verkehrsinformation Individualverkehr (inkl. C2X)“, Handy/Chip-karte – Referenzarchitektur „Elektronisches Fahrgeldmanagement“).

Damit konzentriert sich der Wirkungsbereich (blau) der IVS-Referenzarchitektur „Multimodale Reiseinformation“ auf die Prozesse und Systeme der Informationslogik der Öffentlichen Hand, auf die Schnittstellen zu den Inhalteanbietern (API Datenanbindung) und zu den Dienstanbietern (API Serviceanbindung) sowie auf die Interaktion zur Vertriebslogik von Dritten. Die IVS-Referenzarchitektur „Multimodale Reiseinformation“ ermöglicht somit die direkte Einbindung von regionalen und überregionalen Strategien (rot) der Öffentlichen Hand sowie deren situative und kampagnenorientierte Kommunikation (rot) in die Informationsbereitstellung der Dienstanbieter. Gleichzeitig erlaubt die Einbeziehung von Aspekten der Vertriebslogik in die IVS-Referenzarchitektur der öffentlichen Hand auch die indirekte Berücksichtigung von ideellen oder monetären Bonussystemen (rot) zur Inzentivierung öffentlicher Strategien, sowie die Schärfung von öffentlichen Strategien durch das Nutzen von Konsumdaten aus Clearingprozessen oder Big Data Analysen (rot).

Bezogen auf einen realen Umsetzungsraum wie Deutschland wird die IVS-Referenzarchitektur „Multimodale Reiseinformation“ viele Inhalteanbieter (grün) und Dienstanbieter (grün) kennen, die sich über die API Datenanbindung und API Serviceanbindung mit der öffentlichen Hand vernetzen. Bezogen auf die Einbindung öffentlicher Strategien und die Zusammenfassung von Inhalteanbietern auf regionaler Ebene wird es in Deutschland aufgrund der föderalen Struktur territorial gesehen dagegen eher eindeutige Akteure der öffentlichen Hand (blau) geben.

Kap. 6 Definition des Wirkungsbereichs

2016-06-20T09:10:01Z

Weber: /* Definition des Wirkungsbereichs */

== Definition des Wirkungsbereichs ==

Aufbauend auf der Wertschöpfungskette (siehe z.B. IVS-Rahmenarchitektur im ÖV) und dem damit verbundenen drei Schichtenmodell der Rollen von Akteuren (Inhalteanbieter, Dienstbetreiber, Dienstanbieter) kann für die Domäne „Multimodale Reiseinformation“ eine genaue Zuordnung von Aufgaben und Systemen der Informations- und Vertriebslogistik vorgenommen werden. Die Ausprägung von Aufgaben und Systemen ist dabei von der Rolle und dem Geschäftsmodell des jeweiligen Akteurs abhängig.

Generell muss aber bei der Dimensionierung und Strukturierung des Wirkungsbereichs der IVS-Referenzarchitektur „Multimodale Reiseinformation“ vorgesehen werden, dass drei Strategieebenen in der IVS-Referenzarchitektur Berücksichtigung finden und über unterschiedliche Akteure hinweg vernetzt werden. Diese sind:

* Individuelle Strategien der Zielgruppen auf Ebene der Dienstanbieter (z.B. Autonavigation, private Mobilitäts- und Vertriebsservices für Endkunden wie Online und Offline Reisebüros)
* Öffentliche Strategien auf Ebene der Dienstbetreiber (z.B. Verkehrsmanagement, Mobilitätsmanagement, MDM usw.)
* Betriebliche Strategien auf Ebene der Inhalteanbieter (z.B. Verkehrsunternehmen, Verkehrsleitzentralen, FCD usw.)

Während die Verknüpfung individueller und betrieblicher Strategien seit Jahren zum Status Quo der heutigen Informations- und Vertriebssysteme zählen, ist die Einbindung öffentlicher Strategien aus Stadt und Land in den Informations- und Vertriebssystemen der öffentlichen Hand und der Privaten erst am Anfang. Gerade unter den immer stärker werdenden Aspekten

* der umweltgerechten Verteilung und Durchführung der Mobilität mit multimodalen Verkehrssystemen,
* der wachsenden Notwendigkeit, immer häufiger werdende Verkehrsbehinderungen aufgrund von Umweltkatastrophen (Klimawandel) zu bewältigen, wie auch
* der Notwendigkeit, Verkehrsressourcen aufgrund von wirtschaftlichen und sicherheitsrelevanten Gesichtspunkten besser auszulasten

erfordert eine klare Positionierung und Aufgabenbeschreibung der öffentlichen Hand als maßgebenden Akteur und Mitwirkender bei der „Multimodalen Reiseinformation“. Da diese Rolle hoheitlicher Art ist, grenzt sie sich auch in einer IVS-Referenzarchitektur „Multimodale Reiseinformation“ vertikal von den Rollen der Akteure auf Ebene der Inhalteanbieter und Dienstanbieter ab. Ebenfalls muss aufgrund der mit der öffentlichen Hand ausschließlich verbundenen Auskunftspflicht eine horizontale Trennung der Wirkungsbereiche vorgesehen werden. So müssen Systeme und Prozesse der Informationslogik, die mit der Aufnahme, Verarbeitung und Weiterreichung von öffentlichen Strategien verbunden sind, noch dem Wirkungsbereich der öffentlichen Hand zugesprochen werden. Während Systeme und Prozesse der Vertriebslogik nur im geringen Umfang in den Wirkungsbereich der öffentlichen Hand fallen.

Im Wesentlichen kann zur Definition des Wirkungsbereichs für die IVS-Referenzarchitektur „Multimodale Reiseinformation“ folgendes zentrales Bild (Abbildung 1) herangezogen werden. Es beschreibt generisch die typischen Rollen in einer „Multimodalen Reiseinformation“ unter Beachtung der Einbindung aller Strategien (individuell, öffentlich, betrieblich).

[[Datei:Wirkungsbereich der IVS-Referenzarchitektur Multimodale Reiseinformation_Konsortium MRK-AMADEUS.JPG|700px|thumb|centre]]

'''Abbildung 1''' Wirkungsbereich der IVS-Referenzarchitektur „Multimodale Reiseinformation“ als generische Darstellung von Akteuren und Domänen

So finden sich auf Ebene der Inhalteanbieter die Instanzen, die Produkte, Dienste und Informationen anbieten (Händler). Auf Ebene der Dienstanbieter stehen alle Akteure, die direkten Kontakt zu den Zielkunden (Reisende) haben, um zu informieren und meist auch, um Produkte und Dienste der Händler zu verkaufen. Allen beiden Ebenen (grün) ist zu Eigen, dass ihre Geschäftsmodelle privat- oder gemeinwirtschaftlich sein können und dass ihre Prozesse und Systeme zu eigenen Domänen mit eigenen Referenzarchitekturen gehören (z.B. Anzeiger – Referenzarchitektur „Fahrgastinformation“ bzw. „Verkehrsinformation Individualverkehr (inkl. C2X)“, Handy/Chip-karte – Referenzarchitektur „Elektronisches Fahrgeldmanagement“).

Damit konzentriert sich der Wirkungsbereich (blau) der IVS-Referenzarchitektur „Multimodale Reiseinformation“ auf die Prozesse und Systeme der Informationslogik der Öffentlichen Hand, auf die Schnittstellen zu den Inhalteanbietern (API Datenanbindung) und zu den Dienstanbietern (API Serviceanbindung) sowie auf die Interaktion zur Vertriebslogik von Dritten. Die IVS-Referenzarchitektur „Multimodale Reiseinformation“ ermöglicht somit die direkte Einbindung von regionalen und überregionalen Strategien (rot) der Öffentlichen Hand sowie deren situative und kampagnenorientierte Kommunikation (rot) in die Informationsbereitstellung der Dienstanbieter. Gleichzeitig erlaubt die Einbeziehung von Aspekten der Vertriebslogik in die IVS-Referenzarchitektur der öffentlichen Hand auch die indirekte Berücksichtigung von ideellen oder monetären Bonussystemen (rot) zur Inzentivierung öffentlicher Strategien, sowie die Schärfung von öffentlichen Strategien durch das Nutzen von Konsumdaten aus Clearingprozessen oder Big Data Analysen (rot).

Bezogen auf einen realen Umsetzungsraum wie Deutschland wird die IVS-Referenzarchitektur „Multimodale Reiseinformation“ viele Inhalteanbieter (grün) und Dienstanbieter (grün) kennen, die sich über die API Datenanbindung und API Serviceanbindung mit der öffentlichen Hand vernetzen. Bezogen auf die Einbindung öffentlicher Strategien und die Zusammenfassung von Inhalteanbietern auf regionaler Ebene wird es in Deutschland aufgrund der föderalen Struktur territorial gesehen dagegen eher eindeutige Akteure der öffentlichen Hand (blau) geben.

Kap. 6 Definition des Wirkungsbereichs

2016-06-20T08:54:42Z

Weber: /* Definition des Wirkungsbereichs */

== Definition des Wirkungsbereichs ==

Aufbauend auf der Wertschöpfungskette (siehe z.B. IVS-Rahmenarchitektur im ÖV) und dem damit verbundenen drei Schichtenmodell der Rollen von Akteuren (Inhalteanbieter, Dienstbetreiber, Dienstanbieter) kann für die Domäne „Multimodale Reiseinformation“ eine genaue Zuordnung von Aufgaben und Systemen der Informations- und Vertriebslogistik vorgenommen werden. Die Ausprägung von Aufgaben und Systemen ist dabei von der Rolle und dem Geschäftsmodell des jeweiligen Akteurs abhängig.

Generell muss aber bei der Dimensionierung und Strukturierung des Wirkungsbereichs der IVS-Referenzarchitektur „Multimodale Reiseinformation“ vorgesehen werden, dass drei Strategieebenen in der IVS-Referenzarchitektur Berücksichtigung finden und über unterschiedliche Akteure hinweg vernetzt werden. Diese sind:

* Individuelle Strategien der Zielgruppen auf Ebene der Dienstanbieter (z.B. Autonavigation, private Mobilitäts- und Vertriebsservices für Endkunden wie Online und Offline Reisebüros)
* Öffentliche Strategien auf Ebene der Dienstbetreiber (z.B. Verkehrsmanagement, Mobilitätsmanagement, MDM usw.)
* Betriebliche Strategien auf Ebene der Inhalteanbieter (z.B. Verkehrsunternehmen, Verkehrsleitzentralen, FCD usw.)

Während die Verknüpfung individueller und betrieblicher Strategien seit Jahren zum Status Quo der heutigen Informations- und Vertriebssysteme zählen, ist die Einbindung öffentlicher Strategien aus Stadt und Land in den Informations- und Vertriebssystemen der öffentlichen Hand und der Privaten erst am Anfang. Gerade unter den immer stärker werdenden Aspekten

* der umweltgerechten Verteilung und Durchführung der Mobilität mit multimodalen Verkehrssystemen,
* der wachsenden Notwendigkeit, immer häufiger werdende Verkehrsbehinderungen aufgrund von Umweltkatastrophen (Klimawandel) zu bewältigen, wie auch
* der Notwendigkeit, Verkehrsressourcen aufgrund von wirtschaftlichen und sicherheitsrelevanten Gesichtspunkten besser auszulasten

erfordert eine klare Positionierung und Aufgabenbeschreibung der öffentlichen Hand als maßgebenden Akteur und Mitwirkender bei der „Multimodalen Reiseinformation“. Da diese Rolle hoheitlicher Art ist, grenzt sie sich auch in einer IVS-Referenzarchitektur „Multimodale Reiseinformation“ vertikal von den Rollen der Akteure auf Ebene der Inhalteanbieter und Dienstanbieter ab. Ebenfalls muss aufgrund der mit der öffentlichen Hand ausschließlich verbundenen Auskunftspflicht eine horizontale Trennung der Wirkungs-bereiche vorgesehen werden. So müssen Systeme und Prozesse der Informationslogik, die mit der Aufnahme, Verarbeitung und Weiterreichung von öffentlichen Strategien verbunden sind, noch dem Wirkungsbereich der öffentlichen Hand zugesprochen werden. Während Systeme und Prozesse der Vertriebslogik nur im geringen Umfang in den Wirkungsbereich der öffentlichen Hand fallen.

Im Wesentlichen kann zur Definition des Wirkungsbereichs für die IVS-Referenzarchitektur „Multimodale Reiseinformation“ folgendes zentrales Bild (Abbildung 1) herangezogen werden. Es beschreibt generisch die typischen Rollen in einer „Multimodalen Reiseinformation“ unter Beachtung der Einbindung aller Strategien (individuell, öffentlich, betrieblich).

[[Datei:Wirkungsbereich der IVS-Referenzarchitektur Multimodale Reiseinformation_Konsortium MRK-AMADEUS.JPG|700px|thumb|centre]]

'''Abbildung 1''' Wirkungsbereich der IVS-Referenzarchitektur „Multimodale Reiseinformation“ als generische Darstellung von Akteuren und Domänen

So finden sich auf Ebene der Inhalteanbieter die Instanzen, die Produkte, Dienste und Informationen anbieten (Händler). Auf Ebene der Dienstanbieter stehen alle Akteure, die direkten Kontakt zu den Zielkunden (Reisende) haben, um zu informieren und meist auch, um Produkte und Dienste der Händler zu verkaufen. Allen beiden Ebenen (grün) ist zu Eigen, dass ihre Geschäftsmodelle privat- oder gemeinwirtschaftlich sein können und dass ihre Prozesse und Systeme zu eigenen Domänen mit eigenen Referenzarchitekturen gehören (z.B. Anzeiger – Referenzarchitektur „Fahrgastinformation“ bzw. „Verkehrsinformation Individualverkehr (inkl. C2X)“, Handy/Chip-karte – Referenzarchitektur „Elektronisches Fahrgeldmanagement“).

Damit konzentriert sich der Wirkungsbereich (blau) der IVS-Referenzarchitektur „Multimodale Reiseinformation“ auf die Prozesse und Systeme der Informationslogik der Öffentlichen Hand, auf die Schnittstellen zu den Inhalteanbietern (API Datenanbindung) und zu den Dienstanbietern (API Serviceanbindung) sowie auf die Interaktion zur Vertriebslogik von Dritten. Die IVS-Referenzarchitektur „Multimodale Reiseinformation“ ermöglicht somit die direkte Einbindung von regionalen und überregionalen Strategien (rot) der Öffentlichen Hand sowie deren situative und kampagnenorientierte Kommunikation (rot) in die Informationsbereitstellung der Dienstanbieter. Gleichzeitig erlaubt die Einbeziehung von Aspekten der Vertriebslogik in die IVS-Referenzarchitektur der öffentlichen Hand auch die indirekte Berücksichtigung von ideellen oder monetären Bonussystemen (rot) zur Inzentivierung öffentlicher Strategien, sowie die Schärfung von öffentlichen Strategien durch das Nutzen von Konsumdaten aus Clearingprozessen oder Big Data Analysen (rot).

Bezogen auf einen realen Umsetzungsraum wie Deutschland wird die IVS-Referenzarchitektur „Multimodale Reiseinformation“ viele Inhalteanbieter (grün) und Dienstanbieter (grün) kennen, die sich über die API Datenanbindung und API Serviceanbindung mit der öffentlichen Hand vernetzen. Bezogen auf die Einbindung öffentlicher Strategien und die Zusammenfassung von Inhalteanbietern auf regionaler Ebene wird es in Deutschland aufgrund der föderalen Struktur territorial gesehen dagegen eher eindeutige Akteure der öffentlichen Hand (blau) geben.

Kap. 5 Transformation des Geschäfts

2016-06-20T08:32:58Z

Weber: /* Bewertung der Reife für eine Transformation des Geschäfts */

== Bewertung der Reife für eine Transformation des Geschäfts ==

Die Bereitschaft für die Akzeptanz und Umsetzung der IVS-Referenzarchitektur „Multimodale Reiseinformation“ in Deutschland wird nach den Reifefaktoren von TOGAF eingeschätzt:

* '''Vision:''' Bisher sind die Themen rund um IVS-Rahmen- und Referenzarchitekturen stark durch die öffentliche Hand (v.a. BMVI, BASt) sowie der Forschungslandschaft (z.B. TU München) getrieben. Die Bereitschaft zur Anwendung von IVS-Referenzarchitekturen ist im Allgemeinen in der Privatwirtschaft im Geschäftsgebrauch (Geschäftsprozesse, IT-Systeme) oder durch die Gemeinwirtschaft (Ausschreibung von Leistungen) noch nicht etabliert. Im Hinblick auf die „Multimodale Reiseinformation“ muss daher der Nutzen deutschlandweit seitens der öffentlichen Hand (BMVI) klar und deutlich kommuniziert werden, z.B. an die Bundesländer oder an spezielle Räume in Deutschland (Best Practice). Durch die Fertigstellung der IVS-Referenzarchitekturen (Lose 2-4) sowie die Ausschreibung der ÖV-IVS-Referenzarchitekturen durch den Bund, wird sich die Bereitschaft zur Akzeptanz und Umsetzung mittel- und langfristig stark verbessern.

* '''Desire, Willingness, and Resolve:''' Durch die Vergabe der Leistung, der ständigen Projektbegleitung durch den Auftraggeber BASt sowie dem Projektmanagement der Lose, wird sichergestellt, dass die grundlegenden Arbeiten an der IVS-Referenzarchitekturen entschlossen abgewickelt werden. Der Begleiterkreis trägt die erarbeiteten Ergebnisse nach Außen.

* '''Need:''' Die Ziele und Konsequenzen für eine erfolgreiche Projektumsetzung wurden diskutiert. Dazu zählen u.a. die zunehmende Vernetzung der Mobilitätssysteme, der dahinterliegenden Geschäftsprozesse der Akteure und der Nutzen für den Reisenden in ganz Deutschland (siehe auch Kapitel 3). Mögliche Konsequenzen bei einer erfolglosen Umsetzung des Projekts müssen im Konsortium noch diskutiert werden. Dazu zählen z.B. die erschwerte Vernetzung von IVS-Diensten in Deutschland auf IT- und Prozessebene sowie ein fehlender Austausch zwischen multimodalen Stakeholdern.

* '''Business Case:''' Neben der Information strebt das Konsortium an, die grundlegenden Schnittstellen zum Vertrieb im Bereich multimodaler Reiseinformation aufzuzeigen. Die Kalkulation eines detaillierten Business Cases ist im Projekt nicht vorgesehen. Es ist jedoch anzumerken, dass eine Akzeptanz und dauerhafte Nutzung der Referenzarchitektur sich voraussichtlich nur einstellen wird, wenn alle beteiligten Stakeholder durch die Partizipation profitieren (Privatwirtschaft) oder einen Nutzen davon haben (Gemeinwirtschaft).

* '''Funding:''' Die Finanzierung für die Projektumsetzung ist durch die Beauftragung gegeben. Mögliche Finanzierungswege für die nachhaltige Pflege der IVS-Referenzarchitektur sind in TOGAF F bis H festzulegen.

* '''Sponsorship and Leadership:''' Das Vorhaben ist auf Bundesebene ausgelöst worden und hat damit die Unterstützung des BMVI, respektive des Bundesverkehrsministers. Weitere Unterstützer sind in der Projektlaufzeit hinzuzugewinnen.

* '''Governance:''' Für die Steuerung und Unterstützung des Projekts wird seitens des Auftraggebers bzw. des Los 1 ein Begleiterkreis festgelegt. Der aktuelle Stand des Projekts kann z.B. im nationalen IVS-Beirat regelmäßig präsentiert und abgestimmt werden, sodass bei Bedarf ein Abgleich mit den nationalen IVS-Strategien erfolgt. Öffentlichkeitswirksame Events (2 in der Projektlaufzeit) sichern den Kontakt und die Unterstützung zu den relevanten Stakeholdern.

* '''Accountability:''' Das Projektkonsortium ist in der Pflicht, die Beschreibung der IVS-Referenzarchitektur umzusetzen und der BASt als anwendbares Dokument zu übergeben. Verantwortlich für die Umsetzung nach der Projektlaufzeit in Deutschland sind das BMVI, nachgeordnete Behörden und die Länder, z.B. als Integration in die Förder- und Vergabelandschaft. Da Stakeholder der Privatwirtschaft nicht verpflichtet werden können, die IVS-Referenzarchitektur umzusetzen, werden in den TOGAF Phasen E bis H Möglichkeiten diskutiert, die entsprechenden Anreize zu setzen.

* '''Workable Approach and Execution Model:''' Für die Umsetzung der Referenzarchitektur „Multimodale Reiseinformation“ in die realen Systeme in Deutschland gibt es bereits sehr ausgeprägte und etablierte Strukturen. Dazu gehören beispielsweise die allgemein anerkannten Regeln und Rahmenbedingungen zur Vergabe von Leistungen und Fördermitteln (Bundesgesetze, Landesgesetze) sowie Vorgehensweisen (Besteller-Ersteller Prinzipien bzw. Öffentliche Hand-Lieferanten). Die entsprechenden Verbände zur Informationsverbreitung (VDV, VDA, ADAC etc.) sind vorhanden.

* '''IT Capacity to Execute:''' Sowohl innerhalb der Projektlaufzeit (Entwicklung IVS-Referenzarchitektur) als auch in der Umsetzungsphase in den Räumen in Deutschland stehen ausreichend Ressourcen zur Verfügung. Für die Projektlaufzeit wird Amadeus die IT-Skills, Tools (kostenfreie UML-Diagrammtools) und Arbeitsprozesse bereitstellen. Für die spätere Umsetzung der Referenzarchitekturen kann auf die deutsche Landschaft von IT-Unternehmen zurückgegriffen werden.

* '''Enterprise Capacity to Execute:''' Die Erfüllung der Anforderungen an das Projekt wurden ausführlich im Angebot dargelegt. Die Auswahl des Konsortiums um MRK/Amadeus basierte u.a. auf den Referenzen, in denen ähnliche Projekte bereits erfolgreich durchgeführt wurden.

* '''Enterprise Ability to Implement and Operate:''' Der „Betrieb“ der IVS-Referenzarchitektur wird nicht durch das Konsortium durchgeführt. Nach erfolgreicher Übergabe des Schlussdokuments und Vorbereitung der Migration bzw. des Änderungsmanagement (TOGAF F bis H) wird die BASt das Management der Architektur fortführen.

Kap. 5 Transformation des Geschäfts

2016-06-20T08:29:54Z

Weber: /* Bewertung der Reife für eine Transformation des Geschäfts */

== Bewertung der Reife für eine Transformation des Geschäfts ==

Die Bereitschaft für die Akzeptanz und Umsetzung der IVS-Referenzarchitektur „Multimodale Reiseinformation“ in Deutschland wird nach den Reifefaktoren von TOGAF eingeschätzt:

* '''Vision:''' Bisher sind die Themen rund um IVS-Rahmen- und Referenzarchitekturen stark durch die öffentliche Hand (v.a. BMVI, BASt) sowie der Forschungslandschaft (z.B. TU München) getrieben. Die Bereitschaft zur Anwendung von IVS-Referenzarchitekturen ist im Allgemeinen in der Privatwirtschaft im Geschäftsgebrauch (Geschäftsprozesse, IT-Systeme) oder durch die Gemeinwirtschaft (Ausschreibung von Leistungen) noch nicht etabliert. Im Hinblick auf die „Multimodale Reiseinformation“ muss daher der Nutzen deutschlandweit seitens der öffentlichen Hand (BMVI) klar und deutlich kommuniziert werden, z.B. an die Bundesländer oder an spezielle Räume in Deutschland (Best Practice). Durch die Fertigstellung der IVS-Referenzarchitekturen (Lose 2-4) sowie die Ausschreibung der ÖV-IVS-Referenzarchitekturen durch den Bund, wird sich die Bereitschaft zur Akzeptanz und Umsetzung mittel- und langfristig stark verbessern.

* '''Desire, Willingness, and Resolve:''' Durch die Vergabe der Leistung, der ständigen Projektbegleitung durch den Auftraggeber BASt sowie dem Projektmanagement der Lose, wird sichergestellt, dass die grundlegenden Arbeiten an der IVS-Referenzarchitekturen entschlossen abgewickelt werden. Der Begleiterkreis trägt die erarbeiteten Ergebnisse nach Außen.

* '''Need:''' Die Ziele und Konsequenzen für eine erfolgreiche Projektumsetzung wurden diskutiert. Dazu zählen u.a. die zunehmende Vernetzung der Mobilitätssysteme, der dahinterliegenden Geschäftsprozesse der Akteure und der Nutzen für den Reisenden in ganz Deutschland (siehe auch Kapitel 3). Mögliche Konsequenzen bei einer erfolglosen Umsetzung des Projekts müssen im Konsortium noch diskutiert werden. Dazu zählen z.B. die erschwerte Vernetzung von IVS-Diensten in Deutschland auf IT- und Prozessebene sowie ein fehlender Austausch zwischen multimodalen Stakeholdern.

* '''Business Case:''' Neben der Information strebt das Konsortium an, die grundlegenden Schnittstellen zum Vertrieb im Bereich multimodaler Reiseinformation aufzuzeigen. Die Kalkulation eines detaillierten Business Cases ist im Projekt nicht vorgesehen. Es ist jedoch anzumerken, dass eine Akzeptanz und dauerhafte Nutzung der Referenzarchitektur sich voraussichtlich nur einstellen wird, wenn alle beteiligten Stakeholder durch die Partizipation profitieren (Privatwirtschaft) oder einen Nutzen davon haben (Gemeinwirtschaft).

* '''Funding:''' Die Finanzierung für die Projektumsetzung ist durch die Beauftragung gegeben. Mögliche Finanzierungswege für die nachhaltige Pflege der IVS-Referenzarchitektur sind in TOGAF F bis H festzulegen.

* '''Sponsorship and Leadership:''' Das Vorhaben ist auf Bundesebene ausgelöst worden und hat damit die Unterstützung des BMVI, respektive des Bundesverkehrsministers. Weitere Unterstützer sind in der Projektlaufzeit hinzuzugewinnen.

* '''Governance:''' Für die Steuerung und Unterstützung des Projekts wird seitens des Auftraggebers bzw. des Los 1 ein Begleiterkreis festgelegt. Der aktuelle Stand des Projekts kann z.B. im nationalen IVS-Beirat regelmäßig präsentiert und abgestimmt werden, sodass bei Bedarf ein Abgleich mit den nationalen IVS-Strategien erfolgt. Öffentlichkeitswirksame Events (2 in der Projektlaufzeit) sichern den Kontakt und die Unterstützung zu den relevanten Stakeholdern.

* '''Accountability:''' Das Projektkonsortium ist in der Pflicht, die Beschreibung der IVS-Referenzarchitektur umzusetzen und der BASt als anwendbares Dokument zu übergeben. Verantwortlich für die Umsetzung nach der Projektlaufzeit in Deutschland sind das BMVI, nachgeordnete Behörden und die Länder, z.B. als Integration in die Förder- und Vergabelandschaft. Da Stakeholder der Privatwirtschaft nicht verpflichtet werden können, die IVS-Referenzarchitektur umzusetzen, werden in den TOGAF Phasen E bis H Möglichkeiten diskutiert, die entsprechenden Anreize zu setzen.

* '''Workable Approach and Execution Model:''' Für die Umsetzung der Referenzarchitektur „Multimodale Reiseinformation“ in die realen Systeme in Deutschland gibt es bereits sehr ausgeprägte und etablierte Strukturen. Dazu gehören beispielsweise die allgemein anerkannten Regeln und Rahmenbedingungen zur Vergabe von Leistungen und Fördermitteln (Bundesgesetze, Landesgesetze) sowie Vor-gehensweisen (Besteller-Ersteller Prinzipien bzw. öffentliche Hand-Lieferanten). Die entsprechenden Verbände zur Informationsverbreitung (VDV, VDA, ADAC etc.) sind vorhanden.

* '''IT Capacity to Execute:''' Sowohl innerhalb der Projektlaufzeit (Entwicklung IVS-Referenzarchitektur) als auch in der Umsetzungsphase in den Räumen in Deutschland stehen ausreichend Ressourcen zur Verfügung. Für die Projektlaufzeit wird Amadeus die IT-Skills, Tools (kostenfreie UML-Diagrammtools) und Arbeitsprozesse bereitstellen. Für die spätere Umsetzung der Referenzarchitekturen kann auf die deutsche Landschaft von IT-Unternehmen zurückgegriffen werden.

* '''Enterprise Capacity to Execute:''' Die Erfüllung der Anforderungen an das Projekt wurden ausführlich im Angebot dargelegt. Die Auswahl des Konsortiums um MRK/Amadeus basierte u.a. auf den Referenzen, in denen ähnliche Projekte bereits erfolgreich durchgeführt wurden.

* '''Enterprise Ability to Implement and Operate:''' Der „Betrieb“ der IVS-Referenzarchitektur wird nicht durch das Konsortium durchgeführt. Nach erfolgreicher Übergabe des Schlussdokuments und Vorbereitung der Migration bzw. des Änderungsmanagement (TOGAF F bis H) wird die BASt das Management der Architektur fortführen.

Kap. 5 Transformation des Geschäfts

2016-06-20T08:29:25Z

Weber: /* Bewertung der Reife für eine Transformation des Geschäfts */

== Bewertung der Reife für eine Transformation des Geschäfts ==

Die Bereitschaft für die Akzeptanz und Umsetzung der IVS-Referenzarchitektur „Multimodale Reiseinformation“ in Deutschland wird nach den Reifefaktoren von TOGAF eingeschätzt:

* '''Vision:''' Bisher sind die Themen rund um IVS-Rahmen- und Referenzarchitekturen stark durch die öffentliche Hand (v.a. BMVI, BASt) sowie der Forschungslandschaft (z.B. TU München) getrieben. Die Bereitschaft zur Anwendung von IVS-Referenzarchitekturen ist im Allgemeinen in der Privatwirtschaft im Geschäftsgebrauch (Geschäftsprozesse, IT-Systeme) oder durch die Gemeinwirtschaft (Ausschreibung von Leistungen) noch nicht etabliert. Im Hinblick auf die „Multimodale Reiseinformation“ muss daher der Nutzen deutschlandweit seitens der öffentlichen Hand (BMVI) klar und deutlich kommuniziert werden, z.B. an die Bundesländer oder an spezielle Räume in Deutschland (Best Practice). Durch die Fertigstellung der IVS-Referenzarchitekturen (Lose 2-4) sowie die Ausschreibung der ÖV-IVS-Referenzarchitekturen durch den Bund, wird sich die Bereitschaft zur Akzeptanz und Umsetzung mittel- und langfristig stark verbessern.

* '''Desire, Willingness, and Resolve:''' Durch die Vergabe der Leistung, der ständigen Projektbegleitung durch den Auftraggeber BASt sowie dem Projektmanagement der Lose, wird sichergestellt, dass die Grundlegenden Arbeiten an der IVS-Referenzarchitekturen entschlossen abgewickelt werden. Der Begleiterkreis trägt die erarbeite-ten Ergebnisse nach Außen.

* '''Need:''' Die Ziele und Konsequenzen für eine erfolgreiche Projektumsetzung wurden diskutiert. Dazu zählen u.a. die zunehmende Vernetzung der Mobilitätssysteme, der dahinterliegenden Geschäftsprozesse der Akteure und der Nutzen für den Reisenden in ganz Deutschland (siehe auch Kapitel 3). Mögliche Konsequenzen bei einer erfolglosen Umsetzung des Projekts müssen im Konsortium noch diskutiert werden. Dazu zählen z.B. die erschwerte Vernetzung von IVS-Diensten in Deutschland auf IT- und Prozessebene sowie ein fehlender Austausch zwischen multimodalen Stakeholdern.

* '''Business Case:''' Neben der Information strebt das Konsortium an, die grundlegenden Schnittstellen zum Vertrieb im Bereich multimodaler Reiseinformation aufzuzeigen. Die Kalkulation eines detaillierten Business Cases ist im Projekt nicht vorgesehen. Es ist jedoch anzumerken, dass eine Akzeptanz und dauerhafte Nutzung der Referenzarchitektur sich voraussichtlich nur einstellen wird, wenn alle beteiligten Stakeholder durch die Partizipation profitieren (Privatwirtschaft) oder einen Nutzen davon haben (Gemeinwirtschaft).

* '''Funding:''' Die Finanzierung für die Projektumsetzung ist durch die Beauftragung gegeben. Mögliche Finanzierungswege für die nachhaltige Pflege der IVS-Referenzarchitektur sind in TOGAF F bis H festzulegen.

* '''Sponsorship and Leadership:''' Das Vorhaben ist auf Bundesebene ausgelöst worden und hat damit die Unterstützung des BMVI, respektive des Bundesverkehrsministers. Weitere Unterstützer sind in der Projektlaufzeit hinzuzugewinnen.

* '''Governance:''' Für die Steuerung und Unterstützung des Projekts wird seitens des Auftraggebers bzw. des Los 1 ein Begleiterkreis festgelegt. Der aktuelle Stand des Projekts kann z.B. im nationalen IVS-Beirat regelmäßig präsentiert und abgestimmt werden, sodass bei Bedarf ein Abgleich mit den nationalen IVS-Strategien erfolgt. Öffentlichkeitswirksame Events (2 in der Projektlaufzeit) sichern den Kontakt und die Unterstützung zu den relevanten Stakeholdern.

* '''Accountability:''' Das Projektkonsortium ist in der Pflicht, die Beschreibung der IVS-Referenzarchitektur umzusetzen und der BASt als anwendbares Dokument zu übergeben. Verantwortlich für die Umsetzung nach der Projektlaufzeit in Deutschland sind das BMVI, nachgeordnete Behörden und die Länder, z.B. als Integration in die Förder- und Vergabelandschaft. Da Stakeholder der Privatwirtschaft nicht verpflichtet werden können, die IVS-Referenzarchitektur umzusetzen, werden in den TOGAF Phasen E bis H Möglichkeiten diskutiert, die entsprechenden Anreize zu setzen.

* '''Workable Approach and Execution Model:''' Für die Umsetzung der Referenzarchitektur „Multimodale Reiseinformation“ in die realen Systeme in Deutschland gibt es bereits sehr ausgeprägte und etablierte Strukturen. Dazu gehören beispielsweise die allgemein anerkannten Regeln und Rahmenbedingungen zur Vergabe von Leistungen und Fördermitteln (Bundesgesetze, Landesgesetze) sowie Vor-gehensweisen (Besteller-Ersteller Prinzipien bzw. öffentliche Hand-Lieferanten). Die entsprechenden Verbände zur Informationsverbreitung (VDV, VDA, ADAC etc.) sind vorhanden.

* '''IT Capacity to Execute:''' Sowohl innerhalb der Projektlaufzeit (Entwicklung IVS-Referenzarchitektur) als auch in der Umsetzungsphase in den Räumen in Deutschland stehen ausreichend Ressourcen zur Verfügung. Für die Projektlaufzeit wird Amadeus die IT-Skills, Tools (kostenfreie UML-Diagrammtools) und Arbeitsprozesse bereitstellen. Für die spätere Umsetzung der Referenzarchitekturen kann auf die deutsche Landschaft von IT-Unternehmen zurückgegriffen werden.

* '''Enterprise Capacity to Execute:''' Die Erfüllung der Anforderungen an das Projekt wurden ausführlich im Angebot dargelegt. Die Auswahl des Konsortiums um MRK/Amadeus basierte u.a. auf den Referenzen, in denen ähnliche Projekte bereits erfolgreich durchgeführt wurden.

* '''Enterprise Ability to Implement and Operate:''' Der „Betrieb“ der IVS-Referenzarchitektur wird nicht durch das Konsortium durchgeführt. Nach erfolgreicher Übergabe des Schlussdokuments und Vorbereitung der Migration bzw. des Änderungsmanagement (TOGAF F bis H) wird die BASt das Management der Architektur fortführen.

Kap. 5 Transformation des Geschäfts

2016-06-20T08:28:54Z

Weber: /* Bewertung der Reife für eine Transformation des Geschäfts */

== Bewertung der Reife für eine Transformation des Geschäfts ==

Die Bereitschaft für die Akzeptanz und Umsetzung der IVS-Referenzarchitektur „Multimodale Reiseinformation“ in Deutschland wird nach den Reifefaktoren von TOGAF eingeschätzt:

* '''Vision:''' Bisher sind die Themen rund um IVS-Rahmen- und Referenzarchitekturen stark durch die öffentliche Hand (v.a. BMVI, BASt) sowie der Forschungslandschaft (z.B. TU München) getrieben. Die Bereitschaft zur Anwendung von IVS-Referenzarchitekturen ist im Allgemeinen in der Privatwirtschaft im Geschäftsgebrauch (Geschäftsprozesse, IT-Systeme) oder durch die Gemeinwirtschaft (Ausschreibung von Leistungen) noch nicht etabliert. Im Hinblick auf die „Multimodale Reiseinformation“ muss daher der Nutzen deutschlandweit seitens der öffentlichen Hand (BMVI) klar und deutlich kommuniziert werden, z.B. an die Bundesländer oder an spezielle Räume in Deutschland (Best Practice). Durch die Fertigstellung der IVS-Referenzarchitekturen (Lose 2-4) sowie die Ausschreibung der ÖV-IVS-Referenzarchitekturen durch den Bund, wird sich die Bereitschaft zur Akzeptanz und Umsetzung mittel- und langfristig stark verbessern.

* '''Desire, Willingness, and Resolve:''' Durch die Vergabe der Leistung, der ständigen Projektbegleitung durch den Auftraggeber BASt sowie dem Projektmanagement der Lose, wird sichergestellt, dass die Grundlegenden Arbeiten an der der IVS-Referenzarchitekturen ent-schlossen abgewickelt werden. Der Begleiterkreis trägt die erarbeite-ten Ergebnisse nach Außen.

* '''Need:''' Die Ziele und Konsequenzen für eine erfolgreiche Projektumsetzung wurden diskutiert. Dazu zählen u.a. die zunehmende Vernetzung der Mobilitätssysteme, der dahinterliegenden Geschäftsprozesse der Akteure und der Nutzen für den Reisenden in ganz Deutschland (siehe auch Kapitel 3). Mögliche Konsequenzen bei einer erfolglosen Umsetzung des Projekts müssen im Konsortium noch diskutiert werden. Dazu zählen z.B. die erschwerte Vernetzung von IVS-Diensten in Deutschland auf IT- und Prozessebene sowie ein fehlender Austausch zwischen multimodalen Stakeholdern.

* '''Business Case:''' Neben der Information strebt das Konsortium an, die grundlegenden Schnittstellen zum Vertrieb im Bereich multimodaler Reiseinformation aufzuzeigen. Die Kalkulation eines detaillierten Business Cases ist im Projekt nicht vorgesehen. Es ist jedoch anzumerken, dass eine Akzeptanz und dauerhafte Nutzung der Referenzarchitektur sich voraussichtlich nur einstellen wird, wenn alle beteiligten Stakeholder durch die Partizipation profitieren (Privatwirtschaft) oder einen Nutzen davon haben (Gemeinwirtschaft).

* '''Funding:''' Die Finanzierung für die Projektumsetzung ist durch die Beauftragung gegeben. Mögliche Finanzierungswege für die nachhaltige Pflege der IVS-Referenzarchitektur sind in TOGAF F bis H festzulegen.

* '''Sponsorship and Leadership:''' Das Vorhaben ist auf Bundesebene ausgelöst worden und hat damit die Unterstützung des BMVI, respektive des Bundesverkehrsministers. Weitere Unterstützer sind in der Projektlaufzeit hinzuzugewinnen.

* '''Governance:''' Für die Steuerung und Unterstützung des Projekts wird seitens des Auftraggebers bzw. des Los 1 ein Begleiterkreis festgelegt. Der aktuelle Stand des Projekts kann z.B. im nationalen IVS-Beirat regelmäßig präsentiert und abgestimmt werden, sodass bei Bedarf ein Abgleich mit den nationalen IVS-Strategien erfolgt. Öffentlichkeitswirksame Events (2 in der Projektlaufzeit) sichern den Kontakt und die Unterstützung zu den relevanten Stakeholdern.

* '''Accountability:''' Das Projektkonsortium ist in der Pflicht, die Beschreibung der IVS-Referenzarchitektur umzusetzen und der BASt als anwendbares Dokument zu übergeben. Verantwortlich für die Umsetzung nach der Projektlaufzeit in Deutschland sind das BMVI, nachgeordnete Behörden und die Länder, z.B. als Integration in die Förder- und Vergabelandschaft. Da Stakeholder der Privatwirtschaft nicht verpflichtet werden können, die IVS-Referenzarchitektur umzusetzen, werden in den TOGAF Phasen E bis H Möglichkeiten diskutiert, die entsprechenden Anreize zu setzen.

* '''Workable Approach and Execution Model:''' Für die Umsetzung der Referenzarchitektur „Multimodale Reiseinformation“ in die realen Systeme in Deutschland gibt es bereits sehr ausgeprägte und etablierte Strukturen. Dazu gehören beispielsweise die allgemein anerkannten Regeln und Rahmenbedingungen zur Vergabe von Leistungen und Fördermitteln (Bundesgesetze, Landesgesetze) sowie Vor-gehensweisen (Besteller-Ersteller Prinzipien bzw. öffentliche Hand-Lieferanten). Die entsprechenden Verbände zur Informationsverbreitung (VDV, VDA, ADAC etc.) sind vorhanden.

* '''IT Capacity to Execute:''' Sowohl innerhalb der Projektlaufzeit (Entwicklung IVS-Referenzarchitektur) als auch in der Umsetzungsphase in den Räumen in Deutschland stehen ausreichend Ressourcen zur Verfügung. Für die Projektlaufzeit wird Amadeus die IT-Skills, Tools (kostenfreie UML-Diagrammtools) und Arbeitsprozesse bereitstellen. Für die spätere Umsetzung der Referenzarchitekturen kann auf die deutsche Landschaft von IT-Unternehmen zurückgegriffen werden.

* '''Enterprise Capacity to Execute:''' Die Erfüllung der Anforderungen an das Projekt wurden ausführlich im Angebot dargelegt. Die Auswahl des Konsortiums um MRK/Amadeus basierte u.a. auf den Referenzen, in denen ähnliche Projekte bereits erfolgreich durchgeführt wurden.

* '''Enterprise Ability to Implement and Operate:''' Der „Betrieb“ der IVS-Referenzarchitektur wird nicht durch das Konsortium durchgeführt. Nach erfolgreicher Übergabe des Schlussdokuments und Vorbereitung der Migration bzw. des Änderungsmanagement (TOGAF F bis H) wird die BASt das Management der Architektur fortführen.

Kap. 3 Geschäftsziele & Geschäftstreiber

2016-06-20T08:23:20Z

Weber: /* Bestätigung und Ausarbeitung von Geschäftszielen, Geschäfts-treibern und Rahmenbedingungen */

== Bestätigung und Ausarbeitung von Geschäftszielen, Geschäftstreibern und Rahmenbedingungen ==

Die multimodale Reiseinformation orientiert sich an den Geschäftszielen des Los 1 für die „Multimodale Reiseinformation“ für den Organisationsraum Deutschland. Sie sind wie folgt:

* Harmonisierte Einführung von IVS
* Durchgängige und verbesserte IVS-Anwendungen und IVS-Dienste
* Erleichterung bei der Entwicklung und Einführung von IVS-Diensten
* Sicherheit für öffentliche Betreiber bezüglich Kompatibilität und Interoperabilität von IVS-Anwendungen
* Geringerer Entwicklungsaufwand und Planungssicherheit für die Industrie
* Vermeidung technologischer „Insellösungen“
* Verbesserung der Investitionssicherheit und Markttransparenz
* Effizienterer und leichterer Verkehr
* Erhöhung der Verkehrssicherheit und der Wirtschaftlichkeit
* Reduzierung von negativen Umweltwirkungen des Verkehrs

Hinzu kommen für die Referenzarchitektur „Multimodale Reiseinformation“ spezifische Ziele und Rahmenbedingungen, welche sich an den drei zentralen Säulen der etablierten IVS-Rahmenarchitektur ÖV orientieren:

'''Rollen & Geschäftsmodelle''', z.B.:

* Erhaltung des Wettbewerbs/Keine Wettbewerbsverzerrung durch die IVS-Referenzarchitektur für öffentliche und private Unternehmen.
* Zugang zu multimodalen Reiseinformationen: aus politischen und finanziellen Gründen sind regionale „Access Points“ auf Territorialebene zu organisieren, um eine föderal und dauerhaft machbare Umsetzung sicherzustellen. Wie schon in der ÖV-IVS-Rahmenarchitektur und dem Ergebnispapier des IT-Gipfels 2014 des Bundes empfohlen, sind für diese Rolle „Koordinatoren für Mobilitätsdaten“ aufzubauen.
* Erhalt tragbarer Geschäftsmodelle für die „Multimodale Reiseinformation“, insbesondere für die Zusammenarbeit zwischen Privat- und Gemeinwirtschaft.
* Klare Zuständigkeiten innerhalb der Informationslogistik für öffentliche Partner (z.B. BASt/MDM, DELFI) und private Unternehmen.
* Synergien zwischen der Informations- und Transaktionslogistik bilden den Grundstein einer finanzierbaren, nachhaltigen, globalisierten und marktrobusten Referenzarchitektur für „Multimodale Reiseinformation“.
* Transparenz für die Stakeholder in der Wertschöpfungskette der multimodalen Reiseinformation bezüglich ihrer Geschäftsprozesse (z.B. Zuständigkeiten, rechtliche Spielräume, Datenschutz etc.).

'''Regeln & Rahmenbedingungen''', z.B.:

* Diskriminierungsfreiheit für die „Multimodale Reiseinformation“ (unabhängig vom Reisemittel).
* Beschreibung und Qualitätssicherung von „Level of Service“ für multimodale Reiseinformationen.
* Vorausschauende Konzeption für gemeinsame Dienste (insbesondere im Hinblick auf die Verknüpfung von AGBs mit öffentlichem Recht).
* Beachtung der nationalen und EU-Vorgaben bei der Konzeption, Finanzierung und Organisation der Referenzarchitektur.
* Beachtung öffentlicher Strategien bei der Reiseinformation.
* Verwendung und Weiterentwicklung zentraler Datenüberlassungs- und Datennutzungsverträge zwischen den Stakeholdern (z.B. Kommunen, Verkehrsunternehmen, Serviceprovider).
* Einhaltung des Datenschutzes bei der Informations- und Vertriebslogistik.

'''Informations- & Kommunikationstechnologie''', z.B.:

* Interoperabilität und Offenheit zu technischen Hintergrundsystemen für die Reiseinformation.
* Verwendung globaler Standards.
* Sicherung von einheitlichen IT-Qualitätsstandards für die Übermittlung und Verarbeitung von Mobilitätsdaten.
* Sicherstellung von zukünftigen Performance Anforderungen auf allen Systemebenen/-komponenten bei Akzeptanz der multimodalen Reiseinformation bei den Nutzern und im Markt.
* Weiterentwicklung von Technologien, z.B. Verbesserung der fehlenden Flexibilität und Automation der IT-Systeme zum Austausch von Mobilitätsdaten.

Kap. 2 Identifizierung der Stakeholder

2016-06-20T08:19:50Z

Weber: /* Identifizierung von Stakeholdern mit deren Anliegen und Geschäftsanforderungen */

== Identifizierung von Stakeholdern mit deren Anliegen und Geschäftsanforderungen ==
Grundlage für die erfolgreiche Etablierung der Referenzarchitektur ist die Akzeptanz bei den Stakeholdern in Deutschland. Die erste grobe Einteilung der Stakeholder(-gruppen) der Referenzarchitektur zeigt folgender Katalog:

{| class="wikitable"
! Industrie

|-
|- style="vertical-align:top;"

| Energie || EnBW, RWE

|-
|- style="vertical-align:top;"

| Automobil || Automobilhersteller (z.B. BMW, Audi, Daimler) und Zulieferer (z.B. Bosch, Conti)

|-
|- style="vertical-align:top;"

| Verkehrsinfrastruktur || z.B. SWARCO, Siemens

|-
|- style="vertical-align:top;"

| Telekommunikation || Alcatel Lucent, Nokia, Telekom, Telefonica, Vodafone

|-
|- style="vertical-align:top;"

| Informationstechnik || z.B. Toolhersteller

|-
|- style="vertical-align:top;"
! Verbände

|- style="vertical-align:top;"
| || ADAC

|- style="vertical-align:top;"
| || UIC

|- style="vertical-align:top;"
| || IATA

|- style="vertical-align:top;"
| || VDV

|- style="vertical-align:top;"
| || VDA

|- style="vertical-align:top;"
| || ADFC

|- style="vertical-align:top;"
| || Allianz pro Schiene

|- style="vertical-align:top;"
| || Pro Bahn

|- style="vertical-align:top;"
| || VDB

|- style="vertical-align:top;"
| || VDI/VDE

|- style="vertical-align:top;"
| || Bitkom

|- style="vertical-align:top;"
| || ITS-Verbände in Deutschland

|- style="vertical-align:top;"
| || OCA (Open Traffic Systems City Association)

|- style="vertical-align:top;"
| || ADV (Arbeitsgemeinschaft d. dt. Verkehrsflughäfen)

|- style="vertical-align:top;"
| || TISA (Traveller Information Services Association)

|-
|- style="vertical-align:top;"
! Öffentliche Hand

|- style="vertical-align:top;"
| || Städte (Städtetag)

|- style="vertical-align:top;"
| || Kommunen (Landkreistag)

|- style="vertical-align:top;"
| || Ministerien (Landes- und Bundesebene)

|- style="vertical-align:top;"
| || Straßenbauverwaltung

|-
|- style="vertical-align:top;"
! Wissenschaft und Gremien

|- style="vertical-align:top;"
|Hochschulen || z.B. Zeppelin Universität, TU München, TU Dresden

|- style="vertical-align:top;"
|Institute || Fraunhofer, DLR

|- style="vertical-align:top;"
|Standardisierungsgremien || UIC, OTA, ISO-/CEN-Gremien

|- style="vertical-align:top;"
| || Datenschutzbehörden

|- style="vertical-align:top;"
| || FGSV

|-
|- style="vertical-align:top;"
! Verkehrsunternehmen und -verbünde

|- style="vertical-align:top;"
| || Fernverkehrsunternehmen (z.B. Deutsche Bahn)

|- style="vertical-align:top;"
| || Nahverkehrsunternehmen

|- style="vertical-align:top;"
| || Stadtwerke

|- style="vertical-align:top;"
| || Verkehrsverbünde

|- style="vertical-align:top;"
|Luftfahrt || Lufthansa, Air France, Deutsche Flugsicherung

|- style="vertical-align:top;"
|Schifffahrts- und Seilbahnen || Bayerische Seenschifffahrt GmbH, Sächsische Dampf-schifffahrts-GmbH & Co.

|-
|- style="vertical-align:top;"
! Weitere relevante Dienst- und Datenprovider

|- style="vertical-align:top;"
|Dienstbetreiber || Qixxit, Allryder, Moovel, Odigeo

|- style="vertical-align:top;"
|Dienstbetreiber und Datenprovider || Google, Navteq, TomTom, INRIX

|- style="vertical-align:top;"
|Rundfunkanstalten || ARD-Anstalten, ZDF, WDR, Private, Landesmeldestellen

|- style="vertical-align:top;"
| || Veranstalter

|- style="vertical-align:top;"
| || Gastronomie

|- style="vertical-align:top;"
| || Projektgruppe All Ways Travelling
|}

'''Katalog 1:''' Grobe Einteilung der Stakeholder mit Relevanz für die IVS-Referenzarchitektur „Multimodale Reiseinformation“ (erweiterbar)

Für die Bewertung nach TOGAF werden diese nach den unten stehenden Kriterien bewertet und weitere Stakeholder identifiziert. Folgende Bewertungskriterien im Hinblick auf die Akzeptanz der Referenzarchitektur kommen zum Einsatz:
* Derzeitiges Verständnis
* Erforderliches Verständnis
* Derzeitiges Engagement
* Erforderliches Engagement
* Hemmende Wirkung
* Beeinflussbarkeit durch BASt/BMVI

Als weiteres Kriterium für das Stakeholder Management wird die TOGAF „Stakeholder Power Grid Matrix“ eingesetzt:

[[Datei:Power Grid zur Stakeholderanalyse_Konsortium MRK-AMADEUS.JPG|500px|]]

'''Matrix 1:''' Beispielhafte Darstellung des "Power Grid" zur Stakeholderanalyse

Die Matrix beschreibt den Einfluss für die erfolgreiche Umsetzung der Referenzarchitektur (Power) im Verhältnis zu deren Interesse/Beteiligungsgrad (Level of Interest). Die Schlüsselakteure (Gruppe C und insb. D) sind bei der Einführung der Referenzarchitektur zwingend einzubeziehen. Die Ergebnisse werden in der Stakeholder Map zusammengefasst.

[[Datei:TOGAF A_Stakeholdereinschätzung für die Referenzarchitektur_Konsortium MRK-AMADEUS.JPG|700px|thumb|centre|TOGAF A: Stakeholdereinschätzung für die Referenzarchitektur "multimodale Reiseinformation"]]

[[Datei:Stakeholder Power Grid für Akteure der multimodalen Reiseinformation_Konsortium MRK-AMADEUS.JPG|700px|thumb|centre|Stakeholder Power Grid für die Akteure der "multimodalen Reiseinformation"]]

{| class="wikitable"
! Stakeholder
! Detail
!Key Concerns
!Class (aus Power Grid)

|-
|- style="vertical-align:top;"

| Verkehrsunternehmen/Verbünde (Nahverkehr) || ||| Bedienung lokaler Kundengruppen des ÖPNV, Erhalt der eigenen Rolle in der Wertschöpfungskette der Information und des Vertriebs, Wettbewerb mit anderen Mobilitätanbietern (Car sharing, Uber, usw.) ||| C

|-
|- style="vertical-align:top;"

| Fernverkehr || ||| Stärkere Kundenbindung, Starker Konkurrenzdruck (z.B. Fernbusse vs. DB) über Information und Vertrieb ||| C

|-
|- style="vertical-align:top;"

| Luftfahrt || Flughäfen ||| Kundenfreundliche Anfahrt an den Flughafen, Information und Verkauf über die Anbindungen und Produkte am Flughafen (Non-Aviation) ||| C

|-
|- style="vertical-align:top;"

| || Flugunternehmen ||| Unabhängigkeit von Informations- und Vertriebskanälen Dritter, Bindung von Kunden an das Unternehmen ||| C

|-
|- style="vertical-align:top;"

| Öffentliche Hand || Städte ||| Erhalt der Mobilität, motorisierter Individualverkehr zu dominant, Umweltschäden, Wahrung der Standortvorteile, strategische Verkehrslenkung im Wettbewerb mit privatwirtschaftlichen Services (Routing/Navigation, Parken, usw.) ||| D

|-
|- style="vertical-align:top;"

| || Kommunen ||| Kostendruck, lange Planungsprozesse für Infrastrukturbau ||| A

|-
|- style="vertical-align:top;"

| || Bundesministerien und nachgeordnete Behörden ||| Umsetzbarkeit des politischen Willens ||| D

|-
|- style="vertical-align:top;"

| || Landesministerien ||| Föderaler Wettbewerb, Schonung von Landesmitteln, geringe Fördermittel seitens der Bundesebene ||| C

|-
|- style="vertical-align:top;"

| || Straßenbauverwaltungen, Verkehrsbehörden ||| Erhalt der Infrastruktur, Wettbewerb der Services öffentliche Hand/Private ||| D

|-
|- style="vertical-align:top;"

| Automobilhersteller || ||| Wandel zum Mobilitätsdienstleister, Technologiewandel (Elektromobilität), Zufahrtsbeschränkungen im urbanen Raum aufgrund von Umweltaspekten ||| D

|-
|- style="vertical-align:top;"

| Zulieferindustrie || ||| Roadmap der Automobilhersteller ||| C

|-
|- style="vertical-align:top;"

| Verkehrsinfrastrukturhersteller || ||| Abhängigkeit von Ausschreibungen der öffentlichen Hand, mangelnde Innovationsroadmap, lange Lebensdauer installierter Systeme (Altbestand) ||| A

|-
|- style="vertical-align:top;"

| Telekommunikation || ||| Teilhabe an zukünftigen Geschäftsmodellen von IVS, Annäherung an Automobilindustrie ||| D

|-
|- style="vertical-align:top;"

| Informationstechnik || ||| Eigene Wertschöpfung durch Branchenlösungen ||| D

|-
|- style="vertical-align:top;"

| Verbände || ||| Beeinflussbarkeit der Politik ||| A

|-
|- style="vertical-align:top;"

| Wissenschaft || ||| Forschungsrahmenbedingungen, internationaler Wettbewerb, Markteinführung von Innovationen ||| B

|-
|- style="vertical-align:top;"

| Gremien || ||| Geringe Wirkung auf Innovationen ||| B

|-
|- style="vertical-align:top;"

| Institute || ||| Geringe Marktnähe ||| B

|-
|- style="vertical-align:top;"

| Dienstbetreiber || ||| Alleinstellungsmerkmale, Kundenbindung ||| D

|-
|- style="vertical-align:top;"

| Datenprovider || ||| Privacy, Security, Ownership, Datenverwendung ||| D

|-
|- style="vertical-align:top;"

| Industrie || ||| Verkauf von Techniken zu IVS, Fokus auf Dienste anstatt Produkte ||| D
|}
'''Katalog 2:''' Stakeholder Map für die Akteure der multimodalen Reiseinformation

Kap. 2 Identifizierung der Stakeholder

2016-06-20T08:19:10Z

Weber: /* Identifizierung von Stakeholdern mit deren Anliegen und Geschäftsanforderungen */

== Identifizierung von Stakeholdern mit deren Anliegen und Geschäftsanforderungen ==
Grundlage für die erfolgreiche Etablierung der Referenzarchitektur ist die Akzeptanz bei den Stakeholdern in Deutschland. Die erste grobe Einteilung der Stakeholder(-gruppen) der Referenzarchitektur zeigt folgender Katalog:

{| class="wikitable"
! Industrie

|-
|- style="vertical-align:top;"

| Energie || EnBW, RWE

|-
|- style="vertical-align:top;"

| Automobil || Automobilhersteller (z.B. BMW, Audi, Daimler) und Zulieferer (z.B. Bosch, Conti)

|-
|- style="vertical-align:top;"

| Verkehrsinfrastruktur || z.B. SWARCO, Siemens

|-
|- style="vertical-align:top;"

| Telekommunikation || Alcatel Lucent, Nokia, Telekom, Telefonica, Vodafone

|-
|- style="vertical-align:top;"

| Informationstechnik || z.B. Toolhersteller

|-
|- style="vertical-align:top;"
! Verbände

|- style="vertical-align:top;"
| || ADAC

|- style="vertical-align:top;"
| || UIC

|- style="vertical-align:top;"
| || IATA

|- style="vertical-align:top;"
| || VDV

|- style="vertical-align:top;"
| || VDA

|- style="vertical-align:top;"
| || ADFC

|- style="vertical-align:top;"
| || Allianz pro Schiene

|- style="vertical-align:top;"
| || Pro Bahn

|- style="vertical-align:top;"
| || VDB

|- style="vertical-align:top;"
| || VDI/VDE

|- style="vertical-align:top;"
| || Bitkom

|- style="vertical-align:top;"
| || ITS-Verbände in Deutschland

|- style="vertical-align:top;"
| || OCA (Open Traffic Systems City Association)

|- style="vertical-align:top;"
| || ADV (Arbeitsgemeinschaft d. dt. Verkehrsflughäfen)

|- style="vertical-align:top;"
| || TISA (Traveller Information Services Association)

|-
|- style="vertical-align:top;"
! Öffentliche Hand

|- style="vertical-align:top;"
| || Städte (Städtetag)

|- style="vertical-align:top;"
| || Kommunen (Landkreistag)

|- style="vertical-align:top;"
| || Ministerien (Landes- und Bundesebene)

|- style="vertical-align:top;"
| || Straßenbauverwaltung

|-
|- style="vertical-align:top;"
! Wissenschaft und Gremien

|- style="vertical-align:top;"
|Hochschulen || z.B. Zeppelin Universität, TU München, TU Dresden

|- style="vertical-align:top;"
|Institute || Fraunhofer, DLR

|- style="vertical-align:top;"
|Standardisierungsgremien || UIC, OTA, ISO-/CEN-Gremien

|- style="vertical-align:top;"
| || Datenschutzbehörden

|- style="vertical-align:top;"
| || FGSV

|-
|- style="vertical-align:top;"
! Verkehrsunternehmen und -verbünde

|- style="vertical-align:top;"
| || Fernverkehrsunternehmen (z. B. Deutsche Bahn)

|- style="vertical-align:top;"
| || Nahverkehrsunternehmen

|- style="vertical-align:top;"
| || Stadtwerke

|- style="vertical-align:top;"
| || Verkehrsverbünde

|- style="vertical-align:top;"
|Luftfahrt || Lufthansa, Air France, Deutsche Flugsicherung

|- style="vertical-align:top;"
|Schifffahrts- und Seilbahnen || Bayerische Seenschifffahrt GmbH, Sächsische Dampf-schifffahrts-GmbH & Co.

|-
|- style="vertical-align:top;"
! Weitere relevante Dienst- und Datenprovider

|- style="vertical-align:top;"
|Dienstbetreiber || Qixxit, Allryder, Moovel, Odigeo

|- style="vertical-align:top;"
|Dienstbetreiber und Datenprovider || Google, Navteq, TomTom, INRIX

|- style="vertical-align:top;"
|Rundfunkanstalten || ARD-Anstalten, ZDF, WDR, Private, Landesmeldestellen

|- style="vertical-align:top;"
| || Veranstalter

|- style="vertical-align:top;"
| || Gastronomie

|- style="vertical-align:top;"
| || Projektgruppe All Ways Travelling
|}

'''Katalog 1:''' Grobe Einteilung der Stakeholder mit Relevanz für die IVS-Referenzarchitektur „Multimodale Reiseinformation“ (erweiterbar)

Für die Bewertung nach TOGAF werden diese nach den unten stehenden Kriterien bewertet und weitere Stakeholder identifiziert. Folgende Bewertungskriterien im Hinblick auf die Akzeptanz der Referenzarchitektur kommen zum Einsatz:
* Derzeitiges Verständnis
* Erforderliches Verständnis
* Derzeitiges Engagement
* Erforderliches Engagement
* Hemmende Wirkung
* Beeinflussbarkeit durch BASt/BMVI

Als weiteres Kriterium für das Stakeholder Management wird die TOGAF „Stakeholder Power Grid Matrix“ eingesetzt:

[[Datei:Power Grid zur Stakeholderanalyse_Konsortium MRK-AMADEUS.JPG|500px|]]

'''Matrix 1:''' Beispielhafte Darstellung des "Power Grid" zur Stakeholderanalyse

Die Matrix beschreibt den Einfluss für die erfolgreiche Umsetzung der Referenzarchitektur (Power) im Verhältnis zu deren Interesse/Beteiligungsgrad (Level of Interest). Die Schlüsselakteure (Gruppe C und insb. D) sind bei der Einführung der Referenzarchitektur zwingend einzubeziehen. Die Ergebnisse werden in der Stakeholder Map zusammengefasst.

[[Datei:TOGAF A_Stakeholdereinschätzung für die Referenzarchitektur_Konsortium MRK-AMADEUS.JPG|700px|thumb|centre|TOGAF A: Stakeholdereinschätzung für die Referenzarchitektur "multimodale Reiseinformation"]]

[[Datei:Stakeholder Power Grid für Akteure der multimodalen Reiseinformation_Konsortium MRK-AMADEUS.JPG|700px|thumb|centre|Stakeholder Power Grid für die Akteure der "multimodalen Reiseinformation"]]

{| class="wikitable"
! Stakeholder
! Detail
!Key Concerns
!Class (aus Power Grid)

|-
|- style="vertical-align:top;"

| Verkehrsunternehmen/Verbünde (Nahverkehr) || ||| Bedienung lokaler Kundengruppen des ÖPNV, Erhalt der eigenen Rolle in der Wertschöpfungskette der Information und des Vertriebs, Wettbewerb mit anderen Mobilitätanbietern (Car sharing, Uber, usw.) ||| C

|-
|- style="vertical-align:top;"

| Fernverkehr || ||| Stärkere Kundenbindung, Starker Konkurrenzdruck (z.B. Fernbusse vs. DB) über Information und Vertrieb ||| C

|-
|- style="vertical-align:top;"

| Luftfahrt || Flughäfen ||| Kundenfreundliche Anfahrt an den Flughafen, Information und Verkauf über die Anbindungen und Produkte am Flughafen (Non-Aviation) ||| C

|-
|- style="vertical-align:top;"

| || Flugunternehmen ||| Unabhängigkeit von Informations- und Vertriebskanälen Dritter, Bindung von Kunden an das Unternehmen ||| C

|-
|- style="vertical-align:top;"

| Öffentliche Hand || Städte ||| Erhalt der Mobilität, motorisierter Individualverkehr zu dominant, Umweltschäden, Wahrung der Standortvorteile, strategische Verkehrslenkung im Wettbewerb mit privatwirtschaftlichen Services (Routing/Navigation, Parken, usw.) ||| D

|-
|- style="vertical-align:top;"

| || Kommunen ||| Kostendruck, lange Planungsprozesse für Infrastrukturbau ||| A

|-
|- style="vertical-align:top;"

| || Bundesministerien und nachgeordnete Behörden ||| Umsetzbarkeit des politischen Willens ||| D

|-
|- style="vertical-align:top;"

| || Landesministerien ||| Föderaler Wettbewerb, Schonung von Landesmitteln, geringe Fördermittel seitens der Bundesebene ||| C

|-
|- style="vertical-align:top;"

| || Straßenbauverwaltungen, Verkehrsbehörden ||| Erhalt der Infrastruktur, Wettbewerb der Services öffentliche Hand/Private ||| D

|-
|- style="vertical-align:top;"

| Automobilhersteller || ||| Wandel zum Mobilitätsdienstleister, Technologiewandel (Elektromobilität), Zufahrtsbeschränkungen im urbanen Raum aufgrund von Umweltaspekten ||| D

|-
|- style="vertical-align:top;"

| Zulieferindustrie || ||| Roadmap der Automobilhersteller ||| C

|-
|- style="vertical-align:top;"

| Verkehrsinfrastrukturhersteller || ||| Abhängigkeit von Ausschreibungen der öffentlichen Hand, mangelnde Innovationsroadmap, lange Lebensdauer installierter Systeme (Altbestand) ||| A

|-
|- style="vertical-align:top;"

| Telekommunikation || ||| Teilhabe an zukünftigen Geschäftsmodellen von IVS, Annäherung an Automobilindustrie ||| D

|-
|- style="vertical-align:top;"

| Informationstechnik || ||| Eigene Wertschöpfung durch Branchenlösungen ||| D

|-
|- style="vertical-align:top;"

| Verbände || ||| Beeinflussbarkeit der Politik ||| A

|-
|- style="vertical-align:top;"

| Wissenschaft || ||| Forschungsrahmenbedingungen, internationaler Wettbewerb, Markteinführung von Innovationen ||| B

|-
|- style="vertical-align:top;"

| Gremien || ||| Geringe Wirkung auf Innovationen ||| B

|-
|- style="vertical-align:top;"

| Institute || ||| Geringe Marktnähe ||| B

|-
|- style="vertical-align:top;"

| Dienstbetreiber || ||| Alleinstellungsmerkmale, Kundenbindung ||| D

|-
|- style="vertical-align:top;"

| Datenprovider || ||| Privacy, Security, Ownership, Datenverwendung ||| D

|-
|- style="vertical-align:top;"

| Industrie || ||| Verkauf von Techniken zu IVS, Fokus auf Dienste anstatt Produkte ||| D
|}
'''Katalog 2:''' Stakeholder Map für die Akteure der multimodalen Reiseinformation

Kap. 2 Identifizierung der Stakeholder

2016-06-20T08:18:36Z

Weber: /* Identifizierung von Stakeholdern mit deren Anliegen und Geschäftsanforderungen */

== Identifizierung von Stakeholdern mit deren Anliegen und Geschäftsanforderungen ==
Grundlage für die erfolgreiche Etablierung der Referenzarchitektur ist die Akzeptanz bei den Stakeholdern in Deutschland. Die erste grobe Einteilung der Stakeholder(-gruppen) der Referenzarchitektur zeigt folgender Katalog:

{| class="wikitable"
! Industrie

|-
|- style="vertical-align:top;"

| Energie || EnBW, RWE

|-
|- style="vertical-align:top;"

| Automobil || Automobilhersteller (z.B. BMW, Audi, Daimler) und Zulieferer (z.B. Bosch, Conti)

|-
|- style="vertical-align:top;"

| Verkehrsinfrastruktur || z.B. SWARCO, Siemens

|-
|- style="vertical-align:top;"

| Telekommunikation || Alcatel Lucent, Nokia, Telekom, Telefonica, Vodafone

|-
|- style="vertical-align:top;"

| Informationstechnik || z.B. Toolhersteller

|-
|- style="vertical-align:top;"
! Verbände

|- style="vertical-align:top;"
| || ADAC

|- style="vertical-align:top;"
| || UIC

|- style="vertical-align:top;"
| || IATA

|- style="vertical-align:top;"
| || VDV

|- style="vertical-align:top;"
| || VDA

|- style="vertical-align:top;"
| || ADFC

|- style="vertical-align:top;"
| || Allianz pro Schiene

|- style="vertical-align:top;"
| || Pro Bahn

|- style="vertical-align:top;"
| || VDB

|- style="vertical-align:top;"
| || VDI/VDE

|- style="vertical-align:top;"
| || Bitkom

|- style="vertical-align:top;"
| || ITS-Verbände in Deutschland

|- style="vertical-align:top;"
| || OCA (Open Traffic Systems City Association)

|- style="vertical-align:top;"
| || ADV (Arbeitsgemeinschaft d. dt. Verkehrsflughäfen)

|- style="vertical-align:top;"
| || TISA (Traveller Information Services Association)

|-
|- style="vertical-align:top;"
! Öffentliche Hand

|- style="vertical-align:top;"
| || Städte (Städtetag)

|- style="vertical-align:top;"
| || Kommunen (Landkreistag)

|- style="vertical-align:top;"
| || Ministerien (Landes- und Bundesebene)

|- style="vertical-align:top;"
| || Straßenbauverwaltung

|-
|- style="vertical-align:top;"
! Wissenschaft und Gremien

|- style="vertical-align:top;"
|Hochschulen || z. B. Zeppelin Universität, TU München, TU Dresden

|- style="vertical-align:top;"
|Institute || Fraunhofer, DLR

|- style="vertical-align:top;"
|Standardisierungsgremien || UIC, OTA, ISO-/CEN-Gremien

|- style="vertical-align:top;"
| || Datenschutzbehörden

|- style="vertical-align:top;"
| || FGSV

|-
|- style="vertical-align:top;"
! Verkehrsunternehmen und -verbünde

|- style="vertical-align:top;"
| || Fernverkehrsunternehmen (z. B. Deutsche Bahn)

|- style="vertical-align:top;"
| || Nahverkehrsunternehmen

|- style="vertical-align:top;"
| || Stadtwerke

|- style="vertical-align:top;"
| || Verkehrsverbünde

|- style="vertical-align:top;"
|Luftfahrt || Lufthansa, Air France, Deutsche Flugsicherung

|- style="vertical-align:top;"
|Schifffahrts- und Seilbahnen || Bayerische Seenschifffahrt GmbH, Sächsische Dampf-schifffahrts-GmbH & Co.

|-
|- style="vertical-align:top;"
! Weitere relevante Dienst- und Datenprovider

|- style="vertical-align:top;"
|Dienstbetreiber || Qixxit, Allryder, Moovel, Odigeo

|- style="vertical-align:top;"
|Dienstbetreiber und Datenprovider || Google, Navteq, TomTom, INRIX

|- style="vertical-align:top;"
|Rundfunkanstalten || ARD-Anstalten, ZDF, WDR, Private, Landesmeldestellen

|- style="vertical-align:top;"
| || Veranstalter

|- style="vertical-align:top;"
| || Gastronomie

|- style="vertical-align:top;"
| || Projektgruppe All Ways Travelling
|}

'''Katalog 1:''' Grobe Einteilung der Stakeholder mit Relevanz für die IVS-Referenzarchitektur „Multimodale Reiseinformation“ (erweiterbar)

Für die Bewertung nach TOGAF werden diese nach den unten stehenden Kriterien bewertet und weitere Stakeholder identifiziert. Folgende Bewertungskriterien im Hinblick auf die Akzeptanz der Referenzarchitektur kommen zum Einsatz:
* Derzeitiges Verständnis
* Erforderliches Verständnis
* Derzeitiges Engagement
* Erforderliches Engagement
* Hemmende Wirkung
* Beeinflussbarkeit durch BASt/BMVI

Als weiteres Kriterium für das Stakeholder Management wird die TOGAF „Stakeholder Power Grid Matrix“ eingesetzt:

[[Datei:Power Grid zur Stakeholderanalyse_Konsortium MRK-AMADEUS.JPG|500px|]]

'''Matrix 1:''' Beispielhafte Darstellung des "Power Grid" zur Stakeholderanalyse

Die Matrix beschreibt den Einfluss für die erfolgreiche Umsetzung der Referenzarchitektur (Power) im Verhältnis zu deren Interesse/Beteiligungsgrad (Level of Interest). Die Schlüsselakteure (Gruppe C und insb. D) sind bei der Einführung der Referenzarchitektur zwingend einzubeziehen. Die Ergebnisse werden in der Stakeholder Map zusammengefasst.

[[Datei:TOGAF A_Stakeholdereinschätzung für die Referenzarchitektur_Konsortium MRK-AMADEUS.JPG|700px|thumb|centre|TOGAF A: Stakeholdereinschätzung für die Referenzarchitektur "multimodale Reiseinformation"]]

[[Datei:Stakeholder Power Grid für Akteure der multimodalen Reiseinformation_Konsortium MRK-AMADEUS.JPG|700px|thumb|centre|Stakeholder Power Grid für die Akteure der "multimodalen Reiseinformation"]]

{| class="wikitable"
! Stakeholder
! Detail
!Key Concerns
!Class (aus Power Grid)

|-
|- style="vertical-align:top;"

| Verkehrsunternehmen/Verbünde (Nahverkehr) || ||| Bedienung lokaler Kundengruppen des ÖPNV, Erhalt der eigenen Rolle in der Wertschöpfungskette der Information und des Vertriebs, Wettbewerb mit anderen Mobilitätanbietern (Car sharing, Uber, usw.) ||| C

|-
|- style="vertical-align:top;"

| Fernverkehr || ||| Stärkere Kundenbindung, Starker Konkurrenzdruck (z.B. Fernbusse vs. DB) über Information und Vertrieb ||| C

|-
|- style="vertical-align:top;"

| Luftfahrt || Flughäfen ||| Kundenfreundliche Anfahrt an den Flughafen, Information und Verkauf über die Anbindungen und Produkte am Flughafen (Non-Aviation) ||| C

|-
|- style="vertical-align:top;"

| || Flugunternehmen ||| Unabhängigkeit von Informations- und Vertriebskanälen Dritter, Bindung von Kunden an das Unternehmen ||| C

|-
|- style="vertical-align:top;"

| Öffentliche Hand || Städte ||| Erhalt der Mobilität, motorisierter Individualverkehr zu dominant, Umweltschäden, Wahrung der Standortvorteile, strategische Verkehrslenkung im Wettbewerb mit privatwirtschaftlichen Services (Routing/Navigation, Parken, usw.) ||| D

|-
|- style="vertical-align:top;"

| || Kommunen ||| Kostendruck, lange Planungsprozesse für Infrastrukturbau ||| A

|-
|- style="vertical-align:top;"

| || Bundesministerien und nachgeordnete Behörden ||| Umsetzbarkeit des politischen Willens ||| D

|-
|- style="vertical-align:top;"

| || Landesministerien ||| Föderaler Wettbewerb, Schonung von Landesmitteln, geringe Fördermittel seitens der Bundesebene ||| C

|-
|- style="vertical-align:top;"

| || Straßenbauverwaltungen, Verkehrsbehörden ||| Erhalt der Infrastruktur, Wettbewerb der Services öffentliche Hand/Private ||| D

|-
|- style="vertical-align:top;"

| Automobilhersteller || ||| Wandel zum Mobilitätsdienstleister, Technologiewandel (Elektromobilität), Zufahrtsbeschränkungen im urbanen Raum aufgrund von Umweltaspekten ||| D

|-
|- style="vertical-align:top;"

| Zulieferindustrie || ||| Roadmap der Automobilhersteller ||| C

|-
|- style="vertical-align:top;"

| Verkehrsinfrastrukturhersteller || ||| Abhängigkeit von Ausschreibungen der öffentlichen Hand, mangelnde Innovationsroadmap, lange Lebensdauer installierter Systeme (Altbestand) ||| A

|-
|- style="vertical-align:top;"

| Telekommunikation || ||| Teilhabe an zukünftigen Geschäftsmodellen von IVS, Annäherung an Automobilindustrie ||| D

|-
|- style="vertical-align:top;"

| Informationstechnik || ||| Eigene Wertschöpfung durch Branchenlösungen ||| D

|-
|- style="vertical-align:top;"

| Verbände || ||| Beeinflussbarkeit der Politik ||| A

|-
|- style="vertical-align:top;"

| Wissenschaft || ||| Forschungsrahmenbedingungen, internationaler Wettbewerb, Markteinführung von Innovationen ||| B

|-
|- style="vertical-align:top;"

| Gremien || ||| Geringe Wirkung auf Innovationen ||| B

|-
|- style="vertical-align:top;"

| Institute || ||| Geringe Marktnähe ||| B

|-
|- style="vertical-align:top;"

| Dienstbetreiber || ||| Alleinstellungsmerkmale, Kundenbindung ||| D

|-
|- style="vertical-align:top;"

| Datenprovider || ||| Privacy, Security, Ownership, Datenverwendung ||| D

|-
|- style="vertical-align:top;"

| Industrie || ||| Verkauf von Techniken zu IVS, Fokus auf Dienste anstatt Produkte ||| D
|}
'''Katalog 2:''' Stakeholder Map für die Akteure der multimodalen Reiseinformation

Aufsetzen des Architekturprojekts-Template

2016-06-20T08:17:13Z

Weber: /* Aufsetzen des Architekturprojekts */

== Aufsetzen des Architekturprojekts ==

Durch die Auftragsvergabe durch die Bundesanstalt für Straßenwesen (BASt) Ende 2015 an das Konsortium um Amadeus und MRK wurde das Architekturprojekt aufgesetzt. Die Projektpartner Amadeus/MRK werden von Subdienstleistern unterstützt. Die sich daraus ergebenden Projektinhalte sind in der Leistungsbeschreibung dargelegt und orientieren sich an den methodischen Vorgaben des Projekts „Los 1: IVS-Rahmenarchitektur Straße“.

Unterstützung erhält das Projekt daher mindestens von folgenden Organisationen:
* Alle am Projekt „Rahmenarchitektur“ (inklusiver aller Lose) teilnehmenden Unternehmen
* Die öffentliche Hand auf Bundesebene (BASt, BMVI und die entsprechenden Referate)
* Weitere Organisationen der Privat- und Gemeinwirtschaft, die im Projektverlauf im Detail identifiziert und angesprochen werden müssen

Die Ausprägung des Architekturprojekts orientiert sich an den vom Los 1 erarbeiteten Vorgaben und Vorschlägen zur Ausprägung und Anwendung von TOGAF. Es ist eine Verknüpfung mit den Ergebnissen der anderen Lose angestrebt, insbesondere mit dem Los 2.

Vorbereitungsphase

2016-06-20T08:15:34Z

Weber: /* Vorbereitungsphase */

== Vorbereitungsphase ==

'''IVS-Domäne Los 4:'''
* Verkehrsnetz:
** Fokus: Straße, Schiene, Luft, POIs (z.B. Gebäude, Bahnhöfe, Flughäfen)
** Randbereich: Wasser
* Dienst-Typ: Multimodale Reiseinformation
* Sicht: Architektur (Referenzmodell-Ebene)
* Perspektive: Politik, Staat, Stakeholder und Akteure aus der Branche der "Multimodalen Reiseinformation" aus Privat- und Gemeinwirtschaft (in unterschiedlichen Rollen entlang der Wertschöpfungskette für multimodale Reiseinformationen)
* Fokus: Geschäftsarchitektur und Informationssystemarchitektur, Grundlage der Technologiearchitektur und relevante Schritte der Migration (TOGAF E bis H)

'''IVS-Steuerungs- und Unterstützungsframeworks:'''

(siehe auch folgender Link des IVS-Wiki: wikiivs.albrechtconsult.com/)
* ITS Aktionsplan (Action plan for the deployment of Intelligent Transport Systems in Europe)
* ITS-Direktive 2010/40
* Nationales IVS-Gesetz
* Nationaler IVS-Aktionsplan
* IVS-Rahmenarchitektur für den ÖV

'''IVS-Architekturprinzipien:''' siehe TOGAF A, Punkt 7

'''IVS-Architekturframeworks und Werkzeuge:'''

Grundlage für die Ausarbeitung der IVS-Referenzarchitektur ist die TOGAF-ADM. Das Framework stellt verschiedene Methoden und Werkzeuge zur Beschreibung bereit (z.B. auch Kataloge, Matrizen oder Diagramme). Die Beschreibung der logischen Zusammenhänge wird in UML erfolgen. Wie im Abstimmungstermin am 20.4.2016 in Stuttgart festgelegt, wird dazu die Spezifikationssprache BPMN 2.0 verwendet.

'''IVS-Glossar:'''

Für die Begriffe wird sich Los 4 an den Ausarbeitungen des IVS-Glossar von Los 1 orientieren und diese bei Bedarf erweitern.

Vorbereitungsphase

2016-06-20T08:14:35Z

Weber: /* Vorbereitungsphase */

Kap. 10 Risiken einer Geschäftstransformation

2016-06-20T08:10:50Z

Weber: Die Seite wurde neu angelegt: „== Identifizierung der Risiken einer Geschäftstransformation und der Aktivitäten zur Risikominimierung == Im Folgenden beschreibt die Risikomatrix die Risi…“

== Identifizierung der Risiken einer Geschäftstransformation und der Aktivitäten zur Risikominimierung ==

Im Folgenden beschreibt die Risikomatrix die Risikoquellen, welche anhand einer Bewertung klassifiziert werden.

[[Datei:Risikomatrix_Konsortium MRK-AMADEUS.JPG|500px|]]

'''Matrix 4''': Risikokategorie, Quelle und Bewertung für die IVS-Referenzarchitektur

Für Risiken mit einer Risikokennzahl von über 15 wird das Konsortium folgende Gegenmaßnahmen treffen:

* '''Geringe Beachtung Datenschutz/Nationale Vorgaben (Nr. 4 & 14):'''
** Verstärkter Fokus bei der Ausarbeitung der Referenzarchitektur auf das Thema Datenschutz im Hinblick auf technische und juristische Belange
** Beachtung der deutschen Datenschutzvorgaben in den Ausführungen zur Architektur
* '''Fehlende Umsetzung auf Arbeitsebene (Nr. 6):'''
** Verständliche Beschreibung der Referenzarchitektur
** Verbesserung der Akzeptanz mit den umsetzenden Stellen, z.B. auf den öffentlichkeitswirksamen Terminen mit dem AG
** Ausrichtung der Migrationsplan im Hinblick auf die umsetzenden Räume/zuständigen Stellen
* '''Umgehen IVS-Referenzarchitektur durch Lieferanten (Nr. 16):'''
** Herausarbeiten des Nutzen der Architektur für die Lieferanten
** Implementierung der Ergebnisse der Architektur in die zukünftige Förder- und Vergabelandschaft in Deutschland
* '''Finanzierung der Architekturüberwachung (Nr. 20):'''
** Sensibilisierung des Auftraggebers bzw. des BMVI für den Bedarf der Bereitstellung von Betriebsmitteln
** Aufzeigen des Nutzens und der Finanzierungsspielräume in der Migrationsplanung

Datei:Risikomatrix Konsortium MRK-AMADEUS.JPG

2016-06-20T07:59:55Z

Weber:

Kap. 11 Entwicklung von Unternehmensarchitekturplänen

2016-06-20T07:50:42Z

Weber: Die Seite wurde neu angelegt: „== Entwicklung von Unternehmensarchitekturplänen und Aufträgen für die Architekturarbeit, Sichern der Zustimmung == Grundlage für Punkt 11 bildet das Ange…“

== Entwicklung von Unternehmensarchitekturplänen und Aufträgen für die Architekturarbeit, Sichern der Zustimmung ==

Grundlage für Punkt 11 bildet das Angebot von Los 4 (Ressourcenplanung, Liefergegenstände, Umfang etc.). Die Vertiefung hierzu findet noch in den weiteren Meetings mit Los 1 (TOGAF Workshop) bzw. dem Auftraggeber nach dem Meilenstein 1 statt.

''Diese Punkte werden im geplanten TOGAF-Workshop im Juni 2016 zum aktuellen Stand besprochen.''

Kap. 9 Wertbeitrag der Zielarchitektur

2016-06-20T07:48:28Z

Weber: Die Seite wurde neu angelegt: „== Definition des Wertbeitrags der Zielarchitektur und der KPIs == Die Wertschöpfungskette für multimodale Verkehrsinformationen ist komplex und wird nur d…“

== Definition des Wertbeitrags der Zielarchitektur und der KPIs ==

Die Wertschöpfungskette für multimodale Verkehrsinformationen ist komplex und wird nur durch eine Kooperation verschiedener Stakeholdergruppen abgedeckt. Hierbei ist derzeit in der Regel keine klare Stakeholdersegmentierung gegeben, denn Stakeholder können verschiedene Rollen entlang der Wertschöpfungskette besetzen.

Stark vereinfacht besteht die Wertschöpfungskette aus den Elementen ''Inhalteanbieter'', ''Dienstbetreiber'', ''Dienstanbieter'' und ''Endnutzer'', etwas detaillierter erbringt ein
* Inhalteanbieter die Wertschöpfungen Datenerfassung, Datenverarbeitung und Datenproviding;
* Dienstbetreiber die Wertschöpfungen Datenempfang, Datenfusion, Diensterzeugung und Dienstproviding;
* Dienstanbieter die Wertschöpfungen Dienstempfang, Dienstvisualisierung und Dienstpräsentation.

Die Stakeholdergruppen „Öffentliche Hand“ und „Verkehrsunternehmen“ treten z.B. in Teilbereichen der Datenerfassung, des Datenprovidings, der Diensterzeugung und des Dienstprovidings, der Dienstvisualisierung und der Dienstpräsentation auf, wie die Beispiele „IV-Verkehrsinformationen“ oder „Fahrgastinformationen“ verdeutlichen. Wertschöpfungsstufen können also einzelnen Stakeholdern nicht eindeutig zugeordnet werden. Auch eine Trennung zwischen Individualverkehr und öffentlichem Verkehr ist nicht zielführend, die Automobilindustrie, die dem Bereich „Individualverkehr“ zuzuordnen ist, bietet z.B. mit ihren Partnern aus der Zuliefererindustrie (hier Hersteller von Navigationsgeräten) IV- und ÖV-Verkehrsinformationen auf dem gleichen Endgerät an.

Der business case des einzelnen Stakeholders orientiert sich an den Rollen, die dieser Stakeholder in der Wertschöpfungskette einnimmt und ist somit immer individuell und nicht generalisiert beschreibbar.

Der Wertschöpfungsbetrag (value proposition) kann allerdings den o.g. Elementen der Wertschöpfungskette für multimodale Verkehrsinformationen zugeordnet werden, dagegen kaum den Stakeholdergruppen (ein Gerätehersteller, z.B. TomTom, tritt in einer geschlossenen Wertschöpfungskette als Inhalteanbieter, Dienstbetreiber und Dienstanbieter auf). Die Zuordnung des Wertschöpfungsbetrags zu den Wertschöpfungsstufen kann dann allerdings mit den Stakeholdergruppen besprochen werden, um Transparenz und ein gemeinsames Verständnis darüber zu erzeugen, welchen Beitrag ein Stakeholder zu erbringen hat, wie seine Kooperationsrolle technisch, rechtlich und organisatorisch zu gestalten ist, und wie ein typischer business case aussehen kann, wenn dieser Stakeholder eine definierte Rolle in der Wertschöpfungskette einnehmen will (TOGAF-Aktivität „review and agree the value propositions with the sponsors and stakeholders concerned“).

Die Beschaffungs- und Lieferbedingungen (procurement requirements) sind ebenfalls den Elementen der Wertschöpfungskette zuordbar, wobei es die typischen Bedingungen für die Privatwirtschaft und für die öffentliche Hand zu beachten gilt.

Das Thema KPIs (TOGAF-Aktivität “define the performance metrics and measures to be built into the enterprise architecture to meet the business needs and assess the business risks”) kann in der jetzigen Projektstufe noch nicht bearbeitet werden und wird noch abgestimmt.

Kap. 8 Entwicklung der Architekturvision

2016-06-20T07:40:56Z

Weber: /* Entwicklung der Architekturvision */

== Entwicklung der Architekturvision ==

Aufbauend auf dem Wirkungsbereich für die IVS-Referenzarchitektur „Multimodale Reiseinformation“ können für die Beschreibung der Architekturvision der „Multimodale Reiseinformation“ (Blauer Bereich in Abbildung 2)

* die maßgebenden Komponenten sowie
* ihre Beiträge zur Zielerreichung einer funktionsfähigen „Multimodalen Reiseinformation“ in Deutschland

identifiziert und beschrieben werden.

[[Datei:Komponenten der IVS-Referenzarchitektur Multimodale Reiseinformation_Konsortium MRK-AMADEUS.JPG|700px|thumb|centre]]

'''Abbildung 2''' Komponenten der IVS-Referenzarchitektur „Multimodale Reiseinformation“

'''API-Datenanbindung'''

Die Komponente (IT-Schicht) „API-Datenanbindung“ schließt über diverse technische Transportprotokolle die Systeme der Inhalteanbieter mit dem Zweck der Zustellung von Daten und Informationen an den für ein definiertes Gebiet zuständigen und neutralen Dienstbetreiber der „Multimodalen Reiseinformation“ (z. B. moveBW in Baden-Württemberg, VAO in Österreich) an. Ein Inhalteanbieter kann auch als Aggregator eigene Datenbestände als Informationen (z.B. Fahrplanauskunft eines Verkehrsverbunds, MDM) an der „API-Datenanbindung“ mit einem gewissen Normierungsstand zur Verfügung stellen. Der Inhalteanbieter bestimmt das Exportformat.

Der Datenzugriff erfolgt nach Absprache wahlweise im Pull- oder auch im Push-Mechanismus, um einen Abgleich des gesamten Datenbestands als Vollupdate oder inkrementelles Update sicherzustellen. Die Akteure stimmen untereinander einen geeigneten Updatezyklus ab.

Im Anschluss an den Datenimport aus den Lieferantensystemen der Inhalteanbieter erfolgt beim Dienstbetreiber die Transformation in ein normiertes, übergreifendes Datenformat, um die Leistungen der verschiedenen Träger miteinander in Beziehung zu bringen.

Von Inhalteanbietern muss an Dienstbetreiber u.a. geliefert werden:
* Fahr-, Reisezeiten,
* Aufenthaltsdauern, Umsteigezeiten,
* Tarife, Aktionsangebote/Klassen,
* Produkte und Produkteigenschaften (u.a. Größe, Strecken, Standorte, Verfügbarkeiten/Anzahl freie Plätze, Incidents vorhersehbar/nicht vorhersehbar).

Es müssen u.a. folgende Inhalteanbieter Daten und Informationen liefern:

Bahnunternehmen, Schienennetzbetreiber, Busunternehmen, Flug, Charter, Fahrradverkehr, Automobilunternehmen, Autoinformationssysteme, Mietwagen, Taxi, Transferservice, Parkhäuser, Fähren, Versicherungen, Kommunen, Länder (Vorzugsnetz für LKW, Baustellen, Sperrungen, …), Wetterdienste, Feuerwehr, Rettungsdienste, Polizei, Straßenämter, Behörden, Umweltämter, Geodatenbanken, ADAC/ADFC-Verkehrsprognosen, Mobil funkunternehmen, Informationsdienste (Google, Yahoo, Bing, …), POI (TomTom, …), Energieunternehmen, Unterkünfte etc.

Dabei ist es unerlässlich, dass die Inhalteanbieter Daten und Informationen kontinuierlich in höchstmöglicher Qualität innerhalb eines Servicestandards an den Dienstbetreiber der „Multimodalen Reiseinformation“ liefern, um eine dauerhafte Akzeptanz bei der Zielgruppe zu sichern. Die Dienstbetreiber sind dafür zuständig, mit ihrer Komponente „Informationslogik“ die vorhandenen Daten und Informationen für die Zielgruppen so aufzubereiten, dass über eine komplette Reisekette einer Zielperson über beliebige Medien hinweg in sich stimmige Informationen über beliebige Dienstanbieter (Informations- und Vertriebsdienste) an die Zielgruppe gebracht werden können.

Im Fall eines Vertriebs (Buchen, Verkaufen) von Produkten und Dienstleistungen der Inhalteanbieter über die „Multimodale Reiseinformation“ muss von der Komponente „API-Datenanbindung“ unabhängig von den angeschlossenen Dienstanbietern (mobility services wie z. B. Reisebüro, e-Ticket eines Verbunds, Autonavigationssystem) die Datenvalidierung zu
* Verkaufsinformationen, Validierung und Verfügbarkeit von Produkten und Dienstleistungen,
* gekauften Produkten und Dienstleistungen im Warenkorb,
* sicheren Bezahlungsmethoden für Nutzer und Leistungserbringer (Inhalteanbieter) und das
* Verkaufsbelegmanagement zwischen Inhalteanbieter und Kunde (Zielgruppe)
unterstützt werden.

Dies erreicht man am besten durch Nutzung von dedizierten Kundenprofilen, die den nationalen und internationalen Datenschutzstandards entsprechen.

'''API-Serviceanbindung'''

Die Komponente „API-Serviceanbindung“ ist die Schnittstelle vom neutralen Dienstbetreiber der „Multimodalen Reiseinformation“ für ein definiertes Gebiet (z.B. moveBW in Baden-Württemberg, VAO in Österreich) zu Dienstanbietern von Informations- und Vertriebskanälen (mobility services).

Die Komponente (IT-Schicht) „API-Serviceanbindung“ stellt den Dienstanbietern von Informations- und Vertriebsdiensten den Zugriff auf Information und Buchung zur Verfügung. Dabei werden verschiedenste, teilweise vom Nutzer individuell parametrisierbare und reiseabhängige Kriterien berücksichtigt, wie die
* Zeit-/Reisedauer,
* anfallende Kosten und Incentives,
* öffentliche Strategien (Umwelt, Verkehrssteuerung usw.),
* Kontext sowie
* Komforteigenschaften.

Weiterhin gibt es Zielgruppen, für die besondere Kriterien dauerhaft Anwendung finden müssen, wie gesundheitliche Aspekte oder firmenrelevante Interessen (Reiserichtlinien).

Bei der Bedienung der Dienstanbieter mit Informationen aus der „Multimodalen Reiseinformation“ muss darauf geachtet werden, dass neben der Reisemöglichkeit bezogen auf den individuellen Reisewunsch der Zielgruppe auch alternative Angebote (Fußgänger, ÖV, IV) dem Dienstanbietern über die „API-Serviceanbindung“ übergeben werden müssen, wenn öffentliche Strategien es verlangen. Die Auswahl der Reiseroute und -modalitäten obliegt aber weiterhin der Zielgruppe (Kunde).

Ein besonderer Mehrwert stellt generell die Übermittlung von Informationen aus dem Störfallmanagement (Incident Handling) über den zuständigen Dienstbetreiber der „Multimodalen Reiseinformation“ an die Dienstbetreiber von Informations- und Vertriebskanäle dar. Für diese Dienstanbieter gilt hier generell eine besondere Verantwortung für die Reisenden, sowohl
* bei Unfällen oder (Umwelt-)Katastrophen,
* bei Veranstaltungen und Events, wo Sicherheitsvorkehrungen und die Steuerung der Auslastungsverteilung in der Verantwortung der öffentlichen Hand liegt als auch
* bei Krisen oder Krieg.

Durch Informationen aus den Hochrechnungen und Vorhersagen der Inhalteanbieter zur kurz-, mittel- und langfristigen Verkehrsentwicklung in einem Gebiet können von dem Dienstbetreiber der „Multimodalen Reise“ abgestimmt mit den regionalen und überregionalen Strategien (ermittelt aus der Komponente „Informationslogik“). Informationen hinsichtlich zu erwartender Staus, Störungen und Überlastungen über die „API-Serviceanbindung“ an die Dienstanbieter übergeben werden. Damit können frühzeitig die Zielgruppen von den Informations- und Vertriebsdiensten angesprochen und informiert sowie Änderungen im Mobilitätsverhalten der Zielgruppen motiviert werden. Die Rückmeldung der Akzeptanz der Zielgruppen auf die Informationen erfolgt ebenso über die „API-Serviceanbindung“ an den Dienstbetreiber der „Multimodalen Reiseinformation“ zur Verwendung in den Komponenten Informations- und Vertriebslogik.

Über die Erstellung von Statistiken bzw. Business Intelligence (BI)-Auswertungen werden sowohl
* die Institutionen der öffentliche Hand (z.B. Verkehrsplanung, Verkehrsleitzentralen) in die Lage versetzt, ihre öffentlichen Strategien bei Planung und Betrieb zu optimieren, als auch
* die Inhalteanbieter (z.B. Veranstalter, Verkehrsunternehmen) und Dienstanbieter in die Lage versetzt, ihre Produkte und Dienste auf die Gegebenheiten eines dynamischen Verkehrsablaufs situativ anzupassen und damit ihren Vertrieb zu optimieren.

'''Informationslogik'''

Die Komponente (IT-Schicht) „Informationslogik“ verarbeitet
* die Daten und Informationen der unterschiedlichen Inhalteanbieter,
* unter Beachtung der regionalen und überregionalen geltenden öffentlichen Strategien der Gebietskörperschaften,
* situativer Meldungen an spezifischen Punkten der Reisekette und
* relevanten Faktoren aus dem Vertrieb (z. B. Inzentivs) sowie
* den aktuellen Erkenntnissen aus den Informations- und Vertriebsdiensten der Dienstanbieter hinsichtlich der Akzeptanz von Informationen aus der „Multimodalen Reiseinformation“.

Ein Ziel der Informationslogik ist es, optimierte Reiseketten, welche nutzerspezifische Präferenzen sowie unterschiedliche Verkehrsmittel berücksichtigen, zu berechnen und diese Informationen in vergleichbarer, integrativer und nachvollziehbarer Weise den unterschiedlichen Zielgruppen zur Verfügung zu stellen. Die Zielgruppen werden über regionale und globale Dienstanbieter (mobility services) angesprochen.

Aufgrund der Vielzahl an Akteuren und Systemen im Verkehr bzw. der Reisebranche sowie ihrer Differenzierung nach Räumen muss mit einer „Multimodalen Reiseinformation“ in Deutschland auch eine intelligente Vernetzung der zuständigen Teilsysteme (der Akteure im Wirkungsraum) realisiert werden. Hierzu benötig die Komponente der „Informationslogik“ folgende serverseitig ausgeführten Teilkomponenten.

Die ''Intermodale Logik'' integriert die aus der Nutzerschnittstelle übergebenen Daten, Informationen und Parameter (z.B. Fahrplanauskunft / Tarifauskunft, Verkehrsmeldungen und Steuerungsstrategien öffentlicher Partner, Landkreise, Gemeinden, regionaler Strategiemanager, Floating-Car-Daten, API) über die „API-Datenanbindung“. Aus den regionalen Daten und Verkehrsmanagementstrategien werden auf den Verkehrsnetzen Streckenwiderstände modelliert, die die Grundlage für das modale und intermodale Routing sind. Hierzu muss die Verkehrslage situationsabhängig berechnet und prognostiziert werden. Bei der Aktivierung einer Strategie (z.B. Umleitungsempfehlung oder P+R-Nutzung) werden in der intermodalen Logik die relevanten Netzelemente des strategischen Netzes in der Routenberechnung attraktiver gewichtet.

Die Intermodale Logik berechnet auf der Grundlage der aggregierten modalen Reisewege der externen ÖV-Router, der relevanten MIV-, Fahrrad- und Fußgänger-Router sowie auf Basis von Tarifinformation der jeweiligen Verkehrsmittel, somit Verfügbarkeiten. Sie ermittelt darauf nach nutzerspezifischen Reisepräferenzen und öffentlichen Strategien eine optimierte intermodale Reisekette. Die intermodale Reiseplanung kann unter Berücksichtigung situativer zielgruppenspezifischer Bedürfnisse erfolgen wie z.B. die schnellste, günstigste oder ökologischste, emissionsfreieste bzw. verkehrsoptimalste Route. Die Berechnungsergebnisse der Intermodalen Logik werden über die API „Serviceanbindung“ den Dienstanbietern zur Verfügung gestellt, so dass regionale Partner und Aufgabenträger auch die Steuerungsstrategien in ihren Systemen weiterverarbeiten können.

Der ''POI- und Adressservice'' integriert dazu alle punktbezogenen Informationen wie Adressen, Standorte von Sharing-Angebote, Haltestellen, Parkgaragen / P+R, Ladestationen etc., die an die „API-Datenanbindung“ angeschlossen sind, in ein einheitliches Datenformat und stellt diese über Web-Service-Schnittstellen internen und externen Diensten zur Verfügung (z.B. BW API „Serviceanbindung“). Die Zusammenführung, Harmonisierung und Referenzierung aller Daten muss auf einer gleichen Netzgrundlage, dem bundesweiten Integrationsnetz Straße stattfinden. Es bildet somit die Grundlage für die bundesweite Weiterverarbeitung regionaler Daten und Strategien.

Mit der Anbindung der gebietsspezifischen Dienstanbieter für die „Multimodale Reiseinformation“ an den Mobilitätsdatenmarktplatz MDM der Bundesanstalt für Straßenwesen über die „API-Serviceanbindung“ wird sichergestellt, dass Verkehrsmeldungen und Strategien aus dezidierten Gebieten an den MDM weitergeleitet und damit ausgetauscht werden können. Hier entsteht somit ein weiterer Mehrwert im Bereich der Datenverwendung auf bundesweiter Ebene. Die Anbindung an den MDM muss dabei in Abstimmung mit den Inhalteanbietern festgelegt werden.

Auf regionaler Ebene müssen ''Pflegewerkzeuge'' (Client) die Erfassung, Verortung von Verkehrsmeldungen und Verkehrslenkungs- und Steuerungsstrategien ermöglichen. Die Pflegewerkzeuge müssen mandantenfähig sein, so dass jeder Akteur des regionalen Verkehrsmanagements seine Strategien selber einpflegen kann. Pflegewerkzeuge sind damit eine wichtige Teilkomponente zur Etablierung eines regionalen (dynamischen) Verkehrsmanagements.

Damit wird es im Rahmen der „Informationslogik“ möglich, dass die von der Intermodalen Logik unter Berücksichtigung regionaler und individueller Strategien berechnete multimodale Reise von den eigenen Routerinstanzen der Dienstleister (App-Service, Autonavigationsgerät) übernommen wird und in ihr Routing unverfälscht eingebunden wird. Damit kann der Einwirkungsbereich auf das Mobilitätsverhalten aller Zielgruppen vergrößert werden.

'''Vertriebslogik'''

Die Komponente (IT-Schicht) „Vertriebslogik“ verarbeitet Buchungs-, Stornierungs- und Bezahlvorgänge von Produkten, Dienstleistungen oder Auskünften (Informationen) der Inhalteanbieter.

Aus Sicht der öffentlichen Hand (Auskunftspflicht) bedeutet „Multimodale Reiseinformation“ die alleinige Realisierung aller Komponenten in der Infor mationslogistik. Eine Akzeptanz und dauerhafte Nutzung der IVS-Referenzarchitektur „Multimodale Reiseinformation“ wird sich nach heutigen Erkenntnissen (z.B. VAO) nur einstellen, wenn sich die angezeigten Verkehrsanbindungen auch einfach und verlässlich buchen lassen. Dies ist notwendig, um
* eine Verbindlichkeit mit der Reiseinformation zu verknüpfen (z.B. Umstieg auf den ÖPNV am P+R-Platz durch Kauf der Fahrberechtigung im ÖPNV und des Einfahrtberechtigung in den P+R-Platz vor oder während der Reise),
* die freie Wirtschaft zu endkundenorientierten Angeboten und Lösungen zu bewegen und
* um die Prozesse rund um die Dienstreise und deren Abrechnung zu automatisieren bzw. zu optimieren.

Um entlang von Reiseketten nicht nur diskriminierungsfrei alle Informationen über die möglichen Produkte und Dienstleistungen anbieten zu können, muss auch die Buchung und der Kauf dieser angebotenen Produkte und Dienstleistungen diskriminierungsfrei für alle Zielgruppen möglich sein. In Anbetracht von z.B. einem unerwarteten Ereignis auf einer Reise wird damit gewährleistet, dass der Kunde nicht nur Alternativen aufgezeigt bekommt, sondern diese auch direkt wahrnehmen kann, ohne einen Medienbruch und damit neue Unsicherheiten auf sich zu nehmen. Die Zielgruppen (Nutzer) sparen Zeit, sie bekommen vereinfachte Prozesse vor und während der Reise und somit Vertrauen und Sicherheit in die „Multimodale Reiseinformation“.

Des Weiteren können durch die Einbindung der Komponente „Vertriebslogik“ in die Architekturvision der „Multimodalen Reiseinformation“ auch kommerzielle Elemente wie Inzentivierung, Gamification oder Anreizprogramme zur Unterstützung der Akzeptanz öffentlicher Strategien (z.B. Umsteigen auf den Öffentlichen Verkehr) bei Zielgruppen genutzt werden. In der weiteren Folge lassen sich damit BI-Möglichkeiten zur Erstellung von Statistiken über Reisekosten und deren Veränderung über die Jahre (Kostensteigerung) abbilden. Damit können die Zielgruppen finanzielle und zeitliche Steuerungsmaßnahmen für sich und ihr Mobilitätsverhalten einfach erkennen und ableiten.

Eine IVS-Referenzarchitektur „Multimodale Reiseinformation“ darf sich daher nicht nur auf die Informationslogik zurückziehen, sondern muss auch bei der Komponente „Vertriebslogik“ einen diskriminierungsfreien Einsatz angemessen vorsehen und beschreiben.

'''Data Hub'''

Die Komponente (IT-Schicht) „Data Hub“ stellt die serverseitige Organisationseinheit der Komponenten der „Multimodalen Reiseinformation“ dar. Es beinhaltet u.a.
* Datenmanagement und Datensicherheit (Überlassung, Weitergabe, Nutzung, Regeln, Status)
* Schnittstellenmanagement (Status, Version)
* System Management (Speicher, Verteilung)
* Lastmanagement (Anfragen, Verteilung)
* Hazardmanagement (Angriffe)
* Protokollwesen (LOG-Files, BI-Nutzung)

Der Data Hub erlaubt die kontrollierte Anbindung an die Big-Data-Analystik und an Data-Ware-Houses durch Tracing- und Tracking-Prozesse des Datenflusses über den/die neutralen Dienstbetreiber „Multimodale Reiseinformation“. Dadurch können zukünftig auf Seiten der
* öffentlichen Hand Planungs- und Verkehrssteuerungsprozesse optimiert und auf Seiten der
* Privatwirtschaft Mehrwertdienste entwickelt und an den Endnutzer verkauft werden.

Kap. 7 Architekturprinzipien und Geschäftsprinzipien

2016-06-20T07:29:01Z

Weber: /* Bestätigung und Ausarbeitung von Architekturprinzipien, einschließlich Geschäftsprinzipien */

== Bestätigung und Ausarbeitung von Architekturprinzipien, einschließlich Geschäftsprinzipien ==

Die Multimodale Reiseinformation stellt mit ihren zahlreichen Aspekten wie z.B.:

* Inhalteanbietern, Dienstbetreibern und Dienstanbietern
* gemein- und privatwirtschaftlichen Akteuren
* Informations- und Vertriebslogistik sowie
* unterschiedlichen Datenmodalitäten (Qualität, Quantität und Intensität der Datenlieferung)

eine sehr komplexe Domäne dar.

Architekturprinzipien helfen dabei diese Komplexität zu beherrschen. Entstanden aus erfolgreichen Strategien, komprimieren Prinzipien Inhalte zu anwendbaren und verständlichen Handlungsempfehlungen. Es ist empfehlenswert, dass alle Prinzipien gleichzeitig berücksichtigt werden, um eine gute IVS-Referenzarchitektur zu erstellen.

Als grundlegendes Qualitätsmerkmal für Architekturprinzipien sollen gelten:

* '''Einfachheit:'''
** Einzelne Elemente der Architektur sollen möglichst einfach sein
** Das Zusammenspiel der Elemente der Architektur soll einfach sein
* '''Klarheit / Verständlichkeit:'''
** Leichte Erkennbarkeit der Aufgaben einzelner Elemente
** Leichte Erkennbarkeit der Interaktion einzelner Elemente
* '''Wirtschaftlichkeit:'''
** Einzelne Elemente sollen möglichst selbst tragfähig sein
** Nicht selbst tragfähige aber notwendige Elemente sollen gemeinwirtschaftlich tragfähig sein
* '''Wartbarkeit und Erweiterbarkeit:'''
** Einzelne Elemente sollen ohne Abhängigkeit zu anderen Elementen gewartet und erweitert werden können
** Die Schnittstellen zwischen einzelner Elemente sollen standardisiert bzw. offen sein, um auf Erweiterungen einzelner Elemente angepasst reagieren zu können
* '''Betreibbarkeit:'''
** Leichter Betrieb der einzelner Elemente
** Leichter Betrieb der Interaktion mit anderen Elementen

Grundlagen einer Entwicklung von Prinzipien sind dabei:
* '''Abstraktion:''' Reduktion von Informationen auf wesentliche Informationen
* '''Modularisierung:''' Gliederung nach Zusammengehörigkeit
* '''Kapselung:''' Implizite und schwer erkennbare Abhängigkeiten reduzieren
* '''Hierarchische Dekomposition:''' Gliederung in Ebenen
* '''Begriffliche Dekomposition:''' Gliederung nach Eigenschaften und Aspekten
* '''Einheitlichkeit:''' Strukturen, Schemata, Muster, Vorgehensweisen beibehalten

bezogen auf die Domäne „Multimodale Reiseinformation“ ergeben sich damit acht anzuwendende Architekturprinzipien:
* '''Trennung von Zuständigkeiten:'''
** Jeder Akteur sollte möglichst nur für eine Aufgabe zuständig sein
** Genaue Definition und Abgrenzung von Aufgaben gegenüber anderen Akteuren
* '''Minimierung von Abhängigkeiten:'''
** Minimierung der Abhängigkeiten zwischen den Akteuren und ihren Systemen (z.B. durch Zusammenfassen von Teilen oder durch Entkoppelung)
** Vermeidung von zyklischen Abhängigkeiten (z.B. Verkauf)
* '''Geheimnisprinzip:'''
** Kapselung von Wissen und Logik in Teilsystemen
** Akteure (Nutzer) die mit einem Teilsystem interagieren, müssen nur das Notwendige kennen, um sich anschließen und interagieren zu können
** Für die korrespondierenden Akteure sollen Teilsysteme eine spezielle Sicht auf die verwendeten Funktionalität bereit stellen
* '''Homogenität:'''
** Vergleichbare Problem- und Aufgabenstellungen sind auf ähnliche Weise zu lösen
** Es sollen gleiche Größen und Einheiten sowie Begriffe verwendet werden
* '''Redundanzfreiheit:'''
** In der IVS-Referenzarchitektur sind gleiche Funktionalitäten zu identifizieren, zu verallgemeinern und wieder verwendbar zur Verfügung zu stellen
* '''Schichtenbildung:'''
** Unterteilung der Teilsysteme in Schichten
** Eine Schicht bündelt Teilsysteme mit ähnlichem Aufbau bzw. ähnlicher Grundfunktionalität
** Eine Schicht darf nur mit Systemen innerhalb ihrer eigenen Schicht oder einer nächsten darunter oder darüber liegenden Schicht interagieren
* '''Vertragsbasierter Entwurf:'''
** Vollständige Beschreibung der Interaktion der Teilsysteme und Akteure über Schnittstellen (Typ, Inhalt, Bedingung)
** Schnittstelle ist ein Vertrag zwischen Akteuren (z.B. Anbieter und Abnehmer von Daten, Informationen) und beschreibt alles, was der Abnehmer wissen muss, um mit dem Anbieter zu interagieren.
** Schnittstellen sollten spezifisch wenn nötig und so generell wie möglich beschrieben werden. Schnittstellen müssen den Austausch von Akteuren und Teilsystemen ermöglichen
* '''Datenhoheit:'''
** Festlegung einer einheitlichen Struktur / Modellierung der Daten.
** Festlegung der Verantwortlichkeit über einen Ausschnitt des Datenhaushalts an dezidierte Akteure, die ebenfalls für die Integrität und die Konsistenz dieser Daten sorgen

Kap. 8 Entwicklung der Architekturvision

2016-06-17T14:36:37Z

Weber: Die Seite wurde neu angelegt: „== Entwicklung der Architekturvision == Aufbauend auf dem Wirkungsbereich für die IVS-Referenzarchitektur „Multimodale Reiseinformation“ können für di…“

== Entwicklung der Architekturvision ==

Aufbauend auf dem Wirkungsbereich für die IVS-Referenzarchitektur „Multimodale Reiseinformation“ können für die Beschreibung der Architekturvision der „Multimodale Reiseinformation“ (Blauer Bereich in Abbildung 2)

* die maßgebenden Komponenten sowie
* ihre Beiträge zur Zielerreichung einer funktionsfähigen „Multimodalen Reiseinformation“ in Deutschland

identifiziert und beschrieben werden.

[[Datei:Komponenten der IVS-Referenzarchitektur Multimodale Reiseinformation_Konsortium MRK-AMADEUS.JPG|700px|thumb|centre]]

'''Abbildung 2''' Komponenten der IVS-Referenzarchitektur „Multimodale Reisein-formation“

'''API-Datenanbindung'''

Die Komponente (IT-Schicht) „API-Datenanbindung“ schließt über diverse technische Transportprotokolle die Systeme der Inhalteanbieter mit dem Zweck der Zustellung von Daten und Informationen an den für ein definiertes Gebiet zuständigen und neutralen Dienstbetreiber der „Multimodalen Reiseinformation“ (z. B. moveBW in Baden-Württemberg, VAO in Österreich) an. Ein Inhalteanbieter kann auch als Aggregator eigene Datenbestände als Informationen (z.B. Fahrplanauskunft eines Verkehrsverbunds, MDM) an der „API-Datenanbindung“ mit einem gewissen Normierungsstand zur Verfügung stellen. Der Inhalteanbieter bestimmt das Exportformat.

Der Datenzugriff erfolgt nach Absprache wahlweise im Pull- oder auch im Push-Mechanismus, um einen Abgleich des gesamten Datenbestands als Vollupdate oder inkrementelles Update sicherzustellen. Die Akteure stimmen untereinander einen geeigneten Updatezyklus ab.

Im Anschluss an den Datenimport aus den Lieferantensystemen der Inhalteanbieter erfolgt beim Dienstbetreiber die Transformation in ein normiertes, übergreifendes Datenformat, um die Leistungen der verschiedenen Träger miteinander in Beziehung zu bringen.

Von Inhalteanbietern muss an Dienstbetreiber u.a. geliefert werden:
* Fahr-, Reisezeiten,
* Aufenthaltsdauern, Umsteigezeiten,
* Tarife, Aktionsangebote/Klassen,
* Produkte und Produkteigenschaften (u.a. Größe, Strecken, Standorte, Verfügbarkeiten/Anzahl freie Plätze, Incidents vorhersehbar/nicht vorhersehbar).

Es müssen u.a. folgende Inhalteanbieter Daten und Informationen liefern:

Bahnunternehmen, Schienennetzbetreiber, Busunternehmen, Flug, Charter, Fahrradverkehr, Automobilunternehmen, Autoinformationssysteme, Mietwagen, Taxi, Transferservice, Parkhäuser, Fähren, Versicherungen, Kommunen, Länder (Vorzugsnetz für LKW, Baustellen, Sperrungen, …), Wetterdienste, Feuerwehr, Rettungsdienste, Polizei, Straßenämter, Behörden, Umweltämter, Geodatenbanken, ADAC/ADFC-Verkehrsprognosen, Mobil funkunternehmen, Informationsdienste (Google, Yahoo, Bing, …), POI (TomTom, …), Energieunternehmen, Unterkünfte etc.

Dabei ist es unerlässlich, dass die Inhalteanbieter Daten und Informationen kontinuierlich in höchstmöglicher Qualität innerhalb eines Servicestandards an den Dienstbetreiber der „Multimodalen Reiseinformation“ liefern, um eine dauerhafte Akzeptanz bei der Zielgruppe zu sichern. Die Dienstbetreiber sind dafür zuständig, mit ihrer Komponente „Informationslogik“ die vorhandenen Daten und Informationen für die Zielgruppen so aufzubereiten, dass über eine komplette Reisekette einer Zielperson über beliebige Medien hinweg in sich stimmige Informationen über beliebige Dienstanbieter (Informations- und Vertriebsdienste) an die Zielgruppe gebracht werden können.

Im Fall eines Vertriebs (Buchen, Verkaufen) von Produkten und Dienstleistungen der Inhalteanbieter über die „Multimodale Reiseinformation“ muss von der Komponente „API-Datenanbindung“ unabhängig von den angeschlossenen Dienstanbietern (mobility services wie z. B. Reisebüro, e-Ticket eines Verbunds, Autonavigationssystem) die Datenvalidierung zu
* Verkaufsinformationen, Validierung und Verfügbarkeit von Produkten und Dienstleistungen,
* gekauften Produkten und Dienstleistungen im Warenkorb,
* sicheren Bezahlungsmethoden für Nutzer und Leistungserbringer (Inhalteanbieter) und das
* Verkaufsbelegmanagement zwischen Inhalteanbieter und Kunde (Zielgruppe)
unterstützt werden.

Dies erreicht man am besten durch Nutzung von dedizierten Kundenprofilen, die den nationalen und internationalen Datenschutzstandards entsprechen.

'''API-Serviceanbindung'''

Die Komponente „API-Serviceanbindung“ ist die Schnittstelle vom neutralen Dienstbetreiber der „Multimodalen Reiseinformation“ für ein definiertes Gebiet (z.B. moveBW in Baden-Württemberg, VAO in Österreich) zu Dienstanbietern von Informations- und Vertriebskanälen (mobility services).

Die Komponente (IT-Schicht) „API-Serviceanbindung“ stellt den Dienstanbietern von Informations- und Vertriebsdiensten den Zugriff auf Information und Buchung zur Verfügung. Dabei werden verschiedenste, teilweise vom Nutzer individuell parametrisierbare und reiseabhängige Kriterien berücksichtigt, wie die
* Zeit-/Reisedauer,
* anfallende Kosten und Incentives,
* öffentliche Strategien (Umwelt, Verkehrssteuerung usw.),
* Kontext sowie
* Komforteigenschaften.

Weiterhin gibt es Zielgruppen, für die besondere Kriterien dauerhaft Anwendung finden müssen, wie gesundheitliche Aspekte oder firmenrelevante Interessen (Reiserichtlinien).

Bei der Bedienung der Dienstanbieter mit Informationen aus der „Multimodalen Reiseinformation“ muss darauf geachtet werden, dass neben der Reisemöglichkeit bezogen auf den individuellen Reisewunsch der Zielgruppe auch alternative Angebote (Fußgänger, ÖV, IV) dem Dienstanbietern über die „API-Serviceanbindung“ übergeben werden müssen, wenn öffentliche Strategien es verlangen. Die Auswahl der Reiseroute und -modalitäten obliegt aber weiterhin der Zielgruppe (Kunde).

Ein besonderer Mehrwert stellt generell die Übermittlung von Informationen aus dem Störfallmanagement (Incident Handling) über den zuständigen Dienstbetreiber der „Multimodalen Reiseinformation“ an die Dienstbetreiber von Informations- und Vertriebskanäle dar. Für diese Dienstanbieter gilt hier generell eine besondere Verantwortung für die Reisenden, sowohl
* bei Unfällen oder (Umwelt-)Katastrophen,
* bei Veranstaltungen und Events, wo Sicherheitsvorkehrungen und die Steuerung der Auslastungsverteilung in der Verantwortung der öffentlichen Hand liegt als auch
* bei Krisen oder Krieg.

Durch Informationen aus den Hochrechnungen und Vorhersagen der Inhalteanbieter zur kurz-, mittel- und langfristigen Verkehrsentwicklung in einem Gebiet können von dem Dienstbetreiber der „Multimodalen Reise“ abgestimmt mit den regionalen und überregionalen Strategien (ermittelt aus der Komponente „Informationslogik“). Informationen hinsichtlich zu erwartender Staus, Störungen und Überlastungen über die „API-Serviceanbindung“ an die Dienstanbieter übergeben werden. Damit können frühzeitig die Zielgruppen von den Informations- und Vertriebsdiensten angesprochen und informiert sowie Änderungen im Mobilitätsverhalten der Zielgruppen motiviert werden. Die Rückmeldung der Akzeptanz der Zielgruppen auf die Informationen erfolgt ebenso über die „API-Serviceanbindung“ an den Dienstbetreiber der „Multimodalen Reiseinformation“ zur Verwendung in den Komponenten Informations- und Vertriebslogik.

Über die Erstellung von Statistiken bzw. Business Intelligence (BI)-Auswertungen werden sowohl
* die Institutionen der öffentliche Hand (z.B. Verkehrsplanung, Verkehrsleitzentralen) in die Lage versetzt, ihre öffentlichen Strategien bei Planung und Betrieb zu optimieren, als auch
* die Inhalteanbieter (z.B. Veranstalter, Verkehrsunternehmen) und Dienstanbieter in die Lage versetzt, ihre Produkte und Dienste auf die Gegebenheiten eines dynamischen Verkehrsablaufs situativ anzupassen und damit ihren Vertrieb zu optimieren.

'''Informationslogik'''

Die Komponente (IT-Schicht) „Informationslogik“ verarbeitet
* die Daten und Informationen der unterschiedlichen Inhalteanbieter,
* unter Beachtung der regionalen und überregionalen geltenden öffentlichen Strategien der Gebietskörperschaften,
* situativer Meldungen an spezifischen Punkten der Reisekette und
* relevanten Faktoren aus dem Vertrieb (z. B. Inzentivs) sowie
* den aktuellen Erkenntnissen aus den Informations- und Vertriebsdiensten der Dienstanbieter hinsichtlich der Akzeptanz von Informationen aus der „Multimodalen Reiseinformation“.

Ein Ziel der Informationslogik ist es, optimierte Reiseketten, welche nutzerspezifische Präferenzen sowie unterschiedliche Verkehrsmittel berücksichtigen, zu berechnen und diese Informationen in vergleichbarer, integrativer und nachvollziehbarer Weise den unterschiedlichen Zielgruppen zur Verfügung zu stellen. Die Zielgruppen werden über regionale und globale Dienstanbieter (mobility services) angesprochen.

Aufgrund der Vielzahl an Akteuren und Systemen im Verkehr bzw. der Reisebranche sowie ihrer Differenzierung nach Räumen muss mit einer „Multimodalen Reiseinformation“ in Deutschland auch eine intelligente Vernetzung der zuständigen Teilsysteme (der Akteure im Wirkungsraum) realisiert werden. Hierzu benötig die Komponente der „Informationslogik“ folgende serverseitig ausgeführten Teilkomponenten.

Die ''Intermodale Logik'' integriert die aus der Nutzerschnittstelle übergebenen Daten, Informationen und Parameter (z.B. Fahrplanauskunft / Tarifauskunft, Verkehrsmeldungen und Steuerungsstrategien öffentlicher Partner, Landkreise, Gemeinden, regionaler Strategiemanager, Floating-Car-Daten, API) über die „API-Datenanbindung“. Aus den regionalen Daten und Verkehrsmanagementstrategien werden auf den Verkehrsnetzen Streckenwiderstände modelliert, die die Grundlage für das modale und intermodale Routing sind. Hierzu muss die Verkehrslage situationsabhängig berechnet und prognostiziert werden. Bei der Aktivierung einer Strategie (z.B. Umleitungsempfehlung oder P+R-Nutzung) werden in der intermodalen Logik die relevanten Netzelemente des strategischen Netzes in der Routenberechnung attraktiver gewichtet.

Die Intermodale Logik berechnet auf der Grundlage der aggregierten modalen Reisewege der externen ÖV-Router, der relevanten MIV-, Fahrrad- und Fußgänger-Router sowie auf Basis von Tarifinformation der jeweiligen Verkehrsmittel, somit Verfügbarkeiten. Sie ermittelt darauf nach nutzerspezifischen Reisepräferenzen und öffentlichen Strategien eine optimierte intermodale Reisekette. Die intermodale Reiseplanung kann unter Berücksichtigung situativer zielgruppenspezifischer Bedürfnisse erfolgen wie z.B. die schnellste, günstigste oder ökologischste, emissionsfreieste bzw. verkehrsoptimalste Route. Die Berechnungsergebnisse der Intermodalen Logik werden über die API „Serviceanbindung“ den Dienstanbietern zur Verfügung gestellt, so dass regionale Partner und Aufgabenträger auch die Steuerungsstrategien in ihren Systemen weiterverarbeiten können.

Der ''POI- und Adressservice'' integriert dazu alle punktbezogenen Informationen wie Adressen, Standorte von Sharing-Angebote, Haltestellen, Parkgaragen / P+R, Ladestationen etc., die an die „API-Datenanbindung“ angeschlossen sind, in ein einheitliches Datenformat und stellt diese über Web-Service-Schnittstellen internen und externen Diensten zur Verfügung (z.B. BW API „Serviceanbindung“). Die Zusammenführung, Harmonisierung und Referenzierung aller Daten muss auf einer gleichen Netzgrundlage, dem bundesweiten Integrationsnetz Straße stattfinden. Es bildet somit die Grundlage für die bundesweite Weiterverarbeitung regionaler Daten und Strategien.

Mit der Anbindung der gebietsspezifischen Dienstanbieter für die „Multimodale Reiseinformation“ an den Mobilitätsdatenmarktplatz MDM der Bundesanstalt für Straßenwesen über die „API-Serviceanbindung“ wird sichergestellt, dass Verkehrsmeldungen und Strategien aus dezidierten Gebieten an den MDM weitergeleitet und damit ausgetauscht werden können. Hier entsteht somit ein weiterer Mehrwert im Bereich der Datenverwendung auf bundesweiter Ebene. Die Anbindung an den MDM muss dabei in Abstimmung mit den Inhalteanbietern festgelegt werden.

Auf regionaler Ebene müssen ''Pflegewerkzeuge'' (Client) die Erfassung, Verortung von Verkehrsmeldungen und Verkehrslenkungs- und Steuerungsstrategien ermöglichen. Die Pflegewerkzeuge müssen mandantenfähig sein, so dass jeder Akteur des regionalen Verkehrsmanagements seine Strategien selber einpflegen kann. Pflegewerkzeuge sind damit eine wichtige Teilkomponente zur Etablierung eines regionalen (dynamischen) Verkehrsmanagements.

Damit wird es im Rahmen der „Informationslogik“ möglich, dass die von der Intermodalen Logik unter Berücksichtigung regionaler und individueller Strategien berechnete multimodale Reise von den eigenen Routerinstanzen der Dienstleister (App-Service, Autonavigationsgerät) übernommen wird und in ihr Routing unverfälscht eingebunden wird. Damit kann der Einwirkungsbereich auf das Mobilitätsverhalten aller Zielgruppen vergrößert werden.

'''Vertriebslogik'''

Die Komponente (IT-Schicht) „Vertriebslogik“ verarbeitet Buchungs-, Stornierungs- und Bezahlvorgänge von Produkten, Dienstleistungen oder Auskünften (Informationen) der Inhalteanbieter.

Aus Sicht der öffentlichen Hand (Auskunftspflicht) bedeutet „Multimodale Reiseinformation“ die alleinige Realisierung aller Komponenten in der Infor mationslogistik. Eine Akzeptanz und dauerhafte Nutzung der IVS-Referenzarchitektur „Multimodale Reiseinformation“ wird sich nach heutigen Erkenntnissen (z.B. VAO) nur einstellen, wenn sich die angezeigten Verkehrsanbindungen auch einfach und verlässlich buchen lassen. Dies ist notwendig, um
* eine Verbindlichkeit mit der Reiseinformation zu verknüpfen (z.B. Umstieg auf den ÖPNV am P+R-Platz durch Kauf der Fahrberechtigung im ÖPNV und des Einfahrtberechtigung in den P+R-Platz vor oder während der Reise),
* die freie Wirtschaft zu endkundenorientierten Angeboten und Lösungen zu bewegen und
* um die Prozesse rund um die Dienstreise und deren Abrechnung zu automatisieren bzw. zu optimieren.

Um entlang von Reiseketten nicht nur diskriminierungsfrei alle Informationen über die möglichen Produkte und Dienstleistungen anbieten zu können, muss auch die Buchung und der Kauf dieser angebotenen Produkte und Dienstleistungen diskriminierungsfrei für alle Zielgruppen möglich sein. In Anbetracht von z. B. einem unerwarteten Ereignis auf einer Reise wird damit gewährleistet, dass der Kunde nicht nur Alternativen aufgezeigt bekommt, sondern diese auch direkt wahrnehmen kann ohne einen Medienbruch und damit neue Unsicherheiten auf sich zu nehmen. Die Zielgruppen (Nutzer) sparen Zeit, sie bekommen vereinfachte Prozesse vor und während der Reise und somit Vertrauen und Sicherheit in die „Multimodale Reiseinforma-tion“.
Des Weiteren kann durch die Einbindung der Komponente „Vertriebslogik“ in die Architekturvision der „Multimodalen Reiseinformation“ auch kommerziel-le Elemente wie Inzentivierung, Gamification oder Anreizprogramme zur Un-terstützung der Akzeptanz öffentlicher Strategien (z. B. Umsteigen auf den Öffentlichen Verkehr) bei Zielgruppen genutzt werden. In der weiteren Folge lassen sich damit BI-Möglichkeiten zur Erstellung von Statistiken über Rei-sekosten und deren Veränderung über die Jahre (Kostensteigerung) abbil-den. Damit können die Zielgruppen finanzielle und zeitliche Steuerungs-maßnahmen für sich und ihr Mobilitätsverhalten einfach erkennen und ablei-ten.
Eine IVS-Referenzarchitektur „Multimodale Reiseinformation“ darf sich da-her nicht nur auf die Informationslogik zurückziehen, sondern muss auch bei der Komponente „Vertriebslogik“ einen diskriminierungsfreien Einsatz an-gemessen vorsehen und beschreiben.

Data Hub
Die Komponente (IT-Schicht) „Data Hub“ stellt die Serverseitige Organisati-onseinheit der Komponenten der „Multimodalen Reiseinformation“ dar. Es beinhaltet u. a. das
 Datenmanagement und Datensicherheit (Überlassung, Weitergabe, Nutzung, Regeln, Status)
 Schnittstellenmanagement (Status, Version)
 System Management (Speicher, Verteilung)
 Lastmanagement (Anfragen, Verteilung)
 Hasardmanagement (Angriffe)
 Protokollwesen (LOG-Files, BI-Nutzung)
Der Data Hub erlaubt die kontrollierte Anbindung an die Big-Data-Analystik und an Data-Ware-Houses durch Tracing- und Tracking-Prozesse des Da-tenflusses über den/die neutralen Dienstbetreiber „Multimodale Reiseinfor-mation“. Dadurch können zukünftig auf Seiten der
 öffentlichen Hand Planungs- und Verkehrssteuerungsprozesse opti-miert und auf Seiten der
 Privatwirtschaft Mehrwertdienste entwickelt und an den Endnutzer verkauft werden.

Kap. 7 Architekturprinzipien und Geschäftsprinzipien

2016-06-17T14:00:33Z

Weber: Die Seite wurde neu angelegt: „== Bestätigung und Ausarbeitung von Architekturprinzipien, einschließlich Geschäftsprinzipien == Die Multimodale Reiseinformation stellt mit ihren zahlreic…“

== Bestätigung und Ausarbeitung von Architekturprinzipien, einschließlich Geschäftsprinzipien ==

Die Multimodale Reiseinformation stellt mit ihren zahlreichen Aspekten wie z.B.:

* Inhalteanbietern, Dienstbetreibern und Dienstanbietern
* gemein- und privatwirtschaftlichen Akteuren,
* Informations- und Vertriebslogistik sowie
* unterschiedlichen Datenmodalitäten (Qualität, Quantität und Intensität der Datenlieferung)

eine sehr komplexe Domäne dar.

Architekturprinzipien helfen dabei diese Komplexität zu beherrschen. Entstanden aus erfolgreichen Strategien, komprimieren Prinzipien Inhalte zu anwendbaren und verständlichen Handlungsempfehlungen. Es ist empfehlenswert, dass alle Prinzipien gleichzeitig berücksichtigt werden, um eine gute IVS-Referenzarchitektur zu erstellen.

Als grundlegendes Qualitätsmerkmal für Architekturprinzipien sollen gelten:

* '''Einfachheit''':
** Einzelne Elemente der Architektur sollen möglichst einfach sein
** Das Zusammenspiel der Elemente der Architektur soll einfach sein
* '''Klarheit / Verständlichkeit''':
** Leichte Erkennbarkeit der Aufgaben einzelner Elemente
** Leichte Erkennbarkeit der Interaktion einzelner Elemente
* '''Wirtschaftlichkeit''':
** Einzelne Elemente sollen möglichst selbst tragfähig sein
** Nicht selbst tragfähige aber notwendige Elemente sollen gemeinwirtschaftlich tragfähig sein
* '''Wartbarkeit und Erweiterbarkeit''':
** Einzelne Elemente sollen ohne Abhängigkeit zu anderen Elementen gewartet und erweitert werden können
** Die Schnittstellen zwischen einzelner Elemente sollen standardisiert bzw. offen sein, um auf Erweiterungen einzelner Elemente angepasst reagieren zu können
* '''Betreibbarkeit''':
** Leichter Betrieb der einzelner Elemente
** Leichter Betrieb der Interaktion mit anderen Elementen

Grundlagen einer Entwicklung von Prinzipien sind dabei:
* '''Abstraktion''': Reduktion von Informationen auf wesentliche Informationen
* '''Modularisierung''': Gliederung nach Zusammengehörigkeit
* '''Kapselung''': Implizite und schwer erkennbare Abhängigkeiten reduzieren
* '''Hierarchische Dekomposition''': Gliederung in Ebenen
* '''Begriffliche Dekomposition''': Gliederung nach Eigenschaften und Aspekten
* '''Einheitlichkeit''': Strukturen, Schemata, Muster, Vorgehensweisen beibehalten

bezogen auf die Domäne „Multimodale Reiseinformation“ ergeben sich damit acht anzuwendende Architekturprinzipien:
* '''Trennung von Zuständigkeiten'''
** Jeder Akteur sollte möglichst nur für eine Aufgabe zuständig sein
** Genaue Definition und Abgrenzung von Aufgaben gegenüber anderen Akteuren
* '''Minimierung von Abhängigkeiten'''
** Minimierung der Abhängigkeiten zwischen den Akteuren und ihren Systemen (z.B. durch Zusammenfassen von Teilen oder durch Entkoppelung)
** Vermeidung von zyklischen Abhängigkeiten (z.B. Verkauf)
* '''Geheimnisprinzip'''
** Kapselung von Wissen und Logik in Teilsystemen
** Akteure (Nutzer) die mit einem Teilsystem interagieren, müssen nur das Notwendige kennen, um sich anschließen und interagieren zu können
** Für die korrespondierenden Akteure sollen Teilsysteme eine spezielle Sicht auf die verwendeten Funktionalität bereit stellen
* '''Homogenität'''
** Vergleichbare Problem- und Aufgabenstellungen sind auf ähnliche Weise zu lösen
** Es sollen gleiche Größen und Einheiten sowie Begriffe verwendet werden
* '''Redundanzfreiheit'''
** In der IVS-Referenzarchitektur sind gleiche Funktionalitäten zu identifizieren, zu verallgemeinern und wieder verwendbar zur Verfügung zu stellen
* '''Schichtenbildung'''
** Unterteilung der Teilsysteme in Schichten
** Eine Schicht bündelt Teilsysteme mit ähnlichem Aufbau bzw. ähnlicher Grundfunktionalität
** Eine Schicht darf nur mit Systemen innerhalb ihrer eigenen Schicht oder einer nächsten darunter oder darüber liegenden Schicht interagieren
* '''Vertragsbasierter Entwurf'''
** Vollständige Beschreibung der Interaktion der Teilsysteme und Akteure über Schnittstellen (Typ, Inhalt, Bedingung)
** Schnittstelle ist ein Vertrag zwischen Akteuren (z.B. Anbieter und Abnehmer von Daten, Informationen) und beschreibt alles, was der Abnehmer wissen muss, um mit dem Anbieter zu interagieren.
** Schnittstellen sollten spezifisch wenn nötig und so generell wie möglich beschrieben werden. Schnittstellen müssen den Austausch von Akteuren und Teilsystemen ermöglichen
* '''Datenhoheit'''
** Festlegung einer einheitlichen Struktur / Modellierung der Daten.
** Festlegung der Verantwortlichkeit über einen Ausschnitt des Datenhaushalts an dezidierte Akteure, die ebenfalls für die Integrität und die Konsistenz dieser Daten sorgen

Kap. 6 Definition des Wirkungsbereichs

2016-06-17T13:47:38Z

Weber: /* Definition des Wirkungsbereichs */

== Definition des Wirkungsbereichs ==

Aufbauend auf der Wertschöpfungskette (siehe z.B. IVS-Rahmenarchitektur im ÖV) und dem damit verbundenen drei Schichtenmodell der Rollen von Akteuren (Inhalteanbieter, Dienstbetreiber, Dienstanbieter) kann für die Domäne „Multimodale Reiseinformation“ eine genaue Zuordnung von Aufgaben und Systemen der Informations- und Vertriebslogistik vorgenommen werden. Die Ausprägung von Aufgaben und Systeme ist dabei von der Rolle und dem Geschäftsmodell des jeweiligen Akteurs abhängig.

Generell muss aber bei der Dimensionierung und Strukturierung des Wirkungsbereichs der IVS-Referenzarchitektur „Multimodale Reiseinformation“ vorgesehen werden, dass drei Strategieebenen in der IVS-Referenzarchitektur Berücksichtigung finden und über unterschiedliche Akteure hinweg vernetzt werden. Diese sind:

* Individuelle Strategien der Zielgruppen auf Ebene der Dienstanbieter (z.B. Autonavigation, private Mobilitäts- und Vertriebsservices für Endkunden wie Online und Offline Reisebüros)
* Öffentliche Strategien auf Ebene der Dienstbetreiber (z.B. Verkehrsmanagement, Mobilitätsmanagement, MDM usw.)
* Betriebliche Strategien auf Ebene der Inhalteanbieter (z.B. Verkehrsunternehmen, Verkehrsleitzentralen, FCD usw.)

Während die Verknüpfung individueller und betrieblicher Strategien seit Jahren zum Status Quo der heutigen Informations- und Vertriebssysteme zählen, ist die Einbindung öffentlicher Strategien aus Stadt und Land in den Informations- und Vertriebssystemen der öffentlichen Hand und der Privaten erst am Anfang. Gerade unter den immer stärker werdenden Aspekten

* der umweltgerechten Verteilung und Durchführung der Mobilität mit multimodalen Verkehrssystemen,
* der wachsenden Notwendigkeit, immer häufiger werdende Verkehrsbehinderungen aufgrund von Umweltkatastrophen (Klimawandel) zu bewältigen, wie auch
* der Notwendigkeit, Verkehrsressourcen aufgrund von wirtschaftlichen und sicherheitsrelevanten Gesichtspunkten besser auszulasten

erfordert eine klare Positionierung und Aufgabenbeschreibung der öffentlichen Hand als maßgebenden Akteur und Mitwirkender bei der „Multimodalen Reiseinformation“. Da diese Rolle hoheitlicher Art ist, grenzt sie sich auch in einer IVS-Referenzarchitektur „Multimodale Reiseinformation“ vertikal von den Rollen der Akteure auf Ebene der Inhalteanbieter und Dienstanbieter ab. Ebenfalls muss aufgrund der mit der öffentlichen Hand ausschließlich verbundenen Auskunftspflicht eine horizontale Trennung der Wirkungs-bereiche vorgesehen werden. So müssen Systeme und Prozesse der Informationslogik, die mit der Aufnahme, Verarbeitung und Weiterreichung von öffentlichen Strategien verbunden sind, noch dem Wirkungsbereich der öffentlichen Hand zugesprochen werden. Während Systeme und Prozesse der Vertriebslogik nur im geringen Umfang in den Wirkungsbereich der öffentlichen Hand fallen.

Im Wesentlichen kann zur Definition des Wirkungsbereichs für die IVS-Referenzarchitektur „Multimodale Reiseinformation“ folgendes zentrales Bild (Abbildung 1) herangezogen werden. Es beschreibt generisch die typischen Rollen in einer „Multimodalen Reiseinformation“ unter Beachtung der Einbindung aller Strategien (individuell, öffentlich, betrieblich).

[[Datei:Wirkungsbereich der IVS-Referenzarchitektur Multimodale Reiseinformation_Konsortium MRK-AMADEUS.JPG|700px|thumb|centre]]

'''Abbildung 1''' Wirkungsbereich der IVS-Referenzarchitektur „Multimodale Reiseinformation“ als generische Darstellung von Akteuren und Domänen

So finden sich auf Ebene der Inhalteanbieter die Instanzen, die Produkte, Dienste und Informationen anbieten (Händler). Auf Ebene der Dienstanbieter stehen alle Akteure, die direkten Kontakt zu den Zielkunden (Reisende) haben, um zu informieren und meist auch, um Produkte und Dienste der Händler zu verkaufen. Allen beiden Ebenen (grün) ist zu Eigen, dass ihre Geschäftsmodelle privat- oder gemeinwirtschaftlich sein können und dass ihre Prozesse und Systeme zu eigenen Domänen mit eigenen Referenzarchitekturen gehören (z.B. Anzeiger – Referenzarchitektur „Fahrgastinformation“ bzw. „Verkehrsinformation Individualverkehr (inkl. C2X)“, Handy/Chip-karte – Referenzarchitektur „Elektronisches Fahrgeldmanagement“).

Damit konzentriert sich der Wirkungsbereich (blau) der IVS-Referenzarchitektur „Multimodale Reiseinformation“ auf die Prozesse und Systeme der Informationslogik der Öffentlichen Hand, auf die Schnittstellen zu den Inhalteanbietern (API Datenanbindung) und zu den Dienstanbietern (API Serviceanbindung) sowie auf die Interaktion zur Vertriebslogik von Dritten. Die IVS-Referenzarchitektur „Multimodale Reiseinformation“ ermöglicht somit die direkte Einbindung von regionalen und überregionalen Strategien (rot) der Öffentlichen Hand sowie deren situative und kampagnenorientierte Kommunikation (rot) in die Informationsbereitstellung der Dienstanbieter. Gleichzeitig erlaubt die Einbeziehung von Aspekten der Vertriebslogik in die IVS-Referenzarchitektur der öffentlichen Hand auch die indirekte Berücksichtigung von ideellen oder monetären Bonussystemen (rot) zur Inzentivierung öffentlicher Strategien, sowie die Schärfung von öffentlichen Strategien durch das Nutzen von Konsumdaten aus Clearingprozessen oder Big Data Analysen (rot).

Bezogen auf einen realen Umsetzungsraum wie Deutschland wird die IVS-Referenzarchitektur „Multimodale Reiseinformation“ viele Inhalteanbieter (grün) und Dienstanbieter (grün) kennen, die sich über die API Datenanbindung und API Serviceanbindung mit der öffentlichen Hand vernetzen. Bezogen auf die Einbindung öffentlicher Strategien und die Zusammenfassung von Inhalteanbietern auf regionaler Ebene wird es in Deutschland aufgrund der föderalen Struktur territorial gesehen dagegen eher eindeutige Akteure der öffentlichen Hand (blau) geben.

Datei:Wirkungsbereich der IVS-Referenzarchitektur Multimodale Reiseinformation Konsortium MRK-AMADEUS.JPG

2016-06-17T13:41:07Z

Weber:

Kap. 6 Definition des Wirkungsbereichs

2016-06-17T13:35:01Z

Weber: /* Definition des Wirkungsbereichs */

Kap. 6 Definition des Wirkungsbereichs

2016-06-17T13:33:52Z

Weber: Die Seite wurde neu angelegt: „== Definition des Wirkungsbereichs == Aufbauend auf der Wertschöpfungskette (siehe z.B. IVS-Rahmenarchitektur im ÖV) und dem damit verbundenen drei Schicht…“

Kap. 5 Transformation des Geschäfts

2016-06-17T13:26:51Z

Weber: Die Seite wurde neu angelegt: „== Bewertung der Reife für eine Transformation des Geschäfts == Die Bereitschaft für die Akzeptanz und Umsetzung der IVS-Referenzarchitektur „Multimodal…“

== Bewertung der Reife für eine Transformation des Geschäfts ==

Die Bereitschaft für die Akzeptanz und Umsetzung der IVS-Referenzarchitektur „Multimodale Reiseinformation“ in Deutschland wird nach den Reifefaktoren von TOGAF eingeschätzt:

* '''Vision:''' Bisher sind die Themen rund um IVS-Rahmen- und Referenzarchitekturen stark durch die öffentliche Hand (v.a. BMVI, BASt) sowie der Forschungslandschaft (z.B. TU München) getrieben. Die Bereitschaft zur Anwendung von IVS-Referenzarchitekturen ist im Allgemeinen in der Privatwirtschaft im Geschäftsgebrauch (Geschäftsprozesse, IT-Systeme) oder durch die Gemeinwirtschaft (Ausschreibung von Leistungen) noch nicht etabliert. Im Hinblick auf die „Multimodale Reiseinformation“ muss daher der Nutzen deutschlandweit seitens der öffentlichen Hand (BMVI) klar und deutlich kommuniziert werden, z.B. an die Bundesländer oder an spezielle Räume in Deutschland (Best Practice). Durch die Fertigstellung der IVS-Referenzarchitekturen (Lose 2-4) sowie die Ausschreibung der ÖV-IVS-Referenzarchitekturen durch den Bund wird sich die Bereitschaft zur Akzeptanz und Umsetzung mittel- und langfristig stark verbessern.

* '''Desire, Willingness, and Resolve:''' Durch die Vergabe der Leistung, der ständigen Projektbegleitung durch den Auftraggeber BASt sowie dem Projektmanagement der Lose, wird sichergestellt, dass die Grundlegenden Arbeiten an der der IVS-Referenzarchitekturen ent-schlossen abgewickelt werden. Der Begleiterkreis trägt die erarbeite-ten Ergebnisse nach Außen.

* '''Need:''' Die Ziele und Konsequenzen für eine erfolgreiche Projektumsetzung wurden diskutiert. Dazu zählen u.a. die zunehmende Vernetzung der Mobilitätssysteme, der dahinterliegenden Geschäftsprozesse der Akteure und der Nutzen für den Reisenden in ganz Deutschland (siehe auch Kapitel 3). Mögliche Konsequenzen bei einer erfolglosen Umsetzung des Projekts müssen im Konsortium noch diskutiert werden. Dazu zählen z.B. die erschwerte Vernetzung von IVS-Diensten in Deutschland auf IT- und Prozessebene sowie ein fehlender Austausch zwischen multimodalen Stakeholdern.

* '''Business Case:''' Neben der Information strebt das Konsortium an, die grundlegenden Schnittstellen zum Vertrieb im Bereich multimodaler Reiseinformation aufzuzeigen. Die Kalkulation eines detaillierten Business Cases ist im Projekt nicht vorgesehen. Es ist jedoch anzumerken, dass eine Akzeptanz und dauerhafte Nutzung der Referenzarchitektur sich voraussichtlich nur einstellen wird, wenn alle beteiligten Stakeholder durch die Partizipation profitieren (Privatwirtschaft) oder einen Nutzen davon haben (Gemeinwirtschaft).

* '''Funding:''' Die Finanzierung für die Projektumsetzung ist durch die Beauftragung gegeben. Mögliche Finanzierungswege für die nachhaltige Pflege der IVS-Referenzarchitektur sind in TOGAF F bis H festzulegen.

* '''Sponsorship and Leadership:''' Das Vorhaben ist auf Bundesebene ausgelöst worden und hat damit die Unterstützung des BMVI, respektive des Bundesverkehrsministers. Weitere Unterstützer sind in der Projektlaufzeit hinzuzugewinnen.

* '''Governance:''' Für die Steuerung und Unterstützung des Projekts wird seitens des Auftraggebers bzw. des Los 1 ein Begleiterkreis festgelegt. Der aktuelle Stand des Projekts kann z.B. im nationalen IVS-Beirat regelmäßig präsentiert und abgestimmt werden, sodass bei Bedarf ein Abgleich mit den nationalen IVS-Strategien erfolgt. Öffentlichkeitswirksame Events (2 in der Projektlaufzeit) sichern den Kontakt und die Unterstützung zu den relevanten Stakeholdern.

* '''Accountability:''' Das Projektkonsortium ist in der Pflicht, die Beschreibung der IVS-Referenzarchitektur umzusetzen und der BASt als anwendbares Dokument zu übergeben. Verantwortlich für die Umsetzung nach der Projektlaufzeit in Deutschland sind das BMVI, nachgeordnete Behörden und die Länder, z.B. als Integration in die Förder- und Vergabelandschaft. Da Stakeholder der Privatwirtschaft nicht verpflichtet werden können, die IVS-Referenzarchitektur umzusetzen, werden in den TOGAF Phasen E bis H Möglichkeiten diskutiert, die entsprechenden Anreize zu setzen.

* '''Workable Approach and Execution Model:''' Für die Umsetzung der Referenzarchitektur „Multimodale Reiseinformation“ in die realen Systeme in Deutschland gibt es bereits sehr ausgeprägte und etablierte Strukturen. Dazu gehören beispielsweise die allgemein anerkannten Regeln und Rahmenbedingungen zur Vergabe von Leistungen und Fördermitteln (Bundesgesetze, Landesgesetze) sowie Vor-gehensweisen (Besteller-Ersteller Prinzipien bzw. öffentliche Hand-Lieferanten). Die entsprechenden Verbände zur Informationsverbreitung (VDV, VDA, ADAC etc.) sind vorhanden.

* '''IT Capacity to Execute:''' Sowohl innerhalb der Projektlaufzeit (Entwicklung IVS-Referenzarchitektur) als auch in der Umsetzungsphase in den Räumen in Deutschland stehen ausreichend Ressourcen zur Verfügung. Für die Projektlaufzeit wird Amadeus die IT-Skills, Tools (kostenfreie UML-Diagrammtools) und Arbeitsprozesse bereitstellen. Für die spätere Umsetzung der Referenzarchitekturen kann auf die deutsche Landschaft von IT-Unternehmen zurückgegriffen werden.

* '''Enterprise Capacity to Execute:''' Die Erfüllung der Anforderungen an das Projekt wurden ausführlich im Angebot dargelegt. Die Auswahl des Konsortiums um MRK/Amadeus basierte u.a. auf den Referenzen, in denen ähnliche Projekte bereits erfolgreich durchgeführt wurden.

* '''Enterprise Ability to Implement and Operate:''' Der „Betrieb“ der IVS-Referenzarchitektur wird nicht durch das Konsortium durchgeführt. Nach erfolgreicher Übergabe des Schlussdokuments und Vorbereitung der Migration bzw. des Änderungsmanagement (TOGAF F bis H) wird die BASt das Management der Architektur fortführen.

Kap. 4 Bewertung der Geschäftsfähigkeiten

2016-06-17T13:14:15Z

Weber: Die Seite wurde neu angelegt: „== Bewertung der Geschäftsfähigkeiten == Der Erfolg einer „Multimodalen Reiseinformation“ ist abhängig von den '''Wirkungen''', d.h. dem Nutzen und Er…“

== Bewertung der Geschäftsfähigkeiten ==

Der Erfolg einer „Multimodalen Reiseinformation“ ist abhängig von den '''Wirkungen''', d.h. dem Nutzen und Ertrag für die Akteure (Stakeholder). Erkenntnisse aus dem Betrieb der Verkehrsauskunft Österreich (VAO) haben gezeigt, dass alleinige Informationen keine wesentlichen Veränderung im Verkehrsverhalten erzeugen können, wenn nicht eine Verbindlichkeit über den Verkauf von Produkten und Dienstleistungen damit verbunden ist.

Heute ist auch klar, dass Daten und Informationen alleine keine Wertschöpfung erzeugen können. Eine nachhaltige Geschäftsfähigkeit erlangen alle Prozessbeteiligten (Akteure) daher erst durch die Verschmelzung von Informationen in der Verbindung mit der Buchung und dem Kauf von Produkten und Dienstleistungen. Insbesondere der im Mittelpunkt stehende Bürger (Zielgruppe) erwartet auf dem gesamten Reiseweg einen umfänglichen, barrierefreien und vollständigen Zugang zu allen für ihn relevanten Daten und Informationen, mit hoher Qualität. Ein Mehrwert stellt sich für ihn dabei nur dann ein, wenn er nicht nur die Informationen erhält, sondern diese auch komfortabel und einfach buchen und bei Störungen umbuchen bzw. stornieren kann. Wenn sich dadurch noch eine zusätzliche Zeitersparnis einstellt, maximieren sich Nutzen und Akzeptanz für den Reisenden und die Geschäftsfähigkeit der „Multimodalen Reiseinformation“ wird maximiert.

Ein weiterer zentraler Aspekt für die Geschäftsfähigkeit ist die Schaffung einer '''Mehrheitsfähigkeit''' für die Referenzarchitektur in Deutschland und die '''Akzeptanz''' der umsetzenden Stellen auf regionaler Ebene. Dazu zählt sowohl die öffentliche Hand, z.B. bei der lokalen Ausschreibung und Umsetzung in den realen Systemen der multimodalen Reiseinformation aber auch die Privatwirtschaft, welche als Lieferanten oder als Teilnehmer im IVS-Wertschöpfungsnetzwerk auftreten.

Die o.g. Punkte zur Wirkung, Mehrheitsfähigkeit und Akzeptanz werden durch die Aufstellung eines Begleiterkreises abgedeckt und gehen nach TOGAF in den Phasen E und F (Implementierung/Migration) auf.

Kap. 3 Geschäftsziele & Geschäftstreiber

2016-06-17T12:50:43Z

Weber: Die Seite wurde neu angelegt: „== Bestätigung und Ausarbeitung von Geschäftszielen, Geschäfts-treibern und Rahmenbedingungen == Die multimodale Reiseinformation orientiert sich an den G…“

== Bestätigung und Ausarbeitung von Geschäftszielen, Geschäfts-treibern und Rahmenbedingungen ==

Die multimodale Reiseinformation orientiert sich an den Geschäftszielen des Los 1 für die „Multimodale Reiseinformation“ für den Organisationsraum Deutschland. Sie sind wie folgt:

* Harmonisierte Einführung von IVS
* Durchgängige und verbesserte IVS-Anwendungen und IVS-Dienste
* Erleichterung bei der Entwicklung und Einführung von IVS-Diensten
* Sicherheit für öffentliche Betreiber bezüglich Kompatibilität und Interoperabilität von IVS-Anwendungen
* Geringerer Entwicklungsaufwand und Planungssicherheit für die Industrie
* Vermeidung technologischer „Insellösungen“
* Verbesserung der Investitionssicherheit und Markttransparenz
* Effizienterer und leichterer Verkehr
* Erhöhung der Verkehrssicherheit und der Wirtschaftlichkeit
* Reduzierung von negativen Umweltwirkungen des Verkehrs

Hinzu kommen für die Referenzarchitektur „Multimodale Reiseinformation“ spezifische Ziele und Rahmenbedingungen, welche sich an den drei zentralen Säulen der etablierten IVS-Rahmenarchitektur ÖV orientieren:

'''Rollen & Geschäftsmodelle''', z.B.:

* Erhaltung des Wettbewerbs/Keine Wettbewerbsverzerrung durch die IVS-Referenzarchitektur für öffentliche und private Unternehmen.
* Zugang zu multimodalen Reiseinformationen: aus politischen und finanziellen Gründen sind regionale „Access Points“ auf Territorialebene zu organisieren, um eine föderal und dauerhaft machbare Umsetzung sicherzustellen. Wie schon in der ÖV-IVS-Rahmenarchitektur und dem Ergebnispapier des IT-Gipfels 2014 des Bundes empfohlen, sind für diese Rolle „Koordinatoren für Mobilitätsdaten“ aufzubauen.
* Erhalt tragbarer Geschäftsmodelle für die „Multimodale Reiseinformation“, insbesondere für die Zusammenarbeit zwischen Privat- und Gemeinwirtschaft.
* Klare Zuständigkeiten innerhalb der Informationslogistik für öffentliche Partner (z.B. BASt/MDM, DELFI) und private Unternehmen.
* Synergien zwischen der Informations- und Transaktionslogistik bilden den Grundstein einer finanzierbaren, nachhaltigen, globalisierten und marktrobusten Referenzarchitektur für „Multimodale Reiseinformation“.
* Transparenz für die Stakeholder in der Wertschöpfungskette der multimodalen Reiseinformation bezüglich ihrer Geschäftsprozesse (z.B. Zuständigkeiten, rechtliche Spielräume, Datenschutz etc.).

'''Regeln & Rahmenbedingungen''', z.B.:

* Diskriminierungsfreiheit für die „Multimodale Reiseinformation“ (unabhängig vom Reisemittel).
* Beschreibung und Qualitätssicherung von „Level of Service“ für multimodale Reiseinformationen.
* Vorausschauende Konzeption für gemeinsame Dienste (insbesondere im Hinblick auf die Verknüpfung von AGBs mit öffentlichem Recht).
* Beachtung der nationalen und EU-Vorgaben bei der Konzeption, Finanzierung und Organisation der Referenzarchitektur.
* Beachtung öffentlicher Strategien bei der Reiseinformation.
* Verwendung und Weiterentwicklung zentraler Datenüberlassungs- und Datennutzungsverträge zwischen den Stakeholdern (z.B. Kommunen, Verkehrsunternehmen, Serviceprovider).
* Einhaltung des Datenschutzes bei der Informations- und Vertriebslogistik.

'''Informations- & Kommunikationstechnologie''', z.B.:

* Interoperabilität und Offenheit zu technischen Hintergrundsystemen für die Reiseinformation.
* Verwendung globaler Standards.
* Sicherung von einheitlichen IT-Qualitätsstandards für die Übermittlung und Verarbeitung von Mobilitätsdaten.
* Sicherstellung von zukünftigen Performance Anforderungen auf allen Systemebenen/-komponenten bei Akzeptanz der multimodalen Reiseinformation bei den Nutzern und im Markt.
* Weiterentwicklung von Technologien, z.B. Verbesserung der fehlenden Flexibilität und Automation der IT-Systeme zum Austausch von Mobilitätsdaten.

Kap. 2 Identifizierung der Stakeholder

2016-06-17T12:41:40Z

Weber: /* Identifizierung von Stakeholdern mit deren Anliegen und Geschäftsanforderungen */

== Identifizierung von Stakeholdern mit deren Anliegen und Geschäftsanforderungen ==
Grundlage für die erfolgreiche Etablierung der Referenzarchitektur ist die Akzeptanz bei den Stakeholdern in Deutschland. Die erste grobe Einteilung der Stakeholder(-gruppen) der Referenzarchitektur zeigt folgender Katalog:

{| class="wikitable"
! Industrie

|-
|- style="vertical-align:top;"

| Energie || EnBW, RWE

|-
|- style="vertical-align:top;"

| Automobil || Automobilhersteller (z.B. BMW, Audi, Daimler) und Zulieferer (z.B. Bosch, Conti)

|-
|- style="vertical-align:top;"

| Verkehrsinfrastruktur || z.B. SWARCO, Siemens

|-
|- style="vertical-align:top;"

| Telekommunikation || Alcatel Lucent, Nokia, Telekom, Telefonica, Vodafone

|-
|- style="vertical-align:top;"

| Informationstechnik || z.B. Toolhersteller

|-
|- style="vertical-align:top;"
! Verbände

|- style="vertical-align:top;"
| || ADAC

|- style="vertical-align:top;"
| || UIC

|- style="vertical-align:top;"
| || IATA

|- style="vertical-align:top;"
| || VDV

|- style="vertical-align:top;"
| || VDA

|- style="vertical-align:top;"
| || ADFC

|- style="vertical-align:top;"
| || Allianz pro Schiene

|- style="vertical-align:top;"
| || Pro Bahn

|- style="vertical-align:top;"
| || VDB

|- style="vertical-align:top;"
| || VDI/VDE

|- style="vertical-align:top;"
| || Bitkom

|- style="vertical-align:top;"
| || ITS-Verbände in Deutschland

|- style="vertical-align:top;"
| || OCA (Open Traffic Systems City Association)

|- style="vertical-align:top;"
| || ADV (Arbeitsgemeinschaft d. dt. Verkehrsflughäfen)

|- style="vertical-align:top;"
| || TISA (Traveller Information Services Association)

|-
|- style="vertical-align:top;"
! Öffentliche Hand

|- style="vertical-align:top;"
| || Städte (Städtetag)

|- style="vertical-align:top;"
| || Kommunen (Landkreistag)

|- style="vertical-align:top;"
| || Ministerien (Landes- und Bundesebene)

|- style="vertical-align:top;"
| || Straßenbauverwaltung

|-
|- style="vertical-align:top;"
! Wissenschaft und Gremien

|- style="vertical-align:top;"
|Hochschulen || z. B. Zeppelin Universität, TU München, TU Dresden

|- style="vertical-align:top;"
|Institute || Fraunhofer, DLR

|- style="vertical-align:top;"
|Standardisierungs-gremien || UIC, OTA, ISO-/CEN-Gremien

|- style="vertical-align:top;"
| || Datenschutzbehörden

|- style="vertical-align:top;"
| || FGSV

|-
|- style="vertical-align:top;"
! Verkehrsunternehmen und -verbünde

|- style="vertical-align:top;"
| || Fernverkehrsunternehmen (z. B. Deutsche Bahn)

|- style="vertical-align:top;"
| || Nahverkehrsunternehmen

|- style="vertical-align:top;"
| || Stadtwerke

|- style="vertical-align:top;"
| || Verkehrsverbünde

|- style="vertical-align:top;"
|Luftfahrt || Lufthansa, Air France, Deutsche Flugsicherung

|- style="vertical-align:top;"
|Schifffahrts- und Seilbahnen || Bayerische Seenschifffahrt GmbH, Sächsische Dampf-schifffahrts-GmbH & Co.

|-
|- style="vertical-align:top;"
! Weitere relevante Dienst- und Datenprovider

|- style="vertical-align:top;"
|Dienstbetreiber || Qixxit, Allryder, Moovel, Odigeo

|- style="vertical-align:top;"
|Dienstbetreiber und Datenprovider || Google, Navteq, TomTom, INRIX

|- style="vertical-align:top;"
|Rundfunkanstalten || ARD-Anstalten, ZDF, WDR, Private, Landesmeldestellen

|- style="vertical-align:top;"
| || Veranstalter

|- style="vertical-align:top;"
| || Gastronomie

|- style="vertical-align:top;"
| || Projektgruppe All Ways Travelling
|}

'''Katalog 1:''' Grobe Einteilung der Stakeholder mit Relevanz für die IVS-Referenzarchitektur „Multimodale Reiseinformation“ (erweiterbar)

Für die Bewertung nach TOGAF werden diese nach den unten stehenden Kriterien bewertet und weitere Stakeholder identifiziert. Folgende Bewertungskriterien im Hinblick auf die Akzeptanz der Referenzarchitektur kommen zum Einsatz:
* Derzeitiges Verständnis
* Erforderliches Verständnis
* Derzeitiges Engagement
* Erforderliches Engagement
* Hemmende Wirkung
* Beeinflussbarkeit durch BASt/BMVI

Als weiteres Kriterium für das Stakeholder Management wird die TOGAF „Stakeholder Power Grid Matrix“ eingesetzt:

[[Datei:Power Grid zur Stakeholderanalyse_Konsortium MRK-AMADEUS.JPG|500px|]]

'''Matrix 1:''' Beispielhafte Darstellung des "Power Grid" zur Stakeholderanalyse

Die Matrix beschreibt den Einfluss für die erfolgreiche Umsetzung der Referenzarchitektur (Power) im Verhältnis zu deren Interesse/Beteiligungsgrad (Level of Interest). Die Schlüsselakteure (Gruppe C und insb. D) sind bei der Einführung der Referenzarchitektur zwingend einzubeziehen. Die Ergebnisse werden in der Stakeholder Map zusammengefasst.

[[Datei:TOGAF A_Stakeholdereinschätzung für die Referenzarchitektur_Konsortium MRK-AMADEUS.JPG|700px|thumb|centre|TOGAF A: Stakeholdereinschätzung für die Referenzarchitektur "multimodale Reiseinformation"]]

[[Datei:Stakeholder Power Grid für Akteure der multimodalen Reiseinformation_Konsortium MRK-AMADEUS.JPG|700px|thumb|centre|Stakeholder Power Grid für die Akteure der "multimodalen Reiseinformation"]]

{| class="wikitable"
! Stakeholder
! Detail
!Key Concerns
!Class (aus Power Grid)

|-
|- style="vertical-align:top;"

| Verkehrsunternehmen/Verbünde (Nahverkehr) || ||| Bedienung lokaler Kundengruppen des ÖPNV, Erhalt der eigenen Rolle in der Wertschöpfungskette der Information und des Vertriebs, Wettbewerb mit anderen Mobilitätanbietern (Car sharing, Uber, usw.) ||| C

|-
|- style="vertical-align:top;"

| Fernverkehr || ||| Stärkere Kundenbindung, Starker Konkurrenzdruck (z.B. Fernbusse vs. DB) über Information und Vertrieb ||| C

|-
|- style="vertical-align:top;"

| Luftfahrt || Flughäfen ||| Kundenfreundliche Anfahrt an den Flughafen, Information und Verkauf über die Anbindungen und Produkte am Flughafen (Non-Aviation) ||| C

|-
|- style="vertical-align:top;"

| || Flugunternehmen ||| Unabhängigkeit von Informations- und Vertriebskanälen Dritter, Bindung von Kunden an das Unternehmen ||| C

|-
|- style="vertical-align:top;"

| Öffentliche Hand || Städte ||| Erhalt der Mobilität, motorisierter Individualverkehr zu dominant, Umweltschäden, Wahrung der Standortvorteile, strategische Verkehrslenkung im Wettbewerb mit privatwirtschaftlichen Services (Routing/Navigation, Parken, usw.) ||| D

|-
|- style="vertical-align:top;"

| || Kommunen ||| Kostendruck, lange Planungsprozesse für Infrastrukturbau ||| A

|-
|- style="vertical-align:top;"

| || Bundesministerien und nachgeordnete Behörden ||| Umsetzbarkeit des politischen Willens ||| D

|-
|- style="vertical-align:top;"

| || Landesministerien ||| Föderaler Wettbewerb, Schonung von Landesmitteln, geringe Fördermittel seitens der Bundesebene ||| C

|-
|- style="vertical-align:top;"

| || Straßenbauverwaltungen, Verkehrsbehörden ||| Erhalt der Infrastruktur, Wettbewerb der Services öffentliche Hand/Private ||| D

|-
|- style="vertical-align:top;"

| Automobilhersteller || ||| Wandel zum Mobilitätsdienstleister, Technologiewandel (Elektromobilität), Zufahrtsbeschränkungen im urbanen Raum aufgrund von Umweltaspekten ||| D

|-
|- style="vertical-align:top;"

| Zulieferindustrie || ||| Roadmap der Automobilhersteller ||| C

|-
|- style="vertical-align:top;"

| Verkehrsinfrastrukturhersteller || ||| Abhängigkeit von Ausschreibungen der öffentlichen Hand, mangelnde Innovationsroadmap, lange Lebensdauer installierter Systeme (Altbestand) ||| A

|-
|- style="vertical-align:top;"

| Telekommunikation || ||| Teilhabe an zukünftigen Geschäftsmodellen von IVS, Annäherung an Automobilindustrie ||| D

|-
|- style="vertical-align:top;"

| Informationstechnik || ||| Eigene Wertschöpfung durch Branchenlösungen ||| D

|-
|- style="vertical-align:top;"

| Verbände || ||| Beeinflussbarkeit der Politik ||| A

|-
|- style="vertical-align:top;"

| Wissenschaft || ||| Forschungsrahmenbedingungen, internationaler Wettbewerb, Markteinführung von Innovationen ||| B

|-
|- style="vertical-align:top;"

| Gremien || ||| Geringe Wirkung auf Innovationen ||| B

|-
|- style="vertical-align:top;"

| Institute || ||| Geringe Marktnähe ||| B

|-
|- style="vertical-align:top;"

| Dienstbetreiber || ||| Alleinstellungsmerkmale, Kundenbindung ||| D

|-
|- style="vertical-align:top;"

| Datenprovider || ||| Privacy, Security, Ownership, Datenverwendung ||| D

|-
|- style="vertical-align:top;"

| Industrie || ||| Verkauf von Techniken zu IVS, Fokus auf Dienste anstatt Produkte ||| D
|}
'''Katalog 2:''' Stakeholder Map für die Akteure der multimodalen Reiseinformation