Lav-kode - raskere design og implementering av applikasjoner og IT-systemer.

**automatisk oversatt tekst**

Low-code ser ut til å være en etterlengtet og optimal løsning for gründere, fordi den lar dem delta direkte i utformingen og implementeringen av løsningen de har laget. Dermed er kanonen av forretningsstøtteverktøy utvidet med en annen innovativ kategori av løsninger.

Hva er lavkode?

Ønsker du å finne lavkodepublikasjoner på nett, vil du oftest støte på de som beskriver lavkodeprogramvare samt lavkodede digitale plattformer (LCDP – Low Code Digital Platform). Dette er verktøy som bruker en helt ny måte å programmere på. Programmering med lav kode. Det betyr bokstavelig talt å programmere en gitt IT-løsning med en liten mengde kode.

Denne forklaringen kan imidlertid virke vanskelig å forstå, så det er verdt å sette den sammen med den tradisjonelle måten å utvikle programvare på, slik at alt blir klart.

Standard programmering

Opprettelsen av et nettsted, dedikert applikasjon eller IT-system begynner etter at klienten har akseptert modellen eller prototypen til prosjektet. Først planlegges en arbeidsplan, og til slutt går programvareingeniører og et dedikert team av programmerere inn i handlingen.

En av de tidlige stadiene av programmering er å skrive kildekoden. For at et enkelt kontaktskjema skal opprettes, for eksempel, må utvikleren skrive kode som beskriver hvert element i skjemaet. Koden inkluderer også informasjon (innebygd eller lest fra en ekstern fil) om formatering av et slikt skjema, inkludert:

dens dimensjoner, farger, tilgjengelige rammer,
hvordan teksten vil bli vist (font, størrelse, farge, stil, mellomrom),
hvordan den vil bli plassert i forhold til andre elementer, for eksempel overskrifter eller marginer på nettstedet.
Vi ser det utarbeidede skjemaet som sluttbrukere. Dette er imidlertid ikke alt, fordi det er flere som skal programmeres:

typer skjemafelt og hvordan du behandler innholdet deres,
regler som bestemmer riktigheten av de angitte dataene,
ekstra handlingsknapper (f.eks. legg ved en fil, send),
avhengigheter mellom dem.
Når det gjelder et felt, programmerer utvikleren hvordan det skal fylles ut og hva som vil skje når disse betingelsene er eller ikke oppfylles av personen som fyller ut skjemaet.

Eksempler på skjemafeltprogrammeringsregler:

obligatoriske felt er tradisjonelt merket med "*",
feltet for å angi e-postadressen skal alltid inneholde "@"-symbolet,
på samme måte, når du prøver å endre passordet - i dette feltet har programmereren allerede definert minimum antall tegn og hvilke spesialtegn det skal inneholde eller hvilke som ikke er tillatt. Etter at disse betingelsene er oppfylt, vil vi kunne endre dem - ellers vil vi motta en feilmelding,
GDPR-bokser som brukeren velger for å samtykke til behandling av personopplysninger for et bestemt formål.
Formatering av skjemaet som diskuteres i dag er en halvautomatisk prosess. Programmereren trenger ikke å skrive hele kildekoden, men kan sette inn en klar komponent (f.eks. en tabell). På sin side, for å implementere en gitt funksjon, kan han bruke konsollen, som vil fortelle ham hvilken del av koden han skal angi.

Til tross for disse fasilitetene, er implementeringsprosessen fortsatt tidkrevende, spesielt når det gjelder mer komplekse applikasjoner eller systemer. Det samme gjelder for integrering av systemer fra ulike leverandører. Det er da nødvendig å programmere en spesiell API (Application Programming Interface)-kobling mellom dem.

En ytterligere hindring er mangelen på et tilstrekkelig antall programmerere på IT-markedet i forhold til dagens etterspørsel.

Programmering med lav kode

Målet med lavkode er å redusere utviklings- og konseptuell tid og samtidig gå fra designfasen til å implementere en digital løsning.

