Skräddarsy din applikation med low-code

Behov av tempo

De allra första besluten man fattar när man väl bestämt sig för att starta ett applikations-projekt handlar ofta om teknik - vilket i viss mån sätter ramarna för initiativet som helhet. Man bör noggrant överväga teknik baserat på vad man har kompetens och resurser kring. Om man köper in all utveckling låter man kanske en utvecklingspartner göra alla val, men valen måste göras. I de flesta fall måste man stödja flera operativsystem och dessutom passa in i ett befintlig ekosystem av gamla applikationer.

Fokus på VAD inte HUR

Detta är ett område där low-code plattformar och traditionell programmering skiljer sig åt på ett tydligt sätt. När man valt en low-code plattform - har man lagt valet på plattformen och slipper således fundera så mycket på tekniken. Det är ju hela idén. Eftersom mindre fokus behöver läggas på tekniken och HUR - så kan man lägga desto mer fokus och resurser på VAD man vill skapa.

Möjlighet att växla tid och resurs mot återanvändbara integrationer

Att slippa välja teknik och arbeta på en low-code plattform kan öka tempot med upp till 10x baserat på vad och vilken typ av applikation man ska skapa. Men - det betyder inte att det inte finns jobb som kan handla om traditionell programmering. En low-code plattform bör innehålla möjlighet att addera kod på tre nivåer för att säkerställa att man inte målar in sig i ett hörn. Se bild:

Utveckling av applikationen över tid

“Visst går det snabbt att bygga nya applikationer med low-code-verktyg. Men den största fördelen är att det går mycket snabbt att ändra applikationerna.”

När man jämför low-code med traditionell utveckling är det i slutändan användarna som märker den största skillnaden. När man behöver göra förändringar och justeringar av applikationerna över tid, så kan förändringar publiceras direkt - och användarna får tillgång till ny funktionalitet - troligtvis i mycket snabbare takt än de är vana vid.

Vid traditionell utveckling lanserar man ofta en första version av applikationen och sedan skapar man specifikationer för kommande, vidareutvecklade versioner. Här behöver man planera vidareutveckling med hänsyn till de olika teknologier som används. Kanske har man byggt applikationen på .net i grunden och programmerar användarupplevelsen i HTML eller Angular.

Low-code levereras som en full-stack lösning vilket innebär att förändringar “slår igenom” databas/er, applikationslogik och användargränssnitt på samma gång. Allt hänger ihop automatiskt vilket gör att ändringar kan publiceras med ett knapp-tryck och användarna kan få tillgång till förändringarna direkt.

Fler applikationer över tid

Om man valt en low-code plattform istället för att arbeta med traditionell programmering - har man antagligen gjort ett smart val och slipper fundera så mycket på tekniken. Det är ju hela idén.

Nuförtiden lever en applikation väldigt sällan som en isolerad ö - utan kontakt med omvärlden. En del av den tid och resurser man vinner med low-code kan man med fördel flytta till att öka fokus på bra och återanvändbara integrationer. Det kommer att öka hastigheten ytterligare när man ska addera nya low-code applikationer på plattformen - och då återanvända färdigbakade integrationer mot andra appar i ekosystemet.

Low-code arkitektur - kod eller modell?
Det finns två olika arkitekturella ansatser: För det första finns det leverantörer som tillhandahåller en kodgenerator. Dessa leverantörer levererar en utvecklingsmiljö för visuell applikationsutveckling som förenklar skapandet - men när den är klar genererar plattformen exekverbar kod.

Den andra tekniska ansatsen är modell-driven. I detta fall genereras för användaren visuella applikationer som rent tekniskt är en representation av den aktuella applikationen som plattformen tolkar och exekverar direkt vid användning. Det låter kanske lite komplicerat - men skillnaden är att man inte skapar ny kod för varje ny applikation och befintliga integrationer kan återanvändas på ett enkelt sätt.

De 3 arterna

