Central database og serviceplatform bag it-understøttelse af beskæftigelsesindsatsen

Det Fælles Datagrundlag (DFDG) er datagrundlag for hovedparten af data på beskæftigelsesområdet på personniveau – vedrørende beskæftigelsesindsats. DFDG indeholder i begrænset omfang oplysninger om ydelser – primært i form af forsørgelseshistorik, der beregnes i STAR, og udstilles til jobcentrene i SustenanceHistoryService.

DFDG binder sagsbehandlersystemerne i kommuner og a-kasser på beskæftigelsesområdet sammen med den centrale selvbetjening på Jobnet.dk (ligeledes del af nærværende udbud) og afleverer data til det statistiske datavarehus (DSDV) til statistik m.v., og tilsyn mv. Data betegnes også som masterdata for beskæftigelsesområdet.

Adgang til DFDG sker primært via webservices, der tillader en række systemer adgang til at hente og indrapportere oplysninger på personniveau.

Omfanget af disse masterdata defineres ud fra behovet for data til den centrale selvbetjening samt behovet for fælles (operationelle og opfølgningsmæssige) data for aktørerne på beskæftigelsesområdet. Dette omfang udvides løbende i takt med udbygningen af selvbetjeningen og ændringer i lovgivningen m.v. 

DFDG er en Microsoft-baseret webapplikation uden særlige komponenter. Applikationen anvender load balancering, samt database cluster.

Baggrund og historie

DFDG blev udviklet med udgangspunkt i Arbejdsmarkedsportalen (AMP) som var et webbaseret sagsbehandlingssystem, som gradvist afløste det Mainframe-baserede Amanda, der var sagsbehandlingssystem i Arbejdsformidlingen (AF).

I forbindelse med strukturreformen i 2007 og etablering af fjorten pilotjobcentre, hvor kommunerne selv skulle varetage beskæftigelsesindsatsen over for forsikrede ledige og kommunerne skal varetage den tilhørende it-understøttelse, blev Arbejdsmarkedsportalens data og forretningslogik udstillet via en række webservices. Disse webservices og den underliggende databasen er der blevet arbejdet meget videre på og er det som i dag betegnes som det fælles datagrundlag.

Enkelte dele af Arbejdsmarkedsportalen (også en del af dette udbud) er fortsat i drift.

Forretningsfunktionalitet

DFDG er simpelt fortalt en stor database, som er indkapslet af forretningslogik og udstillet til omverdenen via webservices og udtræk fra databasen. DFDG har altså ikke brugergrænseflader, men i stedet en række tekniske grænseflader.

Overordnet forretningsbeskrivelse

Nedenstående model er et overordnet syn på de systemkomponenter og dataflow, som udgør DFDG og arbejder sammen med DFDG. Det er en idealiseret fremstilling, der alene danner et overblik over de forskellige systemkomponenter og dataflow der understøttes.

Figur 1: Logisk systemoverblik

Her først gennemgang af udvalgte systemkomponenter:

og følgelig integrationer mellem disse:

Primære arbejdsgange

De forretningsgange der understøttes kan deles på følgende primære forretningsområder, dog er Jobsøgning i dag primært understøttet i Jobnet.

Figur 2: Primære forretningsområder, der er understøttet i DFDG

Udover understøttelse af disse primære forretningsområder, indeholder DFDG funktionalitet til styring og administration af disse data.

Da DFDG understøtter registrering og behandling af data i forbindelse med en lang række forretningsgange, er det uden for scope at gennemgå disse. I stedet henvises til beskrivelsen af Systemlandskabet, hvor forretningsgange på beskæftigelsesområdet kort er gennemgået.

Forretningsområderne hvor forretningsgangene ligger indenfor gennemgås her kort.

Sag og kontaktgruppe, ydelse

Baggrund

Beskæftigelsessagen er den centrale entitet i beskæftigelsesområdets it-systemer. Når en borger har en sag betyder det, at borgeren er kendt i jobcentret og at der kan foretages registreringer på borgeren. Sagen findes imidlertid ikke som en konkret entitet i den centrale it-understøttelse i AMP (DFDG), men er et overordnet logisk begreb, der binder datamodellen sammen.

Den implicitte sag har altid en kontaktgruppe. Dermed bliver kontaktgruppe det centrale begreb for borgerens indplacering i den centrale it-understøttelse. Kontaktgruppen registreres som det første, når borgeren kommer i kontakt med beskæftigelsessystemet. Kontaktgruppen er en gruppering, som til sammen favner den samling af borgere i et jobcenter, som lovgivningen angiver, at der skal følges op på, dvs. som har et kontaktforløb i henhold til reglerne for den enkelte gruppe.

