Quality Gates und Datenverträge

Einstieg

Diese Folge gehört zur Serie Datenqualität mit Nachweis. Sie erklärt Datenqualität nicht als abstrakten Score, sondern als begründete Aussage: Für welchen Zweck sind Daten gut genug, welche Grenzen gelten und welcher Nachweis liegt vor?

Begriffe vor dem Lesen

• Quality Gate — Prüfgrenze, an der Daten gewarnt, gestoppt oder freigegeben werden.
• Datenvertrag — Vereinbarung über Bedeutung, Qualität, Aktualität, Änderung und Reaktion.
• Producer — Team oder System, das Daten bereitstellt.
• Consumer — Team, Prozess oder Anwendung, die Daten nutzt.
• Fehlerverhalten — Was passiert, wenn eine Erwartung verletzt wird.

Das Problem im Alltag

Daten werden veröffentlicht, obwohl eine wichtige Erwartung verletzt ist. Alle sehen es erst im Report. Ein Gate fehlt dort, wo aus Technik eine nutzbare Zusage wird.

Das saubere Muster

Was das praktisch bedeutet

Qualität entsteht nicht durch möglichst viele Prüfungen. Qualität entsteht, wenn eine fachliche Erwartung so beschrieben ist, dass sie geprüft, verstanden und im Fehlerfall behandelt werden kann.

Ein gutes Qualitätsmodell macht drei Dinge sichtbar:

• welche Nutzung geschützt wird;
• welche Datenfälle zur Aussage gehören;
• was passiert, wenn die Erwartung verletzt wird.

Damit werden Tests, Katalogeinträge, Incidents und Datenverträge Teil derselben Geschichte. Nutzer sehen nicht nur ein grünes oder rotes Signal, sondern verstehen, was dieses Signal für ihre Entscheidung bedeutet.

Mini-Fall

Ein Datenprodukt darf bei fehlender Währung nicht an Finance veröffentlicht werden. Für explorative Analyse reicht eine Warnung. Der Vertrag erklärt den Unterschied, das Gate setzt ihn um.

Anti-Patterns

• Tests schreiben, bevor Zweck und Umfang geklärt sind.
• Einen globalen Qualitätswert als Freigabe für jede Nutzung verstehen.
• Warnungen sammeln, aber keine Reaktion vereinbaren.
• Technische Logs als Nachweis behandeln, obwohl Nutzer sie nicht finden.
• Fachliche Entscheidungen an ein Tool delegieren.

Erster Umsetzungsschnitt

1. Eine Veröffentlichungsgrenze auswählen.
2. Producer, Consumer und Zweck dokumentieren.
3. Drei kritische Erwartungen in den Vertrag aufnehmen.
4. Warnen, stoppen oder kennzeichnen je Erwartung festlegen.
5. Eine Ausnahme mit Ablaufdatum definieren.
6. Nachweis am Datenprodukt sichtbar machen.

Woran man merkt, dass es besser wird

Teams diskutieren weniger über abstrakte Prozentwerte und mehr über konkrete Entscheidungen. Fachbereiche wissen, welche Daten sie wofür verwenden dürfen. Data Engineering weiß, welche Erwartungen wirklich kritisch sind. Incidents führen zu besseren Regeln statt nur zu neu gestarteten Jobs.