Ihren Daten blind vertrauen? So machen Datenverträge dies möglich

Es gibt ein Sprichwort: Vertrauen kommt zu Fuß und geht zu Pferd. Im Laufe meiner Karriere im Bereich Daten habe ich festgestellt, dass dieses Sprichwort sehr treffend ist, wenn es um die Einführung von Datenprodukten innerhalb eines Unternehmens geht. Es dauert sehr lange, Vertrauen in Ihre Datenprodukte aufzubauen, und wenn das Unternehmen auch nur einen einzigen Fehler darin entdeckt, sind Sie wieder ganz am Anfang. Sie verlieren das Vertrauen fast augenblicklich.

Die Datenprobleme, mit denen wir konfrontiert sind und die das Vertrauen untergraben

Stellen Sie sich Folgendes vor: Sie verbringen viel Zeit damit, die Dashboards richtig einzurichten, die Definitionen abzustimmen und das Unternehmen dazu zu bringen, sich die Zahlen tatsächlich anzusehen, anstatt darüber zu streiten. Und dann, an einem Montagmorgen, öffnet ein leitender Angestellter noch vor seinem ersten Kaffee einen Bericht – und die Umsatzzahl ist falsch.\ Um 9:15 Uhr haben Sie bereits drei E-Mails erhalten. Am Ende des Tages hat jemand die Berechnung in Excel neu erstellt. Am Ende der Woche ist diese Excel-Datei die Version, der alle vertrauen. Den Bericht können Sie an einem Nachmittag korrigieren. Die Excel-Datei wird noch viele Jahre lang Bestand haben.

Dies ist einer der Gründe, warum sich Self-Service-BI auch nach einem Jahrzehnt mit besseren Tools, besseren Data Warehouses und besseren Vorgehensweisen nur schleppend durchsetzt. Die dem semantischen Modell zugrunde liegenden Transformationen sind für den Nutzer eine „Black Box“. Wenn sich die Daten auch nur ein einziges Mal nicht so verhalten, wie es erwartet wird, greifen die Nutzer auf das zurück, was sie verstehen. Sie übernehmen wieder die Kontrolle – und kehren nicht immer zurück. Wenn ich auf die Vorfälle zurückblicke, die ich bei verschiedenen Kunden und über verschiedene Technologiestacks hinweg beobachtet habe, lassen sie sich fast immer einer dieser vier Kategorien zuordnen:

Das Schema durchbrechen. Ein Entwickler benennt eine Spalte um, löscht ein Feld oder ändert einen Datentyp. Er hatte keine Ahnung, dass nachgelagerte Prozesse davon abhängig waren. Infolgedessen funktioniert das Dashboard nicht mehr, und das Datenteam verbringt drei Tage damit, die Datenherkunft zu entwirren, die von Anfang an offensichtlich hätte sein müssen.

Semantische Verschiebung. Die gleiche Spalte hat nun eine andere Bedeutung als früher. Ein Umsatzfeld, das früher in Euro angegeben war, wird nun in der Landeswährung angezeigt, da jemand die Unterstützung für mehrere Regionen hinzugefügt hat und die Umrechnungslogik in einen früheren Prozessschritt verlagert wurde. Technisch gesehen ist nichts ausgefallen. Die Zahlen im Dashboard haben lediglich stillschweigend ihre bisherige Bedeutung verloren. Die Nutzer bemerken dies erst Wochen später, wenn die Zahlen der Quartalsauswertung nicht mit den Berichten der Finanzabteilung übereinstimmen.

Die Begriffsdiskrepanz. Zwei Personen treten mit unterschiedlichen Umsatzzahlen in eine Besprechung ein. Beide Zahlen sind korrekt. Sie beziehen sich jedoch auf leicht unterschiedliche Fragestellungen: Brutto gegenüber Netto, verbucht gegenüber ausgewiesen, unter Einbeziehung oder ohne Berücksichtigung eines bestimmten Segments. Niemand hat auf diesen Unterschied hingewiesen, da die Kennzahl in beiden Berichten unter derselben Bezeichnung aufgeführt war. Die Besprechung gerät aus den Fugen. Eine Entscheidung wird verschoben. Das Vertrauen erleidet einen weiteren kleinen Rückschlag.

