Full-Stack-Krisenkommunikation für Behörden

Problem und Rahmenbedingungen

Ich arbeite bei einem Unternehmen für Krisenkommunikation, dessen Software Behörden nutzen. Eine Lücke fiel besonders auf: Im Ereignisfall schickten Kommunen ihre Lageberichte noch auf Papier und als Word-Dateien an die Leitstelle ihres Kreises. Die Meldungen brauchten eine gemeinsame Struktur, einen sichtbaren Status und eine Historie.

Frühere Versionen des Produkts sind bereits ausgeliefert, und die Entwicklung geht mit neuen Versionen weiter. Das Meldemodul hat einen Feldtest mit den Kommunen eines Kreises durchlaufen und ist jetzt live; seine Ergebnisse unten stammen aus diesem Feldtest, nicht aus dem laufenden Betrieb.

Meine Rolle umfasst den gesamten Stack und mehr als ein Produkt: Web, Backend, Android-Tablets, eine Web-App für die Bevölkerung und öffentliche Anzeigen. Ich verantworte technische Entscheidungen, und andere Entwickler arbeiten nach meinen Plänen und Reviews.

Architektur

Das Meldemodul ist ein Client mit Angular und PrimeNG auf einem Backend mit Java und dem Play Framework und MySQL. Auf der einen Seite steht ein mehrseitiges Meldeformular mit Validierung, Plausibilitätswarnungen, automatischem Speichern von Entwürfen und regelbasierten Prioritätsvorschlägen. Auf der anderen Seite steht das Dashboard der Leitstelle mit kombinierbaren Filtern, Bearbeitung der Meldungen, Änderungshistorie und CSV-Export sowie einem schreibgeschützten Prüfmodus. Konten, rollenbasierte Navigation und Rechte decken jede Behörde ab.

Das Anzeigesystem für öffentliche Informationen hat eine Bedienoberfläche in Angular, eine Middleware mit Java und Play und eine Rendering-Schicht in Python, die die Mitteilung samt Karten für ein E-Paper-Panel zeichnet. Der Rollout wird über Konfiguration gesteuert: Ein neuer Standort braucht eine Standortdatei und einen einmaligen Kartenabruf, aber keine Änderung am Quellcode.

Die Entscheidungen dahinter stehen im Entscheidungsprotokoll unten, jede mit der Alternative, gegen die sie sich durchgesetzt hat.

Die Feld-Tablets

Die Tablet-App ist für Fahrzeugbesatzungen gedacht, die während eines Stromausfalls arbeiten, wenn öffentliche Netze ausfallen können. Das Tablet verbindet sich mit dem WLAN-Access-Point eines Koffers, der mit dem Fahrzeug unterwegs ist, und eine private Funkstrecke trägt den Verkehr zur Leitstelle. Eine Besatzung meldet sich bereit, erhält einen Auftrag mit seinen Stopps, wählt den nächsten Stopp, sieht die Route auf einer Offline-Karte und meldet Position, Status und Ergebnisse zurück. Textnachrichten und Notfallmeldungen laufen über dieselbe Verbindung.

Die App arbeitet auch ohne Verbindung weiter. Karte und Routing laufen auf dem Gerät, und außer Positionsmeldungen warten ausgehende Nachrichten in SQLite und werden erneut gesendet, bis sie bestätigt sind.

Die App ist älter als meine Zeit an ihr. Mein Teil war, sie von Android 6 auf 13 zu bringen, mit einer vollständigen UI-Überarbeitung, bei der ich alle Entscheidungen getroffen habe, eine Redesign-Linie mit Seitennavigation, Turn-by-Turn-Führung, aktualisierter Karte und zitierten Antworten im Chat zu bauen, und Backup und Wiederherstellung, sodass ein Techniker ein Gerät aus einer einzigen Datei vollständig neu einrichten kann. Teils hole ich mir direkt Feedback von Kunden.

Eine Web-App für die Bevölkerung

Wenn Strom und Mobilfunk ausfallen, können sich Menschen vor Ort mit einem lokalen WLAN einer Station verbinden und im Browser eine Web-App öffnen. Ich habe sie gebaut und alle Entscheidungen zu ihr getroffen.

Sie können eine geführte Notfallmeldung abgeben: die Adresse, einige kurze Fragen aus einem Entscheidungsbaum, eine Prüfung, dann das Absenden, und die Meldung erreicht die Einsatzkräfte. Sie können beschreiben, wie die Lage bei ihnen ist, und danach Anlaufstellen auf einer Karte sehen, oder selbst Hilfe anbieten. Die App ist mehrsprachig.

Es ist eine Web-App, deren Seiten ein Backend mit Java und Play aufrufen. Ist das Backend nicht erreichbar, behält der Browser die Meldung und versucht es erneut.

Arbeit an zwei Clients

Den Angular-Client gibt es in zwei Formen: den aktuellen Client und eine auf eine neuere Angular-Version migrierte Fassung mit vollständigem Redesign. Ich halte beide im Gleichschritt, sodass sich dasselbe Feature in beiden gleich verhält. Auch die Tablet-App hat ihre Redesign-Linie neben dem aktuellen Design auf Android 13.

Ergebnisse

Behörden können jetzt strukturierte Meldungen einreichen, die die Leitstelle live sieht, bearbeitet und über ihre Historie zurückverfolgen kann, statt mit Papier und Word-Dateien zu arbeiten. Das Modul hat vor dem Livegang seinen Feldtest durchlaufen, mit Konten, Rechten und einem realistischen Übungsszenario für jede teilnehmende Kommune.

Das Anzeigesystem wurde auf echter Hardware getestet. Dank der Übertragungsschicht berührte der Austausch der gesamten Hardware die Anwendung nicht. Die Tablet-App wurde auf Hardware getestet, und ihr Backup und ihre Wiederherstellung sind auf Feldgeräten ausgeliefert, nach skriptgesteuerten End-to-End-Prüfungen samt Fehlerinjektion.

Die Web-App für die Bevölkerung ist gebaut, und es ist belegt, dass ihre Meldungen die Einsatzkräfte erreichen. Zahlen aus echter Nutzung habe ich nicht, also behaupte ich keine.

Lehren

Drei Lehren sind mir geblieben. Erstens: Nebenläufigkeit auf der echten Datenbank testen; die Szenarien auf MySQL haben mir mehr gezeigt als das Nachdenken über die Sperren. Zweitens: Eine Abstraktion bewährt sich, wenn sich das dahinter wirklich ändert; der Hardwaretausch war der Test für die Übertragungsschicht, und sie hat gehalten. Drittens: In der öffentlichen Kommunikation gehört die Wortwahl zum System: Der Status muss durch Text und Symbol getragen werden, nicht allein durch Farbe, und eine technische Zustellbestätigung darf nie als Beleg ausgegeben werden, dass jemand die Anzeige geprüft hat.