IVS-Wiki - Benutzerbeiträge [de]

Datei:IVS-RA-Los 3.EAP

2018-09-12T10:22:48Z

Scholtes: Scholtes lud eine neue Version von „Datei:IVS-RA-Los 3.EAP“ hoch

Datei:IVS-RA.EAP

2018-09-11T10:37:00Z

Scholtes: Scholtes lud eine neue Version von „Datei:IVS-RA.EAP“ hoch

IVS-Geschäftsarchitektur Ausgangssituation

2018-05-11T13:16:25Z

Scholtes:

== Beschreibung der Ausgangssituation ==

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

== Beschreibung der Ausgangssituation aus der Sicht "IVS-Wertschöpfungsketten und -netzwerke" ==

Die [[Aufbau_von_IVS-Wertschöfungsketten_und_-netzwerke#IVS-Rollenmatrix|IVS-Rollenmatrix]], in der bestehende Kommunikationswege eingezeichnet sind, ist ein geeignetes Instrument, um Aspekte der Zusammenarbeit im Rahmen von bestehenden IVS-Wertschöpfungsketten/-netzwerken zu identifizieren, die eine sinnvolle Umsetzung der Vision von einer IVS-Geschäftsarchitektur behindern. Das in der folgenden Abbildung dargestellte Beispiel zeigt ein IVS-Wertschöpfungsnetzwerk, bei dem mehrdeutige Kommunikationswege existieren:

[[File:Mehrdeutige Komunikationswege.png|thumb|center|500px|Mehrdeutige Kommunikationswege]]

Die mehrdeutigen Kommunikationswege sind in dieser Abbildung sehr leicht zu erkennen und zu identifizieren.

Die folgende Abbildung zeigt eine gewünschte Veränderung, die dazu führt, dass die Kommunikationswege eindeutig werden:

[[File:Veränderung Kommunikationswege.png|thumb|center|500px|Veränderung Kommunikationswege]]

Das Resultat der Veränderung ist dann in der folgenden Abbildung zu sehen:

[[File:Eindeutige Kommunikationswege.png|thumb|center|500px|Eindeutige Kommunikationswege]]

Im hier dargestellten Beispiel soll klar gemacht werden, dass die Mehrdeutigkeit von Kommunikationswegen für einen IVS-Dienst vermieden werden soll. Das bedeutet jedoch nicht, dass Querverbindungen zwischen Dienstebetreibern oder Inhalteanbietern grundsätzlich nicht sinnvoll oder erlaubt wären. 

=== Beschreibung der Ausgangssituation aus der Sicht "IVS-Governance" ===

Fehlende Governance bzw. fehlende oder hinderliche Teilelemente einer funktionierenden Governance sind sehr häufig die Ursache für das Nicht-Erreichen der IVS-Geschäftsarchitekturvision. So können z. B. (gesetzliche) Regelungen eine Einführung bzw. Umsetzung von IVS-Diensten be- oder verhindern.

=== Beschreibung der Ausgangssituation aus der Sicht "IVS-Geschäftsprozesse" ===

IVS-Wertschöpfungsketten/-netzwerke, die auf der Geschäftsprozessebene auf Grund fehlender Kern- oder Supportprozesse nicht in der erforderlichen Qualität operationalisiert werden können, sind häufig die Ursache für eine fehlende Umsetzbarkeit der IVS-Geschäftsarchitekturvision.

----

[[Hauptseite|<< Zurück zur Hauptseite]]

Ziele und Nutzen

2018-05-11T08:10:22Z

Scholtes:

== Wertbeitrag und KPI's von IVS-Architektur ==

=== Vorbemerkung ===

Oftmals beklagen IVS-Architekten, dass der Wertbeitrag von IVS-Architektur von Realisierern und Machern von IVS-Diensten und IVS-Produkten nicht erkannt, angemessen gewürdigt und richtig bewertet wird. Dies liegt vielleicht auch darin begründet, dass IVS-Architekten nicht in der Lage sind zu vermitteln, welchen Beitrag IVS-Architektur auch zur Erreichung der Ziele solcher Realisierer und Macher leistet und wie dieser Beitrag am Ende mittels geeigneter (Schlüssel-)Leistungskennzahlen (engl. KPI's - Key Perforamance Indikators) messbar ist.

IVS-Architekturprojekte dürfen also kein Selbstzweck sein. Auch bei einem IVS-Architekturprojekt müssen stets konkrete Ziele verfolgt werden. Oberstes Ziel des im Rahmen eines IVS-Projektes arbeitenden IVS-Architekten muss es letztlich sein, dass sich die Schaffung von Konformität eines realen IVS-Dienstes bzw. realen Produktes zu den Vorgaben von IVS-Rahmen- und -Referenzarchitektur für alle Beteiligten, einerseits die IVS-End-Nutzer, aber auch die IVS-Akteure und Stakeholder andererseits, auszahlt sowie IVS-Wertschöpfung und IVS-Wertbeitrag für alle nachvollziehbar und quantifizierbar dargestellt werden können.

=== Zusammenarbeitsfähigkeit als Dreh- und Angelpunkt für IVS-Wertschöpfung ===

Besonderes Wertschöpfungspotential von IVS entsteht, wenn es gelingt, mehrere IVS-Akteure und ihre IVS-Leistungen im Sinne des IVS-End-Nutzers organisationsübergreifend zu integrieren/zu vernetzen (siehe auch [[IVS-Dienste-Konzept#IVS-Wertsch.C3.B6pfungsketten_und_-_netzwerke|IVS-Wertschöpfungskette und -netzwerke]]). Zentraler Dreh- und Angelpunkt zur Erschließung des Nutzenpotentials von IVS ist eine entsprechende '''IVS-Informationslogistik''', d.h. die Organisation, Steuerung, Bereitstellung und Optimierung von Informationsströmen. Insofern müssen organisationsübergreifende Wertschöpfungsketten im IVS-Kontext als Prozessketten für IVS-Informationslogistik begriffen werden, in denen der Umgang mit Informationen von vorrangiger Bedeutung ist.

[[File:FormenDerZusammenarbeit 00-00-02.PNG|thumb|right|250px|Formen der Zusammenarbeit, Quelle: Reinhard Riedl, Fachhochschule Bern, Wirtschaftsinformatik]]

IVS-Informationslogistik setzt die '''Zusammenarbeit der IVS-Akteure''' voraus. Es gilt der Grundsatz: eine bessere Zusammenarbeitsfähigkeit der IVS-Akteure führt zu einer besseren IVS-Informationslogistik und am Ende zu einer höheren IVS-Wertschöpfung für alle Beteiligten.

Wie nebenstehende Abbildung zeigt, kann Zusammenarbeit in folgenden Stufen entwickelt werden:

*Kooperation
*Koordination
*Kollaboration

Über die Stufen hinweg steigt sowohl der Nutzen von Zusammenarbeit als auch die Interdependenzen, das heißt die Abhängigkeiten der IVS-Akteure. Insofern ist die Zusammenarbeit von IVS-Akteuren auch mit '''Risiken ('''siehe '''[[Risiko-Management|Risiken bei der Umsetzung von IVS-Architektur]])''' verbunden.

Vor diesem Hintergrund muss einerseits die '''Förderung der Zusammenarbeitsfähigkeit''' in IVS-Wertschöpfungsketten und -netzwerken und anderseits die '''Vermeidung der mit Zusammenarbeit verbundenen Risiken''' ein Hauptanliegen von IVS-Architektur sein.

=== Interoperabilität als Wertbeitrag und Ziel von IVS-Architektur ===

Die Zusammenarbeitsfähigkeit von IVS-Akteuren in IVS-Wertschöpfungsketten und -netzwerken hängt wesentlich davon ab, wie '''interoperabel''' sie ihre [[IVS-Capibilities|IVS-Geschäftsfähigkeiten]], d.h. ihren auf die vorgegebene IVS-Strategie ausgerichteten Ressourceneinsatz als Kombination von Menschen, Organisation, Prozessen und Technologie gestalten können. Hier setzt IVS-Architektur an, indem '''Interoperabilität''' als Ziel in den Mittelpunkt der architekturellen Bemühungen gestellt wird. Die Bereitstellung von '''Interoperabilitäts-Bausteinen''' wird zum Kernziel von IVS-Architektur.

Doch worum geht es bei Interoperabilität, was ist ihr genereller Wert, wo liegt der Nutzen für die Beteiligten, wie kann Interoperabilität gemessen werden?

== Ziele, Dimensionen und Bewertung von Interoperabilität ==

=== Qualitative Ziele von Interoperabilität ===

==== Interoperabilitätsdiskussion auf EU-Ebene ====

[[File:Interoperabilitätslevel.PNG|thumb|right|250px|Interoperabilitätslevel gemäß European Interoperability Framework, Dezember 2010]]

'''Everything open, everything digital, everything cross-border! (EU-Council Conclusions, Oktober 2013)'''

*"The modernisation of public administrations should continue through the swift implementation of services such as e-government, e-health, e-invoicing and e-procurement. This will lead to more and better digital services for citizens and enterprises across Europe, and to cost savings in the public sector.
*Open data is an untapped resource with a huge potential for building stronger, more interconnected societies that better meet the needs of the citizens and allow innovation and prosperity to flourish.
*Interoperability and the re-use of public sector information shall be promoted actively.
*EU legislation should be designed to facilitate digital interaction between citizens and businesses and the public authorities. Efforts should be made to apply the principle that information is collected from citizens only once, in due respect of data protection rules."

'''European Interoperability Framework (E. Government)'''

*Ziel der EU: E-Government Dienstleistungen sollen von der ganzen EU Bevölkerung unabhängig vom Herkunftsland oder Aufenthaltsort genutzt werden können.
*Herausforderung: Die bestehenden Dienstleistungen sind in nationalen Strukturen entstanden. Sie sind nicht interoperabel.

==== Stakeholder (Politik) ====

*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
*Vermeidung technologischer „Insellösungen“

==== IVS-Akteure ====

*Reduzierung der Abhängigkeit von Ressourcen, Bündelung von Ressourcen und Schaffung neuer Kapazitäten
*Planungssicherheit, Verbesserung der Investitionssicherheit und Markttransparenz
*Reduktion von Kosten, geringerer Entwicklungsaufwand
*Risikominimierung in allen Unternehmensbereichen
*Besserer Umgang mit wachsender Komplexität von Umgebungsbedingungen und Technologieeinsatz
*Neue Marktchancen und Möglichkeit zum Eintritt und zur Integration in segmentierte Marktdomänen

=== Dimensionen von Interoperabilität ===

Interoperabilität hat mehrere Dimensionen. Im Sinne der IVS-Pyramide können sie auch nach Ebenen geordnet werden:

{| class="wikitable"
|-
! Ebene der IVS-Pyramide
! Interoperabilitäts-Kategorie
! IVS-Architekturbaustein / IVS-Deliverable
! Wertbeitrag des IVS-Architekturbausteins
! KPI's
|- style="vertical-align:top"
| '''Alle'''
| Semantische Interoperabilität
|
*[[Glossar-Template|IVS-Glossar]]
*[[IVS-Architekturprinzip|IVS-Architekturprinzipien]]
*[[IVS-Domäne-Template|IVS-Domäne]]
*[[IVS-Dienst-Template|IVS-Dienst]]

| Gemeinsames Verstehen und gemeinsames IVS-Architekturverständnis
|
*Begriffs- und Sprachkompatibilität,
*Transparenz hinsichtlich Risiken auf allen Ebenen,
*Schnelligkeit/Einigkeit bei zu treffenden Entscheidungen,
*Konformität IVS-Strategie mit allen Ebenen.

|- style="vertical-align:top"
| '''Strategie-Ebene'''
| Strategische Interoperabilität
|
*[[IVS-Leitbild|IVS-Leitbild]]
*[[IVS-Geschäftsziele-Template|IVS-Geschäftsziele]]
*[[IVS-Vision-Template|IVS-Architekturvision]]
*[[WertbeitragVonIVS-Architektur-Template|Wertbeitrag und KPI's von IVS-Architekturbausteinen]]
*[[IVS-Risikomanagement-Template|Risiko von IVS-Architektur]]

| Gemeinsame IVS-Strategie
| Gesparte Kosten durch IVS-Architektur/generierter Mehrwert (z. B. neue Kunden) durch IVS-Dienst:
*Transparenz der IVS-Strategie und IVS-Ziele,
*Transparenz des Alignements zwischen IVS-Strategie und IT,
*Zufriedenheit der Reisenden mit der Fahrtdauer/Stau-Anteilen/Kosten der Reise.

|- style="vertical-align:top"
| '''Prozess-Ebene'''
| Prozess-Interoperabilität
|
*[[IVS-RollenMap-Template|IVS-Rollen-Map]]
*[[IVS-Rolle|IVS-Rolle]]
*[[IVS-Capability-Template|IVS-Capability]]
*[[IVS-Geschäftsprozess|IVS-Geschäftsprozess]]
*[[IVS-Anforderungen|IVS-Anforderungen an IVS-Geschäftsprozesse]]

|
Gemeinsame Verständnis von IVS-Rollen und Zusammenarbeit,

Verbesserung der Zusammenarbeits-prozesse.

|
Zufriedenheit der IVS-Akteure mit der Opeartionalität der IVS-Dienste,

Zufriedenheit der IVS-End-Nutzer mit der Nutzbarkeit und Zuverlässigkeit von IVS-Diensten.

|- style="vertical-align:top"
| '''Informationsstruktur-Ebene'''
| Informationstechnische Interoperabilität
|
*[[IVS-Informationsobjekt|IVS-Informationsobjekt]]
*[[IVS-Datenmodell|IVS-Datenmodell]]
*[[IVS-Ortsreferenzierung|IVS-Ortsreferenzierung]]

| Gemeinsames Verständnis bzgl. Syntax und Semantik der auszutauschenden IVS-Informationsobjekte
|
Aufwand der Datenbeschaffung sinkt.

|- style="vertical-align:top"
| '''IT-Dienste-Ebene'''
| Interoperabilität von IT-Diensten
|
*[[IVS-Anwendung|IVS-Anwendung]]
*[[IVS-Schnittstelle|IVS-Schnittstelle]]

| Gemeinsames Verständnis der IVS-Schnittstellen
|
*Verbesserung des Grads der Automatisierung,
*Compliance mit Regularien/Standards.

|- style="vertical-align:top"
| '''IT-Infrastruktur-Ebene'''
| Interoperabilität von IT-Infrastrukturen
|
| Komplexität der Infrastrukturen wird reduziert.
|
*Transparenz der IT Infrastruktur für IVS-Akteure.

|}

=== Reifegrade von Interoperabilität ===

Für die Bewertung von Interoperabilität im Rahmen von Gap-Analysen kann der Reifegrad von Interoperabilität verwendet werden. Die folgende Quelle liefert dazu geeignete Ansatzpunkte:

[[File:InteroperabilitätsReifegrade.PNG|thumb|left|500px|Reifegrade von Interoperabilität, Quelle: Reinhard Riedl, Fachhochschule Bern, Wirtschaftsinformatik]]

----

[[Hauptseite|<< Zurück zur Hauptseite]]

Ziele und Nutzen

2018-05-11T08:09:05Z

Scholtes:

== Wertbeitrag und KPI's von IVS-Architektur ==

=== Vorbemerkung ===

Oftmals beklagen IVS-Architekten, dass der Wertbeitrag von IVS-Architektur von Realisierern und Machern von IVS-Diensten und IVS-Produkten nicht erkannt, angemessen gewürdigt und richtig bewertet wird. Dies liegt vielleicht auch darin begründet, dass IVS-Architekten nicht in der Lage sind zu vermitteln, welchen Beitrag IVS-Architektur auch zur Erreichung der Ziele solcher Realisierer und Macher leistet und wie dieser Beitrag am Ende mittels geeigneter (Schlüssel-)Leistungskennzahlen (engl. KPI's - Key Perforamance Indikators) messbar ist.

IVS-Architekturprojekte dürfen also kein Selbstzweck sein. Auch bei einem IVS-Architekturprojekt müssen stets konkrete Ziele verfolgt werden. Oberstes Ziel des im Rahmen eines IVS-Projektes arbeitenden IVS-Architekten muss es letztlich sein, dass sich die Schaffung von Konformität eines realen IVS-Dienstes bzw. realen Produktes zu den Vorgaben von IVS-Rahmen- und -Referenzarchitektur für alle Beteiligten, einerseits die IVS-End-Nutzer, aber auch die IVS-Akteure und Stakeholder andererseits, auszahlt sowie IVS-Wertschöpfung und IVS-Wertbeitrag für alle nachvollziehbar und quantifizierbar dargestellt werden können.

=== Zusammenarbeitsfähigkeit als Dreh- und Angelpunkt für IVS-Wertschöpfung ===

Besonderes Wertschöpfungspotential von IVS entsteht, wenn es gelingt, mehrere IVS-Akteure und ihre IVS-Leistungen im Sinne des IVS-End-Nutzers organisationsübergreifend zu integrieren/zu vernetzen (siehe auch [[IVS-Dienste-Konzept#IVS-Wertsch.C3.B6pfungsketten_und_-_netzwerke|IVS-Wertschöpfungskette und -netzwerke]]). Zentraler Dreh- und Angelpunkt zur Erschließung des Nutzenpotentials von IVS ist eine entsprechende '''IVS-Informationslogistik''', d.h. die Organisation, Steuerung, Bereitstellung und Optimierung von Informationsströmen. Insofern müssen organisationsübergreifende Wertschöpfungsketten im IVS-Kontext als Prozessketten für IVS-Informationslogistik begriffen werden, in denen der Umgang mit Informationen von vorrangiger Bedeutung ist.

[[File:FormenDerZusammenarbeit 00-00-02.PNG|thumb|right|250px|Formen der Zusammenarbeit, Quelle: Reinhard Riedl, Fachhochschule Bern, Wirtschaftsinformatik]]

IVS-Informationslogistik setzt die '''Zusammenarbeit der IVS-Akteure''' voraus. Es gilt der Grundsatz: eine bessere Zusammenarbeitsfähigkeit der IVS-Akteure führt zu einer besseren IVS-Informationslogistik und am Ende zu einer höheren IVS-Wertschöpfung für alle Beteiligten.

Wie nebenstehende Abbildung zeigt, kann Zusammenarbeit in folgenden Stufen entwickelt werden:

*Kooperation
*Koordination
*Kollaboration

Über die Stufen hinweg steigt sowohl der Nutzen von Zusammenarbeit als auch die Interdependenzen, das heißt die Abhängigkeiten der IVS-Akteure. Insofern ist die Zusammenarbeit von IVS-Akteuren auch mit '''Risiken ('''siehe '''[[Risiko-Management|Risiken bei der Umsetzung von IVS-Architektur]])''' verbunden.

Vor diesem Hintergrund muss einerseits die '''Förderung der Zusammenarbeitsfähigkeit''' in IVS-Wertschöpfungsketten und -netzwerken und anderseits die '''Vermeidung der mit Zusammenarbeit verbundenen Risiken''' ein Hauptanliegen von IVS-Architektur sein.

=== Interoperabilität als Wertbeitrag und Ziel von IVS-Architektur ===

Die Zusammenarbeitsfähigkeit von IVS-Akteuren in IVS-Wertschöpfungsketten und -netzwerken hängt wesentlich davon ab, wie '''interoperabel''' sie ihre [[IVS-Capibilities|IVS-Geschäftsfähigkeiten]], d.h. ihren auf die vorgegebene IVS-Strategie ausgerichteten Ressourceneinsatz als Kombination von Menschen, Organisation, Prozessen und Technologie gestalten können. Hier setzt IVS-Architektur an, indem '''Interoperabilität''' als Ziel in den Mittelpunkt der architekturellen Bemühungen gestellt wird. Die Bereitstellung von '''Interoperabilitäts-Bausteinen''' wird zum Kernziel von IVS-Architektur.

Doch worum geht es bei Interoperabilität, was ist ihr genereller Wert, wo liegt der Nutzen für die Beteiligten, wie kann Interoperabilität gemessen werden?

== Ziele, Dimensionen und Bewertung von Interoperabilität ==

=== Qualitative Ziele von Interoperabilität ===

==== Interoperabilitätsdiskussion auf EU-Ebene ====

[[File:Interoperabilitätslevel.PNG|thumb|right|250px|Interoperabilitätslevel gemäß European Interoperability Framework, Dezember 2010]]

'''Everything open, everything digital, everything cross-border! (EU-Council Conclusions, Oktober 2013)'''

*"The modernisation of public administrations should continue through the swift implementation of services such as e-government, e-health, e-invoicing and e-procurement. This will lead to more and better digital services for citizens and enterprises across Europe, and to cost savings in the public sector.
*Open data is an untapped resource with a huge potential for building stronger, more interconnected societies that better meet the needs of the citizens and allow innovation and prosperity to flourish.
*Interoperability and the re-use of public sector information shall be promoted actively.
*EU legislation should be designed to facilitate digital interaction between citizens and businesses and the public authorities. Efforts should be made to apply the principle that information is collected from citizens only once, in due respect of data protection rules."

'''European Interoperability Framework (E. Government)'''

*Ziel der EU: E-Government Dienstleistungen sollen von der ganzen EU Bevölkerung unabhängig vom Herkunftsland oder Aufenthaltsort genutzt werden können.
*Herausforderung: Die bestehenden Dienstleistungen sind in nationalen Strukturen entstanden. Sie sind nicht interoperabel.

==== Stakeholder (Politik) ====

*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
*Vermeidung technologischer „Insellösungen“

==== IVS-Akteure ====

*Reduzierung der Abhängigkeit von Ressourcen, Bündelung von Ressourcen und Schaffung neuer Kapazitäten
*Planungssicherheit, Verbesserung der Investitionssicherheit und Markttransparenz
*Reduktion von Kosten, geringerer Entwicklungsaufwand
*Risikominimierung in allen Unternehmensbereichen
*Besserer Umgang mit wachsender Komplexität von Umgebungsbedingungen und Technologieeinsatz
*Neue Marktchancen und Möglichkeit zum Eintritt und zur Integration in segmentierte Marktdomänen

=== Dimensionen von Interoperabilität ===

Interoperabilität hat mehrere Dimensionen. Im Sinne der IVS-Pyramide können sie auch nach Ebenen geordnet werden:

{| class="wikitable"
|-
! Ebene der IVS-Pyramide
! Interoperabilitäts-Kategorie
! IVS-Architekturbaustein / IVS-Deliverable
! Wertbeitrag des IVS-Architekturbausteins
! KPI's
! Messeverfahren
|- style="vertical-align:top"
| '''Alle'''
| Semantische Interoperabilität
|
*[[Glossar-Template|IVS-Glossar]]
*[[IVS-Architekturprinzip|IVS-Architekturprinzipien]]
*[[IVS-Domäne-Template|IVS-Domäne]]
*[[IVS-Dienst-Template|IVS-Dienst]]

| Gemeinsames Verstehen und gemeinsames IVS-Architekturverständnis
|
*Begriffs- und Sprachkompatibilität,
*Transparenz hinsichtlich Risiken auf allen Ebenen,
*Schnelligkeit/Einigkeit bei zu treffenden Entscheidungen,
*Konformität IVS-Strategie mit allen Ebenen.

|  ??
|- style="vertical-align:top"
| '''Strategie-Ebene'''
| Strategische Interoperabilität
|
*[[IVS-Leitbild|IVS-Leitbild]]
*[[IVS-Geschäftsziele-Template|IVS-Geschäftsziele]]
*[[IVS-Vision-Template|IVS-Architekturvision]]
*[[WertbeitragVonIVS-Architektur-Template|Wertbeitrag und KPI's von IVS-Architekturbausteinen]]
*[[IVS-Risikomanagement-Template|Risiko von IVS-Architektur]]

| Gemeinsame IVS-Strategie
| Gesparte Kosten durch IVS-Architektur/generierter Mehrwert (z. B. neue Kunden) durch IVS-Dienst:
*Transparenz der IVS-Strategie und IVS-Ziele,
*Transparenz des Alignements zwischen IVS-Strategie und IT,
*Zufriedenheit der Reisenden mit der Fahrtdauer/Stau-Anteilen/Kosten der Reise.

|  ??
|- style="vertical-align:top"
| '''Prozess-Ebene'''
| Prozess-Interoperabilität
|
*[[IVS-RollenMap-Template|IVS-Rollen-Map]]
*[[IVS-Rolle|IVS-Rolle]]
*[[IVS-Capability-Template|IVS-Capability]]
*[[IVS-Geschäftsprozess|IVS-Geschäftsprozess]]
*[[IVS-Anforderungen|IVS-Anforderungen an IVS-Geschäftsprozesse]]

|
Gemeinsame Verständnis von IVS-Rollen und Zusammenarbeit,

Verbesserung der Zusammenarbeits-prozesse.

|
Zufriedenheit der IVS-Akteure mit der Opeartionalität der IVS-Dienste,

Zufriedenheit der IVS-End-Nutzer mit der Nutzbarkeit und Zuverlässigkeit von IVS-Diensten.

|
|- style="vertical-align:top"
| '''Informationsstruktur-Ebene'''
| Informationstechnische Interoperabilität
|
*[[IVS-Informationsobjekt|IVS-Informationsobjekt]]
*[[IVS-Datenmodell|IVS-Datenmodell]]
*[[IVS-Ortsreferenzierung|IVS-Ortsreferenzierung]]

| Gemeinsames Verständnis bzgl. Syntax und Semantik der auszutauschenden IVS-Informationsobjekte
|
Aufwand der Datenbeschaffung sinkt.

|
|- style="vertical-align:top"
| '''IT-Dienste-Ebene'''
| Interoperabilität von IT-Diensten
|
*[[IVS-Anwendung|IVS-Anwendung]]
*[[IVS-Schnittstelle|IVS-Schnittstelle]]

| Gemeinsames Verständnis der IVS-Schnittstellen
|
*Verbesserung des Grads der Automatisierung,
*Compliance mit Regularien/Standards.

|
|- style="vertical-align:top"
| '''IT-Infrastruktur-Ebene'''
| Interoperabilität von IT-Infrastrukturen
|
| Komplexität der Infrastrukturen wird reduziert.
|
*Transparenz der IT Infrastruktur für IVS-Akteure.

|
|}

=== Reifegrade von Interoperabilität ===

Für die Bewertung von Interoperabilität im Rahmen von Gap-Analysen kann der Reifegrad von Interoperabilität verwendet werden. Die folgende Quelle liefert dazu geeignete Ansatzpunkte:

[[File:InteroperabilitätsReifegrade.PNG|thumb|left|500px|Reifegrade von Interoperabilität, Quelle: Reinhard Riedl, Fachhochschule Bern, Wirtschaftsinformatik]]

----

[[Hauptseite|<< Zurück zur Hauptseite]]

Weiterentwicklung & Pflege der IVS-Architekturen 1.0

2018-05-11T08:02:15Z

Scholtes:

== Aufgabenstellung ==

Die Entwicklung einer ersten Version der in diesem Projekt definierten Architekturen (Rahmenwerk für IVS-Architekturen und die in den Losen 2-4 ausgeschriebenen drei IVS-Referenzarchitekturen) ist ein wichtiger Schritt hin zu plan- und steuerbaren IVS-Diensten, die zur Verbesserung der Umweltverträglichkeit, zur Steigerung der Effizienz und zur Erhöhung der Sicherheit im Straßenverkehr beitragen können.

Aufgrund sich ständig ändernder Rahmenbedingungen (z.B. Hinzukommen neuer Stakeholder und Anwendungsfelder, Entwicklung neuer Technologien, Änderung der gesetzlichen Anforderungen) ist es notwendig, das Rahmenwerk für IVS-Architekturen in regelmäßigen Abständen auf ihre Aktualität und Gültigkeit zu überprüfen und gegebenenfalls anzupassen. Auch TOGAF sieht z.B. eine ständige Kontrolle und Weiterentwicklung vor. Wichtig ist dazu eine Institutionalisierung dieser Aufgaben der Aktualisierung, Anpassung und Pflege deren Organisation und Finanzierung. Insofern beinhaltet das Konzept für die Weiterentwicklung und Pflege des Rahmenwerks für IVS-Architekturen folgenden Aufgaben:

*Um Wirkung und Nutzen des Rahmenwerks für IVS-Architekturen auf Dauer erhalten und vorantreiben zu können, muss ein Konzept für den Prozess der Einführung, Weiterentwicklung und Pflege des Rahmenwerks für IVS-Architekturen (Weiterentwicklungs- und Pflegeprozess) entwickelt werden. Dabei sollte neben der Weiterentwicklung des in diesem Projekt definierten Rahmenwerks für IVS-Architekturen und IVS-Referenzarchitekturen auch die Identifikation und Entwicklung weiterer IVS Referenzarchitekturen berücksichtigt werden.

*Für die Einführung und Umsetzung des Weiterentwicklungs- und Pflegeprozesses muss ein Organisations- und Finanzierungskonzept erarbeitet werden. Wichtig ist insbesondere dabei, die Zuständigkeiten für die Weiterentwicklung und Pflege festzulegen. Dabei ist eine Verankerung im IVS-Gesetz sicherlich sinnvoll.

== Weiterentwicklung und Pflege des Rahmenwerks für IVS-Architekturen ==

=== Problemstellung ===

Das nationale Rahmenwerk für IVS-Architekturen für Deutschland (kurz: RIAD) ist konzeptionell ein an neue Anforderungen der Anwenderseite anpassbares Meta-Modell für die Entwicklung von IVS-Referenzarchitekturen und IVS-Architekturen realer IVS-Dienste.

Um Planungs- und Rechtssicherheit in der Anwendung und Handhabung des TOGAF-basierten Vorgehensmodells zur Entwicklung von IVS-Architekturen und der auf den fünf Ebenen der IVS-Pyramide angesiedelten, primär die Zusammenarbeit von IVS-Akteuren adressierenden Kernaspekte von IVS-Architektur zu erhalten, muss dem Rahmenwerk für IVS-Architekturen quasi der Stellenwert eines Standards beigemessen werden.

Dem Wesen eines Standards entsprechend, muss die Festlegung dessen, was das Rahmenwerk für IVS-Architekturen ist und wie es angepasst oder erweitert wird, auf einer übergeordneten, neutralen Ebene geregelt werden.

Das Rahmenwerk für IVS-Architekturen muss deshalb Betrachtungs- und Handlungsgegenstand eines offenen und transparenten Prozesses sein, der einen unmittelbaren Bezug zu Einrichtungen besitzt, welche die Kompetenz einer Standardisierungseinrichtung besitzen sollen. Der Anspruch, das Rahmenwerk als offenen Standard verfügbar zu machen, stellt an die an diesem Prozess beteiligten Personen bestimmte Anforderungen im Hinblick auf Kompetenz und Unabhängigkeit. Es muss mit dem Rahmenwerk für IVS-Architekturen eine Interessenslage geweckt werden, die Personen dazu motiviert, sich am Prozess zum Zwecke der Pflege und Fortschreibung des Standards nebst der Festlegung der erforderlichen Konformitäts-Rahmenbedingungen zu beteiligen.

Einrichtungen und Unternehmen, die solche Personen beschäftigen, müssen Mittel bereitstellen wollen, damit sich Mitarbeiter auch wirklich an diesem Prozess beteiligen können. Damit das Rahmenwerk für IVS-Architekturen ein offener Standard bleibt, werden Mechanismen benötigt, die dies sicherstellen.

Eine gewisse Anlehnung an die Verfahren anderer Standardisierungseinrichtungen scheint hier angebracht. Ziel muss es sein, eine Organisationsgrundstruktur, das Qualitätsmanagement und die Anbindung an die Standardisierung zu entwickeln. Auf Grundlage dieses Modells soll der Weiterentwicklungs- und Pflegeprozess nach Möglichkeit unter Beteiligung aller in die Entwicklung und den Betrieb von IVS und IVS-Diensten involvierten und aller sonstigen Stakeholder im Bereich IVS (Bund, Länder, Industrie, Beratungsunternehmen, …) institutionalisiert und instanziiert werden.

=== Der Prozess zur Weiterentwicklung und Pflege des Rahmenwerks für IVS-Architekturen ===

Standards müssen in einem lebendigen Prozess gepflegt und weiterentwickelt werden, sonst drohen sie zu verkümmern. So ist der aktuelle Stand des Rahmenwerks für IVS-Architekturen lediglich eine Momentaufnahme im Gesamtprozess, die durch folgende Abbildung visualisiert wird:

[[File:IVS-RA-Prozess.jpg|500px|Organisation des IVS-Rahmenarchitektur Prozesses]]

Das Prozessmodell stellt sich als ein Kreislauf dar, der sich grundsätzlich für jede Version des Rahmenwerks in vier Phasen unterteilen lässt. Nach der Freigabe einer Version des Rahmenwerks für IVS-Architekturen, die aus Nutzersicht einer Bereitstellung der Version entspricht, erfolgt die Anwendung durch die Nutzer. Diese wird durch den Anwendersupport unterstützt. Feedback der Nutzer wird als Rückkopplung in das Rahmenwerk aufgenommen. Diese Rückmeldungen zu den aktuellen Versionen des Rahmenwerks für IVS-Architekturen sind von großer Bedeutung zur Weiterentwicklung bzw. zur Fehlerbehebung und wirken häufig als Initialzündung für die weitere Pflege des Rahmenwerks für IVS-Architekturen. Die in der Folge von IVS-Architekten entwickelten Versionen des Rahmenwerks für IVS-Architekturen werden in einer neuen (Unter-)Version dem Markt zur Verfügung gestellt.

Durch die Dokumentation des Weiterentwicklungs- und Pflegeprozesses (Ereignisverfolgung/Issue-Tracking) sowie ggfs. die Veröffentlichung von Ergebnissen von begleitenden Forschungsprojekten werden die Nutzer stets über den aktuellen Stand informiert und damit aktiv bei der Umsetzung unterstützt. Eine formelle Freigabe von Ergebnissen des Prozesses gibt den Anwendern zusätzlich Planungssicherheit. Mit diesen Maßnahmen soll die Akzeptanz des Rahmenwerks für IVS-Architekturen bei den Nutzern gefördert und damit die Voraussetzung für ihre Durchsetzung am Markt geschaffen werden.

Ohne ein gewisses Maß an Marktakzeptanz kann der Weiterentwicklungs- und Pflegeprozess nicht überleben. Durch die Anwendung ergeben sich beim Anwender weitere Bedürfnisse bzw. werden Lücken und Mängel der aktuellen Version des Rahmenwerks für IVS-Architekturen erkennbar, was wiederum durch ein entsprechendes Feedback in den Weiterentwicklungs- und Pflegeprozess eingebracht wird und damit die Weiterentwicklung des Rahmenwerks vorantreibt.

Hieraus ergeben sich grundsätzlich folgende Fragen bzgl. des Standardisierungsprozesses:

*Wie passt sich das Rahmenwerk für IVS-Architekturen an neue Anforderungen an?
*Wie reagiert das Rahmenwerk für IVS-Architekturen auf die Entdeckung von Fehlern?

=== Aufgaben des Weiterentwicklungs- und Pflegeprozesses ===

Die grundsätzlichen Aufgaben des Weiterentwicklungs- und Pflegeprozesses unterteilen sich in die Bereiche

*Pflege des Rahmenwerks für IVS-Architekturen,
*Anwenderunterstützung Öffentlichkeitsarbeit sowie *Selbstverwaltung des Prozesses.

Die Arbeiten zur Pflege des Rahmenwerks für IVS-Architekturen erfordern IVS-Architektur-Kompetenz und können u. U. nur von Experten (BASt, (außer)universitäre Einrichtungen, beratende Unternehmen, Hersteller und Betrieber von IVS-Diensten) übernommen werden. Sie umfassen im Wesentlichen folgende Teilbereiche:

*Pflege und Erweiterung der Basiskonzepte
*Pflege und Erweiterung der IVS-Architekturbausteine
*Pflege und Erweiterung des TOGAF-basierten Vorgehensmodells
*evtl. weitere...

Für die Pflege des Rahmenwerks für IVS-Architekturen müssen transparente und offene Prozedere definiert werden. Diese umfassen beispielsweise die Behebung identifizierter Fehler sowie die Weiterentwicklung des Rahmenwerks auf Basis eingereichter Erweiterungsanträge, die ggf. in Abhängigkeit des Schweregrades bzw. nach einer definierten Prioritätenliste von Experten (IVS-Architektur-Spezialisten) zeitnah behandelt werden.

Die Ergebnisse des Pflegeprozesses werden in das Rahmenwerk für IVS-Architekturen eingearbeitet und im IVS-Wiki veröffentlicht. Neben den vorherigen Aspekten, die mit der Pflege des Rahmenwerks für IVS-Architekturen zu assoziieren sind, haben die nachstehenden Aufgaben einen unterstützenden Charakter und sollten vom Aufwand her nicht unterschätzt werden.

'''Anwendersupport'''

Vor allem sei hier der Anwendersupport genannt. Er gliedert sich in eine Reihe von unterschiedlichen Leistungen, wie z.B. die Bereitstellung des Rahmenwerks für IVS-Architekturen und von weiterführenden, unterstützenden Dokumentationen (z.B. IVS-Referenzarchitekturen). Letztere können sich aus Tutorials, Guidelines, Webinars, etc. zusammensetzen.

Für eine Kollaboration von Entwicklern des Rahmenwerks für IVS-Architekturen und Firmen, die ihre Produktpalette konform zum Rahmenwerk für IVS-Architekturen entwickeln und in ihren Systemlandschaften einsetzen, können als Werkzeuge oder Kommunikationsplattformen internetbasierte Foren etc. eingerichtet und betrieben werden. Beide Werkzeuge/Plattformen benötigen eine aktive Moderation, wenn sie im Rahmen einer problemorientierten Unterstützung als Helpdesk eingerichtet werden sollen.

'''Das RIAD Portal'''

Es soll ein zentrales RIAD Portal aufgebaut werden, über das alle Informationen rund um das Rahmenwerk für IVS-Architekturen zugänglich sind. Es ist aber nicht nur ein Informationszentrum, sondern auch ein Werkzeug für den Weiterentwicklungs- und Pflegeprozess.

Über das Portal sollen nicht nur viele Informationen (Spezifikationen, Erweiterungen, IVS-Referenzimplementierung, u.v.m.) erhältlich sein. Es ist auch erforderlich, ein Issue-Tracker-Modul zu integrieren. Dieses soll eine Feedback-Möglichkeit für Nutzer des Rahmenwerks für IVS-Architekturen enthalten (Fehlerreports, Change-Requests, usw.).

Die folgende Abbildung zeigt das jetzige IVS-Wiki, das zum RIAD Portal ausgebaut werden soll:

[[File:IVS-Wiki.jpg|500px|Das IVS-Wiki Portal]]

'''Öffentlichkeitsarbeit'''

Zu den beschriebenen Aufgaben der Pflege des Rahmenwerks für IVS-Architekturen bedarf es zudem einer regen Öffentlichkeitsarbeit, um einerseits die Ergebnisse der Archtekturarbeit zeitnah einem breiten Nutzerkreis zur Verfügung stellen zu können, und andererseits einen geeigneten „Kanal“ für die Rückkopplung bereit zu halten. Nur über eine nachhaltig gewährleistete Kommunikation kann der Prozess wirklich lebendig gehalten werden. Diesbezüglich werden die Unterhaltung des Internetauftritts inkl. Newsletter, die Durchführung von Nutzerforen, Workshops usw. sowie die Repräsentation auf geeigneten (externen) Veranstaltungen (z.B. auf Messen und Kongressen) wichtige Aufgabenfelder darstellen.

Im Projekt Rahmenwerk für IVS-Architekturen für Deutschland wurde z.B. recht früh mit der Öffentlichkeitsarbeit begonnen, um die interessierten Kreise so früh, wie möglich, einzubeziehen. Zu den insgesamt zwei Veranstaltungen wurde ein breites Fachpublikum eingeladen. Auf den Veranstaltungen wurden die geleisteten inhaltlichen Arbeiten bzw. Ergebnisse im Projekt vorgestellt und das Feedback des Fachpublikums zurück in das Projekt eingespeist. Über die Veranstaltungen wurde erreicht, das Interesse am Projekt und seinen Ergebnissen zu wecken und das Fachpublikum an der Verfolgung des Entwicklungsprozesses zu binden.

'''Sekretariat'''

Letztendlich sollten auch Ressourcen für die Verwaltung des Weiterentwicklungs- und Pflegeprozesses eingeplant werden, die die Koordinierung der Prozessabläufe, verwaltungstechnische Unterstützung der Gremien des Weiterentwicklungs- und Pflegeprozesses, ggf. Verwaltung von Finanzen usw. umfasst. Für diese Aufgaben könnte ein Sekretariat eingerichtet werden. Gemessen an den Aufgaben scheint eine Realisierung des Weiterentwicklungs- und Pflegeprozesses recht komplex und aufwendig zu sein. Es ist jedoch zu bedenken, dass, je transparenter und offener der Pflegeprozess und breiter der Support (auch mit wenigen Mitteln) aufgestellt werden kann, die Chancen für eine breitere Akzeptanz bei Entwicklern und Anwendern des Rahmenwerks für IVS-Architekturen steigen.

== Organisation des Weiterentwicklungs- und Pflegeprozesses ==

=== Überblick ===

Um den Weiterentwicklungs- und Pflegeprozess für Hersteller und Anwender offen und transparent zu gestalten, bedarf es einer für alle Beteiligten klaren Organisation mit definierten Regeln. Die Organisation des Weiterentwicklungs- und Pflegeprozesses orientiert sich dabei an bereits bestehenden erfolgreichen Organisationen. Die nachstehende Grafik gibt einen Überblick über die Ausgestaltung der Organisation. Sie wird im Folgenden weiter erläutert.

[[File:IVS-RA-Prozess Organisation.jpg|500px|Organisation des IVS-Rahmenarchitektur Prozesses]]

=== Stakeholder ===

Wie zuvor beschrieben, wird empfohlen, dass der Weiterentwicklungs- und Pflegeprozess von Anwendern und Herstellern gemeinsam betrieben wird. Ergänzt werden diese Gruppierungen mit der Beteiligung von sonstigen Interessenten, wie z.B. beratende Unternehmen oder (außer-)universitäre Einrichtungen. Anwender und Hersteller, aber auch Sonstige, können in Interessensvertretungen organisiert sein. Welche Interessenvertretungen mit den jeweiligen Gruppierungen z.B. assoziiert sein können, zeigt die folgende Tabelle:

{| border="1" cellpadding="1" cellspacing="1" style="width: 528px;"
|-
! scope="col" style="background-color: rgb(238, 238, 238);" | Gruppierung
! scope="col" style="background-color: rgb(238, 238, 238); width: 326px;" | Interessenvertretung
|-
| Öffentliche Hand
| style="width: 326px;" | BASt, Experten der Länder und Kommunen 
|-
| Consultants
| style="width: 326px;" | IVS-Berater, IVS-Architekten
|-
| Hersteller
| style="width: 326px;" | Hersteller von RIAD-konformen Produkten
|-
| Standardisierungsorganisationen
| style="width: 326px;" | DIN, CEN/ISO, ETSI etc.
|-
| Verbände
| style="width: 326px;" | ITS Deutschland, TelematicsPRO etc.
|-
| Sonstige
| style="width: 326px;" | ...
|}

Die in der Tabelle genannten Interessenvertretungen könnten im Wesentlichen die Stakeholder des Weiterentwicklungs- und Pflegeprozesses darstellen. Gemeinsam würden Sie die Interessengruppe für den Weiterentwicklungs- und Pflegeprozess bilden.

=== Organe des Weiterentwicklungs- und Pflegeprozesses und ihre Funktion ===

Es gibt zwei primär beteiligte Organe im Weiterentwicklungs- und Pflegeprozess, die zusammen eine Arbeitsgemeinschaft bilden. Jedes Organ hat eine andere Rolle zu erfüllen, wie im Folgenden aufgeführt wird:

'''Das Lenkungskomittee'''

Das Lenkungskomitee (LK) erstellt und steuert das Arbeitsprogramm. Dabei sind die Festlegung des Arbeitsprogramms und die Zuteilung entsprechender personeller oder finanzieller Ressourcen iterativ und zyklisch (z.B. jährlich) ablaufende (Verhandlungs-)Prozesse. Die Sitzungen des LK finden in regelmäßigen, z.B. halbjährlichen Abständen statt. Es bemüht sich zudem um eine Zusammenarbeit mit anderen relevanten Interessengruppen und leistet Öffentlichkeitsarbeit, wie z.B. die Organisation von Workshops oder Symposien. Die allgemeinen technischen Aufgaben werden vom LK auf den assoziierten Arbeitsausschuss übertragen.

Das LK besteht aus Vertretern der vorrangigen Interessengruppen zu gleichen Teilen, ergänzt um sonstige Interessenten. Die Mitglieder werden aus den jeweiligen Interessenvertretungen heraus gewählt bzw. mandatiert und besitzen pro Teilnehmer im LK eine Stimme im Rahmen der Entscheidungsfindung. Existieren auf einer Seite mehrere Interessenvertretungen sind die Stimmen anteilig aufzuteilen. Die Mitarbeit sonstiger Interessenten im LK geschieht auf freiwilliger Basis und hat beratenden bzw. unterstützenden Charakter. Im Gegensatz zu Vertretern der vorrangigen Interessengruppen besitzen die sonstigen Interessenten kein Stimmrecht.

Im jährlichen Rhythmus liefert das LK einen Bericht über seine bisherigen Arbeiten im Rahmen des Weiterentwicklungs- und Pflegeprozesses an die vertretenen Interessengruppen. Generell kann das LK bei seinen Aufgaben durch ein Sekretariat unterstützt werden. In diesem Fall ist die Finanzierung zu klären. Es sollte aber auch geprüft werden, ob ein Mitglied des LK die Sekretariatsfunktion ehrenamtlich übernehmen kann.

'''Der Arbeitsausschuss'''

Der Arbeitsausschuss (AAS) erhält sein Mandat vom LK und berichtet im Gegenzug z.B. jährlich über die Fortschritte seiner Arbeiten. Daher sollte der Leiter des AAS an den Sitzungen des LK teilnehmen. Der AAS besteht aus technischen Experten, die von den Interessensvertretungen entsendet werden. Ggf. können zur temporären Unterstützung auch externe technische Experten zur Mitarbeit im AAS berufen werden. Die Finanzierung der Experten ist im Einzelfall zu klären. Aufgabe des AAS ist es, sich mit dem Management und der Weiterentwicklung des zu pflegenden Rahmenwerks für IVS-Architekturen zu beschäftigen. Dies schließt den Anwender-Support, das Bearbeiten von Benutzer-Feedbacks (Fehlermeldungen, Change-Requests usw.) über das RIAD-Portal und die Verwaltung desselben ein.

Zu diesem Zweck ist der Einsatz eines Issue-Trackers unerlässlich, in dem das Benutzer-Feedback und die Aufgaben dokumentiert und einzelnen Bearbeitern des AAS zugeordnet werden. Der für Benutzer transparente Umgang mit dem Feedback wurde mit Hilfe der Business Process Modelling Notation (BPMN 2.0 (26)) modelliert. Die dort abgebildeten Prozesse orientieren sich an der ISO 14817 (15). Zusätzlich zu den oben genannten Aufgaben führt der AAS alle erforderlichen technischen Arbeiten zur Unterstützung der laufenden Arbeiten aus. Begünstigt durch verteiltes Arbeiten auf einem gemeinsamen Datenbestand, ein definiertes Konfigurationsmanagement und Kommunikation über einen Emailverteiler, können die Sitzungen des AAS nach Bedarf stattfinden und auf ein Minimum reduziert werden. Natürlich muss eine Einigung darüber erzielt werden, wie das Hosting der Internetseite finanziert wird.

=== Entscheidungsfindung ===

Das Entscheidungsorgan im Weiterentwicklungs- und Pflegeprozess ist das Lenkungskomitee (LK). Es orientiert sich bei der Entscheidungsfindung prinzipiell am Leitbild des Weiterentwicklungs- und Pflegeprozesses. Um Entscheidungen über aufgeworfene Fragen im LK zu erreichen wird eine Abstimmung durchgeführt. Bei jedem Abstimmungs-Gegenstand hat jeder teilnehmende Interessensvertreter eine Stimme. Die Stimmen fehlender Interessenvertreter und Stimmenthaltungen haben keinen Einfluss auf den Ausgang der Abstimmung über ein Thema, es sei denn die Position der abwesenden Interessengruppe wurde dem LK zuvor mitgeteilt.

Ein abwesender Interessensvertreter kann dem LK seine Position vor der Abstimmung bekannt geben. Sie muss dem Vorsitzenden des LK in schriftlicher Form vorliegen. Der Vorsitzende des LK hat dafür zu sorgen, dass diese Position in der Abstimmung Berücksichtigung findet. Abstimmungen können auf zwei Arten geschehen:

*während eines Treffens des LK
*per E-Mail über den LK Email-Verteiler

Die Vorschläge sollten in einer Weise formuliert werden, dass folgende Wahloptionen möglich sind:

*Zustimmung,
*Ablehnung,
*Enthaltung.

Abwesende und Stimmenthaltungen werden nicht berücksichtigt und haben somit keinen Einfluss auf das Ergebnis der Abstimmung. Zur Erreichung der Beschlussfähigkeit für eine gültige Entscheidung des LK müssten jedoch mindestens 50% der verfügbaren Stimmen entweder als Zustimmung oder als Ablehnung abgegeben werden (d.h. die Mehrheit der LK Teilnehmer muss sich für eine bestätigte Position ausgesprochen haben). Ist eine Abstimmung unentschieden, wird eine erneute Abstimmung durchgeführt. Wenn diese zweite Abstimmung ebenfalls unentschieden ausfällt, gilt der Vorschlag als abgelehnt. Haben Erweiterungen des Rahmenwerks für IVS-Architekturen oder Problemlösungen des AAS zur Berücksichtigung von Änderungswünschen oder Behebung gemeldeter Fehler Auswirkungen auf die Abwärtskompatibilität zu einer vorherigen Version, beträgt die erforderliche Mehrheit im LK 75%. Wenn die erforderliche Mehrheit bezüglich einer Erweiterung/Änderung des Rahmenwerks für IVS-Architekturen erzielt ist, wird der AAS die Information über die angenommenen Änderungen auf der Website einstellen.

== Finanzierung des Weiterentwicklungs- und Pflegeprozesses ==

Letztendlich stellt sich nun die Frage, wer die oben dargestellten Aufgaben übernehmen soll/kann und wie dies finanziert werden kann. Würde niemand die Pflege des Rahmenwerks für IVS-Architekturen übernehmen, würde sie verkümmern. Selbst wenn eine Finanzierung des Prozesses möglich wäre und auch eine ausreichende IVS-Architektur Kompetenz sichergestellt werden könnte, hätten die Anwender keine Sicherheit, ob IVS-Architekturen (evtl. durch fehlende Akzeptanz) in Richtlinien und Produkten umgesetzt wird.

Es muss also geklärt werden, wer sich an den Kosten dieses Standardisierungsprozesses beteiligt bzw. Ressourcen für die Pflege des Standards bereitstellt, einhergehend mit der Frage nach den eigentlichen Nutznießern. Einerseits sind es die Städte und Kommunen, Bund und Länder, die als Anwender von diesem Prozess profitieren. Aber auch Hersteller haben ein Interesse daran, die Entwicklung voranzutreiben und den Nutzen, sich mit Vorsprung am Markt behaupten zu können.

Es wird empfohlen, dass der Weiterentwicklungs- und Pflegeprozess von den Interessengruppen gemeinsam betrieben wird. Die Finanzierung kann so auf mehrere Schultern verteilt werden z.B. durch Bereitstellung von freiwilligen Herstellerressourcen und eine finanzielle Unterstützung durch Anwender (z.B. über Projekte bzw. Erwerb der Produkte). Die Kosten des Prozesses können durch eine politische Förderung und eine Öffnung des Prozesses durch Beteiligung von sonstigen Interessenten (z. B. universitäre und außeruniversitäre Einrichtungen) zusätzlich vermindert werden.

Die Zusammenführung von IVS-Architektur Kompetenz der Entwickler und Praxiswissen der Anwender bringt für beide Seiten wesentlichen und in dieser Domäne bisher selten erreichten Nutzen; mündet sie auf der einen Seite in Realisierungssicherheit, auf der anderen Seite in Vertrauen und Anwenderakzeptanz gegenüber dem Standardisierungsobjekt. Ist letzteres erreicht wird die Motivation und die Bereitschaft einer direkten Rückkopplung im Weiterentwicklungs- und Pflegeprozess (Feedback) durch die Anwender maximiert.

Im Vergleich mit der Pflege von DATEX II (internationaler Prozess), der mit einem Aufwand von etwa 100 Personen-Wochen pro Jahr (entspricht ca. 300-400 T€) betrieben wird, kann man beim Prozess zur Weiterentwicklung und Pflege des Rahmenwerks für IVS-Architekturen (nationaler Prozess) von einem Viertel dieser Kosten (75-100 T€) pro Jahr ausgehen.

== Fazit ==

Im Folgenden werden noch einmal die wichtigsten Aspekte der Handlungsempfehlung zusammengefasst:

Jeder lebendige Standard, so auch das Rahmenwerk für IVS-Architekturen, braucht einen lebendigen Pflegeprozess. Da dieser Prozess nicht von den Standardisierungsinstitutionen CEN, DIN oder DKE betrieben wird, muss er von den Stakeholdern, wie Anwender der öffentlichen Hand, Herstellern und sonstige Interessenten, betrieben werden, die damit einen Nutzen verbinden. Dabei kann der Prozess nur für alle zufriedenstellende Ergebnisse liefern, wenn auch alle Stakeholder aktiv teilnehmen.

Die Akzeptanz des Rahmenwerks für IVS-Architekturen wird gesteigert, wenn der Pflegeprozess für alle Stakeholder offen und transparent ist. Zudem braucht der Prozess paritätische Verhältnisse, um alle Interessen auszugleichen. Dies bedeutet zum einen ein gleichmäßiges Verhältnis von Stimmen im entscheidenden Gremium (hier Lenkungskomitee). Zum anderen müssen die Kosten für den Prozess von den Stakeholdern getragen werden, die auch einen Nutzen haben – dabei muss der Nutzen die Kosten natürlich substantiell übertreffen.

Für die Finanzierung des Prozesses gibt es dabei viele Möglichkeiten, die zu prüfen sind:

*Bereitstellung von personellen Ressourcen
*Finanzierung über den Verkauf von Produkten
*Finanzierung über (geförderte) Projekte
*Finanzielle Unterstützung durch die Politik

Insbesondere der letzte Aspekt ist von großer Bedeutung. Wenn die im Weiterentwicklungs- und Pflegeprozess gepflegten Standards einen übergeordneten Nutzen haben, sind auch die Träger übergeordneter Interessen potentielle (finanzielle) Unterstützer – speziell das BMVBS und DG MOVE (IVS-Architektur Deutschland, Implementierung der EU IVS Richtlinie, Umsetzung des Urban Mobility Action Plan). Generell scheint die Etablierung und Finanzierung des Weiterentwicklungs- und Pflegeprozesses zunächst schwierig zu sein, ist aber bei Prüfung aller Variablen durchführbar.

Weiterentwicklung & Pflege der IVS-Architekturen 1.0

2018-05-11T08:00:45Z

Scholtes:

== Aufgabenstellung ==

Die Entwicklung einer ersten Version der in diesem Projekt definierten Architekturen (Rahmenwerk für IVS-Architekturen und die in den Losen 2-4 ausgeschriebenen drei IVS-Referenzarchitekturen) ist ein wichtiger Schritt hin zu plan- und steuerbaren IVS-Diensten, die zur Verbesserung der Umweltverträglichkeit, zur Steigerung der Effizienz und zur Erhöhung der Sicherheit im Straßenverkehr beitragen können.

Aufgrund sich ständig ändernder Rahmenbedingungen (z.B. Hinzukommen neuer Stakeholder und Anwendungsfelder, Entwicklung neuer Technologien, Änderung der gesetzlichen Anforderungen) ist es notwendig, das Rahmenwerk für IVS-Architekturen in regelmäßigen Abständen auf ihre Aktualität und Gültigkeit zu überprüfen und gegebenenfalls anzupassen. Auch TOGAF sieht z.B. eine ständige Kontrolle und Weiterentwicklung vor. Wichtig ist dazu eine Institutionalisierung dieser Aufgaben der Aktualisierung, Anpassung und Pflege deren Organisation und Finanzierung. Insofern beinhaltet das Konzept für die Weiterentwicklung und Pflege des Rahmenwerks für IVS-Architekturen folgenden Aufgaben:

*Um Wirkung und Nutzen des Rahmenwerks für IVS-Architekturen auf Dauer erhalten und vorantreiben zu können, muss ein Konzept für den Prozess der Einführung, Weiterentwicklung und Pflege des Rahmenwerks für IVS-Architekturen (Weiterentwicklungs- und Pflegeprozess) entwickelt werden. Dabei sollte neben der Weiterentwicklung des in diesem Projekt definierten Rahmenwerks für IVS-Architekturen und IVS-Referenzarchitekturen auch die Identifikation und Entwicklung weiterer IVS Referenzarchitekturen berücksichtigt werden.

*Für die Einführung und Umsetzung des Weiterentwicklungs- und Pflegeprozesses muss ein Organisations- und Finanzierungskonzept erarbeitet werden. Wichtig ist insbesondere dabei, die Zuständigkeiten für die Weiterentwicklung und Pflege festzulegen. Dabei ist eine Verankerung im IVS-Gesetz sicherlich sinnvoll.

== Weiterentwicklung und Pflege des Rahmenwerks für IVS-Architekturen ==

=== Problemstellung ===

Das nationale Rahmenwerk für IVS-Architekturen für Deutschland (kurz: RIAD) ist konzeptionell ein an neue Anforderungen der Anwenderseite anpassbares Meta-Modell für die Entwicklung von IVS-Referenzarchitekturen und IVS-Architekturen realer IVS-Dienste.

Um Planungs- und Rechtssicherheit in der Anwendung und Handhabung des TOGAF-basierten Vorgehensmodells zur Entwicklung von IVS-Architekturen und der auf den fünf Ebenen der IVS-Pyramide angesiedelten, primär die Zusammenarbeit von IVS-Akteuren adressierenden Kernaspekte von IVS-Architektur zu erhalten, muss dem Rahmenwerk für IVS-Architekturen quasi der Stellenwert eines Standards beigemessen werden.

Dem Wesen eines Standards entsprechend, muss die Festlegung dessen, was das Rahmenwerk für IVS-Architekturen ist und wie es angepasst oder erweitert wird, auf einer übergeordneten, neutralen Ebene geregelt werden.

Das Rahmenwerk für IVS-Architekturen muss deshalb Betrachtungs- und Handlungsgegenstand eines offenen und transparenten Prozesses sein, der einen unmittelbaren Bezug zu Einrichtungen besitzt, welche die Kompetenz einer Standardisierungseinrichtung besitzen sollen. Der Anspruch, das Rahmenwerk als offenen Standard verfügbar zu machen, stellt an die an diesem Prozess beteiligten Personen bestimmte Anforderungen im Hinblick auf Kompetenz und Unabhängigkeit. Es muss mit dem Rahmenwerk für IVS-Architekturen eine Interessenslage geweckt werden, die Personen dazu motiviert, sich am Prozess zum Zwecke der Pflege und Fortschreibung des Standards nebst der Festlegung der erforderlichen Konformitäts-Rahmenbedingungen zu beteiligen.

Einrichtungen und Unternehmen, die solche Personen beschäftigen, müssen Mittel bereitstellen wollen, damit sich Mitarbeiter auch wirklich an diesem Prozess beteiligen können. Damit das Rahmenwerk für IVS-Architekturen ein offener Standard bleibt, werden Mechanismen benötigt, die dies sicherstellen.

Eine gewisse Anlehnung an die Verfahren anderer Standardisierungseinrichtungen scheint hier angebracht. Ziel muss es sein, eine Organisationsgrundstruktur, das Qualitätsmanagement und die Anbindung an die Standardisierung zu entwickeln. Auf Grundlage dieses Modells soll der Weiterentwicklungs- und Pflegeprozess nach Möglichkeit unter Beteiligung aller in die Entwicklung und den Betrieb von IVS und IVS-Diensten involvierten und aller sonstigen Stakeholder im Bereich IVS (Bund, Länder, Industrie, Beratungsunternehmen, …) institutionalisiert und instanziiert werden.

=== Der Prozess zur Weiterentwicklung und Pflege des Rahmenwerks für IVS-Architekturen ===

Standards müssen in einem lebendigen Prozess gepflegt und weiterentwickelt werden, sonst drohen sie zu verkümmern. So ist der aktuelle Stand der IVS-Rahmenarchitektur lediglich eine Momentaufnahme im Gesamtprozess, die durch folgende Abbildung visualisiert wird:

[[File:IVS-RA-Prozess.jpg|500px|Organisation des IVS-Rahmenarchitektur Prozesses]]

Das Prozessmodell stellt sich als ein Kreislauf dar, der sich grundsätzlich für jede Version des Rahmenwerks in vier Phasen unterteilen lässt. Nach der Freigabe einer Version des Rahmenwerks für IVS-Architekturen, die aus Nutzersicht einer Bereitstellung der Version entspricht, erfolgt die Anwendung durch die Nutzer. Diese wird durch den Anwendersupport unterstützt. Feedback der Nutzer wird als Rückkopplung in das Rahmenwerk aufgenommen. Diese Rückmeldungen zu den aktuellen Versionen der IVS-Rahmenarchitektur sind von großer Bedeutung zur Weiterentwicklung bzw. zur Fehlerbehebung und wirken häufig als Initialzündung für die weitere Pflege des Rahmenwerks für IVS-Architekturen. Die in der Folge von IVS-Architekten entwickelten Versionen des Rahmenwerks für IVS-Architekturen werden in einer neuen (Unter-)Version dem Markt zur Verfügung gestellt.

Durch die Dokumentation des Weiterentwicklungs- und Pflegeprozesses (Ereignisverfolgung/Issue-Tracking) sowie ggfs. die Veröffentlichung von Ergebnissen von begleitenden Forschungsprojekten werden die Nutzer stets über den aktuellen Stand informiert und damit aktiv bei der Umsetzung unterstützt. Eine formelle Freigabe von Ergebnissen des Prozesses gibt den Anwendern zusätzlich Planungssicherheit. Mit diesen Maßnahmen soll die Akzeptanz des Rahmenwerks für IVS-Architekturen bei den Nutzern gefördert und damit die Voraussetzung für ihre Durchsetzung am Markt geschaffen werden.

Ohne ein gewisses Maß an Marktakzeptanz kann der Weiterentwicklungs- und Pflegeprozess nicht überleben. Durch die Anwendung ergeben sich beim Anwender weitere Bedürfnisse bzw. werden Lücken und Mängel der aktuellen Version des Rahmenwerks für IVS-Architekturen erkennbar, was wiederum durch ein entsprechendes Feedback in den Weiterentwicklungs- und Pflegeprozess eingebracht wird und damit die Weiterentwicklung des Rahmenwerks vorantreibt.

Hieraus ergeben sich grundsätzlich folgende Fragen bzgl. des Standardisierungsprozesses:

*Wie passt sich das Rahmenwerk für IVS-Architekturen an neue Anforderungen an?
*Wie reagiert das Rahmenwerk für IVS-Architekturen auf die Entdeckung von Fehlern?

=== Aufgaben des Weiterentwicklungs- und Pflegeprozesses ===

Die grundsätzlichen Aufgaben des Weiterentwicklungs- und Pflegeprozesses unterteilen sich in die Bereiche

*Pflege des Rahmenwerks für IVS-Architekturen,
*Anwenderunterstützung Öffentlichkeitsarbeit sowie *Selbstverwaltung des Prozesses.

Die Arbeiten zur Pflege des Rahmenwerks für IVS-Architekturen erfordern IVS-Architektur-Kompetenz und können u. U. nur von Experten (BASt, (außer)universitäre Einrichtungen, beratende Unternehmen, Hersteller und Betrieber von IVS-Diensten) übernommen werden. Sie umfassen im Wesentlichen folgende Teilbereiche:

*Pflege und Erweiterung der Basiskonzepte
*Pflege und Erweiterung der IVS-Architekturbausteine
*Pflege und Erweiterung des TOGAF-basierten Vorgehensmodells
*evtl. weitere...

Für die Pflege des Rahmenwerks für IVS-Architekturen müssen transparente und offene Prozedere definiert werden. Diese umfassen beispielsweise die Behebung identifizierter Fehler sowie die Weiterentwicklung des Rahmenwerks auf Basis eingereichter Erweiterungsanträge, die ggf. in Abhängigkeit des Schweregrades bzw. nach einer definierten Prioritätenliste von Experten (IVS-Architektur-Spezialisten) zeitnah behandelt werden.

Die Ergebnisse des Pflegeprozesses werden in das Rahmenwerk für IVS-Architekturen eingearbeitet und im IVS-Wiki veröffentlicht. Neben den vorherigen Aspekten, die mit der Pflege des Rahmenwerks für IVS-Architekturen zu assoziieren sind, haben die nachstehenden Aufgaben einen unterstützenden Charakter und sollten vom Aufwand her nicht unterschätzt werden.

'''Anwendersupport'''

Vor allem sei hier der Anwendersupport genannt. Er gliedert sich in eine Reihe von unterschiedlichen Leistungen, wie z.B. die Bereitstellung des Rahmenwerks für IVS-Architekturen und von weiterführenden, unterstützenden Dokumentationen (z.B. IVS-Referenzarchitekturen). Letztere können sich aus Tutorials, Guidelines, Webinars, etc. zusammensetzen.

Für eine Kollaboration von Entwicklern des Rahmenwerks für IVS-Architekturen und Firmen, die ihre Produktpalette konform zum Rahmenwerk für IVS-Architekturen entwickeln und in ihren Systemlandschaften einsetzen, können als Werkzeuge oder Kommunikationsplattformen internetbasierte Foren etc. eingerichtet und betrieben werden. Beide Werkzeuge/Plattformen benötigen eine aktive Moderation, wenn sie im Rahmen einer problemorientierten Unterstützung als Helpdesk eingerichtet werden sollen.

'''Das RIAD Portal'''

Es soll ein zentrales RIAD Portal aufgebaut werden, über das alle Informationen rund um das Rahmenwerk für IVS-Architekturen zugänglich sind. Es ist aber nicht nur ein Informationszentrum, sondern auch ein Werkzeug für den Weiterentwicklungs- und Pflegeprozess.

Über das Portal sollen nicht nur viele Informationen (Spezifikationen, Erweiterungen, IVS-Referenzimplementierung, u.v.m.) erhältlich sein. Es ist auch erforderlich, ein Issue-Tracker-Modul zu integrieren. Dieses soll eine Feedback-Möglichkeit für Nutzer des Rahmenwerks für IVS-Architekturen enthalten (Fehlerreports, Change-Requests, usw.).

Die folgende Abbildung zeigt das jetzige IVS-Wiki, das zum RIAD Portal ausgebaut werden soll:

[[File:IVS-Wiki.jpg|500px|Das IVS-Wiki Portal]]

'''Öffentlichkeitsarbeit'''

Zu den beschriebenen Aufgaben der Pflege des Rahmenwerks für IVS-Architekturen bedarf es zudem einer regen Öffentlichkeitsarbeit, um einerseits die Ergebnisse der Archtekturarbeit zeitnah einem breiten Nutzerkreis zur Verfügung stellen zu können, und andererseits einen geeigneten „Kanal“ für die Rückkopplung bereit zu halten. Nur über eine nachhaltig gewährleistete Kommunikation kann der Prozess wirklich lebendig gehalten werden. Diesbezüglich werden die Unterhaltung des Internetauftritts inkl. Newsletter, die Durchführung von Nutzerforen, Workshops usw. sowie die Repräsentation auf geeigneten (externen) Veranstaltungen (z.B. auf Messen und Kongressen) wichtige Aufgabenfelder darstellen.

Im Projekt Rahmenwerk für IVS-Architekturen für Deutschland wurde z.B. recht früh mit der Öffentlichkeitsarbeit begonnen, um die interessierten Kreise so früh, wie möglich, einzubeziehen. Zu den insgesamt zwei Veranstaltungen wurde ein breites Fachpublikum eingeladen. Auf den Veranstaltungen wurden die geleisteten inhaltlichen Arbeiten bzw. Ergebnisse im Projekt vorgestellt und das Feedback des Fachpublikums zurück in das Projekt eingespeist. Über die Veranstaltungen wurde erreicht, das Interesse am Projekt und seinen Ergebnissen zu wecken und das Fachpublikum an der Verfolgung des Entwicklungsprozesses zu binden.

'''Sekretariat'''

Letztendlich sollten auch Ressourcen für die Verwaltung des Weiterentwicklungs- und Pflegeprozesses eingeplant werden, die die Koordinierung der Prozessabläufe, verwaltungstechnische Unterstützung der Gremien des Weiterentwicklungs- und Pflegeprozesses, ggf. Verwaltung von Finanzen usw. umfasst. Für diese Aufgaben könnte ein Sekretariat eingerichtet werden. Gemessen an den Aufgaben scheint eine Realisierung des Weiterentwicklungs- und Pflegeprozesses recht komplex und aufwendig zu sein. Es ist jedoch zu bedenken, dass, je transparenter und offener der Pflegeprozess und breiter der Support (auch mit wenigen Mitteln) aufgestellt werden kann, die Chancen für eine breitere Akzeptanz bei Entwicklern und Anwendern des Rahmenwerks für IVS-Architekturen steigen.

== Organisation des Weiterentwicklungs- und Pflegeprozesses ==

=== Überblick ===

Um den Weiterentwicklungs- und Pflegeprozess für Hersteller und Anwender offen und transparent zu gestalten, bedarf es einer für alle Beteiligten klaren Organisation mit definierten Regeln. Die Organisation des Weiterentwicklungs- und Pflegeprozesses orientiert sich dabei an bereits bestehenden erfolgreichen Organisationen. Die nachstehende Grafik gibt einen Überblick über die Ausgestaltung der Organisation. Sie wird im Folgenden weiter erläutert.

[[File:IVS-RA-Prozess Organisation.jpg|500px|Organisation des IVS-Rahmenarchitektur Prozesses]]

=== Stakeholder ===

Wie zuvor beschrieben, wird empfohlen, dass der Weiterentwicklungs- und Pflegeprozess von Anwendern und Herstellern gemeinsam betrieben wird. Ergänzt werden diese Gruppierungen mit der Beteiligung von sonstigen Interessenten, wie z.B. beratende Unternehmen oder (außer-)universitäre Einrichtungen. Anwender und Hersteller, aber auch Sonstige, können in Interessensvertretungen organisiert sein. Welche Interessenvertretungen mit den jeweiligen Gruppierungen z.B. assoziiert sein können, zeigt die folgende Tabelle:

{| border="1" cellpadding="1" cellspacing="1" style="width: 528px;"
|-
! scope="col" style="background-color: rgb(238, 238, 238);" | Gruppierung
! scope="col" style="background-color: rgb(238, 238, 238); width: 326px;" | Interessenvertretung
|-
| Öffentliche Hand
| style="width: 326px;" | BASt, Experten der Länder und Kommunen 
|-
| Consultants
| style="width: 326px;" | IVS-Berater, IVS-Architekten
|-
| Hersteller
| style="width: 326px;" | Hersteller von RIAD-konformen Produkten
|-
| Standardisierungsorganisationen
| style="width: 326px;" | DIN, CEN/ISO, ETSI etc.
|-
| Verbände
| style="width: 326px;" | ITS Deutschland, TelematicsPRO etc.
|-
| Sonstige
| style="width: 326px;" | ...
|}

Die in der Tabelle genannten Interessenvertretungen könnten im Wesentlichen die Stakeholder des Weiterentwicklungs- und Pflegeprozesses darstellen. Gemeinsam würden Sie die Interessengruppe für den Weiterentwicklungs- und Pflegeprozess bilden.

=== Organe des Weiterentwicklungs- und Pflegeprozesses und ihre Funktion ===

Es gibt zwei primär beteiligte Organe im Weiterentwicklungs- und Pflegeprozess, die zusammen eine Arbeitsgemeinschaft bilden. Jedes Organ hat eine andere Rolle zu erfüllen, wie im Folgenden aufgeführt wird:

'''Das Lenkungskomittee'''

Das Lenkungskomitee (LK) erstellt und steuert das Arbeitsprogramm. Dabei sind die Festlegung des Arbeitsprogramms und die Zuteilung entsprechender personeller oder finanzieller Ressourcen iterativ und zyklisch (z.B. jährlich) ablaufende (Verhandlungs-)Prozesse. Die Sitzungen des LK finden in regelmäßigen, z.B. halbjährlichen Abständen statt. Es bemüht sich zudem um eine Zusammenarbeit mit anderen relevanten Interessengruppen und leistet Öffentlichkeitsarbeit, wie z.B. die Organisation von Workshops oder Symposien. Die allgemeinen technischen Aufgaben werden vom LK auf den assoziierten Arbeitsausschuss übertragen.

Das LK besteht aus Vertretern der vorrangigen Interessengruppen zu gleichen Teilen, ergänzt um sonstige Interessenten. Die Mitglieder werden aus den jeweiligen Interessenvertretungen heraus gewählt bzw. mandatiert und besitzen pro Teilnehmer im LK eine Stimme im Rahmen der Entscheidungsfindung. Existieren auf einer Seite mehrere Interessenvertretungen sind die Stimmen anteilig aufzuteilen. Die Mitarbeit sonstiger Interessenten im LK geschieht auf freiwilliger Basis und hat beratenden bzw. unterstützenden Charakter. Im Gegensatz zu Vertretern der vorrangigen Interessengruppen besitzen die sonstigen Interessenten kein Stimmrecht.

Im jährlichen Rhythmus liefert das LK einen Bericht über seine bisherigen Arbeiten im Rahmen des Weiterentwicklungs- und Pflegeprozesses an die vertretenen Interessengruppen. Generell kann das LK bei seinen Aufgaben durch ein Sekretariat unterstützt werden. In diesem Fall ist die Finanzierung zu klären. Es sollte aber auch geprüft werden, ob ein Mitglied des LK die Sekretariatsfunktion ehrenamtlich übernehmen kann.

'''Der Arbeitsausschuss'''

Der Arbeitsausschuss (AAS) erhält sein Mandat vom LK und berichtet im Gegenzug z.B. jährlich über die Fortschritte seiner Arbeiten. Daher sollte der Leiter des AAS an den Sitzungen des LK teilnehmen. Der AAS besteht aus technischen Experten, die von den Interessensvertretungen entsendet werden. Ggf. können zur temporären Unterstützung auch externe technische Experten zur Mitarbeit im AAS berufen werden. Die Finanzierung der Experten ist im Einzelfall zu klären. Aufgabe des AAS ist es, sich mit dem Management und der Weiterentwicklung des zu pflegenden Rahmenwerks für IVS-Architekturen zu beschäftigen. Dies schließt den Anwender-Support, das Bearbeiten von Benutzer-Feedbacks (Fehlermeldungen, Change-Requests usw.) über das RIAD-Portal und die Verwaltung desselben ein.

Zu diesem Zweck ist der Einsatz eines Issue-Trackers unerlässlich, in dem das Benutzer-Feedback und die Aufgaben dokumentiert und einzelnen Bearbeitern des AAS zugeordnet werden. Der für Benutzer transparente Umgang mit dem Feedback wurde mit Hilfe der Business Process Modelling Notation (BPMN 2.0 (26)) modelliert. Die dort abgebildeten Prozesse orientieren sich an der ISO 14817 (15). Zusätzlich zu den oben genannten Aufgaben führt der AAS alle erforderlichen technischen Arbeiten zur Unterstützung der laufenden Arbeiten aus. Begünstigt durch verteiltes Arbeiten auf einem gemeinsamen Datenbestand, ein definiertes Konfigurationsmanagement und Kommunikation über einen Emailverteiler, können die Sitzungen des AAS nach Bedarf stattfinden und auf ein Minimum reduziert werden. Natürlich muss eine Einigung darüber erzielt werden, wie das Hosting der Internetseite finanziert wird.

=== Entscheidungsfindung ===

Das Entscheidungsorgan im Weiterentwicklungs- und Pflegeprozess ist das Lenkungskomitee (LK). Es orientiert sich bei der Entscheidungsfindung prinzipiell am Leitbild des Weiterentwicklungs- und Pflegeprozesses. Um Entscheidungen über aufgeworfene Fragen im LK zu erreichen wird eine Abstimmung durchgeführt. Bei jedem Abstimmungs-Gegenstand hat jeder teilnehmende Interessensvertreter eine Stimme. Die Stimmen fehlender Interessenvertreter und Stimmenthaltungen haben keinen Einfluss auf den Ausgang der Abstimmung über ein Thema, es sei denn die Position der abwesenden Interessengruppe wurde dem LK zuvor mitgeteilt.

Ein abwesender Interessensvertreter kann dem LK seine Position vor der Abstimmung bekannt geben. Sie muss dem Vorsitzenden des LK in schriftlicher Form vorliegen. Der Vorsitzende des LK hat dafür zu sorgen, dass diese Position in der Abstimmung Berücksichtigung findet. Abstimmungen können auf zwei Arten geschehen:

*während eines Treffens des LK
*per E-Mail über den LK Email-Verteiler

Die Vorschläge sollten in einer Weise formuliert werden, dass folgende Wahloptionen möglich sind:

*Zustimmung,
*Ablehnung,
*Enthaltung.

Abwesende und Stimmenthaltungen werden nicht berücksichtigt und haben somit keinen Einfluss auf das Ergebnis der Abstimmung. Zur Erreichung der Beschlussfähigkeit für eine gültige Entscheidung des LK müssten jedoch mindestens 50% der verfügbaren Stimmen entweder als Zustimmung oder als Ablehnung abgegeben werden (d.h. die Mehrheit der LK Teilnehmer muss sich für eine bestätigte Position ausgesprochen haben). Ist eine Abstimmung unentschieden, wird eine erneute Abstimmung durchgeführt. Wenn diese zweite Abstimmung ebenfalls unentschieden ausfällt, gilt der Vorschlag als abgelehnt. Haben Erweiterungen des Rahmenwerks für IVS-Architekturen oder Problemlösungen des AAS zur Berücksichtigung von Änderungswünschen oder Behebung gemeldeter Fehler Auswirkungen auf die Abwärtskompatibilität zu einer vorherigen Version, beträgt die erforderliche Mehrheit im LK 75%. Wenn die erforderliche Mehrheit bezüglich einer Erweiterung/Änderung des Rahmenwerks für IVS-Architekturen erzielt ist, wird der AAS die Information über die angenommenen Änderungen auf der Website einstellen.

== Finanzierung des Weiterentwicklungs- und Pflegeprozesses ==

Letztendlich stellt sich nun die Frage, wer die oben dargestellten Aufgaben übernehmen soll/kann und wie dies finanziert werden kann. Würde niemand die Pflege des Rahmenwerks für IVS-Architekturen übernehmen, würde sie verkümmern. Selbst wenn eine Finanzierung des Prozesses möglich wäre und auch eine ausreichende IVS-Architektur Kompetenz sichergestellt werden könnte, hätten die Anwender keine Sicherheit, ob IVS-Architekturen (evtl. durch fehlende Akzeptanz) in Richtlinien und Produkten umgesetzt wird.

Es muss also geklärt werden, wer sich an den Kosten dieses Standardisierungsprozesses beteiligt bzw. Ressourcen für die Pflege des Standards bereitstellt, einhergehend mit der Frage nach den eigentlichen Nutznießern. Einerseits sind es die Städte und Kommunen, Bund und Länder, die als Anwender von diesem Prozess profitieren. Aber auch Hersteller haben ein Interesse daran, die Entwicklung voranzutreiben und den Nutzen, sich mit Vorsprung am Markt behaupten zu können.

Es wird empfohlen, dass der Weiterentwicklungs- und Pflegeprozess von den Interessengruppen gemeinsam betrieben wird. Die Finanzierung kann so auf mehrere Schultern verteilt werden z.B. durch Bereitstellung von freiwilligen Herstellerressourcen und eine finanzielle Unterstützung durch Anwender (z.B. über Projekte bzw. Erwerb der Produkte). Die Kosten des Prozesses können durch eine politische Förderung und eine Öffnung des Prozesses durch Beteiligung von sonstigen Interessenten (z. B. universitäre und außeruniversitäre Einrichtungen) zusätzlich vermindert werden.

Die Zusammenführung von IVS-Architektur Kompetenz der Entwickler und Praxiswissen der Anwender bringt für beide Seiten wesentlichen und in dieser Domäne bisher selten erreichten Nutzen; mündet sie auf der einen Seite in Realisierungssicherheit, auf der anderen Seite in Vertrauen und Anwenderakzeptanz gegenüber dem Standardisierungsobjekt. Ist letzteres erreicht wird die Motivation und die Bereitschaft einer direkten Rückkopplung im Weiterentwicklungs- und Pflegeprozess (Feedback) durch die Anwender maximiert.

Im Vergleich mit der Pflege von DATEX II (internationaler Prozess), der mit einem Aufwand von etwa 100 Personen-Wochen pro Jahr (entspricht ca. 300-400 T€) betrieben wird, kann man beim Prozess zur Weiterentwicklung und Pflege des Rahmenwerks für IVS-Architekturen (nationaler Prozess) von einem Viertel dieser Kosten (75-100 T€) pro Jahr ausgehen.

== Fazit ==

Im Folgenden werden noch einmal die wichtigsten Aspekte der Handlungsempfehlung zusammengefasst:

Jeder lebendige Standard, so auch das Rahmenwerk für IVS-Architekturen, braucht einen lebendigen Pflegeprozess. Da dieser Prozess nicht von den Standardisierungsinstitutionen CEN, DIN oder DKE betrieben wird, muss er von den Stakeholdern, wie Anwender der öffentlichen Hand, Herstellern und sonstige Interessenten, betrieben werden, die damit einen Nutzen verbinden. Dabei kann der Prozess nur für alle zufriedenstellende Ergebnisse liefern, wenn auch alle Stakeholder aktiv teilnehmen.

Die Akzeptanz des Rahmenwerks für IVS-Architekturen wird gesteigert, wenn der Pflegeprozess für alle Stakeholder offen und transparent ist. Zudem braucht der Prozess paritätische Verhältnisse, um alle Interessen auszugleichen. Dies bedeutet zum einen ein gleichmäßiges Verhältnis von Stimmen im entscheidenden Gremium (hier Lenkungskomitee). Zum anderen müssen die Kosten für den Prozess von den Stakeholdern getragen werden, die auch einen Nutzen haben – dabei muss der Nutzen die Kosten natürlich substantiell übertreffen.

Für die Finanzierung des Prozesses gibt es dabei viele Möglichkeiten, die zu prüfen sind:

*Bereitstellung von personellen Ressourcen
*Finanzierung über den Verkauf von Produkten
*Finanzierung über (geförderte) Projekte
*Finanzielle Unterstützung durch die Politik

Insbesondere der letzte Aspekt ist von großer Bedeutung. Wenn die im Weiterentwicklungs- und Pflegeprozess gepflegten Standards einen übergeordneten Nutzen haben, sind auch die Träger übergeordneter Interessen potentielle (finanzielle) Unterstützer – speziell das BMVBS und DG MOVE (IVS-Architektur Deutschland, Implementierung der EU IVS Richtlinie, Umsetzung des Urban Mobility Action Plan). Generell scheint die Etablierung und Finanzierung des Weiterentwicklungs- und Pflegeprozesses zunächst schwierig zu sein, ist aber bei Prüfung aller Variablen durchführbar.

Weiterentwicklung & Pflege der IVS-Architekturen 1.0

2018-05-11T08:00:06Z

Scholtes:

== Aufgabenstellung ==

Die Entwicklung einer ersten Version der in diesem Projekt definierten Architekturen (Rahmenwerk für IVS-Architekturen und die in den Losen 2-4 ausgeschriebenen drei IVS-Referenzarchitekturen) ist ein wichtiger Schritt hin zu plan- und steuerbaren IVS-Diensten, die zur Verbesserung der Umweltverträglichkeit, zur Steigerung der Effizienz und zur Erhöhung der Sicherheit im Straßenverkehr beitragen können.

Aufgrund sich ständig ändernder Rahmenbedingungen (z.B. Hinzukommen neuer Stakeholder und Anwendungsfelder, Entwicklung neuer Technologien, Änderung der gesetzlichen Anforderungen) ist es notwendig, das Rahmenwerk für IVS-Architekturen in regelmäßigen Abständen auf ihre Aktualität und Gültigkeit zu überprüfen und gegebenenfalls anzupassen. Auch TOGAF sieht z.B. eine ständige Kontrolle und Weiterentwicklung vor. Wichtig ist dazu eine Institutionalisierung dieser Aufgaben der Aktualisierung, Anpassung und Pflege deren Organisation und Finanzierung. Insofern beinhaltet das Konzept für die Weiterentwicklung und Pflege des Rahmenwerks für IVS-Architekturen folgenden Aufgaben:

*Um Wirkung und Nutzen des Rahmenwerks für IVS-Architekturen auf Dauer erhalten und vorantreiben zu können, muss ein Konzept für den Prozess der Einführung, Weiterentwicklung und Pflege des Rahmenwerks für IVS-Architekturen (Weiterentwicklungs- und Pflegeprozess) entwickelt werden. Dabei sollte neben der Weiterentwicklung des in diesem Projekt definierten Rahmenwerks für IVS-Architekturen und IVS-Referenzarchitekturen auch die Identifikation und Entwicklung weiterer IVS Referenzarchitekturen berücksichtigt werden.

*Für die Einführung und Umsetzung des Weiterentwicklungs- und Pflegeprozesses muss ein Organisations- und Finanzierungskonzept erarbeitet werden. Wichtig ist insbesondere dabei, die Zuständigkeiten für die Weiterentwicklung und Pflege festzulegen. Dabei ist eine Verankerung im IVS-Gesetz sicherlich sinnvoll.

== Weiterentwicklung und Pflege des Rahmenwerks für IVS-Architekturen ==

=== Problemstellung ===

Das nationale Rahmenwerk für IVS-Architekturen für Deutschland (kurz: RIAD) ist konzeptionell ein an neue Anforderungen der Anwenderseite anpassbares Meta-Modell für die Entwicklung von IVS-Referenzarchitekturen und IVS-Architekturen realer IVS-Dienste.

Um Planungs- und Rechtssicherheit in der Anwendung und Handhabung des TOGAF-basierten Vorgehensmodells zur Entwicklung von IVS-Architekturen und der auf den fünf Ebenen der IVS-Pyramide angesiedelten, primär die Zusammenarbeit von IVS-Akteuren adressierenden Kernaspekte von IVS-Architektur zu erhalten, muss dem Rahmenwerk für IVS-Architekturen quasi der Stellenwert eines Standards beigemessen werden.

Dem Wesen eines Standards entsprechend, muss die Festlegung dessen, was das Rahmenwerk für IVS-Architekturen ist und wie es angepasst oder erweitert wird, auf einer übergeordneten, neutralen Ebene geregelt werden.

Das Rahmenwerk für IVS-Architekturen muss deshalb Betrachtungs- und Handlungsgegenstand eines offenen und transparenten Prozesses sein, der einen unmittelbaren Bezug zu Einrichtungen besitzt, welche die Kompetenz einer Standardisierungseinrichtung besitzen sollen. Der Anspruch, das Rahmenwerk als offenen Standard verfügbar zu machen, stellt an die an diesem Prozess beteiligten Personen bestimmte Anforderungen im Hinblick auf Kompetenz und Unabhängigkeit. Es muss mit dem Rahmenwerk für IVS-Architekturen eine Interessenslage geweckt werden, die Personen dazu motiviert, sich am Prozess zum Zwecke der Pflege und Fortschreibung des Standards nebst der Festlegung der erforderlichen Konformitäts-Rahmenbedingungen zu beteiligen.

Einrichtungen und Unternehmen, die solche Personen beschäftigen, müssen Mittel bereitstellen wollen, damit sich Mitarbeiter auch wirklich an diesem Prozess beteiligen können. Damit das Rahmenwerk für IVS-Architekturen ein offener Standard bleibt, werden Mechanismen benötigt, die dies sicherstellen.

Eine gewisse Anlehnung an die Verfahren anderer Standardisierungseinrichtungen scheint hier angebracht. Ziel muss es sein, eine Organisationsgrundstruktur, das Qualitätsmanagement und die Anbindung an die Standardisierung zu entwickeln. Auf Grundlage dieses Modells soll der Weiterentwicklungs- und Pflegeprozess nach Möglichkeit unter Beteiligung aller in die Entwicklung und den Betrieb von IVS und IVS-Diensten involvierten und aller sonstigen Stakeholder im Bereich IVS (Bund, Länder, Industrie, Beratungsunternehmen, …) institutionalisiert und instanziiert werden.

=== Der Prozess zur Weiterentwicklung und Pflege des Rahmenwerks für IVS-Architekturen ===

Standards müssen in einem lebendigen Prozess gepflegt und weiterentwickelt werden, sonst drohen sie zu verkümmern. So ist der aktuelle Stand der IVS-Rahmenarchitektur lediglich eine Momentaufnahme im Gesamtprozess, die durch folgende Abbildung visualisiert wird:

[[File:IVS-RA-Prozess.jpg|500px|Organisation des IVS-Rahmenarchitektur Prozesses]]

Das Prozessmodell stellt sich als ein Kreislauf dar, der sich grundsätzlich für jede Version des Rahmenwerks in vier Phasen unterteilen lässt. Nach der Freigabe einer Version des Rahmenwerks für IVS-Architekturen, die aus Nutzersicht einer Bereitstellung der Version entspricht, erfolgt die Anwendung durch die Nutzer. Diese wird durch den Anwendersupport unterstützt. Feedback der Nutzer wird als Rückkopplung in das Rahmenwerk aufgenommen. Diese Rückmeldungen zu den aktuellen Versionen der IVS-Rahmenarchitektur sind von großer Bedeutung zur Weiterentwicklung bzw. zur Fehlerbehebung und wirken häufig als Initialzündung für die weitere Pflege des Rahmenwerks für IVS-Architekturen. Die in der Folge von IVS-Architekten entwickelten Versionen des Rahmenwerks für IVS-Architekturen werden in einer neuen (Unter-)Version dem Markt zur Verfügung gestellt.

Durch die Dokumentation des Weiterentwicklungs- und Pflegeprozesses (Ereignisverfolgung/Issue-Tracking) sowie ggfs. die Veröffentlichung von Ergebnissen von begleitenden Forschungsprojekten werden die Nutzer stets über den aktuellen Stand informiert und damit aktiv bei der Umsetzung unterstützt. Eine formelle Freigabe von Ergebnissen des Prozesses gibt den Anwendern zusätzlich Planungssicherheit. Mit diesen Maßnahmen soll die Akzeptanz des Rahmenwerks für IVS-Architekturen bei den Nutzern gefördert und damit die Voraussetzung für ihre Durchsetzung am Markt geschaffen werden.

Ohne ein gewisses Maß an Marktakzeptanz kann der Weiterentwicklungs- und Pflegeprozess nicht überleben. Durch die Anwendung ergeben sich beim Anwender weitere Bedürfnisse bzw. werden Lücken und Mängel der aktuellen Version des Rahmenwerks für IVS-Architekturen erkennbar, was wiederum durch ein entsprechendes Feedback in den Weiterentwicklungs- und Pflegeprozess eingebracht wird und damit die Weiterentwicklung des Rahmenwerks vorantreibt.

Hieraus ergeben sich grundsätzlich folgende Fragen bzgl. des Standardisierungsprozesses:

*Wie passt sich das Rahmenwerk für IVS-Architekturen an neue Anforderungen an?
*Wie reagiert das Rahmenwerk für IVS-Architekturen auf die Entdeckung von Fehlern?

=== Aufgaben des Weiterentwicklungs- und Pflegeprozesses ===

Die grundsätzlichen Aufgaben des Weiterentwicklungs- und Pflegeprozesses unterteilen sich in die Bereiche

*Pflege des Rahmenwerks für IVS-Architekturen,
*Anwenderunterstützung Öffentlichkeitsarbeit sowie *Selbstverwaltung des Prozesses.

Die Arbeiten zur Pflege des Rahmenwerks für IVS-Architekturen erfordern IVS-Architektur-Kompetenz und können u. U. nur von Experten (BASt, (außer)universitäre Einrichtungen, beratende Unternehmen, Hersteller und Betrieber von IVS-Diensten) übernommen werden. Sie umfassen im Wesentlichen folgende Teilbereiche:

*Pflege und Erweiterung der Basiskonzepte
*Pflege und Erweiterung der IVS-Architekturbausteine
*Pflege und Erweiterung des TOGAF-basierten Vorgehensmodells
*evtl. weitere...

Für die Pflege des Rahmenwerks für IVS-Architekturen müssen transparente und offene Prozedere definiert werden. Diese umfassen beispielsweise die Behebung identifizierter Fehler sowie die Weiterentwicklung des Rahmenwerks auf Basis eingereichter Erweiterungsanträge, die ggf. in Abhängigkeit des Schweregrades bzw. nach einer definierten Prioritätenliste von Experten (IVS-Architektur-Spezialisten) zeitnah behandelt werden.

Die Ergebnisse des Pflegeprozesses werden in das Rahmenwerk für IVS-Architekturen eingearbeitet und im IVS-Wiki veröffentlicht. Neben den vorherigen Aspekten, die mit der Pflege des Rahmenwerks für IVS-Architekturen zu assoziieren sind, haben die nachstehenden Aufgaben einen unterstützenden Charakter und sollten vom Aufwand her nicht unterschätzt werden.

'''Anwendersupport'''

Vor allem sei hier der Anwendersupport genannt. Er gliedert sich in eine Reihe von unterschiedlichen Leistungen, wie z.B. die Bereitstellung des Rahmenwerks für IVS-Architekturen und von weiterführenden, unterstützenden Dokumentationen (z.B. IVS-Referenzarchitekturen). Letztere können sich aus Tutorials, Guidelines, Webinars, etc. zusammensetzen.

Für eine Kollaboration von Entwicklern des Rahmenwerks für IVS-Architekturen und Firmen, die ihre Produktpalette konform zum Rahmenwerk für IVS-Architekturen entwickeln und in ihren Systemlandschaften einsetzen, können als Werkzeuge oder Kommunikationsplattformen internetbasierte Foren etc. eingerichtet und betrieben werden. Beide Werkzeuge/Plattformen benötigen eine aktive Moderation, wenn sie im Rahmen einer problemorientierten Unterstützung als Helpdesk eingerichtet werden sollen.

'''Das RIAD Portal'''

Es soll ein zentrales RIAD Portal aufgebaut werden, über das alle Informationen rund um das Rahmenwerk für IVS-Architekturen zugänglich sind. Es ist aber nicht nur ein Informationszentrum, sondern auch ein Werkzeug für den Weiterentwicklungs- und Pflegeprozess.

Über das Portal sollen nicht nur viele Informationen (Spezifikationen, Erweiterungen, IVS-Referenzimplementierung, u.v.m.) erhältlich sein. Es ist auch erforderlich, ein Issue-Tracker-Modul zu integrieren. Dieses soll eine Feedback-Möglichkeit für Nutzer des Rahmenwerks für IVS-Architekturen enthalten (Fehlerreports, Change-Requests, usw.).

Die folgende Abbildung zeigt das jetzige IVS-Wiki, das zum RIAD Portal ausgebaut werden soll:

[[File:IVS-Wiki.jpg|500px|Das IVS-Wiki Portal]]

'''Öffentlichkeitsarbeit'''

Zu den beschriebenen Aufgaben der Pflege des Rahmenwerks für IVS-Architekturen bedarf es zudem einer regen Öffentlichkeitsarbeit, um einerseits die Ergebnisse der Archtekturarbeit zeitnah einem breiten Nutzerkreis zur Verfügung stellen zu können, und andererseits einen geeigneten „Kanal“ für die Rückkopplung bereit zu halten. Nur über eine nachhaltig gewährleistete Kommunikation kann der Prozess wirklich lebendig gehalten werden. Diesbezüglich werden die Unterhaltung des Internetauftritts inkl. Newsletter, die Durchführung von Nutzerforen, Workshops usw. sowie die Repräsentation auf geeigneten (externen) Veranstaltungen (z.B. auf Messen und Kongressen) wichtige Aufgabenfelder darstellen.

Im Projekt Rahmenwerk für IVS-Architekturen für Deutschland wurde z.B. recht früh mit der Öffentlichkeitsarbeit begonnen, um die interessierten Kreise so früh, wie möglich, einzubeziehen. Zu den insgesamt zwei Veranstaltungen wurde ein breites Fachpublikum eingeladen. Auf den Veranstaltungen wurden die geleisteten inhaltlichen Arbeiten bzw. Ergebnisse im Projekt vorgestellt und das Feedback des Fachpublikums zurück in das Projekt eingespeist. Über die Veranstaltungen wurde erreicht, das Interesse am Projekt und seinen Ergebnissen zu wecken und das Fachpublikum an der Verfolgung des Entwicklungsprozesses zu binden.

'''Sekretariat'''

Letztendlich sollten auch Ressourcen für die Verwaltung des Weiterentwicklungs- und Pflegeprozesses eingeplant werden, die die Koordinierung der Prozessabläufe, verwaltungstechnische Unterstützung der Gremien des Weiterentwicklungs- und Pflegeprozesses, ggf. Verwaltung von Finanzen usw. umfasst. Für diese Aufgaben könnte ein Sekretariat eingerichtet werden. Gemessen an den Aufgaben scheint eine Realisierung des Weiterentwicklungs- und Pflegeprozesses recht komplex und aufwendig zu sein. Es ist jedoch zu bedenken, dass, je transparenter und offener der Pflegeprozess und breiter der Support (auch mit wenigen Mitteln) aufgestellt werden kann, die Chancen für eine breitere Akzeptanz bei Entwicklern und Anwendern des Rahmenwerks für IVS-Architekturen steigen.

== Organisation des Weiterentwicklungs- und Pflegeprozesses ==

=== Überblick ===

Um den Weiterentwicklungs- und Pflegeprozess für Hersteller und Anwender offen und transparent zu gestalten, bedarf es einer für alle Beteiligten klaren Organisation mit definierten Regeln. Die Organisation des Weiterentwicklungs- und Pflegeprozesses orientiert sich dabei an bereits bestehenden erfolgreichen Organisationen. Die nachstehende Grafik gibt einen Überblick über die Ausgestaltung der Organisation. Sie wird im Folgenden weiter erläutert.

[[File:IVS-RA-Prozess Organisation.jpg|500px|Organisation des IVS-Rahmenarchitektur Prozesses]]

=== Stakeholder ===

Wie zuvor beschrieben, wird empfohlen, dass der Weiterentwicklungs- und Pflegeprozess von Anwendern und Herstellern gemeinsam betrieben wird. Ergänzt werden diese Gruppierungen mit der Beteiligung von sonstigen Interessenten, wie z.B. beratende Unternehmen oder (außer-)universitäre Einrichtungen. Anwender und Hersteller, aber auch Sonstige, können in Interessensvertretungen organisiert sein. Welche Interessenvertretungen mit den jeweiligen Gruppierungen z.B. assoziiert sein können, zeigt die folgende Tabelle:

{| border="1" cellpadding="1" cellspacing="1" style="width: 528px;"
|-
! scope="col" style="background-color: rgb(238, 238, 238);" | Gruppierung
! scope="col" style="background-color: rgb(238, 238, 238); width: 326px;" | Interessenvertretung
|-
| Öffentliche Hand
| style="width: 326px;" | BASt, Experten der Länder und Kommunen 
|-
| Consultants
| style="width: 326px;" | IVS-Berater, IVS-Architekten
|-
| Hersteller
| style="width: 326px;" | Hersteller von RIAD-konformen Produkten
|-
| Standardisierungsorganisationen
| style="width: 326px;" | DIN, CEN/ISO, ETSI etc.
|-
| Verbände
| style="width: 326px;" | ITS Deutschland, TelematicsPRO etc.
|-
| Sonstige
| style="width: 326px;" | ...
|}

Die in der Tabelle genannten Interessenvertretungen könnten im Wesentlichen die Stakeholder des Weiterentwicklungs- und Pflegeprozesses darstellen. Gemeinsam würden Sie die Interessengruppe für den Weiterentwicklungs- und Pflegeprozess bilden.

=== Organe des IVS-Rahmenarchitektur Prozesses und ihre Funktion ===

Es gibt zwei primär beteiligte Organe im Weiterentwicklungs- und Pflegeprozess, die zusammen eine Arbeitsgemeinschaft bilden. Jedes Organ hat eine andere Rolle zu erfüllen, wie im Folgenden aufgeführt wird:

'''Das Lenkungskomittee'''

Das Lenkungskomitee (LK) erstellt und steuert das Arbeitsprogramm. Dabei sind die Festlegung des Arbeitsprogramms und die Zuteilung entsprechender personeller oder finanzieller Ressourcen iterativ und zyklisch (z.B. jährlich) ablaufende (Verhandlungs-)Prozesse. Die Sitzungen des LK finden in regelmäßigen, z.B. halbjährlichen Abständen statt. Es bemüht sich zudem um eine Zusammenarbeit mit anderen relevanten Interessengruppen und leistet Öffentlichkeitsarbeit, wie z.B. die Organisation von Workshops oder Symposien. Die allgemeinen technischen Aufgaben werden vom LK auf den assoziierten Arbeitsausschuss übertragen.

Das LK besteht aus Vertretern der vorrangigen Interessengruppen zu gleichen Teilen, ergänzt um sonstige Interessenten. Die Mitglieder werden aus den jeweiligen Interessenvertretungen heraus gewählt bzw. mandatiert und besitzen pro Teilnehmer im LK eine Stimme im Rahmen der Entscheidungsfindung. Existieren auf einer Seite mehrere Interessenvertretungen sind die Stimmen anteilig aufzuteilen. Die Mitarbeit sonstiger Interessenten im LK geschieht auf freiwilliger Basis und hat beratenden bzw. unterstützenden Charakter. Im Gegensatz zu Vertretern der vorrangigen Interessengruppen besitzen die sonstigen Interessenten kein Stimmrecht.

Im jährlichen Rhythmus liefert das LK einen Bericht über seine bisherigen Arbeiten im Rahmen des Weiterentwicklungs- und Pflegeprozesses an die vertretenen Interessengruppen. Generell kann das LK bei seinen Aufgaben durch ein Sekretariat unterstützt werden. In diesem Fall ist die Finanzierung zu klären. Es sollte aber auch geprüft werden, ob ein Mitglied des LK die Sekretariatsfunktion ehrenamtlich übernehmen kann.

'''Der Arbeitsausschuss'''

Der Arbeitsausschuss (AAS) erhält sein Mandat vom LK und berichtet im Gegenzug z.B. jährlich über die Fortschritte seiner Arbeiten. Daher sollte der Leiter des AAS an den Sitzungen des LK teilnehmen. Der AAS besteht aus technischen Experten, die von den Interessensvertretungen entsendet werden. Ggf. können zur temporären Unterstützung auch externe technische Experten zur Mitarbeit im AAS berufen werden. Die Finanzierung der Experten ist im Einzelfall zu klären. Aufgabe des AAS ist es, sich mit dem Management und der Weiterentwicklung des zu pflegenden Rahmenwerks für IVS-Architekturen zu beschäftigen. Dies schließt den Anwender-Support, das Bearbeiten von Benutzer-Feedbacks (Fehlermeldungen, Change-Requests usw.) über das RIAD-Portal und die Verwaltung desselben ein.

Zu diesem Zweck ist der Einsatz eines Issue-Trackers unerlässlich, in dem das Benutzer-Feedback und die Aufgaben dokumentiert und einzelnen Bearbeitern des AAS zugeordnet werden. Der für Benutzer transparente Umgang mit dem Feedback wurde mit Hilfe der Business Process Modelling Notation (BPMN 2.0 (26)) modelliert. Die dort abgebildeten Prozesse orientieren sich an der ISO 14817 (15). Zusätzlich zu den oben genannten Aufgaben führt der AAS alle erforderlichen technischen Arbeiten zur Unterstützung der laufenden Arbeiten aus. Begünstigt durch verteiltes Arbeiten auf einem gemeinsamen Datenbestand, ein definiertes Konfigurationsmanagement und Kommunikation über einen Emailverteiler, können die Sitzungen des AAS nach Bedarf stattfinden und auf ein Minimum reduziert werden. Natürlich muss eine Einigung darüber erzielt werden, wie das Hosting der Internetseite finanziert wird.

=== Entscheidungsfindung ===

Das Entscheidungsorgan im Weiterentwicklungs- und Pflegeprozess ist das Lenkungskomitee (LK). Es orientiert sich bei der Entscheidungsfindung prinzipiell am Leitbild des Weiterentwicklungs- und Pflegeprozesses. Um Entscheidungen über aufgeworfene Fragen im LK zu erreichen wird eine Abstimmung durchgeführt. Bei jedem Abstimmungs-Gegenstand hat jeder teilnehmende Interessensvertreter eine Stimme. Die Stimmen fehlender Interessenvertreter und Stimmenthaltungen haben keinen Einfluss auf den Ausgang der Abstimmung über ein Thema, es sei denn die Position der abwesenden Interessengruppe wurde dem LK zuvor mitgeteilt.

Ein abwesender Interessensvertreter kann dem LK seine Position vor der Abstimmung bekannt geben. Sie muss dem Vorsitzenden des LK in schriftlicher Form vorliegen. Der Vorsitzende des LK hat dafür zu sorgen, dass diese Position in der Abstimmung Berücksichtigung findet. Abstimmungen können auf zwei Arten geschehen:

*während eines Treffens des LK
*per E-Mail über den LK Email-Verteiler

Die Vorschläge sollten in einer Weise formuliert werden, dass folgende Wahloptionen möglich sind:

*Zustimmung,
*Ablehnung,
*Enthaltung.

Abwesende und Stimmenthaltungen werden nicht berücksichtigt und haben somit keinen Einfluss auf das Ergebnis der Abstimmung. Zur Erreichung der Beschlussfähigkeit für eine gültige Entscheidung des LK müssten jedoch mindestens 50% der verfügbaren Stimmen entweder als Zustimmung oder als Ablehnung abgegeben werden (d.h. die Mehrheit der LK Teilnehmer muss sich für eine bestätigte Position ausgesprochen haben). Ist eine Abstimmung unentschieden, wird eine erneute Abstimmung durchgeführt. Wenn diese zweite Abstimmung ebenfalls unentschieden ausfällt, gilt der Vorschlag als abgelehnt. Haben Erweiterungen des Rahmenwerks für IVS-Architekturen oder Problemlösungen des AAS zur Berücksichtigung von Änderungswünschen oder Behebung gemeldeter Fehler Auswirkungen auf die Abwärtskompatibilität zu einer vorherigen Version, beträgt die erforderliche Mehrheit im LK 75%. Wenn die erforderliche Mehrheit bezüglich einer Erweiterung/Änderung des Rahmenwerks für IVS-Architekturen erzielt ist, wird der AAS die Information über die angenommenen Änderungen auf der Website einstellen.

== Finanzierung des Weiterentwicklungs- und Pflegeprozesses ==

Letztendlich stellt sich nun die Frage, wer die oben dargestellten Aufgaben übernehmen soll/kann und wie dies finanziert werden kann. Würde niemand die Pflege des Rahmenwerks für IVS-Architekturen übernehmen, würde sie verkümmern. Selbst wenn eine Finanzierung des Prozesses möglich wäre und auch eine ausreichende IVS-Architektur Kompetenz sichergestellt werden könnte, hätten die Anwender keine Sicherheit, ob IVS-Architekturen (evtl. durch fehlende Akzeptanz) in Richtlinien und Produkten umgesetzt wird.

Es muss also geklärt werden, wer sich an den Kosten dieses Standardisierungsprozesses beteiligt bzw. Ressourcen für die Pflege des Standards bereitstellt, einhergehend mit der Frage nach den eigentlichen Nutznießern. Einerseits sind es die Städte und Kommunen, Bund und Länder, die als Anwender von diesem Prozess profitieren. Aber auch Hersteller haben ein Interesse daran, die Entwicklung voranzutreiben und den Nutzen, sich mit Vorsprung am Markt behaupten zu können.

Es wird empfohlen, dass der Weiterentwicklungs- und Pflegeprozess von den Interessengruppen gemeinsam betrieben wird. Die Finanzierung kann so auf mehrere Schultern verteilt werden z.B. durch Bereitstellung von freiwilligen Herstellerressourcen und eine finanzielle Unterstützung durch Anwender (z.B. über Projekte bzw. Erwerb der Produkte). Die Kosten des Prozesses können durch eine politische Förderung und eine Öffnung des Prozesses durch Beteiligung von sonstigen Interessenten (z. B. universitäre und außeruniversitäre Einrichtungen) zusätzlich vermindert werden.

Die Zusammenführung von IVS-Architektur Kompetenz der Entwickler und Praxiswissen der Anwender bringt für beide Seiten wesentlichen und in dieser Domäne bisher selten erreichten Nutzen; mündet sie auf der einen Seite in Realisierungssicherheit, auf der anderen Seite in Vertrauen und Anwenderakzeptanz gegenüber dem Standardisierungsobjekt. Ist letzteres erreicht wird die Motivation und die Bereitschaft einer direkten Rückkopplung im Weiterentwicklungs- und Pflegeprozess (Feedback) durch die Anwender maximiert.

Im Vergleich mit der Pflege von DATEX II (internationaler Prozess), der mit einem Aufwand von etwa 100 Personen-Wochen pro Jahr (entspricht ca. 300-400 T€) betrieben wird, kann man beim Prozess zur Weiterentwicklung und Pflege des Rahmenwerks für IVS-Architekturen (nationaler Prozess) von einem Viertel dieser Kosten (75-100 T€) pro Jahr ausgehen.

== Fazit ==

Im Folgenden werden noch einmal die wichtigsten Aspekte der Handlungsempfehlung zusammengefasst:

Jeder lebendige Standard, so auch das Rahmenwerk für IVS-Architekturen, braucht einen lebendigen Pflegeprozess. Da dieser Prozess nicht von den Standardisierungsinstitutionen CEN, DIN oder DKE betrieben wird, muss er von den Stakeholdern, wie Anwender der öffentlichen Hand, Herstellern und sonstige Interessenten, betrieben werden, die damit einen Nutzen verbinden. Dabei kann der Prozess nur für alle zufriedenstellende Ergebnisse liefern, wenn auch alle Stakeholder aktiv teilnehmen.

Die Akzeptanz des Rahmenwerks für IVS-Architekturen wird gesteigert, wenn der Pflegeprozess für alle Stakeholder offen und transparent ist. Zudem braucht der Prozess paritätische Verhältnisse, um alle Interessen auszugleichen. Dies bedeutet zum einen ein gleichmäßiges Verhältnis von Stimmen im entscheidenden Gremium (hier Lenkungskomitee). Zum anderen müssen die Kosten für den Prozess von den Stakeholdern getragen werden, die auch einen Nutzen haben – dabei muss der Nutzen die Kosten natürlich substantiell übertreffen.

Für die Finanzierung des Prozesses gibt es dabei viele Möglichkeiten, die zu prüfen sind:

*Bereitstellung von personellen Ressourcen
*Finanzierung über den Verkauf von Produkten
*Finanzierung über (geförderte) Projekte
*Finanzielle Unterstützung durch die Politik

Insbesondere der letzte Aspekt ist von großer Bedeutung. Wenn die im Weiterentwicklungs- und Pflegeprozess gepflegten Standards einen übergeordneten Nutzen haben, sind auch die Träger übergeordneter Interessen potentielle (finanzielle) Unterstützer – speziell das BMVBS und DG MOVE (IVS-Architektur Deutschland, Implementierung der EU IVS Richtlinie, Umsetzung des Urban Mobility Action Plan). Generell scheint die Etablierung und Finanzierung des Weiterentwicklungs- und Pflegeprozesses zunächst schwierig zu sein, ist aber bei Prüfung aller Variablen durchführbar.

Weiterentwicklung & Pflege der IVS-Architekturen 1.0

2018-05-11T07:57:15Z

Scholtes:

== Aufgabenstellung ==

Die Entwicklung einer ersten Version der in diesem Projekt definierten Architekturen (IVS-Rahmenarchitektur und die in den Losen 2-4 ausgeschriebenen drei Referenzarchitekturen) ist ein wichtiger Schritt hin zu plan- und steuerbaren IVS-Diensten, die zur Verbesserung der Umweltverträglichkeit, zur Steigerung der Effizienz und zur Erhöhung der Sicherheit im Straßenverkehr beitragen können.

Aufgrund sich ständig ändernder Rahmenbedingungen (z.B. Hinzukommen neuer Stakeholder und Anwendungsfelder, Entwicklung neuer Technologien, Änderung der gesetzlichen Anforderungen) ist es notwendig, die IVS-Rahmenarchitektur in regelmäßigen Abständen auf ihre Aktualität und Gültigkeit zu überprüfen und gegebenenfalls anzupassen. Auch TOGAF sieht z.B. eine ständige Kontrolle und Weiterentwicklung vor. Wichtig ist dazu eine Institutionalisierung dieser Aufgaben der Aktualisierung, Anpassung und Pflege deren Organisation und Finanzierung. Insofern beinhaltet das Konzept für die Weiterentwicklung und Pflege der IVS-Rahmenarchitektur folgenden Aufgaben:

*Um Wirkung und Nutzen der IVS-Rahmenarchitektur auf Dauer erhalten und vorantreiben zu können, muss ein Konzept für den Prozess der Einführung, Weiterentwicklung und Pflege der IVS-Rahmenarchitektur (IVS-Rahmenarchitektur Prozess) entwickelt werden. Dabei sollte neben der Weiterentwicklung der in diesem Projekt definierten IVS-Rahmenarchitektur und IVS-Referenzarchitekturen auch die Identifikation und Entwicklung weiterer IVS Referenzarchitekturen berücksichtigt werden.

*Für die Einführung und Umsetzung des IVS-Rahmenarchitektur Prozesses muss ein Organisations- und Finanzierungskonzept erarbeitet werden. Wichtig ist insbesondere dabei, die Zuständigkeiten für die Weiterentwicklung und Pflege festzulegen. Dabei ist eine Verankerung im IVS-Gesetz sicherlich sinnvoll.

== Weiterentwicklung und Pflege des Rahmenwerks für IVS-Architekturen ==

=== Problemstellung ===

Das nationale Rahmenwerk für IVS-Architekturen für Deutschland (kurz: RIAD) ist konzeptionell ein an neue Anforderungen der Anwenderseite anpassbares Meta-Modell für die Entwicklung von IVS-Referenzarchitekturen und IVS-Architekturen realer IVS-Dienste.

Um Planungs- und Rechtssicherheit in der Anwendung und Handhabung des TOGAF-basierten Vorgehensmodells zur Entwicklung von IVS-Architekturen und der auf den fünf Ebenen der IVS-Pyramide angesiedelten, primär die Zusammenarbeit von IVS-Akteuren adressierenden Kernaspekte von IVS-Architektur zu erhalten, muss dem Rahmenwerk für IVS-Architekturen quasi der Stellenwert eines Standards beigemessen werden.

Dem Wesen eines Standards entsprechend, muss die Festlegung dessen, was das Rahmenwerk für IVS-Architekturen ist und wie es angepasst oder erweitert wird, auf einer übergeordneten, neutralen Ebene geregelt werden.

Das Rahmenwerk für IVS-Architekturen muss deshalb Betrachtungs- und Handlungsgegenstand eines offenen und transparenten Prozesses sein, der einen unmittelbaren Bezug zu Einrichtungen besitzt, welche die Kompetenz einer Standardisierungseinrichtung besitzen sollen. Der Anspruch, das Rahmenwerk als offenen Standard verfügbar zu machen, stellt an die an diesem Prozess beteiligten Personen bestimmte Anforderungen im Hinblick auf Kompetenz und Unabhängigkeit. Es muss mit dem Rahmenwerk für IVS-Architekturen eine Interessenslage geweckt werden, die Personen dazu motiviert, sich am Prozess zum Zwecke der Pflege und Fortschreibung des Standards nebst der Festlegung der erforderlichen Konformitäts-Rahmenbedingungen zu beteiligen.

Einrichtungen und Unternehmen, die solche Personen beschäftigen, müssen Mittel bereitstellen wollen, damit sich Mitarbeiter auch wirklich an diesem Prozess beteiligen können. Damit das Rahmenwerk für IVS-Architekturen ein offener Standard bleibt, werden Mechanismen benötigt, die dies sicherstellen.

Eine gewisse Anlehnung an die Verfahren anderer Standardisierungseinrichtungen scheint hier angebracht. Ziel muss es sein, eine Organisationsgrundstruktur, das Qualitätsmanagement und die Anbindung an die Standardisierung zu entwickeln. Auf Grundlage dieses Modells soll der Weiterentwicklungs- und Pflegeprozess nach Möglichkeit unter Beteiligung aller in die Entwicklung und den Betrieb von IVS und IVS-Diensten involvierten und aller sonstigen Stakeholder im Bereich IVS (Bund, Länder, Industrie, Beratungsunternehmen, …) institutionalisiert und instanziiert werden.

=== Der Prozess zur Weiterentwicklung und Pflege des Rahmenwerks für IVS-Architekturen ===

Standards müssen in einem lebendigen Prozess gepflegt und weiterentwickelt werden, sonst drohen sie zu verkümmern. So ist der aktuelle Stand der IVS-Rahmenarchitektur lediglich eine Momentaufnahme im Gesamtprozess, die durch folgende Abbildung visualisiert wird:

[[File:IVS-RA-Prozess.jpg|500px|Organisation des IVS-Rahmenarchitektur Prozesses]]

Das Prozessmodell stellt sich als ein Kreislauf dar, der sich grundsätzlich für jede Version des Rahmenwerks in vier Phasen unterteilen lässt. Nach der Freigabe einer Version des Rahmenwerks für IVS-Architekturen, die aus Nutzersicht einer Bereitstellung der Version entspricht, erfolgt die Anwendung durch die Nutzer. Diese wird durch den Anwendersupport unterstützt. Feedback der Nutzer wird als Rückkopplung in das Rahmenwerk aufgenommen. Diese Rückmeldungen zu den aktuellen Versionen der IVS-Rahmenarchitektur sind von großer Bedeutung zur Weiterentwicklung bzw. zur Fehlerbehebung und wirken häufig als Initialzündung für die weitere Pflege des Rahmenwerks für IVS-Architekturen. Die in der Folge von IVS-Architekten entwickelten Versionen des Rahmenwerks für IVS-Architekturen werden in einer neuen (Unter-)Version dem Markt zur Verfügung gestellt.

Durch die Dokumentation des Weiterentwicklungs- und Pflegeprozesses (Ereignisverfolgung/Issue-Tracking) sowie ggfs. die Veröffentlichung von Ergebnissen von begleitenden Forschungsprojekten werden die Nutzer stets über den aktuellen Stand informiert und damit aktiv bei der Umsetzung unterstützt. Eine formelle Freigabe von Ergebnissen des Prozesses gibt den Anwendern zusätzlich Planungssicherheit. Mit diesen Maßnahmen soll die Akzeptanz des Rahmenwerks für IVS-Architekturen bei den Nutzern gefördert und damit die Voraussetzung für ihre Durchsetzung am Markt geschaffen werden.

Ohne ein gewisses Maß an Marktakzeptanz kann der Weiterentwicklungs- und Pflegeprozess nicht überleben. Durch die Anwendung ergeben sich beim Anwender weitere Bedürfnisse bzw. werden Lücken und Mängel der aktuellen Version des Rahmenwerks für IVS-Architekturen erkennbar, was wiederum durch ein entsprechendes Feedback in den Weiterentwicklungs- und Pflegeprozess eingebracht wird und damit die Weiterentwicklung des Rahmenwerks vorantreibt.

Hieraus ergeben sich grundsätzlich folgende Fragen bzgl. des Standardisierungsprozesses:

*Wie passt sich das Rahmenwerk für IVS-Architekturen an neue Anforderungen an?
*Wie reagiert das Rahmenwerk für IVS-Architekturen auf die Entdeckung von Fehlern?

=== Aufgaben des Weiterentwicklungs- und Pflegeprozesses ===

Die grundsätzlichen Aufgaben des Weiterentwicklungs- und Pflegeprozesses unterteilen sich in die Bereiche

*Pflege des Rahmenwerks für IVS-Architekturen,
*Anwenderunterstützung Öffentlichkeitsarbeit sowie *Selbstverwaltung des Prozesses.

Die Arbeiten zur Pflege des Rahmenwerks für IVS-Architekturen erfordern IVS-Architektur-Kompetenz und können u. U. nur von Experten (BASt, (außer)universitäre Einrichtungen, beratende Unternehmen, Hersteller und Betrieber von IVS-Diensten) übernommen werden. Sie umfassen im Wesentlichen folgende Teilbereiche:

*Pflege und Erweiterung der Basiskonzepte
*Pflege und Erweiterung der IVS-Architekturbausteine
*Pflege und Erweiterung des TOGAF-basierten Vorgehensmodells
*evtl. weitere...

Für die Pflege des Rahmenwerks für IVS-Architekturen müssen transparente und offene Prozedere definiert werden. Diese umfassen beispielsweise die Behebung identifizierter Fehler sowie die Weiterentwicklung des Rahmenwerks auf Basis eingereichter Erweiterungsanträge, die ggf. in Abhängigkeit des Schweregrades bzw. nach einer definierten Prioritätenliste von Experten (IVS-Architektur-Spezialisten) zeitnah behandelt werden.

Die Ergebnisse des Pflegeprozesses werden in das Rahmenwerk für IVS-Architekturen eingearbeitet und im IVS-Wiki veröffentlicht. Neben den vorherigen Aspekten, die mit der Pflege des Rahmenwerks für IVS-Architekturen zu assoziieren sind, haben die nachstehenden Aufgaben einen unterstützenden Charakter und sollten vom Aufwand her nicht unterschätzt werden.

'''Anwendersupport'''

Vor allem sei hier der Anwendersupport genannt. Er gliedert sich in eine Reihe von unterschiedlichen Leistungen, wie z.B. die Bereitstellung des Rahmenwerks für IVS-Architekturen und von weiterführenden, unterstützenden Dokumentationen (z.B. IVS-Referenzarchitekturen). Letztere können sich aus Tutorials, Guidelines, Webinars, etc. zusammensetzen.

Für eine Kollaboration von Entwicklern des Rahmenwerks für IVS-Architekturen und Firmen, die ihre Produktpalette konform zum Rahmenwerk für IVS-Architekturen entwickeln und in ihren Systemlandschaften einsetzen, können als Werkzeuge oder Kommunikationsplattformen internetbasierte Foren etc. eingerichtet und betrieben werden. Beide Werkzeuge/Plattformen benötigen eine aktive Moderation, wenn sie im Rahmen einer problemorientierten Unterstützung als Helpdesk eingerichtet werden sollen.

'''Das RIAD Portal'''

Es soll ein zentrales RIAD Portal aufgebaut werden, über das alle Informationen rund um das Rahmenwerk für IVS-Architekturen zugänglich sind. Es ist aber nicht nur ein Informationszentrum, sondern auch ein Werkzeug für den Weiterentwicklungs- und Pflegeprozess.

Über das Portal sollen nicht nur viele Informationen (Spezifikationen, Erweiterungen, IVS-Referenzimplementierung, u.v.m.) erhältlich sein. Es ist auch erforderlich, ein Issue-Tracker-Modul zu integrieren. Dieses soll eine Feedback-Möglichkeit für Nutzer des Rahmenwerks für IVS-Architekturen enthalten (Fehlerreports, Change-Requests, usw.).

Die folgende Abbildung zeigt das jetzige IVS-Wiki, das zum RIAD Portal ausgebaut werden soll:

[[File:IVS-Wiki.jpg|500px|Das IVS-Wiki Portal]]

'''Öffentlichkeitsarbeit'''

Zu den beschriebenen Aufgaben der Pflege des Rahmenwerks für IVS-Architekturen bedarf es zudem einer regen Öffentlichkeitsarbeit, um einerseits die Ergebnisse der Archtekturarbeit zeitnah einem breiten Nutzerkreis zur Verfügung stellen zu können, und andererseits einen geeigneten „Kanal“ für die Rückkopplung bereit zu halten. Nur über eine nachhaltig gewährleistete Kommunikation kann der Prozess wirklich lebendig gehalten werden. Diesbezüglich werden die Unterhaltung des Internetauftritts inkl. Newsletter, die Durchführung von Nutzerforen, Workshops usw. sowie die Repräsentation auf geeigneten (externen) Veranstaltungen (z.B. auf Messen und Kongressen) wichtige Aufgabenfelder darstellen.

Im Projekt Rahmenwerk für IVS-Architekturen für Deutschland wurde z.B. recht früh mit der Öffentlichkeitsarbeit begonnen, um die interessierten Kreise so früh, wie möglich, einzubeziehen. Zu den insgesamt zwei Veranstaltungen wurde ein breites Fachpublikum eingeladen. Auf den Veranstaltungen wurden die geleisteten inhaltlichen Arbeiten bzw. Ergebnisse im Projekt vorgestellt und das Feedback des Fachpublikums zurück in das Projekt eingespeist. Über die Veranstaltungen wurde erreicht, das Interesse am Projekt und seinen Ergebnissen zu wecken und das Fachpublikum an der Verfolgung des Entwicklungsprozesses zu binden.

'''Sekretariat'''

Letztendlich sollten auch Ressourcen für die Verwaltung des Weiterentwicklungs- und Pflegeprozesses eingeplant werden, die die Koordinierung der Prozessabläufe, verwaltungstechnische Unterstützung der Gremien des Weiterentwicklungs- und Pflegeprozesses, ggf. Verwaltung von Finanzen usw. umfasst. Für diese Aufgaben könnte ein Sekretariat eingerichtet werden. Gemessen an den Aufgaben scheint eine Realisierung des Weiterentwicklungs- und Pflegeprozesses recht komplex und aufwendig zu sein. Es ist jedoch zu bedenken, dass, je transparenter und offener der Pflegeprozess und breiter der Support (auch mit wenigen Mitteln) aufgestellt werden kann, die Chancen für eine breitere Akzeptanz bei Entwicklern und Anwendern des Rahmenwerks für IVS-Architekturen steigen.

== Organisation des Weiterentwicklungs- und Pflegeprozesses ==

=== Überblick ===

Um den Weiterentwicklungs- und Pflegeprozess für Hersteller und Anwender offen und transparent zu gestalten, bedarf es einer für alle Beteiligten klaren Organisation mit definierten Regeln. Die Organisation des Weiterentwicklungs- und Pflegeprozesses orientiert sich dabei an bereits bestehenden erfolgreichen Organisationen. Die nachstehende Grafik gibt einen Überblick über die Ausgestaltung der Organisation. Sie wird im Folgenden weiter erläutert.

[[File:IVS-RA-Prozess Organisation.jpg|500px|Organisation des IVS-Rahmenarchitektur Prozesses]]

=== Stakeholder ===

Wie zuvor beschrieben, wird empfohlen, dass der Weiterentwicklungs- und Pflegeprozess von Anwendern und Herstellern gemeinsam betrieben wird. Ergänzt werden diese Gruppierungen mit der Beteiligung von sonstigen Interessenten, wie z.B. beratende Unternehmen oder (außer-)universitäre Einrichtungen. Anwender und Hersteller, aber auch Sonstige, können in Interessensvertretungen organisiert sein. Welche Interessenvertretungen mit den jeweiligen Gruppierungen z.B. assoziiert sein können, zeigt die folgende Tabelle:

{| border="1" cellpadding="1" cellspacing="1" style="width: 528px;"
|-
! scope="col" style="background-color: rgb(238, 238, 238);" | Gruppierung
! scope="col" style="background-color: rgb(238, 238, 238); width: 326px;" | Interessenvertretung
|-
| Öffentliche Hand
| style="width: 326px;" | BASt, Experten der Länder und Kommunen 
|-
| Consultants
| style="width: 326px;" | IVS-Berater, IVS-Architekten
|-
| Hersteller
| style="width: 326px;" | Hersteller von RIAD-konformen Produkten
|-
| Standardisierungsorganisationen
| style="width: 326px;" | DIN, CEN/ISO, ETSI etc.
|-
| Verbände
| style="width: 326px;" | ITS Deutschland, TelematicsPRO etc.
|-
| Sonstige
| style="width: 326px;" | ...
|}

Die in der Tabelle genannten Interessenvertretungen könnten im Wesentlichen die Stakeholder des Weiterentwicklungs- und Pflegeprozesses darstellen. Gemeinsam würden Sie die Interessengruppe für den Weiterentwicklungs- und Pflegeprozess bilden.

=== Organe des IVS-Rahmenarchitektur Prozesses und ihre Funktion ===

Es gibt zwei primär beteiligte Organe im Weiterentwicklungs- und Pflegeprozess, die zusammen eine Arbeitsgemeinschaft bilden. Jedes Organ hat eine andere Rolle zu erfüllen, wie im Folgenden aufgeführt wird:

'''Das Lenkungskomittee'''

Das Lenkungskomitee (LK) erstellt und steuert das Arbeitsprogramm. Dabei sind die Festlegung des Arbeitsprogramms und die Zuteilung entsprechender personeller oder finanzieller Ressourcen iterativ und zyklisch (z.B. jährlich) ablaufende (Verhandlungs-)Prozesse. Die Sitzungen des LK finden in regelmäßigen, z.B. halbjährlichen Abständen statt. Es bemüht sich zudem um eine Zusammenarbeit mit anderen relevanten Interessengruppen und leistet Öffentlichkeitsarbeit, wie z.B. die Organisation von Workshops oder Symposien. Die allgemeinen technischen Aufgaben werden vom LK auf den assoziierten Arbeitsausschuss übertragen.

Das LK besteht aus Vertretern der vorrangigen Interessengruppen zu gleichen Teilen, ergänzt um sonstige Interessenten. Die Mitglieder werden aus den jeweiligen Interessenvertretungen heraus gewählt bzw. mandatiert und besitzen pro Teilnehmer im LK eine Stimme im Rahmen der Entscheidungsfindung. Existieren auf einer Seite mehrere Interessenvertretungen sind die Stimmen anteilig aufzuteilen. Die Mitarbeit sonstiger Interessenten im LK geschieht auf freiwilliger Basis und hat beratenden bzw. unterstützenden Charakter. Im Gegensatz zu Vertretern der vorrangigen Interessengruppen besitzen die sonstigen Interessenten kein Stimmrecht.

Im jährlichen Rhythmus liefert das LK einen Bericht über seine bisherigen Arbeiten im Rahmen des Weiterentwicklungs- und Pflegeprozesses an die vertretenen Interessengruppen. Generell kann das LK bei seinen Aufgaben durch ein Sekretariat unterstützt werden. In diesem Fall ist die Finanzierung zu klären. Es sollte aber auch geprüft werden, ob ein Mitglied des LK die Sekretariatsfunktion ehrenamtlich übernehmen kann.

'''Der Arbeitsausschuss'''

Der Arbeitsausschuss (AAS) erhält sein Mandat vom LK und berichtet im Gegenzug z.B. jährlich über die Fortschritte seiner Arbeiten. Daher sollte der Leiter des AAS an den Sitzungen des LK teilnehmen. Der AAS besteht aus technischen Experten, die von den Interessensvertretungen entsendet werden. Ggf. können zur temporären Unterstützung auch externe technische Experten zur Mitarbeit im AAS berufen werden. Die Finanzierung der Experten ist im Einzelfall zu klären. Aufgabe des AAS ist es, sich mit dem Management und der Weiterentwicklung des zu pflegenden Rahmenwerks für IVS-Architekturen zu beschäftigen. Dies schließt den Anwender-Support, das Bearbeiten von Benutzer-Feedbacks (Fehlermeldungen, Change-Requests usw.) über das RIAD-Portal und die Verwaltung desselben ein.

Zu diesem Zweck ist der Einsatz eines Issue-Trackers unerlässlich, in dem das Benutzer-Feedback und die Aufgaben dokumentiert und einzelnen Bearbeitern des AAS zugeordnet werden. Der für Benutzer transparente Umgang mit dem Feedback wurde mit Hilfe der Business Process Modelling Notation (BPMN 2.0 (26)) modelliert. Die dort abgebildeten Prozesse orientieren sich an der ISO 14817 (15). Zusätzlich zu den oben genannten Aufgaben führt der AAS alle erforderlichen technischen Arbeiten zur Unterstützung der laufenden Arbeiten aus. Begünstigt durch verteiltes Arbeiten auf einem gemeinsamen Datenbestand, ein definiertes Konfigurationsmanagement und Kommunikation über einen Emailverteiler, können die Sitzungen des AAS nach Bedarf stattfinden und auf ein Minimum reduziert werden. Natürlich muss eine Einigung darüber erzielt werden, wie das Hosting der Internetseite finanziert wird.

=== Entscheidungsfindung ===

Das Entscheidungsorgan im Weiterentwicklungs- und Pflegeprozess ist das Lenkungskomitee (LK). Es orientiert sich bei der Entscheidungsfindung prinzipiell am Leitbild des Weiterentwicklungs- und Pflegeprozesses. Um Entscheidungen über aufgeworfene Fragen im LK zu erreichen wird eine Abstimmung durchgeführt. Bei jedem Abstimmungs-Gegenstand hat jeder teilnehmende Interessensvertreter eine Stimme. Die Stimmen fehlender Interessenvertreter und Stimmenthaltungen haben keinen Einfluss auf den Ausgang der Abstimmung über ein Thema, es sei denn die Position der abwesenden Interessengruppe wurde dem LK zuvor mitgeteilt.

Ein abwesender Interessensvertreter kann dem LK seine Position vor der Abstimmung bekannt geben. Sie muss dem Vorsitzenden des LK in schriftlicher Form vorliegen. Der Vorsitzende des LK hat dafür zu sorgen, dass diese Position in der Abstimmung Berücksichtigung findet. Abstimmungen können auf zwei Arten geschehen:

*während eines Treffens des LK
*per E-Mail über den LK Email-Verteiler

Die Vorschläge sollten in einer Weise formuliert werden, dass folgende Wahloptionen möglich sind:

*Zustimmung,
*Ablehnung,
*Enthaltung.

Abwesende und Stimmenthaltungen werden nicht berücksichtigt und haben somit keinen Einfluss auf das Ergebnis der Abstimmung. Zur Erreichung der Beschlussfähigkeit für eine gültige Entscheidung des LK müssten jedoch mindestens 50% der verfügbaren Stimmen entweder als Zustimmung oder als Ablehnung abgegeben werden (d.h. die Mehrheit der LK Teilnehmer muss sich für eine bestätigte Position ausgesprochen haben). Ist eine Abstimmung unentschieden, wird eine erneute Abstimmung durchgeführt. Wenn diese zweite Abstimmung ebenfalls unentschieden ausfällt, gilt der Vorschlag als abgelehnt. Haben Erweiterungen des Rahmenwerks für IVS-Architekturen oder Problemlösungen des AAS zur Berücksichtigung von Änderungswünschen oder Behebung gemeldeter Fehler Auswirkungen auf die Abwärtskompatibilität zu einer vorherigen Version, beträgt die erforderliche Mehrheit im LK 75%. Wenn die erforderliche Mehrheit bezüglich einer Erweiterung/Änderung des Rahmenwerks für IVS-Architekturen erzielt ist, wird der AAS die Information über die angenommenen Änderungen auf der Website einstellen.

== Finanzierung des Weiterentwicklungs- und Pflegeprozesses ==

Letztendlich stellt sich nun die Frage, wer die oben dargestellten Aufgaben übernehmen soll/kann und wie dies finanziert werden kann. Würde niemand die Pflege des Rahmenwerks für IVS-Architekturen übernehmen, würde sie verkümmern. Selbst wenn eine Finanzierung des Prozesses möglich wäre und auch eine ausreichende IVS-Architektur Kompetenz sichergestellt werden könnte, hätten die Anwender keine Sicherheit, ob IVS-Architekturen (evtl. durch fehlende Akzeptanz) in Richtlinien und Produkten umgesetzt wird.

Es muss also geklärt werden, wer sich an den Kosten dieses Standardisierungsprozesses beteiligt bzw. Ressourcen für die Pflege des Standards bereitstellt, einhergehend mit der Frage nach den eigentlichen Nutznießern. Einerseits sind es die Städte und Kommunen, Bund und Länder, die als Anwender von diesem Prozess profitieren. Aber auch Hersteller haben ein Interesse daran, die Entwicklung voranzutreiben und den Nutzen, sich mit Vorsprung am Markt behaupten zu können.

Es wird empfohlen, dass der Weiterentwicklungs- und Pflegeprozess von den Interessengruppen gemeinsam betrieben wird. Die Finanzierung kann so auf mehrere Schultern verteilt werden z.B. durch Bereitstellung von freiwilligen Herstellerressourcen und eine finanzielle Unterstützung durch Anwender (z.B. über Projekte bzw. Erwerb der Produkte). Die Kosten des Prozesses können durch eine politische Förderung und eine Öffnung des Prozesses durch Beteiligung von sonstigen Interessenten (z. B. universitäre und außeruniversitäre Einrichtungen) zusätzlich vermindert werden.

Die Zusammenführung von IVS-Architektur Kompetenz der Entwickler und Praxiswissen der Anwender bringt für beide Seiten wesentlichen und in dieser Domäne bisher selten erreichten Nutzen; mündet sie auf der einen Seite in Realisierungssicherheit, auf der anderen Seite in Vertrauen und Anwenderakzeptanz gegenüber dem Standardisierungsobjekt. Ist letzteres erreicht wird die Motivation und die Bereitschaft einer direkten Rückkopplung im Weiterentwicklungs- und Pflegeprozess (Feedback) durch die Anwender maximiert.

Im Vergleich mit der Pflege von DATEX II (internationaler Prozess), der mit einem Aufwand von etwa 100 Personen-Wochen pro Jahr (entspricht ca. 300-400 T€) betrieben wird, kann man beim Prozess zur Weiterentwicklung und Pflege des Rahmenwerks für IVS-Architekturen (nationaler Prozess) von einem Viertel dieser Kosten (75-100 T€) pro Jahr ausgehen.

== Fazit ==

Im Folgenden werden noch einmal die wichtigsten Aspekte der Handlungsempfehlung zusammengefasst:

Jeder lebendige Standard, so auch das Rahmenwerk für IVS-Architekturen, braucht einen lebendigen Pflegeprozess. Da dieser Prozess nicht von den Standardisierungsinstitutionen CEN, DIN oder DKE betrieben wird, muss er von den Stakeholdern, wie Anwender der öffentlichen Hand, Herstellern und sonstige Interessenten, betrieben werden, die damit einen Nutzen verbinden. Dabei kann der Prozess nur für alle zufriedenstellende Ergebnisse liefern, wenn auch alle Stakeholder aktiv teilnehmen.

Die Akzeptanz des Rahmenwerks für IVS-Architekturen wird gesteigert, wenn der Pflegeprozess für alle Stakeholder offen und transparent ist. Zudem braucht der Prozess paritätische Verhältnisse, um alle Interessen auszugleichen. Dies bedeutet zum einen ein gleichmäßiges Verhältnis von Stimmen im entscheidenden Gremium (hier Lenkungskomitee). Zum anderen müssen die Kosten für den Prozess von den Stakeholdern getragen werden, die auch einen Nutzen haben – dabei muss der Nutzen die Kosten natürlich substantiell übertreffen.

Für die Finanzierung des Prozesses gibt es dabei viele Möglichkeiten, die zu prüfen sind:

*Bereitstellung von personellen Ressourcen
*Finanzierung über den Verkauf von Produkten
*Finanzierung über (geförderte) Projekte
*Finanzielle Unterstützung durch die Politik

Insbesondere der letzte Aspekt ist von großer Bedeutung. Wenn die im Weiterentwicklungs- und Pflegeprozess gepflegten Standards einen übergeordneten Nutzen haben, sind auch die Träger übergeordneter Interessen potentielle (finanzielle) Unterstützer – speziell das BMVBS und DG MOVE (IVS-Architektur Deutschland, Implementierung der EU IVS Richtlinie, Umsetzung des Urban Mobility Action Plan). Generell scheint die Etablierung und Finanzierung des Weiterentwicklungs- und Pflegeprozesses zunächst schwierig zu sein, ist aber bei Prüfung aller Variablen durchführbar.

Weiterentwicklung & Pflege der IVS-Architekturen 1.0

2018-05-11T07:28:10Z

Scholtes:

== Aufgabenstellung ==

Die Entwicklung einer ersten Version der in diesem Projekt definierten Architekturen (IVS-Rahmenarchitektur und die in den Losen 2-4 ausgeschriebenen drei Referenzarchitekturen) ist ein wichtiger Schritt hin zu plan- und steuerbaren IVS-Diensten, die zur Verbesserung der Umweltverträglichkeit, zur Steigerung der Effizienz und zur Erhöhung der Sicherheit im Straßenverkehr beitragen können.

Aufgrund sich ständig ändernder Rahmenbedingungen (z.B. Hinzukommen neuer Stakeholder und Anwendungsfelder, Entwicklung neuer Technologien, Änderung der gesetzlichen Anforderungen) ist es notwendig, die IVS-Rahmenarchitektur in regelmäßigen Abständen auf ihre Aktualität und Gültigkeit zu überprüfen und gegebenenfalls anzupassen. Auch TOGAF sieht z.B. eine ständige Kontrolle und Weiterentwicklung vor. Wichtig ist dazu eine Institutionalisierung dieser Aufgaben der Aktualisierung, Anpassung und Pflege deren Organisation und Finanzierung. Insofern beinhaltet das Konzept für die Weiterentwicklung und Pflege der IVS-Rahmenarchitektur folgenden Aufgaben:

*Um Wirkung und Nutzen der IVS-Rahmenarchitektur auf Dauer erhalten und vorantreiben zu können, muss ein Konzept für den Prozess der Einführung, Weiterentwicklung und Pflege der IVS-Rahmenarchitektur (IVS-Rahmenarchitektur Prozess) entwickelt werden. Dabei sollte neben der Weiterentwicklung der in diesem Projekt definierten IVS-Rahmenarchitektur und IVS-Referenzarchitekturen auch die Identifikation und Entwicklung weiterer IVS Referenzarchitekturen berücksichtigt werden.

*Für die Einführung und Umsetzung des IVS-Rahmenarchitektur Prozesses muss ein Organisations- und Finanzierungskonzept erarbeitet werden. Wichtig ist insbesondere dabei, die Zuständigkeiten für die Weiterentwicklung und Pflege festzulegen. Dabei ist eine Verankerung im IVS-Gesetz sicherlich sinnvoll.

== Weiterentwicklung und Pflege des Rahmenwerks für IVS-Architekturen ==

=== Problemstellung ===

Das nationale Rahmenwerk für IVS-Architekturen für Deutschland (kurz: RIAD) ist konzeptionell ein an neue Anforderungen der Anwenderseite anpassbares Meta-Modell für die Entwicklung von IVS-Referenzarchitekturen und IVS-Architekturen realer IVS-Dienste.

Um Planungs- und Rechtssicherheit in der Anwendung und Handhabung des TOGAF-basierten Vorgehensmodells zur Entwicklung von IVS-Architekturen und der auf den fünf Ebenen der IVS-Pyramide angesiedelten, primär die Zusammenarbeit von IVS-Akteuren adressierenden Kernaspekte von IVS-Architektur zu erhalten, muss dem Rahmenwerk für IVS-Architekturen quasi der Stellenwert eines Standards beigemessen werden.

Dem Wesen eines Standards entsprechend, muss die Festlegung dessen, was das Rahmenwerk für IVS-Architekturen ist und wie es angepasst oder erweitert wird, auf einer übergeordneten, neutralen Ebene geregelt werden.

Das Rahmenwerk für IVS-Architekturen muss deshalb Betrachtungs- und Handlungsgegenstand eines offenen und transparenten Prozesses sein, der einen unmittelbaren Bezug zu Einrichtungen besitzt, welche die Kompetenz einer Standardisierungseinrichtung besitzen sollen. Der Anspruch, das Rahmenwerk als offenen Standard verfügbar zu machen, stellt an die an diesem Prozess beteiligten Personen bestimmte Anforderungen im Hinblick auf Kompetenz und Unabhängigkeit. Es muss mit dem Rahmenwerk für IVS-Architekturen eine Interessenslage geweckt werden, die Personen dazu motiviert, sich am Prozess zum Zwecke der Pflege und Fortschreibung des Standards nebst der Festlegung der erforderlichen Konformitäts-Rahmenbedingungen zu beteiligen.

Einrichtungen und Unternehmen, die solche Personen beschäftigen, müssen Mittel bereitstellen wollen, damit sich Mitarbeiter auch wirklich an diesem Prozess beteiligen können. Damit das Rahmenwerk für IVS-Architekturen ein offener Standard bleibt, werden Mechanismen benötigt, die dies sicherstellen.

Eine gewisse Anlehnung an die Verfahren anderer Standardisierungseinrichtungen scheint hier angebracht. Ziel muss es sein, eine Organisationsgrundstruktur, das Qualitätsmanagement und die Anbindung an die Standardisierung zu entwickeln. Auf Grundlage dieses Modells soll der Weiterentwicklungs- und Pflegeprozess nach Möglichkeit unter Beteiligung aller in die Entwicklung und den Betrieb von IVS und IVS-Diensten involvierten und aller sonstigen Stakeholder im Bereich IVS (Bund, Länder, Industrie, Beratungsunternehmen, …) institutionalisiert und instanziiert werden.

=== Der Prozess zur Weiterentwicklung und Pflege des Rahmenwerks für IVS-Architekturen ===

Standards müssen in einem lebendigen Prozess gepflegt und weiterentwickelt werden, sonst drohen sie zu verkümmern. So ist der aktuelle Stand der IVS-Rahmenarchitektur lediglich eine Momentaufnahme im Gesamtprozess, die durch folgende Abbildung visualisiert wird:

[[File:IVS-RA-Prozess.jpg|500px|Organisation des IVS-Rahmenarchitektur Prozesses]]

Das Prozessmodell stellt sich als ein Kreislauf dar, der sich grundsätzlich für jede Version des Rahmenwerks in vier Phasen unterteilen lässt. Nach der Freigabe einer Version des Rahmenwerks für IVS-Architekturen, die aus Nutzersicht einer Bereitstellung der Version entspricht, erfolgt die Anwendung durch die Nutzer. Diese wird durch den Anwendersupport unterstützt. Feedback der Nutzer wird als Rückkopplung in das Rahmenwerk aufgenommen. Diese Rückmeldungen zu den aktuellen Versionen der IVS-Rahmenarchitektur sind von großer Bedeutung zur Weiterentwicklung bzw. zur Fehlerbehebung und wirken häufig als Initialzündung für die weitere Pflege des Rahmenwerks für IVS-Architekturen. Die in der Folge von IVS-Architekten entwickelten Versionen des Rahmenwerks für IVS-Architekturen werden in einer neuen (Unter-)Version dem Markt zur Verfügung gestellt.

Durch die Dokumentation des Weiterentwicklungs- und Pflegeprozesses (Ereignisverfolgung/Issue-Tracking) sowie ggfs. die Veröffentlichung von Ergebnissen von begleitenden Forschungsprojekten werden die Nutzer stets über den aktuellen Stand informiert und damit aktiv bei der Umsetzung unterstützt. Eine formelle Freigabe von Ergebnissen des Prozesses gibt den Anwendern zusätzlich Planungssicherheit. Mit diesen Maßnahmen soll die Akzeptanz des Rahmenwerks für IVS-Architekturen bei den Nutzern gefördert und damit die Voraussetzung für ihre Durchsetzung am Markt geschaffen werden.

Ohne ein gewisses Maß an Marktakzeptanz kann der Weiterentwicklungs- und Pflegeprozess nicht überleben. Durch die Anwendung ergeben sich beim Anwender weitere Bedürfnisse bzw. werden Lücken und Mängel der aktuellen Version des Rahmenwerks für IVS-Architekturen erkennbar, was wiederum durch ein entsprechendes Feedback in den Weiterentwicklungs- und Pflegeprozess eingebracht wird und damit die Weiterentwicklung des Rahmenwerks vorantreibt.

Hieraus ergeben sich grundsätzlich folgende Fragen bzgl. des Standardisierungsprozesses:

*Wie passt sich das Rahmenwerk für IVS-Architekturen an neue Anforderungen an?
*Wie reagiert das Rahmenwerk für IVS-Architekturen auf die Entdeckung von Fehlern?

=== Aufgaben des Weiterentwicklungs- und Pflegeprozesses ===

Die grundsätzlichen Aufgaben des Weiterentwicklungs- und Pflegeprozesses unterteilen sich in die Bereiche

*Pflege des Rahmenwerks für IVS-Architekturen,
*Anwenderunterstützung Öffentlichkeitsarbeit sowie *Selbstverwaltung des Prozesses.

Die Arbeiten zur Pflege des Rahmenwerks für IVS-Architekturen erfordern IVS-Architektur-Kompetenz und können u. U. nur von Experten (BASt, (außer)universitäre Einrichtungen, beratende Unternehmen, Hersteller und Betrieber von IVS-Diensten) übernommen werden. Sie umfassen im Wesentlichen folgende Teilbereiche:

*Pflege und Erweiterung der Basiskonzepte
*Pflege und Erweiterung der IVS-Architekturbausteine
*Pflege und Erweiterung des TOGAF-basierten Vorgehensmodells
*evtl. weitere...

Für die Pflege des Rahmenwerks für IVS-Architekturen müssen transparente und offene Prozedere definiert werden. Diese umfassen beispielsweise die Behebung identifizierter Fehler sowie die Weiterentwicklung des Rahmenwerks auf Basis eingereichter Erweiterungsanträge, die ggf. in Abhängigkeit des Schweregrades bzw. nach einer definierten Prioritätenliste von Experten (IVS-Architektur-Spezialisten) zeitnah behandelt werden.

Die Ergebnisse des Pflegeprozesses werden in das Rahmenwerk für IVS-Architekturen eingearbeitet und im IVS-Wiki veröffentlicht. Neben den vorherigen Aspekten, die mit der Pflege des Rahmenwerks für IVS-Architekturen zu assoziieren sind, haben die nachstehenden Aufgaben einen unterstützenden Charakter und sollten vom Aufwand her nicht unterschätzt werden.

'''Anwendersupport'''

Vor allem sei hier der Anwendersupport genannt. Er gliedert sich in eine Reihe von unterschiedlichen Leistungen, wie z.B. die Bereitstellung des Rahmenwerks für IVS-Architekturen und von weiterführenden, unterstützenden Dokumentationen (z.B. IVS-Referenzarchitekturen). Letztere können sich aus Tutorials, Guidelines, Webinars, etc. zusammensetzen.

Für eine Kollaboration von Entwicklern des Rahmenwerks für IVS-Architekturen und Firmen, die ihre Produktpalette konform zum Rahmenwerk für IVS-Architekturen entwickeln und in ihren Systemlandschaften einsetzen, können als Werkzeuge oder Kommunikationsplattformen internetbasierte Foren etc. eingerichtet und betrieben werden. Beide Werkzeuge/Plattformen benötigen eine aktive Moderation, wenn sie im Rahmen einer problemorientierten Unterstützung als Helpdesk eingerichtet werden sollen.

'''Das RIAD Portal'''

Es soll ein zentrales RIAD Portal aufgebaut werden, über das alle Informationen rund um das Rahmenwerk für IVS-Architekturen zugänglich sind. Es ist aber nicht nur ein Informationszentrum, sondern auch ein Werkzeug für den Weiterentwicklungs- und Pflegeprozess.

Über das Portal sollen nicht nur viele Informationen (Spezifikationen, Erweiterungen, IVS-Referenzimplementierung, u.v.m.) erhältlich sein. Es ist auch erforderlich, ein Issue-Tracker-Modul zu integrieren. Dieses soll eine Feedback-Möglichkeit für Nutzer des Rahmenwerks für IVS-Architekturen enthalten (Fehlerreports, Change-Requests, usw.).

Die folgende Abbildung zeigt das jetzige IVS-Wiki, das zum RIAD Portal ausgebaut werden soll:

[[File:IVS-Wiki.jpg|500px|Das IVS-Wiki Portal]]

'''Öffentlichkeitsarbeit'''

Zu den beschriebenen Aufgaben der Pflege des Rahmenwerks für IVS-Architekturen bedarf es zudem einer regen Öffentlichkeitsarbeit, um einerseits die Ergebnisse der Archtekturarbeit zeitnah einem breiten Nutzerkreis zur Verfügung stellen zu können, und andererseits einen geeigneten „Kanal“ für die Rückkopplung bereit zu halten. Nur über eine nachhaltig gewährleistete Kommunikation kann der Prozess wirklich lebendig gehalten werden. Diesbezüglich werden die Unterhaltung des Internetauftritts inkl. Newsletter, die Durchführung von Nutzerforen, Workshops usw. sowie die Repräsentation auf geeigneten (externen) Veranstaltungen (z.B. auf Messen und Kongressen) wichtige Aufgabenfelder darstellen.

Im Projekt Rahmenwerk für IVS-Architekturen für Deutschland wurde z.B. recht früh mit der Öffentlichkeitsarbeit begonnen, um die interessierten Kreise so früh, wie möglich, einzubeziehen. Zu den insgesamt zwei Veranstaltungen wurde ein breites Fachpublikum eingeladen. Auf den Veranstaltungen wurden die geleisteten inhaltlichen Arbeiten bzw. Ergebnisse im Projekt vorgestellt und das Feedback des Fachpublikums zurück in das Projekt eingespeist. Über die Veranstaltungen wurde erreicht, das Interesse am Projekt und seinen Ergebnissen zu wecken und das Fachpublikum an der Verfolgung des Entwicklungsprozesses zu binden.

'''Sekretariat'''

Letztendlich sollten auch Ressourcen für die Verwaltung des Weiterentwicklungs- und Pflegeprozesses eingeplant werden, die die Koordinierung der Prozessabläufe, verwaltungstechnische Unterstützung der Gremien des Weiterentwicklungs- und Pflegeprozesses, ggf. Verwaltung von Finanzen usw. umfasst. Für diese Aufgaben könnte ein Sekretariat eingerichtet werden. Gemessen an den Aufgaben scheint eine Realisierung des Weiterentwicklungs- und Pflegeprozesses recht komplex und aufwendig zu sein. Es ist jedoch zu bedenken, dass, je transparenter und offener der Pflegeprozess und breiter der Support (auch mit wenigen Mitteln) aufgestellt werden kann, die Chancen für eine breitere Akzeptanz bei Entwicklern und Anwendern des Rahmenwerks für IVS-Architekturen steigen.

== Organisation des IVS-Rahmenarchitektur Prozesses ==

=== Überblick ===

Um den IVS-Rahmenarchitektur Prozess für Hersteller und Anwender offen und transparent zu gestalten, bedarf es einer für alle Beteiligten klaren Organisation mit definierten Regeln. Die Organisation des IVS-Rahmenarchitektur Prozesses orientiert sich dabei an bereits bestehende erfolgreiche Organisationen. Die nachstehende Grafik gibt einen Überblick über die Ausgestaltung der Organisation. Sie wird im Folgenden weiter erläutert.

[[File:IVS-RA-Prozess Organisation.jpg|500px|Organisation des IVS-Rahmenarchitektur Prozesses]]

=== Stakeholder ===

Wie zuvor beschrieben, wird empfohlen, dass der IVS-Rahmenarchitektur Prozess von Anwendern und Herstellern gemeinsam betrieben wird. Ergänzt werden diese Gruppierungen mit der Beteiligung von sonstigen Interessenten, wie z.B. beratende Unternehmen oder (außer-)universitäre Einrichtungen. Anwender und Hersteller, aber auch Sonstige, können in Interessensvertretungen organisiert sein. Welche Interessensvertretungen mit den jeweiligen Gruppierungen z.B. assoziiert sein können, zeigt die folgende Tabelle:

{| style="width: 500px;" border="1" cellspacing="1" cellpadding="1"
|-
! style="background-color: rgb(238, 238, 238);" scope="col" | Gruppierung
! style="background-color: rgb(238, 238, 238);" scope="col" | Interessenvertretung
|-
| Öffentliche Hand
| BASt, Experten der Länder und Kommunen 
|-
| Consultants
|
|-
| Hersteller
|
|-
| Standardisierungsorganisationen
|
|-
| Verbände
|
|-
| Sonstige
|
|}

Die in der Tabelle genannten könnten im Wesentlichen die Stakeholder des IVS-Rahmenarchitektur Prozesses darstellen. Gemeinsam würden Sie die Interessensgruppe für den IVS-Rahmenarchitektur Prozess bilden.

=== Organe des IVS-Rahmenarchitektur Prozesses und ihre Funktion ===

Es gibt zwei primär beteiligte Organe im IVS-Rahmenarchitektur Prozess, die zusammen eine Arbeitsgemeinschaft bilden. Jedes Organ hat eine andere Rolle zu erfüllen, wie im Folgenden aufgeführt wird:

'''Das Lenkungskomittee'''

Das Lenkungskomitee (LK) erstellt und steuert das Arbeitsprogramm. Dabei sind die Festlegung des Arbeitsprogramms und die Zuteilung entsprechender personeller oder finanzieller Ressourcen iterativ und zyklisch (z.B. jährlich) ablaufende (Verhandlungs-)Prozesse. Die Sitzungen des LK finden in regelmäßigen, z.B. halbjährlichen Abständen statt. Es bemüht sich zudem um eine Zusammenarbeit mit anderen relevanten Interessengruppen und leistet Öffentlichkeitsarbeit, wie z.B. die Organisation von Workshops oder Symposien. Die allgemeinen technischen Aufgaben werden vom LK auf den assoziierten Arbeitsausschuss übertragen.

Das LK besteht aus Vertretern der vorrangigen Interessengruppen zu gleichen Teilen, ergänzt um sonstige Interessenten. Die Mitglieder werden aus den jeweiligen Interessenvertretungen heraus gewählt bzw. mandatiert und besitzen pro Teilnehmer im LK eine Stimme im Rahmen der Entscheidungsfindung. Existieren auf einer Seite mehrere Interessenvertretungen sind die Stimmen anteilig aufzuteilen. Die Mitarbeit sonstiger Interessenten im LK geschieht auf freiwilliger Basis und hat beratenden bzw. unterstützenden Charakter. Im Gegensatz zu Vertretern der vorrangigen Interessengruppen besitzen die sonstigen Interessenten kein Stimmrecht.

Im jährlichen Rhythmus liefert das LK einen Bericht über seine bisherigen Arbeiten im Rahmen des IVS-Rahmenarchitektur Prozesses an die vertretenen Interessengruppen. Generell kann das LK bei seinen Aufgaben durch ein Sekretariat unterstützt werden. In diesem Fall ist die Finanzierung zu klären. Es sollte aber auch geprüft werden, ob ein Mitglied des LK die Sekretariatsfunktion ehrenamtlich übernehmen kann.

'''Der Arbeitsausschuss'''

Der Arbeitsausschuss (AAS) erhält sein Mandat vom LK und berichtet im Gegenzug z.B. jährlich über die Fortschritte seiner Arbeiten. Daher sollte der Leiter des AAS an den Sitzungen des LK teilnehmen. Der AAS besteht aus technischen Experten, die von den Interessensvertretungen entsendet werden. Ggf. können zur temporären Unterstützung auch externe technische Experten zur Mitarbeit im AAS berufen werden. Die Finanzierung der Experten ist im Einzelfall zu klären. Aufgabe des AAS ist es, sich mit dem Management und der Weiterentwicklung der zu pflegenden IVS-RAhemnarchtektur zu beschäftigen. Dies schließt den Anwender-Support, das Benutzer-Feedback (Fehlermeldungen, Erweiterungen usw.) über die Internetseite und die Verwaltung derselben ein.

Zu diesem Zweck ist der Einsatz eines Issue-Trackers unerlässlich, in dem das Benutzer- Feedback und die Aufgaben dokumentiert und einzelnen Bearbeitern des AAS zugeordnet werden. Der für Benutzer transparente Umgang mit dem Feedback wurde mit Hilfe der Business Process Modelling Notation (BPMN 2.0 (26)) modelliert. Die dort abgebildeten Prozesse orientieren sich an der ISO 14817 (15). Zusätzlich zu den oben genannten Aufgaben führt der AAS alle erforderlichen technischen Arbeiten zur Unterstützung der laufenden Arbeiten aus. Begünstigt durch verteiltes Arbeiten auf einem gemeinsamen Datenbestand (z.B. SVN-Repository), ein definiertes Konfigurationsmanagement und Kommunikation über einen Emailverteiler, können die Sitzungen des AAS nach Bedarf stattfinden und auf ein Minimum reduziert werden. Natürlich muss eine Einigung darüber erzielt werden, wie das Hosting der Internetseite finanziert wird.

=== Entscheidungsfindung ===

Das Entscheidungsorgan im IVS-Rahmenarchitektur Prozess ist das Lenkungskomitee (LK). Es orientiert sich bei der Entscheidungsfindung prinzipiell am Leitbild des IVS-Rahmenarchitektur Prozesses. Um Entscheidungen über aufgeworfene Fragen im LK zu erreichen wird eine Abstimmung durchgeführt. Bei jedem Abstimmungs-Gegenstand hat jeder teilnehmende Interessensvertreter eine Stimme. Die Stimmen fehlender Interessenvertreter und Stimmenthaltungen haben keinen Einfluss auf den Ausgang der Abstimmung über ein Thema, es sei denn die Position der abwesenden Interessengruppe wurde dem LK zuvor mitgeteilt.

Ein abwesender Interessensvertreter kann dem LK seine Position vor der Abstimmung bekannt geben. Sie muss dem Vorsitzenden des LK in schriftlicher Form vorliegen. Der Vorsitzende des LK hat dafür zu sorgen, dass diese Position in der Abstimmung Berücksichtigung findet. Abstimmungen können auf zwei Arten geschehen:

*während eines Treffens des LK
*per E-Mail über den LK Email-Verteiler

Die Vorschläge sollten in einer Weise formuliert werden, dass folgende Wahloptionen möglich sind:

*Zustimmung,
*Ablehnung,
*Enthaltung.

Abwesende und Stimmenthaltungen werden nicht berücksichtigt und haben somit keinen Einfluss auf das Ergebnis der Abstimmung. Zur Erreichung der Beschlussfähigkeit für eine gültige Entscheidung des LK müssten jedoch mindestens 50% der verfügbaren Stimmen entweder als Zustimmung oder als Ablehnung abgegeben werden (d.h. die Mehrheit der LK Teilnehmer muss sich für eine bestätigte Position ausgesprochen haben). Ist eine Abstimmung unentschieden, wird eine erneute Abstimmung durchgeführt. Wenn diese zweite Abstimmung ebenfalls unentschieden ausfällt, gilt der Vorschlag als abgelehnt. Haben Erweiterungen der IVS-Rahmenarchitektur oder Problemlösungen des AAS zur Berücksichtigung von Änderungswünschen oder Behebung gemeldeter Fehler Auswirkungen auf die Abwärtskompatibilität zu einer vorherigen Version, beträgt die erforderliche Mehrheit im LK 75%. Wenn die erforderliche Mehrheit bezüglich einer Erweiterung/Änderung der IVS-Rahmenarchitektur erzielt ist, wird der AAS die Information über die angenommenen Änderungen auf der Website einstellen.

== Finanzierung des IVS-Rahmenarchitektur Prozesses ==

Letztendlich stellt sich nun die Frage, wer die oben dargestellten Aufgaben übernehmen soll/kann und wie dies finanziert werden kann. Würde niemand die Pflege IVS-Rahmenarchitektur übernehmen, würde sie verkümmern. Selbst wenn eine Finanzierung des Prozesses möglich wäre und auch eine ausreichende IVS-Architektur Kompetenz sichergestellt werden könnte, hätten die Anwender keine Sicherheit, ob IVS-Rahmenarchitektur (evtl. durch fehlende Akzeptanz) in Richtlinien und Produkten umgesetzt wird.

Es muss also geklärt werden, wer sich an den Kosten dieses Standardisierungsprozesses beteiligt bzw. Ressourcen für die Pflege des Standards bereitstellt, einhergehend mit der Frage nach den eigentlichen Nutznießern. Einerseits sind es die Städte und Kommunen, Bund und Länder, die als Anwender von diesem Prozess profitieren. Aber auch Hersteller haben ein Interesse daran, die Entwicklung voranzutreiben und den Nutzen, sich mit Vorsprung am Markt behaupten zu können.

Es wird empfohlen, dass der IVS-Rahmenarchitektur Prozess von den Interessengruppen gemeinsam betrieben wird. Die Finanzierung kann so auf mehreren Schultern verteilt werden z.B. durch Bereitstellung von freiwilligen Herstellerressourcen und eine finanzielle Unterstützung durch Anwender (z.B. über Projekte bzw. Erwerb der Produkte). Die Kosten des Prozesses können durch eine politische Förderung und eine Öffnung des Prozesses durch Beteiligung von sonstigen Interessenten (z. B. universitäre und außeruniversitäre Einrichtungen) zusätzlich vermindert werden.

Die Zusammenführung von IVS-Architektur Kompetenz der Entwickler und Praxiswissen der Anwender bringt für beide Seiten wesentlichen und in dieser Domäne bisher selten erreichten Nutzen; mündet sie auf der einen Seite in Realisierungssicherheit, auf der anderen Seite in Vertrauen und Anwenderakzeptanz gegenüber dem Standardisierungsobjekt. Ist letzteres erreicht wird die Motivation und die Bereitschaft einer direkten Rückkopplung im IVS-Rahmenarchitektur Prozess (Feedback) durch die Anwender maximiert.

Im Vergleich mit der Pflege von DATEX II (internationaler Prozess), der mit einem Aufwand von etwa 100 Mann-Wochen pro Jahr (entspricht ca. 300-400 T€) betrieben wird, kann man beim IVS-Rahmenarchitektur Prozess (nationaler Prozess) von einem Viertel dieser Kosten (75-100 T€) pro Jahr ausgehen.

== Fazit ==

Im Folgenden werden noch einmal die wichtigsten Aspekte der Handlungsempfehlung zusammengefasst:

Jeder lebendige Standard, so auch die IVS-Rahmenarchitektur, braucht einen lebendigen Pflegeprozess. Da dieser Prozess nicht von den Standardisierungsinstitutionen CEN, DIN oder DKE betrieben wird, muss er von den Stakeholdern, wie Anwender der öffentlichen Hand, Herstellern und sonstige Interessenten, betrieben werden, die damit einen Nutzen verbinden. Dabei kann der Prozess nur für alle zufriedenstellende Ergebnisse liefern, wenn auch alle Stakeholder aktiv teilnehmen.

Die Akzeptanz der IVS-Rahmenarchitektur wird gesteigert, wenn der Pflegeprozess für alle Stakeholder offen und transparent ist. Zudem braucht der Prozess paritätische Verhältnisse, um alle Interessen auszugleichen. Dies bedeutet zum einen ein gleichmäßiges Verhältnis von Stimmen im entscheidenden Gremium (hier Lenkungskomitee). Zum anderen müssen die Kosten für den Prozess von den Stakeholdern getragen werden, die auch einen Nutzen haben – dabei muss der Nutzen die Kosten natürlich substantiell übertreffen.

Für die Finanzierung des Prozesses gibt es dabei viele Möglichkeiten, die zu prüfen sind:

*Bereitstellung von personellen Ressourcen
*Finanzierung über den Verkauf von Produkten
*Finanzierung über (geförderte) Projekte
*Finanzielle Unterstützung durch die Politik

Insbesondere der letzte Aspekt ist von großer Bedeutung. Wenn die im IVS-Rahmenarchitektur Prozess gepflegten Standards einen übergeordneten Nutzen haben, sind auch die Träger übergeordneter Interessen potentielle (finanzielle) Unterstützer – speziell das BMVBS und DG MOVE (IVS-Architektur Deutschland, Implementierung der EU IVS Richtlinie, Umsetzung des Urban Mobility Action Plan). Generell scheint die Etablierung und Finanzierung des IVS-Rahmenarchitektur Prozesses zunächst schwierig zu sein, ist aber bei Prüfung aller Variablen durchführbar.

Weiterentwicklung & Pflege der IVS-Architekturen 1.0

2018-05-11T06:53:24Z

Scholtes:

== Aufgabenstellung ==

Die Entwicklung einer ersten Version der in diesem Projekt definierten Architekturen (IVS-Rahmenarchitektur und die in den Losen 2-4 ausgeschriebenen drei Referenzarchitekturen) ist ein wichtiger Schritt hin zu plan- und steuerbaren IVS-Diensten, die zur Verbesserung der Umweltverträglichkeit, zur Steigerung der Effizienz und zur Erhöhung der Sicherheit im Straßenverkehr beitragen können.

Aufgrund sich ständig ändernder Rahmenbedingungen (z.B. Hinzukommen neuer Stakeholder und Anwendungsfelder, Entwicklung neuer Technologien, Änderung der gesetzlichen Anforderungen) ist es notwendig, die IVS-Rahmenarchitektur in regelmäßigen Abständen auf ihre Aktualität und Gültigkeit zu überprüfen und gegebenenfalls anzupassen. Auch TOGAF sieht z.B. eine ständige Kontrolle und Weiterentwicklung vor. Wichtig ist dazu eine Institutionalisierung dieser Aufgaben der Aktualisierung, Anpassung und Pflege deren Organisation und Finanzierung. Insofern beinhaltet das Konzept für die Weiterentwicklung und Pflege der IVS-Rahmenarchitektur folgenden Aufgaben:

*Um Wirkung und Nutzen der IVS-Rahmenarchitektur auf Dauer erhalten und vorantreiben zu können, muss ein Konzept für den Prozess der Einführung, Weiterentwicklung und Pflege der IVS-Rahmenarchitektur (IVS-Rahmenarchitektur Prozess) entwickelt werden. Dabei sollte neben der Weiterentwicklung der in diesem Projekt definierten IVS-Rahmenarchitektur und IVS-Referenzarchitekturen auch die Identifikation und Entwicklung weiterer IVS Referenzarchitekturen berücksichtigt werden.

*Für die Einführung und Umsetzung des IVS-Rahmenarchitektur Prozesses muss ein Organisations- und Finanzierungskonzept erarbeitet werden. Wichtig ist insbesondere dabei, die Zuständigkeiten für die Weiterentwicklung und Pflege festzulegen. Dabei ist eine Verankerung im IVS-Gesetz sicherlich sinnvoll.

== Weiterentwicklung und Pflege der IVA-Rahmenarchitektur ==

=== Problemstellung ===

Das nationale Rahmenwerk für IVS-Architektur "Straße" (kurz: die IVS-Rahmenarchitektur) ist konzeptionell ein an neue Anforderungen der Anwenderseite anpassbares Meta-Modell für die Entwicklung von IVS-Referenzarchitekturen und IVS-Architekturen realer IVS-Dienste.

Um Planungs- und Rechtssicherheit in der Anwendung und Handhabung des TOGAF-basierten Vorgehensmodells zur Entwicklung von IVS-Architekturen und der auf den fünf Ebenen der IVS-Pyramide angesiedelten, primär die Zusammenarbeit von IVS-Akteuren adressierenden Kernaspekte von IVS-Architektur zu erhalten, muss der IVS-Rahmenarchitektur quasi der Stellenwert eines Standards beigemessen werden.

Dem Wesen eines Standards entsprechend, muss die Festlegung dessen, was die IVS-Rahmenarchitektur ist und wie die IVS-Rahmenarchitektur angepasst oder erweitert wird, auf einer übergeordneten, neutralen Ebene geregelt werden.

Die IVS-Rahmenarchitektur muss deshalb Betrachtungs- und Handlungsgegenstand eines offenen und transparenten IVS-Rahmenarchitektur-Prozesses sein, der einen unmittelbaren Bezug zu Einrichtungen besitzt, welche die Kompetenz einer Standardisierungseinrichtung besitzen sollen. Der Anspruch, die IVS-Rahmenarchitektur als offenen Standard verfügbar zu machen, stellt an die an diesem IVS-Rahmenarchitektur-Prozess beteiligten Personen bestimmte Anforderungen im Hinblick auf Kompetenz und Unabhängigkeit. Es muss mit der IVS-Rahmenarchitektur eine Interessenslage geweckt werden, die Personen dazu motiviert, sich am IVS-Rahmenarchitektur Prozess zum Zwecke der Pflege und Fortschreibung des Standards nebst der Festlegung der erforderlichen Konformitäts-Rahmenbedingungen zu beteiligen.

Einrichtungen und Unternehmen, die solche Personen beschäftigen, müssen Mittel bereitstellen wollen, damit sich Mitarbeiter auch wirklich an diesem IVS-Rahmenarchitektur Prozess beteiligen können. Damit die IVS-Rahmenarchitektur ein offener Standard bleibt, werden Mechanismen benötigt, die dies sicherstellen.

Eine gewisse Anlehnung an die Verfahren anderer Standardisierungseinrichtungen scheint hier angebracht. Ziel muss es sein, eine Organisationsgrundstruktur, das Qualitätsmanagement und die Anbindung an die Standardisierung zu entwickeln. Auf Grundlage dieses Modells soll der IVS-Rahmenarchitektur Prozess nach Möglichkeit unter Beteiligung aller in die Entwicklung und den Betrieb von IVS und IVS-Diensten involvierten und aller sonstigen Stakeholder im Bereich IVS (Bund, Länder, Industrie, Beratungsunternehmen, …) institutionalisiert und instanziiert werden.

=== Der IVS-Rahmenarchitektur Prozess ===

Standards müssen in einem lebendigen Prozess gepflegt und weiterentwickelt werden, sonst drohen sie zu verkümmern. So ist der aktuelle Stand der IVS-Rahmenarchitektur lediglich eine Momentaufnahme im IVS-Rahmenarchitektur Prozess, das folgende Abbildung visualisiert:

[[File:IVS-RA-Prozess.jpg|500px|Organisation des IVS-Rahmenarchitektur Prozesses]]

Das IVS-Rahmenarchitektur Prozessmodell stellt sich als ein Kreislauf dar, der sich grundsätzlich in vier Phasen unterteilen lässt. Ein Feedback der Nutzer als Rückkopplung zu den aktuellen Versionen der IVS-Rahmenarchitektur ist von großer Bedeutung zur Weiterentwicklung bzw. zur Fehlerbehebung und wirkt häufig als Initialzündung für die weitere Pflege des IVS-Rahmenarchitektur. Die in der Folge von IVS-Architekten entwickelten IVS-Rahmenarchitektur Versionen werden in einer neuen (Unter-)Version dem Markt zur Realisierung zur Verfügung gestellt.

Durch die Dokumentation des IVS-Rahmenarchitektur Prozesses (Ereignisverfolgung/Issue-Tracking) sowie ggfs. die Veröffentlichung von Ergebnissen von begleitenden Forschungsprojekten werden die Nutzer stets über den aktuellen Stand informiert und damit aktiv bei der Umsetzung unterstützt. Eine formelle Freigabe von Ergebnissen des IVS-Rahmenarchitektur Prozesses gibt den Anwendern zusätzlich Planungssicherheit. Mit diesen Maßnahmen soll die Akzeptanz der IVS-Rahmenarchitektur bei den Nutzern gefördert und damit die Voraussetzung für ihre Durchsetzung am Markt geschaffen werden.

Ohne ein gewisses Maß an Marktakzeptanz kann der IVS-Rahmenarchitektur Prozess nicht überleben. Durch die Anwendung ergeben sich beim Anwender weitere Bedürfnisse bzw. werden Lücken und Mängel der aktuellen Version der IVS-Rahmenarchitektur erkennbar, was wiederum durch ein entsprechendes Feedback in den IVS-Rahmenarchitektur Prozess eingebracht wird und damit die Weiterentwicklung der IVS-Rahmenarchitektur vorantreibt.

Hieraus ergeben sich grundsätzlich folgende Fragen bzgl. des Standardisierungsprozesses:

*Wie passt sich die IVS-Rahmenarchitektur an neue Anforderungen an?
*Wie reagiert die IVS-Rahmenarchitektur auf die Entdeckung von Fehlern?

=== Aufgaben des IVS-Rahmenarchitektur Prozesses ===

Die grundsätzlichen Aufgaben des IVS-Rahmenarchitektur Prozesses unterteilen sich in die Bereiche

*Pflege der IVS-Rahmenarchitektur,
*Anwenderunterstützung Öffentlichkeitsarbeit sowie *Selbstverwaltung des Prozesses.

Die Arbeiten zur Pflege der IVS-Rahmenarchitektur erfordern IVS-Architektur-Kompetenz und können u. U. nur von Experten (BASt, (außer)universitäre Einrichtungen, beratende Unternehmen, Hersteller und Betrieber von IVS-Diensten) übernommen werden. Sie umfassen im Wesentlichen folgende Teilbereiche:

*Pflege und Erweiterung der Basiskonzepte
*Pflege und Erweiterung der IVS-Architekturbausteine
*Pflege und Erweiterung des TOGAF-basierten Vorgehensmodells
*evtl. weitere...

Für die Pflege der IVS-Rahmenarchitektur müssen transparente und offene Prozedere definiert werden. Diese umfassen beispielsweise die Behebung identifizierter Fehler sowie die Weiterentwicklung der IVS-Rahmenarchitektur auf Basis eingereichter Erweiterungsanträge, die ggf. in Abhängigkeit des Schweregrades bzw. nach einer definierten Prioritätenliste von Experten (IVS-Architektur-Spezialisten) zeitnah behandelt werden.

Die Ergebnisse des Pflegeprozesses werden in die IVS-Rahmenarchitektur eingearbeitet und im IVS-Wiki veröffentlicht. Neben den vorherigen Aspekten, die mit der Pflege der IVS-Rahmenarchitektur zu assoziieren sind, haben die nachstehenden Aufgaben einen unterstützenden Charakter und sollten vom Aufwand her nicht unterschätzt werden.

'''Anwendersupport'''

Vor allem sei hier der Anwendersupport genannt. Er gliedert sich in eine Reihe von unterschiedlichen Leistungen, wie z.B. die Bereitstellung IVS-Rahmenarchitektur und von weiterführenden, unterstützenden Dokumentationen (z.B. IVS-Referenzarchitekturen). Letztere können sich aus Tutorials, Guidelines, Webinars, etc. zusammensetzen.

Für eine Kollaboration von Entwicklern der IVS-Rahmenarchitektur und Firmen, die ihre Produktpalette konform zur IVS-Rahmenarchitektur entwickeln und in ihren Systemlandschaften einsetzen, können als Werkzeuge oder Kommunikationsplattformen internetbasierte Foren etc. eingerichtet und betrieben werden. Beide Werkzeuge/Plattformen benötigen eine aktive Moderation, wenn sie im Rahmen einer problemorientierten Unterstützung als Helpdesk eingerichtet werden sollen.

'''Issue-Tracking'''

Aufgetretene Probleme können in einem Issue-Tracking-System dokumentiert werden. Es dient dazu, den reibungslosen Ablauf daraus resultierender Aufgaben zu gewährleisten und die Pflege der IVS-Rahmenarchitektur zu unterstützten. Im Projekt IVS-Rahmenarchitektur wurde dazu mit der Internetplattform www.......org der Grundstein gelegt. Dort finden sich alle Informationen rund um die IVS-Rahmenarchitektur. Es ist aber nicht nur ein Informationszentrum, sondern auch ein Werkzeug für den IVS-Rahmenarchitektur Prozess.

Über das Portal sind nicht nur viele Informationen (Spezifikationen, Erweiterungen, IVS-Referenzimplementierung, u.v.m.) erhältlich. Es ist auch erforderlich, ein Issue-Tracker-Modul zu integrieren. Dieses bietet eine Feedback-Möglichkeit für Nutzer der IVS-Rahmenarchitektur (Fehlerreports, Anforderungen an IVS-Rahmenarchitektur, usw.).

Die folgende Abbildung zeigt das IVS-Wiki Portal:

[[File:IVS-Wiki.jpg|500px|Das IVS-Wiki Portal]]

'''Öffentlichkeitsarbeit'''

Zu den beschriebenen Aufgaben der Pflege der IVS-Rahmenarchitektur bedarf es zudem einer regen Öffentlichkeitsarbeit, um einerseits die Ergebnisse der Archtekturarbeit zeitnah einem breiten Nutzerkreis zur Verfügung stellen zu können und andererseits einen geeigneten „Kanal“ für die Rückkopplung bereit zu halten. Nur über eine nachhaltig gewährleistete Kommunikation kann der Prozess wirklich lebendig gehalten werden. Diesbezüglich werden die Unterhaltung des Internetauftritts inkl. Newsletter, die Durchführung von Nutzerforen, Workshops usw. sowie die Repräsentation auf geeigneten (externen) Veranstaltungen (z.B. auf Messen und Kongressen) wichtige Aufgabenfelder darstellen.

Im Projekt IVS-Rahmenarchitektur wurde z.B. recht früh mit der Öffentlichkeitsarbeit begonnen, um die interessierten Kreise so früh, wie möglich, einzubeziehen. Zu den insgesamt zwei Veranstaltungen wurde ein breites Fachpublikum eingeladen. Auf den Veranstaltungen wurden die geleisteten inhaltlichen Arbeiten bzw. Ergebnisse im Projekt vorgestellt und das Feedback des Fachpublikums zurück in das Projekt eingespeist. Über die Veranstaltungen wurde erreicht, das Interesse am Projekt und seinen Ergebnissen zu wecken und das Fachpublikum an der Verfolgung des IVS-Rahmenarchitektur Prozesses zu binden.

'''Sekretariat'''

Letztendlich sollten auch Ressourcen für die Verwaltung des IVS-Rahmenarchitektur Prozesses eingeplant werden, die die Koordinierung der Prozessabläufe, verwaltungstechnische Unterstützung der Gremien des IVS-Rahmenarchitektur Prozesses, ggf. Verwaltung von Finanzen usw. umfasst. Für diese Aufgaben könnte ein Sekretariat eingerichtet werden. Gemessen an den Aufgaben scheint eine Realisierung des IVS-Rahmenarchitektur Prozesses recht komplex und aufwendig zu sein. Es ist jedoch zu bedenken, dass je transparenter und offener der Pflegeprozess und breiter der Support (auch mit wenigen Mitteln) aufgestellt werden kann, die Chancen für eine breitere Akzeptanz bei Entwicklern und Anwendern der IVS-Rahmenarchitektur steigen.

== Organisation des IVS-Rahmenarchitektur Prozesses ==

=== Überblick ===

Um den IVS-Rahmenarchitektur Prozess für Hersteller und Anwender offen und transparent zu gestalten, bedarf es einer für alle Beteiligten klaren Organisation mit definierten Regeln. Die Organisation des IVS-Rahmenarchitektur Prozesses orientiert sich dabei an bereits bestehende erfolgreiche Organisationen. Die nachstehende Grafik gibt einen Überblick über die Ausgestaltung der Organisation. Sie wird im Folgenden weiter erläutert.

[[File:IVS-RA-Prozess Organisation.jpg|500px|Organisation des IVS-Rahmenarchitektur Prozesses]]

=== Stakeholder ===

Wie zuvor beschrieben, wird empfohlen, dass der IVS-Rahmenarchitektur Prozess von Anwendern und Herstellern gemeinsam betrieben wird. Ergänzt werden diese Gruppierungen mit der Beteiligung von sonstigen Interessenten, wie z.B. beratende Unternehmen oder (außer-)universitäre Einrichtungen. Anwender und Hersteller, aber auch Sonstige, können in Interessensvertretungen organisiert sein. Welche Interessensvertretungen mit den jeweiligen Gruppierungen z.B. assoziiert sein können, zeigt die folgende Tabelle:

{| style="width: 500px;" border="1" cellspacing="1" cellpadding="1"
|-
! style="background-color: rgb(238, 238, 238);" scope="col" | Gruppierung
! style="background-color: rgb(238, 238, 238);" scope="col" | Interessenvertretung
|-
| Öffentliche Hand
| BASt, Experten der Länder und Kommunen 
|-
| Consultants
|
|-
| Hersteller
|
|-
| Standardisierungsorganisationen
|
|-
| Verbände
|
|-
| Sonstige
|
|}

Die in der Tabelle genannten könnten im Wesentlichen die Stakeholder des IVS-Rahmenarchitektur Prozesses darstellen. Gemeinsam würden Sie die Interessensgruppe für den IVS-Rahmenarchitektur Prozess bilden.

=== Organe des IVS-Rahmenarchitektur Prozesses und ihre Funktion ===

Es gibt zwei primär beteiligte Organe im IVS-Rahmenarchitektur Prozess, die zusammen eine Arbeitsgemeinschaft bilden. Jedes Organ hat eine andere Rolle zu erfüllen, wie im Folgenden aufgeführt wird:

'''Das Lenkungskomittee'''

Das Lenkungskomitee (LK) erstellt und steuert das Arbeitsprogramm. Dabei sind die Festlegung des Arbeitsprogramms und die Zuteilung entsprechender personeller oder finanzieller Ressourcen iterativ und zyklisch (z.B. jährlich) ablaufende (Verhandlungs-)Prozesse. Die Sitzungen des LK finden in regelmäßigen, z.B. halbjährlichen Abständen statt. Es bemüht sich zudem um eine Zusammenarbeit mit anderen relevanten Interessengruppen und leistet Öffentlichkeitsarbeit, wie z.B. die Organisation von Workshops oder Symposien. Die allgemeinen technischen Aufgaben werden vom LK auf den assoziierten Arbeitsausschuss übertragen.

Das LK besteht aus Vertretern der vorrangigen Interessengruppen zu gleichen Teilen, ergänzt um sonstige Interessenten. Die Mitglieder werden aus den jeweiligen Interessenvertretungen heraus gewählt bzw. mandatiert und besitzen pro Teilnehmer im LK eine Stimme im Rahmen der Entscheidungsfindung. Existieren auf einer Seite mehrere Interessenvertretungen sind die Stimmen anteilig aufzuteilen. Die Mitarbeit sonstiger Interessenten im LK geschieht auf freiwilliger Basis und hat beratenden bzw. unterstützenden Charakter. Im Gegensatz zu Vertretern der vorrangigen Interessengruppen besitzen die sonstigen Interessenten kein Stimmrecht.

Im jährlichen Rhythmus liefert das LK einen Bericht über seine bisherigen Arbeiten im Rahmen des IVS-Rahmenarchitektur Prozesses an die vertretenen Interessengruppen. Generell kann das LK bei seinen Aufgaben durch ein Sekretariat unterstützt werden. In diesem Fall ist die Finanzierung zu klären. Es sollte aber auch geprüft werden, ob ein Mitglied des LK die Sekretariatsfunktion ehrenamtlich übernehmen kann.

'''Der Arbeitsausschuss'''

Der Arbeitsausschuss (AAS) erhält sein Mandat vom LK und berichtet im Gegenzug z.B. jährlich über die Fortschritte seiner Arbeiten. Daher sollte der Leiter des AAS an den Sitzungen des LK teilnehmen. Der AAS besteht aus technischen Experten, die von den Interessensvertretungen entsendet werden. Ggf. können zur temporären Unterstützung auch externe technische Experten zur Mitarbeit im AAS berufen werden. Die Finanzierung der Experten ist im Einzelfall zu klären. Aufgabe des AAS ist es, sich mit dem Management und der Weiterentwicklung der zu pflegenden IVS-RAhemnarchtektur zu beschäftigen. Dies schließt den Anwender-Support, das Benutzer-Feedback (Fehlermeldungen, Erweiterungen usw.) über die Internetseite und die Verwaltung derselben ein.

Zu diesem Zweck ist der Einsatz eines Issue-Trackers unerlässlich, in dem das Benutzer- Feedback und die Aufgaben dokumentiert und einzelnen Bearbeitern des AAS zugeordnet werden. Der für Benutzer transparente Umgang mit dem Feedback wurde mit Hilfe der Business Process Modelling Notation (BPMN 2.0 (26)) modelliert. Die dort abgebildeten Prozesse orientieren sich an der ISO 14817 (15). Zusätzlich zu den oben genannten Aufgaben führt der AAS alle erforderlichen technischen Arbeiten zur Unterstützung der laufenden Arbeiten aus. Begünstigt durch verteiltes Arbeiten auf einem gemeinsamen Datenbestand (z.B. SVN-Repository), ein definiertes Konfigurationsmanagement und Kommunikation über einen Emailverteiler, können die Sitzungen des AAS nach Bedarf stattfinden und auf ein Minimum reduziert werden. Natürlich muss eine Einigung darüber erzielt werden, wie das Hosting der Internetseite finanziert wird.

=== Entscheidungsfindung ===

Das Entscheidungsorgan im IVS-Rahmenarchitektur Prozess ist das Lenkungskomitee (LK). Es orientiert sich bei der Entscheidungsfindung prinzipiell am Leitbild des IVS-Rahmenarchitektur Prozesses. Um Entscheidungen über aufgeworfene Fragen im LK zu erreichen wird eine Abstimmung durchgeführt. Bei jedem Abstimmungs-Gegenstand hat jeder teilnehmende Interessensvertreter eine Stimme. Die Stimmen fehlender Interessenvertreter und Stimmenthaltungen haben keinen Einfluss auf den Ausgang der Abstimmung über ein Thema, es sei denn die Position der abwesenden Interessengruppe wurde dem LK zuvor mitgeteilt.

Ein abwesender Interessensvertreter kann dem LK seine Position vor der Abstimmung bekannt geben. Sie muss dem Vorsitzenden des LK in schriftlicher Form vorliegen. Der Vorsitzende des LK hat dafür zu sorgen, dass diese Position in der Abstimmung Berücksichtigung findet. Abstimmungen können auf zwei Arten geschehen:

*während eines Treffens des LK
*per E-Mail über den LK Email-Verteiler

Die Vorschläge sollten in einer Weise formuliert werden, dass folgende Wahloptionen möglich sind:

*Zustimmung,
*Ablehnung,
*Enthaltung.

Abwesende und Stimmenthaltungen werden nicht berücksichtigt und haben somit keinen Einfluss auf das Ergebnis der Abstimmung. Zur Erreichung der Beschlussfähigkeit für eine gültige Entscheidung des LK müssten jedoch mindestens 50% der verfügbaren Stimmen entweder als Zustimmung oder als Ablehnung abgegeben werden (d.h. die Mehrheit der LK Teilnehmer muss sich für eine bestätigte Position ausgesprochen haben). Ist eine Abstimmung unentschieden, wird eine erneute Abstimmung durchgeführt. Wenn diese zweite Abstimmung ebenfalls unentschieden ausfällt, gilt der Vorschlag als abgelehnt. Haben Erweiterungen der IVS-Rahmenarchitektur oder Problemlösungen des AAS zur Berücksichtigung von Änderungswünschen oder Behebung gemeldeter Fehler Auswirkungen auf die Abwärtskompatibilität zu einer vorherigen Version, beträgt die erforderliche Mehrheit im LK 75%. Wenn die erforderliche Mehrheit bezüglich einer Erweiterung/Änderung der IVS-Rahmenarchitektur erzielt ist, wird der AAS die Information über die angenommenen Änderungen auf der Website einstellen.

== Finanzierung des IVS-Rahmenarchitektur Prozesses ==

Letztendlich stellt sich nun die Frage, wer die oben dargestellten Aufgaben übernehmen soll/kann und wie dies finanziert werden kann. Würde niemand die Pflege IVS-Rahmenarchitektur übernehmen, würde sie verkümmern. Selbst wenn eine Finanzierung des Prozesses möglich wäre und auch eine ausreichende IVS-Architektur Kompetenz sichergestellt werden könnte, hätten die Anwender keine Sicherheit, ob IVS-Rahmenarchitektur (evtl. durch fehlende Akzeptanz) in Richtlinien und Produkten umgesetzt wird.

Es muss also geklärt werden, wer sich an den Kosten dieses Standardisierungsprozesses beteiligt bzw. Ressourcen für die Pflege des Standards bereitstellt, einhergehend mit der Frage nach den eigentlichen Nutznießern. Einerseits sind es die Städte und Kommunen, Bund und Länder, die als Anwender von diesem Prozess profitieren. Aber auch Hersteller haben ein Interesse daran, die Entwicklung voranzutreiben und den Nutzen, sich mit Vorsprung am Markt behaupten zu können.

Es wird empfohlen, dass der IVS-Rahmenarchitektur Prozess von den Interessengruppen gemeinsam betrieben wird. Die Finanzierung kann so auf mehreren Schultern verteilt werden z.B. durch Bereitstellung von freiwilligen Herstellerressourcen und eine finanzielle Unterstützung durch Anwender (z.B. über Projekte bzw. Erwerb der Produkte). Die Kosten des Prozesses können durch eine politische Förderung und eine Öffnung des Prozesses durch Beteiligung von sonstigen Interessenten (z. B. universitäre und außeruniversitäre Einrichtungen) zusätzlich vermindert werden.

Die Zusammenführung von IVS-Architektur Kompetenz der Entwickler und Praxiswissen der Anwender bringt für beide Seiten wesentlichen und in dieser Domäne bisher selten erreichten Nutzen; mündet sie auf der einen Seite in Realisierungssicherheit, auf der anderen Seite in Vertrauen und Anwenderakzeptanz gegenüber dem Standardisierungsobjekt. Ist letzteres erreicht wird die Motivation und die Bereitschaft einer direkten Rückkopplung im IVS-Rahmenarchitektur Prozess (Feedback) durch die Anwender maximiert.

Im Vergleich mit der Pflege von DATEX II (internationaler Prozess), der mit einem Aufwand von etwa 100 Mann-Wochen pro Jahr (entspricht ca. 300-400 T€) betrieben wird, kann man beim IVS-Rahmenarchitektur Prozess (nationaler Prozess) von einem Viertel dieser Kosten (75-100 T€) pro Jahr ausgehen.

== Fazit ==

Im Folgenden werden noch einmal die wichtigsten Aspekte der Handlungsempfehlung zusammengefasst:

Jeder lebendige Standard, so auch die IVS-Rahmenarchitektur, braucht einen lebendigen Pflegeprozess. Da dieser Prozess nicht von den Standardisierungsinstitutionen CEN, DIN oder DKE betrieben wird, muss er von den Stakeholdern, wie Anwender der öffentlichen Hand, Herstellern und sonstige Interessenten, betrieben werden, die damit einen Nutzen verbinden. Dabei kann der Prozess nur für alle zufriedenstellende Ergebnisse liefern, wenn auch alle Stakeholder aktiv teilnehmen.

Die Akzeptanz der IVS-Rahmenarchitektur wird gesteigert, wenn der Pflegeprozess für alle Stakeholder offen und transparent ist. Zudem braucht der Prozess paritätische Verhältnisse, um alle Interessen auszugleichen. Dies bedeutet zum einen ein gleichmäßiges Verhältnis von Stimmen im entscheidenden Gremium (hier Lenkungskomitee). Zum anderen müssen die Kosten für den Prozess von den Stakeholdern getragen werden, die auch einen Nutzen haben – dabei muss der Nutzen die Kosten natürlich substantiell übertreffen.

Für die Finanzierung des Prozesses gibt es dabei viele Möglichkeiten, die zu prüfen sind:

*Bereitstellung von personellen Ressourcen
*Finanzierung über den Verkauf von Produkten
*Finanzierung über (geförderte) Projekte
*Finanzielle Unterstützung durch die Politik

Insbesondere der letzte Aspekt ist von großer Bedeutung. Wenn die im IVS-Rahmenarchitektur Prozess gepflegten Standards einen übergeordneten Nutzen haben, sind auch die Träger übergeordneter Interessen potentielle (finanzielle) Unterstützer – speziell das BMVBS und DG MOVE (IVS-Architektur Deutschland, Implementierung der EU IVS Richtlinie, Umsetzung des Urban Mobility Action Plan). Generell scheint die Etablierung und Finanzierung des IVS-Rahmenarchitektur Prozesses zunächst schwierig zu sein, ist aber bei Prüfung aller Variablen durchführbar.

Datei:IVS-Anforderung-Template-Katalog 00-00-01.docx

2018-04-04T15:33:51Z

Scholtes: Scholtes lud eine neue Version von „Datei:IVS-Anforderung-Template-Katalog 00-00-01.docx“ hoch

Aufbau des Wikis

2018-03-13T10:45:41Z

Scholtes:

Das Wiki zur Beschreibung der IVS-Rahmenarchitektur für Deutschland sowie der IVS-Referenzarchitekturen für Verkehrsinformation Individualverkehr, zuständigkeitsübergreifendes Verkehrsmanagement und multimodale Reiseinformation ist wie folgt aufgebaut:

Im linken Teil jeder Seite befindet sich ein Menübaum, über den direkt zu den Hauptpunkten navigiert werden kann.

Der Menübaum enthält die folgenden Top-Level-Einträge:

'''Einleitung'''

Hier ist die grundsätzliche Aufgabenstellung für die Entwicklung einer IVS-Rahmenarchitektur sowie der gleichzeitig entwickelten IVS-Referenzarchitekturen beschrieben. Außerdem ist die Struktur dieses Wikis beschrieben.

'''IVS-Architektur - Einführung und Methodik'''

Dieses Kapitel gibt einen Überblick über die methodischen Grundlagen und Schlüsselbegriffe sowie über das TOGAF-basierte Vorgehensmodell. Die Beschreibungen der unter diesem Kapitel zusammengefassten Seiten eignen sich besonders, um einen Überblick über die zugrundeliegende Methodik zu erlangen.

'''IVS-Architektur 1.0'''

Hier sind die Endergebnisse der IVS-Rahmenarchitektur sowie der drei IVS-Referenzarchitekturen zusammengefasst. Für das Verständnis der IVS-Architektur 1.0 sind insbesondere die Beschreibungen im Untermenü ''Die sieben Basiskonzepte der IVS-Rahmenarchitektur'' wichtig.

'''Phasen und Schritte zur Entwicklung einer IVS-Architektur'''

Hier werden alle Phasen zur Entwicklung einer IVS-Architektur beschrieben. Die grundsätzlich von TOGAF vorgesehenen Phasen werden für die IVS-Architektur getailort. Außerdem werden Anleitungen zur Bearbeitung der Phasen, zu erstellende Artefakte sowie Empfehlungen für IVS-Referenzarchitekturen und IVS-Architekturen realer IVS-Dienste beschrieben.

'''Weiterentwicklung & Pflege der IVS-Architekturen 1.0''' Unter diesem Menüpunkt sind Vorschläge für die Weiterentwicklung und Pflege der IVS-Architekturen zusammengefasst.

Aufbau des Wikis

2018-03-13T10:45:16Z

Scholtes:

Das Wiki zur Beschreibung der IVS-Rahmenarchitektur für Deutschland sowie der IVS-Referenzarchitekturen für Verkehrsinformation Individualverkehr, zuständigkeitsübergreifendes Verkehrsmanagement und multimodale Reiseinformation ist wie folgt aufgebaut:

Im linken Teil jeder Seite befindet sich ein Menübaum, über den direkt zu den Hauptpunkten navigiert werden kann.

Der Menübaum enthält die folgenden Top-Level-Einträge:

'''Einleitung'''

Hier ist die grundsätzliche Aufgabenstellung für die Entwicklung einer IVS-Rahmenarchitektur sowie der gleichzeitig entwickelten IVS-Referenzarchitekturen beschrieben. Außerdem ist die Struktur dieses Wikis beschrieben.

'''IVS-Architektur - Einführung und Methodik'''

Dieses Kapitel gibt einen Überblick über die methodischen Grundlagen und Schlüsselbegriffe sowie über das TOGAF-basierte Vorgehensmodell. Die Beschreibungen der unter diesem Kapitel zusammengefassten Seiten eignen sich besonders, um einen Überblick über die zugrundeliegende Methodik zu erlangen.

'''IVS-Architektur 1.0'''

Hier sind die Endergebnisse der IVS-Rahmenarchitektur sowie der drei IVS-Referenzarchitekturen zusammengefasst. Für das Verständnis der IVS-Architektur 1.0 sind insbesondere die Beschreibungen im Untermenü '''Die sieben Basiskonzepte der IVS-Rahmenarchitektur''' wichtig.

'''Phasen und Schritte zur Entwicklung einer IVS-Architektur'''

Hier werden alle Phasen zur Entwicklung einer IVS-Architektur beschrieben. Die grundsätzlich von TOGAF vorgesehenen Phasen werden für die IVS-Architektur getailort. Außerdem werden Anleitungen zur Bearbeitung der Phasen, zu erstellende Artefakte sowie Empfehlungen für IVS-Referenzarchitekturen und IVS-Architekturen realer IVS-Dienste beschrieben.

'''Weiterentwicklung & Pflege der IVS-Architekturen 1.0'''
Unter diesem Menüpunkt sind Vorschläge für die Weiterentwicklung und Pflege der IVS-Architekturen zusammengefasst.

NavTree

2018-03-13T10:29:26Z

Scholtes:

<small>{{#tree:id=1| extensions=["persist"] |
*Einleitung
**[[Aufgabenstellung_der_IVS-Rahmen-_und_-Referenzarchitekturen| Aufgabenstellung]]
**[[Aufbau_des_Wikis| Aufbau des Wikis]]
*IVS-Architektur - Einführung und Methodik
**[[IVS-Architekturprinzipien | IVS-Architektur - Definition und Metamodelle]]
**[[IVS-Archtektur-Vorgehensmodell | Das TOGAF-basierte IVS-Architektur Vorgehensmodell]]
*[[IVS-Architektur 1.0]]
** Die IVS-Rahmenarchitektur 1.0
***[[Grundlegende IVS-Architekturkonzepte | Die sieben Basiskonzepte der IVS-Rahmenarchitektur]]
****[[IVS-Dienste-Konzept|Das IVS-Dienste- und IVS-Wertschöpfungs-Konzept]]
****[[IVS-Rollenkonzept|Das IVS-Rollen- und IVS-Akteurskonzept]]
****[[IVS-Geschäftsziele|Das Konzept zur Formulierung von IVS-Zielen und -Realisierungsvorstellungen]]
****[[IVS-Capibilities|Das IVS-Capability und -Zusammenarbeitskonzept]]
****[[Hilfsmittel,_Sichten_und_Werkzeuge_für_IVS-Geschäftsarchitektur|Hilfsmittel, Sichten und Werkzeuge für IVS-Geschäftsarchitektur]]
****[[IVS-Referenzmodelle_und_Werkzeuge_-_Datenarchitektur|IVS-Referenzmodelle und Werkzeuge - Datenarchitektur]]
****[[IVS-Referenzmodelle_und_Werkzeuge_-_Anwendungsarchitektur|IVS-Referenzmodelle und Werkzeuge - Anwendungsarchitektur]]
**[[IVS-Architekturbausteine | Die IVS-Architekturbausteine der IVS-Rahmenarchitektur 1.0 ]]
** Die drei IVS-Referenzarchitekturen
***[[IVS-Referenzarchitektur_Verkehrsinformation_Individualverkehr_1.0 | IVS-Referenzarchitektur Verkehrsinformation IV 1.0 ]]
***[[IVS-Referenzarchitektur_für_Zuständigkeitsübergreifendes_Verkehrsmanagement_1.0 | IVS-Referenzarchitektur zuständigkeitsübergreifendes VM 1.0 ]]
***[[IVS-Referenzarchitektur Multimodale Reiseinformation 1.0 ]]
*Phasen & Schritte zur Entwicklung einer IVS-Architektur
** [[Vorarbeiten | Vorbereitungsphase]]
** [[TOGAF-Phase A | A - Architekturvision]]
** [[TOGAF-Phase B | B - Geschäftsarchitektur]]
** [[TOGAF-Phase C | C - Informationssystemarchitektur]]
*** [[TOGAF-Phase C.1 | C.1 -Datenarchitektur ]]
*** [[TOGAF-Phase C.2 | C.2 - Anwendungsarchitektur ]]
**[[StepsIVS-Architektur D-H| Von der IVS-Rahmenarchitektur nicht abgedeckte TOGAF-Phasen]]
*** [[TOGAF-Phase D | D - Technologiearchitektur]]
*** [[TOGAF-Phasen E-H| TOGAF-Phasen E-H zur Umsetzung von IVS-Architekturen]]
**** [[TOGAF-Phase E | E - Möglichkeiten und Lösungen]]
**** [[TOGAF-Phase F | F - Migrations-Planung]]
**** [[TOGAF-Phase G | G - Steuerung der Einführung]]
**** [[TOGAF-Phase H | H - Architektur Änderungsmanagement]]
**** [[Requirements-Management#Requirements_Management_in_der_Phase_A_-_Architekturvision | Requirements Management]]
*[[Weiterentwicklung & Pflege der IVS-Architekturen 1.0]]
}}</small>

Datei:IVS-RA.EAP

2018-02-18T08:58:35Z

Scholtes: Scholtes lud eine neue Version von „Datei:IVS-RA.EAP“ hoch

Anleitung zur IVS-Datenarchitektur

2018-02-18T08:56:29Z

Scholtes:

== IVS-Datenarchitektur ==

In der Datenarchitektur werden die Daten mit ihren Beziehungen, die für die Durchführung der Geschäftsprozesse benötigt werden, identifiziert und beschrieben. Dies erfolgt in einem Modell und einer Darstellungsform, die stabil, vollständig, konsistent und für alle Beteiligten verständlich ist (vgl. Datenmodell). Die Informationsarchitektur repräsentiert Informationen, Informationsgruppen und deren Informationsbedürfnisse. Unter Informationsgruppen sind verschiedene Rollen zusammengefasst, die den gleichen Informationsbedarf haben (z. B. Controller).

== Historische Entwicklung ==

Im Laufe der vergangenen Jahre und Jahrzehnte wurden in den verschiedenen [[IVS-Dömänen|IVS-Domänen]] Schnittstellen zum Austausch von Daten entwickelt. Einige dieser Schnittstellenbeschreibungen enthalten explizite Datenbeschreibungen (z. T. in formalen Datenbeschreibungssprachen wie z. B. [https://de.wikipedia.org/wiki/Unified_Modeling_Language UML]), andere Schnittstellenbeschreibungen enthalten implizite Datenbeschreibungen (auch hier z. T. in formalen Datenbeschreibungssprachen).

Diese Standards sind unabhängig voneinander entstanden und für verschiedene Anwendungsbereiche konzipiert worden. Mittlerweile haben sich die Standards weiter entwickelt und überlappen sich zum Teil inhaltlich. Aufgrund der unterschiedlichen Anwendungsbereiche und je nach Zeitpunkt der Entstehung werden die Daten auf unterschiedlichen Abstraktionsniveaus beschrieben.

Mittlerweile existieren Anwendungen, die mit zwei oder mehr der domänenspezifischen Datenmodelle arbeiten. Da kein übergeordnetes Datenmodell existiert, müssen solche Anwendungen bisher die Abbildungen zwischen den Datenmodellen anwendungsspezifisch erarbeitet.

Ein wesentlicher Bestandteil verkehrsbezogener Daten ist der Ort, für den diese Daten gelten. Um die räumliche Gültigkeit von verkehrsbezogenen Daten beschreiben zu können, wurden verschiedene Verfahren (sogenannte Ortsreferenzierungssysteme bzw. englisch location referencing systems) entwickelt. Die domänenspezifischen Datenmodelle verwenden unterschiedliche, z. T. mehrere Ortsreferenzierungssysteme. Auch bei den Ortsreferenzierungssystemen besteht das Problem, dass die Konvertierung von Ortsreferenzen zwischen verschiedenen Systemen z. T. nicht möglich, oft jedoch aufwendig und fehleranfällig ist. Wie bei den domänenspezifischen Datenmodellen gibt es auch hier kein übergeordnetes System, in das alle Ortsreferenzierungssysteme ohne Weiteres eingebettet werden könnten.

== Zusammenhang zwischen Daten- und Anwendungsarchitektur ==

Das folgende Diagramm zeigt den Zusammenhang zwischen den Bausteinen aus der Daten- und der Anwendungsarchitektur: [[File:IVS-Informationssystemarchitektur.png|thumb|center|700px|IVS-Informationssystemarchitektur]]

IVS-Informationsobjekte sind in IVS-Datenmodellen enthalten. IVS-Datenmodelle verwenden IVS-Ortsreferenzierungen und werden in IVS-Schnittstellen verwendet. IVS-Schnittstellen sind in IVS-Anwendungen enthalten.

== IVS-Informationsobjekte ==

Ein IVS-Informationsobjekt enthält die semantische Bedeutung inhaltlich zusammengehöriger Informationen, die als Input bzw. Output eines Geschäftsprozessschrittes verwendet werden. Jede IVS-Architektur muss einen Katalog der verwendeten [[IVS-Informationsobjekt|IVS-Informationsobjekte]] erstellen. Um diesen Katalog sinnvoll erstellen zu können, wird aus dem Katalog der bestehenden IVS-Geschäftsprozesse ermittelt, welche Input- bzw. Output-Informationsobjekte zur Umsetzung dieser Geschäftsprozesse benötigt werden. Wenn der Katalog fertiggestellt ist, kann eine Matrix der Informationsobjekte/Geschäftsprozesse erstellt werden.

Der bereits vorausgefüllte Katalog der [[Media:IVS-Datenart-Katalog_Los1_00-00-01.docx|IVS-Informationsobjekte]] kann ebenfalls dazu verwendet werden. Dazu kann eine Kopie dieses Kataloges angelegt werden. In dieser Kopie sind dann die für die IVS-Architektur relevanten Informationsobjekte (durch Hinzufügen bzw. Löschen von Informationsobjekten) zu beschreiben.

Der Begriff des IVS-Informationsobjekts ist bewusst sehr allgemein gehalten. Es werden darunter nicht nur Daten, die zwischen technischen Systemen ausgetauscht werden, sondern auch Vereinbarungen, die zwischen Akteuren (Personen, Organisationen) ausgetauscht bzw. festgelegt werden (wie .z.B. Verträge) , verstanden.

== IVS-Datenmodelle ==

Ein IVS-Datenmodell besteht aus einer Sammlung von Informationsobjekten und einer Vorgabe, wie die semantischen Informationen der Informationsobjekte syntaktisch korrekt kodiert werden müssen. Jede IVS-Architektur muss einen Katalog der vorhandenen Datenmodelle erstellen. Der bereits vorausgefüllte Katalog der [[Media:IVS-Datenmodell-Katalog_Los1_00-00-01.docx|IVS-Datenmodelle]] kann dazu verwendet werden. Dazu kann eine Kopie dieses Kataloges angelegt werden. In dieser Kopie sind dann die für die IVS-Architektur relevanten Datenmodelle (durch Hinzufügen bzw. Löschen von Datenmodellen) zu beschreiben.

Jede IVS-Architektur muss eine Matrix erstellen, in der die Zuordnung zwischen Informationsobjekten und Datenmodellen beschrieben werden. Die bereits vorausgefüllte Matrix der [[Media:IVS-Informationsobjekte-Datenmodelle-Matrix_Los1_00-00-01.xlsx|IVS-Informationsobjekte-Datenmodelle]] kann dazu verwendet werden. Dazu kann eine Kopie dieser Matrix angelegt werden. In dieser Kopie sind dann die für die IVS-Architektur relevanten Informationsobjekte und Datenmodelle aufzunehmen und die Zuordnung zwischen Informationsobjekten und Datenmodellen zu beschreiben.

== IVS-Ortsreferenzierungssysteme ==

Ein IVS-Ortsreferenzierungssystem legt die Syntax und Semantik für ein Verfahren fest, mit dem geografische Orte auf der Erde oder speziell Positionen in bzw. Teile von Verkehrswegenetzen beschrieben werden können. Jede IVS-Architektur muss einen Katalog der vorhandenen Ortsreferenzierungssysteme erstellen. Der bereits vorausgefüllte Katalog der [[Media:IVS-Ortsreferenzierungs-Katalog_Los1_00-00-01.docx|IVS-Ortsreferenzierungen]] kann dazu verwendet werden. Dazu kann eine Kopie dieses Kataloges angelegt werden. In dieser Kopie sind dann die für die IVS-Architektur relevanten Ortsreferenzierungen (durch Hinzufügen bzw. Löschen von Ortsreferenzierungen) zu beschreiben.

Jede IVS-Architektur muss eine Matrix erstellen, in der die Zuordnung zwischen Datenmodell und Ortsreferenzen beschrieben werden. Die bereits vorausgefüllte Matrix der [[Media:IVS-Datenmodell-Ortsreferenzen-Matrix_00-00-01.xlsx|IVS-Datenmodell-Ortsreferenzen]] kann dazu verwendet werden. Dazu kann eine Kopie dieser Matrix angelegt werden. In dieser Kopie sind dann die für die IVS-Architektur relevanten Datenmodelle und Ortsreferenzierungen aufzunehmen und die Zuordnung zwischen Datenmodellen und Ortsreferenzierungen zu beschreiben.

----

[[Hauptseite|<< Zurück zur Hauptseite]]

Anleitung zur IVS-Anwendungsarchitektur

2018-02-18T08:55:41Z

Scholtes:

== Historische Entwicklung ==

Aufgrund der fehlenden IVS-Rahmenarchitektur und -Referenzarchitekturen gibt es im Bereich der Anwendungsarchitektur eine historisch gewachsene Situation aus Anwendungen, Services und Schnittstellen. Diese Situation ist sowohl im Gesamtbereich der Intelligenten Verkehrs-Systeme als auch in den einzelnen IVS-Domänen durch Zufälle und projektbedingte Notwendigkeiten ohne eine übergeordnete Planung bzw. Lenkung entstanden.

== Zusammenhang zwischen Daten- und Anwendungsarchitektur ==

Das folgende Diagramm zeigt den Zusammenhang zwischen den Bausteinen aus der Daten- und Anwendungsarchitektur: [[File:IVS-Informationssystemarchitektur.png|thumb|center|700px|IVS-Informationssystemarchitektur]]

IVS-Informationsobjekte sind in IVS-Datenmodellen enthalten. IVS-Datenmodelle verwenden IVS-Ortsreferenzierungen und werden in IVS-Schnittstellen verwendet. IVS-Schnittstellen sind in IVS-Anwendungen enthalten.

== IVS-Schnittstellen ==

Eine IVS-Schnittstelle ist eine Einrichtung zwischen Systemen, die der Verbindung und der Kommunikation zwischen diesen dient. Zu jeder IVS-Schnittstelle, die zum Austausch zwischen verschiedenen Systemen verwendet wird, existieren Schnittstellenspezifikationen, die in der Regel schriftlich festgelegt sind oder durch einen Standard vorgegeben werden. Jede IVS-Schnittstellenspezifikation besteht aus einem Protokoll, mit dem festgelegt wird, wie die Informationen ausgetauscht werden, und einem Datenmodell, mit dem festgelegt wird, welche Informationen ausgetauscht werden können. Bei allgemeinen und sehr "breit" ausgelegten Schnittstellen werden häufig noch zusätzliche Vereinbarungen getroffen, mit denen die tatsächlich ausgetauschten Informationen weiter spezifiziert werden bzw. mit denen Erweiterungen oder Abwandlungen der allgemein verfügbaren Schnittstellenspezifikation festgelegt werden.

== IVS-Anwendungen ==

IVS-Anwendungen sind Computerprogramme oder Systeme von Computerprogrammen, die genutzt werden, um nützliche Funktionen zu automatisieren bzw. computergestützt umzusetzen. Die technischen Aktivitäten eines IVS-Geschäftsprozesses werden in IVS-Anwendungen realisiert. Dabei kann eine Aktivität von einer oder mehreren IVS-Anwendungen realisiert werden. Es ist auch möglich, dass mehrere Aktivitäten eines IVS-Geschäftsprozesses in einer IVS-Anwendung realisiert werden.

Eine optimale Unterstützung von IVS-Geschäftsdiensten kann durch eine serviceorientierte Architektur (SOA) erreicht werden. Eine SOA ist ein Architekturmuster, bei dem Anwendungen über definierte Serviceschnittstellen miteinander kommunizieren. Aktuell sind die wenigsten IVS-Anwendungen mit einer serviceorientierten Architektur realisiert. Zukünftig sollen IVS-Anwendungen als Services in einer serviceorientierten Architektur entworfen und realisiert werden.

Der Zusammenhang zwischen Anwendungen und Services einerseits und Schnittstellen andererseits soll in [https://de.wikipedia.org/wiki/Komponentendiagramm Komponentendiagrammen] modelliert werden. Dabei werden Anwendungen und Services als Components und Schnittstellen als Interfaces dargestellt.

----

[[Hauptseite|<< Zurück zur Hauptseite]]

Anleitung zur IVS-Anwendungsarchitektur

2018-02-18T08:54:41Z

Scholtes:

== Historische Entwicklung ==

Aufgrund der fehlenden IVS-Rahmenarchitektur und -Referenzarchitekturen gibt es im Bereich der Anwendungsarchitektur eine historisch gewachsene Situation aus Anwendungen, Services und Schnittstellen. Diese Situation ist sowohl im Gesamtbereich der Intelligenten Verkehrs-Systeme als auch in den einzelnen IVS-Domänen durch Zufälle und projektbedingte Notwendigkeiten ohne eine übergeordnete Planung bzw. Lenkung entstanden.

== Zusammenhang zwischen Daten- und Anwendungsarchitektur ==

Das folgende Diagramm zeigt den Zusammenhang zwischen den Bausteinen aus der Daten- und Anwendungsarchitektur: [[File:IVS-Informationssystemarchitektur.png|thumb|center|700px|Informationsarchitektur]]

IVS-Informationsobjekte sind in IVS-Datenmodellen enthalten. IVS-Datenmodelle verwenden IVS-Ortsreferenzierungen und werden in IVS-Schnittstellen verwendet. IVS-Schnittstellen sind in IVS-Anwendungen enthalten.

== IVS-Schnittstellen ==

Eine IVS-Schnittstelle ist eine Einrichtung zwischen Systemen, die der Verbindung und der Kommunikation zwischen diesen dient. Zu jeder IVS-Schnittstelle, die zum Austausch zwischen verschiedenen Systemen verwendet wird, existieren Schnittstellenspezifikationen, die in der Regel schriftlich festgelegt sind oder durch einen Standard vorgegeben werden. Jede IVS-Schnittstellenspezifikation besteht aus einem Protokoll, mit dem festgelegt wird, wie die Informationen ausgetauscht werden, und einem Datenmodell, mit dem festgelegt wird, welche Informationen ausgetauscht werden können. Bei allgemeinen und sehr "breit" ausgelegten Schnittstellen werden häufig noch zusätzliche Vereinbarungen getroffen, mit denen die tatsächlich ausgetauschten Informationen weiter spezifiziert werden bzw. mit denen Erweiterungen oder Abwandlungen der allgemein verfügbaren Schnittstellenspezifikation festgelegt werden.

== IVS-Anwendungen ==

IVS-Anwendungen sind Computerprogramme oder Systeme von Computerprogrammen, die genutzt werden, um nützliche Funktionen zu automatisieren bzw. computergestützt umzusetzen. Die technischen Aktivitäten eines IVS-Geschäftsprozesses werden in IVS-Anwendungen realisiert. Dabei kann eine Aktivität von einer oder mehreren IVS-Anwendungen realisiert werden. Es ist auch möglich, dass mehrere Aktivitäten eines IVS-Geschäftsprozesses in einer IVS-Anwendung realisiert werden.

Eine optimale Unterstützung von IVS-Geschäftsdiensten kann durch eine serviceorientierte Architektur (SOA) erreicht werden. Eine SOA ist ein Architekturmuster, bei dem Anwendungen über definierte Serviceschnittstellen miteinander kommunizieren. Aktuell sind die wenigsten IVS-Anwendungen mit einer serviceorientierten Architektur realisiert. Zukünftig sollen IVS-Anwendungen als Services in einer serviceorientierten Architektur entworfen und realisiert werden.

Der Zusammenhang zwischen Anwendungen und Services einerseits und Schnittstellen andererseits soll in [https://de.wikipedia.org/wiki/Komponentendiagramm Komponentendiagrammen] modelliert werden. Dabei werden Anwendungen und Services als Components und Schnittstellen als Interfaces dargestellt.

----

[[Hauptseite|<< Zurück zur Hauptseite]]

Datei:IVS-Informationssystemarchitektur.png

2018-02-18T08:52:42Z

Scholtes:

Datei:Activities.png

2018-02-18T08:51:45Z

Scholtes:

Datei:Artifacts.png

2018-02-18T08:51:19Z

Scholtes:

Datei:Events.png

2018-02-18T08:50:55Z

Scholtes:

Datei:Gateways-english.png

2018-02-18T08:50:26Z

Scholtes:

Datei:Message flow.png

2018-02-18T08:49:44Z

Scholtes:

Datei:Sequence flow.png

2018-02-18T08:48:17Z

Scholtes:

Datei:ITS information system architecture.png

2018-02-18T08:47:58Z

Scholtes:

Datei:IVS-RA.EAP

2018-02-13T16:52:26Z

Scholtes: Scholtes lud eine neue Version von „Datei:IVS-RA.EAP“ hoch

Datei:Means concept.png

2018-02-13T16:51:36Z

Scholtes:

Datei:Ends concept.png

2018-02-13T16:51:11Z

Scholtes:

Datei:ITS value-creation network.png

2018-02-13T16:50:49Z

Scholtes:

Datei:ITS role concept.png

2018-02-13T16:50:21Z

Scholtes:

Datei:ITS pyramid.png

2018-02-13T16:49:58Z

Scholtes:

Datei:ITS information object.png

2018-02-13T16:49:31Z

Scholtes:

Datei:ITS business process.png

2018-02-13T16:49:04Z

Scholtes:

Datei:ITS service.png

2018-02-13T16:48:36Z

Scholtes:

Datei:ITS architecture.png

2018-02-13T16:48:03Z

Scholtes:

Datei:ITS requirement.png

2018-02-13T16:47:35Z

Scholtes:

Datei:ITS object of consideration.png

2018-02-13T16:46:58Z

Scholtes:

Datei:Phase-C application.png

2018-02-13T14:59:15Z

Scholtes:

Datei:Phase-C data.png

2018-02-13T14:58:29Z

Scholtes:

Datei:Phase-B english.png

2018-02-13T14:57:54Z

Scholtes:

Diskussion:IVS-Architektur - Einführung und Überblick

2018-02-09T14:29:30Z

Scholtes:

= Natalias Notizen: =

*Wiederholbare Definitionen sollen identisch sein (im Wortlaut und Format); evtl. einiges muss ins Glossar verschoben werden.
*Unter „siehe“ alle Literatur- und Kapitelhinweise überprüfen (im Bericht) oder siehe auch…
*Literatur, die ich selber hinzugefügt habe, ist hier: C:\Users\Romas\Documents\Literatur
*Englische und deutsche Version des Berichts sollte überprüft und verglichen werden, inbesondere das Literaturverzeichnis (ob die Literaturangaben stimmen).
*Wiki engl. u. deutsch vergleichen (Formatierung)
*Die Links von Zwischenberichten müssen überprüft werden

= Für Werner =

*IVS-Archtekturbausteine: Diagramme anpassen und ergänzen => erledigt
*IVS-Glossar: Links verändern mit Bezug auf die Architekturbausteine => erledigt
*<span style="display: inline !important; float: none; background-color: transparent; color: rgb(0, 0, 0); font-family: sans-serif; font-size: 13.93px; font-style: normal; font-variant: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: left; text-decoration: none; text-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;">Bestandteil der IVS-Architektur Version 1.0 </span>--> Ersetzen durch projektspezifsiche Lösung => erledigt
*Art der Informationsobjekte besser darstellen => erledigt
*Einleitung vorstrukturieren => erledigt
*Bericht revidieren => erledigt

= Für Hanfried: =

== Inhaltlich ==

Glossar Template

Denkansätze

0.9 ersetzen durch 1.0

== Seiten mit unschönen Überschriften: ==

#[http://wikiivs.albrechtconsult.com/index.php?title=PhaseA-Step2-Los3_ErfassungUndBeschreibungVonRollen http://wikiivs.albrechtconsult.com/index.php?title=PhaseA-Step2-Los3_ErfassungUndBeschreibungVonRollen] das habe ich zweimal korrigiert und nun sieht es komisch aus

== Seiten, die nicht im Bericht sind: ==

#[http://wikiivs.albrechtconsult.com/index.php?title=IVS-Rolle http://wikiivs.albrechtconsult.com/index.php?title=IVS-Rolle] '''operationalisiert''' ihre IVS-Fähigkeiten, IVS-Verantwortlichkeiten und Aufgaben in Form von '''Aktivitäten''', die mit den Aktivitäten anderer IVS-Rollen, die den '''IVS-Geschäftsprozess''' eines IVS-Dienstes bildet.--------- Der Satz ist schwierig zu verstehen.
#[http://wikiivs.albrechtconsult.com/index.php?title=ITS-Technologiearchitektur http://wikiivs.albrechtconsult.com/index.php?title=ITS-Technologiearchitektur] ich habe gesehen, dass die ganze Wiki Seite aus einer Definition besteht. Man kann vllt. diese in die Architekturbausteine hinzufügen.    [http://wikiivs.albrechtconsult.com/index.php?title=TOGAF-Phase_D http://wikiivs.albrechtconsult.com/index.php?title=TOGAF-Phase_D] ---- in dieser Tabelle findest du den Link.
#[http://wikiivs.albrechtconsult.com/index.php?title=Gap-Analyse_Anwendungsarchitektur http://wikiivs.albrechtconsult.com/index.php?title=Gap-Analyse_Anwendungsarchitektur]      [http://wikiivs.albrechtconsult.com/index.php?title=Roadmap_Anwendungsarchitektur http://wikiivs.albrechtconsult.com/index.php?title=Roadmap_Anwendungsarchitektur]            beide Seiten sind sehr kurz, wollte nur mal Bescheid geben.
#[http://wikiivs.albrechtconsult.com/index.php?title=Architektur-Roadmap http://wikiivs.albrechtconsult.com/index.php?title=Architektur-Roadmap]  statt eine Excel-Datei ist hier eine Word-Datei.
#[http://wikiivs.albrechtconsult.com/index.php?title=Roadmap_IVS-Architektur http://wikiivs.albrechtconsult.com/index.php?title=Roadmap_IVS-Architektur]        überprüfe bitte das Dokument <span style="color:#ff0000">die "Roadmap"</span>, ich bin mir nicht sicher, ob ich den Begriff mit dem richtigen Dokument verknüpft habe.
#Identifizierung von Institutionen/Unternehmen, '''auf die IVS-Architektur mit Auswirkungen auf die Zusammenarbeit mit <span style="color:#ff0000">den unmittelbar betroffenen</span> Institutionen/Unternehmen verbunden ist''', die aber nicht<span style="color:#ff0000">unmittelbar davon betroffen </span>sind ------ das widerspricht sich oder ich verstehe den Satz nicht? [http://wikiivs.albrechtconsult.com/index.php?title=Identifizierung_betroffener_Institutionen_und_Rahmenbedingungen&nbsp http://wikiivs.albrechtconsult.com/index.php?title=Identifizierung_betroffener_Institutionen_und_Rahmenbedingungen&nbsp];
#[http://wikiivs.albrechtconsult.com/index.php?title=IVS-Frameworks http://wikiivs.albrechtconsult.com/index.php?title=IVS-Frameworks]      hier ist ein Dokument, das im Wiki als '''<span style="color:#ff0000">"IVS-Aktionsplan Straße“</span> genannt wird. Aber in der PDF-Datei steht ein anderer Titel.'''
#[http://wikiivs.albrechtconsult.com/index.php?title=TOGAF-Phase_A&nbsp http://wikiivs.albrechtconsult.com/index.php?title=TOGAF-Phase_A&nbsp];        In der Tabelle gibt es Aufsetzen des IVS-Referenzarchitekturprojekts mit drei Komponenten. Ist deren Aufbau in Ordnung? vor allem meine ich den ersten Link: [http://wikiivs.albrechtconsult.com/index.php?title=PhaseA-Step1-Los2&nbsp http://wikiivs.albrechtconsult.com/index.php?title=PhaseA-Step1-Los2&nbsp];
#[http://wikiivs.albrechtconsult.com/index.php?title=Los1:_IVS-Rahmenarchitektur&nbsp http://wikiivs.albrechtconsult.com/index.php?title=Los1:_IVS-Rahmenarchitektur&nbsp];   kann das so bleiben?
#1) <span style="color:#ff0000">Wiederverwendung vor Kauf vor Erstellung</span>------- ist die Formulierung korrekt???         2).......<span style="color:#ff0000">zur </span>??? <span style="color:#ff0000">bereitgestellt werden</span>----hier fehlt ein Substantiv               [http://wikiivs.albrechtconsult.com/index.php?title=Katalog_IVS-Architekturprinzipien http://wikiivs.albrechtconsult.com/index.php?title=Katalog_IVS-Architekturprinzipien]
#[http://wikiivs.albrechtconsult.com/index.php?title=IVS-Architekturframeworks &nbsp http://wikiivs.albrechtconsult.com/index.php?title=IVS-Architekturframeworks    &nbsp]; die Seite ist leer.
#[http://wikiivs.albrechtconsult.com/index.php?title=PhaseA-Step1-Los3_AufsetzenArchitekturprojekt#Wichtige_Begriffe_und_Definitionen &nbsp http://wikiivs.albrechtconsult.com/index.php?title=PhaseA-Step1-Los3_AufsetzenArchitekturprojekt#Wichtige_Begriffe_und_Definitionen        &nbsp]; Abschnitte "<span class="mw-headline" id="wichtige_begriffe_und_definitionen">Wichtige Begriffe und Definitionen" und<span style="color:#ff0000">"</span></span><span class="mw-headline" id="kurzbeschreibung_der_ivs-dienste-kategorie"><span style="color:#ff0000">Kurzbeschreibung der IVS-Dienste-Kategorie"</span> wiederholen sich inhaltlich.</span>                                                                                                                                                 Derselbe Eintrag, den Satz verstehe ich nicht, den ersten Teil also: <span style="color:#ff0000">So ist das Zuständigkeitsübergreifende Verkehrsmanagement die Verkehrsbeeinflussung </span>durch vorab abgestimmte Strategien mit dem Ziel, die Verkehrsnachfrage und das Angebot an Verkehrssystemen '''über die Grenzen von hoheitlich eigenständigen Baulastträgern und Betreibern hinweg '''optimal aufeinander abzustimmen.                                                                                                                                                Erweiterung der eher einfachen Verkehrssteuerungsmethoden zu umfassenden, leistungsfähigen und auf der strategischen sowie taktischen Ebene arbeitenden Strategien des Verkehrsmanagements, welche die Verkehrssteuerung und die Reiseinformationen zur Beeinflussung des Verkehrsteilnehmers nutzen. <span style="color:#ff0000">strategische Ebenen der Strategien? ich verstehe das nicht.</span>
#[http://wikiivs.albrechtconsult.com/index.php?title=IVS-Capibilities http://wikiivs.albrechtconsult.com/index.php?title=IVS-Capibilities]  [http://wikiivs.albrechtconsult.com/index.php?title=IVS-Capability http://wikiivs.albrechtconsult.com/index.php?title=IVS-Capability]  <span style="color:#ff0000">Definition: </span>Unterschied bei den Verben<span style="color:#ff0000">"Sind" und "erfordern". </span>Welches ist denn richtig?
# <span style="color:#ff0000">UAP 1.2. und Vorgehensmodell.</span> Sollen sie gleich aufgebaut werden oder ? [http://wikiivs.albrechtconsult.com/index.php?title=IVS-Archtektur-Vorgehensmodell http://wikiivs.albrechtconsult.com/index.php?title=IVS-Archtektur-Vorgehensmodell][http://wikiivs.albrechtconsult.com/index.php?title=Los1:_UAP1.2_TOGAF_basiertes_Rahmenwerk http://wikiivs.albrechtconsult.com/index.php?title=Los1:_UAP1.2_TOGAF_basiertes_Rahmenwerk]
#[http://wikiivs.albrechtconsult.com/index.php?title=Datei:IVS-RA.eap&nbsp http://wikiivs.albrechtconsult.com/index.php?title=Datei:IVS-RA.eap&nbsp]; lies bitte, was oben steht.            diese Datei habe ich hier gefunden: [http://wikiivs.albrechtconsult.com/index.php?title=IVS-Glossar#Aktivit.C3.A4t http://wikiivs.albrechtconsult.com/index.php?title=IVS-Glossar#Aktivit.C3.A4t]
#[http://wikiivs.albrechtconsult.com/index.php?title=IVS-Glossar#Referenzarchitektur&nbsp http://wikiivs.albrechtconsult.com/index.php?title=IVS-Glossar#Referenzarchitektur&nbsp];       Hier sind Verweise auf  Referenzarchitektur, aber es gibt sie nicht. Dasselbe mit den Intelligenten Verkehrs-Systemen auf derselben Seite.
#[http://wikiivs.albrechtconsult.com/index.php?title=Vorarbeiten&nbsp http://wikiivs.albrechtconsult.com/index.php?title=Vorarbeiten&nbsp];         zwei Links in der Tabelle funktionieren nicht, sie sind rot.
#[http://wikiivs.albrechtconsult.com/index.php?title=IVS-Archtektur-Vorgehensmodell#Das_TOGAF-basierte_Rahmenwerk_f.C3.BCr_IVS-Architektur&nbsp http://wikiivs.albrechtconsult.com/index.php?title=IVS-Archtektur-Vorgehensmodell#Das_TOGAF-basierte_Rahmenwerk_f.C3.BCr_IVS-Architektur&nbsp];   [http://wikiivs.albrechtconsult.com/index.php?title=Vorarbeiten&nbsp http://wikiivs.albrechtconsult.com/index.php?title=Vorarbeiten&nbsp];      zwei identische Tabellen, jedoch mit ganz vielen Unterschieden. Wie muss die Tabelle aussehen? (Welche Variante, meine ich).
#Die DENM Nachrichten sind <span style="color:#ff0000">durch standardisiert (DURCH WAS?)</span> nach EN 302 637-3 V1.2.1 (ETSI 2014) und werden nur unter der Voraussetzung eines eintretenden Ereignisses generiert und versendet.  [http://wikiivs.albrechtconsult.com/index.php?title=Los2_Glossar http://wikiivs.albrechtconsult.com/index.php?title=Los2_Glossar]
#[http://wikiivs.albrechtconsult.com/index.php?title=Los3_Glossar &nbsp http://wikiivs.albrechtconsult.com/index.php?title=Los3_Glossar &nbsp]; hier gibt es die englische Übersetzung der Fachtermini nicht.
#[http://wikiivs.albrechtconsult.com/index.php?title=Los2_Glossar http://wikiivs.albrechtconsult.com/index.php?title=Los2_Glossar] hier auch.
#[http://wikiivs.albrechtconsult.com/index.php?title=Los3_IVS-Architekturprinzipien &nbsp http://wikiivs.albrechtconsult.com/index.php?title=Los3_IVS-Architekturprinzipien       &nbsp] die Tabelle ist kaputt. Das Literaturverzeichnis ist ohne Verweise im Text aufgebaut sowie bei Punkten 5 und 6 habe ich die Werke nirgendwo gefunden (weder im Internet noch im Citavi).
#'''In der genannten Tabelle:<span style="color:#ff0000">Diskussion der Auswirkungen von Strategien </span>oder '''<span style="color:#ff0000">Mittels der Diskussion der Auswirkungen   </span>ich kenne solche Formulierungen nicht.           Vielleicht: Diskussion von oder über usw.
#[http://wikiivs.albrechtconsult.com/index.php?title=Los4_Domäne &nbsp http://wikiivs.albrechtconsult.com/index.php?title=Los4_Dom%C3%A4ne  &nbsp]; wofür eine eigenständige Seite für ein Dokument? Das ist mit dieser Seite verknüpft: [http://wikiivs.albrechtconsult.com/index.php?title=Vorlage:Schnellzugriff http://wikiivs.albrechtconsult.com/index.php?title=Vorlage:Schnellzugriff]
#[http://wikiivs.albrechtconsult.com/index.php?title=IVS-Rollen_Los3 &nbsp http://wikiivs.albrechtconsult.com/index.php?title=IVS-Rollen_Los3  &nbsp]; auf dieser Seite sind <span style="color:#ff0000">viele rot markierte Seiten,</span> die nicht existieren.
#[http://wikiivs.albrechtconsult.com/index.php?title=Spezial:Verwaiste_Seiten&nbsp http://wikiivs.albrechtconsult.com/index.php?title=Spezial:Verwaiste_Seiten&nbsp];        ob man so lassen kann oder muss etwas gelöscht werden?
#[http://wikiivs.albrechtconsult.com/index.php?title=Kap._2_Identifizierung_der_Stakeholder http://wikiivs.albrechtconsult.com/index.php?title=Kap._2_Identifizierung_der_Stakeholder]    Muss ich diese Seite korrigieren?
#[http://wikiivs.albrechtconsult.com/index.php?title=PhaseA-Step2-Los3_ErfassungUndBeschreibungVonRollen&nbsp http://wikiivs.albrechtconsult.com/index.php?title=PhaseA-Step2-Los3_ErfassungUndBeschreibungVonRollen&nbsp];  '''<span style="color:#ff0000;">Hier müssen wir mal diskutieren, welche Rollen wir hier brauchen</span>---- gehört dieser Satz zum Text?                                   '''<span style="color:#ff0000;">Projekt Lena4ITS (FE 03.0484/2011/IRB Maßnahmen zur Gewährleistung der Interoperabilität zwischen öffentlichem Verkehrsmanagement und individuellen Navigationsdiensten) erarbeitet und evaluiert-----------------</span>gibt es ein Dokument dazu? Damit ich eine Fußnote machen kann.
#[http://wikiivs.albrechtconsult.com/index.php?title=Roadmap&nbsp http://wikiivs.albrechtconsult.com/index.php?title=Roadmap&nbsp];       die Seite ist nicht zu Ende geschrieben.

IVS-Capibilities

2018-02-09T14:23:12Z

Scholtes:

== Geschäftsfähigkeiten (Capabilities) in TOGAF ==

=== Capability-Definition ===

[[File:TMValueChainMitPyramiden.png|thumb|right|350px|IVS-Wertschöpfungskette für einen Verkehrsmanagement-Service]]

Mit '''Capability''' wird in TOGAF eine '''Fähigkeit''' bezeichnet, die eine Organisation, Person oder ein System besitzt. Capabilities werden mit allgemeinen bzw. übergeordneten Begriffen benannt und sind typischerweise eine Kombination von Menschen, Organisation, Prozessen und Technologie, um realisiert werden zu können.<span><ref>TOGAF® Version 9.1: The Open Group. Online verfügbar unter http://pubs.opengroup.org/architecture/togaf9-doc/arch/, zuletzt geprüft am 02.11.2017.</ref></span>

Von strategischer Bedeutung für jedes Unternehmen sind sog. '''Business Capabilities (Geschäfts-Fähigkeiten)'''. Sie kennzeichnen Eigenschaften einer Institution/eines Unternehmens, die unbedingt erforderlich sind, damit sie/es ihre/seine strategischen Ziele erreichen kann.

'''Capabilities ...'''

*sind die eigentlichen Bausteine für das Geschäft (Business) einer Institution/eines Unternehmens.
*repräsentieren stabile geschäftliche Funktionen.
*sind einzigartig und unabhängig voneinander.
*abstrahieren von der Organisation einer Institution/eines Unternehmens.
*repräsentieren letztlich das Geschäftsinteresse einer Institution/eines Unternehmens.

Das Besondere an Capabilities ist zum einen ihre Zeitstabilität, d.h. sie ändern sich sehr selten bzw. nur dann, wenn sich die strategische Ausrichtung einer Institution/eines Unternehmens ändert. Zum zweiten werden sie von der Fachseite erarbeitet und nicht wie oftmals üblich, von der IT-Seite diktiert. Insofern bilden sie eine Abstraktionsschicht zwischen Geschäfts- und IT-Prozessen.

=== Capability-Dimensionen ===

Wie nachfolgende Abbildung symbolisieren soll, wirkt sich die Schaffung von Capabilities in der Regel auf alle Ebenen (der IVS-Pyramide) einer Institution/eines Unternehmens aus. Dies wird mit den '''Dimensionen einer Capability''' bezeichnet und ist oft mit schwierigen Eingriffen in bestehende Unternehmens-/Institutions-Strukturen und mit entsprechenden, für die Beteiligten, oft schmerzhaften Veränderungsprozessen verbunden. Vor diesem Hintergrund müssen Fähigkeiten in konkreten Dimensionen strukturiert werden. D.h. es gibt übergeordnete Fähigkeiten, die wiederum andere Fähigkeiten erfordern. Fähigkeiten sollten nicht redundant sein.

[[File:Capa dimensions.png|thumb|center|400px|Capabilities: Ausprägung]]

== Übertragung des Capability-Konzepts auf IVS-Architektur ==

=== Einführung ===

[[File:IVSWertschöpfungsnetzwerk neu.png|thumb|right|150px|IVS-Wertschöpfungsnetzwerk]]

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

Dabei werden Anforderungen der End-Nutzer an den Nutzen von IVS-Diensten immer umfangreicher und komplexer. Daraus resultiert, dass die meisten IVS-Dienste nur über '''Kooperation''', d.h. die Vernetzung und das Zusammenwirken verschiedener IVS-Akteure mit ganz spezifischen Fähigkeiten und Nutzenbeiträgen entstehen können (siehe auch [[IVS-Rollenkonzept|IVS-Wertschöpfungs- und Rollenkonzept]]). Vor diesem Hintergrund gewinnt „die Kooperation von IVS-Akteuren“ für IVS immer mehr an Bedeutung. Alle Lösungen im Bereich von IVS, d.h. technische Produkte oder Dienstangebote etc., müssen im Grundsatz dem Anspruch genügen, dass sie auch als Bestandteil einer Wertschöpfungskette bzw. eines Wertschöpfungsnetzwerks darstellbar sind. Daraus muss hervorgehen, in welcher Beziehung die beteiligten IVS-Akteure in ihren Rollen zusammenarbeiten und welche Fähigkeiten sie in welchen Dimensionen entwickeln müssen, um den von ihnen erwarteten Nutzen bzw. Mehrwert bei der Wertschöpfung generieren zu können.

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

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

Ein Beispiel für das Segment "''IVS-Inhalteanbieter der IVS-Wertschöpfungskette für Zuständigkeitsübergreifendes Verkehrsmanagement"'' zeigt folgende Tabelle:

{| class="wikitable" style="width: 1260px;"
|+
|+
|-
! colspan="2" style="width: 723.88px;" | IVS-Capability
! colspan="3" style="width: 441.12px;" | Beteiligungen
! rowspan="2" | Abhängigkeit von anderen IVS-Capabilities
|-
| style="text-align: center;" | '''Bezeichnung'''
| style="width: 617.88px; text-align: center;" | '''Beschreibung'''
| style="width: 1px; text-align: center;" | '''Beteiligte IVS-Rollen'''
| style="text-align: center;" | '''Beteiligte IVS-Prozesse'''
| style="text-align: center;" | '''Beteiligte IVS-Anwendungsprozesse'''
|- style="vertical-align:top;"
| '''Gewinnung von Planungsdaten'''
| style="width: 617.88px;" | Durchgehende Planung und Versorgung von Versorgungsartefakten (digitale Straßenkarte, LCL-Liste, Versorgungslisten der Anlagen, etc.), die für zuständigkeitsübergreifendes Verkehrsmanagement erforderlich sind.
| style="width: 1px;" |
*Planungsverantwortliche der IVS-Akteure
*Versorgungsverantwortliche der öffentlichen und privaten IVS-Akteure

| Planungs- und Versorgungsprozesse der öffentlichen und privaten IVS-Akteure
| Planungs- und Versorgungsanwendungen wirken direkt auf eine Versorgungsdatenbank, in der mehrere (versionierte) Versorgungen gleichzeitig zur Verfügung gestellt werden. Dies erlaubt das Einspielen und systemweite Umschalten auf eine neue Versorgung im Onlinebetrieb.
!
|- style="vertical-align:top;"
| '''Erfassung und Sammlung von Realzeit-Daten und -Informationen'''
| style="width: 617.88px;" |
Auf Basis verschiedener Sensortypen und Erfassungsmethoden werden Daten in Real-Zeit erfasst:

*Verkehrsstärke und -geschwindigkeit, Belegungsgrad
*Trajektorien (Reisezeit je Reiseabschnitt
*Floating-Car-Daten

| style="width: 1px;" | Datenerfassungssysteme der öffentlichen und privaten IVS-Akteure
| Datenerfassungsprozesse der öffentlichen und privaten IVS-Akteure
|
|
|- style="vertical-align:top;"
| '''Erfassung von Ereignissen und Erkennung von Störungen'''
| style="width: 617.88px;" |
*Vorhersehbare Ereignisse (Baustellen, Veranstaltungen, Messen...)
*Unvorhersehbare Störungen im Netz (Unfälle, Naturereignisse...)

| style="width: 1px;" |
*<u>Ereignisse</u>: Baustellenmanagementsysteme, Redaktionsplätze, Ereigniskalender...
*<u>Störungen</u>: Automatische Systeme zur Erkennung von Störungen, Polizei, Staumelder...

|
*Ereignis-Erfassungsprozesse
*Störungs-Erkennungsprozesse

|
*Manuelle Ereignis-Erfassung (Redaktionsplatz)
*Automatische Ereignis-Erfassung (Event-Kalender)
*Manuelle Störungs-Erfassung (Polizei, Staumelder)
*Automatische Störungs-Erfassung (Incident-Detection-System)

| Erfassung und Sammlung von Echtzeit-Daten und -Informationen
|}

=== Interoperabilität als Schlüsseldimension der Kooperationsfähigkeit ===

[[File:IVS-Interoperabilität Horizontal.png|thumb|right|400px|Interoperabilität zwischen den Schichten der IVS-Architekturpyramide]]

Einer der Schlüssel für erfolgreiche Kooperation ist die '''Interoperabilität der beteiligten IVS-Akteure''' einer IVS-Wertschöpfungskette/eines IVS-Wertschöpfungsnetzwerks. Im IVS-Kontext bedeutet Interoperabilität die Fähigkeit voneinander unabhängiger IVS-Akteure, mit u.U. ganz heterogenen Strategien, Geschäftsprozessen, Informationsstrukturen und IT-Systemen in IVS-Wertschöpfungsketten im Sinne der Informationslogistik, möglichst nahtlos zusammenzuarbeiten, um Informationen auf effiziente und verwertbare Art und Weise auszutauschen und sie am Ende dem Benutzer zur Verfügung zu stellen.

Hier setzt das Interesse des IVS-Architekten und der IVS-Architektur ein. Der Begriff Interoperabilität darf nicht auf IT-Aspekte reduziert werden. Für den erfolgreichen Aufbau von IVS-Wertschöpfung muss Interoperabilität für alle Beteiligten nachvollziehbar auf allen Ebenen von IVS-Architektur hergestellt werden und durch entsprechende Architektur-Bausteine repräsentiert werden.

Als geeignetes Metamodell und methodisches Hilfsmittel zur überschaubaren und nachvollziehbaren Darstellung und Beschreibung von IVS-Diensten wird dem IVS-Architekten die [[IVS-Architekturprinzipien|'''IVS-Pyramide''']] vorgeschlagen. Im Kontext der Capability-Diskussion eignet sie sich besonders auch als Visualisierungsmodell für Interoperabilität auf allen Ebenen von IVS-Architektur.

=== Formen von Interoperabilität ===

Im IVS-Architekturkontext ist Interoperabilität ein Bestandteil von Verhalten auf den Ebenen von IVS-Architektur. Diesen Zusammenhang zeigt - mit den Darstellungsmitteln der IVS-Architekturpyramide - die obere Abbildung.

Interoperabilität wird sichtbar an Schnittstellen. Generell müssen dabei zwei folgende Formen von Interoperabilität unterschieden werden:

*'''Kommunikative Interoperabilität''': Kommunikatives Verhalten an Schnittstellen
*'''Verhaltens-Interoperabilität''': Funktionales Verhalten an Schnittstellen

Die '''kommunikative Interoperabilität''' eines IVS-Akteurs wird sichtbar am '''kommunikativen Verhalten''' an den Schnittstellen, die er anderen IVS-Akteuren auf den verschiedenen Ebenen für die Kooperation anbietet. Hier kommen in der Regel nationale und zukünftig immer mehr europäische bzw. internationale IVS-Normen und -Standards für Kommunikation und Daten zum Einsatz (siehe auch [[TOGAF-Phase_C|TOGAF Phase C – Informationssystem-Architektur ]])

Die '''Verhaltens-Interoperabilität''' eines IVS-Akteurs wird sichtbar am '''funktionalen Verhalten''' an den Schnittstellen, die er anderen IVS-Akteuren auf den verschiedenen Ebenen für die Kooperation anbietet. Es liegt in der Natur der Sache, dass für jede spezifische IVS-Domäne bzw. jeden spezifischen IVS-Dienst fachbezogen ganz unterschiedliche Verhaltens-Interoperabilitäten erforderlich sind. Aber auch hier kommen mehr und mehr nationale und auch europäische IVS-Richtlinien und Spezifikationen zum Einsatz.

Beispiele für funktionale Richtlinien und Spezifikationen im Sinne von IVS-Verhaltens-Interoperabilität:

*Technologiearchitekturen und Standards (z.B. ETSI-Standard)
*Europäische Implementierungsrichtlinien (z.B. EasyWay Deployment Guidelines)
*Übergreifend nutzbare IT-Services (z.B. der Deutsche National Access Point - MDM)
*Architekturmuster (z.B. Service Orientierte Architektur, SOA)
*Web Services und industrielle Standards (z.B. WSDL, WMS, WFS, XML, REST, JSON, WS-*)
*Geschäftsarchitekturmodelle aus IT-Service-Management-Frameworks (z.B. ITIL)
*Nationale Richtlinien und Standards (z.B. Neuversion der MARZ)

== Interoperabilität als Anforderung - Beispiel ==

[[File:CapabilityAlsAnforderung.PNG|thumb|right|180px|Interoperabilität als Anforderung]]

Bei der Entwicklung von IVS-Diensten ist grundsätzlich nicht davon auszugehen, dass die beteiligten IVS-Akteure - auch wenn sie vom Grundsatz her schon über die in Rede stehende Capability verfügen - von Hause aus interoperabel sind. Sind die entsprechenden Capability-Dimensionen für Interoperabilität noch nicht vorhanden, so kann man die zukünftig zu entwickelnden Capability-Dimensionen im Sinne von Requirements verstehen. Wie nebenstehende Abbildung symbolisieren soll, können diese Anforderungen Auswirkungen auf allen Ebenen von IVS-Architektur, und zwar an Schnittstellen nach Außen aber auch innerhalb der Organisation haben:

Als '''Beispiel''' sei die Kooperation einer Stadt mit einem privaten Navigationsdienstleister im Rahmen einer '''Alternativroutensteuerung''' genannt. Die Kooperationsvereinbarung enthält u.a. folgendes:

*die Stadt verpflichtet sich zur kostenpflichtigen Abnahme von FCD-Daten, die der private Navigationsdienstleister zur Verfügung stellen kann.
*als Gegenleistung verpflichtet sich der private Navigationsdienstleister, sich bei seinen Routenempfehlungen "strategiekonform" zu verhalten, das heißt die '''Capability "Strategiekonformes Routen"''' zu entwickeln.

Mit dieser Vereinbarung sind u.a. folgende Anforderungen an das Verhalten des Navigationsdienstleisters verbunden ('''Capability-Dimensionen'''):

;Strategie-Ebene...
:der Navigationsdienstleister muss seine Service-Strategie für seinen Kunden dahingehend anpassen, dass er seinen Kunden nicht grundsätzlich die individuell günstigste Route zu einem Ziel anbietet, sondern dass er die Routenempfehlungen der Stadt einbezieht, insbesondere Tempo-30-Zonen von der Routenempfehlung ausnimmt.
;Geschäftsprozess-Ebene...
:der Navigationsdienstleister muss seine Geschäftsprozesse auf die Kommunikation mit der Stadt hin ausbauen.
;Informationsstrukturen-Ebene...
:der Navigationsdienstleister muss seine Informationsstrukturen um das Datenmodell der Alternativroutenempfehlungen der Stadt erweitern. Auf der anderen Seite muss er ein Datenmodell für FCD-Daten entwickeln, das die Stadt verarbeiten kann.
;IT-Dienstestrukturen-Ebene...
:der Navigationsdienstleister muss neue IT-Dienste für den Austausch von Alternativrouten (Client-Service) und FCD-Daten (Server-Service) bereitstellen.
;IT-Infrastrukturen-Ebene...
:der Navigationsdienstleister muss eine permanente Netzverbindung mit der Stadt herstellen.
:

== Literaturverzeichnis ==

<references />

----

[[Hauptseite|<< Zurück zur Hauptseite]]

IVS-Capibilities

2018-02-09T14:22:32Z

Scholtes:

== Geschäftsfähigkeiten (Capabilities) in TOGAF ==

=== Capability-Definition ===

[[File:TMValueChainMitPyramiden.png|thumb|right|350px|IVS-Wertschöpfungskette für einen Verkehrsmanagement-Service]]

Mit '''Capability''' wird in TOGAF eine '''Fähigkeit''' bezeichnet, die eine Organisation, Person oder ein System besitzt. Capabilities werden mit allgemeinen bzw. übergeordneten Begriffen benannt und sind typischerweise eine Kombination von Menschen, Organisation, Prozessen und Technologie, um realisiert werden zu können.<span><ref>TOGAF® Version 9.1: The Open Group. Online verfügbar unter http://pubs.opengroup.org/architecture/togaf9-doc/arch/, zuletzt geprüft am 02.11.2017.</ref></span>

Von strategischer Bedeutung für jedes Unternehmen sind sog. '''Business Capabilities (Geschäfts-Fähigkeiten)'''. Sie kennzeichnen Eigenschaften einer Institution/eines Unternehmens, die unbedingt erforderlich sind, damit sie/es ihre/seine strategischen Ziele erreichen kann.

'''Capabilities ...'''

*sind die eigentlichen Bausteine für das Geschäft (Business) einer Institution/eines Unternehmens.
*repräsentieren stabile geschäftliche Funktionen.
*sind einzigartig und unabhängig voneinander.
*abstrahieren von der Organisation einer Institution/eines Unternehmens.
*repräsentieren letztlich das Geschäftsinteresse einer Institution/eines Unternehmens.

Das Besondere an Capabilities ist zum einen ihre Zeitstabilität, d.h. sie ändern sich sehr selten bzw. nur dann, wenn sich die strategische Ausrichtung einer Institution/eines Unternehmens ändert. Zum zweiten werden sie von der Fachseite erarbeitet und nicht wie oftmals üblich, von der IT-Seite diktiert. Insofern bilden sie eine Abstraktionsschicht zwischen Geschäfts- und IT-Prozessen.

=== Capability-Dimensionen ===

Wie nachfolgende Abbildung symbolisieren soll, wirkt sich die Schaffung von Capabilities in der Regel auf alle Ebenen (der IVS-Pyramide) einer Institution/eines Unternehmens aus. Dies wird mit den '''Dimensionen einer Capability''' bezeichnet und ist oft mit schwierigen Eingriffen in bestehende Unternehmens-/Institutions-Strukturen und mit entsprechenden, für die Beteiligten, oft schmerzhaften Veränderungsprozessen verbunden. Vor diesem Hintergrund müssen Fähigkeiten in konkreten Dimensionen strukturiert werden. D.h. es gibt übergeordnete Fähigkeiten, die wiederum andere Fähigkeiten erfordern. Fähigkeiten sollten nicht redundant sein.

[[File:Capa dimensions.png|thumb|center|400px|Capabilities: Ausprägung]]

== Übertragung des Capability-Konzepts auf IVS-Architektur ==

=== Einführung ===

[[File:IVSWertschöpfungsnetzwerk neu.png|thumb|right|150px|IVS-Wertschöpfungsnetzwerk]]

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

Dabei werden Anforderungen der End-Nutzer an den Nutzen von IVS-Diensten immer umfangreicher und komplexer. Daraus resultiert, dass die meisten IVS-Dienste nur über '''Kooperation''', d.h. die Vernetzung und das Zusammenwirken verschiedener IVS-Akteure mit ganz spezifischen Fähigkeiten und Nutzenbeiträgen entstehen können (siehe auch [[IVS-Rollenkonzept|IVS-Wertschöpfungs- und Rollenkonzept]]). Vor diesem Hintergrund gewinnt „die Kooperation von IVS-Akteuren“ für IVS immer mehr an Bedeutung. Alle Lösungen im Bereich von IVS, d.h. technische Produkte oder Dienstangebote etc., müssen im Grundsatz dem Anspruch genügen, dass sie auch als Bestandteil einer Wertschöpfungskette bzw. eines Wertschöpfungsnetzwerks darstellbar sind. Daraus muss hervorgehen, in welcher Beziehung die beteiligten IVS-Akteure in ihren Rollen zusammenarbeiten und welche Fähigkeiten sie in welchen Dimensionen entwickeln müssen, um den von ihnen erwarteten Nutzen bzw. Mehrwert bei der Wertschöpfung generieren zu können.

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

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

Ein Beispiel für das Segment "''IVS-Inhalteanbieter der IVS-Wertschöpfungskette für Zuständigkeitsübergreifendes Verkehrsmanagement"'' zeigt folgende Tabelle:

{| class="wikitable" style="width: 1260px;"
|+
|+
|-
! colspan="2" style="width: 723.88px;" | IVS-Capability
! colspan="3" style="width: 441.12px;" | Beteiligungen
! rowspan="2" | Abhängigkeit von anderen IVS-Capabilities
|-
| style="text-align: center;" | '''Bezeichnung'''
| style="width: 617.88px; text-align: center;" | '''Beschreibung'''
| style="width: 1px; text-align: center;" | '''Beteiligte IVS-Rollen'''
| style="text-align: center;" | '''Beteiligte IVS-Prozesse'''
| style="text-align: center;" | '''Beteiligte IVS-Anwendungsprozesse'''
|- style="vertical-align:top;"
| '''Gewinnung von Planungsdaten'''
| style="width: 617.88px;" | Durchgehende Planung und Versorgung von Versorgungsartefakten (digitale Straßenkarte, LCL-Liste, Versorgungslisten der Anlagen, etc.), die für zuständigkeitsübergreifendes Verkehrsmanagement erforderlich sind.
| style="width: 1px;" |
*Planungsverantwortliche der IVS-Akteure
*Versorgungsverantwortliche der öffentlichen und privaten IVS-Akteure

| Planungs- und Versorgungsprozesse der öffentlichen und privaten IVS-Akteure
| Planungs- und Versorgungsanwendungen wirken direkt auf eine Versorgungsdatenbank, in der mehrere (versionierte) Versorgungen gleichzeitig zur Verfügung gestellt werden. Dies erlaubt das Einspielen und systemweite Umschalten auf eine neue Versorgung im Onlinebetrieb.
!
|- style="vertical-align:top;"
| '''Erfassung und Sammlung von Realzeit-Daten und -Informationen'''
| style="width: 617.88px;" |
Auf Basis verschiedener Sensortypen und Erfassungsmethoden werden Daten in Real-Zeit erfasst:

*Verkehrsstärke und -geschwindigkeit, Belegungsgrad
*Trajektorien (Reisezeit je Reiseabschnitt
*Floating-Car-Daten

| style="width: 1px;" | Datenerfassungssysteme der öffentlichen und privaten IVS-Akteure
| Datenerfassungsprozesse der öffentlichen und privaten IVS-Akteure
|
|
|- style="vertical-align:top;"
| '''Erfassung von Ereignissen und Erkennung von Störungen'''
| style="width: 617.88px;" |
*Vorhersehbare Ereignisse (Baustellen, Veranstaltungen, Messen...)
*Unvorhersehbare Störungen im Netz (Unfälle, Naturereignisse...)

| style="width: 1px;" |
*<u>Ereignisse</u>: Baustellenmanagementsysteme, Redaktionsplätze, Ereigniskalender...
*<u>Störungen</u>: Automatische Systeme zur Erkennung von Störungen, Polizei, Staumelder...

|
*Ereignis-Erfassungsprozesse
*Störungs-Erkennungsprozesse

|
*Manuelle Ereignis-Erfassung (Redaktionsplatz)
*Automatische Ereignis-Erfassung (Event-Kalender)
*Manuelle Störungs-Erfassung (Polizei, Staumelder)
*Automatische Störungs-Erfassung (Incident-Detection-System)

| Erfassung und Sammlung von Echtzeit-Daten und -Informationen
|}

=== Interoperabilität als Schlüsseldimension der Kooperationsfähigkeit ===

[[File:IVS-Interoperabilität Horizontal.png|thumb|right|400px|Interoperabilität zwischen den Schichten der IVS-Architekturpyramide]]

Einer der Schlüssel für erfolgreiche Kooperation ist die '''Interoperabilität der beteiligten IVS-Akteure''' einer IVS-Wertschöpfungskette/eines IVS-Wertschöpfungsnetzwerks. Im IVS-Kontext bedeutet Interoperabilität die Fähigkeit voneinander unabhängiger IVS-Akteure, mit u.U. ganz heterogenen Strategien, Geschäftsprozessen, Informationsstrukturen und IT-Systemen in IVS-Wertschöpfungsketten im Sinne der Informationslogistik, möglichst nahtlos zusammenzuarbeiten, um Informationen auf effiziente und verwertbare Art und Weise auszutauschen und sie am Ende dem Benutzer zur Verfügung zu stellen.

Hier setzt das Interesse des IVS-Architekten und der IVS-Architektur ein. Der Begriff Interoperabilität darf nicht auf IT-Aspekte reduziert werden. Für den erfolgreichen Aufbau von IVS-Wertschöpfung muss Interoperabilität für alle Beteiligten nachvollziehbar auf allen Ebenen von IVS-Architektur hergestellt werden und durch entsprechende Architektur-Bausteine repräsentiert werden.

Als geeignetes Metamodell und methodisches Hilfsmittel zur überschaubaren und nachvollziehbaren Darstellung und Beschreibung von IVS-Diensten wird dem IVS-Architekten die [[IVS-Architekturprinzipien|'''IVS-Pyramide''']] vorgeschlagen. Im Kontext der Capability-Diskussion eignet sie sich besonders auch als Visualisierungsmodell für Interoperabilität auf allen Ebenen von IVS-Architektur.

=== Formen von Interoperabilität ===

Im IVS-Architekturkontext ist Interoperabilität ein Bestandteil von Verhalten auf den Ebenen von IVS-Architektur. Diesen Zusammenhang zeigt - mit den Darstellungsmitteln der IVS-Architekturpyramide - die obere Abbildung.

Interoperabilität wird sichtbar an Schnittstellen. Generell müssen dabei zwei folgende Formen von Interoperabilität unterschieden werden:

*'''Kommunikative Interoperabilität''': Kommunikatives Verhalten an Schnittstellen
*'''Verhaltens-Interoperabilität''': Funktionales Verhalten an Schnittstellen

Die '''Kommunikative Interoperabilität''' eines IVS-Akteurs wird sichtbar am '''kommunikativen Verhalten''' an den Schnittstellen, die er anderen IVS-Akteuren auf den verschiedenen Ebenen für die Kooperation anbietet. Hier kommen in der Regel nationale und zukünftig immer mehr europäische bzw. internationale IVS-Normen und -Standards für Kommunikation und Daten zum Einsatz (siehe auch [[TOGAF-Phase_C|TOGAF Phase C – Informationssystem-Architektur ]])

Die '''Verhaltens-Interoperabilität''' eines IVS-Akteurs wird sichtbar am '''funktionalen Verhalten''' an den Schnittstellen, die er anderen IVS-Akteuren auf den verschiedenen Ebenen für die Kooperation anbietet. Es liegt in der Natur der Sache, dass für jede spezifische IVS-Domäne bzw. jeden spezifischen IVS-Dienst fachbezogen ganz unterschiedliche Verhaltens-Interoperabilitäten erforderlich sind. Aber auch hier kommen mehr und mehr nationale und auch europäische IVS-Richtlinien und Spezifikationen zum Einsatz.

Beispiele für funktionale Richtlinien und Spezifikationen im Sinne von IVS-Verhaltens-Interoperabilität:

*Technologiearchitekturen und Standards (z.B. ETSI-Standard)
*Europäische Implementierungsrichtlinien (z.B. EasyWay Deployment Guidelines)
*Übergreifend nutzbare IT-Services (z.B. der Deutsche National Access Point - MDM)
*Architekturmuster (z.B. Service Orientierte Architektur, SOA)
*Web Services und industrielle Standards (z.B. WSDL, WMS, WFS, XML, REST, JSON, WS-*)
*Geschäftsarchitekturmodelle aus IT-Service-Management-Frameworks (z.B. ITIL)
*Nationale Richtlinien und Standards (z.B. Neuversion der MARZ)

== Interoperabilität als Anforderung - Beispiel ==

[[File:CapabilityAlsAnforderung.PNG|thumb|right|180px|Interoperabilität als Anforderung]]

Bei der Entwicklung von IVS-Diensten ist grundsätzlich nicht davon auszugehen, dass die beteiligten IVS-Akteure - auch wenn sie vom Grundsatz her schon über die in Rede stehende Capability verfügen - von Hause aus interoperabel sind. Sind die entsprechenden Capability-Dimensionen für Interoperabilität noch nicht vorhanden, so kann man die zukünftig zu entwickelnden Capability-Dimensionen im Sinne von Requirements verstehen. Wie nebenstehende Abbildung symbolisieren soll, können diese Anforderungen Auswirkungen auf allen Ebenen von IVS-Architektur, und zwar an Schnittstellen nach Außen aber auch innerhalb der Organisation haben:

Als '''Beispiel''' sei die Kooperation einer Stadt mit einem privaten Navigationsdienstleister im Rahmen einer '''Alternativroutensteuerung''' genannt. Die Kooperationsvereinbarung enthält u.a. folgendes:

*die Stadt verpflichtet sich zur kostenpflichtigen Abnahme von FCD-Daten, die der private Navigationsdienstleister zur Verfügung stellen kann.
*als Gegenleistung verpflichtet sich der private Navigationsdienstleister, sich bei seinen Routenempfehlungen "strategiekonform" zu verhalten, das heißt die '''Capability "Strategiekonformes Routen"''' zu entwickeln.

Mit dieser Vereinbarung sind u.a. folgende Anforderungen an das Verhalten des Navigationsdienstleisters verbunden ('''Capability-Dimensionen'''):

;Strategie-Ebene...
:der Navigationsdienstleister muss seine Service-Strategie für seinen Kunden dahingehend anpassen, dass er seinen Kunden nicht grundsätzlich die individuell günstigste Route zu einem Ziel anbietet, sondern dass er die Routenempfehlungen der Stadt einbezieht, insbesondere Tempo-30-Zonen von der Routenempfehlung ausnimmt.
;Geschäftsprozess-Ebene...
:der Navigationsdienstleister muss seine Geschäftsprozesse auf die Kommunikation mit der Stadt hin ausbauen.
;Informationsstrukturen-Ebene...
:der Navigationsdienstleister muss seine Informationsstrukturen um das Datenmodell der Alternativroutenempfehlungen der Stadt erweitern. Auf der anderen Seite muss er ein Datenmodell für FCD-Daten entwickeln, das die Stadt verarbeiten kann.
;IT-Dienstestrukturen-Ebene...
:der Navigationsdienstleister muss neue IT-Dienste für den Austausch von Alternativrouten (Client-Service) und FCD-Daten (Server-Service) bereitstellen.
;IT-Infrastrukturen-Ebene...
:der Navigationsdienstleister muss eine permanente Netzverbindung mit der Stadt herstellen.
:

== Literaturverzeichnis ==

<references />

----

[[Hauptseite|<< Zurück zur Hauptseite]]

IVS-Capibilities

2018-02-09T14:21:27Z

Scholtes:

== Geschäftsfähigkeiten (Capabilities) in TOGAF ==

=== Capability-Definition ===

[[File:TMValueChainMitPyramiden.png|thumb|right|350px|IVS-Wertschöpfungskette für einen Verkehrsmanagement-Service]]

Mit '''Capability''' wird in TOGAF eine '''Fähigkeit''' bezeichnet, die eine Organisation, Person oder ein System besitzt. Capabilities werden mit allgemeinen bzw. übergeordneten Begriffen benannt und sind typischerweise eine Kombination von Menschen, Organisation, Prozessen und Technologie, um realisiert werden zu können.<span><ref>TOGAF® Version 9.1: The Open Group. Online verfügbar unter http://pubs.opengroup.org/architecture/togaf9-doc/arch/, zuletzt geprüft am 02.11.2017.</ref></span>

Von strategischer Bedeutung für jedes Unternehmen sind sog. '''Business Capabilities (Geschäfts-Fähigkeiten)'''. Sie kennzeichnen Eigenschaften einer Institution/eines Unternehmens, die unbedingt erforderlich sind, damit sie/es ihre/seine strategischen Ziele erreichen kann.

'''Capabilities ...'''

*sind die eigentlichen Bausteine für das Geschäft (Business) einer Institution/eines Unternehmens.
*repräsentieren stabile geschäftliche Funktionen.
*sind einzigartig und unabhängig voneinander.
*abstrahieren von der Organisation einer Institution/eines Unternehmens.
*repräsentieren letztlich das Geschäftsinteresse einer Institution/eines Unternehmens.

Das Besondere an Capabilities ist zum einen ihre Zeitstabilität, d.h. sie ändern sich sehr selten bzw. nur dann, wenn sich die strategische Ausrichtung einer Institution/eines Unternehmens ändert. Zum zweiten werden sie von der Fachseite erarbeitet und nicht wie oftmals üblich, von der IT-Seite diktiert. Insofern bilden sie eine Abstraktionsschicht zwischen Geschäfts- und IT-Prozessen.

=== Capability-Dimensionen ===

Wie nachfolgende Abbildung symbolisieren soll, wirkt sich die Schaffung von Capabilities in der Regel auf alle Ebenen (der IVS-Pyramide) einer Institution/eines Unternehmens aus. Dies wird mit den '''Dimensionen einer Capability''' bezeichnet und ist oft mit schwierigen Eingriffen in bestehende Unternehmens-/Institutions-Strukturen und mit entsprechenden, für die Beteiligten, oft schmerzhaften Veränderungsprozessen verbunden. Vor diesem Hintergrund müssen Fähigkeiten in konkreten Dimensionen strukturiert werden. D.h. es gibt übergeordnete Fähigkeiten, die wiederum andere Fähigkeiten erfordern. Fähigkeiten sollten nicht redundant sein.

[[File:Capa dimensions.png|thumb|center|400px|Capabilities: Ausprägung]]

== Übertragung des Capability-Konzepts auf IVS-Architektur ==

=== Einführung ===

[[File:IVSWertschöpfungsnetzwerk neu.png|thumb|right|150px|IVS-Wertschöpfungsnetzwerk]]

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

Dabei werden Anforderungen der End-Nutzer an den Nutzen von IVS-Diensten immer umfangreicher und komplexer. Daraus resultiert, dass die meisten IVS-Dienste nur über '''Kooperation''', d.h. die Vernetzung und das Zusammenwirken verschiedener IVS-Akteure mit ganz spezifischen Fähigkeiten und Nutzenbeiträgen entstehen können (siehe auch [[IVS-Rollenkonzept|IVS-Wertschöpfungs- und Rollenkonzept]]). Vor diesem Hintergrund gewinnt „die Kooperation von IVS-Akteuren“ für IVS immer mehr an Bedeutung. Alle Lösungen im Bereich von IVS, d.h. technische Produkte oder Dienstangebote etc., müssen im Grundsatz dem Anspruch genügen, dass sie auch als Bestandteil einer Wertschöpfungskette bzw. eines Wertschöpfungsnetzwerks darstellbar sind. Daraus muss hervorgehen, in welcher Beziehung die beteiligten IVS-Akteure in ihren Rollen zusammenarbeiten und welche Fähigkeiten sie in welchen Dimensionen entwickeln müssen, um den von ihnen erwarteten Nutzen bzw. Mehrwert bei der Wertschöpfung generieren zu können.

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

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

Ein Beispiel für das Segment "''IVS-Inhalteanbieter der IVS-Wertschöpfungskette für Zuständigkeitsübergreifendes Verkehrsmanagement"'' zeigt folgende Tabelle:

{| class="wikitable" style="width: 1260px;"
|+
|+
|-
! colspan="2" style="width: 723.88px;" | IVS-Capability
! colspan="3" style="width: 441.12px;" | Beteiligungen
! rowspan="2" | Abhängigkeit von anderen IVS-Capabilities
|-
| style="text-align: center;" | '''Bezeichnung'''
| style="width: 617.88px; text-align: center;" | '''Beschreibung'''
| style="width: 1px; text-align: center;" | '''Beteiligte IVS-Rollen'''
| style="text-align: center;" | '''Beteiligte IVS-Prozesse'''
| style="text-align: center;" | '''Beteiligte IVS-Anwendungsprozesse'''
|- style="vertical-align:top;"
| '''Gewinnung von Planungsdaten'''
| style="width: 617.88px;" | Durchgehende Planung und Versorgung von Versorgungsartefakten (digitale Straßenkarte, LCL-Liste, Versorgungslisten der Anlagen, etc.), die für zuständigkeitsübergreifendes Verkehrsmanagement erforderlich sind.
| style="width: 1px;" |
*Planungsverantwortliche der IVS-Akteure
*Versorgungsverantwortliche der öffentlichen und privaten IVS-Akteure

| Planungs- und Versorgungsprozesse der öffentlichen und privaten IVS-Akteure
| Planungs- und Versorgungsanwendungen wirken direkt auf eine Versorgungsdatenbank, in der mehrere (versionierte) Versorgungen gleichzeitig zur Verfügung gestellt werden. Dies erlaubt das Einspielen und systemweite Umschalten auf eine neue Versorgung im Onlinebetrieb.
!
|- style="vertical-align:top;"
| '''Erfassung und Sammlung von Realzeit-Daten und -Informationen'''
| style="width: 617.88px;" |
Auf Basis verschiedener Sensortypen und Erfassungsmethoden werden Daten in Real-Zeit erfasst:

*Verkehrsstärke und -geschwindigkeit, Belegungsgrad
*Trajektorien (Reisezeit je Reiseabschnitt
*Floating-Car-Daten

| style="width: 1px;" | Datenerfassungssysteme der öffentlichen und privaten IVS-Akteure
| Datenerfassungsprozesse der öffentlichen und privaten IVS-Akteure
|
|
|- style="vertical-align:top;"
| '''Erfassung von Ereignissen und Erkennung von Störungen'''
| style="width: 617.88px;" |
*Vorhersehbare Ereignisse (Baustellen, Veranstaltungen, Messen...)
*Unvorhersehbare Störungen im Netz (Unfälle, Naturereignisse...)

| style="width: 1px;" |
*<u>Ereignisse</u>: Baustellenmanagementsysteme, Redaktionsplätze, Ereigniskalender...
*<u>Störungen</u>: Automatische Systeme zur Erkennung von Störungen, Polizei, Staumelder...

|
*Ereignis-Erfassungsprozesse
*Störungs-Erkennungsprozesse

|
*Manuelle Ereignis-Erfassung (Redaktionsplatz)
*Automatische Ereignis-Erfassung (Event-Kalender)
*Manuelle Störungs-Erfassung (Polizei, Staumelder)
*Automatische Störungs-Erfassung (Incident-Detection-System)

| Erfassung und Sammlung von Echtzeit-Daten und -Informationen
|}

=== Interoperabilität als Schlüsseldimension der Kooperationsfähigkeit ===

[[File:IVS-Interoperabilität Horizontal.png|thumb|right|400px|Interoperabilität zwischen den Schichten der IVS-Architekturpyramide]]

Einer der Schlüssel für erfolgreiche Kooperation ist die '''Interoperabilität der beteiligten IVS-Akteure''' einer IVS-Wertschöpfungskette/eines IVS-Wertschöpfungsnetzwerks. Im IVS-Kontext bedeutet Interoperabilität die Fähigkeit voneinander unabhängiger IVS-Akteure, mit u.U. ganz heterogenen Strategien, Geschäftsprozessen, Informationsstrukturen und IT-Systemen in IVS-Wertschöpfungsketten im Sinne der Informationslogistik, möglichst nahtlos zusammenzuarbeiten, um Informationen auf effiziente und verwertbare Art und Weise auszutauschen und sie am Ende dem Benutzer zur Verfügung zu stellen.

Hier setzt das Interesse des IVS-Architekten und der IVS-Architektur ein. Der Begriff Interoperabilität darf nicht auf IT-Aspekte reduziert werden. Für den erfolgreichen Aufbau von IVS-Wertschöpfung muss Interoperabilität für alle Beteiligten nachvollziehbar auf allen Ebenen von IVS-Architektur hergestellt werden und durch entsprechende Architektur-Bausteine repräsentiert werden.

Als geeignetes Metamodell und methodisches Hilfsmittel zur überschaubaren und nachvollziehbaren Darstellung und Beschreibung von IVS-Diensten wird dem IVS-Architekten die [[IVS-Architekturprinzipien|'''IVS-Pyramide''']] vorgeschlagen. Im Kontext der Capability-Diskussion eignet sie sich besonders auch als Visualisierungsmodell für Interoperabilität auf allen Ebenen von IVS-Architektur.

=== Formen von Interoperabilität ===

Im IVS-Architekturkontext ist Interoperabilität ein Bestandteil von Verhalten auf den Ebenen von IVS-Architektur. Diesen Zusammenhang zeigt - mit den Darstellungsmitteln der IVS-Architekturpyramide - die obere Abbildung.

Interoperabilität wird sichtbar an Schnittstellen. Generell müssen dabei zwei folgende Formen von Interoperabilität unterschieden werden:

*'''Kommunikative Interoperabilität''': Kommunikatives Verhalten an Schnittstellen
*'''Verhaltens-Interoperabilität''': Funktionales Verhalten an Schnittstellen

Die '''Kommunikative Interoperabilität''' eines IVS-Akteurs wird sichtbar am '''kommunikativen Verhalten''' an den Schnittstellen, die er anderen IVS-Akteuren auf den verschiedenen Ebenen für die Kooperation anbietet. Hier kommen in der Regel nationale und zukünftig immer mehr europäische bzw. internationale IVS-Normen und -Standards für Kommunikation und Daten zum Einsatz (siehe auch [[TOGAF-Phase_C|TOGAF Phase C – Informationssystem-Architektur ]])

Die '''Verhaltens-Interoperabilität''' eines IVS-Akteurs wird sichtbar am '''funktionalen Verhalten''' an den Schnittstellen, die er anderen IVS-Akteuren auf den verschiedenen Ebenen für die Kooperation anbietet. Es liegt in der Natur der Sache, dass für jede spezifische IVS-Domäne bzw. jeden spezifischen IVS-Dienst fachbezogen ganz unterschiedliche Verhaltens-Interoperabilitäten erforderlich sind. Aber auch hier kommen mehr und mehr nationale und auch europäische IVS-Richtlinien und Spezifikationen zum Einsatz.

Beispiele für funktionale Richtlinien und Spezifikationen im Sinne von IVS-Verhaltens-Interoperabilität:

*Technologiearchitekturen und Standards (z.B. ETSI-Standard)
*Europäische Implementierungsrichtlinien (z.B. EasyWay Deployment Guidelines)
*Übergreifend nutzbare IT-Services (z.B. der Deutsche National Access Point - MDM)
*Architekturmuster (z.B. Service Orientierte Architektur, SOA)
*Web Services und industrielle Standards (z.B. WSDL, WMS, WFS, XML, REST, JSON, WS-*)
*Geschäftsarchitekturmodelle aus IT-Service-Management-Frameworks (z.B. ITIL)
*Nationale Richtlinien und Standards (z.B. Neuversion der MARZ)

== Interoperabilität als Anforderung - Beispiel ==

[[File:CapabilityAlsAnforderung.PNG|thumb|right|180px|Interoperabilität als Anforderung]]

Bei der Entwicklung von IVS-Diensten ist grundsätzlich nicht davon auszugehen, dass die beteiligten IVS-Akteure - auch wenn sie vom Grundsatz her schon über die in Rede stehende Capability verfügen - von Hause aus interoperabel sind. Sind die entsprechenden Capability-Dimensionen für Interoperabilität noch nicht vorhanden, so kann man die zukünftig zu entwickelnden Capability-Dimensionen im Sinne von Requirements verstehen. Wie nebenstehende Abbildung symbolisieren soll, können diese Anforderungen Auswirkungen auf allen Ebenen von IVS-Architektur, und zwar an Schnittstellen nach Außen aber auch innerhalb der Organisation haben:

Als '''Beispiel''' sei die Kooperation einer Stadt mit einem privaten Navigationsdienstleister im Rahmen einer '''Alternativroutensteuerung''' genannt. Die Kooperationsvereinbarung enthält u.a. folgendes:

*die Stadt verpflichtet sich zur kostenpflichtigen Abnahme von FCD-Daten, die der private Navigationsdienstleister zur Verfügung stellen kann.
*als Gegenleistung verpflichtet sich der private Navigationsdienstleister, sich bei seinen Routenempfehlungen "strategiekonform" zu verhalten, das heißt die '''Capability "Strategiekonformes Routen"''' zu entwickeln.

Mit dieser Vereinbarung sind u.a. folgende Anforderungen an das Verhalten des Navigationsdienstleisters verbunden ('''Capability-Dimensionen'''):

;Strategie-Ebene...
:der Navigationsdienstleister muss seine Service-Strategie für seinen Kunden dahingehend anpassen, dass er seinen Kunden nicht grundsätzlich die individuell günstigste Route zu einem Ziel anbietet, sondern dass er die Routenempfehlungen der Stadt einbezieht, insbesondere Tempo-30-Zonen von der Routenempfehlung ausnimmt.
;Geschäftsprozess-Ebene...
:der Navigationsdienstleister muss seine Geschäftsprozesse auf die Kommunikation mit der Stadt hin ausbauen.
;Informationsstrukturen-Ebene...
:der Navigationsdienstleister muss seine Informationsstrukturen um das Datenmodell der Alternativroutenempfehlungen der Stadt erweitern. Auf der anderen Seite muss er ein Datenmodell für FCD-Daten entwickeln, das die Stadt verarbeiten kann.
;IT-Dienstestrukturen-Ebene...
:der Navigationsdienstleister muss neue IT-Dienste für den Austausch von Alternativrouten (Client-Service) und FCD-Daten (Server-Service) bereitstellen.
;IT-Infrastrukturen-Ebene...
:der Navigationsdienstleister muss eine permanente Netzverbindung mit der Stadt herstellen.
:

== Literaturverzeichnis ==

<references />

----

[[Hauptseite|<< Zurück zur Hauptseite]]

IVS-Geschäftsziele

2018-02-09T14:18:44Z

Scholtes:

== Einführung ==

[[File:Business-Motivation-Model-top.png|thumb|right|300px|Übersichtsdarstellung des BMM - Business Motivation Models]]

[[File:BMM.png|thumb|right|300px|Bestandteile des BMM - Business Motivation Models]]

Um die Diskussion über die Formulierung von '''Ziel- und Realisierungsvorstellungen für IVS-Dienste''' von vorneherein auf eine methodisch konsistente und für jeden nachvollziehbare Basis zu stellen, wird im Folgenden auf das [[Media:_Formal-15-05-20.pdf|'''Business Motivation Model''']] (BMM, Version 1.3)<ref>Specification formal/2015-05-20, 2015-05: Business Motivation Model. Online verfügbar unter http://www.omg.org/spec/BMM/1.3/, zuletzt geprüft am 24.10.2017.</ref> der [https://en.wikipedia.org/wiki/Business_Motivation_Model '''OMG - Open Management Group'''] zurückgegriffen.

Das BMM-Business Motivation Model (siehe nebenstehende Abbildung) beleuchtet die '''Anforderungen an das Business (Geschäft)''' eines Unternehmens/einer Organisation auf verschiedenen Ebenen, um gründlich und präzise zu erfassen und zu begründen:

*'''warum''' ein Unternehmen/eine Organisation '''handeln''' will (oder soll),
*'''worauf '''das Handeln abzielt und '''was am Ende erreicht werden soll''',
*'''wie''' ein Unternehmen/eine Organisation plant, '''dorthin zu kommen''' und
*'''wie''' ein Unternehmen/eine Organisation die erreichten '''Ergebnisse bewertet'''.

Für die Beschreibung des "Business" definiert und verwendet das BMM verschiedene Elemente (semantische Konzepte), die zueinander in Beziehung gesetzt werden. Die wichtigsten Elemente sind:

*'''Ends''': ''Was'' (im Gegensatz zu ''Wie'') das Unternehmen/die Organisation - am Ende - erreichen möchte.
*'''Means''': ''Wie'' - mit welchen (Hilfs-)Mitteln - das Unternehmen/die Organisation beabsichtigt, seine ''Ends'' zu erreichen.
*'''Directives''': Die ''Regeln ''und ''Grundsätze'', die die verfügbaren Means einschränken bzw. regulieren.
*'''Influencers''': ''Einflussfaktoren'', die Änderungen erforderlich machen, während ein Unternehmen/eine Organisation mit den Means oder der Erreichung der Ends befasst ist. Influencers sind per Definition neutral.
*'''Assessment''': Eine ''Beurteilung'' eines Influencers, der die Fähigkeit eines Unternehmens bei der Erreichung seiner Ends oder Anwendung seiner Means beeinflusst.

== Das Ends-Konzept (Formulierung von Zielvorstellungen) ==

=== Einführung ===

Im Kontext der Ziele-Diskussion für IVS-Dienste ist zunächst das '''Ends'''-Konzept von Bedeutung. Ends beschreiben, was ein Business (am Ende) sein will bzw. '''wo ein Business (am Ende) stehen will'''. Ends selber geben keine Auskunft darüber, wie sie erreicht werden sollen. Wenn wir den Business-Begriff auf den IVS-Dienst übertragen, d.h. '''wenn wir einen IVS-Dienst als Business begreifen und interpretieren''', hilft das Ends-Konzept, Ziele auf ihre Bedeutung hin semantisch zu differenzieren.

=== Ends-Kategorien ===

[[File:Ends-Konzept.jpg|thumb|right|400px|Ends-Konzept des Business Motivation Models]]

Wie nebenstehendes UML-Diagramm zeigt, sind Ends kategorisiert als '''Vision''' and '''Desired Results'''. Desired Results als '''Goals''' und '''Objectives'''.

*Eine '''Vision''' ist ein generelles Bild dafür, was ein Business zukünftig sein oder werden möchte. '''Hinweis''': das Business Motivation Model kann eingesetzt werden, auch wenn eine Vision nicht explizit festgelegt wurde.
*'''Desired Results (dts: gewünschte Ergebnisse)''', differenziert als '''Goals (dts: generelle Zielsetzung/Oberziel/Zweck)''' und '''Objectives (dts: messbare Einzelziele)''', sind spezifischer als Visionen:
**Ein '''Goal (dts: qualitatives Ziel)''' ist vom Wesen her eher langfristig ausgerichtet und eher qualitativ als quantitativ festgelegt. Es sollte jedoch gerade noch so zukunftsnah sein, dass dafür messbare Einzelziele definiert werden können.
**Ein '''Objective (dts: quantitatives Ziel)''' ist ein Schritt auf dem Weg hin zum generellen Ziel. Es quantifiziert ein Stück weit das generelle Ziel. Es muss mit einem End-Datum verknüpft sein und es müssen Kriterien festgelegt sein, um darüber feststellen zu können, ob es erreicht wurde oder nicht. Messbare Einzelziele bilden die messbare Grundlage dafür, ob ein Fortschritt in Richtung der Erfüllung der generellen Zielsetzung erreicht wurde.

=== Übertragung des Ends-Konzepts auf IVS ===

==== IVS-Visionen (BMM = Visions) ====

Jedes Unternehmen/jede Organisation hat natürlich Visionen, wo die Reise hingehen soll, d.h. wo das Unternehmen/die Organisation z. B. in zehn Jahren stehen will. Visionen sind aber '''oft nicht oder nur unscharf formuliert''' und treten in der Realität des Alltags oft in den Hintergrund. Für IVS allerdings haben Visionen eine große Bedeutung, weil IVS und IVS-Dienste im '''Kontext politischer und gesellschaftlicher Diskussionen über Verkehr, Transport und Mobilität eine große Rolle''' spielen.

'''Beispiele für IVS-Visionen''' für unterschiedliche IVS-Zielfelder zeigt folgende Tabelle:

{| class="wikitable"
|-
! IVS-Zielfeld
! IVS-Vision
|- style="vertical-align:top;"
| Sicherheit
| Unfallfreier Verkehr und Transport auf Bundesautobahnen
|- style="vertical-align:top;"
| Emissionen
| Emissionsfreier Verkehr und Transport bis zum Jahr 2050
|- style="vertical-align:top;"
| Mobilität
| Der informierte Reisende (zu jeder Zeit, an jedem Ort)
|}

==== Ergebnisse (Nutzen und Wirkung) von IVS-Diensten (BMM = Desired results) ====

Mit einem IVS-Dienst werden nicht nur Visionen, sondern '''stets auch konkrete Ziele''' verfolgt. Für das Engagement von IVS-Akteuren und IVS-Stakeholdern soll sich ein bestimmter '''Gegenwert in Form eines Ergebnisses (IVS-Nutzen/IVS-Wirkung)''' einstellen.

Grundsätzlich ist natürlich für jeden IVS-Dienst '''das große Ganze''', also der IVS-Nutzen und der damit verbundene Mehrwert für den späteren IVS-End-Nutzer '''im Fokus zu behalten''' und gemeinsam daraufhin zu arbeiten. IVS-Nutzen entsteht, wenn IVS-End-Nutzer oder IVS-End-Nutzerkollektive Zugriff auf IVS-Informationen haben, um eigene IVS-Entscheidungen sicher, zuverlässig, schnell und effektiv treffen zu können.

In Abhängigkeit der '''rechtlichen Ausgangssituation von IVS-Akteuren oder IVS-Stakeholdern''' (privat oder öffentlich rechtlich) werden generelle IVS-Zielsetzungen in der Regel ganz '''unterschiedlich und ggfs. auch konfliktär formuliert und interpretiert'''.

*Für '''privatwirtschaftlich finanzierte Unternehmen''' stehen bei der Zielformulierung der eigene Business Case und der mit einem IVS-Dienst oder der Konformität zu einer IVS-Architekturvorgabe verbundene wirtschaftliche Mehrwert für das Unternehmen im Vordergrund. Somit sind privatrechtliche Unternehmen naturgemäß eher auf den individuellen IVS-Nutzen von solchen Kunden ausgerichtet, die letztendlich bereit sind für den IVS-Dienst direkt oder indirekt zu bezahlen.

*Für '''steuer- oder gebührenfinanzierte Institutionen des öffentlichen Rechts''' steht bei der Zielformulierung die Umsetzung politischer Vorgaben und genereller gesellschaftspolitischer Ziele (Daseinsvorsorge) und der mit einem IVS-Dienst verbundene Mehrwert für ein End-Nutzer-Kollektiv im Vordergrund. Naturgemäß sind Institutionen des öffentlichen Rechts auf den kollektiven Nutzen der "Kunden" ausgerichtet, die Steuern zahlen.

Um privat- und steuer-/gebührenfinanzierte Nutzen von IVS-Diensten zu unterscheiden, werden die Begriffe '''IVS-Nutzen (privatfinanziert)''' und '''IVS-Wirkung (steuer- oder gebührenfinanziert)''' verwendet. IVS-Nutzen und IVS-Wirkung können als rein '''qualitative IVS-Ziele''' (BMM = Goals) formuliert werden und/oder als '''quantitative IVS-Ziele''' (BMM = Objectives) quantitativ messbar sein.

'''Beispiele für Qualitative und Quantitative IVS-Ziele''' zeigt folgende Tabelle:

{| class="wikitable"
|-
! IVS-Zielfeld
! IVS-Vision
! Qualitative IVS-Ziele (Goals)
! Quantitative IVS-Ziele (Objectives)
|- style="vertical-align:top;"
| Sicherheit
| Unfallfreier Verkehr und Transport auf Bundesautobahnen
|
*Reduzierung von Auffahrunfällen
*Reduzierung von Unfällen in Baustellen

|
*Reduzierung der Unfallhäufigkeit in Folge von Staus um X%
*Reduzierung der Unfälle mit LKW um X%
*Reduzierung von Folgeunfällen bei Stau um X%

|- style="vertical-align:top;"
| Emissionen
| Emissionsfreier Verkehr und Transport bis zum Jahr 2050
|
*Reduzierung des Energieverbrauchs
*Reduzierung der Schadstoffemissionen
*Reduzierung der Lärmbelastungen

|
*Kraftstoffverbrauch um X% reduzieren
*CO2-Ausstoß um X% reduzieren

|- style="vertical-align:top;"
| Mobilität
|
*Der informierte Reisende (zu jeder Zeit, an jedem Ort)
*Kontinuierliche Verbesserung des Modal Split von Pendlern

|
*Verbesserung der Nutzerfreundlichkeit bei der Anfrage von Reisealternativen der multimodalen Reiseplanung
*Aufklärung und Information der Reisenden

|
*Verkürzen der Latenzzeit von der Reiseanfrage bis zur Präsentation der Reiseroute auf < 5 Sekunden
*Umstieg von 10 % der bisherigen PKW-Fahrer auf ÖPNV

|}

Da IVS-Dienste in der Regel nur durch die Kooperation und Zusammenarbeit ganz unterschiedlicher IVS-Akteure entstehen, müssen sich diese letztendlich auf gemeinsame Ziele verständigen ('''Zwang zum Konsens''').

== Das Means-Konzept (Formulierung von Realisierungsvorstellungen) ==

=== Einführung ===

Ein (Hilfs-)Mittel repräsentiert jede Art von spezieller Fähigkeit, System, Technologie, Regelwerk, Instrument oder Methode etc., die in Anspruch genommen, aktiviert oder verstärkt werden kann, um Ziele (Ends) zu erreichen. (Hilfs-)Mittel sagen jedoch weder etwas über Schritte (Geschäftsprozesse und -abläufe) aus, die notwendig sind um sie zu nutzen, noch über Verantwortlichkeiten für solche Aufgaben, sondern lediglich über die Fähigkeiten, die mit den (Hilfs-)Mitteln verbunden sind und die einsetzbar sind, um die gewünschten Ergebnisse (Ends) zu erzielen.

Wenn man (Hilfs-)Mittel beschreibt, ist es auch nützlich zu dokumentieren, wer das (Hilfs-)Mittel zu welchem Zeitpunkt einsetzt, sodass für die Zukunft als Referenz ein Prüfpfad existiert.

=== Hilfs-(Mittel)-Kategorien ===

[[File:Means-Konzept.jpg|thumb|right|500px|Übersichtsdarstellung über das Means-Konzept des Business Motivation Models]]

Wie im nebenstehenden UML-Diagramm sichtbar lässt sich das (Hilfs-)Mittel-Konzept als Hierarchie darstellen und begreifen.

Insofern können (Hilfs-)Mittel sein:

*eine '''Mission''' (Handlungsoption, Aktion, Auftrag)
*:Eine '''Mission''' oder auch '''Handlungsoption''' bezeichnet, wie ihr Gegenstück '''Vision''', einen Langzeit-Ansatz, der auf die Erfüllung der Vision fokussiert ist. Wie die Vision ist die Mission nicht sehr spezifisch formuliert. Die Entscheidung für eine Handlungsoption sollte sich danach richten, wie Ressourcen, Fähigkeiten, Fertigkeiten und Kompetenzen, auf die ein Unternehmen/eine Organisation zurückgreifen kann, am besten genutzt werden können, um die formulierten Ziele auch tatsächlich zu erreichen.
*ein '''Handlungsmuster''' (strategisch oder taktisch)
*:In gewisser Weise, sind '''Handlungsmuster''' von grundsätzlicher Natur. Sie sind jedoch stumpfe Instrumente, wenn sie nicht durch entsprechende Direktiven gestützt werden, um eine reale Chance zu haben, erfolgreich zu sein.
*eine '''Direktive''' (Geschäftspolitik, Geschäftsregel)
*:Im Gegensatz zu Handlungsmustern, können '''Direktiven (Vorschriften und Richtlinien)''' nicht für sich alleine stehen. Vielmehr geben sie den Handlungsmustern den richtigen Schliff. Mit anderen Worten stellen sie sicher, dass Handlungsmuster in intelligenter Weise innerhalb von Grenzen angewendet werden, die für ein Unternehmen/eine Unternehmung akzeptabel bzw. optimal sind. Kurz formuliert, Direktiven repräsentieren das verschlüsselte (z.B. in schriftlicher Form dokumentierte) Wissen, das einem Handlungsmuster die Chance auf den höchstmöglichen Erfolg eröffnet.
*:Eine Direktive hat auch etwas zu tun mit Führung und Lenkung. Im Gegensatz dazu identifiziert ein Handlungsmuster den aktiven Ansatz auf dem Weg hin zu den Ends. Ein Handlungsmuster ist immer aktionsorientiert.

=== Übertragung des Means-Konzepts auf IVS ===

==== IVS-Missionen/IVS-Handlungsoptionen (BMM = Missions) ====

IVS-Missionen sind '''IVS-Handlungsoptionen''', die zum Ausdruck bringen, auf welche '''Art von IVS-Diensten in welcher Kombination''' man grundsätzlich zurückgreifen kann bzw. welche Art von IVS-Diensten in welcher Kombination am besten geeignet sind, um der mit der Vision formulierten Zielvorstellung näher zu kommen. Die Entscheidung für eine Art von IVS-Diensten bzw. Kombination von Diensten und ihre spezifische Ausgestaltung sollte sich danach richten, wie '''ganz aktuell z. B. finanzielle und personelle Ressourcen sowie Fähigkeiten, Fertigkeiten, Kompetenzen und Technologien am besten eingesetzt werden''', um die formulierten Ziele zu erreichen. IVS-Handlungsoptionen müssen jedoch einen als '''realistisch erachteten Zeithorizont''' haben. So sollten z. B. IVS-Dienste, die im betrachteten Zeitraum noch nicht die erforderliche Technologiereife erreicht haben, nicht als IVS-Handlungsoption in Erwägung gezogen werden.

Beispiele für IVS-Handlungsoptionen zeigt folgende Tabelle:

{| class="wikitable"
|-
! IVS-Zielfeld
! IVS-Vision
! IVS-Handlungsoption (Mission)
|- style="vertical-align:top;"
| Sicherheit
| Unfallfreier Verkehr und Transport
| Einsatz von Kooperativen IVS-Diensten mit hoher Sicherheitswirkung
|- style="vertical-align:top;"
| Emissionen
| Emissionsfreier Verkehr und Transport
|
*Einsatz von energieverbrauchsdämpfenden IVS-Diensten (ITS und C-ITS)
*Vermehrtes Feinstaubmanagement

|- style="vertical-align:top;"
| Mobilität
| Der informierte Reisende (jederzeit, an jedem Ort)
| Einsatz von in Realzeit arbeitenden multimodalen IVS-Informationsdiensten
|}

==== IVS-Handlungsmuster (BMM = Course of action) ====

'''IVS-Handlungsmuster''' geben vor, '''wie man bei der Wahl einer IVS-Mission/IVS-Handlungsoption am besten vorgeht'''. IVS-Handlungsmuster definieren, '''was zu tun ist''', aber '''nicht, wie gut etwas zu tun''' ist. IVS-Performance-Kriterien werden mit den Zielen formuliert, die durch Handlungsmuster unterstützt werden. IVS-Handlungsmuster zielen nicht immer unmittelbar auf die Erreichung von Ergebnissen. Manche sind sinnvoll, um andere IVS-Handlungsmuster zu ermöglichen.

IVS-Handlungsmuster werden unterschieden nach:

*'''IVS-Strategien...'''
**sind eher '''langzeitorientiert''' und '''breit''' angelegt.
**sind als Merkmale, die strategische Einflussfaktoren und Rahmenbedingungen repräsentieren, '''wesentlich für den Erfolg eines IVS-Handlungsmusters'''.
**legen für IVS-Handlungsmuster beste Vorgehensweisen, widerspruchsfreie Verhaltensmuster, Positionierungen und Sichtweisen der IVS-Akteure bei der Modellierung, Planung, Realisierung und dem Betrieb von Intelligenten Verkehrs-Systemen fest.
**sind Schlüsselfaktoren, die oftmals über '''Erfolg oder Misserfolg von IVS-Diensten''' entscheiden. Zu den strategischen Merkmalen gehören insbesondere Finanzierungskonzepte, aber oft auch zu schaffende rechtliche Rahmenbedingungen und technologische Voraussetzungen. Diese müssen frühzeitig identifiziert und realisiert werden, um von vorneherein die Machbarkeit von IVS-Diensten sicherzustellen.

*'''IVS-Taktiken...'''
**sind eher '''auf kurze Sicht angelegt.'''
**werden gewählt, um die gewünschten '''Ergebnisse auch bestmöglich sicherzustellen.'''
**können zur Implementierung mehrerer IVS-Strategien beitragen.

So wie IVS-Handlungsmuster mit den gewünschten Ergebnissen (IVS-Nutzen, IVS-Wirkung) eines IVS-Dienstes korrespondieren, sind '''IVS-Strategien''' auf die '''generelle Zielsetzung''' ausgerichtet. IVS-Taktiken werden hingegen gewählt, um die '''gewünschten Ergebnisse''' auch bestmöglich '''sicherzustellen''' (wobei dieser Zusammenhang nicht zwangsweise gilt). '''IVS-Strategien und IVS-Taktiken sind nicht scharf voneinander getrennt'''. Im Einzelfall muss jeder für sich entscheiden, nach welchen Kriterien er beide definiert.

'''Beispiele für IVS-Handlungsmuster''' zeigt folgende Tabelle:

{| class="wikitable"
|-
! rowspan="2" | IVS-Zielfeld
! rowspan="2" style="width: 438px;" | IVS-Handlungsoption (Mission)
! colspan="2" style="width: 1437px;" | '''IVS-Handlungsmuster'''
|- style="vertical-align:top;"
| style="width: 451px; text-align: center;" | '''IVS-Strategy (Strategy)'''
| style="width: 976px; text-align: center;" | '''IVS-Taktik (Tactics)'''
|- style="vertical-align:top;"
| Emissionen
| style="width: 438px;" |
*Implementierung von energieverbrauchsfreundlichen IVS-Diensten
*Einrichtung von (dynamischen) Umweltzonen (bei Feststellung erhöhter Werte werden Maßnahmen wie Fahrverbote o.ä. ergriffen)

| style="width: 451px;" |
*Vermeidung von Geschwindigkeitsschwankungen auf Fernstraßen
*Vermeidung von energieverschwenderischen Brems- und Anfahrverhalten an Lichtsignalanlagen
*...

| style="width: 976px;" |
*Vergleichmäßigung des Verkehrsablaufs auf Fernstraßen
*Vergleichmäßigung des Verkehrsablaufs auf lichtsignalgeregelten Knotenpunkten und Strecken

|- style="vertical-align:top;"
| Mobilität
| style="width: 438px;" |
*Implementierung von multimodalen, in Realzeit arbeitenden IVS-Diensten

| style="width: 451px;" |
*An jedem Ort zu jeder Zeit leicht zugängliche, personalisierte, kontextsensitive und verkehrsmittelneutrale Reiseinformation

| style="width: 976px;" |
*Angebot von Push-Diensten

|-
| Sicherheit
| style="width: 438px;" |
*Implementierung von IVS-Diensten mit hoher Sicherheitswirkung

| style="width: 451px;" |
Vermeidung staubedingter Unfälle

*Vermeidung von Staubildung
*Vorbeugung von Auffahrunfällen bei Stau
*...

Vermeidung von Unfällen an Baustellen

*Baustellen-Slotmanagement
*Baustellenwarnung
*...

| style="width: 976px;" |
*Vergleichmäßigung des Verkehrsablaufs
*Warnung von Stau(-Enden)
*Warnung an Unfallschwerpunkten (Baustellen, Glatteis ...)

|}

==== IVS-Richtlinien (IVS-Politik und IVS-Regeln) (BMM = Directives) ====

'''IVS-Richtlinien geben den IVS-Handlungsmustern sozusagen "die richtige Richtung"'''. Sie führen und lenken die Ausführung der IVS-Handlungsmuster nach politischen Vorgaben und anerkannten Regeln.

*Auf der einen Seite sind mit IVS-Richtlinien '''Einschränkungen''' verbunden. Durch Vorgabe von IVS-Richtlinien soll sichergestellt werden, dass IVS-Handlungsmuster - möglichst in intelligenter Weise - '''innerhalb vorgegebener Grenzen''' angewendet werden.

*Auf der anderen Seite repräsentieren IVS-Richtlinien das verschlüsselte, in der Regel in schriftlicher Form '''dokumentierte Wissen''', das einem '''Handlungsmuster die Chance auf den höchstmöglichen Erfolg''' eröffnet.

IVS-Richtlinien werden kategorisiert nach:

*'''IVS-Politik(-richtlinien''')
**Grundsätzlich ist es Aufgabe der (IVS)-Politik zu '''regulieren''', d.h. die Anwendung von IVS in Form politischer (auch gesetzlicher) Vorgaben zu regeln oder - mit anderen Worten ausgedrückt - '''zu steuern und zu führen''' und damit die angewandten IVS-Strategien und IVS-Taktiken zu gestalten.
**IVS-Politik legt fest, '''was getan werden darf, aber auch was getan werden muss''' und gibt an, wie oder '''in welchen Grenzen''' etwas getan werden kann.
**Im Vergleich zu IVS-Regeln ist '''IVS-Politik weniger strukturiert''' und auch weniger detailliert formuliert. '''IVS-Politik''' ist in diesem Sinne auch '''nicht direkt "ausführbar"'''.

*'''IVS-Regeln (auch IVS-Prinzipien)'''
**IVS-Regeln leiten sich von der IVS-Politik ab und sind '''ausführbare IVS-Richtlinien'''.
**Sie müssen auch als solche definiert sein und aus Konsistenz- und Vollständigkeitsgründen muss '''ihre Ausführung überwacht und überprüft''' werden.

'''Beispiele für IVS-Richtlinien''' zeigt folgende Tabelle:

{| align="center" class="wikitable"
|-
! rowspan="2" | IVS- Zielfeld
! colspan="2" style="width: 737px;" | '''IVS-Handlungsmuster (Course of actions)'''
! colspan="2" rowspan="1" style="width: 1139px;" | IVS-Direktive (Directive)
|- style="vertical-align:top;"
| style="width: 407.46px; text-align: center; vertical-align: middle;" | '''IVS-Strategie (Strategy)'''
| style="width: 327px; text-align: center; vertical-align: middle;" | <ul style="text-align: center;">
</ul>
<p style="text-align: center;">'''IVS-Taktik (Tactics)'''</p>
| style="width: 366px;" | <p style="text-align: center;">'''IVS-Politik (Business Policy)'''</p>
| style="width: 770px;" | <p style="text-align: center;">'''IVS-Regeln und IVS-Prinzipien (Business Rules)'''</p>
|- style="vertical-align:top;"
| Emissionen
| style="width: 407.46px;" |
*Vermeidung von Geschwindigkeitsschwankungen auf Fernstraßen
*Vermeidung von energieverschwenderischen Brems- und Anfahrverhalten an Lichtsignalanlagen
*...

| style="width: 327px;" |
*Vergleichmäßigung des Verkehrsablaufs auf Fernstraßen
*Vergleichmäßigung des Verkehrsablaufs auf lichtsignalgeregelten Knotenpunkten und Strecken
*...

| style="width: 366px;" |
*Verdichtung des Messstellennetzes
*Verdichtung von Anzeigequerschnitten an staugefährdeten Strecken
*Förderung (verstärkter Einsatz von) von Kooperativen Diensten (Unterstützung des Fahrers durch Fahrerassistenzsysteme)
*Verstärkter Einsatz von Grüne-Welle-Assistenten auf lichtsignalgeregelten Strecken

| style="width: 770px;" |
*Abstand zwischen Anzeigequerschnitten < 2 km
*"Vermeidung" vor "Warnung"
*Implementierung von Grüne-Welle-Assistenten ab einer Morgenspitze > X Kfz/h

|- style="vertical-align:top;"
| Mobilität
| style="width: 407.46px;" |
*Implementierung von multimodalen, in Realzeit arbeitenden IVS-Diensten
*...

| style="width: 327px;" |
*An jedem Ort zu jeder Zeit leicht zugängliche, personalisierte, kontextsensitive und verkehrsmittelneutrale Reiseinformation

| style="width: 366px;" |
*Open-Data Initiative

| style="width: 770px;" |
*Schnittstellen grundsätzlich als DATEX II-Profile

|-
| Sicherheit
| style="width: 407.46px;" |
Vermeidung staubedingter Unfälle

*Vermeidung von Staubildung
*Vorbeugung von Auffahrunfällen bei Stau
*...

Vermeidung von Unfällen an Baustellen

*Baustellenmanagement
*Baustellenwarnung
*...

| style="width: 327px;" |
*Vergleichmäßigung des Verkehrsablaufs
*Warnung von Stau(-Enden)
*Warnung an Unfallschwerpunkten (Baustellen, Glatteis ...)

| style="width: 366px;" |
*Verdichtung des Messstellennetzes
*Verdichtung von Anzeigequerschnitten an staugefährdeten Strecken
*Förderung (verstärkter Einsatz von) von Kooperativen Diensten (Unterstützung des Fahrers durch Fahrerassistenzsysteme)

| style="width: 770px;" |
*Abstand zwischen Anzeigequerschnitten < 2 km
*"Vermeidung" vor "Warnung"

|}

==  Literaturverzeichnis ==

<references />

[[Hauptseite|<< Zurück zur Hauptseite]]

IVS-Rollenkonzept

2018-02-09T14:13:31Z

Scholtes:

== Verwendete Architekturbausteine (siehe IVS-Begriffe & Definitionen)  ==

[[IVS-Architekturbausteine#IVS-Rolle...|IVS-Rolle]]

== TISA-Wertschöpfungskette als Einordnungshintergrund für IVS-Rollen ==

Als Ausgangspunkt für die Entwicklung des IVS-Rollen- und -Akteurskonzepts und die Einordnung der IVS-Rollen in Wertschöpfungsstufen wird das '''[[Media:_EO12013TISADefinition-ITS-value-chain20121018.pdf|TISA-Traffic and Travel Information Value Chain Modell]]'''<sup>[[Media:_EO12013TISADefinition-ITS-value-chain20121018.pdf|<ref>TISA (2012): Terms and Definitions for the Traffic and Travel Information Value Chain. Online verfügbar unter http://www.tisa.org/assets/Uploads/Public/EO12013TISADefinition-ITS-value-chain20121018.pdf, zuletzt geprüft am 18.10.2017.</ref>]]</sup> herangezogen, das von TISA speziell für die Darstellung und Beschreibung von Wertschöpfungsketten und -netzwerken für IVS-Verkehrsinformationsdienste entwickelt wurde und in folgender Abbildung dargestellt ist:

[[File:TISAValueChain.png|thumb|center|500px|TISA-Traffic und Travel Information Value Chain Model]]

Das Modell definiert auf der höchsten Ebene '''zwei Wertschöpfungssegmente''', nämlich dass '''Inhalte-Segment''' und das '''Dienste-Segment''' mit jeweils zwei, also insgesamt '''vier Wertschöpfungsstufen''', die typischerweise zum '''Aufbau einer IVS-Informationslogistikkette '''erforderlich sind:

*'''Inhalte-Segment '''(Content segment) mit:
**'''Inhalte-Erfassung''' (Content detection)
**'''Inhalte-Verarbeitung''' (Content processing)
*'''Dienste-Segment''' (Service segment) mit:
**'''Dienst-Bereitstellung''' (Service provision)
**'''Dienst-Darstellung''' (Service presentation)

== Metamodell für IVS-Rollen ==

=== Institutioneller Rollenmodell-Ansatz zur Verknüpfung von Akteurs-Sterotypen und Verhaltens-Stereotypen ===

Für die Definition und Beschreibung der für die einzelnen IVS-Wertschöpfungsstufen erforderlichen IVS-Rollen wird ein '''institutioneller Rollenmodell-Ansatz''' vorgeschlagen, der gemäß Schulz/Mainka/Joisten<sup><ref>Schulz, W.H.; Mainka, M.; Joisten, N. (2013): Entwicklung eines Konzeptes für institutionelle Rollenmodelle als Beitrag zur Einführung kooperativer Systeme im Straßenverkehr, Bergisch Gladbach.
Im Folgenden zitiert als: Schulz, W. H.; Mainka, M.; Joisten, N. (2013).</ref></sup> und [[Media:Detecon_buch_future_telco_iii_d_07_2016_0.pdf|Schulz/Wieker<sup><sub><ref>Schulz, Wolfgang H.; Wieker, Hors (2016): Co-operative Intelligent Transport Systems: Neue Markt-chancen durch den Systemverbund aus Automobil-und Telekommunikationsindustrie. In: Future Telco III, Powerplay für Telekommunikationsunternehmen, S. 138–147. Online verfügbar unter http://www.detecon.com/sites/default/files/detecon_buch_future_telco_iii_d_07_2016_0.pdf, zuletzt geprüft am 18.10.2017.</ref></sub></sup>]] im Wesentlichen auf den Grundlagen der Institutionenökonomik<sup><ref>Schneider, Dieter (1995): Betriebswirtschaftslehre. Grundlagen. 2. Aufl. (1). Online verfügbar unter https://www.amazon.de/Betriebswirtschaftslehre-Bd-1-Grundlagen-Dieter-Schneider/dp/3486234234, zuletzt geprüft am 18.10.2017</ref></sup>, der Systemtheorie<sup><ref>Luhmann, Niklas (2002): Einführung in die Systemtheorie. Heidelberg. Online verfügbar unter https://www.amazon.de/Einf%C3%BChrung-die-Systemtheorie-Dirk-Baecker/dp/3896702920, zuletzt geprüft am 18.10.2017.</ref></sup> und der Theorie der industrieökonomisch basierten System-Dynamics<sup><ref>Schulz, Wolfgang H. (2005): Application of System Dynamics to Empirical Industrial Organization – The Effects of the New Toll System. In: Jahrbuch für Wirtschaftswissenschaften/Review of Economics 56, S. 205–227.</ref></sup> basiert und der im Projekt [http://www.converge-online.de/ CONVERGE] für einen C-ITS Systemverbund angewendet wurde.

Institutionell heißt in diesem Kontext, dass für den Aufbau und den Betrieb einer IVS-Wertschöpfungskette notwendige '''IVS-Rollen anhand institutionalisierter (d.h. erwartbarer) Fähigkeiten und Verhaltensnormen charakterisiert''' werden.

Für den IVS-Architekt ist der institutionelle Rollenmodell-Ansatz von großem Vorteil, weil er sich beim Aufbau von Wertschöpfungsketten auf '''institutionalisierte Rollen (Akteurs-Stereotype) '''abstützen kann, von denen erwartet werden kann, dass sie sich nicht nur '''politisch, wirtschaftlich, operativ und technisch''' institutionalisiert verhalten ('''Verhaltens-Stereotype)''', sondern dass sie auch in Bezug auf ihre '''personellen, technischen und finanziellen Ressourcen sowie ihre Fertigkeiten''' mit entsprechenden institutionalisierten Fähigkeiten '''(Fähigkeits-Stereotype)''' ausgestattet sind.

Beispiele für institutionalisierte Rollen mit institutionalisiertem Verhalten zeigt folgende Tabelle:

{| border="1" cellpadding="1" cellspacing="1" style="width: 500px"
|-
| '''Akteurs-Stereotype'''
| '''Verhaltens-Stereotype'''
|-
| style="vertical-align: top" | Regierungen
| style="vertical-align: top" | machen Gesetze und schaffen rechtliche Rahmenbedingungen
|-
| style="vertical-align: top" | Straßenverkehrsbehörden
| style="vertical-align: top" | genehmigen und ordnen auf der Grundlage von Gesetzen und rechtlichen Rahmenbedingungen an
|-
| style="vertical-align: top" | Öffentliche Straßenbetreiber
| style="vertical-align: top" | steuern und managen den Verkehr auf kollektive Art und Weise
|-
| style="vertical-align: top" | Private Navigationsdienstleister
| style="vertical-align: top" | richten ihre Dienste vor dem Hintergrund der Erwirtschaftung von Gewinnen primär auf "zahlende" Kunden aus
|}
<div id="jsseunrwnoeo" style="display: none"><div class="simple_mutex" id="ocfipreoqyfb" style="display: none">mutex/ocfipreoqyfb/mutex</div> </div>
=== Regelnde und handelnde Institutionen ===

[[File:InstituitionellerAnsatz.png|thumb|right|304x188px|Institutioneller Rollenmodell-Ansatz]] Gemäß Schneider<ref>Schneider, Dieter (1995): Betriebswirtschaftslehre. Grundlagen. 2. Aufl. (1). Online verfügbar unter https://www.amazon.de/Betriebswirtschaftslehre-Bd-1-Grundlagen-Dieter-Schneider/dp/3486234234, zuletzt geprüft am 18.10.2017.</ref> werden Institutionen nach '''Regelsystemen (Ordnungen)''' und '''Handlungssystemen (Organisationen) '''differenziert:

*'''Regelsysteme''' umfassen als Institutionen "'''Rechtsrahmen, Verhaltensnormen und Gepflogenheiten" '''in Märkten und in anderen Organisationen als Bestandteile von Markt- und Unternehmensverfassungen, aber auch Organisationen, die Regelsysteme erstellen.
*'''Handlungssysteme''' umfassen handelnde Organisationen und setzen insofern immer '''handelnde Personen''' voraus. Diese Eigenschaft trennt das Handlungssystem vom Regelsystem.
<div id="jsseunrwnoeo" style="display: none"><div class="simple_mutex" id="ocfipreoqyfb" style="display: none">mutex/ocfipreoqyfb/mutex</div> </div>

=== Kategorien von IVS-Rollen ===

Unter Bezug auf das oben erläuterte Metamodell für IVS-Rollen differenziert "institutionelles" IVS-Rollenmodell drei Kategorien (Familien) von IVS-Rollen:

'''Regelnde IVS-Rollen''', die '''Regelsysteme '''schaffen, die für den Aufbau von IVS-Wertschöpfungsketten/-netzwerken und den Betrieb von IVS-Diensten erforderlich sind:

*Normative Regelungen (rechtlich, technisch)
*Wirtschaftliche Rahmenbedingungen (Förderung)
*Politische Rahmenbedingungen

Diese Rollen werden in der Regel von politischen, parlamentarischen, rechtsprechenden und nachgelagerten ausführenden Institutionen eingenommen.

'''Operativ handelnde IVS-Rollen''', die in '''Handlungssystemen''' von IVS-Diensten Verantwortung tragen, und von denen erwartet wird, dass sie bei der Entwicklung, Einführung und im operativen Betrieb von IVS-Diensten handeln. Hier werden IVS-Rollen wie folgt unterschieden:

*'''Ökonomische IVS-Rollen''' (Governance von IVS-Diensten) mit folgenden Verantwortlichkeiten und Aufgaben:
**Entwicklung der IVS-Ziel- und -Realisierungsvorstellungen eines IVS-Dienstes sowie der IVS-Strategie zur Zielerreichung
**Schaffung der notwendigen vertraglichen und finanziellen Grundlagen für die Entwicklung, die Implementierung und den Betrieb eines IVS-Dienstes
**Bereitstellung der administrativen und betrieblichen Ressourcen für das Management und den Betrieb eines IVS-Dienstes
**Management und Controlling (der Wertschöpfung) eines IVS-Dienstes während des Betriebs
**Schaffung der notwendigen technischen Rahmenbedingungen (technische Standards, notwendige IT und Infrastruktur ...) für den Betrieb des IVS-Dienstes.
*'''Technische IVS-Rollen''' (Betrieb eines IVS-Dienstes) mit der Verantwortlichkeit und den Aufgaben für den operativen Betrieb eines IVS-Dienstes.

Ökonomische und technische Rollen werden in der Regel von Institutionen der Wirtschaft und der Öffentlichen Verwaltung eingenommen.

== Wertigkeiten von IVS-Rollen (Power-Grid) ==

[[File:Power Grid zur Stakeholderanalyse Konsortium MRK-AMADEUS.JPG|thumb|right|300px|Power Grid zur Stakeholderanalyse Konsortium MRK-AMADEUS]]

'''IVS-Rollen haben unterschiedliche Wertigkeiten''' in Bezug auf das Zustandekommen und für den Betrieb eines IVS-Dienstes. Das '''Rollen-Power-Grid Modell''' der Open Group unterscheidet vier unterschiedliche Wertigkeiten (siehe nebenstehendes Bild).

*'''IVS-Schlüsselrollen''' (Power Grid D: Key-Players)
**sind die, die für das Zustandekommen von IVS-Diensten unbedingt erforderlich sind und die an der Wertschöpfung im operativen Betrieb von IVS-Diensten direkt beteiligt sind.
*'''Involvierte IVS-Rollen''' (Power Grid C: Keep satisfied)
**IVS-Rollen, die zwar nicht direkt an der Wertschöpfung eines IVS-Dienstes beteiligt sind, für die der IVS-Dienst aufgrund einer Zusammenarbeit mit den IVS-Schlüsselrollen jedoch mit direkten Auswirkungen verbunden ist.
*'''Interessierte IVS-Rollen''' (Power Grid B: Keep informed)
**Interessengruppen, die als Interessengemeinschaft von IVS-Diensten betroffen sind.
*'''Sonstige IVS-Rollen''' (Power Grid A: Minimal Effort)
**IVS-Rollen, die am Rande beteiligt sind, auf die der IVS-Dienst aber weder eine Auswirkung hat noch mit einem Interesse verbunden ist.

== Stereotype von IVS-Akteuren bzw. IVS-Akteure als Instanzen von IVS-Rollen ==

Im konkreten Fall werden '''IVS-Rollen von IVS-Akteuren eingenommen'''. Bei '''IVS-Referenzarchitekturen''' handelt es sich um '''Stereotype von IVS-Akteuren''' (z. B. Öffentlicher Straßenbaulastträger, Öffentlicher Straßenbetreiber, Verkehrsunternehmen, Navigationsdienstleister etc. (siehe auch [[IVS-Rollenkonzept#Stereotypen_von_IVS-Akteuren_als_Instanzen_von_IVS-Rollen|Stereotype von IVS-Akteuren als Instanzen von IVS-Rollen]])), bei der '''IVS-Architektur für einen realen IVS-Dienst''' um '''konkrete Instanzen der Stereotype von IVS-Akteuren''' (z. B. Tiefbauamt der Stadt X, Amt für Verkehrsmanagement der Stadt X, Verkehrsunternehmen der Stadt X, TomTom, INRIX, GARMIN, Google, HERE ...).

== IVS-Rollen in IVS-Wertschöpfungsketten/-netzwerken ==

=== Sichten als Grundlage für die Differenzierung von Rollen ===

Vor dem oben dargestellten Hintergrund leiten sich die für den Aufbau und Betrieb von IVS-Diensten erforderlichen Rollen durch drei ganz unterschiedliche Sichten auf die IVS-Wertschöpfungskette/das IVS-Wertschöpfungsnetzwerk bzw. ihre einzelnen Stufen ab:

*die '''hoheitliche''' Sicht: Hoheitliche IVS-Rollen
*die '''ökonomische''' Sicht: Ökonomische IVS-Rollen
*die '''technische''' Sicht: Technische IVS-Rollen

=== IVS-Rollen mit hoheitlicher Sicht: Schaffung hoheitlicher IVS-Regeln und -Rahmenbedingungen ===

[[File:RegelndeRollen.png|thumb|right|304x188px|Rollen mit hoheitlicher Sicht]]

*'''Gesetzgebende IVS-Rollen...'''
**Parlamentarische Institutionen, die als gesetzgebende Gewalt rechtlich und technisch normative Regeln- und Rahmenbedingungen schaffen.
*'''Rechtsprechende IVS-Rollen...'''
**Gerichtliche Institutionen, die im Falle von Meinungsverschiedenheiten und Konflikten Recht sprechen.
*'''Ausführende IVS-Rollen...'''
**Regierungsinstitutionen und öffentliche Verwaltungen, die gesetzliche Vorgaben ausführen/umsetzen.
*'''Politische IVS-Rollen...'''
**Institutionen der Politik, die politisch motivierte rechtliche und wirtschaftliche Rahmenbedingungen durch die Meinungsbildung und durch das Einbringen von Gesetzen (z. B. Förderung von IVS oder C-ITS) schaffen.

=== IVS-Rollen mit ökonomischer Sicht: Management von IVS-Wertschöpfungsstufen ===

[[File:ÖkonomischeRollen.png|thumb|right|304x188px|Rollen mit ökonomischer Sicht]]

Als Vorschlag für ein Ökonomisches IVS-Rollenmodell wird ein Modell von Schulz<ref>Schulz, W. H.; Mainka, M.; Joisten, N. (2013).</ref> herangezogen, das die klassischen betriebswirtschaftlichen Rollen '''durch spezifische, ''''''durch die Wertschöpfung geprägte Rollen ersetzt'''.

'''Ökonomische IVS-Rollen''' sind:

*'''IVS-Business Management'''
**Die Rolle umfasst die Entscheidungsbefugnis über die Art und Weise wie IVS-Dienste eingeführt und betrieben werden. Dies betrifft sowohl die Strategie als auch operative Umsetzung.
**Wird diese Rolle durch eine staatliche Institution wahrgenommen, umfassen die damit verbundenen Aktionen das klassische Spektrum über Dienstanweisungen, Rechtsverordnungen, Gesetze, Direktiven und andere.
**Wird diese Rolle durch eine private Institution wahrgenommen, umfasst sie die Funktion der Unternehmensführung.

*'''IVS-Service-Angebot'''
**Die Rolle erfasst alle Aktionen, die den Wertschöpfungsaspekt von IVS-Diensten betreffen. Das schließt die Konzeption des IVS-Dienstes im Allgemeinen ein, wie auch die Entscheidung über die IVS-Architektur des IVS-Dienstes und wie dieser bepreist wird.
**Die Entscheidung darüber, ob der IVS-Dienst selbst erstellt oder durch Dritte angeboten wird, liegt allerdings im Entscheidungsbereich der IVS-Business Management-Rolle.

*'''IVS-Human Resources'''
**Die Rolle ist eine zentrale Rolle für die Umsetzung der IVS-Dienste. Die Kernaufgabe ist die Bereitstellung und der zielorientierte Einsatz von Personal, um IVS-Dienste einzuführen und zu betreiben.
**In der konzeptionellen Planung eines IVS-Dienstes werden die Institutionen identifiziert. Im Falle der Umsetzung wird diese Rolle von den relevanten Institutionen so konkretisiert, dass eine personelle Zuordnung ermöglicht wird.

*'''IVS-Financial Management'''
**Diese Rolle soll sicherstellen, dass sowohl die Anfangsinvestitionen als auch die Ersatzinvestitionen finanziert werden können. Wie sich die Finanzierung gestaltet, hängt hier auch davon ab, ob eine staatliche Institution oder eine private Institution in der Finanzierungsverantwortung steht.
**Im Falle staatlicher Institutionen dürften steuer- und/oder gebührenfinanzierte Lösungen '''im Vordergrund stehen.'''
**Private Investitionen können neben der Innenfinanzierung auf die klassischen Instrumente der Außenfinanzierung (Beteiligungsfinanzierung, Fremdfinanzierung) und Sonderformen der Finanzierung (Factoring) zurückgreifen.

*'''IVS-Controlling'''
**Diese Rolle umfasst vor allem Aufgaben des internen Rechnungswesens. Neben der richtigen Erfassung der Kosten und Erlöse erfüllt das IVS-Controlling eine Unterstützungsfunktion für die Meta-Rolle IVS-Business Management.
**Auch hier ist im Rahmen der Umsetzung darauf zu achten, dass die zu erfassenden ökonomischen Größen unterschiedlich definiert werden können, wenn es sich entweder um staatliche oder private Institutionen handelt.
**Bei einer staatlichen Ausübung dieser Rolle können z. B. neben den für den Betrieb notwendigen betriebswirtschaftlichen Kosten und Erlösen auch gesamtwirtschaftliche Kosten und gesamtwirtschaftliche Nutzen erfasst werden, um die Entscheidungen über Einführung und Betrieb von IVS-Diensten unter volkswirtschaftlichen Gesichtspunkten zu optimieren.

=== IVS-Rollen mit technischer Sicht: Technischer Betrieb von IVS-Wertschöpfungsstufen und von IVS-Diensten ===

[[File:TechnischeRollen.png|thumb|right|304x188px|Rollen mit technischer Sicht]]

*'''IVS-Inhalteanbieter''' (IVS-Content Provider)
**Erfassung und Sammlung von Rohdaten durch automatische Datenerfassungssysteme
**Erfassung/Generierung von (Roh-)Informationen mittels sogenannter "nicht-technischer Quellen" (z. B. Polizei, Feuerwehr, Behörden, Straßenbetreiber, Mobilitätsdienstleister sowie Verkehrsteilnehmer)
**Alle Rohdaten und -informationen müssen - falls relevant - eine Ortscodierung und einen Zeitstempel beinhalten. Neben Echtzeitdaten können auch historische Daten für die Generierung von Prognosen verwendet werden.
**Bereitstellung der Daten und Informationen an Schnittstellen in geeigneten Datenformaten und mittels geeigneter Protokolle
*'''IVS-Dienstbetreiber''' (IVS-Service Operator)
**Sammlung und Verfeinerung von Rohdaten und -Informationen unter Umständen von mehreren und verschiedenen IVS-Inhalteanbietern zu verwertbaren Mehrwert-Informationen (Schaffung von Added Value)
**Anwendung unterschiedlicher Methoden (Fusion von Daten, spezielle Algorithmen, Verkehrs- und Entscheidungsmodelle ...)
**Erzeugung von Informationen mit identischem Inhalt für unterschiedliche IVS-Dienstanbieter und unterschiedliche IVS-Endgeräte von IVS-End-Nutzern (Smartphones, Websites, Navigationssysteme usw.)
*'''IVS-Dienstanbieter''' (IVS-Service Provider)
**Realisierung von direkten Schnittstellen zum IVS-End-Nutzer, oft unter Rückgriff auf IVS-Dienste anderer IVS-Dienstanbieter
**Übermittlung der Mehrwertinformationen an den IVS-End-Nutzer
*'''IVS-End-Nutzer '''
**ist Kunde des IVS-Dienstanbieters und nutzt Informationen für private oder geschäftliche Zwecke.

=== Weitere IVS-Rollen (IVS-Stakeholder) ===

Neben den direkt an der Wertschöpfung beteiligten IVS-Rollen gibt es weitere wichtige IVS-Rollen: z. B.

*Technikhersteller und -lieferanten
*Standardisierungsorganisationen
*Verbände und Vertreter von politischen und wirtschaftlichen Interessensgruppen
*Interessengruppen von Bürgern
*...

== Beispiel-Stereotype von IVS-Akteuren ==

Im konkreten Falle der Konzeption, Einführung und des Betriebs eines IVS-Dienstes werden Rollen von konkreten IVS-Akteuren eingenommen, die Stereotypen von IVS-Akteuren zugeordnet werden können.

Folgende Liste zeigt Stereotype von IVS-Akteuren:

*'''Öffentliche Institutionen'''
**Gesetzgeber/Regulierungsbehörde
**Finanz- und Fördermittelgeber
**Öffentlicher Baulastträger
**Öffentlicher Straßenbetreiber
**Straßenverkehrsbehörde (Polizei)
**Öffentlicher Content- und Serviceoperator (Wetterdienst ...)
**Öffentlicher Service Provider (Landesmeldestellen, öffentliche Rundfunkanstalten ...)
**...

*'''Öffentliche/Private Institutionen'''
**Daten- und Informations-Broker (MDM)
**Standardisierungsorganisationen

*'''Private Content- und Serviceprovider '''
**Private Contentprovider, Serviceoperator und Serviceprovider (Navigationsdienstleister ...)

*'''Industrie'''
**Verkehrstechnik-Industrie
**IKT-Industrie
**Automobilindustrie
**Automobilzulieferer
**Kommunikationsinfrastrukturindustrie

Inhaltlich können IVS-Stereotype von IVS-Rollen wie folgt weiter differenziert werden:

*Rechtsform und Aufgaben
*Geschäftsstrategie und [https://de.wikipedia.org/wiki/Geschäftsmodell IVS-Geschäftsmodell(e)] (Businness-Case)
*Kern-/Zusatzgeschäfte (Inhalte und Ziele), Finanzierungsmodelle
*Organisationsform, Schlüsselressourcen und Partnerschaften
*Wertschöpfungsprozesse
*Informationsstrukturen
*IT (IT-Dienste und IT-Infrastrukturen inkl. Datenbestand, Datenschnittstellen/Vernetzung)

== Erfassung und Beschreibung von IVS-Rollen ==

=== Ziel der Erfassung von IVS-Rollen ===

Für die Entwicklung einer IVS-Referenzarchitektur oder der IVS-Architektur eines realen IVS-Dienstes müssen in diesem Schritt die IVS-Rollen, die in die IVS-Wertschöpfung zu involvierenden IVS-Akteure und die zu beteiligenden IVS-Stakeholder erfasst und beschrieben werden.

=== Identifizierung der IVS-Rollen und ihre Beschreibung ===

Für die Erfassung und Beschreibung der IVS-Rollen ist es - evtl. schon als Vorbereitung für den Schritt [[IVS-Architekturvision|Entwicklung einer IVS-Architekturvision ]] - erforderlich, eine erste Vorstellung für den IVS-Dienst selbst zu entwickeln und darüber die erforderlichen IVS-Rollen in der IVS-Wertschöfungskette/im IVS-Wertschöpfungsnetzwerk wie folgt zu veranschaulichen:

*Beschreibung (evtl. Visualisierung) des IVS-Dienstes und des damit verbundenen Nutzens für den Endkunden
*Beschreibung der dazu erforderlichen IVS-Informationslogistikkette
*Identifizierung der an der Wertschöpfung zu beteiligenden IVS-Rollen mit
**dem Grad der Beteiligung
**den wichtigsten Anliegen und Geschäftsanforderungen (Business Cases)
**deren Bedenken und Perspektiven

=== Ergebnisdarstellung der Identifizierung der IVS-Rollen ===

Zur Ergebnisdarstellung stellt die IVS-Rahmenarchitektur zwei Templates bereit:

*'''Das IVS-Rollen-Map Template'''
**Das IVS-Rollen-Map Template ist ein '''IVS-Architekturdeliverable (siehe [[IVS-RollenMap-Template|IVS-Rollen Map]])''', das die Stereoptype von IVS-Akteuren und IVS-Stakeholdern deklariert und mit Ihren Geschäftsanliegen und IVS-Rollen beschreibt.
**Außerdem '''klassifiziert es die Bedeutung von IVS-Akteuren und IVS-Stakeholdern''', die sie über ihre Rolle für den IVS-Dienst bzw. die IVS-Dienste-Kategorie erlangen (Power-Grid).
*'''Das IVS-Rollen Template'''
**Das IVS-Rollen Template ist ein '''IVS-Architekturbaustein (siehe [[IVS-Rolle|IVS-Rolle]])''', mit dem Stereotype von IVS-Fähigkeiten und IVS-Verantwortlichkeiten, die für IVS-Wertschöpfung von IVS-Diensten typisch und erforderlich sind, bezeichnet und semantisch beschrieben werden.

=== Beispiel Rollen-Map ===

Beispiele von IVS-Rollenbeschreibungen von IVS-Akteurs-Stereotypen mit Hilfe des IVS-Rollen-Map-Templates zeigt folgende Tabelle:

{| border="1" class="wikitable"
|-
! IVS-Rolle für die IVS-Wertschöpfung
!
Sicht der IVS-Rolle

*'''H'''=hoheitlich
*'''Ö'''=Ökonomisch
*'''T'''=Technisch
*'''N'''=Nebenrolle

! Schlüsselanliegen der IVS-Rolle
! IVS-Capabilities/IVS-Verantwortlichkeiten
! Wertigkeit der IVS-Rolle (gemäß Power Grid)
!
IVS-Akteur bzw. IVS-Akteurs-Stereotyp

|- style="vertical-align:top"
| '''Verkehrsplanung'''
| style="text-align: center" | T
| Planerische Grundlagen für Verkehrsmanagement nach verkehrsplanerischen Grundsätzen schaffen
| Netz, Infrastruktur, Verkehrstechnische Unterlagen, VM-Strategien... planen und als Versorgungsdaten bereitstellen
| Key player
| Öffentlicher Straßenbetreiber
|- style="vertical-align:top"
| '''Runder Tisch'''
| style="text-align: center" | T
| Planerische Grundlagen für Zuständigkeitsübergreifendes Verkehrsmanagement nach verkehrsplanerischen Grundsätzen schaffen
| Zuständigkeitsübergreifende VM-Strategien planen und als Versorgungsdaten bereitstellen
| Key player
| Arbeitsgruppe zweier oder mehrerer Öffentlicher Straßenbetreiber
|- style="vertical-align:top"
| '''Betriebsdatenerfassung'''
| style="text-align: center" | T
| Hohe Verfügbarkeit der verkehrstechnischen Infrastruktur
| Betriebsdaten der verkehrstechnischen Infrastruktur detektieren
| Key player
| Öffentlicher Straßenbetreiber
|- style="vertical-align:top"
| '''Stellplatzerfassung'''
| style="text-align: center" | T
| Stellplätze nach wirtschaftlichen Gesichtspunkten vermieten
| Stellplatzangebot detektieren
| Key player
| Parkhausbetreiber
|- style="vertical-align:top"
| '''Datenerfassung Private'''
| style="text-align: center" | T
| Bestmögliche Information des individuellen Kunden (hohe Kundenzufriedenheit)
| Verkehrsdaten Stadt und Fernstraßen detektieren
| Keep satisfied
| Privater (Mobilitäts-)Dienstleister
|- style="vertical-align:top"
| '''Verkehrsdatenerfassung'''
| style="text-align: center" | T
| Qualitativ hochwertige Erfassung von verkehrsrelevanten Daten
| Vorhersehbare Ereignisse erfassen, Verkehrsdaten detektieren, unvorhersehbare Ereignisse detektieren
| Key player
| Öffentlicher Straßenbetreiber
|- style="vertical-align:top"
| '''Verkehrsmanagement'''
| style="text-align: center" | T
| Vermeidung von Überlastungen im Netz sowie schnelle und angemessene Reaktion auf unvorhersehbare Störungen im Netz
| Verkehrsdatenfusion, Verkehrsmodellierung, Betriebsdatenfusion, Strategieauswahl
| Key player
| Öffentlicher Straßenbetreiber
|- style="vertical-align:top"
| '''Verkehrsinformation'''
| style="text-align: center" | T
| Schnelle und kollektive Verbreitung von Verkehrsinformationen in Echtzeit mittels möglichst aller verfügbaren Informationskanäle (Broadcasting)
| Maßnahmen (und Routen) publizieren
| Key player
| Öffentlicher Straßenbetreiber
|- style="vertical-align:top"
| '''Verkehrsinformation Private'''
| style="text-align: center" | T
| Schnelle und personalisierte Verbreitung von Verkehrsinformationen in Echtzeit mittels individueller Informationskanäle
| Maßnahmen publizieren (private)
| Keep satisfied
| Privater Service Provider
|- style="vertical-align:top"
| '''Nationale Access-Point MDM'''
| style="text-align: center" | T
| Förderung des Datenaustausches zwischen IVS-Akteuren
| Maßnahmen und Strategien makeln
| Key player
| Öffentlicher oder privater Service Operator
|- style="vertical-align:top"
| '''Verkehrssteuerung'''
| style="text-align: center" | T
| Schnelles und effektives Umsetzen von Verkehrsmanagmentstrategien
| Aktoren schalten
| Key player
| Öffentlicher Straßenbetreiber
|- style="vertical-align:top"
| '''End-Nutzer individuell'''
| style="text-align: center" | T
| Erhalt von qualitativ hochwertigen, verlässlichen Informationen, die ihn in Echtzeit bei der Wahl seiner Route unterstützen
| Kollektive und individuelle Informationen verarbeiten
| Key player
| End-Nutzer
|- style="vertical-align:top"
| '''End-Nutzer kollektiv'''
| style="text-align: center" | T
| Erhalt von qualitativ hochwertigen, verlässlichen Informationen, die ihn in Echtzeit bei der Wahl seiner Route unterstützen
| Kollektive Informationen verarbeiten
| Key player
| End-Nutzerkollektiv
|- style="vertical-align:top"
| '''Verkehrsmanagement als End-Nutzer'''
| style="text-align: center" | T
| Zugriff auf qualitativ hochwertige Verkehrsinformationen in Echtzeit
| Verkehrsinformationen verarbeiten
| Key player
| Öffentlicher Straßenbetreiber als End-Nutzer
|- style="vertical-align:top"
| '''OCA - Open Traffic Systems City Association'''
| style="text-align: center" | N
| Unterstützung von und Teilhabe an Standards für zuständigkeitsübergreifendes Verkehrsmanagement
| Standards für zuständigkeitsübergreifendes Verkehrsmanagement
| Keep informed
| Öffentlicher Straßenbaulastträger
|- style="vertical-align:top"
| '''IVS-Dienst-Ersteller'''
| style="text-align: center" | Ö
| Erstellung von IVS-Diensten nach wirtschaftlichen und technischen Grundsätzen
| Beschaffung der Finanzmittel für und Erstellung von IVS-Diensten
| Key player
| Öffentlicher Baulastträger
|- style="vertical-align:top"
| '''IVS-Gesetzgeber'''
| style="text-align: center" | H
| Schaffung eindeutiger gesetzlicher Rahmenbedingungen für IVS-Dienste
| Legislative
| Keep satisfied
| Parlamentarische Institutionen
|- style="vertical-align:top"
| '''IVS-Dienste System-Lieferant'''
| style="text-align: center" | N
| Herstellung und Verkauf von wettbewerbsfähigen Systemen, Software und Infrastruktur von IVS-Diensten
| Herstellung, Lieferung, Implementierung und Unterhaltung sowie Vertrieb von Systemen, Software und Infrastruktur von IVS-Diensten
| Keep informed
| Hersteller von Systemen, Software und Infrastruktur von IVS-Diensten
|}

=== Beispiel Rollen-Beschreibung ===

Ein Beispiel für die Beschreibung eines IVS-Akteurs in einer konkreten IVS-Rolle mit Hilfe des IVS-Rollen-Templates zeigt folgende Tabelle:

{| class="wikitable" style="width: 100%;"
|-
! colspan="2" | Stammdaten der IVS-Rolle
|- style="vertical-align:top"
| style="width: 187px" | '''IVS-Rolle''' (für die IVS-Wertschöpfung)
| style="width: 440px" | '''Verkehrsmanagement Stadt ''' (Anwendung von Verkehrsmanagementstrategien im Zuständigkeitsbereich Stadt)
|- style="vertical-align:top"
| style="width: 187px" | '''Sicht der IVS-Rolle'''
| style="width: 440px" | Technische Sicht
|- style="vertical-align:top"
| style="width: 187px" | '''IVS-Akteur(e) bzw. IVS-Akteurs-Stereotyp(e)''' für diese IVS-Rolle:
| style="width: 440px" | Verkehrsmanagementabteilung des öffentlicher Straßenbetreibers Stadt (Amt für Verkehrsmanagement, Düsseldorf)
|-
! colspan="2" | Ziele und Interessen
|- style="vertical-align:top"
| style="width: 187px" | '''Verantwortungsbereich'''
| style="width: 440px" |
*Verantwortlich für die Auswahl und Anwendung von Verkehrsmanagmentstrategien als Beitrag zur Sicherstellung von Sicherheit und Komfort des Verkehrsablaufs des Verkehrsteilnehmers im städtischen Straßennetz
*Umsetzung und Einhaltung der Anforderungen, die aus dieser Rolle erwachsen.
*Beim Zuständigkeitsübergreifenden Verkehrsmanagement in der Rolle des Ansprechpartners und verantwortlichen IVS-Akteurs auf Seiten der Stadt.

|- style="vertical-align:top"
| style="width: 187px" | '''Ziele und Interessen '''der IVS-'''Rolle'''
| style="width: 440px" | Sicherstellung der Sicherheit und Leichtigkeit des Verkehrsablaufs für alle Nutzer des städtischen Straßennetzes.
|-
! colspan="2" | Aufgaben und Interessen
|- style="vertical-align:top"
| style="width: 187px" | '''Aufgaben im Zuständigkeitsübergreifenden Verkehrsmanagement'''
| style="width: 440px" |
Umsetzung der gemeinsam mit der Fernstraßenseite vereinbarten Verkehrsmanagementstrategien mit Wirkung im kommunalen Netzbereich. Diese können im Kontext eines Strategie- und Informationsverbundes mit anderen Straßenbetreibern (andere Kommune, Land) und/oder mit privaten Dienstanbietern erweitert werden. Unter dem Betrachtungsfokus des straßenbetreiber- und privatwirtschaftsübergreifenden Strategie- und Informationsverbundes, stehen folgende Aufgaben im Vordergrund:

*Strategiemanagement vorhersehbarer Ereignisse
*Management unvorhersehbarer Ereignisse
*Straßenbetreiberübergreifende Kooperation
**Anforderung von gemeinsam vereinbarten Schaltungen im Netz des jeweils anderen Zuständigkeitsbereichs. Strategieabgleich zwischen Zuständigkeiten auf Basis vordefinierten Strategien
**Austausch von Betriebszuständen und Meldungen
*Austausch von Verkehrsdaten (LOS, Q, V usw.) für das gesamte Netz oder auch nur für den Netzübergangsbereich
*Kooperation mit Privaten

Die vordergründige Anwendung des Zuständigkeitsübergreifenden Verkehrsmanagements ist die Alternativroutensteuerung. Im Kontext eines Straßenbetreibers und/oder privatwirtschaftsübergreifenden Verbundes müssen aber auch die Bedürfnisse von Privaten IVS-Akteuren durch z. B. Strategieabgleich, Bereitstellen von Verkehrsdaten, Meldungen und Betriebszuständen Rechnung getragen werden. Voraussetzung ist eine planerische und organisatorische Abstimmung von Maßnahmen im Vorfeld.

|- style="vertical-align:top"
| style="width: 187px" | '''Prozessbeteiligung'''
| style="width: 440px" |
*Abstimmung der Strategieauswahl mit Zuständigkeit Fernstraßen im Falle von Stau und besonderen Ereignissen (Maßnahmenaustauschliste)
*Austausch von Verkehrsdaten und Alternativrouten mit Privaten Service Providern (Strategiekonformes Routen)

|- style="vertical-align:top"
| style="width: 187px" | '''Interaktion mit anderen IVS-Rollen'''
| style="width: 440px" | Statische und dynamische Verkehrsmanagementstrategien und -informationen der Zuständigkeit Fernstraßen erheben und bereitstellen
|-
! colspan="2" | Daten und Informationen
|- style="vertical-align:top"
| style="width: 187px" | '''Benötigte Daten/Informationen'''
| style="width: 440px" | Verkehrszustand im Netz und Maßnahmenanforderungen
|- style="vertical-align:top"
| style="width: 187px" | '''Erzeugte Daten/Informationen'''
| style="width: 440px" | Aktualisierte Maßnahmenaustauschliste
|-
! colspan="2" | IVS-Capabilities
|- style="vertical-align:top"
| style="width: 187px" | '''IVS-Fähigkeiten'''
| style="width: 440px" |
*Erstellung und Visualisierung von Betriebszuständen und von zu einem Verkehrslagebericht aufbereitete Verkehrsdaten
*Senden und Empfangen von Maßnahmenaustauschlisten
*Senden und Empfangen von Bestätigungen von Maßnahmenanforderungen mittels Versand einer aktualisierten Maßnahmenaustauschliste
*Weitergabe von Routenempfehlungen.

|- style="vertical-align:top"
| style="width: 187px" | '''Voraussetzungen'''
| style="width: 440px" |
*Leistungsfähige straßenseitige und zentralenseitige IVS-Infrastruktur
*Leitstelle für Verkehrsmanagement mit online- und Realzeit- Interaktionsmöglichkeiten mit anderen IVS-Akteuren
*Für Zuständigkeitsübergreifendes Verkehrsmanagement ausgebildetes, erfahrenes Personal.

|}

=== Requirements Management als Hilfestellung zur Identifikation von Anforderungen an IVS-Rollen ===

Mithilfe des Requirements Managements können '''Anforderungen an IVS-Rollen identifiziert''' werden. Um Anforderungen zu ermitteln, kann die '''Technik der Business-Szenarios''' angewandt werden. Sie dient der Identifikation und Dokumentation von Anforderungen.

[[File:IVS-Anforderungen-Template 00-00-01-1.PNG|500px|IVS-Anforderung Template]]

Für die Formulierung der Requirements in natürlicher Sprache empfiehlt sich die Verwendung einer im Requirements Engineering erprobten und empfohlenen '''Satzschablone''':

[[File:Schablone ReqEng.jpg|thumb|center|500px|Requirements Schablone (Quelle: Pohl/Rupp (2015))]]

Vorteil der '''Satzschablone ist die klare Syntax''' und sie hilft außerdem dabei, '''übliche Fehler bei der Formulierung zu vermeiden'''.

== Literaturverzeichnis ==

<references />

----

[[Hauptseite|<< Zurück zur Hauptseite]]

IVS-Rollenkonzept

2018-02-09T14:12:38Z

Scholtes:

== Verwendete Architekturbausteine (siehe IVS-Begriffe & Definitionen)  ==

[[IVS-Architekturbausteine#IVS-Rolle...|IVS-Rolle]]

== TISA-Wertschöpfungskette als Einordnungshintergrund für IVS-Rollen ==

Als Ausgangspunkt für die Entwicklung des IVS-Rollen- und -Akteurskonzepts und die Einordnung der IVS-Rollen in Wertschöpfungsstufen wird das '''[[Media:_EO12013TISADefinition-ITS-value-chain20121018.pdf|TISA-Traffic and Travel Information Value Chain Modell]]'''<sup>[[Media:_EO12013TISADefinition-ITS-value-chain20121018.pdf|<ref>TISA (2012): Terms and Definitions for the Traffic and Travel Information Value Chain. Online verfügbar unter http://www.tisa.org/assets/Uploads/Public/EO12013TISADefinition-ITS-value-chain20121018.pdf, zuletzt geprüft am 18.10.2017.</ref>]]</sup> herangezogen, das von TISA speziell für die Darstellung und Beschreibung von Wertschöpfungsketten und -netzwerken für IVS-Verkehrsinformationsdienste entwickelt wurde und in folgender Abbildung dargestellt ist:

[[File:TISAValueChain.png|thumb|center|500px|TISA-Traffic und Travel Information Value Chain Model]]

Das Modell definiert auf der höchsten Ebene '''zwei Wertschöpfungssegmente''', nämlich dass '''Inhalte-Segment''' und das '''Dienste-Segment''' mit jeweils zwei, also insgesamt '''vier Wertschöpfungsstufen''', die typischerweise zum '''Aufbau einer IVS-Informationslogistikkette '''erforderlich sind:

*'''Inhalte-Segment '''(Content segment) mit:
**'''Inhalte-Erfassung''' (Content detection)
**'''Inhalte-Verarbeitung''' (Content processing)
*'''Dienste-Segment''' (Service segment) mit:
**'''Dienst-Bereitstellung''' (Service provision)
**'''Dienst-Darstellung''' (Service presentation)

== Metamodell für IVS-Rollen ==

=== Institutioneller Rollenmodell-Ansatz zur Verknüpfung von Akteurs-Sterotypen und Verhaltens-Stereotypen ===

Für die Definition und Beschreibung der für die einzelnen IVS-Wertschöpfungsstufen erforderlichen IVS-Rollen wird ein '''institutioneller Rollenmodell-Ansatz''' vorgeschlagen, der gemäß Schulz/Mainka/Joisten<sup><ref>Schulz, W.H.; Mainka, M.; Joisten, N. (2013): Entwicklung eines Konzeptes für institutionelle Rollenmodelle als Beitrag zur Einführung kooperativer Systeme im Straßenverkehr, Bergisch Gladbach.
Im Folgenden zitiert als: Schulz, W. H.; Mainka, M.; Joisten, N. (2013).</ref></sup> und [[Media:Detecon_buch_future_telco_iii_d_07_2016_0.pdf|Schulz/Wieker<sup><sub><ref>Schulz, Wolfgang H.; Wieker, Hors (2016): Co-operative Intelligent Transport Systems: Neue Markt-chancen durch den Systemverbund aus Automobil-und Telekommunikationsindustrie. In: Future Telco III, Powerplay für Telekommunikationsunternehmen, S. 138–147. Online verfügbar unter http://www.detecon.com/sites/default/files/detecon_buch_future_telco_iii_d_07_2016_0.pdf, zuletzt geprüft am 18.10.2017.</ref></sub></sup>]] im Wesentlichen auf den Grundlagen der Institutionenökonomik<sup><ref>Schneider, Dieter (1995): Betriebswirtschaftslehre. Grundlagen. 2. Aufl. (1). Online verfügbar unter https://www.amazon.de/Betriebswirtschaftslehre-Bd-1-Grundlagen-Dieter-Schneider/dp/3486234234, zuletzt geprüft am 18.10.2017</ref></sup>, der Systemtheorie<sup><ref>Luhmann, Niklas (2002): Einführung in die Systemtheorie. Heidelberg. Online verfügbar unter https://www.amazon.de/Einf%C3%BChrung-die-Systemtheorie-Dirk-Baecker/dp/3896702920, zuletzt geprüft am 18.10.2017.</ref></sup> und der Theorie der industrieökonomisch basierten System-Dynamics<sup><ref>Schulz, Wolfgang H. (2005): Application of System Dynamics to Empirical Industrial Organization – The Effects of the New Toll System. In: Jahrbuch für Wirtschaftswissenschaften/Review of Economics 56, S. 205–227.</ref></sup> basiert und der im Projekt [http://www.converge-online.de/ CONVERGE] für einen C-ITS Systemverbund angewendet wurde.

Institutionell heißt in diesem Kontext, dass für den Aufbau und den Betrieb einer IVS-Wertschöpfungskette notwendige '''IVS-Rollen anhand institutionalisierter (d.h. erwartbarer) Fähigkeiten und Verhaltensnormen charakterisiert''' werden.

Für den IVS-Architekt ist der institutionelle Rollenmodell-Ansatz von großem Vorteil, weil er sich beim Aufbau von Wertschöpfungsketten auf '''institutionalisierte Rollen (Akteurs-Stereotype) '''abstützen kann, von denen erwartet werden kann, dass sie sich nicht nur '''politisch, wirtschaftlich, operativ und technisch''' institutionalisiert verhalten ('''Verhaltens-Stereotype)''', sondern dass sie auch in Bezug auf ihre '''personellen, technischen und finanziellen Ressourcen sowie ihre Fertigkeiten''' mit entsprechenden institutionalisierten Fähigkeiten '''(Fähigkeits-Stereotype)''' ausgestattet sind.

Beispiele für institutionalisierte Rollen mit institutionalisiertem Verhalten zeigt folgende Tabelle:

{| border="1" cellpadding="1" cellspacing="1" style="width: 500px"
|-
| '''Akteurs-Stereotype'''
| '''Verhaltens-Stereotype'''
|-
| style="vertical-align: top" | Regierungen
| style="vertical-align: top" | machen Gesetze und schaffen rechtliche Rahmenbedingungen
|-
| style="vertical-align: top" | Straßenverkehrsbehörden
| style="vertical-align: top" | genehmigen und ordnen auf der Grundlage von Gesetzen und rechtlichen Rahmenbedingungen an
|-
| style="vertical-align: top" | Öffentliche Straßenbetreiber
| style="vertical-align: top" | steuern und managen den Verkehr auf kollektive Art und Weise
|-
| style="vertical-align: top" | Private Navigationsdienstleister
| style="vertical-align: top" | richten ihre Dienste vor dem Hintergrund der Erwirtschaftung von Gewinnen primär auf "zahlende" Kunden aus
|}
<div id="jsseunrwnoeo" style="display: none"><div class="simple_mutex" id="ocfipreoqyfb" style="display: none">mutex/ocfipreoqyfb/mutex</div> </div>
=== Regelnde und handelnde Institutionen ===

[[File:InstituitionellerAnsatz.png|thumb|right|304x188px|Institutioneller Rollenmodell-Ansatz]] Gemäß Schneider<ref>Schneider, Dieter (1995): Betriebswirtschaftslehre. Grundlagen. 2. Aufl. (1). Online verfügbar unter https://www.amazon.de/Betriebswirtschaftslehre-Bd-1-Grundlagen-Dieter-Schneider/dp/3486234234, zuletzt geprüft am 18.10.2017.</ref> werden Institutionen nach '''Regelsystemen (Ordnungen)''' und '''Handlungssystemen (Organisationen) '''differenziert:

*'''Regelsysteme''' umfassen als Institutionen "'''Rechtsrahmen, Verhaltensnormen und Gepflogenheiten" '''in Märkten und in anderen Organisationen als Bestandteile von Markt- und Unternehmensverfassungen, aber auch Organisationen, die Regelsysteme erstellen.
*'''Handlungssysteme''' umfassen handelnde Organisationen und setzen insofern immer '''handelnde Personen''' voraus. Diese Eigenschaft trennt das Handlungssystem vom Regelsystem.
<div id="jsseunrwnoeo" style="display: none"><div class="simple_mutex" id="ocfipreoqyfb" style="display: none">mutex/ocfipreoqyfb/mutex</div> </div>

=== Kategorien von IVS-Rollen ===

Unter Bezug auf das oben erläuterte Metamodell für IVS-Rollen differenziert "institutionelles" IVS-Rollenmodell drei Kategorien (Familien) von IVS-Rollen:

'''Regelnde IVS-Rollen''', die '''Regelsysteme '''schaffen, die für den Aufbau von IVS-Wertschöpfungsketten/-netzwerken und den Betrieb von IVS-Diensten erforderlich sind:

*Normative Regelungen (rechtlich, technisch)
*Wirtschaftliche Rahmenbedingungen (Förderung)
*Politische Rahmenbedingungen

Diese Rollen werden in der Regel von politischen, parlamentarischen, rechtsprechenden und nachgelagerten ausführenden Institutionen eingenommen.

'''Operativ handelnde IVS-Rollen''', die in '''Handlungssystemen''' von IVS-Diensten Verantwortung tragen, und von denen erwartet wird, dass sie bei der Entwicklung, Einführung und im operativen Betrieb von IVS-Diensten handeln. Hier werden IVS-Rollen wie folgt unterschieden:

*'''Ökonomische IVS-Rollen''' (Governance von IVS-Diensten) mit folgenden Verantwortlichkeiten und Aufgaben:
**Entwicklung der IVS-Ziel- und -Realisierungsvorstellungen eines IVS-Dienstes sowie der IVS-Strategie zur Zielerreichung
**Schaffung der notwendigen vertraglichen und finanziellen Grundlagen für die Entwicklung, die Implementierung und den Betrieb eines IVS-Dienstes
**Bereitstellung der administrativen und betrieblichen Ressourcen für das Management und den Betrieb eines IVS-Dienstes
**Management und Controlling (der Wertschöpfung) eines IVS-Dienstes während des Betriebs
**Schaffung der notwendigen technischen Rahmenbedingungen (technische Standards, notwendige IT und Infrastruktur ...) für den Betrieb des IVS-Dienstes.
*'''Technische IVS-Rollen''' (Betrieb eines IVS-Dienstes) mit der Verantwortlichkeit und den Aufgaben für den operativen Betrieb eines IVS-Dienstes.

Ökonomische und technische Rollen werden in der Regel von Institutionen der Wirtschaft und der Öffentlichen Verwaltung eingenommen.

== Wertigkeiten von IVS-Rollen (Power-Grid) ==

[[File:Power Grid zur Stakeholderanalyse Konsortium MRK-AMADEUS.JPG|thumb|right|300px|Power Grid zur Stakeholderanalyse Konsortium MRK-AMADEUS]]

'''IVS-Rollen haben unterschiedliche Wertigkeiten''' in Bezug auf das Zustandekommen und für den Betrieb eines IVS-Dienstes. Das '''Rollen-Power-Grid Modell''' der Open Group unterscheidet vier unterschiedliche Wertigkeiten (siehe nebenstehendes Bild).

*'''IVS-Schlüsselrollen''' (Power Grid D: Key-Players)
**sind die, die für das Zustandekommen von IVS-Diensten unbedingt erforderlich sind und die an der Wertschöpfung im operativen Betrieb von IVS-Diensten direkt beteiligt sind.
*'''Involvierte IVS-Rollen''' (Power Grid C: Keep satisfied)
**IVS-Rollen, die zwar nicht direkt an der Wertschöpfung eines IVS-Dienstes beteiligt sind, für die der IVS-Dienst aufgrund einer Zusammenarbeit mit den IVS-Schlüsselrollen jedoch mit direkten Auswirkungen verbunden ist.
*'''Interessierte IVS-Rollen''' (Power Grid B: Keep informed)
**Interessengruppen, die als Interessengemeinschaft von IVS-Diensten betroffen sind.
*'''Sonstige IVS-Rollen''' (Power Grid A: Minimal Effort)
**IVS-Rollen, die am Rande beteiligt sind, auf die der IVS-Dienst aber weder eine Auswirkung hat noch mit einem Interesse verbunden ist.

== Stereotype von IVS-Akteuren bzw. IVS-Akteure als Instanzen von IVS-Rollen ==

Im konkreten Fall werden '''IVS-Rollen von IVS-Akteuren eingenommen'''. Bei '''IVS-Referenzarchitekturen''' handelt es sich um '''Stereotype von IVS-Akteuren''' (z. B. Öffentlicher Straßenbaulastträger, Öffentlicher Straßenbetreiber, Verkehrsunternehmen, Navigationsdienstleister etc. (siehe auch [[IVS-Rollenkonzept#Stereotypen_von_IVS-Akteuren_als_Instanzen_von_IVS-Rollen|Stereotype von IVS-Akteuren als Instanzen von IVS-Rollen]])), bei der '''IVS-Architektur für einen realen IVS-Dienst''' um '''konkrete Instanzen der Stereotype von IVS-Akteuren''' (z. B. Tiefbauamt der Stadt X, Amt für Verkehrsmanagement der Stadt X, Verkehrsunternehmen der Stadt X, TomTom, INRIX, GARMIN, Google, HERE ...).

== IVS-Rollen in IVS-Wertschöpfungsketten/-netzwerken ==

=== Sichten als Grundlage für die Differenzierung von Rollen ===

Vor dem oben dargestellten Hintergrund leiten sich die für den Aufbau und Betrieb von IVS-Diensten erforderlichen Rollen durch drei ganz unterschiedliche Sichten auf die IVS-Wertschöpfungskette/das IVS-Wertschöpfungsnetzwerk bzw. ihre einzelnen Stufen ab:

*die '''hoheitliche''' Sicht: Hoheitliche IVS-Rollen
*die '''ökonomische''' Sicht: Ökonomische IVS-Rollen
*die '''technische''' Sicht: Technische IVS-Rollen

=== IVS-Rollen mit hoheitlicher Sicht: Schaffung hoheitlicher IVS-Regeln und -Rahmenbedingungen ===

[[File:RegelndeRollen.png|thumb|right|304x188px|Rollen mit hoheitlicher Sicht]]

*'''Gesetzgebende IVS-Rollen...'''
**Parlamentarische Institutionen, die als gesetzgebende Gewalt rechtlich und technisch normative Regeln- und Rahmenbedingungen schaffen.
*'''Rechtsprechende IVS-Rollen...'''
**Gerichtliche Institutionen, die im Falle von Meinungsverschiedenheiten und Konflikten Recht sprechen.
*'''Ausführende IVS-Rollen...'''
**Regierungsinstitutionen und öffentliche Verwaltungen, die gesetzliche Vorgaben ausführen/umsetzen.
*'''Politische IVS-Rollen...'''
**Institutionen der Politik, die politisch motivierte rechtliche und wirtschaftliche Rahmenbedingungen durch die Meinungsbildung und durch das Einbringen von Gesetzen (z. B. Förderung von IVS oder C-ITS) schaffen.

=== IVS-Rollen mit ökonomischer Sicht: Management von IVS-Wertschöpfungsstufen ===

[[File:ÖkonomischeRollen.png|thumb|right|304x188px|Rollen mit ökonomischer Sicht]]

Als Vorschlag für ein Ökonomisches IVS-Rollenmodell wird ein Modell von Schulz<ref>Schulz, W. H.; Mainka, M.; Joisten, N. (2013).</ref> herangezogen, das die klassischen betriebswirtschaftlichen Rollen '''durch spezifische, ''''''durch die Wertschöpfung geprägte Rollen ersetzt'''.

'''Ökonomische IVS-Rollen''' sind:

*'''IVS-Business Management'''
**Die Rolle umfasst die Entscheidungsbefugnis über die Art und Weise wie IVS-Dienste eingeführt und betrieben werden. Dies betrifft sowohl die Strategie als auch operative Umsetzung.
**Wird diese Rolle durch eine staatliche Institution wahrgenommen, umfassen die damit verbundenen Aktionen das klassische Spektrum über Dienstanweisungen, Rechtsverordnungen, Gesetze, Direktiven und andere.
**Wird diese Rolle durch eine private Institution wahrgenommen, umfasst sie die Funktion der Unternehmensführung.

*'''IVS-Service-Angebot'''
**Die Rolle erfasst alle Aktionen, die den Wertschöpfungsaspekt von IVS-Diensten betreffen. Das schließt die Konzeption des IVS-Dienstes im Allgemeinen ein, wie auch die Entscheidung über die IVS-Architektur des IVS-Dienstes und wie dieser bepreist wird.
**Die Entscheidung darüber, ob der IVS-Dienst selbst erstellt oder durch Dritte angeboten wird, liegt allerdings im Entscheidungsbereich der IVS-Business Management-Rolle.

*'''IVS-Human Resources'''
**Die Rolle ist eine zentrale Rolle für die Umsetzung der IVS-Dienste. Die Kernaufgabe ist die Bereitstellung und der zielorientierte Einsatz von Personal, um IVS-Dienste einzuführen und zu betreiben.
**In der konzeptionellen Planung eines IVS-Dienstes werden die Institutionen identifiziert. Im Falle der Umsetzung wird diese Rolle von den relevanten Institutionen so konkretisiert, dass eine personelle Zuordnung ermöglicht wird.

*'''IVS-Financial Management'''
**Diese Rolle soll sicherstellen, dass sowohl die Anfangsinvestitionen als auch die Ersatzinvestitionen finanziert werden können. Wie sich die Finanzierung gestaltet, hängt hier auch davon ab, ob eine staatliche Institution oder eine private Institution in der Finanzierungsverantwortung steht.
**Im Falle staatlicher Institutionen dürften steuer- und/oder gebührenfinanzierte Lösungen '''im Vordergrund stehen.'''
**Private Investitionen können neben der Innenfinanzierung auf die klassischen Instrumente der Außenfinanzierung (Beteiligungsfinanzierung, Fremdfinanzierung) und Sonderformen der Finanzierung (Factoring) zurückgreifen.

*'''IVS-Controlling'''
**Diese Rolle umfasst vor allem Aufgaben des internen Rechnungswesens. Neben der richtigen Erfassung der Kosten und Erlöse erfüllt das IVS-Controlling eine Unterstützungsfunktion für die Meta-Rolle IVS-Business Management.
**Auch hier ist im Rahmen der Umsetzung darauf zu achten, dass die zu erfassenden ökonomischen Größen unterschiedlich definiert werden können, wenn es sich entweder um staatliche oder private Institutionen handelt.
**Bei einer staatlichen Ausübung dieser Rolle können z. B. neben den für den Betrieb notwendigen betriebswirtschaftlichen Kosten und Erlösen auch gesamtwirtschaftliche Kosten und gesamtwirtschaftliche Nutzen erfasst werden, um die Entscheidungen über Einführung und Betrieb von IVS-Diensten unter volkswirtschaftlichen Gesichtspunkten zu optimieren.

=== IVS-Rollen mit technischer Sicht: Technischer Betrieb von IVS-Wertschöpfungsstufen und von IVS-Diensten ===

[[File:TechnischeRollen.png|thumb|right|304x188px|Rollen mit technischer Sicht]]

*'''IVS-Inhalteanbieter''' (IVS-Content Provider)
**Erfassung und Sammlung von Rohdaten durch automatische Datenerfassungssysteme
**Erfassung/Generierung von (Roh-)Informationen mittels sogenannter "nicht-technischer Quellen" (z. B. Polizei, Feuerwehr, Behörden, Straßenbetreiber, Mobilitätsdienstleister sowie Verkehrsteilnehmer)
**Alle Rohdaten und -informationen müssen - falls relevant - eine Ortscodierung und einen Zeitstempel beinhalten. Neben Echtzeitdaten können auch historische Daten für die Generierung von Prognosen verwendet werden.
**Bereitstellung der Daten und Informationen an Schnittstellen in geeigneten Datenformaten und mittels geeigneter Protokolle
*'''IVS-Dienstbetreiber''' (IVS-Service Operator)
**Sammlung und Verfeinerung von Rohdaten und -Informationen unter Umständen von mehreren und verschiedenen IVS-Inhalteanbietern zu verwertbaren Mehrwert-Informationen (Schaffung von Added Value)
**Anwendung unterschiedlicher Methoden (Fusion von Daten, spezielle Algorithmen, Verkehrs- und Entscheidungsmodelle ...)
**Erzeugung von Informationen mit identischem Inhalt für unterschiedliche IVS-Dienstanbieter und unterschiedliche IVS-Endgeräte von IVS-End-Nutzern (Smartphones, Websites, Navigationssysteme usw.)
*'''IVS-Dienstanbieter''' (IVS-Service Provider)
**Realisierung von direkten Schnittstellen zum IVS-End-Nutzer, oft unter Rückgriff auf IVS-Dienste anderer IVS-Dienstanbieter
**Übermittlung der Mehrwertinformationen an den IVS-End-Nutzer
*'''IVS-End-Nutzer '''
**ist Kunde des IVS-Dienstanbieters und nutzt Informationen für private oder geschäftliche Zwecke.

=== Weitere IVS-Rollen (IVS-Stakeholder) ===

Neben den direkt an der Wertschöpfung beteiligten IVS-Rollen gibt es weitere wichtige IVS-Rollen: z. B.

*Technikhersteller und -lieferanten
*Standardisierungsorganisationen
*Verbände und Vertreter von politischen und wirtschaftlichen Interessensgruppen
*Interessengruppen von Bürgern
*...

== Beispiel-Stereotype von IVS-Akteuren ==

Im konkreten Falle der Konzeption, Einführung und des Betriebs eines IVS-Dienstes werden Rollen von konkreten IVS-Akteuren eingenommen, die Stereotypen von IVS-Akteuren zugeordnet werden können.

Folgende Liste zeigt Stereotype von IVS-Akteuren:

*'''Öffentliche Institutionen'''
**Gesetzgeber/Regulierungsbehörde
**Finanz- und Fördermittelgeber
**Öffentlicher Baulastträger
**Öffentlicher Straßenbetreiber
**Straßenverkehrsbehörde (Polizei)
**Öffentlicher Content- und Serviceoperator (Wetterdienst ...)
**Öffentlicher Service Provider (Landesmeldestellen, Öffentliche Rundfunkanstalten ...)
**...

*'''Öffentliche/Private Institutionen'''
**Daten- und Informations-Broker (MDM)
**Standardisierungsorganisationen

*'''Private Content- und Serviceprovider '''
**Private Contentprovider, Serviceoperator und Serviceprovider (Navigationsdienstleister ...)

*'''Industrie'''
**Verkehrstechnik-Industrie
**IKT-Industrie
**Automobilindustrie
**Automobilzulieferer
**Kommunikationsinfrastrukturindustrie

Inhaltlich können IVS-Stereotype von IVS-Rollen wie folgt weiter differenziert werden:

*Rechtsform und Aufgaben
*Geschäftsstrategie und [https://de.wikipedia.org/wiki/Geschäftsmodell IVS-Geschäftsmodell(e)] (Businness-Case)
*Kern-/Zusatzgeschäfte (Inhalte und Ziele), Finanzierungsmodelle
*Organisationsform, Schlüsselressourcen und Partnerschaften
*Wertschöpfungsprozesse
*Informationsstrukturen
*IT (IT-Dienste und IT-Infrastrukturen inkl. Datenbestand, Datenschnittstellen/Vernetzung)

== Erfassung und Beschreibung von IVS-Rollen ==

=== Ziel der Erfassung von IVS-Rollen ===

Für die Entwicklung einer IVS-Referenzarchitektur oder der IVS-Architektur eines realen IVS-Dienstes müssen in diesem Schritt die IVS-Rollen, die in die IVS-Wertschöpfung zu involvierenden IVS-Akteure und die zu beteiligenden IVS-Stakeholder erfasst und beschrieben werden.

=== Identifizierung der IVS-Rollen und ihre Beschreibung ===

Für die Erfassung und Beschreibung der IVS-Rollen ist es - evtl. schon als Vorbereitung für den Schritt [[IVS-Architekturvision|Entwicklung einer IVS-Architekturvision ]] - erforderlich, eine erste Vorstellung für den IVS-Dienst selbst zu entwickeln und darüber die erforderlichen IVS-Rollen in der IVS-Wertschöfungskette/im IVS-Wertschöpfungsnetzwerk wie folgt zu veranschaulichen:

*Beschreibung (evtl. Visualisierung) des IVS-Dienstes und des damit verbundenen Nutzens für den Endkunden
*Beschreibung der dazu erforderlichen IVS-Informationslogistikkette
*Identifizierung der an der Wertschöpfung zu beteiligenden IVS-Rollen mit
**dem Grad der Beteiligung
**den wichtigsten Anliegen und Geschäftsanforderungen (Business Cases)
**deren Bedenken und Perspektiven

=== Ergebnisdarstellung der Identifizierung der IVS-Rollen ===

Zur Ergebnisdarstellung stellt die IVS-Rahmenarchitektur zwei Templates bereit:

*'''Das IVS-Rollen-Map Template'''
**Das IVS-Rollen-Map Template ist ein '''IVS-Architekturdeliverable (siehe [[IVS-RollenMap-Template|IVS-Rollen Map]])''', das die Stereoptype von IVS-Akteuren und IVS-Stakeholdern deklariert und mit Ihren Geschäftsanliegen und IVS-Rollen beschreibt.
**Außerdem '''klassifiziert es die Bedeutung von IVS-Akteuren und IVS-Stakeholdern''', die sie über ihre Rolle für den IVS-Dienst bzw. die IVS-Dienste-Kategorie erlangen (Power-Grid).
*'''Das IVS-Rollen Template'''
**Das IVS-Rollen Template ist ein '''IVS-Architekturbaustein (siehe [[IVS-Rolle|IVS-Rolle]])''', mit dem Stereotype von IVS-Fähigkeiten und IVS-Verantwortlichkeiten, die für IVS-Wertschöpfung von IVS-Diensten typisch und erforderlich sind, bezeichnet und semantisch beschrieben werden.

=== Beispiel Rollen-Map ===

Beispiele von IVS-Rollenbeschreibungen von IVS-Akteurs-Stereotypen mit Hilfe des IVS-Rollen-Map-Templates zeigt folgende Tabelle:

{| border="1" class="wikitable"
|-
! IVS-Rolle für die IVS-Wertschöpfung
!
Sicht der IVS-Rolle

*'''H'''=hoheitlich
*'''Ö'''=Ökonomisch
*'''T'''=Technisch
*'''N'''=Nebenrolle

! Schlüsselanliegen der IVS-Rolle
! IVS-Capabilities/IVS-Verantwortlichkeiten
! Wertigkeit der IVS-Rolle (gemäß Power Grid)
!
IVS-Akteur bzw. IVS-Akteurs-Stereotyp

|- style="vertical-align:top"
| '''Verkehrsplanung'''
| style="text-align: center" | T
| Planerische Grundlagen für Verkehrsmanagement nach verkehrsplanerischen Grundsätzen schaffen
| Netz, Infrastruktur, Verkehrstechnische Unterlagen, VM-Strategien... planen und als Versorgungsdaten bereitstellen
| Key player
| Öffentlicher Straßenbetreiber
|- style="vertical-align:top"
| '''Runder Tisch'''
| style="text-align: center" | T
| Planerische Grundlagen für Zuständigkeitsübergreifendes Verkehrsmanagement nach verkehrsplanerischen Grundsätzen schaffen
| Zuständigkeitsübergreifende VM-Strategien planen und als Versorgungsdaten bereitstellen
| Key player
| Arbeitsgruppe zweier oder mehrerer Öffentlicher Straßenbetreiber
|- style="vertical-align:top"
| '''Betriebsdatenerfassung'''
| style="text-align: center" | T
| Hohe Verfügbarkeit der verkehrstechnischen Infrastruktur
| Betriebsdaten der verkehrstechnischen Infrastruktur detektieren
| Key player
| Öffentlicher Straßenbetreiber
|- style="vertical-align:top"
| '''Stellplatzerfassung'''
| style="text-align: center" | T
| Stellplätze nach wirtschaftlichen Gesichtspunkten vermieten
| Stellplatzangebot detektieren
| Key player
| Parkhausbetreiber
|- style="vertical-align:top"
| '''Datenerfassung Private'''
| style="text-align: center" | T
| Bestmögliche Information des individuellen Kunden (hohe Kundenzufriedenheit)
| Verkehrsdaten Stadt und Fernstraßen detektieren
| Keep satisfied
| Privater (Mobilitäts-)Dienstleister
|- style="vertical-align:top"
| '''Verkehrsdatenerfassung'''
| style="text-align: center" | T
| Qualitativ hochwertige Erfassung von verkehrsrelevanten Daten
| Vorhersehbare Ereignisse erfassen, Verkehrsdaten detektieren, unvorhersehbare Ereignisse detektieren
| Key player
| Öffentlicher Straßenbetreiber
|- style="vertical-align:top"
| '''Verkehrsmanagement'''
| style="text-align: center" | T
| Vermeidung von Überlastungen im Netz sowie schnelle und angemessene Reaktion auf unvorhersehbare Störungen im Netz
| Verkehrsdatenfusion, Verkehrsmodellierung, Betriebsdatenfusion, Strategieauswahl
| Key player
| Öffentlicher Straßenbetreiber
|- style="vertical-align:top"
| '''Verkehrsinformation'''
| style="text-align: center" | T
| Schnelle und kollektive Verbreitung von Verkehrsinformationen in Echtzeit mittels möglichst aller verfügbaren Informationskanäle (Broadcasting)
| Maßnahmen (und Routen) publizieren
| Key player
| Öffentlicher Straßenbetreiber
|- style="vertical-align:top"
| '''Verkehrsinformation Private'''
| style="text-align: center" | T
| Schnelle und personalisierte Verbreitung von Verkehrsinformationen in Echtzeit mittels individueller Informationskanäle
| Maßnahmen publizieren (private)
| Keep satisfied
| Privater Service Provider
|- style="vertical-align:top"
| '''Nationale Access-Point MDM'''
| style="text-align: center" | T
| Förderung des Datenaustausches zwischen IVS-Akteuren
| Maßnahmen und Strategien makeln
| Key player
| Öffentlicher oder privater Service Operator
|- style="vertical-align:top"
| '''Verkehrssteuerung'''
| style="text-align: center" | T
| Schnelles und effektives Umsetzen von Verkehrsmanagmentstrategien
| Aktoren schalten
| Key player
| Öffentlicher Straßenbetreiber
|- style="vertical-align:top"
| '''End-Nutzer individuell'''
| style="text-align: center" | T
| Erhalt von qualitativ hochwertigen, verlässlichen Informationen, die ihn in Echtzeit bei der Wahl seiner Route unterstützen
| Kollektive und individuelle Informationen verarbeiten
| Key player
| End-Nutzer
|- style="vertical-align:top"
| '''End-Nutzer kollektiv'''
| style="text-align: center" | T
| Erhalt von qualitativ hochwertigen, verlässlichen Informationen, die ihn in Echtzeit bei der Wahl seiner Route unterstützen
| Kollektive Informationen verarbeiten
| Key player
| End-Nutzerkollektiv
|- style="vertical-align:top"
| '''Verkehrsmanagement als End-Nutzer'''
| style="text-align: center" | T
| Zugriff auf qualitativ hochwertige Verkehrsinformationen in Echtzeit
| Verkehrsinformationen verarbeiten
| Key player
| Öffentlicher Straßenbetreiber als End-Nutzer
|- style="vertical-align:top"
| '''OCA - Open Traffic Systems City Association'''
| style="text-align: center" | N
| Unterstützung von und Teilhabe an Standards für zuständigkeitsübergreifendes Verkehrsmanagement
| Standards für zuständigkeitsübergreifendes Verkehrsmanagement
| Keep informed
| Öffentlicher Straßenbaulastträger
|- style="vertical-align:top"
| '''IVS-Dienst-Ersteller'''
| style="text-align: center" | Ö
| Erstellung von IVS-Diensten nach wirtschaftlichen und technischen Grundsätzen
| Beschaffung der Finanzmittel für und Erstellung von IVS-Diensten
| Key player
| Öffentlicher Baulastträger
|- style="vertical-align:top"
| '''IVS-Gesetzgeber'''
| style="text-align: center" | H
| Schaffung eindeutiger gesetzlicher Rahmenbedingungen für IVS-Dienste
| Legislative
| Keep satisfied
| Parlamentarische Institutionen
|- style="vertical-align:top"
| '''IVS-Dienste System-Lieferant'''
| style="text-align: center" | N
| Herstellung und Verkauf von wettbewerbsfähigen Systemen, Software und Infrastruktur von IVS-Diensten
| Herstellung, Lieferung, Implementierung und Unterhaltung sowie Vertrieb von Systemen, Software und Infrastruktur von IVS-Diensten
| Keep informed
| Hersteller von Systemen, Software und Infrastruktur von IVS-Diensten
|}

=== Beispiel Rollen-Beschreibung ===

Ein Beispiel für die Beschreibung eines IVS-Akteurs in einer konkreten IVS-Rolle mit Hilfe des IVS-Rollen-Templates zeigt folgende Tabelle:

{| class="wikitable" style="width: 100%;"
|-
! colspan="2" | Stammdaten der IVS-Rolle
|- style="vertical-align:top"
| style="width: 187px" | '''IVS-Rolle''' (für die IVS-Wertschöpfung)
| style="width: 440px" | '''Verkehrsmanagement Stadt ''' (Anwendung von Verkehrsmanagementstrategien im Zuständigkeitsbereich Stadt)
|- style="vertical-align:top"
| style="width: 187px" | '''Sicht der IVS-Rolle'''
| style="width: 440px" | Technische Sicht
|- style="vertical-align:top"
| style="width: 187px" | '''IVS-Akteur(e) bzw. IVS-Akteurs-Stereotyp(e)''' für diese IVS-Rolle:
| style="width: 440px" | Verkehrsmanagementabteilung des öffentlicher Straßenbetreibers Stadt (Amt für Verkehrsmanagement, Düsseldorf)
|-
! colspan="2" | Ziele und Interessen
|- style="vertical-align:top"
| style="width: 187px" | '''Verantwortungsbereich'''
| style="width: 440px" |
*Verantwortlich für die Auswahl und Anwendung von Verkehrsmanagmentstrategien als Beitrag zur Sicherstellung von Sicherheit und Komfort des Verkehrsablaufs des Verkehrsteilnehmers im städtischen Straßennetz
*Umsetzung und Einhaltung der Anforderungen, die aus dieser Rolle erwachsen.
*Beim Zuständigkeitsübergreifenden Verkehrsmanagement in der Rolle des Ansprechpartners und verantwortlichen IVS-Akteurs auf Seiten der Stadt.

|- style="vertical-align:top"
| style="width: 187px" | '''Ziele und Interessen '''der IVS-'''Rolle'''
| style="width: 440px" | Sicherstellung der Sicherheit und Leichtigkeit des Verkehrsablaufs für alle Nutzer des städtischen Straßennetzes.
|-
! colspan="2" | Aufgaben und Interessen
|- style="vertical-align:top"
| style="width: 187px" | '''Aufgaben im Zuständigkeitsübergreifenden Verkehrsmanagement'''
| style="width: 440px" |
Umsetzung der gemeinsam mit der Fernstraßenseite vereinbarten Verkehrsmanagementstrategien mit Wirkung im kommunalen Netzbereich. Diese können im Kontext eines Strategie- und Informationsverbundes mit anderen Straßenbetreibern (andere Kommune, Land) und/oder mit privaten Dienstanbietern erweitert werden. Unter dem Betrachtungsfokus des straßenbetreiber- und privatwirtschaftsübergreifenden Strategie- und Informationsverbundes, stehen folgende Aufgaben im Vordergrund:

*Strategiemanagement vorhersehbarer Ereignisse
*Management unvorhersehbarer Ereignisse
*Straßenbetreiberübergreifende Kooperation
**Anforderung von gemeinsam vereinbarten Schaltungen im Netz des jeweils anderen Zuständigkeitsbereichs. Strategieabgleich zwischen Zuständigkeiten auf Basis vordefinierten Strategien
**Austausch von Betriebszuständen und Meldungen
*Austausch von Verkehrsdaten (LOS, Q, V usw.) für das gesamte Netz oder auch nur für den Netzübergangsbereich
*Kooperation mit Privaten

Die vordergründige Anwendung des Zuständigkeitsübergreifenden Verkehrsmanagements ist die Alternativroutensteuerung. Im Kontext eines Straßenbetreibers und/oder privatwirtschaftsübergreifenden Verbundes müssen aber auch die Bedürfnisse von Privaten IVS-Akteuren durch z. B. Strategieabgleich, Bereitstellen von Verkehrsdaten, Meldungen und Betriebszuständen Rechnung getragen werden. Voraussetzung ist eine planerische und organisatorische Abstimmung von Maßnahmen im Vorfeld.

|- style="vertical-align:top"
| style="width: 187px" | '''Prozessbeteiligung'''
| style="width: 440px" |
*Abstimmung der Strategieauswahl mit Zuständigkeit Fernstraßen im Falle von Stau und besonderen Ereignissen (Maßnahmenaustauschliste)
*Austausch von Verkehrsdaten und Alternativrouten mit Privaten Service Providern (Strategiekonformes Routen)

|- style="vertical-align:top"
| style="width: 187px" | '''Interaktion mit anderen IVS-Rollen'''
| style="width: 440px" | Statische und dynamische Verkehrsmanagementstrategien und -informationen der Zuständigkeit Fernstraßen erheben und bereitstellen
|-
! colspan="2" | Daten und Informationen
|- style="vertical-align:top"
| style="width: 187px" | '''Benötigte Daten/Informationen'''
| style="width: 440px" | Verkehrszustand im Netz und Maßnahmenanforderungen
|- style="vertical-align:top"
| style="width: 187px" | '''Erzeugte Daten/Informationen'''
| style="width: 440px" | Aktualisierte Maßnahmenaustauschliste
|-
! colspan="2" | IVS-Capabilities
|- style="vertical-align:top"
| style="width: 187px" | '''IVS-Fähigkeiten'''
| style="width: 440px" |
*Erstellung und Visualisierung von Betriebszuständen und von zu einem Verkehrslagebericht aufbereitete Verkehrsdaten
*Senden und Empfangen von Maßnahmenaustauschlisten
*Senden und Empfangen von Bestätigungen von Maßnahmenanforderungen mittels Versand einer aktualisierten Maßnahmenaustauschliste
*Weitergabe von Routenempfehlungen.

|- style="vertical-align:top"
| style="width: 187px" | '''Voraussetzungen'''
| style="width: 440px" |
*Leistungsfähige straßenseitige und zentralenseitige IVS-Infrastruktur
*Leitstelle für Verkehrsmanagement mit online- und Realzeit- Interaktionsmöglichkeiten mit anderen IVS-Akteuren
*Für Zuständigkeitsübergreifendes Verkehrsmanagement ausgebildetes, erfahrenes Personal.

|}

=== Requirements Management als Hilfestellung zur Identifikation von Anforderungen an IVS-Rollen ===

Mithilfe des Requirements Managements können '''Anforderungen an IVS-Rollen identifiziert''' werden. Um Anforderungen zu ermitteln, kann die '''Technik der Business-Szenarios''' angewandt werden. Sie dient der Identifikation und Dokumentation von Anforderungen.

[[File:IVS-Anforderungen-Template 00-00-01-1.PNG|500px|IVS-Anforderung Template]]

Für die Formulierung der Requirements in natürlicher Sprache empfiehlt sich die Verwendung einer im Requirements Engineering erprobten und empfohlenen '''Satzschablone''':

[[File:Schablone ReqEng.jpg|thumb|center|500px|Requirements Schablone (Quelle: Pohl/Rupp (2015))]]

Vorteil der '''Satzschablone ist die klare Syntax''' und sie hilft außerdem dabei, '''übliche Fehler bei der Formulierung zu vermeiden'''.

== Literaturverzeichnis ==

<references />

----

[[Hauptseite|<< Zurück zur Hauptseite]]

IVS-Rollenkonzept

2018-02-09T14:11:29Z

Scholtes:

== Verwendete Architekturbausteine (siehe IVS-Begriffe & Definitionen)  ==

[[IVS-Architekturbausteine#IVS-Rolle...|IVS-Rolle]]

== TISA-Wertschöpfungskette als Einordnungshintergrund für IVS-Rollen ==

Als Ausgangspunkt für die Entwicklung des IVS-Rollen- und -Akteurskonzepts und die Einordnung der IVS-Rollen in Wertschöpfungsstufen wird das '''[[Media:_EO12013TISADefinition-ITS-value-chain20121018.pdf|TISA-Traffic and Travel Information Value Chain Modell]]'''<sup>[[Media:_EO12013TISADefinition-ITS-value-chain20121018.pdf|<ref>TISA (2012): Terms and Definitions for the Traffic and Travel Information Value Chain. Online verfügbar unter http://www.tisa.org/assets/Uploads/Public/EO12013TISADefinition-ITS-value-chain20121018.pdf, zuletzt geprüft am 18.10.2017.</ref>]]</sup> herangezogen, das von TISA speziell für die Darstellung und Beschreibung von Wertschöpfungsketten und -netzwerken für IVS-Verkehrsinformationsdienste entwickelt wurde und in folgender Abbildung dargestellt ist:

[[File:TISAValueChain.png|thumb|center|500px|TISA-Traffic und Travel Information Value Chain Model]]

Das Modell definiert auf der höchsten Ebene '''zwei Wertschöpfungssegmente''', nämlich dass '''Inhalte-Segment''' und das '''Dienste-Segment''' mit jeweils zwei, also insgesamt '''vier Wertschöpfungsstufen''', die typischerweise zum '''Aufbau einer IVS-Informationslogistikkette '''erforderlich sind:

*'''Inhalte-Segment '''(Content segment) mit:
**'''Inhalte-Erfassung''' (Content detection)
**'''Inhalte-Verarbeitung''' (Content processing)
*'''Dienste-Segment''' (Service segment) mit:
**'''Dienst-Bereitstellung''' (Service provision)
**'''Dienst-Darstellung''' (Service presentation)

== Metamodell für IVS-Rollen ==

=== Institutioneller Rollenmodell-Ansatz zur Verknüpfung von Akteurs-Sterotypen und Verhaltens-Stereotypen ===

Für die Definition und Beschreibung der für die einzelnen IVS-Wertschöpfungsstufen erforderlichen IVS-Rollen wird ein '''institutioneller Rollenmodell-Ansatz''' vorgeschlagen, der gemäß Schulz/Mainka/Joisten<sup><ref>Schulz, W.H.; Mainka, M.; Joisten, N. (2013): Entwicklung eines Konzeptes für institutionelle Rollenmodelle als Beitrag zur Einführung kooperativer Systeme im Straßenverkehr, Bergisch Gladbach.
Im Folgenden zitiert als: Schulz, W. H.; Mainka, M.; Joisten, N. (2013).</ref></sup> und [[Media:Detecon_buch_future_telco_iii_d_07_2016_0.pdf|Schulz/Wieker<sup><sub><ref>Schulz, Wolfgang H.; Wieker, Hors (2016): Co-operative Intelligent Transport Systems: Neue Markt-chancen durch den Systemverbund aus Automobil-und Telekommunikationsindustrie. In: Future Telco III, Powerplay für Telekommunikationsunternehmen, S. 138–147. Online verfügbar unter http://www.detecon.com/sites/default/files/detecon_buch_future_telco_iii_d_07_2016_0.pdf, zuletzt geprüft am 18.10.2017.</ref></sub></sup>]] im Wesentlichen auf den Grundlagen der Institutionenökonomik<sup><ref>Schneider, Dieter (1995): Betriebswirtschaftslehre. Grundlagen. 2. Aufl. (1). Online verfügbar unter https://www.amazon.de/Betriebswirtschaftslehre-Bd-1-Grundlagen-Dieter-Schneider/dp/3486234234, zuletzt geprüft am 18.10.2017</ref></sup>, der Systemtheorie<sup><ref>Luhmann, Niklas (2002): Einführung in die Systemtheorie. Heidelberg. Online verfügbar unter https://www.amazon.de/Einf%C3%BChrung-die-Systemtheorie-Dirk-Baecker/dp/3896702920, zuletzt geprüft am 18.10.2017.</ref></sup> und der Theorie der industrieökonomisch basierten System-Dynamics<sup><ref>Schulz, Wolfgang H. (2005): Application of System Dynamics to Empirical Industrial Organization – The Effects of the New Toll System. In: Jahrbuch für Wirtschaftswissenschaften/Review of Economics 56, S. 205–227.</ref></sup> basiert und der im Projekt [http://www.converge-online.de/ CONVERGE] für einen C-ITS Systemverbund angewendet wurde.

Institutionell heißt in diesem Kontext, dass für den Aufbau und den Betrieb einer IVS-Wertschöpfungskette notwendige '''IVS-Rollen anhand institutionalisierter (d.h. erwartbarer) Fähigkeiten und Verhaltensnormen charakterisiert''' werden.

Für den IVS-Architekt ist der institutionelle Rollenmodell-Ansatz von großem Vorteil, weil er sich beim Aufbau von Wertschöpfungsketten auf '''institutionalisierte Rollen (Akteurs-Stereotype) '''abstützen kann, von denen erwartet werden kann, dass sie sich nicht nur '''politisch, wirtschaftlich, operativ und technisch''' institutionalisiert verhalten ('''Verhaltens-Stereotype)''', sondern dass sie auch in Bezug auf ihre '''personellen, technischen und finanziellen Ressourcen sowie ihre Fertigkeiten''' mit entsprechenden institutionalisierten Fähigkeiten '''(Fähigkeits-Stereotype)''' ausgestattet sind.

Beispiele für institutionalisierte Rollen mit institutionalisiertem Verhalten zeigt folgende Tabelle:

{| border="1" cellpadding="1" cellspacing="1" style="width: 500px"
|-
| '''Akteurs-Stereotype'''
| '''Verhaltens-Stereotype'''
|-
| style="vertical-align: top" | Regierungen
| style="vertical-align: top" | machen Gesetze und schaffen rechtliche Rahmenbedingungen
|-
| style="vertical-align: top" | Straßenverkehrsbehörden
| style="vertical-align: top" | genehmigen und ordnen auf der Grundlage von Gesetzen und rechtlichen Rahmenbedingungen an
|-
| style="vertical-align: top" | Öffentliche Straßenbetreiber
| style="vertical-align: top" | steuern und managen den Verkehr auf kollektive Art und Weise
|-
| style="vertical-align: top" | Private Navigationsdienstleister
| style="vertical-align: top" | richten ihre Dienste vor dem Hintergrund der Erwirtschaftung von Gewinnen primär auf "zahlende" Kunden aus
|}
<div id="jsseunrwnoeo" style="display: none"><div class="simple_mutex" id="ocfipreoqyfb" style="display: none">mutex/ocfipreoqyfb/mutex</div> </div>
=== Regelnde und handelnde Institutionen ===

[[File:InstituitionellerAnsatz.png|thumb|right|304x188px|Institutioneller Rollenmodell-Ansatz]] Gemäß Schneider<ref>Schneider, Dieter (1995): Betriebswirtschaftslehre. Grundlagen. 2. Aufl. (1). Online verfügbar unter https://www.amazon.de/Betriebswirtschaftslehre-Bd-1-Grundlagen-Dieter-Schneider/dp/3486234234, zuletzt geprüft am 18.10.2017.</ref> werden Institutionen nach '''Regelsystemen (Ordnungen)''' und '''Handlungssystemen (Organisationen) '''differenziert:

*'''Regelsysteme''' umfassen als Institutionen "'''Rechtsrahmen, Verhaltensnormen und Gepflogenheiten" '''in Märkten und in anderen Organisationen als Bestandteile von Markt- und Unternehmensverfassungen, aber auch Organisationen, die Regelsysteme erstellen.
*'''Handlungssysteme''' umfassen handelnde Organisationen und setzen insofern immer '''handelnde Personen''' voraus. Diese Eigenschaft trennt das Handlungssystem vom Regelsystem.
<div id="jsseunrwnoeo" style="display: none"><div class="simple_mutex" id="ocfipreoqyfb" style="display: none">mutex/ocfipreoqyfb/mutex</div> </div>

=== Kategorien von IVS-Rollen ===

Unter Bezug auf das oben erläuterte Metamodell für IVS-Rollen differenziert "institutionelles" IVS-Rollenmodell drei Kategorien (Familien) von IVS-Rollen:

'''Regelnde IVS-Rollen''', die '''Regelsysteme '''schaffen, die für den Aufbau von IVS-Wertschöpfungsketten/-netzwerken und den Betrieb von IVS-Diensten erforderlich sind:

*Normative Regelungen (rechtlich, technisch)
*Wirtschaftliche Rahmenbedingungen (Förderung)
*Politische Rahmenbedingungen

Diese Rollen werden in der Regel von politischen, parlamentarischen, rechtsprechenden und nachgelagerten ausführenden Institutionen eingenommen.

'''Operativ handelnde IVS-Rollen''', die in '''Handlungssystemen''' von IVS-Diensten Verantwortung tragen, und von denen erwartet wird, dass sie bei der Entwicklung, Einführung und im operativen Betrieb von IVS-Diensten handeln. Hier werden IVS-Rollen wie folgt unterschieden:

*'''Ökonomische IVS-Rollen''' (Governance von IVS-Diensten) mit folgenden Verantwortlichkeiten und Aufgaben:
**Entwicklung der IVS-Ziel- und -Realisierungsvorstellungen eines IVS-Dienstes sowie der IVS-Strategie zur Zielerreichung
**Schaffung der notwendigen vertraglichen und finanziellen Grundlagen für die Entwicklung, die Implementierung und den Betrieb eines IVS-Dienstes
**Bereitstellung der administrativen und betrieblichen Ressourcen für das Management und den Betrieb eines IVS-Dienstes
**Management und Controlling (der Wertschöpfung) eines IVS-Dienstes während des Betriebs
**Schaffung der notwendigen technischen Rahmenbedingungen (technische Standards, notwendige IT und Infrastruktur ...) für den Betrieb des IVS-Dienstes.
*'''Technische IVS-Rollen''' (Betrieb eines IVS-Dienstes) mit der Verantwortlichkeit und den Aufgaben für den operativen Betrieb eines IVS-Dienstes.

Ökonomische und technische Rollen werden in der Regel von Institutionen der Wirtschaft und der Öffentlichen Verwaltung eingenommen.

== Wertigkeiten von IVS-Rollen (Power-Grid) ==

[[File:Power Grid zur Stakeholderanalyse Konsortium MRK-AMADEUS.JPG|thumb|right|300px|Power Grid zur Stakeholderanalyse Konsortium MRK-AMADEUS]]

'''IVS-Rollen haben unterschiedliche Wertigkeiten''' in Bezug auf das Zustandekommen und für den Betrieb eines IVS-Dienstes. Das '''Rollen-Power-Grid Modell''' der Open Group unterscheidet vier unterschiedliche Wertigkeiten (siehe nebenstehendes Bild).

*'''IVS-Schlüsselrollen''' (Power Grid D: Key-Players)
**sind die, die für das Zustandekommen von IVS-Diensten unbedingt erforderlich sind und die an der Wertschöpfung im operativen Betrieb von IVS-Diensten direkt beteiligt sind.
*'''Involvierte IVS-Rollen''' (Power Grid C: Keep satisfied)
**IVS-Rollen, die zwar nicht direkt an der Wertschöpfung eines IVS-Dienstes beteiligt sind, für die der IVS-Dienst aufgrund einer Zusammenarbeit mit den IVS-Schlüsselrollen jedoch mit direkten Auswirkungen verbunden ist.
*'''Interessierte IVS-Rollen''' (Power Grid B: Keep informed)
**Interessengruppen, die als Interessengemeinschaft von IVS-Diensten betroffen sind.
*'''Sonstige IVS-Rollen''' (Power Grid A: Minimal Effort)
**IVS-Rollen, die am Rande beteiligt sind, auf die der IVS-Dienst aber weder eine Auswirkung hat noch mit einem Interesse verbunden ist.

== Stereotype von IVS-Akteuren bzw. IVS-Akteure als Instanzen von IVS-Rollen ==

Im konkreten Fall werden '''IVS-Rollen von IVS-Akteuren eingenommen'''. Bei '''IVS-Referenzarchitekturen''' handelt es sich um '''Stereotype von IVS-Akteuren''' (z. B. Öffentlicher Straßenbaulastträger, Öffentlicher Straßenbetreiber, Verkehrsunternehmen, Navigationsdienstleister etc. (siehe auch [[IVS-Rollenkonzept#Stereotypen_von_IVS-Akteuren_als_Instanzen_von_IVS-Rollen|Stereotype von IVS-Akteuren als Instanzen von IVS-Rollen]])), bei der '''IVS-Architektur für einen realen IVS-Dienst''' um '''konkrete Instanzen der Stereotype von IVS-Akteuren''' (z. B. Tiefbauamt der Stadt X, Amt für Verkehrsmanagement der Stadt X, Verkehrsunternehmen der Stadt X, TomTom, INRIX, GARMIN, Google, HERE ...).

== IVS-Rollen in IVS-Wertschöpfungsketten/-netzwerken ==

=== Sichten als Grundlage für die Differenzierung von Rollen ===

Vor dem oben dargestellten Hintergrund leiten sich die für den Aufbau und Betrieb von IVS-Diensten erforderlichen Rollen durch drei ganz unterschiedliche Sichten auf die IVS-Wertschöpfungskette/das IVS-Wertschöpfungsnetzwerk bzw. ihre einzelnen Stufen ab:

*die '''hoheitliche''' Sicht: Hoheitliche IVS-Rollen
*die '''ökonomische''' Sicht: Ökonomische IVS-Rollen
*die '''technische''' Sicht: Technische IVS-Rollen

=== IVS-Rollen mit hoheitlicher Sicht: Schaffung hoheitlicher IVS-Regeln und -Rahmenbedingungen ===

[[File:RegelndeRollen.png|thumb|right|304x188px|Rollen mit hoheitlicher Sicht]]

*'''Gesetzgebende IVS-Rollen...'''
**Parlamentarische Institutionen, die als gesetzgebende Gewalt rechtlich und technisch normative Regeln- und Rahmenbedingungen schaffen.
*'''Rechtsprechende IVS-Rollen...'''
**Gerichtliche Institutionen, die im Falle von Meinungsverschiedenheiten und Konflikten Recht sprechen.
*'''Ausführende IVS-Rollen...'''
**Regierungsinstitutionen und Öffentliche Verwaltungen, die gesetzliche Vorgaben ausführen/umsetzen.
*'''Politische IVS-Rollen...'''
**Institutionen der Politik, die politisch motivierte rechtliche und wirtschaftliche Rahmenbedingungen durch die Meinungsbildung und durch das Einbringen von Gesetzen (z. B. Förderung von IVS oder C-ITS) schaffen.

=== IVS-Rollen mit ökonomischer Sicht: Management von IVS-Wertschöpfungsstufen ===

[[File:ÖkonomischeRollen.png|thumb|right|304x188px|Rollen mit ökonomischer Sicht]]

Als Vorschlag für ein Ökonomisches IVS-Rollenmodell wird ein Modell von Schulz<ref>Schulz, W. H.; Mainka, M.; Joisten, N. (2013).</ref> herangezogen, das die klassischen betriebswirtschaftlichen Rollen '''durch spezifische, ''''''durch die Wertschöpfung geprägte Rollen ersetzt'''.

'''Ökonomische IVS-Rollen''' sind:

*'''IVS-Business Management'''
**Die Rolle umfasst die Entscheidungsbefugnis über die Art und Weise wie IVS-Dienste eingeführt und betrieben werden. Dies betrifft sowohl die Strategie als auch operative Umsetzung.
**Wird diese Rolle durch eine staatliche Institution wahrgenommen, umfassen die damit verbundenen Aktionen das klassische Spektrum über Dienstanweisungen, Rechtsverordnungen, Gesetze, Direktiven und andere.
**Wird diese Rolle durch eine private Institution wahrgenommen, umfasst sie die Funktion der Unternehmensführung.

*'''IVS-Service-Angebot'''
**Die Rolle erfasst alle Aktionen, die den Wertschöpfungsaspekt von IVS-Diensten betreffen. Das schließt die Konzeption des IVS-Dienstes im Allgemeinen ein, wie auch die Entscheidung über die IVS-Architektur des IVS-Dienstes und wie dieser bepreist wird.
**Die Entscheidung darüber, ob der IVS-Dienst selbst erstellt oder durch Dritte angeboten wird, liegt allerdings im Entscheidungsbereich der IVS-Business Management-Rolle.

*'''IVS-Human Resources'''
**Die Rolle ist eine zentrale Rolle für die Umsetzung der IVS-Dienste. Die Kernaufgabe ist die Bereitstellung und der zielorientierte Einsatz von Personal, um IVS-Dienste einzuführen und zu betreiben.
**In der konzeptionellen Planung eines IVS-Dienstes werden die Institutionen identifiziert. Im Falle der Umsetzung wird diese Rolle von den relevanten Institutionen so konkretisiert, dass eine personelle Zuordnung ermöglicht wird.

*'''IVS-Financial Management'''
**Diese Rolle soll sicherstellen, dass sowohl die Anfangsinvestitionen als auch die Ersatzinvestitionen finanziert werden können. Wie sich die Finanzierung gestaltet, hängt hier auch davon ab, ob eine staatliche Institution oder eine private Institution in der Finanzierungsverantwortung steht.
**Im Falle staatlicher Institutionen dürften steuer- und/oder gebührenfinanzierte Lösungen '''im Vordergrund stehen.'''
**Private Investitionen können neben der Innenfinanzierung auf die klassischen Instrumente der Außenfinanzierung (Beteiligungsfinanzierung, Fremdfinanzierung) und Sonderformen der Finanzierung (Factoring) zurückgreifen.

*'''IVS-Controlling'''
**Diese Rolle umfasst vor allem Aufgaben des internen Rechnungswesens. Neben der richtigen Erfassung der Kosten und Erlöse erfüllt das IVS-Controlling eine Unterstützungsfunktion für die Meta-Rolle IVS-Business Management.
**Auch hier ist im Rahmen der Umsetzung darauf zu achten, dass die zu erfassenden ökonomischen Größen unterschiedlich definiert werden können, wenn es sich entweder um staatliche oder private Institutionen handelt.
**Bei einer staatlichen Ausübung dieser Rolle können z. B. neben den für den Betrieb notwendigen betriebswirtschaftlichen Kosten und Erlösen auch gesamtwirtschaftliche Kosten und gesamtwirtschaftliche Nutzen erfasst werden, um die Entscheidungen über Einführung und Betrieb von IVS-Diensten unter volkswirtschaftlichen Gesichtspunkten zu optimieren.

=== IVS-Rollen mit technischer Sicht: Technischer Betrieb von IVS-Wertschöpfungsstufen und von IVS-Diensten ===

[[File:TechnischeRollen.png|thumb|right|304x188px|Rollen mit technischer Sicht]]

*'''IVS-Inhalteanbieter''' (IVS-Content Provider)
**Erfassung und Sammlung von Rohdaten durch automatische Datenerfassungssysteme
**Erfassung/Generierung von (Roh-)Informationen mittels sogenannter "nicht-technischer Quellen" (z. B. Polizei, Feuerwehr, Behörden, Straßenbetreiber, Mobilitätsdienstleister sowie Verkehrsteilnehmer)
**Alle Rohdaten und -informationen müssen - falls relevant - eine Ortscodierung und einen Zeitstempel beinhalten. Neben Echtzeitdaten können auch historische Daten für die Generierung von Prognosen verwendet werden.
**Bereitstellung der Daten und Informationen an Schnittstellen in geeigneten Datenformaten und mittels geeigneter Protokolle
*'''IVS-Dienstbetreiber''' (IVS-Service Operator)
**Sammlung und Verfeinerung von Rohdaten und -Informationen unter Umständen von mehreren und verschiedenen IVS-Inhalteanbietern zu verwertbaren Mehrwert-Informationen (Schaffung von Added Value)
**Anwendung unterschiedlicher Methoden (Fusion von Daten, spezielle Algorithmen, Verkehrs- und Entscheidungsmodelle ...)
**Erzeugung von Informationen mit identischem Inhalt für unterschiedliche IVS-Dienstanbieter und unterschiedliche IVS-Endgeräte von IVS-End-Nutzern (Smartphones, Websites, Navigationssysteme usw.)
*'''IVS-Dienstanbieter''' (IVS-Service Provider)
**Realisierung von direkten Schnittstellen zum IVS-End-Nutzer, oft unter Rückgriff auf IVS-Dienste anderer IVS-Dienstanbieter
**Übermittlung der Mehrwertinformationen an den IVS-End-Nutzer
*'''IVS-End-Nutzer '''
**ist Kunde des IVS-Dienstanbieters und nutzt Informationen für private oder geschäftliche Zwecke.

=== Weitere IVS-Rollen (IVS-Stakeholder) ===

Neben den direkt an der Wertschöpfung beteiligten IVS-Rollen gibt es weitere wichtige IVS-Rollen: z. B.

*Technikhersteller und -lieferanten
*Standardisierungsorganisationen
*Verbände und Vertreter von politischen und wirtschaftlichen Interessensgruppen
*Interessengruppen von Bürgern
*...

== Beispiel-Stereotype von IVS-Akteuren ==

Im konkreten Falle der Konzeption, Einführung und des Betriebs eines IVS-Dienstes werden Rollen von konkreten IVS-Akteuren eingenommen, die Stereotypen von IVS-Akteuren zugeordnet werden können.

Folgende Liste zeigt Stereotype von IVS-Akteuren:

*'''Öffentliche Institutionen'''
**Gesetzgeber/Regulierungsbehörde
**Finanz- und Fördermittelgeber
**Öffentlicher Baulastträger
**Öffentlicher Straßenbetreiber
**Straßenverkehrsbehörde (Polizei)
**Öffentlicher Content- und Serviceoperator (Wetterdienst ...)
**Öffentlicher Service Provider (Landesmeldestellen, Öffentliche Rundfunkanstalten ...)
**...

*'''Öffentliche/Private Institutionen'''
**Daten- und Informations-Broker (MDM)
**Standardisierungsorganisationen

*'''Private Content- und Serviceprovider '''
**Private Contentprovider, Serviceoperator und Serviceprovider (Navigationsdienstleister ...)

*'''Industrie'''
**Verkehrstechnik-Industrie
**IKT-Industrie
**Automobilindustrie
**Automobilzulieferer
**Kommunikationsinfrastrukturindustrie

Inhaltlich können IVS-Stereotype von IVS-Rollen wie folgt weiter differenziert werden:

*Rechtsform und Aufgaben
*Geschäftsstrategie und [https://de.wikipedia.org/wiki/Geschäftsmodell IVS-Geschäftsmodell(e)] (Businness-Case)
*Kern-/Zusatzgeschäfte (Inhalte und Ziele), Finanzierungsmodelle
*Organisationsform, Schlüsselressourcen und Partnerschaften
*Wertschöpfungsprozesse
*Informationsstrukturen
*IT (IT-Dienste und IT-Infrastrukturen inkl. Datenbestand, Datenschnittstellen/Vernetzung)

== Erfassung und Beschreibung von IVS-Rollen ==

=== Ziel der Erfassung von IVS-Rollen ===

Für die Entwicklung einer IVS-Referenzarchitektur oder der IVS-Architektur eines realen IVS-Dienstes müssen in diesem Schritt die IVS-Rollen, die in die IVS-Wertschöpfung zu involvierenden IVS-Akteure und die zu beteiligenden IVS-Stakeholder erfasst und beschrieben werden.

=== Identifizierung der IVS-Rollen und ihre Beschreibung ===

Für die Erfassung und Beschreibung der IVS-Rollen ist es - evtl. schon als Vorbereitung für den Schritt [[IVS-Architekturvision|Entwicklung einer IVS-Architekturvision ]] - erforderlich, eine erste Vorstellung für den IVS-Dienst selbst zu entwickeln und darüber die erforderlichen IVS-Rollen in der IVS-Wertschöfungskette/im IVS-Wertschöpfungsnetzwerk wie folgt zu veranschaulichen:

*Beschreibung (evtl. Visualisierung) des IVS-Dienstes und des damit verbundenen Nutzens für den Endkunden
*Beschreibung der dazu erforderlichen IVS-Informationslogistikkette
*Identifizierung der an der Wertschöpfung zu beteiligenden IVS-Rollen mit
**dem Grad der Beteiligung
**den wichtigsten Anliegen und Geschäftsanforderungen (Business Cases)
**deren Bedenken und Perspektiven

=== Ergebnisdarstellung der Identifizierung der IVS-Rollen ===

Zur Ergebnisdarstellung stellt die IVS-Rahmenarchitektur zwei Templates bereit:

*'''Das IVS-Rollen-Map Template'''
**Das IVS-Rollen-Map Template ist ein '''IVS-Architekturdeliverable (siehe [[IVS-RollenMap-Template|IVS-Rollen Map]])''', das die Stereoptype von IVS-Akteuren und IVS-Stakeholdern deklariert und mit Ihren Geschäftsanliegen und IVS-Rollen beschreibt.
**Außerdem '''klassifiziert es die Bedeutung von IVS-Akteuren und IVS-Stakeholdern''', die sie über ihre Rolle für den IVS-Dienst bzw. die IVS-Dienste-Kategorie erlangen (Power-Grid).
*'''Das IVS-Rollen Template'''
**Das IVS-Rollen Template ist ein '''IVS-Architekturbaustein (siehe [[IVS-Rolle|IVS-Rolle]])''', mit dem Stereotype von IVS-Fähigkeiten und IVS-Verantwortlichkeiten, die für IVS-Wertschöpfung von IVS-Diensten typisch und erforderlich sind, bezeichnet und semantisch beschrieben werden.

=== Beispiel Rollen-Map ===

Beispiele von IVS-Rollenbeschreibungen von IVS-Akteurs-Stereotypen mit Hilfe des IVS-Rollen-Map-Templates zeigt folgende Tabelle:

{| border="1" class="wikitable"
|-
! IVS-Rolle für die IVS-Wertschöpfung
!
Sicht der IVS-Rolle

*'''H'''=hoheitlich
*'''Ö'''=Ökonomisch
*'''T'''=Technisch
*'''N'''=Nebenrolle

! Schlüsselanliegen der IVS-Rolle
! IVS-Capabilities/IVS-Verantwortlichkeiten
! Wertigkeit der IVS-Rolle (gemäß Power Grid)
!
IVS-Akteur bzw. IVS-Akteurs-Stereotyp

|- style="vertical-align:top"
| '''Verkehrsplanung'''
| style="text-align: center" | T
| Planerische Grundlagen für Verkehrsmanagement nach verkehrsplanerischen Grundsätzen schaffen
| Netz, Infrastruktur, Verkehrstechnische Unterlagen, VM-Strategien... planen und als Versorgungsdaten bereitstellen
| Key player
| Öffentlicher Straßenbetreiber
|- style="vertical-align:top"
| '''Runder Tisch'''
| style="text-align: center" | T
| Planerische Grundlagen für Zuständigkeitsübergreifendes Verkehrsmanagement nach verkehrsplanerischen Grundsätzen schaffen
| Zuständigkeitsübergreifende VM-Strategien planen und als Versorgungsdaten bereitstellen
| Key player
| Arbeitsgruppe zweier oder mehrerer Öffentlicher Straßenbetreiber
|- style="vertical-align:top"
| '''Betriebsdatenerfassung'''
| style="text-align: center" | T
| Hohe Verfügbarkeit der verkehrstechnischen Infrastruktur
| Betriebsdaten der verkehrstechnischen Infrastruktur detektieren
| Key player
| Öffentlicher Straßenbetreiber
|- style="vertical-align:top"
| '''Stellplatzerfassung'''
| style="text-align: center" | T
| Stellplätze nach wirtschaftlichen Gesichtspunkten vermieten
| Stellplatzangebot detektieren
| Key player
| Parkhausbetreiber
|- style="vertical-align:top"
| '''Datenerfassung Private'''
| style="text-align: center" | T
| Bestmögliche Information des individuellen Kunden (hohe Kundenzufriedenheit)
| Verkehrsdaten Stadt und Fernstraßen detektieren
| Keep satisfied
| Privater (Mobilitäts-)Dienstleister
|- style="vertical-align:top"
| '''Verkehrsdatenerfassung'''
| style="text-align: center" | T
| Qualitativ hochwertige Erfassung von verkehrsrelevanten Daten
| Vorhersehbare Ereignisse erfassen, Verkehrsdaten detektieren, unvorhersehbare Ereignisse detektieren
| Key player
| Öffentlicher Straßenbetreiber
|- style="vertical-align:top"
| '''Verkehrsmanagement'''
| style="text-align: center" | T
| Vermeidung von Überlastungen im Netz sowie schnelle und angemessene Reaktion auf unvorhersehbare Störungen im Netz
| Verkehrsdatenfusion, Verkehrsmodellierung, Betriebsdatenfusion, Strategieauswahl
| Key player
| Öffentlicher Straßenbetreiber
|- style="vertical-align:top"
| '''Verkehrsinformation'''
| style="text-align: center" | T
| Schnelle und kollektive Verbreitung von Verkehrsinformationen in Echtzeit mittels möglichst aller verfügbaren Informationskanäle (Broadcasting)
| Maßnahmen (und Routen) publizieren
| Key player
| Öffentlicher Straßenbetreiber
|- style="vertical-align:top"
| '''Verkehrsinformation Private'''
| style="text-align: center" | T
| Schnelle und personalisierte Verbreitung von Verkehrsinformationen in Echtzeit mittels individueller Informationskanäle
| Maßnahmen publizieren (private)
| Keep satisfied
| Privater Service Provider
|- style="vertical-align:top"
| '''Nationale Access-Point MDM'''
| style="text-align: center" | T
| Förderung des Datenaustausches zwischen IVS-Akteuren
| Maßnahmen und Strategien makeln
| Key player
| Öffentlicher oder privater Service Operator
|- style="vertical-align:top"
| '''Verkehrssteuerung'''
| style="text-align: center" | T
| Schnelles und effektives Umsetzen von Verkehrsmanagmentstrategien
| Aktoren schalten
| Key player
| Öffentlicher Straßenbetreiber
|- style="vertical-align:top"
| '''End-Nutzer individuell'''
| style="text-align: center" | T
| Erhalt von qualitativ hochwertigen, verlässlichen Informationen, die ihn in Echtzeit bei der Wahl seiner Route unterstützen
| Kollektive und individuelle Informationen verarbeiten
| Key player
| End-Nutzer
|- style="vertical-align:top"
| '''End-Nutzer kollektiv'''
| style="text-align: center" | T
| Erhalt von qualitativ hochwertigen, verlässlichen Informationen, die ihn in Echtzeit bei der Wahl seiner Route unterstützen
| Kollektive Informationen verarbeiten
| Key player
| End-Nutzerkollektiv
|- style="vertical-align:top"
| '''Verkehrsmanagement als End-Nutzer'''
| style="text-align: center" | T
| Zugriff auf qualitativ hochwertige Verkehrsinformationen in Echtzeit
| Verkehrsinformationen verarbeiten
| Key player
| Öffentlicher Straßenbetreiber als End-Nutzer
|- style="vertical-align:top"
| '''OCA - Open Traffic Systems City Association'''
| style="text-align: center" | N
| Unterstützung von und Teilhabe an Standards für zuständigkeitsübergreifendes Verkehrsmanagement
| Standards für zuständigkeitsübergreifendes Verkehrsmanagement
| Keep informed
| Öffentlicher Straßenbaulastträger
|- style="vertical-align:top"
| '''IVS-Dienst-Ersteller'''
| style="text-align: center" | Ö
| Erstellung von IVS-Diensten nach wirtschaftlichen und technischen Grundsätzen
| Beschaffung der Finanzmittel für und Erstellung von IVS-Diensten
| Key player
| Öffentlicher Baulastträger
|- style="vertical-align:top"
| '''IVS-Gesetzgeber'''
| style="text-align: center" | H
| Schaffung eindeutiger gesetzlicher Rahmenbedingungen für IVS-Dienste
| Legislative
| Keep satisfied
| Parlamentarische Institutionen
|- style="vertical-align:top"
| '''IVS-Dienste System-Lieferant'''
| style="text-align: center" | N
| Herstellung und Verkauf von wettbewerbsfähigen Systemen, Software und Infrastruktur von IVS-Diensten
| Herstellung, Lieferung, Implementierung und Unterhaltung sowie Vertrieb von Systemen, Software und Infrastruktur von IVS-Diensten
| Keep informed
| Hersteller von Systemen, Software und Infrastruktur von IVS-Diensten
|}

=== Beispiel Rollen-Beschreibung ===

Ein Beispiel für die Beschreibung eines IVS-Akteurs in einer konkreten IVS-Rolle mit Hilfe des IVS-Rollen-Templates zeigt folgende Tabelle:

{| class="wikitable" style="width: 100%;"
|-
! colspan="2" | Stammdaten der IVS-Rolle
|- style="vertical-align:top"
| style="width: 187px" | '''IVS-Rolle''' (für die IVS-Wertschöpfung)
| style="width: 440px" | '''Verkehrsmanagement Stadt ''' (Anwendung von Verkehrsmanagementstrategien im Zuständigkeitsbereich Stadt)
|- style="vertical-align:top"
| style="width: 187px" | '''Sicht der IVS-Rolle'''
| style="width: 440px" | Technische Sicht
|- style="vertical-align:top"
| style="width: 187px" | '''IVS-Akteur(e) bzw. IVS-Akteurs-Stereotyp(e)''' für diese IVS-Rolle:
| style="width: 440px" | Verkehrsmanagementabteilung des öffentlicher Straßenbetreibers Stadt (Amt für Verkehrsmanagement, Düsseldorf)
|-
! colspan="2" | Ziele und Interessen
|- style="vertical-align:top"
| style="width: 187px" | '''Verantwortungsbereich'''
| style="width: 440px" |
*Verantwortlich für die Auswahl und Anwendung von Verkehrsmanagmentstrategien als Beitrag zur Sicherstellung von Sicherheit und Komfort des Verkehrsablaufs des Verkehrsteilnehmers im städtischen Straßennetz
*Umsetzung und Einhaltung der Anforderungen, die aus dieser Rolle erwachsen.
*Beim Zuständigkeitsübergreifenden Verkehrsmanagement in der Rolle des Ansprechpartners und verantwortlichen IVS-Akteurs auf Seiten der Stadt.

|- style="vertical-align:top"
| style="width: 187px" | '''Ziele und Interessen '''der IVS-'''Rolle'''
| style="width: 440px" | Sicherstellung der Sicherheit und Leichtigkeit des Verkehrsablaufs für alle Nutzer des städtischen Straßennetzes.
|-
! colspan="2" | Aufgaben und Interessen
|- style="vertical-align:top"
| style="width: 187px" | '''Aufgaben im Zuständigkeitsübergreifenden Verkehrsmanagement'''
| style="width: 440px" |
Umsetzung der gemeinsam mit der Fernstraßenseite vereinbarten Verkehrsmanagementstrategien mit Wirkung im kommunalen Netzbereich. Diese können im Kontext eines Strategie- und Informationsverbundes mit anderen Straßenbetreibern (andere Kommune, Land) und/oder mit privaten Dienstanbietern erweitert werden. Unter dem Betrachtungsfokus des straßenbetreiber- und privatwirtschaftsübergreifenden Strategie- und Informationsverbundes, stehen folgende Aufgaben im Vordergrund:

*Strategiemanagement vorhersehbarer Ereignisse
*Management unvorhersehbarer Ereignisse
*Straßenbetreiberübergreifende Kooperation
**Anforderung von gemeinsam vereinbarten Schaltungen im Netz des jeweils anderen Zuständigkeitsbereichs. Strategieabgleich zwischen Zuständigkeiten auf Basis vordefinierten Strategien
**Austausch von Betriebszuständen und Meldungen
*Austausch von Verkehrsdaten (LOS, Q, V usw.) für das gesamte Netz oder auch nur für den Netzübergangsbereich
*Kooperation mit Privaten

Die vordergründige Anwendung des Zuständigkeitsübergreifenden Verkehrsmanagements ist die Alternativroutensteuerung. Im Kontext eines Straßenbetreibers und/oder privatwirtschaftsübergreifenden Verbundes müssen aber auch die Bedürfnisse von Privaten IVS-Akteuren durch z. B. Strategieabgleich, Bereitstellen von Verkehrsdaten, Meldungen und Betriebszuständen Rechnung getragen werden. Voraussetzung ist eine planerische und organisatorische Abstimmung von Maßnahmen im Vorfeld.

|- style="vertical-align:top"
| style="width: 187px" | '''Prozessbeteiligung'''
| style="width: 440px" |
*Abstimmung der Strategieauswahl mit Zuständigkeit Fernstraßen im Falle von Stau und besonderen Ereignissen (Maßnahmenaustauschliste)
*Austausch von Verkehrsdaten und Alternativrouten mit Privaten Service Providern (Strategiekonformes Routen)

|- style="vertical-align:top"
| style="width: 187px" | '''Interaktion mit anderen IVS-Rollen'''
| style="width: 440px" | Statische und dynamische Verkehrsmanagementstrategien und -informationen der Zuständigkeit Fernstraßen erheben und bereitstellen
|-
! colspan="2" | Daten und Informationen
|- style="vertical-align:top"
| style="width: 187px" | '''Benötigte Daten/Informationen'''
| style="width: 440px" | Verkehrszustand im Netz und Maßnahmenanforderungen
|- style="vertical-align:top"
| style="width: 187px" | '''Erzeugte Daten/Informationen'''
| style="width: 440px" | Aktualisierte Maßnahmenaustauschliste
|-
! colspan="2" | IVS-Capabilities
|- style="vertical-align:top"
| style="width: 187px" | '''IVS-Fähigkeiten'''
| style="width: 440px" |
*Erstellung und Visualisierung von Betriebszuständen und von zu einem Verkehrslagebericht aufbereitete Verkehrsdaten
*Senden und Empfangen von Maßnahmenaustauschlisten
*Senden und Empfangen von Bestätigungen von Maßnahmenanforderungen mittels Versand einer aktualisierten Maßnahmenaustauschliste
*Weitergabe von Routenempfehlungen.

|- style="vertical-align:top"
| style="width: 187px" | '''Voraussetzungen'''
| style="width: 440px" |
*Leistungsfähige straßenseitige und zentralenseitige IVS-Infrastruktur
*Leitstelle für Verkehrsmanagement mit online- und Realzeit- Interaktionsmöglichkeiten mit anderen IVS-Akteuren
*Für Zuständigkeitsübergreifendes Verkehrsmanagement ausgebildetes, erfahrenes Personal.

|}

=== Requirements Management als Hilfestellung zur Identifikation von Anforderungen an IVS-Rollen ===

Mithilfe des Requirements Managements können '''Anforderungen an IVS-Rollen identifiziert''' werden. Um Anforderungen zu ermitteln, kann die '''Technik der Business-Szenarios''' angewandt werden. Sie dient der Identifikation und Dokumentation von Anforderungen.

[[File:IVS-Anforderungen-Template 00-00-01-1.PNG|500px|IVS-Anforderung Template]]

Für die Formulierung der Requirements in natürlicher Sprache empfiehlt sich die Verwendung einer im Requirements Engineering erprobten und empfohlenen '''Satzschablone''':

[[File:Schablone ReqEng.jpg|thumb|center|500px|Requirements Schablone (Quelle: Pohl/Rupp (2015))]]

Vorteil der '''Satzschablone ist die klare Syntax''' und sie hilft außerdem dabei, '''übliche Fehler bei der Formulierung zu vermeiden'''.

== Literaturverzeichnis ==

<references />

----

[[Hauptseite|<< Zurück zur Hauptseite]]