Eén bron van waarheid per attribuut

🌐 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 Stamgegevens en identiteit, hoofdstuk 6 van de cursus Data Architect. Elke module staat op zichzelf. Volgende: De vier manieren om stamgegevens te beheren

De vraag die deze module beantwoordt: Wat betekent “één bron van waarheid” echt?

Er is een zin die ik constant hoor: “We hebben één bron van waarheid nodig.” Oké. Waarvoor? De klant? Dat is niet specifiek genoeg. Neem een account. Wie is eigenaar van de naam van de klant, het factuuradres, de kredietlimiet, de accountmanager, het supportniveau, de marketingvoorkeuren? Die antwoorden wijzen niet naar hetzelfde systeem. Het ERP kan de juridische naam, het factuuradres en de kredietstatus controleren; Salesforce de relatie-eigenaar en de salesattributen; een ander platform de toestemming. Dus als iemand me vertelt “Salesforce is onze enige bron van waarheid voor de klant”, is mijn volgende vraag: welke waarheid?

Waarheid hoort bij een attribuut

Het eerste principe van stamgegevens is dit: zeggenschap wordt per attribuut toegewezen, niet per record. Een account kan in Salesforce staan zonder dat Salesforce gezaghebbend is voor elk veld erop. Zeven velden op één record, twee zeggenschappen:

Attribuut	Gezaghebbend systeem
Juridische naam, factuuradres, klant-ID van het ERP, kredietlimiet	ERP
Accountmanager, markering strategisch account, successniveau	Salesforce

Eén record; de waarheid is verdeeld. Dat is normaal. “Bronsysteem = Salesforce” beschrijft het niet. Een zeggenschapsmodel wel.

Aangemaakt, bewerkt, verwezen, en hoe snel?

Als ik stamgegevens doceer, kom ik voor elk belangrijk stuk data steeds terug bij dezelfde vragen: waar wordt het aangemaakt, waar wordt het bewerkt, waar wordt ernaar verwezen, en hoe snel verandert het? Ze leggen de architectuur snel bloot. (De eerste drie kwam je tegen in hoofdstuk 4, bij het indelen van de soorten data; hier doen ze hun echte werk.)

Neem een asset. Een klant bestelt drie fietsen. Salesforce heeft de verkoopkans en de regels ervan, en de order gaat naar het ERP. Het ERP voert hem uit, en daar worden de assets aangemaakt: drie fietsen, drie serienummers, teruggestuurd naar Salesforce. Maanden later belt de klant over een ervan, en support verwijst in een case naar de asset. Nu moet iemand een attribuut corrigeren. Welke mag Salesforce bewerken, en welke horen bij het ERP dat ze aanmaakte? En als het ERP er een wijzigt, hoe snel moet Salesforce dat weten? Eén asset, vier vragen, en de antwoorden zijn niet voor elk veld hetzelfde.

Stel dat de juridische naam in het ERP aangemaakt wordt en in Salesforce verwezen, en een verkoper merkt dat hij fout is. Moet hij het in Salesforce repareren? Als het ERP eigenaar is van het veld, repareert het wijzigen van de kopie niets. In het beste geval overschrijft de volgende synchronisatie het; in het slechtste geval zijn de twee systemen het nu oneens en weet niemand welke te vertrouwen. Als het bedrijf wil dat de verkoper de correctie start, is dat anders: Salesforce biedt de ervaring, stuurt een verzoek naar het ERP, het ERP voert de wijziging door of keurt haar goed, en de gezaghebbende waarde komt terug. Dat is een heel andere architectuur dan Salesforce het veld zelf laten bewerken.

Vertraging is ook deel van de waarheid. Het ERP wijzigt om 10.00 uur de kredietstatus van een klant; Salesforce synchroniseert ‘s nachts; om 15.00 uur kijkt een verkoper in Salesforce. Is de waarde fout? Ze is verouderd. Als de waarde één keer per jaar verandert en een dag vertraging niets kost, is ‘s nachts prima. Als ze bepaalt of je vandaag een order van een miljoen dollar accepteert, niet. Zeggenschap zegt waar de waarheid vandaan komt; vertraging zegt hoe snel anderen moeten horen dat ze veranderde. Twee aparte beslissingen.

Bronsysteem, engagementsysteem, referentiesysteem