Die Datenschutzpanne. Ein neues Feld wird in die Produktion übernommen. Es enthält personenbezogene Daten. Niemand hat es als solches gekennzeichnet, da die Klassifizierung in einem Wiki hinterlegt ist, das niemand aktualisiert hat. Das Feld fließt in einen Export ein, der an einen Dritten übermittelt wird. Nun läuft die 72-Stunden-Meldefrist gemäß der DSGVO, und es geht nicht mehr um Datenqualität. Es geht um Bußgelder und eine Pressemitteilung.

Niemand macht diese Fehler absichtlich. Alle sind beschäftigt, alle erledigen ihre Arbeit, doch leider hat fast niemand den vollständigen Überblick über alle Abhängigkeiten, wenn er die Änderungen vornimmt. Hinter all diesen Problemen verbirgt sich ein übergeordnetes Problem.

Es gibt keine ausdrückliche, maschinenlesbare und von beiden Seiten getragene Vereinbarung zwischen dem Ersteller der Daten und den Nutzern darüber, was die Daten tatsächlich bedeuten. Kein Vertrag. Lediglich eine Reihe stillschweigender Annahmen, festgehalten in einem unbeachteten Dokument, deren Einhaltung durch nichts durchgesetzt wird.

Daten Verträge

Was ist ein Datenvertrag?

Im Kern gibt es einige aussagekräftige Beschreibungen von Datenverträgen, die sich zwar in ihrer Perspektive leicht unterscheiden, aber zum gleichen Ergebnis führen. Die von mir bevorzugte Variante wird im Folgenden beschrieben.

In dieser Definition steckt eine ganze Menge. Vor allem die Verben.

Gegründet. Der Vertrag ist keine stillschweigende Annahme, die sich aus Unterlagen ergibt, die niemand liest. Er ist ein bewusster Akt, bei dem die Vereinbarung schriftlich festgehalten wird – an einem Ort, den sowohl Produzenten als auch Verbraucher einsehen.

Aktualisiert. Der Vertrag entwickelt sich im Laufe der Zeit weiter und wird in verschiedenen Versionen geführt. Eine Änderung an den Daten stellt ebenfalls eine Änderung am Vertrag dar, und diese Änderung kann wie jeder andere Codeabschnitt überprüft, kommuniziert und rückgängig gemacht werden.

Durchgesetzt. Dies ist das entscheidende Verb. Der Vertrag wird automatisch überprüft und nicht freiwillig eingehalten. Er lässt sich in dieselbe Toolchain integrieren, in der bereits Unit-Tests, Bereitstellungsprüfungen und CI/CD-Pipelines ausgeführt werden. Versucht ein Entwickler, eine Änderung zu veröffentlichen, die gegen den Vertrag verstößt, schlägt der Build fehl. Die Änderung gelangt nicht in die Produktion.

Im Allgemeinen könnte man einen Datenvertrag als Schnittstelle betrachten. Er stellt die Verpflichtung des Anbieters dar, das dokumentierte Verhalten einer Datenressource aufrechtzuerhalten, sowie die Verpflichtung des Nutzers, seine Programme ausschließlich auf der Grundlage der dokumentierten Angaben zu erstellen. Damit sind bestimmte Erwartungen verbunden: Schema, gültige Werte, Aktualität, Eigentumsverhältnisse und Klassifizierung. Und er ist explizit, was bedeutet, dass die Daten gezielt für den Verbraucher generiert werden und nicht als Nebeneffekt eines vorgelagerten Systems erfasst werden. Die meisten Daten in den meisten Unternehmen werden heutzutage implizit generiert. Das Marketing-Dashboard basiert auf einem Ereignisstrom, der nur deshalb existiert, weil die Anwendung diese Ereignisse zufällig protokolliert. Niemand hat diesen Datenstrom als Produkt konzipiert. Er ist einfach aus dem System herausgesickert.

Der kulturelle Wandel, den der Datenvertrag fordert, lässt sich zwar leicht beschreiben, ist jedoch schwer umzusetzen: Hören Sie auf, Daten implizit zu generieren. Beginnen Sie stattdessen, sie bewusst zu generieren – für die Menschen, die sie nutzen werden. Wir werden später noch näher auf diesen kulturellen Wandel eingehen.

Was ist KEIN Datenvertrag?

Genau hier liegt zunächst ein Großteil der Verwirrung begründet, da Unternehmen schon seit langem versuchen, dieses Problem mit anderen Instrumenten zu lösen, und einige dieser Instrumente auf den ersten Blick wie Verträge aussehen.

