Hvordan bygge systemdesignkatas som trener ingeniører til å evaluere arkitektoniske avveininger

Et team designer en billettbestillingstjeneste for en regional festival. Den håndterer den forventede belastningen komfortabelt, og designgjennomgangen avsluttes med nikk. Så endres det korte: arrangøren lover nå at billettsalget må fortsette å fungere selv om ett datasenter går offline i løpet av salgsvinduet. Det samme designet har nå et enkelt feilpunkt, og ingeniørene som tegnet det må bestemme hva de skal endre, hva de skal gi opp og hvordan de skal forklare valget.

Dette er et illustrerende scenario, ikke en dokumentert hendelse. Det er situasjonen en systemdesignkata er bygget for å øve på: en design som var fin under ett sett med begrensninger møter en ny, og ingeniører må forsvare eller revidere den med begrunnelser. Denne veiledningen er for ledere for tekniske muligheter og ingeniørledere. Den dekker hva en systemdesignkata er, hvordan man bygger en, hvordan man kjører og scorer den, og hvor trening slutter å være svaret. Hvert tilfelle og kriterium bør valideres av en senioringeniør før du bruker det.

Hva er en systemdesignkata?

En systemdesignkata er en kort, tidsbegrenset designøvelse. Et lite team mottar et forretningsproblem på ett avsnitt, skisserer en arkitektur, presenterer den for kolleger og svarer på vanskelige spørsmål. Søkere kaller det også en arkitekturkata eller en arkitektonisk kata. Formatet ble startet av Ted Neward som en workshop og er dokumentert, med sine regler og moderatorrollen, på Neal Fords arkitektoniske kata-sideNewards motiverende spørsmål, sitert der, er hvordan organisasjoner skal kunne utvikle gode arkitekter når ingeniører får sjansen til å være arkitekt færre enn et halvt dusin ganger i løpet av en karriere. En kata gir dem ekstra repetisjoner uten produksjonsrisiko.

Kjappe fakta

1. Beskriv ytelsesproblemet

Start med oppgaven, ikke emnet. Oppgaven er å forsvare en arkitektur under endrede begrensninger. I det virkelige arbeidet skjer dette i designgjennomganger, hendelsesoppfølginger og planleggingsmøter der et krav flytter seg: mer trafikk, et strengere tilgjengelighetsløfte, en ny regel for dataopphold, et strammere budsjett.

Mange ingeniører kan tegne en fornuftig arkitektur. Færre kan si hva de ville gitt avkall på når to mål kolliderer, og hvilke bevis som ville få dem til å ombestemme seg. Den andre ferdigheten er det kata praktiserer.

Skriv en ytelseserklæring på én setning og få en ingeniørleder til å sjekke den: «Gitt en arkitektur og en endret begrensning, navngir ingeniøren hva som går i stykker, foreslår en endring, angir avveiningen og sier hva de fortsatt ikke vet.»

2. Diagnostiser lærings- og konteksthullene

Før du bygger noe som helst, sammenlign oppgaven med det programmet ditt praktiserer og vurderer i dag.

1. Bruker praksis den virkelige oppgaven? Hvis opplæring lærer bort mønstre isolert og vurdering er en flervalgstest, har ingen øvd på å forsvare et valg.
2. Hva er den kognitive etterspørselen? I Blooms reviderte taksonomi ligger sammenligning av alternativer mot begrensninger i analyse og evaluering, og å foreslå et revidert design når frem til å skape. Vår guide til matche læringsaktiviteter med Blooms taksonomi viser hvordan man kan tilpasse aktiviteten til det nivået.
3. Er det noe annet enn ferdigheter som står i veien? Sjekk om ingeniører har tid til å designe, om noen eier arkitekturbeslutninger og om kravene er skrevet ned. Hvis en beslutning tas av noen utenfor teamet, vil ingen kata endre hva teamet kan gjøre. Overfør disse årsakene til de som kan fikse dem.

3. Designforberedelse og praksis

Gi hvert trinn en distinkt oppgave.

Forberedelse. Sjekk forkunnskapene med en kort diagnostikk: vokabularet teamet ditt bruker (tilgjengelighet, konsistens, latens, kostnad), byggeklossene de forventes å kjenne til, og din egen mal for designgjennomgang. Selvstudium passer til dette stadiet, og en gjentakelsessjekk bekrefter kun forkunnskapene.

