BI Spektrum: Der erfolgreiche Weg zu einer modernen Datenarchitektur

Ein Beitrag von André Lohse und Lukas Gomber, DATA MART Consulting

Seit 2012 setzte die öffentliche Verwaltung erfolgreich auf ein Data Warehouse, um datengetriebene Prozesse zu optimieren und komplexe Abfragen effizient zu bewältigen. Technologisch basierte die Lösung auf dem Microsoft Analytics Platform System (APS) – einer spezialisierten On-Premises-Datenbank für Massendatenverarbeitung bzw. Massive Parallel Processing (MPP). Doch mit dem angekündigten Support-Ende für APS und dem damit verbundenen Anstieg der Betriebskosten war schnell klar: Eine neue, zukunftsfähige Datenplattform musste her.

Daher wurde eine neue Data-Lakehouse-Architektur ausgewählt, definiert und ein Migrationsplan erstellt. Das zur Verfügung stehende Zeitfenster war mit nicht einmal einem Jahr recht knapp, sodass an eine Komplettmigration aufgrund der Vielzahl der Prozesse und Berichte nicht zu denken war. Schließlich sollten die bis zu 1.000 täglichen Nutzer auch weiterhin performant auf den Datenschatz zugreifen können.

In diesem Beitrag erfahren Sie, wie das Projektvorgehen gestaltet wurde, welche Herausforderungen das Projektteam bewältigen musste und wie am Ende das Projekt erfolgreich abgeschlossen werden konnte. Die Weichen für die Zukunft sind gestellt. Die Weiterentwicklung und die neuen Möglichkeiten des nun vorhandenen On-Premises Data Lakehouse können nun erschlossen werden.

In den frühen 2010er-Jahren, als der Hype um Big-Data-Lösungen gerade so richtig Fahrt aufnahm, entschied sich unser Kunde für ein traditionelles Data Warehouse, um täglich Millionen von Zeilen mit Gesundheitsdaten zu verarbeiten. Heute, ein gutes Jahrzehnt später, setzt dieselbe Organisation auf ein Spark-Cluster. Ist der öffentliche Sektor einfach immer zehn Jahre zu spät oder gibt es andere Gründe für diese Entwicklung?

Dieser Beitrag beleuchtet die Gründe und das Vorgehen bei der erfolgreichen Modernisierung einer Datenplattform im Gesundheitssektor.

Bevor das erste Data Warehouse eingeführt wurde, gab es keine zentralisierten Prozesse für analytische Daten. Stattdessen wurden Berichte manuell aus den operativen Systemen zusammengestellt – oft mit Excel – und per Mail verteilt.

Eine „Single Source of Truth“ existierte nicht, was zu inkonsistenten Zahlen in verschiedenen Abteilungen führte. Ein standardisiertes, automatisiertes Reporting? Fehlanzeige. Besonders herausfordernd war der Umgang mit den Millionen von Zeilen an Daten, die täglich geladen werden mussten und unterschiedlich aufbereitet wurden.

Zudem mussten externe Stakeholder mit aktuellen und korrekten Zahlen versorgt werden – eine Aufgabe, die oft sehr viel Zeit in Anspruch nahm.

Hinzu kam das Fehlen einer konsistenten Datenhistorie, was Analysen über längere Zeiträume erschwerte. Kurzum: Wer Daten suchte, musste wissen, wen er fragen musste – und hoffen, dass die Antwort noch aktuell war. Wer verschiedene Personen fragte, erhielt unterschiedliche Antworten auf die gleiche Frage.

Der wichtigste Grund für die Einführung des Data Warehouse war daher die Prozesssicherheit für das Standardberichtswesen: Prozesssicherheit, die Datenqualität und Aktualität in jedem Fall sicherstellen sollte, um das Standardberichtswesen für interne und externe Stakeholder zuverlässig mit Daten zu versorgen.

Um die großen Datenmengen zu bewältigen, hatte sich die Organisation bereits im Jahr 2012 für ein Parallel Data Warehouse (PDW) auf der APS entschieden. Da der Support für die Appliance nun auslief, war es höchste Zeit für eine neue Lösung.

