Datenverträge im Betrieb

Begriffe vor dem Lesen

• Ein Datenvertrag ist eine versionierte Vereinbarung zwischen einem bereitstellenden und einem nutzenden Team über Inhalt, Bedeutung, Qualität und Änderung eines Datenprodukts.
• Ein Schema beschreibt technische Felder und Datentypen. Es erklärt noch nicht vollständig, was die Daten fachlich bedeuten.
• Ein Produzent stellt Daten bereit. Ein Verbraucher verwendet sie in einem Prozess, Bericht, Modell oder anderen Datenprodukt.
• Eine Invariante ist eine zugesicherte Regel, die immer gelten muss, beispielsweise eine eindeutige Auftragsnummer.

Ausgangslage

Ein Quellsystem liefert täglich Auftragsdaten. Das bereitstellende Team ergänzt ein Feld, ändert später die Bedeutung des Status „abgeschlossen“ und korrigiert alte Datensätze rückwirkend. Technisch bleibt die Tabelle lesbar. Im Umsatzbericht und in der Lieferprognose entstehen trotzdem andere Ergebnisse.

Ein Datenvertrag verhindert nicht jede Änderung. Er macht sichtbar, worauf sich Verbraucher verlassen dürfen, wie Änderungen angekündigt werden und wer bei einem Konflikt entscheidet.

Was in einen Datenvertrag gehört

Zugriffsregeln, Schutzbedarf und Aufbewahrung gehören ebenfalls hinein oder werden eindeutig verlinkt. Der Vertrag bleibt lesbar; technische Details können in prüfbaren Schema- oder Testdateien liegen.

Wer vereinbart den Vertrag?

Der Data Product Owner des bereitstellenden Teams verantwortet Angebot, Prioritäten und zugesicherte Leistung. Fachliche Owner entscheiden über Bedeutung und erlaubte Nutzung. Der Data Steward koordiniert Definitionen, bekannte Verbraucher und offene Abweichungen. Technische Betreiber setzen Prüfungen und Veröffentlichung um. Verbraucher bestätigen, welche Felder und Zusagen für ihren Prozess kritisch sind.

Der Katalog kann den Vertrag auffindbar machen, ist aber nicht selbst die Vereinbarung. Ein Schema-Werkzeug kann Datentypen prüfen, entscheidet aber nicht, was „abgeschlossen“ fachlich bedeutet.

Ein kleines Beispiel

Für das Datenprodukt „Auftragsstatus“ wird vereinbart: Eine Zeile beschreibt eine Auftragsposition. Der Status „abgeschlossen“ bedeutet, dass Leistung und fachliche Freigabe vorliegen. Daten erscheinen werktags bis 06:00 Uhr. Fehlen mehr als 0,5 Prozent der Währungsangaben, wird die Veröffentlichung markiert und Abrechnung informiert. Änderungen an Bedeutung oder fachlicher Einheit benötigen eine neue Hauptversion.

Diese wenigen Sätze sind wertvoller als ein hundertseitiges Dokument, das keine konkrete Zusage enthält.

Prüffragen

• Versteht ein fachlicher Nutzer Zweck und Bedeutung ohne Quellcode?
• Sind fachliche Einheit, kritische Felder und Qualitätsregeln eindeutig?
• Ist bekannt, welche Verbraucher auf den Vertrag bauen?
• Sind Änderung, Ausnahme und Eskalation beschrieben?
• Stimmen Dokumentation, technische Prüfungen und tatsächliche Daten überein?

Begriffe vor dem Lesen

• Eine inkompatible Änderung kann einen bestehenden Verbraucher fachlich oder technisch falsch werden lassen.
• Eine Hauptversion kennzeichnet eine Änderung, bei der Verbraucher bewusst auf eine neue Vertragsfassung wechseln müssen.
• Eine Übergangszeit ist der vereinbarte Zeitraum, in dem alte und neue Fassung parallel nutzbar sind.
• Eine Stilllegung beendet eine alte Version kontrolliert, nachdem Verbraucher umgestellt oder ausdrücklich ausgenommen wurden.

