Arkitekturen som ble organisert istykker

Har du hørt om programvareløsningen som ble organisert istykker? Det hadde ikke vi heller, inntil vi fikk se det med egne øyne. Conways lov, som ikke er en lov men en observasjon, sier at en løsning vil få en arkitektur som gjenspeiler kommunikasjonsmønstrene i organisasjonen som lager den. Denne observasjonen kan vi utnytte, og gjøre det lettere å lage en hensiktsmessig arkitektur med riktig organisering. Hvis vi ikke tar hensyn til observasjonen, og «bare setter sammen en organisasjon» for å løse et problem, kan mye gå galt – og da gjør det gjerne det.

Det var en gang et prosjekt, la oss kalle det prosjekt Rammeverk, som skulle bygge et rammeverk som skulle brukes av flere av utviklingsteamene våre. Prosjektet ble staffet med folk og de fikk frie tøyler til å utvikle rammeverket. Etterhvert hadde vi et rammeverk i produksjon som understøttet funksjonalitet i nettbanken. Og

  • det var andre abstraksjoner og konsepter i koden enn vi bruker i resten av nettbanken
  • det var integrasjons- og enhetstester, men ingen ende-til-endetester
  • maven byggesystemet og modulariseringen var annerledes enn vi bruker i resten av nettbanken
  • utviklingsmiljøet kjørte på feil operativsystem

En annen historie handler om et prosjekt som skulle erstatte eksisterende funksjonalitet med ny, grunnet nye tjenester i de aktuelle baksystemene. La oss kalle det prosjekt Erstatt. Etterhvert hadde vi funksjonaliteten i pilot i nettbanken. Og

  • frontenddelen av løsningen var utviklet på feil teknologi
  • det felles stilbiblioteket vårt var ikke brukt
  • en rekke av avhengighetene i koden var utdatert

Hva er sammenhengen mellom organisering og arkitektur?

Hva skjedde egentlig i prosjektene over? Hvordan og hvorfor påvirker organiseringen av prosjektet arkitekturen? Det avhenger av hva en skal lage.

Lage noe som skal brukes av alle

Hvis en skal lage noe som skal brukes av alle, og lager en organisasjon på utsiden av de som skal bruke det, kan en ende opp med noe som blir enklest å gjennomføre for organisasjonen, ikke det som blir enklest å bruke for alle. Med mindre en har flaks, og organisasjonen settes opp med folk som har samme kompetanse, erfaring og verdier som de som jobber der fra før, ender en fort opp med arkitektur og løsninger som ikke passer med resten av organisasjonen. I prosjekt Rammeverk endte vi opp uten ende-til-endetester, og utviklingsmiljø på feil operativsystem.

Utvikling av ende-til-endetester er et verdivalg. Det er basert på en grunnleggende tro på automatisering av regresjonstester for hele tiden være så sikker som mulig på at vi har kode som fungerer. Disse verdiene var ikke tilstrekkelig til stede i utviklingsorganisasjonen som tok fram det aktuelle rammeverket. Dermed ble de heller ikke laget.

Utviklingsmiljøet var tatt fram på feil operativsystem. Dette skyldtes minste motstands vei for organisasjonen på utsiden. De hadde mest erfaring med et annet operativsystem, og da var det det som ble brukt. I og med at vi utvikler løsninger for JVMen så fungerer dette, men var i praksis ikke mulig å ta utviklingsmiljøet i bruk for resten av utviklingsteamene.

Videreutvikling av eksisterende funksjonalitet

Hva når en skal videreutvikle eksisterende funksjonalitet, som i prosjekt Erstatt? Hva skjer hvis en kjører et slikt prosjekt med andre mekanismer enn de som benyttes i den ordinære utviklingen? I prosjekt Erstatt ble det satt opp en utviklingsorganisasjon med flere som hadde erfaring fra de andre nettbankteamene. Alt burde dermed ligge til rette for en smidig gjennomføring. Her ble det utfordringer med finansieringsmodellen – som også viste seg å påvirke arkitekturen. Det ble ikke hensyntatt at vi gjør kontinuerlig forbedring og videreutvikling av nettbankarkitekturen. Blant annet skiftet vi standard frontendrammeverk i nettbanken mens det aktuelle prosjektet pågikk. Dette valgte prosjektet ikke å ta hensyn til. Dermed ble ny funksjonalitet utviklet på utdatert frontendteknologi. Vi hadde også innføring og mye utvikling av det felles stilbiblioteket vårt i perioden. Dette tok heller ikke Erstatt hensyn til.

