Warum starre Data Catalog Strategien scheitern – und wie Open Source neue Möglichkeiten eröffnet
Warum starre Data Catalog Strategien scheitern – und wie Open Source neue Möglichkeiten eröffnet
Data Governance in der Praxis
Es ist Montagmorgen, 9:15 Uhr. Mein Team-Lead kommt auf mich zu: „Der Vertrieb braucht dringend eine Auswertung über alle kunden-exklusiven Verträge. Kannst du die Daten bis Ende der Woche bereitstellen?“ Ich nicke, notiere mir die Anforderung und beginne mit der Arbeit. Was ich zu diesem Zeitpunkt nicht weiß: Drei Stockwerke weiter arbeitet ein Kollege aus dem SAP-Team bereits seit zwei Wochen an exakt denselben Daten – nur dass sein Fachbereich sie „kunden-spezifische Verträge“ nennt.
Das klingt wie ein absurdes Missverständnis aus einer Sitcom. Leider ist es bittere Realität in vielen wachsenden Datenorganisationen – die Folge fehlender Datentransparenz. Und die kostet Unternehmen mehr, als den meisten bewusst ist.
Das Szenario
Zwei Teams, eine Datenmenge, null Koordination
Unser Data-Engineering-Team ist in den letzten Monaten gewachsen – eine gute Entwicklung. Team A, zu dem ich gehöre, fokussiert sich auf die Migration historischer Daten von einer alten On-Premise-Instanz in unseren neuen Cloud Data Lake. Team B arbeitet parallel daran, aktuelle Geschäftsdaten aus dem SAP-System zu extrahieren und ebenfalls im Data Lake bereitzustellen. Beide Teams kennen den Data Lake. Aber Team B hat keinen Einblick in die alte On-Prem-Welt, und wir haben nur begrenztes Wissen über die SAP-Strukturen.
Organisatorisch sind wir klar getrennt: unterschiedliche Führungsebenen, unterschiedliche Stakeholder, unterschiedliche Prioritäten. Als die Anforderungen reinkommen, passiert genau das, was passieren muss: Beide Teams machen ihren Job. Wir ziehen beide die gleichen Daten, transformieren sie nach unseren jeweiligen Anforderungen, dokumentieren sie in unseren eigenen Projekt-Wikis und liefern sie fristgerecht ab.
Erfolg auf ganzer Linie – könnte man meinen.
Die Kosten
Die versteckten Kosten fehlender Datentransparenz
Erst Wochen später, bei einem zufälligen Gespräch in der Kaffeeküche, stellt sich heraus: Wir haben beide exakt dieselbe Datenmenge bearbeitet. „Kunden-exklusiv“ und „kunden-spezifisch“ waren nur unterschiedliche Bezeichnungen aus verschiedenen Fachbereichen für denselben Inhalt. Der Ärger darüber vergeht schnell, aber die Konsequenzen bleiben:
- Doppelte Entwicklungskosten: Zwei Teams haben unabhängig voneinander Extraktionslogik entwickelt, getestet und dokumentiert. Bei durchschnittlich 100 Stunden pro Team sind das 200 Entwicklerstunden – bei einem konservativen Stundensatz von 100 € also 20.000 € allein für die Erstentwicklung.
- Doppelte Wartungskosten: Beide Pipelines müssen jetzt gepflegt werden. Ändert sich die Quelldatenstruktur, müssen beide Teams reagieren. Taucht ein Bug auf, wird er möglicherweise nur in einer Pipeline gefixt. Die laufenden Kosten summieren sich Jahr für Jahr.
- Inkonsistente Definitionen: Noch problematischer: Die beiden Fachbereiche arbeiten jetzt mit potenziell unterschiedlichen Interpretationen derselben Daten. Team A hat vielleicht historische Verträge inkludiert, die Team B bewusst ausgeschlossen hat. Welche Zahlen sind nun richtig, wenn die Geschäftsführung nach „kunden-spezifischen Umsätzen“ fragt?
- Verlorenes Vertrauen: Kommen solche Diskrepanzen ans Licht, leidet das Vertrauen in die gesamte Dateninfrastruktur. Fachbereiche beginnen, Zahlen zu hinterfragen, verlangen manuelle Abgleiche – und im schlimmsten Fall bauen sie ihre eigenen Schatten-Datenbanken auf.
Realistisch betrachtet landen wir schnell bei Gesamtkosten von 50.000 € oder mehr – nur weil zwei Teams nicht wussten, dass der jeweils andere bereits an denselben Daten arbeitet.
Data Catalog
Mehr Datentransparenz: wo ein Data Catalog geholfen hätte
Die Ironie an der Geschichte: Das Problem wäre mit relativ einfachen Mitteln vermeidbar gewesen. Ein funktionierender Data Catalog hätte an drei konkreten Stellen eingegriffen.
1. Data Discovery: „Gibt es das schon?“
Bevor ich mit der Entwicklung beginne, ist die erste Frage immer: Existieren diese Daten bereits irgendwo in unserem Data Lake? Ein Data Catalog mit grundlegender Suchfunktion hätte mir innerhalb von Minuten gezeigt: Ja, ein anderes Team hat bereits eine Datenmenge angelegt, die verdächtig ähnlich klingt. Allein diese Information hätte ausgereicht, um das Gespräch mit dem SAP-Team zu suchen.
Ohne Catalog heißt es: Kollegen fragen, in Wikis suchen, alte Confluence-Seiten durchforsten – vielleicht findet man etwas, vielleicht auch nicht. Meist ist der Zeitdruck zu hoch, um gründlich zu recherchieren, und man baut lieber neu, als zu riskieren, eine Deadline zu verpassen.
2. Business Glossar: „Reden wir vom Gleichen?“
Der Kern des Problems lag in der Terminologie. „Kunden-exklusiv“ und „kunden-spezifisch“ klangen unterschiedlich genug, dass niemand auf die Idee kam, sie könnten identisch sein. Ein gepflegtes Business Glossar hätte diese Begriffe definiert, ihre Synonyme aufgelistet und idealerweise auf die zugrunde liegenden Datenquellen verwiesen.
Das Business Glossar ist nicht nur ein Wörterbuch – es ist der gemeinsame Sprachcode für das gesamte Unternehmen. Schauen beide Fachbereiche in dasselbe Glossar und sehen „Kunden-exklusive Daten = Kunden-spezifische Daten = Verträge mit Exklusivitätsklausel gemäß Tabelle XYZ“, gibt es kein Missverständnis mehr.
3. Data Lineage: „Woher kommt das?“
Selbst wenn die Terminologie unklar bleibt, hätte ein Blick auf die Data Lineage Klarheit geschaffen. Stammen beide Datensätze letztendlich aus derselben Quelltabelle und durchlaufen ähnliche Transformationen, ist die Wahrscheinlichkeit hoch, dass es sich um dieselben Daten handelt. Lineage visualisiert diese Zusammenhänge und macht Duplikate sichtbar, bevor sie zum Problem werden.
Open Source
Der pragmatische Weg: Open Source als Realitätscheck
Jetzt könnte man sagen: „Gut, dann kaufen wir eben einen Enterprise Data Catalog, und das Problem ist gelöst.“ Doch genau hier liegt die Gefahr, in alte Muster zurückzufallen. Ein teures Tool einzukaufen, ohne die Prozesse und die Kultur dahinter etabliert zu haben, führt wieder zu den Problemen, die wir in unserem Beitrag zu starren Data-Catalog-Strategien beschrieben haben: überkomplexe Lösungen, fehlende Adoption, vererbte Stewardship ohne echtes Commitment.
Der pragmatischere Ansatz ist ein Proof of Concept mit Open-Source-Data-Catalog-Tools. Diese liefern genau die drei Kernfunktionen, die wir für unser Szenario gebraucht hätten:
- eine zentrale Suchfunktion für alle Datasets im Data Lake,
- ein einfaches Business Glossar zur Begriffsdefinition,
- eine grundlegende Lineage-Visualisierung.
Mehr braucht es zunächst nicht. Der entscheidende Unterschied: Ein Open-Source-PoC zwingt Teams dazu, sich auf das Wesentliche zu konzentrieren. Es gibt keine hundert Features, die konfiguriert werden wollen. Stattdessen stellt sich schnell die Frage: Nutzen wir das überhaupt? Pflegt irgendjemand das Glossar? Schauen die Teams tatsächlich nach, bevor sie neue Pipelines bauen?
Business Case
Der Business Case schreibt sich von selbst
Hier schließt sich der Kreis zum strategischen Wert von Data Governance: Verhindert ein simpler Open-Source-Catalog innerhalb von drei Monaten auch nur einen einzigen Fall von Duplikation, hat er sich bereits amortisiert. 50.000 € vermiedene Kosten gegen ein paar Tage Implementierungsaufwand – das ist eine Rechnung, die auch dem Controlling einleuchtet.
Noch wichtiger: Es ist der Beweis, dass Data Governance kein theoretisches Konstrukt ist, sondern ein handfester Kostenfaktor. Unternehmen können damit argumentieren: „Ja, das Konzept funktioniert. Es spart uns Geld. Es verhindert Chaos. Jetzt sind wir bereit für den nächsten Schritt.“
Vielleicht ist das der Moment, in dem aus einem skeptischen „Müssen wir wirklich einen Data Catalog einführen?“ ein überzeugendes „Wir können es uns nicht leisten, keinen zu haben“ wird.
FAQ
Häufige Fragen zu Datentransparenz und Data Catalog
Was kostet fehlende Datentransparenz?
Mehr als meist gedacht: doppelte Entwicklung und Wartung, inkonsistente Definitionen und verlorenes Vertrauen in die Daten. Schon ein einziger Fall paralleler Arbeit an denselben Daten kann sich realistisch auf 50.000 € oder mehr summieren.
Welche Funktionen eines Data Catalogs sind am wichtigsten?
Für den Einstieg drei: Data Discovery, um vorhandene Daten zu finden, ein Business Glossar für gemeinsame Begriffe und Data Lineage, um Herkunft und Zusammenhänge von Daten sichtbar zu machen.
Was ist ein Business Glossar?
Ein gemeinsames Verzeichnis fachlicher Begriffe mit Definitionen, Synonymen und Verweisen auf die zugrunde liegenden Datenquellen – der gemeinsame Sprachcode für das ganze Unternehmen.
Brauchen wir gleich einen Enterprise Data Catalog?
Nicht zwingend. Ein Proof of Concept mit Open-Source-Tools zeigt schnell, ob Teams den Catalog nutzen und pflegen – ohne Feature-Overkill und mit messbarem Nutzen als Basis für den nächsten Schritt.
Fazit
Datentransparenz und die 50.000-Euro-Frage
Wie viele dieser stillen Duplikationen gibt es in deiner Organisation? Wie oft arbeiten Teams parallel an denselben Daten, ohne es zu wissen? Wie viele Entwicklerstunden verschwinden in redundanten Pipelines, inkonsistenten Definitionen und endlosen Abstimmungsschleifen? Die Antwort kennt niemand genau – und genau das ist das Problem.
Ein Data Catalog macht diese versteckten Kosten sichtbar. Er zeigt, wo Daten bereits existieren, bevor neue gebaut werden. Er klärt, was Begriffe wirklich bedeuten, bevor Teams aneinander vorbeireden. Und er dokumentiert, woher Daten kommen, bevor sie in Silos verschwinden. Vielleicht ist es an der Zeit, Data Governance nicht mehr als abstraktes Konzept zu diskutieren, sondern als konkrete Investition in Effizienz.
Du erkennst dich in diesem Szenario wieder? Dein Bauchgefühl sagt dir, dass ähnliche Duplikationen auch in deinem Data Lake schlummern? Lass uns darüber sprechen. Ein Open-Source-basierter Proof of Concept kann der pragmatische Einstieg sein – ohne Perfektionismus, ohne Feature-Overkill, aber mit messbarem Business Value.
Über den Autor: Sven Landmann, Senior Consultant Data
Hinweis: Dieser Beitrag wurde mit Unterstützung von KI erstellt oder überarbeitet. Inhalte, Struktur und fachliche Bewertung stammen aus der Projektpraxis von cimt; redaktionelle Prüfung und Freigabe erfolgen durch die Autorinnen und Autoren.
Kontakt
Michael SchwarzHead of Business Enablement & Customer Relations
Heimspiel KI in Frankfurt – live erleben
Am 25. November zeigen wir im Stadion von Eintracht Frankfurt, wie aus KI-Piloten produktive Prozesse werden – mit echten Projekten, Praxisberichten und Networking. Gemeinsam mit Camunda. Teilnahme kostenfrei, Plätze begrenzt.
Data Governance in der Praxis
Das 50.000-€-Problem: Wie fehlende Datentransparenz zur stillen Ressourcenverschwendung führt
Zwei Teams bauen dieselben Daten zweimal – nur weil Fachbereiche unterschiedliche Begriffe nutzen. Wie fehlende Datentransparenz schnell 50.000 € kostet und ein Data Catalog das verhindert.