Was leistet die bestehende Data-Warehouse-Lösung?

Mit der Etablierung des Data Warehouse hatte die Organisation eine robuste Datenplattform geschaffen, die den Anforderungen an Sicherheit, Verfügbarkeit und Performance gerecht wurde. Doch welche Stärken brachte die Lösung konkret mit? Ein Blick auf die Kernfunktionen zeigt, warum sie über Jahre hinweg das Rückgrat des Berichtswesens bildete.

Datenbeschaffung: Schnelle Integration bei minimaler Quelllast

Die größte Herausforderung in der Datenbeschaffung war das schiere Volumen: Milliarden von Datensätzen müssen täglich verarbeitet werden – und das möglichst, ohne die operativen Systeme zu belasten. Die Lösung setzte auf eine metadatengetriebene Steuerung der Datenbeladung, die effizient steuerte, welche Daten wann extrahiert und integriert wurden. Durch eine intelligente Parallelisierung konnte das System große Datenmengen performant verarbeiten und ins Data Warehouse überführen.

Datenspeicherung: Klare Strukturen für Konsistenz und Historie

Die Architektur des Data Warehouse basierte auf einem Schichtenmodell, das eine klare Trennung zwischen Rohdaten und fachlich transformierten Daten gewährleistet. Der dreischichtige Aufbau folgt einer hybriden Modellierung aus dem Kimball- und Inmon-Modell [Ser24, S. 118]. Eine vollständige und verlustfreie Historisierung aller Daten bildet einerseits die Grundlage für die Single Source of Truth in allen fachlichen Prozessen und stellt andererseits sicher, dass das Quellsystem nur für neue Daten unter Last gesetzt werden muss. Die fachlichen Daten werden als dimensionales Modell aufbereitet und sind so für viele Prozessschritte im BI-Frontend abfrageoptimiert verfügbar.

Datenverarbeitung: Saubere Trennung von fachlicher und technischer Transformation

Ein zentrales Prinzip der Datenverarbeitung war die strikte Trennung zwischen fachlicher und technischer Transformation – das erhöht die Zuverlässigkeit und Wartbarkeit des gesamten Datenprozesses. Die hohe Komplexität beider Prozesse, die stabile CRUD-Operationen (Create, Read, Update, Delete) für Merges, Partitions-Switches, temporäre Tabellen und Co. unverzichtbar machen, setzt höchste Ansprüche an die Transaktionssicherheit.

Nur ACID-Prozesse (Atomicity, Consistency, Isolation, Durability – Atomarität, Konsistenz, Isolation und Dauerhaftigkeit) können die Integrität der Daten über die gesamte Prozesskette garantieren.

Datenbereitstellung: Hohe Performance für viele Nutzer

Das Data Warehouse bildete die Basis für ein umfangreiches Standardberichtswesen mit über tausend täglichen Nutzern. Dabei galt es, eine hohe Abfrage-Performance auch bei starker gleichzeitiger Nutzung sicherzustellen. Das System war darauf optimiert, analytische Abfragen effizient auszuführen und große Datenmengen innerhalb kürzester Zeit bereitzustellen – eine essenzielle Voraussetzung für verlässliche Berichterstattung.

Einerseits ist das System für die parallele Verarbeitung großer Datenmengen optimiert. Die parallele Abfrage vieler Nutzer stellt das System aber vor Performance-Probleme. Ein neues System muss in jedem Fall eine hohe Abfrage-Concurrency besser verarbeiten können als das Parallel Data Warehouse (PDW/APS) .

Datenverwaltung: Höchste Sicherheitsstandards für sensible Gesundheitsdaten

Im Gesundheitssektor steht Datenschutz an oberster Stelle. Die alte On-Premises-Lösung war darauf ausgerichtet, sensible personenbezogene Daten mit höchster Sicherheit zu speichern und zu verarbeiten. Die Lösung erfüllte alle regulatorischen Anforderungen und bot eine sichere Umgebung für den Umgang mit vertraulichen Informationen. Zur Verwaltung gehört auch der Administrationsaufwand für die Infrastruktur, und hier liegt ein weiterer Nachteil des bestehenden DWH:

Die PDW-Appliance war gemessen an heutigen Standards recht wartungsintensiv. Die Aussteuerung der Parallelität hat auf Hardware- wie auf Softwareseite zusätzliche Aufwände produziert.

Technologieentscheidung: Zukunftsfähigkeit im Fokus

Die bestehende Lösung hatte über Jahre hinweg zuverlässig funktioniert und die Basis für ein professionelles Berichtswesen geschaffen. Doch mit dem nahenden Support-Ende und den sich wandelnden Anforderungen war klar: Ein technologischer Umbruch war unausweichlich. Die Frage lautete nicht mehr, ob, sondern wie die Plattform modernisiert werden sollte.

Cloud oder nicht Cloud?

Die Modernisierung eines Data Warehouse ist nicht nur eine Frage der Software, sondern auch der Infrastruktur. Die zentrale Entscheidung zu Beginn des Projekts lautete: Wagen wir den Schritt in die Cloud oder bleiben wir On-Premises? Die Vorteile der Cloud sind verlockend: Sie bietet Flexibilität, Skalierbarkeit und eine hohe Innovationsgeschwindigkeit. Neue Technologien können schnell implementiert werden, und der administrative Aufwand für Wartung und Betrieb ist geringer als bei einer eigenen Infrastruktur.

Doch für eine Organisation im öffentlichen Gesundheitssektor geht es nicht nur um Effizienz – Sicherheit, Kontrolle und Kosten spielen eine entscheidende Rolle [Ser24, S. 226].

Sicherheit: Absolute Kontrolle über die Daten

Gesundheitsdaten gehören zu den sensibelsten Informationen. Eine Cloud-Lösung hätte bedeutet, dass Daten außerhalb der eigenen Infrastruktur verarbeitet und gespeichert werden – selbst bei zertifizierten Anbietern eine Herausforderung. Eine On-Premises-Lösung hingegen gewährleistete 100-prozentige Kontrolle darüber, wo und wie die Daten gespeichert und verarbeitet werden. Da die Sicherheitsanforderungen sehr hoch sind und in vielen Cloud-Umgebungen nur schwer oder gar nicht umsetzbar wären, war dies eines der gewichtigsten Argumente gegen die Cloud.

Kosten: Berechenbarkeit versus Skalierbarkeit

Cloud-Dienste sind in der Regel nutzer- und ressourcenabhängig bepreist. Hohe Zugriffszahlen und die regelmäßige Verarbeitung großer Datenmengen führen schnell zu steigenden Betriebskosten – ein Risiko, das schwer vorhersehbar ist.

Eine On-Premises-Lösung mag in der Anschaffung teurer sein, doch die Kosten sind langfristig besser zu kontrollieren. Investitionen in Hardware und Lizenzen sind einmalig oder langfristig planbar, während Cloud-Kosten dynamisch schwanken.

Die Entscheidung: On-Premises bleibt – vorerst

Nach Abwägung aller Faktoren entschied sich die Organisation, vorerst On-Premises zu bleiben. Die Anforderungen an Datenschutz, Sicherheit und Kostenkontrolle wogen schwerer als die Vorteile der Cloud. Gleichzeitig war klar, dass die neue Architektur die Möglichkeit für zukünftige Cloud-Integrationen offenhalten sollte – denn in einer sich schnell verändernden Technologielandschaft kann die Entscheidung von heute in wenigen Jahren schon wieder anders ausfallen.

Data Warehouse oder Data Lakehouse? Eine Entscheidung für die Zukunft

Mit der Entscheidung, die Infrastruktur vorerst On-Premises zu behalten, war noch keine Entscheidung über die zukünftige Architektur getroffen.

Die Wahl der richtigen Architektur ist eine der zentralen Fragen bei der Modernisierung einer Datenplattform. Soll die Organisation weiterhin auf ein klassisches Data Warehouse (DWH) setzen oder sich für ein Data Lakehouse entscheiden?

Für beides gibt es am Markt erprobte Technologien.

Abb. 1: Zielarchitektur des On-Premises-Lakehouse