Liksom biologin sorterar in allt levande i domäner, klasser och arter kan man kategorisera olika typer av It-system. Några vanliga begrepp, som man ofta stöter på inom affärsapplikationer är “Best of Breed”, “Monolithic” och “Tailored”. I princip kan man översätta detta till specialist-, generalist- och skräddarsydda system. När man ska skaffa ett nytt system behöver man göra en avvägning mellan dessa tre huvudkategorier - ska vi skaffa ett system som är framtaget för sitt ändamål, ett allomfattande system - eller skräddarsy för att passa perfekt för våra behov. När det gäller grundläggande system såsom affärssystem (ERP) är en skräddarsydd lösning i princip aldrig ett bra alternativ - då är det bra att använda det som finns färdigt på marknaden. När det gäller specialist-system blir ofta frågan lite öppnare. Ska vi välja ett CRM system som finns på marknaden - eller bredda affärsystemet med CRM funktionalitet. Eller - har vi ett unikt och konkurrenskraftigt arbetssätt som vi vill stödja perfekt med hjälp av skräddarsytt? Här hamnar man i gränslandet mellan Generalist (Monolithic) -system och Specialist (Best-of-breed) -system. Just här - i gränslandet mellan specialist- och generalist-system passar low-code perfekt. För många företag har det varit för dyrt och komplicerat att bygga en helt specialanpassad applikation, trots att det skulle vara det bästa för att kunna uppfylla behoven helt perfekt. Men med traditionell programmering blir det ofta för dyrt och oöverskådligt avseende leveranstider. Low-code gör det möjligt att bygga specialanpassade applikationer - skräddarsydda - till en bråkdel av tid och kostnad. Low-code kan ses som det bästa av två världar. Man bygger en skräddarsydd lösning med hjälp av standardmoduler som minimerar behovet av traditionell programmering och allt vad det innebär i form av dyra resurser, buggar och försenade projekt.

Generalistsystem (Monolitiska)

Begreppet monolitiskt system används ofta för applikationer som erbjuder allt som verksamheten behöver. Det kan vara allt från kundbearbetning till transport och logistikflöden inklusive bokföring och rapportering. Om man köper allt inom en och samma applikation från en leverantör i ett system som finns “på hyllan” så upplevs det ofta som enkelt och försvarbart. “Vad skönt att allt är integrerat”. Nackdelen är ofta att ingenting blir perfekt anpassat efter verksamheten - det blir lite vaniljsmak över det hela - och specialanpassningar (konfigureringar) kan bli väldigt kostsamma. Tiderna förändras - och möjligheterna med den. Många affärssystem som går att köpa “från hyllan” idag innehåller 1000-tals funktioner och färdiga moduler. Från ett harmoniserings-perspektiv kan det verka bra, man har ett helintegrerat verksamhetssystem och kan fokusera på annat. Verkligheten är ofta en annan - även standardsystem behöver konfigureras för att passa ditt företags unika behov, vilket ofta innebär stora kostnader och långa leveranstider. Hur ofta har vi inte kunna läsa om IT projekt som drar ut på tiden och spräcker budget. Men det finns även ett annat intressant perspektiv på detta - om alla företag jobbar i liknande färdiga “från hyllan produkter” - vad händer då med företagens unicitet och konkurrenskraft? ​Bildtext: Ofta kan man se low-code som ett agilt komplement till de Best-of-breed och monolitiska affärssystemen som man redan har i sin applikationsportfölj. När du har behov av att ta fram en ny applikation eller förnya en utdaterad är det flera saker du bör utvärdera för att välja rätt väg framåt. Vilken typ av applikation gäller det? Finns det standardsystem på marknaden för ändamålet? Vilka krav finns det gällande unika anpassningar, tid och budget? I stort kan man tala om tre alternativa spår.

1. Konfigurering av standardsystem
   Även känd som ”off the shelf” på engelska. Det är tänkt att man ska kunna skräddarsy applikationens funktionalitet inom ramarna för ett administrativt system. Men i många fall, speciellt hos stora företag och organisationer, är en färdig applikation sällan färdig. Istället krävs det omfattande anpassningar, ofta i form av ett tillägg av anpassad kod.
   
2. Traditionell utveckling
   Med traditionell utveckling menas det att utvecklaren skriver kod i en textredigerare och kompilerar koden till färdiga programfiler. Det finns många hjälpmedel och förenklade metoder, men i slutänden handlar det om manuell produktion av kod.
   
3. Low-code
   Med hjälp av grafiska utvecklingsverktyg bygger utvecklaren applikationer med en minimimängd kod.Man kan säga att utvecklaren konfigurerar applikationen från början och lägger därefter till den kod som inte finns i standardbiblioteket.

Skräddarsydda system

