Low-code: snarvei eller blindvei?
Low-code passer utmerket for avgrensede interne arbeidsflyter, skjemaer og enklere verktøy der hastighet veier tyngre enn egenart. For kjerneprodukter med krav til skala, ytelse eller et eget uttrykk blir det ofte en blindvei der lisenser og begrensninger etter hvert innhenter prosjektet. Beslutningsmodellen tar utgangspunkt i systemets levetid og hvor forretningskritisk det er, ikke i teknologien i seg selv.
Low-code vekker sterke følelser. Tilhengerne ser en fremtid der hvem som helst bygger apper på en ettermiddag; skeptikerne ser en felle som låser deg inne i en plattform. Sannheten er at begge har rett, men om ulike typer prosjekter. Low-code er et utmerket verktøy for noen behov og et dårlig valg for andre, og kunsten er å vite hva som er hva. Her er en saklig grenseoppgang, fri for både hype og fordømmelse.
Der low-code leverer raskt og billig
Low-code betyr plattformer der man bygger ved å konfigurere og dra og slippe snarere enn å skrive all koden for hånd. Styrken er hastighet: En fungerende løsning kan stå ferdig på en brøkdel av tiden, iblant bygget av en person uten dyp programmeringsbakgrunn.
Det gjør low-code ideelt for avgrensede, interne behov der hastighet veier tyngre enn egenart:
- Skjemaer og datainnsamling. En søknad, en påmelding, en spørreundersøkelse som må ut raskt.
- Interne godkjenningsflyter. En forespørsel som skal gjennom noen trinn og godkjennes av riktig person.
- Enkle registre og verktøy. Et internt hjelpemiddel som løser et tydelig problem for en avdeling.
Felles for disse er at behovet er standardisert og internt. Ingen kunder ser løsningen, den trenger ikke å skalere til millioner av brukere, og den skal ikke bære noe unikt varemerke. Jo mer et behov ser slik ut, desto sterkere taler det for low-code.
Veggene man møter
Problemene med low-code viser seg sjelden i starten. De kommer når løsningen skal vokse eller strekke seg utover plattformens rammer, og da kan de være dyre å oppdage.
| Vegg | Når den merkes |
|---|---|
| Lisenskostnader | Når brukerne blir mange; prisen kan løpe løpsk med volumet |
| Ytelsestak | Når datamengde eller last vokser utover det plattformen klarer |
| Integrasjoner | Når løsningen må kommunisere med systemer plattformen ikke støtter godt |
| Innlåsing og utflytting | Når dere vil forlate plattformen; løsningen er vanskelig å flytte ut |
Den lumske fellesnevneren er at alle de fire veggene er usynlige i det små og akutte i det store. En løsning som fungerer perfekt for femti interne brukere, kan bli ulønnsom ved fem tusen, umulig å koble mot et nytt ERP-system eller nesten umulig å flytte ut hvis plattformen øker prisen eller legges ned. Det er nettopp derfor et forretningskritisk kjerneprodukt er risikabelt å bygge i low-code: Det er bygget for å vokse, og det er i veksten veggene står.
En beslutningsmodell som tar utgangspunkt i systemet
Spørsmålet «low-code eller skreddersydd» skal ikke avgjøres av teknologipreferanser, men av to egenskaper ved selve systemet: hvor lenge det skal leve, og hvor forretningskritisk det er.
- Kort levetid, lav kritikalitet. Et midlertidig eller internt støtteverktøy. Her er low-code som regel riktig: Det går raskt, er billig, og konsekvensene av begrensningene er små.
- Lang levetid, høy kritikalitet. Et kjerneprodukt som skal bære virksomheten og skille dere ut. Her er skreddersydd utvikling verdt den høyere startkostnaden, for ellers bygger dere fremtiden på grensene i noen andres plattform.
De fleste systemer havner tydelig på én side når man stiller de to spørsmålene. Usikkerheten oppstår i midten, og der er et nyttig kontrollspørsmål: Hva skjer den dagen vi møter en av veggene? Er svaret «da bytter vi verktøy, det gjør ingenting», er low-code trygt. Er svaret «da står hele virksomheten stille», bør dere bygge noe som varer.
Et scenario: riktig verktøy på riktig sted
Et selskap bygde to ting samme år. Det interne verktøyet for å håndtere feriesøknader ble bygget i low-code og var ferdig på et par uker. Det var helt riktig, for verktøyet var internt, avgrenset og ikke sårbart for plattformens grenser. Det kundevendte produktet, som var selve forretningen og skulle skalere, ble utviklet skreddersydd til tross for den høyere kostnaden.
Da produktet noen år senere vokste kraftig, holdt arkitekturen, mens en tenkt low-code-løsning ville ha nådd både pris- og ytelsestaket. Poenget er ikke at det ene er bedre enn det andre, men at de løste hvert sitt problem, og at valget ble tatt ut fra systemet, ikke teknologien.
Står dere overfor valget mellom low-code og skreddersydd for et bestemt system, hjelper vi i Weapp gjerne til med vurderingen ut fra systemets levetid og rolle. Ta kontakt med en beskrivelse av hva dere ønsker å bygge.
Ofte stilte spørsmål
Hva er low-code, kort forklart?
Low-code (lavkode) er plattformer der man bygger applikasjoner i stor grad ved å konfigurere og dra og slippe i stedet for å skrive all koden for hånd. Det gjør at løsninger kan lages raskt, og noen ganger av personer uten dyp programmeringsbakgrunn. Prisen er at man jobber innenfor plattformens rammer: Det plattformen ikke støtter, blir vanskelig eller umulig å bygge.
Når passer low-code best?
For avgrensede, interne behov der hastighet er viktigere enn egenart: et skjema, en godkjenningsflyt, et enkelt internt register eller et verktøy som skal løse et tydelig problem for en avdeling. Der leverer low-code raskt og billig. Jo mer standardisert og internt behovet er, desto sterkere taler det for low-code fremfor skreddersydd utvikling.
Hvilke vegger kan man møte med low-code?
Fire er vanligst: lisenskostnader som vokser med antall brukere, ytelsestak når volumet blir stort, dårlig støtte for integrasjoner mot andre systemer og vanskeligheter med å flytte løsningen ut hvis man vil forlate plattformen. De merkes sjelden i starten, men først når løsningen skal vokse, og det er nettopp derfor kjerneprodukter er risikable å bygge i low-code.
Hvordan velger vi mellom low-code og skreddersydd?
Ta utgangspunkt i systemets levetid og hvor forretningskritisk det er, ikke i teknologien. Et kortlivet, internt støtteverktøy passer for low-code. Et langlivet, forretningskritisk kjerneprodukt som skal skille dere ut, bør utvikles skreddersydd, til tross for høyere startkostnad. Spør dere selv hvor systemet ligger på de to skalaene. Svaret peker som regel tydelig i én retning.