Opret ny epic

Jira ID: ISB-96

Indholdsfortegnelse

Målgruppe for dokumentet

Baggrund og forretningsmål

Opdateret 2021-10-05 pga. ændret ansvarsfordeling mellem STAR City Teams: Denne ISB omfatter fremover alene VITAS, idet øvrige VirkSag systemer er overdragede til andre teams. ISB'en er pt. ikke konsekvensrettet. ISB'en indeholdt i forvejen fortrinsvis epics ved. VITAS.

Denne ISB omfatter ansvar for løbende at nedbringe teknisk gæld på VirkSags systemer. Ansvaret omfatter:

• Løbende analyser af behov for at opgradere eller udskifte tekniske komponenter.
• Løbende opgradering af tekniske komponenter, frameworks, værktøjer mv. således af VirkSags systemer altid anvender supporterede tekniske komponenter.
• Løbende udskiftning af udfasede tekniske komponenter, frameworks, værktøjer mv. således af VirkSags systemer altid anvender supporterede tekniske komponenter.
• Risikostyring af open source pakker
• Løbende tilpasning af VirkSags systemer til STAR City standarder.
• Løbende forbedring af SIG-score på baggrund af SIG-analyser
• Løbende vurdering af om arkitekturen i VirkSags systemer afspejler de forretningsmæssige behov og effektiv vedligeholdelse.

Analyser, opgradering og udskiftning af tekniske komponenter kan kun ske i det omfang, at STAR afsætter de fornødne ressourcer. Leverandørerne har ansvar for at påpege behov, mens STAR har ansvar for at tildele de nødvendige ressourcer.

VirkSags systemer omfatter:

• JobAG (Jobnet for arbejdsgivere)
• Jobkon (Jobnet for jobkonsulenter)
• JGM (Jobgodkendelsesmodul)
• VITAS
• JobAD (Snitflade til jobannoncer)
• EURES (Udveksling af CV'er og jobannoncer til US' EURES portal)

ISB'en omfatter specielt ansvar for at migrere VITAS fra AngularJS til Angular 10, da AngularJS ikke længere er supporteret. ISB'en indeholder et selvstændigt afsnit om denne migrering, herunder estimater, epics og roadmap.

Risikostyring af open source pakker

Der udarbejdes en epic pr. release, som implementerer processerne beskrevet i "Risikostyring af open source pakker i STAR", Søren Hansen 14.09.2020.

Migrering af VITAS fra AngularJS til Angular 10

Leverandøren og STARs arkitekt har gennemført en estimeringsworkshop d. 6. august 2020, som resulterede i migreringsmodeller, nedbrydning i epics, estimering af epics og afdækning af afhængigheder til brug for roadmap.

Baggrund

VITAS består i dag af to forskellige applikationer med forskellig arkitektur, som driftsafvikles på en måde, så brugerne i al væsentlighed opfatter VITAS som én applikation:

• Den gamle applikation "Gammel VITAS m. AngularJS", der er baseret på AngularJS, indeholder VITAS' rammefunktioner (forsider, login, dashboard, lister ...) samt de gamle ordninger (løntilskud, virksomhedspraktik, voksenlærling, IGU, mentor tillægsbevilling, hjælpemidler tillægsbevilling). Den gamle applikation anvender en arkitektur, der betragtes som forældet i forhold til den nye applikation. Der anvendes bl.a. Windows Worflow Foundation, MVC, fede WSRM'er og en mindre hensigtsmæssig datamodel, ligesom arkitekturen ikke understøtter genbrug, men i vid udstrækning er baseret på kodekopiering. Det er den gamle VITAS applikation, som skal migreres fra AngualrJS til Angular.
• Den nye applikation "Ny VITAS m. Angular", der er baseret på Angular 7, indeholder de nye ordninger (Fleksjob, Mentor, Personlig assistance, Hjælpemidler og Jobrotation). Den nye applikation har en mere hensigtsmæssig arkitektur end den gamle applikation, så selv om der forsat er en række uhensigtsmæssigheder i arkitekturen (hardkodede tekster, ingen versionering af ordninger mv), så kan den nye applikations arkitektur opfattes som målarkitektur for migrering af den gamle applikation.

