Denken als een architect
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 1 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 hoofdstukoverzicht · Volgende: Het datamodel is het skelet
De vraag die deze module beantwoordt: Wat is het verschil tussen bouwen en architectuur, en wat doet een architect eigenlijk?
Het grootste deel van mijn loopbaan ben ik een bouwer geweest.
Ik begon als developer. Ik werkte met Java en .NET voordat ik in Salesforce terechtkwam, en ik heb jarenlang systemen ontworpen, code geschreven, platforms geïntegreerd, architecten opgeleid en architecturen beoordeeld.
Maar een van de belangrijkste lessen die ik onderweg leerde, is dat een goede bouwer zijn en een goede architect zijn niet altijd hetzelfde is.
Een bouwer vraagt:
Hoe bouw ik dit?
Een architect moet een andere reeks vragen stellen:
Moeten we dit bouwen?
Waarom bouwen we het op deze manier?
Wat zijn de alternatieven?
Wat gebeurt er als dit groter wordt?
Wat gebeurt er als het faalt?
En welke beslissing nemen we vandaag waarvan we over drie jaar zullen wensen dat we er beter over hadden nagedacht?
Ik herinner me een project voor een retailbedrijf met afspraken. Ik vroeg: hoeveel afspraken per dag per winkel? Daarna: hoeveel winkels hebben jullie? En hoeveel dagen per week zijn jullie open? Al snel besefte ik dat we alleen al in het eerste jaar miljoenen afspraken zouden hebben. Dat zijn de vragen die een architect aan het begin van een project stelt.
Die verandering in denken is waar deze cursus eigenlijk over gaat.
De persoon met de bouwtekening
Section titled “De persoon met de bouwtekening ”Ik heb deze vergelijking vaak gebruikt als ik architecten lesgeef.
Stel je een bouwplaats voor. Er zijn mensen die beton storten, elektra aanleggen, leidingen installeren, wanden opbouwen en tientallen andere gespecialiseerde klussen doen. Ze moeten heel goed zijn in wat ze doen.
Maar iemand moet ook de bouwtekening vasthouden.
Die persoon moet begrijpen hoe al die onderdelen in elkaar passen. Diegene moet merken wanneer iets in het ene deel van het project ergens anders een probleem veroorzaakt.
Dat is architectuur.
In de technologie maken we soms de fout te denken dat de architect gewoon degene is die het meest weet. Dat is het niet echt. Kennis van het platform is belangrijk. Je hebt technische diepgang nodig. Maar architectuur is geen quiz.
De taak van de architect is goede beslissingen nemen, soms met onvolledige informatie en tegenstrijdige eisen, en de gevolgen van die beslissingen begrijpen.
Dat is een heel andere vaardigheid.
Neem de eis niet zomaar over
Section titled “Neem de eis niet zomaar over ”Een van de eerste gewoonten die ik architecten wil aanleren is simpel:
Vraag waarom.
Iemand zegt tegen je:
We hebben nog een object nodig.
Waarom?
We willen dit veld naar de Account gekopieerd hebben.
Waarom?
We willen al deze gegevens in Salesforce opgeslagen hebben.
Waarom?
Dat betekent niet moeilijk doen. Het betekent de echte bedrijfseis begrijpen in plaats van meteen de voorgestelde oplossing te bouwen.
Een eis komt vaak vermomd als ontwerp binnen.
“We hebben een nieuw aangepast object nodig” is niet per se een eis. De eis kan eigenlijk zijn “we moeten deze informatie apart bijhouden”. Dat is niet hetzelfde.
Zodra je de echte eis begrijpt, kun je alternatieven gaan verkennen. Misschien is een nieuw object precies het juiste antwoord. Misschien hoort de informatie op een plek die al bestaat. Misschien moet Salesforce die gegevens helemaal niet bezitten.
De architect moet wat de business nodig heeft scheiden van één voorgestelde manier om het te leveren.
We werkten aan een sales-applicatie, en de klant had meerdere goedkeuringen, elk met een goedkeurder en een datum. Hun eerste vraag was om Goedkeurder 2 en Goedkeurder 3, elk met een datum, als velden op de verkoopkans toe te voegen. Toen we dieper groeven, bleek dat het er meer dan twee of drie konden zijn. Dus verplaatsten we goedkeuringen naar een child-object. Het verzoek was meer velden; de eis was elke goedkeuring bijhouden, hoeveel het er ook zouden blijken te zijn.
Verder denken dan de eis
Section titled “Verder denken dan de eis ”Uit het vragen naar het waarom volgen twee gewoonten, en elk krijgt later in dit hoofdstuk een eigen module.
Er is meestal meer dan één antwoord. Salesforce geeft ons veel manieren om een probleem op te lossen, en sommige zijn bijna meteen verkeerd. Kiezen tussen de manieren die werken is de kunst van het afwegen (module 4).
En de eisen die je krijgt zijn niet alle eisen die je hebt. Niemand zegt “zorg dat dit werkt als de nachtelijke load maar half lukt”, maar het is toch een eis. Ik bekijk elk ontwerp door drie lenzen: bouw voor vandaag, plan voor morgen, plan voor falen (module 5).
Denk aan iemand die een architect inhuurt om een gebouw te ontwerpen. Die vraagt niet om een brandalarm of een sprinklerinstallatie, of om een gebouw dat overeind blijft bij een aardbeving. Dat verwacht diegene als onderdeel van het werk, zonder erom te vragen. Onze wereld werkt net zo. Niemand vraagt om nette foutafhandeling, om logs of om een manier om te herstellen als er iets misgaat. Het is aan de architect om te weten welke van die systemen in het ontwerp horen, en ze erin te zetten.
Maak je redenering zichtbaar
Section titled “Maak je redenering zichtbaar ”Een architect moet niet zomaar een ruimte binnenlopen en aankondigen: “Dit gaan we doen.”
Je taak is ook uitleggen waarom. Ik wil dat stakeholders de alternatieven begrijpen die we hebben overwogen en de afwegingen die erbij horen. Dat betekent niet dat je een bestuurder een ontwerpdocument van 40 pagina’s geeft. Het betekent dat je dezelfde architectuur kunt uitleggen aan een developer, aan de business en aan een bestuurder: verschillende gesprekken over dezelfde beslissing.
En de manier om dat te doen is met duidelijke bouwtekeningen en instructies, zoals de persoon met de bouwtekening op de bouwplaats. Voor een data-architect is het datamodel een van de belangrijkste van die bouwtekeningen.
Als niemand begrijpt waarom een beslissing is genomen, is de kans groot dat iemand haar uiteindelijk terugdraait. En die persoon kan daar volkomen redelijke redenen voor hebben, omdat niemand de oorspronkelijke beslissing ooit heeft uitgelegd.
De architect hoeft niet alles te bouwen
Section titled “De architect hoeft niet alles te bouwen ”Er is nog een overgang die lastig kan zijn, vooral voor mensen die via development in de architectuur terechtkomen.
Je hoeft niet alles zelf te bouwen.
Ik vind het nog steeds fijn om op een heel technisch niveau te begrijpen hoe dingen werken, en dat fundament is belangrijk. Maar als architect wordt je verantwoordelijkheid groter dan je eigen implementatie. Je hoeft niet alles te bouwen; je moet weten hoe je de mensen die het wel bouwen de juiste richting en de juiste kaders geeft. Dat betekent genoeg begrijpen om hun werk te sturen, te herkennen wanneer een voorgestelde implementatie een architectuurprobleem veroorzaakt, en te schakelen tussen de details en het grotere geheel.
Soms betekent dat diep in een query, een API of een datamodel duiken.
Soms betekent het een stap terug doen en vragen of we er überhaupt iets van moeten doen.
En steeds vaker zijn het niet alleen mensen die bouwen. Met AI werkt de architect misschien rechtstreeks met het gereedschap dat de objecten, de code en de schermen genereert. Dan gaan de richting, de kaders en de richtlijnen naar de AI, en ze goed meegeven wordt steeds meer de verantwoordelijkheid van de architect. Daar komen we op terug in module 7.
Dat hoort bij de reis van bouwer naar architect.
Je taak is beslissingen nemen
Section titled “Je taak is beslissingen nemen ”Uiteindelijk gaat architectuur over beslissingen.
Sommige beslissingen zijn makkelijk te veranderen. Andere niet.
Een page layout kun je aanpassen. Een label kun je hernoemen.
Maar kies het verkeerde fundamentele datamodel, publiceer identificatoren waar tientallen systemen van gaan afhangen, of zet de mastercopy van kritieke gegevens op de verkeerde plek, en van gedachten veranderen wordt veel duurder.
Dat zijn architectuurbeslissingen. En dat zijn precies het soort beslissingen waar deze cursus zich op richt.
Als data-architect neem je beslissingen over hoe informatie gestructureerd is, waar ze staat, hoe ze groeit, hoe ze beweegt, wie erbij kan en hoe de rest van de organisatie haar begrijpt.
De technologie is belangrijk.
Maar elke Salesforce-functie kennen is niet het doel.
Het doel is het oordeelsvermogen ontwikkelen om te weten welk gereedschap je gebruikt, wanneer je het gebruikt, wat je ervoor inlevert en wat er daarna gebeurt.
Dat is denken als een architect.
En nu kunnen we beginnen te denken als een data-architect.
Wat een architect hier beslist
Section titled “Wat een architect hier beslist ”- Of een verzoek een echte eis is, of één voorgesteld ontwerp daarvoor.
- Welke vragen je stelt voordat er iets gebouwd wordt: moeten we dit, waarom zo, wat kunnen we nog meer doen, wat gebeurt er als het groeit of faalt.
- Welke beslissingen aan de architect zijn en welke bij de bouwers horen; en welke richting en kaders je de bouwers geeft, mensen of AI.
- Hoe je een beslissing zo uitlegt dat een developer, de business en een bestuurder haar allemaal begrijpen.