Regel Nummer eins für qualitativ hochwertige Daten: Stoppen Sie das Laden von Daten von schlechter Qualität. Wirklich, es ist so einfach. Ich sehe so viele Unternehmen, die diesen Fehler machen, und sich dann wundern, warum ihre Datenqualität so schlecht ist.

Das Fast Food der Daten: Erfassen Sie alle Daten!

„Zuerst erfassen, später Fragen stellen.“ Es ist im Grunde der Slogan von Big Data vor einem Jahrzehnt. In gewisser Weise ist es sogar schlimmer als Fast Food, denn bei Fast Food weiß man zumindest, wie viele Kalorien man zu sich nimmt – auch wenn man sich entscheidet, es zu ignorieren. Bei dieser Strategie weiß man einfach nicht, was in den Daten steckt. Das ist die ganze Idee. Zuerst erfassen, später Fragen stellen.

Erfassen Sie alle Daten, leiten Sie sie an die Endbenutzer weiter. Glückliche Tage.

Es ist sinnvoll, dass Unternehmen ihre Dateninitiativen einfach damit beginnen, alles zu erfassen, was sie können. Viele Unternehmen sind seit Jahrzehnten datenhungrig. Und nein, die Datenlager der 90er und 00er zählen nicht. Das ist das Äquivalent eines nordkoreanischen Hungerregimes, bei dem nur die wenigen Glücklichen Zugang zu den Daten hatten und entschieden, wie sie von wem verwendet wurden. Als dann die Cloud- und Big-Data-Technologien aufkamen, machte es viel Sinn, sie so weit wie möglich zu nutzen. Genau wie bei Fast Food schafft dieser Ansatz sofortige Befriedigung. Ihr erster Anwendungsfall ist im Handumdrehen live.

Aber die negativen Auswirkungen kommen später. Die Hauptursache der meisten Datenqualitätsprobleme ist, dass sich die Quellsysteme ohne Vorankündigung ändern. Ihre Schemata ändern sich, ihre zugrunde liegenden Technologien ändern sich, die Infrastruktur, auf der sie bereitgestellt werden, ändert sich, ihre Sicherheitseinstellungen ändern sich, der ganze Zweck ihrer Existenz ändert sich… ständig. Jeder Ausfall kann, wenn Sie Glück haben, ein paar Stunden dauern, um ihn zu beheben, zu debuggen und zu reparieren. Selbst stabile Quellen, die sich nur einmal im Jahr ändern, verursachen viele Ausfälle. Es ist nicht ungewöhnlich, dass Datenabteilungen 1.000+ Tabellen erfassen. Wenn jede Tabelle im Durchschnitt einmal im Jahr geändert wird, bedeutet dies, dass Sie 1.000 Änderungen pro Jahr oder 2–3 Änderungen pro Tag haben. Dies führt dazu, dass die Datenteams einen Großteil ihrer Zeit im „Breakfix“-Modus verbringen.

Jede Änderung in einer vorgelagerten Quelle wird Ihre Pipelines zum Scheitern bringen

Behandeln Sie nicht nur die Symptome!

Sobald es schmerzlich offensichtlich wird, dass die Datenqualität ein Problem darstellt, ergreifen die Datenteams in der Regel die Initiative, um die Dinge zu reparieren. Hier sind einige Dinge, die nur die Symptome bekämpfen, aber nicht die Hauptursache angehen:

1. Schema-Evolution: Ah, die Quelle ändert sich? Kein Problem, wir spiegeln alle Änderungen in unserem Datensee wider. Oder besser noch, wir machen Data Vaulting, sodass wir einfach mehr Satelliten hinzufügen können, um die geänderten Daten zu erfassen. Das funktioniert nicht, denn so clever Sie Ihre Datenpipeline auch entwerfen, sie kann niemals auf zukünftige Änderungen vorbereitet sein. Eine Währungs-Spalte ändert sich von Text in Dezimal, die cust-Spalte wird in customerid umbenannt, das country-Feld wird entfernt oder schlimmer, bleibt einfach leer, oder ganze Tabellen verschwinden einfach in Luft.

2. Installieren (Datenqualitäts-)Monitoring: Toll, dass Sie wissen, wann Dinge abgestürzt sind, aber sie können den Absturz nicht im ersten Fall verhindern. Datenqualitätsüberwachung hat ihren Platz, löst aber keine schlechten Datenqualitäten. Sie macht sie nur sichtbarer. Mehr dazu später!

