De vier manieren om stamgegevens te beheren
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)
Module 2 van 6 in het hoofdstuk Stamgegevens en identiteit, hoofdstuk 6 van de cursus Data Architect. Elke module staat op zichzelf. Vorige: Eén bron van waarheid per attribuut · Volgende: Matchen, samenvoegen en survivorship
De vraag die deze module beantwoordt: Hoe beheren organisaties stamgegevens, en welke stijl past?
Module 1 zei dat zeggenschap attribuut voor attribuut toegewezen wordt. Nu: wat doen we als die attributen tegelijk in meerdere systemen staan? Klantinformatie in Salesforce, het ERP, facturatie, support, misschien Data 360, misschien een datawarehouse, elk met een eigen versie. Dat is het probleem dat master data management (MDM) probeert op te lossen, en MDM is niet één architectuur. Je hoort vier patronen: registry, consolidatie, coëxistentie en gecentraliseerd. Het zijn geen productinstellingen. Het zijn vier antwoorden op één vraag: hoeveel zeggenschap heeft de beheerlaag?
Begin bij het probleem, niet bij het product
Section titled “Begin bij het probleem, niet bij het product ”Mensen horen MDM en gaan op zoek naar een MDM-product. Ik zou bij het probleem beginnen. Moeten we alleen weten dat meerdere records dezelfde klant zijn? Hebben we één gecombineerd beeld nodig voor analytics? Moeten we beslissen welke waarden gezaghebbend zijn en ze terugzetten naar andere systemen? Of willen we één centraal systeem dat de stamgegevens voor iedereen aanmaakt? Heel verschillende eisen, heel verschillende architecturen.
Registry: vertel me wie wie is
Section titled “Registry: vertel me wie wie is ”Het lichtste patroon. Een registry vervangt de bronnen niet. Het ERP houdt zijn klant, Salesforce zijn account, facturatie zijn klant, en de registry zoekt uit dat deze records dezelfde entiteit vertegenwoordigen: Salesforce-account 001…, ERP-klant SAP-43821 en facturatieklant BILL-9127 horen bij één klant. De bronnen blijven waar ze zijn en worden niet overschreven. Nu heeft “laat me alles zien wat we over deze klant weten” een antwoord.
Maar let op wat een registry niet beantwoordt. Salesforce zegt 123 Main Street, het ERP 125, facturatie “123 Main St., Suite 200.” De registry weet dat ze bij elkaar horen. Hij beslist niet welke moet veranderen. Koppelen is geen beheren.
In mijn ervaring is registry de norm in Salesforce-projecten, dan consolidatie en coëxistentie; puur gecentraliseerde MDM is zeldzaam. Registry is gewoon omdat het niet ingrijpend is. Je hoeft niet elk operationeel systeem te herontwerpen voordat je waarde krijgt. Salesforce blijft doen wat het doet, het ERP blijft doen wat het doet, en je voegt een identiteitslaag toe. Dat is een veel kleinere verandering dan elk systeem vertellen “jij controleert de klantdata niet meer; dit nieuwe centrale systeem wel.”
Een registry beantwoordt: welke records horen bij dezelfde entiteit?
Consolidatie: breng de data samen
Section titled “Consolidatie: breng de data samen ”Consolidatie haalt data uit meerdere bronnen en combineert die in een centrale weergave, voor rapportage, analytics, segmentatie, klantinzicht. Een datawarehouse is het bekende voorbeeld: Salesforce stuurt de klant, het ERP de financiën, facturatie de betalingen, en het bedrijf kan de klant eindelijk over systemen heen analyseren. De bronnen bestaan nog en kunnen nog steeds gezaghebbend zijn. De richting doet ertoe: data stroomt naar het geconsolideerde systeem, dat meestal geen beheerde wijzigingen terugzet. Een beter beeld van de klant, zonder er de operationele zeggenschap over te worden.
Registry en consolidatie zijn makkelijk te verwarren. Het verschil is wat er gecentraliseerd wordt: registry centraliseert identiteit (“deze horen bij elkaar”); consolidatie centraliseert meer van de data (“breng de attributen samen zodat we ze kunnen gebruiken”). Geen van beide zegt “dit centrale systeem is nu de master en elke applicatie moet zijn waarden accepteren.”
Consolidatie brengt de data samen zonder het eigenaarschap bij de bronnen weg te halen.
Coëxistentie: beslis, en stuur het terug
Section titled “Coëxistentie: beslis, en stuur het terug ”Bij coëxistentie krijgt de beheerlaag echte zeggenschap. Data staat nog steeds in meerdere operationele systemen, maar het MDM-proces beslist de beheerde waarde en publiceert die terug. Salesforce, het ERP en facturatie hebben elk een andere juridische naam; het MDM-proces bepaalt de bestuurde naam en verspreidt die naar alle drie. De systemen bestaan naast elkaar, maar ze komen uit bij de beheerde waarde.
Dat is een veel sterkere vorm van MDM. Het zegt niet “deze horen bij elkaar”; het zegt “voor dit attribuut is dit de waarde die de enterprise gebruikt.” Dat vraagt meer dan matchen: bedrijfsregels, eigenaarschap, survivorship, integratie in twee richtingen, foutafhandeling en governance, want iemand moet beslissen waarom één waarde wint.
Coëxistentie koppelt de records niet alleen. Ze beslist over beheerde waarden en stuurt ze terug.
Gecentraliseerd: de master maakt de waarheid
Section titled “Gecentraliseerd: de master maakt de waarheid ”Het sterkste patroon. Bij gecentraliseerde MDM worden de bestuurde stamgegevens aangemaakt en bijgehouden in de centrale master en naar alle anderen verspreid. In plaats van dat elk systeem zijn eigen klant aanmaakt en MDM ze achteraf verzoent, maak je de bestuurde klant aan in de master, en stuur je hem dan naar Salesforce, het ERP en facturatie. Heel sterke governance, en een heel grote verandering: bestaande processen maken hun eigen klanten aan, gebruikers hebben hun werkwijzen, integraties gaan uit van lokaal aanmaken, en bedrijfsonderdelen zijn het misschien niet eens over wat een klant is. Daarom is het zeldzaam in de Salesforce-landschappen die ik zie. Het kan juist zijn. Het is een veel grotere beslissing dan een tool installeren.
Gecentraliseerde MDM verplaatst het aanmaken en de zeggenschap naar de master.
De vier naast elkaar
Section titled “De vier naast elkaar ”| Stijl | Wat er gecentraliseerd wordt | Blijven de bronnen? | Zet bestuurde waarden terug? |
|---|---|---|---|
| Registry | Identiteit en koppelingen | Ja | Meestal niet |
| Consolidatie | Identiteit plus gecombineerde data | Ja | Meestal niet |
| Coëxistentie | Identiteit, data en beheerbeslissingen | Ja | Ja |
| Gecentraliseerd | Aanmaken en zeggenschap | Ja, als afnemers | Ja |
Hoe verder in de tabel, hoe meer zeggenschap de beheerlaag krijgt, en hoe meer de organisatie meestal moet veranderen.
Examenkennis. Ken de vier MDM-implementatiestijlen: registry (koppelt identiteiten; de bronnen houden hun data), consolidatie (brengt de data samen, meestal voor analyse), coëxistentie (beslist over beheerde waarden en publiceert ze terug naar de bronnen) en gecentraliseerd (de master maakt de data aan; de bronnen gebruiken ze).
Dus er is geen “gecentraliseerd is het volwassenst, dus iedereen moet daar komen.” Kies het lichtste patroon dat het probleem oplost. Moet je weten dat records bij elkaar horen? Denk aan registry. Een gecombineerd beeld voor analytics? Consolidatie. Bestuurde waarden die teruggesynchroniseerd worden naar meerdere operationele systemen? Coëxistentie. Eén proces dat stamgegevens voor iedereen aanmaakt en controleert? Gecentraliseerd.
Waar past Data 360?
Section titled “Waar past Data 360? ”Data 360 bouwt geünificeerde profielen over veel bronnen heen, wat veel op MDM lijkt, en het lost ook een deel van het probleem op. De identiteitsresolutie matcht bronprofielen tot een geünificeerde identiteit en houdt de koppelingen naar de bronrecords bij (Data 360 Architecture (opens in a new tab)). Dat maakt het het dichtst bij een registry. Het kan ook verzoende waarden tonen op het geünificeerde profiel. Maar dat maakt het geen gecentraliseerd golden-recordsysteem dat de bronnen herschrijft. Een geünificeerd beeld is niet automatisch een beheerd enterpriserecord. Module 4 gaat helemaal over dat verschil.
Een gemeenschappelijk model is geen gemeenschappelijke waarheid
Section titled “Een gemeenschappelijk model is geen gemeenschappelijke waarheid ”Je hoort ook canoniek datamodel. Het account van Salesforce, de business partner van het ERP en de klant van facturatie sluiten allemaal aan op één afgesproken enterpriseconcept, Klant, met afgesproken identificatoren en attributen, zodat niet elke integratie de vorm van elk ander systeem hoeft te begrijpen. Het datamodel van Data 360 is een voorbeeld van bronnen harmoniseren tot gemeenschappelijke concepten. Maar een canoniek model beantwoordt hoe geven we dit consistent weer? MDM beantwoordt hoe identificeren, besturen en beheren we het over systemen heen? Breng alle drie de systemen perfect onder in één vorm Klant, en Salesforce zegt nog steeds 123 Main Street terwijl het ERP 125 zegt. Je hebt de structuur opgelost, niet de zeggenschap. Harmoniseren en beheren zijn niet uitwisselbaar.
Eén bedrijf, meerdere patronen
Section titled “Eén bedrijf, meerdere patronen ”Dus “Steve Trucking heeft MDM nodig” is geen eis. Waarvoor? Retailpartners, distributiecentra, ploegen, vrachtwagens, ontvangers zijn verschillende domeinen met verschillende zeggenschappen: retailpartners bestuurd in Salesforce en het financiële ERP, de identiteit van vrachtwagens uit FleetLink, elke ontvanger geleverd door een partner voor elke levering. Verschillende domeinen kunnen verschillende patronen krijgen, en binnen een domein kunnen attributen verschillende zeggenschappen hebben. Teken dus geen vakje met het label MDM in het midden van het diagram om het dan opgelost te noemen. Vraag wat het vakje doet.
De stijl verandert ook de integratie. Registry heeft identiteitskoppelingen nodig; consolidatie betrouwbare inkomende stromen; coëxistentie data in twee richtingen; gecentraliseerd verspreiding vanuit de master plus controles die voorkomen dat andere systemen een rivaliserende waarheid aanmaken. Als de zeggenschap groeit, groeit de coördinatie mee, en ook de foutafhandeling: wat als MDM de juridische naam wijzigt en het ERP die weigert? Daarom zijn coëxistentie en gecentraliseerd geen “registry met meer functies”. Ze brengen andere operationele verantwoordelijkheden mee.
MDM is een bedrijfsbeslissing
Section titled “MDM is een bedrijfsbeslissing ”Het belangrijkste punt: MDM is in de kern geen technologiebeslissing. Het is een beslissing over zeggenschap. Wie maakt de klant aan, wie mag hem wijzigen, wie beslist welke waarde wint, welke systemen moeten die accepteren, wat gebeurt er als ze het oneens zijn. Een tool kan die beslissingen implementeren; hij kan de organisatie het er niet over eens laten worden. Daarom kan een MDM-project uitstekende technologie hebben en toch mislukken: het technische team loste het matchen op, en de business loste het eigenaarschap nooit op.
De algemene les die ik op de harde manier geleerd heb: als meerdere systemen dezelfde data beheren, kan Salesforce niet verzoenen waarover zij het niet eens zijn. Als een bedrijf twee ERP’s draait, vraag ik hoe ze die synchroon houden. Als zij dat niet kunnen, kan Salesforce het ook niet. Module 5 vertelt dat verhaal (Eén klant, twee ERP’s).
Wat een architect hier beslist
Section titled “Wat een architect hier beslist ”- Of het probleem identiteitskoppelingen, gecombineerde data, teruggezette beheerde waarden of centraal aanmaken vraagt.
- Welk patroon bij elk datadomein past, in plaats van één patroon voor de hele enterprise.
- Hoeveel zeggenschap de beheerlaag krijgt, en welke systemen haar beslissingen moeten accepteren.
- Of er een canoniek model nodig is, zonder harmonisatie te verwarren met zeggenschap.
- Hoe het gekozen patroon de richting van integratie, eigenaarschap en foutafhandeling verandert.
Als iemand een vakje MDM op een diagram zet, vraag dan wat het doet. Weet het welke records bij elkaar horen? Combineert het hun data? Beslist het welke waarden winnen? Zet het die beslissingen terug? Maakt het de data überhaupt aan? De antwoorden vertellen je welke architectuur je echt hebt, en waar de zeggenschap ligt.
Verder lezen
Section titled “Verder lezen ”- Salesforce Architects, Data 360 Architecture (opens in a new tab) (Engels, gecontroleerd op 2026-10-14).