Har du også arvet et sandslot?

Først et lille ønske til arrangørerne: Vil I ikke godt lade være med at finde på temaer som "master-builder", der lægger op til, at foredragsholderene tåger rundt i definitioner af ord som "master-builder", "architect" m.fl. og laver tåbelige, uvedkommende analogier mellem softwareudvikling i dag, og hvordan det var at bygge katedraler i middelalderen? Tak.

Nå, men bortset fra dette indledende rant om Software Architecture-tracket generelt, så vil jeg gerne rose foredragsholderen Eoin Woods for at tage fat i et ganske relevant emne, nemlig hvordan man som softwarearkitekt håndterer legacy-systemer; noget der jo unægteligt er en del af derude.

Woods tog udgangspunkt i en situation, hvor man som softwarearkitekt bliver kastet ind på et projekt, hvor der allerede eksisterer et system og et team, der arbejder på dette, men hvor der er opstået en eller andet problem (f.eks. omkring skalering) - faktisk lod det til, at det i hans erfaring ofte først er når det brænder på, at der bliver kaldt på arkitekt-hjælp. Og dermed er der også sat en alvorlig tidsfaktor på, hvilket begrænset arkitektens handlemuligheder.

I den situation, som Woods beskrev, er arkitektens først opgave derfor at få overblik over systemet. Blandt de teknikker, som Woods anviste er: * At skabe en minimal model af de centrale dele - og for Guds skyld huske at definere hvilken notation, man anvender; et kasse-og-streger-diagram kan læses utroligt forskelligt af forskellige mennesker. * At benytte automatiserede analyseværktøjer til at få overblik over afhængigheder, både mellem komponenter og indenfor hver komponent. * At overvåge og måle; både på produktions-systemet og implementeringen, samt indsamle forskellige stakeholders' meninger om systemet.

Baseret på dette input foretages en vurdering af, hvor de største risici i produktet pt. er, og derefter kan sættes ind med en handlingsplan. Der er strukturerede metoder til dette, som Woods dog ikke kom nærmere ind på i foredraget, men en Google-søgning på "architecture assessment" burde kunne lede i retning af disse.

Han understregede også, hvor vigtigt det er at engagere teamet i processen og sørge for, at de kan se en fremtid for systemet, herunder hvordan den fremtidige arkitektur kommer til at gøre systemet stabilt og forhåbentlig også rart for dem at arbejde videre med.

Hvilke værktøjer, der konkret skal trækkes op af værktøjskassen afhænger naturligvis af hvilke risici, der skal imødegås, men Woods har meget ofte introduceret automatiserede tests (eller flere af dem), refaktorering, indførsel af monitorering og Continuous Integration / Continuous Deployment.

Og så skal man huske at kode lidt som arkitekt, mindede Woods os om... Både for at opbygge en troværdighed overfor udviklerne (der i dette scenarie jo ikke nødvendigvis kendte arkitekten i forvejen), og "for your own sanity" ;-) MEN man skal sørge for ikke at vælge opgaver på den kritiske sti - derved kan man selv blive en kilde til forsinkelser - og man skal også huske at passe sine andre opgaver. Om det er et 50/50 split eller 90/10 mellem arkitektur og kode, ja det fik vi ikke noget one-size-fits-all-svar på fra Woods. Nogle gange bliver man selv nødt til at tænke sig om. Pokkers.