Een team ontwerpt een ticketverkoopsysteem voor een regionaal festival. Het systeem kan de verwachte belasting probleemloos aan en de ontwerpbeoordeling wordt positief afgerond. Dan verandert de opdracht: de organisator belooft nu dat de kaartverkoop moet blijven functioneren, zelfs als een datacenter uitvalt tijdens de verkoopperiode. Hetzelfde ontwerp heeft nu een single point of failure en de ingenieurs die het hebben getekend, moeten beslissen wat ze moeten veranderen, wat ze moeten opgeven en hoe ze die keuze moeten toelichten.
Dit is een illustratief scenario, geen gedocumenteerd incident. Het is de situatie die een systeemontwerp-kata beoogt te simuleren: een ontwerp dat onder bepaalde voorwaarden prima was, stuit op nieuwe beperkingen, en engineers moeten het ontwerp verdedigen of herzien met onderbouwing. Deze handleiding is bedoeld voor engineering enablement leads en engineering managers. Het behandelt wat een systeemontwerp-kata is, hoe je er een bouwt, hoe je deze uitvoert en beoordeelt, en wanneer training niet langer de oplossing is. Elk geval en criterium moet door een senior engineer worden gevalideerd voordat je het gebruikt.
Wat is een systeemontwerp-kata?
Een systeemontwerp-kata is een korte, tijdgebonden ontwerpoefening. Een klein team ontvangt een bedrijfsprobleem van één alinea, schetst een architectuur, presenteert deze aan collega's en beantwoordt lastige vragen. Onderzoekers noemen het ook wel een architectuurkata of architecturale kata. Het format is bedacht door Ted Neward als workshop en is, inclusief de regels en de rol van de moderator, gedocumenteerd op [websiteadres]. De architecturale kata'spagina van Neal FordDe motiverende vraag van Neward, die daar wordt geciteerd, is hoe organisaties geweldige architecten moeten opleiden als ingenieurs in hun carrière minder dan zes keer de kans krijgen om te ontwerpen. Een kata biedt hen extra herhalingen zonder risico voor de productie.
Faktenüberblick
| Vraag | Kort antwoord |
|---|---|
| Wat is de taak? | Verdedig een architectuur wanneer een beperking verandert. |
| Hoe groot is een groep? | De oorspronkelijke opzet maakt gebruik van kleine groepen van 3 tot 5 personen, onder leiding van een moderator. |
| Wat is je score? | Een afwegingsredenering en de reactie op een nieuwe beperking, niet bepaald een fraai diagram. |
| Is een quiz over ontwerppatronen voldoende? | Nee. Het bevestigt de randvoorwaarden, maar niet of een ingenieur een keuze onder druk kan verantwoorden. |
| Wie bevestigt de juistheid van de zaak? | Een engineeringmanager of een senior architect. |
| Wat kan een kata níét oplossen? | Gebrek aan ontwerpbevoegdheid, onduidelijke eisen en geen tijd om op het werk goed te ontwerpen. |
| Hoe weet je dat het gelukt is? | Een nieuwe, nog niet eerder vertoonde casus beoordeeld aan de hand van overeengekomen criteria, plus een vervolgonderzoek naar daadwerkelijke ontwerpbeoordelingen. |
1. Beschrijf het prestatieprobleem
Begin bij de taak, niet bij het onderwerp. De taak is om een architectuur te verdedigen onder veranderende omstandigheden. In de praktijk gebeurt dit tijdens ontwerpbeoordelingen, incidentafhandeling en planningsvergaderingen, waar een vereiste verandert: meer verkeer, een strengere beschikbaarheidsgarantie, een nieuwe regel voor dataopslag, een krapper budget.
Veel ingenieurs kunnen een logische architectuur ontwerpen. Minder ingenieurs kunnen echter aangeven wat ze zouden opofferen als twee doelen botsen en welk bewijs hen van gedachten zou doen veranderen. Die tweede vaardigheid wordt in de kata geoefend.
Schrijf een prestatieomschrijving van één zin en laat deze door een engineeringmanager controleren: "Gegeven een architectuur en een gewijzigde beperking, benoemt de engineer wat er misgaat, stelt een wijziging voor, beschrijft de afweging en geeft aan wat er nog niet bekend is."
2. Stel de leer- en contexthiaten vast.
Vergelijk, voordat je iets bouwt, de taak met wat er momenteel binnen je programma wordt geoefend en beoordeeld.
- Wordt er tijdens de oefening gebruikgemaakt van de daadwerkelijke taak? Als training patronen geïsoleerd aanleert en beoordeling een meerkeuzetoets is, heeft niemand geoefend met het verdedigen van een keuze.
- Wat is de cognitieve belasting? In de herziene taxonomie van Bloom valt het vergelijken van opties met beperkingen onder de categorieën analyseren en evalueren, terwijl het voorstellen van een herzien ontwerp onder de categorie creëren valt. Onze gids voor Leeractiviteiten afstemmen op de taxonomie van Bloom. laat zien hoe de activiteit op dat niveau kan worden afgestemd.
- Is er naast vaardigheid nog iets anders dat in de weg staat? Controleer of de engineers tijd hebben om te ontwerpen, of er iemand verantwoordelijk is voor architectuurbeslissingen en of de eisen zijn vastgelegd. Als een beslissing door iemand buiten het team wordt genomen, zal geen enkele oefening (kata) veranderen wat het team kan doen. Geef die oorzaken door aan de mensen die ze kunnen oplossen.
3. Ontwerpvoorbereiding en -oefening
Wijs aan elke fase een specifieke taak toe.
Voorbereiding. Controleer de vereisten met een korte diagnose: de terminologie die uw team gebruikt (beschikbaarheid, consistentie, latentie, kosten), de bouwstenen die ze moeten kennen en uw eigen sjabloon voor ontwerpbeoordelingen. Zelfstudie is geschikt voor deze fase, en een geheugentest bevestigt alleen de vereisten.
Praktijk. Voer de kata zelf uit. In het format zoals beschreven op de website van Neal Ford, verloopt de oefening, nadat de teams zijn gevormd, in drie fasen: een discussiefase waarin het team bepaalt wat het gaat bouwen, een peer review-fase waarin elk team zijn/haar werk presenteert en vragen beantwoordt, en een stemfase waarin de teamleden een duim omhoog ("perfect"), een duim "meh" ("een paar dingen gemist") of een duim omlaag ("helemaal mis") geven. Sommige regels zijn het waard om direct over te nemen: teams mogen aannames doen over onbekende technologie, maar moeten deze wel vermelden, en mogen er niet van uitgaan dat ze een team van topmensen kunnen inhuren.
Voeg de veranderende beperking toe. De standaard kata biedt een vast probleem. Om de vaardigheid in deze handleiding te trainen, voeg je halverwege een tweede kaart toe: een gewijzigde beperking die het team moet accepteren. Dit is een ontwerpkeuze van ons, geen onderdeel van de oorspronkelijke regels, dus experimenteer ermee.
Feedback. Koppel feedback aan beslissingen, niet aan een totaalscore. "U bent naar twee regio's verhuisd, maar u hebt niet aangegeven wat er met een bestelling gebeurt tijdens de overstap" is nuttiger dan "3 van de 5".
Live input of asynchrone beoordeling? Live begeleiding is vooral waardevol wanneer een keuze onduidelijk is en engineers leren van een senior collega die uitlegt waarom ze voor een bepaald standpunt zouden kiezen. Asynchrone beoordeling is voldoende om een schriftelijke onderbouwing te vergelijken met een voorbeeld met annotaties.
4. Werk een realistisch voorbeeld uit.
Ter illustratie. Een senior engineer dient de casus en de antwoordcriteria te valideren alvorens deze te gebruiken.
De zaak. Een regionaal festival verkoopt 20,000 tickets in een weekend, waarvan de meeste in de eerste tien minuten. De eerste versie van de briefing vraagt om een boekingssysteem dat deze piek aankan. Het ontwerp: één webinterface, één database en een aanroep naar de betalingsprovider bij het afrekenen.
De gewijzigde beperking. Halverwege voegt de organisator eraan toe: de verkoop moet doorgaan als een datacenter uitvalt, en er mogen geen tickets twee keer worden verkocht.
Een eerste poging. "Voeg een tweede datacenter toe en repliceer de database." Het team heeft een bekende oplossing gekozen, maar heeft niet aangegeven wat er gebeurt met de regel dat er geen dubbele verkoop mag plaatsvinden wanneer de twee locaties niet met elkaar kunnen communiceren.
Feedback en opnieuw proberen. De facilitator vraagt het team om de twee conflicterende doelen te benoemen en aan te geven welk doel ze zouden beschermen bij een netwerksplitsing. Bij de herkansing wordt hen gevraagd een keuze te maken en uit te leggen wat de klant ervaart.
Een serieuzere poging. "We zouden de regel tegen dubbele verkoop handhaven. Tijdens een splitsing verkoopt alleen de primaire site tickets en toont de andere site een wachtpagina. We accepteren een lagere beschikbaarheid voor een korte periode om te voorkomen dat dezelfde stoel twee keer wordt verkocht. We gaan ervan uit dat de splitsing zeldzaam en van korte duur is, en we willen dat de organisator bevestigt dat een wachtpagina acceptabel is. Als ze willen dat beide sites verkopen, zouden we van tevoren aparte stoelblokken aan elke site toewijzen, ten koste van een aantal onverkochte stoelen." Merk op dat dit antwoord het conflict benoemt, een kant kiest, de kosten aangeeft en aangeeft wat het niet weet.
Waarom elk antwoord verdedigbaar of onvolledig is. Beoordeel elk voorstel aan de hand van goedgekeurde criteria, niet aan de hand van de door de reviewer geprefereerde architectuur. De eerste poging benoemt een component, maar geeft geen afweging. De sterkere poging is specifiek, vermeldt de aannames en biedt een alternatief met de bijbehorende prijs.
5. Beoordeel de capaciteit en plan de overdracht.
Bewijs van bekwaamheid blijkt uit de prestaties op een nieuwe casus die de ingenieur nog niet eerder heeft gezien. Beoordeel het afwegen van factoren en de reactie op een nieuwe beperking. Een eenvoudige beoordelingsschaal gebruikt een score van 0 tot 2 per criterium:
| Criterium | Observeerbaar bewijs |
|---|---|
| Taakuitvoering | Verdedigt de architectuur onder de gewijzigde beperkingen en documenteert het bewijsmateriaal dat aan de beslissing ten grondslag ligt. |
| Redenering | Hierin worden de relevante beperkingen, de overwogen alternatieven en de nog onzekere aspecten toegelicht. |
| Grenzen | Volgt de goedgekeurde ontwerpprocedures en vraagt om hulp wanneer informatie of bevoegdheid ontbreekt. |
Ankers: 0 is afwezig of niet onderbouwd, 1 is gedeeltelijk met relevante weglatingen en 2 is volledig en gerechtvaardigd op basis van de overeengekomen criteria. Definieer kritieke fouten afzonderlijk, zoals het negeren van een gestelde veiligheids- of gegevensbeschermingseis, zodat een algemene score er geen kan verbergen. Deze rubric is een voorstel, geen gevalideerde gereedheidsnorm: pas deze aan met een engineeringmanager en test deze in een pilotproject. Onze handleiding voor Interactieve oefeningen ontwerpen met nuttige feedback Dit artikel behandelt hoe je feedback schrijft die aansluit op beslissingen.
Plan de overdracht bewust. Vraag na de kata elke engineer om een concrete ontwerpbeslissing ter beoordeling voor te leggen en dezelfde vragen te stellen. Een objectieve beoordeling van een incident uit het verleden is ook een goede brug naar de praktijk; zie onze handleiding voor meer informatie. het uitvoeren van incidentbeoordelingen zonder schuldbeschuldiging.
Waar interactieve levering helpt
Interactieve formats zijn handig wanneer iedereen zich van tevoren vastlegt voordat ze de groep zien. In een live kata-sessie kan een facilitator de gewijzigde beperking tonen, elk teamlid vragen om de afweging die ze zouden maken en de redenen daarvoor te typen, en vervolgens de spreiding onthullen voordat de discussie begint. De peer-stemming aan het einde van het oorspronkelijke format is eenvoudig op dezelfde manier uit te voeren. Dezelfde casus kan ook in eigen tempo worden doorlopen ter voorbereiding of voor engineers die de sessie missen. AhaSlides ondersteunt interactief leren en de overgang tussen live en zelfstudie. Het is een presentatie- en leertool, geen plek om te tekenen of architectuur uit te voeren, dus houd diagrammen op een whiteboard of in je ontwerptool. Controleer of de specifieke auteurs-, feedback- of rapportagefuncties die je wilt gebruiken, aansluiten bij je eigen workflow. Zie ons artikel over het kiezen van formats voor meer informatie. Wanneer moet je adaptief, interactief en live leren inzetten?.
Meet wat er veranderd is
Bepaal van tevoren wat zou aantonen dat ingenieurs een architectuur kunnen verdedigen onder veranderende omstandigheden. Vergelijk de afwegingen in een onbekende casus met een basislijn die vóór het programma is vastgesteld. Definieer wie erbij betrokken is, de noemer en de timing. Als de resultaten verbeteren, kijk dan naar andere veranderingen in dezelfde periode, zoals een nieuw sjabloon voor ontwerpbeoordelingen, een personeelswijziging of een incident dat de aandacht trok, voordat de training als oorzaak wordt aangewezen.
Mogelijke beperkingen die kunnen blijven bestaan
- Ontwerpexpertise. Als het team de beslissing niet zelf neemt, heeft het oefenen ervan weinig effect.
- Time. Een kata duurt uren; echte ontwerpen vergen weken en vereisen gegevens die een kata niet kan leveren.
- Dekking van de zaak. In één geval moeten een aantal afwegingen worden gemaakt. Een score geeft geen algemeen beeld van het oordeel van een ingenieur.
- Complexiteit. Meer complexiteit betekent niet per se een betere architectuur, dus beloon niet de architectuur met de meeste componenten.
- Transfer. Goed presteren tijdens een workshop is niet hetzelfde als goed presteren tijdens een spannende evaluatie. Controleer daarom de prestatie na de kata, in de echte situatie.
Benoem deze problemen vroegtijdig aan de sponsors en plan afzonderlijke oplossingen. Een kata verbetert wat engineers kunnen uitleggen en verdedigen. Het creëert geen autoriteit of tijd.
Veelgestelde vragen
Wat is een systeemontwerp-kata?
Een korte, tijdgebonden ontwerpoefening waarbij een klein team een architectuur schetst voor een zakelijk probleem, deze presenteert aan collega's en uitdagende vragen beantwoordt. Dit wordt ook wel een architectuurkata genoemd.
Hoeveel mensen moeten er in een team zitten?
De oorspronkelijke opzet maakt gebruik van kleine groepjes van 3 tot 5 personen, meestal als één van de 4 tot 10 groepjes in een ruimte. Gebruik groepjes die klein genoeg zijn zodat iedereen aan het woord komt.
Hoe beoordeel je een systeemontwerp-kata?
Geef een nieuwe casus en beoordeel de afwegingsredenering en de reactie op een gewijzigde beperking aan de hand van overeengekomen criteria. Een collegiale stemming is nuttige feedback, maar op zichzelf geen score.
Waar te beginnen
Kies een terugkerende ontwerpbeslissing binnen uw organisatie en schrijf daar een korte casusbeschrijving van één alinea over. Voeg een gewijzigde beperking toe, laat een engineeringmanager de casus en de antwoordcriteria valideren en stel een beoordelingsschema met drie criteria op, inclusief een lijst met kritieke fouten. Test het eerst met één team voordat u het implementeert.
Om te zien hoe een kata live met je eigen team kan worden uitgevoerd en daarna in je eigen tempo opnieuw kan worden gebruikt, kun je AhaSlides bekijken.