Beispielsweise: - Ein Datenvertrag ist kein „Stammeswissen“. Stammeswissen ist das, worauf man zurückgreifen sollte, wenn es noch keine offiziellen oder produktionsreifen Lösungen gibt, und es geht jedes Mal aus dem Unternehmen verloren, wenn jemand den Arbeitsplatz wechselt. - Ein Datenvertrag ist kein Wiki. Eine Wiki-Seite, die eine Tabelle beschreibt, ist Dokumentation. Sie ist nicht maschinenlesbar, wird nicht zusammen mit dem Code, der die Daten erzeugt, versioniert und führt nicht zu einem Build-Fehler, wenn die tatsächlichen Gegebenheiten davon abweichen. - Ein Datenvertrag ist kein SLA. Ein SLA ist eine Service-Level-Vereinbarung, die oft recht formell verfasst ist. Sie wird jedoch selten durch Tools durchgesetzt und befindet sich auf einer Confluence-Seite, auf die zwischen den jährlichen Verlängerungen niemand Bezug nimmt. Ein SLA ist etwas, das in einem Datenvertrag festgehalten werden sollte. - Ein Datenvertrag ist kein Datenkatalog. Dies ist der wichtigste Punkt, den es richtig zu verstehen gilt, da Kataloge wirklich nützlich sind und sich an manchen Stellen mit Verträgen überschneiden. Ein Katalog ist ein Erkundungstool: ein Ort, an dem Nutzer nachschlagen können, welche Daten vorhanden sind und was sie bedeuten. Moderne Kataloge übernehmen Schemata und Datenherkunft automatisch aus der Produktion, sodass der beschreibende Teil stets auf dem neuesten Stand bleibt. Der präskriptive Teil jedoch – also das, wozu sich der Produzent verpflichtet hat, worauf sich der Nutzer verlassen kann und was bei Verstößen den Build zum Scheitern bringt – fehlt in der Regel gänzlich.

Wenn Sie sich nur eine Sache aus diesem Blogbeitrag merken, dann sollte es Folgendes sein: Ein Datenvertrag unterscheidet sich von anderen Instrumenten dadurch, dass er bei Verstößen die CI unterbricht. Wikis, SLAs und Kataloge tun dies nicht. Dies ist die einzige Eigenschaft, die zu einer grundlegenden Verbesserung der Datenqualität führt, da sie die Vereinbarung mit demselben Durchsetzungsmechanismus verbindet, auf den Entwickler bereits im Hinblick auf die Codequalität vertrauen.

Das bedeutet nicht, dass Kataloge und SLAs verschwinden sollten. Das sollten sie nicht. Sie erfüllen ihre eigenen Zwecke und leisten dabei gute Dienste. Sie sollten sich jedoch aus dem Vertrag ableiten und diesen nicht ersetzen. Der Vertrag ist die maßgebliche Quelle; alles andere ist lediglich eine darauf aufbauende Sichtweise.

Nach links schieben

Es gibt einen Begriff, der sich still und leise aus der Softwareentwicklung in den Datenbereich verlagert hat: „Shift Left“. Die Idee ist einfach: Qualitätsaspekte, Tests, Sicherheit und Compliance sollten so früh wie möglich im Entwicklungszyklus berücksichtigt werden. Denn dort lassen sie sich am kostengünstigsten beheben. Im Datenbereich fehlte diese erste Ebene jahrelang. Wir erkennen Qualitätsprobleme erst am Dashboard, also am Ende der Pipeline – dort, wo bereits alles schiefgelaufen ist, wo der Nutzer bereits das Vertrauen verloren hat und wo die Behebung am teuersten ist. Ein Datenvertrag sorgt dafür, dass eine Überprüfung so früh wie möglich im Prozess erfolgt. Der Vertrag befindet sich im Repository des Produzenten. Ein Pull-Request, der eine inkompatible Änderung vorschlägt, scheitert an der CI – an derselben Stelle, an der die Unit-Tests des Erstellers ausgeführt werden, in demselben Kontext, dem der Ersteller bereits vertraut.

Es geschehen drei Dinge gleichzeitig:

Doch wenn nichts mehr kaputtgeht, können Sie dann bei Bedarf dennoch kompatibilitätsbrechende Änderungen vornehmen? Auf jeden Fall, doch dies bedeutet, dass Änderungen ausgehandelt und kommuniziert werden müssen. Da der Vertrag versioniert ist, ist ein Produzent, der eine kompatibilitätsbrechende Änderung wirklich benötigt, nicht gezwungen, sich zwischen einer Blockade des Geschäftsbetriebs und der Beeinträchtigung der Verbraucher zu entscheiden. Er veröffentlicht die neue Version parallel zur aktuellen und eröffnet ein überlappendes Auslaufzeitfenster. Beide Versionen bleiben für einen vereinbarten Zeitraum verfügbar, die Verbraucher migrieren nach ihrem eigenen Zeitplan, und die alte Version wird erst dann aus dem Verkehr gezogen, wenn niemand mehr davon abhängig ist. Die inkompatible Änderung findet weiterhin statt. Sie stellt lediglich keinen Vorfall mehr dar.

