Koppelen is geen 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)
Hoofdstuk 6 van Data Architect, Deel 1: Data-architect worden. Vorige: Datakwaliteit en governance.
“We hebben één bron van waarheid nodig.” Het is een van de meest herhaalde zinnen in architectuur, en een van de minst onderzochte. Waarvoor? Neem één account. Het ERP kan eigenaar zijn van de juridische naam, het factuuradres en de kredietlimiet; Salesforce van de accountmanager en het supportniveau; een toestemmingsplatform van de marketingvoorkeuren. Drie zeggenschappen op één record, en dat is normaal. Dus als iemand zegt “Salesforce is onze enige bron van waarheid voor de klant”, is mijn volgende vraag altijd: welke waarheid?
Dit hoofdstuk gaat over die vraag bewust beantwoorden. Zeggenschap wordt attribuut voor attribuut toegewezen. Records koppelen is ze niet beheren. En Salesforce geeft je verschillende tools voor verschillende taken: duplicaatbeheer en samenvoegen binnen één org; identiteitsresolutie in Data 360 voor één beeld over bronnen heen; een apart MDM-platform als waarden één keer beslist en overal teruggezet moeten worden. Het eindigt met Checkpoint 1, waar Deel 1 samenkomt bij Steve Trucking.
Afbeelding gegenereerd met AI.
De standpunten in dit hoofdstuk
Section titled “De standpunten in dit hoofdstuk ”- Waarheid per attribuut. Vraag waar elk stuk data aangemaakt, bewerkt en verwezen wordt, en hoe snel het verandert. Laat externe zeggenschap in het schema zien met een systeemprefix, zoals
sap_oferp_. - Prospects zijn anders. Ze staan in Salesforce voordat het ERP ze kent; de zeggenschap van het ERP geldt na de omzetting.
- Registry is de norm in Salesforce-projecten, dan consolidatie en coëxistentie; puur gecentraliseerde MDM is zeldzaam.
- Voeg alleen samen met een duidelijke winnaar. Houd duplicaten uit externe loads als je misschien moet terugzoeken; samenvoegen vernietigt die historie. En beslis wat er met de onderliggende records gebeurt: verplaats ze, laad ze niet, of houd ze op een inactief record.
- Een geünificeerd profiel is een kaart; een golden record is een beslissing. Dit kan verwarrend zijn voor mensen: identiteitsresolutie maakt een geünificeerd individu, maar geen golden record.
- Hoe streng je matcht is een risicobeslissing. Waar vermengen duur is, match je bewust te weinig.
- Drie tools voor drie taken: samenvoegen, identiteitsresolutie, MDM.
- Hiërarchieën hebben gesplitste zeggenschap. Beslis de zeggenschap tak voor tak.
- “The hardest thing are the bi-directionals” (het moeilijkste zijn de tweerichtingsintegraties). Een integratie in twee richtingen maakt nog geen twee masters. Beslis vóór de eerste botsing welke velden samen als één transactie reizen.
- Maak stamgegevens zichtbaar. Een veld dat zegt dat dit stamgegevens zijn (de sleutel van het ERP of een vlag) stuurt de bewerkbaarheid, geen recordtype.
- We hebben de ERP’s niet in de hand. We bepalen hoe we ze in Salesforce weergeven: één klant in twee ERP’s is een hiërarchie, gelijken, of één account met een onderliggend record per ERP, afhankelijk van hoe goed de opdrachtgever zijn ERP’s synchroon houdt.
Drie tools voor drie taken
Section titled “Drie tools voor drie taken ”| De taak | De tool | Wat het met de bronnen doet |
|---|---|---|
| Duplicaten binnen één org, met een duidelijke winnaar | Duplicaatbeheer en samenvoegen | Voegt tot drie records samen; de andere gaan naar de prullenbak |
| Eén identiteit en één beeld over bronnen heen | Identiteitsresolutie in Data 360 | Koppelt ze; verandert er geen enkele (een registry) |
| Eén bestuurde waarde, teruggezet naar elk systeem | Een apart MDM-platform | Beslist de waarde en verspreidt haar (coëxistentie of gecentraliseerd) |
De route door dit hoofdstuk
Section titled “De route door dit hoofdstuk ”Zes modules en een opdracht, die elk op zichzelf staan.
- Eén bron van waarheid per attribuut. De zeggenschapskaart, het hybride golden record, en vertrouwenssignalen.
- De vier manieren om stamgegevens te beheren. Registry, consolidatie, coëxistentie en gecentraliseerd, en waarom een gemeenschappelijk model geen gemeenschappelijke waarheid is.
- Matchen, samenvoegen en survivorship. De prijs van een valse match, wat samenvoegen in Salesforce echt doet (en wat er met de onderliggende records gebeurt), en survivorship als uitspraak over vertrouwen.
- Een kaart is geen beslissing. Matchregels en matchmethoden, reconciliatieregels, en waarom een geünificeerd profiel geen golden record is.
- Als zeggenschap gedeeld is. Verzoeken tegenover updates, lussen en botsingen, hiërarchieën met gesplitste zeggenschap, en één klant in twee ERP’s.
- De opdracht van Checkpoint 1, daarna Checkpoint 1: Steve Trucking, hoe ik het zou ontwerpen. Probeer eerst de opdracht: teken en verdedig het ontwerp van Deel 1, vergelijk het dan met het mijne, en zie wat er verandert ten opzichte van het landschap uit hoofdstuk 4.
Als je klaar bent, test jezelf met de studiegids bij dit hoofdstuk: een checklist voor het examen, de gewoonten die verder gaan, de begrippen en een paar vragen. Ze sluit Deel 1 af; de studiegids bij Deel 1 brengt alle zes hoofdstukken samen.
Wat een architect hier beslist
Section titled “Wat een architect hier beslist ”- Welk systeem gezaghebbend is voor elk belangrijk attribuut, en hoe dat in het model zichtbaar is.
- Welke beheerstijl bij elk datadomein past, en hoeveel zeggenschap de beheerlaag krijgt.
- Wanneer je samenvoegt, wanneer je koppelt, en wie eigenaar is van elke survivorshipregel.
- Hoe streng matchen moet zijn, op basis van wat een valse match kost.
- Waar data in twee richtingen en gedeelde hiërarchieën expliciete grenzen nodig hebben.
Voorbij het examen: agents hebben één identiteit nodig om op te handelen, en dat verhoogt de inzet in beide richtingen. Te veel matchen wordt een privacy-incident, en een agent die “de klant bijwerkt” moet naar het bronsysteem van elk attribuut schrijven, niet naar het geünificeerde profiel. Elke module eindigt met wat AI verandert.
Verder lezen
Section titled “Verder lezen ”- Salesforce Architects, Data 360 Architecture (opens in a new tab) (Engels, gecontroleerd op 2026-10-14).
- Salesforce Help, Considerations for Merging Duplicate Accounts (opens in a new tab), Identity Resolution Match Methods (opens in a new tab) en Identity Resolution Reconciliation Rules (opens in a new tab) (Engels, gecontroleerd op 2026-10-14).
Volgende: Deel 2 begint met Ontwerpen voor schaal (coming soon).