11 · Risiken und technische Schulden¶
Die Zielarchitektur weist ausdrücklich darauf hin, dass einige Elemente noch im Aufbau sind. Dieses Kapitel benennt die daraus resultierenden Risiken und die bekannten technischen Schulden sachlich – ohne Bagatellisierung, aber auch ohne Dramatisierung.
Offene Baustellen (Ziel vs. aktueller Stand)¶
| Thema | Aktueller Stand | Risiko |
|---|---|---|
ODW-Frontend (open-data-web) |
Im Aufbau; Datennutzer greifen derzeit noch auf das ältere CKAN-Frontend zurück | Nutzer-seitige Erfahrung bleibt hinter der Zielarchitektur zurück; Parallelentwicklung erhöht den Abstimmungsaufwand |
| API-Gateway (Traefik) | Noch nicht vollständig deployed; NGINX Ingress übernimmt aktuell die Routing-Aufgaben | API-Management-Features (Rate-Limiting, zentrales Auth-Routing) fehlen; externe APIs sind ohne Throttling-Schutz |
| Daten-Governance (Apache Ranger) | Noch in der Entwicklung; die geplante Kontrolle darüber, welcher Client welchen Datensatz veröffentlichen darf, liegt noch nicht vor der Staging-API | Feinere Mandantensteuerung ist noch nicht durchsetzbar; Rechte werden aktuell nur über Keycloak-Claims gesteuert |
| Visualization-Stack | Grundfunktion (Vega-Lite-Diagramme als Iframes) ist implementiert; tiefere Datenkatalog-Integration noch in Arbeit | Eingeschränkte Visualisierungsmöglichkeiten gegenüber dem Zielzustand |
Technische Schulden¶
Testabdeckung variiert. Die Testtiefe ist zwischen den Diensten ungleichmäßig: Das odi-staging-backend und das odi-frictionless-backend haben automatisierte Tests; andere Dienste sind weniger umfassend abgedeckt. Das System-Test-Repository odi-testing und die FitNesse-Tests in odi-fitnesse-systemtests decken Kernprozesse end-to-end ab, aber nicht alle Edge Cases.
Docker-Compose vs. Kubernetes-Manifeste. Die lokale Entwicklungsumgebung (odi-docker-compose-deployment) muss manuell mit den Kubernetes-Manifesten synchron gehalten werden. Konfigurationsabweichungen (Umgebungsvariablen, Service-Namen) können dazu führen, dass Fehler lokal nicht reproduzierbar sind.
Direkte CKAN-Abhängigkeiten an einzelnen Stellen. Die Kapselung des Datenkatalogs über den odi-ckan-service ist das Ziel; an wenigen Stellen existieren noch direkte CKAN-Aufrufe außerhalb dieser Fassade (z. B. im CKAN-Harvester). Das erhöht den Migrationsaufwand, wenn die Katalog-Technologie gewechselt wird.
Redis-Caching im Schema-Repository. Das Schema-Repository (odi-schema-backend) nutzt Redis als Cache für Frictionless-Schemas. Bei Cache-Invalidierungen oder Redis-Ausfällen muss der Cache vollständig geleert werden; eine granulare Invalidierung einzelner Schemas ist noch nicht implementiert.
Umgang mit den Risiken¶
Die genannten Punkte sind dem Team bekannt und im Entwicklungsplan berücksichtigt. Die Fassaden-Architektur (ADR-1) und die capability-basierten Microservices (ADR-2) sind bewusst so gewählt, dass die noch offenen Themen ergänzt werden können, ohne das Gesamtsystem umzubauen. Der Einsatz von Stage als 1:1-Spiegel der Produktion sorgt dafür, dass neue Bausteine in realistischer Umgebung getestet werden, bevor sie produktiv gehen.