OeffWorkshop1: Unterschied zwischen den Versionen
Zur Navigation springen
Zur Suche springen
(56 dazwischenliegende Versionen von 5 Benutzern werden nicht angezeigt) | |||
Zeile 1: | Zeile 1: | ||
− | |||
− | + | == [[Media:20170629_Workshop_IVS-Rahmenarchitektur_Teilnehmerliste.pdf|Teilnehmerliste]] == | |
− | == | + | == [[Media:20170629_Workshop_IVS-Rahmenarchitektur_Gesamt_01-00-00.pdf|Gesamtpräsentation]] == |
− | + | == [[Media:2017-06-29-Protokoll-Workshop_00_00_05.docx|Protokoll (Entwurf)]] == | |
− | |||
− | == | ||
− | |||
− | [[Media:2017-06-29-Protokoll-Workshop_00_00_05.docx| | ||
− | |||
− | |||
== Fotos == | == Fotos == | ||
− | === | + | === Fotos vom Raum === |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | + | <gallery mode="packed-hover"> | |
+ | Image: OEWS1.jpg | ||
+ | Image: OEWS2.jpg | ||
+ | Image: OEWS3.jpg | ||
+ | Image: OEWS4.jpg | ||
+ | Image: OEWS5.jpg | ||
+ | Image: OEWS6.jpg | ||
+ | </gallery> | ||
− | |||
− | |||
− | == | + | === Lose === |
− | = | + | <gallery mode="traditional"> |
+ | Image: Los_1_IMG_20170629_161232.jpg | Los 1 | ||
+ | Image: Los_2_IMG_20170629_161215.jpg | Los 2 | ||
+ | Image: 20170629_Workshop_Los3_Brainstorming.jpg | Los 3 | ||
+ | Image: Los_4_IMG_20170629_161403.jpg| Los 4 | ||
+ | </gallery> | ||
− | + | == 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 | ||
− | === Los | + | === Aspekte Los 1 === |
− | + | *In Phase D: Betonen, dass keine Vorgaben gemacht werden, dass aber die Phase grundsätzlich relevant ist. Ins Wiki so schreiben. --> Scholtes | |
+ | *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. |
+ | *Aussage eines Teilnehmers: Geschäftsfall prägt Architektur! | ||
+ | *Wo und wie entsteht Wertschöpfung? | ||
+ | *Governance: Ausgewogener Partnermix, wer garantiert? Wem wird das übertragen? | ||
+ | *Wir brauchen <u>eine</u> Datenplattform in Deutschland, worüber auch das Ticketing (mindestens ÖV) abläuft. | ||
+ | *Es gibt in Deutschland „verteilte Systeme“ die angebunden werden müssen. | ||
+ | *Wie viele Plattformen <u>kann </u>es geben? (aus wirtschaftlicher Sicht) | ||
+ | *In welchen „Größeneinheiten“ (auf eine Region bezogen) kann es in Plattformen zur multimodalen Reiseinformation geben? | ||
+ | *Problem: Zentralisierung („Data Hub“ im Bild) Eine zentrale Datenplattform für die multimodale Reiseinformation wird als problematisch angesehen. | ||
+ | *Es muss eine Balance zwischen zentralen und verteilten Komponenten geben. | ||
+ | *Betriebliche Dinge müssen in den realen Systemen geregelt werden! Nicht Aufgabe der Referenzarchitektur. | ||
+ | *Ein Akteur kann mehrere Rollen einnehmen. | ||
+ | *Konkreter <u>Nutzen</u>! Wer hat den Nutzen? | ||
+ | *Was ist Rahmen- und Referenzarchitektur?! Rahmenarchitektur = Hauptstraßen?! (Wie greifen Sie ineinander? Die Rahmenarchitektur sollte mehr sein als nur die Methodik) | ||
+ | *Informationsbereitstellung öffentlicher Daten = öffentlicher Auftrag im Sinne der Daseinsvorsorge? ( = Finanzierung der öffentlichen Hand) | ||
+ | *Kann die Referenzarchitektur Mindeststandards der Datenlieferung für Kommunen definieren? | ||
+ | *Es ist wichtig die Daten aller Kommunen für eine Beauskunftung berücksichtigen zu können! (auch kleinerer Städte und Gemeinden) | ||
+ | *Rechtliche Fragestellungen beachten. Wer muss miteinander reden? | ||
+ | *Technische Expertise für Datenfusion und Haftung für Datenqualität kann nur durch ÖH geleistet werden! | ||
+ | *Prognosedaten IV? Wo gibt’s die?! (Kann diese Frage von der Referenzarchitektur beantwortet werden?) | ||
+ | *Wertschöpfungsstufen: | ||
+ | * | ||
| | ||
− | + | *Capability: Netzgrundlage für multimodale Route. | |
+ | *Gibt es eine Skalierbarkeit der Geschäftsmodelle der mulitmodalen Reiseinformation? | ||
+ | *Nationale Plattform muss kein Geld verdienen! | ||
+ | *Nicht jeder Business Case muss gerechnet <u>sein</u>! | ||
+ | *Geschäftsmodell?! <u>Gibt’s das</u>?! | ||
+ | *Entgeltfreie Beistellungen (z.B. – Daten der ÖH) können zu Wettbewerbsverzerrungen durch beteiligte Partner führen. | ||
− | + | == Poster == | |
− | + | *[[Media:20170629_Workshop_Poster_Los1_00-01-01.pdf|Workshop Poster Los 1]] | |
+ | *[[Media:_20170629_Workshop_Poster_Los2_00-01-00.pdf|Workshop Poster Los 2]] | ||
+ | *[[Media:_20170629_Workshop_Poster_Los3_00-01-00.pdf|Workshop Poster Los 3]] | ||
+ | *[[Media:_20170629_Workshop_Poster_Los4_00-01-00.pdf|Workshop Poster Los 4]] |
Aktuelle Version vom 13. Juli 2017, 09:01 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. --> Scholtes
- 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.
- Aussage eines Teilnehmers: Geschäftsfall prägt Architektur!
- Wo und wie entsteht Wertschöpfung?
- Governance: Ausgewogener Partnermix, wer garantiert? Wem wird das übertragen?
- Wir brauchen eine Datenplattform in Deutschland, worüber auch das Ticketing (mindestens ÖV) abläuft.
- Es gibt in Deutschland „verteilte Systeme“ die angebunden werden müssen.
- Wie viele Plattformen kann es geben? (aus wirtschaftlicher Sicht)
- In welchen „Größeneinheiten“ (auf eine Region bezogen) kann es in Plattformen zur multimodalen Reiseinformation geben?
- Problem: Zentralisierung („Data Hub“ im Bild) Eine zentrale Datenplattform für die multimodale Reiseinformation wird als problematisch angesehen.
- Es muss eine Balance zwischen zentralen und verteilten Komponenten geben.
- Betriebliche Dinge müssen in den realen Systemen geregelt werden! Nicht Aufgabe der Referenzarchitektur.
- Ein Akteur kann mehrere Rollen einnehmen.
- Konkreter Nutzen! Wer hat den Nutzen?
- Was ist Rahmen- und Referenzarchitektur?! Rahmenarchitektur = Hauptstraßen?! (Wie greifen Sie ineinander? Die Rahmenarchitektur sollte mehr sein als nur die Methodik)
- Informationsbereitstellung öffentlicher Daten = öffentlicher Auftrag im Sinne der Daseinsvorsorge? ( = Finanzierung der öffentlichen Hand)
- Kann die Referenzarchitektur Mindeststandards der Datenlieferung für Kommunen definieren?
- Es ist wichtig die Daten aller Kommunen für eine Beauskunftung berücksichtigen zu können! (auch kleinerer Städte und Gemeinden)
- Rechtliche Fragestellungen beachten. Wer muss miteinander reden?
- Technische Expertise für Datenfusion und Haftung für Datenqualität kann nur durch ÖH geleistet werden!
- Prognosedaten IV? Wo gibt’s die?! (Kann diese Frage von der Referenzarchitektur beantwortet werden?)
- Wertschöpfungsstufen:
- Capability: Netzgrundlage für multimodale Route.
- Gibt es eine Skalierbarkeit der Geschäftsmodelle der mulitmodalen Reiseinformation?
- Nationale Plattform muss kein Geld verdienen!
- Nicht jeder Business Case muss gerechnet sein!
- Geschäftsmodell?! Gibt’s das?!
- Entgeltfreie Beistellungen (z.B. – Daten der ÖH) können zu Wettbewerbsverzerrungen durch beteiligte Partner führen.