Begrebet konstituerer således kontaktforløbet mellem jobcenter og borger – og fsva. dagpengemodtagere det fælles kontaktforløb mellem jobcenter, a-kasse- og dagpengemodtagere.

Alle med kontakt til et jobcenter er i en kontaktgruppe. Kontaktgruppe samler de kontaktrelevante objekter fra lov om en aktiv beskæftigelsesindsats (LAB) - målgruppe, tilmeldekategori, match- og visitationskategori og forsørgel­ses­kategori.

Hver forekomst af kontaktgruppe, er dermed et udtryk for, at der for netop denne gruppe, er forskellige regler for beregningsgrundlaget ifm. rettidighed/rådighed mm.

Kon­takt­gruppen vil for nogle forekomster være lig en LAB målgruppe, og for andre være lig et udsnit af en LAB målgruppe eller anden lovgivning, fx sygedagpengeloven, integrationsloven eller lov om aktiv socialpolitik.

Kontaktgruppen bliver oprettet ved første registrering af borgeren i DFDG, hvad enten denne registrering sker fra de kommunale sagsbehandlingssystemer, a-kasser eller af borgeren selv via Jobnet.

Et andet centralt begreb på beskæftigelsesområdet er ydelse. DFDG er dog ikke dataejer for ydelsesdata, men modtager disse asynkront fra de forskellige ydelsessystemer (ydelsescentret i kommunen og a-kasserne). Derfor spiller ydelse ikke en ligeså stor rolle som kontaktgruppe i DFDG. Ydelse udtrykkes i DFDG dels gennem kontaktgruppe (der kan mappes entydigt fra kontaktgruppe til ydelse[1], men ikke fra ydelse til kontaktgruppe) og endvidere gennem tilmeldekategori (se tilmelding).

Der er mange valideringer og forretningsregler bundet op på kontaktgrupper. Se datarum under Releasedokumentation/Webservice dokumentation/Fritagelser per målgruppe. DFDG skifter automatisk kontaktgruppe i flg. situationer:

• Tilmelding, kontanthjælp eller dagpenge.
• Skift til Tilmeldt uden ydelse, fx ved manglende bekræftelse af aktiv jobsøgning.
• Overgang mellem fleksjobvisiteret og fleksjobansat.

Implementering

Kontaktgruppe registreres gennem PersonRegistrationService: CreateContactGroup. Kontaktgruppe registreres derudover på baggrund af tilmeldingen via UnemploymentEnrollmentService, hvor værdien ClientCategoryTypeIdentifier (tilmeldekategori) entydigt kan oversættes til kontaktgruppe. Dette gælder dog kun for kontaktgrupper, der skal stå til rådighed (ledige).

Tendenser, roadmap

Primo 2015 er DFDG udvidet med en række nye kontaktgrupper. Dette er sket i forbindelse med sanering af forskellige indberetningskanaler for deltagelse i aktiveringstilbud og andre aktiviteter således, at Min Plan og aktiveringstilbud m.v. alene indberettes online via PlanService og ActivityService.

Min Plan og aktiveringstilbud er ikke implementeret i AMP brugergrænsefladen.

CV og tilmelding

Baggrund

De borgere, der har kontakt med Jobcenteret, kan groft[2] opdeles i følgende grupper:

1. Arbejdsmarkedsparate dagpengemodtagere (matchgruppe 1), kontanthjælpsmodtagere (visitationsgruppe jobparat), uddannelseshjælpsmodtagere (visitationsgruppe åbenlyst uddannelsesparate)
2. Ikke arbejdsmarkedsparate kontanthjælpsmodtagere (visitationsgruppe aktivitetsparat) og ikke åbenlyst uddannelsesparate uddannelseshjælpsmodtagere (visitationsgruppe uddannelsesparat og aktivitetsparat)
3. Syge
4. Fleksjobvisiterede

For at være i gruppe 1 skal man stå til rådighed for arbejde. Dette kræver, at tre forhold er opfyldt. Dels at man er tilmeldt (meldt ledig), dels, at man har et tilgængeligt, digitalt CV, og dels, at man dokumenterer sin jobsøgning i en digital joblog.

Tilmeldebegrebet stammer tilbage fra AF-tiden, hvor alle ledige (uanset ydelse) skulle tilmelde sig AF-kontoret.