3. Installieren Sie Daten-Governance-Tools: Wissen Sie, was? Wenn wir herausfinden, wer jede Quelle besitzt, was in dieser Quelle ist, und wir sie bitten, alles zu dokumentieren, werden sie verantwortungsbewusster! Nein, das erzeugt einen Haufen (digitalen) Papierkram, den niemand liest. Wie die Datenqualitätsüberwachung hat auch die Daten-Governance-Software ihren Platz, aber sie löst dieses Problem nicht.

4. Installieren Sie einen Änderungsbeirat: Wir werden den Prozess verbessern! Jeder, der Änderungen in der Produktion vornehmen will, muss dies zuerst im gefürchteten CAB oder Change Advisory Board ankündigen, damit wir dies mit allen besprechen können, die von Ihrem System abhängig sind. Wir gehen zurück zu 4 großen Releases pro Jahr, um es überschaubar zu halten. Das funktioniert nicht, weil oft die Quellsysteme nicht – oder kaum – wissen, dass ihre Daten in Analysen verwendet werden. Es ist nur ein Nachgedanke. Und selbst in den Fällen, in denen das Daten-Team rechtzeitig über die Änderung informiert wird und die richtigen neuen Testdaten erhält, um die Migration ihrer Datenpipelines vorzubereiten, geht es oft schief. Denn die Testdaten ähneln nie den tatsächlichen Produktionsdaten. Und Sie arbeiten immer noch Überstunden, um sich von den Ausfällen zu erholen.

5. GenAI wird all meine Probleme lösen: Das sollte wirklich selbstverständlich sein, aber ich muss es dennoch sagen, da einige Unternehmen hundertprozentig überzeugt sind, dass dies der Weg ist: Nein, Sie können dieses Problem nicht mit GenAI lösen. Ich kenne Datenabteilungen, die im Grunde ihre Daten-Governance-Initiativen gestoppt haben, weil „man jetzt einfach einen Chatbot alles über seine Daten fragen kann und er wird antworten.“ Oh, Sie werden eine Antwort bekommen. Aber auf wessen Grundlage? Wenn Ihre Daten so ein Chaos sind, dass ein menschlicher Experte es nicht manuell lösen kann, wird es auch ChatGPT nicht beantworten können.

Sie benötigen eine Schnittstelle zu Ihren Quellsystemen

Softwareingenieure haben diesen einen Trick, den sie seit Jahrzehnten verwenden. Es nennt sich API. Immer wenn Softwareteams miteinander interagieren wollen, sei es innerhalb des Unternehmens oder nach außen, kommunizieren Sie über diese APIs. Was ein Team hinter jeder dieser APIs tut, geht Sie nichts an. Sie könnten Technologien ändern, die zugrunde liegende Infrastruktur ändern oder Sicherheitseinstellungen ändern. Sie könnten sogar Schemata ändern. Solange sie ihre APIs respektieren, können Sie sie in Ihrer App konsumieren.

Was ist jedoch mit brechenden Änderungen? Nun, dafür haben sie einen Prozess. Er heißt „API veraltet machen“. Es ist immer noch verdammt ärgerlich. Aber Veränderungen passieren. Und einige davon sind brechend. Wenn Sie sich in einer v1 einer beliebigen API befinden, können sie eine v2 veröffentlichen und Ihnen 6 Monate bis ein Jahr geben, um auf v2 umzusteigen, wenn Sie bereit sind. Ist das perfekt? Nein. Aber es funktioniert.

Bedeutet das, dass wir jetzt alle anfangen müssen, APIs in der Datenwelt zu hosten? Überhaupt nicht. Aber wir können anfangen, uns über Schnittstellen mit Quellsystemen zu einigen. Das bedeutet, dass sie eine Reihe von Tabellen vorbereiten, die eine gute Darstellung der Daten sind, die in ihren Systemen vorhanden sind, ohne jede interne Tabelle offenzulegen. Das Quellteam entscheidet über das Format. Sie können dieses Schema in ihrer eigenen Datenbank zur Verfügung stellen oder diese Daten in einer gemeinsamen Datenbank/Lakehouse veröffentlichen, die das gesamte Unternehmen für Analysen nutzt. Wenn sie jemals brechende Änderungen haben, können sie eine v2 dieser Tabellen in einem anderen Schema veröffentlichen, während sie v1 parallel veröffentlichen. Sobald alle Verbraucher auf v2 migriert sind, können Sie die v1-Schnittstelle schließen.

