De omkeerbaarheidstest
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 3 van 7 in het hoofdstuk Denken als een data-architect, het eerste hoofdstuk van de cursus Data Architect. Elke module staat op zichzelf. Vorige: Het datamodel is het skelet · Volgende: Architectuur is de kunst van het afwegen
De vraag die deze module beantwoordt: Hoe onderscheid je een architectuurbeslissing van een gewone?
Architecten nemen veel beslissingen.
Maar niet elke beslissing is een architectuurbeslissing.
Dat is een belangrijk onderscheid. Als we elke beslissing als architectuur behandelen, besteden we al onze tijd aan discussies over dingen die relatief makkelijk te veranderen zijn. Als we de beslissingen die echt architecturaal zijn niet herkennen, kunnen we vandaag in vijf minuten iets beslissen waar we vijf jaar over doen om het terug te draaien.
Hoe zien we het verschil?
Ik stel graag een simpele vraag:
Hoe moeilijk wordt het om deze beslissing later terug te draaien?
Ik noem dit de omkeerbaarheidstest.
Hoe moeilijker iets terug te draaien is, en hoe meer andere dingen ervan gaan afhangen, hoe meer architectuuraandacht het verdient.
Sommige beslissingen zijn goedkoop te veranderen
Section titled “Sommige beslissingen zijn goedkoop te veranderen ”Laten we met iets simpels beginnen.
We noemen een veld Klantcategorie. Zes maanden later besluit de business dat iedereen het eigenlijk Klantsegment noemt. We veranderen het label. Er is misschien wat documentatie bij te werken en een beetje gebruikerstraining, maar dit is geen grote architectuurgebeurtenis. Met de oorspronkelijke API-naam moeten we wel leven, want die veranderen heeft veel grotere gevolgen. Dit kan dus gewoon betekenen dat we omgaan met een labelwijziging, en de verwarring die daarbij kan horen.
We namen een beslissing. We bedachten ons. We gingen verder.
Vergelijk dat nu met een andere beslissing.
We maken een identificator voor klanten. We beslissen wat die betekent, welk formaat die heeft en welk systeem hem aanmaakt. Dan publiceren we hem.
Salesforce gebruikt hem. Het datawarehouse gebruikt hem. Het integratieplatform gebruikt hem. Het klantportaal gebruikt hem. Vijf andere applicaties gaan hem opslaan. Rapporten en datapijplijnen gebruiken hem. Misschien zien klanten hem uiteindelijk ook.
Drie jaar later zegt iemand:
We hadden die identificator waarschijnlijk niet zo moeten ontwerpen.
Dat is een heel ander gesprek.
Het verschil is niet dat de ene beslissing technischer is dan de andere.
Het verschil is omkeerbaarheid.
Zo kan dat gebeuren. Stel dat de business haar sleutels altijd heeft opgebouwd uit een deel van de klantnaam plus een nummer. Dat werkt jarenlang, omdat niemand ooit een naam heeft hoeven veranderen. Dan, een jaar of langer later, verandert er toch een naam, en ineens passen de sleutels niet meer in het patroon dat de rest van de data verwacht. Dat is een van de redenen waarom sleutels geen eigen betekenis horen te dragen.
Architectuur creëert zwaartekracht
Section titled “Architectuur creëert zwaartekracht ”Een architectuurbeslissing trekt dingen naar zich toe. Ik zie dat als zwaartekracht.
Kies een objectmodel, en er wordt automatisering omheen gebouwd.
Kies een sleutel, en andere systemen gaan hem opslaan.
Kies waar stamgegevens staan, en integraties gaan ernaartoe en ervandaan stromen.
Kies een sharingmodel, en bedrijfsprocessen gaan afhangen van wie wat kan zien.
Kies een integratiepatroon, en systemen gaan afhangen van de timing en het gedrag ervan.
Hoe langer die beslissingen bestaan, hoe meer zwaartekracht ze krijgen. Uiteindelijk betekent het veranderen van de oorspronkelijke beslissing dat je alles verandert wat zich eromheen heeft opgehoopt.
AI voelt die zwaartekracht ook. Een AI-tool werkt vanuit wat er al in het systeem zit: zodra een belangrijk ontwerpelement er is, behandelt elke AI-interactie daarna dat element als feit en bouwt erop voort, en bouwt erop voort, en bouwt erop voort. De beslissing echoot vooruit door veel meer beslissingen heen, en geen mens gaat ooit terug om de oorspronkelijke opnieuw te bekijken. Elke generatie voegt zwaartekracht toe.
Daarom is het belangrijk dat het datamodel “het skelet” is. We zijn niet voorzichtig omdat verandering slecht is. We zijn voorzichtig omdat afhankelijkheden verandering duur maken.
Stel twee vragen
Section titled “Stel twee vragen ”Als ik naar een ontwerpbeslissing kijk, stel ik twee vragen:
Hoe moeilijk is dit terug te draaien?
Hoeveel gaat ervan afhangen?
Ze hangen samen, maar zijn niet hetzelfde. Iets kan technisch makkelijk te veranderen zijn maar honderden afnemers hebben. Mensen gaven vroeger standaardobjecten een ander label voor de duidelijkheid, Account als “Klant” bijvoorbeeld. Makkelijk gedaan. Toen wilde een ander systeem accounts gebruiken voor partners, en dat kon niet. Iets anders heeft misschien maar een paar afnemers maar vraagt een enorme migratie om te veranderen, zoals de API-naam van een object waarnaar intern op veel plekken verwezen wordt. Buiten ziet niemand hem, maar een verkeerde blijft het team in de war brengen. Allebei verdienen ze aandacht.
Denk aan een paar veelvoorkomende databeslissingen:
- Welk Salesforce-object vertegenwoordigt dit bedrijfsconcept?
- Wat is de unieke identificator?
- Welk systeem is het bronsysteem?
- Worden deze gegevens naar Salesforce gekopieerd of ergens anders benaderd?
- Is dit één object of meerdere gerelateerde objecten?
- Wie is eigenaar van de gegevens, en hoe lang bewaren we ze?
- Wat zijn onze standaardgrenzen voor toegang?
- Hoe bewegen deze gegevens tussen systemen?
Dat is iets heel anders dan beslissen waar een veld op een Lightning-pagina staat. Paginaontwerp is ook belangrijk. Maar de kosten van een vergissing zijn anders.
Denk aan de impactradius
Section titled “Denk aan de impactradius ”Een andere manier om over omkeerbaarheid na te denken is de impactradius: als ik deze beslissing verander, wat beweegt er dan nog meer?
Stel dat iets wat we als veld hebben gemodelleerd eigenlijk een child-object moet worden. Dat is niet alleen een schemawijziging. Wat gebeurt er met de bestaande data? Met de rapporten, de integraties die dat veld verwachten, de Apex en Flows die ernaar verwijzen, de beveiliging, de analyses, een AI-agent waarvan de acties afhangen van de oorspronkelijke structuur?
Hoe groter de radius, hoe zorgvuldiger we de oorspronkelijke beslissing moeten nemen.
Daarom moeten architecten ook verder kijken dan hun eigen deel van het systeem. Vanuit Salesforce lijkt een wijziging misschien makkelijk. Vanuit de hele organisatie kan ze twaalf andere systemen raken.
Beslissingen in de organisatie en beslissingen in Salesforce
Section titled “Beslissingen in de organisatie en beslissingen in Salesforce ”Een data-architect denkt op twee niveaus.
Binnen Salesforce beslissen we over objecten, relaties, sleutels, volume, toegang, automatisering en hoe data zich op het platform gedraagt.
Over de hele organisatie stellen we bredere vragen. Waar staat Klant eigenlijk? Wie is eigenaar van Product? Welk systeem maakt een Order aan? Wat is onze gezaghebbende identificator? Welke informatie wordt tussen systemen gekopieerd, en welke blijft waar ze is?
De twee niveaus moeten op elkaar aansluiten. Ik heb Salesforce-implementaties gezien waar het interne model op zichzelf volkomen logisch was maar niet paste bij de organisatie eromheen. Dat is niet genoeg. Salesforce-structuren moeten op organisatieniveau vertegenwoordigd zijn, en beslissingen op organisatieniveau moeten terugvloeien naar Salesforce.
Architectuur is verkeer in twee richtingen.
Vertraag bij de dure beslissingen
Section titled “Vertraag bij de dure beslissingen ”Een gevaar in de technologie is dat de beslissingen die het makkelijkst te implementeren zijn, eruit kunnen zien als de beslissingen die het makkelijkst te nemen zijn. Dat is niet hetzelfde.
Nog een aangepast object maken is makkelijk. Nog een veld maken is makkelijk. Nog een API koppelen wordt steeds makkelijker, en AI maakt het allemaal nog makkelijker.
Maar hoe makkelijk iets te implementeren is, zegt bijna niets over de kosten van de architectuurbeslissing.
Vertraag vóór een moeilijk terug te draaien beslissing lang genoeg om te vragen: welk probleem lossen we eigenlijk op? Welke alternatieven hebben we overwogen? Wat nemen we aan? Wat gebeurt er als het volume groeit, en als de business verandert? Wat gaat hier nog meer van afhangen? Wat gebeurt er als we ons vergissen?
We hebben geen zes maanden review nodig elke keer dat we een object maken. We hebben wel nadenken nodig in verhouding tot de kosten van een vergissing. Is het een object voor één afdeling of subsysteem, dan kun je sneller gaan. Gaat het om referentiegegevens, een belangrijk klantobject of iets wat over systemen heen gebruikt wordt, neem dan de tijd om het goed te doordenken.
Schrijf op waarom
Section titled “Schrijf op waarom ”Er is nog een probleem met belangrijke beslissingen: mensen vergeten waarom ze genomen zijn.
Iemand kijkt drie jaar later naar een architectuur en vraagt: “Waarom zou iemand het zo ontwerpen?” Soms is het antwoord dat het een slecht ontwerp was. Dat gebeurt. Maar soms was er een heel goede reden: een beperking van het platform die niet meer bestaat, een wettelijke eis, een ander systeem dat de voorkeursaanpak niet ondersteunde, een afweging die bewust is geaccepteerd om een deadline te halen.
Als we alleen vastleggen wat we beslisten en niet waarom, kan de volgende architect dat op geen enkele manier weten.
Schrijf belangrijke beslissingen op. Het hoeft geen document van 50 pagina’s te zijn. Een bruikbaar beslisdocument kan heel klein zijn:
Context: welk probleem lossen we op?
Opties: welke realistische alternatieven hebben we overwogen?
Beslissing: wat hebben we gekozen?
Gevolgen: wat winnen we, en wat leveren we in?
Eigenaar: wie is verantwoordelijk voor deze beslissing?
Herziening: welke reden of datum moet ons ertoe brengen haar opnieuw te bekijken?
De waarde zit niet in het document. De waarde zit in het bewaren van de redenering.
En als een beslissing verandert, wis de oorspronkelijke dan niet. Vervang haar. De beslissing die in 2027 juist was, is in 2030 misschien niet meer juist, omdat volumes, de business, Salesforce en ons begrip allemaal veranderen. Wat ik wil bewaren is het verhaal: dit was de context, dit was de beslissing en waarom, dit is er veranderd, en dit beslissen we nu. Dat is veel waardevoller dan doen alsof we het antwoord altijd al wisten.
Voorbij het examen: AI verkort de tijd van beslissing tot afhankelijkheid. Een AI-tool kan in seconden een datamodel voorstellen en er vervolgens de objecten, de automatisering, de integratiecode en de gebruikersinterface bovenop maken. Vroeger duurde het maanden aan ontwikkeling voordat er veel van een twijfelachtige beslissing afhing; nu komen de afhankelijkheden vrijwel meteen. Beoordeel dus de beslissingen onder de output, niet alleen de output. AI kan helpen: het kan opties op een rij zetten, aannames uitdagen en het beslisdocument opstellen. Maar de architect beslist nog steeds, en hoe moeilijker de beslissing terug te draaien is, hoe belangrijker dat menselijke oordeel wordt.
Weet welke beslissingen ertoe doen
Section titled “Weet welke beslissingen ertoe doen ”Een van de vaardigheden die ik je wil laten ontwikkelen, is weten waar je je aandacht aan besteedt.
Maak niet van elke configuratiekeuze een architectuurtop.
Maar neem ook niet achteloos een beslissing waar de organisatie het komende decennium mee moet leven.
Vraag:
Hoe moeilijk wordt dit om terug te draaien?
Hoeveel gaat ervan afhangen?
Als de antwoorden heel moeilijk en heel veel zijn, heb je waarschijnlijk een architectuurbeslissing gevonden.
Vertraag. Begrijp de eis. Verken de alternatieven. Maak de afwegingen zichtbaar. Neem de beslissing. En schrijf op waarom.
Het doel van architectuur is niet beslissingen nemen die nooit kunnen veranderen.
Het doel is de beslissingen herkennen waarbij van gedachten veranderen duur gaat worden.
Wat een architect hier beslist
Section titled “Wat een architect hier beslist ”- Welke beslissingen architecturaal zijn: moeilijk terug te draaien, met veel wat ervan afhangt.
- Hoeveel aandacht elke beslissing krijgt, in verhouding tot de kosten van een vergissing.
- Welke beslissingen worden opgeschreven, met hun context, opties, gevolgen, eigenaar en herzieningsmoment.
- Hoe de beslissingen in Salesforce aansluiten op die van de organisatie.
Verder lezen
Section titled “Verder lezen ”- Object Relationships Overview (opens in a new tab), Salesforce Help (Engels, gecontroleerd op 2026-10-09; opnieuw gecontroleerd op 2026-10-12): in een hoofd-detailrelatie volgen de toegang en het eigenaarschap van het detail de master, en het verwijderen van een master verwijdert zijn details.
- Considerations for Object Relationships (opens in a new tab), Salesforce Help (Engels, gecontroleerd op 2026-10-09; opnieuw gecontroleerd op 2026-10-12): een lookup wordt alleen master-detail als elk record er een waarde in heeft; omzetten verandert het sharingmodel (naar Controlled by Parent), en het relatietype bepaalt welke standaardrapporttypen beschikbaar zijn.
- Roll-Up Summary Field (opens in a new tab), Salesforce Help (Engels, gecontroleerd op 2026-10-09; opnieuw gecontroleerd op 2026-10-12): samenvattingsvelden bestaan alleen bij hoofd-detailrelaties, en moeten worden verwijderd voordat een master-detail een lookup kan worden.