Het datamodel is het skelet
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 7 in het hoofdstuk Denken als een data-architect, het eerste hoofdstuk van de cursus Data Architect. Elke module staat op zichzelf. Vorige: Denken als een architect · Volgende: De omkeerbaarheidstest
De vraag die deze module beantwoordt: Waarom is het datamodel belangrijker dan alles wat erop gebouwd wordt, en hoe beoordeel je er een?
Als ik data-architectuur lesgeef, is er één zin waar ik steeds weer op terugkom: het datamodel is het skelet.
Het datamodel is het skelet van het systeem. Al het andere wordt eromheen gebouwd, en het houdt de rest van het lichaam bij elkaar. Je ziet het skelet niet als je naar iemand kijkt, maar het bepaalt hoe lang die persoon is, hoe die beweegt en wat die kan dragen.
Denk aan alles wat we in een Salesforce-implementatie bouwen. We bouwen automatisering rond het datamodel. We schrijven Apex ertegen, en Flows die het lezen en bijwerken. We bouwen integraties die data erin sturen en eruit halen. We maken rapporten en analyses erop, en we ontwerpen beveiliging eromheen. En steeds vaker bouwen we AI-agents die die data moeten begrijpen en ernaar moeten handelen. Alles hangt af van de structuur eronder.
Daarom is het zo belangrijk om het datamodel vroeg goed te krijgen. Je kunt het skelet later veranderen. Maar dat gaat waarschijnlijk pijn doen.
Begin bij de business
Section titled “Begin bij de business ”Een goed datamodel begint met een simpele vraag: wat moet de business eigenlijk vastleggen? Niet “welke Salesforce-objecten hebben we?” En zeker niet “wat kan ik snel bouwen?”
We proberen eerst de business te begrijpen. Wat zijn de belangrijke dingen in dit bedrijf? Hoe hangen ze samen? Wie is er eigenaar van? Hoe veranderen ze in de loop van de tijd? Wat moet onthouden worden, en wat wordt over bedrijfsprocessen heen gedeeld? Pas als we dat begrijpen, moeten we het gaan vertalen naar objecten, velden en relaties.
Dit klinkt vanzelfsprekend. In de praktijk doe je het heel makkelijk andersom. Iemand herkent iets dat op een verkoopkans, een case of een asset lijkt en begint er meteen omheen te ontwerpen. Soms is dat precies goed. Soms proberen we een vierkante pen in een rond gat te slaan, en zodra er genoeg rond die beslissing gebouwd is, wordt het heel duur om de pen er weer uit te krijgen.
Hier is een vraag die ik constant hoor. Het bedrijf van een klant kan veel afleverlocaties hebben. Moet elke locatie een account zijn, of een aangepast object? Voordat je antwoordt: kijk wat je eerst zou moeten weten, namelijk wat een locatie voor dit bedrijf betekent en wat ermee gebeurt. Dat is de business modelleren vóór de objecten. (Mijn antwoord geef ik in hoofdstuk 3.)
Ondersteunen. Groeien. Presteren.
Section titled “Ondersteunen. Groeien. Presteren. ”Als ik naar een datamodel kijk, wil ik dat het drie tests doorstaat: de business ondersteunen, meegroeien met de business, en presteren.
Ondersteunen. Het model moet ondersteunen wat de business echt probeert te bereiken. Er is een groot verschil tussen een model dat de data technisch kan opslaan en een model dat de business echt goed weergeeft. Als ik constant vreemde velden, speciale vlaggen, ingewikkelde automatisering en uitzonderingen toevoeg omdat het model niet helemaal past, ga ik me afvragen of het probleem echt de automatisering is. Misschien is het model verkeerd. Een goed model zou de business makkelijker te begrijpen moeten maken, niet moeilijker.
Groeien. Als ik groeien zeg, bedoel ik niet alleen meer records. Volume is belangrijk: tienduizend records en honderd miljoen geven heel andere problemen. Maar bedrijven groeien ook in complexiteit. Ze voegen producten toe, betreden nieuwe markten, nemen bedrijven over, veranderen processen, voegen kanalen toe en koppelen nieuwe systemen. Ze ontdekken dat iets wat ze voor één ding hielden eigenlijk vijf verschillende dingen is. Een model dat vandaag prachtig werkt, kan een valkuil worden als er geen ruimte is voor morgen. Daarom heb ik liever ontwerpen die groeien door toevoeging dan ontwerpen die steeds veranderen wat er al is. Iets nieuws toevoegen is meestal makkelijker dan iets herdefiniëren waar tientallen andere dingen van afhangen.
Presteren. Data ligt niet alleen maar stil. We schrijven het, zoeken het, bevragen het, delen het, rapporteren erover en integreren het, en steeds vaker halen AI-systemen het op als context voordat ze handelen. Een model kan er op een diagram prachtig uitzien en toch vreselijk zijn in gebruik. Dus ontwerpen we voor allebei: hoe de data wordt opgeslagen en hoe de data gebruikt gaat worden.
En het moet blijven presteren. Het moet presteren op schaal: als het aantal gebruikers stijgt, als het datavolume stijgt, onder echte omstandigheden en op de pieken, op de drukste dag van het jaar in plaats van een gemiddelde dag. En het moet blijven presteren als er iets onverwachts gebeurt.
Ondersteunen. Groeien. Presteren. Op die drie tests komen we in deze hele cursus steeds terug.
Te plat, te ingewikkeld of gewoon verkeerd
Section titled “Te plat, te ingewikkeld of gewoon verkeerd ”Ik heb datamodellen op drie manieren mis zien gaan.
De eerste is vanaf het begin het verkeerde ding kiezen. We gebruiken een standaardobject omdat het er dicht genoeg bij lijkt, en besteden daarna jaren aan het toevoegen van uitzonderingen omdat het nooit goed paste. Dat is de vierkante pen.
De tweede is het model te plat maken. Alles gaat in één object, en eerst lijkt dat heerlijk eenvoudig. Dan groeit de business, en ontdekken we dat sommige van die dingen hun eigen levenscyclus hebben, meerdere keren kunnen voorkomen, hun eigen beveiliging nodig hebben of eigen relaties hebben. Ineens leggen we een een-op-veel-relatie vast met Veld 1, Veld 2 en Veld 3, of met steeds ingewikkelder vlaggen en automatisering. Het model liet ons nergens ruimte om te groeien.
De derde is de omgekeerde fout: we normaliseren te ver door. We maken een elegant diagram met object na object, elk concept perfect gescheiden. Technisch prachtig, in de praktijk ellendig. Gebruikers snappen het nauwelijks, en de page layouts en Lightning-pagina’s, met related list na related list, voelen eindeloos diep. Query’s worden ingewikkelder, automatisering loopt over meer relaties, rapportage wordt moeilijker, en het platform moet meer werk doen om gewone bedrijfsvragen te beantwoorden.
Dus wat is juist, plat of genormaliseerd? Er is geen formule. Je hebt een beeld van het optimale model in je hoofd en begrijpt de afwegingen als je ervan afwijkt. Dat is de kunst van architectuur, en we komen erop terug in module 4 en in het volgende hoofdstuk, waar we leren modelleren. Voor nu: zie in dat de structuur zelf een architectuurbeslissing is.
Wees voorzichtig met het veranderen van het skelet
Section titled “Wees voorzichtig met het veranderen van het skelet ”Zodra een systeem draait, word ik heel voorzichtig met fundamentele wijzigingen aan het datamodel.
Stel dat een tekstveld al jaren bestaat, en iemand zegt: “We gebruiken het eigenlijk niet meer zo. Laten we er een getal van maken.” Het klinkt als een veldwijziging. Maar wat hangt er van dat veld af? Flows, Apex, rapporten, integraties, datapijplijnen, externe applicaties, AI-agents. En wat gebeurt er met de historische data? Het platform laat je het type van een veld niet eens veranderen zolang code of flows ernaar verwijzen, en dat zegt iets over hoe ver de wijziging reikt.
Soms is het juiste antwoord niet om te veranderen wat er al is. Afhankelijk van hoe ingrijpend de wijziging is, maak ik liever iets nieuws, migreer ik bewust en faseer ik de oude structuur uit:
Voeg toe in plaats van te wijzigen. Faseer uit in plaats van te verrassen.
Salesforce geeft je zelfs een manier om dat in de metadata te zeggen: de Field Usage van een veld kan op DeprecateCandidate worden gezet, “gepland voor uitfasering en niet meer in gebruik”. Dat markeert het veld voor iedereen die het object leest; het verbergt het veld niet, dus het uitfaseren blijft een beslissing die je zelf uitvoert.
Want zodra andere delen van de architectuur ergens van afhangen, kan het veranderen van de betekenis veel gevaarlijker zijn dan het veranderen van de naam. De ergste variant is het veld waarvan de naam hetzelfde blijft terwijl de inhoud verandert: alles stroomafwaarts vertrouwt de naam nog steeds.
Zelfs iets simpels als het vakje Verplicht aanvinken bij een veld kan een tijdbom worden. Als je al data hebt verzameld, zullen sommige records dat veld niet gevuld hebben. Dagen, weken of maanden later werkt iemand een van die records bij, en het opslaan mislukt vanwege het verplichte veld, terwijl niemand die waarde heeft. Een simpele wijziging als een veld verplicht maken kan onbedoelde en uitgestelde gevolgen hebben. We komen terug op Verplicht, en op wanneer een waarde eigenlijk bekend is, in hoofdstuk 3.
Voorbij het examen: AI bouwt ook op het skelet. Vraag een AI-tool om een applicatie te bouwen en het genereert binnen een paar minuten de objecten, velden, Flows, Apex, componenten en tests. Als het oorspronkelijke datamodel verkeerd was, hebben we de gevolgen van een slechte beslissing niet vermeden; we hebben ze versneld, omdat elke gegenereerde laag weer iets is dat van die structuur afhangt. Daarom wil ik dat een menselijke architect een door AI gegenereerd datamodel beoordeelt, begrijpt en er verantwoordelijk voor is. Module 7 gaat hier verder op in.
Het skelet komt eerst
Section titled “Het skelet komt eerst ”In deze cursus gaan we het over veel technologie hebben: objecten en relaties, grote datavolumes, query’s, integratie, migratie, transacties, beveiliging, Data 360 en AI. Onder dat alles ligt het datamodel.
Als het model de business ondersteunt, met de business kan meegroeien en presteert voor de manieren waarop we de data gaan gebruiken, hebben we een sterk fundament gebouwd. Als we het fundament verkeerd hebben, wordt alles daarna moeilijker.
Het datamodel is het skelet. Architecten moeten heel voorzichtig zijn bij het ontwerpen van het skelet. Wijzigingen aan bestaande structuren kunnen een kettingreactie van gevolgen hebben.
Wat een architect hier beslist
Section titled “Wat een architect hier beslist ”- Of het model de business ondersteunt, ermee kan meegroeien en presteert voor de manieren waarop de data gebruikt gaat worden.
- Of een concept bij een standaardobject past of een vierkante pen is.
- Hoe plat of hoe genormaliseerd het model wordt, en waarom.
- Of een wijziging aan het skelet een toevoeging, een migratie of een uitfasering moet zijn, in plaats van een wijziging ter plekke.
Verder lezen
Section titled “Verder lezen ”- Considerations for Converting the Field Type of a Custom Field (opens in a new tab), Salesforce Help (Engels, gecontroleerd op 2026-10-02; opnieuw gecontroleerd op 2026-10-12): welke typewijzigingen data kunnen kosten, en waarom je het type niet kunt veranderen van een veld waar Apex, flows of processen naar verwijzen.
- Data Classification Metadata Fields (opens in a new tab), Salesforce Help (Engels, gecontroleerd op 2026-10-02; opnieuw gecontroleerd op 2026-10-12): de waarden van Field Usage (Active, DeprecateCandidate, Hidden) en de andere classificatievelden.