Implementering

Tilmeldingen foregår gennem UnemploymentEnrollmentService. Tilmelding kan foretages af borgeren selv på Jobnet, hvilket ca. 65 % (2014/15 tal) vælger at gøre. Derudover kan tilmeldingen ske fra jobcenteret og a-kassen. Tilmeldingen har en del valideringer og sideeffekter. Hvis den ledige ikke har et CV i forvejen, så medfører tilmeldingen, at der oprettes et provisorisk CV.

CV’et er ejet af Jobnet, men udstilles via DFDG til sagsbehandlersystemerne og på JobKon.

Jobnet indeholder ikke følsomme persondata, herunder CPR, hvorfor CV-nummeret anvendes til at identificere borgeren fra Jobnet over for DFDG. Sammenknytningen mellem CV-nummer og CPR sker ved tilmelding.

Tendenser

Tilmeldingens centrale betydning er som sagt en arv fra AF-systemet, der udelukkende tog sig af de arbejdsmarkedsparate.

STAR har de seneste år åbnet Jobnet for selvbetjening for andre målgrupper end tilmeldte ledige. Bl.a. i forhold til ledige fleksjobvisiterede, aktivitetsparate kontanthjælpsmodtagere og syge. Tendensen går i retning af at gøre selvbetjeningsmuligheder tilgængelig for flere målgrupper.

Samtaler, indkaldelser – kategoriseringer

Baggrund

Jobcentrenes arbejde er i højt omfang koncentreret om samtaler med borgerne. Jobcentrene måles på, om disse samtaler og tilbud (aktiveringer) afvikles rettidigt

DFDG indeholder udover samtaler også indkaldelserne til disse, da indkaldelserne udstilles på Jobnet, hvor borgeren kan ombooke. Kunden tilbyder jobcentrene en onlineapplikation til at håndtere ombookingen, kalenderintegration m.v. (via Jobcenter Planner). Men denne applikation er ikke en del af DFDG. Indkaldelser og samtaler har ingen sammenhæng i den logiske model.

Ved disse samtaler udføres der i de fleste tilfælde en matchning eller en visitering af borgeren. Matchningen sker i forhold til beskæftigelsesområdets match-model, der inddeler borgeren i tre kategorier. Jobbcentrets målgrupper er omfattet af en række forskellige visitationssystemer (beskrivelsen er ikke udtømmende fsva. målgrupper):

Ved samtaler indgås der desuden en aftale mellem jobcenteret og borgeren. Denne aftale udstilles på Jobnet via metoden GetConductedInterviews i JobnetBookingService.

Implementering

Registrering af samtaler og match foregår i PersonRegistrationsService med metoderne CreatePersonInterview og CreatePersonCategory.

Udstillingen af samtaler og visitationskategoriseringer sker gennem PersonStatusService.

Registrering af indkaldelser foregår i BookingService. Udstillingen af indkaldelser til jobcentre og a-kasser er via PersonStatusServices og via WSRM. Udstilling af indkaldelser til Jobnet foregår i JobnetBookingService.

I 2015 er webservicemodellen bragt i overensstemmelse med den logiske model således at der opereres med én samtale og én match-model. På udbudstidspunktet udestår en oprydning i databasen således, at historiske indkaldelser og samtaler fra før juli 2015 skilles ad.

Udrulning af muligheden for ombooking og selvbooking via Jobcenter Planner er afsluttet i 2015. I 2016 åbnes der for at jobcentrene kan anvende alternative selvbooking løsninger.

Min Plan, aktive tilbud og selvvalgt uddannelse

Baggrund

For store dele af jobcentrenes målgrupper udtrykkes indsatsen gennem en plan – Min Plan. Her skelnes der også mellem ledige, der rent teknisk i PlanService har jobplaner, sygedagpengemodtagere, der har aftale om opfølgning og rehabiliteringsplaner, uddannelsesplaner for unge – og endelig Planer uden plantype.

Min Plan indeholder udover en aftaletekst en række tilbud (populært kaldet aktiveringer) der enten kan være virksomhedsrettede i form af forskellige tilskudsordninger m.v. eller uddannelsesrettede, fx i form af jobsøgningskurser eller ordinær uddannelse.

Min Plan og tilhørende aktiveringer indgår fra januar 2015 i DFDG for alle jobcentrets målgrupper. Min Plan og med tilhørende aktiveringer en del af DFDG, og de udstilles for borgeren på Jobnet – for de fleste målgrupper fra januar 2015 og for de sidste målgrupper fra januar 2016.