En av de største fordelene med denne løsningen er det faktum at vi helt fra starten påtar oss rollen som designer, selv om vi ikke har typiske programmeringskunnskaper eller ferdigheter. Vi har et grafisk brukergrensesnitt (UI, User Interface) til rådighet, slik som i for eksempel grafiske programmer eller til og med i populære CMS-er.

Fra panelnivå velger vi de riktige komponentene som skal være en del av prosjektet vi lager. For eksempel vil det kreve at det opprettes for eksempel en feriesøknad for å bli fullført. Da strekker vi oss etter ferdige maler i brukerpanelet, for eksempel i form av et dynamisk skjema, og modifiserer dem etter våre behov.

Ved hjelp av grensesnittet designer vi utseendet til applikasjonen, endrer fargen på skjemaet, fonten og legger til nye felt. Ved første øyekast ligner dette på formbyggende verktøy, men det er en viktig forskjell. Hvert av skjemafeltene kan 'programmeres' akkurat som en programmerer som skriver kildekoden, men på en mer intuitiv måte - ved å velge et tekstfelt og velge en passende funksjon fra rullegardinlisten.

Eksempler på applikasjonsprogrammering:

definere et obligatorisk felt - vi 'programmerer' vanligvis ved å krysse av for for eksempel JA / NEI ved siden av funksjonen, som tilsvarer å sette inn det nødvendige elementet i kildekoden av programmereren.
legge til et vedlegg, spesifisere filtypen og dens vekt. Det er likt her - vi kan sjekke om vi vil la sluttbrukeren legge til en fil, dens type (PDF, docx) og størrelse, for eksempel opptil 20MB.
sette inn et felt, for eksempel årsaken til klagen, og legge til fra rullegardinlisten som lar ett eller flere alternativer velges.
I tillegg til muligheten for å lage skjemaer har plattformene også BPM (Business Process Management) / Workflow-verktøy for styring og planlegging av prosesser og arbeidsflyter. Takket være dem er det mulig å enkelt tegne en gitt prosess, avhengigheter mellom alle dens elementer og definere forhold som påvirker prosessen.

Bedrifter bruker ofte disse verktøyene når de planlegger systemene sine slik at implementeringsbedriften har et komplett bilde av hvordan prosessene i organisasjonen fungerer og henger sammen. For å gjøre dette må du først definere hovedtrinnene for prosessen og deretter sette dem som elementer på diagrammet.

Eksempelstadier i en enkel prosess basert på klagesøknaden:

fylle ut og sende klagesøknaden fra kunden:
ankomst av søknaden, dens klassifisering og registrering i systemet (tilordning av et referansenummer),
automatisk e-postbekreftelse om aksept av søknaden,
behandling av søknaden og utstedelse av vedtak,
tilbakemelding til kunden (resultat av klagen).
Helt i begynnelsen vil det bare være et statisk diagram med store trinn. Deretter går vi videre til programmering av helhetlig forretningslogikk og avhengigheter mellom elementer i diagrammet – vi designer arbeidsflyten. Vi gir dem strømningsretningen, vi definerer hvilke betingelser som skal oppfylles for å kunne gå videre til de neste trinnene, og hva som skal skje når vi går til neste trinn.

Til dette formål bruker vi en spesiell seksjon i brukerpanelet, som har forhåndsdefinerte funksjoner - handlinger som vil bli utført etter å ha oppfylt eller ikke oppfyller visse betingelser.

Eksempler på handlinger og avhengigheter:

1. Fylle ut søknaden fra klienten:

positiv bekreftelse: klienten har fullført søknaden riktig, lagt til et vedlegg i riktig format, "Send"-knappen er aktiv.
negativ bekreftelse: for eksempel at kunden ikke valgte årsaken til klagen, vises en passende melding som ber om fullstendig utfylling av søknaden.

2. Registreringer av søknaden sendt av kunden i systemet:

klassifisering og innledende registrering av søknaden: tildelt den aktuelle kategorien på grunnlag av den valgte årsaken til klagen, nummeret på søknaden er gitt.
verifisering av innholdet i applikasjonen og et forsøk på å automatisk løse problemet basert på eksisterende løsningstilstand

3. Videresending av søknad for videre sirkulasjon:

søknaden sendes fra riktig avdeling,
på tidspunktet for tildeling av verifikatoren, blir varslingsstatusen tildelt,
det sendes en e-post til kunden med status og sporbarhet.

Dette er bare noen få enkle eksempler på forretningslogikk tilgjengelig som lavkode. Det kan imidlertid skje at vi ikke finner den nødvendige handlingen. Deretter kan vi holde musepekeren over et gitt diagramelement og vise den skjulte kildekoden og modifisere den slik at det er mulig å utføre den gitte funksjonen.

På denne måten transformerer lavkodeplattformer tradisjonell, men også tidkrevende programmering til en mer dynamisk prosess skreddersydd for forretningsmiljøets behov. De ble opprettet med tanke på å fokusere på prosessdesign og gi spesifikke løsninger.

En gitt prosess kan designes av bare én person som jobber i forretningsmiljøet på daglig basis og har forretningslogikkferdigheter. I tillegg vet han hvordan han skal løse problemer ved å bruke sin praktiske kunnskap i kombinasjon med spesifikke IT-ressurser i organisasjonen.

Det er verdt å vite at begrepet "Citizen Developer" ble laget for folk som utfører denne funksjonen, og etterspørselen etter spesialister på dette feltet vokser stadig.

Hvilke lavkodeprosjekter?

Den nye typen programmering medfører ingen begrensninger i så henseende.

Uavhengig av hvilken bransje vi opererer i, vil vi designe og implementere blant annet:

et enkelt skjema, for eksempel en feriesøknad eller en klage,
prosessen med for eksempel å samle bestillinger i organisasjonen og sende dem til en pålitelig leverandør,
en enkel mobilapplikasjon for kunder, men også en omfattende eBOK-plattform (selvbetjening),
programvare i full størrelse inkludert alt det ovennevnte.
MVP (Minimum Viable Product) prosjektledelse og lavkode prosjektledelse er en veldig god kombinasjon. For eksempel er det mulig å lage en enkel applikasjon for kunder for å sende inn klager og spore status for søknaden deres. I de neste stadiene, legge til en annen funksjon, for eksempel en enkel kundetilfredshetsundersøkelse, og deretter utvide den videre.

En interessant applikasjon av lavkodedesign er å lage enkle applikasjoner som svarer til selskapets interne behov. Takket være dette er det mulig å løse hverdagslige problemer og forkorte tidkrevende aktiviteter, for eksempel konsolidering av data fra flere kilder og rapportering. En Excel-arbeidsbok som inneholder statiske data kan bli et enkelt program som analyserer dataene for oss og gir rask tilgang til informasjon.

På den annen side, hvis vi bruker avansert salgsrapporteringsprogramvare, er det mulig å vise KPI eller andre data i form av en widget (oppdatering i sanntid). Det kan for eksempel være synlig på hjemmesiden i en søknad for salgsrepresentanter og gi tilbakemelding på salgsresultater.

Lav kode i virksomheten

Som vi allerede har nevnt, er arbeidsoptimalisering eller rask utgivelse av applikasjoner til markedet med lave applikasjonsutviklingskostnader realitetene i dagens virksomhet.

Så vil den tradisjonelle tilnærmingen til programmering bli en saga blott, og vil lavkode erstatte den?

Det skal bemerkes at tradisjonell programmering allerede gjennomgår en enorm transformasjon. Den begynner å stole på automatisering, og utviklere leter etter nye måter å optimalisere arbeidet sitt på. De har allerede spesialisert seg på programmering med bruk av kunstig intelligens, Power Business Intelligence eller IoT (Internet of Things) løsninger. Design en enkel applikasjon eller din egen chatbot i dag, for eksempel takket være Microsoft Power Apps-løsningen, som er en lavkodekomponent i Power Platform.

Dessuten fremmer Gartner-organisasjonen lav-kode-praksis ved å belønne skaperne av denne typen plattformer og nøye observere deres videre utvikling. Det kan også sies at lavkode på en måte er et kompromiss innen programmering og definitivt har redusert den eksisterende avstanden mellom forretningsverdenen og IT.