Architektur

Einordnung

In diesem Kapitel wird die Systemarchitektur der Einsatzsoftware schrittweise hergeleitet.

Ziel ist es, zunächst die wesentlichen Architekturoptionen auf Client- und Serverseite getrennt zu betrachten. Erst auf dieser Grundlage kann anschließend eine belastbare Gesamtarchitektur abgeleitet werden.

Die Betrachtung erfolgt dabei bewusst noch unabhängig von einer konkreten Programmiersprache. Zunächst soll geklärt werden, welche architektonischen Anforderungen sich aus den Einsatzszenarien, den Zielplattformen und den betrieblichen Rahmenbedingungen ergeben.

Vorgehensweise

Die Herleitung einer Gesamtarchitektur erfolgt in mehreren Schritten:

Prüfung der möglichen Architekturen auf Client-Seite
Prüfung der möglichen Architekturen auf Server-Seite
Umsetzung der Vorgaben zu Wartbarkeit und Betreibbarkeit
Umsetzung der Vorgaben für die zu erwartende Systemlebensdauer
Betrachtung zum Entwicklerökosystem
Betrachtung der vorgesehenen Zielplattformen
Berücksichtigung der Kriterien für die Technologieauswahl
Berücksichtigung der Vorgaben für die Betriebsumgebung
Umsetzung der zu erwartenden Interessen der IT-Sicherheit zumindest zunächst als Security-Baseline
Berücksichtigung der Betrachtungen zu Build und Deployment

Aus allen Teilbetrachtungen wird anschließend eine Gesamtarchitektur abgeleitet, die den fachlichen und technischen Anforderungen der Einsatzsoftware möglichst gut entspricht.

Teilaspekte

Client-Architektur: Entscheidungstendenz

Ausgangspunkt

Aus Zielplattformen ergeben sich drei Client-Klassen:

Smartphones (iOS/Android) für Datenerfassung und Kontrolle eigener Daten im Einsatzraum
Windows-Arbeitsplätze (Laptops/Thin-Clients) für Analyse, Führung, Datenmanagement
Lage-/Statusanzeigen (z. B. Raspberry Pi) im Kiosk-Betrieb

Zusätzlich gilt Offline-Fähigkeit als Grundprinzip (siehe Netzausfall).

Bewertung der Client-Optionen

Reine Browser-/PWA-Lösungen sind für Windows-Arbeitsplätze und Kiosk-Anzeigen grundsätzlich attraktiv (Plattformunabhängigkeit, zentraler Rollout). Für die Gefahrenabwehr werden jedoch klare Grenzen benannt: Offline-Funktionalität ist bei PWAs in kritischen Szenarien technisch begrenzt und Hardwarezugriffe sind je nach Plattform eingeschränkt (siehe geobyte-pwa).

Insbesondere für Smartphones im Einsatzraum ist ein verlässlicher Offline-Betrieb mit späterer Synchronisation entscheidend. Hier sind PWAs durch Browser-API-Lücken problematisch, z. B. fehlt die Background-Synchronization in Safari/iOS (SyncManager/SyncEvent werden nicht unterstützt, siehe mdn-sync). Das erschwert robuste Outbox-Mechanismen (späterer Upload), wie sie im Einsatz zu erwarten sind.

Native oder hybride Mobile-Clients sind für Datenerfassung daher wahrscheinlicher, da sie:

stabilen Offline-Betrieb mit lokaler Datenbank ermöglichen
Hardwarezugriffe (Kamera, GPS, Sensorik) zuverlässig abdecken
weniger abhängig vom Browser-API-Stand sind

Für Windows-Arbeitsplätze ist dagegen ein Web-UI (Browser oder Desktop-Shell mit eingebetteter Webtechnologie) naheliegend, da hier größere Displays, Tastatur/Maus und klarere Arbeitsumgebungen vorliegen (siehe Datenanalyse).

Tendenz

Es zeichnet sich eine hybride Client-Gesamtarchitektur ab:

Mobile Datenerfassung (iOS/Android): Installierbarer Client mit lokaler Datenhaltung und robustem Hardwarezugriff. Browser-only/PWA ist für diesen Teil zu riskant.
Windows-Arbeitsplätze (Führung/Analyse): Web-UI (Browser oder Desktop-Shell), da Verteilung und Wartung so vereinfacht werden. Sicherheit ist dabei nach BSI-Grundschutz für Webanwendungen explizit adressierbar (CON.10, bsi-con10).
Lage-/Statusanzeigen: Kiosk-Browser oder schlanker Client, der definierte Dashboards darstellt. Betrieb bevorzugt als “Anzeige-Endpunkt” ohne lokale Fachlogik.

