Revolutionære teknologi-opgraderinger med en evolutionær approach

Hvis du har arbejdet med at udvikle og drive større software-produkter, kender du formentlig til udfordringen om, at tiden har indhentet produktets oprindelige teknologier. Du har fulgt med udviklingen og kender derfor også drømmescenariet i forhold til, hvilke nye teknologier som produktet burde baseres på i dag. Den store udfordring er bare, at de nye teknologier sandsynligvis er radikalt forskellige fra, hvor du er i dag og kræver en fuld eller delvis omskrivning.

• Hvordan laver man radikale teknologiske opgraderinger, når man har et kørende system, hvor forretningen og brugerne kræver løbende fremdrift?

• Vil det bedste være en big bang-tilgang, eller kan opgraderingen laves evolutionært i små bider?

• Hvad er det gode incitament for at gå i gang?

.legal blev etableret i slutningen af 2019, hvor vi tilmed overtog ansvaret for to kørende produkter - Pactius og DPA Service. Begge systemer var begyndt at trænge til en UI og UX-overhaling og de bagvedliggende teknologier ligeså. Vi havde derfor et ønske om at opgradere begge dele på én gang, men vi vidste ikke helt, hvordan vi skulle gribe det an. Vi vidste, at vi ikke ville “få lov” til at sætte den løbende udvikling i stå for at lave en komplet omskrivning af frontenden. På den anden side stod vi ikke med den gode løsning i forhold til at angribe det iterativt. Så hvad skulle vi gøre for at komme videre?

Big Bang vs. Evolutionær tilgang

I starten gik vi i længere tid og overvejede, om vi skulle lave en komplet omskrivning af hele frontenden, eller hvorvidt vi kunne finde en god tilgang i forhold til en gradvis opgradering.

 

Big Bang omskrivning

Den mest simple tekniske løsning er som oftest at kode produktet om i den nye teknologi. På den måde får du en helt ny og ren techstack og kan bruge al din erfaring fra den originale løsning til at lave den nye og forbedrede udgave. Problemet er bare, at det helst kræver, at du sætter udviklingen af det eksisterende system i bero i mellemtiden, da det kan være en nærmest umulig kamp at lave en omskrivning af noget, som stadig bevæger sig.  

Tilmed var det svært for os at “nøjes” med at tale teknologi, når vi talte omskrivning. For hvorfor ikke lave produktet fuldstændigt om, når man nu har muligheden? Så scopet blev hurtigt enormt, og i en mindre virksomhed med begrænset kapacitet var det en urealistisk tilgang.

Jeg har én gang i mit liv været med til en komplet omskrivning af et levende system. Det endte med at tage ca. 4 år, før vi var klar til idriftsættelse, hvilket er en af grundene til, at jeg forsøger at udfordre den tilgang i dag

Evolutionær udsultning

Alternativet til big bang er at udsulte de gamle teknologier bid for bid, indtil man til sidst igen har en ny ren techstack.

Fordelene er, at man får værdi ud til brugerne hurtigere og får det altafgørende iterative feedback-loop op at stå tidligt i processen.

Til gengæld er det en mere kompliceret approach, som kræver, at man kan finde en god teknisk løsning på det hybride setup. Ved big bang simplificerer du ofte din techstack, men ved en evolutionær tilgang introducerer du kompleksitet, da man nu skal til at gabe over flere teknologier på én gang.

Der findes ikke meget materiale om, hvordan du laver et hybrid setup bestående af WebForms og React.JS i samme applikation, så vi var klar over, at der skulle nogle indledende eksperimenter til for at finde en god løsning.

I forhold til brugeroplevelsen krævede det en plan i forhold til at skabe en sammenhængende brugeroplevelse mellem den gamle og nye UI, som tillod, at den faktiske teknologiske opgradering kunne ske over tid i drypvise releases.

Jeg har en fornemmelse af, at mange er fanget mellem big bang og den evolutionære udsultning og derfor har svært ved at komme videre. De fleste ved efterhånden godt, at en iterativ tilgang er at foretrække, men når små evolutionære skridt skal til for at favne ændringer, som i sin natur er revolutionære, begynder det for alvor at blive svært.

Det gode incitament for at komme i gang

Det er altid svært at argumentere for teknologiske opgraderinger, når man har en lang backlog af features, der presser på.

I vores tilfælde har det handlet om at time og bundle de teknologiske opgraderinger med krav fra forretningen, hvor dele af systemet måske skal have en overhaling af andre årsager. I sådanne tilfælde forsøger vi at gribe chancen, da det således bliver forretningskrav, der kommer til at prioritere den teknologiske udvikling. Dette skaber tilmed en øget interesse på tværs af organisationen, da vi ikke længere taler teknologi-releases men brugerrettede releases. Standarden for hvad der kommer ud til brugeren er bare blevet højere - takket være de ny teknologiers muligheder.

 

Fra WebForms til React.JS  

Den overordnede ambition

Pactius er et større administrativt kontraktstyringssystem, hvis frontend oprindelig er udviklet i Asp.Net WebForms.

Samlet set stod vi overfor ambitionen om at skabe et mere brugervenligt system, i et nyt design, som tilmed skulle performe bedre end den eksisterende WebForms-løsning. Valget faldt på React.JS, som er en radikal anderledes måde at tænke UI på, men det er desværre ikke forenelig med WebForms.

Slicing i logiske komponenter

