Ken je gereedschap: de negen vragen

🌐 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 6 van 7 in het hoofdstuk Denken als een data-architect, het eerste hoofdstuk van de cursus Data Architect. Elke module staat op zichzelf. Vorige: Bouw voor vandaag. Plan voor morgen. Plan voor falen. · Volgende: De data-architect in het tijdperk van AI

De vraag die deze module beantwoordt: Hoe beoordeel je elk gereedschap, ook een dat je nog nooit gezien hebt?

Architecten hebben oordeelsvermogen nodig. Maar oordeelsvermogen zonder kennis is niet erg nuttig. Je moet je gereedschap nog steeds kennen.

Ik leid al jaren architecten op, en een kader dat ik gebruik is een reeks vragen die je moet kunnen beantwoorden over elk belangrijk gereedschap of elke belangrijke mogelijkheid in je architectuur. Oorspronkelijk leerde ik acht vragen. Ik heb er een negende aan toegevoegd. De technologieën veranderen, Salesforce verandert, nieuwe producten verschijnen en oude mogelijkheden ontwikkelen zich, en AI versnelt het allemaal. Deze vragen blijven werken.

De negen vragen

Als je een technologie leert of beoordeelt, vraag dan:

1. Wat is het?
2. Waar wordt het gebruikt?
3. Hoe gebruik ik het?
4. Wat zijn mijn alternatieven?
5. Wat zijn de sterke punten?
6. Wat zijn de zwakke punten?
7. Hoe leg ik het uit aan developers, de business en bestuurders?
8. Hoe wordt het op de lange termijn onderhouden?
9. Wat kost het, welke licenties vraagt het, en wat zijn de limieten?

Als je ze alle negen kunt beantwoorden, begin je het gereedschap te begrijpen zoals een architect. Kijk wat er niet op de lijst staat: “Kan ik het configureren?” Dat is belangrijk, maar het is maar een deel van het gereedschap kennen.

Click to enlarge

1. Wat is het?

Begin met de voor de hand liggende vraag, want mensen slaan haar verrassend vaak over. We horen de naam van een product of functie en beginnen meteen te discussiëren of we het moeten gebruiken. Rustig aan. Wat doet het eigenlijk? Voor welk probleem is het ontworpen? Waar zit het in de architectuur, en wat is het niet? Een architect moet een technologie kunnen beschrijven zonder de marketingtekst te herhalen. Als ik iets niet in een paar zinnen kan uitleggen, begrijp ik het waarschijnlijk nog niet goed genoeg.

2. Waar wordt het gebruikt?

Weten wat iets doet is niet hetzelfde als weten wanneer het in een architectuur thuishoort. In welke soorten problemen is het goed? Welke omstandigheden maken het geschikt, en welke omstandigheden zouden me argwanend moeten maken? Dit is de stap van “ik ken deze functie” naar “ik herken het probleem dat deze functie oplost”, en het is een grote stap. Je wilt niet rondlopen op zoek naar plekken om je favoriete technologie te gebruiken. Je wilt problemen herkennen en weten welk gereedschap erbij past.

3. Hoe gebruik ik het?

Ja, architecten moeten de implementatie begrijpen. Je hoeft niet elk onderdeel te bouwen, maar je moet genoeg begrijpen om te weten wat je anderen vraagt te bouwen. Weet hoe het geconfigureerd wordt, hoe een developer ermee werkt, hoe data erin en eruit komt, hoe het gedeployed en beveiligd wordt, en hoe het eruitziet in gebruik. Ik wil niet dat een architect ontwerpt rond een technologie die die alleen op een productslide heeft gezien. Maak je handen vuil: bouw iets, maak iets kapot, kijk hoe het zich echt gedraagt. Architectuur wordt beter als ze gegrond is in de werkelijkheid.

4. Wat zijn mijn alternatieven?

Dit is misschien de belangrijkste vraag op de lijst. Als je maar één manier kent om een probleem op te lossen, heb je geen architectuurbeslissing; je hebt een standaardkeuze. Als iemand een technologie voorstelt, wil ik weten wat we nog meer zouden kunnen doen. Een andere Salesforce-mogelijkheid? Iets declaratiefs, of code? Kan de mogelijkheid buiten Salesforce leven? Kunnen we de data laten waar ze is in plaats van haar te kopiëren, een event gebruiken in plaats van een API-aanroep, of helemaal niets bouwen? Alternatieven creëren afwegingen, en afwegingen zijn de kern van architectuur.

5. Wat zijn de sterke punten?

Elk gereedschap bestaat met een reden. Begrijp waar het echt goed in is: wat het makkelijk maakt, waar het goed schaalt, welke complexiteit het weghaalt, welke problemen het elegant oplost. Gebruik technologieën waar hun sterke punten aansluiten op het probleem. Dat klinkt vanzelfsprekend, maar het is heel makkelijk een gereedschap te kiezen omdat we het al hebben, het team het kent, het nieuw is of iemand een demo zag. Dat kunnen factoren zijn. Het is niet hetzelfde als architecturale fit.