Den gamle applikation skal migreres fra AngularJS til Angular 10, da AngularJS ikke længere supporteres efter 2021. Dermed vil der ikke blive foretaget fejlrettelser, herunder rettelse af evt. sikkerhedsproblemer efter 2021. Der er ingen egentlig migrationsvej fra AngularJS til Angular, hvilket betyder, at der skal gennemføres en egentlig omprogrammering af hele brugergrænsefladen på VITAS' gamle applikation.

Der er identificeret to løsningsmodeller.

Løsningsmodel "Lille"

Den lille løsningsmodel omfatter den billigst mulige migration fra AngularJS til Angular 10, hvilket svarer til STARs ønsker til migreringen.

Løsningsmodellen omfatter migrering af såvel rammefunktioner som ordninger:

• Rammefunktionernes brugergrænseflader vil blive omprogrammeret i VITAS' eksisterende nye applikation “Ny VITAS m. Angular”. Rammefunktionernes eksisterende forretningslogik og databaseunderstøttelse er relativ enkel og bibeholdes. Arbejdsgruppen finder, at denne migrering er i overensstemmelse med arkitekturen for den eksisterende nye applikation i tilstrækkeligt omfang til, at der ikke efterlades teknisk gæld på rammefunktionerne.
• De gamle ordninger vil blive omprogrammeret til en selvstændig Angular 10 baseret applikation "Gammel VITAS m. Angular" med et tilhørende nyt WebAPI lag, der gennemstiller til den gamle applikations back-end, som beholder uændret arkitektur. Dvs. de gamle ordninger vil have samme omfang af teknisk gæld på back-end delen som de har i den nuværende gamle applikation "Gammel VITAS m. AngularJS". Det er ikke muligt at implementere de gamle ordningers brugergrænseflader i den eksisterende, nye VITAS applikation og samtidig bibeholde de gamle ordningers back-end uden at der i uhensigtsmæssigt omfang introduceres teknisk gæld i den eksisterende, nye applikation. *1

Det betyder, at der i migreringsperioden vil være tale om 3 webapplikationer, men at der efter migreringsperioden igen vil være tale om 2 webapplikationer: "Ny VITAS m. Angular", som indeholder rammefunktioner og de nye ordninger med den pt. ønskede målarkitektur, samt "Gammel VITAS m. Angular", der indeholder de gamle ordninger . Figuren herunder illustrerer den nuværende arkitektur, arkitektur i migrationsperioden og arkitektur efter migrationsperioden:

(draw.io fil med ovenstående figur: Angular arkitektur - Lille.drawio)

*1: Den eksisterende nye Angular applikation er bundet op på modellen i den tilhørende nye back-end applikation, og der anvendes i ved udstrækning fælles komponenter på tværs af ordningerne. Den arkitektur kan ikke videreføres i integrationen med den gamle back-end uden at dårligdommene fra den gamle applikation forurener den nye Angular applikationen, hvorved der vil komme teknisk gæld og dårlig kvalitet ind i den nye applikation. Det er derfor leverandørens vurdering, at STAR ikke bør introducere teknisk gæld og dårlig kvalitet i den eksisterende nye Angular applikation.

Løsningsmodel "Fuld"

Denne løsningsmodel efterlader VITAS med én webapplikation med samme arkitektur som den nuværende nye webapplikation "Ny VITAS m. Angular", idet alle funktioner fra den gamle webapplikation migreres til den nye applikation. I denne løsningsmodel omskrives de gamle ordninger fuldstændigt, og data migreres fra VITAS' gamle database "VITAS" til den nye database "VITAS2". Dermed efterlades der ikke teknisk gæld svarende til uhensigtsmæssighederne i den gamle applikation, men uhensigtsmæssighederne i den eksisterende nye applikation adresseres ikke. Ved denne løsningsmodel migreres integration til KSS'er m.fl. fra tykke WSRM'er til tynde WSRM'er og webserviceudstilling, dvs. KSS'erne vil blive påvirket af denne løsningsmodel.