Som namnet indikerar så är skräddarsydda applikationer byggda för att passa behoven perfekt. Fördelen är givetvis att användarna får ett verktyg som är anpassat efter behoven - varken mer eller mindre. Det finns tillfällen då skräddarsytt är enda möjligheten - men med alla de verktyg som finns att köpa från hyllan är det ganska ovanligt när man talar om olika typer av affärsapplikationer. Pratar vi om affärsunika processer så bör man förstås inse på att systemstödet för just de unika processerna är en del av kärnverksamheten och med ett standardsystem kan man därför inte räkna med att nå de konkurrensfördelar som ett egenutvecklat system kan innebära. Grundfilosofin bakom skräddarsydda lösningar är att man vill att behovet ska styra applikationen och inte tvärtom. Det är en ganska vanlig missuppfattning att det är billigare och bättre att köpa standardsystem, eftersom man får mycket funktionalitet “på köpet”. Problemet är dock att man ofta tvingas anpassa arbetssätt och processer efter verktygen, eftersom det kan vara både dyrt och krångligt att konfigurera om standardsystemet. Alltför ofta köps standardsystem in, varefter man upptäcker att några nödvändiga funktioner inte uppfylls. Om man kommer fram till att det är bäst att bygga en skräddarsydd lösning, så kan det med traditionell utveckling bli alltför kostsamt. Det är svårt att hitta programmerare och leveransprecisionen minskar med storlek på system och inbyggd komplexitet. Här kan low-code vara ett bra alternativ att utvärdera. Med low-code får man det bästa av båda världar. Det går att bygga applikationer som är perfekt anpassad efter behoven dvs. att skapa ett skräddarsytt system, men man bygger det på en standardplattform av färdiga komponenter.

Specialistsystem (Best of breed)

Marknaden för färdiga (från hyllan) specialist-system (best of breed) är i det närmaste oändlig. Det finns applikationer som är anpassade för vissa uppgifter, till system för branscher och roller. Här hittar man system för tidsbokning, logistik, rekrytering, marknadsföring, försäljning, till branschsystem för applikationer för bank & finans, bygg & fastigheter, utbildning och tillverkande industri… När man tittar på de här specialist-system blir ofta frågan lite öppnare när man resonerar kring Low-code som ett alternativ. Ska vi välja ett färdigt CRM system som finns på marknaden? - eller bredda affärsystemet med CRM funktionalitet? Eller - har vi ett unikt och konkurrenskraftigt arbetssätt som vi vill stödja perfekt med hjälp av skräddarsytt? Med de möjligheter low-code ger, att bygga perfekt anpassade system för verksamheten snabbt och billigt, verkar trenden gå mot att överväga skräddarsydda verktyg allt oftare. I affärslogiken ligger att man fokuserar på sina processer, flöden och arbetssätt i första hand och själva verktyget i andra hand. Genom att bygga ett specialanpassat system får man något som passar organisationen, kunderna och användarna som handen i handsken och skräddarsydda applikationer är inte översållade med funktionalitet som aldrig används - och som i värsta hand distraherar användarna. För att påbörja utvärderingen av low-code jämfört med färdiga specialist-system kan det vara bra att ställa sig följande frågor:

• Det krävs jobbiga anpassningar?

Är dyrt och krångligt att bygga ut existerande applikationer?

Många företag börjar med att basera sin verksamhet på ett standardmässigt affärssystem, med moduler som hanterar ekonomihantering, logistik, och så vidare. Med tiden tar man sig an fler specialiserade funktioner, som kan vara specifika för den bransch som företaget är verksamt i eller för hur verksamheten sköts på just det företaget. Det kan också handla om innovativa beslut för att sköta verksamheten på smartare sätt än konkurrenterna. I samtliga fall behövs IT-stöd och det naturliga stället att ordna det är i affärssystemet. Det här resonemanget gäller även om ett någon annan typ av standardsystem än ett affärssystem, anpassat för den aktuella verksamheten och/eller branschen, används. Poängen är att det uppstår specialiserade behov av IT-stöd som man vill uppfylla med ett system som redan finns på plats. Det kan i lika hög grad handla om ett existerande applikationer (system) som man har byggt själv. Det togs i drift med ett visst syfte, att vara IT-stöd för en bestämd samling processer, arbetsuppgifter och en för en viss affärsmodell. När nya behov uppstår är det naturligt att fundera på om det går att bygga ut funktionaliteten för den egenutvecklade applikationen. I många fall låter det sig helt enkelt inte göras att lägga till ny funktionalitet för vare sig standardsystem eller egenutvecklade applikationer. Det kan vara så enkelt som att den nya funktionaliteten helt enkelt inte ryms inom applikationens arkitektur, att den färdiga lösningen skulle bli både tekniskt och användarmässigt komplicerad och tungrodd. I andra fall är det orimligt komplicerat, tidsödande och dyrt att bygga ut och anpassa funktionalitet i existerande applikationer. De flesta skräckhistorier om misslyckade implementationer av affärssystem har till exempel sina rötter i den här problematiken. Det som skulle vara snabba ”anpassningar” och ”konfigurationer” av befintlig funktionalitet, för att uppfylla specialiserade behov, kan bli till mardrömmar. Många företag hamnar då i ett läge där följande alternativ återstår:

• Köpa en applikation från hyllan

Finns det standardsystem som uppfyller kraven?

Om det finns ett standardsystem som uppfyller både nya och gamla behov på ett bra sätt så är det självklart att titta närmare på det. Men risken är stor att något av följande gäller:

• Det krävs jobbiga anpassningar ( se fråga 01).

Kommer applikationen att behöva utvecklas och byggas på över tid?

Om beslutet går i riktningen att bygga en egen applikation så blir nu frågan om den ska byggas på en low-code-plattform eller på en traditionell plattform som kräver kod. ​ För att ta ställning till det är det viktigt att börja blicka framåt för att förstå hur applikationen kommer att leva och utvecklas över tid. Vi vet att det är svårt att ha projekttänk för digitala initiativ idag, med en början och ett slut. Då omvärld, marknad och organisation är i ständig förändring betyder det att även behoven förändras. Det gränssnitt eller det systemstöd som är atraktivt och effektivt idag kanske helt tappat relevans om några månader. Mycket talar därför för att satsa på plattformar som främjar att det går snabbt och enkelt att förändra, bygga på och bygga nytt. De stora skillnaderna mellan low-code-verktyg och traditionella verktyg landar ofta in i kostnad och enkelhet. På low-code-plattformarna går det betydligt enklare och snabbare att både skapa applikationen från början och att ändra och förfina över tid, just tack vare att du kan använda dig av dra-och-släpp och slipper använda kod. En stor fördel är också att du inte behöver använda dig av de traditionella utvecklarna, som ofta är hårt belastade med annat, utan kan utnyttja affärs-människorna som faktiskt är de som sitter på behoven. Här är en artikel från IDG som hänvisat till citat från Siemens på ämnet. ​ Låt oss nu fylla på med ytterligare ett starkt argument för low-code, genom att titta på steg 4.

Är det troligt att det kommer uppstå behov av fler nya applikationer?

I de flesta organisationerna finns det ofta ett stort lager av applikationer i lagret ovanpå standardsystemen - alltifrån avancerade Excel till olika typer av lösningar i Sharepoint, Filemaker eller Lotus Notes. I större bolag kan de handla om tusetals applikationer i detta lager, som skapar ett virrvarr av kopplingar och integrationer. Dessa applikationerportföljer är ofta IT-chefernas stora huvudvärk, då de både driver kostnader och skapar osäkerhet och brist på kontroll. Samtidigt finns det ofta en god anledning till att var och en av de olika applikationerna finns. De flesta apparna och systemstöden är trots allt framtagna för att skapa bättre affärsnytta i något led. Om allt tvingas ner i standardsystemen finns stor risk att företaget inte sticker ut och tappar konkurrenskraft. Med tanke på hur snabbt omvärld och förutsättningar förändras idag kommer behovet av nya applikationer bara att bli större. Svaret på frågan är därför enkelt - det kommer med säkerhet uppstå behov av fler applikationer inom organisationen över tid. ​ Vad talar då för low-code-plattformen om det ska byggas flera applikationer över tid? Utöver hastigheten och kostnaden för själva skapandet av apparna finns följande tydliga fördelar: ​

• De tidsödande integrationslösningar som krävs skapas snabbare med low-code-verktyg. I och med att När de stora integrationen Dels är hanteringen i allmänhet enklare och dels finns möjligheten att bygga många olika typer av applikationer på en och samma samma low-code-plattform. På så det senare underlättar integrationsarbetet i sig.