Die Auswahl an etablierten und zukunftssicheren On-Premises-Lösungen für sehr große Datenmengen hat sich in den letzten Jahren im Vergleich zu Cloud-Lösungen deutlich weniger weit entwickelt. Bei den MPP-Datenbanken sind es vor allem Teradata und Oracles Exadata, die den Markt unter sich aufteilen. Bei der Entscheidung für eine Lakehouse-Architektur kommt man an Apache Spark und einem S3-kompatiblen Object Storage nicht vorbei.

Die Entscheidung über die Architektur bezieht sich im Wesentlichen nicht nur auf die eine oder andere Technologie, sondern sie ist auch eine strategische Entscheidung über die Prozesse für Datenbeschaffung und -verarbeitung, über die Datenspeicherung, ihre Bereitstellung und Verwaltung.

Datenbeschaffung: Ähnliche Prinzipien, neue Technologie

An den grundlegenden Prinzipien der Datenbeschaffung ändert sich wenig – allerdings bringt die Ablösung des klassischen ETL-Stacks technologische Veränderungen mit sich. Die bisherigen Ingestion-Prozesse basierten auf Stored Procedures und SQL-Server-SSIS-Jobs, Technologien, die in einer modernen Architektur kaum noch eine

Rolle spielen. Eine Umstellung war also ohnehin notwendig – ob für ein neues MPP-System (Massive Parallel Processing) oder für eine Lakehouse-Architektur.

Die Wahl fiel schließlich auf eine Lösung, die auf über Airflow orchestrierte PySpark-Jobs setzt, die von einem Spark-Cluster ausgeführt werden. Dadurch wird nicht nur der gesamte Prozess transparenter und flexibler, sondern auch erheblich schneller: Die Schreibgeschwindigkeit für Parquet-Files ist um ein Vielfaches höher als das Insert in eine relationale Tabelle [Arm20]. Allein dieser technologische Unterschied sorgt für eine deutliche Reduzierung der Ingestion-Laufzeiten.

Datenverarbeitung: Die neue Stärke des Lakehouse

Lange Zeit galt eine filebasierte Architektur als ungeeignet für komplexe Transformationen – insbesondere dort, wo Prozesssicherheit, Transaktionskonsistenz und eine zuverlässige Historisierung gefragt waren. In der Vergangenheit wäre eine Hadoop-basierte Plattform daher nie infrage gekommen. Erst die jüngste Entwicklung der Open-Table-Formate hat das Blatt gewendet [Tha24, S. 15].

Durch die in Delta-Parquet oder Apache Iceberg integrierte Metadatenverwaltung werden nun Transaktionssicherheit (mit ACID-Konformität) gewährleistet – und das mit einer Qualität, die sich kaum noch von der eines traditionellen Data Warehouse unterscheidet. Einzelne Zeilen lassen sich updaten oder löschen, Tabellen können partitioniert und indexiert werden, und all das mit Standardtechnologien [Ser24, S. 160f.]. Gleichzeitig macht der Wechsel von SQL zu Python die Verarbeitung nicht nur unabhängiger von der zugrunde liegenden Hardware, sondern auch zukunftssicher. Die Logik im Code bleibt portabel und lässt sich später mit minimalem Aufwand in eine Cloud-Infrastruktur übertragen.

Datenspeicherung: Offenheit für die Zukunft

Auch in der Datenspeicherung zeigen sich die Vorteile der neuen Architektur. Durch die Nutzung von Open-Table-Formaten wird nicht nur die Migration vereinfacht, sondern auch die Anschlussfähigkeit an moderne Analyse- und KI-Tools erheblich verbessert.

Wo ein klassisches Data Warehouse oft eine proprietäre Umgebung bildet, bleiben die Daten im Lakehouse in einem offenen Standard, der sich mit einer Vielzahl von Systemen und Open-Source-Standards verarbeiten lässt [Arm21]. Gleichzeitig musste jedoch nicht auf bewährte Prinzipien verzichtet werden. Das bisherige Schichtensystem aus Raw-, Enriched- und Curated-Layer, das eine saubere Trennung zwischen quellnahen und fachlich modellierten Daten sicherstellt, konnte problemlos beibehalten werden und entspricht in den Grundzügen etwa der von Databricks vorgeschlagenen Medallion-Architektur [Dat24]. Um den Übergang für die Organisation so reibungslos wie möglich zu gestalten, erfolgte in der ersten Phase die Migration des dimensionalen Modells und der Business-Logik im Curated-Layer als klassischer Lift-and-Shift auf einen SQL-Server. So blieben die bekannten Strukturen erhalten, während die technische Transformation im Enriched-Layer bereits vollständig in die neue Architektur migriert ist.