Wenn Sie das gut machen, gestalten Sie Ihre Schnittstelle so, dass sie leicht konsumierbar ist. Betriebssysteme speichern Daten normalerweise in normalisiertem Format. Daher müssen Sie 300 exotische Joins machen, um irgendwelche Erkenntnisse zu erhalten. Sie können den Konsum Ihrer Daten vorbereiten, indem Sie 4 breite Tabellen anstelle von 100 kleinen veröffentlichen. Das hält Ihre Schnittstelle einfach und verständlich.

Saubere Trennung von Quellsystemen und Datenprodukten

Herzlichen Glückwunsch, Sie haben gerade Ihr erstes Source Aligned Data Product erstellt. Wir haben darüber bereits hier gebloggt: https://medium.com/datamindedbe/source-aligned-data-products-the-foundation-of-a-scalable-data-mesh-228528720bd1

Hindernisse: Warum ist das noch nicht alltäglich?

Fast jeder in der Datenabteilung, mit dem Sie sprechen, denkt, dass dies eine fantastische Idee ist. Und es hat einen klaren Erfolgsvorlauf in der Softwarewelt. Warum machen wir das also nicht die ganze Zeit? Es gibt ein paar Hindernisse:

1. Das verursacht zusätzliche Arbeit und Verantwortung für die Teams, die die Quellsysteme betreiben. Das sind unterschiedliche Budgets, unterschiedliche Backlogs, unterschiedliche Abteilungen… Warum sollten sie in das investieren? Sie haben wirklich keinen Anreiz, dass andere ihre Daten verwenden. Und wenn sie selbst Analysen durchführen wollen, wissen sie am besten, was in ihren Daten steckt, also haben sie kein Problem, direkt darauf zuzugreifen und einige Abfragen auszuführen.

2. Es ist schwieriger einzurichten, als einfach die Quelldaten zu kopieren: Es gibt nichts Einfacheres als eine JDBC-Verbindung und einen SELECT *-Befehl, der jede Nacht ausgeführt wird. Wenn Sie Glück haben, müssen Sie nicht einmal mit dem Ingenieur auf der anderen Seite sprechen. Sie können alle Daten kopieren, die Sie möchten, wann immer Sie möchten, in dem Format, das Ihnen am besten gefällt. Sie fühlen sich super produktiv. Einige Unternehmen haben sogar Kennzahlen darüber, wie viele Datenquellen bereits in den See aufgenommen wurden.

3. Diese Ideen sind relativ neu: Während sie in der Softwarewelt alltäglich sind, sind sie in der Datenwelt relativ neu. Das Konzept eines Data Mesh wurde erst vor ein paar Jahren eingeführt. Das Denken in Datenprodukten ist immer noch ein junges Konzept. Datenverträge leben größtenteils in Blogs und LinkedIn-Beiträgen – nicht so sehr in der Produktion.

Wie fangen Sie an, das Denken in Datenprodukten für Quelldaten zu übernehmen?

Zuerst kommt der Wert

Wenn Sie noch keinen Datenanwendungsfall in der Produktion haben, der geschäftlichen Wert liefert, tun Sie das zuerst. Sie werden keine zusätzlichen Budgets erhalten oder andere Teams überzeugen, etwas für Sie zu tun, bis Sie der Organisation erheblichen Wert nachgewiesen haben. Also hacken Sie den ersten Anwendungsfall zusammen. Erfassen Sie Daten direkt aus der Quelle. Vergessen Sie alles, was ich oben geschrieben habe. Schaffen Sie Wert. Wie Sie das tun, ist ein Thema für einen anderen Beitrag.

Arbeiten Sie an geschäftskritischen Anwendungsfällen

Die harte Wahrheit ist, dass Unternehmen sich in der Regel nicht ändern, es sei denn, sie haben einen echten Grund zur Veränderung. Möglicherweise schaffen Sie mit ein paar einfachen Tableau-Dashboards, die jeden Monat aktualisiert werden müssen, eine Menge Wert. Glückwunsch. Das ist ein guter Ort. Das bedeutet wahrscheinlich, dass Sie nur ein paar Datenquellen haben, die wichtig sind, und sie brechen ab und zu. Kein Problem, Sie reparieren es nächste Woche. Sobald Sie aktiven Handel basierend auf den Daten, die Sie erfasst haben, machen, oder Sie einen KI-Chatbot für Kunden unter Verwendung von Daten aus den Betriebssystemen erstellen, können Datenqualitätsprobleme beginnen, viel Geld, Reputation oder beides zu kosten. Glauben Sie mir, jetzt haben Sie die Ohren der Führungskräfte in der Organisation, was großartig ist, denn Sie benötigen dies für den nächsten Schritt.

