Baggrund

Nævn det hænger sammen med løsningsbeskrivelse for Taxonomy Admin.

Evt. Figur med Taxonomy forretningsdomænet nedenunder Admin + interne (Jobnet, VITAS, JobAG) og ekstern aftagere (Jobcenter, A-kasser osv.).

Hvad er Taxonomy, og hvorfor er det valgt til moderniseringsprojektet?

Dette dokument beskriver Taxonomy løsningen set fra en række perspektiver i henhold til de principper, der er beskrevet i FDA Reolen.

Dokumentet hænger tæt sammen med løsningsbeskrivelsen for Taxonomy Admin, da dette er en webapplikation, der fungerer som brugergrænseflade til Taxonomy. Moderniseringen af de to løsninger udgør tilsammen det pilotprojekt, som er første skridt i moderniseringsprojektet i STAR City.

På diagrammet nedenfor ses en konceptuel illustration af det domæne, som denne løsningsbeskrivelse berører.

Taxonomy er ét af en række forretningsdomæner i Det Fælles IT-baserede Datagrundlag (DFDG).

Hvad er Taxonomy, og hvorfor er det tilvalgt som en del af pilotprojektet?

Pilotprojektet er ligeledes en øvelse for STAR City på et organisatorisk niveau. Den dokumentation, og de arbejdsprocesser der anvendes, vil danne grundlag for, og facilitere den videre modernisering af øvrige løsninger i STAR.

Applikation mappet til forretning

Kravene der implementeres, tag listen fra confluence, hvor man kan følge links for at få flere detaljer. Lidt forklarende prosa tekst, som kan tages fra ISB 976 ESCO STAR Beskæftiger os kun med nederste to lag i pyramiden, resten implementeres senere.
ESCO-STAR kan perspektivere, give baggrund osv.
Load af opdateret ESCO fra EU til ESCO STAR
De forretningsmæssige krav er dem vi skal leve op til for at have samme funktionalitet på den anden side.
Dokumentation og proces der kan facilitere videre modernisering af STAR

Kravene fungerer som en liste over den nuværende funktionalitet, og de forretningsprocesser, som Taxonomy indeholder. Derved har forretningsanalytikere, udviklere og testere et tydeligt udgangspunkt at arbejde med moderniseringen af løsningen. Kravene er således udgangspunkt for udformning af acceptkriterier og testcases for de dele af systemet der skal implementeres eller omskrives i forbindelse med opgradering af teknologier. Det sikres således, at den eksisterende funktionalitet i løsningen stadig fungerer fejlfrit efter en modernisering.

De forretningsmæssige krav, som er afdækket for Taxonomy, er vist i nedenstående tabel.

Titel	Beskrivelse
Hent stillingsbetegnelser og aliasser fra EU	De nyeste ESCO data vedr. stillingsbetegnelser skal kunne hentes fra EU via en komponent og efterfølgende loades til ESCO STAR.
Afsendelse af besked pga. ændringer	Systemet skal understøtte at opdateringer på baggrund af oprettelse og/eller ændringer i stillingsbetegnelse udløser tekniske beskeder om ændringer til eksterne serviceaftagere.
Oprettelse og opdatering af stillingsbetegnelse	Ifm. oprettelse/redigering af stilllingsbetegnelser i Taxonomy skal systemet kunne opdatere disse ændringer i databasen.
Taxonomy er dataejer for ESCO STAR stillingsbetegnelser, Alias og Erhvervsområder	Forretningsdomænet (Taxonomy) er dataejer over: ESCO STAR stillingsbetegnelser og tilhørende Alias Hvorvidt der er tale om stillingsbetegnelsen et Hotjob. Stillingsbetegnelsens engelske navn, hvis et sådan er tilknyttet. Erhvervsområder
Udstilling af Erhvervsområder til snitflade	Forretningsdomænet (Taxonomy) skal udstille data vedr. Erhvervsområder til et endpoint, hvorfra eksterne og interne snitflader kan hente dataen.
Generelle og specifikke fejlkoder	Systemet skal kunne generere og udstille fejlkoder, der er specifikke ifm. hentningen af taxonomien for ESCO STAR.
Mulighed for udstilling af udenlandsk navn for stillingsbetegnelse	Forretningsdomænet (Taxonomy) skal udstille udenlandske titler til en specifik stillingsbetegnelse til et endpoint, hvorfra eksterne og interne snitflader kan hente dataen.
Dataleverancer af eksisterende data til eksterne/interne	Systemet understøtter dataleverancer af eksisterende data til interne/eksterne, her VOA via BI samt til Ankiro ifm. optimering af CV-søgning.
Udstilling af markeringer	Forretningsdomænet (Taxonomy) skal udstille markeringer på en stillingsbetegnelse til et endpoint, hvorfra eksterne og interne snitflader kan hente dataen.
Udstilling af ESCO STAR stillingsbetegnelser og alias	Forretningsdomænet (Taxonomy) skal udstille ESCO STAR stillingsbetengelser og alias til et endpoint, så eksterne og interne snitflader kan hente dataen.
Oprettelse og opdatering af aliasser	Ifm. oprettelse/redigering af aliasser i Taxonomy Admin skal systemet kunne opdatere disse ændringer i databasen.
Udstilling af kodelister til eksterne og interne snitflader	Systemet skal udstille forretningsdomænets Taxonomys kodelister til et endpoint, hvorfra det er muligt for eksterne og interne snitflader at hente de pågældende kodelister
Udstilling af DiscoAms08 mapninger ift. ESCO STAR til eksterne og interne snitflader	Systemet skal udstille DiscoAms08 mapninger ift. ESCO STAR til et endpoint, hvorfra det er muligt for eksterne og interne snitflader at hente disse ESCO-STAR mapninger