De woorden uit hoofdstuk 4 helpen hier. Een bronsysteem houdt de gezaghebbende versie bij. Een engagementsysteem is waar mensen ermee werken. Een referentiesysteem levert data die een ander systeem gebruikt maar niet bezit. Salesforce kan het engagementsysteem zijn voor de klantrelatie terwijl het ERP het bronsysteem blijft voor de juridische en financiële attributen. Dat is geen zwakte in de architectuur; het is de architectuur. De fout is doen alsof één systeem eigenaar van alles moet zijn zodat het diagram er eenvoudiger uitziet.

Het hybride golden record

Dat verandert wat “golden record” betekent. Hoofdstuk 5 introduceerde het idee bij het buiten de deur houden van slechte data; hier is het de kern van het ontwerp. Mensen stellen zich één magisch record voor waarvan elk veld op één plek beheerd wordt. Soms is dat het ontwerp. In Salesforce zie ik vaker een hybride: een deel van het account wordt elders beheerd en binnengekopieerd (juridische naam, klantnummer van het ERP, factuuradres, kredietstatus), en een deel bestaat alleen omdat Salesforce het nodig heeft (accountmanager, verkoopkansstrategie, successniveau, relatienotities). De ERP-velden komen binnen zodat mensen ze kunnen gebruiken. De Salesforce-velden gaan nooit terug, omdat het ERP er niet om geeft. Volkomen redelijk, zolang iedereen weet welke welke is.

Maak zeggenschap zichtbaar

Dus maak ik externe zeggenschap duidelijk in het schema. Als SAP een veld controleert, krijgt het een prefix: sap_Customer_Number, sap_Credit_Status, sap_Legal_Name. Het is hetzelfde idee als de prefix erp_ uit hoofdstuk 4. Gebruik de naam van het systeem als die zeggenschap specifiek en stabiel is, en een generieke prefix als de betekenis meer doet dan de leverancier van vandaag. Het punt is dat iemand die het model zes maanden later leest kan zien: dit is niet zomaar nog een Salesforce-veld; een ander systeem is eigenaar van deze waarde. Laat mensen zeggenschap niet opnieuw ontdekken door integraties te ontleden.

Bouw een zeggenschapskaart

Voor belangrijke stamgegevens wil ik een zeggenschapskaart: voor elk belangrijk attribuut wie het aanmaakt, wie eigenaar is van de bedrijfsbeslissing, welk systeem gezaghebbend is, en wie of wat het mag wijzigen. Vier verschillende vragen:

Attribuut	Aangemaakt door	Bedrijfseigenaar	Gezaghebbend systeem	Mag het wijzigen
Juridische naam	Finance	Finance	ERP	Het financiële proces
Kredietlimiet	Finance	Finance	ERP	Het kredietteam
Accountmanager	Salesoperations	Sales	Salesforce	Salesmanagement
Supportniveau	Serviceoperations	Service	Salesforce	Servicemanagement
Toestemming	De klant	Privacy	Toestemmingsplatform	De klant, een goedgekeurd proces

Merk op dat bedrijfseigenaar en gezaghebbend systeem niet hetzelfde zijn. Een systeem is geen eigenaar van beleid; mensen wel. Het systeem slaat het resultaat op en dwingt het af. Dat is weer hoofdstuk 5: eigenaren bepalen het beleid; architecten dwingen het af.

Click to enlarge

Eén klant. Veel attributen. Eén zeggenschap voor elk.

Zeggenschap verandert over de levenscyclus

Een verkoper ontmoet een prospect waarvan het ERP nog nooit gehoord heeft en maakt het account aan in Salesforce. Op dat moment is Salesforce gezaghebbend voor de naam, het adres, de contactpersonen en de kwalificatie. De prospect wordt klant; het ERP maakt de officiële klant aan en kent het klantnummer, de juridische naam, het factuuradres en het krediet toe. De zeggenschap is verschoven. Salesforce had het eerst niet fout; de levenscyclus veranderde. Het is het patroon van voorlopig naar bestuurd uit hoofdstuk 5: vóór de omzetting is Salesforce eigenaar van de prospect; daarna is het ERP eigenaar van de bestuurde attributen, en blijft Salesforce eigenaar van zijn eigen. Dus “welk systeem is eigenaar van het account?” is een zwakke vraag. Vraag: welk systeem is eigenaar van dit attribuut, op dit punt in de levenscyclus?

