Warum moderne Datenarchitektur im Produktivbetrieb scheitert

Jeder Platform-Lead, der derzeit eine Data-Warehouse-, Lake- oder Lakehouse-Migration plant, trifft eine Personalentscheidung, bevor er eine Technologieentscheidung trifft – und die meisten merken das noch nicht. Der Blueprint sieht im Vendor-Deck immer sauber aus. Die Frage ist, ob die Engineering-Organisation, die man tatsächlich hat – nicht die im RFP – diesen Blueprint noch achtzehn Monate später betriebsfähig halten kann.

Das ist die unbequeme These eines neuen Forbes-Technology-Council-Beitrags von Enterprise-CIO Thai Vong, und sie trifft genau in dem Moment ein, in dem Platform-Teams siebenstellige und achtstellige Budgets für KI-fähige Datenstacks committen. Die Architektur ist selten das, was bricht. Das Betriebsmodell drumherum schon.

Das Problem

Die Standard-Modernisierungsgeschichte läuft so ab: Ein Platform-Team wählt ein Muster (Warehouse, Lake oder Lakehouse), rechtfertigt die Plattformwahl im Steuerungsausschuss und liefert ein Referenzarchitekturdiagramm mit sauberen Boxen für Ingestion, Transformation und Serving. Zwölf bis achtzehn Monate später verlangsamt sich die Auslieferung, der On-Call-Betrieb wird unangenehm, und eine kleine Änderung an einem Quellsystem breitet sich durch Pipelines aus, die niemand wirklich besitzt.

Wie Forbes berichtete, argumentiert Vong, dass der häufigste Fehler darin besteht, eine Architektur danach auszuwählen, was sie kann, statt danach, was die Organisation realistischerweise betreiben kann. Dieser Satz klingt nach Consulting-Boilerplate, bis man ihn auf ein Budget überträgt. Capability ist eine Zeile, die der CFO versteht. Operability ist ein Headcount-Gespräch, das der CFO bislang vertagt hat.

Das technische Muster, das Vong beschreibt, ist jedem vertraut, der eine fünf Jahre alte Datenplattform übernommen hat. Pipelines vermehren sich. Transformationen werden über Teams hinweg dupliziert, die voneinander nichts wussten. Legacy-Code, hardcodierte Logik und Notlösungen häufen sich an, um frühere Systemgrenzen zu kompensieren, und sie werden länger als nötig mitgeschleppt. Das Ergebnis ist technischer Ballast und das, was Vong als institutionelles Wissensrisiko bezeichnet: zu viel Verständnis konzentriert sich auf zu wenige Personen.

Was sich 2026 verändert hat, ist die Last. KI-Anwendungsfälle sind nun eine explizite Anforderung an diese Plattformen, keine Future-State-Folie mehr. Das bedeutet, dass dieselben Architekturen, die tolerierbar waren, als sie wöchentliche BI-Dashboards belieferten, jetzt erwartet werden, Feature Stores, Retrieval-Pipelines und Model-Evaluation-Harnesses zu speisen. Die Flexibilität, die Lakes und Lakehouses bieten – viele Daten schnell zu sammeln und zu nutzen, ohne alles vorab perfekt zu organisieren, in Vongs Formulierung – wird zu einer operativen Verbindlichkeit, sobald nachgelagerte Verbraucher Freshness-SLAs in Minuten statt Tagen erwarten.

Der aufschlussreiche Vergleich: Ein warehouse-zentrischer Stack erzwingt Alignment-Kosten vorab, ein Lake verschiebt sie. Aufgeschobenes Alignment wächst mit der Zeit. Im dritten Jahr zahlt das Team Zinsen.

Die Optionen im Überblick

Ohne Marketing-Schicht betrachtet, wählen Platform-Leads zwischen drei Mustern, jeweils mit einem unterschiedlichen Betriebsprofil.

