Woordenboek, herkomst en classificatie

🌐 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 3 van 6 in het hoofdstuk Datakwaliteit en governance, hoofdstuk 5 van de cursus Data Architect. Elke module staat op zichzelf. Vorige: Slechte data buiten de deur houden · Volgende: Privacywetten bepalen het ontwerp

De vraag die deze module beantwoordt: Hoe leg je vast wat data betekent, waar ze vandaan komt en hoe gevoelig ze is?

Je hebt een org geërfd. Account heeft 900 velden, waaronder Customer_Type__c, Customer_Class__c, Customer_Category__c, Customer_Status__c, ERP_Status__c en Account_Status__c. Welke vertelt je of iemand echt klant is? Je opent de omschrijvingen. Drie zijn leeg. Eén zegt “Customer Type.” Dank je. Eén zegt dat het uit het ERP kwam; een ander is zes jaar geleden gemaakt door iemand die allang weg is. Stel je nu voor dat je niet de architect bent maar een integratie, een rapportageteam of een agent. De organisatie heeft data genoeg. Dat betekent niet dat ze weet wat de data betekent.

Daar wordt metadata architectuur, via drie vragen die verwant zijn maar niet hetzelfde:

• Woordenboek: wat betekent deze data?
• Herkomst (lineage): waar komt ze vandaan?
• Classificatie: hoe moet ze behandeld worden?

Twee soorten metadata

Metadata is er in twee soorten, en je hebt ze allebei nodig. Bedrijfsmetadata (business metadata) is wat de data voor het bedrijf betekent: de definitie, de eigenaar, de regels voor het gebruik, hoe gevoelig ze is. Technische metadata is hoe ze gebouwd is en beweegt: het object en het veld, het type en de lengte, de API-naam, het schema, de mapping van het ene systeem naar het andere, de herkomst van bron naar doel. De API-naam en het type van een veld vertellen een developer hoe hij het gebruikt; de definitie en de eigenaar vertellen iedereen anders of hij het gebruikt. Als die het oneens zijn, of als er een ontbreekt, gaan integraties en rapporten daar mis.

Examenkennis. Ken het verschil tussen bedrijfsmetadata (betekenis, definities, eigenaar, regels, gevoeligheid: het bedrijfswoordenboek en de classificatie) en technische metadata (objecten, velden, typen, API-namen, schema’s, mappings en herkomst).

Begin bij de betekenis

Hoofdstuk 3 stelde de regel: elk veld krijgt een omschrijving. Niet “Customer Status” voor een veld dat Customer Status heet, maar iets als “De huidige commerciële relatie van de partner met Steve Trucking. Gezet vanuit het ERP na activering. Niet gebruiken voor het kwalificeren van prospects.” Nu weet ik wat het betekent, waar het vandaan komt en waarvoor ik het niet moet gebruiken. Dat is het begin van een bedrijfswoordenboek: gemeenschappelijke definities voor de data die ertoe doet. Wat is een klant? Een actieve klant? Wat betekent Geleverd? Wat telt als op tijd? Dat klinkt vanzelfsprekend tot je vijf afdelingen in een ruimte zet: Finance heeft één definitie, Sales een andere, Operations een derde, het datawarehouse een vierde, en iemand heeft een dashboard op een vijfde gebouwd. Het probleem is niet dat niemand dezelfde taal spreekt. Het is dat de enterprise het niet eens is over de betekenis.

Een woordenboek kan in een spreadsheet of een documentatietool staan, maar de belangrijke definities moeten dicht bij de plek staan waar mensen de data gebruiken. Op het platform zijn dat veldomschrijvingen, helptekst en de classificatiemetadata. In analytics doet het er nog meer toe: “omzet” mag niet het ene betekenen op het dashboard van het management en het andere in de query van een analist. Daar is een semantische laag voor, en de semantische modellen van Data 360 bevatten bestuurde definities zoals metrieken, dimensies en relaties boven de fysieke data (Create a Semantic Model in Data 360 (opens in a new tab)). De technologie verandert; de eis niet: belangrijke data heeft een afgesproken betekenis nodig.

En begin bij de betekenis, niet bij de technologie. Een woordenboek dat begint met object, veld, type en API-naam documenteert de implementatie. Een woordenboek dat begint met bedrijfsbegrippen documenteert de enterprise:

Bedrijfsbegrip	Betekenis	Waar het weergegeven wordt
Retailpartner	Een retailer waarvoor Steve Trucking levert, onder contract	Salesforce-account; klant in het financiële ERP
Levering	Eén levering aan één ontvanger, op één adres, op één dag	Vandaag RouteDesk; een werkorder zodra leveringen naar Salesforce verhuizen
Ontvanger	De persoon die een levering ontvangt	Ontvangergegevens op de levering
Geleverd	Afgerond volgens de afgesproken operationele definitie	Leveringsstatus
Levering op tijd	Afgerond binnen het afgesproken leveringsvenster	Afgeleide metriek

