Datenarchitektur gestalten: Wer die Eigentümerschaft nicht klärt, baut auf Sand

Ungeklärte Dateneigentümerschaft ist die häufigste Ursache für widersprüchliche Berichte, brüchige Verarbeitungsstrecken und gescheiterte Governance-Initiativen – eine Architektur, die das strukturell adressiert, sieht anders aus als die meisten Organisationen heute betreiben.

Das Problem hat einen Namen – und er heißt nicht „schlechte Daten“

Datensümpfe, widersprüchliche Berichte, brüchige Verarbeitungsstrecken. In fast jedem Unternehmen, das wir bei CONVOTIS begleiten, liegt die Wurzel an derselben Stelle: Daten haben keinen Eigentümer. Nicht weil niemand zuständig sein will – sondern weil die Architektur Eigentümerschaft strukturell nicht vorsieht.

Jede Organisation steht damit vor drei Fragen, die beantwortet sein müssen, bevor das erste Tool ausgewählt wird:

• Wer verantwortet die Qualität? Die Antwort „alle“ ist in der Praxis identisch mit „niemand“. Domänenbasierte Eigentümerschaft – das erzeugende Team trägt die Verantwortung – klingt banal, verlangt aber organisatorische Verankerung. Eine RACI-Tabelle reicht nicht.
• Wo steht verbindlich, was „aktiver Kunde“ bedeutet? Meistens in einem Tabellenkalkulationsdokument mit drei konkurrierenden Versionen, von denen keine als offiziell gilt. Eine semantische Schicht im Repository löst das technisch – aber nur dann, wenn gleichzeitig geklärt ist, wer die Hoheit über diese Definition hält.
• Ab welcher Verarbeitungsstufe gilt ein Datensatz als entscheidungsreif? Ohne explizite Qualitätszonen landet alles ungefiltert im Analysewerkzeug. Was dann folgt: Berichte, die sich widersprechen, und Diskussionen darüber, welcher der richtige ist – statt über das, was die Daten eigentlich zeigen.

Eine Architektur, die diese drei Fragen offen lässt, verschiebt Vertrauen in Richtung Bauchgefühl.

Wann lohnt sich der Umbau – und wann nicht?

Bevor wir in die Architektur einsteigen, eine ehrliche Einschätzung: Das Modell verwalteter Datenprodukte ist kein Allheilmittel.

Weniger als fünf Teams, weniger als zwanzig Datensätze – leichtgewichtige Konventionen reichen vollständig aus. Der Overhead lohnt sich, wenn abhängige Teams sich gegenseitig blockieren, wenn die Kosten eines Datenausfalls den Aufwand für Governance übersteigen, oder wenn ein DSGVO-Auskunftsersuchen heute drei Wochen dauert.

Zu früh eingeführt: Komplexität ohne Gegenwert. Zu spät: Nachbau auf unsauberer Basis, mit dem vollen Schuldenberg technischer und organisatorischer Altlasten im Rücken.

Was ein Datenprodukt ist – und warum klassische Pipelines scheitern

Der entscheidende Wandel ist konzeptionell: weg vom Gedanken, dass Daten fließen, hin zum Gedanken, dass Daten geliefert werden.

Ein Datenprodukt ist eine abgegrenzte, versionierte, dokumentierte und überwachte Einheit – vergleichbar mit einem Schnittstellenvertrag zwischen Teams. Es hat einen stabilen Zugangspunkt, einen definierten Service Level und ein verantwortliches Team. Data Mesh beschreibt diesen Ansatz als domänengetriebene Dateneigentümerschaft – kein Tool, kein Stack, sondern ein Organisationsprinzip mit technischen Konsequenzen.

Ein reifes Datenprodukt erfüllt sechs Bedingungen:

• Auffindbar – im Datenkatalog, nicht per Zuruf oder interner E-Mail-Kette
• Dokumentiert – Felddefinitionen maschinenlesbar, nicht in einem Wiki, das niemand pflegt
• Qualitätszusage – messbare SLOs, keine Aussagen wie „sollte eigentlich stimmen“
• Stabiler Zugangspunkt – keine stillen Schemabrüche, kein Migrationschaos
• Eindeutige Eigentümerschaft – ein Team, kein Komitee, kein Zuständigkeitsnebel
• Automatisierte Qualitätsprüfung – bei jeder Verarbeitung, nicht im Nachhinein

Wer eine einzige dieser Bedingungen weglässt, baut keine Datenprodukte. Er baut gut gemeinte Tabellen.

Die teuersten Fehler entstehen fast immer bei Bedingung fünf – nicht weil niemand prüft, sondern weil unklar ist, wer auf den Alarm reagieren muss. In einem Projekt, das wir bei CONVOTIS übernommen haben, existierten Monitoring-Alerts seit Monaten unbeantwortet, weil kein Team die formale Zuständigkeit hatte. Die Daten liefen weiter. Die Entscheidungen auch.

Die drei Fundamente: Herkunft, Semantik, Qualität

Das Datenprodukt ist die Einheit. Aber es steht auf drei Schichten. Fehlt eine, brechen die anderen zusammen.

Herkunftsverfolgung: Wissen, woher ein Wert kommt

Ohne Lineage ist jede Fehlersuche ein Ratespiel. Mit ihr lässt sich in Minuten beantworten, was ohne sie Stunden kostet: Wo ist der Fehler eingetreten – im Quellsystem, in der Transformation, oder erst bei der Lieferung?

