Diskussion über die Gestaltung eines Datensystems mit einem auf Governance priorisierenden Denkmodell

Einführung – Governance neu denken

Wenn ich das Wort „Governance“ höre, stelle ich mir sofort Menschen vor, die „Nein!“ sagen, den Zugang blockieren, Genehmigungen verlangen und vielleicht sogar ein bisschen streng wirken. Für mich ist Governance eher ein Hindernis als ein Treiber.

Ehrlich gesagt finde ich es langweilig. Ich vermeide alles, was sich wie Sicherheit oder Compliance anfühlt. Ich habe Sicherheitszertifizierungen übersprungen, weil es sich anstrengend anfühlte, mich in Zugangspolitiken und Auditprotokolle zu vertiefen.

Ich erinnere mich noch, wie ich in der frühen Phase meiner Karriere Zugang zu einem Datensatz für ein Projekt brauchte. Es dauerte mehrere Tage, und ich wechselte zwischen verschiedenen Teams. Als ich endlich den Zugang erhielt, hatte sich die Projektrichtung bereits geändert.

In diesem Moment bildete sich in mir die Überzeugung: Governance behindert alles! Viele Leute finden Umgehungsmöglichkeiten für diese Reibungen: lokale Kopien, nicht-offizielle Pipelines, nicht-dokumentierte Abkürzungen.

Ich mache es auch „manchmal“, insbesondere bei Forschungsversuchen, bei denen Governance keine dringende Angelegenheit ist. Aber was in isolierten Experimenten funktioniert, funktioniert nicht in Systemen, die auf Skalierbarkeit, Zusammenarbeit oder die Bedienung echter Benutzer ausgelegt sind.

Es hat mich einige Zeit und einige „Überraschungen“ gekostet, um zu verstehen, dass Governance kein „später zu bearbeitendes“ Thema ist. Sie ist keine Hürde, keine Kosten, sondern ein Design! Dieser Artikel ist eine strukturierte Überlegung zu dieser Erkenntnis aus einer anderen Perspektive.

Governance ist nicht mehr etwas, was ich vermeide. Es ist etwas, über das ich von Anfang an gründlich und systematisch nachdenke!

Um dieser Denkweise eine Architektur zu geben, können wir uns das DAMA-Modell ansehen. Ich werde nicht das gesamte Modell erklären; es ist sehr umfangreich und deckt mehr ab, als ich hier behandeln kann. Stattdessen werde ich meine Lernerfolge auf ausgewählte Teile des Modells abbilden, nicht als abstrakte Theorie, sondern als Methode, um praktische Erkenntnisse an etwas Strukturiertem und Allgemein Anerkanntem zu verankern. Man könnte sagen, ich werde mich bei Bedarf auf das DAMA-Modell beziehen, aber es ist nicht der Schwerpunkt, sondern eine nützliche Referenz, um meine Überlegungen zur Governance zu formen.

➀ Governance ist nicht nur Zugangskontrolle

Governance war lange Zeit an der Peripherie meines Bewusstseins. Als Data Scientist habe ich es normalerweise als Synonym für Zugangskontrolle angesehen, d. h. wer kann was lesen und wo kann wer schreiben. Angesichts der Art meiner Arbeit ist das logisch.

Wenn Sie ein Data Scientist oder Analyst sind, haben Sie vielleicht Ihre eigene Meinung, Governance ist etwas, das Sie gelegentlich im Hintergrund begegnen, wenn Sie Zugang anfordern.

Aber das ist nur ein Teil der Gesamtsituation.

Als ich die Rolle eines Architekten übernahm, änderte sich meine Beziehung zur Governance.

Plötzlich ging es nicht nur darum, „Kann jemand auf diese Tabelle zugreifen?“, sondern um Vertrauen, Nachverfolgbarkeit und langfristige Wartbarkeit.

