Architectuur is de kunst van het afwegen

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

De vraag die deze module beantwoordt: Als meerdere oplossingen kunnen werken, hoe kiest een architect dan, en hoe legt die de keuze uit?

Als architectuur gewoon ging over het vinden van het juiste antwoord, zou het een stuk makkelijker zijn. Leer het platform, leer de patronen, leer de limieten, kies de juiste, klaar.

Zo werkt echte architectuur niet. De moeilijke beslissingen gaan meestal niet tussen een duidelijk goede en een duidelijk slechte oplossing. Ze gaan tussen meerdere oplossingen die kunnen werken, elk met voor- en nadelen, en elk duwt de architectuur een net iets andere kant op. Daar verdient de architect zijn plek aan tafel.

Veel manieren om het probleem op te lossen

Ik heb een versie van dit voorbeeld vaak gebruikt als ik architecten lesgeef.

Er kunnen in Salesforce veel manieren zijn om een probleem op te lossen. Soms plak ik er een getal op, zeg tien, maar dat is een vergelijking, geen telling. Veel van de opties hebben vanaf het begin problemen: ze lopen tegen een beperking van het platform aan, missen een kritieke eis, of veroorzaken een beveiligings- of prestatieprobleem dat we niet kunnen accepteren. Die kunnen we snel opzijleggen. Sommige andere werken vandaag maar krijgen problemen als de data groeit. Ze functioneren technisch, maar ze houden geen stand bij de groei waarvan we al weten dat die eraan komt.

Wat overblijft is een klein aantal opties die je behoeften ook in de toekomst kunnen ondersteunen, en nu wordt het interessant. Elk ervan kan werken, schalen en aan de eisen voldoen. Welke is dan de juiste? Misschien allemaal. De taak van de architect is de verschillen begrijpen.

Zelfs iets simpels als een keuzelijst werkt vandaag en kan problemen krijgen als de data groeit. Een keuzelijst is makkelijk voor gebruikers. Maar vraag waar de waarden vandaan komen, en hoeveel het er kunnen worden. Keuzelijsten werken het best met minder dan zo’n 20 waarden. Soms gaan we tot 50, zoals de Amerikaanse staten, en zelden voorbij de 100, zoals landen, en die worden onhandig. Ken dus bij elke keuzelijst de bovengrens. En de waarden van een keuzelijst wijzigen is een metadatawijziging, geen datawijziging.

Gebruik in plaats daarvan een lookup, en de gebruikersinterface wordt iets complexer. Maar de lijst kan zonder bovengrens blijven groeien, en nieuwe waarden kunnen via een integratie binnenkomen. Dat is een afweging tegen gebruiksgemak. Dat is de balans.

Click to enlarge

Optimaal betekent niet perfect

Ik gebruik het woord optimaal met zorg. Een optimale architectuur is niet een architectuur waarin elke afzonderlijke beslissing perfect is; die architectuur bestaat waarschijnlijk niet. Het is een architectuur waarin de oplossing als geheel in balans is.

Stel dat oplossing A de beste prestaties geeft maar duur en moeilijk te onderhouden is. Oplossing B kost minder en is makkelijker te beheren maar levert wat prestaties in. Oplossing C is flexibeler voor de toekomst maar voegt vandaag complexiteit toe. Welke is optimaal? Op basis van alleen die feiten kan ik dat niet zeggen. Ik moet de business, de eisen en de prioriteiten kennen, en weten welke beperkingen echt zijn en welke voorkeuren. Architectuur hangt af van de context. Daarom kan het patroon dat goed was voor de ene klant volkomen verkeerd zijn voor de volgende.

En je taak als data-architect is deze beslissingen in balans brengen. Tientallen ervan neem je zelf, of met je team. Weet welke dat zijn, en weet wanneer een beslissing een grotere impact heeft, op kosten, tijd of functionaliteit, en naar de belangrijkste beslissers moet.

Een suboptimale beslissing kan deel zijn van een optimale architectuur

Dit is een van de belangrijkste ideeën in dit hoofdstuk. Soms neem ik bewust een suboptimale beslissing in één deel van de architectuur omdat die de hele oplossing beter maakt.

Misschien dupliceer ik een kleine hoeveelheid data, omdat het weghalen van de duplicatie onnodige integratiecomplexiteit zou opleveren. Misschien kies ik een eenvoudiger datamodel, omdat het theoretisch schonere model rapportage en dagelijks gebruik veel moeilijker zou maken. Misschien accepteer ik een kleine prestatiekost, omdat het alternatief infrastructuur toevoegt die de organisatie nog niet kan beheren.

Bekijk er één los en je zou zeggen dat het niet optimaal is. Klopt. Maar architectuur gaat niet over het optimaliseren van elk onderdeel op zichzelf; het gaat over het optimaliseren van het systeem. Een lokaal suboptimale beslissing kan deel zijn van een globaal optimale architectuur, zolang we de afweging begrijpen die we maken. Gevaarlijk is de afweging maken zonder te weten dat je hem maakt.

Weet wat je inlevert

Als iemand me vertelt “dit is de beste oplossing”, is mijn volgende vraag “de beste waarin?” Het snelst? Het goedkoopst? Het eenvoudigst? Het meest schaalbaar, het veiligst, het flexibelst? Het makkelijkst te beheren, het snelst opgeleverd, het minst afhankelijk van specialistische vaardigheden? Er is bijna altijd een andere dimensie waarin het antwoord niet “de beste” is. Dat is de afweging. Ik wil weten wat we krijgen, en ik wil ook weten wat we inleveren.

Neem twee opties voor een grote verzameling bedrijfsgegevens. De ene kopieert de data naar Salesforce, waardoor Salesforce-eigen mogelijkheden makkelijker te gebruiken zijn, maar nu zijn we verantwoordelijk voor het verplaatsen, opslaan, synchroniseren en beveiligen van nog een kopie, en voor de vertraging. De andere laat de data waar ze is en benadert haar wanneer nodig. We hebben wat duplicatie weggehaald, maar nu worden beschikbaarheid, queryprestaties, netwerkafhankelijkheden en de mogelijkheden van het andere systeem belangrijker. Geen van beide beschrijvingen zegt welke we moeten kiezen. Ze zeggen welke vragen we moeten stellen.

Eisen zijn niet allemaal gelijk

Afwegingen dwingen ons ook in te zien dat niet elke eis even zwaar weegt.

Iemand zegt: “De data moet direct beschikbaar zijn.” Goed, wat betekent direct? Eén seconde, tien seconden, een minuut? En waarom? Misschien gaat het om fraudedetectie, waar seconden tellen. Misschien vindt iemand het gewoon niet fijn om op de nachtelijke load te wachten. Dat zijn heel verschillende eisen, en de architect blijft vragen tot we weten welke we hebben.

Ik hou van eisen die vragen overleven: hoeveel, hoe vaak, hoe snel, voor wie, en wat gebeurt er als we het niet doen? “Snel” is geen architectuureis. “95 procent van de klantupdates moet binnen 30 seconden beschikbaar zijn voor de servicemedewerker” komt er al veel dichter bij. Nu kunnen we afwegingen maken.

Beperkingen veranderen het antwoord

Soms wordt de architectuur helemaal niet beperkt door technologie. Ze wordt beperkt door geld, mensen, tijd, licenties of de volwassenheid van de organisatie.

Een architectuur die technisch uitstekend is maar een beheerteam vraagt dat het bedrijf niet heeft, is geen goede architectuur. Een mogelijkheid die het probleem elegant oplost maar licenties vraagt die de klant niet gaat kopen, is ook niet de oplossing. En de perfecte transformatie van drie jaar helpt een bedrijf niet dat over acht weken live moet.

Niets daarvan betekent dat we goede architectuur opgeven vanwege een deadline. Het betekent dat we begrijpen wat we compromitteren, waarom, en welke gevolgen we accepteren, en idealiter hoe we van het compromis van vandaag naar de architectuur van morgen komen.

De architect heeft een beeld van “optimaal” nodig

Hier zit een interessante spanning. Ik vertel je dat er vaak niet één perfect antwoord is, en ik wil ook dat je een beeld in je hoofd hebt van hoe een optimale oplossing eruitziet. Dat is geen tegenspraak. Je hebt een referentiepunt nodig.

Als ik naar een datamodel kijk, wil ik weten wat ik zou bouwen als ik voor de eisen kon optimaliseren zonder onnodige beperkingen. Als echte beperkingen ons dan van dat ontwerp wegduwen (we maken een deel van het model platter, dupliceren wat data, stellen een integratie uit, accepteren tijdelijk een handmatig proces), maak ik geen willekeurige compromissen. Ik weet in welke richting ik van optimaal afwijk, en waarom. Dat is de kunst van architectuur, en dat instinct vraagt oefening.

Teken het

Een van de beste manieren om een afweging te begrijpen is haar tekenen. Architectuurdiagrammen zijn geen versiering voor een presentatie; het zijn denkgereedschappen. Als we tussen twee aanpakken kiezen, teken ze dan allebei. Waar staat de data, en waar beweegt ze? Wie is eigenaar? Waar liggen de grenzen, en waar wordt beveiliging afgedwongen? Wat gebeurt er als iets faalt, en wat verandert er als het volume groeit?