På Jobnet skal borgeren kvittere for at have set Min Plan.

A-kasserne kan fra januar 2016 - for egne medlemmer - se Min Plan i egne fagsystemer via kald af DFDGs webservices (PlanService eller MyPlanService).

Udover tilbud har ledige dagpengemodtagere ret til seks ugers selvvalgt uddannelse. Dette registreres i dag i DFDG som fravær - en række jobcentre har dog valgt også at registrere selvvalgt uddannelse som et tilbud. Selvvalgt uddannelse er dog ikke et tilbud i lovens forstand. Der adskilles mellem de forskellige former for tilbud og andre tilbudslignende aktiviteter via en kodeliste fra DFDG.

Implementering

Min Plan og aktiveringer registreres gennem PlanService og ActivityService.

Når borgeren har kvitteret på Jobnet sendes denne kvittering tilbage til sagsbehandlingsdelen som en besked på køen.

Min Plan og aktiveringer leveres til Det Statistiske Datavarehus, der bl.a. anvender disse data til beregning af rettidighed (se nedenfor), og videre fra Det Statistiske Datavarehus til Danmarks Statistik, hvor oplysningerne indgår i opgørelsen af bl.a. ledighedsstatistikken.

Fravær og fritagelser

Baggrund

Når borgeren ikke er i ”normalsituationen” (eller i et aktiveringstilbud) har borgeren typisk et fravær, fx sygdom. Fraværet kan medføre en eller flere fritagelser for hhv. rådighed, samtale og tilbud (aktivering). Sammenhængen mellem fravær og fritagelse skifter fra kontaktgruppe til kontaktgruppe, til tider for de enkelte kategoriseringer inden for en kontaktgruppe, og er forholdsvis komplekse. Reglerne er dokumenteret i Webservice-dokumentationen.

Implementering

Fravær registreres gennem AbsenceService og IllnessCompostiveService og læses gennem PersonStatusService.

Ved registrering af fravær fra Jobnet anvendes en række andre Jobnet-specifikke services.

Tendenser

Der er ingen konkrete planer om at ændre logikken vedr. fravær og fritagelser, men der sker regelmæssigt tilpasninger som følge af regelændringer – fx i form af nye fravær og fritagelser eller i form af ændringer til hvilke kontaktgrupper, der kan have de enkelte fraværs- og fritagelsestyper.

Rettidighed

Baggrund

Jobcentrenes produktion styres i høj grad af rettidighed. Rettidigheden fortæller hvornår en borger senest skal til hhv. samtale og i tilbud (aktivering). Rettidigheden bygger på komplekse beregninger og foretages derfor for nogle målgrupper centralt i Det Statistiske Datavarehus.

Implementering

Rettidighedsdata udstilles som datasæt, der hentes ind i de kommunale systemer, hvor de danner baggrund for udsøgninger. Rettidigheden udstilles desuden i PersonStatusServicen, og en søgeservice - TimelinessSearchService. For dagpengemodtagere udstilles vejledende samtaledatoer endvidere som WSRM-beskeder.

Det er et af de dataflows, hvor data flyder fra DFDG til Det Statistiske Datavarehus og tilbage igen.

Tendenser

De konkrete regler for området ændres generelt løbende.

Jobsøgning

Tjek af jobforslag

Tilmeldte ledige skal mindst hver 7. dag tjekke jobforslag på Jobnet, for på denne måde at bekræfte, at de er aktivt jobsøgende. DFDG holder forretningsreglerne omkring rettidighed i tjek af jobforslag, afsendelse af WSRM-beskeder til jobcentrene om dannelse af breve med påmindelser om tjek af jobforslag, og i sidste ende afmelding ved manglende tjek af jobforslag. DFDG styrer, at der ikke beregnes frist for tjek af jobforslag i tilknytning til visse helligdage eller i forbindelse med fravær, der i en periode kan fritage for tjek af jobforslag. Regelsættet på området er ganske komplekst.

Digital joblog

Jobparate kontanthjælpsmodtagere, åbenlyst uddannelsesparate uddannelseshjælpsmodtagere, ledige dagpengemodtagere og ledige fleksjobvisiterede skal dokumentere jobsøgningsaktiviteter i den fælles joblog på Jobnet.

Andre målgrupper har mulighed for, men ikke pligt til, at anvende den fælles joblog på Jobnet.

Oplysninger, der registreres i den fælles joblog på Jobnet persisteres i DFDG via JobnetJoblogService.

