Programmiersprachen-Bewertung

Einordnung

Dieses Dokument bewertet Programmiersprachen und naheliegende Erweiterungen (Frameworks/Stacks) für das Kernsystem der Einsatzsoftware.

Wichtige Annahme: Die mobile Datenerfassung (iOS/Android) wird über MDM (Workspace ONE) organisationsweit verwaltet. Sie wird deshalb bei der Auswahl der Programmiersprache(n) für das Kernsystem nicht als zwingende Randbedingung betrachtet. Fokus ist damit:

Windows-Clients (Windows 10/11 LTSC) für Analyse/Führung/Management
Serverbetrieb on-premise (Debian; optional Windows-Server)

Referenzen:

Bewertungsmethode

Die Bewertung erfolgt entlang der MUSS/SOLL/KANN-Kriterien aus Technologieauswahl-Kriterien.

Die Kriterien werden hier in vier Gruppen verdichtet:

A) Betrieb und Langfristigkeit (Hauptamt, LTS, Wartbarkeit, Support) B) Deployment und Supply-Chain (offline installierbar, Updates, Signierung) C) Sicherheit (Grundschutz-konforme Prozesse, Auditierbarkeit, Risiken) D) Umsetzbarkeit in der Architektur (Server on-prem, Web-UI, Modularität)

Sprachen, die an MUSS-Kriterien klar scheitern, werden nicht betrachtet. Die Bewertung ist bewusst fakten- und risikoorientiert und vermeidet Präferenzen.

Architekturannahme für das Kernsystem (Tendenz)

Auf Basis der bisherigen Dokumente ist für Windows-Arbeitsplätze und Anzeigen eine Web-Oberfläche (Browser oder Desktop-Shell mit Web-UI) naheliegend. Für Server ist ein on-premise, gut betreibbarer Ansatz (kein Kubernetes-Zwang) naheliegend, häufig als modularer Monolith.

Damit ist in der Praxis meist ein Stack aus:

einer UI-Technologie (Web) und
einer Servertechnologie (on-prem) realistisch.

Kandidatenübersicht (Kernsystem)

Bewertete Sprachen:

TypeScript/JavaScript (primär UI)
Java (primär Server)
Kotlin (Server als JVM-Variante)
C#/.NET (Server, optional Windows-nahe Clients)
Go (Server)
Python (Tooling; Kernserver nur eingeschränkt empfehlenswert)
C/C++ (Spezialkomponenten)

Bewertungsmatrix (Kurzfassung)

Legende:

++ sehr gut passend
+ gut passend
o möglich, aber mit nennenswerten Risiken/Aufwand
- kritisch im Kontext der MUSS/SOLL-Kriterien

Sprache	A Betrieb/Langfristig	B Deploy/Supply	C Security	D Architekturfit
TypeScript/JS	`o`	`o`/`-`	`o`	`++` (UI)
Java	`++`	`+`	`+`	`++` (Server)
Kotlin (JVM)	`+`	`+`	`+`	`++` (Server)
C#/.NET	`++`	`+`	`+`	`++` (Server)
Go	`+`	`++`	`+`	`+` (Server)
Python	`o`	`o`/`-`	`o`	`o` (Tools)
C/C++	`o`	`+`	`o`/`-`	`o` (Spezial)

Hinweis: TypeScript/JS ist als UI sehr stark, aber als alleiniger Gesamtstack für ein langlebiges, offline-updatefähiges Behörden-Fachsystem supply-chain-seitig riskanter als klassische Enterprise-Stacks. Diese Risiken sind prinzipiell beherrschbar, erfordern aber strenge Prozesse (Mirrors, Locking, Signierung, Scanning, SBOM).

Detailbewertung je Sprache

TypeScript / JavaScript

Typische Rolle im Kernsystem:

Web-UI auf Windows (Edge/Firefox) für Analyse/Führung/Management
Dashboards/Kiosk-Anzeigen
optional: Node.js-Server (nicht zwingend)

Vorteile (fakten-/risikobasiert):

Sehr geeignet für browserbasierte UIs auf Windows und Anzeigen
Breite Auswahl an UI-Komponenten, Visualisierung, Tabellen, Karten
Gute Eignung für modulare Oberflächen (Basismodul + UI-Module)

Nachteile / Risiken:

Dependency-Bäume sind typischerweise groß und häufig aktualisiert. Das erhöht Supply-Chain-Aufwand (Lockfiles, Mirror, Scans, SBOM).
Langfristige Wartung über Jahrzehnte ist möglich, aber stark prozessabhängig (konsequente Update-Strategie, Sicherheits-Patching).
Node.js als Server ist möglich, aber für on-premise Behördenbetrieb muss Observability/Hardening bewusst standardisiert werden.