6. Wat zijn de zwakke punten?

Dit is net zo belangrijk. Elke technologie heeft zwakke punten, echt elke. Als iemand je alleen de sterke punten van een technologie kan vertellen, voer je nog geen architectuurdiscussie. Wat doet het niet goed? Waar duikt complexiteit op, en wat gebeurt er op schaal? Welke beheerlast en afhankelijkheden brengt het mee? Welke eisen duwen het uit zijn sweet spot? Een zwak punt betekent niet altijd dat we de technologie niet moeten gebruiken. Het betekent dat we moeten weten wat we accepteren. Een afweging die je begrijpt, kan een architectuurbeslissing zijn. Een afweging die je niet begrijpt, kan een verrassing worden.

7. Hoe leg ik het uit aan verschillende doelgroepen?

Dit is een van de vragen die technische kennis scheidt van architectuurvaardigheid. Kun je dezelfde technologie uitleggen aan een developer, aan de business en aan een bestuurder? Dat moeten niet dezelfde uitleggen zijn. De developer heeft de API’s, het transactiegedrag, de beveiliging, de foutafhandeling en de implementatiepatronen nodig. De business geeft om wat het mogelijk maakt en hoe hun proces verandert. De bestuurder geeft om kosten, risico, tijd, impact op de organisatie, en welke opties de beslissing openhoudt of afsluit. Je verandert de waarheid niet; je verandert het abstractieniveau. Als je een technologie alleen kunt uitleggen in de woorden van haar documentatie, werk dan verder aan je begrip.

8. Hoe wordt het op de lange termijn onderhouden?

Projecten eindigen. Systemen niet, of dat hopen we tenminste. Iemand moet eigenaar zijn van wat we bouwen nadat het projectteam vertrekt. Dat betekent weten hoe het gemonitord, geüpgraded en geanalyseerd wordt bij problemen, wie de vaardigheden nodig heeft om het te ondersteunen, hoe wijzigingen gedeployed en getest worden, en wat er gebeurt als de technologie zich ontwikkelt of Salesforce er iets onder verandert. Stel je het over drie jaar voor. Ik heb architecturen gezien die op de lanceerdag heel slim waren en daarna ellendig om te beheren. Dat is geen succes. Onderhoudbaarheid hoort bij architectuur.

9. Wat kost het, welke licenties vraagt het, en wat zijn de limieten?

Dit is de vraag die ik aan de oorspronkelijke acht heb toegevoegd, en vandaag denk ik dat je haar onmogelijk kunt weglaten. Een technologie kan de perfecte technische oplossing zijn en toch de verkeerde architectuuroplossing als de economie niet klopt. Zit het in de licenties die we hebben, of is het een add-on? Wordt het gelicentieerd per gebruiker, gebruik, verbruik, opslag of transactie? Wat gebeurt er met de kosten als we schalen?

Dan zijn er de limieten, en elk platform heeft ze: limieten voor API’s, opslag, query’s, transacties, gelijktijdigheid, doorvoer en licenties. Sommige zijn hard, andere zacht; sommige kunnen omhoog en andere niet; sommige doen er op onze schaal niet toe tot we er een nul bij krijgen. Je hoeft niet elke Salesforce-limiet uit je hoofd te kennen, en dat zou een vreselijke besteding van je tijd zijn. Je moet weten dat de limieten bestaan, welke ertoe doen voor jouw architectuur, en wanneer je het actuele getal moet nakijken. De getallen veranderen. De architectuurvraag blijft.

Een uitgewerkt voorbeeld: Apex sharing

Dit is een van mijn meest gebruikte voorbeelden van de vragen in de praktijk. We krijgen een eis voor ingewikkelde sharing, sharing die met geen enkele eigenaargebaseerde of criteriagebaseerde deelregel te realiseren is. Dat brengt ons bij Apex sharing: code die de sharingrecords zelf schrijft. Nu moeten we dus weten wat Apex sharing is, waar het gebruikt wordt, hoe je het gebruikt, enzovoort. Het is een escalatie: Apex sharing is het alternatief (vraag 4) voor als de regels die we nodig hebben verder gaan dan wat eigenaar- en criteriagebaseerde sharing kan uitdrukken.

Nu de zwakke punten (vraag 6). Stel dat we een klantcommunity hebben met 10 of 20 miljoen leden, en we gebruiken de licentie Customer Community, niet Customer Community Plus. Dat zijn high-volume users. Ze hebben geen rollen, en ze gebruiken het sharingmodel helemaal niet: hun toegang komt van sharing sets en share groups, gekoppeld via hun account en contactpersoon. Er is geen sharerecord dat Apex voor hen kan schrijven, dus Apex sharing werkt voor hen niet. En de vraag over kosten en licenties (vraag 9) is wat ons daar bracht: de licentiekeuze besliste welke sharinggereedschappen er überhaupt bestaan.

