Moderne Datenarchitektur aufbauen: Muster, Schichten und Entscheidungen

Die meisten Datenprobleme im Unternehmen sind keine Werkzeugprobleme, sondern Architekturprobleme. Ein neues Tool auf eine unklare Struktur zu setzen, verschiebt das Problem nur. Dieser Artikel beschreibt, aus welchen Schichten eine moderne Datenarchitektur besteht, welche vier Muster zur Auswahl stehen, wann welches passt und welche Entscheidungen im DACH-Kontext von Anfang an getroffen werden müssen.

Was Datenarchitektur umfasst

Datenarchitektur ist die Struktur, die festlegt, wie Daten in ein Unternehmen gelangen, wo sie liegen, wie sie verarbeitet werden und wie sie den Konsumenten erreichen. Sie ist keine Technologieliste, sondern eine Reihe von Entscheidungen über Verantwortlichkeiten, Datenflüsse und Grenzen.

Der Unterschied zwischen einer tragfähigen und einer improvisierten Architektur zeigt sich nicht am ersten Tag, sondern im dritten Jahr: wenn zehn Teams in dieselben Systeme schreiben, wenn niemand mehr weiß, welche Kennzahl aus welcher Quelle stammt, und wenn jede neue Anforderung eine Sonderlösung erzwingt. Eine gute Architektur macht den nächsten Schritt einfach; eine schlechte macht jeden Schritt zur Ausnahme.

Die Schichten einer modernen Datenarchitektur

Unabhängig vom gewählten Muster gliedert sich eine Datenarchitektur in vier durchlaufende Schichten und zwei Querschnittsfunktionen.

• Ingestion: Daten gelangen per Batch oder Streaming ins System. Werkzeuge wie Apache Kafka, Apache Flink oder Change Data Capture liefern operative Daten in nahezu Echtzeit, ohne die Quellsysteme zu belasten.
• Speicher: Rohdaten und veredelte Daten liegen getrennt, typischerweise auf einem Object Store (S3, Azure Data Lake Storage) oder in einem Warehouse. Speicher und Rechenleistung sind in modernen Architekturen entkoppelt.
• Verarbeitung: Transformation, Bereinigung und Anreicherung, deklarativ verwaltet (etwa mit dbt) oder über verteilte Engines (Apache Spark).
• Serving: Aufbereitete Datenprodukte für Dashboards, APIs, ML-Inferenz und Ad-hoc-Analyse.

Quer über alle Schichten liegen zwei Funktionen, die nicht optional sind: ein Data Catalog für Auffindbarkeit und Governance für Ownership, Qualität und Zugriff. Ohne sie wird jede Speicherschicht früher oder später unübersichtlich.

Die vier Architekturmuster

Vier Muster decken den Großteil der Praxis ab. Die Entscheidung folgt den Anforderungen.

Data Warehouse. Schema-on-Write, strukturiert, optimiert für SQL und Reporting. Die richtige Wahl, wenn die Anforderungen klar sind und primär strukturierte Analysen gefragt sind.

Data Lake. Schema-on-Read, heterogene Rohdaten, optimiert für Exploration und Machine Learning. Sinnvoll bei großen Rohdatenvolumen und noch offenen Anforderungen. Der Preis ist Governance-Aufwand, sonst entsteht ein Data Swamp.

Lakehouse. Verbindet die Speicherflexibilität des Lake mit transaktionaler Konsistenz und SQL-Schichten darüber, über Tabellenformate wie Apache Iceberg oder Delta Lake. Das pragmatische Standardmodell, wenn ein Unternehmen beides braucht und die Infrastruktur konsolidieren will.

Data Mesh. Kein Speichermuster, sondern ein Organisationsmodell: Daten als Produkt, Ownership in den Fachdomänen, eine Self-Service-Plattform. Sinnvoll ab einer Größe, in der eine zentrale Datenmannschaft zum Engpass wird. Die Umsetzung ist eine organisatorische, keine rein technische Entscheidung.

Die häufigste Fehleinschätzung ist, das komplexeste Muster zu wählen, weil es modern klingt. Ein Mittelständler mit klaren Reporting-Anforderungen braucht selten ein Data Mesh.

Die Medaillon-Architektur als Zonenmodell

Innerhalb eines Lake oder Lakehouse hat sich die Medaillon-Architektur als praktikables Zonenmodell durchgesetzt: drei Ebenen, die Daten schrittweise veredeln.

• Bronze: Rohdaten, exakt wie geliefert, append-only und unveränderlich. Grundlage für Audits und Wiederaufbereitung.
• Silber: bereinigt, dedupliziert, in ein einheitliches Schema überführt.
• Gold: aggregierte, anwendungsfallspezifische Datenprodukte für Dashboards und ML.

Der Wert liegt in der Nachvollziehbarkeit: Jede Kennzahl in Gold lässt sich über Silber bis zur Bronze-Quelle zurückverfolgen. Das ist keine Formalität, sondern die Voraussetzung dafür, einem Wert überhaupt vertrauen zu können.

Build, Buy und der DACH-Kontext

Zwei Entscheidungen prägen jede Architektur im DACH-Raum von Anfang an.

Erstens Build versus Buy. Managed-Plattformen (etwa Snowflake, Databricks oder die Cloud-nativen Dienste) beschleunigen den Start, binden aber an einen Anbieter. Selbstgehostete, offene Komponenten (Iceberg, Trino, Spark) geben Kontrolle zum Preis von Betriebsaufwand. Die Antwort hängt von der Reife des Datenteams ab, nicht von einer generellen Vorliebe.

Zweitens Souveränität und DSGVO. Wo personenbezogene Daten liegen, ist eine Architekturentscheidung: europäische Cloud-Regionen (Frankfurt, Amsterdam, Zürich), Löschkonzepte für Artikel 17 DSGVO und ein Verarbeitungsverzeichnis, das jeden Datenfluss abbildet. Diese Punkte nachzurüsten ist teuer; sie einzuplanen kostet fast nichts. Für viele Unternehmen im DACH-Raum ist Datenresidenz kein Zusatz, sondern die Grundbedingung.

Typische Fehler

Aus der Praxis: die Muster, die Datenarchitekturen scheitern lassen.

1. Werkzeug vor Struktur. Eine Plattform kaufen, bevor die Datenflüsse und Verantwortlichkeiten geklärt sind. Das Tool erbt die Unklarheit.

2. Das komplexeste Muster als Default. Data Mesh oder Lakehouse, wo ein Warehouse gereicht hätte, mit entsprechendem Betriebsaufwand.

3. Katalog und Governance als Nachgedanke. Speicher wächst, Auffindbarkeit nicht. Nach zwei Jahren findet niemand mehr die richtigen Daten.

4. Compliance nachgelagert. DSGVO und Residenz erst beim ersten Audit, dann als Migrationsprojekt unter Druck.

5. Alles auf einmal. Eine Architektur, die jeden Anwendungsfall abdecken soll, bevor einer produktiv ist, wird nie fertig.

Datenarchitektur besprechen

DNA Solutions berät Unternehmen im DACH-Raum beim Entwurf und Aufbau von Datenarchitekturen: von der Musterwahl zwischen Warehouse, Lake, Lakehouse und Mesh über die Schichten und das Zonenmodell bis zu Katalog, Governance und DSGVO-konformer Datenhaltung. Wenn Sie vor einer Architekturentscheidung stehen oder eine gewachsene Struktur konsolidieren müssen, sequenzieren wir es entlang der Anwendungsfälle, die wirklich zählen. Sprechen Sie uns an.