IVS-Wiki - Benutzerbeiträge [de]

Ausgangssituation Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement IVS-Datenmodelle

2018-09-18T10:43:21Z

Albrecht:

== Einführung ==

IVS-Datenmodelle sind IVS-Architekturbausteine, die IVS-Informationsobjekte enthalten und - weit erforderlich - Referenzierungen zur Beschreibung von Orten verwenden. IVS-Datenmodelle werden für eine Domäne entwickelt und in IVS-Schnittstellen verwendet. Zur Erstellung eines Katalogs von IVS-Datenmodellen für zuständigkeitsübergreifendes Verkehrsmanagement kann der von Los 1 vorausgefüllte Katalog der IVS-Datenmodelle als Basis verwendet und entsprechend der im zuständigkeitsübergreifenden Verkehrsmanagement benötigten IVS-Datenmodelle erweitert bzw. reduziert werden. Die IVS-Datenmodelle werden nachfolgend für die beiden Szenarien Stadt-Fernstraße sowie Fernstraße-Fernstraße dargestellt und in folgende Kategorien unterteilt:

*'''Kern-Datenmodelle''': Datenmodelle, welche zwischen zuständigkeitsübergreifenden Prozessbestandteilen angesiedelt sind
*'''Flankierende Datenmodelle''': Datenmodelle, welche in den internen Teilprozessen der einzelnen Akteure angesiedelt sind

== Szenario Stadt -  Fernstraße ==

Basierend auf dem bereits von Los 1 vorausgefüllte Katalog der IVS-Datenmodelle werden im zuständigkeitsübergreifenden Verkehrsmanagement für das Szenario Stadt-Fernstraße folgenden IVS-Datenmodelle identifiziert.

{| border="1" cellpadding="1" cellspacing="1" width="935"
|-
! scope="col" style="width: 97px; vertical-align: bottom" | Name
| style="width: 290px; vertical-align: bottom" | '''Link zur Definition des Datenmodells'''
! scope="col" style="width: 206px; vertical-align: bottom" |
Domäne

(Anwendungsgebiet: Verkehrsmanagement, Straßenverkehrstechnik, Öffentlicher Verkehr ...)

! scope="col" style="vertical-align: bottom" | Beschreibung
|-
| style="width: 97px; vertical-align: top" | OTS2
| style="width: 290px; vertical-align: middle" |
[http://www.ocit.org/downloadOCIT-I.htm http://www.ocit.org/downloadOCIT-I.htm]

| style="width: 206px; vertical-align: top" | Verkehrsmanagement
| style="vertical-align: top" | Standard für Prozessdaten und Objekte für Verkehrsmanagement
|-
| style="width: 97px; vertical-align: top" | OCIT-Instations
| style="width: 290px; vertical-align: top" | [http://www.ocit.org/downloadOCIT-I.htm http://www.ocit.org/downloadOCIT-I.htm]
| style="vertical-align: top" | Verkehrsinformation, Verkehrsmanagement
| style="vertical-align: top" | Standard für Prozess- und Versorgungsdaten für Lichtsignalsteuerung
|-
| style="width: 97px; vertical-align: top" | DATEX II
| style="width: 290px; vertical-align: top" | [http://www.datex2.eu/ http://www.datex2.eu/]
| style="vertical-align: top" | Verkehrsmanagement
| style="vertical-align: top" | DATEX II ist ein Standard, der zum Austausch von Daten und Informationen zwischen Verkehrsmanagementzentralen entwickelt wurde
|}

== Szenario Fernstraße - Fernstraße ==

Basierend auf dem bereits von Los 1 vorausgefüllte Katalog der IVS-Datenmodelle werden im zuständigkeitsübergreifenden Verkehrsmanagement für das Szenario Fernstraße-Fernstraße folgenden IVS-Datenmodelle identifiziert.

=== IVS-Kern-Datenmodelle ===

{| width="935" border="1" cellspacing="1" cellpadding="1"
|-
! style="width: 73px; vertical-align: bottom" scope="col" | Name
| style="width: 314px; vertical-align: bottom" | '''Link zur Definition des Datenmodells'''
! style="width: 206px; vertical-align: bottom" scope="col" |
Domäne

(Anwendungsgebiet: Verkehrsmanagement, Straßenverkehrstechnik, Öffentlicher Verkehr ...)

! style="vertical-align: bottom" scope="col" | Beschreibung
|-
| style="width: 73px; vertical-align: top" | DATEX II
| style="width: 314px; vertical-align: top" |
[http://www.datex2.eu/ http://www.datex2.eu/]

| style="width: 206px; vertical-align: top" | Verkehrsmanagement
| style="vertical-align: top" | DATEX II ist ein Standard, der zum Austausch von Daten und Informationen zwischen Verkehrsmanagementzentralen entwickelt wurde
|-
| style="vertical-align: top" | Proprietär (ISM)
| style="vertical-align: top" |
Riegelhuth, G., Kirschfink, H., Dölger, R., Stüben, G. & Bohlander, F. (2010): Technische Grundlagen und Anwendungserfahrungen beim Korridormanagement mit dem Intermodalen/Interregionalen Strategie-Manager. In: Straßenverkehrstechnik 08/2010. Köln

| style="vertical-align: top" | Verkehrsmanagement
| style="vertical-align: top" | Der Intermodale Strategiemanager (ISM) ist ein Kommunikationswerkzeug, welches die Partner bei der Strategieumsetzung unterstützen soll.
|}

=== Flankierende IVS-Datenmodelle ===

{| border="1" cellpadding="1" cellspacing="1" width="935"
|-
! scope="col" style="width: 73px; vertical-align: bottom" | Name
| style="width: 314px; vertical-align: bottom" | '''Link zur Definition des Datenmodells'''
! scope="col" style="width: 206px; vertical-align: bottom" |
Domäne

(Anwendungsgebiet: Verkehrsmanagement, Straßenverkehrstechnik, Öffentlicher Verkehr ...)

! scope="col" style="vertical-align: bottom" | Beschreibung
|-
| style="width: 73px; vertical-align: top" | ITS-G5
| style="width: 314px; vertical-align: top" | [http://www.etsi.org/standards-search#page=1&search=&title=1&etsiNumber=1&content=1&version=0&onApproval=1&published=1&historical=1&startDate=1988-01-15&endDate=2016-03-19&harmonized=0&keyword=&TB=&stdType=&frequency=&mandate=M/453&sort=1 http://www.etsi.org/standards-search#page=1&search=&title=1&etsiNumber=1&content=1&version=0&onApproval=1&published=1&historical=1&startDate=1988-01-15&endDate=2016-03-19&harmonized=0&keyword=&TB=&stdType=&frequency=&mandate=M/453&sort=1]
| style="width: 206px; vertical-align: top" | Kooperative Systeme
| style="vertical-align: top" | ITS G5 ist eine Sammlung von Standards, die zum Austausch von Daten zwischen Fahrzeugen (C2C) und zwischen Fahrzeugen und Infrastruktur (C2I) verwendet werden
|-
| style="width: 73px; vertical-align: top" | TLS
| style="width: 314px; vertical-align: top" | [http://www.bast.de/DE/Verkehrstechnik/Fachthemen/v5-tls/tls-streckenstationen.html http://www.bast.de/DE/Verkehrstechnik/Fachthemen/v5-tls/tls-streckenstationen.html]
| style="width: 206px; vertical-align: top" | Straßenverkehrstechnik
| style="vertical-align: top" | Die Technischen Lieferbedingungen für Streckenstationen (TLS) sind ein Standard für den Aufbau von Verkehrsbeeinflussungsanalgen an Bundesfernstraßen.
|-
| style="vertical-align: top" | TMC
| style="vertical-align: top" | [http://tisa.org/technologies/tmc/ http://tisa.org/technologies/tmc/]
| style="vertical-align: top" | Verkehrsinformation
| style="vertical-align: top" | Der Traffic Message Channel (TMC) ist eine Applikation für das UKW Radio Data System (RDS), der zur Aussendung von Echtzeit-Verkehrs- und Wetterinformationen verwendet wird.
|-
| style="vertical-align: top" | csv
| style="vertical-align: top" | [https://de.onpage.org/wiki/CSV_(Dateiformat) https://de.onpage.org/wiki/CSV_%28Dateiformat%29]
| style="vertical-align: top" | Verkehrsinformation
| style="vertical-align: top" | CSV (comma-separate values) ist ein Textdateityp, mit dessen Hilfe auch große Mengen an strukturierten Verkehrsdaten erfasst, gespeichert und verarbeitet werden können.
|}

 

----

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

Diskussion:Hilfsmittel zur Darstellung der IVS-Datenarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement

2018-09-18T09:52:56Z

Albrecht: Die Seite wurde neu angelegt: „<parsererror xmlns="http://www.mozilla.org/newlayout/xml/parsererror.xml">XML Parsing Error: syntax error</parsererror>“

<parsererror xmlns="http://www.mozilla.org/newlayout/xml/parsererror.xml">XML Parsing Error: syntax error</parsererror>

IVS-Referenzarchitektur für Zuständigkeitsübergreifendes Verkehrsmanagement 1.0

2018-08-29T11:34:55Z

Albrecht:

== Vorbereitungsphase ==

=== Steuerungs- und Unterstützungsframeworks ===

Mit den Steuerungs- und Unterstützungsframeworks für IVS-Architektur werden generell IVS-Architekturprojekte motiviert, begründet und gestützt. Der Inhalt dieser Frameworks bildet im Prinzip auch den Geist, in dem IVS-Architekturprojekte durchgeführt werden.

Für die IVS-Rahmenarchitektur bilden der Europäische IVS-Aktionsplan und die IVS-Direktive sowie auf nationaler Ebene das IVS-Gesetz und der Nationale IVS-Aktionsplan Straße die wesentlichen Frameworks. Für die IVS-Referenzarchitektur für Zuständigkeitsübergreifendes Verkehrsmanagement setzen neben den rechtlichen Vorgaben auch interne Vorgaben der einzelnen Stakeholder und Akteure den rechtlichen Handlungsrahmen.

Ergebnis: [[PhaseV-Step3-Los3_SteuerungsUndUnterstützungsframeworks|IVS-Steuerungs- und Unterstützungsframeworks für Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== IVS-Glossar ===

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

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

Für das Glossar für Zuständigkeitsübergreifendes Verkehrsmanagement gilt:

*Die Begriffsbestimmungen für IVS-Architektur (siehe [[IVS-Architekturbausteine#IVS-Architektur...|Was ist IVS-Architektur? - Schlüsselbegriffe]] und [[IVS-Architekturbausteine|Begriffe für die IVS-Gestaltungsmerkmale von IVS-Architektur]]) werden auf Zuständigkeitsübergreifendes Verkehrsmanagement übertragen.
*[[IVS-Glossar#Begriffsdefinitionen|Allgemeine Begriffe aus Verkehr, Transport und Mobilität]], die keine spezifische IVS-Architektur-Semantik repräsentieren, werden für Zuständigkeitsübergreifendes Verkehrsmanagement ergänzt.

Ergebnis: [[Los3_Glossar|IVS-Glossar für Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== Architekturprinzipien ===

Prinzipien stellen Grundsätze dar, die nicht nur dauerhaft gelten, sondern auch selten geändert werden sollten. Sie beschreiben die Art und Weise, wie eine davon betroffene Organisation ihre Aufgaben zu erfüllen hat. Prinzipien können für verschiedene Ebenen entwickelt und definiert werden.

Zur Detaillierung werden IVS-Architekturprinzipien gemäß den Ebenen von IVS-Architektur in folgende Untergruppen aufgeteilt:

*Geschäftsprinzip
*Daten-/Informationsprinzip
*Anwendungsprinzip
*Technologieprinzip

Ergebnis: [[Los3_IVS-Architekturprinzipien|IVS-Architekturprinzipien für Zuständigkeitsübergreifendes Verkehrsmanagement]]

----

== Phase Architektur Vision ==

=== Aufsetzen eines Architekturprojekts ===

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

*den IVS-Betrachtungsgegenstand "Zuständigkeitsübergreifendes Verkehrsmanagement" semantisch zu beschreiben (was ist der IVS-Betrachtungsgegenstand Zuständigkeitsübergreifendes Verkehrsmanagement) und
*klare Grenzen zu ähnlichen bzw. angrenzenden IVS-Betrachtungsgegenständen des Zuständigkeitsübergreifenden Verkehrsmanagements zu ziehen und festzulegen ('''was ist drin, was ist nicht drin''').

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

*Eine IVS-Referenzarchitektur soll verschiedene Gestaltungskonzepte für eine IVS-Dienstekategorie vorweisen.
*Bei der IVS-Architektur eines realen IVS-Dienstes müssen verschiedene Implementierungskonzepte für einen spezifischen IVS-Dienst erstellt werden.

Ergebnisse:

==== IVS-Domäne für Zuständigkeitsübergreifendes Verkehrsmanagement ====

*[[IVS-Domäne_Zuständigkeitsübergreifenden_Verkehrsmanagements_-_Template|IVS-Domäne für Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== IVS-Dienste(-kategorie) für Zuständigkeitsübergreifendes Verkehrsmanagement ====

*[[IVS-Dienste_Los3|IVS-Dienste(-kategorie) für Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== Zuständigkeitsübergreifendes Verkehrsmanagement - Allgemeine Beschreibung ====

*[[Zuständigkeitsübergreifendes_Verkehrsmanagement_-_Allgemeine_Beschreibung|Zuständigkeitsübergreifendes Verkehrsmanagement - Allgemeine Beschreibung]]

=== Erfassen und Beschreibung 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 in die IVS-Wertschöpfung zu involvierenden IVS-Akteure und die zu beteiligenden IVS-Stakeholder erfasst und beschrieben werden.

Dazu ist es nützlich - in Vorbereitung für den Schritt Entwicklung einer IVS-Architekturvision - eine erste Vorstellung für den IVS-Dienst/die IVS-Dienstekategorie zugrunde zu legen und darüber die erforderlichen IVS-Rollen in der IVS-Wertschöpfungskette/im IVS-Wertschöpfungsnetzwerk zu veranschaulichen.

Zur Ergebnisdarstellung werden zwei IVS-Bausteine verwendet:

*Der Baustein IVS-Rollen-Map, mit dem Stereotype von IVS-Akteuren und IVS-Stakeholdern deklariert, mit ihren Geschäftsanliegen und IVS-Rollen beschrieben und die Bedeutung von IVS-Akteuren und IVS-Stakeholdern gemäß "Power-Grid" klassifiziert werden.

*Der Baustein IVS-Rolle, mit dem Stereotype von IVS-Fähigkeiten und IVS-Verantwortlichkeiten, die für die Bereitstellung und den Betrieb von IVS-Diensten typisch und erforderlich sind, bezeichnet und semantisch beschrieben werden.

Ergebnisse:

*[[PhaseA-Step2-Los3_ErfassungUndBeschreibungVonRollen|IVS-Rollen im Zuständigkeitsübergreifenden Verkehrsmanagement - Allgemeine Beschreibung]]
*[[IVS-Rollen_Los3|IVS-Rollen-Map und IVS-Rollen Power-Grid für Zuständigkeitsübergreifendes Verkehrsmanagement]]
*[[IVS-Business_Szenarios_und_IVS-Anforderungen_Los_3_-_Zuständigkeitsübergreifendes_Verkehrsmanagement|IVS-Business Szenarios und IVS-Anforderungen für Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== Ziele, strategische Einflussfaktoren und Rahmenbedingungen ===

==== IVS-Leitbilder ====

Die Akzeptanz von Maßnahmen des Verkehrsmanagements wird beim Verkehrsteilnehmer erhöht, wenn sich der Betrieb an seinen Mobilitätsbedürfnissen und tatsächlichen Wegen orientiert und nicht an Zuständigkeitsgrenzen endet oder das Erscheinungsbild wechselt. Bei den indirekt beteiligten IVS-Stakeholdern und IVS-Akteuren wird eine hohe Akzeptanz erwartet, weil die "IVS-Referenzarchitektur für Zuständigkeitsübergreifendes Verkehrsmanagement" die Planungs- und Investitionssicherheit verbessert (Vermeidung von Insellösungen) und interoperable, betrieblich effiziente Lösungen begünstigt.

Ergebnis: [[IVS-Leitbilder_Los3|IVS-Leitbilder für Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== IVS-Geschäftsziele ====

Das Straßen- und Verkehrswesen kann einen Beitrag dazu leisten, die Lebensqualität der einzelnen Individuen zu steigern. Diese Forderung wird durch Definition der vier Oberziele des Verkehrs bekräftigt:

*Erhöhung der Sicherheit,
*Befriedigung des Mobilitätsbedürfnisses,
*Schonung der Umwelt und
*Verbesserung der Wirtschaftlichkeit.

Das Zuständigkeitsübergreifende Verkehrsmanagement setzt an dieser Stelle an. Durch gezielte Maßnahmen oder Maßnahmenbündel, die den gleichzeitigen Einsatz mehrerer Verkehrssysteme und -mittel (multimodal) oder den Wechsel der Verkehrssysteme (intermodal) innerhalb und außerhalb des eigenen Zuständigkeitsbereichs berücksichtigen, sollen Probleme oder bestimmte Situationen im regionalen und/oder überregionalen Verkehrssystem reduziert bzw. verbessert werden.

Ergebnis: [[IVS-Geschäftsziele_Los3|IVS-Geschäftsziele für Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== IVS-Capabilities ===

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

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

Grobe Vorstellungen für die Wertschöpfungskette des Zuständigkeitsübergreifenden Verkehrsmanagements zeigen folgenden Abbildungen:

<gallery mode="packed-hover">
File:TMValueChain.png | Wertschöpfungskette Verkehrsmanagement
File:WertschöpfungImSystemStrasse.png | System Strasse (Quelle Hessen Mobil)
</gallery>

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

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

Ergebnis: [[IVS-Capabilities_Los3|IVS-Capabilities für Zuständigkeitsübergreifenden Verkehrsmanagement]]

=== IVS-Architektur Vision ===

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

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

*Die Idee (für den IVS-Dienst),

:
::die die Kernaufgabe, die Nutzung und die Schnittstellen, das heißt den Kontext des zu erstellenden IVS-Dienstes aufzeigt.

*Einflussfaktoren und Randbedingungen

:
::wie funktionale und nicht-funktionale Anforderungen, organisatorische und technische Einflüsse.

*Lösungsstrategien

:
::halten die ersten Entscheidungen, wesentliche Architektur-Muster und Konzepte fest. Erste Architektursichten können entstehen, um die Lösungsstrategien zu verdeutlichen.

Ergebnis: [[IVS-Archtekturvision_Los3|IVS-Architektur Vision für Zuständigkeitsübergreifendes Verkehrsmanagement]]

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

Um den IVS-Dienst "Zuständigkeitsübergreifendes Verkehrsmanagement" realisieren zu können, müssen verschiedene IVS-Akteure zusammenarbeiten, sobald für eine Routenempfehlung die Aktorik, die Sensorik und/oder die Alternativroute oder Teile davon benötigt werden, die nicht in den eigenen Zuständigkeitsbereich fallen. Somit hängt die Interoperabilität von IVS-Akteuren im IVS-Dienst "Zuständigkeitsübergreifendes Verkehrsmanagement" im Wesentlichen davon ab, wie nahtlos diese zusammenarbeiten bzw. wie interoperabel diese ihre IVS-Geschäftsfähigkeiten gestalten können. Interoperabilität wird somit in den Mittelpunkt der architekturellen Bemühungen gestellt und die Bereitstellung von Interoperabilitäts-Bausteinen zum Kernziel von IVS-Architektur.

Ergebnis: [[IVS-Wertbeitrag_Los3|Wertbeitrag und KPIs von IVS-Architektur für Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== Risiken der Einführung einer IVS-Referenzarchitektur für zuständigkeitsübergreifendes Verkehrsmanagement ===

Die Einführung einer IVS-Architektur birgt auch Risiken. Das Risikomanagement soll genutzt wer-den, um die Risiken Einführung einer IVS-Referenzarchitektur für Zuständigkeitsübergreifenden Verkehrsmanagements zu erkennen, zu beurteilen und handzuhaben.

Ergebnis: [[Risiken_Los3|Risiken der Einführung einer IVS-Referenzarchitektur für Zuständigkeitsübergreifendes Verkehrsmanagement]]

----

== Phase Geschäftsarchitektur ==

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

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

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

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

*für die Sicht "IVS-Wertschöpfungskette/IVS-Wertschöpfungsnetzwerk"

:
:*Darstellung als '''IVS-Rollenmatrix''', wie sie im Projekt [[Media:ÖV-IVS_Schlussbericht_März_2014.pdf|Entwicklung einer ÖV-IVS-Rahmenarchitektur in Deutschland unter Einbindung Europäischer IVS-Richtlinien mit ÖV-Relevanz<ref>Kieslich, Wolfgang; Albrecht, Hanfried; Dinkel, Alexander u.a. (2014): Entwicklung einer für ÖV-IVS-Architektur in Deutschland unter Einbindung Europäischer IVS-Richtlinien mit ÖPNV-Relevanz. Schlussbericht. Im Auftrag des Bundesministeriums für Verkehr und digitale Infrastruktur. München.</ref>]] entwickelt wurde. Eine Anleitung findet sich [[Aufbau_von_IVS-Wertschöfungsketten_und_-netzwerke|'''hier''']].
:*Darstellung als '''Rollen/Capability-Diagramm'''. Ein Beispiel finden Sie '''[[PhaseB-Step2-Los3#Sicht_.22Wertsch.C3.B6pfungskette.2FWertsch.C3.B6pfungsnetzwerk.22_f.C3.BCr_Zust.C3.A4ndigkeits.C3.BCbergreifendes_Verkehrsmanagement|hier]]'''.

*für die Sicht "IVS-Governance"

:
::Für die Darstellung wird ein Textdokument empfohlen. Eine Beschreibungsstruktur findet sich [[IVS-Governance|hier]].

*für die Sicht "IVS-Geschäftsprozesse"

:
::für die Darstellung und Visualisierung der IVS-Geschäftsprozessarchitektur wird grundsätzlich ein Prozessmodellierungs-Ansatz gewählt. Durch das Aufschlüsseln von Geschäftsfunktionen und Geschäftsdiensten mit Hilfe der Prozessmodellierung wird die Identifizierung der Schlüssel-Prozesse und der nachgeordneten Dienste und Funktionen ermöglicht.
::*Ein Template zur Beschreibung von Geschäftsprozessen findet sich [[IVS-Geschäftsprozess|hier]].
::*Zur Modellierung von Geschäftsprozessen und Geschäftsfunktionen wird die Spezifikationssprache Business Process Model and Notation (BPMN) verwendet. Eine Anleitung findet sich [[Geschäftsprozessdiagramm|hier]].

Ergebnis: [[Hilfsmittel_und_Werkzeuge_Los3|Hilfsmittel zur Darstellung der IVS-Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== Ausgangssituation der IVS-Geschäftsarchitektur ===

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

*Sicht "IVS-Wertschöpfungsketten und -netzwerke"

:
::Die [[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.

*Sicht "IVS-Governance"

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

*Sicht "IVS-Geschäftsprozesse"

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

Ergebnisse:

*[[Ausgangssituation_Geschäftsarchitektur_Los_3_-_Sicht_Wertschöpfungsnetzwerk|Ausgangssituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Wertschöpfungsnetzwerk]]
*[[Ausgangssituation_Geschäftsarchitektur_Los_3_-_Sicht_Governance|Ausgangssituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Governance]]
*[[Ausgangssituation_Geschäftsarchitektur_Los_3_-_Sicht_Geschäftsprozesse|Ausgangssituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Geschäftsprozesse]]

=== Zielsituation der IVS-Geschäftsarchitektur ===

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

*Sicht [[Aufbau_von_IVS-Wertschöfungsketten_und_-netzwerke|"IVS-Wertschöpfungskette/IVS-Wertschöpfungsnetzwerk"]]

:
::Identifizierung, Darstellung und Beschreibung, über welche Bestandteile (Teildienste) der IVS-Dienst gebildet wird, welche IVS-Rollen daran beteiligt sein müssen und welche Anforderungen (IVS-Capabilities) an diese gestellt werden.

*Sicht [[IVS-Governance|"IVS-Governance"]]

:
::Beschreibung, auf welcher gesetzlichen, rechtlichen und vertraglichen Grundlage der IVS-Dienst und die Zusammenarbeit der IVS-Akteure zustande kommen und wie letztere operativ geführt und gesteuert wird.

*Sicht [[IVS-Geschäftsprozesse_und_Wertschöpfungsnetzwerke|"IVS-Geschäftsprozesse"]]

:
::Darstellung und Beschreibung, über welche Schlüssel-Geschäftsprozesse der IVS-Dienst operationalisiert wird.

Weitere Sichten können projektspezifisch aufgebaut und beschrieben werden.

Ergebnisse:

*[[Zielsituation_Geschäftsarchitektur_Los_3_-_Sicht_Wertschöpfungsnetzwerk|Zielsituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Wertschöpfungsnetzwerk]]
*[[Zielsituation_Geschäftsarchitektur_Los_3_-_Sicht_Governance|Zielsituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Governance]]
*[[Zielsituation_Geschäftsarchitektur_Los_3_-_Sicht_Geschäftsprozesse|Zielsituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Geschäftsprozesse]]

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

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

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

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

Ergebnisse:

*[[Gap-Analyse_Geschäftsarchitektur_Los_3_-_Sicht_Wertschöpfungsnetzwerk|Gap-Analyse Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Wertschöpfungsnetzwerk]]
*[[Gap-Analyse_Geschäftsarchitektur_Los_3_-_Sicht_Governance|Gap-Analyse Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Governance]]
*[[Gap-Analyse_Geschäftsarchitektur_Los_3_-_Sicht_Geschäftsprozesse|Gap-Analyse Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Geschäftsprozesse]]

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

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

Zur Beschreibung der einzelnen Arbeitsschritte sowie zur Festlegung von zeitlichen und inhaltlichen Abhängigkeiten zwischen den einzelnen Arbeitsschritten wird der Katalog [[Media:Architektur-Roadmap_00-00-01.docx|Architektur-Roadmap]] verwendet.

Ergebnis: [[IVS-Architektur-Roadmap_Los3|IVS-Architektur-Roadmap - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

----

== Phase IVS-Datenarchitektur ==

=== Hilfsmittel, Sichten und Werkzeuge für IVS-Datenarchitektur ===

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

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

Ergebnis: [[Hilfsmittel_zur_Darstellung_der_IVS-Datenarchitektur_-_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement|Hilfsmittel zur Darstellung der IVS-Datenarchitektur für Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== Ausgangssituation der IVS-Datenarchitektur ===

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

Ergebnisse - Kataloge:

*[[Ausgangssituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement|Ausgangssituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Informationsobjekte]]
*[[Ausgangssituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_IVS-Datenmodelle|Ausgangssituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Datenmodelle]]
*[[Ausgangssituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_IVS-Ortsreferenzierung|Ausgangssituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Ortsreferenzierungen]]

Ergebnisse - Matrizen:

*[[Ausgangssituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_Matrix_IVS-Informationsobjekte/_IVS-Datenmodelle|Ausgangssituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Matrix IVS-Informationsobjekte/Datenmodelle]]
*[[Ausgangssituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_Matrix_IVS-Datenmodelle/_IVS-Ortsreferenzierungssysteme|Ausgangssituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Matrix IVS-Datenmodelle/ IVS-Ortsreferenzierungssysteme]]

=== Zielsituation der IVS-Datenarchitektur ===

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

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

Ergebnisse - Kataloge:

*[[Zielsituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Informationsobjekte|Zielsituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Informationsobjekte]]
*[[Zielsituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Datenmodelle|Zielsituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Datenmodelle]]
*[[Zielsituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Ortsreferenzierung|Zielsituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Ortsreferenzierung]]

Ergebnisse - Matrizen:

*[[Zielsituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_Matrix_IVS-Informationsobjekte/_IVS-Datenmodelle|Zielsituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Matrix IVS-Informationsobjekte/Datenmodelle]]
*[[Zielsituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_Matrix_IVS-Datenmodelle/_IVS-Ortsreferenzierungssysteme|Zielsituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Matrix IVS-Datenmodelle/ IVS-Ortsreferenzierungssysteme]]

=== Gap-Analyse für die IVS-Datenarchitektur ===

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

Ergebnisse:

*[[Gap-Analyse_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Informationsobjekte|Gap-Analyse IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Informationsobjekte]]
*[[Gap-Analyse_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Datenmodelle|Gap-Analyse IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Datenmodelle]]
*[[Gap-Analyse_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Ortsreferenzierungssysteme|Gap-Analyse IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Ortsreferenzierungssysteme]]

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

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

Ergebnis: [[IVS-Architektur-Roadmap_-_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Datenarchitektur|IVS-Architektur-Roadmap - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Datenarchitektur]]

----

== Phase IVS-Anwendungsarchitektur ==

=== Hilfsmittel, Sichten und Werkzeuge für IVS-Anwendungsarchitektur ===

Die IVS-Anwendungsarchitektur fokussiert IVS-Anwendungen und deren IVS-Schnittstellen im Zuständigkeitsübergreifenden Verkehrsmanagement, die für die Ausführung der zuständigkeitsübergreifenden IVS-Geschäftsprozesse erforderlich sind.

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

Für die Darstellung der Anwendungsarchitektur im Zuständigkeitsübergreifenden Verkehrsmanagement schlägt die IVS-Rahmenarchitektur folgende Modellierungsprinzipien bzw. -werkzeuge vor:

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

Ergebnis: [[Hilfsmittel_zur_Darstellung_der_IVS-Anwendungsarchitektur_-_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement|Hilfsmittel zur Darstellung der IVS-Anwendungsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== Ausgangssituation der IVS-Anwendungsarchitektur ===

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

Ergebnis: [[Ausgangssituation_Anwendungsarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement|Ausgangssituation IVS-Anwendungsarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== Zielsituation der IVS-Anwendungsarchitektur ===

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

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

Ergebnis: [[Zielsituation_Anwendungsarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Anwendung|Zielsituation IVS-Anwendungsarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== Gap-Analyse für die IVS-Anwendungsarchitektur ===

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

Ergebnis: [[Gap-Analyse_Anwendungsarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Anwendung|Gap-Analyse IVS-Anwendungsarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

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

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

Ergebnis: [[IVS-Architektur-Roadmap_-_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Anwendungsarchitektur|IVS-Architektur-Roadmap - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Anwendungsarchitektur]]

----

== Phase IVS-Technologiearchitektur ==

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

== Literaturverzeichnis ==

<references />

----

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

IVS-Referenzarchitektur für Zuständigkeitsübergreifendes Verkehrsmanagement 1.0

2018-08-29T11:00:53Z

Albrecht:

== Vorbereitungsphase ==

=== Steuerungs- und Unterstützungsframeworks ===

Mit den Steuerungs- und Unterstützungsframeworks für IVS-Architektur werden generell IVS-Architekturprojekte motiviert, begründet und gestützt. Der Inhalt dieser Frameworks bildet im Prinzip auch den Geist, in dem IVS-Architekturprojekte durchgeführt werden.

Für die IVS-Rahmenarchitektur bilden der Europäische IVS-Aktionsplan und die IVS-Direktive sowie auf nationaler Ebene das IVS-Gesetz und der Nationale IVS-Aktionsplan Straße die wesentlichen Frameworks. Für die IVS-Referenzarchitektur für Zuständigkeitsübergreifendes Verkehrsmanagement setzen neben den rechtlichen Vorgaben auch interne Vorgaben der einzelnen Stakeholder und Akteure den rechtlichen Handlungsrahmen.

Ergebnis: [[PhaseV-Step3-Los3_SteuerungsUndUnterstützungsframeworks|IVS-Steuerungs- und Unterstützungsframeworks für Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== IVS-Glossar ===

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

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

Für das Glossar für Zuständigkeitsübergreifendes Verkehrsmanagement gilt:

*Die Begriffsbestimmungen für IVS-Architektur (siehe [[IVS-Architekturbausteine#IVS-Architektur...|Was ist IVS-Architektur? - Schlüsselbegriffe]] und [[IVS-Architekturbausteine|Begriffe für die IVS-Gestaltungsmerkmale von IVS-Architektur]]) werden auf Zuständigkeitsübergreifendes Verkehrsmanagement übertragen.
*[[IVS-Glossar#Begriffsdefinitionen|Allgemeine Begriffe aus Verkehr, Transport und Mobilität]], die keine spezifische IVS-Architektur-Semantik repräsentieren, werden für Zuständigkeitsübergreifendes Verkehrsmanagement ergänzt.

Ergebnis: [[Los3_Glossar|IVS-Glossar für Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== Architekturprinzipien ===

Prinzipien stellen Grundsätze dar, die nicht nur dauerhaft gelten, sondern auch selten geändert werden sollten. Sie beschreiben die Art und Weise, wie eine davon betroffene Organisation ihre Aufgaben zu erfüllen hat. Prinzipien können für verschiedene Ebenen entwickelt und definiert werden.

Zur Detaillierung werden IVS-Architekturprinzipien gemäß den Ebenen von IVS-Architektur in folgende Untergruppen aufgeteilt:

*Geschäftsprinzip
*Daten-/Informationsprinzip
*Anwendungsprinzip
*Technologieprinzip

Ergebnis: [[Los3_IVS-Architekturprinzipien|IVS-Architekturprinzipien für Zuständigkeitsübergreifendes Verkehrsmanagement]]

----

== Phase Architektur Vision ==

=== Aufsetzen eines Architekturprojekts ===

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

*den IVS-Betrachtungsgegenstand "Zuständigkeitsübergreifendes Verkehrsmanagement" semantisch zu beschreiben (was ist der IVS-Betrachtungsgegenstand Zuständigkeitsübergreifendes Verkehrsmanagement) und
*klare Grenzen zu ähnlichen bzw. angrenzenden IVS-Betrachtungsgegenständen des Zuständigkeitsübergreifenden Verkehrsmanagements zu ziehen und festzulegen ('''was ist drin, was ist nicht drin''').

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

*Eine IVS-Referenzarchitektur soll verschiedene Gestaltungskonzepte für eine IVS-Dienstekategorie vorweisen.
*Bei der IVS-Architektur eines realen IVS-Dienstes müssen verschiedene Implementierungskonzepte für einen spezifischen IVS-Dienst erstellt werden.

Ergebnisse:

==== IVS-Domäne für Zuständigkeitsübergreifendes Verkehrsmanagement ====

*[[IVS-Domäne_Zuständigkeitsübergreifenden_Verkehrsmanagements_-_Template|IVS-Domäne für Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== IVS-Dienste(-kategorie) für Zuständigkeitsübergreifendes Verkehrsmanagement ====

*[[IVS-Dienste_Los3|IVS-Dienste(-kategorie) für Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== Zuständigkeitsübergreifendes Verkehrsmanagement - Allgemeine Beschreibung ====

*[[Zuständigkeitsübergreifendes_Verkehrsmanagement_-_Allgemeine_Beschreibung|Zuständigkeitsübergreifendes Verkehrsmanagement - Allgemeine Beschreibung]]

=== Erfassen und Beschreibung 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 in die IVS-Wertschöpfung zu involvierenden IVS-Akteure und die zu beteiligenden IVS-Stakeholder erfasst und beschrieben werden.

Dazu ist es nützlich - in Vorbereitung für den Schritt Entwicklung einer IVS-Architekturvision - eine erste Vorstellung für den IVS-Dienst/die IVS-Dienstekategorie zugrunde zu legen und darüber die erforderlichen IVS-Rollen in der IVS-Wertschöpfungskette/im IVS-Wertschöpfungsnetzwerk zu veranschaulichen.

Zur Ergebnisdarstellung werden zwei IVS-Bausteine verwendet:

*Der Baustein IVS-Rollen-Map, mit dem Stereotype von IVS-Akteuren und IVS-Stakeholdern deklariert, mit ihren Geschäftsanliegen und IVS-Rollen beschrieben und die Bedeutung von IVS-Akteuren und IVS-Stakeholdern gemäß "Power-Grid" klassifiziert werden.

*Der Baustein IVS-Rolle, mit dem Stereotype von IVS-Fähigkeiten und IVS-Verantwortlichkeiten, die für die Bereitstellung und den Betrieb von IVS-Diensten typisch und erforderlich sind, bezeichnet und semantisch beschrieben werden.

Ergebnisse:

*[[PhaseA-Step2-Los3_ErfassungUndBeschreibungVonRollen|IVS-Rollen im Zuständigkeitsübergreifenden Verkehrsmanagement - Allgemeine Beschreibung]]
*[[IVS-Rollen_Los3|IVS-Rollen-Map und IVS-Rollen Power-Grid für Zuständigkeitsübergreifendes Verkehrsmanagement]]
*[[IVS-Business_Szenarios_und_IVS-Anforderungen_Los_3_-_Zuständigkeitsübergreifendes_Verkehrsmanagement|IVS-Business Szenarios und IVS-Anforderungen für Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== Ziele, strategische Einflussfaktoren und Rahmenbedingungen ===

==== IVS-Leitbilder ====

Die Akzeptanz von Maßnahmen des Verkehrsmanagements wird beim Verkehrsteilnehmer erhöht, wenn sich der Betrieb an seinen Mobilitätsbedürfnissen und tatsächlichen Wegen orientiert und nicht an Zuständigkeitsgrenzen endet oder das Erscheinungsbild wechselt. Bei den indirekt beteiligten IVS-Stakeholdern und IVS-Akteuren wird eine hohe Akzeptanz erwartet, weil die "IVS-Referenzarchitektur für Zuständigkeitsübergreifendes Verkehrsmanagement" die Planungs- und Investitionssicherheit verbessert (Vermeidung von Insellösungen) und interoperable, betrieblich effiziente Lösungen begünstigt.

Ergebnis: [[IVS-Leitbilder_Los3|IVS-Leitbilder für Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== IVS-Geschäftsziele ====

Das Straßen- und Verkehrswesen kann einen Beitrag dazu leisten, die Lebensqualität der einzelnen Individuen zu steigern. Diese Forderung wird durch Definition der vier Oberziele des Verkehrs bekräftigt:

*Erhöhung der Sicherheit,
*Befriedigung des Mobilitätsbedürfnisses,
*Schonung der Umwelt und
*Verbesserung der Wirtschaftlichkeit.

Das Zuständigkeitsübergreifende Verkehrsmanagement setzt an dieser Stelle an. Durch gezielte Maßnahmen oder Maßnahmenbündel, die den gleichzeitigen Einsatz mehrerer Verkehrssysteme und -mittel (multimodal) oder den Wechsel der Verkehrssysteme (intermodal) innerhalb und außerhalb des eigenen Zuständigkeitsbereichs berücksichtigen, sollen Probleme oder bestimmte Situationen im regionalen und/oder überregionalen Verkehrssystem reduziert bzw. verbessert werden.

Ergebnis: [[IVS-Geschäftsziele_Los3|IVS-Geschäftsziele für Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== IVS-Capabilities ===

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

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

Grobe Vorstellungen für die Wertschöpfungskette des Zuständigkeitsübergreifenden Verkehrsmanagements zeigen folgenden Abbildungen:

<gallery mode="packed-hover">
File:TMValueChain.png | Wertschöpfungskette Verkehrsmanagement
File:WertschöpfungImSystemStrasse.png | System Strasse (Quelle Hessen Mobil)
</gallery>

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

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

Ergebnis: [[IVS-Capabilities_Los3|IVS-Capabilities für Zuständigkeitsübergreifenden Verkehrsmanagement]]

=== IVS-Architektur Vision ===

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

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

*Die Idee (für den IVS-Dienst),

:
::die die Kernaufgabe, die Nutzung und die Schnittstellen, das heißt den Kontext des zu erstellenden IVS-Dienstes aufzeigt.

*Einflussfaktoren und Randbedingungen

:
::wie funktionale und nicht-funktionale Anforderungen, organisatorische und technische Einflüsse.

*Lösungsstrategien

:
::halten die ersten Entscheidungen, wesentliche Architektur-Muster und Konzepte fest. Erste Architektursichten können entstehen, um die Lösungsstrategien zu verdeutlichen.

Ergebnis: [[IVS-Archtekturvision_Los3|IVS-Architektur Vision für Zuständigkeitsübergreifendes Verkehrsmanagement]]

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

Um den IVS-Dienst "Zuständigkeitsübergreifendes Verkehrsmanagement" realisieren zu können, müssen verschiedene IVS-Akteure zusammenarbeiten, sobald für eine Routenempfehlung die Aktorik, die Sensorik und/oder die Alternativroute oder Teile davon benötigt werden, die nicht in den eigenen Zuständigkeitsbereich fallen. Somit hängt die Interoperabilität von IVS-Akteuren im IVS-Dienst "Zuständigkeitsübergreifendes Verkehrsmanagement" im Wesentlichen davon ab, wie nahtlos diese zusammenarbeiten bzw. wie interoperabel diese ihre IVS-Geschäftsfähigkeiten gestalten können. Interoperabilität wird somit in den Mittelpunkt der architekturellen Bemühungen gestellt und die Bereitstellung von Interoperabilitäts-Bausteinen zum Kernziel von IVS-Architektur.

Ergebnis: [[IVS-Wertbeitrag_Los3|Wertbeitrag und KPIs von IVS-Architektur für Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== Risiken der Einführung einer IVS-Referenzarchitektur für zuständigkeitsübergreifendes Verkehrsmanagement ===

Die Einführung einer IVS-Architektur birgt auch Risiken. Das Risikomanagement soll genutzt wer-den, um die Risiken Einführung einer IVS-Referenzarchitektur für Zuständigkeitsübergreifenden Verkehrsmanagements zu erkennen, zu beurteilen und handzuhaben.

Ergebnis: [[Risiken_Los3|Risiken der Einführung einer IVS-Referenzarchitektur für Zuständigkeitsübergreifendes Verkehrsmanagement]]

----

== Phase Geschäftsarchitektur ==

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

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

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

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

*für die Sicht "IVS-Wertschöpfungskette/IVS-Wertschöpfungsnetzwerk"

:
:*Darstellung als '''IVS-Rollenmatrix''', wie sie im Projekt [[Media:ÖV-IVS_Schlussbericht_März_2014.pdf|Entwicklung einer ÖV-IVS-Rahmenarchitektur in Deutschland unter Einbindung Europäischer IVS-Richtlinien mit ÖV-Relevanz<ref>Kieslich, Wolfgang; Albrecht, Hanfried; Dinkel, Alexander u.a. (2014): Entwicklung einer für ÖV-IVS-Architektur in Deutschland unter Einbindung Europäischer IVS-Richtlinien mit ÖPNV-Relevanz. Schlussbericht. Im Auftrag des Bundesministeriums für Verkehr und digitale Infrastruktur. München.</ref>]] entwickelt wurde. Eine Anleitung findet sich [[Aufbau_von_IVS-Wertschöfungsketten_und_-netzwerke|'''hier''']].
:*Darstellung als '''Rollen/Capability-Diagramm'''. Ein Beispiel finden Sie '''[[PhaseB-Step2-Los3#Sicht_.22Wertsch.C3.B6pfungskette.2FWertsch.C3.B6pfungsnetzwerk.22_f.C3.BCr_Zust.C3.A4ndigkeits.C3.BCbergreifendes_Verkehrsmanagement|hier]]'''.

*für die Sicht "IVS-Governance"

:
::Für die Darstellung wird ein Textdokument empfohlen. Eine Beschreibungsstruktur findet sich [[IVS-Governance|hier]].

*für die Sicht "IVS-Geschäftsprozesse"

:
::für die Darstellung und Visualisierung der IVS-Geschäftsprozessarchitektur wird grundsätzlich ein Prozessmodellierungs-Ansatz gewählt. Durch das Aufschlüsseln von Geschäftsfunktionen und Geschäftsdiensten mit Hilfe der Prozessmodellierung wird die Identifizierung der Schlüssel-Prozesse und der nachgeordneten Dienste und Funktionen ermöglicht.
::*Ein Template zur Beschreibung von Geschäftsprozessen findet sich [[IVS-Geschäftsprozess|hier]].
::*Zur Modellierung von Geschäftsprozessen und Geschäftsfunktionen wird die Spezifikationssprache Business Process Model and Notation (BPMN) verwendet. Eine Anleitung findet sich [[Geschäftsprozessdiagramm|hier]].

Ergebnis: [[Hilfsmittel_und_Werkzeuge_Los3|Hilfsmittel zur Darstellung der IVS-Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== Ausgangssituation der IVS-Geschäftsarchitektur ===

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

*Sicht "IVS-Wertschöpfungsketten und -netzwerke"

:
::Die [[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.

*Sicht "IVS-Governance"

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

*Sicht "IVS-Geschäftsprozesse"

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

Ergebnisse:

*[[Ausgangssituation_Geschäftsarchitektur_Los_3_-_Sicht_Wertschöpfungsnetzwerk|Ausgangssituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Wertschöpfungsnetzwerk]]
*[[Ausgangssituation_Geschäftsarchitektur_Los_3_-_Sicht_Governance|Ausgangssituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Governance]]
*[[Ausgangssituation_Geschäftsarchitektur_Los_3_-_Sicht_Geschäftsprozesse|Ausgangssituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Geschäftsprozesse]]

=== Zielsituation der IVS-Geschäftsarchitektur ===

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

*Sicht [[Aufbau_von_IVS-Wertschöfungsketten_und_-netzwerke|"IVS-Wertschöpfungskette/IVS-Wertschöpfungsnetzwerk"]]

:
::Identifizierung, Darstellung und Beschreibung, über welche Bestandteile (Teildienste) der IVS-Dienst gebildet wird, welche IVS-Rollen daran beteiligt sein müssen und welche Anforderungen (IVS-Capabilities) an diese gestellt werden.

*Sicht [[IVS-Governance|"IVS-Governance"]]

:
::Beschreibung, auf welcher gesetzlichen, rechtlichen und vertraglichen Grundlage der IVS-Dienst und die Zusammenarbeit der IVS-Akteure zustande kommen und wie letztere operativ geführt und gesteuert wird.

*Sicht [[IVS-Geschäftsprozesse_und_Wertschöpfungsnetzwerke|"IVS-Geschäftsprozesse"]]

:
::Darstellung und Beschreibung, über welche Schlüssel-Geschäftsprozesse der IVS-Dienst operationalisiert wird.

Weitere Sichten können projektspezifisch aufgebaut und beschrieben werden.

Ergebnisse:

*[[Zielsituation_Geschäftsarchitektur_Los_3_-_Sicht_Wertschöpfungsnetzwerk|Zielsituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Wertschöpfungsnetzwerk]]
*[[Zielsituation_Geschäftsarchitektur_Los_3_-_Sicht_Governance|Zielsituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Governance]]
*[[Zielsituation_Geschäftsarchitektur_Los_3_-_Sicht_Geschäftsprozesse|Zielsituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Geschäftsprozesse]]

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

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

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

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

Ergebnisse:

*[[Gap-Analyse_Geschäftsarchitektur_Los_3_-_Sicht_Wertschöpfungsnetzwerk|Gap-Analyse Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Wertschöpfungsnetzwerk]]
*[[Gap-Analyse_Geschäftsarchitektur_Los_3_-_Sicht_Governance|Gap-Analyse Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Governance]]
*[[Gap-Analyse_Geschäftsarchitektur_Los_3_-_Sicht_Geschäftsprozesse|Gap-Analyse Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Geschäftsprozesse]]

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

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

Zur Beschreibung der einzelnen Arbeitsschritte sowie zur Festlegung von zeitlichen und inhaltlichen Abhängigkeiten zwischen den einzelnen Arbeitsschritten wird der Katalog [[Media:Architektur-Roadmap_00-00-01.docx|Architektur-Roadmap]] verwendet.

Ergebnis: [[IVS-Architektur-Roadmap_Los3|IVS-Architektur-Roadmap - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

----

== Phase IVS-Datenarchitektur ==

=== Hilfsmittel, Sichten und Werkzeuge für IVS-Datenarchitektur ===

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

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

Ergebnis: [[Hilfsmittel_zur_Darstellung_der_IVS-Datenarchitektur_-_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement|Hilfsmittel zur Darstellung der IVS-Datenarchitektur für Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== Ausgangssituation der IVS-Datenarchitektur ===

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

Ergebnisse - Kataloge:

*[[Ausgangssituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement|Ausgangssituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Informationsobjekte]]
*[[Ausgangssituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_IVS-Datenmodelle|Ausgangssituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Datenmodelle]]
*[[Ausgangssituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_IVS-Ortsreferenzierung|Ausgangssituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Ortsreferenzierungen]]

Ergebnisse - Matrizen:

*[[Ausgangssituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_Matrix_IVS-Informationsobjekte/_IVS-Datenmodelle|Ausgangssituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Matrix IVS-Informationsobjekte/Datenmodelle]]
*[[Ausgangssituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_Matrix_IVS-Datenmodelle/_IVS-Ortsreferenzierungssysteme|Ausgangssituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Matrix IVS-Datenmodelle/ IVS-Ortsreferenzierungssysteme]]

=== Zielsituation der IVS-Datenarchitektur ===

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

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

Ergebnisse - Kataloge:

*[[Zielsituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Informationsobjekte|Zielsituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Informationsobjekte]]
*[[Zielsituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Datenmodelle|Zielsituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Datenmodelle]]
*[[Zielsituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Ortsreferenzierung|Zielsituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Ortsreferenzierung]]

Ergebnisse - Matrizen:

*[[Zielsituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_Matrix_IVS-Informationsobjekte/_IVS-Datenmodelle|Zielsituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Matrix IVS-Informationsobjekte/Datenmodelle]]
*[[Zielsituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_Matrix_IVS-Datenmodelle/_IVS-Ortsreferenzierungssysteme|Zielsituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Matrix IVS-Datenmodelle/ IVS-Ortsreferenzierungssysteme]]

=== Gap-Analyse für die IVS-Datenarchitektur ===

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

Ergebnisse:

*[[Gap-Analyse_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Informationsobjekte|Gap-Analyse IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Informationsobjekte]]
*[[Gap-Analyse_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Datenmodelle|Gap-Analyse IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Datenmodelle]]
*[[Gap-Analyse_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Ortsreferenzierungssysteme|Gap-Analyse IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Ortsreferenzierungssysteme]]

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

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

Ergebnis: [[IVS-Architektur-Roadmap_-_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Datenarchitektur|IVS-Architektur-Roadmap - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Datenarchitektur]]

----

== Phase IVS-Anwendungsarchitektur ==

=== Hilfsmittel, Sichten und Werkzeuge für IVS-Anwendungsarchitektur ===

Die IVS-Anwendungsarchitektur fokussiert IVS-Anwendungen und deren IVS-Schnittstellen im Zuständigkeitsübergreifenden Verkehrsmanagement, die für die Ausführung der zuständigkeitsübergreifenden IVS-Geschäftsprozesse erforderlich sind.

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

Für die Darstellung der Anwendungsarchitektur im Zuständigkeitsübergreifenden Verkehrsmanagement schlägt die IVS-Rahmenarchitektur folgende Modellierungsprinzipien bzw. -werkzeuge vor:

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

Ergebnis: [[Hilfsmittel_zur_Darstellung_der_IVS-Anwendungsarchitektur_-_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement|Hilfsmittel zur Darstellung der IVS-Anwendungsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== Ausgangssituation der IVS-Anwendungsarchitektur ===

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

Ergebnis: [[Ausgangssituation_Anwendungsarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement|Ausgangssituation IVS-Anwendungsarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== Zielsituation der IVS-Anwendungsarchitektur ===

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

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

Ergebnis: [[Zielsituation_Anwendungsarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Anwendung|Zielsituation IVS-Anwendungsarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== Gap-Analyse für die IVS-Anwendungsarchitektur ===

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

Ergebnis: [[Gap-Analyse_Anwendungsarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Anwendung|Gap-Analyse IVS-Anwendungsarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

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

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

Ergebnis: [[IVS-Architektur-Roadmap_-_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Anwendungsarchitektur|IVS-Architektur-Roadmap - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Anwendungsarchitektur]]

----

== Phase IVS-Technologiearchitektur ==

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

== Literaturverzeichnis ==

<references />

----

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

IVS-Referenzarchitektur für Zuständigkeitsübergreifendes Verkehrsmanagement 1.0

2018-08-29T11:00:32Z

Albrecht:

== Vorbereitungsphase ==

=== Steuerungs- und Unterstützungsframeworks ===

Mit den Steuerungs- und Unterstützungsframeworks für IVS-Architektur werden generell IVS-Architekturprojekte motiviert, begründet und gestützt. Der Inhalt dieser Frameworks bildet im Prinzip auch den Geist, in dem IVS-Architekturprojekte durchgeführt werden.

Für die IVS-Rahmenarchitektur bilden der Europäische IVS-Aktionsplan und die IVS-Direktive sowie auf nationaler Ebene das IVS-Gesetz und der Nationale IVS-Aktionsplan Straße die wesentlichen Frameworks. Für die IVS-Referenzarchitektur für Zuständigkeitsübergreifendes Verkehrsmanagement setzen neben den rechtlichen Vorgaben auch interne Vorgaben der einzelnen Stakeholder und Akteure den rechtlichen Handlungsrahmen.

Ergebnis: [[PhaseV-Step3-Los3_SteuerungsUndUnterstützungsframeworks|IVS-Steuerungs- und Unterstützungsframeworks für Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== IVS-Glossar ===

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

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

Für das Glossar für Zuständigkeitsübergreifendes Verkehrsmanagement gilt:

*Die Begriffsbestimmungen für IVS-Architektur (siehe [[IVS-Architekturbausteine#IVS-Architektur...|Was ist IVS-Architektur? - Schlüsselbegriffe]] und [[IVS-Architekturbausteine|Begriffe für die IVS-Gestaltungsmerkmale von IVS-Architektur]]) werden auf Zuständigkeitsübergreifendes Verkehrsmanagement übertragen.
*[[IVS-Glossar#Begriffsdefinitionen|Allgemeine Begriffe aus Verkehr, Transport und Mobilität]], die keine spezifische IVS-Architektur-Semantik repräsentieren, werden für Zuständigkeitsübergreifendes Verkehrsmanagement ergänzt.

Ergebnis: [[Los3_Glossar|IVS-Glossar für Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== Architekturprinzipien ===

Prinzipien stellen Grundsätze dar, die nicht nur dauerhaft gelten, sondern auch selten geändert werden sollten. Sie beschreiben die Art und Weise, wie eine davon betroffene Organisation ihre Aufgaben zu erfüllen hat. Prinzipien können für verschiedene Ebenen entwickelt und definiert werden.

Zur Detaillierung werden IVS-Architekturprinzipien gemäß den Ebenen von IVS-Architektur in folgende Untergruppen aufgeteilt:

*Geschäftsprinzip
*Daten-/Informationsprinzip
*Anwendungsprinzip
*Technologieprinzip

Ergebnis: [[Los3_IVS-Architekturprinzipien|IVS-Architekturprinzipien für Zuständigkeitsübergreifendes Verkehrsmanagement]]

----

== Phase Architektur Vision ==

=== Aufsetzen eines Architekturprojekts ===

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

*den IVS-Betrachtungsgegenstand "Zuständigkeitsübergreifendes Verkehrsmanagement" semantisch zu beschreiben (was ist der IVS-Betrachtungsgegenstand Zuständigkeitsübergreifendes Verkehrsmanagement) und
*klare Grenzen zu ähnlichen bzw. angrenzenden IVS-Betrachtungsgegenständen des Zuständigkeitsübergreifenden Verkehrsmanagements zu ziehen und festzulegen ('''was ist drin, was ist nicht drin''').

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

*Eine IVS-Referenzarchitektur soll verschiedene Gestaltungskonzepte für eine IVS-Dienstekategorie vorweisen.
*Bei der IVS-Architektur eines realen IVS-Dienstes müssen verschiedene Implementierungskonzepte für einen spezifischen IVS-Dienst erstellt werden.

Ergebnisse:

==== IVS-Domäne für Zuständigkeitsübergreifendes Verkehrsmanagement ====

*[[IVS-Domäne_Zuständigkeitsübergreifenden_Verkehrsmanagements_-_Template|IVS-Domäne für Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== IVS-Dienste(-kategorie) für Zuständigkeitsübergreifendes Verkehrsmanagement ====

*[[IVS-Dienste_Los3|IVS-Dienste(-kategorie) für Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== Zuständigkeitsübergreifendes Verkehrsmanagement - Allgemeine Beschreibung ====

*[[Zuständigkeitsübergreifendes_Verkehrsmanagement_-_Allgemeine_Beschreibung|Zuständigkeitsübergreifendes Verkehrsmanagement - Allgemeine Beschreibung]]

=== Erfassen und Beschreibung 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 in die IVS-Wertschöpfung zu involvierenden IVS-Akteure und die zu beteiligenden IVS-Stakeholder erfasst und beschrieben werden.

Dazu ist es nützlich - in Vorbereitung für den Schritt Entwicklung einer IVS-Architekturvision - eine erste Vorstellung für den IVS-Dienst/die IVS-Dienstekategorie zugrunde zu legen und darüber die erforderlichen IVS-Rollen in der IVS-Wertschöpfungskette/im IVS-Wertschöpfungsnetzwerk zu veranschaulichen.

Zur Ergebnisdarstellung werden zwei IVS-Bausteine verwendet:

*Der Baustein IVS-Rollen-Map, mit dem Stereotype von IVS-Akteuren und IVS-Stakeholdern deklariert, mit ihren Geschäftsanliegen und IVS-Rollen beschrieben und die Bedeutung von IVS-Akteuren und IVS-Stakeholdern gemäß "Power-Grid" klassifiziert werden.

*Der Baustein IVS-Rolle, mit dem Stereotype von IVS-Fähigkeiten und IVS-Verantwortlichkeiten, die für die Bereitstellung und den Betrieb von IVS-Diensten typisch und erforderlich sind, bezeichnet und semantisch beschrieben werden.

Ergebnisse:

*[[PhaseA-Step2-Los3_ErfassungUndBeschreibungVonRollen|IVS-Rollen im Zuständigkeitsübergreifenden Verkehrsmanagement - Allgemeine Beschreibung]]
*[[IVS-Rollen_Los3|IVS-Rollen-Map und IVS-Rollen Power-Grid für Zuständigkeitsübergreifendes Verkehrsmanagement]]
*[[IVS-Business_Szenarios_und_IVS-Anforderungen_Los_3_-_Zuständigkeitsübergreifendes_Verkehrsmanagement|IVS-Business Szenarios und IVS-Anforderungen für Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== Ziele, strategische Einflussfaktoren und Rahmenbedingungen ===

==== IVS-Leitbilder ====

Die Akzeptanz von Maßnahmen des Verkehrsmanagements wird beim Verkehrsteilnehmer erhöht, wenn sich der Betrieb an seinen Mobilitätsbedürfnissen und tatsächlichen Wegen orientiert und nicht an Zuständigkeitsgrenzen endet oder das Erscheinungsbild wechselt. Bei den indirekt beteiligten IVS-Stakeholdern und IVS-Akteuren wird eine hohe Akzeptanz erwartet, weil die "IVS-Referenzarchitektur für Zuständigkeitsübergreifendes Verkehrsmanagement" die Planungs- und Investitionssicherheit verbessert (Vermeidung von Insellösungen) und interoperable, betrieblich effiziente Lösungen begünstigt.

Ergebnis: [[IVS-Leitbilder_Los3|IVS-Leitbilder für Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== IVS-Geschäftsziele ====

Das Straßen- und Verkehrswesen kann einen Beitrag dazu leisten, die Lebensqualität der einzelnen Individuen zu steigern. Diese Forderung wird durch Definition der vier Oberziele des Verkehrs bekräftigt:

*Erhöhung der Sicherheit,
*Befriedigung des Mobilitätsbedürfnisses,
*Schonung der Umwelt und
*Verbesserung der Wirtschaftlichkeit.

Das Zuständigkeitsübergreifende Verkehrsmanagement setzt an dieser Stelle an. Durch gezielte Maßnahmen oder Maßnahmenbündel, die den gleichzeitigen Einsatz mehrerer Verkehrssysteme und -mittel (multimodal) oder den Wechsel der Verkehrssysteme (intermodal) innerhalb und außerhalb des eigenen Zuständigkeitsbereichs berücksichtigen, sollen Probleme oder bestimmte Situationen im regionalen und/oder überregionalen Verkehrssystem reduziert bzw. verbessert werden.

Ergebnis: [[IVS-Geschäftsziele_Los3|IVS-Geschäftsziele für Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== IVS-Capabilities ===

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

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

Grobe Vorstellungen für die Wertschöpfungskette des Zuständigkeitsübergreifenden Verkehrsmanagements zeigen folgenden Abbildungen:

<gallery mode="packed-hover">
File:TMValueChain.png | Wertschöpfungskette Verkehrsmanagement
File:WertschöpfungImSystemStrasse.png | System Strasse (Quelle Hessen Mobil)
</gallery>

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

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

Ergebnis: [[IVS-Capabilities_Los3|IVS-Capabilities für Zuständigkeitsübergreifenden Verkehrsmanagement]]

=== IVS-Architektur Vision ===

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

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

*Die Idee (für den IVS-Dienst),

:
::die die Kernaufgabe, die Nutzung und die Schnittstellen, das heißt den Kontext des zu erstellenden IVS-Dienstes aufzeigt.

*Einflussfaktoren und Randbedingungen

:
::wie funktionale und nicht-funktionale Anforderungen, organisatorische und technische Einflüsse.

*Lösungsstrategien

:
::halten die ersten Entscheidungen, wesentliche Architektur-Muster und Konzepte fest. Erste Architektursichten können entstehen, um die Lösungsstrategien zu verdeutlichen.

Ergebnis: [[IVS-Archtekturvision_Los3|IVS-Architektur Vision für Zuständigkeitsübergreifendes Verkehrsmanagement]]

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

Um den IVS-Dienst "Zuständigkeitsübergreifendes Verkehrsmanagement" realisieren zu können, müssen verschiedene IVS-Akteure zusammenarbeiten, sobald für eine Routenempfehlung die Aktorik, die Sensorik und/oder die Alternativroute oder Teile davon benötigt werden, die nicht in den eigenen Zuständigkeitsbereich fallen. Somit hängt die Interoperabilität von IVS-Akteuren im IVS-Dienst "Zuständigkeitsübergreifendes Verkehrsmanagement" im Wesentlichen davon ab, wie nahtlos diese zusammenarbeiten bzw. wie interoperabel diese ihre IVS-Geschäftsfähigkeiten gestalten können. Interoperabilität wird somit in den Mittelpunkt der architekturellen Bemühungen gestellt und die Bereitstellung von Interoperabilitäts-Bausteinen zum Kernziel von IVS-Architektur.

Ergebnis: [[IVS-Wertbeitrag_Los3|Wertbeitrag und KPIs von IVS-Architektur für Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== Risiken der Einführung einer IVS-Referenzarchitektur für zuständigkeitsübergreifendes Verkehrsmanagement ===

Die Einführung einer IVS-Architektur birgt auch Risiken. Das Risikomanagement soll genutzt wer-den, um die Risiken Einführung einer IVS-Referenzarchitektur für Zuständigkeitsübergreifenden Verkehrsmanagements zu erkennen, zu beurteilen und handzuhaben.

Ergebnis: [[Risiken_Los3|Risiken der Einführung einer IVS-Referenzarchitektur für Zuständigkeitsübergreifendes Verkehrsmanagement]]

----

== Phase Geschäftsarchitektur ==

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

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

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

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

*für die Sicht "IVS-Wertschöpfungskette/IVS-Wertschöpfungsnetzwerk"

:
:*Darstellung als '''IVS-Rollenmatrix''', wie sie im Projekt [[Media:ÖV-IVS_Schlussbericht_März_2014.pdf|Entwicklung einer ÖV-IVS-Rahmenarchitektur in Deutschland unter Einbindung Europäischer IVS-Richtlinien mit ÖV-Relevanz<ref>Kieslich, Wolfgang; Albrecht, Hanfried; Dinkel, Alexander u.a. (2014): Entwicklung einer für ÖV-IVS-Architektur in Deutschland unter Einbindung Europäischer IVS-Richtlinien mit ÖPNV-Relevanz. Schlussbericht. Im Auftrag des Bundesministeriums für Verkehr und digitale Infrastruktur. München.</ref>]] entwickelt wurde. Eine Anleitung findet sich [[Aufbau_von_IVS-Wertschöfungsketten_und_-netzwerke|'''hier''']].
:*Darstellung als '''Rollen/Capability-Diagramm'''. Ein Beispiel finden Sie '''[[PhaseB-Step2-Los3#Sicht_.22Wertsch.C3.B6pfungskette.2FWertsch.C3.B6pfungsnetzwerk.22_f.C3.BCr_Zust.C3.A4ndigkeits.C3.BCbergreifendes_Verkehrsmanagement|hier]]'''.

*für die Sicht "IVS-Governance"

:
::Für die Darstellung wird ein Textdokument empfohlen. Eine Beschreibungsstruktur findet sich [[IVS-Governance|hier]].

*für die Sicht "IVS-Geschäftsprozesse"

:
::für die Darstellung und Visualisierung der IVS-Geschäftsprozessarchitektur wird grundsätzlich ein Prozessmodellierungs-Ansatz gewählt. Durch das Aufschlüsseln von Geschäftsfunktionen und Geschäftsdiensten mit Hilfe der Prozessmodellierung wird die Identifizierung der Schlüssel-Prozesse und der nachgeordneten Dienste und Funktionen ermöglicht.
::*Ein Template zur Beschreibung von Geschäftsprozessen findet sich [[IVS-Geschäftsprozess|hier]].
::*Zur Modellierung von Geschäftsprozessen und Geschäftsfunktionen wird die Spezifikationssprache Business Process Model and Notation (BPMN) verwendet. Eine Anleitung findet sich [[Geschäftsprozessdiagramm|hier]].

Ergebnis: [[Hilfsmittel_und_Werkzeuge_Los3|Hilfsmittel zur Darstellung der IVS-Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== Ausgangssituation der IVS-Geschäftsarchitektur ===

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

*Sicht "IVS-Wertschöpfungsketten und -netzwerke"

:
::Die [[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.

*Sicht "IVS-Governance"

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

*Sicht "IVS-Geschäftsprozesse"

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

Ergebnisse:

*[[Ausgangssituation_Geschäftsarchitektur_Los_3_-_Sicht_Wertschöpfungsnetzwerk|Ausgangssituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Wertschöpfungsnetzwerk]]
*[[Ausgangssituation_Geschäftsarchitektur_Los_3_-_Sicht_Governance|Ausgangssituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Governance]]
*[[Ausgangssituation_Geschäftsarchitektur_Los_3_-_Sicht_Geschäftsprozesse|Ausgangssituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Geschäftsprozesse]]

=== Zielsituation der IVS-Geschäftsarchitektur ===

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

*Sicht [[Aufbau_von_IVS-Wertschöfungsketten_und_-netzwerke|"IVS-Wertschöpfungskette/IVS-Wertschöpfungsnetzwerk"]]

:
::Identifizierung, Darstellung und Beschreibung, über welche Bestandteile (Teildienste) der IVS-Dienst gebildet wird, welche IVS-Rollen daran beteiligt sein müssen und welche Anforderungen (IVS-Capabilities) an diese gestellt werden.

*Sicht [[IVS-Governance|"IVS-Governance"]]

:
::Beschreibung, auf welcher gesetzlichen, rechtlichen und vertraglichen Grundlage der IVS-Dienst und die Zusammenarbeit der IVS-Akteure zustande kommen und wie letztere operativ geführt und gesteuert wird.

*Sicht [[IVS-Geschäftsprozesse_und_Wertschöpfungsnetzwerke|"IVS-Geschäftsprozesse"]]

:
::Darstellung und Beschreibung, über welche Schlüssel-Geschäftsprozesse der IVS-Dienst operationalisiert wird.

Weitere Sichten können projektspezifisch aufgebaut und beschrieben werden.

Ergebnisse:

*[[Zielsituation_Geschäftsarchitektur_Los_3_-_Sicht_Wertschöpfungsnetzwerk|Zielsituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Wertschöpfungsnetzwerk]]
*[[Zielsituation_Geschäftsarchitektur_Los_3_-_Sicht_Governance|Zielsituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Governance]]
*[[Zielsituation_Geschäftsarchitektur_Los_3_-_Sicht_Geschäftsprozesse|Zielsituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Geschäftsprozesse]]

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

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

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

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

Ergebnisse:

*[[Gap-Analyse_Geschäftsarchitektur_Los_3_-_Sicht_Wertschöpfungsnetzwerk|Gap-Analyse Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Wertschöpfungsnetzwerk]]
*[[Gap-Analyse_Geschäftsarchitektur_Los_3_-_Sicht_Governance|Gap-Analyse Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Governance]]
*[[Gap-Analyse_Geschäftsarchitektur_Los_3_-_Sicht_Geschäftsprozesse|Gap-Analyse Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Geschäftsprozesse]]

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

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

Zur Beschreibung der einzelnen Arbeitsschritte sowie zur Festlegung von zeitlichen und inhaltlichen Abhängigkeiten zwischen den einzelnen Arbeitsschritten wird der Katalog [[Media:Architektur-Roadmap_00-00-01.docx|Architektur-Roadmap]] verwendet.

Ergebnis: [[IVS-Architektur-Roadmap_Los3|IVS-Architektur-Roadmap - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

----

== Phase IVS-Datenarchitektur ==

=== Hilfsmittel, Sichten und Werkzeuge für IVS-Datenarchitektur ===

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

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

Ergebnis: [[Hilfsmittel_zur_Darstellung_der_IVS-Datenarchitektur_-_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement|Hilfsmittel zur Darstellung der IVS-Datenarchitektur für Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== Ausgangssituation der IVS-Datenarchitektur ===

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

Ergebnisse - Kataloge:

*[[Ausgangssituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement|Ausgangssituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Informationsobjekte]]
*[[Ausgangssituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_IVS-Datenmodelle|Ausgangssituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Datenmodelle]]
*[[Ausgangssituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_IVS-Ortsreferenzierung|Ausgangssituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Ortsreferenzierungen]]

Ergebnisse - Matrizen:

*[[Ausgangssituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_Matrix_IVS-Informationsobjekte/_IVS-Datenmodelle|Ausgangssituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Matrix IVS-Informationsobjekte/Datenmodelle]]
*[[Ausgangssituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_Matrix_IVS-Datenmodelle/_IVS-Ortsreferenzierungssysteme|Ausgangssituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Matrix IVS-Datenmodelle/ IVS-Ortsreferenzierungssysteme]]

=== Zielsituation der IVS-Datenarchitektur ===

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

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

Ergebnisse - Kataloge:

*[[Zielsituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Informationsobjekte|Zielsituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Informationsobjekte]]
*[[Zielsituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Datenmodelle|Zielsituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Datenmodelle]]
*[[Zielsituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Ortsreferenzierung|Zielsituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Ortsreferenzierung]]

Ergebnisse - Matrizen:

*[[Zielsituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_Matrix_IVS-Informationsobjekte/_IVS-Datenmodelle|Zielsituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Matrix IVS-Informationsobjekte/Datenmodelle]]
*[[Zielsituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_Matrix_IVS-Datenmodelle/_IVS-Ortsreferenzierungssysteme|Zielsituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Matrix IVS-Datenmodelle/ IVS-Ortsreferenzierungssysteme]]

=== Gap-Analyse für die IVS-Datenarchitektur ===

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

Ergebnisse:

*[[Gap-Analyse_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Informationsobjekte|Gap-Analyse IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Informationsobjekte]]
*[[Gap-Analyse_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Datenmodelle|Gap-Analyse IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Datenmodelle]]
*[[Gap-Analyse_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Ortsreferenzierungssysteme|Gap-Analyse IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Ortsreferenzierungssysteme]]

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

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

Ergebnis: [[IVS-Architektur-Roadmap_-_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Datenarchitektur|IVS-Architektur-Roadmap - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Datenarchitektur]]

----

== Phase IVS-Anwendungsarchitektur ==

=== Hilfsmittel, Sichten und Werkzeuge für IVS-Anwendungsarchitektur ===

Die IVS-Anwendungsarchitektur fokussiert IVS-Anwendungen und deren IVS-Schnittstellen im Zuständigkeitsübergreifenden Verkehrsmanagement, die für die Ausführung der zuständigkeitsübergreifenden IVS-Geschäftsprozesse erforderlich sind.

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

Für die Darstellung der Anwendungsarchitektur im Zuständigkeitsübergreifenden Verkehrsmanagement schlägt die IVS-Rahmenarchitektur folgende Modellierungsprinzipien bzw. -werkzeuge vor:

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

Ergebnis: [[Hilfsmittel_zur_Darstellung_der_IVS-Anwendungsarchitektur_-_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement|Hilfsmittel zur Darstellung der IVS-Anwendungsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== Ausgangssituation der IVS-Anwendungsarchitektur ===

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

Ergebnis: [[Ausgangssituation_Anwendungsarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement|Ausgangssituation IVS-Anwendungsarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== Zielsituation der IVS-Anwendungsarchitektur ===

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

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

Ergebnis: [[Zielsituation_Anwendungsarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Anwendung|Zielsituation IVS-Anwendungsarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== Gap-Analyse für die IVS-Anwendungsarchitektur ===

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

Ergebnis: [[Gap-Analyse_Anwendungsarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Anwendung|Gap-Analyse IVS-Anwendungsarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

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

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

Ergebnis: [[IVS-Architektur-Roadmap_-_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Anwendungsarchitektur|IVS-Architektur-Roadmap - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Anwendungsarchitektur]]

----

=== Phase IVS-Technologiearchitektur ===

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

== Literaturverzeichnis ==

<references />

----

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

IVS-Referenzarchitektur für Zuständigkeitsübergreifendes Verkehrsmanagement 1.0

2018-08-29T11:00:12Z

Albrecht:

== Vorbereitungsphase ==

=== Steuerungs- und Unterstützungsframeworks ===

Mit den Steuerungs- und Unterstützungsframeworks für IVS-Architektur werden generell IVS-Architekturprojekte motiviert, begründet und gestützt. Der Inhalt dieser Frameworks bildet im Prinzip auch den Geist, in dem IVS-Architekturprojekte durchgeführt werden.

Für die IVS-Rahmenarchitektur bilden der Europäische IVS-Aktionsplan und die IVS-Direktive sowie auf nationaler Ebene das IVS-Gesetz und der Nationale IVS-Aktionsplan Straße die wesentlichen Frameworks. Für die IVS-Referenzarchitektur für Zuständigkeitsübergreifendes Verkehrsmanagement setzen neben den rechtlichen Vorgaben auch interne Vorgaben der einzelnen Stakeholder und Akteure den rechtlichen Handlungsrahmen.

Ergebnis: [[PhaseV-Step3-Los3_SteuerungsUndUnterstützungsframeworks|IVS-Steuerungs- und Unterstützungsframeworks für Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== IVS-Glossar ===

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

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

Für das Glossar für Zuständigkeitsübergreifendes Verkehrsmanagement gilt:

*Die Begriffsbestimmungen für IVS-Architektur (siehe [[IVS-Architekturbausteine#IVS-Architektur...|Was ist IVS-Architektur? - Schlüsselbegriffe]] und [[IVS-Architekturbausteine|Begriffe für die IVS-Gestaltungsmerkmale von IVS-Architektur]]) werden auf Zuständigkeitsübergreifendes Verkehrsmanagement übertragen.
*[[IVS-Glossar#Begriffsdefinitionen|Allgemeine Begriffe aus Verkehr, Transport und Mobilität]], die keine spezifische IVS-Architektur-Semantik repräsentieren, werden für Zuständigkeitsübergreifendes Verkehrsmanagement ergänzt.

Ergebnis: [[Los3_Glossar|IVS-Glossar für Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== Architekturprinzipien ===

Prinzipien stellen Grundsätze dar, die nicht nur dauerhaft gelten, sondern auch selten geändert werden sollten. Sie beschreiben die Art und Weise, wie eine davon betroffene Organisation ihre Aufgaben zu erfüllen hat. Prinzipien können für verschiedene Ebenen entwickelt und definiert werden.

Zur Detaillierung werden IVS-Architekturprinzipien gemäß den Ebenen von IVS-Architektur in folgende Untergruppen aufgeteilt:

*Geschäftsprinzip
*Daten-/Informationsprinzip
*Anwendungsprinzip
*Technologieprinzip

Ergebnis: [[Los3_IVS-Architekturprinzipien|IVS-Architekturprinzipien für Zuständigkeitsübergreifendes Verkehrsmanagement]]

----

== Phase Architektur Vision ==

=== Aufsetzen eines Architekturprojekts ===

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

*den IVS-Betrachtungsgegenstand "Zuständigkeitsübergreifendes Verkehrsmanagement" semantisch zu beschreiben (was ist der IVS-Betrachtungsgegenstand Zuständigkeitsübergreifendes Verkehrsmanagement) und
*klare Grenzen zu ähnlichen bzw. angrenzenden IVS-Betrachtungsgegenständen des Zuständigkeitsübergreifenden Verkehrsmanagements zu ziehen und festzulegen ('''was ist drin, was ist nicht drin''').

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

*Eine IVS-Referenzarchitektur soll verschiedene Gestaltungskonzepte für eine IVS-Dienstekategorie vorweisen.
*Bei der IVS-Architektur eines realen IVS-Dienstes müssen verschiedene Implementierungskonzepte für einen spezifischen IVS-Dienst erstellt werden.

Ergebnisse:

==== IVS-Domäne für Zuständigkeitsübergreifendes Verkehrsmanagement ====

*[[IVS-Domäne_Zuständigkeitsübergreifenden_Verkehrsmanagements_-_Template|IVS-Domäne für Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== IVS-Dienste(-kategorie) für Zuständigkeitsübergreifendes Verkehrsmanagement ====

*[[IVS-Dienste_Los3|IVS-Dienste(-kategorie) für Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== Zuständigkeitsübergreifendes Verkehrsmanagement - Allgemeine Beschreibung ====

*[[Zuständigkeitsübergreifendes_Verkehrsmanagement_-_Allgemeine_Beschreibung|Zuständigkeitsübergreifendes Verkehrsmanagement - Allgemeine Beschreibung]]

=== Erfassen und Beschreibung 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 in die IVS-Wertschöpfung zu involvierenden IVS-Akteure und die zu beteiligenden IVS-Stakeholder erfasst und beschrieben werden.

Dazu ist es nützlich - in Vorbereitung für den Schritt Entwicklung einer IVS-Architekturvision - eine erste Vorstellung für den IVS-Dienst/die IVS-Dienstekategorie zugrunde zu legen und darüber die erforderlichen IVS-Rollen in der IVS-Wertschöpfungskette/im IVS-Wertschöpfungsnetzwerk zu veranschaulichen.

Zur Ergebnisdarstellung werden zwei IVS-Bausteine verwendet:

*Der Baustein IVS-Rollen-Map, mit dem Stereotype von IVS-Akteuren und IVS-Stakeholdern deklariert, mit ihren Geschäftsanliegen und IVS-Rollen beschrieben und die Bedeutung von IVS-Akteuren und IVS-Stakeholdern gemäß "Power-Grid" klassifiziert werden.

*Der Baustein IVS-Rolle, mit dem Stereotype von IVS-Fähigkeiten und IVS-Verantwortlichkeiten, die für die Bereitstellung und den Betrieb von IVS-Diensten typisch und erforderlich sind, bezeichnet und semantisch beschrieben werden.

Ergebnisse:

*[[PhaseA-Step2-Los3_ErfassungUndBeschreibungVonRollen|IVS-Rollen im Zuständigkeitsübergreifenden Verkehrsmanagement - Allgemeine Beschreibung]]
*[[IVS-Rollen_Los3|IVS-Rollen-Map und IVS-Rollen Power-Grid für Zuständigkeitsübergreifendes Verkehrsmanagement]]
*[[IVS-Business_Szenarios_und_IVS-Anforderungen_Los_3_-_Zuständigkeitsübergreifendes_Verkehrsmanagement|IVS-Business Szenarios und IVS-Anforderungen für Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== Ziele, strategische Einflussfaktoren und Rahmenbedingungen ===

==== IVS-Leitbilder ====

Die Akzeptanz von Maßnahmen des Verkehrsmanagements wird beim Verkehrsteilnehmer erhöht, wenn sich der Betrieb an seinen Mobilitätsbedürfnissen und tatsächlichen Wegen orientiert und nicht an Zuständigkeitsgrenzen endet oder das Erscheinungsbild wechselt. Bei den indirekt beteiligten IVS-Stakeholdern und IVS-Akteuren wird eine hohe Akzeptanz erwartet, weil die "IVS-Referenzarchitektur für Zuständigkeitsübergreifendes Verkehrsmanagement" die Planungs- und Investitionssicherheit verbessert (Vermeidung von Insellösungen) und interoperable, betrieblich effiziente Lösungen begünstigt.

Ergebnis: [[IVS-Leitbilder_Los3|IVS-Leitbilder für Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== IVS-Geschäftsziele ====

Das Straßen- und Verkehrswesen kann einen Beitrag dazu leisten, die Lebensqualität der einzelnen Individuen zu steigern. Diese Forderung wird durch Definition der vier Oberziele des Verkehrs bekräftigt:

*Erhöhung der Sicherheit,
*Befriedigung des Mobilitätsbedürfnisses,
*Schonung der Umwelt und
*Verbesserung der Wirtschaftlichkeit.

Das Zuständigkeitsübergreifende Verkehrsmanagement setzt an dieser Stelle an. Durch gezielte Maßnahmen oder Maßnahmenbündel, die den gleichzeitigen Einsatz mehrerer Verkehrssysteme und -mittel (multimodal) oder den Wechsel der Verkehrssysteme (intermodal) innerhalb und außerhalb des eigenen Zuständigkeitsbereichs berücksichtigen, sollen Probleme oder bestimmte Situationen im regionalen und/oder überregionalen Verkehrssystem reduziert bzw. verbessert werden.

Ergebnis: [[IVS-Geschäftsziele_Los3|IVS-Geschäftsziele für Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== IVS-Capabilities ===

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

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

Grobe Vorstellungen für die Wertschöpfungskette des Zuständigkeitsübergreifenden Verkehrsmanagements zeigen folgenden Abbildungen:

<gallery mode="packed-hover">
File:TMValueChain.png | Wertschöpfungskette Verkehrsmanagement
File:WertschöpfungImSystemStrasse.png | System Strasse (Quelle Hessen Mobil)
</gallery>

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

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

Ergebnis: [[IVS-Capabilities_Los3|IVS-Capabilities für Zuständigkeitsübergreifenden Verkehrsmanagement]]

=== IVS-Architektur Vision ===

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

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

*Die Idee (für den IVS-Dienst),

:
::die die Kernaufgabe, die Nutzung und die Schnittstellen, das heißt den Kontext des zu erstellenden IVS-Dienstes aufzeigt.

*Einflussfaktoren und Randbedingungen

:
::wie funktionale und nicht-funktionale Anforderungen, organisatorische und technische Einflüsse.

*Lösungsstrategien

:
::halten die ersten Entscheidungen, wesentliche Architektur-Muster und Konzepte fest. Erste Architektursichten können entstehen, um die Lösungsstrategien zu verdeutlichen.

Ergebnis: [[IVS-Archtekturvision_Los3|IVS-Architektur Vision für Zuständigkeitsübergreifendes Verkehrsmanagement]]

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

Um den IVS-Dienst "Zuständigkeitsübergreifendes Verkehrsmanagement" realisieren zu können, müssen verschiedene IVS-Akteure zusammenarbeiten, sobald für eine Routenempfehlung die Aktorik, die Sensorik und/oder die Alternativroute oder Teile davon benötigt werden, die nicht in den eigenen Zuständigkeitsbereich fallen. Somit hängt die Interoperabilität von IVS-Akteuren im IVS-Dienst "Zuständigkeitsübergreifendes Verkehrsmanagement" im Wesentlichen davon ab, wie nahtlos diese zusammenarbeiten bzw. wie interoperabel diese ihre IVS-Geschäftsfähigkeiten gestalten können. Interoperabilität wird somit in den Mittelpunkt der architekturellen Bemühungen gestellt und die Bereitstellung von Interoperabilitäts-Bausteinen zum Kernziel von IVS-Architektur.

Ergebnis: [[IVS-Wertbeitrag_Los3|Wertbeitrag und KPIs von IVS-Architektur für Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== Risiken der Einführung einer IVS-Referenzarchitektur für zuständigkeitsübergreifendes Verkehrsmanagement ===

Die Einführung einer IVS-Architektur birgt auch Risiken. Das Risikomanagement soll genutzt wer-den, um die Risiken Einführung einer IVS-Referenzarchitektur für Zuständigkeitsübergreifenden Verkehrsmanagements zu erkennen, zu beurteilen und handzuhaben.

Ergebnis: [[Risiken_Los3|Risiken der Einführung einer IVS-Referenzarchitektur für Zuständigkeitsübergreifendes Verkehrsmanagement]]

----

== Phase Geschäftsarchitektur ==

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

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

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

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

*für die Sicht "IVS-Wertschöpfungskette/IVS-Wertschöpfungsnetzwerk"

:
:*Darstellung als '''IVS-Rollenmatrix''', wie sie im Projekt [[Media:ÖV-IVS_Schlussbericht_März_2014.pdf|Entwicklung einer ÖV-IVS-Rahmenarchitektur in Deutschland unter Einbindung Europäischer IVS-Richtlinien mit ÖV-Relevanz<ref>Kieslich, Wolfgang; Albrecht, Hanfried; Dinkel, Alexander u.a. (2014): Entwicklung einer für ÖV-IVS-Architektur in Deutschland unter Einbindung Europäischer IVS-Richtlinien mit ÖPNV-Relevanz. Schlussbericht. Im Auftrag des Bundesministeriums für Verkehr und digitale Infrastruktur. München.</ref>]] entwickelt wurde. Eine Anleitung findet sich [[Aufbau_von_IVS-Wertschöfungsketten_und_-netzwerke|'''hier''']].
:*Darstellung als '''Rollen/Capability-Diagramm'''. Ein Beispiel finden Sie '''[[PhaseB-Step2-Los3#Sicht_.22Wertsch.C3.B6pfungskette.2FWertsch.C3.B6pfungsnetzwerk.22_f.C3.BCr_Zust.C3.A4ndigkeits.C3.BCbergreifendes_Verkehrsmanagement|hier]]'''.

*für die Sicht "IVS-Governance"

:
::Für die Darstellung wird ein Textdokument empfohlen. Eine Beschreibungsstruktur findet sich [[IVS-Governance|hier]].

*für die Sicht "IVS-Geschäftsprozesse"

:
::für die Darstellung und Visualisierung der IVS-Geschäftsprozessarchitektur wird grundsätzlich ein Prozessmodellierungs-Ansatz gewählt. Durch das Aufschlüsseln von Geschäftsfunktionen und Geschäftsdiensten mit Hilfe der Prozessmodellierung wird die Identifizierung der Schlüssel-Prozesse und der nachgeordneten Dienste und Funktionen ermöglicht.
::*Ein Template zur Beschreibung von Geschäftsprozessen findet sich [[IVS-Geschäftsprozess|hier]].
::*Zur Modellierung von Geschäftsprozessen und Geschäftsfunktionen wird die Spezifikationssprache Business Process Model and Notation (BPMN) verwendet. Eine Anleitung findet sich [[Geschäftsprozessdiagramm|hier]].

Ergebnis: [[Hilfsmittel_und_Werkzeuge_Los3|Hilfsmittel zur Darstellung der IVS-Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== Ausgangssituation der IVS-Geschäftsarchitektur ===

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

*Sicht "IVS-Wertschöpfungsketten und -netzwerke"

:
::Die [[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.

*Sicht "IVS-Governance"

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

*Sicht "IVS-Geschäftsprozesse"

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

Ergebnisse:

*[[Ausgangssituation_Geschäftsarchitektur_Los_3_-_Sicht_Wertschöpfungsnetzwerk|Ausgangssituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Wertschöpfungsnetzwerk]]
*[[Ausgangssituation_Geschäftsarchitektur_Los_3_-_Sicht_Governance|Ausgangssituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Governance]]
*[[Ausgangssituation_Geschäftsarchitektur_Los_3_-_Sicht_Geschäftsprozesse|Ausgangssituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Geschäftsprozesse]]

=== Zielsituation der IVS-Geschäftsarchitektur ===

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

*Sicht [[Aufbau_von_IVS-Wertschöfungsketten_und_-netzwerke|"IVS-Wertschöpfungskette/IVS-Wertschöpfungsnetzwerk"]]

:
::Identifizierung, Darstellung und Beschreibung, über welche Bestandteile (Teildienste) der IVS-Dienst gebildet wird, welche IVS-Rollen daran beteiligt sein müssen und welche Anforderungen (IVS-Capabilities) an diese gestellt werden.

*Sicht [[IVS-Governance|"IVS-Governance"]]

:
::Beschreibung, auf welcher gesetzlichen, rechtlichen und vertraglichen Grundlage der IVS-Dienst und die Zusammenarbeit der IVS-Akteure zustande kommen und wie letztere operativ geführt und gesteuert wird.

*Sicht [[IVS-Geschäftsprozesse_und_Wertschöpfungsnetzwerke|"IVS-Geschäftsprozesse"]]

:
::Darstellung und Beschreibung, über welche Schlüssel-Geschäftsprozesse der IVS-Dienst operationalisiert wird.

Weitere Sichten können projektspezifisch aufgebaut und beschrieben werden.

Ergebnisse:

*[[Zielsituation_Geschäftsarchitektur_Los_3_-_Sicht_Wertschöpfungsnetzwerk|Zielsituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Wertschöpfungsnetzwerk]]
*[[Zielsituation_Geschäftsarchitektur_Los_3_-_Sicht_Governance|Zielsituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Governance]]
*[[Zielsituation_Geschäftsarchitektur_Los_3_-_Sicht_Geschäftsprozesse|Zielsituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Geschäftsprozesse]]

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

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

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

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

Ergebnisse:

*[[Gap-Analyse_Geschäftsarchitektur_Los_3_-_Sicht_Wertschöpfungsnetzwerk|Gap-Analyse Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Wertschöpfungsnetzwerk]]
*[[Gap-Analyse_Geschäftsarchitektur_Los_3_-_Sicht_Governance|Gap-Analyse Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Governance]]
*[[Gap-Analyse_Geschäftsarchitektur_Los_3_-_Sicht_Geschäftsprozesse|Gap-Analyse Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Geschäftsprozesse]]

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

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

Zur Beschreibung der einzelnen Arbeitsschritte sowie zur Festlegung von zeitlichen und inhaltlichen Abhängigkeiten zwischen den einzelnen Arbeitsschritten wird der Katalog [[Media:Architektur-Roadmap_00-00-01.docx|Architektur-Roadmap]] verwendet.

Ergebnis: [[IVS-Architektur-Roadmap_Los3|IVS-Architektur-Roadmap - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

----

== Phase IVS-Datenarchitektur ==

=== Hilfsmittel, Sichten und Werkzeuge für IVS-Datenarchitektur ===

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

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

Ergebnis: [[Hilfsmittel_zur_Darstellung_der_IVS-Datenarchitektur_-_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement|Hilfsmittel zur Darstellung der IVS-Datenarchitektur für Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== Ausgangssituation der IVS-Datenarchitektur ===

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

Ergebnisse - Kataloge:

*[[Ausgangssituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement|Ausgangssituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Informationsobjekte]]
*[[Ausgangssituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_IVS-Datenmodelle|Ausgangssituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Datenmodelle]]
*[[Ausgangssituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_IVS-Ortsreferenzierung|Ausgangssituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Ortsreferenzierungen]]

Ergebnisse - Matrizen:

*[[Ausgangssituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_Matrix_IVS-Informationsobjekte/_IVS-Datenmodelle|Ausgangssituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Matrix IVS-Informationsobjekte/Datenmodelle]]
*[[Ausgangssituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_Matrix_IVS-Datenmodelle/_IVS-Ortsreferenzierungssysteme|Ausgangssituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Matrix IVS-Datenmodelle/ IVS-Ortsreferenzierungssysteme]]

=== Zielsituation der IVS-Datenarchitektur ===

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

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

Ergebnisse - Kataloge:

*[[Zielsituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Informationsobjekte|Zielsituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Informationsobjekte]]
*[[Zielsituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Datenmodelle|Zielsituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Datenmodelle]]
*[[Zielsituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Ortsreferenzierung|Zielsituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Ortsreferenzierung]]

Ergebnisse - Matrizen:

*[[Zielsituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_Matrix_IVS-Informationsobjekte/_IVS-Datenmodelle|Zielsituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Matrix IVS-Informationsobjekte/Datenmodelle]]
*[[Zielsituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_Matrix_IVS-Datenmodelle/_IVS-Ortsreferenzierungssysteme|Zielsituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Matrix IVS-Datenmodelle/ IVS-Ortsreferenzierungssysteme]]

=== Gap-Analyse für die IVS-Datenarchitektur ===

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

Ergebnisse:

*[[Gap-Analyse_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Informationsobjekte|Gap-Analyse IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Informationsobjekte]]
*[[Gap-Analyse_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Datenmodelle|Gap-Analyse IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Datenmodelle]]
*[[Gap-Analyse_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Ortsreferenzierungssysteme|Gap-Analyse IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Ortsreferenzierungssysteme]]

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

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

Ergebnis: [[IVS-Architektur-Roadmap_-_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Datenarchitektur|IVS-Architektur-Roadmap - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Datenarchitektur]]

----

== Phase IVS-Anwendungsarchitektur ==

=== Hilfsmittel, Sichten und Werkzeuge für IVS-Anwendungsarchitektur ===

Die IVS-Anwendungsarchitektur fokussiert IVS-Anwendungen und deren IVS-Schnittstellen im Zuständigkeitsübergreifenden Verkehrsmanagement, die für die Ausführung der zuständigkeitsübergreifenden IVS-Geschäftsprozesse erforderlich sind.

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

Für die Darstellung der Anwendungsarchitektur im Zuständigkeitsübergreifenden Verkehrsmanagement schlägt die IVS-Rahmenarchitektur folgende Modellierungsprinzipien bzw. -werkzeuge vor:

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

Ergebnis: [[Hilfsmittel_zur_Darstellung_der_IVS-Anwendungsarchitektur_-_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement|Hilfsmittel zur Darstellung der IVS-Anwendungsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== Ausgangssituation der IVS-Anwendungsarchitektur ===

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

Ergebnis: [[Ausgangssituation_Anwendungsarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement|Ausgangssituation IVS-Anwendungsarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== Zielsituation der IVS-Anwendungsarchitektur ===

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

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

Ergebnis: [[Zielsituation_Anwendungsarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Anwendung|Zielsituation IVS-Anwendungsarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== Gap-Analyse für die IVS-Anwendungsarchitektur ===

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

Ergebnis: [[Gap-Analyse_Anwendungsarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Anwendung|Gap-Analyse IVS-Anwendungsarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

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

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

Ergebnis: [[IVS-Architektur-Roadmap_-_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Anwendungsarchitektur|IVS-Architektur-Roadmap - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Anwendungsarchitektur]]

----

=== Ergebnisse IVS-Technologiearchitektur ===

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

== Literaturverzeichnis ==

<references />

----

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

IVS-Referenzarchitektur für Zuständigkeitsübergreifendes Verkehrsmanagement 1.0

2018-08-29T10:58:44Z

Albrecht:

== Vorbereitungsphase ==

=== Steuerungs- und Unterstützungsframeworks ===

Mit den Steuerungs- und Unterstützungsframeworks für IVS-Architektur werden generell IVS-Architekturprojekte motiviert, begründet und gestützt. Der Inhalt dieser Frameworks bildet im Prinzip auch den Geist, in dem IVS-Architekturprojekte durchgeführt werden.

Für die IVS-Rahmenarchitektur bilden der Europäische IVS-Aktionsplan und die IVS-Direktive sowie auf nationaler Ebene das IVS-Gesetz und der Nationale IVS-Aktionsplan Straße die wesentlichen Frameworks. Für die IVS-Referenzarchitektur für Zuständigkeitsübergreifendes Verkehrsmanagement setzen neben den rechtlichen Vorgaben auch interne Vorgaben der einzelnen Stakeholder und Akteure den rechtlichen Handlungsrahmen.

Ergebnis: [[PhaseV-Step3-Los3_SteuerungsUndUnterstützungsframeworks|IVS-Steuerungs- und Unterstützungsframeworks für Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== IVS-Glossar ===

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

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

Für das Glossar für Zuständigkeitsübergreifendes Verkehrsmanagement gilt:

*Die Begriffsbestimmungen für IVS-Architektur (siehe [[IVS-Architekturbausteine#IVS-Architektur...|Was ist IVS-Architektur? - Schlüsselbegriffe]] und [[IVS-Architekturbausteine|Begriffe für die IVS-Gestaltungsmerkmale von IVS-Architektur]]) werden auf Zuständigkeitsübergreifendes Verkehrsmanagement übertragen.
*[[IVS-Glossar#Begriffsdefinitionen|Allgemeine Begriffe aus Verkehr, Transport und Mobilität]], die keine spezifische IVS-Architektur-Semantik repräsentieren, werden für Zuständigkeitsübergreifendes Verkehrsmanagement ergänzt.

Ergebnis: [[Los3_Glossar|IVS-Glossar für Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== Architekturprinzipien ===

Prinzipien stellen Grundsätze dar, die nicht nur dauerhaft gelten, sondern auch selten geändert werden sollten. Sie beschreiben die Art und Weise, wie eine davon betroffene Organisation ihre Aufgaben zu erfüllen hat. Prinzipien können für verschiedene Ebenen entwickelt und definiert werden.

Zur Detaillierung werden IVS-Architekturprinzipien gemäß den Ebenen von IVS-Architektur in folgende Untergruppen aufgeteilt:

*Geschäftsprinzip
*Daten-/Informationsprinzip
*Anwendungsprinzip
*Technologieprinzip

Ergebnis: [[Los3_IVS-Architekturprinzipien|IVS-Architekturprinzipien für Zuständigkeitsübergreifendes Verkehrsmanagement]]

----

== Phase Architektur Vision ==

=== Aufsetzen eines Architekturprojekts ===

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

*den IVS-Betrachtungsgegenstand "Zuständigkeitsübergreifendes Verkehrsmanagement" semantisch zu beschreiben (was ist der IVS-Betrachtungsgegenstand Zuständigkeitsübergreifendes Verkehrsmanagement) und
*klare Grenzen zu ähnlichen bzw. angrenzenden IVS-Betrachtungsgegenständen des Zuständigkeitsübergreifenden Verkehrsmanagements zu ziehen und festzulegen ('''was ist drin, was ist nicht drin''').

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

*Eine IVS-Referenzarchitektur soll verschiedene Gestaltungskonzepte für eine IVS-Dienstekategorie vorweisen.
*Bei der IVS-Architektur eines realen IVS-Dienstes müssen verschiedene Implementierungskonzepte für einen spezifischen IVS-Dienst erstellt werden.

Ergebnisse:

==== IVS-Domäne für Zuständigkeitsübergreifendes Verkehrsmanagement ====

*[[IVS-Domäne_Zuständigkeitsübergreifenden_Verkehrsmanagements_-_Template|IVS-Domäne für Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== IVS-Dienste(-kategorie) für Zuständigkeitsübergreifendes Verkehrsmanagement ====

*[[IVS-Dienste_Los3|IVS-Dienste(-kategorie) für Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== Zuständigkeitsübergreifendes Verkehrsmanagement - Allgemeine Beschreibung ====

*[[Zuständigkeitsübergreifendes_Verkehrsmanagement_-_Allgemeine_Beschreibung|Zuständigkeitsübergreifendes Verkehrsmanagement - Allgemeine Beschreibung]]

=== Erfassen und Beschreibung 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 in die IVS-Wertschöpfung zu involvierenden IVS-Akteure und die zu beteiligenden IVS-Stakeholder erfasst und beschrieben werden.

Dazu ist es nützlich - in Vorbereitung für den Schritt Entwicklung einer IVS-Architekturvision - eine erste Vorstellung für den IVS-Dienst/die IVS-Dienstekategorie zugrunde zu legen und darüber die erforderlichen IVS-Rollen in der IVS-Wertschöpfungskette/im IVS-Wertschöpfungsnetzwerk zu veranschaulichen.

Zur Ergebnisdarstellung werden zwei IVS-Bausteine verwendet:

*Der Baustein IVS-Rollen-Map, mit dem Stereotype von IVS-Akteuren und IVS-Stakeholdern deklariert, mit ihren Geschäftsanliegen und IVS-Rollen beschrieben und die Bedeutung von IVS-Akteuren und IVS-Stakeholdern gemäß "Power-Grid" klassifiziert werden.

*Der Baustein IVS-Rolle, mit dem Stereotype von IVS-Fähigkeiten und IVS-Verantwortlichkeiten, die für die Bereitstellung und den Betrieb von IVS-Diensten typisch und erforderlich sind, bezeichnet und semantisch beschrieben werden.

Ergebnisse:

*[[PhaseA-Step2-Los3_ErfassungUndBeschreibungVonRollen|IVS-Rollen im Zuständigkeitsübergreifenden Verkehrsmanagement - Allgemeine Beschreibung]]
*[[IVS-Rollen_Los3|IVS-Rollen-Map und IVS-Rollen Power-Grid für Zuständigkeitsübergreifendes Verkehrsmanagement]]
*[[IVS-Business_Szenarios_und_IVS-Anforderungen_Los_3_-_Zuständigkeitsübergreifendes_Verkehrsmanagement|IVS-Business Szenarios und IVS-Anforderungen für Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== Ziele, strategische Einflussfaktoren und Rahmenbedingungen ===

==== IVS-Leitbilder ====

Die Akzeptanz von Maßnahmen des Verkehrsmanagements wird beim Verkehrsteilnehmer erhöht, wenn sich der Betrieb an seinen Mobilitätsbedürfnissen und tatsächlichen Wegen orientiert und nicht an Zuständigkeitsgrenzen endet oder das Erscheinungsbild wechselt. Bei den indirekt beteiligten IVS-Stakeholdern und IVS-Akteuren wird eine hohe Akzeptanz erwartet, weil die "IVS-Referenzarchitektur für Zuständigkeitsübergreifendes Verkehrsmanagement" die Planungs- und Investitionssicherheit verbessert (Vermeidung von Insellösungen) und interoperable, betrieblich effiziente Lösungen begünstigt.

Ergebnis: [[IVS-Leitbilder_Los3|IVS-Leitbilder für Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== IVS-Geschäftsziele ====

Das Straßen- und Verkehrswesen kann einen Beitrag dazu leisten, die Lebensqualität der einzelnen Individuen zu steigern. Diese Forderung wird durch Definition der vier Oberziele des Verkehrs bekräftigt:

*Erhöhung der Sicherheit,
*Befriedigung des Mobilitätsbedürfnisses,
*Schonung der Umwelt und
*Verbesserung der Wirtschaftlichkeit.

Das Zuständigkeitsübergreifende Verkehrsmanagement setzt an dieser Stelle an. Durch gezielte Maßnahmen oder Maßnahmenbündel, die den gleichzeitigen Einsatz mehrerer Verkehrssysteme und -mittel (multimodal) oder den Wechsel der Verkehrssysteme (intermodal) innerhalb und außerhalb des eigenen Zuständigkeitsbereichs berücksichtigen, sollen Probleme oder bestimmte Situationen im regionalen und/oder überregionalen Verkehrssystem reduziert bzw. verbessert werden.

Ergebnis: [[IVS-Geschäftsziele_Los3|IVS-Geschäftsziele für Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== IVS-Capabilities ===

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

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

Grobe Vorstellungen für die Wertschöpfungskette des Zuständigkeitsübergreifenden Verkehrsmanagements zeigen folgenden Abbildungen:

<gallery mode="packed-hover">
File:TMValueChain.png | Wertschöpfungskette Verkehrsmanagement
File:WertschöpfungImSystemStrasse.png | System Strasse (Quelle Hessen Mobil)
</gallery>

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

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

Ergebnis: [[IVS-Capabilities_Los3|IVS-Capabilities für Zuständigkeitsübergreifenden Verkehrsmanagement]]

=== IVS-Architektur Vision ===

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

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

*Die Idee (für den IVS-Dienst),

:
::die die Kernaufgabe, die Nutzung und die Schnittstellen, das heißt den Kontext des zu erstellenden IVS-Dienstes aufzeigt.

*Einflussfaktoren und Randbedingungen

:
::wie funktionale und nicht-funktionale Anforderungen, organisatorische und technische Einflüsse.

*Lösungsstrategien

:
::halten die ersten Entscheidungen, wesentliche Architektur-Muster und Konzepte fest. Erste Architektursichten können entstehen, um die Lösungsstrategien zu verdeutlichen.

Ergebnis: [[IVS-Archtekturvision_Los3|IVS-Architektur Vision für Zuständigkeitsübergreifendes Verkehrsmanagement]]

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

Um den IVS-Dienst "Zuständigkeitsübergreifendes Verkehrsmanagement" realisieren zu können, müssen verschiedene IVS-Akteure zusammenarbeiten, sobald für eine Routenempfehlung die Aktorik, die Sensorik und/oder die Alternativroute oder Teile davon benötigt werden, die nicht in den eigenen Zuständigkeitsbereich fallen. Somit hängt die Interoperabilität von IVS-Akteuren im IVS-Dienst "Zuständigkeitsübergreifendes Verkehrsmanagement" im Wesentlichen davon ab, wie nahtlos diese zusammenarbeiten bzw. wie interoperabel diese ihre IVS-Geschäftsfähigkeiten gestalten können. Interoperabilität wird somit in den Mittelpunkt der architekturellen Bemühungen gestellt und die Bereitstellung von Interoperabilitäts-Bausteinen zum Kernziel von IVS-Architektur.

Ergebnis: [[IVS-Wertbeitrag_Los3|Wertbeitrag und KPIs von IVS-Architektur für Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== Risiken der Einführung einer IVS-Referenzarchitektur für zuständigkeitsübergreifendes Verkehrsmanagement ===

Die Einführung einer IVS-Architektur birgt auch Risiken. Das Risikomanagement soll genutzt wer-den, um die Risiken Einführung einer IVS-Referenzarchitektur für Zuständigkeitsübergreifenden Verkehrsmanagements zu erkennen, zu beurteilen und handzuhaben.

Ergebnis: [[Risiken_Los3|Risiken der Einführung einer IVS-Referenzarchitektur für Zuständigkeitsübergreifendes Verkehrsmanagement]]

----

== Phase Geschäftsarchitektur ==

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

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

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

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

*für die Sicht "IVS-Wertschöpfungskette/IVS-Wertschöpfungsnetzwerk"

:
:*Darstellung als '''IVS-Rollenmatrix''', wie sie im Projekt [[Media:ÖV-IVS_Schlussbericht_März_2014.pdf|Entwicklung einer ÖV-IVS-Rahmenarchitektur in Deutschland unter Einbindung Europäischer IVS-Richtlinien mit ÖV-Relevanz<ref>Kieslich, Wolfgang; Albrecht, Hanfried; Dinkel, Alexander u.a. (2014): Entwicklung einer für ÖV-IVS-Architektur in Deutschland unter Einbindung Europäischer IVS-Richtlinien mit ÖPNV-Relevanz. Schlussbericht. Im Auftrag des Bundesministeriums für Verkehr und digitale Infrastruktur. München.</ref>]] entwickelt wurde. Eine Anleitung findet sich [[Aufbau_von_IVS-Wertschöfungsketten_und_-netzwerke|'''hier''']].
:*Darstellung als '''Rollen/Capability-Diagramm'''. Ein Beispiel finden Sie '''[[PhaseB-Step2-Los3#Sicht_.22Wertsch.C3.B6pfungskette.2FWertsch.C3.B6pfungsnetzwerk.22_f.C3.BCr_Zust.C3.A4ndigkeits.C3.BCbergreifendes_Verkehrsmanagement|hier]]'''.

*für die Sicht "IVS-Governance"

:
::Für die Darstellung wird ein Textdokument empfohlen. Eine Beschreibungsstruktur findet sich [[IVS-Governance|hier]].

*für die Sicht "IVS-Geschäftsprozesse"

:
::für die Darstellung und Visualisierung der IVS-Geschäftsprozessarchitektur wird grundsätzlich ein Prozessmodellierungs-Ansatz gewählt. Durch das Aufschlüsseln von Geschäftsfunktionen und Geschäftsdiensten mit Hilfe der Prozessmodellierung wird die Identifizierung der Schlüssel-Prozesse und der nachgeordneten Dienste und Funktionen ermöglicht.
::*Ein Template zur Beschreibung von Geschäftsprozessen findet sich [[IVS-Geschäftsprozess|hier]].
::*Zur Modellierung von Geschäftsprozessen und Geschäftsfunktionen wird die Spezifikationssprache Business Process Model and Notation (BPMN) verwendet. Eine Anleitung findet sich [[Geschäftsprozessdiagramm|hier]].

Ergebnis: [[Hilfsmittel_und_Werkzeuge_Los3|Hilfsmittel zur Darstellung der IVS-Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== Ausgangssituation der IVS-Geschäftsarchitektur ===

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

*Sicht "IVS-Wertschöpfungsketten und -netzwerke"

:
::Die [[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.

*Sicht "IVS-Governance"

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

*Sicht "IVS-Geschäftsprozesse"

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

Ergebnisse:

*[[Ausgangssituation_Geschäftsarchitektur_Los_3_-_Sicht_Wertschöpfungsnetzwerk|Ausgangssituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Wertschöpfungsnetzwerk]]
*[[Ausgangssituation_Geschäftsarchitektur_Los_3_-_Sicht_Governance|Ausgangssituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Governance]]
*[[Ausgangssituation_Geschäftsarchitektur_Los_3_-_Sicht_Geschäftsprozesse|Ausgangssituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Geschäftsprozesse]]

=== Zielsituation der IVS-Geschäftsarchitektur ===

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

*Sicht [[Aufbau_von_IVS-Wertschöfungsketten_und_-netzwerke|"IVS-Wertschöpfungskette/IVS-Wertschöpfungsnetzwerk"]]

:
::Identifizierung, Darstellung und Beschreibung, über welche Bestandteile (Teildienste) der IVS-Dienst gebildet wird, welche IVS-Rollen daran beteiligt sein müssen und welche Anforderungen (IVS-Capabilities) an diese gestellt werden.

*Sicht [[IVS-Governance|"IVS-Governance"]]

:
::Beschreibung, auf welcher gesetzlichen, rechtlichen und vertraglichen Grundlage der IVS-Dienst und die Zusammenarbeit der IVS-Akteure zustande kommen und wie letztere operativ geführt und gesteuert wird.

*Sicht [[IVS-Geschäftsprozesse_und_Wertschöpfungsnetzwerke|"IVS-Geschäftsprozesse"]]

:
::Darstellung und Beschreibung, über welche Schlüssel-Geschäftsprozesse der IVS-Dienst operationalisiert wird.

Weitere Sichten können projektspezifisch aufgebaut und beschrieben werden.

Ergebnisse:

*[[Zielsituation_Geschäftsarchitektur_Los_3_-_Sicht_Wertschöpfungsnetzwerk|Zielsituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Wertschöpfungsnetzwerk]]
*[[Zielsituation_Geschäftsarchitektur_Los_3_-_Sicht_Governance|Zielsituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Governance]]
*[[Zielsituation_Geschäftsarchitektur_Los_3_-_Sicht_Geschäftsprozesse|Zielsituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Geschäftsprozesse]]

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

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

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

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

Ergebnisse:

*[[Gap-Analyse_Geschäftsarchitektur_Los_3_-_Sicht_Wertschöpfungsnetzwerk|Gap-Analyse Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Wertschöpfungsnetzwerk]]
*[[Gap-Analyse_Geschäftsarchitektur_Los_3_-_Sicht_Governance|Gap-Analyse Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Governance]]
*[[Gap-Analyse_Geschäftsarchitektur_Los_3_-_Sicht_Geschäftsprozesse|Gap-Analyse Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Geschäftsprozesse]]

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

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

Zur Beschreibung der einzelnen Arbeitsschritte sowie zur Festlegung von zeitlichen und inhaltlichen Abhängigkeiten zwischen den einzelnen Arbeitsschritten wird der Katalog [[Media:Architektur-Roadmap_00-00-01.docx|Architektur-Roadmap]] verwendet.

Ergebnis: [[IVS-Architektur-Roadmap_Los3|IVS-Architektur-Roadmap - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

----

== Phase IVS-Datenarchitektur ==

=== Hilfsmittel, Sichten und Werkzeuge für IVS-Datenarchitektur ===

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

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

Ergebnis: [[Hilfsmittel_zur_Darstellung_der_IVS-Datenarchitektur_-_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement|Hilfsmittel zur Darstellung der IVS-Datenarchitektur für Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== Ausgangssituation der IVS-Datenarchitektur ===

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

Ergebnisse - Kataloge:

*[[Ausgangssituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement|Ausgangssituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Informationsobjekte]]
*[[Ausgangssituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_IVS-Datenmodelle|Ausgangssituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Datenmodelle]]
*[[Ausgangssituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_IVS-Ortsreferenzierung|Ausgangssituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Ortsreferenzierungen]]

Ergebnisse - Matrizen:

*[[Ausgangssituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_Matrix_IVS-Informationsobjekte/_IVS-Datenmodelle|Ausgangssituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Matrix IVS-Informationsobjekte/Datenmodelle]]
*[[Ausgangssituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_Matrix_IVS-Datenmodelle/_IVS-Ortsreferenzierungssysteme|Ausgangssituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Matrix IVS-Datenmodelle/ IVS-Ortsreferenzierungssysteme]]

=== Zielsituation der IVS-Datenarchitektur ===

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

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

Ergebnisse - Kataloge:

*[[Zielsituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Informationsobjekte|Zielsituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Informationsobjekte]]
*[[Zielsituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Datenmodelle|Zielsituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Datenmodelle]]
*[[Zielsituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Ortsreferenzierung|Zielsituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Ortsreferenzierung]]

Ergebnisse - Matrizen:

*[[Zielsituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_Matrix_IVS-Informationsobjekte/_IVS-Datenmodelle|Zielsituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Matrix IVS-Informationsobjekte/Datenmodelle]]
*[[Zielsituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_Matrix_IVS-Datenmodelle/_IVS-Ortsreferenzierungssysteme|Zielsituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Matrix IVS-Datenmodelle/ IVS-Ortsreferenzierungssysteme]]

=== Gap-Analyse für die IVS-Datenarchitektur ===

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

Ergebnisse:

*[[Gap-Analyse_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Informationsobjekte|Gap-Analyse IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Informationsobjekte]]
*[[Gap-Analyse_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Datenmodelle|Gap-Analyse IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Datenmodelle]]
*[[Gap-Analyse_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Ortsreferenzierungssysteme|Gap-Analyse IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Ortsreferenzierungssysteme]]

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

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

Ergebnis: [[IVS-Architektur-Roadmap_-_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Datenarchitektur|IVS-Architektur-Roadmap - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Datenarchitektur]]

----

=== Ergebnisse IVS-Anwendungsarchitektur ===

==== Hilfsmittel, Sichten und Werkzeuge für IVS-Anwendungsarchitektur ====

Die IVS-Anwendungsarchitektur fokussiert IVS-Anwendungen und deren IVS-Schnittstellen im Zuständigkeitsübergreifenden Verkehrsmanagement, die für die Ausführung der zuständigkeitsübergreifenden IVS-Geschäftsprozesse erforderlich sind.

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

Für die Darstellung der Anwendungsarchitektur im Zuständigkeitsübergreifenden Verkehrsmanagement schlägt die IVS-Rahmenarchitektur folgende Modellierungsprinzipien bzw. -werkzeuge vor:

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

Ergebnis: [[Hilfsmittel_zur_Darstellung_der_IVS-Anwendungsarchitektur_-_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement|Hilfsmittel zur Darstellung der IVS-Anwendungsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== Ausgangssituation der IVS-Anwendungsarchitektur ====

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

Ergebnis: [[Ausgangssituation_Anwendungsarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement|Ausgangssituation IVS-Anwendungsarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== Zielsituation der IVS-Anwendungsarchitektur ====

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

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

Ergebnis: [[Zielsituation_Anwendungsarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Anwendung|Zielsituation IVS-Anwendungsarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== Gap-Analyse für die IVS-Anwendungsarchitektur ====

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

Ergebnis: [[Gap-Analyse_Anwendungsarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Anwendung|Gap-Analyse IVS-Anwendungsarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

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

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

Ergebnis: [[IVS-Architektur-Roadmap_-_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Anwendungsarchitektur|IVS-Architektur-Roadmap - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Anwendungsarchitektur]]

----

=== Ergebnisse IVS-Technologiearchitektur ===

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

== Literaturverzeichnis ==

<references />

----

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

IVS-Referenzarchitektur für Zuständigkeitsübergreifendes Verkehrsmanagement 1.0

2018-08-29T10:57:11Z

Albrecht:

== Vorbereitungsphase ==

=== Steuerungs- und Unterstützungsframeworks ===

Mit den Steuerungs- und Unterstützungsframeworks für IVS-Architektur werden generell IVS-Architekturprojekte motiviert, begründet und gestützt. Der Inhalt dieser Frameworks bildet im Prinzip auch den Geist, in dem IVS-Architekturprojekte durchgeführt werden.

Für die IVS-Rahmenarchitektur bilden der Europäische IVS-Aktionsplan und die IVS-Direktive sowie auf nationaler Ebene das IVS-Gesetz und der Nationale IVS-Aktionsplan Straße die wesentlichen Frameworks. Für die IVS-Referenzarchitektur für Zuständigkeitsübergreifendes Verkehrsmanagement setzen neben den rechtlichen Vorgaben auch interne Vorgaben der einzelnen Stakeholder und Akteure den rechtlichen Handlungsrahmen.

Ergebnis: [[PhaseV-Step3-Los3_SteuerungsUndUnterstützungsframeworks|IVS-Steuerungs- und Unterstützungsframeworks für Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== IVS-Glossar ===

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

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

Für das Glossar für Zuständigkeitsübergreifendes Verkehrsmanagement gilt:

*Die Begriffsbestimmungen für IVS-Architektur (siehe [[IVS-Architekturbausteine#IVS-Architektur...|Was ist IVS-Architektur? - Schlüsselbegriffe]] und [[IVS-Architekturbausteine|Begriffe für die IVS-Gestaltungsmerkmale von IVS-Architektur]]) werden auf Zuständigkeitsübergreifendes Verkehrsmanagement übertragen.
*[[IVS-Glossar#Begriffsdefinitionen|Allgemeine Begriffe aus Verkehr, Transport und Mobilität]], die keine spezifische IVS-Architektur-Semantik repräsentieren, werden für Zuständigkeitsübergreifendes Verkehrsmanagement ergänzt.

Ergebnis: [[Los3_Glossar|IVS-Glossar für Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== Architekturprinzipien ===

Prinzipien stellen Grundsätze dar, die nicht nur dauerhaft gelten, sondern auch selten geändert werden sollten. Sie beschreiben die Art und Weise, wie eine davon betroffene Organisation ihre Aufgaben zu erfüllen hat. Prinzipien können für verschiedene Ebenen entwickelt und definiert werden.

Zur Detaillierung werden IVS-Architekturprinzipien gemäß den Ebenen von IVS-Architektur in folgende Untergruppen aufgeteilt:

*Geschäftsprinzip
*Daten-/Informationsprinzip
*Anwendungsprinzip
*Technologieprinzip

Ergebnis: [[Los3_IVS-Architekturprinzipien|IVS-Architekturprinzipien für Zuständigkeitsübergreifendes Verkehrsmanagement]]

----

== Phase Architektur Vision ==

=== Aufsetzen eines Architekturprojekts ===

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

*den IVS-Betrachtungsgegenstand "Zuständigkeitsübergreifendes Verkehrsmanagement" semantisch zu beschreiben (was ist der IVS-Betrachtungsgegenstand Zuständigkeitsübergreifendes Verkehrsmanagement) und
*klare Grenzen zu ähnlichen bzw. angrenzenden IVS-Betrachtungsgegenständen des Zuständigkeitsübergreifenden Verkehrsmanagements zu ziehen und festzulegen ('''was ist drin, was ist nicht drin''').

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

*Eine IVS-Referenzarchitektur soll verschiedene Gestaltungskonzepte für eine IVS-Dienstekategorie vorweisen.
*Bei der IVS-Architektur eines realen IVS-Dienstes müssen verschiedene Implementierungskonzepte für einen spezifischen IVS-Dienst erstellt werden.

Ergebnisse:

==== IVS-Domäne für Zuständigkeitsübergreifendes Verkehrsmanagement ====

*[[IVS-Domäne_Zuständigkeitsübergreifenden_Verkehrsmanagements_-_Template|IVS-Domäne für Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== IVS-Dienste(-kategorie) für Zuständigkeitsübergreifendes Verkehrsmanagement ====

*[[IVS-Dienste_Los3|IVS-Dienste(-kategorie) für Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== Zuständigkeitsübergreifendes Verkehrsmanagement - Allgemeine Beschreibung ====

*[[Zuständigkeitsübergreifendes_Verkehrsmanagement_-_Allgemeine_Beschreibung|Zuständigkeitsübergreifendes Verkehrsmanagement - Allgemeine Beschreibung]]

=== Erfassen und Beschreibung 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 in die IVS-Wertschöpfung zu involvierenden IVS-Akteure und die zu beteiligenden IVS-Stakeholder erfasst und beschrieben werden.

Dazu ist es nützlich - in Vorbereitung für den Schritt Entwicklung einer IVS-Architekturvision - eine erste Vorstellung für den IVS-Dienst/die IVS-Dienstekategorie zugrunde zu legen und darüber die erforderlichen IVS-Rollen in der IVS-Wertschöpfungskette/im IVS-Wertschöpfungsnetzwerk zu veranschaulichen.

Zur Ergebnisdarstellung werden zwei IVS-Bausteine verwendet:

*Der Baustein IVS-Rollen-Map, mit dem Stereotype von IVS-Akteuren und IVS-Stakeholdern deklariert, mit ihren Geschäftsanliegen und IVS-Rollen beschrieben und die Bedeutung von IVS-Akteuren und IVS-Stakeholdern gemäß "Power-Grid" klassifiziert werden.

*Der Baustein IVS-Rolle, mit dem Stereotype von IVS-Fähigkeiten und IVS-Verantwortlichkeiten, die für die Bereitstellung und den Betrieb von IVS-Diensten typisch und erforderlich sind, bezeichnet und semantisch beschrieben werden.

Ergebnisse:

*[[PhaseA-Step2-Los3_ErfassungUndBeschreibungVonRollen|IVS-Rollen im Zuständigkeitsübergreifenden Verkehrsmanagement - Allgemeine Beschreibung]]
*[[IVS-Rollen_Los3|IVS-Rollen-Map und IVS-Rollen Power-Grid für Zuständigkeitsübergreifendes Verkehrsmanagement]]
*[[IVS-Business_Szenarios_und_IVS-Anforderungen_Los_3_-_Zuständigkeitsübergreifendes_Verkehrsmanagement|IVS-Business Szenarios und IVS-Anforderungen für Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== Ziele, strategische Einflussfaktoren und Rahmenbedingungen ===

==== IVS-Leitbilder ====

Die Akzeptanz von Maßnahmen des Verkehrsmanagements wird beim Verkehrsteilnehmer erhöht, wenn sich der Betrieb an seinen Mobilitätsbedürfnissen und tatsächlichen Wegen orientiert und nicht an Zuständigkeitsgrenzen endet oder das Erscheinungsbild wechselt. Bei den indirekt beteiligten IVS-Stakeholdern und IVS-Akteuren wird eine hohe Akzeptanz erwartet, weil die "IVS-Referenzarchitektur für Zuständigkeitsübergreifendes Verkehrsmanagement" die Planungs- und Investitionssicherheit verbessert (Vermeidung von Insellösungen) und interoperable, betrieblich effiziente Lösungen begünstigt.

Ergebnis: [[IVS-Leitbilder_Los3|IVS-Leitbilder für Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== IVS-Geschäftsziele ====

Das Straßen- und Verkehrswesen kann einen Beitrag dazu leisten, die Lebensqualität der einzelnen Individuen zu steigern. Diese Forderung wird durch Definition der vier Oberziele des Verkehrs bekräftigt:

*Erhöhung der Sicherheit,
*Befriedigung des Mobilitätsbedürfnisses,
*Schonung der Umwelt und
*Verbesserung der Wirtschaftlichkeit.

Das Zuständigkeitsübergreifende Verkehrsmanagement setzt an dieser Stelle an. Durch gezielte Maßnahmen oder Maßnahmenbündel, die den gleichzeitigen Einsatz mehrerer Verkehrssysteme und -mittel (multimodal) oder den Wechsel der Verkehrssysteme (intermodal) innerhalb und außerhalb des eigenen Zuständigkeitsbereichs berücksichtigen, sollen Probleme oder bestimmte Situationen im regionalen und/oder überregionalen Verkehrssystem reduziert bzw. verbessert werden.

Ergebnis: [[IVS-Geschäftsziele_Los3|IVS-Geschäftsziele für Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== IVS-Capabilities ===

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

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

Grobe Vorstellungen für die Wertschöpfungskette des Zuständigkeitsübergreifenden Verkehrsmanagements zeigen folgenden Abbildungen:

<gallery mode="packed-hover">
File:TMValueChain.png | Wertschöpfungskette Verkehrsmanagement
File:WertschöpfungImSystemStrasse.png | System Strasse (Quelle Hessen Mobil)
</gallery>

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

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

Ergebnis: [[IVS-Capabilities_Los3|IVS-Capabilities für Zuständigkeitsübergreifenden Verkehrsmanagement]]

=== IVS-Architektur Vision ===

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

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

*Die Idee (für den IVS-Dienst),

:
::die die Kernaufgabe, die Nutzung und die Schnittstellen, das heißt den Kontext des zu erstellenden IVS-Dienstes aufzeigt.

*Einflussfaktoren und Randbedingungen

:
::wie funktionale und nicht-funktionale Anforderungen, organisatorische und technische Einflüsse.

*Lösungsstrategien

:
::halten die ersten Entscheidungen, wesentliche Architektur-Muster und Konzepte fest. Erste Architektursichten können entstehen, um die Lösungsstrategien zu verdeutlichen.

Ergebnis: [[IVS-Archtekturvision_Los3|IVS-Architektur Vision für Zuständigkeitsübergreifendes Verkehrsmanagement]]

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

Um den IVS-Dienst "Zuständigkeitsübergreifendes Verkehrsmanagement" realisieren zu können, müssen verschiedene IVS-Akteure zusammenarbeiten, sobald für eine Routenempfehlung die Aktorik, die Sensorik und/oder die Alternativroute oder Teile davon benötigt werden, die nicht in den eigenen Zuständigkeitsbereich fallen. Somit hängt die Interoperabilität von IVS-Akteuren im IVS-Dienst "Zuständigkeitsübergreifendes Verkehrsmanagement" im Wesentlichen davon ab, wie nahtlos diese zusammenarbeiten bzw. wie interoperabel diese ihre IVS-Geschäftsfähigkeiten gestalten können. Interoperabilität wird somit in den Mittelpunkt der architekturellen Bemühungen gestellt und die Bereitstellung von Interoperabilitäts-Bausteinen zum Kernziel von IVS-Architektur.

Ergebnis: [[IVS-Wertbeitrag_Los3|Wertbeitrag und KPIs von IVS-Architektur für Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== Risiken der Einführung einer IVS-Referenzarchitektur für zuständigkeitsübergreifendes Verkehrsmanagement ===

Die Einführung einer IVS-Architektur birgt auch Risiken. Das Risikomanagement soll genutzt wer-den, um die Risiken Einführung einer IVS-Referenzarchitektur für Zuständigkeitsübergreifenden Verkehrsmanagements zu erkennen, zu beurteilen und handzuhaben.

Ergebnis: [[Risiken_Los3|Risiken der Einführung einer IVS-Referenzarchitektur für Zuständigkeitsübergreifendes Verkehrsmanagement]]

----

== Phase Geschäftsarchitektur ==

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

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

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

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

*für die Sicht "IVS-Wertschöpfungskette/IVS-Wertschöpfungsnetzwerk"

:
:*Darstellung als '''IVS-Rollenmatrix''', wie sie im Projekt [[Media:ÖV-IVS_Schlussbericht_März_2014.pdf|Entwicklung einer ÖV-IVS-Rahmenarchitektur in Deutschland unter Einbindung Europäischer IVS-Richtlinien mit ÖV-Relevanz<ref>Kieslich, Wolfgang; Albrecht, Hanfried; Dinkel, Alexander u.a. (2014): Entwicklung einer für ÖV-IVS-Architektur in Deutschland unter Einbindung Europäischer IVS-Richtlinien mit ÖPNV-Relevanz. Schlussbericht. Im Auftrag des Bundesministeriums für Verkehr und digitale Infrastruktur. München.</ref>]] entwickelt wurde. Eine Anleitung findet sich [[Aufbau_von_IVS-Wertschöfungsketten_und_-netzwerke|'''hier''']].
:*Darstellung als '''Rollen/Capability-Diagramm'''. Ein Beispiel finden Sie '''[[PhaseB-Step2-Los3#Sicht_.22Wertsch.C3.B6pfungskette.2FWertsch.C3.B6pfungsnetzwerk.22_f.C3.BCr_Zust.C3.A4ndigkeits.C3.BCbergreifendes_Verkehrsmanagement|hier]]'''.

*für die Sicht "IVS-Governance"

:
::Für die Darstellung wird ein Textdokument empfohlen. Eine Beschreibungsstruktur findet sich [[IVS-Governance|hier]].

*für die Sicht "IVS-Geschäftsprozesse"

:
::für die Darstellung und Visualisierung der IVS-Geschäftsprozessarchitektur wird grundsätzlich ein Prozessmodellierungs-Ansatz gewählt. Durch das Aufschlüsseln von Geschäftsfunktionen und Geschäftsdiensten mit Hilfe der Prozessmodellierung wird die Identifizierung der Schlüssel-Prozesse und der nachgeordneten Dienste und Funktionen ermöglicht.
::*Ein Template zur Beschreibung von Geschäftsprozessen findet sich [[IVS-Geschäftsprozess|hier]].
::*Zur Modellierung von Geschäftsprozessen und Geschäftsfunktionen wird die Spezifikationssprache Business Process Model and Notation (BPMN) verwendet. Eine Anleitung findet sich [[Geschäftsprozessdiagramm|hier]].

Ergebnis: [[Hilfsmittel_und_Werkzeuge_Los3|Hilfsmittel zur Darstellung der IVS-Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== Ausgangssituation der IVS-Geschäftsarchitektur ===

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

*Sicht "IVS-Wertschöpfungsketten und -netzwerke"

:
::Die [[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.

*Sicht "IVS-Governance"

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

*Sicht "IVS-Geschäftsprozesse"

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

Ergebnisse:

*[[Ausgangssituation_Geschäftsarchitektur_Los_3_-_Sicht_Wertschöpfungsnetzwerk|Ausgangssituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Wertschöpfungsnetzwerk]]
*[[Ausgangssituation_Geschäftsarchitektur_Los_3_-_Sicht_Governance|Ausgangssituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Governance]]
*[[Ausgangssituation_Geschäftsarchitektur_Los_3_-_Sicht_Geschäftsprozesse|Ausgangssituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Geschäftsprozesse]]

=== Zielsituation der IVS-Geschäftsarchitektur ===

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

*Sicht [[Aufbau_von_IVS-Wertschöfungsketten_und_-netzwerke|"IVS-Wertschöpfungskette/IVS-Wertschöpfungsnetzwerk"]]

:
::Identifizierung, Darstellung und Beschreibung, über welche Bestandteile (Teildienste) der IVS-Dienst gebildet wird, welche IVS-Rollen daran beteiligt sein müssen und welche Anforderungen (IVS-Capabilities) an diese gestellt werden.

*Sicht [[IVS-Governance|"IVS-Governance"]]

:
::Beschreibung, auf welcher gesetzlichen, rechtlichen und vertraglichen Grundlage der IVS-Dienst und die Zusammenarbeit der IVS-Akteure zustande kommen und wie letztere operativ geführt und gesteuert wird.

*Sicht [[IVS-Geschäftsprozesse_und_Wertschöpfungsnetzwerke|"IVS-Geschäftsprozesse"]]

:
::Darstellung und Beschreibung, über welche Schlüssel-Geschäftsprozesse der IVS-Dienst operationalisiert wird.

Weitere Sichten können projektspezifisch aufgebaut und beschrieben werden.

Ergebnisse:

*[[Zielsituation_Geschäftsarchitektur_Los_3_-_Sicht_Wertschöpfungsnetzwerk|Zielsituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Wertschöpfungsnetzwerk]]
*[[Zielsituation_Geschäftsarchitektur_Los_3_-_Sicht_Governance|Zielsituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Governance]]
*[[Zielsituation_Geschäftsarchitektur_Los_3_-_Sicht_Geschäftsprozesse|Zielsituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Geschäftsprozesse]]

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

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

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

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

Ergebnisse:

*[[Gap-Analyse_Geschäftsarchitektur_Los_3_-_Sicht_Wertschöpfungsnetzwerk|Gap-Analyse Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Wertschöpfungsnetzwerk]]
*[[Gap-Analyse_Geschäftsarchitektur_Los_3_-_Sicht_Governance|Gap-Analyse Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Governance]]
*[[Gap-Analyse_Geschäftsarchitektur_Los_3_-_Sicht_Geschäftsprozesse|Gap-Analyse Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Geschäftsprozesse]]

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

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

Zur Beschreibung der einzelnen Arbeitsschritte sowie zur Festlegung von zeitlichen und inhaltlichen Abhängigkeiten zwischen den einzelnen Arbeitsschritten wird der Katalog [[Media:Architektur-Roadmap_00-00-01.docx|Architektur-Roadmap]] verwendet.

Ergebnis: [[IVS-Architektur-Roadmap_Los3|IVS-Architektur-Roadmap - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

----

=== Ergebnisse IVS-Datenarchitektur ===

==== Hilfsmittel, Sichten und Werkzeuge für IVS-Datenarchitektur ====

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

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

Ergebnis: [[Hilfsmittel_zur_Darstellung_der_IVS-Datenarchitektur_-_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement|Hilfsmittel zur Darstellung der IVS-Datenarchitektur für Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== Ausgangssituation der IVS-Datenarchitektur ====

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

Ergebnisse - Kataloge:

*[[Ausgangssituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement|Ausgangssituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Informationsobjekte]]
*[[Ausgangssituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_IVS-Datenmodelle|Ausgangssituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Datenmodelle]]
*[[Ausgangssituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_IVS-Ortsreferenzierung|Ausgangssituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Ortsreferenzierungen]]

Ergebnisse - Matrizen:

*[[Ausgangssituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_Matrix_IVS-Informationsobjekte/_IVS-Datenmodelle|Ausgangssituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Matrix IVS-Informationsobjekte/Datenmodelle]]
*[[Ausgangssituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_Matrix_IVS-Datenmodelle/_IVS-Ortsreferenzierungssysteme|Ausgangssituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Matrix IVS-Datenmodelle/ IVS-Ortsreferenzierungssysteme]]

==== Zielsituation der IVS-Datenarchitektur ====

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

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

Ergebnisse - Kataloge:

*[[Zielsituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Informationsobjekte|Zielsituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Informationsobjekte]]
*[[Zielsituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Datenmodelle|Zielsituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Datenmodelle]]
*[[Zielsituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Ortsreferenzierung|Zielsituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Ortsreferenzierung]]

Ergebnisse - Matrizen:

*[[Zielsituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_Matrix_IVS-Informationsobjekte/_IVS-Datenmodelle|Zielsituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Matrix IVS-Informationsobjekte/Datenmodelle]]
*[[Zielsituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_Matrix_IVS-Datenmodelle/_IVS-Ortsreferenzierungssysteme|Zielsituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Matrix IVS-Datenmodelle/ IVS-Ortsreferenzierungssysteme]]

==== Gap-Analyse für die IVS-Datenarchitektur ====

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

Ergebnisse:

*[[Gap-Analyse_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Informationsobjekte|Gap-Analyse IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Informationsobjekte]]
*[[Gap-Analyse_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Datenmodelle|Gap-Analyse IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Datenmodelle]]
*[[Gap-Analyse_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Ortsreferenzierungssysteme|Gap-Analyse IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Ortsreferenzierungssysteme]]

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

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

Ergebnis: [[IVS-Architektur-Roadmap_-_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Datenarchitektur|IVS-Architektur-Roadmap - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Datenarchitektur]]

----

=== Ergebnisse IVS-Anwendungsarchitektur ===

==== Hilfsmittel, Sichten und Werkzeuge für IVS-Anwendungsarchitektur ====

Die IVS-Anwendungsarchitektur fokussiert IVS-Anwendungen und deren IVS-Schnittstellen im Zuständigkeitsübergreifenden Verkehrsmanagement, die für die Ausführung der zuständigkeitsübergreifenden IVS-Geschäftsprozesse erforderlich sind.

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

Für die Darstellung der Anwendungsarchitektur im Zuständigkeitsübergreifenden Verkehrsmanagement schlägt die IVS-Rahmenarchitektur folgende Modellierungsprinzipien bzw. -werkzeuge vor:

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

Ergebnis: [[Hilfsmittel_zur_Darstellung_der_IVS-Anwendungsarchitektur_-_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement|Hilfsmittel zur Darstellung der IVS-Anwendungsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== Ausgangssituation der IVS-Anwendungsarchitektur ====

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

Ergebnis: [[Ausgangssituation_Anwendungsarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement|Ausgangssituation IVS-Anwendungsarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== Zielsituation der IVS-Anwendungsarchitektur ====

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

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

Ergebnis: [[Zielsituation_Anwendungsarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Anwendung|Zielsituation IVS-Anwendungsarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== Gap-Analyse für die IVS-Anwendungsarchitektur ====

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

Ergebnis: [[Gap-Analyse_Anwendungsarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Anwendung|Gap-Analyse IVS-Anwendungsarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

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

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

Ergebnis: [[IVS-Architektur-Roadmap_-_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Anwendungsarchitektur|IVS-Architektur-Roadmap - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Anwendungsarchitektur]]

----

=== Ergebnisse IVS-Technologiearchitektur ===

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

== Literaturverzeichnis ==

<references />

----

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

IVS-Referenzarchitektur für Zuständigkeitsübergreifendes Verkehrsmanagement 1.0

2018-08-29T10:56:54Z

Albrecht:

== Vorbereitungsphase ==

=== Steuerungs- und Unterstützungsframeworks ===

Mit den Steuerungs- und Unterstützungsframeworks für IVS-Architektur werden generell IVS-Architekturprojekte motiviert, begründet und gestützt. Der Inhalt dieser Frameworks bildet im Prinzip auch den Geist, in dem IVS-Architekturprojekte durchgeführt werden.

Für die IVS-Rahmenarchitektur bilden der Europäische IVS-Aktionsplan und die IVS-Direktive sowie auf nationaler Ebene das IVS-Gesetz und der Nationale IVS-Aktionsplan Straße die wesentlichen Frameworks. Für die IVS-Referenzarchitektur für Zuständigkeitsübergreifendes Verkehrsmanagement setzen neben den rechtlichen Vorgaben auch interne Vorgaben der einzelnen Stakeholder und Akteure den rechtlichen Handlungsrahmen.

Ergebnis: [[PhaseV-Step3-Los3_SteuerungsUndUnterstützungsframeworks|IVS-Steuerungs- und Unterstützungsframeworks für Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== IVS-Glossar ===

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

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

Für das Glossar für Zuständigkeitsübergreifendes Verkehrsmanagement gilt:

*Die Begriffsbestimmungen für IVS-Architektur (siehe [[IVS-Architekturbausteine#IVS-Architektur...|Was ist IVS-Architektur? - Schlüsselbegriffe]] und [[IVS-Architekturbausteine|Begriffe für die IVS-Gestaltungsmerkmale von IVS-Architektur]]) werden auf Zuständigkeitsübergreifendes Verkehrsmanagement übertragen.
*[[IVS-Glossar#Begriffsdefinitionen|Allgemeine Begriffe aus Verkehr, Transport und Mobilität]], die keine spezifische IVS-Architektur-Semantik repräsentieren, werden für Zuständigkeitsübergreifendes Verkehrsmanagement ergänzt.

Ergebnis: [[Los3_Glossar|IVS-Glossar für Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== Architekturprinzipien ===

Prinzipien stellen Grundsätze dar, die nicht nur dauerhaft gelten, sondern auch selten geändert werden sollten. Sie beschreiben die Art und Weise, wie eine davon betroffene Organisation ihre Aufgaben zu erfüllen hat. Prinzipien können für verschiedene Ebenen entwickelt und definiert werden.

Zur Detaillierung werden IVS-Architekturprinzipien gemäß den Ebenen von IVS-Architektur in folgende Untergruppen aufgeteilt:

*Geschäftsprinzip
*Daten-/Informationsprinzip
*Anwendungsprinzip
*Technologieprinzip

Ergebnis: [[Los3_IVS-Architekturprinzipien|IVS-Architekturprinzipien für Zuständigkeitsübergreifendes Verkehrsmanagement]]

----

== Phase Architektur Vision ==

=== Aufsetzen eines Architekturprojekts ===

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

*den IVS-Betrachtungsgegenstand "Zuständigkeitsübergreifendes Verkehrsmanagement" semantisch zu beschreiben (was ist der IVS-Betrachtungsgegenstand Zuständigkeitsübergreifendes Verkehrsmanagement) und
*klare Grenzen zu ähnlichen bzw. angrenzenden IVS-Betrachtungsgegenständen des Zuständigkeitsübergreifenden Verkehrsmanagements zu ziehen und festzulegen ('''was ist drin, was ist nicht drin''').

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

*Eine IVS-Referenzarchitektur soll verschiedene Gestaltungskonzepte für eine IVS-Dienstekategorie vorweisen.
*Bei der IVS-Architektur eines realen IVS-Dienstes müssen verschiedene Implementierungskonzepte für einen spezifischen IVS-Dienst erstellt werden.

Ergebnisse:

==== IVS-Domäne für Zuständigkeitsübergreifendes Verkehrsmanagement ====

*[[IVS-Domäne_Zuständigkeitsübergreifenden_Verkehrsmanagements_-_Template|IVS-Domäne für Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== IVS-Dienste(-kategorie) für Zuständigkeitsübergreifendes Verkehrsmanagement ====

*[[IVS-Dienste_Los3|IVS-Dienste(-kategorie) für Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== Zuständigkeitsübergreifendes Verkehrsmanagement - Allgemeine Beschreibung ====

*[[Zuständigkeitsübergreifendes_Verkehrsmanagement_-_Allgemeine_Beschreibung|Zuständigkeitsübergreifendes Verkehrsmanagement - Allgemeine Beschreibung]]

=== Erfassen und Beschreibung 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 in die IVS-Wertschöpfung zu involvierenden IVS-Akteure und die zu beteiligenden IVS-Stakeholder erfasst und beschrieben werden.

Dazu ist es nützlich - in Vorbereitung für den Schritt Entwicklung einer IVS-Architekturvision - eine erste Vorstellung für den IVS-Dienst/die IVS-Dienstekategorie zugrunde zu legen und darüber die erforderlichen IVS-Rollen in der IVS-Wertschöpfungskette/im IVS-Wertschöpfungsnetzwerk zu veranschaulichen.

Zur Ergebnisdarstellung werden zwei IVS-Bausteine verwendet:

*Der Baustein IVS-Rollen-Map, mit dem Stereotype von IVS-Akteuren und IVS-Stakeholdern deklariert, mit ihren Geschäftsanliegen und IVS-Rollen beschrieben und die Bedeutung von IVS-Akteuren und IVS-Stakeholdern gemäß "Power-Grid" klassifiziert werden.

*Der Baustein IVS-Rolle, mit dem Stereotype von IVS-Fähigkeiten und IVS-Verantwortlichkeiten, die für die Bereitstellung und den Betrieb von IVS-Diensten typisch und erforderlich sind, bezeichnet und semantisch beschrieben werden.

Ergebnisse:

*[[PhaseA-Step2-Los3_ErfassungUndBeschreibungVonRollen|IVS-Rollen im Zuständigkeitsübergreifenden Verkehrsmanagement - Allgemeine Beschreibung]]
*[[IVS-Rollen_Los3|IVS-Rollen-Map und IVS-Rollen Power-Grid für Zuständigkeitsübergreifendes Verkehrsmanagement]]
*[[IVS-Business_Szenarios_und_IVS-Anforderungen_Los_3_-_Zuständigkeitsübergreifendes_Verkehrsmanagement|IVS-Business Szenarios und IVS-Anforderungen für Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== Ziele, strategische Einflussfaktoren und Rahmenbedingungen ===

==== IVS-Leitbilder ====

Die Akzeptanz von Maßnahmen des Verkehrsmanagements wird beim Verkehrsteilnehmer erhöht, wenn sich der Betrieb an seinen Mobilitätsbedürfnissen und tatsächlichen Wegen orientiert und nicht an Zuständigkeitsgrenzen endet oder das Erscheinungsbild wechselt. Bei den indirekt beteiligten IVS-Stakeholdern und IVS-Akteuren wird eine hohe Akzeptanz erwartet, weil die "IVS-Referenzarchitektur für Zuständigkeitsübergreifendes Verkehrsmanagement" die Planungs- und Investitionssicherheit verbessert (Vermeidung von Insellösungen) und interoperable, betrieblich effiziente Lösungen begünstigt.

Ergebnis: [[IVS-Leitbilder_Los3|IVS-Leitbilder für Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== IVS-Geschäftsziele ====

Das Straßen- und Verkehrswesen kann einen Beitrag dazu leisten, die Lebensqualität der einzelnen Individuen zu steigern. Diese Forderung wird durch Definition der vier Oberziele des Verkehrs bekräftigt:

*Erhöhung der Sicherheit,
*Befriedigung des Mobilitätsbedürfnisses,
*Schonung der Umwelt und
*Verbesserung der Wirtschaftlichkeit.

Das Zuständigkeitsübergreifende Verkehrsmanagement setzt an dieser Stelle an. Durch gezielte Maßnahmen oder Maßnahmenbündel, die den gleichzeitigen Einsatz mehrerer Verkehrssysteme und -mittel (multimodal) oder den Wechsel der Verkehrssysteme (intermodal) innerhalb und außerhalb des eigenen Zuständigkeitsbereichs berücksichtigen, sollen Probleme oder bestimmte Situationen im regionalen und/oder überregionalen Verkehrssystem reduziert bzw. verbessert werden.

Ergebnis: [[IVS-Geschäftsziele_Los3|IVS-Geschäftsziele für Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== IVS-Capabilities ===

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

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

Grobe Vorstellungen für die Wertschöpfungskette des Zuständigkeitsübergreifenden Verkehrsmanagements zeigen folgenden Abbildungen:

<gallery mode="packed-hover">
File:TMValueChain.png | Wertschöpfungskette Verkehrsmanagement
File:WertschöpfungImSystemStrasse.png | System Strasse (Quelle Hessen Mobil)
</gallery>

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

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

Ergebnis: [[IVS-Capabilities_Los3|IVS-Capabilities für Zuständigkeitsübergreifenden Verkehrsmanagement]]

=== IVS-Architektur Vision ===

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

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

*Die Idee (für den IVS-Dienst),

:
::die die Kernaufgabe, die Nutzung und die Schnittstellen, das heißt den Kontext des zu erstellenden IVS-Dienstes aufzeigt.

*Einflussfaktoren und Randbedingungen

:
::wie funktionale und nicht-funktionale Anforderungen, organisatorische und technische Einflüsse.

*Lösungsstrategien

:
::halten die ersten Entscheidungen, wesentliche Architektur-Muster und Konzepte fest. Erste Architektursichten können entstehen, um die Lösungsstrategien zu verdeutlichen.

Ergebnis: [[IVS-Archtekturvision_Los3|IVS-Architektur Vision für Zuständigkeitsübergreifendes Verkehrsmanagement]]

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

Um den IVS-Dienst "Zuständigkeitsübergreifendes Verkehrsmanagement" realisieren zu können, müssen verschiedene IVS-Akteure zusammenarbeiten, sobald für eine Routenempfehlung die Aktorik, die Sensorik und/oder die Alternativroute oder Teile davon benötigt werden, die nicht in den eigenen Zuständigkeitsbereich fallen. Somit hängt die Interoperabilität von IVS-Akteuren im IVS-Dienst "Zuständigkeitsübergreifendes Verkehrsmanagement" im Wesentlichen davon ab, wie nahtlos diese zusammenarbeiten bzw. wie interoperabel diese ihre IVS-Geschäftsfähigkeiten gestalten können. Interoperabilität wird somit in den Mittelpunkt der architekturellen Bemühungen gestellt und die Bereitstellung von Interoperabilitäts-Bausteinen zum Kernziel von IVS-Architektur.

Ergebnis: [[IVS-Wertbeitrag_Los3|Wertbeitrag und KPIs von IVS-Architektur für Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== Risiken der Einführung einer IVS-Referenzarchitektur für zuständigkeitsübergreifendes Verkehrsmanagement ====

Die Einführung einer IVS-Architektur birgt auch Risiken. Das Risikomanagement soll genutzt wer-den, um die Risiken Einführung einer IVS-Referenzarchitektur für Zuständigkeitsübergreifenden Verkehrsmanagements zu erkennen, zu beurteilen und handzuhaben.

Ergebnis: [[Risiken_Los3|Risiken der Einführung einer IVS-Referenzarchitektur für Zuständigkeitsübergreifendes Verkehrsmanagement]]

----

== Phase Geschäftsarchitektur ==

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

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

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

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

*für die Sicht "IVS-Wertschöpfungskette/IVS-Wertschöpfungsnetzwerk"

:
:*Darstellung als '''IVS-Rollenmatrix''', wie sie im Projekt [[Media:ÖV-IVS_Schlussbericht_März_2014.pdf|Entwicklung einer ÖV-IVS-Rahmenarchitektur in Deutschland unter Einbindung Europäischer IVS-Richtlinien mit ÖV-Relevanz<ref>Kieslich, Wolfgang; Albrecht, Hanfried; Dinkel, Alexander u.a. (2014): Entwicklung einer für ÖV-IVS-Architektur in Deutschland unter Einbindung Europäischer IVS-Richtlinien mit ÖPNV-Relevanz. Schlussbericht. Im Auftrag des Bundesministeriums für Verkehr und digitale Infrastruktur. München.</ref>]] entwickelt wurde. Eine Anleitung findet sich [[Aufbau_von_IVS-Wertschöfungsketten_und_-netzwerke|'''hier''']].
:*Darstellung als '''Rollen/Capability-Diagramm'''. Ein Beispiel finden Sie '''[[PhaseB-Step2-Los3#Sicht_.22Wertsch.C3.B6pfungskette.2FWertsch.C3.B6pfungsnetzwerk.22_f.C3.BCr_Zust.C3.A4ndigkeits.C3.BCbergreifendes_Verkehrsmanagement|hier]]'''.

*für die Sicht "IVS-Governance"

:
::Für die Darstellung wird ein Textdokument empfohlen. Eine Beschreibungsstruktur findet sich [[IVS-Governance|hier]].

*für die Sicht "IVS-Geschäftsprozesse"

:
::für die Darstellung und Visualisierung der IVS-Geschäftsprozessarchitektur wird grundsätzlich ein Prozessmodellierungs-Ansatz gewählt. Durch das Aufschlüsseln von Geschäftsfunktionen und Geschäftsdiensten mit Hilfe der Prozessmodellierung wird die Identifizierung der Schlüssel-Prozesse und der nachgeordneten Dienste und Funktionen ermöglicht.
::*Ein Template zur Beschreibung von Geschäftsprozessen findet sich [[IVS-Geschäftsprozess|hier]].
::*Zur Modellierung von Geschäftsprozessen und Geschäftsfunktionen wird die Spezifikationssprache Business Process Model and Notation (BPMN) verwendet. Eine Anleitung findet sich [[Geschäftsprozessdiagramm|hier]].

Ergebnis: [[Hilfsmittel_und_Werkzeuge_Los3|Hilfsmittel zur Darstellung der IVS-Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== Ausgangssituation der IVS-Geschäftsarchitektur ===

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

*Sicht "IVS-Wertschöpfungsketten und -netzwerke"

:
::Die [[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.

*Sicht "IVS-Governance"

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

*Sicht "IVS-Geschäftsprozesse"

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

Ergebnisse:

*[[Ausgangssituation_Geschäftsarchitektur_Los_3_-_Sicht_Wertschöpfungsnetzwerk|Ausgangssituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Wertschöpfungsnetzwerk]]
*[[Ausgangssituation_Geschäftsarchitektur_Los_3_-_Sicht_Governance|Ausgangssituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Governance]]
*[[Ausgangssituation_Geschäftsarchitektur_Los_3_-_Sicht_Geschäftsprozesse|Ausgangssituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Geschäftsprozesse]]

=== Zielsituation der IVS-Geschäftsarchitektur ===

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

*Sicht [[Aufbau_von_IVS-Wertschöfungsketten_und_-netzwerke|"IVS-Wertschöpfungskette/IVS-Wertschöpfungsnetzwerk"]]

:
::Identifizierung, Darstellung und Beschreibung, über welche Bestandteile (Teildienste) der IVS-Dienst gebildet wird, welche IVS-Rollen daran beteiligt sein müssen und welche Anforderungen (IVS-Capabilities) an diese gestellt werden.

*Sicht [[IVS-Governance|"IVS-Governance"]]

:
::Beschreibung, auf welcher gesetzlichen, rechtlichen und vertraglichen Grundlage der IVS-Dienst und die Zusammenarbeit der IVS-Akteure zustande kommen und wie letztere operativ geführt und gesteuert wird.

*Sicht [[IVS-Geschäftsprozesse_und_Wertschöpfungsnetzwerke|"IVS-Geschäftsprozesse"]]

:
::Darstellung und Beschreibung, über welche Schlüssel-Geschäftsprozesse der IVS-Dienst operationalisiert wird.

Weitere Sichten können projektspezifisch aufgebaut und beschrieben werden.

Ergebnisse:

*[[Zielsituation_Geschäftsarchitektur_Los_3_-_Sicht_Wertschöpfungsnetzwerk|Zielsituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Wertschöpfungsnetzwerk]]
*[[Zielsituation_Geschäftsarchitektur_Los_3_-_Sicht_Governance|Zielsituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Governance]]
*[[Zielsituation_Geschäftsarchitektur_Los_3_-_Sicht_Geschäftsprozesse|Zielsituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Geschäftsprozesse]]

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

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

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

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

Ergebnisse:

*[[Gap-Analyse_Geschäftsarchitektur_Los_3_-_Sicht_Wertschöpfungsnetzwerk|Gap-Analyse Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Wertschöpfungsnetzwerk]]
*[[Gap-Analyse_Geschäftsarchitektur_Los_3_-_Sicht_Governance|Gap-Analyse Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Governance]]
*[[Gap-Analyse_Geschäftsarchitektur_Los_3_-_Sicht_Geschäftsprozesse|Gap-Analyse Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Geschäftsprozesse]]

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

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

Zur Beschreibung der einzelnen Arbeitsschritte sowie zur Festlegung von zeitlichen und inhaltlichen Abhängigkeiten zwischen den einzelnen Arbeitsschritten wird der Katalog [[Media:Architektur-Roadmap_00-00-01.docx|Architektur-Roadmap]] verwendet.

Ergebnis: [[IVS-Architektur-Roadmap_Los3|IVS-Architektur-Roadmap - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

----

=== Ergebnisse IVS-Datenarchitektur ===

==== Hilfsmittel, Sichten und Werkzeuge für IVS-Datenarchitektur ====

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

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

Ergebnis: [[Hilfsmittel_zur_Darstellung_der_IVS-Datenarchitektur_-_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement|Hilfsmittel zur Darstellung der IVS-Datenarchitektur für Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== Ausgangssituation der IVS-Datenarchitektur ====

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

Ergebnisse - Kataloge:

*[[Ausgangssituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement|Ausgangssituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Informationsobjekte]]
*[[Ausgangssituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_IVS-Datenmodelle|Ausgangssituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Datenmodelle]]
*[[Ausgangssituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_IVS-Ortsreferenzierung|Ausgangssituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Ortsreferenzierungen]]

Ergebnisse - Matrizen:

*[[Ausgangssituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_Matrix_IVS-Informationsobjekte/_IVS-Datenmodelle|Ausgangssituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Matrix IVS-Informationsobjekte/Datenmodelle]]
*[[Ausgangssituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_Matrix_IVS-Datenmodelle/_IVS-Ortsreferenzierungssysteme|Ausgangssituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Matrix IVS-Datenmodelle/ IVS-Ortsreferenzierungssysteme]]

==== Zielsituation der IVS-Datenarchitektur ====

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

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

Ergebnisse - Kataloge:

*[[Zielsituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Informationsobjekte|Zielsituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Informationsobjekte]]
*[[Zielsituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Datenmodelle|Zielsituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Datenmodelle]]
*[[Zielsituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Ortsreferenzierung|Zielsituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Ortsreferenzierung]]

Ergebnisse - Matrizen:

*[[Zielsituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_Matrix_IVS-Informationsobjekte/_IVS-Datenmodelle|Zielsituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Matrix IVS-Informationsobjekte/Datenmodelle]]
*[[Zielsituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_Matrix_IVS-Datenmodelle/_IVS-Ortsreferenzierungssysteme|Zielsituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Matrix IVS-Datenmodelle/ IVS-Ortsreferenzierungssysteme]]

==== Gap-Analyse für die IVS-Datenarchitektur ====

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

Ergebnisse:

*[[Gap-Analyse_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Informationsobjekte|Gap-Analyse IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Informationsobjekte]]
*[[Gap-Analyse_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Datenmodelle|Gap-Analyse IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Datenmodelle]]
*[[Gap-Analyse_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Ortsreferenzierungssysteme|Gap-Analyse IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Ortsreferenzierungssysteme]]

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

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

Ergebnis: [[IVS-Architektur-Roadmap_-_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Datenarchitektur|IVS-Architektur-Roadmap - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Datenarchitektur]]

----

=== Ergebnisse IVS-Anwendungsarchitektur ===

==== Hilfsmittel, Sichten und Werkzeuge für IVS-Anwendungsarchitektur ====

Die IVS-Anwendungsarchitektur fokussiert IVS-Anwendungen und deren IVS-Schnittstellen im Zuständigkeitsübergreifenden Verkehrsmanagement, die für die Ausführung der zuständigkeitsübergreifenden IVS-Geschäftsprozesse erforderlich sind.

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

Für die Darstellung der Anwendungsarchitektur im Zuständigkeitsübergreifenden Verkehrsmanagement schlägt die IVS-Rahmenarchitektur folgende Modellierungsprinzipien bzw. -werkzeuge vor:

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

Ergebnis: [[Hilfsmittel_zur_Darstellung_der_IVS-Anwendungsarchitektur_-_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement|Hilfsmittel zur Darstellung der IVS-Anwendungsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== Ausgangssituation der IVS-Anwendungsarchitektur ====

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

Ergebnis: [[Ausgangssituation_Anwendungsarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement|Ausgangssituation IVS-Anwendungsarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== Zielsituation der IVS-Anwendungsarchitektur ====

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

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

Ergebnis: [[Zielsituation_Anwendungsarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Anwendung|Zielsituation IVS-Anwendungsarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== Gap-Analyse für die IVS-Anwendungsarchitektur ====

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

Ergebnis: [[Gap-Analyse_Anwendungsarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Anwendung|Gap-Analyse IVS-Anwendungsarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

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

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

Ergebnis: [[IVS-Architektur-Roadmap_-_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Anwendungsarchitektur|IVS-Architektur-Roadmap - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Anwendungsarchitektur]]

----

=== Ergebnisse IVS-Technologiearchitektur ===

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

== Literaturverzeichnis ==

<references />

----

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

IVS-Referenzarchitektur für Zuständigkeitsübergreifendes Verkehrsmanagement 1.0

2018-08-29T10:56:39Z

Albrecht:

== Vorbereitungsphase ==

=== Steuerungs- und Unterstützungsframeworks ===

Mit den Steuerungs- und Unterstützungsframeworks für IVS-Architektur werden generell IVS-Architekturprojekte motiviert, begründet und gestützt. Der Inhalt dieser Frameworks bildet im Prinzip auch den Geist, in dem IVS-Architekturprojekte durchgeführt werden.

Für die IVS-Rahmenarchitektur bilden der Europäische IVS-Aktionsplan und die IVS-Direktive sowie auf nationaler Ebene das IVS-Gesetz und der Nationale IVS-Aktionsplan Straße die wesentlichen Frameworks. Für die IVS-Referenzarchitektur für Zuständigkeitsübergreifendes Verkehrsmanagement setzen neben den rechtlichen Vorgaben auch interne Vorgaben der einzelnen Stakeholder und Akteure den rechtlichen Handlungsrahmen.

Ergebnis: [[PhaseV-Step3-Los3_SteuerungsUndUnterstützungsframeworks|IVS-Steuerungs- und Unterstützungsframeworks für Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== IVS-Glossar ===

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

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

Für das Glossar für Zuständigkeitsübergreifendes Verkehrsmanagement gilt:

*Die Begriffsbestimmungen für IVS-Architektur (siehe [[IVS-Architekturbausteine#IVS-Architektur...|Was ist IVS-Architektur? - Schlüsselbegriffe]] und [[IVS-Architekturbausteine|Begriffe für die IVS-Gestaltungsmerkmale von IVS-Architektur]]) werden auf Zuständigkeitsübergreifendes Verkehrsmanagement übertragen.
*[[IVS-Glossar#Begriffsdefinitionen|Allgemeine Begriffe aus Verkehr, Transport und Mobilität]], die keine spezifische IVS-Architektur-Semantik repräsentieren, werden für Zuständigkeitsübergreifendes Verkehrsmanagement ergänzt.

Ergebnis: [[Los3_Glossar|IVS-Glossar für Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== Architekturprinzipien ===

Prinzipien stellen Grundsätze dar, die nicht nur dauerhaft gelten, sondern auch selten geändert werden sollten. Sie beschreiben die Art und Weise, wie eine davon betroffene Organisation ihre Aufgaben zu erfüllen hat. Prinzipien können für verschiedene Ebenen entwickelt und definiert werden.

Zur Detaillierung werden IVS-Architekturprinzipien gemäß den Ebenen von IVS-Architektur in folgende Untergruppen aufgeteilt:

*Geschäftsprinzip
*Daten-/Informationsprinzip
*Anwendungsprinzip
*Technologieprinzip

Ergebnis: [[Los3_IVS-Architekturprinzipien|IVS-Architekturprinzipien für Zuständigkeitsübergreifendes Verkehrsmanagement]]

----

== Phase Architektur Vision ==

=== Aufsetzen eines Architekturprojekts ===

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

*den IVS-Betrachtungsgegenstand "Zuständigkeitsübergreifendes Verkehrsmanagement" semantisch zu beschreiben (was ist der IVS-Betrachtungsgegenstand Zuständigkeitsübergreifendes Verkehrsmanagement) und
*klare Grenzen zu ähnlichen bzw. angrenzenden IVS-Betrachtungsgegenständen des Zuständigkeitsübergreifenden Verkehrsmanagements zu ziehen und festzulegen ('''was ist drin, was ist nicht drin''').

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

*Eine IVS-Referenzarchitektur soll verschiedene Gestaltungskonzepte für eine IVS-Dienstekategorie vorweisen.
*Bei der IVS-Architektur eines realen IVS-Dienstes müssen verschiedene Implementierungskonzepte für einen spezifischen IVS-Dienst erstellt werden.

Ergebnisse:

==== IVS-Domäne für Zuständigkeitsübergreifendes Verkehrsmanagement ====

*[[IVS-Domäne_Zuständigkeitsübergreifenden_Verkehrsmanagements_-_Template|IVS-Domäne für Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== IVS-Dienste(-kategorie) für Zuständigkeitsübergreifendes Verkehrsmanagement ====

*[[IVS-Dienste_Los3|IVS-Dienste(-kategorie) für Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== Zuständigkeitsübergreifendes Verkehrsmanagement - Allgemeine Beschreibung ====

*[[Zuständigkeitsübergreifendes_Verkehrsmanagement_-_Allgemeine_Beschreibung|Zuständigkeitsübergreifendes Verkehrsmanagement - Allgemeine Beschreibung]]

=== Erfassen und Beschreibung 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 in die IVS-Wertschöpfung zu involvierenden IVS-Akteure und die zu beteiligenden IVS-Stakeholder erfasst und beschrieben werden.

Dazu ist es nützlich - in Vorbereitung für den Schritt Entwicklung einer IVS-Architekturvision - eine erste Vorstellung für den IVS-Dienst/die IVS-Dienstekategorie zugrunde zu legen und darüber die erforderlichen IVS-Rollen in der IVS-Wertschöpfungskette/im IVS-Wertschöpfungsnetzwerk zu veranschaulichen.

Zur Ergebnisdarstellung werden zwei IVS-Bausteine verwendet:

*Der Baustein IVS-Rollen-Map, mit dem Stereotype von IVS-Akteuren und IVS-Stakeholdern deklariert, mit ihren Geschäftsanliegen und IVS-Rollen beschrieben und die Bedeutung von IVS-Akteuren und IVS-Stakeholdern gemäß "Power-Grid" klassifiziert werden.

*Der Baustein IVS-Rolle, mit dem Stereotype von IVS-Fähigkeiten und IVS-Verantwortlichkeiten, die für die Bereitstellung und den Betrieb von IVS-Diensten typisch und erforderlich sind, bezeichnet und semantisch beschrieben werden.

Ergebnisse:

*[[PhaseA-Step2-Los3_ErfassungUndBeschreibungVonRollen|IVS-Rollen im Zuständigkeitsübergreifenden Verkehrsmanagement - Allgemeine Beschreibung]]
*[[IVS-Rollen_Los3|IVS-Rollen-Map und IVS-Rollen Power-Grid für Zuständigkeitsübergreifendes Verkehrsmanagement]]
*[[IVS-Business_Szenarios_und_IVS-Anforderungen_Los_3_-_Zuständigkeitsübergreifendes_Verkehrsmanagement|IVS-Business Szenarios und IVS-Anforderungen für Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== Ziele, strategische Einflussfaktoren und Rahmenbedingungen ===

==== IVS-Leitbilder ====

Die Akzeptanz von Maßnahmen des Verkehrsmanagements wird beim Verkehrsteilnehmer erhöht, wenn sich der Betrieb an seinen Mobilitätsbedürfnissen und tatsächlichen Wegen orientiert und nicht an Zuständigkeitsgrenzen endet oder das Erscheinungsbild wechselt. Bei den indirekt beteiligten IVS-Stakeholdern und IVS-Akteuren wird eine hohe Akzeptanz erwartet, weil die "IVS-Referenzarchitektur für Zuständigkeitsübergreifendes Verkehrsmanagement" die Planungs- und Investitionssicherheit verbessert (Vermeidung von Insellösungen) und interoperable, betrieblich effiziente Lösungen begünstigt.

Ergebnis: [[IVS-Leitbilder_Los3|IVS-Leitbilder für Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== IVS-Geschäftsziele ====

Das Straßen- und Verkehrswesen kann einen Beitrag dazu leisten, die Lebensqualität der einzelnen Individuen zu steigern. Diese Forderung wird durch Definition der vier Oberziele des Verkehrs bekräftigt:

*Erhöhung der Sicherheit,
*Befriedigung des Mobilitätsbedürfnisses,
*Schonung der Umwelt und
*Verbesserung der Wirtschaftlichkeit.

Das Zuständigkeitsübergreifende Verkehrsmanagement setzt an dieser Stelle an. Durch gezielte Maßnahmen oder Maßnahmenbündel, die den gleichzeitigen Einsatz mehrerer Verkehrssysteme und -mittel (multimodal) oder den Wechsel der Verkehrssysteme (intermodal) innerhalb und außerhalb des eigenen Zuständigkeitsbereichs berücksichtigen, sollen Probleme oder bestimmte Situationen im regionalen und/oder überregionalen Verkehrssystem reduziert bzw. verbessert werden.

Ergebnis: [[IVS-Geschäftsziele_Los3|IVS-Geschäftsziele für Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== IVS-Capabilities ===

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

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

Grobe Vorstellungen für die Wertschöpfungskette des Zuständigkeitsübergreifenden Verkehrsmanagements zeigen folgenden Abbildungen:

<gallery mode="packed-hover">
File:TMValueChain.png | Wertschöpfungskette Verkehrsmanagement
File:WertschöpfungImSystemStrasse.png | System Strasse (Quelle Hessen Mobil)
</gallery>

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

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

Ergebnis: [[IVS-Capabilities_Los3|IVS-Capabilities für Zuständigkeitsübergreifenden Verkehrsmanagement]]

=== IVS-Architektur Vision ===

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

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

*Die Idee (für den IVS-Dienst),

:
::die die Kernaufgabe, die Nutzung und die Schnittstellen, das heißt den Kontext des zu erstellenden IVS-Dienstes aufzeigt.

*Einflussfaktoren und Randbedingungen

:
::wie funktionale und nicht-funktionale Anforderungen, organisatorische und technische Einflüsse.

*Lösungsstrategien

:
::halten die ersten Entscheidungen, wesentliche Architektur-Muster und Konzepte fest. Erste Architektursichten können entstehen, um die Lösungsstrategien zu verdeutlichen.

Ergebnis: [[IVS-Archtekturvision_Los3|IVS-Architektur Vision für Zuständigkeitsübergreifendes Verkehrsmanagement]]

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

Um den IVS-Dienst "Zuständigkeitsübergreifendes Verkehrsmanagement" realisieren zu können, müssen verschiedene IVS-Akteure zusammenarbeiten, sobald für eine Routenempfehlung die Aktorik, die Sensorik und/oder die Alternativroute oder Teile davon benötigt werden, die nicht in den eigenen Zuständigkeitsbereich fallen. Somit hängt die Interoperabilität von IVS-Akteuren im IVS-Dienst "Zuständigkeitsübergreifendes Verkehrsmanagement" im Wesentlichen davon ab, wie nahtlos diese zusammenarbeiten bzw. wie interoperabel diese ihre IVS-Geschäftsfähigkeiten gestalten können. Interoperabilität wird somit in den Mittelpunkt der architekturellen Bemühungen gestellt und die Bereitstellung von Interoperabilitäts-Bausteinen zum Kernziel von IVS-Architektur.

Ergebnis: [[IVS-Wertbeitrag_Los3|Wertbeitrag und KPIs von IVS-Architektur für Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== Risiken der Einführung einer IVS-Referenzarchitektur für zuständigkeitsübergreifendes Verkehrsmanagement ====

Die Einführung einer IVS-Architektur birgt auch Risiken. Das Risikomanagement soll genutzt wer-den, um die Risiken Einführung einer IVS-Referenzarchitektur für Zuständigkeitsübergreifenden Verkehrsmanagements zu erkennen, zu beurteilen und handzuhaben.

Ergebnis: [[Risiken_Los3|Risiken der Einführung einer IVS-Referenzarchitektur für Zuständigkeitsübergreifendes Verkehrsmanagement]]

----

== Phase Geschäftsarchitektur ==

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

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

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

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

*für die Sicht "IVS-Wertschöpfungskette/IVS-Wertschöpfungsnetzwerk"

:
:*Darstellung als '''IVS-Rollenmatrix''', wie sie im Projekt [[Media:ÖV-IVS_Schlussbericht_März_2014.pdf|Entwicklung einer ÖV-IVS-Rahmenarchitektur in Deutschland unter Einbindung Europäischer IVS-Richtlinien mit ÖV-Relevanz<ref>Kieslich, Wolfgang; Albrecht, Hanfried; Dinkel, Alexander u.a. (2014): Entwicklung einer für ÖV-IVS-Architektur in Deutschland unter Einbindung Europäischer IVS-Richtlinien mit ÖPNV-Relevanz. Schlussbericht. Im Auftrag des Bundesministeriums für Verkehr und digitale Infrastruktur. München.</ref>]] entwickelt wurde. Eine Anleitung findet sich [[Aufbau_von_IVS-Wertschöfungsketten_und_-netzwerke|'''hier''']].
:*Darstellung als '''Rollen/Capability-Diagramm'''. Ein Beispiel finden Sie '''[[PhaseB-Step2-Los3#Sicht_.22Wertsch.C3.B6pfungskette.2FWertsch.C3.B6pfungsnetzwerk.22_f.C3.BCr_Zust.C3.A4ndigkeits.C3.BCbergreifendes_Verkehrsmanagement|hier]]'''.

*für die Sicht "IVS-Governance"

:
::Für die Darstellung wird ein Textdokument empfohlen. Eine Beschreibungsstruktur findet sich [[IVS-Governance|hier]].

*für die Sicht "IVS-Geschäftsprozesse"

:
::für die Darstellung und Visualisierung der IVS-Geschäftsprozessarchitektur wird grundsätzlich ein Prozessmodellierungs-Ansatz gewählt. Durch das Aufschlüsseln von Geschäftsfunktionen und Geschäftsdiensten mit Hilfe der Prozessmodellierung wird die Identifizierung der Schlüssel-Prozesse und der nachgeordneten Dienste und Funktionen ermöglicht.
::*Ein Template zur Beschreibung von Geschäftsprozessen findet sich [[IVS-Geschäftsprozess|hier]].
::*Zur Modellierung von Geschäftsprozessen und Geschäftsfunktionen wird die Spezifikationssprache Business Process Model and Notation (BPMN) verwendet. Eine Anleitung findet sich [[Geschäftsprozessdiagramm|hier]].

Ergebnis: [[Hilfsmittel_und_Werkzeuge_Los3|Hilfsmittel zur Darstellung der IVS-Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== Ausgangssituation der IVS-Geschäftsarchitektur ===

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

*Sicht "IVS-Wertschöpfungsketten und -netzwerke"

:
::Die [[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.

*Sicht "IVS-Governance"

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

*Sicht "IVS-Geschäftsprozesse"

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

Ergebnisse:

*[[Ausgangssituation_Geschäftsarchitektur_Los_3_-_Sicht_Wertschöpfungsnetzwerk|Ausgangssituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Wertschöpfungsnetzwerk]]
*[[Ausgangssituation_Geschäftsarchitektur_Los_3_-_Sicht_Governance|Ausgangssituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Governance]]
*[[Ausgangssituation_Geschäftsarchitektur_Los_3_-_Sicht_Geschäftsprozesse|Ausgangssituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Geschäftsprozesse]]

=== Zielsituation der IVS-Geschäftsarchitektur ===

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

*Sicht [[Aufbau_von_IVS-Wertschöfungsketten_und_-netzwerke|"IVS-Wertschöpfungskette/IVS-Wertschöpfungsnetzwerk"]]

:
::Identifizierung, Darstellung und Beschreibung, über welche Bestandteile (Teildienste) der IVS-Dienst gebildet wird, welche IVS-Rollen daran beteiligt sein müssen und welche Anforderungen (IVS-Capabilities) an diese gestellt werden.

*Sicht [[IVS-Governance|"IVS-Governance"]]

:
::Beschreibung, auf welcher gesetzlichen, rechtlichen und vertraglichen Grundlage der IVS-Dienst und die Zusammenarbeit der IVS-Akteure zustande kommen und wie letztere operativ geführt und gesteuert wird.

*Sicht [[IVS-Geschäftsprozesse_und_Wertschöpfungsnetzwerke|"IVS-Geschäftsprozesse"]]

:
::Darstellung und Beschreibung, über welche Schlüssel-Geschäftsprozesse der IVS-Dienst operationalisiert wird.

Weitere Sichten können projektspezifisch aufgebaut und beschrieben werden.

Ergebnisse:

*[[Zielsituation_Geschäftsarchitektur_Los_3_-_Sicht_Wertschöpfungsnetzwerk|Zielsituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Wertschöpfungsnetzwerk]]
*[[Zielsituation_Geschäftsarchitektur_Los_3_-_Sicht_Governance|Zielsituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Governance]]
*[[Zielsituation_Geschäftsarchitektur_Los_3_-_Sicht_Geschäftsprozesse|Zielsituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Geschäftsprozesse]]

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

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

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

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

Ergebnisse:

*[[Gap-Analyse_Geschäftsarchitektur_Los_3_-_Sicht_Wertschöpfungsnetzwerk|Gap-Analyse Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Wertschöpfungsnetzwerk]]
*[[Gap-Analyse_Geschäftsarchitektur_Los_3_-_Sicht_Governance|Gap-Analyse Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Governance]]
*[[Gap-Analyse_Geschäftsarchitektur_Los_3_-_Sicht_Geschäftsprozesse|Gap-Analyse Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Geschäftsprozesse]]

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

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

Zur Beschreibung der einzelnen Arbeitsschritte sowie zur Festlegung von zeitlichen und inhaltlichen Abhängigkeiten zwischen den einzelnen Arbeitsschritten wird der Katalog [[Media:Architektur-Roadmap_00-00-01.docx|Architektur-Roadmap]] verwendet.

Ergebnis: [[IVS-Architektur-Roadmap_Los3|IVS-Architektur-Roadmap - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

----

=== Ergebnisse IVS-Datenarchitektur ===

==== Hilfsmittel, Sichten und Werkzeuge für IVS-Datenarchitektur ====

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

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

Ergebnis: [[Hilfsmittel_zur_Darstellung_der_IVS-Datenarchitektur_-_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement|Hilfsmittel zur Darstellung der IVS-Datenarchitektur für Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== Ausgangssituation der IVS-Datenarchitektur ====

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

Ergebnisse - Kataloge:

*[[Ausgangssituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement|Ausgangssituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Informationsobjekte]]
*[[Ausgangssituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_IVS-Datenmodelle|Ausgangssituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Datenmodelle]]
*[[Ausgangssituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_IVS-Ortsreferenzierung|Ausgangssituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Ortsreferenzierungen]]

Ergebnisse - Matrizen:

*[[Ausgangssituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_Matrix_IVS-Informationsobjekte/_IVS-Datenmodelle|Ausgangssituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Matrix IVS-Informationsobjekte/Datenmodelle]]
*[[Ausgangssituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_Matrix_IVS-Datenmodelle/_IVS-Ortsreferenzierungssysteme|Ausgangssituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Matrix IVS-Datenmodelle/ IVS-Ortsreferenzierungssysteme]]

==== Zielsituation der IVS-Datenarchitektur ====

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

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

Ergebnisse - Kataloge:

*[[Zielsituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Informationsobjekte|Zielsituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Informationsobjekte]]
*[[Zielsituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Datenmodelle|Zielsituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Datenmodelle]]
*[[Zielsituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Ortsreferenzierung|Zielsituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Ortsreferenzierung]]

Ergebnisse - Matrizen:

*[[Zielsituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_Matrix_IVS-Informationsobjekte/_IVS-Datenmodelle|Zielsituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Matrix IVS-Informationsobjekte/Datenmodelle]]
*[[Zielsituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_Matrix_IVS-Datenmodelle/_IVS-Ortsreferenzierungssysteme|Zielsituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Matrix IVS-Datenmodelle/ IVS-Ortsreferenzierungssysteme]]

==== Gap-Analyse für die IVS-Datenarchitektur ====

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

Ergebnisse:

*[[Gap-Analyse_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Informationsobjekte|Gap-Analyse IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Informationsobjekte]]
*[[Gap-Analyse_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Datenmodelle|Gap-Analyse IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Datenmodelle]]
*[[Gap-Analyse_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Ortsreferenzierungssysteme|Gap-Analyse IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Ortsreferenzierungssysteme]]

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

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

Ergebnis: [[IVS-Architektur-Roadmap_-_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Datenarchitektur|IVS-Architektur-Roadmap - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Datenarchitektur]]

----

=== Ergebnisse IVS-Anwendungsarchitektur ===

==== Hilfsmittel, Sichten und Werkzeuge für IVS-Anwendungsarchitektur ====

Die IVS-Anwendungsarchitektur fokussiert IVS-Anwendungen und deren IVS-Schnittstellen im Zuständigkeitsübergreifenden Verkehrsmanagement, die für die Ausführung der zuständigkeitsübergreifenden IVS-Geschäftsprozesse erforderlich sind.

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

Für die Darstellung der Anwendungsarchitektur im Zuständigkeitsübergreifenden Verkehrsmanagement schlägt die IVS-Rahmenarchitektur folgende Modellierungsprinzipien bzw. -werkzeuge vor:

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

Ergebnis: [[Hilfsmittel_zur_Darstellung_der_IVS-Anwendungsarchitektur_-_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement|Hilfsmittel zur Darstellung der IVS-Anwendungsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== Ausgangssituation der IVS-Anwendungsarchitektur ====

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

Ergebnis: [[Ausgangssituation_Anwendungsarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement|Ausgangssituation IVS-Anwendungsarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== Zielsituation der IVS-Anwendungsarchitektur ====

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

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

Ergebnis: [[Zielsituation_Anwendungsarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Anwendung|Zielsituation IVS-Anwendungsarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== Gap-Analyse für die IVS-Anwendungsarchitektur ====

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

Ergebnis: [[Gap-Analyse_Anwendungsarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Anwendung|Gap-Analyse IVS-Anwendungsarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

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

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

Ergebnis: [[IVS-Architektur-Roadmap_-_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Anwendungsarchitektur|IVS-Architektur-Roadmap - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Anwendungsarchitektur]]

----

=== Ergebnisse IVS-Technologiearchitektur ===

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

== Literaturverzeichnis ==

<references />

----

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

IVS-Referenzarchitektur für Zuständigkeitsübergreifendes Verkehrsmanagement 1.0

2018-08-29T10:56:18Z

Albrecht:

== Vorbereitungsphase ==

=== Steuerungs- und Unterstützungsframeworks ===

Mit den Steuerungs- und Unterstützungsframeworks für IVS-Architektur werden generell IVS-Architekturprojekte motiviert, begründet und gestützt. Der Inhalt dieser Frameworks bildet im Prinzip auch den Geist, in dem IVS-Architekturprojekte durchgeführt werden.

Für die IVS-Rahmenarchitektur bilden der Europäische IVS-Aktionsplan und die IVS-Direktive sowie auf nationaler Ebene das IVS-Gesetz und der Nationale IVS-Aktionsplan Straße die wesentlichen Frameworks. Für die IVS-Referenzarchitektur für Zuständigkeitsübergreifendes Verkehrsmanagement setzen neben den rechtlichen Vorgaben auch interne Vorgaben der einzelnen Stakeholder und Akteure den rechtlichen Handlungsrahmen.

Ergebnis: [[PhaseV-Step3-Los3_SteuerungsUndUnterstützungsframeworks|IVS-Steuerungs- und Unterstützungsframeworks für Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== IVS-Glossar ===

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

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

Für das Glossar für Zuständigkeitsübergreifendes Verkehrsmanagement gilt:

*Die Begriffsbestimmungen für IVS-Architektur (siehe [[IVS-Architekturbausteine#IVS-Architektur...|Was ist IVS-Architektur? - Schlüsselbegriffe]] und [[IVS-Architekturbausteine|Begriffe für die IVS-Gestaltungsmerkmale von IVS-Architektur]]) werden auf Zuständigkeitsübergreifendes Verkehrsmanagement übertragen.
*[[IVS-Glossar#Begriffsdefinitionen|Allgemeine Begriffe aus Verkehr, Transport und Mobilität]], die keine spezifische IVS-Architektur-Semantik repräsentieren, werden für Zuständigkeitsübergreifendes Verkehrsmanagement ergänzt.

Ergebnis: [[Los3_Glossar|IVS-Glossar für Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== Architekturprinzipien ===

Prinzipien stellen Grundsätze dar, die nicht nur dauerhaft gelten, sondern auch selten geändert werden sollten. Sie beschreiben die Art und Weise, wie eine davon betroffene Organisation ihre Aufgaben zu erfüllen hat. Prinzipien können für verschiedene Ebenen entwickelt und definiert werden.

Zur Detaillierung werden IVS-Architekturprinzipien gemäß den Ebenen von IVS-Architektur in folgende Untergruppen aufgeteilt:

*Geschäftsprinzip
*Daten-/Informationsprinzip
*Anwendungsprinzip
*Technologieprinzip

Ergebnis: [[Los3_IVS-Architekturprinzipien|IVS-Architekturprinzipien für Zuständigkeitsübergreifendes Verkehrsmanagement]]

----

== Phase Architektur Vision ==

=== Aufsetzen eines Architekturprojekts ===

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

*den IVS-Betrachtungsgegenstand "Zuständigkeitsübergreifendes Verkehrsmanagement" semantisch zu beschreiben (was ist der IVS-Betrachtungsgegenstand Zuständigkeitsübergreifendes Verkehrsmanagement) und
*klare Grenzen zu ähnlichen bzw. angrenzenden IVS-Betrachtungsgegenständen des Zuständigkeitsübergreifenden Verkehrsmanagements zu ziehen und festzulegen ('''was ist drin, was ist nicht drin''').

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

*Eine IVS-Referenzarchitektur soll verschiedene Gestaltungskonzepte für eine IVS-Dienstekategorie vorweisen.
*Bei der IVS-Architektur eines realen IVS-Dienstes müssen verschiedene Implementierungskonzepte für einen spezifischen IVS-Dienst erstellt werden.

Ergebnisse:

==== IVS-Domäne für Zuständigkeitsübergreifendes Verkehrsmanagement ====

*[[IVS-Domäne_Zuständigkeitsübergreifenden_Verkehrsmanagements_-_Template|IVS-Domäne für Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== IVS-Dienste(-kategorie) für Zuständigkeitsübergreifendes Verkehrsmanagement ====

*[[IVS-Dienste_Los3|IVS-Dienste(-kategorie) für Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== Zuständigkeitsübergreifendes Verkehrsmanagement - Allgemeine Beschreibung ====

*[[Zuständigkeitsübergreifendes_Verkehrsmanagement_-_Allgemeine_Beschreibung|Zuständigkeitsübergreifendes Verkehrsmanagement - Allgemeine Beschreibung]]

=== Erfassen und Beschreibung 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 in die IVS-Wertschöpfung zu involvierenden IVS-Akteure und die zu beteiligenden IVS-Stakeholder erfasst und beschrieben werden.

Dazu ist es nützlich - in Vorbereitung für den Schritt Entwicklung einer IVS-Architekturvision - eine erste Vorstellung für den IVS-Dienst/die IVS-Dienstekategorie zugrunde zu legen und darüber die erforderlichen IVS-Rollen in der IVS-Wertschöpfungskette/im IVS-Wertschöpfungsnetzwerk zu veranschaulichen.

Zur Ergebnisdarstellung werden zwei IVS-Bausteine verwendet:

*Der Baustein IVS-Rollen-Map, mit dem Stereotype von IVS-Akteuren und IVS-Stakeholdern deklariert, mit ihren Geschäftsanliegen und IVS-Rollen beschrieben und die Bedeutung von IVS-Akteuren und IVS-Stakeholdern gemäß "Power-Grid" klassifiziert werden.

*Der Baustein IVS-Rolle, mit dem Stereotype von IVS-Fähigkeiten und IVS-Verantwortlichkeiten, die für die Bereitstellung und den Betrieb von IVS-Diensten typisch und erforderlich sind, bezeichnet und semantisch beschrieben werden.

Ergebnisse:

*[[PhaseA-Step2-Los3_ErfassungUndBeschreibungVonRollen|IVS-Rollen im Zuständigkeitsübergreifenden Verkehrsmanagement - Allgemeine Beschreibung]]
*[[IVS-Rollen_Los3|IVS-Rollen-Map und IVS-Rollen Power-Grid für Zuständigkeitsübergreifendes Verkehrsmanagement]]
*[[IVS-Business_Szenarios_und_IVS-Anforderungen_Los_3_-_Zuständigkeitsübergreifendes_Verkehrsmanagement|IVS-Business Szenarios und IVS-Anforderungen für Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== Ziele, strategische Einflussfaktoren und Rahmenbedingungen ===

==== IVS-Leitbilder ====

Die Akzeptanz von Maßnahmen des Verkehrsmanagements wird beim Verkehrsteilnehmer erhöht, wenn sich der Betrieb an seinen Mobilitätsbedürfnissen und tatsächlichen Wegen orientiert und nicht an Zuständigkeitsgrenzen endet oder das Erscheinungsbild wechselt. Bei den indirekt beteiligten IVS-Stakeholdern und IVS-Akteuren wird eine hohe Akzeptanz erwartet, weil die "IVS-Referenzarchitektur für Zuständigkeitsübergreifendes Verkehrsmanagement" die Planungs- und Investitionssicherheit verbessert (Vermeidung von Insellösungen) und interoperable, betrieblich effiziente Lösungen begünstigt.

Ergebnis: [[IVS-Leitbilder_Los3|IVS-Leitbilder für Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== IVS-Geschäftsziele ====

Das Straßen- und Verkehrswesen kann einen Beitrag dazu leisten, die Lebensqualität der einzelnen Individuen zu steigern. Diese Forderung wird durch Definition der vier Oberziele des Verkehrs bekräftigt:

*Erhöhung der Sicherheit,
*Befriedigung des Mobilitätsbedürfnisses,
*Schonung der Umwelt und
*Verbesserung der Wirtschaftlichkeit.

Das Zuständigkeitsübergreifende Verkehrsmanagement setzt an dieser Stelle an. Durch gezielte Maßnahmen oder Maßnahmenbündel, die den gleichzeitigen Einsatz mehrerer Verkehrssysteme und -mittel (multimodal) oder den Wechsel der Verkehrssysteme (intermodal) innerhalb und außerhalb des eigenen Zuständigkeitsbereichs berücksichtigen, sollen Probleme oder bestimmte Situationen im regionalen und/oder überregionalen Verkehrssystem reduziert bzw. verbessert werden.

Ergebnis: [[IVS-Geschäftsziele_Los3|IVS-Geschäftsziele für Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== IVS-Capabilities ===

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

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

Grobe Vorstellungen für die Wertschöpfungskette des Zuständigkeitsübergreifenden Verkehrsmanagements zeigen folgenden Abbildungen:

<gallery mode="packed-hover">
File:TMValueChain.png | Wertschöpfungskette Verkehrsmanagement
File:WertschöpfungImSystemStrasse.png | System Strasse (Quelle Hessen Mobil)
</gallery>

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

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

Ergebnis: [[IVS-Capabilities_Los3|IVS-Capabilities für Zuständigkeitsübergreifenden Verkehrsmanagement]]

==== IVS-Architektur Vision ====

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

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

*Die Idee (für den IVS-Dienst),

:
::die die Kernaufgabe, die Nutzung und die Schnittstellen, das heißt den Kontext des zu erstellenden IVS-Dienstes aufzeigt.

*Einflussfaktoren und Randbedingungen

:
::wie funktionale und nicht-funktionale Anforderungen, organisatorische und technische Einflüsse.

*Lösungsstrategien

:
::halten die ersten Entscheidungen, wesentliche Architektur-Muster und Konzepte fest. Erste Architektursichten können entstehen, um die Lösungsstrategien zu verdeutlichen.

Ergebnis: [[IVS-Archtekturvision_Los3|IVS-Architektur Vision für Zuständigkeitsübergreifendes Verkehrsmanagement]]

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

Um den IVS-Dienst "Zuständigkeitsübergreifendes Verkehrsmanagement" realisieren zu können, müssen verschiedene IVS-Akteure zusammenarbeiten, sobald für eine Routenempfehlung die Aktorik, die Sensorik und/oder die Alternativroute oder Teile davon benötigt werden, die nicht in den eigenen Zuständigkeitsbereich fallen. Somit hängt die Interoperabilität von IVS-Akteuren im IVS-Dienst "Zuständigkeitsübergreifendes Verkehrsmanagement" im Wesentlichen davon ab, wie nahtlos diese zusammenarbeiten bzw. wie interoperabel diese ihre IVS-Geschäftsfähigkeiten gestalten können. Interoperabilität wird somit in den Mittelpunkt der architekturellen Bemühungen gestellt und die Bereitstellung von Interoperabilitäts-Bausteinen zum Kernziel von IVS-Architektur.

Ergebnis: [[IVS-Wertbeitrag_Los3|Wertbeitrag und KPIs von IVS-Architektur für Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== Risiken der Einführung einer IVS-Referenzarchitektur für zuständigkeitsübergreifendes Verkehrsmanagement ====

Die Einführung einer IVS-Architektur birgt auch Risiken. Das Risikomanagement soll genutzt wer-den, um die Risiken Einführung einer IVS-Referenzarchitektur für Zuständigkeitsübergreifenden Verkehrsmanagements zu erkennen, zu beurteilen und handzuhaben.

Ergebnis: [[Risiken_Los3|Risiken der Einführung einer IVS-Referenzarchitektur für Zuständigkeitsübergreifendes Verkehrsmanagement]]

----

== Phase Geschäftsarchitektur ==

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

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

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

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

*für die Sicht "IVS-Wertschöpfungskette/IVS-Wertschöpfungsnetzwerk"

:
:*Darstellung als '''IVS-Rollenmatrix''', wie sie im Projekt [[Media:ÖV-IVS_Schlussbericht_März_2014.pdf|Entwicklung einer ÖV-IVS-Rahmenarchitektur in Deutschland unter Einbindung Europäischer IVS-Richtlinien mit ÖV-Relevanz<ref>Kieslich, Wolfgang; Albrecht, Hanfried; Dinkel, Alexander u.a. (2014): Entwicklung einer für ÖV-IVS-Architektur in Deutschland unter Einbindung Europäischer IVS-Richtlinien mit ÖPNV-Relevanz. Schlussbericht. Im Auftrag des Bundesministeriums für Verkehr und digitale Infrastruktur. München.</ref>]] entwickelt wurde. Eine Anleitung findet sich [[Aufbau_von_IVS-Wertschöfungsketten_und_-netzwerke|'''hier''']].
:*Darstellung als '''Rollen/Capability-Diagramm'''. Ein Beispiel finden Sie '''[[PhaseB-Step2-Los3#Sicht_.22Wertsch.C3.B6pfungskette.2FWertsch.C3.B6pfungsnetzwerk.22_f.C3.BCr_Zust.C3.A4ndigkeits.C3.BCbergreifendes_Verkehrsmanagement|hier]]'''.

*für die Sicht "IVS-Governance"

:
::Für die Darstellung wird ein Textdokument empfohlen. Eine Beschreibungsstruktur findet sich [[IVS-Governance|hier]].

*für die Sicht "IVS-Geschäftsprozesse"

:
::für die Darstellung und Visualisierung der IVS-Geschäftsprozessarchitektur wird grundsätzlich ein Prozessmodellierungs-Ansatz gewählt. Durch das Aufschlüsseln von Geschäftsfunktionen und Geschäftsdiensten mit Hilfe der Prozessmodellierung wird die Identifizierung der Schlüssel-Prozesse und der nachgeordneten Dienste und Funktionen ermöglicht.
::*Ein Template zur Beschreibung von Geschäftsprozessen findet sich [[IVS-Geschäftsprozess|hier]].
::*Zur Modellierung von Geschäftsprozessen und Geschäftsfunktionen wird die Spezifikationssprache Business Process Model and Notation (BPMN) verwendet. Eine Anleitung findet sich [[Geschäftsprozessdiagramm|hier]].

Ergebnis: [[Hilfsmittel_und_Werkzeuge_Los3|Hilfsmittel zur Darstellung der IVS-Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== Ausgangssituation der IVS-Geschäftsarchitektur ===

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

*Sicht "IVS-Wertschöpfungsketten und -netzwerke"

:
::Die [[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.

*Sicht "IVS-Governance"

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

*Sicht "IVS-Geschäftsprozesse"

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

Ergebnisse:

*[[Ausgangssituation_Geschäftsarchitektur_Los_3_-_Sicht_Wertschöpfungsnetzwerk|Ausgangssituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Wertschöpfungsnetzwerk]]
*[[Ausgangssituation_Geschäftsarchitektur_Los_3_-_Sicht_Governance|Ausgangssituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Governance]]
*[[Ausgangssituation_Geschäftsarchitektur_Los_3_-_Sicht_Geschäftsprozesse|Ausgangssituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Geschäftsprozesse]]

=== Zielsituation der IVS-Geschäftsarchitektur ===

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

*Sicht [[Aufbau_von_IVS-Wertschöfungsketten_und_-netzwerke|"IVS-Wertschöpfungskette/IVS-Wertschöpfungsnetzwerk"]]

:
::Identifizierung, Darstellung und Beschreibung, über welche Bestandteile (Teildienste) der IVS-Dienst gebildet wird, welche IVS-Rollen daran beteiligt sein müssen und welche Anforderungen (IVS-Capabilities) an diese gestellt werden.

*Sicht [[IVS-Governance|"IVS-Governance"]]

:
::Beschreibung, auf welcher gesetzlichen, rechtlichen und vertraglichen Grundlage der IVS-Dienst und die Zusammenarbeit der IVS-Akteure zustande kommen und wie letztere operativ geführt und gesteuert wird.

*Sicht [[IVS-Geschäftsprozesse_und_Wertschöpfungsnetzwerke|"IVS-Geschäftsprozesse"]]

:
::Darstellung und Beschreibung, über welche Schlüssel-Geschäftsprozesse der IVS-Dienst operationalisiert wird.

Weitere Sichten können projektspezifisch aufgebaut und beschrieben werden.

Ergebnisse:

*[[Zielsituation_Geschäftsarchitektur_Los_3_-_Sicht_Wertschöpfungsnetzwerk|Zielsituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Wertschöpfungsnetzwerk]]
*[[Zielsituation_Geschäftsarchitektur_Los_3_-_Sicht_Governance|Zielsituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Governance]]
*[[Zielsituation_Geschäftsarchitektur_Los_3_-_Sicht_Geschäftsprozesse|Zielsituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Geschäftsprozesse]]

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

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

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

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

Ergebnisse:

*[[Gap-Analyse_Geschäftsarchitektur_Los_3_-_Sicht_Wertschöpfungsnetzwerk|Gap-Analyse Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Wertschöpfungsnetzwerk]]
*[[Gap-Analyse_Geschäftsarchitektur_Los_3_-_Sicht_Governance|Gap-Analyse Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Governance]]
*[[Gap-Analyse_Geschäftsarchitektur_Los_3_-_Sicht_Geschäftsprozesse|Gap-Analyse Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Geschäftsprozesse]]

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

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

Zur Beschreibung der einzelnen Arbeitsschritte sowie zur Festlegung von zeitlichen und inhaltlichen Abhängigkeiten zwischen den einzelnen Arbeitsschritten wird der Katalog [[Media:Architektur-Roadmap_00-00-01.docx|Architektur-Roadmap]] verwendet.

Ergebnis: [[IVS-Architektur-Roadmap_Los3|IVS-Architektur-Roadmap - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

----

=== Ergebnisse IVS-Datenarchitektur ===

==== Hilfsmittel, Sichten und Werkzeuge für IVS-Datenarchitektur ====

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

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

Ergebnis: [[Hilfsmittel_zur_Darstellung_der_IVS-Datenarchitektur_-_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement|Hilfsmittel zur Darstellung der IVS-Datenarchitektur für Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== Ausgangssituation der IVS-Datenarchitektur ====

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

Ergebnisse - Kataloge:

*[[Ausgangssituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement|Ausgangssituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Informationsobjekte]]
*[[Ausgangssituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_IVS-Datenmodelle|Ausgangssituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Datenmodelle]]
*[[Ausgangssituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_IVS-Ortsreferenzierung|Ausgangssituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Ortsreferenzierungen]]

Ergebnisse - Matrizen:

*[[Ausgangssituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_Matrix_IVS-Informationsobjekte/_IVS-Datenmodelle|Ausgangssituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Matrix IVS-Informationsobjekte/Datenmodelle]]
*[[Ausgangssituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_Matrix_IVS-Datenmodelle/_IVS-Ortsreferenzierungssysteme|Ausgangssituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Matrix IVS-Datenmodelle/ IVS-Ortsreferenzierungssysteme]]

==== Zielsituation der IVS-Datenarchitektur ====

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

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

Ergebnisse - Kataloge:

*[[Zielsituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Informationsobjekte|Zielsituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Informationsobjekte]]
*[[Zielsituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Datenmodelle|Zielsituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Datenmodelle]]
*[[Zielsituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Ortsreferenzierung|Zielsituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Ortsreferenzierung]]

Ergebnisse - Matrizen:

*[[Zielsituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_Matrix_IVS-Informationsobjekte/_IVS-Datenmodelle|Zielsituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Matrix IVS-Informationsobjekte/Datenmodelle]]
*[[Zielsituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_Matrix_IVS-Datenmodelle/_IVS-Ortsreferenzierungssysteme|Zielsituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Matrix IVS-Datenmodelle/ IVS-Ortsreferenzierungssysteme]]

==== Gap-Analyse für die IVS-Datenarchitektur ====

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

Ergebnisse:

*[[Gap-Analyse_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Informationsobjekte|Gap-Analyse IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Informationsobjekte]]
*[[Gap-Analyse_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Datenmodelle|Gap-Analyse IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Datenmodelle]]
*[[Gap-Analyse_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Ortsreferenzierungssysteme|Gap-Analyse IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Ortsreferenzierungssysteme]]

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

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

Ergebnis: [[IVS-Architektur-Roadmap_-_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Datenarchitektur|IVS-Architektur-Roadmap - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Datenarchitektur]]

----

=== Ergebnisse IVS-Anwendungsarchitektur ===

==== Hilfsmittel, Sichten und Werkzeuge für IVS-Anwendungsarchitektur ====

Die IVS-Anwendungsarchitektur fokussiert IVS-Anwendungen und deren IVS-Schnittstellen im Zuständigkeitsübergreifenden Verkehrsmanagement, die für die Ausführung der zuständigkeitsübergreifenden IVS-Geschäftsprozesse erforderlich sind.

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

Für die Darstellung der Anwendungsarchitektur im Zuständigkeitsübergreifenden Verkehrsmanagement schlägt die IVS-Rahmenarchitektur folgende Modellierungsprinzipien bzw. -werkzeuge vor:

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

Ergebnis: [[Hilfsmittel_zur_Darstellung_der_IVS-Anwendungsarchitektur_-_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement|Hilfsmittel zur Darstellung der IVS-Anwendungsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== Ausgangssituation der IVS-Anwendungsarchitektur ====

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

Ergebnis: [[Ausgangssituation_Anwendungsarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement|Ausgangssituation IVS-Anwendungsarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== Zielsituation der IVS-Anwendungsarchitektur ====

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

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

Ergebnis: [[Zielsituation_Anwendungsarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Anwendung|Zielsituation IVS-Anwendungsarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== Gap-Analyse für die IVS-Anwendungsarchitektur ====

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

Ergebnis: [[Gap-Analyse_Anwendungsarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Anwendung|Gap-Analyse IVS-Anwendungsarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

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

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

Ergebnis: [[IVS-Architektur-Roadmap_-_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Anwendungsarchitektur|IVS-Architektur-Roadmap - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Anwendungsarchitektur]]

----

=== Ergebnisse IVS-Technologiearchitektur ===

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

== Literaturverzeichnis ==

<references />

----

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

IVS-Referenzarchitektur für Zuständigkeitsübergreifendes Verkehrsmanagement 1.0

2018-08-29T10:54:50Z

Albrecht:

== Vorbereitungsphase ==

=== Steuerungs- und Unterstützungsframeworks ===

Mit den Steuerungs- und Unterstützungsframeworks für IVS-Architektur werden generell IVS-Architekturprojekte motiviert, begründet und gestützt. Der Inhalt dieser Frameworks bildet im Prinzip auch den Geist, in dem IVS-Architekturprojekte durchgeführt werden.

Für die IVS-Rahmenarchitektur bilden der Europäische IVS-Aktionsplan und die IVS-Direktive sowie auf nationaler Ebene das IVS-Gesetz und der Nationale IVS-Aktionsplan Straße die wesentlichen Frameworks. Für die IVS-Referenzarchitektur für Zuständigkeitsübergreifendes Verkehrsmanagement setzen neben den rechtlichen Vorgaben auch interne Vorgaben der einzelnen Stakeholder und Akteure den rechtlichen Handlungsrahmen.

Ergebnis: [[PhaseV-Step3-Los3_SteuerungsUndUnterstützungsframeworks|IVS-Steuerungs- und Unterstützungsframeworks für Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== IVS-Glossar ===

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

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

Für das Glossar für Zuständigkeitsübergreifendes Verkehrsmanagement gilt:

*Die Begriffsbestimmungen für IVS-Architektur (siehe [[IVS-Architekturbausteine#IVS-Architektur...|Was ist IVS-Architektur? - Schlüsselbegriffe]] und [[IVS-Architekturbausteine|Begriffe für die IVS-Gestaltungsmerkmale von IVS-Architektur]]) werden auf Zuständigkeitsübergreifendes Verkehrsmanagement übertragen.
*[[IVS-Glossar#Begriffsdefinitionen|Allgemeine Begriffe aus Verkehr, Transport und Mobilität]], die keine spezifische IVS-Architektur-Semantik repräsentieren, werden für Zuständigkeitsübergreifendes Verkehrsmanagement ergänzt.

Ergebnis: [[Los3_Glossar|IVS-Glossar für Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== Architekturprinzipien ===

Prinzipien stellen Grundsätze dar, die nicht nur dauerhaft gelten, sondern auch selten geändert werden sollten. Sie beschreiben die Art und Weise, wie eine davon betroffene Organisation ihre Aufgaben zu erfüllen hat. Prinzipien können für verschiedene Ebenen entwickelt und definiert werden.

Zur Detaillierung werden IVS-Architekturprinzipien gemäß den Ebenen von IVS-Architektur in folgende Untergruppen aufgeteilt:

*Geschäftsprinzip
*Daten-/Informationsprinzip
*Anwendungsprinzip
*Technologieprinzip

Ergebnis: [[Los3_IVS-Architekturprinzipien|IVS-Architekturprinzipien für Zuständigkeitsübergreifendes Verkehrsmanagement]]

----

== Phase Architektur Vision ==

=== Aufsetzen eines Architekturprojekts ===

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

*den IVS-Betrachtungsgegenstand "Zuständigkeitsübergreifendes Verkehrsmanagement" semantisch zu beschreiben (was ist der IVS-Betrachtungsgegenstand Zuständigkeitsübergreifendes Verkehrsmanagement) und
*klare Grenzen zu ähnlichen bzw. angrenzenden IVS-Betrachtungsgegenständen des Zuständigkeitsübergreifenden Verkehrsmanagements zu ziehen und festzulegen ('''was ist drin, was ist nicht drin''').

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

*Eine IVS-Referenzarchitektur soll verschiedene Gestaltungskonzepte für eine IVS-Dienstekategorie vorweisen.
*Bei der IVS-Architektur eines realen IVS-Dienstes müssen verschiedene Implementierungskonzepte für einen spezifischen IVS-Dienst erstellt werden.

Ergebnisse:

==== IVS-Domäne für Zuständigkeitsübergreifendes Verkehrsmanagement ====

*[[IVS-Domäne_Zuständigkeitsübergreifenden_Verkehrsmanagements_-_Template|IVS-Domäne für Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== IVS-Dienste(-kategorie) für Zuständigkeitsübergreifendes Verkehrsmanagement ====

*[[IVS-Dienste_Los3|IVS-Dienste(-kategorie) für Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== Zuständigkeitsübergreifendes Verkehrsmanagement - Allgemeine Beschreibung ====

*[[Zuständigkeitsübergreifendes_Verkehrsmanagement_-_Allgemeine_Beschreibung|Zuständigkeitsübergreifendes Verkehrsmanagement - Allgemeine Beschreibung]]

=== Erfassen und Beschreibung 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 in die IVS-Wertschöpfung zu involvierenden IVS-Akteure und die zu beteiligenden IVS-Stakeholder erfasst und beschrieben werden.

Dazu ist es nützlich - in Vorbereitung für den Schritt Entwicklung einer IVS-Architekturvision - eine erste Vorstellung für den IVS-Dienst/die IVS-Dienstekategorie zugrunde zu legen und darüber die erforderlichen IVS-Rollen in der IVS-Wertschöpfungskette/im IVS-Wertschöpfungsnetzwerk zu veranschaulichen.

Zur Ergebnisdarstellung werden zwei IVS-Bausteine verwendet:

*Der Baustein IVS-Rollen-Map, mit dem Stereotype von IVS-Akteuren und IVS-Stakeholdern deklariert, mit ihren Geschäftsanliegen und IVS-Rollen beschrieben und die Bedeutung von IVS-Akteuren und IVS-Stakeholdern gemäß "Power-Grid" klassifiziert werden.

*Der Baustein IVS-Rolle, mit dem Stereotype von IVS-Fähigkeiten und IVS-Verantwortlichkeiten, die für die Bereitstellung und den Betrieb von IVS-Diensten typisch und erforderlich sind, bezeichnet und semantisch beschrieben werden.

Ergebnisse:

*[[PhaseA-Step2-Los3_ErfassungUndBeschreibungVonRollen|IVS-Rollen im Zuständigkeitsübergreifenden Verkehrsmanagement - Allgemeine Beschreibung]]
*[[IVS-Rollen_Los3|IVS-Rollen-Map und IVS-Rollen Power-Grid für Zuständigkeitsübergreifendes Verkehrsmanagement]]
*[[IVS-Business_Szenarios_und_IVS-Anforderungen_Los_3_-_Zuständigkeitsübergreifendes_Verkehrsmanagement|IVS-Business Szenarios und IVS-Anforderungen für Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== Ziele, strategische Einflussfaktoren und Rahmenbedingungen ===

==== IVS-Leitbilder ====

Die Akzeptanz von Maßnahmen des Verkehrsmanagements wird beim Verkehrsteilnehmer erhöht, wenn sich der Betrieb an seinen Mobilitätsbedürfnissen und tatsächlichen Wegen orientiert und nicht an Zuständigkeitsgrenzen endet oder das Erscheinungsbild wechselt. Bei den indirekt beteiligten IVS-Stakeholdern und IVS-Akteuren wird eine hohe Akzeptanz erwartet, weil die "IVS-Referenzarchitektur für Zuständigkeitsübergreifendes Verkehrsmanagement" die Planungs- und Investitionssicherheit verbessert (Vermeidung von Insellösungen) und interoperable, betrieblich effiziente Lösungen begünstigt.

Ergebnis: [[IVS-Leitbilder_Los3|IVS-Leitbilder für Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== IVS-Geschäftsziele ====

Das Straßen- und Verkehrswesen kann einen Beitrag dazu leisten, die Lebensqualität der einzelnen Individuen zu steigern. Diese Forderung wird durch Definition der vier Oberziele des Verkehrs bekräftigt:

*Erhöhung der Sicherheit,
*Befriedigung des Mobilitätsbedürfnisses,
*Schonung der Umwelt und
*Verbesserung der Wirtschaftlichkeit.

Das Zuständigkeitsübergreifende Verkehrsmanagement setzt an dieser Stelle an. Durch gezielte Maßnahmen oder Maßnahmenbündel, die den gleichzeitigen Einsatz mehrerer Verkehrssysteme und -mittel (multimodal) oder den Wechsel der Verkehrssysteme (intermodal) innerhalb und außerhalb des eigenen Zuständigkeitsbereichs berücksichtigen, sollen Probleme oder bestimmte Situationen im regionalen und/oder überregionalen Verkehrssystem reduziert bzw. verbessert werden.

Ergebnis: [[IVS-Geschäftsziele_Los3|IVS-Geschäftsziele für Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== IVS-Capabilities ====

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

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

Grobe Vorstellungen für die Wertschöpfungskette des Zuständigkeitsübergreifenden Verkehrsmanagements zeigen folgenden Abbildungen:

<gallery mode="packed-hover">
File:TMValueChain.png | Wertschöpfungskette Verkehrsmanagement
File:WertschöpfungImSystemStrasse.png | System Strasse (Quelle Hessen Mobil)
</gallery>

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

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

Ergebnis: [[IVS-Capabilities_Los3|IVS-Capabilities für Zuständigkeitsübergreifenden Verkehrsmanagement]]

==== IVS-Architektur Vision ====

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

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

*Die Idee (für den IVS-Dienst),

:
::die die Kernaufgabe, die Nutzung und die Schnittstellen, das heißt den Kontext des zu erstellenden IVS-Dienstes aufzeigt.

*Einflussfaktoren und Randbedingungen

:
::wie funktionale und nicht-funktionale Anforderungen, organisatorische und technische Einflüsse.

*Lösungsstrategien

:
::halten die ersten Entscheidungen, wesentliche Architektur-Muster und Konzepte fest. Erste Architektursichten können entstehen, um die Lösungsstrategien zu verdeutlichen.

Ergebnis: [[IVS-Archtekturvision_Los3|IVS-Architektur Vision für Zuständigkeitsübergreifendes Verkehrsmanagement]]

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

Um den IVS-Dienst "Zuständigkeitsübergreifendes Verkehrsmanagement" realisieren zu können, müssen verschiedene IVS-Akteure zusammenarbeiten, sobald für eine Routenempfehlung die Aktorik, die Sensorik und/oder die Alternativroute oder Teile davon benötigt werden, die nicht in den eigenen Zuständigkeitsbereich fallen. Somit hängt die Interoperabilität von IVS-Akteuren im IVS-Dienst "Zuständigkeitsübergreifendes Verkehrsmanagement" im Wesentlichen davon ab, wie nahtlos diese zusammenarbeiten bzw. wie interoperabel diese ihre IVS-Geschäftsfähigkeiten gestalten können. Interoperabilität wird somit in den Mittelpunkt der architekturellen Bemühungen gestellt und die Bereitstellung von Interoperabilitäts-Bausteinen zum Kernziel von IVS-Architektur.

Ergebnis: [[IVS-Wertbeitrag_Los3|Wertbeitrag und KPIs von IVS-Architektur für Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== Risiken der Einführung einer IVS-Referenzarchitektur für zuständigkeitsübergreifendes Verkehrsmanagement ====

Die Einführung einer IVS-Architektur birgt auch Risiken. Das Risikomanagement soll genutzt wer-den, um die Risiken Einführung einer IVS-Referenzarchitektur für Zuständigkeitsübergreifenden Verkehrsmanagements zu erkennen, zu beurteilen und handzuhaben.

Ergebnis: [[Risiken_Los3|Risiken der Einführung einer IVS-Referenzarchitektur für Zuständigkeitsübergreifendes Verkehrsmanagement]]

----

== Phase Geschäftsarchitektur ==

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

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

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

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

*für die Sicht "IVS-Wertschöpfungskette/IVS-Wertschöpfungsnetzwerk"

:
:*Darstellung als '''IVS-Rollenmatrix''', wie sie im Projekt [[Media:ÖV-IVS_Schlussbericht_März_2014.pdf|Entwicklung einer ÖV-IVS-Rahmenarchitektur in Deutschland unter Einbindung Europäischer IVS-Richtlinien mit ÖV-Relevanz<ref>Kieslich, Wolfgang; Albrecht, Hanfried; Dinkel, Alexander u.a. (2014): Entwicklung einer für ÖV-IVS-Architektur in Deutschland unter Einbindung Europäischer IVS-Richtlinien mit ÖPNV-Relevanz. Schlussbericht. Im Auftrag des Bundesministeriums für Verkehr und digitale Infrastruktur. München.</ref>]] entwickelt wurde. Eine Anleitung findet sich [[Aufbau_von_IVS-Wertschöfungsketten_und_-netzwerke|'''hier''']].
:*Darstellung als '''Rollen/Capability-Diagramm'''. Ein Beispiel finden Sie '''[[PhaseB-Step2-Los3#Sicht_.22Wertsch.C3.B6pfungskette.2FWertsch.C3.B6pfungsnetzwerk.22_f.C3.BCr_Zust.C3.A4ndigkeits.C3.BCbergreifendes_Verkehrsmanagement|hier]]'''.

*für die Sicht "IVS-Governance"

:
::Für die Darstellung wird ein Textdokument empfohlen. Eine Beschreibungsstruktur findet sich [[IVS-Governance|hier]].

*für die Sicht "IVS-Geschäftsprozesse"

:
::für die Darstellung und Visualisierung der IVS-Geschäftsprozessarchitektur wird grundsätzlich ein Prozessmodellierungs-Ansatz gewählt. Durch das Aufschlüsseln von Geschäftsfunktionen und Geschäftsdiensten mit Hilfe der Prozessmodellierung wird die Identifizierung der Schlüssel-Prozesse und der nachgeordneten Dienste und Funktionen ermöglicht.
::*Ein Template zur Beschreibung von Geschäftsprozessen findet sich [[IVS-Geschäftsprozess|hier]].
::*Zur Modellierung von Geschäftsprozessen und Geschäftsfunktionen wird die Spezifikationssprache Business Process Model and Notation (BPMN) verwendet. Eine Anleitung findet sich [[Geschäftsprozessdiagramm|hier]].

Ergebnis: [[Hilfsmittel_und_Werkzeuge_Los3|Hilfsmittel zur Darstellung der IVS-Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== Ausgangssituation der IVS-Geschäftsarchitektur ===

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

*Sicht "IVS-Wertschöpfungsketten und -netzwerke"

:
::Die [[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.

*Sicht "IVS-Governance"

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

*Sicht "IVS-Geschäftsprozesse"

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

Ergebnisse:

*[[Ausgangssituation_Geschäftsarchitektur_Los_3_-_Sicht_Wertschöpfungsnetzwerk|Ausgangssituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Wertschöpfungsnetzwerk]]
*[[Ausgangssituation_Geschäftsarchitektur_Los_3_-_Sicht_Governance|Ausgangssituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Governance]]
*[[Ausgangssituation_Geschäftsarchitektur_Los_3_-_Sicht_Geschäftsprozesse|Ausgangssituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Geschäftsprozesse]]

=== Zielsituation der IVS-Geschäftsarchitektur ===

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

*Sicht [[Aufbau_von_IVS-Wertschöfungsketten_und_-netzwerke|"IVS-Wertschöpfungskette/IVS-Wertschöpfungsnetzwerk"]]

:
::Identifizierung, Darstellung und Beschreibung, über welche Bestandteile (Teildienste) der IVS-Dienst gebildet wird, welche IVS-Rollen daran beteiligt sein müssen und welche Anforderungen (IVS-Capabilities) an diese gestellt werden.

*Sicht [[IVS-Governance|"IVS-Governance"]]

:
::Beschreibung, auf welcher gesetzlichen, rechtlichen und vertraglichen Grundlage der IVS-Dienst und die Zusammenarbeit der IVS-Akteure zustande kommen und wie letztere operativ geführt und gesteuert wird.

*Sicht [[IVS-Geschäftsprozesse_und_Wertschöpfungsnetzwerke|"IVS-Geschäftsprozesse"]]

:
::Darstellung und Beschreibung, über welche Schlüssel-Geschäftsprozesse der IVS-Dienst operationalisiert wird.

Weitere Sichten können projektspezifisch aufgebaut und beschrieben werden.

Ergebnisse:

*[[Zielsituation_Geschäftsarchitektur_Los_3_-_Sicht_Wertschöpfungsnetzwerk|Zielsituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Wertschöpfungsnetzwerk]]
*[[Zielsituation_Geschäftsarchitektur_Los_3_-_Sicht_Governance|Zielsituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Governance]]
*[[Zielsituation_Geschäftsarchitektur_Los_3_-_Sicht_Geschäftsprozesse|Zielsituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Geschäftsprozesse]]

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

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

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

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

Ergebnisse:

*[[Gap-Analyse_Geschäftsarchitektur_Los_3_-_Sicht_Wertschöpfungsnetzwerk|Gap-Analyse Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Wertschöpfungsnetzwerk]]
*[[Gap-Analyse_Geschäftsarchitektur_Los_3_-_Sicht_Governance|Gap-Analyse Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Governance]]
*[[Gap-Analyse_Geschäftsarchitektur_Los_3_-_Sicht_Geschäftsprozesse|Gap-Analyse Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Geschäftsprozesse]]

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

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

Zur Beschreibung der einzelnen Arbeitsschritte sowie zur Festlegung von zeitlichen und inhaltlichen Abhängigkeiten zwischen den einzelnen Arbeitsschritten wird der Katalog [[Media:Architektur-Roadmap_00-00-01.docx|Architektur-Roadmap]] verwendet.

Ergebnis: [[IVS-Architektur-Roadmap_Los3|IVS-Architektur-Roadmap - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

----

=== Ergebnisse IVS-Datenarchitektur ===

==== Hilfsmittel, Sichten und Werkzeuge für IVS-Datenarchitektur ====

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

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

Ergebnis: [[Hilfsmittel_zur_Darstellung_der_IVS-Datenarchitektur_-_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement|Hilfsmittel zur Darstellung der IVS-Datenarchitektur für Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== Ausgangssituation der IVS-Datenarchitektur ====

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

Ergebnisse - Kataloge:

*[[Ausgangssituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement|Ausgangssituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Informationsobjekte]]
*[[Ausgangssituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_IVS-Datenmodelle|Ausgangssituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Datenmodelle]]
*[[Ausgangssituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_IVS-Ortsreferenzierung|Ausgangssituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Ortsreferenzierungen]]

Ergebnisse - Matrizen:

*[[Ausgangssituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_Matrix_IVS-Informationsobjekte/_IVS-Datenmodelle|Ausgangssituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Matrix IVS-Informationsobjekte/Datenmodelle]]
*[[Ausgangssituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_Matrix_IVS-Datenmodelle/_IVS-Ortsreferenzierungssysteme|Ausgangssituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Matrix IVS-Datenmodelle/ IVS-Ortsreferenzierungssysteme]]

==== Zielsituation der IVS-Datenarchitektur ====

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

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

Ergebnisse - Kataloge:

*[[Zielsituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Informationsobjekte|Zielsituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Informationsobjekte]]
*[[Zielsituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Datenmodelle|Zielsituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Datenmodelle]]
*[[Zielsituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Ortsreferenzierung|Zielsituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Ortsreferenzierung]]

Ergebnisse - Matrizen:

*[[Zielsituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_Matrix_IVS-Informationsobjekte/_IVS-Datenmodelle|Zielsituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Matrix IVS-Informationsobjekte/Datenmodelle]]
*[[Zielsituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_Matrix_IVS-Datenmodelle/_IVS-Ortsreferenzierungssysteme|Zielsituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Matrix IVS-Datenmodelle/ IVS-Ortsreferenzierungssysteme]]

==== Gap-Analyse für die IVS-Datenarchitektur ====

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

Ergebnisse:

*[[Gap-Analyse_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Informationsobjekte|Gap-Analyse IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Informationsobjekte]]
*[[Gap-Analyse_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Datenmodelle|Gap-Analyse IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Datenmodelle]]
*[[Gap-Analyse_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Ortsreferenzierungssysteme|Gap-Analyse IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Ortsreferenzierungssysteme]]

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

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

Ergebnis: [[IVS-Architektur-Roadmap_-_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Datenarchitektur|IVS-Architektur-Roadmap - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Datenarchitektur]]

----

=== Ergebnisse IVS-Anwendungsarchitektur ===

==== Hilfsmittel, Sichten und Werkzeuge für IVS-Anwendungsarchitektur ====

Die IVS-Anwendungsarchitektur fokussiert IVS-Anwendungen und deren IVS-Schnittstellen im Zuständigkeitsübergreifenden Verkehrsmanagement, die für die Ausführung der zuständigkeitsübergreifenden IVS-Geschäftsprozesse erforderlich sind.

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

Für die Darstellung der Anwendungsarchitektur im Zuständigkeitsübergreifenden Verkehrsmanagement schlägt die IVS-Rahmenarchitektur folgende Modellierungsprinzipien bzw. -werkzeuge vor:

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

Ergebnis: [[Hilfsmittel_zur_Darstellung_der_IVS-Anwendungsarchitektur_-_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement|Hilfsmittel zur Darstellung der IVS-Anwendungsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== Ausgangssituation der IVS-Anwendungsarchitektur ====

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

Ergebnis: [[Ausgangssituation_Anwendungsarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement|Ausgangssituation IVS-Anwendungsarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== Zielsituation der IVS-Anwendungsarchitektur ====

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

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

Ergebnis: [[Zielsituation_Anwendungsarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Anwendung|Zielsituation IVS-Anwendungsarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== Gap-Analyse für die IVS-Anwendungsarchitektur ====

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

Ergebnis: [[Gap-Analyse_Anwendungsarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Anwendung|Gap-Analyse IVS-Anwendungsarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

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

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

Ergebnis: [[IVS-Architektur-Roadmap_-_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Anwendungsarchitektur|IVS-Architektur-Roadmap - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Anwendungsarchitektur]]

----

=== Ergebnisse IVS-Technologiearchitektur ===

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

== Literaturverzeichnis ==

<references />

----

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

IVS-Referenzarchitektur für Zuständigkeitsübergreifendes Verkehrsmanagement 1.0

2018-08-29T10:53:21Z

Albrecht:

== Vorbereitungsphase ==

=== Steuerungs- und Unterstützungsframeworks ===

Mit den Steuerungs- und Unterstützungsframeworks für IVS-Architektur werden generell IVS-Architekturprojekte motiviert, begründet und gestützt. Der Inhalt dieser Frameworks bildet im Prinzip auch den Geist, in dem IVS-Architekturprojekte durchgeführt werden.

Für die IVS-Rahmenarchitektur bilden der Europäische IVS-Aktionsplan und die IVS-Direktive sowie auf nationaler Ebene das IVS-Gesetz und der Nationale IVS-Aktionsplan Straße die wesentlichen Frameworks. Für die IVS-Referenzarchitektur für Zuständigkeitsübergreifendes Verkehrsmanagement setzen neben den rechtlichen Vorgaben auch interne Vorgaben der einzelnen Stakeholder und Akteure den rechtlichen Handlungsrahmen.

Ergebnis: [[PhaseV-Step3-Los3_SteuerungsUndUnterstützungsframeworks|IVS-Steuerungs- und Unterstützungsframeworks für Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== IVS-Glossar ===

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

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

Für das Glossar für Zuständigkeitsübergreifendes Verkehrsmanagement gilt:

*Die Begriffsbestimmungen für IVS-Architektur (siehe [[IVS-Architekturbausteine#IVS-Architektur...|Was ist IVS-Architektur? - Schlüsselbegriffe]] und [[IVS-Architekturbausteine|Begriffe für die IVS-Gestaltungsmerkmale von IVS-Architektur]]) werden auf Zuständigkeitsübergreifendes Verkehrsmanagement übertragen.
*[[IVS-Glossar#Begriffsdefinitionen|Allgemeine Begriffe aus Verkehr, Transport und Mobilität]], die keine spezifische IVS-Architektur-Semantik repräsentieren, werden für Zuständigkeitsübergreifendes Verkehrsmanagement ergänzt.

Ergebnis: [[Los3_Glossar|IVS-Glossar für Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== Architekturprinzipien ===

Prinzipien stellen Grundsätze dar, die nicht nur dauerhaft gelten, sondern auch selten geändert werden sollten. Sie beschreiben die Art und Weise, wie eine davon betroffene Organisation ihre Aufgaben zu erfüllen hat. Prinzipien können für verschiedene Ebenen entwickelt und definiert werden.

Zur Detaillierung werden IVS-Architekturprinzipien gemäß den Ebenen von IVS-Architektur in folgende Untergruppen aufgeteilt:

*Geschäftsprinzip
*Daten-/Informationsprinzip
*Anwendungsprinzip
*Technologieprinzip

Ergebnis: [[Los3_IVS-Architekturprinzipien|IVS-Architekturprinzipien für Zuständigkeitsübergreifendes Verkehrsmanagement]]

----

== Phase Architektur Vision ==

=== Aufsetzen eines Architekturprojekts ===

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

*den IVS-Betrachtungsgegenstand "Zuständigkeitsübergreifendes Verkehrsmanagement" semantisch zu beschreiben (was ist der IVS-Betrachtungsgegenstand Zuständigkeitsübergreifendes Verkehrsmanagement) und
*klare Grenzen zu ähnlichen bzw. angrenzenden IVS-Betrachtungsgegenständen des Zuständigkeitsübergreifenden Verkehrsmanagements zu ziehen und festzulegen ('''was ist drin, was ist nicht drin''').

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

*Eine IVS-Referenzarchitektur soll verschiedene Gestaltungskonzepte für eine IVS-Dienstekategorie vorweisen.
*Bei der IVS-Architektur eines realen IVS-Dienstes müssen verschiedene Implementierungskonzepte für einen spezifischen IVS-Dienst erstellt werden.

Ergebnisse:

==== IVS-Domäne für Zuständigkeitsübergreifendes Verkehrsmanagement ====

*[[IVS-Domäne_Zuständigkeitsübergreifenden_Verkehrsmanagements_-_Template|IVS-Domäne für Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== IVS-Dienste(-kategorie) für Zuständigkeitsübergreifendes Verkehrsmanagement ====

*[[IVS-Dienste_Los3|IVS-Dienste(-kategorie) für Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== Zuständigkeitsübergreifendes Verkehrsmanagement - Allgemeine Beschreibung ====

*[[Zuständigkeitsübergreifendes_Verkehrsmanagement_-_Allgemeine_Beschreibung|Zuständigkeitsübergreifendes Verkehrsmanagement - Allgemeine Beschreibung]]

=== Erfassen und Beschreibung 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 in die IVS-Wertschöpfung zu involvierenden IVS-Akteure und die zu beteiligenden IVS-Stakeholder erfasst und beschrieben werden.

Dazu ist es nützlich - in Vorbereitung für den Schritt Entwicklung einer IVS-Architekturvision - eine erste Vorstellung für den IVS-Dienst/die IVS-Dienstekategorie zugrunde zu legen und darüber die erforderlichen IVS-Rollen in der IVS-Wertschöpfungskette/im IVS-Wertschöpfungsnetzwerk zu veranschaulichen.

Zur Ergebnisdarstellung werden zwei IVS-Bausteine verwendet:

*Der Baustein IVS-Rollen-Map, mit dem Stereotype von IVS-Akteuren und IVS-Stakeholdern deklariert, mit ihren Geschäftsanliegen und IVS-Rollen beschrieben und die Bedeutung von IVS-Akteuren und IVS-Stakeholdern gemäß "Power-Grid" klassifiziert werden.

*Der Baustein IVS-Rolle, mit dem Stereotype von IVS-Fähigkeiten und IVS-Verantwortlichkeiten, die für die Bereitstellung und den Betrieb von IVS-Diensten typisch und erforderlich sind, bezeichnet und semantisch beschrieben werden.

Ergebnisse:

*[[PhaseA-Step2-Los3_ErfassungUndBeschreibungVonRollen|IVS-Rollen im Zuständigkeitsübergreifenden Verkehrsmanagement - Allgemeine Beschreibung]]
*[[IVS-Rollen_Los3|IVS-Rollen-Map und IVS-Rollen Power-Grid für Zuständigkeitsübergreifendes Verkehrsmanagement]]
*[[IVS-Business_Szenarios_und_IVS-Anforderungen_Los_3_-_Zuständigkeitsübergreifendes_Verkehrsmanagement|IVS-Business Szenarios und IVS-Anforderungen für Zuständigkeitsübergreifendes Verkehrsmanagement]]

== Ziele, strategische Einflussfaktoren und Rahmenbedingungen ==

=== IVS-Leitbilder ===

Die Akzeptanz von Maßnahmen des Verkehrsmanagements wird beim Verkehrsteilnehmer erhöht, wenn sich der Betrieb an seinen Mobilitätsbedürfnissen und tatsächlichen Wegen orientiert und nicht an Zuständigkeitsgrenzen endet oder das Erscheinungsbild wechselt. Bei den indirekt beteiligten IVS-Stakeholdern und IVS-Akteuren wird eine hohe Akzeptanz erwartet, weil die "IVS-Referenzarchitektur für Zuständigkeitsübergreifendes Verkehrsmanagement" die Planungs- und Investitionssicherheit verbessert (Vermeidung von Insellösungen) und interoperable, betrieblich effiziente Lösungen begünstigt.

Ergebnis: [[IVS-Leitbilder_Los3|IVS-Leitbilder für Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== IVS-Geschäftsziele ===

Das Straßen- und Verkehrswesen kann einen Beitrag dazu leisten, die Lebensqualität der einzelnen Individuen zu steigern. Diese Forderung wird durch Definition der vier Oberziele des Verkehrs bekräftigt:

*Erhöhung der Sicherheit,
*Befriedigung des Mobilitätsbedürfnisses,
*Schonung der Umwelt und
*Verbesserung der Wirtschaftlichkeit.

Das Zuständigkeitsübergreifende Verkehrsmanagement setzt an dieser Stelle an. Durch gezielte Maßnahmen oder Maßnahmenbündel, die den gleichzeitigen Einsatz mehrerer Verkehrssysteme und -mittel (multimodal) oder den Wechsel der Verkehrssysteme (intermodal) innerhalb und außerhalb des eigenen Zuständigkeitsbereichs berücksichtigen, sollen Probleme oder bestimmte Situationen im regionalen und/oder überregionalen Verkehrssystem reduziert bzw. verbessert werden.

Ergebnis: [[IVS-Geschäftsziele_Los3|IVS-Geschäftsziele für Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== IVS-Capabilities ===

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

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

Grobe Vorstellungen für die Wertschöpfungskette des Zuständigkeitsübergreifenden Verkehrsmanagements zeigen folgenden Abbildungen:

<gallery mode="packed-hover">
File:TMValueChain.png | Wertschöpfungskette Verkehrsmanagement
File:WertschöpfungImSystemStrasse.png | System Strasse (Quelle Hessen Mobil)
</gallery>

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

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

Ergebnis: [[IVS-Capabilities_Los3|IVS-Capabilities für Zuständigkeitsübergreifenden Verkehrsmanagement]]

=== IVS-Architektur Vision ===

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

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

*Die Idee (für den IVS-Dienst),

:
::die die Kernaufgabe, die Nutzung und die Schnittstellen, das heißt den Kontext des zu erstellenden IVS-Dienstes aufzeigt.

*Einflussfaktoren und Randbedingungen

:
::wie funktionale und nicht-funktionale Anforderungen, organisatorische und technische Einflüsse.

*Lösungsstrategien

:
::halten die ersten Entscheidungen, wesentliche Architektur-Muster und Konzepte fest. Erste Architektursichten können entstehen, um die Lösungsstrategien zu verdeutlichen.

Ergebnis: [[IVS-Archtekturvision_Los3|IVS-Architektur Vision für Zuständigkeitsübergreifendes Verkehrsmanagement]]

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

Um den IVS-Dienst "Zuständigkeitsübergreifendes Verkehrsmanagement" realisieren zu können, müssen verschiedene IVS-Akteure zusammenarbeiten, sobald für eine Routenempfehlung die Aktorik, die Sensorik und/oder die Alternativroute oder Teile davon benötigt werden, die nicht in den eigenen Zuständigkeitsbereich fallen. Somit hängt die Interoperabilität von IVS-Akteuren im IVS-Dienst "Zuständigkeitsübergreifendes Verkehrsmanagement" im Wesentlichen davon ab, wie nahtlos diese zusammenarbeiten bzw. wie interoperabel diese ihre IVS-Geschäftsfähigkeiten gestalten können. Interoperabilität wird somit in den Mittelpunkt der architekturellen Bemühungen gestellt und die Bereitstellung von Interoperabilitäts-Bausteinen zum Kernziel von IVS-Architektur.

Ergebnis: [[IVS-Wertbeitrag_Los3|Wertbeitrag und KPIs von IVS-Architektur für Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== Risiken der Einführung einer IVS-Referenzarchitektur für zuständigkeitsübergreifendes Verkehrsmanagement ====

Die Einführung einer IVS-Architektur birgt auch Risiken. Das Risikomanagement soll genutzt wer-den, um die Risiken Einführung einer IVS-Referenzarchitektur für Zuständigkeitsübergreifenden Verkehrsmanagements zu erkennen, zu beurteilen und handzuhaben.

Ergebnis: [[Risiken_Los3|Risiken der Einführung einer IVS-Referenzarchitektur für Zuständigkeitsübergreifendes Verkehrsmanagement]]

----

== Phase Geschäftsarchitektur ==

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

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

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

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

*für die Sicht "IVS-Wertschöpfungskette/IVS-Wertschöpfungsnetzwerk"

:
:*Darstellung als '''IVS-Rollenmatrix''', wie sie im Projekt [[Media:ÖV-IVS_Schlussbericht_März_2014.pdf|Entwicklung einer ÖV-IVS-Rahmenarchitektur in Deutschland unter Einbindung Europäischer IVS-Richtlinien mit ÖV-Relevanz<ref>Kieslich, Wolfgang; Albrecht, Hanfried; Dinkel, Alexander u.a. (2014): Entwicklung einer für ÖV-IVS-Architektur in Deutschland unter Einbindung Europäischer IVS-Richtlinien mit ÖPNV-Relevanz. Schlussbericht. Im Auftrag des Bundesministeriums für Verkehr und digitale Infrastruktur. München.</ref>]] entwickelt wurde. Eine Anleitung findet sich [[Aufbau_von_IVS-Wertschöfungsketten_und_-netzwerke|'''hier''']].
:*Darstellung als '''Rollen/Capability-Diagramm'''. Ein Beispiel finden Sie '''[[PhaseB-Step2-Los3#Sicht_.22Wertsch.C3.B6pfungskette.2FWertsch.C3.B6pfungsnetzwerk.22_f.C3.BCr_Zust.C3.A4ndigkeits.C3.BCbergreifendes_Verkehrsmanagement|hier]]'''.

*für die Sicht "IVS-Governance"

:
::Für die Darstellung wird ein Textdokument empfohlen. Eine Beschreibungsstruktur findet sich [[IVS-Governance|hier]].

*für die Sicht "IVS-Geschäftsprozesse"

:
::für die Darstellung und Visualisierung der IVS-Geschäftsprozessarchitektur wird grundsätzlich ein Prozessmodellierungs-Ansatz gewählt. Durch das Aufschlüsseln von Geschäftsfunktionen und Geschäftsdiensten mit Hilfe der Prozessmodellierung wird die Identifizierung der Schlüssel-Prozesse und der nachgeordneten Dienste und Funktionen ermöglicht.
::*Ein Template zur Beschreibung von Geschäftsprozessen findet sich [[IVS-Geschäftsprozess|hier]].
::*Zur Modellierung von Geschäftsprozessen und Geschäftsfunktionen wird die Spezifikationssprache Business Process Model and Notation (BPMN) verwendet. Eine Anleitung findet sich [[Geschäftsprozessdiagramm|hier]].

Ergebnis: [[Hilfsmittel_und_Werkzeuge_Los3|Hilfsmittel zur Darstellung der IVS-Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== Ausgangssituation der IVS-Geschäftsarchitektur ===

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

*Sicht "IVS-Wertschöpfungsketten und -netzwerke"

:
::Die [[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.

*Sicht "IVS-Governance"

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

*Sicht "IVS-Geschäftsprozesse"

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

Ergebnisse:

*[[Ausgangssituation_Geschäftsarchitektur_Los_3_-_Sicht_Wertschöpfungsnetzwerk|Ausgangssituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Wertschöpfungsnetzwerk]]
*[[Ausgangssituation_Geschäftsarchitektur_Los_3_-_Sicht_Governance|Ausgangssituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Governance]]
*[[Ausgangssituation_Geschäftsarchitektur_Los_3_-_Sicht_Geschäftsprozesse|Ausgangssituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Geschäftsprozesse]]

=== Zielsituation der IVS-Geschäftsarchitektur ===

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

*Sicht [[Aufbau_von_IVS-Wertschöfungsketten_und_-netzwerke|"IVS-Wertschöpfungskette/IVS-Wertschöpfungsnetzwerk"]]

:
::Identifizierung, Darstellung und Beschreibung, über welche Bestandteile (Teildienste) der IVS-Dienst gebildet wird, welche IVS-Rollen daran beteiligt sein müssen und welche Anforderungen (IVS-Capabilities) an diese gestellt werden.

*Sicht [[IVS-Governance|"IVS-Governance"]]

:
::Beschreibung, auf welcher gesetzlichen, rechtlichen und vertraglichen Grundlage der IVS-Dienst und die Zusammenarbeit der IVS-Akteure zustande kommen und wie letztere operativ geführt und gesteuert wird.

*Sicht [[IVS-Geschäftsprozesse_und_Wertschöpfungsnetzwerke|"IVS-Geschäftsprozesse"]]

:
::Darstellung und Beschreibung, über welche Schlüssel-Geschäftsprozesse der IVS-Dienst operationalisiert wird.

Weitere Sichten können projektspezifisch aufgebaut und beschrieben werden.

Ergebnisse:

*[[Zielsituation_Geschäftsarchitektur_Los_3_-_Sicht_Wertschöpfungsnetzwerk|Zielsituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Wertschöpfungsnetzwerk]]
*[[Zielsituation_Geschäftsarchitektur_Los_3_-_Sicht_Governance|Zielsituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Governance]]
*[[Zielsituation_Geschäftsarchitektur_Los_3_-_Sicht_Geschäftsprozesse|Zielsituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Geschäftsprozesse]]

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

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

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

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

Ergebnisse:

*[[Gap-Analyse_Geschäftsarchitektur_Los_3_-_Sicht_Wertschöpfungsnetzwerk|Gap-Analyse Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Wertschöpfungsnetzwerk]]
*[[Gap-Analyse_Geschäftsarchitektur_Los_3_-_Sicht_Governance|Gap-Analyse Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Governance]]
*[[Gap-Analyse_Geschäftsarchitektur_Los_3_-_Sicht_Geschäftsprozesse|Gap-Analyse Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Geschäftsprozesse]]

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

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

Zur Beschreibung der einzelnen Arbeitsschritte sowie zur Festlegung von zeitlichen und inhaltlichen Abhängigkeiten zwischen den einzelnen Arbeitsschritten wird der Katalog [[Media:Architektur-Roadmap_00-00-01.docx|Architektur-Roadmap]] verwendet.

Ergebnis: [[IVS-Architektur-Roadmap_Los3|IVS-Architektur-Roadmap - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

----

=== Ergebnisse IVS-Datenarchitektur ===

==== Hilfsmittel, Sichten und Werkzeuge für IVS-Datenarchitektur ====

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

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

Ergebnis: [[Hilfsmittel_zur_Darstellung_der_IVS-Datenarchitektur_-_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement|Hilfsmittel zur Darstellung der IVS-Datenarchitektur für Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== Ausgangssituation der IVS-Datenarchitektur ====

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

Ergebnisse - Kataloge:

*[[Ausgangssituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement|Ausgangssituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Informationsobjekte]]
*[[Ausgangssituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_IVS-Datenmodelle|Ausgangssituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Datenmodelle]]
*[[Ausgangssituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_IVS-Ortsreferenzierung|Ausgangssituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Ortsreferenzierungen]]

Ergebnisse - Matrizen:

*[[Ausgangssituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_Matrix_IVS-Informationsobjekte/_IVS-Datenmodelle|Ausgangssituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Matrix IVS-Informationsobjekte/Datenmodelle]]
*[[Ausgangssituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_Matrix_IVS-Datenmodelle/_IVS-Ortsreferenzierungssysteme|Ausgangssituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Matrix IVS-Datenmodelle/ IVS-Ortsreferenzierungssysteme]]

==== Zielsituation der IVS-Datenarchitektur ====

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

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

Ergebnisse - Kataloge:

*[[Zielsituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Informationsobjekte|Zielsituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Informationsobjekte]]
*[[Zielsituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Datenmodelle|Zielsituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Datenmodelle]]
*[[Zielsituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Ortsreferenzierung|Zielsituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Ortsreferenzierung]]

Ergebnisse - Matrizen:

*[[Zielsituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_Matrix_IVS-Informationsobjekte/_IVS-Datenmodelle|Zielsituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Matrix IVS-Informationsobjekte/Datenmodelle]]
*[[Zielsituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_Matrix_IVS-Datenmodelle/_IVS-Ortsreferenzierungssysteme|Zielsituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Matrix IVS-Datenmodelle/ IVS-Ortsreferenzierungssysteme]]

==== Gap-Analyse für die IVS-Datenarchitektur ====

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

Ergebnisse:

*[[Gap-Analyse_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Informationsobjekte|Gap-Analyse IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Informationsobjekte]]
*[[Gap-Analyse_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Datenmodelle|Gap-Analyse IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Datenmodelle]]
*[[Gap-Analyse_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Ortsreferenzierungssysteme|Gap-Analyse IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Ortsreferenzierungssysteme]]

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

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

Ergebnis: [[IVS-Architektur-Roadmap_-_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Datenarchitektur|IVS-Architektur-Roadmap - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Datenarchitektur]]

----

=== Ergebnisse IVS-Anwendungsarchitektur ===

==== Hilfsmittel, Sichten und Werkzeuge für IVS-Anwendungsarchitektur ====

Die IVS-Anwendungsarchitektur fokussiert IVS-Anwendungen und deren IVS-Schnittstellen im Zuständigkeitsübergreifenden Verkehrsmanagement, die für die Ausführung der zuständigkeitsübergreifenden IVS-Geschäftsprozesse erforderlich sind.

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

Für die Darstellung der Anwendungsarchitektur im Zuständigkeitsübergreifenden Verkehrsmanagement schlägt die IVS-Rahmenarchitektur folgende Modellierungsprinzipien bzw. -werkzeuge vor:

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

Ergebnis: [[Hilfsmittel_zur_Darstellung_der_IVS-Anwendungsarchitektur_-_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement|Hilfsmittel zur Darstellung der IVS-Anwendungsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== Ausgangssituation der IVS-Anwendungsarchitektur ====

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

Ergebnis: [[Ausgangssituation_Anwendungsarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement|Ausgangssituation IVS-Anwendungsarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== Zielsituation der IVS-Anwendungsarchitektur ====

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

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

Ergebnis: [[Zielsituation_Anwendungsarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Anwendung|Zielsituation IVS-Anwendungsarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== Gap-Analyse für die IVS-Anwendungsarchitektur ====

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

Ergebnis: [[Gap-Analyse_Anwendungsarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Anwendung|Gap-Analyse IVS-Anwendungsarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

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

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

Ergebnis: [[IVS-Architektur-Roadmap_-_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Anwendungsarchitektur|IVS-Architektur-Roadmap - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Anwendungsarchitektur]]

----

=== Ergebnisse IVS-Technologiearchitektur ===

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

== Literaturverzeichnis ==

<references />

----

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

IVS-Referenzarchitektur für Zuständigkeitsübergreifendes Verkehrsmanagement 1.0

2018-08-29T10:45:40Z

Albrecht:

== Vorbereitungsphase ==

=== Steuerungs- und Unterstützungsframeworks ===

Mit den Steuerungs- und Unterstützungsframeworks für IVS-Architektur werden generell IVS-Architekturprojekte motiviert, begründet und gestützt. Der Inhalt dieser Frameworks bildet im Prinzip auch den Geist, in dem IVS-Architekturprojekte durchgeführt werden.

Für die IVS-Rahmenarchitektur bilden der Europäische IVS-Aktionsplan und die IVS-Direktive sowie auf nationaler Ebene das IVS-Gesetz und der Nationale IVS-Aktionsplan Straße die wesentlichen Frameworks. Für die IVS-Referenzarchitektur für Zuständigkeitsübergreifendes Verkehrsmanagement setzen neben den rechtlichen Vorgaben auch interne Vorgaben der einzelnen Stakeholder und Akteure den rechtlichen Handlungsrahmen.

Ergebnis: [[PhaseV-Step3-Los3_SteuerungsUndUnterstützungsframeworks|IVS-Steuerungs- und Unterstützungsframeworks für Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== IVS-Glossar ===

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

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

Für das Glossar für Zuständigkeitsübergreifendes Verkehrsmanagement gilt:

*Die Begriffsbestimmungen für IVS-Architektur (siehe [[IVS-Architekturbausteine#IVS-Architektur...|Was ist IVS-Architektur? - Schlüsselbegriffe]] und [[IVS-Architekturbausteine|Begriffe für die IVS-Gestaltungsmerkmale von IVS-Architektur]]) werden auf Zuständigkeitsübergreifendes Verkehrsmanagement übertragen.
*[[IVS-Glossar#Begriffsdefinitionen|Allgemeine Begriffe aus Verkehr, Transport und Mobilität]], die keine spezifische IVS-Architektur-Semantik repräsentieren, werden für Zuständigkeitsübergreifendes Verkehrsmanagement ergänzt.

Ergebnis: [[Los3_Glossar|IVS-Glossar für Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== Architekturprinzipien ===

Prinzipien stellen Grundsätze dar, die nicht nur dauerhaft gelten, sondern auch selten geändert werden sollten. Sie beschreiben die Art und Weise, wie eine davon betroffene Organisation ihre Aufgaben zu erfüllen hat. Prinzipien können für verschiedene Ebenen entwickelt und definiert werden.

Zur Detaillierung werden IVS-Architekturprinzipien gemäß den Ebenen von IVS-Architektur in folgende Untergruppen aufgeteilt:

*Geschäftsprinzip
*Daten-/Informationsprinzip
*Anwendungsprinzip
*Technologieprinzip

Ergebnis: [[Los3_IVS-Architekturprinzipien|IVS-Architekturprinzipien für Zuständigkeitsübergreifendes Verkehrsmanagement]]

----

== Phase Architektur Vision ==

=== Aufsetzen eines Architekturprojekts ===

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

*den IVS-Betrachtungsgegenstand "Zuständigkeitsübergreifendes Verkehrsmanagement" semantisch zu beschreiben (was ist der IVS-Betrachtungsgegenstand Zuständigkeitsübergreifendes Verkehrsmanagement) und
*klare Grenzen zu ähnlichen bzw. angrenzenden IVS-Betrachtungsgegenständen des Zuständigkeitsübergreifenden Verkehrsmanagements zu ziehen und festzulegen ('''was ist drin, was ist nicht drin''').

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

*Eine IVS-Referenzarchitektur soll verschiedene Gestaltungskonzepte für eine IVS-Dienstekategorie vorweisen.
*Bei der IVS-Architektur eines realen IVS-Dienstes müssen verschiedene Implementierungskonzepte für einen spezifischen IVS-Dienst erstellt werden.

Ergebnisse:

==== IVS-Domäne für Zuständigkeitsübergreifendes Verkehrsmanagement ====

*[[IVS-Domäne_Zuständigkeitsübergreifenden_Verkehrsmanagements_-_Template|IVS-Domäne für Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== IVS-Dienste(-kategorie) für Zuständigkeitsübergreifendes Verkehrsmanagement ====

*[[IVS-Dienste_Los3|IVS-Dienste(-kategorie) für Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== Zuständigkeitsübergreifendes Verkehrsmanagement - Allgemeine Beschreibung ====

*[[Zuständigkeitsübergreifendes_Verkehrsmanagement_-_Allgemeine_Beschreibung|Zuständigkeitsübergreifendes Verkehrsmanagement - Allgemeine Beschreibung]]

=== Erfassen und Beschreibung 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 in die IVS-Wertschöpfung zu involvierenden IVS-Akteure und die zu beteiligenden IVS-Stakeholder erfasst und beschrieben werden.

Dazu ist es nützlich - in Vorbereitung für den Schritt Entwicklung einer IVS-Architekturvision - eine erste Vorstellung für den IVS-Dienst/die IVS-Dienstekategorie zugrunde zu legen und darüber die erforderlichen IVS-Rollen in der IVS-Wertschöpfungskette/im IVS-Wertschöpfungsnetzwerk zu veranschaulichen.

Zur Ergebnisdarstellung werden zwei IVS-Bausteine verwendet:

*Der Baustein IVS-Rollen-Map, mit dem Stereotype von IVS-Akteuren und IVS-Stakeholdern deklariert, mit ihren Geschäftsanliegen und IVS-Rollen beschrieben und die Bedeutung von IVS-Akteuren und IVS-Stakeholdern gemäß "Power-Grid" klassifiziert werden.

*Der Baustein IVS-Rolle, mit dem Stereotype von IVS-Fähigkeiten und IVS-Verantwortlichkeiten, die für die Bereitstellung und den Betrieb von IVS-Diensten typisch und erforderlich sind, bezeichnet und semantisch beschrieben werden.

Ergebnisse:

*[[PhaseA-Step2-Los3_ErfassungUndBeschreibungVonRollen|IVS-Rollen im Zuständigkeitsübergreifenden Verkehrsmanagement - Allgemeine Beschreibung]]
*[[IVS-Rollen_Los3|IVS-Rollen-Map und IVS-Rollen Power-Grid für Zuständigkeitsübergreifendes Verkehrsmanagement]]
*[[IVS-Business_Szenarios_und_IVS-Anforderungen_Los_3_-_Zuständigkeitsübergreifendes_Verkehrsmanagement|IVS-Business Szenarios und IVS-Anforderungen für Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== IVS-Leitbilder ===

Die Akzeptanz von Maßnahmen des Verkehrsmanagements wird beim Verkehrsteilnehmer erhöht, wenn sich der Betrieb an seinen Mobilitätsbedürfnissen und tatsächlichen Wegen orientiert und nicht an Zuständigkeitsgrenzen endet oder das Erscheinungsbild wechselt. Bei den indirekt beteiligten IVS-Stakeholdern und IVS-Akteuren wird eine hohe Akzeptanz erwartet, weil die "IVS-Referenzarchitektur für Zuständigkeitsübergreifendes Verkehrsmanagement" die Planungs- und Investitionssicherheit verbessert (Vermeidung von Insellösungen) und interoperable, betrieblich effiziente Lösungen begünstigt.

Ergebnis: [[IVS-Leitbilder_Los3|IVS-Leitbilder für Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== IVS-Geschäftsziele ====

Das Straßen- und Verkehrswesen kann einen Beitrag dazu leisten, die Lebensqualität der einzelnen Individuen zu steigern. Diese Forderung wird durch Definition der vier Oberziele des Verkehrs bekräftigt:

*Erhöhung der Sicherheit,
*Befriedigung des Mobilitätsbedürfnisses,
*Schonung der Umwelt und
*Verbesserung der Wirtschaftlichkeit.

Das Zuständigkeitsübergreifende Verkehrsmanagement setzt an dieser Stelle an. Durch gezielte Maßnahmen oder Maßnahmenbündel, die den gleichzeitigen Einsatz mehrerer Verkehrssysteme und -mittel (multimodal) oder den Wechsel der Verkehrssysteme (intermodal) innerhalb und außerhalb des eigenen Zuständigkeitsbereichs berücksichtigen, sollen Probleme oder bestimmte Situationen im regionalen und/oder überregionalen Verkehrssystem reduziert bzw. verbessert werden.

Ergebnis: [[IVS-Geschäftsziele_Los3|IVS-Geschäftsziele für Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== IVS-Capabilities ====

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

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

Grobe Vorstellungen für die Wertschöpfungskette des Zuständigkeitsübergreifenden Verkehrsmanagements zeigen folgenden Abbildungen:

<gallery mode="packed-hover">
File:TMValueChain.png | Wertschöpfungskette Verkehrsmanagement
File:WertschöpfungImSystemStrasse.png | System Strasse (Quelle Hessen Mobil)
</gallery>

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

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

Ergebnis: [[IVS-Capabilities_Los3|IVS-Capabilities für Zuständigkeitsübergreifenden Verkehrsmanagement]]

==== IVS-Architektur Vision ====

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

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

*Die Idee (für den IVS-Dienst),

:
::die die Kernaufgabe, die Nutzung und die Schnittstellen, das heißt den Kontext des zu erstellenden IVS-Dienstes aufzeigt.

*Einflussfaktoren und Randbedingungen

:
::wie funktionale und nicht-funktionale Anforderungen, organisatorische und technische Einflüsse.

*Lösungsstrategien

:
::halten die ersten Entscheidungen, wesentliche Architektur-Muster und Konzepte fest. Erste Architektursichten können entstehen, um die Lösungsstrategien zu verdeutlichen.

Ergebnis: [[IVS-Archtekturvision_Los3|IVS-Architektur Vision für Zuständigkeitsübergreifendes Verkehrsmanagement]]

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

Um den IVS-Dienst "Zuständigkeitsübergreifendes Verkehrsmanagement" realisieren zu können, müssen verschiedene IVS-Akteure zusammenarbeiten, sobald für eine Routenempfehlung die Aktorik, die Sensorik und/oder die Alternativroute oder Teile davon benötigt werden, die nicht in den eigenen Zuständigkeitsbereich fallen. Somit hängt die Interoperabilität von IVS-Akteuren im IVS-Dienst "Zuständigkeitsübergreifendes Verkehrsmanagement" im Wesentlichen davon ab, wie nahtlos diese zusammenarbeiten bzw. wie interoperabel diese ihre IVS-Geschäftsfähigkeiten gestalten können. Interoperabilität wird somit in den Mittelpunkt der architekturellen Bemühungen gestellt und die Bereitstellung von Interoperabilitäts-Bausteinen zum Kernziel von IVS-Architektur.

Ergebnis: [[IVS-Wertbeitrag_Los3|Wertbeitrag und KPIs von IVS-Architektur für Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== Risiken der Einführung einer IVS-Referenzarchitektur für zuständigkeitsübergreifendes Verkehrsmanagement ====

Die Einführung einer IVS-Architektur birgt auch Risiken. Das Risikomanagement soll genutzt wer-den, um die Risiken Einführung einer IVS-Referenzarchitektur für Zuständigkeitsübergreifenden Verkehrsmanagements zu erkennen, zu beurteilen und handzuhaben.

Ergebnis: [[Risiken_Los3|Risiken der Einführung einer IVS-Referenzarchitektur für Zuständigkeitsübergreifendes Verkehrsmanagement]]

----

== Phase Geschäftsarchitektur ==

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

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

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

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

*für die Sicht "IVS-Wertschöpfungskette/IVS-Wertschöpfungsnetzwerk"

:
:*Darstellung als '''IVS-Rollenmatrix''', wie sie im Projekt [[Media:ÖV-IVS_Schlussbericht_März_2014.pdf|Entwicklung einer ÖV-IVS-Rahmenarchitektur in Deutschland unter Einbindung Europäischer IVS-Richtlinien mit ÖV-Relevanz<ref>Kieslich, Wolfgang; Albrecht, Hanfried; Dinkel, Alexander u.a. (2014): Entwicklung einer für ÖV-IVS-Architektur in Deutschland unter Einbindung Europäischer IVS-Richtlinien mit ÖPNV-Relevanz. Schlussbericht. Im Auftrag des Bundesministeriums für Verkehr und digitale Infrastruktur. München.</ref>]] entwickelt wurde. Eine Anleitung findet sich [[Aufbau_von_IVS-Wertschöfungsketten_und_-netzwerke|'''hier''']].
:*Darstellung als '''Rollen/Capability-Diagramm'''. Ein Beispiel finden Sie '''[[PhaseB-Step2-Los3#Sicht_.22Wertsch.C3.B6pfungskette.2FWertsch.C3.B6pfungsnetzwerk.22_f.C3.BCr_Zust.C3.A4ndigkeits.C3.BCbergreifendes_Verkehrsmanagement|hier]]'''.

*für die Sicht "IVS-Governance"

:
::Für die Darstellung wird ein Textdokument empfohlen. Eine Beschreibungsstruktur findet sich [[IVS-Governance|hier]].

*für die Sicht "IVS-Geschäftsprozesse"

:
::für die Darstellung und Visualisierung der IVS-Geschäftsprozessarchitektur wird grundsätzlich ein Prozessmodellierungs-Ansatz gewählt. Durch das Aufschlüsseln von Geschäftsfunktionen und Geschäftsdiensten mit Hilfe der Prozessmodellierung wird die Identifizierung der Schlüssel-Prozesse und der nachgeordneten Dienste und Funktionen ermöglicht.
::*Ein Template zur Beschreibung von Geschäftsprozessen findet sich [[IVS-Geschäftsprozess|hier]].
::*Zur Modellierung von Geschäftsprozessen und Geschäftsfunktionen wird die Spezifikationssprache Business Process Model and Notation (BPMN) verwendet. Eine Anleitung findet sich [[Geschäftsprozessdiagramm|hier]].

Ergebnis: [[Hilfsmittel_und_Werkzeuge_Los3|Hilfsmittel zur Darstellung der IVS-Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

=== Ausgangssituation der IVS-Geschäftsarchitektur ===

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

*Sicht "IVS-Wertschöpfungsketten und -netzwerke"

:
::Die [[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.

*Sicht "IVS-Governance"

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

*Sicht "IVS-Geschäftsprozesse"

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

Ergebnisse:

*[[Ausgangssituation_Geschäftsarchitektur_Los_3_-_Sicht_Wertschöpfungsnetzwerk|Ausgangssituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Wertschöpfungsnetzwerk]]
*[[Ausgangssituation_Geschäftsarchitektur_Los_3_-_Sicht_Governance|Ausgangssituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Governance]]
*[[Ausgangssituation_Geschäftsarchitektur_Los_3_-_Sicht_Geschäftsprozesse|Ausgangssituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Geschäftsprozesse]]

=== Zielsituation der IVS-Geschäftsarchitektur ===

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

*Sicht [[Aufbau_von_IVS-Wertschöfungsketten_und_-netzwerke|"IVS-Wertschöpfungskette/IVS-Wertschöpfungsnetzwerk"]]

:
::Identifizierung, Darstellung und Beschreibung, über welche Bestandteile (Teildienste) der IVS-Dienst gebildet wird, welche IVS-Rollen daran beteiligt sein müssen und welche Anforderungen (IVS-Capabilities) an diese gestellt werden.

*Sicht [[IVS-Governance|"IVS-Governance"]]

:
::Beschreibung, auf welcher gesetzlichen, rechtlichen und vertraglichen Grundlage der IVS-Dienst und die Zusammenarbeit der IVS-Akteure zustande kommen und wie letztere operativ geführt und gesteuert wird.

*Sicht [[IVS-Geschäftsprozesse_und_Wertschöpfungsnetzwerke|"IVS-Geschäftsprozesse"]]

:
::Darstellung und Beschreibung, über welche Schlüssel-Geschäftsprozesse der IVS-Dienst operationalisiert wird.

Weitere Sichten können projektspezifisch aufgebaut und beschrieben werden.

Ergebnisse:

*[[Zielsituation_Geschäftsarchitektur_Los_3_-_Sicht_Wertschöpfungsnetzwerk|Zielsituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Wertschöpfungsnetzwerk]]
*[[Zielsituation_Geschäftsarchitektur_Los_3_-_Sicht_Governance|Zielsituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Governance]]
*[[Zielsituation_Geschäftsarchitektur_Los_3_-_Sicht_Geschäftsprozesse|Zielsituation Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Geschäftsprozesse]]

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

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

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

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

Ergebnisse:

*[[Gap-Analyse_Geschäftsarchitektur_Los_3_-_Sicht_Wertschöpfungsnetzwerk|Gap-Analyse Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Wertschöpfungsnetzwerk]]
*[[Gap-Analyse_Geschäftsarchitektur_Los_3_-_Sicht_Governance|Gap-Analyse Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Governance]]
*[[Gap-Analyse_Geschäftsarchitektur_Los_3_-_Sicht_Geschäftsprozesse|Gap-Analyse Geschäftsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Sicht Geschäftsprozesse]]

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

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

Zur Beschreibung der einzelnen Arbeitsschritte sowie zur Festlegung von zeitlichen und inhaltlichen Abhängigkeiten zwischen den einzelnen Arbeitsschritten wird der Katalog [[Media:Architektur-Roadmap_00-00-01.docx|Architektur-Roadmap]] verwendet.

Ergebnis: [[IVS-Architektur-Roadmap_Los3|IVS-Architektur-Roadmap - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

----

=== Ergebnisse IVS-Datenarchitektur ===

==== Hilfsmittel, Sichten und Werkzeuge für IVS-Datenarchitektur ====

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

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

Ergebnis: [[Hilfsmittel_zur_Darstellung_der_IVS-Datenarchitektur_-_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement|Hilfsmittel zur Darstellung der IVS-Datenarchitektur für Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== Ausgangssituation der IVS-Datenarchitektur ====

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

Ergebnisse - Kataloge:

*[[Ausgangssituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement|Ausgangssituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Informationsobjekte]]
*[[Ausgangssituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_IVS-Datenmodelle|Ausgangssituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Datenmodelle]]
*[[Ausgangssituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_IVS-Ortsreferenzierung|Ausgangssituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Ortsreferenzierungen]]

Ergebnisse - Matrizen:

*[[Ausgangssituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_Matrix_IVS-Informationsobjekte/_IVS-Datenmodelle|Ausgangssituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Matrix IVS-Informationsobjekte/Datenmodelle]]
*[[Ausgangssituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_Matrix_IVS-Datenmodelle/_IVS-Ortsreferenzierungssysteme|Ausgangssituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Matrix IVS-Datenmodelle/ IVS-Ortsreferenzierungssysteme]]

==== Zielsituation der IVS-Datenarchitektur ====

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

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

Ergebnisse - Kataloge:

*[[Zielsituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Informationsobjekte|Zielsituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Informationsobjekte]]
*[[Zielsituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Datenmodelle|Zielsituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Datenmodelle]]
*[[Zielsituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Ortsreferenzierung|Zielsituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Ortsreferenzierung]]

Ergebnisse - Matrizen:

*[[Zielsituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_Matrix_IVS-Informationsobjekte/_IVS-Datenmodelle|Zielsituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Matrix IVS-Informationsobjekte/Datenmodelle]]
*[[Zielsituation_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_Matrix_IVS-Datenmodelle/_IVS-Ortsreferenzierungssysteme|Zielsituation IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - Matrix IVS-Datenmodelle/ IVS-Ortsreferenzierungssysteme]]

==== Gap-Analyse für die IVS-Datenarchitektur ====

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

Ergebnisse:

*[[Gap-Analyse_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Informationsobjekte|Gap-Analyse IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Informationsobjekte]]
*[[Gap-Analyse_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Datenmodelle|Gap-Analyse IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Datenmodelle]]
*[[Gap-Analyse_Datenarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Ortsreferenzierungssysteme|Gap-Analyse IVS-Datenarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Ortsreferenzierungssysteme]]

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

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

Ergebnis: [[IVS-Architektur-Roadmap_-_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Datenarchitektur|IVS-Architektur-Roadmap - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Datenarchitektur]]

----

=== Ergebnisse IVS-Anwendungsarchitektur ===

==== Hilfsmittel, Sichten und Werkzeuge für IVS-Anwendungsarchitektur ====

Die IVS-Anwendungsarchitektur fokussiert IVS-Anwendungen und deren IVS-Schnittstellen im Zuständigkeitsübergreifenden Verkehrsmanagement, die für die Ausführung der zuständigkeitsübergreifenden IVS-Geschäftsprozesse erforderlich sind.

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

Für die Darstellung der Anwendungsarchitektur im Zuständigkeitsübergreifenden Verkehrsmanagement schlägt die IVS-Rahmenarchitektur folgende Modellierungsprinzipien bzw. -werkzeuge vor:

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

Ergebnis: [[Hilfsmittel_zur_Darstellung_der_IVS-Anwendungsarchitektur_-_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement|Hilfsmittel zur Darstellung der IVS-Anwendungsarchitektur - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== Ausgangssituation der IVS-Anwendungsarchitektur ====

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

Ergebnis: [[Ausgangssituation_Anwendungsarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement|Ausgangssituation IVS-Anwendungsarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== Zielsituation der IVS-Anwendungsarchitektur ====

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

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

Ergebnis: [[Zielsituation_Anwendungsarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Anwendung|Zielsituation IVS-Anwendungsarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

==== Gap-Analyse für die IVS-Anwendungsarchitektur ====

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

Ergebnis: [[Gap-Analyse_Anwendungsarchitektur_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Anwendung|Gap-Analyse IVS-Anwendungsarchitektur Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement]]

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

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

Ergebnis: [[IVS-Architektur-Roadmap_-_Los_3:_Zuständigkeitsübergreifendes_Verkehrsmanagement_-_IVS-Anwendungsarchitektur|IVS-Architektur-Roadmap - Los 3: Zuständigkeitsübergreifendes Verkehrsmanagement - IVS-Anwendungsarchitektur]]

----

=== Ergebnisse IVS-Technologiearchitektur ===

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

== Literaturverzeichnis ==

<references />

----

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

TOGAF-Phase C.2

2018-06-21T10:05:31Z

Albrecht:

== Einführung in die Entwicklung von Anwendungsarchitekturen ==

In der '''Phase C.2 Entwicklung der IVS-Anwendungsarchitektur''' geht es grundsätzlich darum, die Anwendungsarchitektur (engl. Application Architecture) von IVS-Diensten/IVS-Dienstekategorien zu verstehen, zu modellieren, zu visualisieren und zu beschreiben.

Die Hauptaufgabe einer Anwendungsarchitektur ist die Entwicklung von Lösungsbausteinen, mit denen die Geschäftsarchitektur und die Architekturvision umgesetzt werden können. Des Weiteren wird eine Roadmap entwickelt, in der die Umsetzung der Lösungsbausteine zeitlich und inhaltlich geplant wird.

Da die IVS-Architektur sich weniger mit der internen Anwendungsarchitektur der an IVS beteiligten Organisationen/Institutionen selbst befasst, sondern den IVS-Dienst und die dafür erforderliche Zusammenarbeitsfähigkeit von IVS-Akteuren zum Gegenstand hat, muss das Konzept der Datenarchitektur auf IVS-Architektur als Zusammenarbeitskonzept übertragen werden. Grundlage dafür sind die IVS-Schnittstellen, die verwendet werden, um einen IVS-Dienst bzw. eine IVS-Dienstekategorie zu realisieren.

== Schritte der Phase C.2 - IVS-Anwendungsarchitektur ==

'''Wichtige Hinweise''': [[Hinweise_zu_den_Phasen_B,C_und_D|zu den Schritten der IVS-Architekturentwicklung in den Phasen B, C und D]]

{| class="wikitable"
|-
! Schritt
! TOGAF
! Tailoring IVS-Rahmenarchitektur
! Anleitung
! Artefakte {K=Katalog, M=Matrix, D=Diagramm}, O=Other Deliverables
! Empfehlung für IVS-Referenzarchitekturen
! Empfehlung für IVS-Architekturen realer IVS-Dienste
|- style="vertical-align:top"
| 1
| Auswahl von [http://pubs.opengroup.org/architecture/togaf91-doc/arch/chap11.html#tag_11_04_01 Hilfsmitteln, Sichten und Werkzeugen für die Darstellung der Anwendungsarchitektur]
| Auswahl von Hilfsmitteln, Sichten und Werkzeugen für die Darstellung der IVS-Anwendungsarchitektur
| '''[[IVS-Referenzmodelle_und_Werkzeuge_-_Anwendungsarchitektur|Hilfsmittel, Sichten und Werkzeuge für die Darstellung der IVS-Anwendungsarchitektur]]'''
| Projektspezifische Lösung
| Auswahl von Hilfsmitteln, Sichten und Werkzeugen für die Darstellung der IVS-Anwendungsarchitektur einer IVS-Dienstekategorie
*[[PhaseC2-Step1-Los2|Verkehrsinformation Individualverkehr]]

| Auswahl von Hilfsmitteln, Sichten und Werkzeugen für die Darstellung der IVS-Anwendungsarchitektur eines spezifischen IVS-Dienstes
|- style="vertical-align:top"
| 2
| Entwicklung einer Beschreibung der [http://pubs.opengroup.org/architecture/togaf91-doc/arch/chap11.html#tag_11_04_02 Ausgangssituation für die Anwendungsarchitektur]
| Entwicklung einer Beschreibung der Ausgangssituation für die Anwendungsarchitektur
| '''[[IVS-Anwendungsarchitektur_Ausgangssituation|Ausgangssituation der IVS-Anwendungsarchitektur]]'''
|
Projektspezifische Lösung

|
Beschreibung der Ausgangssituation der Anwendungsarchitektur für die IVS-Dienstekategorie

*[[PhaseC2-Step2-Los2|Verkehrsinformation Individualverkehr]]

|
Beschreibung der Ausgangssituation der Anwendungsarchitektur für den spezifischen IVS-Dienst (falls vorhanden)

|- style="vertical-align:top"
| 3
| Entwicklung einer Beschreibung der [http://pubs.opengroup.org/architecture/togaf91-doc/arch/chap11.html#tag_11_04_03 Ziel-Anwendungsarchitektur]
| Ermittlung von zukünftig benötigten Anwendungen, Services und Schnittstellen
| '''[[Zielsituation_der_IVS-Anwendungsarchitektur|Zielsituation der IVS-Anwendungsarchitektur]]'''
*[[IVS-Anwendung|Template: Baustein IVS-Anwendung]]
*[[IVS-Schnittstelle|Template: Baustein IVS-Schnittstelle]]

|
*[[Media:IVS-Anwendungen-Katalog_00-00-02.docx|K:IVS-Anwendung]]
*[[Media:IVS-Schnittstellen-Katalog_00-00-02.docx|K:IVS-Schnittstelle]]
*[[Media:Schnittstellen-Datenmodelle-Template_00-00-01.xlsx|M:Schnittstellen-Datenmodelle]]
*[[Media:Anwendungen-Schnittstellen-Template_00-00-02.xlsx|M:Anwendungen-Schnittstellen]]
*[[Komponentendiagramm|D:Komponentendiagramm]]

|
Beschreibung der Ziel-Anwendungsarchitektur für die IVS-Dienstekategorie

*[[:File:PhaseC2-Step3-Los2.docx|Verkehrsinformation Individualverkehr]]

|
Beschreibung der Ziel-Anwendungsarchitektur für den spezifischen IVS-Dienst

|- style="vertical-align:top"
| 4
| Durchführung einer [http://pubs.opengroup.org/architecture/togaf91-doc/arch/chap11.html#tag_11_04_04 Gap-Analyse]
| Durchführung einer Gap-Analyse für die IVS-Anwendungsarchitektur
| '''[[Gap-Analyse_Anwendungsarchitektur|Gap-Analyse Anwendungsarchitektur]]'''
| Projektspezifische Lösung
| Durchführung einer Gap-Analyse für die Anwendungsarchitektur der IVS-Dienstekategorie
*[[PhaseC2-Step4-Los2|Verkehrsinformation Individualverkehr]]

| Durchführung einer Gap-Analyse für die Anwendungsarchitektur des spezifischen IVS-Dienstes
|- style="vertical-align:top"
| 5
| Definition von [http://pubs.opengroup.org/architecture/togaf91-doc/arch/chap11.html#tag_11_04_05 Roadmap-Komponenten]
| Festlegung von IVS-Anwendungsarchitektur-Kandidaten für die IVS-Architektur-Roadmap
| [[Roadmap_Anwendungsarchitektur|'''IVS-Anwendungsarchitektur-Kandidaten für die IVS-Architektur-Roadmap''']]
*[[Architektur-Roadmap|Template: IVS-Architektur-Roadmap]]

;Hintergrundinformationen und Techniken
:[[Roadmap_IVS-Architektur|Roadmap IVS-Architektur]]

|
*[[Media:Architektur-Roadmap_00-00-01.docx|O:Architektur-Roadmap]]

| Erweiterung der Architektur-Roadmap für die Anwendungsarchitektur der IVS-Dienstekategorie
| Erweiterung der Architektur-Roadmap für die Anwendungsarchitektur des spezifischen IVS-Dienstes
|- style="vertical-align:top"
| 6
| Klärung der [http://pubs.opengroup.org/architecture/togaf91-doc/arch/chap11.html#tag_11_04_06 Auswirkungen auf die gesamte Architekturlandschaft]
| Klärung der Auswirkungen der IVS-Anwendungsarchitekturkandidaten der IVS-Architektur-Roadmap auf die gesamte IVS-Architekturlandschaft (Ebenen der IVS-Pyramide)
| [[Auswirkungen_IVS-Anwendungsarchitektur|'''Auswirkungen auf die gesamte IVS-Architekturlandschaft''']]
| Projektspezifische Lösung
| Klärung der Auswirkungen der IVS-Anwendungsarchitekturkandidaten der IVS-Architektur-Roadmap auf die gesamte IVS-Architekturlandschaft der IVS-Dienstekategorie
| Klärung der Auswirkungen der IVS-Anwendungsarchitekturkandidaten der IVS-Architektur-Roadmap auf die gesamte IVS-Architekturlandschaft des realen IVS-Dienstes
|- style="vertical-align:top"
| 7
| Durchführung eines formalen [http://pubs.opengroup.org/architecture/togaf91-doc/arch/chap11.html#tag_11_04_07 Stakeholder-Reviews]
| Durchführung eines formalen Stakeholder-Reviews für die IVS-Anwendungsarchitektur
| '''[[Stakeholder-Review_IVS-Anwendungsarchitektur|Formales Stakeholder-Review für IVS-Anwendungsarchitektur]]'''
| Projektspezifische Lösung
| Durchführung eines formalen Stakeholder-Reviews für die IVS-Anwendungsarchitektur der IVS-Dienstekategorie
| Durchführung eines formalen Stakeholder-Reviews für die IVS-Anwendungsarchitektur eines realen IVS-Dienstes
|- style="vertical-align:top"
| 8
| Finalisierung der [http://pubs.opengroup.org/architecture/togaf91-doc/arch/chap11.html#tag_11_04_08 Anwendungsarchitektur]
| Finalisierung der IVS-Anwendungsarchitektur
| [[Finalisierung_der_IVS-Anwendungsarchitektur|'''Finalisierung der IVS-Anwendungsarchitektur''']]
| Projektspezifische Lösung
| Finalisierung der IVS-Anwendungsarchitektur für die IVS-Dienstekategorie
| Finalisierung der Anwendungsarchitektur für den realen IVS-Dienst
|- style="vertical-align:top"
| 9
| Erstellung der [http://pubs.opengroup.org/architecture/togaf91-doc/arch/chap11.html#tag_11_04_09 Dokumentation für die Architekturdefinition]
| Erweiterung des IVS-Architekturdefinitionsdokuments um die IVS-Anwendungsarchitektur
| [[IVS-Architekturdefinitionsdokument_Anwendungsarchitektur|'''IVS-Architekturdefinitionsdokument - Abschnitt IVS-Anwendungsarchitektur''']]
| Projektspezifische Lösung
| Erweiterung des Architekturdefinitionsdokuments für die Anwendungsarchitektur der IVS-Dienstekategorie
| Erweiterung des Architekturdefinitionsdokuments für die Anwendungsarchitektur des spezifischen IVS-Dienstes des spezifischen IVS-Dienstes
|}

== Schritte der Phase C - IVS-Anwendungsarchitektur im Überblick ==

[[File:Phase-C-Anwendung.png|thumb|left|300px|Phase C - IVS-Anwendungsarchitektur]]

----

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

TOGAF-Phase C.1

2018-06-21T10:04:41Z

Albrecht:

== Einführung in die Entwicklung von Datenarchitekturen ==

In der '''Phase C.1 Entwicklung der IVS-Datenarchitektur''' geht es grundsätzlich darum, die Datenarchitektur (engl. Data Architecture) von IVS-Diensten/IVS-Dienstekategorien zu verstehen, zu modellieren, zu visualisieren und zu beschreiben.

Die Hauptaufgabe einer Datenarchitektur ist die Entwicklung von Lösungsbausteinen, mit denen die Geschäftsarchitektur und die Architekturvision umgesetzt werden können. Des Weiteren wird eine Roadmap entwickelt, in der die Umsetzung der Lösungsbausteine zeitlich und inhaltlich geplant wird.

Da die IVS-Architektur sich weniger mit der internen Datenarchitektur der an IVS beteiligten Organisationen/Institutionen selbst befasst, sondern den IVS-Dienst und die dafür erforderliche Zusammenarbeitsfähigkeit von IVS-Akteuren zum Gegenstand hat, muss das Konzept der Datenarchitektur auf IVS-Architektur als Zusammenarbeitskonzept übertragen werden. Grundlage dafür sind die zwischen IVS-Akteuren bzw. IVS-Akteurs-Stereotypen auszutauschenden IVS-Informationsobjekte.

== Schritte der Phase C.1 - IVS-Datenarchitektur ==

'''Wichtige Hinweise''': [[Hinweise_zu_den_Phasen_B,C_und_D|zu den Schritten der IVS-Architekturentwicklung in den Phasen B, C und D]]

{| class="wikitable"
|-
! Schritt
! TOGAF
! Tailoring IVS-Rahmenarchitektur
! Anleitung
! Artefakte {K=Katalog, M=Matrix, D=Diagramm}, O=Other Deliverables
! Empfehlung für IVS-Referenzarchitekturen
! Empfehlung für IVS-Architekturen realer IVS-Dienste
|- style="vertical-align:top;"
| 1
| Auswahl von [http://pubs.opengroup.org/architecture/togaf91-doc/arch/chap10.html#tag_10_04_01 Hilfsmitteln, Sichten und Werkzeugen für die Darstellung der Datenarchitektur]
| Auswahl von Hilfsmitteln, Sichten und Werkzeugen für die Darstellung IVS-Datenarchitektur
| '''[[IVS-Referenzmodelle_und_Werkzeuge_-_Datenarchitektur|Hilfsmittel, Sichten und Werkzeuge für die Darstellung IVS-Datenarchitektur]]'''
|
Projektspezifische Lösung

|
Auswahl von Hilfsmitteln, Sichten und Werkzeugen für die Darstellung IVS-Datenarchitektur einer IVS-Dienstekategorie

*[[PhaseC1-Step1-Los2|Verkehrsinformation Individualverkehr]]

|
Auswahl von Hilfsmitteln, Sichten und Werkzeugen für die Darstellung IVS-Datenarchitektur eines spezifischen IVS-Dienstes

|- style="vertical-align:top;"
| 2
| Entwicklung einer Beschreibung der [http://pubs.opengroup.org/architecture/togaf91-doc/arch/chap10.html#tag_10_04_02 Ausgangssituation für die Datenarchitektur]
| Entwicklung einer Beschreibung der Ausgangssituation der Datenarchitektur
| '''[[IVS-Datenarchitektur_Ausgangssituation|Ausgangssituation der IVS-Datenarchitektur]]'''
|
Projektspezifische Lösung

|
Beschreibung der Ausgangssituation der Datenarchitektur für die IVS-Dienstekategorie

*[[PhaseC1-Step2-Los2|Verkehrsinformation Individualverkehr]]

|
Beschreibung der Ausgangssituation der Datenarchitektur für den spezifischen IVS-Dienst (falls vorhanden)

|- style="vertical-align:top;"
| 3
| Entwicklung einer Beschreibung der [http://pubs.opengroup.org/architecture/togaf91-doc/arch/chap10.html#tag_10_04_03 Ziel-Datenarchitektur]
| Ermittlung von zukünftig benötigten Informationsobjekten, Datenmodellen und Ortsreferenzierungssysteme
| '''[[Zielsituation_der_IVS-Datenarchitektur|Zielsituation der IVS-Datenarchitektur]]'''
*[[IVS-Informationsobjekt|Template: Baustein IVS-Informationsobjekt]]
*[[IVS-Datenmodell|Template: Baustein IVS-Datenmodell]]
*[[IVS-Ortsreferenzierung|Template: Baustein IVS-Ortsreferenzierung]]

|
*[[Media:IVS-Informationsobjekt-Katalog_00-00-02.docx|K:IVS-Informationsobjekt]]
*[[Media:IVS-Datenmodell-Katalog_00-00-02.docx|K:IVS-Datenmodell]]
*[[Media:IVS-Ortsreferenzierungs-Katalog_00-00-01.docx|K:IVS-Ortsreferenzierung]]
*[[Media:Informationsobjekte-Aktivitäten-Template_00-00-01.xlsx|M:Informationsobjekte-Aktivitäten]]
*[[Media:IVS-Informationsobjekte-Datenmodelle-Template_00-00-01.xlsx|M:Informationsobjekte-Datenmodelle]]
*[[Media:IVS-Datenmodell-Ortsreferenzen-Template_00-00-01.xlsx|M:Datenmodelle-Ortsreferenzierungen]]

|
Beschreibung der Ziel-Datenarchitektur für die IVS-Dienstekategorie

*[[:File:PhaseC1-Step3-Los2.docx|Verkehrsinformation Individualverkehr]]

|
Beschreibung der Ziel-Datenarchitektur für den spezifischen IVS-Dienst

|- style="vertical-align:top;"
| 4
| Durchführung einer [http://pubs.opengroup.org/architecture/togaf91-doc/arch/chap10.html#tag_10_04_04 Gap-Analyse]
| Durchführung einer Gap-Analyse für die IVS-Datenarchitektur
| '''[[Gap-Analyse_Datenarchitektur|Gap-Analyse Datenarchitektur]]'''
|
Projektspezifische Lösung

|
Durchführung einer Gap-Analyse für die Datenarchitektur der IVS-Dienstekategorie

*[[PhaseC1-Step4-Los2|Verkehrsinformation Individualverkehr]]

|
Durchführung einer Gap-Analyse für die Datenarchitektur des spezifischen IVS-Dienstes

|- style="vertical-align:top;"
| 5
| Definition von [http://pubs.opengroup.org/architecture/togaf91-doc/arch/chap10.html#tag_10_04_05 Roadmap-Komponenten]
| Festlegung von IVS-Datenarchitektur-Kandidaten für die IVS-Architektur-Roadmap
| [[Roadmap_Datenarchitektur|'''IVS-Datenarchitektur-Kandidaten für die IVS-Architektur-Roadmap''']]
*[[Architektur-Roadmap|Template: IVS-Architektur-Roadmap]]

;Hintergrundinformationen und Techniken
:[[Roadmap_IVS-Architektur|Roadmap IVS-Architektur]]

|
*[[Media:Architektur-Roadmap_00-00-01.docx|O:Architektur-Roadmap]]

| Erweiterung der Architektur-Roadmap für die Datenarchitektur der IVS-Dienstekategorie
| Erweiterung der Architektur-Roadmap für die Datenarchitektur des spezifischen IVS-Dienstes
|- style="vertical-align:top;"
| 6
| Klärung der [http://pubs.opengroup.org/architecture/togaf91-doc/arch/chap10.html#tag_10_04_06 Auswirkungen auf die gesamte Architekturlandschaft]
| Klärung der Auswirkungen der IVS-Datenarchitekturkandidaten der IVS-Architektur-Roadmap auf die gesamte IVS-Architekturlandschaft (Ebenen der IVS-Pyramide)
| [[Auswirkungen_IVS-Datenarchitektur|'''Auswirkungen auf die gesamte IVS-Architekturlandschaft''']]
| Projektspezifische Lösung
| Klärung der Auswirkungen der IVS-Datenarchitekturkandidaten der IVS-Architektur-Roadmap auf die gesamte IVS-Architekturlandschaft der IVS-Dienstekategorie
| Klärung der Auswirkungen der IVS-Datenarchitekturkandidaten der IVS-Architektur-Roadmap auf die gesamte IVS-Architekturlandschaft des realen IVS-Dienstes
|- style="vertical-align:top;"
| 7
| Durchführung eines formalen [http://pubs.opengroup.org/architecture/togaf91-doc/arch/chap10.html#tag_10_04_07 Stakeholder-Reviews]
| Durchführung eines formalen Stakeholder-Reviews für die IVS-Datenarchitektur
| '''[[Stakeholder-Review_IVS-Datenarchitektur|Formales Stakeholder-Review für IVS-Datenarchitektur]]'''
| Projektspezifische Lösung
| Durchführung eines formalen Stakeholder-Reviews für die IVS-Datenarchitektur der IVS-Dienstekategorie
| Durchführung eines formalen Stakeholder-Reviews für die IVS-Datenarchitektur eines realen IVS-Dienstes
|- style="vertical-align:top;"
| 8
| Finalisierung der [http://pubs.opengroup.org/architecture/togaf91-doc/arch/chap10.html#tag_10_04_08 Datenarchitektur]
| Finalisierung der IVS-Datenarchitektur
| [[Finalisierung_der_IVS-Datensarchitektur|'''Finalisierung der IVS-Datenarchitektur''']]
| Projektspezifische Lösung
| Finalisierung der IVS-Datenarchitektur für die IVS-Dienstekategorie
| Finalisierung der IVS-Datenarchitektur für den realen IVS-Dienst
|- style="vertical-align:top;"
| 9
| Erweiterung der [http://pubs.opengroup.org/architecture/togaf91-doc/arch/chap10.html#tag_10_04_09 Dokumentation für die Architekturdefinition]
| Erweiterung des IVS-Architekturdefinitionsdokuments um die IVS-Datenarchitektur
| [[IVS-Architekturdefinitionsdokument_Datenarchitektur|'''IVS-Architekturdefinitionsdokument - Abschnitt IVS-Datenarchitektur''']]
| Projektspezifische Lösung
| Erweiterung des Architekturdefinitionsdokuments für die Datenarchitektur der IVS-Dienstekategorie
| Erweiterung des Architekturdefinitionsdokuments für die Datenarchitektur des spezifischen IVS-Dienstes
|}

== Schritte der Phase C - IVS-Datenarchitektur im Überblick ==

[[File:Phase-C-Daten.png|thumb|left|300px|Phase C – IVS-Datenarchitektur]]

----

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

TOGAF-Phase B

2018-06-21T10:03:41Z

Albrecht:

== Einführung in die Entwicklung von Geschäftsarchitekturen ==

In der '''Phase B Entwicklung der IVS-Geschäftsarchitektur''' geht es grundsätzlich darum, die Geschäftsarchitektur (engl. Business Architecture) von IVS-Diensten/IVS-Dienstekategorien zu verstehen, zu modellieren, zu visualisieren und zu beschreiben.

Der Begriff '''Business Architecture und seine Semantik''' sind durchaus noch in Diskussion:

*Erst 2013 hat die OMG-Arbeitsgruppe BASIG ([http://www.omg.org/bawg/ Business Architecture Special Interest Group der OMG]) folgende Definition aufgestellt:
**''Business Architecture is defined as "Formal models and diagrammatic representations of governance structures, business semantics and value streams across the extended enterprise"''
*TOGAF behandelt das Thema "Geschäftsarchitektur in der ADM-Phase B und definiert den Begriff wie folgt:
**''Business Architecture defines the "Business strategy, governance, organization and key business processes"''.
*Im IBM Knowledge Center findet sich unter [http://www.ibm.com/support/knowledgecenter/de/SS6RBX_11.4.3/com.ibm.sa.togaf9.doc/topics/t_bldphs_b.html Liefergegenstände für Phase B: Geschäftsarchitektur erstellen] eine ausführliche Beschreibung zu den Inhalten und Liefergegenständen der Phase B - Geschäftsarchitektur

== [[IVS-Geschäftsarchitektur|Übertragung des Geschäftsarchitekturkonzepts auf IVS-Architektur]] ==

Da die IVS-Architektur sich weniger mit der Geschäftsarchitektur der an IVS beteiligten Organisationen/Institutionen selbst befasst, sondern den IVS-Dienst und die dafür erforderliche Zusammenarbeitsfähigkeit von IVS-Akteuren zum Gegenstand hat, muss das Konzept der Geschäftsarchitektur auf IVS-Architektur als Zusammenarbeitskonzept übertragen werden. Grundlage dafür sind folgende Konzepte von IVS-Architektur:

;[[IVS-Dienste-Konzept#IVS-Dienst|IVS-Dienste...]]
:sind eine geschäftliche Leistung von IVS-Wertschöpfungsketten bzw. IVS-Wertschöpfungsnetzwerken, die aus der '''organisationsübergreifenden Vernetzung und Zusammenarbeit von IVS-Akteuren''' resultieren.

;[[IVS-Dienste-Konzept#IVS-Wertsch.C3.B6pfungsketten_und_-_netzwerke|IVS-Wertschöpfungsketten/IVS-Wertschöpfungsnetzwerke...]]
:müssen als Prozessketten für '''IVS-Informationslogistik''' interpretiert werden.

;IVS-Informationslogistik...
:das heißt die '''Organisation, Steuerung, Bereitstellung und Optimierung von IVS relevanten Informationsströmen''' ist die eigentliche Herausforderung für die IVS-Akteure als Bestandteil von IVS-Wertschöpfungsketten/IVS-Wertschöpfungsnetzwerken

Vor diesem Hintergrund kann/muss der Begriff IVS-Geschäftsarchitektur wie folgt festgelegt werden:

'''IVS-Geschäftsarchitektur...'''

*'''konkretisiert und operationalisiert die Geschäftsstrategie (Ziele und Nutzen)''' von IVS-Wertschöpfungsketten/IVS-Wertschöpfungsnetzwerken.
*entwickelt '''Sichten auf das Geschäft (Business)''' von IVS-Wertschöpfungsketten/IVS-Wertschöpfungsnetzwerken in Bezug auf '''Aufbau (IVS-Rollen), Führung und Steuerung (IVS-Governance) und Geschäftsprozessen (IVS-Geschäftsprozesse) ''' und leitet daraus Anforderungen ab.

== Schritte der Phase B - IVS-Geschäftsarchitektur ==

'''Wichtige Hinweise''': [[Hinweise_zu_den_Phasen_B,C_und_D|zu den Schritten der IVS-Architekturentwicklung in den Phasen B, C und D]]

{| class="wikitable"
|-
! Schritt
! TOGAF
! Tailoring IVS-Architekturen
! Anleitung
! Artefakte {K=Katalog, M=Matrix, D=Diagramm}, O=Other Deliverables
! Empfehlung für IVS-Referenzarchitekturen
! Empfehlung für IVS-Architekturen realer IVS-Dienste
|- style="vertical-align:top"
| 1
| Auswahl [http://pubs.opengroup.org/architecture/togaf91-doc/arch/chap08.html#tag_08_04_01 von Hilfsmitteln, Sichten und Werkzeugen für die Darstellung der Geschäftsarchitektur]
| Auswahl von Hilfsmitteln, Sichten und Werkzeugen für die Darstellung IVS-Geschäftsarchitektur
| [[Hilfsmittel,_Sichten_und_Werkzeuge_für_IVS-Geschäftsarchitektur|'''Hilfsmittel, Sichten und Werkzeuge für die Darstellung der IVS-Geschäftsarchitektur''']]
;Hintergrundinformationen und Techniken
:[[Aufbau_von_IVS-Wertschöfungsketten_und_-netzwerke|Darstellung von IVS-Wertschöpfungsketten und -netzwerken]]
:[[IVS-Governance|Darstellung von IVS-Governance]]
:[[Geschäftsprozesse|Darstellung von IVS-Geschäftsprozessen]]

| Projektspezifische Lösung
| Auswahl von Hilfsmitteln, Sichten und Werkzeugen für die Darstellung der IVS-Geschäftsarchitektur einer IVS-Dienstekategorie
*[[PhaseB-Step1-Los2|Verkehrsinformation Individualverkehr]]
*[[PhaseB-Step1-Los3|Zuständigkeitsübergreifendes Verkehrsmanagement]]
*[[Hilfsmittel_und_Werkzeuge_Los4|Multimodale Reiseinformation]]

| Auswahl von Hilfsmitteln, Sichten und Werkzeugen für die Darstellung der IVS-Geschäftsarchitektur eines spezifischen IVS-Dienstes
|- style="vertical-align:top"
| 2
| Beschreibung der [http://pubs.opengroup.org/architecture/togaf91-doc/arch/chap08.html#tag_08_04_02 Ausgangssituation der Geschäftsarchitektur]
| Beschreibung der Ausgangssituation der IVS-Geschäftsarchitektur
| '''[[IVS-Geschäftsarchitektur_Ausgangssituation|Ausgangssituation der IVS-Geschäftsarchitektur]]'''
*[[IVS-Geschäftsprozess|Template: Baustein IVS-Geschäftsprozess]]

| Projektspezifische Lösung (soweit vorhanden bzw. erforderlich)
*[[Aufbau_von_IVS-Wertschöfungsketten_und_-netzwerke|D:IVS-Rollenmatrix]]
*[[IVS-Governance|O:IVS-Governance]]
*[[Media:IVS-Geschäftsprozess-Katalog_00-00-03.docx|K:IVS-Geschäftprozesse]]
*[[Geschäftsprozessdiagramm|D:IVS-Geschäftsprozessdiagramm]]

| Beschreibung der Ausgangssituation der IVS-Geschäftsarchitektur für die IVS-Kategorie (nur soweit vorhanden)
*[[PhaseB-Step2-Los2|Verkehrsinformation Individualverkehr]]
*[[PhaseB-Step2-Los3|Zuständigkeitsübergreifendes Verkehrsmanagement]]
*[[TOGAF_B#Ausgangssituation_der_IVS-Gesch.C3.A4ftsarchitektur|Multimodale Reiseinformation]]

| Beschreibung der Ausgangssituation der IVS-Geschäftsarchitektur für den spezifischen IVS-Dienst (nur soweit erforderlich)
|- style="vertical-align:top"
| 3
| Beschreibung der [http://pubs.opengroup.org/architecture/togaf91-doc/arch/chap08.html#tag_08_04_03 Ziel-Geschäftsarchitektur]
| Beschreibung der Ziel-IVS-Geschäftsarchitektur
| '''[[Zielsituation_der_IVS-Geschäftsarchitektur|Ziel-IVS-Geschäftsarchitektur]]'''
*[[IVS-Geschäftsprozess|Template: Baustein IVS-Geschäftsprozess]]

|
*[[Aufbau_von_IVS-Wertschöfungsketten_und_-netzwerke|D:IVS-Rollenmatrix]]
*[[IVS-Governance|O:IVS-Governance]]
*[[Media:_IVS-Geschäftsprozess-Katalog_00-00-03.docx|K:IVS-Geschäftprozesse]]
*[[Geschäftsprozessdiagramm|D:IVS-Geschäftsprozessdiagramm]]

| Beschreibung der Ziel-IVS-Geschäftsarchitektur für die IVS-Dienstekategorie
*[[PhaseB-Step3-Los2|Verkehrsinformation Individualverkehr]]
*[[PhaseB-Step3-Los3|Zuständigkeitsübergreifendes Verkehrsmanagement]]
*[[TOGAF_B#Ziel-IVS-Gesch.C3.A4ftsarchitektur|Multimodale Reiseinformation]]

| Beschreibung der Ziel-IVS-Geschäftsarchitektur für den spezifischen IVS-Dienst
|- style="vertical-align:top"
| 4
| Durchführung einer [http://pubs.opengroup.org/architecture/togaf91-doc/arch/chap08.html#tag_08_04_04 Gap-Analyse]
| Durchführung einer Gap-Analyse für die IVS-Geschäftsarchitektur
| '''[[Gap-Analyse_Geschäftsarchitektur|Gap-Analyse für die IVS-Geschäftsarchitektur]]'''
| Projektspezifische Lösung
| Durchführung einer Gap-Analyse für die IVS-Geschäftsarchitektur der IVS-Dienstekategorie
*[[PhaseB-Step4-Los2|Verkehrsinformation Individualverkehr]]
*[[PhaseB-Step4-Los3|Zuständigkeitsübergreifendes Verkehrsmanagement]]
*[[TOGAF_B#Gap-Analyse_f.C3.BCr_die_IVS-Gesch.C3.A4ftsarchitektur|Multimodale Reiseinformation]]

| Durchführung einer Gap-Analyse für die IVS-Geschäftsarchitektur des spezifischen IVS-Dienstes
|- style="vertical-align:top"
| 5
| Festlegung von Kandidaten für [http://pubs.opengroup.org/architecture/togaf91-doc/arch/chap08.html#tag_08_04_05 die Architektur Roadmap]
| Festlegung von IVS-Geschäftsarchitektur-Kandidaten für die IVS-Architektur-Roadmap
| [[Roadmap_Geschäftsarchitektur|'''IVS-Geschäftsarchitekturkandidaten für die IVS-Architektur-Roadmap''']]
*[[Architektur-Roadmap|Template: Baustein IVS-Architektur-Roadmap]]

;Hintergrundinformationen und Techniken
:[[Roadmap_IVS-Architektur|Roadmap für IVS-Architektur]]

|
*[[Media:Architektur-Roadmap_00-00-01.docx|O:IVS-Architektur-Roadmap]]

| Anlegen der IVS-Architektur-Roadmap für die IVS-Dienstekategorie
*[[PhaseB-Step5-Los3|Zuständigkeitsübergreifendes Verkehrsmanagement]]
*[[IVS-Architektur-Roadmap_Los4|Multimodale Reiseinformation]]

| Anlegen der IVS-Architektur-Roadmap für die IVS-Architektur des spezifischen IVS-Dienstes
|- style="vertical-align:top"
| 6
| Klärung der [http://pubs.opengroup.org/architecture/togaf91-doc/arch/chap08.html#tag_08_04_06 Auswirkungen auf die gesamte Architekturlandschaft]
| Klärung der Auswirkungen der IVS-Geschäftsarchitekturkandidaten der IVS-Architektur-Roadmap auf die gesamte IVS-Architekturlandschaft (Ebenen der IVS-Pyramide)
| [[Auswirkungen_auf_die_Architekturlandschaft|'''Auswirkungen auf die gesamte IVS-Architekturlandschaft''']]
| Projektspezifische Lösung
| Klärung der Auswirkungen der IVS-Geschäftsarchitekturkandidaten der IVS-Architektur-Roadmap auf die gesamte IVS-Architekturlandschaft der IVS-Dienstekategorie
| Klärung der Auswirkungen der IVS-Geschäftsarchitekturkandidaten der IVS-Architektur-Roadmap auf die gesamte IVS-Architekturlandschaft des realen IVS-Dienstes
|- style="vertical-align:top"
| 7
| Durchführung eines formalen [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap08.html#tag_08_04_07 Stakeholder-Reviews]
| Durchführung eines formalen Stakeholder-Reviews für IVS-Geschäftsarchitektur
| [[Durchführung_eines_formalen_Stakeholder-Reviews_für_IVS-Geschäftsarchitektur|'''Durchführung eines formalen Stakeholder-Reviews für IVS-Geschäftsarchitektur''']]
| Projektspezifische Lösung
| Durchführung eines formalen Stakeholder-Reviews für die IVS-Geschäftsarchitektur der IVS-Dienstekategorie
| Durchführung eines formalen Stakeholder-Reviews für die IVS-Geschäftsarchitektur eines realen IVS-Dienstes
|- style="vertical-align:top"
| 8
| Finalisierung der [http://pubs.opengroup.org/architecture/togaf91-doc/arch/chap08.html#tag_08_04_08 Geschäftsarchitektur]
| Finalisierung der IVS-Geschäftsarchitektur
| [[Finalisierung_der_IVS-Geschäftsarchitektur|'''Finalisierung der IVS-Geschäftsarchitektur''']]
| Projektspezifische Lösung
| Finalisierung der IVS-Geschäftsarchitektur für die IVS-Dienstekategorie
| Finalisierung der IVS-Geschäftsarchitektur für den realen IVS-Dienst
|- style="vertical-align:top"
| 9
| Anlegen der [http://pubs.opengroup.org/architecture/togaf91-doc/arch/chap08.html#tag_08_04_09 Dokumentation für die Architekturdefinition]
| Anlegen des IVS-Architekturdefinitionsdokuments
| [[IVS-Architekturdefinitionsdokument|'''IVS-Architekturdefinitionsdokument''']]
| Projektspezifische Lösung
| Anlegen des IVS-Architekturdefinitionsdokuments für die IVS-Dienstekategorie
| Anlegen des IVS-Architekturdefinitionsdokuments für den realen IVS-Dienst
|}

== Schritte der Phase B - IVS-Geschäftsarchitektur im Überblick ==

[[File:Phase-B 00-00-01.png|thumb|left|300px|Phase B - IVS-Geschäftsarchitektur]]

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

Vorarbeiten

2018-06-21T10:03:00Z

Albrecht:

== Vorbereitungsphase ==

;TOGAF

:In der Vorbereitungsphase werden die Grundlagen für die Durchführung erfolgreicher Unternehmensarchitekturprojekte geschaffen.

;IVS-Rahmenarchitektur

:In der Vorbereitungsphase werden die Grundlagen für die Durchführung erfolgreicher IVS-Architekturprojekte geschaffen.

== Schritte der Vorbereitungsphase ==

{| class="wikitable"
|-
! Schritt
! TOGAF
! Tailoring IVS-Architektur
! Anleitung
! Artefakte {K=Katalog, M=Matrix, D=Diagramm}, O=Other Deliverables
! Empfehlung für IVS-Referenzarchitekturen
! Empfehlung für IVS-Architekturen realer IVS-Dienste
|- style="vertical-align:top;"
| 1
| Bestimmung des [http://pubs.opengroup.org/architecture/togaf91-doc/arch/chap06.html#tag_06_04 Wirkungsbereichs]
| Bestimmung des Wirkungsbereichs von IVS-Architektur
| [[Wirkungsbereichs_der_IVS-Architekturaufgabe|'''Wirkungsbereich von IVS-Architektur''']]
;Hintergrundinformationen und Techniken
:[[Wirkungsbereich_von_IVS-Architektur|Beispiel IVS-Rahmenarchitektur]]

| Projektspezifische Lösung
| Projektspezifische Lösung
| Projektspezifische Lösung
|- style="vertical-align:top;"
| 2
| Identifizierung der betroffenen [http://pubs.opengroup.org/architecture/togaf91-doc/arch/chap06.html#tag_06_04_01 Organisationseinheiten]
| Identifizierung von IVS-Architektur betroffener Institutionen/Unternehmen
| [[Identifizierung_betroffener_Institutionen_und_Rahmenbedingungen|'''Von IVS-Architektur betroffene Institutionen/Unternehmen und Rahmenbedingungen''']]
| Projektspezifische Lösung
| Projektspezifische Lösung
| Projektspezifische Lösung
|- style="vertical-align:top;"
| 3
| Sicherstellung von [http://pubs.opengroup.org/architecture/togaf91-doc/arch/chap06.html#tag_06_04_02 Steuerungs- und Unterstützungsframeworks]
| Sicherstellung von Steuerungs- und Unterstützungsframeworks für IVS-Architektur
| [[IVS-Frameworks|'''Steuerungs- und Unterstützungsframeworks für IVS-Architektur''']]
| Projektspezifische Lösung
|
*[[PhaseV-Step3-Los3|Zuständigkeitsübergreifendes Verkehrsmanagement]]

| Projektspezifische Lösung
|- style="vertical-align:top;"
| 4
| Definition und Aufbau eines [http://pubs.opengroup.org/architecture/togaf91-doc/arch/chap06.html#tag_06_04_03 Unternehmensarchitektur-Teams und einer Organisation]
| Definition und Aufbau eines IVS-Architektur-Teams und einer Organisation
|
*[[IVS-Architekturteam|'''Hinweise zur Bildung eines IVS-Architekturteams''']]
*[[Glossar|'''Glossar, Grundlage für gemeinsames Verstehen''']]
**[[Glossar-Template|Template: Other Deliverable IVS-Glossar - Allgemeine Begriffe aus Verkehr, Transport und Mobilität]]

;Hintergrundinformationen und Techniken
:[[Meta-Modelle|Modell, Grundlage für Nachvollziehbarkeit]]

|
*Projektspezifische Lösung
*[[Media:Glossar-Template_00-00-01.docx|O:IVS-Glossar - Allgemeine Begriffe aus Verkehr, Transport und Mobilität]]

|
Projektspezifische Lösung

;IVS-Glossar - Allgemeine Begriffe aus Verkehr, Transport und Mobilität

*[[PhaseV-Step4-Los2|Verkehrsinformation Individualverkehr]]
*[[PhaseV-Step4-Los3|Zuständigkeitsübergreifendes Verkehrsmanagement]]
*[[PhaseV-Step4-Los4|Multimodale Reiseinformation]]

| Projektspezifische Lösung und IVS-Glossar
|- style="vertical-align:top;"
| 5
| Identifizierung und Festlegung von [http://pubs.opengroup.org/architecture/togaf91-doc/arch/chap06.html#tag_06_04_04 Architekturprinzipien]
| Identifizierung und Festlegung von IVS-Architekturprinzipien
| [[IVS-Architektur&Geschäftsprinzipien|'''IVS-Architektur-Prinzipien''']]
*[[IVS-Architekturprinzip|Template: Baustein IVS-Architekturprinzip]]

;Hintergrundinformationen und Techniken
:[[Katalog_IVS-Architekturprinzipien|Beispiele für Architekturprinzipien aus dem IKT-Bereich]]

|
*[[Media:IVS-Architekturprinzip-Katalog_00-00-01.docx|K: IVS-Architekturprinzipien]]

| IVS-Architekturprinzipien für die IVS-Dienstekategorie
*[[PhaseV-Step5-Los2|Verkehrsinformation Individualverkehr]]
*[[PhaseV-Step5-Los3|Zuständigkeitsübergreifendes Verkehrsmanagement]]
*[[PhaseV-Step5-Los4|Multimodale Reiseinformation]]

| IVS-Architekturprinzipien für den spezifischen IVS-Dienst
|- style="vertical-align:top;"
| 6
| Auswahl und organisationsspezifische Anpassung von [http://pubs.opengroup.org/architecture/togaf91-doc/arch/chap06.html#tag_06_04_05 Architekturframeworks]
| Auswahl und Anpassung von IVS-Architekturframeworks
| [[IVS-Archtektur-Vorgehensmodell|'''Anpassung des TOGAF-Architekturmodells für die Entwicklung von IVS-Architektur''']]
| ggfs. Projektspezifische Anpassung und Erweiterung
| ggfs. Projektspezifische Anpassung und Erweiterung
| ggfs. Projektspezifische Anpassung und Erweiterung
|- style="vertical-align:top;"
| 7
| Implementierung von [http://pubs.opengroup.org/architecture/togaf91-doc/arch/chap06.html#tag_06_04_06 Architekturwerkzeugen]
| Implementierung von IVS-Architekturwerkzeugen
| [[IVS-Architekturwerkzeuge|'''Vorschläge für IVS-Architekturwerkzeuge''']]
| Projektspezifische Lösung
| Projektspezifische Lösung
| Projektspezifische Lösung
|}

== Vorbereitungsphase für IVS-Architektur im Überblick ==

[[File:Vorbereitungsphase 00-00-07.png|thumb|left|400px|IVS-Architektur Vorbereitungsphase]]

----

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

TOGAF-Phase A

2018-06-21T10:00:34Z

Albrecht:

== Einführung in die "Phase A – Entwicklung einer Architekturvision" ==

In '''Phase A – Entwicklung einer Architekturvision''' geht es grundsätzlich darum, eine Vision für einen IVS-Dienst bzw. eine IVS-Dienstkategorie zu entwickeln und - auf einem hohen Niveau - einen ersten Aufschlag für die IVS-Architektur und ihre Architekturdomänen zu machen. Stakeholdern und Beteiligten soll anhand der Vision vermittelt werden, wie ihre strategischen und geschäftlichen Erwartungen berücksichtigt werden, wie diese in Form von geschäftlichen Zielen (engl. business goals) formuliert werden und mit welchen messbaren Zielen (engl. business objectives) ihre Zielerreichung am Ende bewertet werden kann.

Ein wichtiger Kern der Phase A ist es, den Zweck des Architekturansatzes zu klären (zu erklären), darüber unter allen Beteiligten Konsens zu erzielen und diesen in Form einer Vision zu formulieren.

Normalerweise sind Schlüsselelemente einer Architekturvision bereits Bestandteil einer weiter gefassten, z. B. politischen Strategie. Hier gilt es, die Vision so zu formulieren, dass ein Bezug zu dieser Strategie hergestellt wird und die Architekturvision darin eingeordnet werden kann. Beispiele für politische Strategien sind der '''europäische IVS-Aktionsplan''', die '''europäische IVS-Direktive''' und der '''[[Media:_C-ITS-Masterplan.pdf|Europäische C-ITS-Masterplan]]'''. Beispiele für nationale Strategien sind der '''IVS-Aktionsplan Straße''' sowie die '''Strategie automatisiertes und vernetztes Fahren''' der Bundesregierung.

'''Business-Szenarien''' stellen eine nützliche Technik dar, um strategische und geschäftliche Anforderungen zu identifizieren, zu dokumentieren und daraus eine Vision zu artikulieren, die diesen Anforderungen entspricht. Business-Szenarien stellen insofern eine gesonderte Methode innerhalb der TOGAF-ADM dar.

== Schritte der "Phase A - IVS-Architekturvision" ==

{| class="wikitable"
|-
! Schritt
! TOGAF
! Tailoring IVS-Rahmenarchitektur
! Anleitung
! Artefakte {K=Katalog, M=Matrix, D=Diagramm}, O=Other Deliverables
! Empfehlung für IVS-Referenzarchitekturen
! Empfehlung für IVS-Architekturen realer IVS-Dienste
|- style="vertical-align:top"
| 1
| Aufsetzen des [http://pubs.opengroup.org/architecture/togaf91-doc/arch/chap07.html#tag_07_04_01 Architekturprojekts]
| Aufsetzen des IVS-Architekturprojekts
| [[Aufsetzen_von_IVS-Architekturprojekten|'''Aufsetzen eines Architekturprojekts''']]
*[[IVS-Domäne-Template|Template: Other Deliverable IVS-Domäne]]
*[[IVS-Dienst-Template|Template: Other Deliverable IVS-Dienst]]

;'''Hintergrundinformationen und Techniken''' "IVS-Domäne"
:[[IVS-Dömänen|IVS-Domänen-Konzept]]
;Hintergrundinformationen und Techniken "IVS-Dienst"
:[[IVS-Dienste-Konzept|IVS-Dienste-Konzept]]
;'''Hintergrundinformationen und Techniken''' "IVS-Wertschöpfungskette"
:[[BusinessFootprintDiagramm_Los3-2|Beispiel Wertschöpfung im System Straße]]
:[[BusinessFootprintDiagramm_Los2|Beispiel Verkehrsinformation Individualverkehr]]
:[[BusinessFootprintDiagramm_Los3|Beispiel Zuständigkeitsübergreifendes Verkehrsmanagement]]
:[[BusinessFootprintDiagramm_Los4|Beispiel Multimodale Verkehrsinformation]]

|
Aufsetzen eines IVS-Architekturprojekts unter Nutzung von:

*[[Media:_IVS-Domäne-Template_00-00-01.docx|O:IVS-Domäne]]
*[[Media:_IVS-Dienst-Template_00-00-01.docx|O:IVS-Dienst]]

| Aufsetzen des IVS-Referenzarchitekturprojekts
*[[PhaseA-Step1-Los2|Verkehrsinformation Individualverkehr]]
*[[PhaseA-Step1-Los3|Zuständigkeitsübergreifendes Verkehrsmanagement]]
*[[Kap._1_Aufsetzen_des_Architekturprojekts|Multimodale Reiseinformation]]

| Aufsetzen des IVS-Architekturprojekts für einen realen IVS-Dienst
|- style="vertical-align:top"
| 2
| Identifizierung von [http://pubs.opengroup.org/architecture/togaf91-doc/arch/chap07.html#tag_07_04_02 Stakeholdern mit deren Anliegen und Geschäftsanforderungen]
| Identifizierung der IVS-Rollen mit deren Anliegen und Geschäftsanforderungen
| [[IVS-Rollenkonzept#Erfassung_und_Beschreibung_von_IVS-Rollen|'''Erfassung und Beschreibung von IVS-Rollen''']]
*[[IVS-RollenMap-Template|Template: IVS-Rollen-Map]]
*[[IVS-Rolle|Template: Baustein IVS-Rolle]]
*[[IVS-Anforderungen|Template: Baustein IVS-Anforderung]]
*[[BS_Template_Seite|Template: Business Szenario]]

;'''Hintergrundinformationen und Techniken'''
:[[IVS-Rollenkonzept|IVS-Rollenkonzept]]
:[[Business-Szenarien|Business-Szenarien als Technik zur Erhebung von Anforderungen, Stakeholdern, IVS-Rollen ...]]

|
*[[Media:_IVS-Rollen-Template-Katalog_00-00-06.xlsx|O:IVS-Rollen-Map]]
*[[Media:_IVS-Rollen-Template-Katalog_00-00-04.docx|K:IVS-Rollen]]
*[[Media:_IVS-Anforderung-Template-Katalog_00-00-01.docx|K:IVS-Anforderungen]]
*[[Media:_IVS-Business-Szenario-Template_00-00-04.docx|O:Business Szenarien]]

| IVS-Referenzarchitekturspezifische Erfassung und Beschreibung von IVS-Rollen
*[[PhaseA-Step2-Los2|Verkehrsinformation Individualverkehr]]
*[[PhaseA-Step2-Los3|Zuständigkeitsübergreifendes Verkehrsmanagement]]
*[[Kap._2_Identifizierung_der_Stakeholder|Multimodale Reiseinformation]]

| IVS-Dienstspezifische Erfassung und Beschreibung von IVS-Rollen
|- style="vertical-align:top"
| 3
| Bestätigung und Ausarbeitung von [http://pubs.opengroup.org/architecture/togaf91-doc/arch/chap07.html#tag_07_04_03 geschäftlichen Zielen, strategischen Einflussfaktoren und Rahmenbedingungen]
| Ausarbeitung von geschäftlichen Zielen, strategischen Einflussfaktoren und Rahmenbedingungen für IVS-Dienste
| '''[[IVS-Geschäftsziele|Geschäftliche Ziele, strategische Einflussfaktoren und Rahmenbedingungen für IVS]]'''
*[[IVS-Leitbild|Template: Baustein IVS-Leitbild]]
*[[IVS-Geschäftsziele-Template|Template: Baustein IVS-Geschäftsziele]]

'''Hintergrundinformationen und Techniken'''

:[[IVS-Leitbild_Verständnis|Was verstehen wir unter einem IVS-Leitbild]]
:[[Leitbild|Definition und Aufbau eines IVS-Leitbilds]]

|
*[[Media:_IVS-Leitbild-Template-Katalog_00-00-01.docx|K:IVS-Leitbilder]]
*[[Media:_IVS-Geschäftsziele-Template_00-00-01.docx|K:IVS-Geschäftsziele]]

| Ausarbeitung von geschäftlichen Zielen, strategischen Einflussfaktoren und Rahmenbedingungen für IVS-Dienste-Kategorien
*[[PhaseA-Step3-Los2|Verkehrsinformation Individualverkehr]]
*[[PhaseA-Step3-Los3|Zuständigkeitsübergreifendes Verkehrsmanagement]]
*[[Kap._3_Geschäftsziele_&_Geschäftstreiber|Multimodale Reiseinformation]]

| Ausarbeitung von geschäftlichen Zielen, strategischen Einflussfaktoren und Rahmenbedingungen für spezifische IVS-Dienste
|- style="vertical-align:top"
| 4
| Bewertung der [http://pubs.opengroup.org/architecture/togaf91-doc/arch/chap07.html#tag_07_04_04 Geschäftsfähigkeiten]
| Entwicklung/Bewertung der IVS-Capabilities von IVS-Rollen
| '''[[IVS-Capibilities|IVS-Capabilities von IVS-Rollen]]'''
*[[IVS-Capability-Template|Template: Baustein IVS-Capability]]

|
*[[Media:_IVS-Capability-Template-Katalog_00-00-01.docx|K:IVS-Capabilities]]

| IVS-Kategoriespezifische Entwicklung/Bewertung der IVS-Capabilities von IVS-Rollen
*[[PhaseA-Step4-Los2|Verkehrsinformation Individualverkehr]]
*[[PhaseA-Step4-Los3|Zuständigkeitsübergreifendes Verkehrsmanagement]]
*[[Kap._4_Bewertung_der_Geschäftsfähigkeiten|Multimodale Reiseinformation]]

| IVS-Dienstspezifische Entwicklung/Bewertung der IVS-Capabilities von IVS-Rollen
|- style="vertical-align:top"
| 5
| Bewertung der [http://pubs.opengroup.org/architecture/togaf91-doc/arch/chap07.html#tag_07_04_05 Reife für eine Transformation des Geschäfts]
| Bewertung der Reife für das Aufsetzen eines IVS-Dienstes
| Projektspezifische Anleitung (Schritt nicht IVS-spezifisch)
| Projektspezifische Lösung
|
Projektspezifische Lösung

*[[Kap._5_Transformation_des_Geschäfts|Multimodale Reiseinformation]]

| Projektspezifische Lösung
|- style="vertical-align:top"
| 6
| [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap07.html#tag_07_04_06 Reichweite der Architektur festlegen]
| Reichweite von Referenzarchitekturen und Architekturen realer Systeme
| '''[[Reichweite_der_Architektur|Reichweite der Architektur]]'''
| Projektspezifische Lösung
| Projektspezifische Lösung
*[[PhaseA-Step6-Los2|Verkehrsinformation Individualverkehr]]
*[[Kap._6_Definition_des_Wirkungsbereichs|Multimodale Reiseinformation]]

| Projektspezifische Lösung
|- style="vertical-align:top"
| 7
| Bestätigung und Ausarbeitung von [http://pubs.opengroup.org/architecture/togaf91-doc/arch/chap07.html#tag_07_04_07 Architekturprinzipien, einschließlich Geschäftsprinzipien]
| Überprüfung und ggf. Konkretisierung/Ergänzung der in der Vorbereitungsphase aufgestellten Architektur- und Geschäftsprinzipen
| Projektspezifische Anleitung
| Projektspezifische Lösung
|
Projektspezifische Lösung

*[[Kap._7_Architekturprinzipien_und_Geschäftsprinzipien|Multimodale Reiseinformation]]

| Projektspezifische Lösung
|- style="vertical-align:top"
| 8
| Entwicklung der [http://pubs.opengroup.org/architecture/togaf91-doc/arch/chap07.html#tag_07_04_08 Architekturvision]
| Entwicklung der IVS-Architekturvision
| '''[[IVS-Architekturvision|IVS-Architektur Vision]]'''
*[[IVS-Vision-Template|Template: Other Deliverable IVS-Architekturvision]]

|
*[[Media:_IVS-Architekturvision_Template.docx|O: IVS-Architekturvision]]

| Entwicklung der IVS-Architekturvision für die IVS-Kategorie
*[[PhaseA-Step8-Los2|Verkehrsinformation Individualverkehr]]
*[[PhaseA-Step8-Los3|Zuständigkeitsübergreifendes Verkehrsmanagement]]
*[[Kap._8_Entwicklung_der_Architekturvision|Multimodale Reiseinformation]]

| Entwicklung der IVS-Architekturvision für den spezifischen IVS-Dienst
|- style="vertical-align:top"
| 9
| Definition des [http://pubs.opengroup.org/architecture/togaf91-doc/arch/chap07.html#tag_07_04_09 Wertbeitrags der Zielarchitektur und der KPI's]
| Definition des Wertbeitrags und KPI's von IVS-Architektur
| '''[[Ziele_und_Nutzen|Wertbeitrag und KPI's von IVS-Architektur]]'''
*[[WertbeitragVonIVS-Architektur-Template|Template: Other Deliverable Wertbeitrag und KPI's von IVS-Architekturbausteinen]]

|
*[[Media:_IVS-KPIs-Template-Katalog_00-00-01.docx|O:Wertbeitrag und KPI's von IVS-Architekturbausteinen]]

| Definition des Wertbeitrags und KPI's von IVS-Architektur für die IVS-Dienstekategorie
*[[PhaseA-Step9-Los3|Zuständigkeitsübergreifendes Verkehrsmanagement]]
*[[Kap._9_Wertbeitrag_der_Zielarchitektur|Multimodale Reiseinformation]]

| Definition des Wertbeitrags und KPI's von IVS-Architektur für den spezifischen IVS-Dienst
|- style="vertical-align:top"
| 10
| Identifizierung der [http://pubs.opengroup.org/architecture/togaf91-doc/arch/chap07.html#tag_07_04_10 Risiken einer Geschäfts-Transformation und der Aktivitäten zur Risikominimierung]
| Identifizierung der Risiken der Umsetzung von IVS-Architektur und der Aktivitäten zur Risikominimierung
| '''[[Risiko-Management|Risikomanagement bei der Umsetzung von IVS-Architektur]]'''
*[[IVS-Risikomanagement-Template|Template: Baustein Risiko von IVS-Architektur]]

|
*[[Media:IVS-Risikomanagement-Template-00-00-02.docx|K:Risiken von IVS-Architektur]]

| Identifizierung der Risiken der Umsetzung von IVS-Architektur und der Aktivitäten zur Risikominimierung für die IVS-Dienstekategorie
*[[PhaseA-Step10-Los3|Zuständigkeitsübergreifendes Verkehrsmanagement]]
*[[Kap._10_Risiken_einer_Geschäftstransformation|Multimodale Reiseinformation]]

| Identifizierung der Risiken der Umsetzung von IVS-Architektur und der Aktivitäten zur Risikominimierung für den spezifischen IVS-Dienst
|- style="vertical-align:top"
| 11
| Entwicklung von [http://pubs.opengroup.org/architecture/togaf91-doc/arch/chap07.html#tag_07_04_11 Unternehmensarchitekturplänen und Aufträgen für die Architekturarbeit, Sichern der Zustimmung]
| Entwicklung von IVS-Architekturplänen und Aufträgen für die IVS-Architekturarbeit, Sichern der Zustimmung der Stakeholder
| Projektspezifische Anleitung (Schritt nicht IVS-spezifisch)
| Projektspezifische Lösung
|
Projektspezifische Lösung

*[[Kap._11_Entwicklung_von_Unternehmensarchitekturplänen|Multimodale Reiseinformation]]

| Projektspezifische Lösung
|}

== Schritte der Phase A - IVS-Architekturvision im Überblick ==

[[File:Phase-A 00-00-03.png|thumb|left|300px|Phase A - IVS-Architekturvision]]

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

IVS-Anforderungen

2018-05-29T07:05:11Z

Albrecht:

=== IVS-Anforderungen ===

*(engl. requirement) ist ein IVS-Architekturbaustein, mit dem ein Bedürfnis zum Ausdruck gebracht wird, der einem spezifischen IVS-Architekturmerkmal entsprochen werden muss.
*wird innerhalb aller Phasen zur Entwicklung einer IVS-Architektur identifiziert (Requirement Management).
*kann mit Hilfe der Business-Szenario-Technik ermittelt werden, die gleichzeitig der Identifikation und Dokumentation von IVS-Anforderungen dient.

=== Satzschablone für die Formulierung von IVS-Anforderungen ===

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 nicht nur die klare Syntax, sondern sie hilft außerdem dabei, übliche Fehler bei der Formulierung zu vermeiden.

=== Template als Tabelle ===

{| class="wikitable"
|+
|-
! Lfd. Nr
! Beschreibung
! Art der Anforderung
! Begründung
! Zugehörigkeit zu Phase(n) der IVS-Archtekturentwicklung
! Quelle
|- style="vertical-align:top"
|
|
|
|
|
|
|- style="vertical-align:top"
|
|
|
|
|
|
|- style="vertical-align:top"
|
|
|
|
|
|
|- style="vertical-align:top"
|
|
|
|
|
|
|}

=== Template als Word-Datei ===

[[Media:IVS-Anforderung-Template-Katalog_00-00-01_Neu.docx|IVS-Anforderung]]

----

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

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

2018-05-29T07:01:44Z

Albrecht:

IVS-Anforderungen

2018-05-29T07:01:05Z

Albrecht:

=== IVS-Anforderungen ===

*(engl. requirement) ist ein IVS-Architekturbaustein, mit dem ein Bedürfnis zum Ausdruck gebracht wird, der einem spezifischen IVS-Architekturmerkmal entsprochen werden muss.
*wird innerhalb aller Phasen zur Entwicklung einer IVS-Architektur identifiziert (Requirement Management).
*kann mit Hilfe der Business-Szenario-Technik ermittelt werden, die gleichzeitig der Identifikation und Dokumentation von IVS-Anforderungen dient.

=== Satzschablone für die Formulierung von IVS-Anforderungen ===

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 nicht nur die klare Syntax, sondern sie hilft außerdem dabei, übliche Fehler bei der Formulierung zu vermeiden.

=== Template als Tabelle ===

{| class="wikitable"
|+
|-
! Lfd. Nr
! Einordnung zu TOGAF-Phase(n)
! Beschreibung
! Art der Anforderung
! Quelle
|- style="vertical-align:top"
|
|
|
|
|
|- style="vertical-align:top"
|
|
|
|
|
|- style="vertical-align:top"
|
|
|
|
|
|- style="vertical-align:top"
|
|
|
|
|
|}

=== Template als Word-Datei ===

[[Media:IVS-Anforderung-Template-Katalog_00-00-01_Neu.docx|IVS-Anforderung]]

----

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

Datei:2018-05-08 Vorstellung RIAD.pdf

2018-05-09T11:29:55Z

Albrecht:

NavTree

2018-04-18T10:18:47Z

Albrecht:

{{#tree:id=1| extensions=["persist"] |
*Einleitung
**[[Aufgabenstellung_der_IVS-Rahmen-_und_-Referenzarchitekturen| Aufgabenstellung]]
**[[Aufbau_des_Wikis| Aufbau des Wikis]]
*IVS-Architektur - Grundlagen
**[[IVS-Architekturprinzipien | IVS-Architektur - Metamodelle und Architekturprinzipien]]
**[[IVS-Architektur - Schlüsselbegriffe | IVS-Architektur - Schlüsselbegriffe]]
*[[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]]
* Die IVS-Rahmenarchitektur 1.0
**[[IVS-Archtektur-Vorgehensmodell | Das TOGAF-basierte IVS-Architektur Vorgehensmodell]]
**[[IVS-Architekturbausteine | Die IVS-Architekturbausteine der IVS-Rahmenarchitektur 1.0 ]]
*[[IVS-Referenzarchitektur_Verkehrsinformation_Individualverkehr_1.0 | Die IVS-Referenzarchitektur Verkehrsinformation IV 1.0 ]]
*[[IVS-Referenzarchitektur_für_Zuständigkeitsübergreifendes_Verkehrsmanagement_1.0 | Die IVS-Referenzarchitektur zuständigkeitsübergreifendes VM 1.0 ]]
*[[IVS-Referenzarchitektur Multimodale Reiseinformation 1.0 | Die 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]]
*[[Schlussberichte]]
}}

NavTree

2018-04-18T10:16:43Z

Albrecht:

{{#tree:id=1| extensions=["persist"] |
*Einleitung
**[[Aufgabenstellung_der_IVS-Rahmen-_und_-Referenzarchitekturen| Aufgabenstellung]]
**[[Aufbau_des_Wikis| Aufbau des Wikis]]
*IVS-Architektur - Definitionen und Metamodelle
**[[IVS-Architekturprinzipien | IVS-Architektur - Metamodelle und Architekturprinzipien]]
**[[IVS-Architektur - Schlüsselbegriffe | IVS-Architektur - Schlüsselbegriffe]]
*[[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]]
* Die IVS-Rahmenarchitektur 1.0
**[[IVS-Archtektur-Vorgehensmodell | Das TOGAF-basierte IVS-Architektur Vorgehensmodell]]
**[[IVS-Architekturbausteine | Die IVS-Architekturbausteine der IVS-Rahmenarchitektur 1.0 ]]
*[[IVS-Referenzarchitektur_Verkehrsinformation_Individualverkehr_1.0 | Die IVS-Referenzarchitektur Verkehrsinformation IV 1.0 ]]
*[[IVS-Referenzarchitektur_für_Zuständigkeitsübergreifendes_Verkehrsmanagement_1.0 | Die IVS-Referenzarchitektur zuständigkeitsübergreifendes VM 1.0 ]]
*[[IVS-Referenzarchitektur Multimodale Reiseinformation 1.0 | Die 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]]
*[[Schlussberichte]]
}}

NavTree

2018-04-18T10:15:27Z

Albrecht:

{{#tree:id=1| extensions=["persist"] |
*Einleitung
**[[Aufgabenstellung_der_IVS-Rahmen-_und_-Referenzarchitekturen| Aufgabenstellung]]
**[[Aufbau_des_Wikis| Aufbau des Wikis]]
*IVS-Architektur - Definitionen und Metamodelle
**[[IVS-Architekturprinzipien | IVS-Architektur - Metamodelle und Architekturprinzipien]]
**[[IVS-Architektur - Schlüsselbegriffe | IVS-Architektur - Schlüsselbegriffe]]
*[[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]]
* Die IVS-Rahmenarchitektur 1.0
**[[IVS-Archtektur-Vorgehensmodell | Das TOGAF-basierte IVS-Architektur Vorgehensmodell]]
**[[IVS-Architekturbausteine | Die IVS-Architekturbausteine der IVS-Rahmenarchitektur 1.0 ]]
* Die 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]]
*[[Schlussberichte]]
}}

NavTree

2018-04-18T10:13:56Z

Albrecht:

{{#tree:id=1| extensions=["persist"] |
*Einleitung
**[[Aufgabenstellung_der_IVS-Rahmen-_und_-Referenzarchitekturen| Aufgabenstellung]]
**[[Aufbau_des_Wikis| Aufbau des Wikis]]
*IVS-Architektur - Definitionen und Metamodelle
**[[IVS-Architekturprinzipien | IVS-Architektur - Metamodelle und Architekturprinzipien]]
**[[IVS-Architektur - Schlüsselbegriffe | IVS-Architektur - Schlüsselbegriffe]]
*[[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-Architektur 1.0]]
** Die IVS-Rahmenarchitektur 1.0
***[[IVS-Archtektur-Vorgehensmodell | Das TOGAF-basierte IVS-Architektur Vorgehensmodell]]
***[[IVS-Architekturbausteine | Die IVS-Architekturbausteine der IVS-Rahmenarchitektur 1.0 ]]
** Die 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]]
*[[Schlussberichte]]
}}

IVS-Architekturbausteine

2018-04-17T09:17:51Z

Albrecht:

== Vorbereitung der IVS-Architekturarbeit ==

=== [[IVS-Glossar|IVS-Glossar...]] ===

*ist ein '''IVS-Architekturdeliverable (siehe [[IVS-Glossar|IVS-Glossar)]]''', mit dem die '''Grundlage für gemeinsames Verstehen''' in einem IVS-Architekturprojekt gelegt wird.
*hat die zwei Bestandteile
**'''IVS-Architekturbausteine - IVS-Begriffe & Definitionen''', über das das Verständnis von IVS-Architektur hergestellt werden soll und das die IVS-Architekturbausteine als eigentliches Ergebnis der IVS-Rahmenarchitektur umfasst sowie
**'''Allgemeine Begriffe aus Verkehr, Transport und Mobilität''', die keine spezifische IVS-Architektur-Semantik repräsentieren.

=== [[IVS-Architektur&Geschäftsprinzipien#Architekturprinzipien|IVS-Architekturprinzip...]] ===

*ist ein '''IVS-Architekturdeliverable (siehe [[IVS-Architekturprinzip|IVS-Architekturprinzipien]]),''' mit dem '''verbindliche Grundsätze''' und auch '''Orientierungshilfen''' zur Erstellung einer IVS-Architektur aufgestellt werden.
*ist '''Bestandteil der Architekturplanung''' und kann für '''alle IVS-Architekturdomänen''' (Ebenen der IVS-Pyramide) ausgearbeitet werden.

== Abgrenzung des IVS-Gegenstandes der architektuerellen Betrachtung ==

[[File:IVS Gegenstand Abgrenzung.jpg|thumb|right|500px|Abgrenzung des IVS-Gegenstandes der architektuerellen Betrachtung - Modell]]

=== [[IVS-Dömänen|IVS-Domäne...]] ===

*ist ein '''IVS-Architekturdeliverable (siehe [[IVS-Domäne-Template|IVS-Domäne]])''', mit dem die äußerst umfangreiche und komplexe Anwendungsvielfalt von IVS-Diensten in spezifische Anwendungsfelder, in dem spezifisches Wissen zum Thema IVS (Domänen-Wissen) angewendet wird, und Anwendungssichten unterteilt wird. Im Fall von IVS-Architektur wird Architekturwissen zum IVS-Betrachtungsgegenstand angewendet.
*wird zu Beginn eines IVS-Architekturprojekts definiert und festgelegt, um den '''Betrachtungsgegenstand und die Betrachtungsweise/den Betrachtungsfokus''' des Projekts und seine '''räumliche sowie zeitliche Dimension''' überschaubar zu machen und von weiteren ähnlichen bzw. angrenzenden Betrachtungsgegenständen und Betrachtungsweisen abgrenzen zu können.

=== [[Reichweite_der_Architektur|Reichweite der IVS-Architektur...]] ===

*legt fest, wie '''weitreichend''' die Ist-Architektur und die Ziel-Architektur '''beschrieben werden sollen'''.
*hat zwei Dimensionen: '''Breite''' und '''Tiefe'''.
*wird für IVS-Referenzarchitekturen und die IVS-Architekturen realer IVS-Dienste '''spezifisch''' festgelegt.

== Begriffe, Bausteine und Deliverables Phase A - IVS-Architekturvision ==

=== IVS-Dienst und IVS-Dienstekategorie ===

[[File:IVS-Dienst.jpg|thumb|right|500px|IVS-Dienstekategorie und realer IVS-Dienst - Modell]]

==== [[IVS-Geschäftsziele|IVS-Leitbild...]] ====

*ist ein '''IVS-Architekturbaustein (siehe [[IVS-Leitbild|IVS-Leitbild]])''', der als "Aushängeschild" nach außen einen angestrebten Zielzustand (Idealbild) in Bezug auf den IVS-Betrachtungsgegenstand (IVS-Dienst oder IVS-Dienstekategorie) formuliert.
*vermittelt der Außenwelt und dem IVS-End-Nutzer das Selbstverständnis und die Grundprinzipien einer Organisation/Interessensgemeinschaft und den auf den IVS-Betrachtungsgegenstand bezogenen Wertekonsens sowie IVS-Nutzen.

==== [[IVS-Dienste-Konzept#IVS-Dienst|Realer IVS-Dienst...]] ====

*ist ein '''IVS-Architekturdeliverable''' (siehe [[IVS-Dienst-Template|'''IVS-Dienst''']]), mit dem eine auf '''IVS-End-Nutzer''' abzielende geschäftliche und wertschöpfende Leistung von '''IVS-Akteuren''' im Bereich von '''Verkehr, Transport und Mobilität''' bezeichnet wird, die [[IVS-Dienste-Konzept#IVS-Wertsch.C3.B6pfung|'''IVS-Wertschöpfung''']] betreiben , indem sie mittels Einsatz einer Kombination von Menschen, Organisation, Prozessen und Technologie (IVS-Kosten) alleine oder in Zusammenarbeit mit weiteren IVS-Akteuren einen IVS-Mehrwert schaffen.

*schafft einen IVS-Mehrwert, der aus folgenden Bestandteilen bestehen kann:
**einem individuellen, also für einzelne IVS-End-Nutzer personalisierten '''IVS-Nutzen''', für den diese - direkt oder indirekt - bereit sind zu bezahlen ('''Nutzerfinanzierung des IVS-Dienstes''') oder
**einer kollektiven, also für IVS-End-Nutzerkollektive zugeschnittenen '''IVS-Wirkung''', für die die öffentliche Hand als Vertreter von Politik und Gesellschaft bereit ist Steuermittel oder Gebühren einzusetzen ('''Steuer- bzw. Gebührenfinanzierung des IVS-Dienstes''') oder
**aus einer Mischung von beidem, wenn öffentliche und private IVS-Akteure im Rahmen der Wertschöpfung zusammenarbeiten.

==== IVS-Dienstekategorie... ====

*ist '''Gegenstand der Entwicklung von IVS-Referenzarchitekturen''' und insofern der Bezeichner für eine '''den Architekturstil prägende Referenz für IVS-Dienste''', die im Sinne von IVS-Architektur und in Bezug auf den architekturellen Fokus mit '''gleichen/gleichartigen IVS-Architekturmerkmalen''' ausgestattet sind.
*überträgt und konkretisiert die von der IVS-Rahmenarchitektur vorgegebenen Gestaltungsebenen und Gestaltungsobjekte auf den '''Gestaltungsraum einer spezifischen, mit einem Bezeichner benannten IVS-Dienstefamilie''', sodass sie aus fachlicher Sicht gemeinsamen Bedingungen entsprechen.

==== IVS-Nutzen... ====

*entsteht, wenn IVS-End-Nutzer im Rahmen von Anwendungsprozessen über leicht zugängliche IVS-Dienst-Zugangspunkte (im einfachsten Fall von z. B. einer Privatperson mit ihrem Smartphone) Zugriff auf IVS-Informationen erhalten, um '''eigene IVS-Entscheidungen sicher, zuverlässig, schnell und effektiv''' treffen zu können.

==== IVS-Wirkung... ====

*entsteht, wenn IVS-End-Nutzer im Rahmen von Anwendungsprozessen über leicht zugängliche IVS-Dienst-Zugangspunkte (im einfachsten Fall von z. B. einer Privatperson mit ihrem Smartphone) Zugriff auf IVS-Informationen erhalten und daraufhin ihr '''Verhalten im Sinne der Ziele der Betreiber von IVS-Diensten ausrichten'''.

=== Mechanismus der IVS-Wertschöpfung ===

[[File:IVS-Wertschöpfungsnetzwerk.jpg|thumb|right|500px|IVS-Wertschöpfungskette/IVS-Wertschöpfungsnetzwerk - Modell]]

==== [[IVS-Geschäftsziele|IVS-Geschäftsziel...]] ====

*ist ein '''IVS-Architekturbaustein (siehe [[IVS-Geschäftsziele-Template|IVS-Geschäftsziele]])''', der den mit einem IVS-Dienst verbundenen wirtschaftlichen Mehrwert für eine Institution/ein Unternehmen als Zielvorstellung formuliert.

==== [[IVS-Dienste-Konzept#IVS-Wertsch.C3.B6pfungsketten_und_-netzwerke|IVS-Wertschöpfungsketten/IVS-Wertschöpfungsnetzwerke...]] ====

*resultieren aus der '''organisationsübergreifenden Vernetzung und Zusammenarbeit von eine oder mehrere IVS-Rollen einnehmenden IVS-Akteuren''', die gemeinsam das Ziel haben, einen IVS-Dienst anzubieten, zu realisieren und zu betreiben.
*müssen als Prozessketten für '''IVS-Informationslogistik''', das heißt der Organisation, Steuerung, Bereitstellung und Optimierung von IVS-relevanten Informationsströmen, interpretiert werden, die als zentraler Dreh- und Angelpunkt zur '''Erschließung und Schöpfung des Nutzenpotentials von IVS''' die eigentliche Herausforderung für die IVS-Akteure als Bestandteil von IVS-Wertschöpfungsketten/-netzwerken darstellt.

==== [[IVS-Rollenkonzept#IVS-Akteure_als_Instanzen_von_Rollen|IVS-Akteur...]] ====

*ist '''Bestandteil einer IVS-Wertschöpfungskette/eines IVS-Wertschöpfungsnetzwerks''' und als solcher direkt '''an der Wertschöpfung beteiligt'''.
*leistet seinen Wertschöpfungsbeitrag zum IVS-Nutzen, indem er seine IVS-Capabilities im Rahmen seiner IVS-Aktivitäten als Bestandteil des IVS-(Wertschöpfungs)Geschäftsprozesses einbringt und einsetzt.
*'''vertritt in der Regel auch Interessen von IVS-Stakeholdern''', die selbst nicht unmittelbar an der IVS-Wertschöpfungskette/am IVS-Wertschöpfungsnetzwerk beteiligt sind, die aber starke Interessen damit verbinden.
*umfasst als Begriff auch den '''IVS-End-Nutzer''' als speziellen IVS-Akteur.

==== [[IVS-Dienste-Konzept#IVS-End-Nutzer|IVS-End-Nutzer...]] ====

*sind im Normalfall '''Verkehrsteilnehmer und Reisende''', die IVS-Dienste für die Vorbereitung oder Durchführung einer Fahrt oder einer Reise von A nach B nutzen.

*sind im Falle von C-ITS und automatisiertem Fahren als Fahrerassistenzsysteme bezeichnete IVS-End-Nutzer Systeme, die Verkehrsteilnehmer und Reisende in der Vorbereitung oder Durchführung einer Fahrt oder einer Reise von A nach B unterstützen.

*sind aber auch '''IVS-Akteure''', die selbst IVS-Dienste anbieten oder daran beteiligt sind und dabei die Dienste anderer IVS-Akteure nutzen, um ihre eigenen geschäftlichen IVS-Leistungen zu unterstützen oder zu verbessern.

==== [[IVS-Rollenkonzept#Das_IVS-Rollen-Map_Template|IVS-Rollen Map...]] ====

*ist ein '''IVS-Architekturdeliverable (siehe [[IVS-RollenMap-Template|IVS-Rollen Map]])''', das die Stereotype von IVS-Akteuren und IVS-Stakeholdern deklariert und mit ihren Geschäftsanliegen und IVS-Rollen beschreibt.
*'''klassifiziert die Bedeutung von IVS-Akteuren und IVS-Stakeholdern''', welche sie über ihre Rolle für den IVS-Dienst bzw. die IVS-Dienste-Kategorie erlangen (Power-Grid).

==== [[IVS-Rollenkonzept#IVS-Rolle|IVS-Rolle...]] ====

[[File:IVS-Rollenkonzept.jpg|thumb|right|500px|IVS-Rollenkonzept als UML-Diagramm]]

*ist ein '''IVS-Architekturbaustein (siehe [[IVS-Rolle|IVS-Rolle]])''', mit dem Stereotype von IVS-Fähigkeiten, IVS-Verantwortlichkeiten und IVS-Aufgaben, die für die Wertschöpfung mit Hilfe von IVS-Diensten typisch und erforderlich sind, bezeichnet und semantisch beschrieben werden.
*ist ein '''signifikanter Bestandteil von IVS-Wertschöpfungsketten für IVS-Informationslogistik''', der von '''IVS-Akteuren und IVS-Stakeholdern''' je nach Erfordernis des zu realisierenden IVS-Dienstes eingenommen wird, wobei ein einzelner IVS-Akteur oder IVS-Stakeholder eine oder mehrere IVS-Rollen besetzen kann.
*'''operationalisiert''' ihre IVS-Fähigkeiten, IVS-Verantwortlichkeiten und Aufgaben in Form von '''Aktivitäten''', die mit den Aktivitäten anderer IVS-Rollen den '''IVS-Geschäftsprozess''' eines IVS-Dienstes bildet.
*wird in '''IVS-Referenzarchitekturen von Stereotypen von IVS-Akteuren''', in '''IVS-Architekturen realer IVS-Dienste von konkreten Instanzen von Stereotypen von IVS-Akteuren''' eingenommen.

==== [[IVS-Capibilities|IVS-Capability...]] ====

*ist ein '''IVS-Architekturbaustein (siehe [[IVS-Capability-Template|IVS-Capability]])''', der eine '''Fähigkeit''' repräsentiert, die eine '''IVS-Rolle 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.
*ist als '''Business Capability (Geschäfts-Fähigkeit)''' von strategischer Bedeutung für jedes Unternehmen, weil sie eine Eigenschaft kennzeichnet, die für eine Institution/ein Unternehmen unbedingt erforderlich ist, damit es ihre/seine strategischen Ziele erreichen kann.

=== Business-Szenarien zur Erfassung von Anforderungen ===

[[File:IVS-Anforderung.jpg|thumb|right|500px|IVS-Business-Szenario - Modell]]

==== [[IVS-Anforderungen|IVS-Anforderung...]] ====

*(engl. requirement) ist ein '''IVS-Architekturbaustein (siehe [[IVS-Anforderungen|IVS-Anforderung]]), mit dem ein Bedürfnis zum Ausdruck gebracht wird, der einem spezifischen IVS-Architekturmerkmal entsprochen werden muss.'''
*wird innerhalb aller Phasen zur Entwicklung einer IVS-Architektur identifiziert (Requirements Management).
*kann mit Hilfe der Business-Szenario-Technik ermittelt werden, die gleichzeitig der Identifikation und Dokumentation von IVS-Anforderungen dient.

==== [[Business-Szenarien|IVS-Business Szenario...]] ====

*ist ein '''IVS-Architekturdeliverable''' (siehe [[Media:IVS-Business-Szenario-Template_00-00-03.docx|IVS-Business-Szenario]]'''), das der Identifikation von '''IVS-Anforderungen''',''' z. B. in Bezug auf Stakeholder, IVS-Rollen, IVS-Akteure oder die IVS-Architekturvision'''dient.'''
*identifiziert ein '''größeres Problem und beschreibt seine Lösung''' umfassend, unter Beachtung, dass die Beschreibung aus der Sicht der Anforderungen erfolgt und noch nicht konkret auf Lösungen eingeht.
*beschreibt in Phase A ein umfängliches '''End-to-End-Szenario''', dessen Beschreibung in der Phase B vertieft wird.

=== Ziele, Nutzen und Risiken von IVS-Architektur ===

==== [[IVS-Architekturvision|IVS-Architekturvision...]] ====

*ist ein '''IVS-Architekturbaustein (siehe [[IVS-Vision-Template|IVS-Architekturvision]])''', mit dem eine '''erste "high-level" Fassung der IVS-Architektur''' für eine IVS-Dienstekategorie bzw. einen spezifischen IVS-Dienst erarbeitet wird.
*'''konzentriert sich''' typischerweise - auf einem hohen Niveau - mehr '''auf die Breite der Anforderungen''' und weniger auf ihre Tiefe (siehe auch Phase A - Architekturvision, Schritt 6).

==== [[Ziele_und_Nutzen|Wertbeitrag und KPI's von IVS-Architektur...]] ====

*ist ein '''IVS-Architekturdeliverable (siehe [[WertbeitragVonIVS-Architektur-Template|Wertbeitrag und KPI's von IVS-Architektur]])''', mit dem der für IVS-End-Nutzer, IVS-Akteure und Stakeholder intendierte '''Nutzen von IVS-Architekturbausteinen und -Deliverables''' nachvollziehbar '''bewertet werden kann'''.
*liefert '''Schlüsselkennzahlen (KPI's für IVS-Architektur) und Messverfahren''', mit denen der Nutzen von IVS-Architektur gemessen und nachgewiesen werden kann.

==== [[Risiko-Management|Risiko von IVS-Architektur...]] ====

*ist ein '''IVS-Architekturbaustein (siehe [[IVS-Risikomanagement-Template|Risiko von IVS-Architektur]])''', mit dem Risiken '''vor und nach der Umsetzung von IVS-Architektur''' identifiziert und in Bezug auf '''Eintrittswahrscheinlichkeit und Schwere''' bewertet werden.
*legt die Schritte für Identifikation und Bewertung fest und '''identifiziert mögliche Gegenmaßnahmen''' für kritische Risiken ('''Risikomanagement''').

== Begriffe, Bausteine und Deliverables Phase B - IVS-Geschäftsarchitektur ==

=== [[TOGAF-Phase_B|IVS-Geschäftsarchitektur...]] ===

*'''konkretisiert und operationalisiert die Geschäftsstrategie (Ziele und Nutzen)''' einer IVS-Wertschöpfungskette/eines IVS-Wertschöpfungsnetzwerks.
*entwickelt '''Sichten auf das Geschäft (Business)''' einer/eines IVS-Wertschöpfungskette/IVS-Wertschöpfungsnetzwerkes in Bezug auf '''Aufbau (IVS-Rollenmatrix), Führung und Steuerung (IVS-Governance) sowie ''''''Aktivitäten' '''''der IVS-Akteure (IVS-Geschäftsprozess)''' und leitet daraus Anforderungen ab.

=== [[Aufbau_von_IVS-Wertschöfungsketten_und_-netzwerke|Die IVS-Rollenmatrix...]] ===

*ist ein '''Architekturdeliverable''', das als praktisches Instrument für die Entwicklung und Visualisierung des '''Aufbaus von IVS-Wertschöpfungsketten und -netzwerken''' verwendet werden kann.
*wurde im Projekt "[[Media:ÖV-IVS_Schlussbericht_März_2014.pdf|Entwicklung einer ÖV-IVS-Rahmenarchitektur in Deutschland unter Einbindung Europäischer IVS-Richtlinien mit ÖV-Relevanz]]" entwickelt und erlaubt neben der Ausgestaltung von IVS-Wertschöpfungsketten und -netzwerken die '''Einordnung von IVS-Akteuren über eine Rolle'''.

=== [[IVS-Governance|IVS-Governance...]] ===

*ist ein '''Architekturdeliverable''', über das beschrieben und vermittelt wird, auf welcher '''gesetzlichen, rechtlichen und vertraglichen Grundlage''' ein IVS-Dienst aufbaut und wie die Zusammenarbeit von IVS-Akteuren durchzuführen ist.
*vermittelt Anforderungen, wie ein IVS-Dienst zustande kommt und welche Anforderungen es für dessen Führung und Steuerung (Governance) gibt.

=== [[Geschäftsprozesse|IVS-Geschäftsprozess...]] ===

[[File:IVS-Geschäftsprozess.jpg|thumb|right|500px|IVS-Geschäftsprozess - Modell]]

*ist ein '''IVS-Architekturbaustein (siehe [[IVS-Geschäftsprozess|IVS-Geschäftsprozess]])''', mit dem (auf den verschiedenen Handlungsfeldern einer Wertschöpfungskette/eines Wertschöpfungsnetzwerks) die '''Aktivitäten von IVS-Rollen''' beschrieben und verknüpft werden, die in Summe einen '''IVS-Dienst implementieren/operationalisieren'''.
*'''ordnet einzelne Aktivitäten''' vordefinierten Rollen zu, die die zur Durchführung einer Aktivität erforderlichen '''IVS-Capabilities''' repräsentieren.
*verwendet '''IVS-Informationsobjekte''' zum Informationsaustausch zwischen den Aktivitäten der IVS-Rollen und '''IVS-Anwendungen (IT-Dienste) mit Schnittstellen''', über die IVS-Rollen auf die Informationsobjekte zugreifen können.

=== [[Roadmap|IVS-Architektur Roadmap...]] ===

*enthält eine '''zeitliche Planung''' der '''Änderungen''', die benötigt wird, um die Ziel-Architektur zu erreichen.
*beschreibt '''Abhängigkeiten''' zwischen den Änderungen.
*wird sukzessive in den Architekturentwicklungsphasen B-D erstellt.

== Begriffe, Bausteine und Deliverables Phase C.1 - IVS-Datenarchitektur ==

=== [[IVS-Referenzmodelle_und_Werkzeuge_-_Datenarchitektur|IVS-Datenarchitektur ...]] ===

[[File:IVS-Informationsobjekt.jpg|thumb|right|500px|IVS-Informationsobjekt - Modell]]

*beschreibt die '''Informationen''', die in '''IVS-Geschäftsprozessen''' verwendet und generiert werden
*enthält die Architekturbausteine '''IVS-Informationsobjekt''', '''IVS-Datenmodell''' und '''IVS-Ortsreferenzierung'''

=== [[Ausgangssituation_der_IVS-Datenarchitektur#IVS-Informationsobjekte|IVS-Informationsobjekt ...]] ===

*ist ein '''IVS-Architekturbaustein (siehe [[IVS-Informationsobjekt|IVS-Informationsobjekt]])''', der die '''semantische Bedeutung '''inhaltlich zusammengehöriger Informationen beschreibt.
*wird als Input bzw. Output in '''IVS-Geschäftsprozessen''' verwendet.
*werden in '''IVS-Datenmodellen''' beschrieben und verwendet.

=== [[Ausgangssituation_der_IVS-Datenarchitektur#IVS-Datenmodelle|IVS-Datenmodell...]] ===

*ist ein '''IVS-Architekturbaustein (siehe [[IVS-Datenmodell|IVS-Datenmodell]])''', der '''IVS-Informationsobjekte''' enthält und '''IVS-Referenzierungen''' zur Beschreibung von Orten verwendet.
*wird in einer '''IVS-Domäne''' entwickelt und ist historisch gewachsen.
*wird in '''IVS-Schnittstellen''' verwendet.

=== [[Ausgangssituation_der_IVS-Datenarchitektur#IVS-Ortsreferenzierungssysteme|IVS-Ortsreferenzierung...]] ===

*ist ein '''IVS-Architekturbaustein (siehe [[IVS-Ortsreferenzierung|IVS-Ortsreferenzierung]])''', der verwendet wird, um '''geographische Orte''' zu beschreiben.
*wird in verschiedenen (nicht nur IVS-) '''Domänen''' entwickelt und ist historisch gewachsen.
*wird in '''Datenmodellen''' verwendet, um den Ort, an dem oder für den eine Information gilt, zu beschreiben.
*kann teilweise und oft nur ''verlustbehaftet'' in andere Ortsreferenzierungen umgerechnet werden.

== Begriffe, Bausteine und Deliverables Phase C.2 - IVS-Anwendungsarchitektur ==

=== [[IVS-Referenzmodelle_und_Werkzeuge_-_Anwendungsarchitektur|IVS-Anwendungsarchitektur...]] ===

*beschreibt '''IVS-Anwendungen''', die benötigt werden, um '''IVS-Dienste''' zu realisieren.
*beschreibt '''IVS-Schnittstellen''', die von '''IVS-Anwendungen''' verwendet werden, um Informationen auszutauschen.

=== [[Anleitung_zur_IVS-Anwendungsarchitektur|IVS-Anwendung...]] ===

*ist ein '''IVS-Architekturbaustein (siehe [[IVS-Anwendung|IVS-Anwendung]])''' und besteht aus einem Computerprogramm oder einem '''System von Computerprogrammen''', mit dem nützliche Funktionen automatisiert oder computergestützt realisiert werden.
*kann in einer '''serviceorientierten Architektur''' realisiert sein.
*benutzt '''IVS-Schnittstellen''' zur Kommunikation mit anderen IVS-Anwendungen.
*realisiert '''technische Aktivitäten''' in einem IVS-Geschäftsprozess.
*unterstützt '''menschliche Aktivitäten''' in einem IVS-Geschäftsprozess.

=== [[Anweisungen_zur_IVS-Anwendungsarchitektur#IVS-Schnittstellen|IVS-Schnittstelle...]] ===

*ist ein '''IVS-Architekturbaustein (siehe [[IVS-Schnittstelle|IVS-Schnittstelle]])''', dient zum Austausch von '''Informationen''' zwischen Systemen.
*entspricht einer '''Schnittstellenspezifikation''', die aus der Festlegung eines '''Protokolls''' und eines '''Datenmodells''' besteht.
*wird von '''IVS-Anwendungen''' verwendet und durch diese realisiert.

----

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

IVS-Architekturbausteine

2018-04-17T09:17:06Z

Albrecht:

IVS-Architekturprinzipien

2018-04-17T09:03:45Z

Albrecht:

In den folgenden Unterkapiteln werden die wichtigsten Begriffe definiert und Metamodelle vor-gestellt, die zum Verständnis der IVS-Rahmenarchitektur benötigt werden.

== Intelligente Verkehrs-Systeme - Definition ==

*verstehen sich als '''intelligente Anwendungen im Bereich von Transport, Verkehr und Mobilität,''' die vom IVS-End-Nutzer als [[IVS-Dienste-Konzept#IVS-Dienst|IVS-Dienst (engl. ITS service)]] genutzt werden können.
*betreiben IVS-Weretschöpfung, indem sie IVS-End-Nutzer mit umfassenderen Informationen in die Lage versetzen, Verkehrsnetze auf sicherere, koordiniertere und "klügere" Weise zu nutzen (siehe [[Media:_2011_its_initial_report_germany.pdf|Status und Rahmenbedingungen für Intelligente Verkehrssysteme (IVS) in Deutschland 2010]] [[Media:_2011_its_initial_report_germany.pdf|<ref> Bericht gemäß Artikel 17(1) der Richtlinie 2010/40/EU des Europäischen Parlaments und des Rates vom 7. Juli 2010 zum Rahmen für die Einführung intelligenter Verkehrssysteme im Straßenverkehr und für deren Schnittstellen zu anderen Verkehrsträgern (2010). Deutschland. Online verfügbar unter http://ec.europa.eu/transport/themes/its/road/action_plan/doc/2011_its_initial_report_germany.pdf, zuletzt geprüft am 24.10.2017</ref>]]).
*setzen Informations- und Kommunikationstechnologien (IKT) im Straßenverkehr und an den Schnittstellen zu anderen Verkehrsträgern ein, mit deren Hilfe '''verkehrsbezogene Daten und Informationen erfasst, übermittelt, verarbeitet und ausgetauscht werden '''können (siehe [[Media:Ivs.pdf|IVS-Gesetz<ref>Das Bundesministerium der Justiz und für Verbraucherschutz in Zusammenarbeit mit der juris GmbH (2013): Gesetz über Intelligente Verkehrssysteme im Straßenverkehr und deren Schnittstellen zu anderen Verkehrsträgern. Intelligente Verkehrssysteme Gesetz - IVSG. Online verfügbar unter https://www.gesetze-im-internet.de/ivsg/IVSG.pdf, zuletzt geprüft am 18.10.2017.</ref>]]).
*dürfen über ihren Wortanteil '''Intelligenz''' nicht im Sinne künstlicher Intelligenz (KI), sondern müssen im Sinne von '''Business Intelligence''' verstanden werden. Dabei ist '''Intelligenz''' ist ein '''Synonym für Informationen und Erkenntnisse, die durch das Sammeln und Auswerten von Daten und Informationen''' mit dem Ziel '''gewonnen''' werden, dem End-Nutzer von IVS im Hinblick auf seine Ziele '''bessere strategische und/oder operative Entscheidungen''' zu ermöglichen bzw. aus Betreibersicht auf End-Nutzer von IVS eine besondere Wirkung derart auszuüben, dass diese '''ihr Verhalten auf die Ziele des Betreibers ausrichten'''.

== IVS-Architektur - Architektur Intelligenter Verkehrs-Systeme ==

IVS-Architektur befasst sich grundsätzlich neben der funktionalen, technischen und wirtschaftlichen Realisierung vor allem mit der '''gestalterischen Planung von IVS und IVS-Diensten'''. Dabei orientiert sich IVS-Architektur an '''übergeordneten Leitbildern und Zielvorstellungen''' des „Bauherrn“.

Insofern liegt die Kernkompetenz eines IVS-Architekten über das Wissen um Realisierung von IVS und IVS-Diensten hinaus vor allem in der '''Schaffung von IVS-Architektur''' mittels '''Vorschlagen und Ausprägen von IVS-Architekturmerkmalen''', die den Leitbildern und Zielvorstellungen des Bauherrn entsprechen oder er entwickelt dazu eigene Vorstellungen.

== Die IVS-Architektur-Pyramide ==

Als geeignetes Metamodell und methodisches Hilfsmittel zur überschaubaren und nachvollziehbaren Darstellung und Beschreibung von IVS-Diensten wird dem IVS-Architekten vom Arbeitskreis "ITS Systemarchitekturen“ der Forschungsgesellschaft für Straßen- und Verkehrswesen (FGSV) die beschriebene und begründete „IVS-Pyramide“ vorgeschlagen (siehe [[Media:W1-Papier_AK_3_1_4_v2_1.pdf|Hinweise zur Strukturierung einer Rahmenarchitektur für Intelligente Verkehrssysteme (IVS) in Deutschland – Notwendigkeit und Methodik, FGSV-Nr. 305 ]]<ref>Rittershaus, Lutz; Aicher, Peter; Albrecht, Hanfried u.a. (2012): Hinweise zur Strukturierung einer Rahmenarchitektur für Intelligente Verkehrssysteme (IVS) in Deutschland – Notwendigkeit und Methodik. Hg. v. FGSV. FGSV. Köln (Nr. 305). Online verfügbar unter https://trid.trb.org/view.aspx?id=1141880, zuletzt geprüft am 24.10.2017.</ref>).

[[File:IVS-Pyramide.png|thumb|right|250px|Die IVS-Architektur-Pyramide mit 5 Ebenen]]

'''Die IVS-Architektur-Pyramide'''

*besteht aus fünf Schichten, die zusammen den potentiell möglichen Betrachtungs- und Darstellungsbereich einer IVS-Architektur aufspannen.
*repräsentiert den strukturellen Aufbau von IVS-Diensten, um darüber ihre Eigenschaften besser identifizieren, einordnen und miteinander in Beziehung setzen zu können.
*liefert für die Beschreibung von IVS-Diensten die für IVS-Geschäftsmodelle notwendige Semantik.

Die IVS-Architektur-Pyramide enthält folgende Schichten:

'''Leitbild-/Strategie-Ebene''' beschreibt...

*die Ziele von IVS bzw. IVS-Diensten (Schaffung von Mehrwert) in Form eines Leitbildes,
*wie, d.h. auf welche Art und Weise die IVS-Ziele erreicht werden sollen (Strategie).

'''Prozesse-Ebene''' beschreibt und identifiziert...

*welche IVS-Rollen an der Mehrwertbildung mit Hilfe von IVS beteiligt sind,
*wie die IVS-Rollen IVS-Ziele und IVS-Strategie für sich als Business Case interpretieren,
*wie über die Zusammenarbeit/Beziehung zwischen den IVS-Rollen der IVS-Mehrwert/IVS-Nutzen generiert und über IVS-Geschäftsprozesse operationalisiert wird.

'''Informationsstrukturen-Ebene''' beschreibt und identifiziert...

*welche IVS-Informationen zur IVS-Mehrwertbildung beitragen und
*wie diese strukturiert sind.

'''IT-Dienste-Ebene und IT-Infrastruktur-Ebene''' beschreiben...

*wie die IVS-Informationen generierbar sind und
*wie/wo sie bereitgestellt werden.

Die IVS-Architektur-Pyramide kann in allen Phasen einer inhaltlichen Auseinandersetzung auf alle relevanten Aspekte von IVS und IVS-Diensten angewendet werden. Vor allem können Forderungen nach verändertem Rollenverständnis über die Anwendung der IVS-Architektur-Pyramide identifiziert und konkretisiert werden. Insbesondere wenn IVS-Dienste verteilt realisiert werden, kann die IVS-Architektur-Pyramide stets den logischen Zusammenhang vermitteln.

== Instanzen von IVS-Architektur ==

In den [[Media:W1-Papier_AK_3_1_4_v2_1.pdf|Hinweisen zur Strukturierung einer Rahmenarchitektur für Intelligente Verkehrssysteme (IVS) in Deutschland – Notwendigkeit und Methodik, FGSV-Nr. 305]] werden drei Instanz-Ebenen von IVS-Architekturen unterschieden.

[[File:EbenenVonIVS-Architektur 00-00-01.png|thumb|right|250px|Instanz-Ebenen von IVS-Architektur]]

Die '''IVS-Rahmenarchitektur'''...

*legt IVS-Gestaltungselemente als Architekturbausteine (TOGAF: Building blocks) fest und definiert dafür Begriffe und ihre Semantik (IVS-Glossar).
*legt Gestaltungsgrundsätze fest, nach denen der IVS-Architekt bei der Planung und Realisierung von IVS-Diensten vorgehen soll.

Eine '''IVS-Referenzarchitektur'''...

*konkretisiert die von der IVS-Rahmenarchitektur vorgegebenen Konzepte für eine IVS-Dienstekategorie (IVS-Dienstefamilie) für den Gestaltungsraum einer spezifischen IVS-Domäne.

Die '''IVS-Architektur realer IVS-Dienste'''...

*ist die tatsächliche Umsetzung relevanter IVS-Referenzarchitekturen bis zur letzten Detaillierungsebene in einem konkreten Anwendungsfall.

Die Zahl der IVS-Referenzarchitekturen ist vom Grunde her nicht begrenzt. Im vorliegenden Projektverbund der Lose 1- 4 ist mit den Losen 2 bis 4 die Entwicklung von IVS-Referenzarchitekturen für drei '''IVS-Dienstekategorien''' umgesetzt, und zwar:

*Los 2: '''Durchgängige Verkehrsinformation Individualverkehr'''
*Los 3: '''Zuständigkeitsübergreifendes Verkehrsmanagement'''
*Los 4: '''Multimodale Reiseinformationen'''

== IVS-Architekturmerkmale zur Implementierung von IVS-Architektur ==

[[File:ImplementierungVonArchitektur.png|thumb|right|250px|Implementierung von IVS-Architektur]]

Für die Implementierung von IVS-Architektur bedarf es der Entwicklung von IVS-Architekturkonzepten, die über '''IVS-Architekturmerkmale und deren Semantik formuliert werden''' und die durchgehend den Charakter und das Wesen von IVS-Diensten bestimmen sollen. Die Gesamtheit der IVS-Architekturkonzepte könnten mit dem Begriff '''IVS-Architekturschule''' belegt werden.

Wenn z.B. "Interoperabilität" ein Stilmerkmal des IVS-Architekten/der IVS-Architekturschule ist, dann wird sich das Architekturmerkmal "Interoperabilität" in allen Teilen des IVS-Betrachtungsgegenstandes in verschiedensten Ausprägungen wiederfinden.

Mit der IVS-Architekturschule, die durch die  IVS-Rahmenarchitektur repräsentiert wird, werden vornehmlich politische Zielsetzungen implementiert. Da "kluge" Politik jedoch auch immer die Interessen der Basis einbindet, reflektiert die "Schulmeinung" auch das '''Interesse der Bauherren realer IVS-Dienste''' durch nachhaltige Einbindung von Stakeholdern und IVS-Akteuren (siehe auch [[Open-IVS|"Open IVS" als Leitgedanke]]).

== Konzeptinstanziierung zur Konkretisierung von IVS-Architektur ==

[[File:GoingMeta.png|thumb|right|250px|Going Meta]]

Die Methodik der '''Konzeptinstanziierung''', das heißt der Übertragung und Abbildung von IVS-Architekturkonzepten mit ihrer Semantik (siehe auch [[Meta-Modelle#Modelle_als_Grundlage_f.C3.BCr_Nachvollziehbarkeit|Modelle - Grundlage für Nachvollziehbarkeit]]), ausgehend von der IVS-Rahmenarchitektur über die IVS-Referenzarchitekturen bis hin zu IVS-Architekturen realer IVS-Dienste soll nebenstehendes Bild verdeutlichen:

*mit der '''IVS-Rahmenarchitektur''' (Meta-Meta-Modell der realen Welt) werden die für die IVS-Architektur von IVS-Diensten notwendigen Architekturkonzepte über den '''Vorschlag diesbezüglicher IVS-Architekturmerkmale strukturiert, semantisch beschrieben und letztendlich begründet'''.

*mit '''IVS-Referenzarchitekturen''' (Meta-Modelle der realen Welt) werden die '''Architekturkonzepte der IVS-Rahmenarchitektur für eine IVS-Dienstekategorie konkretisiert.'''

*mit '''IVS-Architekturen realer IVS-Dienste''' (Modelle der realen Welt) werden die bereits für eine IVS-Dienstekategorie konkretisierten Architekturkonzepte der IVS-Rahmenarchitektur für einen '''realen IVS-Dienst weiter konkretisiert und angewendet'''.

'''Beispiele für Konzeptinstanziierung''' sind:

{| class="wikitable"
|-
! Baustein IVS-Rahmenarchitektur
! Verwendung für die IVS-Referenzarchitektur
! Verwendung für die IVS-Architektur realer IVS-Dienste
|- style="vertical-align:top"
| '''IVS-Dienst''' als Konzept (Prinzip der IVS-Wertschöpfungskette/des IVS-Wertschöpfungsnetzwerks)
| '''Stereotype von IVS-Diensten''' (Verkehrsinformation Individualverkehr, Zuständigkeitsübergreifendes Verkehrsmanagement und Multimodale Verkehrsinformation)
| '''Realer IVS-Dienst''' (Google Maps, Alternativroutensteuerung Dmotion, Reiseauskunft der Deutschen Bahn ...)
|- style="vertical-align:top"
| '''IVS-Rolle''' als Konzept (als Aufbauelement von IVS-Wertschöpfungsketten und -netzwerken)
| '''Stereotype von IVS-Akteuren''' (Navigationsdienstleister, Öffentlicher Straßenbetreiber, Verkehrsunternehmen ...)
| '''Realer IVS-Akteur''' (Google, Hessen Mobil/Amt für Verkehrsmanagement Düsseldorf und Deutsche Bahn)
|- style="vertical-align:top"
| '''IVS-Mehrwert''' als Konzept (als Ziel und Ergebnis von IVS-Wertschöpfungsketten und -netzwerken)
| '''Stereotype von IVS-Mehrwerten''' (Erhöhung der Sicherheit, Verbesserung der Effizienz, Reduzierung von Umwelteinflüssen ...)
| '''Reale IVS-Kenngrößen''' (Anzahl der Unfalltoten, Staubilanz, CO2 und NOX-Emissionen)
|}

Die '''IVS-Architektur eines realen IVS-Dienstes''' muss allerdings '''nicht zwangsweise in allen Punkten konform zur IVS-Rahmenarchitektur und IVS-Referenzarchitektur''' sein. Breite und Tiefe der IVS-Architektur-Konzeptinstanziierung liegen im '''Ermessen des Realisierers'''. Die Bewertung der IVS-Architektur und damit des Nutzens eines realen IVS-Dienstes liegt dann im '''Ermessen des Nutzers'''.

== Qualität von IVS-Architektur ==

'''Gibt es eine „gute“ IVS-Architektur?'''

Konstruktive Weitsicht ist eine wünschenswerte Qualifikation eines IVS-Architekten; entweder hat er sie oder er hat sie nicht. Hat er sie, wird er die Freiheitsgrade für IVS-Dienste-Gestaltung nutzen, damit die aktuell zu realisierenden Dienstmerkmale einem der Hauptziele von IVS-Architektur, soweit für ihn erkennbar, '''zukünftigen Integrations- oder Erweiterungsmöglichkeiten nicht im Wege''' stehen.

Eine IVS-Referenzarchitektur oder die IVS-Architektur eines realen IVS-Dienstes sind dann eine „gute“ Architektur, wenn sie die Merkmale der IVS-Rahmenarchitektur konzeptgetreu in die Architektur einer IVS-Dienstekategorie oder eines realen IVS-Dienstes übertragen.

Es sollte jedoch beachtet werden, dass „gut“ ein Ideal ist. Das heißt, dass '''IVS-Rahmenarchitektur im konkreten Anwendungsfall vorrangig eine Orientierungs- und Bewertungshilfe''' ist, um dem Vorsatz der Erzielung einer guten Architektur auch nachvollziehbar folgen zu können. Unvermeidbare Abweichungen können dann erkannt, bewertet und in ein Gesamtbild eingeordnet werden.

== Verbindung von TOGAF Konzepten mit Vorstellungen von IVS-Architektur ==

=== Architekturdomänen von TOGAF ===

[[File:TOGAFArchitekturdomänen4.png|thumb|right|244x141px|Architekturdomänen von TOGAF]]

Um die Diskussion um Begriffe und ihre Semantik im Projekt "IVS-Architektur Straße für Deutschland" von Anfang an objektiver und effektiver zu gestalten und auf die übergeordnete Zielsetzung der konsensualen Schaffung einer IVS-Rahmenarchitektur und von drei IVS-Referenzarchitekturen auszurichten, bietet die [https://de.wikipedia.org/wiki/TOGAF '''Standardisierungsinitiative TOGAF'''] das '''Metamodell der in Schichten angeordneten TOGAF-Architekturdomänen''' mit dem Ziel an, unter dem Schlagwort Unternehmensarchitektur das komplexe Verhalten von Unternehmen auf der Grundlage vereinbarter (standardisierter) Grundkonzepte (sogenannte Basisarchitekturen) zukünftig gleichartig beschreiben zu können.

Hier schließt sich der Kreis zu der aktuellen Vorstellung von IVS-Architektur, der von der IVS-Architektur Pyramide als hierarchisches Ordnungsprinzip geprägt ist, das auf die Schichten des TOGAF-Schichtenmodells abgebildet werden kann.

;Wichtiger Hinweis:
:Um Genaueres über TOGAF und die einzelnen Schritte der TOGAF ADM zu erfahren, muss ein Account auf der Website der "The Open Group" angelegt werden. Hierzu kann folgender Link genutzt werden: [https://www2.opengroup.org/ogsys/common/createIndividual.html?popup=true/ TOGAF-Login]

=== TOGAF-Architekturdomänen und die Ebenen der IVS-Pyramide ===

TOGAF ist ein umfangreiches Modell und beinhaltet sehr mächtige Konzepte. Insofern besteht eine besondere Fragestellung für die Entwicklung der IVS-Rahmenarchitektur darin, die für IVS-Architektur wirklich relevanten Konzepte von TOGAF erst zu identifizieren und sie dann auf IVS in einer Weise zu übertragen und verständlich zu machen, dass IVS-Experten im Sinne von [[Open-IVS|"Open-IVS"]] darin einen wirklichen Nutzen sehen, sie wirklich annehmen und sich in Form von IVS-Architektur zu eigen machen ('''Theorie trifft auf Praxis''').

Vor diesem Hintergrund besteht die methodische Herausforderung der Verwendung von TOGAF darin:

*die mit den dargestellten TOGAF-Architekturdomänen verbundenen TOGAF Konzepte, also dessen, worum es strukturell und semantisch bei TOGAF wirklich geht, auf IVS-Architekturdomänen zu übertragen und
*über die Anwendung und Anpassung der TOGAF-ADM diejenigen Ebenen und Unterebenen der TOGAF-Architekturdomänen zu adressieren und für IVS zu interpretieren, die für IVS-Funktionalität und IVS-Verhalten wirklich bedeutsam sind (Qualität vor Quantität).

[[File:TOGAFMeetsIVS 00-00-01.png|thumb|right|300px|Abbildung der TOGAF-Architekturdomänen auf die Ebenen der IVS-Pyramide]]

Natürlich muss klar sein, dass von von der IVS-Rahmenarchitektur nur die wichtigsten Ebenen/Unterebenen und deren Bereiche adressiert werden können und müssen, eben diejenigen, die für '''die Funktionalität und das Verhalten von IVS-Diensten''' bedeutsam sind. Bildhaft gesprochen geht es darum, für IVS-Dienste solche Teilbereiche in den TOGAF-Ebenen zu identifizieren, die geeignet sind, '''allgemeine Gestaltungsziele für IVS-Architekturen '''(IVS-Referenzarchitekturen, IVS-Architektur realer IVS-Dienste)'''den allgemeinen TOGAF-Zielen unterzuordnen'''. IVS-Ziele sind in diesem Sinne spezieller als TOGAF-Ziele. Konformität wäre z.B. gegeben, wenn Merkmale eines IVS-Ziels auch als Merkmale eines TOGAF-Ziels feststellbar sind.

=== Beziehung zwischen TOGAF und IVS ===

TOGAF steht insgesamt für eine semantische Struktur, die TOGAF-relevante Konzepte in Beziehung bringt und damit eine Grundordnung für übergreifendes Gestalten von TOGAF-Domänen vermittelt. '''Durch Gestalten sollen Formen der Zusammenarbeit von IVS-Akteuren in globalen Zusammenhängen verbessert oder gar erst ermöglicht werden'''. Effizienz und Effektivität sind dabei wesentliche Qualitätsmerkmale in der Ausrichtung gestalterischer Entscheidungen.

IVS als Ganzes ist bisher „unscharf“ definiert. Es müssen also Wege für Interpretationen gefunden werden, auf denen für Dritte nachvollziehbar dargestellt werden kann, wie eine allgemeine TOGAF-Sicht auf TOGAF-Konzepte auf IVS-Konzepte abgebildet oder damit in Beziehung gebracht werden können. Dazu muss umgekehrt auch dargelegt werden, dass die gemeinhin spezielleren IVS-Konzepte eine TOGAF-Relevanz in sich tragen. Mit anderen Worten, '''es muss verifizierbar werden, dass der IVS-Gestaltungsfokus dem TOGAF-Gestaltungszweck entspricht'''.

Für die sprachliche Ausstattung der Bestandteile der Terminologie und ihre Darstellung sollte sich auf die Verwendung von – möglichst schon existierenden und bewährten – Standards und den dort angebotenen Konzepten geeinigt werden. Nur damit können subjektive Sachverhalte zumindest in der Darstellung objektiviert werden.

== Literaturverzeichnis ==

<references />

----

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

IVS-Architektur - Schlüsselbegriffe

2018-04-17T08:59:08Z

Albrecht:

== IVS-Architektur - Definitionen ==

=== [[IVS-Dienste-Konzept#Intelligente_Verkehrs-Systeme|IVS - Intelligente Verkehrs-Systeme (engl. ITS - Intelligent Transport Systems)...]] ===

*verstehen sich als '''intelligente Anwendungen im Bereich von Transport, Verkehr und Mobilität,''' die vom '''IVS-End-Nutzer '''als [[IVS-Dienste-Konzept#IVS-Dienst|IVS-Dienst (engl. ITS service)]] genutzt werden können.
*betreiben '''IVS-Wertschöpfung''', indem sie IVS-End-Nutzer mit umfassenderen Informationen in die Lage versetzen Verkehrsnetze auf sicherere, koordiniertere und "klügere" Weise zu nutzen (siehe [[Media:_2011_its_initial_report_germany.pdf|Status und Rahmenbedingungen für Intelligente Verkehrssysteme (IVS) in Deutschland 2010]] [[Media:_2011_its_initial_report_germany.pdf|<ref> Bericht gemäß Artikel 17(1) der Richtlinie 2010/40/EU des Europäischen Parlaments und des Rates vom 7. Juli 2010 zum Rahmen für die Einführung intelligenter Verkehrssysteme im Straßenverkehr und für deren Schnittstellen zu anderen Verkehrsträgern (2010). Deutschland. Online verfügbar unter http://ec.europa.eu/transport/themes/its/road/action_plan/doc/2011_its_initial_report_germany.pdf, zuletzt geprüft am 24.10.2017</ref>]]).
*setzen Informations- und Kommunikationstechnologien (IKT) im Straßenverkehr und an den Schnittstellen zu anderen Verkehrsträgern ein, mit deren Hilfe '''verkehrsbezogene Daten und Informationen erfasst, übermittelt, verarbeitet und ausgetauscht werden '''können (siehe [[Media:Ivs.pdf|IVS-Gesetz]]).
*dürfen über ihren Wortanteil '''Intelligenz''' nicht im Sinne künstlicher Intelligenz (KI), sondern müssen im Sinne von '''Business Intelligence''' verstanden werden. Dabei ist '''Intelligenz''' ein '''Synonym für Informationen und Erkenntnisse, die durch das Sammeln und Auswerten von Daten und Informationen''' mit dem Ziel '''gewonnen''' werden, dem End-Nutzer von IVS im Hinblick auf seine Ziele '''bessere strategische und/oder operative Entscheidungen''' zu ermöglichen bzw. aus Betreibersicht auf End-Nutzer von IVS eine besondere Wirkung derart auszuüben, dass diese '''ihr Verhalten auf die Ziele des Betreibers ausrichten'''.

=== [[IVS-Architekturprinzipien|IVS-Architektur...]] ===

[[File:IVS-Architektur.jpg|thumb|right|500px|IVS-Architektur und Ebenen von IVS-Architektur - Modell]]

*befasst sich grundsätzlich neben der funktionalen, technischen und wirtschaftlichen Realisierung vor allem mit der '''gestalterischen Planung von IVS und IVS-Diensten'''.
*orientiert sich an '''übergeordneten Leitbildern und Zielvorstellungen''' des „Bauherrn“. Insofern liegt die Kernkompetenz eines IVS-Architekten über das Wissen um Realisierung von IVS und IVS-Diensten hinaus, vor allem in der '''Schaffung von IVS-Architektur''' mittels '''Vorschlagen und Ausprägen von IVS-Architekturmerkmalen''', die den Leitbildern und Zielvorstellungen des Bauherrn entsprechen oder er entwickelt dazu eigene Vorstellungen.

=== [[IVS-Architekturprinzipien#Ebenen_von_IVS-Architektur|Die IVS-Rahmenarchitektur...]] ===

*legt die Gestaltungsebenen ('''IVS-Architekturdomänen''') und Gestaltungsobjekte ('''IVS-Architekturelemente''') fest, die das architekturelle Erscheinungsbild von IVS und IVS-Diensten repräsentieren und sie als solche charakterisieren und wiedererkennbar machen.
*verleiht den Gestaltungsebenen und Gestaltungsobjekten von IVS und IVS-Diensten eine '''IVS-Semantik''' zur gegenseitigen Verständigung; dies erfolgt über einen (eineindeutigen) IVS-Begriff, der im IVS-Glossar sprachlich und anhand von Bildern erläutert wird.
*legt darüber hinaus (in Anlehnung an das Vorgehensmodell von TOGAF) die '''Schritte''' und '''Grundsätze''' fest, nach denen der IVS-Architekt bei der Planung und Realisierung von IVS-Diensten vorgehen soll.

=== [[IVS-Architekturprinzipien#IVS-Architekturmerkmale_zur_Implementierung_von_IVS-Architektur|IVS-Architekturmerkmale...]] ===

*prägen das '''architekturelle Erscheinungsbild des IVS-Betrachtungsgegenstandes''' und machen so den '''Stil der IVS-Architekturschule/eines IVS-Architekten''' wiedererkennbar.
*'''repräsentieren''' über ihre Auswahl und Semantik '''die IVS-Rahmenarchitektur''' als '''Meta-Meta-Modell von IVS-Architektur.'''
*'''implementieren die IVS-Architektur''' der IVS-Architekturschule/eines IVS-Architekten, indem sie als '''Merkmale einer IVS-Dienstekategorie/eines IVS-Dienstes''' instanziiert werden (Konzeptinstanziierung).

=== [[IVS-Architekturprinzipien#Ebenen_von_IVS-Architektur|Die IVS-Referenzarchitektur...]] ===

*'''überträgt''' die von der IVS-Rahmenarchitektur vorgegebenen '''Gestaltungsebenen und Gestaltungsobjekte''' auf den Gestaltungsraum einer spezifischen, mit einem Bezeichner benannten '''IVS-Dienstekategorie''' (man könnte auch sagen IVS-Dienstefamilie), und konkretisiert sie soweit, dass sie aus fachlicher Sicht den gemeinsamen Bedingungen der IVS-Dienstekategorie entsprechen.
*ist auch die '''Grundlage''' zur Spezifikation und Entwicklung der IVS-Architekturen '''realer IVS-Dienste und spezifischer IVS-Produkte''' für spezielle IVS-Anwendungsdomänen.
*ist von großem Nutzen, wenn sie von einer „größeren“ Gemeinschaft akzeptiert und '''quasi als Standard''' eingesetzt und genutzt wird.

=== [[IVS-Architekturprinzipien#Ebenen_von_IVS-Architektur|Die IVS-Architektur realer IVS-Dienste und IVS-Produkte...]] ===

*ist die '''tatsächliche Umsetzung der relevanten IVS-Referenzarchitekturen''' bis zur letzten Detaillierungsebene in einem konkreten Anwendungsfall.
*bildet die Konzeptmerkmale (semantische Merkmale) von IVS-Referenzarchitekturen nach dem '''Prinzip der Konzeptinstanziierung''' auf konkrete Architekturen realer IVS-Dienste oder IVS-Produkte ab.
*darf '''Konformität zu IVS-Rahmenarchitektur und zu IVS-Referenzarchitekturen''' in Anspruch nehmen, wenn deren IVS-Architekturkonzepte nachvollziehbar wiedererkennbar sind.

== Verbindung von IVS- und TOGAF-Architekturkonzepten ==

[[File:IVS-Pyramide.jpg|thumb|right|500px|Verbindung von IVS- und TOGAF-Architekturkonzepten - Modell]]

=== [[IVS-Architekturprinzipien#Die_IVS-Pyramide|Die IVS-Pyramide...]] ===

*besteht aus fünf als '''IVS-Architekturdomänen''' bezeichnete Schichten, die zusammen den potentiell möglichen '''Betrachtungs- und Darstellungsbereich von IVS-Architektur''' aufspannen.
*repräsentiert über ihre Schichten den '''strukturellen Aufbau von IVS-Diensten''', um darüber ihre Eigenschaften besser identifizieren, einordnen und miteinander in Beziehung setzen zu können.
*ist ein Konzept, das Basiskonzepte von IVS-Architektur in Beziehung setzt und damit eine '''Grundordnung für übergreifendes Gestalten''' von IVS-Architektur vermittelt.

=== [[IVS-Architekturprinzipien#Ebenen_von_IVS-Architektur|Die IVS-Architekturdomäne...]] ===

*unterteilt den komplexen Gestaltungsraum von IVS-Diensten in '''semantische Schichten'''.
*verleiht über ihre '''Benennung und inhaltliche Konkretisierung ''' der Beschreibung von IVS-Diensten die dafür zugrundeliegende '''architekturelle Semantik'''.
*ist als '''Schicht der [[IVS-Architekturprinzipien#Die_IVS-Pyramide|IVS-Pyramide]]''' ein Bestandteil der Vorstellung von IVS-Architektur und als '''TOGAF-ADM-Phase (B bis D)''' ein Gegenstand der Entwicklung einer '''Unternehmensarchitektur''' (Enterprise Architecture) und verbindet darüber IVS- mit TOGAF-Architekturkonzepten.

----

== Literaturverzeichnis ==

<references />

----

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

IVS-Architektur - Schlüsselbegriffe

2018-04-17T08:58:06Z

Albrecht:

== IVS-Architektur - Schlüsselbegriffe ==

=== [[IVS-Dienste-Konzept#Intelligente_Verkehrs-Systeme|IVS - Intelligente Verkehrs-Systeme (engl. ITS - Intelligent Transport Systems)...]] ===

*verstehen sich als '''intelligente Anwendungen im Bereich von Transport, Verkehr und Mobilität,''' die vom '''IVS-End-Nutzer '''als [[IVS-Dienste-Konzept#IVS-Dienst|IVS-Dienst (engl. ITS service)]] genutzt werden können.
*betreiben '''IVS-Wertschöpfung''', indem sie IVS-End-Nutzer mit umfassenderen Informationen in die Lage versetzen Verkehrsnetze auf sicherere, koordiniertere und "klügere" Weise zu nutzen (siehe [[Media:_2011_its_initial_report_germany.pdf|Status und Rahmenbedingungen für Intelligente Verkehrssysteme (IVS) in Deutschland 2010]] [[Media:_2011_its_initial_report_germany.pdf|<ref> Bericht gemäß Artikel 17(1) der Richtlinie 2010/40/EU des Europäischen Parlaments und des Rates vom 7. Juli 2010 zum Rahmen für die Einführung intelligenter Verkehrssysteme im Straßenverkehr und für deren Schnittstellen zu anderen Verkehrsträgern (2010). Deutschland. Online verfügbar unter http://ec.europa.eu/transport/themes/its/road/action_plan/doc/2011_its_initial_report_germany.pdf, zuletzt geprüft am 24.10.2017</ref>]]).
*setzen Informations- und Kommunikationstechnologien (IKT) im Straßenverkehr und an den Schnittstellen zu anderen Verkehrsträgern ein, mit deren Hilfe '''verkehrsbezogene Daten und Informationen erfasst, übermittelt, verarbeitet und ausgetauscht werden '''können (siehe [[Media:Ivs.pdf|IVS-Gesetz]]).
*dürfen über ihren Wortanteil '''Intelligenz''' nicht im Sinne künstlicher Intelligenz (KI), sondern müssen im Sinne von '''Business Intelligence''' verstanden werden. Dabei ist '''Intelligenz''' ein '''Synonym für Informationen und Erkenntnisse, die durch das Sammeln und Auswerten von Daten und Informationen''' mit dem Ziel '''gewonnen''' werden, dem End-Nutzer von IVS im Hinblick auf seine Ziele '''bessere strategische und/oder operative Entscheidungen''' zu ermöglichen bzw. aus Betreibersicht auf End-Nutzer von IVS eine besondere Wirkung derart auszuüben, dass diese '''ihr Verhalten auf die Ziele des Betreibers ausrichten'''.

=== [[IVS-Architekturprinzipien|IVS-Architektur...]] ===

[[File:IVS-Architektur.jpg|thumb|right|500px|IVS-Architektur und Ebenen von IVS-Architektur - Modell]]

*befasst sich grundsätzlich neben der funktionalen, technischen und wirtschaftlichen Realisierung vor allem mit der '''gestalterischen Planung von IVS und IVS-Diensten'''.
*orientiert sich an '''übergeordneten Leitbildern und Zielvorstellungen''' des „Bauherrn“. Insofern liegt die Kernkompetenz eines IVS-Architekten über das Wissen um Realisierung von IVS und IVS-Diensten hinaus, vor allem in der '''Schaffung von IVS-Architektur''' mittels '''Vorschlagen und Ausprägen von IVS-Architekturmerkmalen''', die den Leitbildern und Zielvorstellungen des Bauherrn entsprechen oder er entwickelt dazu eigene Vorstellungen.

=== [[IVS-Architekturprinzipien#Ebenen_von_IVS-Architektur|Die IVS-Rahmenarchitektur...]] ===

*legt die Gestaltungsebenen ('''IVS-Architekturdomänen''') und Gestaltungsobjekte ('''IVS-Architekturelemente''') fest, die das architekturelle Erscheinungsbild von IVS und IVS-Diensten repräsentieren und sie als solche charakterisieren und wiedererkennbar machen.
*verleiht den Gestaltungsebenen und Gestaltungsobjekten von IVS und IVS-Diensten eine '''IVS-Semantik''' zur gegenseitigen Verständigung; dies erfolgt über einen (eineindeutigen) IVS-Begriff, der im IVS-Glossar sprachlich und anhand von Bildern erläutert wird.
*legt darüber hinaus (in Anlehnung an das Vorgehensmodell von TOGAF) die '''Schritte''' und '''Grundsätze''' fest, nach denen der IVS-Architekt bei der Planung und Realisierung von IVS-Diensten vorgehen soll.

=== [[IVS-Architekturprinzipien#IVS-Architekturmerkmale_zur_Implementierung_von_IVS-Architektur|IVS-Architekturmerkmale...]] ===

*prägen das '''architekturelle Erscheinungsbild des IVS-Betrachtungsgegenstandes''' und machen so den '''Stil der IVS-Architekturschule/eines IVS-Architekten''' wiedererkennbar.
*'''repräsentieren''' über ihre Auswahl und Semantik '''die IVS-Rahmenarchitektur''' als '''Meta-Meta-Modell von IVS-Architektur.'''
*'''implementieren die IVS-Architektur''' der IVS-Architekturschule/eines IVS-Architekten, indem sie als '''Merkmale einer IVS-Dienstekategorie/eines IVS-Dienstes''' instanziiert werden (Konzeptinstanziierung).

=== [[IVS-Architekturprinzipien#Ebenen_von_IVS-Architektur|Die IVS-Referenzarchitektur...]] ===

*'''überträgt''' die von der IVS-Rahmenarchitektur vorgegebenen '''Gestaltungsebenen und Gestaltungsobjekte''' auf den Gestaltungsraum einer spezifischen, mit einem Bezeichner benannten '''IVS-Dienstekategorie''' (man könnte auch sagen IVS-Dienstefamilie), und konkretisiert sie soweit, dass sie aus fachlicher Sicht den gemeinsamen Bedingungen der IVS-Dienstekategorie entsprechen.
*ist auch die '''Grundlage''' zur Spezifikation und Entwicklung der IVS-Architekturen '''realer IVS-Dienste und spezifischer IVS-Produkte''' für spezielle IVS-Anwendungsdomänen.
*ist von großem Nutzen, wenn sie von einer „größeren“ Gemeinschaft akzeptiert und '''quasi als Standard''' eingesetzt und genutzt wird.

=== [[IVS-Architekturprinzipien#Ebenen_von_IVS-Architektur|Die IVS-Architektur realer IVS-Dienste und IVS-Produkte...]] ===

*ist die '''tatsächliche Umsetzung der relevanten IVS-Referenzarchitekturen''' bis zur letzten Detaillierungsebene in einem konkreten Anwendungsfall.
*bildet die Konzeptmerkmale (semantische Merkmale) von IVS-Referenzarchitekturen nach dem '''Prinzip der Konzeptinstanziierung''' auf konkrete Architekturen realer IVS-Dienste oder IVS-Produkte ab.
*darf '''Konformität zu IVS-Rahmenarchitektur und zu IVS-Referenzarchitekturen''' in Anspruch nehmen, wenn deren IVS-Architekturkonzepte nachvollziehbar wiedererkennbar sind.

== Verbindung von IVS- und TOGAF-Architekturkonzepten ==

[[File:IVS-Pyramide.jpg|thumb|right|500px|Verbindung von IVS- und TOGAF-Architekturkonzepten - Modell]]

=== [[IVS-Architekturprinzipien#Die_IVS-Pyramide|Die IVS-Pyramide...]] ===

*besteht aus fünf als '''IVS-Architekturdomänen''' bezeichnete Schichten, die zusammen den potentiell möglichen '''Betrachtungs- und Darstellungsbereich von IVS-Architektur''' aufspannen.
*repräsentiert über ihre Schichten den '''strukturellen Aufbau von IVS-Diensten''', um darüber ihre Eigenschaften besser identifizieren, einordnen und miteinander in Beziehung setzen zu können.
*ist ein Konzept, das Basiskonzepte von IVS-Architektur in Beziehung setzt und damit eine '''Grundordnung für übergreifendes Gestalten''' von IVS-Architektur vermittelt.

=== [[IVS-Architekturprinzipien#Ebenen_von_IVS-Architektur|Die IVS-Architekturdomäne...]] ===

*unterteilt den komplexen Gestaltungsraum von IVS-Diensten in '''semantische Schichten'''.
*verleiht über ihre '''Benennung und inhaltliche Konkretisierung ''' der Beschreibung von IVS-Diensten die dafür zugrundeliegende '''architekturelle Semantik'''.
*ist als '''Schicht der [[IVS-Architekturprinzipien#Die_IVS-Pyramide|IVS-Pyramide]]''' ein Bestandteil der Vorstellung von IVS-Architektur und als '''TOGAF-ADM-Phase (B bis D)''' ein Gegenstand der Entwicklung einer '''Unternehmensarchitektur''' (Enterprise Architecture) und verbindet darüber IVS- mit TOGAF-Architekturkonzepten.

----

== Literaturverzeichnis ==

<references />

----

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

IVS-Architektur - Schlüsselbegriffe

2018-04-17T08:56:33Z

Albrecht: Die Seite wurde neu angelegt: „== IVS-Architektur - Schlüsselbegriffe == === IVS-Dienste-Konzept#Intelligente_Verkehrs-Systeme|IVS - Intelligente Verkehrs-Systeme (engl. ITS - Intelligen…“

NavTree

2018-04-17T08:56:07Z

Albrecht:

{{#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-Architektur - Definitionen und Metamodelle
***[[IVS-Architekturprinzipien | IVS-Architektur - Metamodelle und Architekturprinzipien]]
***[[IVS-Architektur - Schlüsselbegriffe | IVS-Architektur - Schlüsselbegriffe]]
**[[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-Architektur 1.0]]
** Die IVS-Rahmenarchitektur 1.0
***[[IVS-Archtektur-Vorgehensmodell | Das TOGAF-basierte IVS-Architektur Vorgehensmodell]]
***[[IVS-Architekturbausteine | Die IVS-Architekturbausteine der IVS-Rahmenarchitektur 1.0 ]]
** Die 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]]
*[[Schlussberichte]]
}}

NavTree

2018-04-17T08:50:43Z

Albrecht:

{{#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-Architektur - Metamodelle und Definitionen
***[[IVS-Architekturprinzipien | IVS-Architektur - Metamodelle]]
***[[IVS-Architektur - Grundlegende Definitionen | IVS-Architektur - Grundlegende Definitionen]]
**[[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-Architektur 1.0]]
** Die IVS-Rahmenarchitektur 1.0
***[[IVS-Archtektur-Vorgehensmodell | Das TOGAF-basierte IVS-Architektur Vorgehensmodell]]
***[[IVS-Architekturbausteine | Die IVS-Architekturbausteine der IVS-Rahmenarchitektur 1.0 ]]
** Die 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]]
*[[Schlussberichte]]
}}

NavTree

2018-04-12T06:11:36Z

Albrecht:

{{#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]]
**[[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-Architektur 1.0]]
** Die IVS-Rahmenarchitektur 1.0
***[[IVS-Archtektur-Vorgehensmodell | Das TOGAF-basierte IVS-Architektur Vorgehensmodell]]
***[[IVS-Architekturbausteine | Die IVS-Architekturbausteine der IVS-Rahmenarchitektur 1.0 ]]
** Die 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]]
*[[Schlussberichte]]
}}

NavTree

2018-04-12T06:10:01Z

Albrecht:

{{#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]]
**[[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-Architektur 1.0]]
** Die IVS-Rahmenarchitektur 1.0
**[[IVS-Archtektur-Vorgehensmodell | Das TOGAF-basierte IVS-Architektur Vorgehensmodell]]
**[[IVS-Architekturbausteine | Die IVS-Architekturbausteine der IVS-Rahmenarchitektur 1.0 ]]
** Die 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]]
*[[Schlussberichte]]
}}

Diskussion:Weiterentwicklung & Pflege der IVS-Architekturen 1.0

2018-04-11T06:20:23Z

Albrecht:

== 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 Prozess 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.

'''Pflege der IVS-Rahmenarchitektur'''

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.

Diskussion:Weiterentwicklung & Pflege der IVS-Architekturen 1.0

2018-04-11T06:19:05Z

Albrecht: Die Seite wurde neu angelegt: „== Aufgabenstellung == Die Entwicklung einer ersten Version der in diesem Projekt definierten Architekturen (IVS-Rahmenarchitektur und die in den Losen 2-4 au…“

== 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 Prozess 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.

Weiterentwicklung & Pflege der IVS-Architekturen 1.0

2018-04-11T06:17:10Z

Albrecht: Änderung 13695 von Albrecht (Diskussion) rückgängig gemacht.

== 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 Prozess 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.

Weiterentwicklung & Pflege der IVS-Architekturen 1.0

2018-04-11T06:15:29Z

Albrecht:

== 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 Prozess 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?

<parsererror xmlns="http://www.mozilla.org/newlayout/xml/parsererror.xml">XML Parsing Error: syntax error</parsererror>

== 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-04-11T06:12:55Z

Albrecht:

== 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 Prozess 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.

Weiterentwicklung & Pflege der IVS-Architekturen 1.0

2018-04-11T06:11:15Z

Albrecht:

== 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 Prozess 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.

Weiterentwicklung & Pflege der IVS-Architekturen 1.0

2018-04-11T06:00:37Z

Albrecht:

== 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 Prozess 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.

Weiterentwicklung & Pflege der IVS-Architekturen 1.0

2018-04-11T05:57:42Z

Albrecht:

== 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 Prozess 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-Rahmenarchitektur Schlussbericht DTS 10-00-02.pdf

2018-04-09T10:14:03Z

Albrecht:

Schlussberichte

2018-04-09T10:13:23Z

Albrecht:

Los1: IVS-Rahmenarchitektur - ein Rahmenwerk zur Entwicklung von IVS-Architekturen

*[[Media:FE03-4083-2011-IRB_IVS-Rahmenarchitektur_Kurzfassung_DTS-ENG_00-01-02.pdf|IVS-Rahmenarchitektur Schlussbericht Kurzfassung DTS-ENG Entwurf.pdf]]
*[[Media:FE03-4083-2011-IRB_IVS-Rahmenarchitektur_Kurzbericht_DTS_00-01-00.pdf|IVS-Rahmenarchitektur Schlussbericht Kurzbericht DTS Entwurf.pdf]]
*[[Media:FE03-4083-2011-IRB_IVS-Rahmenarchitektur_Kurzbericht_ENG_00-01-00.pdf|IVS-Rahmenarchitektur Schlussbericht Kurzbericht ENG Entwurf.pdf]]
*[[Media:IVS-Rahmenarchitektur_Schlussbericht_DTS_10-00-02.pdf|IVS-Rahmenarchitektur Schlussbericht DTS Entwurf.pdf]]

Los 2: IVS-Referenzarchitektur für Verkehrsinformation im Individualverkehr

*[[Media:Los2_IVS-Referenzarchitektur_Verkehrsinformation_IV_Kurzfassung.pdf|Los2 IVS-Referenzarchitektur Verkehrsinformation IV Kurzfassung Entwurf.pdf]]
*[[Media:Los2_IVS-Referenzarchitektur_Verkehrsinformation_IV_Schlussbericht_Entwurf.pdf|Los2 IVS-Referenzarchitektur Verkehrsinformation IV Schlussbericht Entwurf.pdf]]

Los 3: IVS-Referenzarchitektur für zentralenübergreifendes Verkehrsmanagement

*[[Media:Los3_IVS-Referenzarchitektur_Kurzbericht_Entwurf.pdf|Los3 IVS-Referenzarchitektur ZUeVM Kurzfassung Entwurf.pdf]]
*[[Media:Los3_IVS-Referenzarchitektur_ZUeVM_Schlussbericht_Entwurf.pdf|Los3 IVS-Referenzarchitektur ZUeVM Schlussbericht Entwurf.pdf]]

Los 4: IVS-Referenzarchitektur für multimodale Reiseinformation

*[[Media:Los4_IVS-Referenzarchitektur_MMRI_Kurzfassung_Entwurf.pdf|Los4 IVS-Referenzarchitektur MMRI Kurzfassung Entwurf.pdf]]
*[[Media:Los4_IVS-Referenzarchitektur_MMRI_Schlussbericht_Entwurf.pdf|Los4 IVS-Referenzarchitektur MMRI Schlussbericht Entwurf.pdf]]

Schlussberichte

2018-04-09T09:59:37Z

Albrecht:

Los1: IVS-Rahmenarchitektur - ein Rahmenwerk zur Entwicklung von IVS-Architekturen

*[[Media:FE03-4083-2011-IRB_IVS-Rahmenarchitektur_Kurzfassung_DTS-ENG_00-01-02.pdf|IVS-Rahmenarchitektur Schlussbericht Kurzfassung DTS-ENG Entwurf.pdf]]
*[[Media:FE03-4083-2011-IRB_IVS-Rahmenarchitektur_Kurzbericht_DTS_00-01-00.pdf|IVS-Rahmenarchitektur Schlussbericht Kurzbericht DTS Entwurf.pdf]]
*[[Media:FE03-4083-2011-IRB_IVS-Rahmenarchitektur_Kurzbericht_ENG_00-01-00.pdf|IVS-Rahmenarchitektur Schlussbericht Kurzbericht ENG Entwurf.pdf]]
*[[Media:IVS-Rahmenarchitektur_Schlussbericht_Entwurf.pdf|IVS-Rahmenarchitektur Schlussbericht DTS Entwurf.pdf]]

Los 2: IVS-Referenzarchitektur für Verkehrsinformation im Individualverkehr

*[[Media:Los2_IVS-Referenzarchitektur_Verkehrsinformation_IV_Kurzfassung.pdf|Los2 IVS-Referenzarchitektur Verkehrsinformation IV Kurzfassung Entwurf.pdf]]
*[[Media:Los2_IVS-Referenzarchitektur_Verkehrsinformation_IV_Schlussbericht_Entwurf.pdf|Los2 IVS-Referenzarchitektur Verkehrsinformation IV Schlussbericht Entwurf.pdf]]

Los 3: IVS-Referenzarchitektur für zentralenübergreifendes Verkehrsmanagement

*[[Media:Los3_IVS-Referenzarchitektur_Kurzbericht_Entwurf.pdf|Los3 IVS-Referenzarchitektur ZUeVM Kurzfassung Entwurf.pdf]]
*[[Media:Los3_IVS-Referenzarchitektur_ZUeVM_Schlussbericht_Entwurf.pdf|Los3 IVS-Referenzarchitektur ZUeVM Schlussbericht Entwurf.pdf]]

Los 4: IVS-Referenzarchitektur für multimodale Reiseinformation

*[[Media:Los4_IVS-Referenzarchitektur_MMRI_Kurzfassung_Entwurf.pdf|Los4 IVS-Referenzarchitektur MMRI Kurzfassung Entwurf.pdf]]
*[[Media:Los4_IVS-Referenzarchitektur_MMRI_Schlussbericht_Entwurf.pdf|Los4 IVS-Referenzarchitektur MMRI Schlussbericht Entwurf.pdf]]

Datei:FE03-4083-2011-IRB IVS-Rahmenarchitektur Kurzbericht ENG 00-01-00.pdf

2018-04-09T09:58:45Z

Albrecht:

Datei:FE03-4083-2011-IRB IVS-Rahmenarchitektur Kurzbericht DTS 00-01-00.pdf

2018-04-09T09:58:22Z

Albrecht: