Ett team designar en biljettbokningstjänst för en regional festival. Den hanterar den förväntade belastningen bekvämt, och designgranskningen avslutas med nickningar. Sedan ändras det korta: arrangören lovar nu att biljettförsäljningen måste fortsätta fungera även om ett datacenter går offline under försäljningsfönstret. Samma design har nu en enda felpunkt, och ingenjörerna som ritade den måste bestämma vad som ska ändras, vad som ska ge upp och hur de ska förklara valet.
Detta är ett illustrativt scenario, inte en dokumenterad incident. Det är den situation som en systemdesignkata är byggd för att repetera: en design som fungerade bra under en uppsättning begränsningar möter en ny, och ingenjörer måste försvara eller revidera den med motiveringar. Den här guiden är för tekniska möjliggörande ledare och tekniska chefer. Den behandlar vad en systemdesignkata är, hur man bygger en, hur man kör och poängsätter den, och var utbildning slutar vara lösningen. Varje fall och kriterium bör valideras av en senior ingenjör innan du använder den.
Vad är en systemdesignkata?
En systemdesignkata är en kort, tidsbegränsad designövning. Ett litet team får ett affärsproblem på ett stycke, skissar en arkitektur, presenterar den för kollegor och svarar på svåra frågor. Sökare kallar det också en arkitekturkata eller en arkitektonisk kata. Formatet startades av Ted Neward som en workshop och är dokumenterat, med sina regler och moderatorrollen, på Neal Fords arkitektoniska katassidaNewards motiverande fråga, som citeras där, är hur organisationer förväntas kunna frambringa bra arkitekter när ingenjörer får chansen att arbeta som arkitekter färre än ett halvdussin gånger under en karriär. En kata ger dem extra repetitioner utan produktionsrisk.
Snabb fakta
| Fråga | Kort svar |
|---|---|
| Vad är uppgiften? | Försvara en arkitektur när en begränsning ändras. |
| Hur stor är en grupp? | Det ursprungliga formatet använder små grupper om 3 till 5 personer, med en moderator. |
| Vad får du i poäng? | Avvägningsresonemang och svaret på en ny begränsning, inte det vackraste diagrammet. |
| Räcker det med ett quiz om designmönster? | Nej. Det bekräftar förutsättningarna, men inte om en ingenjör kan motivera ett val under press. |
| Vem bekräftar fallet? | En teknisk chef eller en senior arkitekt. |
| Vad kan en kata inte fixa? | Saknad designauktoritet, oklara krav och ingen tid att designa ordentligt på jobbet. |
| Hur vet du att det fungerade? | Ett nytt, oset fall bedömt enligt överenskomna kriterier, plus uppföljning av verkliga designgranskningar. |
1. Beskriv prestandaproblemet
Börja med uppgiften, inte ämnet. Uppgiften är att försvara en arkitektur under förändrade begränsningar. I verkliga arbeten händer detta i designgranskningar, incidentuppföljningar och planeringsmöten där ett krav flyttas: mer trafik, ett striktare tillgänglighetslöfte, en ny regel för datalagring, en stramare budget.
Många ingenjörer kan rita en förnuftig arkitektur. Färre kan säga vad de skulle göra avkall på när två mål kolliderar och vilka bevis som skulle få dem att ändra sig. Den andra färdigheten är vad kata övar på.
Skriv ett prestandautlåtande på en mening och låt en teknisk chef kontrollera det: "Med tanke på en arkitektur och en ändrad begränsning namnger ingenjören vad som går sönder, föreslår en ändring, anger avvägningen och säger vad de fortfarande inte vet."
2. Diagnostisera inlärnings- och kontextuella luckor
Innan du bygger något, jämför uppgiften med vad ditt program praktiserar och utvärderar idag.
- Använder praktiken den verkliga uppgiften? Om träning lär ut mönster i isolering och bedömning är ett flervalsfrågor, har ingen övat på att försvara ett val.
- Vad är det kognitiva kravet? I Blooms reviderade taxonomi ligger jämförelse av alternativ mot begränsningar i analys och utvärdering, och att föreslå en reviderad design når skapandet. Vår guide till matcha läraktiviteter med Blooms taxonomi visar hur man matchar aktiviteten till den nivån.
- Är något annat än skicklighet i vägen? Kontrollera om ingenjörer har tid att designa, om någon äger arkitekturbeslut och om kraven är nedskrivna. Om ett beslut fattas av någon utanför teamet kommer inga kata att förändra vad teamet kan göra. Skicka dessa orsaker till de personer som kan åtgärda dem.
3. Förberedelser och övning i design
Ge varje steg en specifik uppgift.
Förberedelse. Kontrollera förkunskapskraven med en kort diagnostik: den vokabulär som ditt team använder (tillgänglighet, konsistens, latens, kostnad), de byggstenar de förväntas känna till och din egen mall för designgranskning. Självstudier passar detta steg, och en återkallelsekontroll bekräftar endast förkunskapskraven.
Öva. Kör själva katan. I det format som beskrivs på Neal Fords webbplats, efter att laget har bildats, löper övningen i tre faser: en diskussionsfas där laget utarbetar vad det bygger, en granskningsfas där varje lag presenterar och svarar på frågor, och en omröstningsfas där kollegor ger tummen upp ("prickade i"), en tumme "meh" ("missade några saker") eller en tummen ner ("missade, rejält"). Vissa regler är värda att låna direkt: lag kan göra antaganden om okänd teknologi men måste ange dem, och får inte anta att de kan anställa ett lag med all-stars.
Lägg till ändringsbegränsningen. Standardkatan ger ett fixat problem. För att träna färdigheten i den här guiden, lägg till ett andra kort halvvägs: en ändrad begränsning som laget måste acceptera. Detta är ett designval vi gjort, inte en del av de ursprungliga reglerna, så testa det.
Återkoppling. Koppla feedback till beslut, inte till en totalpoäng. "Du flyttade till två regioner, men sa inte vad som händer med en beställning som gjordes under bytet" är mer användbart än "3 av 5".
Liveinmatning eller asynkron granskning? Live facilitering ger mest effekt när ett val är tvetydigt och ingenjörer lär sig av en senior kollega som förklarar varför de skulle hålla sig till planen. Asynkron granskning räcker för att jämföra en skriftlig motivering med ett kommenterat exempel.
4. Arbeta igenom ett realistiskt exempel
Illustrativt. En senioringenjör bör validera fallet och svarskriterierna före användning.
Fallet. En regional festival säljer 20 000 biljetter under en helg, med mest försäljning under de första tio minuterna. Den första versionen av briefen efterfrågar en bokningstjänst som hanterar den toppen. Designen: en webbnivå, en databas, en betalningsleverantörs samtal i kassan.
Den ändrade begränsningen. Halvvägs tillägger arrangören: försäljningen måste fortsätta om ett datacenter går offline, och ingen biljett får säljas två gånger.
Ett första försök. "Lägg till ett andra datacenter och replikera databasen." Teamet har gripit tag i en välbekant komponent, men har inte sagt vad som händer med regeln om ingen dubbelförsäljning när de två webbplatserna inte kan kommunicera med varandra.
Feedback och försök igen. Handledaren ber teamet att namnge de två mål som står i spänning och vilket de skulle skydda i en nätverksdelning. I det nya försöket ber de att välja och berätta vad kunden upplever.
Ett starkare försök. "Vi skulle skydda regeln om att inga dubbelbiljetter säljs. Under en delning säljer endast den primära platsen biljetter och den andra platsen visar en väntesida. Vi accepterar lägre tillgänglighet under en kort tid för att undvika att sälja samma plats två gånger. Vi har antagit att delning är sällsynt och kort, och vi vill att arrangören bekräftar att en väntesida är acceptabel. Om de behöver att båda platserna säljer, skulle vi i förväg tilldela separata sittplatsblock till varje plats, på kostnaden för några osålda platser." Observera att detta svar namnger konflikten, väljer en sida, anger kostnaden och flaggar det som inte är känt.
Varför varje svar är försvarbart eller ofullständigt. Bedöm varje försök mot godkända kriterier, inte mot en granskares föredragna arkitektur. Det första försöket namnger en komponent men ingen avvägning. Det starkare försöket är specifikt, anger sina antaganden och erbjuder ett alternativ med sitt pris.
5. Bedöm kapacitet och planöverföring
Bevis på förmåga är prestanda i ett nytt fall som ingenjören inte har sett. Resonemang kring poängavvägning och svaret på en ny begränsning. En enkel matris använder en skala från 0 till 2 per kriterium:
| Kriterium | Observerbara bevis |
|---|---|
| Uppgiftskörning | Försvarar arkitekturen under den ändrade begränsningen och dokumenterar bevisen bakom beslutet. |
| Resonemang | Förklarar de relevanta begränsningarna, de alternativ som övervägts och vad som fortfarande är osäkert. |
| Gränser | Följer godkända designprocedurer och ber om hjälp när information eller behörighet saknas. |
Ankare: 0 är frånvarande eller saknar stöd, 1 är ofullständig med relevanta utelämnanden och 2 är fullständig och motiverad mot de överenskomna kriterierna. Definiera kritiska fel separat, såsom att ignorera ett angivet säkerhets- eller dataskyddskrav, så att en totalpoäng inte kan dölja ett sådant. Denna bedömningsmatris är ett förslag, inte en validerad beredskapsstandard: anpassa den med en teknisk chef och testa den. Vår guide till utforma interaktiv praktik med användbar feedback behandlar hur man skriver feedback som kopplar till beslut.
Planera överföringen medvetet. Efter katan, be varje ingenjör att ta med ett verkligt designbeslut till en granskning och ställ samma frågor. En oskyldig granskning av en tidigare incident är en annan bra brygga till verkligt arbete; se vår guide till köra oskyldiga incidentgranskningar.
Där interaktiv leverans hjälper
Interaktiva format hjälper till där alla bör förbinda sig innan de ser gruppen. I en live-kata-session kan en handledare visa den ändrade begränsningen, be varje teammedlem att skriva in den avvägning de skulle göra och varför, och sedan avslöja spridningen innan diskussionen börjar. Kamratröstningen i slutet av det ursprungliga formatet är enkel att köra på samma sätt. Samma fall kan köras i självstudier för förberedelser eller för ingenjörer som missar sessionen. AhaSlides stöder interaktivt lärande och växling mellan live- och självstudier. Det är ett presentations- och inlärningsverktyg, inte en plats att rita eller köra arkitektur, så förvara diagram på en whiteboard eller i ditt designverktyg. Kontrollera eventuella specifika redigerings-, feedback- eller rapporteringsfunktioner som du planerar att förlita dig på mot ditt eget arbetsflöde. För vägledning om val av format, se vår artikel om när man ska använda adaptiv, interaktiv och liveinlärning.
Mät vad som förändrats
Bestäm i förväg vad som skulle visa att ingenjörer kan försvara en arkitektur under förändrade begränsningar. Jämför avvägningsresonemang i ett osedd fall med en baslinje som tagits före programmet. Definiera vem som ingår, nämnaren och tidpunkten. Om resultaten förbättras, titta på vad mer som förändrats under samma period, såsom en ny mall för designgranskning, en personalförändring eller en incident som väckte uppmärksamhet, innan utbildningen tillgodoräknas.
Begränsningar som kan finnas kvar
- Designauktoritet. Om laget inte fattar beslutet har det begränsad effekt att öva på det.
- Tid. En kata tar timmar; riktiga designer tar veckor och involverar data som en kata inte kan tillhandahålla.
- Falltäckning. Ett fall kräver några avvägningar. En poäng beskriver inte en ingenjörs bedömning i allmänhet.
- Komplexitet. Mer komplexitet är inte nödvändigtvis en bättre arkitektur, så belöna inte flest komponenter.
- Överföra. Att göra bra ifrån sig på en workshop är inte samma sak som att göra bra ifrån sig under en spänd repetition, så kontrollera prestationen efter katan, i den verkliga miljön.
Nämn dessa för sponsorer tidigt och planera separata korrigeringar. En kata förbättrar vad ingenjörer kan förklara och försvara. Den skapar inte auktoriteten eller tiden.
Vanliga frågor och svar
Vad är en systemdesignkata?
En kort, tidsbegränsad designövning där ett litet team skissar en arkitektur för ett affärsproblem, presenterar den för kollegor och besvarar utmanande frågor. Det kallas också en arkitekturkata.
Hur många personer ska vara i ett team?
Det ursprungliga formatet använder små grupper om 3 till 5 personer, vanligtvis som en av 4 till 10 grupper i ett rum. Använd grupper som är tillräckligt små så att alla kan tala.
Hur bedömer man en systemdesignkata?
Ge ett nytt fall och poängsätt avvägningsresonemang och svaret på en ändrad begränsning mot överenskomna kriterier. En kamratröst är användbar feedback men inte en poäng i sig.
Var ska man börja
Välj ett återkommande designbeslut i din organisation och skriv ett fallstudie på ett stycke kring det. Lägg till en ändrad begränsning, låt en teknisk chef validera fallstudien och svarskriterierna och utarbeta en matris med tre kriterier med en lista över kritiska fel. Testa det med ett team innan du lanserar det.
För att se hur en kata kan köras live med ditt eget lag, och återanvändas i ditt eget tempo efteråt, utforska AhaSlides.
