Ferdig modul eller egen løsning? Slik velger du riktig

I Sitevision finnes det ofte en ferdig løsning når behovet oppstår. Men noen ganger frister tanken på å bygge noe helt eget. Så hvordan vet vi hva som er riktig vei? Svaret er sjelden svart-hvitt, men det finnes noen avgjørende spørsmål som hjelper oss å velge riktig.

En av de store fordelene med Sitevision som plattform er det brede biblioteket av ferdige moduler som følger med – standardmoduler som dekker de fleste behov for et intranett eller en ekstern nettside, bygget som perfekte brikker i det puslespillet som utgjør plattformens økosystem. I tillegg dukker det stadig opp nye tillegg i Marketplace. Å bruke en ferdig modul er fristende fordi ansvaret for forvaltning ligger hos leverandøren, i motsetning til en egenutviklet løsning som må vedlikeholdes internt. Samtidig kan en egen løsning gi større frihet i detaljene. Som utvikler skriver jeg gjerne kode og kan levere akkurat det som ønskes, men vet samtidig at det innebærer et ansvar for at løsningen må fungere over tid.

Å bygge eller ikke bygge – det er (nesten) alltid spørsmålet

Ta et klassisk 50/50-element: bilde til venstre, tekst til høyre. Dette kan enkelt bygges med standardmodulene Tekst og Bilde, styrt av en omsluttende dekorasjonsmal. Fordelene er mange: støtte for bildetekst, størrelser, formatmaler og muligheten til å legge til en call to action.

Men hva skjer hvis elementet kopieres til hundre sider, og man senere ønsker å endre layout eller funksjon? Da kan en WebApp være enklere å justere sentralt, i stedet for å manuelt oppdatere hver instans eller lappe med CSS.

Det er teknisk mulig å tilpasse en ferdig modul uten tilgang til kildekoden. Med CSS og JavaScript kan vi endre knapper i en dialog etter at modulen er rendret. Men jo flere slike tilpasninger vi gjør, desto mer utvikler løsningen seg til et slags Frankensteins monster over tid, og endringene våre risikerer å bryte sammen når modulen oppdateres. Er vi villige til å ta den risikoen, eller kan vi akseptere standardmodulen slik den er?

En enkel beslutningsmodell

1. Kartlegg behovet grundig – Hva er det vi faktisk ønsker å oppnå?
2. Finnes det en standardmodul som dekker behovet?
3. Kan vi akseptere mindre avvik? Noen ganger er “godt nok” det riktige valget. Her kan man som konsulent måtte stå på og forklare fordelene.
4. Er løsningen forvaltningsbar over tid? Spesielt hvis flere moduler bygges sammen til én løsning.
5. Kan behovet løftes til Sitevision? Min erfaring er at forslag som skaper reell verdi blir tatt på alvor.
6. Utvikle egen løsning – men gjør det på en ansvarlig og bærekraftig måte.

Når egen utvikling er riktig vei

Sitevision er bygget for å være utviklervennlig. Et tydelig internt API og SDK, god støtte for datalagring og sterke integrasjonsmuligheter gjør det mulig å bygge robuste løsninger. Det kan for eksempel handle om å synkronisere ekstern data for å gjøre den søkbar, eller bruke den som grunnlag for en KI-assistent. Å utnytte disse mulighetene er også en form for “standard”, siden vi jobber innenfor plattformen og slipper å bygge løsninger ved siden av.

Men med frihet følger ansvar. Når vi velger å utvikle en egen modul, må vi sikre høy grad av forvaltningsbarhet. Hvordan gjør vi det? Som konsulent skal jeg jobbe for kundens beste, noe som også betyr å unngå personlige utviklingsmønstre som låser kunden til en løsning som er vanskelig å overta. Derfor bør vi holde oss til standarder og følge best practice.

Bærekraftig utvikling i Sitevision

• Gjør som Sitevision selv: bruk React og TypeScript.
• Minimer tredjepartsavhengigheter og utilgjengelig/låst kode via npm.
• Dokumenter mer: bruk appens README-fil til å beskrive formålet og begrunne valgene du har gjort. Legg arkitektur- og kodenær dokumentasjon i markdown som en del av kodebasen. Dette gjør den tilgjengelig både for utviklere og KI-assistenter.