Hvorfor tok ikke prosjektet inn disse store forbedringene? Vi tror dette primært skyldtes at det var valgt å kjøre en større release i stedet for flere mindre. Dette gjorde at prosjektet befant seg i en grad av test i en lang periode. I denne perioden var det ikke aktuelt å innføre andre endringer enn feilrettinger i koden. Arkitekturforbedringene ble dermed ikke hensyntatt.

Dette kan sees på som (nok) et argument for hyppigere og mindre releaser. Hyppigere og mindre releaser gjør det enklere å gjennomføre kontinuerlige forbedringer i koden og i arkitekturen.

Hensiktsmessig organisering gir bedre arkitektur

Hensiktsmessig organisering avhenger av hva en skal lage.

Lage noe som skal brukes av alle

Hvis en skal lage noe som skal brukes av alle, lag dette i tett samarbeid med de som skal bruke det. Vi gjør det ved å utvide eksisterende team med folkene som trengs for å gjennomføre oppgaven. Dette gjør det enklere å bygge det nye i harmoni med det eksisterende. Det gjør det også enklere å henge med på de kontinuerlige forbedringene som skjer i den eksisterende arkitekturen.

En ny løsning vil alltid gi nye muligheter. Den vil også alltid ha utfordringer. Vi kan ikke understreke nok viktigheten av å overkommunisere rundt nye løsninger når det er noe som skal brukes av mange. Det er naturlig å være skeptisk til nye løsninger. Dermed er det ekstra viktig å fortelle ikke bare om det som er nytt og flott, men også om utfordringene vi vet om med «det nye». Dette både tar ned skepsisen, og viser at det jobbes med å finne gode løsninger på de aktuelle utfordringene.

Videreutvikling av eksisterende funksjonalitet

Vi bruker samme resept også når vi skal videreutvikle eksisterende funksjonalitet. Vi utvider et eksisterende team med folkene som trengs for å gjennomføre oppgaven. Vi tar med folk fra det eksisterende teamet inn for å jobbe sammen med eventuelt nye folk for å løse oppgaven. Det er bedre å sette inn nye folk i det eksisterende teamet, enn å la bare nye folk gjøre den aktuelle videreutviklingsjobben.

Blir det for mange folk i et team, oppstår det problemer. Blant annet slutter standupene å fungere. Vi håndterer dette ved å dele opp teamet i subteam. Vi sitter fortsatt sammen, og kjører felles teamledelse for subteamene. Siden subteamene er så tette på hverandre, har vi ikke utfordringer med å få med oss den kontinuerlige forbedringen som skjer i teamene også inn i funksjonaliteten som videreutvikles.

Lage noe helt nytt

Men hva om en skal lage noe helt nytt som hverken skal taes i bruk av alle, eller er videreutvikling av eksisterende funksjonalitet? Kan det da fungere å sette opp en egen utviklingsorganisasjon?

Dette vil være løsere koblet til den eksisterende plattformen enn rammverksutvikling og videreutvikling av eksisterende funksjonalitet. Vi mener organisasjonen må settes opp basert på hvem som skal forvalte og videreutvikle løsningen i produksjon. Er dette et eksisterende team, bør dette teamet være ansvarlig for nyutviklingen. Skal forvaltningen settes ut, så spiller det mindre rolle. Men en må da påregne vesentlig koordinasjonskost i følge med testing, godkjenning, produksjonssetting og handover til mottagende forvaltningsteam.

Fra prosjekter til flyt

Vi kaller fortsatt en del av utviklingsoppgavene vi gjør for prosjekter. I og med at vi nå gjør all utvikling i kontekst av utviklingsteamene våre, så er det strengt tatt ikke prosjekter lengre. Det er vanlig produktutvikling. Det gjør det lettere for oss å sørge for at vi har de med dypest kompetanse på det aktuelle området til å gjøre jobben. Folk får variert arbeidsoppgavene sine med både store og små utviklingsoppgaver. Og ikke minst gjør det det enkelt å drive kontinuerlig forbedring av både koden og arkitekturen vår.

Vidar Moe, mai 2018