Lean arkitektur

Store virksomheter kan lære mye av startup-kulturen når det gjelder utvikling av digitale produkter. Det viktigste er at arkitekturen må støtte innovasjonsprosessen.

Lean-inspirerte tankesett ser ut til å kunne løse mange av utfordringene vi har hatt i digital produkt- og tjenesteutvikling. Lean Startup og Lean UX oppmuntrer til å validere grunnleggende antakelser om alt fra forretningsmodell til brukeropplevelse gjennom prototyping og brukerinvolvering; prøving og feiling.

Slike prosesser er som regel preget av stor usikkerhet, og det er ikke gitt at systemarkitekturen man har lagt opp til vil passe det endelige behovet. Dermed er det på tide å reflektere over hvordan man sørger for å ha en tilstrekkelig og fleksibel arkitektur på plass til enhver tid i en prototypedrevet prosess. Sagt på en annen måte: hvordan bør arkitekturarbeidet støtte opp under Leans grunnidé, nemlig å øke løsningens verdi [slik brukerne opplever den], og samtidig redusere unødvendig ressursbruk?

Prototypens høye takt

I Lean UX og Lean Startup eksperimenterer vi gjennom prototypene våre, får gradvis større innsikt og forbedrer løsningen (kontinuerlig) deretter. Vi foretrekker å feile tidlig (og billig) fremfor sent (og dyrt).

Prototypen vil kunne øke i kompleksitet i form av antall komponenter og aktører, integrasjoner og grad av distribusjon. Dette er spesielt sant for prosjekter som fortsetter med den prototypedrevne prosessen etter at løsningen er satt i produksjon og lansert i markedet. Dette vil også kunne skje i tilfeller hvor det er viktig å få testet ikke-funksjonelle krav som ytelse, skalerbarhet og sikkerhet. Arkitektens jobb blir dermed å håndtere kompleksiteten på en måte som ikke kommer i veien for den høye takten prototypingen krever.

Systemarkitektur i innovasjonsprosessen: viltvoksende eller skrevet i stein?

Under smidig-paradigmet ble systemarkitektur opprinnelig sett på som noe som kunne «vokse fram organisk» gjennom iterative utviklingsprosesser (emerging architecture) og i mindre grad burde planlegges på forhånd. I dag vet vi at en slik tilnærming ofte kommer til kort allerede ved moderat kompleksitet og at en viss fremsynthet kreves for å sikre at arkitekturen skalerer og på andre måter tilfredsstiller ikke-funksjonelle krav.

Det er ikke dermed sagt at den tradisjonelle tilnærmingen med en tung systemdesignfase tidlig i prosjektet (BDUF) er svaret. Tvert imot. Å bruke tid og ressurser på å planlegge arkitektur når man bare har et sett med antakelser om hvilke behov brukerne har (og noen idéer om hvordan disse skal løses) vil nesten alltid føre til mye overflødig arbeid (eller Waste i Lean-vokabularet).

Arkitektens handlingsrom befinner seg ofte et sted imellom. Selv om en overordnet arkitekturvisjon kanskje kan bestemmes tidlig (eller er gitt av føringer i organisasjonen) vil systemdesign og implementasjonsdetaljer være mindre klare. Passer relasjonsdatabaser eller NoSQL våre behov best? Er mikrotjenester, kontinuerlige leveranser og DevOps godt egnet for prosjektets behov (og organisasjonen for øvrig)? Hvilke deler av løsningen kan vi regne med å måtte skalere for høy belastning?

Utsett irreversible beslutninger

Å utsette irreversible beslutninger knyttet til systemdesign så lenge som mulig er en nyttig strategi for å begrense risiko i Lean-prosjekter. For mange vil dette virke unaturlig, hvorfor ikke legge ned mer innsats i planleggingsarbeidet og sørge for å få det rett første gangen? Svaret ligger delvis i innsikt, delvis i at krav og rammebetingelser nesten alltid endres underveis i et prosjekt. Ved å vente så lenge som mulig ut i utviklingsprosessen lærer man mer, kan utforske flere muligheter og er i stand til å ta mer kvalifiserte valg. I en prototypedrevet prosess hvor forutsetningene kan endre seg flere ganger vil det dermed være gunstig å ikke binde seg opp i teknologivalg som er vanskelig å reversere. I Lean anerkjenner vi at endringer kommer til å skje, og forsøker å velge robuste, fleksible arkitekturer som tåler disse endringene.

Delaying irreversible decisions until uncertainty is reduced has economic value. It leads to better decisions, it limits risk, it helps manage complexity, it reduces waste, and it makes customers happy

Mary og Tom Poppendieck

Å utsette beslutninger kan være vanskelig fordi mange aktiviteter knyttet til arkitekturarbeid tar tid. Noen ganger må man utrede hvorvidt man skal bygge selv eller kjøpe hyllevare med påfølgende (tidkrevende) anskaffelsesprosesser. I mange organisasjoner skal den nye løsningen inn i en eksisterende portefølje, og IT-funksjonen har (ofte med rette) mye den skal ha sagt hva gjelder innfasing og forvaltning av systemene. Noen ganger tar det lang tid å etablere den nødvendige infrastrukturen fordi man må vente på maskinvare eller avhengigheter til eksisterende infrastruktur.