„Shift Left“ ersetzt nicht den Rest der Pipeline. Sie benötigen weiterhin Integrationstests, Komponententests und die Überwachung der Produktionsumgebung. Jede Ebene erfasst, was die vorherige übersehen hat.

Der Kulturwandel

Daten als Produkt

Es gibt einen Fehlerfall, den ich ansprechen möchte, bevor wir fortfahren. Ein Team begeistert sich für Verträge. Es führt ODCS (den Open Data Contract Standard) ein. Es richtet CI-Prüfungen ein, und innerhalb kürzester Zeit verfügt es über eine Vielzahl von Verträgen zu Datenbeständen, die eigentlich niemand nutzt. Die Verträge sind korrekt. Die ihnen zugrunde liegenden Daten sind es jedoch nicht. Es handelt sich nach wie vor um denselben Nebeneffekt eines vorgelagerten Systems wie zuvor, nur dass nun eine YAML-Datei darüber liegt.

Ein Datenvertrag ist der technische Mechanismus. Ein Datenprodukt ist das, was dieser Mechanismus regeln soll. Beides ist erforderlich. Das Datenprodukt ist das Ziel.

Was macht ein Datenprodukt aus? – Erstens hat es stets einen Datenverantwortlichen. Dabei handelt es sich um eine einzelne Person, die fest im Erstellungsteam verankert ist und die die Verantwortung trägt, wenn es zu Störungen kommt. - Es verfügt über identifizierbare, erreichbare Nutzer und nicht über anonyme Endverbraucher. - Es verfügt über eine auf dem Lebenszyklus basierende Roadmap. Änderungen erfolgen bewusst und werden angekündigt. - Es verfügt über KPIs wie die Anzahl aktiver Nutzer, die Einhaltung der Aktualitätsvorgaben, Zufriedenheitswerte usw. Anhand dieser Kennzahlen erkennt der Verantwortliche, ob das Produkt in einem guten Zustand ist. - Und nicht zuletzt: Es verfügt stets über ein Support-Modell. Menschen bauen auf dem Datenprodukt auf. Sie sind davon abhängig. Was geschieht, wenn die Daten ausfallen? Wer reagiert? Innerhalb welcher Zeitspanne? Ausgereifte Datenprodukte verfügen über Bereitschaftsdienste, Runbooks für die Störungsbehebung und für Nutzer zugängliche Statusseiten.

Ein Datenvertrag für ein Datenprodukt dient der Steuerung. Ein Datenvertrag für einen Datenauszug ist nutzlos.

Laufzeitkurve

Wenn Sie bis hierher gelesen haben, sind Sie wahrscheinlich interessiert. Sie möchten Datenverträge einführen oder zumindest einen Proof of Concept (POC) starten. Als Nächstes werden Sie wissen wollen: Wie lässt sich dies tatsächlich in einem Unternehmen umsetzen? Die meisten Unternehmen können nicht innerhalb eines Quartals von „Stammwissen und Wikis“ zu einer „vollständig vertraglich durchgesetzten Governance“ übergehen. Der realistische Weg umfasst drei Phasen.

Bewusstsein: Das Ziel ist Transparenz. – Die meisten Produzenten wissen tatsächlich nicht, welche Konsumenten von welchen Feldern abhängig sind. – Die meisten Konsumenten wissen tatsächlich nicht, wem die vorgelagerten Daten gehören, auf die sie angewiesen sind. Beide Seiten entdecken die Existenz des jeweils anderen. Die praktischen Maßnahmen in dieser Phase sind überschaubar: automatisierte Datenherkunftsverfolgung, Dashboards, die anzeigen, welche Erstellertabellen am stärksten genutzt werden, Warnmeldungen, wenn Änderungen in vorgelagerten Systemen Auswirkungen auf nachgelagerte Pipelines haben (ohne diese Änderungen jedoch vorerst zu blockieren), sowie ein oder zwei Pilotverträge für Tier-1-Datenprodukte, um den Arbeitsablauf kennenzulernen. Der kulturelle Wandel ist gering, aber real. Die Produzenten beginnen, vor der Freigabe einer Änderung zu fragen: „Wer nutzt das?“

