Sådan bygger du systemdesignkatas, der træner ingeniører i at evaluere arkitektoniske afvejninger

Et team designer en billetbookingtjeneste til en regional festival. Den håndterer den forventede belastning komfortabelt, og designgennemgangen slutter med nik. Så ændres det korte: arrangøren lover nu, at billetsalget skal fortsætte med at fungere, selvom ét datacenter går offline i løbet af salgsvinduet. Det samme design har nu et enkelt fejlpunkt, og de ingeniører, der tegnede det, skal beslutte, hvad de skal ændre, hvad de skal opgive, og hvordan de skal forklare valget.

Dette er et illustrativt scenarie, ikke en dokumenteret hændelse. Det er den situation, en systemdesignkata er bygget til at øve: et design, der var fint under ét sæt begrænsninger, møder et nyt, og ingeniører skal forsvare eller revidere det med begrundelser. Denne vejledning er til tekniske støtteledere og ingeniørchefer. Den dækker, hvad en systemdesignkata er, hvordan man bygger en, hvordan man kører og scorer den, og hvor træning ophører med at være svaret. Hver case og hvert kriterium bør valideres af en ledende ingeniør, før du bruger det.

Hvad er en systemdesignkata?

En systemdesignkata er en kort, tidsbegrænset designøvelse. Et lille team modtager et forretningsproblem på et afsnit, skitserer en arkitektur, præsenterer den for kolleger og besvarer vanskelige spørgsmål. Søgere kalder det også en arkitekturkata eller en arkitektonisk kata. Formatet blev startet af Ted Neward som en workshop og er dokumenteret, med sine regler og moderatorrollen, på Neal Fords arkitektoniske kata-sideNewards motiverende spørgsmål, som citeres der, er, hvordan organisationer skal kunne udvikle store arkitekter, når ingeniører får chancen for at være arkitekter færre end et halvt dusin gange i en karriere. En kata giver dem ekstra gentagelser uden produktionsrisiko.

hurtige fakta

1. Beskriv ydeevneproblemet

Start med opgaven, ikke emnet. Opgaven er at forsvare en arkitektur under skiftende begrænsninger. I det virkelige arbejde sker dette i designgennemgange, opfølgninger på hændelser og planlægningsmøder, hvor et krav flytter sig: mere trafik, et strengere tilgængelighedsløfte, en ny regel for dataopbevaring, et strammere budget.

Mange ingeniører kan tegne en fornuftig arkitektur. Færre kan sige, hvad de ville give afkald på, når to mål støder sammen, og hvilke beviser der ville ændre deres mening. Den anden færdighed er den, kata øver.

Skriv en præstationserklæring på én sætning, og få en ingeniørchef til at tjekke den: "Given en arkitektur og en ændret begrænsning navngiver ingeniøren, hvad der går i stykker, foreslår en ændring, angiver afvejningen og siger, hvad de stadig ikke ved."

2. Diagnosticer lærings- og kontekstmanglerne

Før du bygger noget, så sammenlign opgaven med det, dit program praktiserer og vurderer i dag.

1. Bruger praksis den virkelige opgave? Hvis træning lærer mønstre isoleret, og evaluering er en multiple-choice-test, har ingen øvet sig i at forsvare et valg.
2. Hvad er den kognitive efterspørgsel? I Blooms reviderede taksonomi ligger sammenligning af muligheder og begrænsninger i analyse og evaluering, og at foreslå et revideret design når frem til skabelse. Vores guide til Matching af læringsaktiviteter til Blooms taksonomi viser, hvordan aktiviteten kan tilpasses det pågældende niveau.
3. Er der noget andet end færdigheder i vejen? Tjek om ingeniører har tid til at designe, om nogen ejer arkitekturbeslutninger, og om kravene er nedskrevet. Hvis en beslutning træffes af en person uden for teamet, vil ingen kata ændre, hvad teamet kan gøre. Giv disse årsager videre til de personer, der kan løse dem.

3. Designforberedelse og -praksis

Giv hvert trin et specifikt job.

Forberedelse. Tjek forudsætningerne med en kort diagnosticering: det ordforråd, dit team bruger (tilgængelighed, konsistens, latenstid, omkostninger), de byggesten, de forventes at kende, og din egen skabelon til designgennemgang. Selvstudium er egnet til denne fase, og en genkaldelseskontrol bekræfter kun forudsætningerne.

