Repository navigation
vis
-
Aktuell ist kein Rechtemanagement implementiert. Alle können alles tun.
-
Es gibt keine vernünftige Lösung, falls keine BP zu einer DVP verfügbar ist/falls keine BP die Notlage annimmt.
-
Falls eine BP mit geringer Priorität eine Notlage annimmt werden zuvor informierte BP (mit höherer Priorität) nicht darüber informiert. Es kann zu Unklarheiten kommen, wer eine Notlage bearbeitet.
-
Falls eine BP eine Notlage löst werden andere BPs nicht über den Ausgang der Situation informiert.
-
Bei Benachrichtigungen über unterschiedliche Kanäle (außer einer App mit Push Notification), tritt die Frage auf, auf welche Weise BPs überhaupt die Annahme einer Notlage bestätigen sollen. Bei E-Mail, SMS, WhatsApp oder ähnlichen textbasierten Benachrichtigungen kann nicht direkt ein Bedienelement zur Verfügung gestellt werden, mit dem der Nutzer eine Notlage bestätigen oder ablehnen kann. Die naheliegende Idee den Nutzer eine Antwortnachricht verfassen zu lassen (Bspw. OK oder Abgelehnt) ist umständlich, fehleranfällig und aus MCI Gesichtspunkten als ungünstig zu bewerten.
-
Rechtemanagement & Sicherheitskonzept: Implementierung eines Rechtemanagements, bei dem klar definiert ist welche Personen welche Rechte haben. Umsetzung von Authentisierung und Verschlüsselung um das System abzusichern und das Sicherheitskonzept durchzusetzen.
-
Sicherstellung der Benachrichtigung Vorschlag 1: Es soll eine zentrale Stelle für jede DVP geben (mit der jeweils niedrigsten Priorität), die per Definition immer Verfügbar ist und sich um jede eingehende Notlage kümmern muss. Dies würde durch organisatorische Maßnahmen sichergestellt. Das aktuelle Konzept zur Benachrichtigung könnte beibehalten werden.
-
Sicherstellung der Alarmierung Vorschlag 2: Der Benachrichtigungsvorgang wird, sollte die letzte geeignete (verfügbare BP mit der geringsten Priorität) BP nicht reagieren, erneut bei der ersten zu benachrichtigenden BP (verfügbare BP mit der höchsten Priorität) begonnen. Optional könnten in weiteren Durchgängen auch als nicht Verfügbar gekennzeichnete BPs benachrichtigt werden. Dies könnte entweder durchgeführt werden bis eine BP antwortet oder eine bestimmte Zeit vergangen ist (1 Tag).
-
Benachrichtigung anderer BPs über die Annahme einer Notlage durch eine BP: Die Funktionalität müsste erweitert werden, alle bereits informierten BPs müssten eine Nachricht erhalten, dass die Notlage durch eine andere BP angenommen wurde.
-
Benachrichtigung über Ausgang der Situation die zur Notlage geführt hat: Die Funktionalität müsste erweitert werden, alle bereits informierten BPs müssten eine Nachricht erhalten, wie die Notlage gelöst wurde.
Alternativ entstand, im Laufe des Projekts — insbesondere im Anschluss an den Workshop mit den Sozialarbeitern — eine Vision für einen funktional gänzlich anders gearteten Notlageninformationsservice. Dieses Konzept soll die zuvor genannten Probleme lösen und gleichzeitig einen Mehrwert bieten.
Das im Folgenden dargestellte Konzept wurde nicht implementiert, stellt aber bereits die Basis für die UI-Entwürfe dar.
Die Idee ist es zu jeder Notlage eine Statusseite bereitzustellen. Auf dieser Statusseite soll, ähnlich einem Bugtracker, der Bearbeitungsstatus und die jeweilige BP, welche die Bearbeitung der Notlage übernommen hat dargestellt werden. Hat noch keine BP die Bearbeitung übernommen soll es jeder BP welche die Seite besucht möglich sein die Bearbeitung selbst zu übernehmen.
Weiterhin soll es eine Kommentarfunktion geben, mit der sich die BPs (mittels vorgegebenen Möglichkeiten und/oder Freitext) über die getätigten Maßnahmen oder erforderliche Schritte austauschen können.
Diese Kommentarfunktion soll ferner dazu genutzt werden können Maßnahmen für die Zukunft festzulegen, etwa die Aufnahme von Gebieten in die Whitelist oder anderes. Aus diesem Grund sollte die Statusseite auch für einen angemessenen Zeitraum nach Lösung der Notlage weiterexistieren. Zusätzlich ermöglicht dies anderen BPs sich über den Ausgang der Notlage zu informieren.
BPs sollen sich, je nach Wunsch, über Statusänderungen oder neue Kommentare benachrichtigen lassen können.
Die Benachrichtigung von BPs würde sich dann auf die Mitteilung beschränken, dass eine neue Notlage vorliegt und wo die entsprechende Statusseite abrufbar ist. Technisch würde das durch die Zustellung eines individuellen Links über einen beliebigen unterstützten Kommunikationskanal gelöst, welcher auf die Statusseite der Notlage zeigt. Je nach Sicherheitsanforderungen könnte der Link bereits einen Token enthalten der die BP identifiziert und autorisiert, oder es könnte eine zusätzliche Anmeldeseite vorgeschaltet werden.
Es könnten bei dieser Lösung alle BPs informiert werden, Prioritäten wären nicht mehr erforderlich. Dies könnte zusätzlich die Reaktionsgeschwindigkeit steigern. (Alternativ könnte eine nach Priorität verzögerte Benachrichtigung dennoch beibehalten werden)
Es könnte zusätzlich auf die Überprüfung der Verfügbarkeit verzichtet werden. Jede BP könnte selbst entscheiden ob sie in der Lage ist sich um die Notlage zu kümmern. (Die Prüfung der Verfügbarkeit vor Benachrichtigung könnte jedoch beibehalten werden, falls gewünscht.)
Ein zusätzlicher Vorteil durch die Statusseite wäre eine einheitliche Bedienbarkeit und die Möglichkeit (da es sich um eine Webseite/Webapp handeln würde) die Notlage von jedem Gerät aus zu bearbeiten.
-
- REST- Oliver Drotbohm
- REWE digital - Ansgar Brauner
- Containerisierung- Axel Burghof
- Eventing - Sebastian Gauder
- UI - Wolf Schlegel, Niko Hellwig
- Brownfield zu Greenfield - Christian Nockemann
- Resilience - Marion Bruns, Komal Ahluwalias
- UI bei REWE digial - Christian Fröhlingsdorf
- 8 things developers should know about microservices - Wolf Schlegel, Laura Ionescu, Felix Hammerl