Governance wordt in de org ontworpen

🌐 Ook beschikbaar in 28 talen

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Afbeelding gegenereerd met AI

Vertaald door AI. Nog niet door de community nagekeken. Lees in het Engels

Module 1 van 6 in het hoofdstuk Datakwaliteit en governance, hoofdstuk 5 van de cursus Data Architect. Elke module staat op zichzelf. Volgende: Slechte data buiten de deur houden

De vraag die deze module beantwoordt: Wat betekent datagovernance voor een architect, en wie doet wat?

Als mensen datagovernance horen, denken ze aan vergaderingen: commissies, beleid, standaarden, een document dat uitlegt wie wat met de data hoort te doen. Dat kan allemaal deel zijn van een governanceprogramma. Als architect ben ik geïnteresseerd in een andere vraag: waar wordt het beleid afgedwongen?

Als het beleid zegt dat alleen Finance een veld mag wijzigen, wat dwingt dat af? Als het zegt dat het ERP eigenaar is van het juridische klantrecord, wat houdt iemand in Salesforce tegen om het te wijzigen? Als het zegt dat ploegen het adres van een ontvanger alleen zien voor hun eigen stops, alleen op die dag, wat maakt dat dan echt waar? Als het zegt dit zeven jaar te bewaren, wat archiveert of verwijdert het na zeven jaar? Beleid zonder handhavingspunt is vooral een wens. Governance wordt architectuur als die beslissingen in het systeem ingebouwd worden.

Governance is nooit af

Laat me dit vroeg uit de weg ruimen: governance krijg je nooit af. Ik heb het met eb en vloed zien gaan. Een bedrijf besteedt echte aandacht aan datakwaliteit, en het wordt beter. De aandacht gaat ergens anders heen, en de kwaliteit zakt weg. Er komt een nieuwe integratie bij, een bedrijfsonderdeel verandert zijn proces, iemand importeert een bestand, het bedrijf neemt een ander over, een agent begint records te schrijven, en het probleem verandert weer. Het doel is geen mythische toestand waarin elk record voor altijd perfect is. Het is de data betrouwbaar genoeg houden voor het bedrijf en het ergste van de slechte data buiten houden. Dat is doorlopend werk.

Als Salesforce grotendeels op zichzelf staat, betekent governance data op één plek opschonen. Als het één knooppunt is in het landschap uit hoofdstuk 4, wordt het moeilijker, en noodzakelijker. Nu staat de klant in Salesforce, het ERP, het datawarehouse, partnersystemen, Data 360. Wie is eigenaar? Wie mag hem wijzigen? Welke kopie is gezaghebbend, welke attributen mogen bewegen, hoe lang worden ze bewaard, en wie staat ervoor in als ze fout zijn? Dat zijn geen configuratievragen. Het zijn governancevragen die configuratie worden.

Recordeigenaar is geen data-eigenaar

Begin bij het woord eigenaar, want Salesforce maakt het verwarrend. Open een account en je ziet een Owner: een verkoper, bijvoorbeeld. Is de verkoper eigenaar van de klantdata? Niet per se. In Salesforce is een record op een object met een eigenaar het eigendom van een gebruiker of een wachtrij; de eigenaar krijgt volledige toegang, en de eigenaar stuurt toewijzing en sharing via de rolhiërarchie en deelregels (Sharing and Record Access Features (opens in a new tab)). Dat is recordeigenaarschap: een platformmechanisme.

De data-eigenaar is iets anders: de persoon of functie die verantwoordelijk is voor de data als bedrijfsmiddel. Finance kan eigenaar zijn van de juridische klantinformatie, Operations van de leveringsstatus, HR van de medewerkersdata. Salesforce geeft je zelfs een plek om dat vast te leggen: het classificatieveld Data Owner op elk veld (Data Classification Metadata Fields (opens in a new tab)).

Bij Steve Trucking kan het account van een retailpartner eigendom zijn van de salesmanager die die partner beheert. Maar de juridische identiteit van de partner wordt bestuurd door Finance en beheerd in het financiële ERP. Sales, service, operations en het partnerportaal hebben het account allemaal nodig; niets daarvan betekent dat de salesmanager de juridische identiteit van de partner mag wijzigen zodra Finance die vastgesteld heeft. Ik heb teams naar het veld Owner zien kijken en aannemen dat ze data-eigenaarschap opgelost hadden. Dat hadden ze niet. Recordtoewijzing is geen bedrijfsverantwoordelijkheid.

Eigenaar, steward, beheerder

Drie governancerollen, drie verschillende taken.