Ausgangslage

Das Feld „customer_id“ wird umbenannt. Das fällt in technischen Tests sofort auf. Schwieriger ist eine scheinbar harmlose Änderung: „Lieferdatum“ bezeichnet künftig den geplanten statt den tatsächlichen Termin. Datentyp und Feldname bleiben gleich, aber Lieferquote und Verspätungsberichte werden fachlich falsch.

Deshalb prüft ein Änderungsprozess nicht nur Schemas, sondern auch Bedeutung, Betrachtungsebene, Qualitätszusagen und Aktualität.

Welche Änderungen kritisch sind

Vom Änderungsvorschlag zur Einführung

1. Der Produzent beschreibt Änderung, Grund, betroffene Vertragsteile und geplanten Termin.
2. Der Steward ermittelt bekannte Verbraucher und deren kritische Nutzung.
3. Produzent und Verbraucher bewerten technische und fachliche Kompatibilität.
4. Bei einer inkompatiblen Änderung entsteht eine neue Hauptversion mit Übergangszeit.
5. Verbraucher testen ihren Prozess mit repräsentativen Daten und bestätigen die Umstellung.
6. Die alte Version wird erst beendet, wenn offene Verbraucher entschieden, migriert oder mit befristeter Ausnahme dokumentiert sind.

Ein automatischer Schematest unterstützt die Schritte, ersetzt aber nicht den fachlichen Vergleich. Auch unveränderte Spalten können eine neue Bedeutung erhalten.

Beispiel

Ein Verkaufskanal führt Sammelaufträge ein. Bisher entsprach eine Zeile einem Auftrag; künftig entspricht sie einer Position. Statt die bestehende Tabelle still umzudeuten, veröffentlicht das Team Version 2 mit Positionskennung. Version 1 bleibt sechs Wochen verfügbar. Abrechnung, Forecast und Service testen ihre Summen und wechseln dokumentiert. Danach wird Version 1 mit einer letzten Nutzungsprüfung stillgelegt.

Prüffragen

• Wird Bedeutung ebenso geprüft wie Name und Datentyp?
• Sind alle bekannten Verbraucher informiert und erreichbar?
• Besitzt die neue Version realistische Testdaten?
• Gibt es ein klares Ende für die Übergangszeit?
• Kann nachträglich gezeigt werden, wer wann auf welche Version wechselte?

Begriffe vor dem Lesen

• Ein Verbraucherregister ist eine aktuelle Liste der Prozesse, Berichte, Modelle und Teams, die ein Datenprodukt verwenden.
• Ein kritischer Verbraucher verursacht bei falschen oder fehlenden Daten eine wesentliche fachliche Auswirkung.
• Eine Nutzungsbestätigung hält fest, dass ein Team seine Abhängigkeit, Kontaktperson und verwendete Vertragsversion bestätigt hat.

Ausgangslage

Ein Datenprodukt soll geändert werden. Die Zugriffsprotokolle zeigen 70 technische Konten, aber niemand weiß, welches Konto zur Abrechnung, zu einem alten Test oder zu einem wichtigen Prognosemodell gehört. Eine Rundmail erreicht einige Teams und übersieht andere.

Das Verbraucherregister verbindet technische Nutzung mit fachlicher Auswirkung. Es ist kein vollständiger Katalog aller Abfragen, sondern eine gepflegte Kontakt- und Abhängigkeitsliste für Entscheidungen.

Mindestangaben

Für jeden wesentlichen Verbraucher werden Datenprodukt und Vertragsversion, verantwortliches Team, fachlicher Zweck, Kontaktperson, Kritikalität, verwendete Felder oder Zusagen und letzter Bestätigungstermin erfasst. Automatisch erkannte Nutzung kann einen Eintrag vorschlagen; das nutzende Team bestätigt seine Bedeutung.