Øve sig. Kør selve kataen. I det format, der er beskrevet på Neal Fords hjemmeside, forløber øvelsen, efter holdet er dannet, i tre faser: en diskussionsfase, hvor holdet finder ud af, hvad det er ved at bygge, en peer review-fase, hvor hvert hold præsenterer og besvarer spørgsmål, og en afstemningsfase, hvor kolleger giver en thumbs up ("nail it"), en thumbs "meh" ("missede et par ting") eller en thumbs down ("missede det, virkelig meget"). Nogle regler er værd at låne direkte: Hold kan lave antagelser om ukendt teknologi, men skal angive dem og må ikke antage, at de kan ansætte et hold af all-stars.

Tilføj den ændrede begrænsning. Standardkataen giver et fast problem. For at træne færdigheden i denne guide, tilføj et andet kort halvvejs igennem: en ændret begrænsning, som holdet skal acceptere. Dette er et designvalg, ikke en del af de oprindelige regler, så afprøv det.

Feedback. Forbind feedback med beslutninger, ikke med en samlet score. "Du flyttede til to regioner, men sagde ikke, hvad der sker med en ordre, der blev afgivet under skiftet" er mere brugbart end "3 ud af 5".

Live input eller asynkron gennemgang? Live facilitering giver mest effekt, når et valg er tvetydigt, og ingeniører lærer af en erfaren kollega, der forklarer, hvorfor de ville holde stand. Asynkron gennemgang er tilstrækkelig til at sammenligne en skriftlig begrundelse med et kommenteret eksempel.

4. Arbejd dig igennem et realistisk eksempel

Illustrativt. En ledende ingeniør bør validere casen og svarkriterierne før brug.

Sagen. En regional festival sælger 20,000 billetter i løbet af en weekend, med det meste salg i de første ti minutter. Den første version af briefingen efterspørger en bookingtjeneste, der kan håndtere denne spidsbelastning. Designet: ét webniveau, én database, et opkald fra en betalingsudbyder ved kassen.

Den ændrede begrænsning. Halvvejs tilføjer arrangøren: salget skal fortsætte, hvis ét datacenter går offline, og ingen billet må sælges to gange.

Et første forsøg. "Tilføj et andet datacenter og replikér databasen." Holdet har brugt en velkendt komponent, men har ikke sagt, hvad der sker med reglen om intet dobbeltsalg, når de to steder ikke kan kommunikere med hinanden.

Feedback og forsøg igen. Facilitatoren beder teamet om at nævne de to mål, der er i spænding, og hvilket de ville beskytte i en netværksopdeling. I genforsøget bedes de vælge og fortælle, hvad kunden oplever.

Et stærkere forsøg. "Vi ville beskytte reglen om ikke at dobbeltsælge billetter. Under en split sælger kun det primære sted billetter, og det andet sted viser en venteside. Vi accepterer lavere tilgængelighed i en kort periode for at undgå at sælge det samme sæde to gange. Vi har antaget, at splitten er sjælden og kort, og vi vil gerne have, at arrangøren bekræfter, at en venteside er acceptabel. Hvis de har brug for, at begge steder sælger, vil vi på forhånd tildele separate sædeblokke til hvert sted på bekostning af nogle usolgte sæder." Bemærk, at dette svar navngiver konflikten, vælger en side, angiver prisen og markerer det, det ikke kender.

Hvorfor hvert svar er forsvarligt eller ufuldstændigt. Bedøm hver enkelt ud fra godkendte kriterier, ikke ud fra en anmelders foretrukne arkitektur. Det første forsøg nævner en komponent, men ingen kompromis. Det stærkeste forsøg er specifikt, angiver sine antagelser og tilbyder et alternativ med sin pris.

5. Vurder kapacitet og planoverførsel

Bevis for evne er præstation på en ny case, som ingeniøren ikke har set. Ræsonnement for afvejning af score og respons på en ny begrænsning. En simpel rubrik bruger en skala fra 0 til 2 pr. kriterium:

Ankre: 0 er fraværende eller ikke understøttet, 1 er delvis med relevante udeladelser, og 2 er fuldstændig og begrundet i forhold til de aftalte kriterier. Definer kritiske fejl separat, såsom at ignorere et angivet sikkerheds- eller databeskyttelseskrav, så en samlet score ikke kan skjule en. Denne rubrik er et forslag, ikke en valideret parathedsstandard: tilpas den med en teknisk leder og afprøv den. Vores guide til design af interaktiv praksis med nyttig feedback dækker, hvordan man skriver feedback, der knytter sig til beslutninger.