Zusammenarbeit: Verträge entwickeln sich vom Pilotprojekt zur gängigen Praxis. Produzenten und Verbraucher verhandeln diese aktiv. Grundlegende Änderungen durchlaufen einen Überprüfungsprozess, an dem die betroffenen Verbraucher beteiligt sind. Es gilt eine strenge Durchsetzung der Vertragsbedingungen: Ein Produzent darf eine vertragswidrige Änderung nicht ohne die ausdrückliche Zustimmung des Verbrauchers einbinden. Der Vertrag wird zur Plattform, auf der der Dialog zwischen Produzent und Verbraucher stattfindet – nicht im Nachhinein, sondern direkt im Code, noch vor der Bereitstellung.

An dieser Stelle kommt das Wachstum der meisten Organisationen ins Stocken. Der Grund dafür ist nicht technischer Natur, denn die entsprechenden Werkzeuge sind zu diesem Zeitpunkt bereits gut bekannt. Der Grund ist kultureller Art. Zusammenarbeit erfordert, dass die Ersteller akzeptieren, dass ihre Änderungen von den Nutzern blockiert werden können, und das gefällt den Erstellern nicht immer. Die Unternehmen, die diese Hürde überwinden, gestalten die Zusammenarbeit transparent, zügig und reibungslos (die Prüfung eines Vertrags dauert Minuten statt Tage) und verknüpfen diese Vorgehensweise mit für die Führungsebene sichtbaren Kennzahlen, die die Kosteneinsparungen verdeutlichen.

Verantwortlichkeit: Verträge sind keine Sonderregelung mehr. Sie sind die Standardvorgehensweise. Jedes Tier-1-Datenprodukt verfügt über einen solchen Vertrag. Jedes produzierende Team hat einen namentlich benannten Datenproduktverantwortlichen. Vertragsverletzungen führen ebenso regelmäßig zu CI-Fehlern wie fehlgeschlagene Unit-Tests. Die Diskussion in Pull-Anfragen umfasst regelmäßig Erfordert diese Änderung eine Vertragsänderung? Haben wir die betroffenen Verbraucher benachrichtigt? Die Verantwortung für die Daten liegt nicht mehr allein beim Datenteam. Es handelt sich um eine gemeinsame Verantwortung, wobei die Ersteller die operative Verantwortung tragen und die Nutzer die Anforderungen vorgeben. Die Rolle des Datenteams verlagert sich vom Reagieren auf Vorfälle hin zur Bereitstellung der Plattform.

Einige Aspekte, die die Reifekurve nicht verspricht: - Es handelt sich nicht um einen Sechsmonatsplan. Organisationen verbringen mindestens ein Jahr oder länger in jeder Phase. - Es handelt sich nicht um einen einheitlichen organisatorischen Zustand. Verschiedene Teams innerhalb desselben Unternehmens befinden sich an unterschiedlichen Punkten auf der Kurve, und das ist normal. - Und sie verläuft nicht in eine Richtung. Eine Umstrukturierung, ein Führungswechsel oder ein schwerwiegender Vorfall können ein Team von der „Zusammenarbeit“ zurück in die Phase „Bewusstsein“ versetzen. Reife muss aktiv aufrechterhalten werden.

Fazit

Dies war der erste Teil einer zweiteiligen Blogreihe zum Thema Datenverträge. In diesem ersten Teil habe ich mich bewusst auf die Theorie konzentriert, da zunächst die konzeptionellen Grundlagen geschaffen werden müssen. Die technische Umsetzung ist erst dann sinnvoll, wenn man sich über das zu lösende Problem geeinigt hat.

Im zweiten Teil werde ich Ihnen erläutern, wie ein tatsächlicher Vertrag aussieht und wie Sie ihn nutzen können. Zu den Beispielen gehören:

Abschließend möchte ich noch Folgendes anmerken: Vertrauen in Daten lässt sich nicht durch ein weiteres Dashboard, ein weiteres Tool oder einen weiteren Ausschuss aufbauen. Es entsteht vielmehr dadurch, dass die Vereinbarungen zwischen Erzeuger und Verbraucher explizit, maschinenlesbar und verbindlich gestaltet werden.

Ich kann gar nicht genug betonen, wie wichtig die verbindliche Umsetzung ist, damit Datenverträge ein Erfolg werden. Alles andere ist nur guter Wille. Und guter Wille verfliegt schnell.