Betrieb des Registers

Neue Verbraucher registrieren sich vor produktiver Nutzung oder werden aus technischen Signalen zur Bestätigung eingeladen. Bei Vertragsänderungen erhalten betroffene Kontakte eine konkrete Nachricht mit Version, Wirkung und Termin. Verbraucher bestätigen Umstellung oder melden Hindernisse. Inaktive Einträge werden nicht sofort gelöscht, sondern zunächst geprüft, weil seltene Monats- oder Jahresprozesse in kurzen Protokollfenstern unsichtbar sein können.

Der Steward pflegt Qualität und offene Bestätigungen. Der Data Product Owner entscheidet über Übergangszeit und Stilllegung. Verbraucher verantworten ihre Kontakt- und Nutzungsangaben. Die Technik liefert Erkennungssignale und Verknüpfungen.

Beispiel

Das Produkt „Kundenstatus“ soll ein altes Feld entfernen. Das Register zeigt fünf Verbraucher: Service, Kampagnensteuerung, Monatsabschluss, Betrugsmodell und ein unbestätigtes Notebook. Vier Teams bestätigen ihre Migration. Das Notebook hatte seit drei Monaten keinen Zugriff und wird nach Rückfrage als ehemaliger Test stillgelegt. Erst danach endet die alte Version.

Prüffragen

• Enthält das Register fachliche Zwecke statt nur technische Konten?
• Sind kritische Verbraucher und Kontaktpersonen aktuell?
• Werden automatisch erkannte und manuell bestätigte Nutzung unterschieden?
• Berücksichtigt die Inaktivitätsprüfung selten laufende Prozesse?
• Ist das Register mit Änderung, Vorfall und Stilllegung verbunden?

Begriffe vor dem Lesen

• Ein Service Level Objective (SLO) ist ein messbares Zuverlässigkeitsziel, beispielsweise „an Werktagen bis 06:00 Uhr verfügbar“.
• Ein Messfenster legt fest, über welchen Zeitraum ein Ziel bewertet wird.
• Ein Fehlerbudget beschreibt, wie viel Abweichung innerhalb des vereinbarten Ziels toleriert wird.
• Eine Eskalation bringt eine Abweichung zur benannten Rolle, die Wirkung und nächste Schritte entscheiden kann.

Ausgangslage

„Die Daten müssen immer aktuell und vollständig sein“ klingt anspruchsvoll, ist aber nicht steuerbar. Ein nächtlicher Finanzlauf braucht andere Zusagen als eine wöchentliche Analyse. Ohne messbare Grenze erzeugt jede Verspätung Streit oder kein Problem wird ernst genommen.

Zusagen aus dem Geschäftszweck ableiten

Ein SLO beginnt mit der Nutzung: Wann entscheidet der Verbraucher? Welche Fehler verändern diese Entscheidung? Wie schnell muss eine Störung behoben sein? Daraus entstehen wenige überprüfbare Ziele.

Die Zahlen sind Beispiele, keine universellen Vorgaben. Sie müssen zur Auswirkung und zu realistischen Betriebsmöglichkeiten passen.

Messung und Reaktion

Jedes Ziel nennt Formel, Datenquelle, Messfenster, verantwortliche Person und Reaktion bei Verletzung. Eine einzelne verspätete Lieferung kann eine Warnung auslösen; wiederholte Verletzungen können Veröffentlichung blockieren oder eine Prioritätsentscheidung verlangen. Geplante Wartung und genehmigte Ausnahmen werden sichtbar getrennt, statt die Statistik still zu bereinigen.

Das bereitstellende Team misst und erklärt die Leistung. Der Data Product Owner entscheidet über Prioritäten und zugesicherte Ziele. Verbraucher melden die fachliche Auswirkung. Ein Steward hält Definitionen, Ausnahmen und wiederkehrende Verletzungen zusammen.

Beispiel