Datenbereitstellung: Herausforderungen und Lösungen

Die größte Herausforderung beim Wechsel zur Lake house-Architektur lag in der Datenbereitstellung. In einem Umfeld, in dem zahlreiche interne und externe Nutzer regelmäßig Berichte abrufen, müssen Abfragen performant und zuverlässig bleiben – unabhängig davon, wie viele Nutzer gleichzeitig auf das System zugreifen. Aufgrund der Multi-Node-Architektur können klassische MPP-Datenbanken bei hoher Abfrage-Concurrency schnell an ihre Grenzen stoßen – wie es auch schon im bestehenden System der Fall war.

Hier erwies sich die Architektur des neuen Systems als echter Vorteil: Da der SQL-Server als Abfrage-Schicht für das Lakehouse genutzt wird, übernimmt er die Lastverteilung und steuert die Abfragen effizienter, als ein MPP-System es könnte, da sein Single-Node-System keinen Bottleneck für viele parallele Abfragen bildet. So bleibt die Reporting-Performance auch unter hoher Belastung stabil. Zudem stellt der SQL-Server als relationaler Serving-Layer [Ser24, S. 167] sicher, dass Analysten weiterhin mit den vertrauten Werkzeugen arbeiten können, ohne sich auf neue Technologien umstellen zu müssen.

Datenverwaltung: Einfacherer Betrieb

Neben den technischen Vorteilen spielte auch die Datenverwaltung eine entscheidende Rolle. Der Wechsel von einer Shared-Nothing-MPP-Architektur zu einem Shared-Disk-Modell reduzierte den Administrationsaufwand erheblich. Die Notwendigkeit, komplexe Cluster-Set-ups zu betreiben, entfiel, während gleichzeitig Storage und Compute unabhängig voneinander skaliert werden konnten [Ser24, S. 165]. Damit konnten einige der Vorteile der Cloud auch in einer On-Premises-Umgebung realisiert werden – ein entscheidender Punkt für eine Organisation, die bewusst auf die Kontrolle über ihre Infrastruktur setzt.

Die Entscheidung: Mit dem Lakehouse in die Zukunft

Nach eingehender Analyse entschied sich die Organisation für das Data Lakehouse – nicht aus einem kurzfristigen Trend heraus, sondern aufgrund der technologischen und strategischen Vorteile. Die neue Plattform kombiniert die Stabilität und Prozesssicherheit eines klassischen Data Warehouse mit der Flexibilität und Skalierbarkeit moderner Datenarchitekturen. Mit einer klaren Strategie für die Migration kann der Übergang schrittweise erfolgen – ohne die bewährten Prinzipien der bisherigen Lösung über Bord zu werfen. Die neue Zielarchitektur (siehe Abbildung 1) bleibt den bewährten Prinzipien treu und denkt sie mit modernen Technologien konsequent weiter.

Die bisher relationale Schichtenarchitektur wird in einen S3-kompatiblen Objektspeicher überführt, in dem die Daten nun in Open-Table-Formaten abgelegt werden. Gesteuert wird das gesamte Ingestion- und Transformationsgeschehen durch PySpark-Prozesse, die mithilfe von Apache Airflow orchestriert werden. Der SQL-Server hat in dieser Architektur eine neue Rolle: Er fungiert als virtualisierte Zugriffsschicht – etwa für bestehende Analysis Services Cubes, die ROLAP-Zugriffe benötigen, sowie für das bestehende Berichtswesen mit SSRS und Power BI.