På trods af at Pactius havde en monolitisk frontend, bestod det indledende arbejde i at lave en logisk komponentisering af UI’en. I Pactius er det ikke så svært at se de overordnede komponenter for sig, da applikationen er organiseret efter en række hovedmenupunkter, som stort set 1:1 kan opfattes som en komponent i denne sammenhæng.  

 

Den langsigtede strategi blev så efterfølgende, at hver gang en logisk komponent skulle have en større forretningsmæssig overhaling, så ville vi i samme ombæring skrive komponenten om til React.JS.

Det hybride tekniske setup

De indledende tekniske eksperimenter gik ud på at bevise, at vi kunne hoste to vidt forskellige frontend-teknologier (WebFoms og React.JS) inde i samme UI og stadig få login, navigation og routes til at fungere.

Selvom vi på dette tidspunkt ikke havde ambitioner om egentlige Microfrontends, hentede vi inspiration herfra, da man i et hybrid frontend setup har mange af de samme udfordringer.

Læs mere om Microfrontends her

Udviklingsteamet fandt en god løsning, og så var vi egentlig klar til at gå i gang.

Første hybrid-release

Første større release handlede om at få etableret en hybrid platform, hvor vi kunne hoste WebForms og React.JS i samme løsning. Vi startede med at restyle den eksisterende Webforms løsning for at aligne så meget som muligt med det fremadrettede udtryk. Tilmed blev navigationen lavet om til en responsive sidemenu, som ydermere blev det første kode, der blev skrevet i React.JS. 

Før vi begyndte med opgraderingen, så den rene WebForms-løsning således ud.

 

Nedenfor ser du første lancerede hybrid-løsning, hvor side– og topmenu er skrevet i React.JS, imens indholdet stadig er WebForms – dog restylet for at aligne med det den nye retning i designet.

 

Anden hybrid-release

Anden hybrid release var en relancering af dashboard-komponenten, som med React.JS blev mere interaktiv, fik en bedre performance samt et nyt layout. Denne release krævede tilmed en ny BFF (backend for frontend) for at imødekomme kravene til performance. Dette medførte sidegevinsten i at kunne opgradere til Asp.Net Core og en tilhørende mere SOLID arkitektur.

Nedenfor ser du den gamle WebForms dashboard-løsning.

 

Nedenfor ser du den nye React.JS dashboard-løsning.  

 

Med denne release begyndte vi således at have dele af systemet, som kørte rent React.JS. Både sidemenu, topmenu og indhold er React.JS.

Tredje hybrid-release

Pactius har et større modul kaldet “Privacy”, hvor man har mulighed for at administrere en virksomheds datastrømme. Efter øget fokus på GDPR ønskede vi at lancere en komplet ny version af dette modul, som skulle aligne 100% med begreberne og kravene i GDPR.

Dette blev til en gentænkning af hele løsningen og domænet bag, blandt andet takket være de foregående releases, som havde skabt grundstenene i form af en mere moderne teckstack, hvor React.JS og ASP.NET Core nu var fundamentet.

Nedenfor ses nogle screenshots fra det gamle Privacy i ren WebForms.

 

 

Nedenfor ses nogle screenshot fra den nye Privacy løsning, hvor brugeren igen har en fuld oplevelse af fordelene ved at leve i en ren React.JS løsning.

 

 

 

Feature Toggling 

Første mål har været at kunne boarde nye kunder på løsningen så hurtigt som muligt og efterfølgende begynde migreringen af eksisterende kunder fra det gamle til det nye Privacy.

Ved at introducere feature toggling af det nye Privacy-modul på kundeniveau har vi kunne gå i markedet tidligere, idet vi har kunne sende nye kunder til det nye Privacy og lade eksisterende kunder forblive på den gamle løsning indtil videre. Derudover kan vi nu selv kontrollere, i hvilken fart kunderne skal flyttes fra den gamle til den nye løsning. Dette gør, at eksisterende kunder med helt særlige krav er blevet skåret fra i scope til en første version.

Læs mere om feature toggling her

I dag er vi i gang med at boarde de første kunder i drift, og sideløbende udvikler vi migreringen fra det gamle til det nye sammen med de første justeringer ud fra tidlig feedback.

Fremtiden?  

Vi står nu et sted, hvor vi overvejer at splitte det nye Privacy-modul ud i et helt særskilt produkt for at ramme kunder, der er tidligere i processen i forhold til at leve op til GDPR.

De har ikke nødvendigvis brug for alt det andet, Pactius kan, så hvis vi kunne afkoble Privacy-modulet 100% fra Pactius, ville vi kunne levere hurtigere i mindre bider og med mindre overhead.

Takket være vores evolutionære tilgang til teknologi-opgraderinger, står vi helt klart et bedre sted i dag end for bare 6 måneder siden. Fornemmelsen er, at vores evolutionære teknologiske udsultnings-strategi måske i lige så høj grad er blevet til et gradvist boost af egne evner og mod til rent faktisk at få tingene til at ske. Næste skridt mod et isoleret produkt virker ikke længere så skræmmende, da vi jo allerede har bevist, at det godt kan lade sig gøre at lave revolutionære opgraderinger - et skridt ad gangen.

Psst!

Hvis du rent faktisk har læst hertil, så vil jeg lige nævne, at vi står og mangler en erfaren og drevet full-stack udvikler med evner inden for C# + React.JS. Hvis du tilmed synes, at det kunne være spændende at bruge dine evner i en virkelighed, som den jeg har beskrevet, så skynd dig at hive fat i mig.

Passioneret Full-Stack .NET/React udvikler til ambitiøs legaltech-satsning