Holen Sie sich die Zustimmung der Führung

Jeff Bezos schrieb berühmt eine E-Mail an alle Amazon-Mitarbeiter, in der er im Grunde die Verwendung von APIs dekretiert. Die Chancen stehen gut, dass Ihre Führungskräfte weniger technikaffin sind als Jeff Bezos. Trotzdem ist jetzt der Zeitpunkt, um ihre Hilfe zu bitten. Denn denken Sie an das erste Hindernis? Das wird Arbeit für die Operationsteams verursachen. Sie benötigen Budgets, um das zu tun. Und neben den Budgets müssen sie den Sinn erkennen. Wenn Sie Schritt 1 und 2 erledigt haben, wird es einfach, sie von dem Wert Ihrer Arbeit zu überzeugen. Aber selbst dann wird es Abteilungen geben, die sich freuen, an Bord zu springen, und Abteilungen, die sich gegen jede Veränderung sträuben. Versuchen Sie nicht, die gesamte Organisation auf einmal zu verändern. Machen Sie Ihre größten Unterstützer erfolgreich. Wenn andere Geschäftsleiter das sehen, werden sie sich bald auch umdrehen. Und für die wenigen Zögerer, die unweigerlich zurückbleiben, kann die Unternehmensführung sie einfach überstimmen. Die Reihenfolge ist hier wichtig. Beginnen Sie nicht damit, als Datenpolizei aufzutreten, die alle zwingt, für Sie zu arbeiten, bevor Wert geliefert wird. Die Verantwortung liegt bei Ihnen, sie von dem Wert zu überzeugen, den Sie bringen.

Installieren Sie die richtigen Werkzeuge, um den Fortschritt zu überwachen und Governance zu bringen

Wenn Sie den Domains mehr Verantwortung geben möchten, müssen Sie einige Dinge in place(no translate needed). Wenn man ins Detail geht, wäre das Material für einen weiteren Blog, aber hier sind die üblichen Verdächtigen:

1. Datenqualitätswerkzeuge: Ja, die benötigen Sie. Denn selbst mit den besten Absichten werden Sie immer noch schlechte Datenqualität erzeugen. Sie müssen diese Probleme frühzeitig erkennen und idealerweise die Ausbreitung von schlechter Qualität downstream stoppen.

2. Datenverträge: Was APIs für die Softwarewelt sind, sind Datenverträge für die Datenwelt. Sie müssen sich darauf einigen, welche Daten Sie für den nachgelagerten Verbrauch zur Verfügung stellen. Ein Datenvertrag kann eine einfache Dokumentationsseite sein. Aber es ist besser, wenn es eine Lösung gibt, die diese Verträge aktiv durchsetzt, damit Sie versehentlich Ihren eigenen Vertrag nicht brechen.

3. Datenkatalog: Es ist auch hilfreich, wenn Sie mindestens Ihre Schnittstellen in einem Datenkatalog dokumentieren, damit die Leute herausfinden können, was jeder Datensatz bedeutet und wer ihn besitzt.

4. Datenprodukt-Marktplatz: Wenn Sie dezentralisiert arbeiten, werden mehrere Teams Datenprodukte erstellen. Während ein Datenlager zentralen kommunistischen Produktions ähnelt, sind Datenprodukte das Äquivalent eines freien Marktes. Sie möchten, dass Teams in der Lage sind, ihre Datenprodukte zu veröffentlichen, ihren Zweck, ihre Inhalte und ihre Eigentümer zu dokumentieren. Sie möchten, dass andere Teams Datenprodukte auf eine geregelte Weise konsumieren können. Sie möchten eine hochrangige Linienführung sehen, wie Ihre Daten in der Organisation verwendet werden. Schauen Sie sich unseren eigenen Datenprodukt-Marktplatz hier an: https://github.com/conveyordata/data-product-portal. Es ist Open Source und wird von Unternehmen verwendet, die bereits weit fortgeschritten sind auf ihrem Weg zu Datenprodukten.

Leisten Sie die Vorarbeit für die föderierten Teams

Vergessen Sie nicht, dass sie Hilfe benötigen – auch wenn sie die besten Absichten haben. Ein Ansatz, der uns geholfen hat, ist, dass die Datenabteilung diese Verantwortung für die wichtigsten Datenquellen übernimmt. Das bedeutet, dass das zentrale Datenteam die quellen-aligned Datenprodukte erstellt. In diesen Fällen ist es wichtig, dass jemand aus der Quell-Domain der Datenproduktschöpfer wird. Auch wenn dies nichts mehr bedeutet als ein wöchentliches Treffen mit dem Team, ist es entscheidend, dass die geschäftliche Verantwortung der veröffentlichten Daten bei jemandem liegt, der die Daten versteht. Und überraschend für manche ist das fast nie das Daten-Team. Wir haben in der Regel keine Ahnung, was die Daten bedeuten, die wir erfassen. Und wir sollten das auch nicht müssen. Wir können die Daten von einem Dutzend verschiedener Abteilungen nicht in unseren Köpfen unterbringen.