For a-kasser, der har egne digitale joblogs, kan dagpengemodtagere dog frit vælge, om de vil anvende den digitale joblog på Jobnet eller a-kassens egen digitale joblog, under forudsætning af, at a-kassens joblog er integreret med jobloggen på DFDG. Integrationen mellem a-kassernes egne digitale joblogs og joblog-oplysningerne i DFDG ske via CitizenJoblogService.

Registreringerne i jobloggen udstilles for sagsbehandlere i jobcentre og a-kasser på JobKon.

DFDG udstiller endvidere services (JoblogService), så a-kasser og jobcentre kan indlæse joblog-oplysninger i egne fagsystemer for egne medlemmer hhv. borgere.

Andre forretningsmæssige elementer

Helbredsmæssige begrænsninger

Jobcenteret og a-kasserne kan registrere helbredsmæssige begrænsninger for en borger. Fx kan en rygskade give begrænsninger i borgerens evne til at varetage fysisk tungt arbejde.

Samtykke

Når en borger flytter mellem myndigheder kræver det for nogle oplysningstyper samtykke fra borgeren, før den nye myndighed kan tilgå sagen. Dog er der på beskæftigelsesområdet en række registreringer om borgeren, der er tilgængeligt på tværs af myndigheder pga. kravet om landsdækkende jobformidling.

Underretningspligtige hændelser

Hvis en dagpengemodtager ikke overholder sine pligter sendes der besked til a-kassen i form af en såkaldt underretningspligtig hændelse. Herefter tager a-kassen stilling til evt. sanktioner.

Partshøring

For kontanthjælpsmodtagere, der ikke overholder deres pligter, indledes der en partshøring. Denne er dog p.t. ikke it-understøttet i DFDG, men kan være genstand for en senere digitalisering jf. kontanthjælpsreformen.

Persongruppemarkering

Persongruppemarkeringer giver sagsbehandler mulighed for at markere en person til udsøgningsformål. Persongruppemarkeringen anvendes også centralt ifm. forsøg. Person­gruppe­markeringen kan være landsdækkende, gælde for en beskæftigelsesregion (nu arbejdsmarkedsområde) eller for et enkelt jobcenter.

Forretningsobjekter

DFDG behandler, gemmer og videreformidler mange hundrede forretningsobjekter. Der er dog en række kerne objekter som mange services (og systemer der trække på disse services) anvender. Disse er gengivet på nedenstående:

Figur 3: Væsentligste forretningsobjekter i DFDG (med gråt)

Forretningsobjekterne Virksomhed, Job og CV er i dag understøttet af Jobnet. CVR data omkring virksomheder findes dog også i DFDG, ligesom DFDG formidler adgang for jobcentre og a-kasser til CV i Jobnet. Viden omkring Sagsbehandler er primært gemt i DFDG i forbindelse med audit logning ved registreringer, eller som ansvarlig sagsbehandler på borger. Der er ikke vedligeholdt et katalog over kommunale og a-kasse sagsbehandlere i DFDG.

Hvilke data skal DFDG indeholde?

1. DFDG skal indeholde alle data omkring en borgers beskæftigelsestilstand, som skabes i beskæftigelsesindsatsen i kommuner, a-kasser, regioner og stat.
2. Derudover skal DFDG indeholde nødvendige data for at kunne styre og administrere disse data.
3. Dette inkluderer også det fulde revisionsspor, med identifikation af hvilke data der er registreret/slettet, af hvem og hvornår.
4. DFDG skal kunne fungere som journal for kommuner og a-kasser, for de data der registreres i DFDG.

Hvilke data indeholder DFDG ikke?

Kommunerne har ansvar for beskæftigelsesindsatsen, og derfor også for at have de nødvendige IT værktøjer der skal til for at kunne styre dette. Grundlæggende er dette ikke DFDG’s ansvar. Derfor er følgende data for nuværende ikke en del af DFDG:

• Kommunal organisering, teams, medarbejdere
• Opgavestyring

–    På nær: Borgers booking og ombooking af samtaler med sagsbehandlere

• Generel journal og notater
• Visse samtaletyper, og notater fra disse
• Sagen

–    På nær: målgrupper (kontaktgrupper) ligger i DFDG

• Visse plantyper (DFDG har som en del af Min Plan plantyper for jobplaner, aftale om opfølgning, plan uden plantype og rehabiliteringsplanens[3] indsatsdel)
• Ydelse og bevilling af denne

