Hva er lavkode, og hvorfor er det populært?

Samtidig er ikke lavkode en måte å omgå IT eller unngå teknisk ansvar. I dette innlegget lærer du mer om hva lavkode er, hvordan det skiller seg fra ingen kode, hvorfor det har blitt populært, og når det er best å bygge det selv, involvere utviklere eller få hjelp fra en partner.

Hva er lavkode?

Lavkode er en måte å utvikle applikasjoner på ved hjelp av ferdige komponenter, visuelle grensesnitt, konfigurasjon og en liten mengde håndskrevet kode. I stedet for å bygge hver del fra bunnen av, kan utvikleren eller brukeren starte med ferdige byggeklosser for for eksempel skjemaer, arbeidsflyter, visninger, tillatelser, datamodeller og integrasjoner.

Lavkode betyr ikke at koden forsvinner. Den eksisterer «under overflaten», mens plattformen håndterer mer av standardarbeidet. Hos Multisoft betyr utvikling i lavkodeplattformen Softadmin® ofte at vi kan bygge 5–20 ganger raskere enn tradisjonell utvikling, samtidig som kravinnsamling, tilpasning, testing og sikkerhet fortsatt er sentrale i arbeidet.

Lavkode og ingen kode blir ofte referert til sammen, men de løser ikke akkurat det samme. Ingen kode er primært rettet mot brukere som ikke kan programmere og passer best for enklere apper, skjemaer, automatiseringer og prototyper, eller som en del av et eksisterende system der brukeren kanskje ikke engang er klar over at «koding skjer». Lavkode gir mer teknisk rom og brukes oftere når løsningen krever mer logikk, integrasjoner, datamodeller eller muligheten til å supplere med kode.

Hva er et lavkodesystem?

Et lavkodesystem er en applikasjon eller et system som er bygget helt eller delvis ved hjelp av en lavkodeplattform. Det kan være en enkel intern app eller en mer avansert systemstøtte for én eller flere spesifikke prosesser.

Plattformen gir deg ferdige funksjoner og strukturer som gjør utviklingen raskere. Samtidig må du forstå hva plattformen er god på og hvor den setter grenser.

Et lavkodesystem er ofte egnet når:

• Bedriften må komme i gang raskt/gjennomføre et pilotprosjekt
• Løsningen må kunne endres over tid
• Manuelle oppgaver må erstattes med en mer strukturert arbeidsmåte
• Prosessen er tydelig, men for forretningsspesifikk for et standardverktøy

Dette er ikke alltid egnet når kravene til ytelse, teknisk kontroll eller spesiell logikk er svært høye. Det kan også være et spørsmål om hvor mange avvik som er greit å slippe gjennom, eller at regelverk begrenser hva som kan eller bør utvikles. I dette tilfellet kan tradisjonell utvikling eller låsekode med et tilpasset system være et bedre alternativ.

Hvorfor er lavkode populært?

Lavkode er populært fordi mange organisasjoner har flere digitaliseringsbehov enn tradisjonelle utviklingsprosesser kan håndtere. Ansatte på tvers av organisasjonen ønsker å teste ideer, automatisere manuelle oppgaver og få bedre støtte for prosesser som ikke passer perfekt inn i eksisterende systemer.

Samtidig må IT håndtere sikkerhet, drift, integrasjoner, datakvalitet og styring. Lavkode kan derfor være en måte å øke utviklingskapasiteten uten å bygge alt fra bunnen av, og i mange tilfeller kan man involvere ressurser som ikke har de samme ferdighetene.

Gartner beskriver hvordan utviklerrollen endrer seg etter hvert som AI og automatisering blir viktigere i programvareutvikling. Rollen beveger seg mer mot problemløsning, design og kvalitetssikring, men ikke bort fra ansvar. Dette er et rimelig bilde selv for lavkode: etter hvert som mer grunnleggende arbeid automatiseres, blir en helhetlig forståelse viktigere.