Click to enlarge

Eén betekenis, veel technische weergaven.

Vraag dan waar het vandaan komt

Zodra ik weet wat een waarde betekent, wil ik weten waar ze vandaan komt. Dat is herkomst. De juridische naam van een partner in Salesforce: heeft een verkoper hem getypt, heeft het ERP hem gestuurd, heeft een integratie hem getransformeerd, heeft Data 360 hem geünificeerd, is hij berekend, heeft AI hem gegenereerd? Dat beïnvloedt hoeveel ik hem vertrouw en wat ik ermee mag doen. Denk aan de voorlopige records uit module 2: twee accounts kunnen allebei “Keystone” zeggen, de een gisteren door een verkoper aangemaakt, de ander uit het ERP met een gezaghebbende identificator. Dezelfde tekst, een andere herkomst, een andere behandeling.

Herkomst is niet alleen het diagram van duizend tabellen van een data engineer. Voor belangrijke data wil ik praktische vragen beantwoorden: waar is ze begonnen, welk systeem is gezaghebbend, wat heeft haar getransformeerd, welke systemen kregen kopieën, wat heeft haar het laatst gewijzigd, en kan ik een afgeleide waarde terugvoeren naar haar bronnen? Het landschap uit hoofdstuk 4 zegt dat de systemen verbonden zijn. Herkomst zegt wat er onderweg met de data gebeurde.

Sommige herkomst krijg je gratis: de ERP-ID op het account, Created By en Last Modified By, integratielogs, mappingdocumenten. Data 360 voegt herkomstvelden toe aan zijn dataobjecten die voor elk record de databron en het bronobject vastleggen (Data Lineage Fields (opens in a new tab)). Maar ga er niet van uit dat herkomst verschijnt omdat systemen geïntegreerd zijn. Soms is de nuttigste herkomst één veld: Bronsysteem = Keystone. En als de bron ertoe doet voor governance, maak haar dan mechanisch betrouwbaar, gezet door de integratie, niet getypt door een mens.

Afgeleide data heeft herkomst het hardst nodig. Stel dat Steve Trucking een risico op late levering berekent uit de positie van de vrachtwagen, het leveringsvenster en de routehistorie, en dat de planning het gebruikt om prioriteiten te stellen. Waar kwam “hoog” vandaan? Voeg een agent toe die een ontvanger vertelt “je levering loopt vertraging op”, en je moet weten waarop dat gebaseerd was, en hoe vers het was. Hoe verder je gaat van opgeslagen waarden naar berekende, geünificeerde, voorspelde en gegenereerde, hoe meer herkomst ertoe doet.

Classificatie beantwoordt een andere vraag

Nu: hoe moet ze behandeld worden? Naam van de ontvanger, leveringsadres, telefoonnummer, leveringsnotities, leveringsstatus, vrachtwagennummer, distributiecentrum, retailpartner, foto: ze zijn niet even gevoelig. “Onderweg” is geen telefoonnummer, en een DC-code is geen foto van de binnenkant van iemands huis. Salesforce laat je dit op elk veld vastleggen, standaard of aangepast: Data Owner, Field Usage, Data Sensitivity Level en Compliance Categorization (Data Classification Metadata Fields (opens in a new tab)). Hoofdstuk 3 noemde ze de taxonomievelden, en legde uit waarom ze ertoe doen: markeer een veld als PII of GDPR en processen kunnen het vinden, van maskeringstools tot de AI-trustlaag van Salesforce, die gemarkeerde waarden uit de buurt van een large language model kan houden. Eén waarschuwing uit hoofdstuk 3: Salesforce schakelt die LLM-maskering nu uit voor agents, omdat ze de context kan weghalen die een agent nodig heeft (Classificeer wat ertoe doet: de taxonomievelden). Classificatie moet dus nog steeds de andere controles sturen.

Mijn standpunt hier is bewust: classificeer de gevoelige velden, niet elk veld. Ik wil niet dat er drie maanden besteed worden aan het classificeren van duizenden velden zodat iemand “100% geclassificeerd” kan rapporteren en niemand het gebruikt. Het telefoonnummer van de ontvanger: ja. Huisadres: ja. Leveringsnotities die toegangscodes en “hond in de tuin” kunnen bevatten: ja. Foto’s die mensen of een huis kunnen laten zien: absoluut. Een intern weergavelabel? Daar hoort de governance-energie niet heen te gaan. Dat maakt ongedocumenteerde velden niet acceptabel. Twee verschillende taken: documentatie is breed; classificatie is bewust. Dat houdt classificatie betekenisvol.

Een taxonomie die mensen kunnen gebruiken