Ich musste darüber nachdenken, wie das System aufgebaut ist, wie Teams zusammenarbeiten und wie die Entscheidungen von heute morgen verstanden werden können. In diesem Moment erkannte ich, dass Governance Zugangskontrolle umfasst, aber nicht durch sie definiert wird.

Das DAMA-Framework hat mir geholfen, dies zu verstehen. Mit seinen Begriffen habe ich festgestellt, dass das, was ich in der Vergangenheit als „Governance“ bezeichnet habe, tatsächlich nur einen kleinen Teil des Bereichs Datensicherheit abdeckt.

Aber der Bereich Datengovernance in DAMA hat mir Konzepte vorgestellt, auf die ich bisher wenig geachtet habe, wie z. B. Verwaltung und Entscheidungsbefugnis.

Auf den ersten Blick klingen diese Begriffe abstrakt. Aber wenn man genauer hinsieht, stellt man fest, dass sie genau die Lücken beschreiben, die ich festgestellt habe.

🏷️ Die Essenz der Datenverwaltung liegt darin: Wer verwaltet diese Daten? Tatsächlich ist die Datenverwaltung derjenige, der dafür sorgt, dass alle Daten dokumentiert sind, die Definitionen konsistent bleiben und Qualitätsprobleme zeitnah behoben werden und nicht ignoriert werden. Wenn jemand fragt: „Was bedeutet diese Spalte?“, ist der Datenverwalter derjenige, der die Bedeutung der Daten wirklich versteht oder weiß, wen er fragen muss!

Ja, vielleicht fragen Sie sich: „Was ist der Unterschied zwischen Verwaltung und Eigentum?“ Ich hatte dieselbe Frage.

Kurz gesagt: Eigentum bezieht sich auf Verantwortung, Verwaltung bezieht sich auf Aufgaben.

Sogar wenn Sie nicht persönlich mit den Daten arbeiten, können Sie die Daten besitzen, wichtige Entscheidungen treffen und für die Ergebnisse verantwortlich sein. Im Gegenteil können Sie die Daten verwalten, ihre Qualität und Verfügbarkeit aufrechterhalten, ohne bei Problemen die endgültige Verantwortung zu übernehmen. Beispielsweise sagt ein Datenadministrator (z. B. ein BI-Entwickler oder ein Business Analyst): „Diese Zahl scheint falsch zu sein. Ich denke, sie enthält falsche Einnahmen.“ Der Dateninhaber (z. B. ein Finanzpartner) sagt: „Danke, wir werden das jetzt beheben und sicherstellen, dass es nicht wieder passiert.“

Die Entscheidungsbefugnis befasst sich mit einem oft übersehenen Problem: Wer trifft Entscheidungen über diese Daten? Wer entscheidet über die Umbenennung von Feldern, die Änderung des Datentyps oder die Neudefinition von Indikatoren? In vielen Teams erfolgen Änderungen ad-hoc, vorangetrieben von denen, die sie benötigen. Eine gute Governance führt für diese Entscheidungen einen klaren Prozess ein, um sicherzustellen, dass Änderungen gründlich überlegt werden und ihre Auswirkungen leicht verständlich sind.

Als Architekt hat mich die breitere Sichtweise auf Governance bewusst gemacht, dass Governance nicht nachträglich repariert werden kann, sondern frühzeitig geplant werden muss!

② Ein Blick auf das DAMA-Governance-Architektur

An diesem Punkt fragen Sie sich vielleicht: Was ist das DAMA-Modell überhaupt? Was umfasst es? Was habe ich noch übersehen?

Ich hatte ähnliche Zweifel. Vor allem, weil Menschen oft bekannte Konzepte wie Datenqualität, Zugangskontrolle, Metadaten auflisten und dann einfach „usw.“ hinzufügen, als ob alles andere nur ein vagees, nachträglich gedachtes Konzept wäre.