Planlæg overførslen bevidst. Efter kataen skal du bede hver ingeniør om at bringe én live designbeslutning til en gennemgang og anvende de samme spørgsmål. En uskyldig gennemgang af en tidligere hændelse er en anden god bro til det rigtige arbejde; se vores guide til kører uskyldige hændelsesvurderinger.

Hvor interaktiv levering hjælper

Interaktive formater hjælper, hvor alle bør forpligte sig, før de ser gruppen. I en live kata-session kan en facilitator vise den ændrede begrænsning, bede hvert teammedlem om at skrive den afvejning, de ville foretage, og hvorfor, og derefter afsløre spredningen, før diskussionen starter. Peer-afstemningen i slutningen af ​​det oprindelige format er nem at køre på samme måde. Den samme case kan køres i eget tempo til forberedelse eller for ingeniører, der går glip af sessionen. AhaSlides understøtter interaktiv læring og skift mellem live og selvstændig levering. Det er et præsentations- og læringsværktøj, ikke et sted at tegne eller køre arkitektur, så opbevar diagrammer på en whiteboard eller i dit designværktøj. Tjek enhver specifik forfatter-, feedback- eller rapporteringsfunktion, du planlægger at stole på, i forhold til din egen arbejdsgang. For vejledning i valg af formater, se vores artikel om Hvornår skal man bruge adaptiv, interaktiv og live læring.

Mål hvad der har ændret sig

Beslut på forhånd, hvad der ville vise, at ingeniører kan forsvare en arkitektur under skiftende begrænsninger. Sammenlign afvejningsræsonnement på et uset tilfælde med en baseline taget før programmet. Definer, hvem der er inkluderet, nævneren og timingen. Hvis resultaterne forbedres, så se på, hvad der ellers har ændret sig i samme periode, såsom en ny skabelon til designgennemgang, en ændring i personale eller en hændelse, der vakte opmærksomhed, før du krediterer træningen.

Begrænsninger, der kan forblive

• Designmyndighed. Hvis holdet ikke træffer beslutningen, har det begrænset effekt at øve den.
• Tid. En kata tager timer; rigtige designs tager uger og involverer data, som en kata ikke kan levere.
• Sagsdækning. Én case kræver et par afvejninger. En score beskriver ikke en ingeniørs vurdering generelt.
• Kompleksitet. Mere kompleksitet er ikke nødvendigvis en bedre arkitektur, så belønn ikke flest komponenter.
• Overførsel. At klare sig godt i en workshop er ikke det samme som at klare sig godt i en anspændt gennemgang, så tjek præstationen efter kataen, i den virkelige setting.

Nævn disse for sponsorerne tidligt og planlæg separate rettelser. En kata forbedrer det, som ingeniører kan forklare og forsvare. Den skaber ikke autoriteten eller tiden.

Ofte stillede spørgsmål

Hvad er en systemdesignkata?

En kort, tidsbegrænset designøvelse, hvor et lille team skitserer en arkitektur til et forretningsproblem, præsenterer den for kolleger og besvarer udfordrende spørgsmål. Det kaldes også en arkitekturkata.

Hvor mange personer skal være i et hold?

Det oprindelige format bruger små grupper på 3 til 5 personer, normalt som en af ​​4 til 10 grupper i et rum. Brug grupper, der er små nok til, at alle kan tale.

Hvordan vurderer man en systemdesign-kata?

Giv en ny case og giv score for afvejningsargumentet og svaret på en ændret begrænsning i forhold til aftalte kriterier. En peer vote er nyttig feedback, men ikke en score i sig selv.

Hvor skal man begynde

Vælg én tilbagevendende designbeslutning i din organisation, og skriv en case på ét afsnit omkring den. Tilføj en ændret begrænsning, få en teknisk leder til at validere casen og svarkriterierne, og udarbejd en rubrik med tre kriterier med en liste over kritiske fejl. Afprøv det med ét team, før du ruller det ud.

For at se, hvordan en kata kan køres live med dit eget hold og genbruges i dit eget tempo bagefter, kan du udforske AhaSlides.