Dus net zoals Apex sharing het alternatief was voor eigenaar- en criteriagebaseerde regels, kun je een situatie tegenkomen waarin je een alternatief voor Apex sharing nodig hebt. En op dat punt zijn er eigenlijk geen configuratieopties voor complexe deelregels. Je maakt het object uiteindelijk alleen-lezen en regelt de toegang via Apex. Daarom stel je alle negen vragen voordat je kiest, niet erna.

Leer het platform niet uit je hoofd

Dit is het belangrijkst als je Salesforce-architectuur aan het leren bent. Probeer Salesforce niet uit je hoofd te leren. Dat kan niet: het platform is te groot en verandert te snel. Ik werk al heel lang met Salesforce, en ik leer nog steeds. Dat is normaal.

Wat ik je wil laten ontwikkelen, is een kader om te leren. Als Salesforce morgen een nieuwe mogelijkheid uitbrengt, hoef ik die niet eerder gezien te hebben. Ik weet wat ik moet vragen: wat is het, waar past het, hoe gebruik ik het, wat kan ik nog meer gebruiken, waar is het goed in, waar heeft het moeite mee, hoe leg ik het uit, hoe beheer ik het, en wat kost het en waar liggen de limieten? Nu kan ik het gaan beoordelen. Dat is veel waardevoller dan nog een functiematrix uit je hoofd leren.

Voorbij het examen: AI maakt de negen vragen sneller te beantwoorden, en makkelijker fout. Kom je een technologie tegen die je niet kent, dan kun je AI vragen haar uit te leggen, drie aanpakken te vergelijken, haar limieten en veelvoorkomende faalwijzen op te sommen, of te pleiten tegen het gebruik ervan. Dat is een opmerkelijke onderzoeksassistent. Maar het kan verkeerd zijn, verouderd, of met grote stelligheid twee producten of edities met een vergelijkbare naam door elkaar halen. Controleer alles wat een beslissing beïnvloedt: volg de bron en kijk de actuele documentatie, limieten en licenties na. Vertrouw, maar controleer (module 7).

Leer de vragen, niet alleen de antwoorden

We komen in deze cursus veel technologieën tegen. Ik wil niet dat je antwoorden verzamelt; ik wil dat je de vragen oefent. Als we het hebben over big objects, externe data, Data 360, integratiepatronen of een AI-mogelijkheid die Salesforce zes maanden na het schrijven van dit hoofdstuk uitbrengt, stel dan dezelfde negen vragen.

De antwoorden veranderen. De vragen blijven. Dat maakt dit een architectuurkader in plaats van een studiegids.

Ken je gereedschap: waar het goed in is, waar het slecht in is, wat je nog meer zou kunnen gebruiken, wat het kost en waar het breekt. En weet genoeg om de beslissing uit te leggen aan de mensen die ermee moeten leven. Zo leert een architect technologie.

Wat een architect hier beslist

• Of een gereedschap bij het probleem past, beoordeeld op alle negen vragen, niet alleen op of het te configureren is.
• Wat de alternatieven zijn, en wat de kosten, licenties en limieten van het gereedschap betekenen op jouw schaal.
• Wie het onderhoudt, en hoe, over drie jaar.
• Welke feiten over het gereedschap je moet controleren voordat je erop vertrouwt.

Verder lezen

• About High-Volume Community or Site Users (opens in a new tab), Salesforce Help (Engels, gecontroleerd op 2026-10-09; opnieuw gecontroleerd op 2026-10-12): high-volume users (de licenties External Apps, Customer Community, High Volume Customer Portal en Authenticated Website) hebben geen rollen; hun toegang komt van sharing sets en share groups; ze kunnen niet in eigenaargebaseerde deelregels worden opgenomen, en records waarvan zij eigenaar zijn kunnen niet handmatig worden gedeeld.
• Platform Sharing Architecture (opens in a new tab), Salesforce Architects (Engels, gecontroleerd op 2026-10-09; opnieuw gecontroleerd op 2026-10-12): high-volume users (Customer Community, High Volume Customer Portal, Authenticated Website) gebruiken het sharingmodel niet, omdat hun licenties geen rollen ondersteunen; toegang werkt door de gebruiker te koppelen aan de opzoekvelden naar account en contactpersoon, via sharing sets of share groups. Dezelfde pagina noemt wanneer Apex managed sharing het juiste gereedschap is.
• Account Sharing Sets for High Volume Customer Portal Users (opens in a new tab), vraag in de Trailblazer Community, november 2024 (Engels, gecontroleerd op 2026-10-09; opnieuw gecontroleerd op 2026-10-12): iemand uit de praktijk meldt dat het invoegen van sharerecords voor high-volume users mislukte met een foutmelding. Een praktijkmelding, geen officiële documentatie. (De online Trailblazer Community wordt op 30 oktober 2026 alleen-lezen; de link kan veranderen.)
• Create a Sharing Set for Experience Cloud Site Users (opens in a new tab), Salesforce Help (Engels, gecontroleerd op 2026-10-09): een sharing set geeft toegang tot records die gerelateerd zijn aan de account of contactpersoon van de gebruiker.