OeffWorkshop1: Unterschied zwischen den Versionen
Zur Navigation springen
Zur Suche springen
Rausch (Diskussion | Beiträge) |
|||
Zeile 72: | Zeile 72: | ||
*Aus Sicht der Forschung wurde angemerkt, dass hiermit eine Referenz bereitgestellt wird, auf die sich im Rahmen von neuen F/E-Projekten im Rahmen der Beantragung als State-of-the -Art bezogen werden kann. | *Aus Sicht der Forschung wurde angemerkt, dass hiermit eine Referenz bereitgestellt wird, auf die sich im Rahmen von neuen F/E-Projekten im Rahmen der Beantragung als State-of-the -Art bezogen werden kann. | ||
*Wertschöpfung/Mehrwert/Nutzen: Bisher werden hauptsächlich Datenströme und Verträge/Vereinbarungen gut dargestellt. | *Wertschöpfung/Mehrwert/Nutzen: Bisher werden hauptsächlich Datenströme und Verträge/Vereinbarungen gut dargestellt. | ||
+ | |||
=== Aspekte Los 3 === | === Aspekte Los 3 === | ||
*Wertschöpfung/Mehrwert/Nutzen: Bisher werden hauptsächlich Datenströme und Verträge/Vereinbarungen gut dargestellt. | *Wertschöpfung/Mehrwert/Nutzen: Bisher werden hauptsächlich Datenströme und Verträge/Vereinbarungen gut dargestellt. | ||
+ | *Definition des IVS-Dienstes „Zuständigkeitsübergreifendes Verkehrsmanagement“ keine Einwände, Berücksichtigung des intermodalen Aspekts befürwortet | ||
+ | *Fokus von Los 3 darstellen, der bei den Szenarios auf „Straße“ liegt | ||
+ | *Einbindung von kleineren Städten: Prüfung, ob die Referenzarchitektur für das zuständigkeitsübergreifende Verkehrsmanagement auf kleinere, schwächere Akteure ohne eigene Verkehrsmanagementzentrale o.ä. übertragen werden kann | ||
+ | *bislang berücksichtigt die Architektur den Übertrag von Kompetenzen nicht | ||
+ | *Übertragbarkeit: Interesse seitens städtischer Vertreter (bspw. Szenario Kooperation Hessen Mobil mit Stadt Frankfurt und mit Stadt Kassel) an einem möglichen „Test“ der Referenzarchitektur vorhanden | ||
+ | *Migration: Einbindung von bestehenden Systeme in einen der Referenzarchitektur entsprechenden Zustand, bspw. durch Abbildung in einem Stadt/ Stadt-Szenario | ||
+ | *Losinterne Prüfung, ob an den unterschiedlichen Szenarien (Stadt-Land, etc.) festgehalten oder ob ein allgemeingültiges Szenario aufgrund der vielen Überschneidungen angewandt wird | ||
+ | *Geschäftsprozess: Anregungen zu dargestelltem Betriebsprozess bezüglich der Datenflüsse werden aufgenommen | ||
+ | *Abstimmung mit Los 2: Gemeinsames Treffen zur Vermeidung von Unstimmigkeiten innerhalb der Los 2 und Los 3 dargestellten Datenflüsse geplant | ||
=== Aspekte Los 4 === | === Aspekte Los 4 === |
Version vom 11. Juli 2017, 14:41 Uhr
Inhaltsverzeichnis
Teilnehmerliste
Gesamtpräsentation
Protokoll (Entwurf)
Fotos
Fotos vom Raum
Lose
- Fehler beim Erstellen des Vorschaubildes: Datei mit Abmessungen größer als 12,5 MP
Los 3
Feedback
Allgemein
- Insgesamt sehr positiv
- Zeitplan von allen sehr gut eingehalten, gute strukturiert und verständlich
- Gut geeignet für Vernetzung, auch mit parallelen Architekturprojekten, z.B. OMP
- Konstruktiv kritisches Feedback
- Theorie-Teil für Teilnehmer sehr fordernd, besonders für „Nicht-Wissenschaftler“
- Interesse für erste Anwendungen, z.B. in Projekt in Düsseldorf (Estel, Straßen.NRW, Prof. Ortgiese)
- TOGAF-Anlehnung eventuell nicht ausreichend dargestellt
Lessons learned:
- Anteil interaktiver Teil in Kleingruppen zu gering
- Taktung bei Poster-Session, sodass alle Poster viel Rückmeldung bekommen
Aspekte Los 1
- In Phase D: Betonen, dass keine Vorgaben gemacht werden, dass aber die Phase grundsätzlich relevant ist. Ins Wiki so schreiben.
- Sehr gut, dass es diesen Ansatz gibt. Höchste Zeit. Freuen.
- Auf welcher Ebene der IVS-Pyramide ist Software? Klären und dokumentieren.
- Australien und England haben ähnliche Ansätze. Australien hat dies erst vor kurzem bekannt gegeben. Sie vereinen TOGAF und FRAME. Ansatz von Australien anschauen, ggf. Kontakt aufnehmen.
- Frame abgrenzen von IVS-Rahmenarchitektur. Ist das bereits im Wiki? Wenn nicht, aufnehmen.
- Warum wird TOGAF verwendet? Folgefragen: Ist TOGAF zu abstrakt, also zu weit weg von der Praxis? Ist TOGAF nicht zu umfangreich, wenn man ja „nur schnell“ die Software entwickeln will? Gründe für TOGAF auf extra Wiki-Seite.
- Konzeptinstanziierung: Bausteine müssen durchgängig und wiedererkennbar sein. Welche Bausteine sind das? Bisher wurden nicht alle Bausteine durchgängig entwickelt. >> Nach Bearbeitung der Referenzarchitekturen aus den Erfahrungen lernen und verpflichtende Bausteine und Prioritäten festlegen.
- Darstellung der TOGAF Phasen und Schritte. Waren zwar nicht Ziel des Workshops, die notwendigen und optionalen Bausteine könnten aber anschaulicher dargestellt werden.
- Wertschöpfung: Wie kann sie besser dargestellt werden? Einzelne Akteure kombinieren oft mehrere Rollen, um Wertschöpfung zu betreiben. Bisher werden hauptsächlich Datenströme und Verträge/Vereinbarungen gut dargestellt.
- In Phase B werden Aktivitäten und Informationsobjekte dargestellt, aber erst in Phase C beschrieben.
- Darstellung von Verträgen/Vereinbarungen in Phase C: Gehören Sie nun zu Phase C oder Phase B (Governance)
Aspekte Los 2
- Von den Teilnehmern der Postersession am Poster von LOS2 wurde für das Verständnis festgehalten, dass die Rahmenarchitektur ein vor allem methodischer Rahmen für die Erarbeitung der Referenzarchitekturen darstellt.
- Anregungen aus dem universitären Bereich beinhalteten in Bezug auf den Mehrwert der Referenzarchitektur Individualverkehr die Möglichkeit einer Ausrichtung der Lehre im Sinne einer Standardisierung des IVS-Lehrstoffes im Rahmen der betreffenden Studiengänge.
- Ein weiterer wichtiger Mehrwert wird in der Übertragung und Adaption der Erkenntnisse der Referenzarchitektur in den Kontext des integrierten Bahn/Schiff-Ladungsverkehrs und die Anknüpfung an die Logistikprozesse des integrierten Warenwirtschafts- und Güterverkehrs gesehen.
- Wichtige Impulse werden durch die Referenzarchitektur in dem Bereich der Datennutzung unter dem Aspekt von Open Data im universitären Sektor und darüber hinaus erwartet.
- Als allgemeiner Vorzug wird von den Teilnehmern ebenfalls eine bessere Beherrschung der Komplexität von IVS und eine verbesserte Vermittelbarkeit der gesamtem Materie betrachtet.
- Insbesondere für Kommunen besteht ein wichtiger Mehrwert in der Bereitstellung einer Systematik bei der Behandlung von Architekturen auf dem Gebiet der IVS.
- Aus Sicht der Forschung wurde angemerkt, dass hiermit eine Referenz bereitgestellt wird, auf die sich im Rahmen von neuen F/E-Projekten im Rahmen der Beantragung als State-of-the -Art bezogen werden kann.
- Wertschöpfung/Mehrwert/Nutzen: Bisher werden hauptsächlich Datenströme und Verträge/Vereinbarungen gut dargestellt.
Aspekte Los 3
- Wertschöpfung/Mehrwert/Nutzen: Bisher werden hauptsächlich Datenströme und Verträge/Vereinbarungen gut dargestellt.
- Definition des IVS-Dienstes „Zuständigkeitsübergreifendes Verkehrsmanagement“ keine Einwände, Berücksichtigung des intermodalen Aspekts befürwortet
- Fokus von Los 3 darstellen, der bei den Szenarios auf „Straße“ liegt
- Einbindung von kleineren Städten: Prüfung, ob die Referenzarchitektur für das zuständigkeitsübergreifende Verkehrsmanagement auf kleinere, schwächere Akteure ohne eigene Verkehrsmanagementzentrale o.ä. übertragen werden kann
- bislang berücksichtigt die Architektur den Übertrag von Kompetenzen nicht
- Übertragbarkeit: Interesse seitens städtischer Vertreter (bspw. Szenario Kooperation Hessen Mobil mit Stadt Frankfurt und mit Stadt Kassel) an einem möglichen „Test“ der Referenzarchitektur vorhanden
- Migration: Einbindung von bestehenden Systeme in einen der Referenzarchitektur entsprechenden Zustand, bspw. durch Abbildung in einem Stadt/ Stadt-Szenario
- Losinterne Prüfung, ob an den unterschiedlichen Szenarien (Stadt-Land, etc.) festgehalten oder ob ein allgemeingültiges Szenario aufgrund der vielen Überschneidungen angewandt wird
- Geschäftsprozess: Anregungen zu dargestelltem Betriebsprozess bezüglich der Datenflüsse werden aufgenommen
- Abstimmung mit Los 2: Gemeinsames Treffen zur Vermeidung von Unstimmigkeiten innerhalb der Los 2 und Los 3 dargestellten Datenflüsse geplant
Aspekte Los 4
- Wertschöpfung/Mehrwert/Nutzen: Bisher werden hauptsächlich Datenströme und Verträge/Vereinbarungen gut dargestellt.