Prototyping av arkitektur

For at arkitekturen ikke skal bli et hinder for den prototypedrevne prosessen kan det derfor være nyttig å utvide prototypetankegangen til å omfatte arkitekturen (eller deler av den). For å kunne teste de grunnleggende antakelsene i et prosjekt kan det være behov for integrasjoner, lagringsteknologi og distribusjon av data. Men i stedet for å binde oss til konkrete teknologivalg tidlig kan vi lage prototyper av de underliggende komponentene også.

Vi har selv god erfaring med slike forsøk. I et tilfelle var vi usikre på om en relasjonsdatabase eller NoSQL ville være best til vårt formål, og tok i bruk en enkel,” flat”, skybasert lagringsteknologi (Redis minnebasert database på Microsoft Azure) inntil vi visste mer. Etter hvert som innsikten økte ble det klart at et tredje alternativ, en søkemotor (Elasticsearch), ville løse behovet bedre. Som resultat fikk vi et bedre produkt uten å ha kastet bort tid på teknologiene som så mest lovende ut i utgangspunktet.

Systemarkitektur i den operasjonelle fasen: Når prototypen settes i produksjon

Verdien av å eksperimentere er fortsatt stor etter at løsningen er satt i produksjon, spesielt i markedsdrevne prosjekter. Data fra reell brukeratferd gir ny innsikt, og i kombinasjon med mekanismer for kontinuerlig leveranse er det lettere å se effekten av endringene som slippes. Dermed kan løsningen kontinuerlig forbedres. Skyplattformer som Amazon AWS og Microsoft Azure er spesielt godt egnet for denne type prøving og feiling fordi etableringskostnadene er svært lave, ledetiden kort og risikoen for feilinvestering lav sammenliknet med tradisjonell IT-infrastruktur samtidig som krav til oppetid og skalerbarhet er svært godt ivaretatt.

Etablerte virksomheter sitter i mange tilfeller med store mengder informasjon som ville tilføre verdi for sluttbrukere i mange sammenhenger, også utenfor organisasjonen. Eksempler kan være trafikkdata, geografiske data, meteorologiske data og så videre. Kanskje befinner dataene seg i ulike systemer, som datavarehus, ERP-systemer, fagsystemer og legacy-systemer. Slike systemer forvaltes tradisjonelt sett på en annen måte enn markedsrettede websystemer. Endringsregimet er som regel mer rigid og har vesentlig lengre sykluser.

To sider av arkitekturen

For å lykkes med prototypedrevne prosesser er det nødvendig med korte feedback-løkker, det vil si at tiden fra en endring slippes til effekten måles er kort. Dermed kan det være hensiktsmessig å betrakte arkitekturen som en two speed architecture slik McKinsey foreslår. De digitale, forbrukerrettede tjenestene innrettes mot svært korte sykluser (kontinuerlig leveranse og DevOps) mens kjernesystemene forvaltes for robusthet og stabilitet (tradisjonelt etter mønster fra rammeverk som ITIL, COBIT og liknende). Dermed fristilles den prototypedrevne delen av løsningen til en viss grad fra kjernesystemene, samtidig som kjernesystemene kan følge sitt ordinære endringsprogram uten å måtte håndtere hasteendringer og unntak.

Som arkitekt blir det nødvendig å koordinere mellom de to sidene av arkitekturen og melde inn krav til kjernesystemene tidlig. Men gjennom eksperimentering i ”fronten” er det grunn til å anta at kravene vil ha høyere kvalitet fordi de er validert gjennom prototyping. Ved stor usikkerhet kan man eksempelvis skaffe et uttrekk av en database, og bruke dette øyeblikksbildet for å teste ut en hypotese før man bestiller en reell integrasjon.

I et prosjekt hadde vi en idé om hvordan data fra et datavarehus kunne utnyttes for å øke kvaliteten og opplevd verdi i applikasjonen. Integrasjonen hadde imidlertid avhengigheter som ville gi lang ledetid. For å teste hypotesen mottok vi et uttrekk fra datavarehus som kommaseparert fil og fôret denne inn i søkemotoren. Dager etter at ideen oppsto kunne vi demonstrere et lovende konsept som senere førte til beslutning om å integrere systemene.

Rullebanen

Arkitekturarbeid i Lean-sammenheng innebærer en kombinasjon av langsiktig tenkning og evne til å se systemdesignet i lys av stadig bedre innsikt. Spesielt i tidlige faser, hvor usikkerheten er størst, kan det være hensiktsmessig å ikke binde seg til konkrete teknologivalg som er kostbare å gjøre om på.

Etter hvert som systemene settes i produksjon er det viktig å ha en fortsatt evne til hyppige leveranser. I mange organisasjoner kan dette være i konflikt med gjeldende retningslinjer og leveranserutiner. Anerkjenn at ulike typer løsninger har ulike typer behov og organiser leveranseprosessene deretter.

Bygg den enkleste arkitekturen som vil fungere. Gi innovasjonsprosesser spillerom.

 

Publisert