Offene Datenarchitekturen – Vendor-Lock-In vermeiden

Viele Unternehmen sind in den letzten Jahren in die Cloud gewechselt. Der Schritt war oft gut begründet: geringerer Betriebsaufwand, bessere Skalierbarkeit, schnellere Umsetzung neuer Anforderungen. Gleichzeitig hat sich mit der Cloud aber auch etwas grundlegend verändert. Die technologische Halbwertszeit ist deutlich kürzer geworden.

In der klassischen On-Premise-Welt konnte ein Data Warehouse über viele Jahre, teilweise über ein Jahrzehnt hinweg betrieben werden. Investitionen waren langfristig planbar. In der Cloud ist das anders. Plattformen, die vor wenigen Jahren noch als strategisch gesetzt galten, werden heute abgekündigt, funktional eingefroren oder durch neue Produkte ersetzt. Ein prominentes Beispiel ist Azure Synapse Analytics, das in vielen Unternehmen erst eingeführt wurde und nun faktisch keine strategische Weiterentwicklung mehr erfährt.

Damit verschiebt sich der Fokus: Es geht weniger um maximale Funktionalität, sondern stärker um Kalkulierbarkeit, Investitionsschutz und die Frage, wie stark man sich von den Entscheidungen einzelner Anbieter abhängig macht. Die großen Cloud-Vendoren verfolgen verständlicherweise das Ziel, Kunden möglichst tief in ihre Ökosysteme einzubinden. Wer alle zentralen Prozesse, Metadaten und Pipelines in proprietären Services abbildet, hat später kaum noch Handlungsspielraum.

Im Mittelstand geht es bei Datenplattformen selten um große Architekturprinzipien. Es geht darum, dass Lösungen funktionieren, langfristig nutzbar bleiben und nicht jedes Jahr neu gebaut werden müssen. In der Cloud wird genau das zunehmend schwierig. Offenheit ist in diesem Kontext kein absolutes Ziel, das man erreicht, sondern ein Weg, um Risiken zu begrenzen. Wer früh an den richtigen Stellen Standards setzt, hält sich Optionen offen, ohne alles auf einmal ändern zu müssen.

Grundlage für diesen graduellen Ansatz ist die Data-Lakehouse-Architektur. Sie trennt Storage und Compute, nutzt günstigen Objektspeicher und erlaubt gleichzeitig unterschiedliche Verarbeitungs-Engines. Für viele Organisationen ist das Lakehouse schnell adaptierbar, weil es durch flexible Skalierbarkeit einen günstigen Einstieg erlaubt und trotz meist pySpark-basiertem Arbeiten weiterhin SQL-Endpunkte für Analyse, BI und Reporting bereitstellt. Genau diese Mischung macht das Lakehouse für den viele Anwendungsfälle attraktiv und ermöglicht eine kostengünstige Überführung aus SQL-basierten Data Warehouses.

Ein sinnvoller Einstieg liegt auf der untersten Ebene: dem Datenformat. Offene Table-Formate wie Delta Lake oder Iceberg, die auf Parquet basieren, entkoppeln Speicher und Verarbeitung. Daten liegen damit nicht mehr in einer proprietären Datenbank-Engine, sondern in einem Format, das von verschiedenen Systemen gelesen werden kann. Das allein schafft noch keine vollständige Freiheit, ist aber ein robuster erster Schritt.

Ähnlich verhält es sich bei Ingestion und Transformationen. Ein einfaches Beispiel ist ein API-Call, etwa auf die Microsoft Graph API. Ob dieser Call als visuelle Pipeline in einem Cloud-Tool modelliert wird oder als Python-Code in einem Notebook umgesetzt ist, macht funktional kaum einen Unterschied. Architektonisch aber sehr wohl. Code bleibt portierbar, versionierbar und wiederverwendbar, während GUI-basierte Logik in der Regel an eine Plattform gebunden ist.

Auch beim Thema Compute lohnt Pragmatismus. Verteilte Engines wie Spark sind mächtig, aber nicht für jeden Workload notwendig. Für kleinere Datenmengen oder einfache Integrationsaufgaben reicht oft Python oder eine In-Process-Engine wie DuckDB oder Polars. Selbst mit den Bordmitteln einer SaaS-Plattform lässt sich für viele Anwendungsfälle die passende Engine finden, ohne Zeit und Geld in eigenes Cluster-Management investieren zu müssen.