Øve på. Kjør selve kataen. I formatet beskrevet på Neal Fords nettsted, etter at laget er dannet, går øvelsen i tre faser: en diskusjonsfase der laget jobber med hva det bygger, en fagfellevurderingsfase der hvert lag presenterer og svarer på spørsmål, og en avstemningsfase der fagfeller gir tommelen opp («pailed it»), tommelen «meh» («bommet på et par ting») eller tommelen ned («bommet på, veldig mye»). Noen regler er verdt å låne direkte: lag kan gjøre antagelser om ukjent teknologi, men må oppgi dem, og kan ikke anta at de kan ansette et lag med all-stars.

Legg til endringsbegrensningen. Standardkataen gir et løst problem. For å trene ferdigheten i denne veiledningen, legg til et nytt kort halvveis: en endret begrensning laget må absorbere. Dette er et designvalg vi har valgt, ikke en del av de opprinnelige reglene, så prøv det ut.

Feedback. Koble tilbakemeldinger til avgjørelser, ikke til en totalpoengsum. «Du flyttet til to regioner, men sa ikke hva som skjer med en bestilling som ble lagt inn under byttet» er mer nyttig enn «3 av 5».

Live input eller asynkron gjennomgang? Direkte tilrettelegging gir mest effekt når et valg er tvetydig, og ingeniører lærer av en seniorkollega som forklarer hvorfor de ville holde stand. Asynkron gjennomgang er nok for å sammenligne en skriftlig begrunnelse med et kommentert eksempel.

4. Arbeid deg gjennom et realistisk eksempel

Illustrativt. En senioringeniør bør validere tilfellet og svarkriteriene før bruk.

Saken. En regional festival selger 20 000 billetter i løpet av en helg, med mest salg i løpet av de første ti minuttene. Den første versjonen av briefen ber om en bookingtjeneste som takler denne toppen. Designet: ett nettnivå, én database, en betalingsleverandørs oppringning ved kassen.

Den endrede begrensningen. Halvveis legger arrangøren til: salget må fortsette dersom ett datasenter går offline, og ingen billett kan selges to ganger.

Et første forsøk. «Legg til et andre datasenter og repliker databasen.» Teamet har brukt en kjent komponent, men har ikke sagt hva som skjer med regelen om ikke dobbelt salg når de to nettstedene ikke kan kommunisere med hverandre.

Tilbakemelding og prøv på nytt. Tilretteleggeren ber teamet om å navngi de to målene som står i spenning, og hvilket de ville beskytte i en nettverksdeling. I det nye forsøket blir de bedt om å velge og si hva kunden opplever.

Et sterkere forsøk. «Vi ville beskytte regelen om ikke dobbelt salg. Under en deling av billetter selger bare hovedstedet billetter, og det andre stedet viser en venteside. Vi aksepterer lavere tilgjengelighet i en kort periode for å unngå å selge samme sete to ganger. Vi har antatt at deling av billetter er sjelden og kort, og vi ønsker at arrangøren skal bekrefte at en venteside er akseptabel. Hvis de trenger at begge stedene selger, vil vi tildele separate seteblokker til hvert sted på forhånd, på bekostning av noen usolgte seter.» Legg merke til at dette svaret navngir konflikten, velger en side, oppgir kostnaden og flagger det det ikke vet.

Hvorfor hvert svar er forsvarlig eller ufullstendig. Bedøm hver av dem mot godkjente kriterier, ikke mot en anmelders foretrukne arkitektur. Det første forsøket navngir en komponent, men ingen avveininger. Det sterkeste forsøket er spesifikt, angir sine antagelser og tilbyr et alternativ med prisen.

5. Vurder kapasitet og planoverføring

Bevis på evne er ytelse på en ny sak ingeniøren ikke har sett. Avveiningsresonnement for poengsum og responsen på en ny begrensning. En enkel rubrikk bruker en skala fra 0 til 2 per kriterium:

Ankere: 0 er fraværende eller ikke støttet, 1 er delvis med relevante utelatelser, og 2 er fullstendig og begrunnet mot de avtalte kriteriene. Definer kritiske feil separat, for eksempel å ignorere et oppgitt sikkerhets- eller databeskyttelseskrav, slik at en samlet poengsum ikke kan skjule en. Denne rubrikken er et forslag, ikke en validert beredskapsstandard: tilpass den med en ingeniørleder og test den. Vår veiledning til utforme interaktiv praksis med nyttig tilbakemelding dekker hvordan man skriver tilbakemeldinger som er knyttet til beslutninger.