–    Den bevilgede og udbetalte ydelse overføres til STAR og derfra til DFDGs forsørgelseshistorik med faste intervaller

• Ledige tilbud (dvs. inden de er bevilget til en konkret borger)

–    På nær: 6 ugers selvvalgt uddannelse

–    På nær: Ledige virksomhedstilbud indrapporteres

Forretningsmoduler

DFDG er ikke direkte opdelt i egentlige moduler. Opdelingen i DFDG er snarere foretaget med udgangspunkt i aftagerne samt den tekniske type af grænseflade:

1. Webservicekataloger
2. Batchjobs
3. Databaser

Overordnet løsningsdesign

Følgende giver en gennemgang af den tekniske løsning der er udviklet for at understøtte forretningsfunktionaliteten.

Applikationsdesign

DFDG er udviklet så det understøtter en lagdelt webapplikation, som registrerer direkte i DFDG’s database. DFDG er udviklet efter normal best practice for Microsoft.NET platformen for sådanne applikationer, dog præget af at udviklingen af DFDG har stået på i en del år. Det er en arkitektur med fire logiske applikationslag som vist på tegningen herunder, suppleret med en række delte komponenter og klasser. DFDG har ikke egen brugergrænseflade, så Præsentationslaget i nedenstående er ikke en del af DFDG men en del af de applikationer der anvender DFDG.

Figur 4: Lagdelt opbygning af DFDG, dog er brugergrænsefladen ikke en del af DFDG

DFDG implementerer følgende lag:

• Servicelag – udstilling af forretningslaget via webservices samt besked-kø
• Forretningslag – forretningskomponenter (dog uden brug af Microsoft workflow logik)
• Datalag – adgangslag til datakilder som databaser og eksterne services

Systemet udvikles i Microsoft.NET teknologi i programmeringssproget C#, med anvendelse af enkelte støttekomponenter til f.eks. logning, e-mail afsendelse, sms-afsendelse til SMS-gateway, dannelse af pdf-dokumenter, osv.

Servicelaget

Servicelaget er en tynd skal oven på forretningslaget. Servicelaget målrettes forretningsbehovene i de enkelte forretningsapplikationer og skærmer disse mod forretningslogikken og domænemodellen som anvendes i forretningslaget.

Alle services udstilles som SOAP webservices, og der skrives WSDL kontrakter via Contract-first arbejdsformen med anvendelse af delte typer (Shared-Types), herunder bl.a. OIO typer. WSDL kontrakten beskriver syntaks for de enkelte felter, samt kardinalitet. Alle kald valideres. Ved fejl kastes en SOAP Exception.

Webservices er udviklet via Microsoft Webservice Communication Foundation (WCF) rammeværket.

Alle webservices er beskyttes via server-certifikater til kryptering af kommunikationen og klient OCES funktionscertifikater til autentificering. Forretningslaget sikrer også at aftagere kun får adgang til de services og data som aftager må modtage.

Services i DFDG kan logisk opdeles i fire typer:

1. Forretningsservices
   1. Disse services foretager en forretningshandling som kan resultere i en eller flere registreringer af data i DFDG, men også resultere i kald til andre systemer. Sådanne services er typisk tænkt som del at en specifik forretningsgang.
   2. Dataservices
      1. Disse services arbejder direkte på en enkelt entitet, og stiller typisk et CRUD (Create, Read, Update og Delete) interface til rådighed. Read operationen er typisk stillet til rådighed via PersonStatusServices, der returnerer mange centrale data omkring borgeren og Delete operationen er i flere tilfælde udeladt, men understøttet som en blød sletning via Update operationen.
      2. Hændelsesservices
         1. Disse services returnerer data om hændelser, som udsendes via WSRM køen i DFDG. WSRM køen er en hændelseskø for hver aftagertype (dvs. organisation, forretningsenhed, osv.), f.eks. et Jobcenter eller en Kommune. Hændelseskøen underretter aftagerne om hvilke hændelser der kan være relevante for denne aftager.
         2. Infrastrukturservices
            1. Disse services er en del af rammeværket og understøtter f.eks. hændelseskøen, logning, sikkerhed eller andet.

Webservicekatalog

DFDG tilbyder en række webservicekataloger med et antal webservices i hver, som kan tilgås af eksterne applikationer.

Der findes i dag:

• ca. 160 webservices, der hver tilbyder en eller flere operationer

Hver service underordnes et versionsnummer. Versionsnummer tælles op for hver servicegeneration. Beskrivelse af de enkelte services kan findes her:

• http://starwswiki.amstest.dk/