Herausfordernder ist das Thema Metadaten und Lineage. Während sich bei Table-Formaten mit Delta und Iceberg klare Standards etabliert haben, ist das Ökosystem für Open Lineage und Open Metadata fragmentiert und weniger verbreitet. Hier zeigt sich, dass Offenheit nicht überall gleich weit entwickelt ist – ein weiterer Grund, schrittweise vorzugehen.

Ein häufiger Irrtum ist die Annahme, dass SaaS-Plattformen per se geschlossen seien. In der Praxis hängt es stark davon ab, wie sie genutzt werden. Auch in stark integrierten Plattformen lassen sich Offenheitsgrade erreichen, wenn bestimmte Schichten bewusst offen gehalten werden.

Werkzeuge wie dbt und Airflow spielen dabei eine wichtige Rolle. Sie ersetzen keine Plattform, sondern legen eine zusätzliche Abstraktionsschicht darüber. Transformationen werden nicht mehr als proprietäre Workflows modelliert, sondern als SQL-Modelle mit klarer Struktur, Tests und Dokumentation. Orchestrierung erfolgt nicht mehr über plattformspezifische GUIs, sondern über ein offenes Steuerungssystem. Sowohl dbt als auch Airflow sind fest im Python-Ökosystem verankert. Beide fördern ein stark codebasiertes Arbeiten, das im ersten Moment komplexer wirkt als eine grafische Oberfläche. In der Praxis skaliert dieser Ansatz jedoch deutlich besser, weil Logik in Code viel besser wiederverwenden lässt. Gerade bei wachsenden Plattformen wird dieser Unterschied schnell spürbar.

Der Mehrwert liegt nicht nur in der Portabilität. dbt kann beispielsweise eine technologieübergreifende Lineage und Dokumentation liefern – nicht nur für eine einzelne Plattform. So lassen sich bestehende On-Premise-Systeme und neue Cloud-Plattformen gemeinsam steuern und verstehen. Die Tiefe mag nicht immer mit einem proprietären Governance-Tool mithalten, dafür entsteht ein konsistentes Bild über Systemgrenzen hinweg.

Was in einer Organisation sinnvoll ist, kann in einer anderen scheitern. Größe des Teams, vorhandene Skills, Datenmengen, regulatorische Anforderungen und Cloud-Strategie unterscheiden sich erheblich. Ein hochgradig modulares Open-Source-Ökosystem, wie man es bei Unternehmen wie Uber sieht, ist für den Mittelstand in der Regel weder notwendig noch realistisch.

Gleichzeitig sind vollständig gekapselte Plattformlösungen nicht immer die beste Antwort. Die Entscheidung zwischen SaaS, PaaS und selbstbetriebenen Komponenten ist keine ideologische, sondern eine organisatorische. Wer wenig Betriebsressourcen hat, profitiert von SaaS. Wer maximale Flexibilität braucht und entsprechende Kompetenzen aufbauen kann, wird eher zu PaaS oder einzelnen Open-Source-Komponenten greifen.

Der vielleicht wichtigste Punkt: Offene Architekturen entstehen nicht durch einen radikalen Umbau. Sie entwickeln sich. Erfolgreiche Projekte zeichnen sich selten dadurch aus, dass alles neu gemacht wird. Stattdessen werden gezielt die kritischsten Stellen angepasst.

Weniger Logik in GUIs, mehr Code. Speicherung in offenen Formaten. Transformationen in einer abstrahierten Schicht. Orchestrierung außerhalb proprietärer Plattformen. Jeder dieser Schritte erhöht die Handlungsfreiheit, ohne den laufenden Betrieb zu gefährden.

In der Cloud ist Veränderung die Regel. Services kommen und gehen, Plattformen verschieben ihren Fokus, Preismodelle ändern sich. Für den Mittelstand wird damit Investitionsschutz und Optimierung laufender Kosten wichtiger als je zuvor.

Offene Datenarchitekturen bieten keine Garantie gegen Wandel, aber sie schaffen Spielräume. Nicht durch maximale Offenheit, sondern durch kluge Entscheidungen an den richtigen Stellen. Wer Architektur als evolutiven Pfad versteht, statt als starres Zielbild, kann auch in einer schnelllebigen Cloud-Welt handlungsfähig bleiben.