Die tägliche Bestandsplanung beginnt um 07:00 Uhr. Das Datenprodukt sagt Verfügbarkeit bis 06:15 Uhr an 99 Prozent der Werktage zu. Bei Verspätung erhalten Planung und Betrieb automatisch Status und erwartete Wiederherstellungszeit. Nach drei Verletzungen im Messfenster wird nicht nur der Alarm quittiert: Product Owner und Verbraucher entscheiden über Ursache, Investition oder eine realistischere Zusage.

Prüffragen

• Leitet sich das Ziel aus einer konkreten Entscheidung ab?
• Sind Formel, Messfenster und Messpunkt eindeutig?
• Werden geplante Ausnahmen sichtbar dokumentiert?
• Erreicht eine Verletzung die betroffenen Verbraucher rechtzeitig?
• Führt wiederholte Zielverletzung zu einer Entscheidung statt nur zu mehr Alarmen?

Begriffe vor dem Lesen

• Durchsetzung bedeutet, dass eine Vertragsregel an einem technischen oder organisatorischen Kontrollpunkt tatsächlich geprüft wird.
• Ein negativer Test weist nach, dass fehlerhafte Daten oder eine unerlaubte Änderung erkannt und wie vorgesehen behandelt werden.
• Quarantäne hält fehlerhafte Daten getrennt, sodass sie nicht unbemerkt produktiv verwendet werden.
• Eine Ausnahme erlaubt eine begründete, befristete Abweichung mit verantwortlicher Person und Ablaufdatum.

Ausgangslage

Ein Datenvertrag ist veröffentlicht, aber die Datenpipeline prüft keine seiner Zusagen. Als ein Pflichtfeld leer bleibt, läuft der Bericht weiter und zeigt plausible, aber unvollständige Zahlen. Eine Dokumentation ohne wirksamen Kontrollpunkt schützt Verbraucher nicht.

Nicht jede Regel wird gleich durchgesetzt

Blockieren ist sinnvoll, wenn falsche Daten schwerwiegender sind als fehlende Daten. Warnen kann sinnvoll sein, wenn Verbraucher mit gekennzeichneter Einschränkung weiterarbeiten können. Diese Entscheidung ist fachlich und wird nicht pauschal vom Werkzeug getroffen.

Kontrollkette

Der Data Product Owner bestimmt gemeinsam mit Verbrauchern die kritischen Zusagen und Reaktionen. Der Steward verbindet Regeln mit Definition und Ausnahmeprozess. Engineering implementiert Prüfungen möglichst nahe am Entstehungs- oder Veröffentlichungspunkt. Der technische Betrieb überwacht Ausführung und Alarmierung.

Zu jeder kritischen Regel gehören ein positiver Test mit gültigen Daten und ein negativer Test mit einem gezielten Fehler. Das Ergebnis zeigt, ob wirklich blockiert, quarantänisiert oder gewarnt wird. Screenshots einer aktivierten Regel ersetzen diesen Wirksamkeitsnachweis nicht.

Beispiel

Das Abrechnungsprodukt verlangt Auftragsnummer, Währung und positiven Nettobetrag. Ein Testdatensatz ohne Währung wird vor Veröffentlichung abgefangen und in Quarantäne geschrieben. Abrechnung erhält eine Meldung mit betroffener Menge und erwartetem Korrekturzeitpunkt. Eine befristete Ausnahme wäre nur möglich, wenn der fachliche Owner die Wirkung akzeptiert und ein Ablaufdatum festlegt.

Prüffragen

• Ist jede kritische Zusage mit einem konkreten Kontrollpunkt verbunden?
• Ist begründet, wann blockiert und wann nur gewarnt wird?
• Beweist ein negativer Test die tatsächliche Reaktion?
• Können Nutzer Status und Einschränkung vor ihrer Entscheidung erkennen?
• Besitzen Ausnahmen Begründung, Verantwortung, Ablauf und erneute Prüfung?