De data-eigenaar bepaalt het beleid. Die beantwoordt wat de data betekent, wie haar mag aanmaken en wijzigen, hoe nauwkeurig ze moet zijn, hoe lang ze bewaard wordt, wie haar mag zien, welk systeem gezaghebbend is, en wat er gebeurt als ze fout is. De architect hoort die antwoorden niet te verzinnen. Dat is een van mijn stelligste standpunten: eigenaren bepalen het beleid; architecten dwingen het af. Als Finance zegt dat de juridische naam alleen via het ERP-proces mag veranderen zodra de klant actief is, is dat een governancebeslissing. Het mechanisch waar maken is mijn taak.

De data steward houdt het werkend. De steward staat dicht bij de dagelijkse gezondheid van de data: kwaliteitssignalen in de gaten houden, duplicaten onderzoeken, uitzonderingen oplossen, reparaties coördineren, definities bijhouden, het proces opsporen dat steeds slechte data oplevert. Nog twee taken liggen bij de steward. Als twee teams het oneens zijn over wat een veld betekent, wie er eigenaar van is of wie het mag zien, legt de steward het geschil voor aan de eigenaar en ziet erop toe dat de beslissing uitgevoerd wordt. En de steward bouwt datageletterdheid (data literacy) op: hij helpt de mensen die de data invoeren en gebruiken begrijpen wat ze betekent en waarom de regels bestaan. Een steward heeft meer nodig dan een naam in een organogram. Hij heeft tijd nodig, zicht, een proces, en de bevoegdheid om problemen opgelost te krijgen. Anders wordt “data steward” de achtste verantwoordelijkheid van iemand, één keer per kwartaal bekeken.

De beheerder (custodian) draait het systeem. Admins, platformteams, securityteams: wie de technologie bedient die de data opslaat en verwerkt. De eigenaar zegt dat alleen deze rollen haar mogen zien; de beheerder bedient de controles die dat waarmaken. De namen doen er minder toe dan elke verantwoordelijkheid duidelijk maken, en in een kleine organisatie kan één persoon twee petten dragen.

Hoe het programma draait

Governanceprogramma’s hebben meestal een van drie vormen. Gecentraliseerd: één team schrijft het beleid en de standaarden voor elk domein. Het is consistent, en het kan een bottleneck worden, ver van de mensen die het werk doen. Gefedereerd (gedecentraliseerd): elk domein, zoals finance, sales of operations, bestuurt zijn eigen data binnen een paar gedeelde regels. Het staat dicht bij het werk, en definities groeien tussen domeinen uit elkaar. Hybride: een klein centraal team is eigenaar van de standaarden en de gedeelde definities, en de domeineigenaren en stewards runnen hun eigen data. De meeste enterprises die ik gezien heb, komen ergens in de hybride vorm uit. Voor de architect beantwoordt de vorm één praktische vraag: wie keurt een beleid goed voordat ik het afdwing, en waar staan de gedeelde definities?

Examenkennis. Ken de drie manieren om een governanceprogramma te runnen, gecentraliseerd, gefedereerd (gedecentraliseerd) en hybride, en wat elk betekent voor wie het beleid bepaalt en waar de gedeelde definities staan.

Laat de RACI zijn plek verdienen

Een RACI (wie is Responsible, Accountable, Consulted en Informed) helpt, maar niet als een gigantische spreadsheet die gemaakt wordt omdat governance “er een vereist”. Ik wil dat hij architectuurvragen beantwoordt, te beginnen met de drie uit hoofdstuk 4 (De vier vragen achter de categorieën): waar wordt de data aangemaakt, waar wordt ze bewerkt, en waar wordt ernaar verwezen? Dat zijn vaak verschillende systemen. Neem een product: het ERP maakt het aan, Salesforce verwijst ernaar, het portaal toont het, het datawarehouse analyseert het. Nu verandert het bedrijf wat “actief product” betekent. Waar begint de wijziging, wie keurt haar goed, hoe verspreidt ze zich, en welke kopieën zijn alleen-lezen? Als je dat niet kunt beantwoorden, heb je nog geen governance. Je hebt kopieën. Een goede RACI legt precies die onduidelijkheid bloot.

Governance moet mechanisch worden

Het bedrijf zegt dat alleen Finance de juridische klantnaam mag wijzigen. Ik wil niet dat het architectuurantwoord “dat nemen we mee in de training” is. Training helpt; het is geen handhaving. Misschien is het toegang op veldniveau, een validatieregel, een veld dat alleen de integratie schrijft, of een gecontroleerd proces in plaats van directe bewerkingen. Het mechanisme hangt af van de eis, maar er moet er een zijn:

Governancebeleid	Eigenaar beslist	Mogelijk handhavingspunt
Het ERP is eigenaar van de juridische klantidentiteit	Finance	Velden alleen voor de integratie, rechten, validatie
Alleen mensen die het nodig hebben zien persoonsgegevens	Privacy, security	Sharing, rechten, veldtoegang
Klantidentificatoren zijn uniek	Bedrijfseigenaar	Unieke externe ID, duplicaatregels
Beheerde records worden niet met de hand aangemaakt	Data-eigenaar	Rechten, automatisering, integratie
Gevoelige data heeft een vaste bewaartermijn	Privacy, juridisch	Een bewaar- of verwijderproces
Belangrijke wijzigingen moeten aantoonbaar zijn	Compliance	Veldhistorie, audit trail
De bron van data blijft herkenbaar	Data-eigenaar	Een bronveld, herkomstmetadata

Ik zeg bewust mogelijk handhavingspunt. Dit is geen tabel om functies uit te kiezen. Het is de volgorde van denken: wat is het beleid, wie is er eigenaar van, en wat in de architectuur maakt het waar?

Click to enlarge

Eigenaren bepalen het beleid; architecten dwingen het af.

Vertrouw niet op goed gedrag

“Wijzig nooit de klant-ID van het ERP.” Iedereen weet het, tot iemand het toch doet: per ongeluk, via een dataload, via automatisering, via een integratie, via een agent. Als het wijzigen ervan enterprisedata zou beschadigen, is “doe het alsjeblieft niet” niet de controle. Bouw de controle. Vertrouwen is goed, controle is beter. Mensen, integraties, automatisering en AI maken allemaal fouten, dus de architectuur moet ervan uitgaan dat er uiteindelijk iets zal proberen wat het beleid verbiedt. Wat gebeurt er dan?

Governance steekt systeemgrenzen over

Terug naar het landschap. Het ERP is eigenaar van de klant; Salesforce, het datawarehouse en een customer data platform hebben kopieën; een partner krijgt er een deel van. Op welk systeem is het beleid van toepassing? Op allemaal. Salesforce kan een wijziging van de juridische naam terecht blokkeren terwijl een integratie een downstream systeem haar laat overschrijven. Salesforce kan persoonsgegevens verwijderen die het datawarehouse nog bewaart. Een veld dat in Salesforce als gevoelig geclassificeerd is, kan elders in een niet-geclassificeerd tekstveld belanden. Governance kan niet stoppen bij de rand van de org, omdat de data dat ook niet doet. Daarom kwam hoofdstuk 4 eerst: het landschap vertelt je hoe ver governance moet reiken.

Bestuur genoeg, niet alles

De omgekeerde fout is net zo echt. We ontdekken dat governance ertoe doet, dus we sluiten alles af: niemand kan aanmaken, elke wijziging vraagt goedkeuring. De data is bestuurd, en niemand kan zijn werk doen. Governance betekent de passende controle voor de data: streng voor sommige, licht voor andere. Sommige records mogen vrij aangemaakt worden, sommige vragen goedkeuring; sommige velden kan bijna iedereen bewerken, sommige alleen de integratie. De volgende module wordt daar praktisch over.

En omdat governance nooit af is, heeft handhaving terugkoppeling nodig. Nemen duplicaten toe? Lopen verplichte velden vol met rommel? Falen integraties, vinden gebruikers omwegen, groeien uitzonderingen, besteden stewards de hele dag aan één probleem? Die signalen vertellen je of het ontwerp werkt, en soms dat de controle, of het beleid, moet veranderen.

Voorbij het examen: wat AI verandert. Governance heeft een nieuwe afnemer: de agent. De data-eigenaar beslist nog steeds wat gebruikt mag worden en waarvoor; de architect maakt het nog steeds afdwingbaar. Wat verandert is snelheid en schaal. Een agent leest, combineert en handelt op bestuurde data veel sneller dan een mens, dus beleid dat alleen in een document bestaat, beschermt nog minder.

Wat een architect hier beslist

• Wie verantwoordelijk is voor elk belangrijk datadomein, en hoe dat verschilt van recordeigenaarschap.
• Wie de data als steward verzorgt en wie haar als beheerder bedient.
• Waar belangrijke data aangemaakt, bewerkt, verwezen en beheerd wordt in het landschap.
• Welk handhavingspunt elk belangrijk beleid mechanisch waar maakt.
• Hoe de architectuur laat zien of governance werkt, of begint weg te zakken.

Als ik een governance-eis hoor, vertaal ik haar. “Het ERP is hier eigenaar van.” “Alleen deze mensen mogen dit zien.” “We moeten kunnen bewijzen wie dit wijzigde.” “Bewaar dit zeven jaar.” Elke keer: laat me het handhavingspunt zien. De architect beslist het beleid niet. We ontwerpen het systeem dat het afdwingt. Daar houdt governance op een document te zijn en wordt het architectuur.

Verder lezen

• Salesforce Help, Sharing and Record Access Features (opens in a new tab) (Engels, gecontroleerd op 2026-10-14).
• Salesforce Help, Data Classification Metadata Fields (opens in a new tab) (Engels, gecontroleerd op 2026-10-14).