Um dem gestiegenen Bedarf an Transparenz, Kontrolle und Wartbarkeit gerecht zu werden, kommt eine Vielzahl spezialisierter Tools zum Einsatz. Container-Images werden über Harbor verwaltet, Code-Fragmente dokumentiert und die Ausführungshistorie über den Spark History Server nachvollziehbar gemacht. Doch eine moderne Lakehouse-Architektur endet nicht bei der Technik – auch Themen wie Data Governance, Datenkatalogisierung und Lineage gehören heute zur Grundausstattung.

All diese Informationen werden in DataHub zentral zusammengeführt, dokumentiert und verfügbar gemacht. So entsteht ein Gesamtbild des Systems, das nicht nur die Qualität und Nachvollziehbarkeit der Daten verbessert, sondern auch die Grundlage für eine nachhaltige Weiterentwicklung der Plattform schafft.

Der Weg zum Ziel: Bottom-up-Migration

Lehrbücher zur IT-Migration kennen klare Migrationsstrategien – die „6R“: Rehost, Replatform, Repurchase, Refactor, Retire oder Retain [Orb16]. Doch in der Praxis führt selten eine dieser Methoden allein zum Erfolg. Stattdessen war eine pragmatische Lösung gefragt, die sich an den spezifischen Anforderungen der Organisation orientierte. Dabei standen zwei Dinge im Mittelpunkt: die Ablösung des bestehenden Systems, insbesondere bei der technischen Integration der Massendaten, und ein nahtloser Übergang im Reporting. Letzterer war entscheidend, um sicherzustellen, dass alle Nutzer ihre Berichte weiterhin verwenden können und komplexe Business-Logik nicht schon zu Beginn der Migration vollständig überarbeitet werden muss.

Die bestehende Schichtenarchitektur der Datenplattform bot den idealen Rahmen für eine Migration, die sich funktional gliedern und zeitlich staffeln ließ. Wie in Abbildung 2 dargestellt, wurde der Projektverlauf entlang vier Workstreams organisiert:

• Spezifikation & Entscheidung

• Infrastrukturaufbau

• Migration

• Weiterer Aufbau

Diese Struktur erlaubte es, einzelne Komponenten zielgerichtet umzusetzen, ohne sofort alle Abhängigkeiten aufzulösen.

Im Zentrum des Migrations-Workstreams stand zunächst die Neuentwicklung der Integrationsschicht. Für die Prozesse der Datenintegration und technischen Transformation war ein vollständiges Refactoring notwendig. Die Steuerung über Metadaten, die strukturierte Historisierung sowie die Wiederverwendbarkeit zentraler Transformationen wurden beibehalten, mussten jedoch grundlegend neu in PySpark umgesetzt und mithilfe von Airflow orchestriert werden. Die Migration erfolgte zweistufig: Zuerst wurden die Bewegungsdaten überführt, da sie die größten Ressourcen beanspruchen. Erst danach folgte die Migration der Stammdaten.

Anschließend konnte das dimensionale Modell – also die obere Schicht der Plattform – mit einem Replatforming-Ansatz von der alten PDW-Instanz auf einen neuen SQL-Server übertragen werden. Ein unmittelbares Lift-&-Shift war nicht möglich, da die technologischen Unterschiede zwischen den Datenbankgenerationen zu groß waren. Dennoch konnte der Aufwand gering gehalten werden, da sich dieser fachliche Prozess weitgehend gekapselt behandeln ließ und die neuen Tabellen in der Integrationsschicht nahtlos weiterverwendet werden konnten. Durch diesen Schritt war auch die Anschlussfähigkeit an bestehende Downstream-Prozesse sichergestellt: Analysis Services Cubes, SSRS Berichte und Power BI konnten im Lift & Shift mit minimalem Aufwand migriert werden – nur mit einem neuen Endpunkt.

Abb.2: Phasen der Lakehouse-Migration

Ein begleitendes Testing stellte sicher, dass Datenqualität und Prozessverhalten in jeder Phase überprüft und validiert wurden. In einer anschließenden Stabilisierungsphase wurde die neue Architektur Ende 2024 in den regulären Betrieb überführt.

Mit diesem schrittweisen Aufbau war nicht nur sichergestellt, dass das System nach einer relativ kurzen Migrationsphase wieder betriebsbereit war, sondern auch, dass das Team nicht überfordert wurde. Das Team konnte sich schrittweise die neuen Technologien aneignen, während kritische, wartungsintensive fachliche Prozesse vorläufig in SQL und SSIS bestehen blieben.

