OeffWorkshop1: Unterschied zwischen den Versionen

Aus IVS-Wiki
Zur Navigation springen Zur Suche springen
 
(66 dazwischenliegende Versionen von 5 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
== Teilnehmerliste ==
 
  
 
+
== [[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)]] ==
  
== Präsentation ==
+
== Fotos ==
  
[[Media:|Download der Folien]]
+
=== Fotos vom Raum ===
  
== Protokoll ==
+
<gallery mode="packed-hover">
 +
Image: OEWS1.jpg
 +
Image: OEWS2.jpg
 +
Image: OEWS3.jpg
 +
Image: OEWS4.jpg
 +
Image: OEWS5.jpg
 +
Image: OEWS6.jpg
 +
</gallery>
  
&nbsp;
 
  
== Fotos ==
 
  
=== Los 1 ===
+
=== Lose ===
  
[[File:Los 1 IMG 20170629 161232.jpg|200x200px|Ergebnis WS]]
+
<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>
  
=== Los 2 ===
+
== Feedback ==
  
&nbsp;
+
=== Allgemein ===
  
=== Los 3 ===
+
*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
  
&nbsp;
+
=== Lessons learned: ===
  
=== Los 4 ===
+
*Anteil interaktiver Teil in Kleingruppen zu gering
 +
*Taktung bei Poster-Session, sodass alle Poster viel Rückmeldung bekommen
  
&nbsp;
+
=== Aspekte Los 1 ===
  
&nbsp;
+
*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)
  
== Dokumentation durch die einzelnen Lose ==
+
=== Aspekte Los 2 ===
  
=== Los 1 ===
+
*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.&nbsp;
 +
*Anregungen aus dem universitären Bereich beinhalteten in Bezug auf den Mehrwert der&nbsp;Referenzarchitektur Individualverkehr die Möglichkeit einer Ausrichtung der Lehre im Sinne einer Standardisierung des&nbsp;IVS-Lehrstoffes im Rahmen der betreffenden Studiengänge.
 +
*Ein&nbsp;weiterer&nbsp;wichtiger&nbsp;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&nbsp;die Referenzarchitektur in dem Bereich der Datennutzung unter dem Aspekt von Open Data im universitären Sektor&nbsp;und darüber hinaus erwartet.
 +
*Als allgemeiner Vorzug wird von den Teilnehmern ebenfalls eine bessere Beherrschung der Komplexität&nbsp;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.&nbsp;
 +
*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.
  
&nbsp;
 
  
=== Los 2 ===
+
=== Aspekte Los 3 ===
  
&nbsp;
+
*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
  
=== Los 3 ===
 
  
&nbsp;
+
=== Aspekte Los 4 ===
  
=== 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:
 +
*&nbsp;
  
 
&nbsp;
 
&nbsp;
  
&nbsp;
+
*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 ==
  
&nbsp;
+
*[[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

Teilnehmerliste

Gesamtpräsentation

Protokoll (Entwurf)

Fotos

Fotos vom Raum


Lose

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.

Poster