Hva er programvarearkitektur og hvem lager den?
Metaforen arkitektur innen utvikling av programvare er like passende som den er feilslått. Den er diskutert opp og ned i mente i mange tiår nå uten at jeg føler vi har falt ned på en klar og konsis definisjon av hva det faktisk er. Så i all ydmykhet skal jeg prøve meg på en, og si noe om hvem som har ansvaret for at et system får den beste arkitekturen.
Den gang da
Opp gjennom min nå nokså lange tid innen programvareutvikling har jeg hatt mange oppfatninger og forventninger om hva som menes når ordet arkitektur blir nevnt. I starten, den gang vi bedrev planlegging og design av programvaren ned til minste detalj før en linje kode ble skrevet, var arkitektene og deres produkt noe opphøyet og fjernt fra selve implementasjonen. Når arkitekturen var klar kunne man lage nøyaktige estimater og bli enig om en pris på programvaren som skulle lages. Som utvikler stilte man ikke spørsmål ved arkitekturen, men man lærte kjapt nok å ignorere den. For, som vi nå nesten alle har lært, så er det som oftest utrolig vanskelig å forutse alle krav og løsninger før man begynner å lage systemet. Likevel var ikke arkitektur noe vi programmerere trodde vi holdt på med. Inntrykket om at dette var noe som andre bedrev satte seg.
Etter hvert som erfaringen kom snikende kom også ideen om at arkitektur var noe man likevel tenkte en del på og følte man burde ha en stemme i. Så jeg søkte meg mot konferanseforedrag og kurs med arkitektur i tittel og sammendrag. Spennet i tema var svært overraskende. Fra organisasjon og planlegging av store utviklingsprosjekter med mange systemer og alle slags typer av involverte deltakere, til hvordan man bør organisere kode i pakker og klasser på best måte. Man lærte fort at det er en grunn til at ordet arkitektur ofte prefikses, og at det er blitt mange av dem. Takk Gud, for Wikipedia.
Siden smidig utvikling har blitt utbredt og man har sluttet å planlegge (så mye) før man setter i gang implementasjon. Arkitektur og den medfølgende rollen har blitt dratt med i dragsuget til det tilbaketrekkende fossefallet. Det er noe vemodig med det, men i all hovedsak er det til det gode. Det henger fremdeles igjen til en viss grad (jeg er nok ikke alene om å ha “utvikler/arkitekt” i CV-en), mer i visse organisasjoner enn andre, men trenden er klar. Spørsmålet som dukker opp da er om vi skal droppe begrepet helt.
Det hadde vært fint, da det ville hjulpet med å komme vekk fra ideen om at dette er noe som må gjøres ferdig først. I motsetning til byggarkitektur så er programvarearkitektur noe som blir til underveis, og dermed blir fort metaforen uhensiktsmessig. Jeg tror dog at den er så godt innarbeidet at det blir fåfengt å prøve å bruke noe annet.
Definisjonen
Selv om vi har beveget oss bort fra å lage og snakke om arkitektur, så har det fremdeles en verdi i å skille det ut fra selve implementasjonen og snakke om det som noe eget. Fordi det er noe som er felles for alle programmerere og jobben de gjør, uansett hvilke verktøy man bruker for å lage programmene. Det er det jeg vil definere programvarearkitektur til å være.
Eksempelvis så trenger alle utviklere å ha en struktur på koden. Selv om valg av språk ofte legger premissene for hvordan det best gjøres, så er det likevel mange valg man må ta som er universelle: Hva og hvor mye skal en metode eller funksjon gjøre? Skal den kunne ha sideeffekter? Hvor tilgjengelig skal den være fra annen kode? Slike beslutninger tas av utviklere flere ganger hver dag. Det er nok ikke alle som tenker på de som arkitekturbeslutninger og at man trenger å ha noen spesiell kompetanse for å ta dem.
I andre enden av skalaen finner vi valg som er mer naturlig at en med arkitekturrollen tar, men som i dag i større og større grad gjøres av utviklere. Det er en klar tendens til at applikasjonene, og dermed teamene som lager dem, blir mindre og mer autonome. Den optimale team-størrelsen blir i dag ofte oppgitt til å være så mange som 2 pizzaer kan fø til overtidsmaten. Noe som jo er litt rart da det foreslår at de med størst appetitt også produserer mer funksjonalitet. Nåja, det sier i hvert fall at dagene da antall personer i et team brukte tierplassen og noen ganger også hundreplassen er over. Denne måten å organisere teamene på gir ikke rom for en arkitekt. Så utviklerne må ofte ta betydelige arkitekturbeslutninger selv – og her ligger det en del utfordringer.
Utviklerrollen har tradisjonelt vært forbundet med å være spesialist på sin valgte teknologi. Man snakker gjerne om utviklere med en eller annen teknologi foran, Java-utvikler, .Net-utvikler, eller innsnevret til en del av valgt teknologi, frontend eller devops eksempelvis. For å ta gode arkitekturbeslutninger derimot bør man ha oversikt over mange teknologier og deres styrker og svakheter, fremfor detaljene om hvordan de brukes. Dersom utvikleren ikke er bevisst på dette og evner å endre sin rolleoppfattelse, kan man ende opp som håndverkeren som kun har en hammer og ser på alle oppgaver som en spiker. Det er heller ikke alltid det er åpenbart hva som er den gode beslutningen, og medlemmene i teamet kan være uenige i hva den er. Der man før hadde arkitekten som den myndige stemme i disputter, kan man nå ende opp i endeløse diskusjoner og skyttergravssituasjoner der samarbeidet og arbeidsklimaet forvitrer.
Så, hva nå?
Det er nå viktig at vi som lager programvare snakker om arkitekturen som noe vi alle har ansvaret for, og at derfor alle må delta i diskusjonene om dette. Alle prosjekter, faggrupper, etc. bør sørge for at alle utviklere har et forum der de kan diskutere og arbeide med dette på tvers av teknologier, og at alle forventes å være med. Ikke at det blir kun for de med lang fartstid og spesiell interesse som skal stå for de gode arkitekturbeslutningene. Det er nå alles ansvar.
De som setter sammen teamene bør likevel være bevisste på at det blir en naturlig orden, mtp. hvem som får det siste ordet der man ikke får diskutert seg frem til enighet innen rimelig tid.