Men de positive egenskapene ved lavkode kan også skape problemer. Hvis det blir for enkelt å bygge uten et felles rammeverk, kan organisasjonen ende opp med mange apper, uklart eierskap og vanskelig administrerbare løsninger. KPMG fremhever spesielt risikoen for at lavkode og ingen kode kan bidra til «skygge-IT» hvis utviklingen skjer utenfor etablerte arbeidsmetoder og godkjente plattformer. Dette er vanlig i større organisasjoner som har et komplekst IT-miljø , der enkeltpersoner eller team tar saken i egne hender og løser problemer. Noe som igjen skaper nye problemer.

3 måter å bygge med lav kode

Bygg selv når risikoen er lav, bygg med utviklere når teknologien er viktig, og bygg med partnere når behovet er spesifikt, langsiktig og krever administrasjon.

Lavkode og AI

AI gjør lavkode kraftigere, men ikke automatisk mer kontrollert. Mange plattformer får nå funksjoner der AI kan bidra til å lage skjemaer, foreslå arbeidsflyter, generere kode, skrive dokumentasjon eller bygge apper basert på tekstinstruksjoner.

Dette kan gjøre det enda raskere å komme i gang. Men det gjør også gjennomgang viktigere. AI kan foreslå en løsning, men den vet ikke alltid hvilke data som er sensitive, hvilke regler som gjelder i organisasjonen, eller hvilke unntak som oppstår i prosessen og hvordan de skal håndteres.

McKinsey har vist at generativ AI kan gjøre utviklere raskere på visse kodeoppgaver, men effekten varierer avhengig av oppgavens kompleksitet. Derfor er det lurt å se AI som en støtte for utviklingsarbeid i dag.

1. Bygg deg selv med lavkode

Å bygge din egen med lavkode kan være svært effektivt når du har de riktige ferdighetene og et tydelig rammeverk. Det kan gi bedriften din muligheten til å teste ideer raskt og la folk nær prosessen bli mer involvert i løsningen. For team med teknisk kyndige ansatte kan lavkode også være en måte å avlaste IT og korte ledetider.

Fordelen er at organisasjonen kan jobbe raskere, lære ved testing og bygge nærmere brukerne. Bygg selv når behovet er tydelig, risikoen er håndterbar og det finnes personer som kan eie løsningen over tid. Men som sagt, vær mer forsiktig når løsningen håndterer sensitive data, påvirker mange brukere eller blir avhengig av flere andre systemer.

2. Utvikle i lavkode med hjelp fra utviklere

Mange mer seriøse lavkodeinitiativer drives ikke av virksomheten, men av IT, som bruker lavkode for å bygge raskere. Det er et viktig skille.

Når utviklere bruker lavkode, kan organisasjonen øke hastigheten uten å miste teknisk kvalitet. Utviklere kan vurdere datamodeller, integrasjoner, sikkerhet, ytelse og testing. Samtidig trenger de ikke å bygge alt «fra bunnen av».

Risikoen er at plattformen fortsatt setter grenser. Hvis løsningen krever mye spesiell logikk, uvanlige brukerflyter eller spesielle ytelseskrav, kan lavkode bli trangt. I så fall må teamet tidlig vurdere om plattformen er tilstrekkelig.

3. Bygg med en lavkodepartner

I mange tilfeller ønsker organisasjoner hastigheten til lavkode, men ønsker ikke å bygge det selv. I så fall kan en partnerdrevet lavkodeløsning være relevant.

Dette betyr at en ekstern partner bruker en lavkodeplattform for å bygge, tilpasse og videreutvikle et system for organisasjonen. Fordelen er at man får tilgang til en ferdiglaget arbeidsmetode, teknisk erfaring og administrasjon. Ulempen er at man blir avhengig av partneren og plattformen, noe som gjør langsiktig planlegging og åpenhet viktig.

Det passer ikke for alle. Hvis du har sterk intern utviklingskapasitet (med tid til overs) og ønsker å eie byggingen selv, kan en selvbetjeningsplattform være bedre. Men hvis behovet er spesifikt, langsiktig og krever administrasjon, kan lavkode med partnere være en måte å oppnå både tilpasning og ansvarlighet.