Innehållsförteckning
Samtidigt är lågkod inte ett sätt att runda IT eller slippa tekniskt ansvar. I det här inlägget får du veta mer om vad lågkod är, hur det skiljer sig från no-code, varför det blivit populärt och när det passar bäst att bygga själv, involvera utvecklare eller ta hjälp av en partner.
Vad är lågkod?
Lågkod, eller low-code, är ett sätt att utveckla applikationer med hjälp av färdiga komponenter, visuella gränssnitt, konfiguration och mindre mängd handskriven kod. I stället för att varje del byggs från grunden kan utvecklaren eller användaren utgå från färdiga byggblock för till exempel formulär, arbetsflöden, vyer, behörigheter, datamodeller och integrationer.
Lågkod betyder inte att kod försvinner. Den finns ”under ytan”, medan plattformen hanterar mer av standardarbetet. Hos Multisoft innebär utveckling i lågkodplattformen Softadmin® ofta att vi kan bygga 5–20 gånger snabbare än traditionell utveckling, samtidigt som kravinsamling, anpassning, testning och säkerhet fortfarande är centrala delar av arbetet.
Low-code och no-code benämns ofta tillsammans, men de löser inte riktigt samma sak. No-code riktar sig främst till användare som inte kan programmera och passar bäst för enklare appar, formulär, automationer och prototyper, eller som en del av ett befintligt system där användaren kanske inte ens är medveten om att ”kodning sker”. Low-code ger mer tekniskt utrymme och används oftare när lösningen kräver mer logik, integrationer, datamodeller eller möjlighet att komplettera med kod.
Vad är ett lågkodssystem?
Ett lågkodssystem är en applikation eller ett system som har byggts helt eller delvis med hjälp av en lågkodsplattform. Det kan vara en enkel intern app, men också ett mer avancerat systemstöd för en eller flera specifika processer.
Plattformen ger dig färdiga funktioner och strukturer som gör utvecklingen snabbare. Samtidigt behöver du förstå vad plattformen är bra på och var den sätter gränser.
Ett lågkodssystem passar ofta när:
- Verksamheten behöver komma i gång snabbt/göra en pilot
- Lösningen behöver kunna ändras över tid
- Manuella moment behöver ersättas med ett mer strukturerat arbetssätt
- Processen är tydlig men för verksamhetsspecifik för ett standardverktyg
Det passar inte alltid när kraven på prestanda, teknisk kontroll eller speciallogik är mycket höga. Det kan också handla om hur många avvikelser som är okej att släppa igenom eller att regler begränsar det som kan eller bör utvecklas. Då kan traditionell utveckling eller låkod med ett skräddarsytt system vara ett bättre alternativ.
Tips!
Många väljer att bygga ett test eller en POC först för att testa och utvärdera behovet för att sen gå över till en lösning som byggs och förvaltas av en partner.
Varför är lågkod populärt?
Lågkod är populärt eftersom många organisationer har fler digitaliseringsbehov än vad traditionella utvecklingsprocesser hinner hantera. Medarbetare ute i organisationen vill testa idéer, automatisera manuella moment och få bättre stöd för processer som inte passar perfekt i befintliga system.
Samtidigt behöver IT hantera säkerhet, drift, integrationer, datakvalitet och förvaltning. Lågkod kan därför bli ett sätt att öka utvecklingskapaciteten utan att allt byggs från grunden och du kan i många fall involvera resurser som inte har samma kompetens.
Gartner beskriver hur utvecklarrollen förändras när AI och automatisering får större betydelse i mjukvaruutveckling. Rollen rör sig mer mot problemlösning, design och kvalitetssäkring, men inte bort från ansvar. Det är en rimlig bild även för lågkod: när mer grundarbete automatiseras blir helhetsförståelsen viktigare.
Men lågkods positiva egenskaper kan också skapa problem. Om det blir för enkelt att bygga utan gemensamma ramar kan organisationen få många appar, otydliga ägarskap och svårförvaltade lösningar. KPMG lyfter just risken att low-code och no-code kan bidra till ”shadow IT” om utvecklingen sker utanför etablerade arbetssätt och godkända plattformar. Det är vanligt i större organisationer som har en komplex IT-miljö, där individer eller team tar saken i egna händer, och löser problem. Som i sin tur skapar ny problematik.
3 sätt att bygga med lågkod
Bygg själv när risken är låg, bygg med utvecklare när tekniken är viktig och bygg med partner när behovet är specifikt, långsiktigt och kräver förvaltning.
Lågkod och AI
AI gör lågkod mer kraftfullt, men inte automatiskt mer kontrollerat. Många plattformar får nu funktioner där AI kan hjälpa till att skapa formulär, föreslå arbetsflöden, generera kod, skriva dokumentation eller bygga appar utifrån textinstruktioner.
Det kan göra det ännu snabbare att komma i gång. Men det gör också granskning viktigare. AI kan föreslå en lösning, men den vet inte alltid vilken data som är känslig, vilka regler som gäller i organisationen eller vilka undantag som uppstår i processen, och hur de bör hanteras.
McKinsey har visat att generativ AI kan göra utvecklare snabbare i vissa kodningsuppgifter, men effekten varierar beroende på uppgiftens komplexitet. Det är därför klokt att se AI som ett stöd i utvecklingsarbetet i dagsläget.
1. Bygga själv med lågkod
Att bygga själv med lågkod kan vara mycket effektivt när ni har rätt kompetens och tydliga ramar. Det kan ge verksamheten möjlighet att testa idéer snabbt och låta personer nära processen vara mer delaktiga i lösningen. För team med tekniskt kunniga medarbetare kan lågkod också bli ett sätt att avlasta IT och korta ledtider.
Fördelen är att organisationen kan arbeta snabbare, lära sig genom att testa och bygga närmare användarna. Bygg själv när behovet är tydligt, risken är hanterbar och det finns personer som kan äga lösningen över tid. Men som sagt, var mer försiktig när lösningen hanterar känsliga data, påverkar många användare eller blir beroende av flera andra system.
2. Utveckla i lågkod med hjälp av utvecklare
Många mer seriösa lågkodssatsningar drivs inte av verksamheten, utan av IT som använder lågkod för att bygga snabbare. Det är en viktig distinktion.
När utvecklare använder lågkod kan organisationen få upp tempo utan att tappa teknisk kvalitet. Utvecklarna kan bedöma datamodeller, integrationer, säkerhet, prestanda och testning. Samtidigt slipper de bygga allt ”från början”.
Risken är att plattformen ändå sätter gränser. Om lösningen kräver mycket speciallogik, ovanliga användarflöden eller särskilda prestandakrav kan lågkod bli trångt. Då behöver teamet tidigt bedöma om plattformen räcker till.
3. Bygga med en lågkodspartner
I många fall vill organisationen ha lågkodens hastighet, men inte bygga själva. Då kan en partnerdriven lågkodslösning vara relevant.
Det innebär att en extern partner använder en lågkodsplattform för att bygga, anpassa och vidareutveckla ett system åt organisationen. Fördelen är att du får tillgång till ett färdigt arbetssätt, teknisk erfarenhet och förvaltning. Nackdelen är att man blir beroende av partnern och plattformen, vilket gör långsiktighet och transparens viktiga.
Det är inte rätt för alla. Har ni stark intern utvecklingskapacitet (som har tid över) och vill äga byggandet själva kan en självbetjänad plattform vara bättre. Men om behovet är specifikt, långsiktigt och kräver förvaltning kan lågkod med partner vara ett sätt att få till både anpassning och ansvar.
