OeffWorkshop1

Aus IVS-Wiki
Zur Navigation springen Zur Suche springen

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