Hvert af kravene har resulteret i én til flere User Stories, som udviklere og testere kan tage udgangspunkt i, og herved effektivt udføre implementering af ny teknologi, og verificering af den fortsat fungerende forretningsfunktionalitet.

Applikation mappet til information

Hvilke typer information der bliver behandlet hvor i applikationen. Stillingsbetegnelser der kommer fra EU (ESCO stillingsbetegnelser) og den danske udgave af dem (ESCO-Star stillingsbetegnelser), færdigheder og kompetencer, kvalifikationer og uddannelse.
Hierarkisk datamodel. Hver stillingsbetegnelse refererer til en EU stillingsbetegnelse.

Infrastrukturkoncept og mønstre

Forklare at pilotprojektet vil demonstrere en stor mængde øvrigt arbejde, der bl.a. omfatter en helt ny IT-platform, sikkerhedsmodel, logning og overvågning. Derudover en ny DevSecOps proces, der i langt højere grad er automatiseret, dvs. mere sikker, mindre risiko for fejl, mindre manuelt arbejde (tidsbesparelse) ifm. test og deployments.
Modernisering af taxonomy beviser ovenstående
Fysisk, Taxonomy ligger som en microservice som et forretningsdomæne for sig selv. Driftet hos SIT, som kan køre på fysisk adskilt maskine. Docker. (Mulighed for at dette kan ligge i cloud, fordi der ikke er personfølsom data).
Fordelen ved SIT driften
Lave diagrammer.

Sikkerhedsmodel

Hvordan forholder de her to applikationer sig til sikkerhed.
Hvordan forholder data sig ift. GDPR. Der er ikke personhenførbare oplysninger. Undgår derfor sletteregler og logik.
GDPR er et nøgleelement i at vælge piloten. Med Taxonomy løber vi ikke risiko for databrud og sikkerhedslæk.

Løsningsarkitektur

Taxonomy kommer til at blive kaldt gennem en API gateway.
Reference til målarkitektur (link til Kaspers tegning). Eget forretningsdomæne. Sikkerhedsmodel. Fælleskomponenter. Logning og overvågning, SIEM.
Afprøvelse af enablers.

Applikations og komponent design

Ankiro (måske) til søgning. Ankiro får loadet det data der skal bruges.
Fælleskomponenter (STAR.Foundation)
Hvordan er backend applikationen struktureret.
Hvad er det konkret vi gør ved applikationen for at sikre målene (cloud ready, nyeste .Net). Vi tager noget der er i forvejen, men løfter det bare op, og viser at det kan driftes på den nye IT-platform.

Snitfladebeskrivelser

Hvem der er bruger. Jobnet, VITAS, Taxonomy Admin. Lave diagrammer
(Konsekvenser for eksterne uden for STAR (serviceaftagere). Hvordan piloten kommer til at påvirke eksterne. I denne sammenhæng kommer det ikke til at påvirke dem, udover at der skal peges på et andet endpoint. Der sker ikke ændringer i forretningslogikken.)

Automatiserede tests i koden
Automatiserede tests i brugergrænsefladen
Manuelle tests
Er der noget vi ikke kan teste? Skal der gennemføres ekstraordinære tests, som ikke er en del af vores DevOps pipeline?

1005.3 Løsningsbeskrivelse Taxonomy - Kladde