Planlegg overføringen bevisst. Etter kataen, be hver ingeniør om å ta med én designbeslutning i sanntid til en gjennomgang og bruk de samme spørsmålene. En uskyldig gjennomgang av en tidligere hendelse er en annen god bro til virkelig arbeid; se vår veiledning til kjører uskyldige hendelsesvurderinger.

Der interaktiv levering hjelper

Interaktive formater hjelper der alle bør forplikte seg før de ser gruppen. I en live kata-økt kan en tilrettelegger vise den endrede begrensningen, be hvert teammedlem skrive inn avveiningen de ville gjort og hvorfor, og deretter avsløre spredningen før diskusjonen starter. Fagfelleavstemningen på slutten av det opprinnelige formatet er enkel å kjøre på samme måte. Den samme saken kan kjøres i eget tempo for forberedelse eller for ingeniører som går glipp av økten. AhaSlides støtter interaktiv læring og bevegelse mellom live og selvstendig levering. Det er et presentasjons- og læringsverktøy, ikke et sted å tegne eller kjøre arkitektur, så hold diagrammer på en tavle eller i designverktøyet ditt. Sjekk eventuelle spesifikke redigerings-, tilbakemeldings- eller rapporteringsfunksjoner du planlegger å stole på mot din egen arbeidsflyt. For veiledning om valg av formater, se artikkelen vår om når man skal bruke adaptiv, interaktiv og live læring.

Mål hva som endret seg

Bestem på forhånd hva som viser at ingeniører kan forsvare en arkitektur under endrede begrensninger. Sammenlign avveiningsresonnement på et usett tilfelle med en baseline tatt før programmet. Definer hvem som er inkludert, nevneren og tidspunktet. Hvis resultatene forbedres, se på hva annet som har endret seg i samme periode, for eksempel en ny mal for designgjennomgang, en bemanningsendring eller en hendelse som vekket oppmerksomhet, før du gir godskriving for opplæringen.

Begrensninger som kan gjenstå

• Designmyndighet. Hvis ikke teamet tar avgjørelsen, har det begrenset effekt å øve på den.
• Tid. En kata tar timer; ekte design tar uker og involverer data en kata ikke kan gi.
• Saksdekning. Én sak innebærer noen få avveininger. En poengsum beskriver ikke en ingeniørs vurdering generelt.
• Kompleksitet. Mer kompleksitet er ikke nødvendigvis en bedre arkitektur, så ikke belønn flest komponenter.
• Overføre. Å gjøre det bra på en workshop er ikke det samme som å gjøre det bra i en anspent gjennomgang, så sjekk prestasjonen etter kataen, i den virkelige settingen.

Navngi disse til sponsorer tidlig og planlegg separate rettelser. En kata forbedrer det ingeniører kan forklare og forsvare. Den skaper ikke autoriteten eller tiden.

Ofte stilte spørsmål

Hva er en systemdesignkata?

En kort, tidsbegrenset designøvelse der et lite team skisserer en arkitektur for et forretningsproblem, presenterer den for kolleger og svarer på utfordrende spørsmål. Det kalles også en arkitekturkata.

Hvor mange personer bør være i et lag?

Det opprinnelige formatet bruker små grupper på 3 til 5 personer, vanligvis som én av 4 til 10 grupper i et rom. Bruk grupper som er små nok til at alle kan snakke.

Hvordan vurderer du en systemdesignkata?

Gi et nytt tilfelle og gi poeng for avveiningsresonnementet og responsen på en endret begrensning mot avtalte kriterier. En fagfelleavstemning er nyttig tilbakemelding, men ikke en poengsum i seg selv.

Hvor skal jeg starte

Velg én tilbakevendende designbeslutning i organisasjonen din og skriv et case-eksemplar på ett avsnitt rundt den. Legg til en endret begrensning, få en ingeniørsjef til å validere case-eksemplet og svarkriteriene, og utarbeid en rubrikk med tre kriterier med en liste over kritiske feil. Test det med ett team før du ruller det ut.

For å se hvordan en kata kan kjøres live med ditt eget lag, og brukes om igjen i ditt eget tempo etterpå, kan du utforske AhaSlides.