| Create from Template | ||||||
|---|---|---|---|---|---|---|
|
...
- 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.
...
- 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" (brugergrænseflade i browser) 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.
...
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.
...