1 Einführung und Ziele
1.1 Aufgabenstellung
Das e-gov-framework ist eine Java-Bibliothek (kein eigenständiges System), die Schweizer Behörden und Ämter dabei unterstützt, E-Government-Fachapplikationen effizient und sicher zu entwickeln. Es stellt technische Grundfunktionen bereit, die in allen E-Gov-Projekten wiederkehren: regelbasierte Autorisierung auf Zeilen- und Feldebene, ein generisches Persistence-Layer mit dynamischer Filtersprache, Stammdatenverwaltung (MDM) sowie ein Command-basiertes Verarbeitungsmodell für nachvollziehbare Schreiboperationen.
Das Framework wird von ti&m AG entwickelt und über ein Maven-Repository (Artifactory) bereitgestellt. Behörden beziehen es als Abhängigkeit und bauen darauf ihre spezifischen Fachapplikationen auf.
1.2 Qualitätsziele
| Priorität | Qualitätsziel | Motivation / Szenario |
|---|---|---|
| 1 | Wartbarkeit / Developer Experience | Ein Entwicklerteam einer Behörde soll innerhalb eines Tages eine neue CRUD-Domäne (Entity, Repository, Command, REST-Endpoint) vollständig integrieren können |
| 2 | Performance der Query-Schicht | Eine gefilterte, paginierte Liste von 10 000 Entitäten muss inklusive Permission-Filter in unter 500 ms geliefert werden |
| 3 | Row-based Security | Jede Datenbankabfrage wird automatisch um rollenbasierte WHERE-Klauseln erweitert — ein Benutzer sieht niemals Datensätze, für die er keine Berechtigung besitzt |
| 4 | Stammdatenkonsistenz | Das zentrale MDM-Modul stellt sicher, dass alle Fachapplikationen identische, mehrsprachige Codelisten verwenden |
| 5 | Nachvollziehbarkeit / Audit-Trail | Jede fachliche Schreiboperation ist mit Benutzer, Zeitstempel und Status in der Command-Tabelle protokolliert (Compliance-Anforderung der Behörden) |
| 6 | Zuverlässigkeit | Das Framework verhält sich bei Pod-Ausfällen und Startfehlern vorhersehbar — Datenverlust und stiller Misserfolg werden verhindert |
| 7 | Portabilität / Datenbankflexibilität | Ein Datenbankwechsel zwischen PostgreSQL und SQL Server erfordert keine Code-Änderungen in consuming Apps |
| 8 | Betreibbarkeit | Fehlkonfigurationen werden beim Start erkannt und gemeldet, bevor Traffic auf den Pod geleitet wird |
| 9 | Testbarkeit | Integrationstests laufen ohne produktive Infrastruktur, sodass Entwickler und CI-Pipelines schnell Feedback erhalten |
1.3 Stakeholder
| Rolle | Erwartung |
|---|---|
| Framework-Team (ti&m) | Wartbare, gut testbare Codebasis; klare Release-Prozesse via Semantic Release |
| Entwicklerteams der Behörden | Schneller Einstieg, geringe Boilerplate, stabile API zwischen Minor-Versionen |
| Behörden / Ämter (Betreiber) | Compliance mit Sicherheitsvorgaben, stabiler Betrieb, klar dokumentierte Konfiguration |
| Endnutzer (Sachbearbeiter) | Schnelle Antwortzeiten, korrekte Zugriffskontrolle auf Daten |
| Sicherheitsverantwortliche | Nachvollziehbarer Audit-Trail (Command-Tabelle), row-based Security |