Kort version: - Applikationsmodernisering – erstatte en legacy-applikationen med en ny løsning, som er lettere at vedligeholde og fremtidssikret.
- Brugerfokus og effektivitet – adressere faktiske brugerbehov og fjerne unødvendige funktioner.
- Integration og driftssikkerhed – sikre integration med ESDH, regnskab og betalingssystemer samt overholde interne driftstandarder.
Lead-ansvarlig: Per Holst |
En kunde stod i en lidt uheldig situation. De var nødt til at finde en løsning for en eksisterende applikation, som ikke længere kunne hostes på samme platform efter årsskiftet. Applikationen kunne ikke nedlægges, og udviklingsteamet var allerede i gang med at omskrive en anden applikation under samme forudsætninger.
Vi trådte til for at kigge på mulighederne og potentielt løfte efterfølgende opgaver. Vi definerer ikke en løsning, som vi ikke selv kan gennemføre, samtidig forventer vi heller ikke, at vi automatisk får opgaven.
Analyse af moderniseringsmuligheder og strategiske valg
En analyse af applikationen og data viste, at applikationen som minimum skulle leve videre i yderligere 12 år. Spørgsmålene var: Hvad kan vi gøre? Kan vi hjemtage applikationen som den er (dvs. Rehost)? Eller kan vi …
- Retire – nedlægge applikationen
- Retain – beholde applikationen, som den er, hostet samme sted (status quo)
- Rehost – flytte applikationen til et andet driftcenter, evt. cloud, men med samme operativsystem
- Replatform – flytte applikationen til en ny platform, fx en anden cloud-service
- Repackage – beholde applikationen, men opdatere frameworks
- Refactor – omskrive dele af applikationen, evt. containerize; dvs. repackage + replatform + lidt ekstra
- Rearchitect – ændre applikationen, så den passer ind i en ny arkitektur og drager fordel af nye muligheder
- Rebuild – redesign + rewrite: omskrive applikationen med samme funktionalitet, så vidt muligt one-to-one
- Replace – erstatte den eksisterende applikation med en ny løsning, designet ud fra aktuelle og fremtidige behov
Vi kunne hurtigt strege de to første punkter og på grund af nogle tekniske vanskeligheder blev de næste fem muligheder også udelukket. Vi stod derfor tilbage med valget mellem Rebuild og Replace. Yderligere analyse viste, at forskellen i udviklingstimer mellem de to muligheder var forsvindende lille, men at fordelene ved Replace langt oversteg hvad den eksisterende applikation kunne tilbyde.
Vi kunne genbruge en del af det eksisterende udviklingsteams arbejde i forbindelse med Replace, herunder integrationer og datamigrering. Det ville også gøre applikationen nemmere at vedligeholde internt fremadrettet.
Brugerindsigter, integrationer og prioritering mod en sikker lancering
Ved at vælge Replace fik vi integration til ESDH-system, regnskabssystem, opkrævnings- og betalingssystemer. Vi lyttede til brugerne for at finde deres pain points, så vi kunne adressere dem. Det giver ikke mening at implementere en ny løsning på samme måde, hvis brugsmønsteret i virkeligheden er anderledes.
På den operative side blev interne standarder respekteret. Hvis der opstod problemer, kunne man på normal vis fremsøge logdata.
Application Triage
Med en hård og tæt deadline måtte vi vurdere, hvilke dele af applikationen der var absolut nødvendige ved lanceringen, og hvilke dele der kunne implementeres efterfølgende.
Det viste sig, at dele af den oprindelige applikation ikke længere var nødvendige. Ved at vælge Replace kunne vi også undlade at implementere disse. Selv om tiden var knap, nåede vi at levere en MVP, som også var testet inden deadline. Undervejs fandt vi endda en løsning, så vi kunne lukke det eksisterende system ned inden årsskiftet og samtidig have mulighed for en forlænget build- og testdeadline. Det gav lidt mere ro i en travl periode.