OeffWorkshop1: Unterschied zwischen den Versionen
Zur Navigation springen
Zur Suche springen
| Zeile 31: | Zeile 31: | ||
== Feedback == | == Feedback == | ||
| + | |||
=== Allgemein === | === Allgemein === | ||
*Insgesamt sehr positiv | *Insgesamt sehr positiv | ||
| − | * | + | *Zeitplan von allen sehr gut eingehalten, gute strukturiert und verständlich |
| − | 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“ |
| − | Gut geeignet für Vernetzung, auch mit parallelen Architekturprojekten, z.B. OMP | + | *Interesse für erste Anwendungen, z.B. in Projekt in Düsseldorf (Estel, Straßen.NRW, Prof. Ortgiese) |
| − | + | *TOGAF-Anlehnung eventuell nicht ausreichend dargestellt | |
| − | * | ||
| − | 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: === | === Lessons learned: === | ||
Version vom 11. Juli 2017, 10:28 Uhr
Inhaltsverzeichnis
Teilnehmerliste
Gesamtpräsentation
Protokoll (Entwurf)
Fotos
Fotos vom Raum
Lose
Los 1
Los 2
- Fehler beim Erstellen des Vorschaubildes: Datei mit Abmessungen größer als 12,5 MP
Los 3
Los 4
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.
Los 3
- Wertschöpfung/Mehrwert/Nutzen: Bisher werden hauptsächlich Datenströme und Verträge/Vereinbarungen gut dargestellt.
Los 4
- Wertschöpfung/Mehrwert/Nutzen: Bisher werden hauptsächlich Datenströme und Verträge/Vereinbarungen gut dargestellt.
Poster
Los 1
20170629 Workshop Poster Los1 00-01-01.pdf
Los 2
20170629 Workshop Poster Los2 00-01-00.pdf
Los 3
20170629 Workshop Poster Los3 00-01-00.pdf
Los 4
20170629 Workshop Poster Los4 00-01-00.pdf