Für den Einstieg reicht die Tabellenebene. OpenLineage definiert das offene Austauschformat, Marquez implementiert es leichtgewichtig. DataHub ist die umfassendere Alternative: vollständiger Katalog mit Lineage, Suche und Klassifizierung – mehr Betriebsaufwand, aber auch mehr Reichweite.

Die Spaltenebene wird Pflicht, sobald DSGVO-Konformität nachweisbar sein muss. Wer das erst beim ersten Auskunftsersuchen implementiert, merkt schnell, wie viel Arbeit sich aufgestaut hat und wie lange eine gesetzlich vorgeschriebene Anfrage plötzlich dauert.

Semantische Schicht: Eine Wahrheit, versioniert

Zwei Berichte, eine Frage, zwei Ergebnisse – ein klassisches Symptom fehlender semantischer Autorität.

MetricFlow (Teil von dbt) hält Begriffsdefinitionen versioniert im Repository: eine einzige, geprüfte Definition von aktive_kunden, abrufbar von jedem Analysewerkzeug. Kein Tabellenkalkulationsdokument, keine informelle Absprache, keine konkurrierende Version im anderen Fachbereich.

Der bekannte Engpass dabei: Bei konkurrierenden Fachbereichen wird die semantische Schicht selbst zum Konfliktpunkt. Vertrieb und Finance definieren „Umsatz“ unterschiedlich – und beide haben nachvollziehbare Gründe dafür. Was hilft, ist klare Metrik-Eigentümerschaft und ein Eskalationsweg, der Fachbereichsvertreter einbindet, bevor die Definition ins Repository wandert. Werkzeuge machen solche Konflikte sichtbar – auflösen müssen sie Menschen.

Qualitätsüberwachung in der Strecke: Früh prüfen, explizit reagieren

Qualitätsprüfungen gehören in die Verarbeitungsstrecke – nicht in den Bericht. Wer Fehler erst im Dashboard entdeckt, hat bereits schlechte Entscheidungen ermöglicht.

Ein bewährtes Muster teilt die Strecke in drei Zonen:

• Eingangszone – Vollständigkeit, Zulässigkeit, Formatkonformität
• Transformationszone – Mengenkonsistenz, Geschäftsregeln, referenzielle Integrität
• Lieferzone – Abweichung zum Vortag, Quality Score, Freigabestatus

Entscheidend ist die Reaktionsstrategie bei Fehlschlag: harter Stopp für Finanzdaten, Quarantäne bei hohem Volumen, Warnung mit Kennzeichnung für explorative Analysen. Diese Entscheidung muss explizit getroffen sein – sie darf nicht implizit entstehen, weil niemand sie gestellt hat. Great Expectations oder dbt Tests setzen das Muster um.

Governance: Warum Zugriffsregeln und Löschbarkeit in die Architektur gehören

DSGVO-Auskunftsersuchen, Löschanfragen, Revisionen – sie alle stellen dieselbe Frage: Wo sind die Daten dieser Person? Wer die Antwort erst suchen muss, hat Governance als Nachgedanken behandelt.

Vier Maßnahmen verhindern das strukturell:

• Zugriffsregeln als Code via Open Policy Agent. Ohne das: manuelle Freigabeprozesse, keine Auditierbarkeit, keine Reproduzierbarkeit.
• Sensitivitätskennzeichnung am Feld in den Schema-Metadaten. Ohne das kann die Plattform nicht automatisch maskieren oder sperren – und tut es deshalb nicht.
• Aufbewahrungsfristen als Konfiguration im versionierten Repository – sonst übernehmen E-Mail-Ketten und manuelle Prozesse, und Fristen werden vergessen.
• Löschbarkeit als Entwurfsprinzip – verankert vor Tag 1
  Nachgerüstete Löschbarkeit gehört zu den teuersten Architekturproblemen, die wir kennen. Mehrere Teams, mehrere Wochen, ein einziges Auskunftsersuchen – weil die Frage „wo liegen diese Daten überhaupt“ niemand beantworten kann.

Wie man anfängt – ohne das gesamte System umzubauen

Der häufigste Fehler bei der Einführung: zu breit starten. Der richtige Einstieg ist fokussiert.

Schritt 1: Den kritischen Datenpfad identifizieren – dort, wo Berichte sich widersprechen, wo Teams sich gegenseitig die Schuld zuschieben, wo ein Ausfall die größten Konsequenzen hätte.

Schritt 2: Für genau diesen Pfad Lineage einrichten, automatisierte Qualitätsprüfungen einbauen, Reaktionsstrategien festlegen.

Schritt 3: Eigentümerschaft explizit klären – mit Namen, mit Eskalationsweg, mit tatsächlichen Ressourcen. Verantwortung ohne Ressourcen und Mandat bleibt eine Absichtserklärung.

Erst wenn dieser Pfad stabil läuft und das Team die Eigentümerschaft tatsächlich lebt, lohnt die Ausweitung.

Der Punkt, an dem Technik aufhört

Wer Datenqualität als Projektziel behandelt, hat nach dem Go-live ein neues Problem. Die Werkzeuge für einen stabilen Betrieb existieren – ausgereift, erprobt, gut dokumentiert. Was fast immer fehlt, ist jemand, der sich zuständig fühlt, wenn es darauf ankommt. Mit Mandat. Mit Ressourcen. Mit einem Eskalationsweg, der funktioniert.