Warehouse-zentrisch (Snowflake, BigQuery, Redshift). Struktur und Konsistenz sind die Verkaufsargumente. Schema-Disziplin wird durch die Plattform selbst durchgesetzt, was bedeutet, dass ein kleineres Analytics-Engineering-Team die Dinge im Griff behalten kann. Der Kompromiss ist Governance-Overhead bei der Ingestion und eine Rechnung, die mit dem Compute auf eine Weise skaliert, die Finance-Teams fürchten gelernt haben. Snowflakes Dokumentation ist explizit zu Workload-Isolation-Mustern, aber Isolation ist auch, wie sich Ausgaben still verdreifachen.

Lake-first (Object Storage plus Query Engines). Maximale Flexibilität, niedrigste Speicherkosten und die Möglichkeit, Daten zuerst zu landen und später zu entscheiden, was damit zu tun ist. Der Haken ist, dass ohne starke Engineering-Kontrollen die Logik auf zu viele Pipelines verteilt wird und Teams dasselbe Problem auf unterschiedliche Weisen lösen. Vongs Worte. Debugging verlangsamt sich. Die Plattform funktioniert technisch, wird aber zunehmend schwieriger zu betreiben.

Lakehouse (Databricks, offene Tabellenformate wie Iceberg und Delta). Die aktuelle Konsensantwort, die Flexibilität und Struktur ausbalanciert. Databricks und das Open-Table-Format-Ökosystem haben das im großen Maßstab glaubwürdig gemacht. Aber Lakehouse-Architekturen erben die operative Komplexität beider Eltern. Man braucht gleichzeitig Governance auf Warehouse-Niveau und Engineering-Disziplin auf Lake-Niveau.

Der Entscheidungsrahmen, den ich Platform-Leads empfehlen würde, lautet: Jedes Modell trägt ein unterschiedliches Maß an Komplexität, Flexibilität und Governance-Overhead. Mehr Flexibilität erfordert mehr Disziplin. Mehr Struktur erfordert mehr Alignment vorab. Die Build-vs.-Buy-Frage kollabiert zu einer Personalfrage. Ein Warehouse-Stack könnte mit drei Analytics Engineers und einem Teilzeit-Platform-Engineer laufen. Ein Lakehouse mit vergleichbarem Umfang benötigt realistischerweise ein dediziertes Platform-Team, eine Data-Reliability-Funktion und ein Transformation-Framework wie dbt mit ausgereiften CI-Konventionen, bevor irgendetwas in die Produktion geht.

Für analytics-lastige Workloads, bei denen Query-Latenz dominiert, ist eine OLAP-Engine wie ClickHouse nachgelagert zu beiden Mustern zunehmend die richtige Antwort – kein Ersatz für die Plattformentscheidung, sondern die Erkenntnis, dass eine Engine nicht alle Workloads sauber bedient.

Die Vendor-Lock-in-Dimension ist real und wird selten ehrlich modelliert. Offene Tabellenformate reduzieren sie. Proprietäre Stored Procedures und warehouse-spezifische SQL-Erweiterungen erhöhen sie. Wer auch immer diese Entscheidung trifft, sollte sie explizit im Architecture Review festhalten – und nicht beim Vertragsverlängerungsgespräch entdecken.

Was Data-Teams konkret tun sollten

Vong identifiziert vier Qualitäten von Architekturen, die sich langfristig bewähren: beobachtbare Pipelines, wiederverwendbare Transformationen, kontrollierte Deployments und eine Gesamtarchitektur, die auch beim Wachsen verständlich bleibt. Das sind keine Plattform-Features. Es sind Ergebnisse von Engineering-Entscheidungen, und sie sind der richtige Bewertungsmaßstab für jede Vendor-Evaluierung in diesem Quartal.

Das in Maßnahmen übersetzen: Vor dem Unterzeichnen eines mehrjährigen Vertrags sollte der Platform-Lead vier Fragen konkret beantworten können. Wie überwachen wir einen Pipeline-Fehler von Anfang bis Ende, und wer wird benachrichtigt? Wie verhindern wir, dass zwei Teams dieselbe Transformationslogik schreiben, und welche Review-Oberfläche erkennt das? Wie sieht ein Deployment aus, und wie rollen wir es zurück? Wenn im neunten Monat ein neuer Engineer eintritt, kann er das System allein aus der Dokumentation verstehen, oder ist er von drei Personen abhängig, die sich zufällig daran erinnern, warum ein bestimmter SQL-View existiert?