Mit den verbesserten Skills im Team werden in der letzten Phase seit Anfang 2025 auch die komplexen fachlichen Themen nach und nach überarbeitet und die alten SSIS-Pakete, Stored Procedures und SQL-Skripte in einem gründlichen Refactoring in der neuen Technologie neu aufgebaut.

Neben der reinen Systemablösung eröffnete das neue Lakehouse-Set-up zusätzliche Chancen. Die Bereitstellung der quellnahen Daten als Delta-Files im Data Lake machte erstmals völlig neue Use- Cases möglich – insbesondere für Data Science und KI-Anwendungen. Wo zuvor die starren Strukturen einer relationalen Datenbank Grenzen setzten, ließ sich jetzt mit den Daten flexibel und explorativ arbeiten. Ein abgestuftes Governance-Konzept mit objektorientierter Sicherheit sorgt dabei für einen kontrollierten, aber flexiblen Zugriff.

Am Ende war die gewählte schrittweise Migrationsstrategie nicht nur technologisch, sondern auch wirtschaftlich die sinnvollste Lösung. Im Vergleich zu einem vollständigen Refactoring in der Cloud hielt sie die Gesamtaufwände in einem vertretbaren Rahmen. So wurde der Umstieg nicht zum abrupten Systembruch, sondern zu einer kontinuierlichen Evolution der Datenplattform – passgenau auf die Anforderungen des öffentlichen Sektors zugeschnitten.

Fazit: Mehr als nur ein technologischer Wandel

Die Migration vom klassischen Data Warehouse zum Data Lakehouse On-Premises war weit mehr als ein reines Technologie-Upgrade. Sie war ein strategischer Schritt, der die Organisation nicht nur von einem veralteten System befreite, sondern auch völlig neue Möglichkeiten für die Datenverarbeitung, Analyse und Nutzung eröffnete.

Statt einer radikalen Umstellung wurde ein pragmatischer Migrationspfad gewählt, der Kontinuität im Reporting gewährleistete und gleichzeitig den Grundstein für eine moderne Datenarchitektur legte. Die schrittweise Migration entlang der bestehenden Schichtenarchitektur stellte sicher, dass kritische Prozesse jederzeit funktionsfähig blieben und die Umstellung wirtschaftlich tragbar war.

Die Entscheidung, weiterhin On-Premises zu bleiben, folgte einer klaren Abwägung zwischen Kosten, Sicherheit und Flexibilität. Während die Cloud unbestreitbare Vorteile in Skalierbarkeit und Automatisierung bietet, wäre sie in diesem Fall mit erheblichen Herausforderungen – sowohl finanzieller als auch regulatorischer Natur – verbunden gewesen. Stattdessen gelang es, mit dem Wechsel auf eine Lakehouse-Architektur On-Premises viele Vorteile der Cloud zu realisieren, insbesondere durch die Entkopplung von Speicher- und Rechenleistung.

Am Ende zeigt dieses Projekt exemplarisch, dass Digitalisierung im öffentlichen Sektor nicht zwangsläufig hinterherhinken muss. Mit einer klugen Strategie, die auf bewährte Konzepte aufbaut, sich aber gleichzeitig den neuesten technologischen Entwicklungen öffnet, kann eine Organisation den Sprung in die Zukunft schaffen – ohne dabei bestehende Prozesse oder Nutzer zu überfordern.

Die Reise ist jedoch noch nicht zu Ende. Die neue Plattform ist so konzipiert, dass sie nicht nur die heutigen Anforderungen erfüllt, sondern auch zukünftige Entwicklungen ermöglicht. Ob erweiterte Data-Science-Anwendungen, eine spätere Cloud-Migration oder neue regulatorische Anforderungen – die Organisation ist nun technologisch flexibel aufgestellt.

Letztlich ist die wichtigste Erkenntnis dieser Migration: Es gibt nicht die eine richtige Lösung – sondern nur den richtigen Weg für die jeweilige Organisation.