Velger du teknisk gjeld før nettsideprosjektet er i gang? 

De fleste problemer med en nettside oppstår som følge av beslutninger som tas før en eneste linje kode er skrevet. Forskning viser at arkitektonisk gjeld er både vanskeligere å oppdage og dyrere å hanskes med enn kodemessig gjeld. Å være et kompetent utviklerbyrå inkluderer selvfølgelig å ha nordens beste utviklere på huset, men hvorvidt et prosjekt lykkes eller ikke har mer å gjøre med strategi enn med rask og feilfri kode.

Da trelastleverandøren Talgø fra Todalen på Nordmøre kom til oss i 2020 hadde de to nettsteder med alvorlige performanceproblemer, bygget på en headless React-løsning. Løsningen var ikke feil i seg selv – headless er ikke like i vinden som det var, men mange headless-løsninger fungerer helt utmerket. Men for Talgø var den for ressurskrevende å vedlikeholde, avhengig av spesialistkompetanse på React, og vanskelig for redaktørene å bruke selvstendig. Resultatet var høye løpende kostnader og lav handlefrihet.

En løsning som sikkert hadde vært passende for andre bedrifter ble en hemsko for Talgø, fordi den ikke passet inn i deres daglige drift. Kostnaden ved å opprettholde nettsiden var også dobbelt, fordi den holdt dem tilbake fra å bruke ressursene på det de egentlig ønsket, nemlig videreutvikling og tydelig markedskommunikasjon.

Denne typen teknisk gjeld kalles “arkitektonisk gjeld”. Den skiller seg fra kodemessig gjeld ved at den oppstår i beslutningene som former selve strukturen i en løsning: hvilke teknologier som velges, hvordan systemet er delt opp, hvilke avhengigheter som bygges inn, osv.

Vi bygget en ny løsning som var bedre tilpasset hverdagen deres, og nå bruker de endelig tid på UX-forbedringer, tracking, analyse og SEO-optimalisering framfor å lappe på en løsning som aldri var bygget for dem.

Vi har gjort det samme både før og siden: omstrukturert nettsider for å tilpasse dem eierne sine, enten det gjelder forenkling av administrasjon av komplekse sider som hoyre.no, eller forbedre digital synlighet som med Statped.

Det er fristende å tenke at nettsidearkitektur er en rent kodemessig vurdering, men det finnes utallige eksempler på at arkitektur i bunn og grunn er et strategisk valg. Løsningen som implementeres i dag avgjør hva som er mulig om to år, og hva som vil kreve en fullstendig ombygging. En dårlig arkitektur er ikke nødvendigvis en som krasjer (selv om det også kan være et problem), men en som hindrer deg i å oppnå bedriftsmålene dine.

Å bygge for i dag er den største fallgruven

Charles de Gaulle flyplass i Paris er kjent som en av verdens verste flyplasser. Da den sto ferdig i 1974 ble den hyllet som et arkitektonisk mesterverk, men på grunn av økt trafikk, større fly og en sirkelform som gjør den vanskelig å utvide, har den etterhvert blitt et mareritt å navigere seg i og fly fra.

Bedrifter er også i konstant endring. Nye tjenester introduseres, gamle fases ut. Kanalmiksen bedriften bruker i dag vil kanskje se ganske annerledes ut om tre år.

Det som passer en organisasjons behov perfekt i dag, kan vise seg å være for lite fleksibelt, for underdimensjonert eller for manuelt om tolv måneder. Ikke fordi det er dårlig håndtverk, men fordi den ble designet for en organisasjon som på en måte ikke lenger eksisterer. Dette er kjernen i teknisk gjeld: løsninger som ga mening da de ble laget, men som nå krever stadig mer arbeid for å holdes i gang, uten å tilføre noe nytt. Den vanligste kilden til dette problemet, og også den dyreste, er å behandle skalering som en ettertanke.

Men det er ikke bare å fundere litt på hvilke løsninger man kan få bruk for om fem år. Da risikerer man å ende opp som Talgø, med en rigg som er overdimensjonert og egentlig krever et helt team å vedlikeholde. Arbeidet med å utvikle nettsiden må stå i stil med realiteten, og det er her kompetansen, og ikke minst erfaringen, til nettsidebyrået kommer inn. For eksempel hjelper det å ha noen av verdens beste utviklere på laget. Evnen til å gjøre slike kvalifiserte vurderinger kommer i stor grad med erfaring med å planlegge større nettsideprosjekter.