Migrering af rammefunktioner er identisk med løsningsmodel "Lille", mens migrering af de gamle ordninger er fundamentalt anderledes.

(draw.io fil med ovenstående figur: Angular arkitektur - Fuld.drawio)

Migrering fra løsningsmodel "Lille" til løsningsmodel "Fuld"

Det vil være muligt at migrere fra løsningsmodel "Lille" til løsningsmodel "Fuld" på et senere tidspunkt. Omkostningerne ved at først migrere fra løsningsmodel "Lille" til løsningsmodel "Fuld er imidlertidig væsentligt større end at migrere til løsningsmodel "Fuld" fra starten, hvilket fremgår af epicsoversigten. 

(draw.io fil med ovenstående figur: Angular arkitektur - Lille til Fuld.drawio)

Epics og estimater

Migreringen er nedbrudt i et antal epics, som hver især kan implementeres uafhængigt af de andre, herunder i forskellige releases. Dog skal den første epic "1 Opgradering fra Angular 7 til Angular 10" implementeres før de øvrige epics for at der kan migreres fra AnguarlJS til nyeste version af Angular.

Estimaterne er i story points (*1) og har følgende betydning:

• Estimat lille
  Estimat for at lave minimal migrering af funktionen fra AngularJS til Angular 10 jf. model "Lille", som efterlader teknisk gæld.
• Estimat fuld
  Estimat for at genimplementere funktionen i VITAS' nye Angular baserede applikation jf. model "Fuld", som ikke efterlader teknisk gæld
• Estimat lille → fuld
  Estimat for at migrere funktionen fra model "Lille" til model "Fuld" på et senere tidspunkt. 

Tabellen angiver forventet ressourceforbrug. Best case (20% fraktil) er 20% lavere, mens worst case (80% fraktil) er 30% højere.

*1: Et story point svarer til ca. 7½ udviklingstimer + ca. 7½ timer til analyse, kvalitetssikring og fejlrettelser, dvs. i alt ca. 15 timer. 

Roadmap

Da der er meget få afhængigheder mellem epics i migrationen, kan epics implementeres uafhængigt af hinanden, dog skal den første epic implementeres før de øvrige. Dermed har STAR stor frihed til at prioritere fordeling af migrationen mellem releases. Det vil dog være mest effektivt at migrere en ordning ad gangen. 

STAR kan derfor planlægge migrationen ved at balancere risici forbundet med at anvende ikke supporteret AngularJS framework efter juli 2021 i forhold til øvrige udvikling og kvalitetsforbedring på VITAS og under hensyntagen til udviklingsressourcer.

Risici

Der er ikke særlige risici ved transitionen, da der kun anvendes teknologier og værktøjer, som allerede anvendes på VITAS. Risici omfatter derfor fortrinsvis:

• Usikkerhed i kompleksitet, som kan påvirke ressourceforbruget
• Manglende kendskab til forretningsregler, som kan introducere fejl i VITAS.

Leverandøranbefaling

Leverandøren anbefaler migrering til den fulde løsning med det samme, hvis STAR har et ønske eller en forventning om at migrere til løsningsmodel "Fuld". Hvis STAR ikke har et ønske om at migrere til løsningsmodel "Fuld" på et senere tidspunkt, men er indstillet på at VITAS skal forsætte med det nuværende omfang af teknisk gæld og det tilhørende ressourceforbrug, så anbefaler leverandøren løsningsmodel "Lille". 

Løsningens grænseflader

Løsningens omfang

Der er tale om en løbende opgave, der har til formål at sikre god kvalitets i VirkSags systemer.

Anbefalinger/kommentarer vedr. arkitektur.

Arkitekturændringer afstemmes løbende med STARs arkitekt. 

Oversigt over epics