Drücken Sie schrittweise mehr Verantwortung auf die Abteilungen

Sie können die Datenübernahme in einer Organisation nicht wirklich skalieren, ohne dass jede Abteilung Verantwortung für ihre eigenen Daten übernimmt. Ich habe Teams getroffen, die versucht haben, alles zentral zu erledigen, und sie stoßen auf unvermeidliche Engpässe. In einem Fall traf ich einen genialen Datenanalyst – nennen wir ihn Frank. Frank ist wirklich einer der smartesten Menschen, die ich je getroffen habe. Er arbeitete über ein Jahrzehnt in der Datenabteilung des Unternehmens. Er kannte die Daten des Data Warehouses in- und auswendig. Und er war fleißig darin, seine Erkenntnisse zu dokumentieren, was in buchstäblich Hunderte von Seiten von Datenbeschreibungen resultierte. In Meetings konnte er Fragen in 5 Minuten beantworten, für die ein Junioranalyst 3 Monate bräuchte, um sie herauszufinden. „Ah, Sie möchten diese Erkenntnis? Dann müssen Sie Tabelle A aus Datenbank X mit Tabellen B und C vom Mainframe verknüpfen. Achten Sie darauf, die custid-Spalte zu ignorieren. Ich weiß, dass sie noch da ist, aber seit der Änderung zu einem neuen System vor 4 Jahren kann dieses Feld Ungenauigkeiten aufweisen, wenn Sie versuchen, zu tun, was Sie tun möchten. Es ist besser, die custid aus Datenbank Y zu beziehen. Aber mein Gedächtnis ist ein bisschen eingerostet; ich müsste die Dokumentation nochmal überprüfen, um genau zu sehen, wie das geht.“ „Wow, danke Frank, das hätten wir niemals ohne Sie herausgefunden. Nicht in einer Million Jahren.“ Das Problem ist, ich kenne nur wenige Organisationen, die einen Frank haben. Und selbst die, die das tun, benötigt Frank auch Urlaub. Und Frank könnte in naher Zukunft in den Ruhestand gehen. Außerdem, so genial Frank auch ist, er kann nicht die gesamten Unternehmensdaten in seinem Kopf behalten. Frank ist in der Regel der Erste, der das gesteht.

So sollten früher oder später die Verantwortlichkeiten auf die Abteilungen übertragen werden. Für machthungrige Datenleiter könnte dies eine bittere Pille sein. Denn Sie haben weniger direkte Kontrolle. Sie müssen sich die Frage stellen: Bin ich hier, um alle Datenanwendungsfälle zu implementieren? Und die Antwort auf diese Frage ist Nein. Ihr Unternehmen hat auch keine E-Mail-Abteilung, die alle E-Mails versendet. Sie sind hier, um die Organisation zu befähigen, Daten optimal zu nutzen. Die habilitierende Arbeit sollte zentral im Datenteam erledigt werden. Je mehr Sie die einzelnen Anwendungsfälle auf die Abteilungen übertragen können, desto mehr Einfluss können Sie ausüben. Denken Sie daran: Statt eines zentralen Datenteams von 30 Personen haben Sie nun ein verteiltes Datenteam von 300 Personen. Und das Beste daran ist, während sie alle daran arbeiten, aus Daten Wert zu schaffen, tun nur 10 % von ihnen dies mit Ihrem Budget

Domainbesitz von Datenprodukten

Fazit

Das Lösen von Datenqualitätsproblemen kann nicht allein mit Werkzeugen erledigt werden. Es benötigt organisatorische Veränderungen. Hier ist ein Weg, der für uns erfolgreich war:

1. Zuerst kommt der Wert

2. Arbeiten Sie an geschäftskritischen Anwendungsfällen

3. Holen Sie sich die Zustimmung der Führung

4. Installieren Sie die richtigen Werkzeuge, um den Fortschritt zu überwachen und Governance zu bringen

5. Leisten Sie die Vorarbeit für die föderierten Teams

6. Drücken Sie schrittweise mehr Verantwortung auf die Abteilungen