Technologieauswahl-Kriterien

Einordnung

Dieses Dokument definiert die Kriterien, nach denen Programmiersprachen und technische Grundsatzentscheidungen für die Einsatzsoftware bewertet werden.

Ziel ist eine nachvollziehbare, faktenbasierte Entscheidungsgrundlage, die spätere Grundsatzdiskussionen reduziert und die Auswahl logisch herleitet.

Die Kriterien sind so formuliert, dass sie unabhängig von einer konkreten Programmiersprache anwendbar sind und sowohl Client- als auch Serveraspekte abdecken.

Geltungsbereich

Die Kriterien gelten für:

Client-Technologie (Smartphones, Windows-Arbeitsplätze, Anzeigen)
Server-Technologie (lokal, föderiert, zentral)
Programmiersprache(n) und Laufzeitumgebungen
Frameworks und Toolchains, soweit sie die Kriterien beeinflussen

Nicht Gegenstand dieses Dokuments sind:

detailliertes Datenmodell
detailliertes Synchronisationsmodell
konkrete API-Spezifikation

Referenzen

Dieses Dokument baut auf folgenden Design-Artikeln auf:

Bewertungslogik

Die Kriterien werden in drei Klassen eingeteilt:

MUSS: zwingend, andernfalls scheidet eine Option aus
SOLL: stark bevorzugt, Abweichungen müssen begründet werden
KANN: wünschenswert, kann bei Zielkonflikten entfallen

Zusätzlich wird empfohlen, je Kriterium eine kurze Begründung und eine Prüfmethode zu dokumentieren.

Grundannahmen

Für die Auswahl wird von folgenden Rahmenbedingungen ausgegangen:

Einsatzsoftware ist ein langfristiges Fachsystem (siehe Systemlebensdauer).
Betrieb und First-Level-Support erfolgt langfristig hauptamtlich, Entwicklung maßgeblich ehrenamtlich unterstützt (siehe Wartbarkeit).
Offline-Fähigkeit ist ein Grundprinzip (siehe Netzausfall).
Es existieren mehrere Endgeräteklassen mit unterschiedlichen Aufgaben (siehe Zielplattformen).

Kriterienkatalog

1. Plattformabdeckung

MUSS: Zielplattformen werden abgedeckt.

Prüffragen:

Funktioniert die Lösung auf Smartphones (iOS und Android) für Datenerfassung und Kontrolle der selbst erfassten Daten?
Funktioniert die Lösung auf Windows-Arbeitsplätzen für Analyse und Führung?
Funktioniert die Lösung auf Anzeige-Systemen (z. B. Raspberry Pi) für Lagevisualisierung?

Referenz:

Zielplattformen

2. Offline-Fähigkeit und Resilienz

MUSS: Kernfunktionen bleiben bei Netzausfall arbeitsfähig.

Prüffragen:

Können Daten lokal erfasst, bearbeitet und angezeigt werden?
Können Daten über physische Datenträger übertragen werden?
Sind Versions- und Konfliktmechanismen architekturseitig möglich?

Referenz:

Netzausfall

3. Betreibbarkeit im Hauptamt

MUSS: Systembetrieb ist mit behördlichen Strukturen realistisch.

Prüffragen:

Ist Betrieb ohne Spezialrollen und ohne Hochkomplexität möglich?
Sind Installation, Updates und Fehlersuche standardisierbar?
Ist der Betrieb ohne Kubernetes-Ökosystem realistisch umsetzbar?

Referenz:

4. Wartbarkeit und Supportfähigkeit

MUSS: Supportmodell ist umsetzbar.

Prüffragen:

Unterstützt die Technologie ein klares 1st/2nd/3rd-Level-Modell?
Können Fehler reproduzierbar diagnostiziert werden?
Gibt es etablierte Debugging-, Logging- und Monitoring-Werkzeuge?

Referenz:

Wartbarkeit

5. Langfristige Stabilität

MUSS: Technologie ist für lange Lebensdauer geeignet.

Prüffragen:

Gibt es stabile Release- und LTS-Mechanismen?
Ist das Ökosystem über viele Jahre plausibel weiter gepflegt?
Ist die Abhängigkeit von kurzlebigen Trends gering?

Referenz:

Systemlebensdauer

6. Entwicklerökosystem und Personalverfügbarkeit

