Governance wird in die Org hineinentworfen
Auch in 28 Sprachen
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada)
Modul 1 von 6 im Kapitel Datenqualität und Governance, Kapitel 5 des Kurses Data Architect. Jedes Modul steht für sich. Weiter: Schlechte Daten fernhalten
Die Frage, die dieses Modul beantwortet: Was bedeutet Daten-Governance für die Architektur, und wer tut was?
Wenn Menschen Daten-Governance hören, denken sie an Besprechungen: Gremien, Richtlinien, Standards, ein Dokument, das erklärt, wer was mit den Daten tun soll. All das kann Teil eines Governance-Programms sein. In der Architektur interessiert mich eine andere Frage: Wo wird die Richtlinie durchgesetzt?
Wenn die Richtlinie sagt, nur die Finanzabteilung darf ein Feld ändern, was setzt das durch? Wenn sie sagt, dem ERP gehört der rechtliche Kundendatensatz, was hält jemanden in Salesforce davon ab, ihn zu ändern? Wenn sie sagt, Crews sehen die Adresse eines Empfängers nur für ihre eigenen Stopps, nur am Tag selbst, was macht das tatsächlich wahr? Wenn sie sagt, bewahre dies sieben Jahre auf, was archiviert oder entfernt es nach sieben? Eine Richtlinie ohne Durchsetzungspunkt ist meist ein Wunsch. Governance wird zur Architektur, wenn diese Entscheidungen in das System eingebaut sind.
Governance ist nie fertig
Abschnitt betitelt „Governance ist nie fertig “Klären wir das gleich am Anfang: Mit Governance wird man nicht fertig. Ich habe sie in Ebbe und Flut verlaufen sehen. Ein Unternehmen richtet echte Aufmerksamkeit auf die Datenqualität, und es wird besser. Die Aufmerksamkeit wandert woandershin, und die Qualität rutscht ab. Eine neue Integration geht live, ein Geschäftsbereich ändert seinen Prozess, jemand importiert eine Datei, das Unternehmen kauft ein anderes, ein Agent beginnt, Datensätze zu schreiben, und das Problem verändert sich wieder. Das Ziel ist kein mythischer Zustand, in dem jeder Datensatz für immer perfekt ist. Es ist, die Daten für das Geschäft vertrauenswürdig genug zu halten und das Schlimmste der schlechten Daten fernzuhalten. Das ist fortlaufende Arbeit.
Wenn Salesforce weitgehend allein steht, heisst Governance, Daten an einem Ort zu bereinigen. Wenn es ein Knoten in der Landschaft aus Kapitel 4 ist, wird sie schwerer und nötiger. Jetzt lebt der Kunde in Salesforce, im ERP, im Data Warehouse, in Partnersystemen, in Data 360. Wem gehört er? Wer darf ihn ändern? Welche Kopie ist massgeblich, welche Attribute dürfen sich bewegen, wie lange werden sie aufbewahrt, und wer steht ein, wenn sie falsch sind? Das sind keine Konfigurationsfragen. Es sind Governance-Fragen, die zu Konfiguration werden.
Datensatzeigentümer ist nicht gleich Dateneigentümer:in
Abschnitt betitelt „Datensatzeigentümer ist nicht gleich Dateneigentümer:in “Beginnen Sie mit dem Wort Eigentümer, denn Salesforce macht es verwirrend. Öffnen Sie einen Account, und Sie sehen einen Eigentümer: zum Beispiel jemanden aus dem Vertrieb. Gehören dieser Person die Kundendaten? Nicht unbedingt. Auf Salesforce gehört ein Datensatz eines Objekts mit Eigentümer einem Benutzer oder einer Warteschlange; der Eigentümer bekommt vollen Zugriff und steuert Zuweisung und Freigabe über die Rollenhierarchie und Freigaberegeln (Sharing and Record Access Features (opens in a new tab), auf Englisch). Das ist Datensatzeigentümerschaft: ein Mechanismus der Plattform.
Die Dateneigentümerschaft ist etwas anderes: die Person oder Funktion, die für die Daten als Geschäftswert verantwortlich ist. Der Finanzabteilung gehören vielleicht die rechtlichen Kundeninformationen, dem Betrieb der Lieferstatus, der Personalabteilung die Personaldaten. Salesforce gibt Ihnen sogar einen Ort, das festzuhalten: das Klassifizierungsfeld Data Owner an jedem Feld (Data Classification Metadata Fields (opens in a new tab), auf Englisch).
Bei Steve Trucking gehört der Account eines Handelspartners vielleicht der Vertriebsleiterin, die diesen Partner betreut. Aber die rechtliche Identität des Partners wird von der Finanzabteilung gesteuert und im Finanz-ERP als Stammdatum geführt. Vertrieb, Service, Betrieb und das Partnerportal brauchen alle den Account; nichts davon heisst, dass die Vertriebsleiterin die rechtliche Identität des Partners ändern sollte, sobald die Finanzabteilung sie festgelegt hat. Ich habe Teams auf das Feld Eigentümer schauen und annehmen sehen, sie hätten die Dateneigentümerschaft gelöst. Haben sie nicht. Datensatzzuweisung ist keine geschäftliche Verantwortung.
Eigentümer:in, Steward, Verwaltende
Abschnitt betitelt „Eigentümer:in, Steward, Verwaltende “Drei Governance-Rollen, drei verschiedene Aufgaben.
Die Dateneigentümer:innen legen die Richtlinie fest. Sie beantworten, was die Daten bedeuten, wer sie anlegen und ändern darf, wie genau sie sein müssen, wie lange sie aufbewahrt werden, wer sie sehen darf, welches System massgeblich ist und was passiert, wenn sie falsch sind. Die Architektur sollte diese Antworten nicht erfinden. Das ist eine meiner festesten Positionen: Eigentümer:innen legen die Richtlinie fest; Architekt:innen setzen sie durch. Wenn die Finanzabteilung sagt, der rechtliche Name darf sich nur über den ERP-Prozess ändern, sobald der Kunde aktiv ist, ist das eine Governance-Entscheidung. Sie mechanisch wahr zu machen, ist meine Aufgabe.
Der Data Steward hält sie am Laufen. Der Steward ist nah an der täglichen Gesundheit der Daten: beobachtet Qualitätssignale, untersucht Duplikate, löst Ausnahmen, koordiniert Korrekturen, pflegt Definitionen, entdeckt den Prozess, der immer wieder schlechte Daten erzeugt. Zwei weitere Aufgaben liegen beim Steward. Wenn zwei Teams uneinig sind, was ein Feld bedeutet, wem es gehört oder wer es sehen darf, bringt der Steward den Streit vor die Dateneigentümer:innen und sorgt dafür, dass die Entscheidung umgesetzt wird. Und der Steward baut Datenkompetenz auf: Er hilft den Menschen, die die Daten erfassen und nutzen, zu verstehen, was sie bedeuten und warum es die Regeln gibt. Ein Steward braucht mehr als einen Namen im Organigramm. Er braucht Zeit, Sichtbarkeit, einen Prozess und die Befugnis, Probleme beheben zu lassen. Sonst wird «Data Steward» zur achten Verantwortung von jemandem, die einmal im Quartal angeschaut wird.
Die Verwaltenden (Custodians) betreiben das System. Administration, Plattformteams, Sicherheitsteams: wer auch immer die Technologie betreibt, die die Daten speichert und verarbeitet. Die Eigentümer:innen sagen, nur diese Rollen dürfen sie sehen; die Verwaltenden betreiben die Kontrollen, die das sicherstellen. Die Namen zählen weniger, als jede Verantwortung klar zu machen, und in einer kleinen Organisation trägt eine Person vielleicht zwei Hüte.
Wie das Programm läuft
Abschnitt betitelt „Wie das Programm läuft “Governance-Programme gibt es meist in drei Formen. Zentralisiert: Ein Team schreibt die Richtlinien und Standards für jede Domäne. Das ist einheitlich, kann aber zum Engpass werden, weit weg von den Menschen, die die Arbeit machen. Föderiert (dezentral): Jede Domäne, etwa Finanzen, Vertrieb oder Betrieb, regelt ihre eigenen Daten innerhalb weniger gemeinsamer Regeln. Das ist nah an der Arbeit, und die Definitionen driften zwischen den Domänen auseinander. Hybrid: Ein kleines zentrales Team verantwortet die Standards und die gemeinsamen Definitionen, und die Dateneigentümer:innen und Data Stewards der Domänen führen ihre eigenen Daten. Die meisten Unternehmen, die ich gesehen habe, landen irgendwo im Hybriden. Für Architekt:innen beantwortet die Form eine praktische Frage: Wer gibt eine Richtlinie frei, bevor ich sie durchsetze, und wo liegen die gemeinsamen Definitionen?
Prüfungswissen. Kennen Sie die drei Arten, ein Governance-Programm zu führen, zentralisiert, föderiert (dezentral) und hybrid, und was jede davon dafür bedeutet, wer Richtlinien festlegt und wo die gemeinsamen Definitionen liegen.
Die RACI muss sich ihren Platz verdienen
Abschnitt betitelt „Die RACI muss sich ihren Platz verdienen “Eine RACI (wer ist Responsible, Accountable, Consulted und Informed) hilft, aber keine riesige Tabelle, die erstellt wird, weil Governance «eine verlangt». Ich will, dass sie Architekturfragen beantwortet, beginnend mit den drei aus Kapitel 4 (Die vier Fragen hinter den Kategorien): Wo werden die Daten angelegt, wo werden sie bearbeitet, und wo werden sie referenziert? Das sind oft verschiedene Systeme. Nehmen Sie ein Produkt: Das ERP legt es an, Salesforce referenziert es, das Portal zeigt es, das Data Warehouse analysiert es. Jetzt ändert das Geschäft, was «aktives Produkt» bedeutet. Wo beginnt die Änderung, wer genehmigt sie, wie verbreitet sie sich, und welche Kopien sind schreibgeschützt? Wenn Sie das nicht beantworten können, haben Sie noch keine Governance. Sie haben Kopien. Eine gute RACI legt genau diese Unklarheit offen.
Governance muss mechanisch werden
Abschnitt betitelt „Governance muss mechanisch werden “Das Geschäft sagt, nur die Finanzabteilung darf den rechtlichen Kundennamen ändern. Ich will nicht, dass die Architekturantwort lautet «Das decken wir in der Schulung ab». Schulung hilft; sie ist keine Durchsetzung. Vielleicht ist es Zugriff auf Feldebene, eine Validierungsregel, ein Feld, das nur die Integration schreibt, oder ein kontrollierter Prozess statt direkter Bearbeitungen. Der Mechanismus hängt von der Anforderung ab, aber es muss einen geben:
| Governance-Richtlinie | Entscheidender Eigentümer | Möglicher Durchsetzungspunkt |
|---|---|---|
| Dem ERP gehört die rechtliche Kundenidentität | Finanzen | Felder nur für die Integration, Berechtigungen, Validierung |
| Nur wer es braucht, sieht personenbezogene Daten | Datenschutz, Sicherheit | Freigabe, Berechtigungen, Feldzugriff |
| Kundenkennungen sind eindeutig | Geschäftlicher Eigentümer | Eindeutige externe ID, Duplikatsregeln |
| Gesteuerte Datensätze werden nicht von Hand angelegt | Dateneigentümer:innen | Berechtigungen, Automatisierung, Integration |
| Sensible Daten haben eine festgelegte Aufbewahrungsfrist | Datenschutz, Recht | Ein Aufbewahrungs- oder Löschprozess |
| Wichtige Änderungen müssen nachweisbar sein | Compliance | Feldverlauf, Prüfpfad |
| Die Quelle der Daten bleibt erkennbar | Dateneigentümer:innen | Ein Quellfeld, Metadaten zur Datenherkunft |
Ich sage absichtlich möglicher Durchsetzungspunkt. Das ist keine Tabelle zum Auswählen von Funktionen. Es ist die Reihenfolge des Denkens: Was ist die Richtlinie, wem gehört sie, und was in der Architektur macht sie wahr?
Eigentümer:innen legen die Richtlinie fest; Architekt:innen setzen sie durch.
Verlassen Sie sich nicht auf gutes Benehmen
Abschnitt betitelt „Verlassen Sie sich nicht auf gutes Benehmen “«Ändere nie die ERP-Kunden-ID.» Alle wissen es, bis es jemand tut: aus Versehen, durch einen Datenladevorgang, durch Automatisierung, durch eine Integration, durch einen Agenten. Wenn eine Änderung die Unternehmensdaten beschädigen würde, ist «bitte nicht» nicht die Kontrolle. Bauen Sie die Kontrolle. Vertrauen, aber überprüfen. Menschen, Integrationen, Automatisierung und KI machen alle Fehler, also sollte die Architektur annehmen, dass irgendwann etwas versucht, was die Richtlinie verbietet. Was passiert dann?
Governance überschreitet Systemgrenzen
Abschnitt betitelt „Governance überschreitet Systemgrenzen “Zurück zur Landschaft. Dem ERP gehört der Kunde; Salesforce, das Data Warehouse und eine Kundendatenplattform halten Kopien; ein Partner bekommt einen Teil davon. Für welches System gilt die Richtlinie? Für alle. Salesforce blockiert vielleicht korrekt eine Änderung des rechtlichen Namens, während eine Integration ein nachgelagertes System ihn überschreiben lässt. Salesforce löscht vielleicht personenbezogene Daten, die das Data Warehouse noch hält. Ein Feld, das in Salesforce als sensibel klassifiziert ist, landet vielleicht anderswo in einem unklassifizierten Textfeld. Governance kann nicht am Rand der Org aufhören, denn die Daten tun es auch nicht. Deshalb kam Kapitel 4 zuerst: Die Landschaft sagt Ihnen, wie weit die Governance reichen muss.
Steuern Sie genug, nicht alles
Abschnitt betitelt „Steuern Sie genug, nicht alles “Das umgekehrte Scheitern ist genauso real. Wir entdecken, dass Governance zählt, also sperren wir alles: Niemand darf anlegen, jede Änderung braucht eine Genehmigung. Die Daten sind gesteuert, und niemand kann seine Arbeit machen. Governance heisst die angemessene Kontrolle für die Daten: streng für manche, leicht für andere. Manche Datensätze können frei angelegt werden, manche brauchen eine Genehmigung; manche Felder kann fast jeder bearbeiten, manche nur die Integration. Das nächste Modul wird genau dazu praktisch.
Und weil Governance nie fertig ist, braucht die Durchsetzung Rückmeldung. Nehmen Duplikate zu? Füllen sich Pflichtfelder mit Unsinn? Scheitern Integrationen, finden Benutzer Umwege, wachsen die Ausnahmen, verbringen Stewards den ganzen Tag mit einem Problem? Diese Signale sagen Ihnen, ob der Entwurf funktioniert, und manchmal, dass die Kontrolle, oder die Richtlinie, sich ändern muss.
Über die Prüfung hinaus: Was KI ändert. Die Governance hat einen neuen Abnehmer: den Agenten. Die Dateneigentümer:innen entscheiden weiterhin, was wofür genutzt werden darf; die Architektur macht es weiterhin durchsetzbar. Was sich ändert, sind Geschwindigkeit und Umfang. Ein Agent liest, kombiniert und handelt auf gesteuerten Daten weit schneller als ein Mensch, also schützt eine Richtlinie, die nur in einem Dokument existiert, noch weniger.
Was Architekt:innen hier entscheiden
Abschnitt betitelt „Was Architekt:innen hier entscheiden “- Wer für jeden wichtigen Datenbereich verantwortlich ist und wie sich das von der Datensatzeigentümerschaft unterscheidet.
- Wer die Daten als Steward betreut und wer sie als Verwaltende betreiben.
- Wo wichtige Daten in der Landschaft angelegt, bearbeitet, referenziert und als Stammdaten geführt werden.
- Welcher Durchsetzungspunkt jede wichtige Richtlinie mechanisch wahr macht.
- Wie die Architektur zeigt, ob die Governance funktioniert oder abzurutschen beginnt.
Wenn ich eine Governance-Anforderung höre, übersetze ich sie. «Das gehört dem ERP.» «Nur diese Menschen dürfen das sehen.» «Wir müssen nachweisen, wer das geändert hat.» «Bewahre das sieben Jahre auf.» Jedes Mal: Zeigen Sie mir den Durchsetzungspunkt. Die Architektur entscheidet nicht über die Richtlinie. Wir entwerfen das System, das sie durchsetzt. Dort hört Governance auf, ein Dokument zu sein, und wird Architektur.
Weiterlesen
Abschnitt betitelt „Weiterlesen “- Salesforce-Hilfe, Sharing and Record Access Features (opens in a new tab) (auf Englisch), geprüft am 2026-10-14.
- Salesforce-Hilfe, Data Classification Metadata Fields (opens in a new tab) (auf Englisch), geprüft am 2026-10-14.