Modulprinzip

Die Client-Funktionalität SOLL modular aufgebaut sein:

Basismodul (Identität, lokale Daten, Protokollierung, Offline)
Mobile Module (Datenerfassung, Medien, Sensorik)
Desktop Module (Analyse, Datenmanagement, Visualisierung)
Kiosk Module (Visualisierung)

Damit bleibt eine gemeinsame Architektur möglich, ohne alle Clients funktionsgleich zu machen.

Implikation für Programmiersprachen

Diese Tendenz begrenzt den sinnvollen Sprachraum stark:

Es wird sehr wahrscheinlich mindestens eine UI-/Frontend-Technologie benötigt (Web-UI und/oder Cross-Platform-Mobile).
Mobile Clients müssen iOS/Android abdecken, ohne zwei völlig getrennte Codebasen zu erzwingen (wenn “maximal wenige Sprachen” das Ziel ist).

Als realistische Kandidaten (gesamt, über alle Clients hinweg) bleiben damit voraussichtlich nur wenige Ökosysteme übrig, insbesondere:

TypeScript/JavaScript (Web-UI, ggf. Cross-Platform Mobile)
Java oder Kotlin (JVM, Backend; ggf. Android-nahe Entwicklung)
C#/.NET (Backend, Windows-nahe Entwicklung)
Dart (falls Flutter als Mobile-Strategie gewählt wird)
Go (Backend, falls bewusst minimalistische Serverdienste gewählt werden)

Server-Architektur: Entscheidungstendenz

Ausgangspunkt

Aus Betriebsumgebung und Netzausfall folgt:

Server müssen on-premise betreibbar sein (Debian, optional Docker/ Podman)
Kein Kubernetes als Voraussetzung
Betrieb im Hauptamt, Entwicklung primär Ehrenamt, sehr lange Lebensdauer (siehe Systemlebensdauer)

Bewertung der Server-Optionen

Cloud-zentrierte Architekturen scheiden als Grundmodell aus, da sie bei längerem Infrastruktur-Ausfall nicht zuverlässig funktionieren.

Für die Gefahrenabwehr wird explizit darauf hingewiesen, dass für komplexe operative Anforderungen und lange autarke Betriebsfähigkeit klassische On-Premise-Infrastrukturen mit resilienter Architektur und lokaler Datenspeicherung weiterhin unverzichtbar sind (Siehe geobyte-pwa).

Microservices/Kubernetes erhöhen Betriebs- und Diagnosekomplexität massiv und sind mit den Randbedingungen (Hauptamt-Betrieb, keine Kubernetes-Vorgabe, Offline-Deployments) nicht kompatibel als Baseline-Ansatz.

Der IT-Grundschutz adressiert Softwareentwicklung, Betrieb, Patch-/Änderungsmanagement, Protokollierung und Notfallmanagement über eigene Bausteine (u. a. CON.8, OPS.* bsi-con8). Das spricht für überschaubare, gut auditierbare Betriebsmodelle.

Tendenz

Es zeichnet sich eine föderierte On-Premise-Architektur ab:

Lokale Einsatzinstanzen (z. B. Fahrzeug/Führungsstelle), die vollständig autark arbeiten können (inkl. lokaler Datenhaltung).
Optionale zentrale Instanz (LuK/Stab), die bei verfügbarer Konnektivität aggregiert, verteilt und auswertet.
Datenaustausch bei Bedarf auch über physische Transportwege (siehe Netzausfall).

Technisch ist als Baseline am plausibelsten:

Modularer Monolith auf Serverseite (klar getrennte Module, gemeinsamer Deployable)
Standardisierte Schnittstellen (HTTP/REST) für Clients und Anzeigen
Container optional (Docker/Podman), aber nicht zwingend

Vorbereitung für höheren Schutzbedarf

Da die Software konzeptionell auf eine spätere Hochstufung vorbereitet sein SOLL, ist relevant, dass der IT-Grundschutz auch VS-NfD als Baustein abbildet (CON.11.1 bsi-vsnfd).

Implikation für Programmiersprachen

Die Server-Tendenz erfordert:

sehr stabile, langfristig wartbare Ökosysteme
große Entwicklerpools im Behörden-/Dienstleisterumfeld
robuste Toolchains (Offline-Deployment, Signierung, Logging, Monitoring)

Damit reduziert sich der realistische Kandidatenkreis serverseitig in der Praxis typischerweise auf:

Java oder Kotlin (JVM)
C#/.NET
Go