Denne klumme er et debatindlæg og er alene udtryk for forfatterens synspunkter.
Low code eller no code vinder indpas hos flere og flere softwareleverandører, og det er der gode grunde til.
Den vigtigste er, at det er hurtigere og nemmere for brugerne at arbejde med applikationerne.
TechTarget definerer low code-platforme som et visuelt programmeringsmiljø, hvor udviklerne kan hente applikationskomponenter med drag & drop, forbinde dem og skabe mobil- eller netbaserede apps.
Low code er en demokratisering af softwareudvikling, som gør det muligt for alle at være med, lige fra analytikere til produktionschefer som selv kan strukturere de forretningsprocesser og funktioner, de har brug for, uden at skulle bruge tid og penge på eksterne programmører.
De to analytikere Joe Pucciaelli og Serge Findling fra IDC forudser, at over halvdelen at it-cheferne inden 2025 vil bruge low code-værktøjer til at styrke produktiviteten i it- og forretningsdriften.
Gartner er enig og siger, at 65 procent af al applikationsudvikling vil foregå i low code-miljøer inden 2024.
Fuld åbenhed
I min virksomhed har vi fra begyndelsen prioriteret åbenhed og muligheden for at programmere vores software.
Jeg tror, det er nøglen til højere afkast i fremtiden.
Men hverken højere afkast eller low code kommer af sig selv.
For at kunne levere de grafiske værktøjer, som forbinder systemer og transaktioner, skal den bagvedliggende software spille godt sammen med andre systemer.
Nogle virksomheder siger, at de har åbne, programmerbare grænseflader (API’er), men glemmer at fortælle, at disse ofte er designet på baggrund af forhåndsbestemte scenerier, der styrer brugerne over i integration med bestemte produkter.
Det fulde potentiale med low code opnås kun, når hele softwaren er bygget på åbne API’er - ikke kun en lille del.
Det bedste bud i dag er RESTful API’er baseret på Representational State Transfer-arkitekturen.
Man kan også gå skridtet videre og bruge ISO-certificerede OASIS Odata (Open Data Protocol).
Hurtigere integration, nul kode
En robust arkitektur bygget på disse principper giver brugerne mulighed for at anvende low code-løsninger og selv udvikle målrettede applikationer til bestemte arbejdsopgaver, som kobles til andre systemer.
Det kan være enkle opgaver som at automatisere processerne omkring nyansættelser, herunder at opdatere lønsystemet, oprette en ny konto i Outlook 365 og bestille blomster hos den lokale blomsterforretning til den nye medarbejders første arbejdsdag.
Det kan også sende data fra en delstruktur i en produktionsproces ind i det software, der anvendes til at servicere udstyr i forbindelse med en årlig vedligeholdskontrakt.
Den samme løsning kan også sende data fra en delstruktur i en produktionsproces ind i det software, der anvendes til at service udstyr i forbindelse med en årlig vedligeholdskontrakt.
Alle data, handlinger eller funktioner i softwaresystemet skal være tilgængelige i et klart og detaljeret API-bibliotek.
Low code kan også kombineres med machine learning.
Forestil dig, at en produktionschef skal sende en tekniker ud til en kunde på et bestemt tidspunkt. Teknikeren skal have en specifik kompetence og være certificeret for kunne hjælpe kunden.
Her kan AI og machine learning-modeller anvendes til at træffe valg i automationsapplikationen og beslutte næste skridt. Det sker ved hjælp af et bibliotek af API’er og intelligent procesautomation.
”Hvad så med udvikling af ny funktionalitet?” tænker du måske som udvikler.
Det findes der også en low code-løsning på. En som kan bygge branchespecifikke funktioner billigere og i bedre kvalitet.
Ved hjælp af Domain Specific Language (DSL) bliver man ovenikøbet beskyttet ved fremtidige teknologiændringer som for eksempel når funktionerne på mobiltelefonen redesignes.
DSL kan beskrive, hvad hensigten med en applikation er frem for hvordan den teknisk set skal gennemføres.
I min virksomhed bruger vi den samme DSL-definition af sider i brugerinterfacet på tværs af webbrowsere og Android, iOS og Windows.
Det betyder, at ændringer kan implementeres med mindre forstyrrelse af brugerne, og at softwareudviklingen foregår hurtigere.
Det er årsagen til, at vi har forpligtet os til et low code og no code-mål.
Hvor dur det ikke?
Er low code det nye vidundermiddel?
Jeg er som sagt begejstret over de mange anvendelsesmuligheder, men som med al ny teknologi er det ikke svaret på alt, og der er situationer, hvor man bør undgå at bruge low code, i hvert fald ind til videre.
Det gælder blandt andet, når man skal implementere algoritmer for at udføre procesautomatik - ofte med store datamængder.
For eksempel beregner planlægnings- og optimeringsmotoren i vores system hvert sekund millioner af arbejdsplaner for serviceteknikere.
Det ville være ekstremt udfordrende - ja faktisk umuligt - at udvikle den type motor med low code, og det ville resultere i markante perfomance-tab.
Generelt er software i de nedre arkitekturlag herunder operativsystemer, databaser og middleware uegnede til low code.
Derudover skal man være opmærksom på, at markedet for low code-platforme stadig er relativt nyt.
Derfor er sandsynligheden for en konsolidering stor, hvilket vil sende mange af platformene ud i kulden, enten fordi de fejler, eller fordi videreudviklingen af dem stopper.
Den slags usikkerhed har man ikke med traditionelle programmeringssprog som Java og C#.
De forsvinder ikke bare og vil stadig blive understøttet af branchen de næste årtier.
Så hvis du bygger noget, hvor du ikke tør løbe risikoen for at skulle migrere til en anden platform i løbet af de næste få år, så skal du tænke en ekstra gang over, om du vil bruge low code.
Klummer er læsernes platform på Computerworld til at fortælle de bedste historier, og samtidig er det vores meget populære og meget læste forum for videndeling.
Har du en god historie, eller har du specialviden, som du synes trænger til at blive delt?
Læs vores klumme-guidelines og send os din tekst, så kontakter vi dig - måske bliver du en del af vores hurtigt voksende korps af klummeskribenter.
