Betriebsumgebung

Einordnung

Dieses Dokument beschreibt die geplante und realistische Betriebsumgebung der Einsatzsoftware.

Ziel ist es, harte Randbedingungen zu dokumentieren, die spätere Architektur- und Technologieentscheidungen (insbesondere die Wahl von Programmiersprachen und Frameworks) objektiv begrenzen.

Das Dokument legt keine Programmiersprache fest, definiert aber Betriebsvoraussetzungen, die von jeder technischen Lösung erfüllt werden müssen.

Geltungsbereich

Die Betriebsumgebung wird für folgende Bereiche beschrieben:

Clients im Einsatz (Smartphones, Laptops, Thin-Clients, Monitore)
Clients in Stäben und Führungsstellen
Server-Komponenten (lokal, föderiert, zentral)
Betrieb, Wartung und Support (hauptamtlich, mit 2nd Level Ehrenamt)

Nicht Gegenstand dieses Dokuments sind:

detailliertes Datenmodell
detailliertes Synchronisationsmodell
vollständiges Sicherheitskonzept

Grundprinzipien

Einsatzfähigkeit bei Störungen

Die Software muss unter Störungen der Infrastruktur arbeitsfähig bleiben. Details sind in Netzausfall beschrieben.

Offline installierbar und nutzbar

Installation, Updates und Betrieb müssen auch ohne Internetzugang möglich sein.

Beherrschbarkeit im Behördenbetrieb

Betrieb und Support sollen im Hauptamt realistisch leistbar sein. Details sind in Wartbarkeit und Betreibbarkeit beschrieben.

Client-Umgebungen

Windows-Clients (Hauptamt)

Einsatz in LuK-Stäben, Stäben und Führungsstrukturen.

Betriebssysteme:

Windows 10 LTSC (derzeit)
Windows 11 LTSC (geplant)

Browser:

Microsoft Edge
Mozilla Firefox

Anforderungen:

offline installierbar
offline nutzbar
nutzbar ohne besondere lokale Administratorrechte, soweit möglich

Windows-Clients (Ehrenamt)

Einsatz in Fahrzeugen, Führungsstrukturen und Ausbildung.

Betriebssysteme:

Windows 10 LTSC (verbreitet)
Windows 11 LTSC (geplant)

Browser:

Microsoft Edge
Mozilla Firefox

Anforderungen:

offline installierbar
offline nutzbar

Mobile Clients (Ehrenamt)

Einsatz primär für Datenerfassung und Kontrolle eigener Daten (siehe Datenerfassung).

Betriebssysteme:

Android (verschiedene Gerätegenerationen)
iOS (iPhone, verschiedene Gerätegenerationen)

Anforderungen:

Unterstützung älterer, aber noch halbwegs aktueller Geräte
Nutzung unter Einsatzbedingungen (Handschuhe, Wetter, Stress) gemäß Mentales Modell

Hinweis:

Konkrete Vorgaben für zentrale Geräteverwaltung (MDM), App-Stores, Enterprise-Deployment oder Zertifikatsverteilung sind in dieser Phase nicht festgelegt und müssen später ergänzt werden.

Anzeige- und Visualisierungsgeräte

Einsatz als Lage- und Statusanzeigen in Führungsbereichen.

Typische Umsetzungen:

Raspberry Pi als Zuspieler im Kiosk-Betrieb
Mini-PC als Zuspieler
alternativ lokale Installation, die beim Einschalten automatisch startet

Anforderungen:

robust im Dauerbetrieb
definierter Autostart der Visualisierung
möglichst geringer Pflegeaufwand

Server-Umgebungen

Linux-Server

Serverkomponenten dürfen auf Linux betrieben werden.

Vorgabe:

Debian ist zwingend, wenn Linux als Serverplattform genutzt wird.

Begründung:

stabile Basis für Behördenbetrieb
gut beherrschbar und langfristig wartbar

Containerbetrieb

Container sind zulässig.

Zulässige Technologien:

Docker
Podman

Nicht vorgesehen:

Kubernetes oder vergleichbare Orchestrierungssysteme

Hinweis:

Container sind eine Betriebsform, kein Architekturziel. Der Betrieb muss auch ohne komplexe Orchestrierung beherrschbar bleiben.

Server-Standorte

Folgende Betriebsorte sind grundsätzlich möglich:

lokaler Server im Fahrzeug
lokaler Server in einer Führungsstelle
zentraler Server in organisationsnaher Infrastruktur

Die genaue Zielarchitektur wird in Server-Architekturoptionen hergeleitet und später konkretisiert.

Netzwerk- und Konnektivitätsannahmen

Unzuverlässige Netze im Einsatz

Netze können ausfallen oder stark eingeschränkt sein. Dies betrifft:

Mobilfunk
lokale Netze
Übergänge zwischen Netzen

Das System darf deshalb nicht voraussetzen, dass eine zentrale Serververbindung permanent besteht.

Datenaustausch ohne Netz

Der Austausch von Daten über physische Datenträger (z. B. USB) muss möglich sein.

Details sind in Netzausfall beschrieben.

Lokale Netze

Lokale Netze in Fahrzeugen oder Führungsstellen können vorhanden sein, müssen aber nicht stabil sein. Das System muss auch dann funktionieren, wenn nur ein Teil der Komponenten im lokalen Netz erreichbar ist.

Installations- und Updateanforderungen

Offline-Installation

Es muss möglich sein, Clients und Server offline zu installieren.

Beispiele:

Installer-Pakete auf Datenträgern
interne Paketquellen in einem abgeschotteten Netz
Bereitstellung über lokale Server in Führungsstellen

Offline-Updates

Updates müssen offline eingespielt werden können.

Anforderungen:

dokumentierter Updateprozess
Möglichkeit zum Rollback ist wünschenswert
klare Versionierung der ausgelieferten Artefakte

Hinweis:

Die konkrete Ausgestaltung wird später in einem eigenen Dokument zu Build und Deployment präzisiert.

Betriebs- und Supportmodell

Verantwortlichkeiten

Langfristig wird folgendes Modell angenommen:

Betrieb und First-Level-Support: Hauptamt
Second-Level-Support: technisch versierte Ehrenamtliche
Entwicklung: primär Ehrenamt, unterstützend Hauptamt möglich

Details sind in Wartbarkeit und Betreibbarkeit beschrieben.

Betrieb außerhalb zentraler Bundes-IT

Für das System wird davon ausgegangen, dass es aufgrund seiner Spezialisierung voraussichtlich nicht durch zentrale Bundesdienstleister betrieben wird, sondern organisationsintern.

Konsequenz:

Supportzyklen und Betrieb liegen langfristig in eigener Verantwortung, solange die Software benötigt wird.

Konsequenzen für Technologieentscheidungen

Aus dieser Betriebsumgebung ergeben sich mehrere direkte Konsequenzen:

Windows-Clients sind zwingend zu unterstützen.
iOS und Android sind für mobile Datenerfassung zu unterstützen.
Debian ist als Serverplattform zwingend, sofern Linux genutzt wird.
Containerbetrieb darf nur Docker oder Podman voraussetzen.
Offline-Installation und Offline-Betrieb sind zwingend.
Orchestrierungskomplexität (z. B. Kubernetes) ist zu vermeiden.

Diese Randbedingungen begrenzen den sinnvollen Lösungsraum für Programmiersprachen und Frameworks erheblich und müssen bei der Technologieauswahl konsequent berücksichtigt werden.

Zusammenfassung

Die Einsatzsoftware muss in einer gemischten Umgebung betrieben werden:

Windows 10/11 LTSC (Clients, Hauptamt und Ehrenamt)
iOS und Android (Datenerfassung im Einsatz)
Debian (Server, sofern Linux genutzt wird)
Container optional, aber nur Docker/Podman
offline installierbar und offline nutzbar

Diese Betriebsumgebung ist eine harte Grundlage für die spätere Architektur- und Technologieauswahl.