Naheliegende Erweiterungen:

UI: React oder Vue (beide etabliert; Auswahl ist sekundär, wichtiger sind Build-Disziplin, Tests, Komponentenrichtlinien).
Desktop-Shell: Electron ist etabliert, aber schwergewichtig. Tauri ist als Windows-Shell möglich, bringt aber zusätzliche Toolchain-Komplexität und WebView-Abhängigkeiten; als primäre Gesamtstrategie ist es eher riskant (siehe separate Bewertung).

Fazit:

Sehr wahrscheinlich als UI-Teil.
Als alleiniger Kern-Serverstack nur dann, wenn Supply-Chain und LTS/Update-Prozesse extrem diszipliniert umgesetzt werden.

Hier gibts mehr zu TypeScript.

Java (JVM)

Typische Rolle im Kernsystem:

Serverkern auf Debian (und optional Windows)
on-premise, modularer Monolith oder klar getrennte Module

Vorteile:

Sehr etabliert in langlebigen Enterprise-/Behörden-Systemen
Reife Build- und Betriebswerkzeuge (Tests, Monitoring, Logging)
Stabiler Betrieb über lange Zeiträume plausibel
Gute Basis für BSI-Grundschutz-konforme Prozesse (Auditierbarkeit, Rollen, Logkonzepte, Patchprozesse)

Nachteile / Risiken:

UI wird in der Praxis meist nicht in Java gebaut, sondern als Web-UI. Das ist aber eher ein Architekturmerkmal als ein Nachteil.
Ressourcenbedarf kann höher sein als bei sehr schlanken Servern, ist im on-premise Betrieb typischerweise planbar.

Naheliegende Erweiterungen:

Spring Boot: sehr verbreitet im Enterprise-Umfeld; liefert standardisierte Patterns (Konfiguration, Security, Actuator, Dependency Injection) und erleichtert Wartbarkeit gegenüber “Plain Java”, weil Konventionen und Ökosystem etabliert sind.
Alternativen: Quarkus oder Micronaut können technisch attraktiv sein, sind aber organisationsseitig oft seltener Standard als Spring.

Fazit:

Sehr hoher “Wahrscheinlichkeitskandidat” für den Serverkern.

Kotlin (JVM)

Typische Rolle im Kernsystem:

Serverkern oder Module als JVM-Variante zu Java

Vorteile:

Läuft auf JVM, kann in denselben Betriebsmodellen wie Java betrieben werden
Gute Entwicklerproduktivität, moderne Sprachfeatures
Integration mit Java-Ökosystem möglich

Nachteile / Risiken:

Im Behörden-/Dienstleisterumfeld ist Java oft verbreiteter als Kotlin. Das kann Personalverfügbarkeit und 2nd/3rd-Level-Support beeinflussen.
Für sehr konservative Langfrist-Systeme wird häufig Java bevorzugt, weil es die geringste organisatorische Reibung erzeugt.

Naheliegende Erweiterungen:

Spring Boot funktioniert ebenso mit Kotlin; das reduziert die Unterschiede im Betrieb.

Fazit:

Kandidat, wenn JVM gesetzt ist und Kotlin organisatorisch akzeptiert wird; sonst Java als konservativere Basis.

C# / .NET

Typische Rolle im Kernsystem:

Serverkern (Debian und/oder Windows)
optional: Windows-nahe Komponenten, falls nicht alles Web-UI ist

Vorteile:

Sehr etabliert im Windows- und Enterprise-Kontext
Serverseitig auch unter Linux gut betreibbar
Gute Toolchain, gute Wartbarkeit, breite Dienstleisterbasis
Sehr plausibel für langfristige Systeme mit klarer LTS-Strategie

Nachteile / Risiken:

Für maximale Portabilität nach Debian muss man Windows-spezifische Abhängigkeiten diszipliniert vermeiden.
Die Wahl von UI-Strategien im .NET-Ökosystem (z. B. Blazor, Desktop) muss gegen Browser-UI abgewogen werden; Browser-UI bleibt oft langfristig am flexibelsten.

Naheliegende Erweiterungen:

ASP.NET Core (Server): etablierter Standard für Web-APIs und Dienste.
Serverseitige Modularität: klare Modulgrenzen im Monolithen, oder wenige Dienste, ohne Microservice-Overhead.

Fazit:

Ebenfalls sehr hoher “Wahrscheinlichkeitskandidat” für Serverkern.

Go

Typische Rolle im Kernsystem:

Serverdienste auf Debian, ggf. lokale Dienste in Fahrzeugumgebungen
Schnittstellen, Gateway, Utility-Dienste

Vorteile:

Sehr einfache Deployments (einzelne Binaries)
Überschaubare Toolchain; Betrieb in on-premise Umgebungen gut kontrollierbar
Performance/Footprint günstig

Nachteile / Risiken:

Kein UI-Stack; Web-UI bleibt getrennt (TypeScript)
In vielen Behörden-/Enterprise-Kontexten ist der Entwicklerpool für Go kleiner als bei Java/.NET; das ist ein organisatorischer Risikofaktor.
Für sehr große Domänenmodelle ist Architekturdisziplin erforderlich.

Naheliegende Erweiterungen:

Server: bewusst minimalistische Architektur mit klaren Modulen.
Gute Option, wenn man “Betrieb so einfach wie möglich” priorisiert.

Fazit:

Plausibel für Server, wenn Personalverfügbarkeit gesichert ist. Sonst Java/.NET wahrscheinlicher.

Python

Typische Rolle im Kernsystem:

Tooling, Automatisierung, Import/Export, Hilfsdienste
Kernserver nur eingeschränkt empfehlenswert

Vorteile:

Sehr produktiv für Hilfstools und Datenverarbeitung
Sehr großes Bibliotheksangebot

Nachteile / Risiken:

Offline-Deployment und langfristig stabile Packaging-Strategie sind möglich, aber aufwändiger als bei Java/.NET/Go (Prozessdisziplin).
Für ein jahrzehntelanges Kern-Fachsystem ist das Risiko höher, wenn Packaging/Supply-Chain nicht extrem sauber gemanagt wird.

Naheliegende Erweiterungen:

Als Ergänzungssprache sehr sinnvoll (Skripte, Migration, ETL).
Nicht als primärer Serverkern empfohlen.

Fazit:

Sehr sinnvoll als Tooling-Sprache; als Kernserver nur mit außergewöhnlich strengen Prozessen.

C / C++

Typische Rolle im Kernsystem:

Spezialkomponenten (Performance, sehr niedrige Latenz, Treibernähe)
nicht als Hauptstack

Vorteile:

Langfristig stabile Basis, sehr gute Performance
Offline-Deployment gut beherrschbar

Nachteile / Risiken:

Höherer Entwicklungs- und Wartungsaufwand
Höheres Sicherheitsrisiko durch typische Fehlerklassen
Für ein komplexes Fachsystem organisatorisch meist zu teuer

Fazit:

Spezialfälle; als Hauptstack nicht plausibel.

Ergebnis: realistische Stack-Korridore

Aus den bisherigen MUSS-Randbedingungen, der Betriebsumgebung und den Wahrscheinlichkeiten ergeben sich für das Kernsystem realistisch nur wenige, stabile Korridore.

Korridor A (maximale Behörden- und Langfrist-Plausibilität)

UI: TypeScript
Server: Java (typisch mit Spring Boot)

Wahrscheinlichkeit: hoch Begründung: große Entwicklerpools, langfristige Stabilität, reife Betriebsmodelle, gut in on-premise Umgebungen.

Korridor B (Windows-/Behördennähe, sehr plausibel)

UI: TypeScript
Server: C#/.NET (typisch ASP.NET Core)

Wahrscheinlichkeit: hoch Begründung: sehr gute Windows-Integration, dennoch Debian-Server möglich; große Dienstleisterbasis.

Korridor C (Betrieb maximal simpel, wenn Know-how gesichert)

UI: TypeScript
Server: Go

Wahrscheinlichkeit: mittel Begründung: sehr einfache Deployments; Risiko vor allem in Personalverfügbarkeit und langfristigem Know-how.

Kotlin als Variante

Kotlin ist kein eigener Korridor, sondern eine Variante des JVM-Stacks:

Server: Kotlin statt Java, typischerweise weiterhin Spring Boot.

Wahrscheinlichkeit: mittel Begründung: technisch gut; organisatorisch abhängig von Support-/Pool.

Python und C/C++

Python und C/C++ sind im Kernsystem nicht als Hauptsprachen zu priorisieren, sondern als Ergänzung bzw. Spezialkomponente.

Festlegung

Auf Basis dieser Bewertung kommt als perfekte Wahl

Java Spring Boot mit TypeScript

für Server- und Clientanwendung infrage.