Classificatie heeft een woordenlijst nodig, een taxonomie. De standaardwaarden van Salesforce zijn Public, Internal, Confidential, Restricted en MissionCritical; je organisatie wil misschien eigen labels. Ik schrijf ze niet voor. Houd ze begrijpelijk: als er 47 categorieën zijn en niemand buiten het privacyteam categorie 31 van 32 kan onderscheiden, helpt het niet. Een goede taxonomie verbindt een label aan gedrag. Als een veld gevoelige persoonsgegevens bevat: wie mag het zien, mag het naar een sandbox, de regio verlaten, in analytics verschijnen, hoe lang wordt het bewaard, mag een agent het gebruiken? Nu doet classificatie werk.

Classificatie zonder handhaving is versiering

Markeer het telefoonnummer van de ontvanger als gevoelig en verander verder niets, en je hebt documentatie geschreven. Nuttig, maar governance gaat verder: classificatie hoort rechten, maskering, versleuteling, bewaren, toestemming, dataverkeer, sandboxgebruik, audit en AI-toegang te sturen. Een deel daarvan is een ontwerpbeslissing van de architect; sommige platformen passen tags en classificaties nu rechtstreeks in beleid toe, zoals de governance van Data 360 doet (Data Governance in Data 360 (opens in a new tab)). En een veld als Restricted markeren houdt niemand tegen om het te lezen. Classificatie zegt hoe een veld behandeld moet worden; beveiliging maakt het zo. De volgorde is: identificeer de data, begrijp haar, classificeer wat ertoe doet, en pas dan de controles toe die die classificatie vraagt.

Click to enlarge

Drie vragen over je data, en de derde moet iets sturen.

Referentiegegevens hebben ook metadata nodig

Landcodes, leveringsstatussen, DC-codes, partneridentificatoren, annuleringsredenen: ze lijken eenvoudig tot twee systemen het oneens zijn. De een zegt CANCELLED, een ander CANCELED, een derde CNCL, een vierde 9. Referentiegegevens hebben definities nodig, een eigenaar, een bron, een levenscyclus waar waarden veranderen, en mappings als systemen ze verschillend weergeven. Kleine waarden kunnen heel grote processen sturen. Hoofdstuk 6 gaat verder.

Alle drie samen

Neem het telefoonnummer van de ontvanger. Woordenboek: het nummer waarmee de persoon die een specifieke levering ontvangt bereikt wordt. Herkomst: uit de vrachtlijst van de retailpartner. Classificatie: persoonsgegeven. Nu worden de architectuurvragen mogelijk: mag de ploeg het zien, en hoe lang (de briefing zegt alleen voor hun eigen stops, alleen op die dag); mag het naar een sandbox; heeft Snowflake het nodig; mag een agent het gebruiken; wat gebeurt er als de levering klaar is?

Neem nu de leveringsstatus. Woordenboek: de huidige operationele toestand van de levering. Herkomst: gezet door het leveringsproces van Steve Trucking en via een eigen integratie teruggestuurd naar elke partner. Classificatie: operationeel, niet gevoelig. Andere data, andere behandeling. Daar gaat het om.

Ik behandel metadata niet als documentatie die gemaakt wordt nadat de echte architectuur klaar is. Als ik niet kan zeggen wat een veld betekent, begrijp ik het datamodel niet. Als ik niet weet waar een waarde vandaan kwam, begrijp ik de integraties niet. Als ik niet weet of ze gevoelig is, begrijp ik de beveiliging niet. Metadata beschrijft de architectuur, en stuurt haar soms.

Voorbij het examen: wat AI verandert. Classificatie wordt de schakelaar voor wat een agent mag ophalen of herhalen, en herkomst moet helemaal reiken tot het antwoord of de actie van de agent. Als een agent een ontvanger vertelt dat de levering te laat is, moet de architectuur kunnen zeggen waarop dat gebaseerd was, waar het vandaan kwam, en of de agent het mocht gebruiken. “Ergens in Salesforce” is geen herkomst, en “klantdata” is geen classificatie.

Wat een architect hier beslist

• Welke bedrijfsbegrippen bestuurde definities nodig hebben, zodat systemen en teams één woord geen verschillende betekenissen geven.
• Hoe belangrijke waarden genoeg herkomst houden om hun bron, zeggenschap en transformaties te laten zien.
• Welke velden een gevoeligheids- of compliancebetekenis dragen en dus een expliciete classificatie krijgen.
• Welke taxonomie de organisatie gebruikt, en of mensen haar consequent kunnen toepassen.
• Hoe classificatie echte controles stuurt in plaats van ongebruikt te blijven.

Voordat je data bestuurt, moet je weten wat je hebt: wat het betekent, waar het vandaan komt, hoe het behandeld moet worden. Documenteer breed, classificeer bewust, houd herkomst bij waar het ertoe doet. Anders bestuur je de data niet. Dan heb je haar gewoon.

Verder lezen

• Salesforce Help, Data Classification Metadata Fields (opens in a new tab) (Engels, gecontroleerd op 2026-10-14).
• Salesforce Help, Data 360: Data Lineage Fields (opens in a new tab), Data Governance in Data 360 (opens in a new tab) en Create a Semantic Model in Data 360 (opens in a new tab) (Engels, gecontroleerd op 2026-10-14).