Een diagram trekt onduidelijkheid de openbaarheid in, en het geeft iedereen hetzelfde plaatje om naar te wijzen.

Hoe belangrijk dat is, leerde ik op een project bij een nutsbedrijf. Review na review merkte ik dat ik dezelfde concepten opnieuw uitlegde en het gesprek terugtrok naar het oorspronkelijke ontwerp. Dus veranderde ik hoe ik die vergaderingen leidde: elke review begon met het datamodel op het scherm. Niet het gedetailleerde met elk veld. Een samenvattend model: een account heeft contactpersonen, dit record heeft children, hier hangt het werk aan. De zaal bestond vooral uit bestuurders, en het kostte een paar minuten.

Omdat het vergadering na vergadering dezelfde mensen waren, werd het diagram onze gedeelde taal. Mensen gingen de namen ervan gebruiken. De herhaalde vragen verdwenen, en de vergaderingen werden veel makkelijker. Ik noem het de vergadering gronden: een eenvoudig diagram, elke keer getoond, was veel meer waard dan het kostte om te maken.

Het doel is geen artistieke perfectie. Soms is het een gedetailleerd diagram voor engineers, soms vijf blokken en zes pijlen voor een bestuurder. Het doel is helderheid.

Leg de afweging uit

Een goede architect zet het op volgorde: dit zijn de opties die we overwogen, dit geeft elke optie ons, dit kost elke optie ons, dit is de optie die ik aanbeveel, en dit is waarom.

Merk op dat de aanbeveling na de afwegingen komt. Ik wil niet dat architectuur verwordt tot “ik heb dit eerder gedaan, vertrouw me nou maar”. Ervaring is enorm belangrijk; ze helpt je patronen sneller te herkennen en problemen eerder te zien. Maar je ervaring moet je redenering verbeteren, niet vervangen. Onze taak is niet alleen de architectuur begrijpen. Het is de organisatie helpen de beslissing te begrijpen, vooral als de mensen die de knoop doorhakken geen architecten zijn.

Think Correct. Think Fast.

Je hebt niet altijd drie weken om elke optie te analyseren. Soms heb je drie minuten. Een eis verandert in een vergadering, iemand noemt een beperking waar je niets van wist, of een bestuurder vraagt: “Wat als we dit volgend jaar in Europa nodig hebben?”

Ik gebruik de uitdrukking Think Correct. Think Fast. (denk correct, denk snel). Snelheid komt niet van het overslaan van het denkwerk. Ze komt van genoeg denkwerk vóórdat het moment aanbreekt: je kent de patronen, je kent het platform, je hebt mislukkingen gezien, je weet welke vragen je moet stellen en welke beslissingen moeilijk terug te draaien zijn. Daarom werken we in deze hele cursus met scenario’s. Hoe meer beslissingen je analyseert, hoe sneller je de vorm van de volgende herkent.

Ik had een klant die formulieren moest kunnen invullen. Maar er waren veel formulieren, en de vragen konden in de loop van de tijd veranderen. Ik herkende snel de behoefte aan een datamodel voor enquêtes, een patroon waar we later in de cursus op terugkomen. Omdat ik het patroon en de oplossing herkende, kon ik een completer datamodel inbrengen, een dat ook de eisen aankon die nog moesten komen, niet alleen die van dat moment.

Architectuur gaat over balans

Als we dieper in data-architectuur duiken, kom je keuzes tegen waarbij ik me verzet tegen het geven van een simpele regel. Normaliseren of plat maken? De data kopiëren of federeren? Synchroon of asynchroon? Standaardobject of aangepast? Archiveren of online houden?

Er zijn principes, patronen en limieten, en soms duidelijk verkeerde antwoorden. Maar vaak is de taak van de architect de juiste balans vinden voor dit systeem, dit bedrijf en dit moment.

Weet hoe optimaal eruitziet. Begrijp de beperkingen. Bepaal de haalbare opties. Maak de afwegingen zichtbaar. Neem dan de beslissing.

Dat is geen besluiteloosheid. Dat is architectuur.

Wat een architect hier beslist

• Welke opties haalbaar zijn, en welke nu al verkeerd zijn of over een jaar slecht uitpakken.
• Wat elke haalbare optie oplevert en inlevert, gemeten aan eisen die vragen overleven.
• Welke beperkingen echt zijn en welke alleen voorkeuren.
• Welke optie je aanbeveelt, nadat je de afwegingen op een rij hebt gezet, en hoe je haar uitlegt.