Hvorfor er arkitektonisk gjeld annerledes?

Den enkleste formen for teknisk gjeld ligger på kodenivå. Du har kanskje hørt om at AI-modellen Claude kan oppdage skjulte sikkerhetsfeil? Disse er kodemessige feil eller mangler som kan oppdages automatisk, og som kan fikses med begrensede ressurser.

Arkitektonisk gjeld er en annen sak. I motsetning til kodegjeld er den vanskelig å oppdage, kostbar å utbedre, og lett å ignorere – helt til den ikke kan ignoreres lenger.

Forskning som involverer erfarne tekniske ledere på tvers av bransjer tegner et gjenkjennelig bilde av hvordan dette utvikler seg. De vanligste kildene er tidspress, manglende dokumentasjon, og aller viktigst: beslutninger tatt uten tilstrekkelig kontekstkunnskap. En løsning som var riktig da den ble valgt, kan bli feil etter hvert som organisasjonen endrer seg, og arkitekturen ikke gjør det.

Konsekvensene er heller ikke abstrakte. Arkitektonisk gjeld gir seg konkrete utslag: utviklingen går saktere, nye behov blir vanskeligere å innfri, og i ytterste konsekvens fryser systemet fast. Det kan i verste fall rett og slett være umulig å legge til ny funksjonalitet uten å bygge om fra grunnen. Gjelden vises ikke på en faktura, men den koster. Hver gang teamet bruker tid på å lappe i stedet for å bygge, er det penger og kapasitet som ikke går til det dere egentlig ønsker å drive med.

Tre valg er mer avgjørende enn andre

• Velg en partner fremfor en teknologi. Problemet er nesten aldri WordPress kontra noe annet, med mindre det er snakk om oppgraderinger fra ferdigløsninger som Wix eller Squarespace. Sjelden er det selve teknologivalget som gjør at en løsning eldes. Det er de som tar beslutningene, og begrunnelsen bak dem, som avgjør om en løsning holder over tid. En god partner forstår hvor du skal, og utformer arkitekturen deretter.

• Hyr inn seniorutviklere. En junior fokuserer på det umiddelbare problemet, mens en god senior fungerer som en rådgiver som tenker på problemene du ikke har fått ennå. En nettside bør gjenspeile organisasjonens arbeidsflyt og retning, ikke tvinge organisasjonen til å tilpasse seg nettsiden. En arkitekt kan begrunne alle aspekter ved løsningen, og det er et tegn på at det er tenkt grundig gjennom.

• Diskuter visjonen din for de neste fem årene før dere snakker om funksjonalitet. Å ta valg uten retning fører bare til at de samme valgene må tas to ganger: først nå, og igjen når det viser seg at de ikke holder. De dyreste ombyggingene vi ser skyldes ikke slett håndtverk, men at de riktige spørsmålene ikke ble stilt tidlig nok.

Kostnaden ved å velge feil

Teknisk gjeld er ikke abstrakt. Det materialiserer seg som oppgaver du ikke hadde planlagt: oppdateringer, omskrivinger og integrasjoner som slutter å fungere. Arbeid som må gjøres, men som ikke tilfører noe nytt, og som trekker ressurser bort fra prosjektene organisasjonen faktisk ønsker å gjennomføre, og fra initiativene som beveger selskapet fremover. Å ta de riktige valgene fra starten hjelper deg å unngå å rive alt ned for å komme deg dit.

Hvilket CMS er egentlig best?

Vi burde egentlig si WordPress her, siden det er det vi driver med, men i realiteten kan vi anbefale flere andre åpen kildekode-løsninger som Drupal eller til og med Ghost, Strapi og Payload, litt avhengig av konkret bruksområde.

Det er derfor vi sier at du bør velge en partner, ikke en teknologi. Med de rette folka kan du få til stort sett alt du vil med flere forskjellige teknologier.

Her i Dekode hjelper vi bedrifter og organisasjoner med å ta gode beslutninger fra starten. Ikke bare som en teknisk leverandør, men som en strategisk partner. Vi stiller spørsmålene om fremtiden tidlig, begrunner anbefalingene våre og sørger for at løsningene vi leverer er rustet til å tilpasse seg en hverdag i endring.

Er nettsiden din klar for der organisasjonen ønsker å være om fem år, og har dere det dere trenger for å møte det som kommer? Ta gjerne en prat med oss.