MUSS: Ausreichender Entwicklerpool ist realistisch verfügbar.

Prüffragen:

Gibt es einen großen Entwicklerpool im deutschsprachigen Raum?
Gibt es einen großen Pool in Europa?
Gibt es viele Dienstleister mit Erfahrung in Behördenprojekten?
Ist die Technologie in Ausbildung und Praxis verbreitet?

Referenz:

Entwicklerökosystem

7. Einhaltung des mentalen Modells

SOLL: Technologie ermöglicht stress- und einsatztaugliche UIs.

Prüffragen:

Unterstützt die UI-Technik kurze Interaktionen und klare Strukturen?
Unterstützt sie robuste Offline-Bedienung?
Unterstützt sie schnelle Datenerfassung unter Einsatzbedingungen?

Referenz:

8. Architekturflexibilität

SOLL: Option erlaubt modulare Ausprägungen je Plattform.

Prüffragen:

Kann ein Basismodul mit plattformspezifischen Modulen kombiniert werden (Datenerfassung, Analyse, Visualisierung)?
Unterstützt die Technologie hybride Ansätze, falls notwendig?

Referenz:

9. Toolchain und Offline-Installierbarkeit

SOLL: Toolchain ist in Behördenumgebungen beherrschbar.

Prüffragen:

Ist Installation offline möglich (Pakete, Installer, Mirror)?
Sind Abhängigkeiten kontrollierbar und langfristig verfügbar?
Sind Builds reproduzierbar oder zumindest stabil nachvollziehbar?

Hinweis:

Dieses Kriterium ist später im Detail in einem eigenen Dokument (Build und Deployment) zu präzisieren.

10. Sicherheit und Integrität

MUSS: Technologie unterstützt sichere Implementierung.

Prüffragen:

Gibt es etablierte Kryptobibliotheken und sichere Defaults?
Unterstützt die Plattform sichere lokale Speicherung?
Unterstützt die Architektur nachvollziehbare Audit- und Logpfade?

Hinweis:

Dieses Kriterium ist später im Detail in einem eigenen Dokument (Sicherheitsanforderungen) zu präzisieren.

11. Performance und Skalierbarkeit

KANN: Performance reicht für Analyse und Visualisierung.

Prüffragen:

Sind typische Analyseaufgaben auf Windows-Arbeitsplätzen flüssig?
Sind Visualisierungen auf Anzeige-Systemen stabil darstellbar?
Sind mobile Geräte nicht übermäßig belastet?

Referenz:

12. Lizenz- und Abhängigkeitsrisiken

KANN: Ökosystem ist lizenzseitig beherrschbar.

Prüffragen:

Sind zentrale Abhängigkeiten OSS-kompatibel und langfristig nutzbar?
Ist der Dependency-Tree beherrschbar und auditierbar?
Gibt es geringe Abhängigkeiten von einzelnen proprietären Anbietern?

Mindestanforderungen als Ausschlusskriterien

Eine Technologieoption scheidet aus, wenn mindestens eines der folgenden Kriterien nicht erfüllt ist:

Plattformabdeckung (Zielplattformen)
Offline-Fähigkeit und Resilienz
Betreibbarkeit im Hauptamt
Wartbarkeit und Supportfähigkeit
Langfristige Stabilität
Entwicklerökosystem und Personalverfügbarkeit

Anwendung des Kriterienkatalogs

Empfohlenes Vorgehen:

Kandidatenliste festlegen (Sprachen/Stacks)
Je Kandidat MUSS-Kriterien prüfen
Nicht erfüllte MUSS-Kriterien führen zum Ausschluss
SOLL- und KANN-Kriterien bewerten und begründen
Ergebnis als nachvollziehbare Matrix dokumentieren

Die Bewertung soll dabei ausdrücklich nicht nur technische Aspekte betrachten, sondern auch Betrieb, Wartung und langfristige Organisationsrealität.

Zusammenfassung

Die Technologieauswahl erfolgt anhand objektivierbarer Kriterien, die aus Einsatzrealität, Plattformlandschaft, Offline-Anforderungen, Betriebsmodellen und Langfristigkeit abgeleitet werden.

Der Kriterienkatalog schafft damit die Grundlage, aus der die spätere Programmiersprachenwahl logisch und nachvollziehbar abgeleitet werden kann.