Jeg opplever stadig oftere at arkitekturvalg i systemutvikling styres av problemer som kanskje kan oppstå om fem eller ti år. Vi designer for ekstrem skalerbarhet, høy last og komplekse scenarioer lenge før det finnes reelle behov for det. Ofte skjer dette på bekostning av å løse de faktiske problemene vi har her og nå.

På NDC Oslo 2025 holdt David Whitney keynoten The Unbearable Weight of Architecture. Den traff veldig godt. Han satte ord på noe mange av oss kjenner igjen, nemlig hvordan arkitektur kan bli så tung og fremtidsfiksert at den i praksis bremser både utvikling og verdiskaping. Ikke fordi intensjonen er dårlig, men fordi vi prøver å forutsi en fremtid vi egentlig ikke forstår ennå.

Arkitektur kan fort bli ett pengesluk

Vi utviklere er ofte veldig flinke til å frustrere oss over ledere og teknologiledere som tar beslutninger vi mener er dårlige eller unødvendig kostbare. Men vi burde kanskje være like strenge med oss selv. For vi gjør akkurat det samme når vi overarkitekter løsninger for behov som kanskje aldri kommer. Vi vil gjerne gjøre ting «riktig», men noen ganger blir resultatet at vi skaper mer kompleksitet enn det verdiutfordringen tilsier.

Jeg ser dette igjen og igjen i praksis. Hvis en applikasjon har rundt hundre brukere, gir det da mening å designe løsningen som om den snart skal ha titusenvis? Hvis en tjeneste kjører én gang i døgnet eller én gang i uka, er det virkelig kritisk at den er ferdig på sekunder i stedet for noen timer? Det er selvsagt ikke optimalt at noe tar lang tid, men hvis det er innenfor dagens krav og ikke påvirker brukerne, er det da riktig sted å bruke masse ressurser på dette?

Optimalisere for scenarioer som aldri vil oppstå

Nå jobber jeg som arkitekt og tech lead på en ny testresultatløsning for Olympiatoppen. I teorien kan flere hundre tusen brukere logge seg inn i løsningen. I praksis vet vi at det kanskje er rundt tusen brukere i løpet av et helt år. I dag inneholder løsningen rundt 60 000 testresultater, og dette tallet vil sannsynligvis vokse med noen tusen i året fremover. Spørsmålet blir da om det gir mye verdi å bruke tid og penger på å støtte flere millioner resultater med millisekundrespons allerede nå.

Etter min mening gjør det sjelden det. Det betyr ikke at man skal bygge løsninger som ikke skalerer, eller ignorere grunnleggende gode prinsipper. Det er alltid fornuftig å lage enkle løsninger som skalerer greit. Samtidig mener jeg det er viktig å være kritisk til hvordan man prioriterer ressursene sine. Tid brukt på å optimalisere for ekstreme scenarioer er tid som ikke brukes på å forbedre funksjonalitet, brukervennlighet og stabilitet for de brukerne som faktisk finnes i dag.

Fleksibilitet > skalerbarhet

Jeg mener ikke at vi skal ignorere fremtiden. God arkitektur handler om å ta bevisste valg og unngå å låse seg unødvendig. Men det er stor forskjell på å bygge for fleksibilitet og å bygge for hypotetiske problemer. Vi er generelt dårlige til å forutsi hvordan systemer faktisk kommer til å brukes. Forretningsbehov endrer seg, organisasjoner endrer seg, og teknologi endrer seg raskere enn arkitekturdiagrammene våre.

Derfor tror jeg mer og mer på at arkitektur bør optimalisere for endring, ikke for perfekte antagelser om fremtiden. En enklere løsning som er lett å justere, slår ofte en kompleks løsning som er «klar for alt», men som er tung å endre.

Til syvende og sist handler dette om prioriteringer. Når vi bruker mesteparten av tiden på å løse morgendagens potensielle problemer, risikerer vi å levere mindre verdi i dag. Kanskje burde vi oftere stoppe opp og spørre oss selv hvilke problemer vi faktisk har nå, hva som realistisk sett kan endre seg på kort sikt, og hvordan vi kan ta valg som gjør det enkelt å justere kursen senere.

Fremtiden kommer uansett. Spørsmålet er om vi har bygget noe som er lett å ta med seg dit.