Das mag ein harmloser Witz sein, aber in technischen Gesprächen bedeutet „usw.“ normalerweise, dass wir das Verständnislimit erreicht haben. Ehrlich gesagt habe ich auch in der obigen Vergleichsabbildung darauf hingewiesen (die Spitze des Eisbergs, ich habe „… usw.“ erwähnt).

Genauer gesagt listet das DAMA-Framework 11 verschiedene Datenverwaltungsbereiche auf. Es ist keine Liste oder ein Schritt-für-Schritt-Ansatz, sondern eher eine Karte. Karten sind nützlich, insbesondere für Architekten.

Der Mittelpunkt des Rads ist die Datengovernance. Sie ist nicht nur einer von vielen Frameworks, sondern die koordinierende Schicht, die alles zusammenhält.

Die umliegenden Bereiche umfassen Datenarchitektur, Metadatenverwaltung, Datensicherheit, Datenqualität und „weitere“ Bereiche, die jedoch klar definiert und sinnvoll sind.

Allerdings ist es so: Wenn Sie ein Datenarchitekt sind, ist nur einer dieser Bereiche, nämlich die Datenarchitektur, wörtlich mit dem Wort „Architektur“ im Titel versehen. Aber in der Praxis werden Sie von fast allen Bereichen angezogen.

Sie werden Entwurfsentscheidungen treffen, die auf einer guten Metadatenverwaltung beruhen.

Sie werden Systeme übernehmen, die nicht klar verwaltet werden, und werden aufgefordert, sie „skalierbar zu machen“.

Sie werden Pipelines aufbauen, die davon ausgehen, dass die Daten vertrauenswürdig und verwaltet sind.

Sie müssen die Qualität modellieren, über Silos hinweg integrieren und bei der Ausführung „sicherstellen“.

Also: Ein Architekt besitzt nicht das gesamte DAMA-System. Aber wenn Sie seine Bestandteile nicht kennen, könnten Sie am Ende versehentlich um sie herum entwerfen oder, noch schlimmer, Sie ignorieren sie, bis sie in der Produktion ausfallen.

③ Vertrauen durch Metadaten und Herkunft aufbauen

Sobald ich begann, Governance als Entwurf und nicht als Beschränkung zu sehen, konnte ich nicht aufhören, alle subtilen, stillen Arten zu bemerken, wie das Vertrauen in einem System zusammenbricht.

Es ist nicht immer spektakulär. Es ist kein Datenschutzverstoß oder Systemausfall. Es ist subtiler: Jemand zögert, einen Datensatz zu verwenden, weil er sich nicht sicher ist, ob er aktuell ist. Dashboards werden verworfen, weil niemand sich mehr daran erinnert, wie eine Zahl berechnet wurde. Junior-Analysten erstellen Berichte von Grund auf neu, weil sie die vorhandenen Berichte nicht finden oder nicht vertrauen können.

Diese Situationen tauchen selten in Ereignisprotokollen auf, aber sie sind die wirklichen Kosten eines mangels Governance. Sie verlangsamen das Team, verursachen Redundanzen und schwächen das Vertrauen.

Damals erkannte ich: Governance geht nicht nur darum, wer Zugang hat, sondern auch darum, ob die Menschen dem, was sie nach dem Zugang sehen, vertrauen können.

Dieses Vertrauen kommt nicht von Dashboards oder Dokumentationen. Es kommt von Metadaten und Herkunft!

Metadaten: Das eigene Gedächtnis des Systems

Metadaten sind nicht nur eine Beschreibung oder ein Label. Sie sind das Gedächtnis des Systems!

Sie ermöglichen es, dass Datensätze sich selbst erklären. Sie ermöglichen es den Menschen, komplexe Situationen ohne Vermutungen zu meistern. Sie erhöhen die Auffindbarkeit, reduzieren Missverständnisse und befreien das Team von der Abhängigkeit von verborgenen Kenntnissen.