Wenn diese Antworten vor der Beschaffung nicht existieren, werden sie danach nicht magisch auftauchen. Die Lücke zwischen gut gestalteter und nachhaltiger Datenarchitektur ist, so Vong, selten die Technologie selbst. Es sind die Engineering-Kontrollen drumherum.

Meine Einschätzung: Die richtige Reihenfolge ist, zuerst in Transformation-Tooling, Observability und Deployment-Disziplin zu investieren und dann die Plattform auszuwählen. Die meisten Organisationen machen das rückwärts, weil die Plattformentscheidung die mit Executive-Rückendeckung und einer Budgetzeile ist. Die Kontrollen werden später hinzugefügt – unter Druck, nach dem ersten größeren Vorfall.

Fallstricke und Sonderfälle

Der CFO eines Unternehmens, das in diesem Quartal eine Lakehouse-Migration evaluiert, sollte dem VP of Engineering eine spezifische Frage stellen: Was sind die vollständig eingerechneten Betriebskosten über sechsunddreißig Monate, einschließlich des Headcounts für Pipeline-Observability und Transformation-Reuse – nicht nur den Plattformvertrag. Die meisten TCO-Modelle, die dem Finance-Bereich präsentiert werden, unterschätzen die Personalkosten um den Faktor zwei oder drei, und das ist die Lücke, die aus einer sauberen Migration einen mehrjährigen Overrun macht.

Diese Fehlermuster sollte man beim Rollout im Blick behalten: Kleine Änderungen, die sich über mehrere Schichten ausbreiten, sind ein frühes Warnsignal, dass Transformationslogik nicht für Veränderungen strukturiert ist. Wenn eine Column-Umbenennung in einem Quellsystem das Anfassen von zwölf Dateien erfordert, hat die Architektur bereits angefangen zu driften. Wenn zweitens zu viel Verständnis bei zu wenigen Personen sitzt, ist das ein Risikoproblem im Einstellungsmarkt, nicht nur ein Dokumentationsproblem. Zwei Senior Engineers, die im selben Quartal das Unternehmen verlassen, können die Plattformevolution faktisch einfrieren.

Regulatorische Exposition ist der dritte Fallstrick, besonders für Fintech- und iGaming-Teams, die das hier lesen. Lake-Architekturen sammeln zuerst Daten und regulieren sie später – was genau umgekehrt ist zu dem, wie die meisten Datenschutzregelungen es erwarten. Lineage, Retention und Zugriffskontrollen müssen eingebaut werden, nicht unter Prüfungsdruck nachgerüstet.

Die wichtigsten Erkenntnisse

• Wähle die Architektur, die dein Team betreiben kann, nicht die, die am besten demonstriert wird. Vongs zentraler Punkt: Komplexität übersteigt die Capability, wenn Teams ausschließlich nach Capability wählen.
• Flexibilität hat eine Disziplin-Steuer. Lakes und Lakehouses erlauben schnelles Datensammeln, aber ohne Engineering-Kontrollen wird diese Geschwindigkeit innerhalb von achtzehn Monaten zum Chaos.
• Die vier Qualitäten dauerhafter Architekturen sind organisatorischer, nicht technischer Natur: beobachtbare Pipelines, wiederverwendbare Transformationen, kontrollierte Deployments und eine Architektur, die beim Wachsen verständlich bleibt.
• Konzentration von institutionellem Wissen ist ein Plattformrisiko. Aggressiv dokumentieren, Ownership rotieren und einzelne menschliche Fehlerpunkte genauso behandeln wie einzelne System-Fehlerpunkte.
• Teams, die eine Plattformmigration 2026 evaluieren, sollten sich jetzt fragen, ob ihre nächste Einstellung ein Platform Engineer oder ein Data Reliability Engineer sein soll, denn die Architekturentscheidung und die Organigramm-Entscheidung sind dieselbe Entscheidung.