Een kopie is geen zeggenschap

We kopiëren ERP-data naar Salesforce omdat mensen haar constant nodig hebben. Dat maakt Salesforce een handige lokale kopie, niet de master, en de architectuur moet zich daarnaar gedragen: alleen-lezen voor gebruikers, ververst door de integratie, gelabeld met de bron, alleen gewijzigd via een verzoek, gecontroleerd door reconciliatie als de kopie afdrijft. De kopie is nuttig. De zeggenschap is niet verschoven.

Vertrouwen vraagt meer dan een waarde

“Factuuradres: 123 Main Street.” Moet je het vertrouwen? Ik wil vertrouwenssignalen: waar het vandaan kwam, wanneer het voor het laatst bevestigd is, welk systeem het leverde, en wie of wat het het laatst wijzigde: een persoon, een integratie, een agent? Nu zegt het ERP 123 Main Street, Salesforce 125, en een partnerbestand “123 Main St., Suite 200.” Welke klopt? Antwoord niet “gebruik de meest recente.” Misschien. Maar “meest recent” is zelf een regel die aanneemt dat wie het het laatst wijzigde, verdient te winnen. Dat kan waar zijn, of vreselijk. Module 3 gaat hierop in. Vertrouwen komt uit zeggenschap en herkomst, niet uit het vinden van een veld dat ingevuld is.

Steve Trucking: wiens waarheid is het?

Een retailpartner stuurt een levering, en in die ene transactie verstoppen zich meerdere waarheden. De orderreferentie van de partner is van de partner; Steve Trucking bewaart haar om updates te matchen, maar wordt er niet de master van. De leveringsstatus (aangekomen, geleverd, geïnstalleerd, een uitzondering) is van Steve Trucking; de partner ontvangt haar, maar een status ontvangen maakt de partner niet gezaghebbend voor wat er op de vrachtwagen gebeurde. En de ontvanger is de klant van de partner. De partner levert de naam, het adres, de telefoon en de leveringsnotities omdat Steve Trucking ze nodig heeft om te leveren. Dat maakt Steve Trucking niet de master van de identiteit van die persoon, en dat onderscheid bepaalt het ontwerp van de ontvanger bij de checkpoint.

Click to enlarge

Eén levering, twee zeggenschappen.

Waar data staat en wie eigenaar is van haar waarheid zijn verschillende vragen. Salesforce kan het klantnummer van het ERP bewaren zonder er eigenaar van te zijn; Snowflake kan de leveringsstatus bewaren zonder er de operationele master van te zijn; een customer data platform kan identiteiten unificeren zonder eigenaar te zijn van elk attribuut. Een agent kan alle drie lezen, en dat laat de agent zeker niet beslissen welke waar is.

Voorbij het examen: wat AI verandert. Agents maken van zeggenschap per attribuut een uitvoeringsregel. Een mens ziet een fout factuuradres en weet “dat komt uit SAP; ik moet het hier niet wijzigen.” Een agent die opdracht krijgt “werk het factuuradres van de klant bij” weet dat niet, tenzij we ervoor ontwerpen. Hij heeft dezelfde zeggenschapskaart nodig als de architect: toegang tot een veld maakt dat veld nog niet de juiste plek om te schrijven.

Wat een architect hier beslist

• Welk systeem gezaghebbend is voor elk belangrijk attribuut, in plaats van één systeem voor een heel record.
• Waar elk attribuut aangemaakt, bewerkt en verwezen wordt, en hoe snel de wijzigingen moeten reizen.
• Wie het beleid voor elk attribuut bepaalt, en welke mensen, integraties of agents het mogen wijzigen.
• Hoe externe zeggenschap zichtbaar is in het model: naamprefixen, rechten, gedrag van integraties.
• Hoe zeggenschap verschuift over de levenscyclus, zoals een prospect die een door het ERP bestuurde klant wordt.

Eén bron van waarheid betekent niet één org, één ERP, één MDM-platform of één gigantisch record. Het betekent dat de architectuur voor elk stuk bestuurde informatie kan zeggen waar de gezaghebbende waarde staat, en dat elk ander systeem daardoor weet hoe het zich moet gedragen. Dat is niet één bron van waarheid. Het is een architectuur van waarheid.

Verder lezen

• Salesforce Architects, Data 360 Architecture (opens in a new tab) (Engels, gecontroleerd op 2026-10-14).