9 · Architekturentscheidungen¶
Architekturentscheidungen (Architecture Decision Records, ADRs) halten fest, warum die ODI so gebaut ist, wie sie ist. Jeder ADR benennt den Kontext, die getroffene Entscheidung und ihre Konsequenzen. Wer später eine Entscheidung in Frage stellt oder ändern möchte, findet hier den Ausgangspunkt.
ADR-1 · Katalog-Technologie hinter einer stabilen Fassade kapseln¶
Kontext: Die ODI benötigt einen Datenkatalog, der Datensätze und Distributionen verwaltet und DCAT-AP-konform nach außen darstellt. Zum Projektzeitpunkt kamen CKAN und Piveau als Optionen in Frage; beide haben unterschiedliche APIs und Betriebsmodelle.
Entscheidung: Das Staging-Backend spricht den Datenkatalog nicht direkt an, sondern ausschließlich über den odi-ckan-service, der als Adapter/Fassade dient. Die Fassade übersetzt fachliche Aufrufe (Dataset anlegen, Distribution hochladen, veröffentlichen) in katalog-spezifische API-Calls.
Konsequenz: Die konkrete Katalog-Technologie ist austauschbar, ohne das Staging-Backend zu ändern. Parallel existiert ein odi-piveau-service nach demselben Muster. Der Nachteil ist eine zusätzliche Indirektion und ein weiterer Dienst im Stack.
ADR-2 · Mehrere gleichrangige Orchestrierungsdienste statt eines zentralen Monolithen¶
Kontext: Open Data umfasst tabellarische Daten, Geodaten, Linked Open Data und Echtzeitdaten – jeder Typ hat einen eigenen Veröffentlichungsweg mit anderen Fachdiensten und Plattformkomponenten.
Entscheidung: Statt eines zentralen Orchestrierungsdienstes gibt es mehrere gleichrangige: das Staging-Backend (tabellarische Daten), den Geodaten-Dienst (Geodaten im Geo-Stack) und den Semantic-Data-Dienst (Linked Open Data im Triple Store). Jeder ist für seinen Weg vollständig verantwortlich.
Konsequenz: Jeder Orchestrierungsdienst kann unabhängig weiterentwickelt und skaliert werden. Der Preis ist eine verteilte Verantwortung, die klare Schnittstellenabsprachen erfordert. Neue Datentypen erfordern entweder einen weiteren Orchestrierungsdienst oder eine Erweiterung eines bestehenden.
ADR-3 · Frictionless Table Schema als Strukturbeschreibung für tabellarische Datensätze¶
Kontext: Tabellarische Datensätze müssen inhaltlich geprüft werden – Spalten, Datentypen, Werteregeln. Es wurde ein offener Standard benötigt, der Schemas maschinenlesbar beschreibt und Validierung ermöglicht.
Entscheidung: Die ODI verwendet Frictionless Table Schema als verbindlichen Schema-Standard. Schemas werden im odi-schema-backend versioniert verwaltet; das odi-frictionless-backend führt die Validierung durch.
Konsequenz: Datenbereitsteller müssen ein Frictionless-Schema erstellen oder auswählen, bevor sie einen Datensatz hochladen. Das ist ein Onboarding-Aufwand, der sich durch automatisierte Schema-Inferenz im Frontend (odi-schema-staging-frontend) verringert. Der Vorteil: Jedes Schema ist maschinenlesbar und ermöglicht die automatische Erzeugung von TDR, Parquet und RDF-Repräsentationen.
ADR-4 · Keycloak-Instanz mit Federated Identity zum Dataport-IdP¶
Kontext: Verwaltungsmitarbeitende in Schleswig-Holstein haben bereits einen Dataport-Account. Eine separate Benutzerverwaltung für die ODI wäre ein Akzeptanzproblem und ein Betriebsaufwand.
Entscheidung: Die ODI betreibt einen eigenen Keycloak (Realm open-data-infrastruktur), der per Keycloak-Identity-Brokering an den Dataport Identity Provider (ebenfalls Keycloak) angebunden ist. Mitarbeitende melden sich mit ihrem Dataport-Account an; die ODI-spezifischen Berechtigungs-Claims werden im ODI-Keycloak vergeben.
Konsequenz: Keine Passwort-Duplikation, kein separates ODI-Account-Management für Verwaltungsmitarbeitende. Der ODI-Keycloak bleibt der einzige Ort, an dem ODI-Berechtigungen definiert werden. Externe Aufrufer (Fachverfahren) erhalten eigene Service-Accounts im ODI-Realm.
ADR-5 · Managed Cloud statt Eigenbetrieb von Datenbank und Objektspeicher¶
Kontext: PostgreSQL, Objektspeicher und Filesysteme müssen hochverfügbar und regelmäßig gesichert werden. Eigenbetrieb in Kubernetes (StatefulSets, PersistentVolumes) erfordert erhebliches Betriebswissen und bindet Kapazität.
Entscheidung: Die ODI verwendet ausschließlich Managed Services bei IONOS: Managed PostgreSQL-Cluster, Managed S3-Objektspeicher und NFS-Fileservice. Kubernetes-Workloads sind durchgehend zustandslos oder nutzen diese externen Services.
Konsequenz: Backup, Failover und Skalierung der Datenpersistenz sind Betriebssache von IONOS. Dafür gibt es eine Abhängigkeit von einem einzelnen Cloud-Anbieter (Vendor Lock-in). IONOS wurde gewählt, weil der Anbieter EU-ansässig ist und keine Abhängigkeit von US-Hyperscalern entsteht.
ADR-6 · GitOps mit FluxCD für automatisiertes Deployment¶
Kontext: Die ODI besteht aus über zehn Services, die unabhängig deployt werden. Manuelle Deploy-Schritte sind fehleranfällig und verlangsamen die Bereitstellung von Bugfixes und Features.
Entscheidung: Deployment erfolgt ausschließlich per GitOps: Der gewünschte Cluster-Zustand ist in den Kubernetes-Repositories (odi-kubernetes-stage, odi-kubernetes-prod) versioniert; FluxCD gleicht den tatsächlichen Zustand kontinuierlich dagegen ab. Image-Tag-Updates schreibt Flux automatisch ins Manifest und committet zurück.
Konsequenz: Entwickler:innen pushen nur Code; Build, Registry-Push, Manifest-Update und Rollout laufen automatisch. Der Cluster-Zustand ist jederzeit aus dem Git-Repository reproduzierbar. Der Nachteil: Komplexere Pipeline-Konfiguration und eine zusätzliche Abstraktionsebene, die beim Debugging berücksichtigt werden muss.