Hovedkataloget i DFDG er PjakTass, hvor de fleste webservices fremadrettet oprettes, og en række mindre kataloger, hvoraf en del forventes nedlukket med tiden. PjakTass blev i sin tid oprettet for at understøtte Pilot Jobcentrenes A-kasse Kommunikation (PJAK), samt Tilmelde, Afmelde og Status Service (TASS) i både kommuner, a-kasser og på Jobnet.

Webservices (der tilgås af eksterne aftagere og af Jobnet[5], primært PjakTass servicekataloget) er beskrevet i STAR’s webservice WIKI:

• http://starwswiki.amstest.dk/

Forretningslaget

Forretningslaget indeholder forretningskomponenter for de forskellige applikationer. Forretningslaget kan kalde andre services, via service agenter.

DFDG er opdelt i en række applikationsmoduler som har hver sine egne forretningsmoduler. Applikationsmodulet PjakTass er f.eks. opdelt i ca 75 forretningsmoduler med hvert sit ansvar.

Forretningsmodulerne foretager forretningsmæssig validering af kaldene, og der returneres fejl. Alle forretningsfejl er nummereret. Fejl kan findes ud fra kodeliste i CodeListService.

Batchjobs

DFDG indeholder en del forretningslogik som afvikles som batchjob. Afviklingen for DFDG er omfattende, og der afvikles mere end 70 batchjob, hvoraf hovedparten afvikles alle ugens dage.

Beskrivelserne er DFDG batchjobs er fordel på:

• STAR’s webservice WIKI: http://starwswiki.amstest.dk/BatchjobOversigtDFDG.ashx?HL=batchjob
• STAR Dokumentationsarkiv (kræver login)

https://dokumentationsarkiv.star.dk/Lists/Batch%20Dokumentation/AllItems.aspx

Her den overordnede gruppering af jobs:

Datalaget

Dataadgangslaget i DFDG håndterer helt klassisk adgangen til databaser og eksterne services og tilbyder et abstraktionslag mod data/services så forretningslaget kan anvende og gemme data uafhængigt af kilden.

Data access

Under DFDG opsamles data i en række databaser. De enkelte DFDG databaser anvender alt overvejende Stored Procedures som adgang til tabeller og data. Hoveddatabasen under DFDG er BrokerServices. Denne indeholder mange hundrede Stored Procedures.

Databaserne er listet i det følgende:

Service agents

DFDG kalder eksterne services, her kan kort nævnes:

Miljøer

Følgende er en kort introduktion til de anvendte miljøer.

Produktionsmiljø

DFDG eksekveres i dag i en webfarm med en række webservere og et database-cluster, som illustreret på følgende:

Figur 5: Driftsarkitektur (produktion)

Serverne er Microsoft Windows Baserede, og anvender følgende serversoftware:

• Windows Server 2012R2
• SQL Server 2008R2

Miljøet afvikles i en to-centre drift konfiguration. Miljøet kører samtidig i begge centre med fælles kapacitet.

Følgende observeres omkring to-center konfigurationen:

• Data er placeret i et SAN der er fuldt redundant.
• AD er redundant ved at hver AD Server står i hvert sit driftscenter-site.
• SQL Cluster er redundant via en active-passive konfiguration.
• SQL serverne for henholdsvis produktionsmiljøet og præ-produktion, er placeret i hvert sit driftscenter-site.
• Web servere er redundant ved at disse er jævnt fordelt på hvert driftscenter-site.

Driftsleverandøren er KMD på driftsaftale indgået gennem Statens IT.

Testmiljø

Eksternt rettede testmiljøer hostes hos TDC. Testmiljøerne indeholder både DFDG, Jobnet og andre af STAR’s løsninger.

Der tilbydes en lang række miljøer som er opdelt i forhold til de forskellige spor og test pass som koden løber igennem. Det er miljøer til:

• Kundetest
• Ekstern integrationstest
• Intern integrationstest
• Leverandørtest
• Udviklingstest

DFDG releases til de enkelte miljøer med faste intervaller eller efter behov, afhængigt af miljø.

Anvendte teknologier og værktøjer

Løsningen er Microsoft baseret og vedligeholdes for det væsentligste med Microsoft standardværktøjer, fra Microsoft Web Platformen.

Udviklingen forgår primært med anvendelse af:

• Visual Studio 2013 Enterprise Edition
• Visual Studio Online (TFS)

Og ved anvendelse af følgende teknologier:

• Microsoft.NET C# V2.0, V4.0 og V4.5 (Hovedparten i V4.0)
• WCF
• EntityFramework
• T-SQL Stored Procedures

Samt følgende væsentlige .NET biblioteker:

• Log4net

Data- og trafikmængder

Datamængder

Der registreres årligt en lang række data i DFDG, datamængden kan ses som en funktion af antallet af personer som er i berøring med beskæftigelsessystemet. Nedenfor er angivet antallet af forløb og personer fordelt på en række af de målgrupper der behandles i DFDG.

Data samles i DFDG’s underliggende databaser, primært BrokerServices databasen. Den samlede datamængde i produktionsmiljøet er:

• DFDG databaser: ca. 430 GB data
• DFDG programværk: ca. 500 MB filer

DFDG indeholder data om ca. 4.500.000 borgere.

Trafikmængder

Samlet set gennemføres dagligt ca. 4 000 000 servicekald mod DFDG, og trafikken forventes at være stigende.

Kodemængder

Kørsel med en standardinstallation af NDepend værktøjet på koden giver følgende resultat:

Forventninger til fremtiden

Forretningsmæssigt og funktionelt

STAR forventer, at der skal ske en konsolidering af de udviklede løsninger – og fremover i mindre omfang udvikles nye funktioner[6]. STAR er i gang med at modernisere/udfase ældre portaler og forventer at der sker en konsolidering af funktioner, der skal overleve, i LSS og i JobKon.

STAR forventer, at jobcentre og a-kasser i stigende omfang begynder at anvende en flerleverandør-strategi. DFDG og Systemforvalter skal derfor kunne håndtere, at ikke alle serviceaftager påbegynder anvendelsen af nye services eller nye versioner af en service på én gang.

Det forventes at DFDG i større omfang end hidtil skal være bagud kompatible således, at nogle serviceaftagere kan anvende nye services eller nyeste version af en service, mens andre i en periode forbliver på en ældre udgave.

STAR forventer, at der som led i den kommende fællesoffentlige digitaliseringsstrategi i større omfang end hidtil skal ske en målrettet deling af nødvendige oplysninger på tværs af sektorområder. Fx på tværs af beskæftigelsesområdet, socialområdet og sundhedsområdet.

DFDG har i dag i et vist omfang deling af nødvendige oplysninger med Undervisningsministeriet. Der er i DFDG ved at blive udviklet en service til deling af oplysninger om unge med et uddannelsespålæg med Uddannelses- og Forskningsministeriet (Styrelsen for Videregående Uddannelser, der administrerer SU).

Teknisk

STAR forventer at følgende skal gennemføres inden for en horisont på 2 år:

• Yderligere robustgøring af batchjob
• Udfasning af printarkivet
• Fjernelse af ubrugte databaser og ubrugte tabeller

Teknisk gæld

Der er i forbindelse med videreudvikling gennem de sidste 4 år gjort en indsats for at reducere den tekniske gæld i de dele af systemet, som har været berørt af videreudvikling.

Tilstandsvurdering af systemet

Gartner har i juni 2015 gennemført en kildekode- og databaseanalyse.

Arkitektur og kode

Det er Gartners opfattelse at koden grundlæggende er sund og velstruktureret, og kan også fremadrettet anvendes som fælles central dataplatform.

Fordelingen af ansvar mellem Jobnet og DFDG er trods den gradvise udvikling af Jobnet til at varetage flere opgaver holdt relativt klar. Det giver et sundt udgangspunkt for videre udvikling.

Det bemærkes dog på den negative side at kodekommentarniveauet i DFDG er lidt for lavt, der foretages for få logninger, klasserne er generelt til den store side.

Database og scripts

Databasen er velstruktureret og normaliseret, dog anvendes der i udpræget grad stored procedures, hvoraf mange er komplekse og mangelfuldt dokumenteret. Flere af databaserelationerne er sub-optimale og kan reducere ydeevne, øge vedligeholdelsesomkostninger og være en kilde til fejl.

Teknologisk platform

Den teknologiske platform er homogen på tværs af de centrale systemer i arkitekturen (Jobnet og DFDG) (Microsoft.Net version 4 er den overordnede platform).

Den teknologiske platform har ikke problemer med forældede teknologier.

Den teknologiske platform giver således ikke anledning til bekymring eller overvejelser omkring udskiftning af teknologier på grund af manglende support.

Dokumentationsniveau

Kun dokumentationsniveau i koden er undersøgt. Denne vurderes til at være middel.

Brugervenlighed

N/A