In modernen Datensystemen sind Metadaten nicht etwas, das nachträglich hinzugefügt wird, sondern etwas, das bereits bei der Entwurfsphase berücksichtigt wird. Metadaten geben Struktur ansonsten ungeordneten Tabellen und Dateien.

Ich sage das, weil ich es selbst erlebt habe. Als Data Scientist öffnete ich einmal eine Tabelle ohne Beschreibung, ohne Eigentümer und ohne dass ich die Hälfte der Spalten verstand. Ich habe wie viele andere geraten oder die Spalten, die ich nicht verstand, ignoriert. Manchmal hatte ich Glück, manchmal nicht.

Metadaten umfassen Datensatzbesitz, Felddefinitionen, Klassifizierungen, Beziehungen zwischen Objekten, Nutzungsmuster und Zugangskontexte. Das Erfassen all dieser Informationen ist nicht nur Dokumentation, sondern Entwurf.

Weil gute Metadaten nicht auf einer Wiki-Seite liegen bleiben; sie beeinflussen, wie Ihr System verstanden, genutzt und erweitert wird.

Von Namenskonventionen bis hin zum Besitzermodell, von Klassifizierungen bis hin zur Herkunft – all diese Entscheidungen beeinflussen die Architektur. Sie sind nicht nur beschreibend, sondern strukturell.

Entwurf mit Governance im Kopf bedeutet, dass Sie nicht nur fragen, „Wo sollte das hin?“

Sie fragen auch: „Wie werden die Menschen es in sechs Monaten, wenn ich nicht mehr da bin, finden, verstehen und, was noch wichtiger ist, vertrauen?“

Herkunft: Die Spuren, die Vertrauen aufbauen

Wenn Metadaten das Gedächtnis sind, dann ist die Herkunft die Geschichte!

Die Herkunft kann Ihnen sagen, wie ein Datensatz entstanden ist, welche Quellsysteme in ihn eingegeben haben, welche Transformationen angewendet wurden und welche Dashboards oder Modelle von ihm abhängen. Sie macht die unsichtbare Logik in einen sichtbaren Prozess!

Wenn etwas schief geht oder falsch aussieht, ist die Herkunft oft die einzige Möglichkeit, sicher zu debuggen.

Ich habe das in der Praxis erlebt. Die Zahlen auf einem Dashboard sehen verdächtig aus, und es gibt keine Herkunftsinformationen. Sie können nur Tabellen öffnen, Pipelines verfolgen und raten.

Aber mit der Herkunft? Sie folgen den Spuren. Sie sehen die Verknüpfung, die Nullwerte eingeführt hat. Sie bemerken das oberhalb liegende, stumm abgeschaffte Feld. Sie debuggen das „System“ und nicht nur das „Symptom“.

Aber die Herkunft ist nicht nur für Notfälle wichtig. Selbst wenn alles normal läuft, baut sie Vertrauen auf. Sie hilft Analysten, bessere Fragen zu stellen. Sie hilft neuen Teammitgliedern, sich schneller einzuarbeiten. Sie hilft Stakeholdern, den Zahlen zu vertrauen, die sie sehen.

Deshalb sollten alle Entwürfe die Herkunftsinformation berücksichtigen.

④ Qualitätssensibles Design

Datenqualität ist ein Schlagwort, das schwer zu bestreiten ist. Jeder spricht darüber, und jeder sagt, dass ihm es wichtig ist. Aber wenn es um reale Systeme geht, verhalten sich die Menschen oft reaktiv: Sie messen nachträglich, melden Probleme und hoffen, dass jemand weiter unten in der Kette diese Probleme beheben kann.

Es wird als technisches Problem gesehen: Testen, Validieren, Prüfen. Aber wenn Sie genauer hinschauen, wird klar, dass Qualität die praktische Umsetzung von Governance ist. Es geht darum, Erwartungen zu setzen und diese Erwartungen in die Systemstruktur zu integrieren