Den Offentlige Integrationsmodel, OIM

Her beskrives tre generiske processer omkring integration af portalservices i portalerne, svarende til de tre overordnede scenarier for brug af integrationsmodellen.

• Integration af en portalservice i en af de to portaler.
• Integration af en ny version af en portalservice, som i forvejen er udstillet i portalen.
• Fjernelse af en portalservice fra en af de to portaler.

Der er tale om generiske processer i den forstand, at de peger på roller og aktiviteter, som skal konkretiseres i hvert enkelt tilfælde, hvor en konkret serviceudbyder skal arbejde med en konkret portalservice i en konkret portal. Procesbeskrivelserne fokuserer på fælles elementer, men peger også på steder, hvor der eksempelvis kan være tale om forskelle mellem de to portaler. Eksempelvis skal dele af processen som udgangspunkt udføres to gange, hvis den samme portalservice skal udstilles på – eller fjernes fra – begge portaler. En række aktiviteter foretages én gang eller i begrænset omfang i andet gennemløb, ligesom viden og resultater kan genbruges på tværs af de to gennemløb af processen.

Processerne understøttes af retningslinier, der giver mere præcise anvisninger, og uddyber særlige forhold for de enkelte integrationsformer.

Processerne omfatter ikke governance over den samlede portefølje af portalservice på de to portaler, ligesom processen frem til beslutning om at udbyde – eller fjerne – en portalservice ligger uden for rammerne af integrationsmodellen. Det samme gælder processer vedrørende etablering og løbende vedligeholdelse af portalerne.

Processerne i integrationsmodellen vil med fordel kunne anvendes inden for rammerne af PRINCE2 vedrørende governance og projektledelse af udviklingsarbejdet og ITIL vedrørende drift og it-serviceprocesser samt rammer for håndtering af infrastruktur, eksempelvis etablering af support- og driftserviceaftaler, ændrings- og releasestyring.

Nedenfor beskrives de roller, som indgår i de tre processer, efterfulgt af et diagram og aktivitetsbeskrivelser for hver proces.

Roller

I processerne indgår et antal aktører, dvs. de organisatoriske enheder og de roller, de spiller. Overordnet set indgår tre aktører i processen:

• Serviceudbyder
• Portalejer
• IdP udbyder

Serviceudbyder repræsenterer i processerne en myndighed, herunder eventuelle leverandører og deres underleverandører, som skal udstille en portalservice på en eller begge portaler. Hvis to eller flere myndigheder i fællesskab skal udstille en portalservice, repræsenteres de i processen som én Serviceudbyder. Eksempler på en serviceudbyder er: Rødovre Kommune, SKAT og EBST.

Portalejer repræsenterer en myndighed, som drifter en af de to portaler. I praksis er der tale om Erhvervs & Selskabsstyrelsen som driftsansvarlig for virksomhedsportalen, og IT- og Telestyrelsen som driftsansvarlig for borgerportalen.

IdP udbyder repræsenterer den organisation, som driver den løsning, som portalen anvender til autentifikation (på sigt den bruger/rettigheds-løsning, som portalen anvender). For virksomhedsportalens vedkommende er det Erhvervs & Selskabsstyrelsen. For borgerportalens vedkommende er det den fællesoffentlige IdP aktør.

I procesdiagrammerne er de tre aktører repræsenteret af adskilte ”svømmebassiner”. Hver af disse er opdelt i nogle få roller, som er repræsenteret i procesdiagrammerne af ”svømmebaner” i det pågældende svømmebassin. Rollernes ansvar i forhold til integrationsmodellen illustreres af de aktiviteter, som er placeret i deres svømmebane. Den konkrete arbejdsfordeling sker i praksis, når disse roller skal omsættes til konkrete organisatoriske enheder og/eller personer i de enkelte myndigheder og virksomheder, som gennemfører processen. Rollerne beskrives kort nedenfor.

Projektleder
Rollen Projektleder hos Serviceudbyder repræsenterer ansvaret for planlægning og styring af udviklingsopgaven hos den eller de myndigheder, som udbyder den portalservice, der er under udvikling. Denne rolle har endvidere ansvaret for at indhente nødvendige beslutninger hos relevante beslutningstagere, så projektlederen kan indgå de relevante aftaler på Serviceudbyders vegne.

Udvikler
Rollen Udvikler hos Serviceudbyder repræsenterer kompetencen til at forestå udviklings-, test- og drifts-relaterede aktiviteter i et udviklingsforløb, der resulterer i en portalservice, som udstilles på en eller begge portaler.

Integrationssupport
Rollen Integrationssupport hos Portalejer repræsenterer kompetencen til at rådgive om hvorledes integration af en portalservice i portalen foretages. I forhold til integrationsmodellen er der fokus på rådgivning vedrørende valg af integrationsformer og retningslinier for visuel integration, sikkerhed mv. Endvidere udfører Integrationssupport integrationsopgaver i portalmiljøet såsom registrering og test af portalservices.

Service kontakt
Rollen Service kontakt hos Portalejer varetager den overordnede kontakt til serviceudbyderne.

Driftansvarlig
Rollen Driftsansvarlig hos Portalejer administrerer infrastrukturen hos Portalejer, og repræsenterer kompetencen til at sætte portalservices i drift i QA- og produktionsmiljøer.

Beslutningstager
Rollen Beslutningstager hos Portalejer repræsenterer den beslutningsmæssige kompetence til at godkende resultater fra processen. Eksempler på en beslutningstager er STS, departementschef og kontorchef.

Generelt om processerne

De parter, der deltager i processerne forventes alle at indgå aktivt og konstruktivt i samarbejdet om integration af portalservices ved eksempelvis at afsætte de nødvendige ressourcer, stille relevant dokumentation til rådighed og informere øvrige parter i rimelig tid om relevante hændelser.

I det omfang en af parterne gør brug af en ekstern leverandør til fx systemudvikling, administration eller overvågning af driftsmiljøer mv. har den part ansvaret for at styre leverandøren, således at samarbejdet fungerer i henhold til indgåede aftaler mellem parterne.

Integrationsmodellens processer beskriver en arbejdsdeling mellem de involverede parter, men angiver ikke juridisk placering af ansvar mellem parterne i relation til forhold som sikkerhed, håndtering af persondata mv. På dette område ændrer integrationsmodellen ikke ved eksisterende regler.

Processerne i integrationsmodellen er ikke et forsøg på at beskrive alle de mulige gennemløb, som kan foretages i konkrete situationer, men en hjælp til at strukturere et konkret forløb og til at huske de væsentlige ting undervejs.

Integrationsmodellen beskriver derfor et fremadskridende forløb uden afbrydelser og tilbageløb, et såkaldt solskinsscenario, for hver af de tre processer. Dette giver en overskuelig ramme for aktivitetsbeskrivelserne, men i et konkret gennemløb af en af processerne vil der ofte være afvigelser fra dette solskinsscenario, fx i form af pauser eller iterationer i forløbet eller, at enkelte aktiviteter gennemføres samtidigt. På tilsvarende måde kan processen principielt set afbrydes efter en vilkårlig aktivitet, såfremt dette er påkrævet. Der kan i dette tilfælde være behov for at ”rydde op” efter de aktiviteter, der er gennemført.

Der kan godt være flere konkrete gennemløb af processerne i gang samtidig, fx kan en serviceudbyder have to integrationsforløb i gang, der integrerer hver sin portalservice på samme portal, eller samme portalservice på hver sin portal. På tilsvarende kan en serviceudbyder integrere én portalservice og fjerne en anden, således at den ene bliver aktiv samtidig med at den anden fjernes. Dette vil svare til at foretage koordinerede gennemløb af to af integrationsmodellens processer.

Proces for integration af en portalservice på en af de to portaler

Udgangspunktet for processen for at integrere en portalservice på en af de to portaler er, at beslutningen om at integrere en portalservice, er truffet.

Processen illustreres grafisk i nedenstående diagram. Bemærk, at hvis portalservicen skal udstilles på begge portaler, gennemløbes processen som udgangspunkt to gange.

∞

Aktiviteter

Aktiviteterne i procesdiagrammet beskrives nedenfor, grupperet efter aktør. For hver aktivitet beskrives væsentlige trin, som den ansvarlige aktør udfører, relevante input og forudsætninger for aktiviteten og de resultater, som kommer ud af aktiviteten. Endelig er der henvisninger til yderligere information, som understøtter aktøren i at udføre aktiviteten. Der kan være henvisninger til retningslinier i informationsmodellen og til eksterne kilder.

Aktiviteter hos Serviceudbyder

Etablér kontakt til portalejer

Ansvarlig	Projektleder (Serviceudbyder)
Beskrivelse	Portalejer kontaktes for at aftale et forløb frem mod integration af en portalservice på portalen. Vær opmærksom på egne og eksterne deadlines og deraf afledte afhængigheder og tidsfrister mellem parterne. I samarbejde med Portalejer fastlægges behovet for tværgående projektledelse og koordinering, kontaktpersoner og kommunikation mv. Rollerne i processen skal besættes med konkrete ressourcer og der skal udpeges kontakt­personer, så der etableres den fornødne organisatoriske understøttelse til integrationsarbejdet.
Input og forudsætninger	Beslutning om udvikling af portalservice og integration på portal er truffet. Hvis flere myndigheder er fælles om udstilling af en portalservice, er deres indbyrdes ansvarsfordeling afklaret.
Eventuelle gældende drift- og supportaftaler. Resultat	Kontaktinformation og aftale om at igangsætte et integrationsforløb.
Henvisninger	[ITILv3]: Transition Planning and Support, Change Mgt. VIRK [MYNDIGHEDSNET]. BORGER [OMBORGER].

Vælg integrationsform, tests mv.

Ansvarlig	Udvikler (Serviceudbyder)
Beskrivelse	Der skal vælges integrationsform for den portalservice, som skal integreres. Valget træffes ud fra en række parametre. For en eksisterende portalservice kan valget være givet på forhånd. Andre parametre, der kan påvirke valget er: - Eksisterende integrationsinfrastruktur i brug mellem serviceudbyder og portal. - Serviceudbyders øvrige infrastruktur, fx udviklings- og driftsmiljø. - Funktionalitet i portalservicen. - Initiel rådgivning fra portalejer.
Input og forudsætninger	Viden om portalservicens funktionalitet og tekniske egenskaber samt og serviceudbyders infrastruktur, fx udviklings- og driftsmiljø. Initiel rådgivning fra portalejer.
Resultat	Integrationsform for portalservicen er valgt. Ambitionsniveau fastlagt for integrationsforløbet, særligt tests.
Henvisninger	Integrationsmodellens bilag A. [ITILv3]: Service Level Mgt., Service Operation. VIRK [MYNDIGHEDSNET]. BORGER [OMBORGER].

Indgå aftale med IdP udbyder

Ansvarlig	Projektleder (Serviceudbyder)
Beskrivelse	Der indgås trustaftale med IdP udbyderen, således at portalservicen kan indgå i SSO.
Input og forudsætninger	Viden om portalservicens funktionalitet og tekniske egenskaber. Viden om serviceudbyders sikkerhedsinfrastruktur. Eventuelle gældende drift- og supportaftaler.
Resultat	Trustaftale
Henvisninger	Integrationsmodellens bilag A. [ITILv3]: Information Security Mgt. VIRK [MYNDIGHEDSNET]. BORGER [OMBORGER].

Indgå aftale med portalejer

Ansvarlig	Projektleder (Serviceudbyder)
Beskrivelse	Der indgås en tilslutningsaftale med Portalejer. Aftalen fastlægger interessenter, opgavefordeling, overordnet tidsplan samt tekniske forhold som integrationsform mv. Vær opmærksom på at aftale eventuel anvendelse af portalens ”sandkassemiljø” under udvikling. Vær opmærksom på nødvendig infrastruktur, såsom kommunikationslinier, SSO infrastruktur mv. og indarbejd eventuel etablering heraf i planer og aftaler mv. Det kan være hensigtsmæssigt at konsultere interessenterne inden der indgås en aftale med portalejer og IdP udbyder for at sikre, at alle forudsætninger er på plads. Der kan således forekomme en kalendermæssig pause i processen inden de næste aktiviteter.
Input og forudsætninger	Viden om portalservicens funktionalitet og tekniske egenskaber. Planer for integrationsforløb. Eventuelle gældende drift- og serviceaftaler.
Resultat	Tilslutningsaftale. Aftaler vedr. samarbejdet under integrationsforløbet.
Henvisninger	[ITILv3]: Service Level Mgt. VIRK [MYNDIGHEDSNET]. BORGER [OMBORGER].

Udvikl service

Ansvarlig	Udvikler (Serviceudbyder)
Beskrivelse	Her gennemføres det udviklingsarbejde, som er nødvendigt for at levere en portalservice klar til test. Hvis der er tale om en eksisterende portalservice, som skal integreres på portalen, er det ikke nyudvikling forfra, men der foretages den nødvendige tilpasning, fx vedrørende styling eller SSO. Vær opmærksom på, at anvendelse af portalens og IdP udbyders ”sandkassemiljø” kan være begrænset til bestemte tidsrum og udvalgte ressourcer. Der kan være afhængigheder mellem disse to miljøer og serviceudbyders eget udviklings/testmiljø, som skal håndteres undervejs. Dette kræver koordinering mellem parterne. Det kan være nødvendigt at foretage en ”test-opmærkning” af portalservicen og en ”test-registrering” hos IdP udbyderen, for at kunne anvende sandkassemiljøerne undervejs, og for at kunne se om portalservicen fungerer korrekt fx med hensyn til styling.
Input og forudsætninger	Integrationsrådgivning Portal sandkassemiljø IdP sandkassemiljø
Resultat	Portalservice udviklet.
Henvisninger	Serviceudbyders/leverandørs egen udviklingsmodel Integrationsmodellens bilag A. VIRK [MYNDIGHEDSNET], [DESIGNVIRK]. BORGER [OMBORGER], [DESIGNBORGER]. Aktivitet: Opmærk service. Aktivitet: Registrér service hos IdP.

Opmærk service

Ansvarlig	Udvikler (Serviceudbyder)
Beskrivelse	Portalservicen registreres hos portalen og opmærkes ud fra funktionalitet, målgruppe mv. i forhold til portalens struktur for emneord, temaer samt eventuelt i forhold til support- og servicekrav. Dette gøres ved hjælp af portalens registreringsværktøj.
Input og forudsætninger	Viden om portalservicens funktionalitet og tekniske egenskaber. Eventuelle gældende drift- og supportaftaler.
Resultat	Service opmærket i portalens registreringsværktøj.
Henvisninger	Integrationsmodellens bilag A. [ITILv3]: Service Level Mgt. VIRK [MYNDIGHEDSNET]. BORGER [OMBORGER].

Registrér service hos IdP

Ansvarlig	Udvikler (Serviceudbyder)
Beskrivelse	Portalservicen skal registreres hos IdP udbyder.
Input og forudsætninger	Viden om portalservicens funktionalitet og sikkerhedsmæssige egenskaber. Eventuelle gældende drift- og supportaftaler.
Resultat	Portalservice registreret i IdP miljø.
Henvisninger	Integrationsmodellens bilag A. [ITILv3]: Information Security Mgt. VIRK [MYNDIGHEDSNET]. BORGER [OMBORGER].

Planlæg tests og staging

Ansvarlig	Projektleder (Serviceudbyder)
Beskrivelse	Undervejs i integrationsforløbet skal der gennemføres en række tests, ligesom portalservice-implementeringen og andre nødvendige softwarekomponenter skal overføres mellem de forskellige udviklings- og testmiljøer hos serviceudbyderen (staging). Serviceudbyderen tester portalservicens funktionalitet og, at den er i overensstemmelse integrationsmodellens retningslinier og relevante standarder. Disse test- og staging-aktiviteter skal planlægges således, at de nødvendige ressourcer, definitioner, certifikater og sikkerhedsmæssige adgange mv. er til stede, når de behøves. Som udgangspunkt foretages denne planlægning ud fra serviceudbyderens egen udviklings- og projektstyringsmodel. Dog skal man være opmærksom på de afhængigheder, der er i forhold til testmiljøer mv. på portal- og IdP-siden. Det er nødvendigt, at disse aktiviteter planlægges i i god tid og i samarbejde med portalejer og IdP udbyder. Der kan være begrænsninger i forhold til hvornår portalservices kan aktiveres i eksempelvis Pre-produktion- og Produktion-miljøerne. Det er afgørende, at der afsættes tilstrækkelig kalendertid til at gennemføre tests, fejlretninger mv.
Input og forudsætninger	Viden om portalservicens funktionalitet og tekniske egenskaber samt om serviceudbyders infrastruktur, fx udviklings- og testmiljøer, herunder anden planlagt anvendelse heraf. Viden om testmiljøer hos IdP udbyder og portal, herunder eventuelle begrænsninger i anvendelse heraf. Eventuelle gældende drift- og supportaftaler. Testmiljø hos portalen skal til stadighed være til rådighed for serviceudbyder.
Resultat	Testplaner Krav og behov til test- og udviklingsmiljøer, ressourcer mv.
Henvisninger	[ITILv3]: Transition Planning and Support, Service Testing and Validation, Change Mgt., Service Operation, Information Security Mgt., Release and Deployment Mgt., VIRK [MYNDIGHEDSNET]. BORGER [OMBORGER].

Gennemfør tests og staging

Ansvarlig	Udvikler (Serviceudbyder)
Beskrivelse	De planlagte test- og staging-aktiviteter gennemføres. Der kan forekomme tilbageløb herfra til tidligere aktiviteter, herunder Udvikl service, og Planlæg tests og staging.
Input og forudsætninger	Testplaner. En portalservice, som er klar til test. Testmiljø hos portalen skal til stadighed være til rådighed for serviceudbyder.
Resultat	Testresultater. Portalservice på plads i det relevante driftsmiljø.
Henvisninger	[ITIL v3]: Service Testing and Validation. VIRK [MYNDIGHEDSNET]. BORGER [OMBORGER].

Godkend Go live for ny service

Ansvarlig	Projektleder (Serviceudbyder)
Beskrivelse	Portalservicen godkendes til go-live på portalen. Det sikres, at portalservicen lever op til retningslinierne i integrationsmodellen. Det sikres, at relevante forudsætninger er på plads, eksempelvis at de gennemførte tests er godkendt og der er etableret en supportorganisation. Bemærk, at der kan forekomme tilbageløb fra denne aktivitet til tidligere aktiviteter, såfremt portalservicen ikke kan godkendes.
Input og forudsætninger	Testresultater.
Resultat	Portalservice godkendt til go-live.
Henvisninger	Integrationsmodellens bilag A. Tjeklister/krav i serviceudbyders egen udviklingsmodel. [ITILv3]: Change Mgt., Release and Deployment Mgt. VIRK [MYNDIGHEDSNET]. BORGER [OMBORGER].

Aktiviteter hos IdP udbyder
Indgå aftale med serviceudbyder

Ansvarlig	IdP udbyder
Beskrivelse	Der indgås trustaftale med serviceudbyderen, således at portalservicen kan indgå i SSO. De relevante krav og forventninger til serviceudbyder og portalservicen skal formidles og aftales. Vær opmærksom på eventuelle drift- og supportaftaler, der skal etableres med egne leverandører.
Input og forudsætninger	Viden om portalservicens funktionalitet og tekniske egenskaber. Viden om serviceudbyders sikkerhedsinfrastruktur. Viden om IdP infrastruktur og de krav, den stiller til portalservicen. Eventuelle gældende drift- og supportaftaler.
Resultat	Trustaftale.
Henvisninger	Integrationsmodellens bilag A. [ITILv3]: Service Level Mgt., Supplier Mgt., Security Mgt. VIRK [MYNDIGHEDSNET]. BORGER [OMBORGER].

Konfigurér service i IdP miljø

Ansvarlig	IdP udbyder
Beskrivelse	Den nødvendige konfigurering af IdP miljøet foretages, således at portalservicen kan fungere i sammenhæng med SSO infrastrukturen.
Input og forudsætninger	Trustaftale. Serviceregistrering.
Resultat	IdP miljø konfigureret.
Henvisninger

[ITILv3]: Configuration Mgt.

Aktiviteter hos Portalejer
Etablér support til serviceudbyder

Ansvarlig	Servicekontakt (Portalejer)
Beskrivelse	Der etableres kontakt til serviceudbyder og der foretages en afdækning af behov for support og rådgivning i integrationsforløbet. Ud fra de afdækkede behov etableres den nødvendige support ved at besætte rollerne i processen med konkrete ressourcer og udpege kontaktpersoner. Det aftales med serviceudbyder at igangsætte et integrationsforløb.
Input og forudsætninger	Kontakt fra serviceudbyder og viden om behov. Eventuelle gældende drift- og supportaftaler.
Resultat	Kontaktpersoner og supportressourcer er udpeget og aftale med serviceudbyder om at igangsætte et integrationsforløb.
Henvisninger	[ITILv3]: Service Level Mgt. VIRK [MYNDIGHEDSNET]. BORGER [OMBORGER].

Rådgiv om valg af integrationsform mv.

Ansvarlig	Integrationssupport (Portalejer)
Beskrivelse	Der ydes initiel rådgivning til serviceudbyderen med fokus på integration, herunder valg af integrationsform og deraf følgende retningslinier for integration, hvilke tests der skal udføres og eventuelle komponenter i portalmiljøet, som serviceudbyder skal planlægge med at anvende til trafiktælling, styling, SSO mv. Vær opmærksom på om serviceudbyderen har andre portalservices på portalen. Dette kan reducere behovet for rådgivning. Vær opmærksom på planlagte ændringer i portalmiljøet, herunder opgraderinger af basissoftware mv. der kan påvirke integrationsforløbet. VIRK Serviceudbyder forventes at kunne finde størstedelen af den nødvendige information på [MYNDIGHEDSNET]. Eventuelt afholdes møder.
Input og forudsætninger	Information fra serviceudbyder om portalservicens funktionalitet og tekniske egenskaber. Viden om portalmiljøets kapacitet og tekniske egenskaber, herunder planlagt ændringer mv. Eventuelle gældende drift- og serviceaftaler.
Resultat	Initiel rådgivning til serviceudbyder.
Henvisninger	Integrationsmodellens bilag A. [ITILv3]: Capacity Mgt., Service Level Mgt. VIRK [MYNDIGHEDSNET]. BORGER [OMBORGER].

Indgå aftale med serviceudbyder

Ansvarlig	Beslutningstager (Portalejer)
Beskrivelse	Der indgås en tilslutningsaftale med serviceudbyder, der fastlægger interessenter, opgavefordeling, overordnet tidsplan samt tekniske forhold som integrationsform mv. Vær opmærksom på at inddrage de aktører, som skal sikre at portalejer lever op til aftalen. Vær opmærksom på planlagte ændringer i portalmiljøet, herunder opgraderinger af basissoftware mv. der kan påvirke integrationsforløbet.
Input og forudsætninger	Information fra serviceudbyder om portalservicens funktionalitet og tekniske egenskaber. Viden om portalmiljøets kapacitet og tekniske egenskaber, herunder planlagte ændringer mv. Planer for integrationsforløb. Eventuelle gældende drift- og supportaftaler.
Resultat	Tilslutningsaftale. Aftaler vedr. planlægning af samarbejdet under integrationsforløbet.
Henvisninger	[ITILv3]: Transition Planning and Support, CapacityMgt., Service Level Mgt. VIRK [MYNDIGHEDSNET]. BORGER [OMBORGER].

Rådgiv om integration

Ansvarlig	Integrationssupport (Portalejer)
Beskrivelse	Der ydes teknisk rådgivning til serviceudbyder med fokus på integration til portalen, herunder opmærkning af portalservicen. - Rådgivningen tager udgangspunkt i bl.a. - Portalservicens funktionalitet og tekniske egenskaber. - Integrationsform. - Integrationsmodellens retningslinier for den valgte integrationsform, og den konkrete fysiske implementering af disse i portalmiljøet. - Portalmiljøets kapacitet og tekniske egenskaber, herunder planlagte ændringer mv. - Om det er en eksisterende portalservice, eller den udvikles undervejs. - Tidshorisont. Vær opmærksom på specifikke komponenter i portalmiljøet til fx trafiktælling, styling og SSO, som skal anvendes ved integration af portalservicen. Vær opmærksom på eventuelle kommunikationsforbindelser, certifikater, sikkerhedsmæssige adgange mv., der skal etableres eller konfigureres undervejs, herunder eventuelle afhængigheder i forhold til IdP miljøet. Vær opmærksom på eventuelle behov for "test-opmærkning" undervejs. Vær opmærksom på planlagte ændringer i portalmiljøet, herunder opgradering af basissoftware mv.
Input og forudsætninger	Viden om portalmiljøets (særligt "sandkassemiljøets") kapacitet og tekniske egenskaber, herunder planlagte ændringer mv.
Resultat	Integrationsrådgivning.
Henvisninger	Integrationsmodellens bilag A. VIRK [MYNDIGHEDSNET], [DESIGNVIRK]. BORGER [OMBORGER], [DESIGNBORGER].

Validér opmærkning af service

Ansvarlig	Servicekontakt (Portaljer)
Beskrivelse	Den opmærkning, som serviceudbyder har foretaget i Pre-produktion-miljøet med henblik på anvendelse i produktion valideres. Der kan forekomme iterationer mellem denne aktivitet og Opmærk service hos serviceudbyder.
Input og forudsætninger	Serviceopmærkning. Viden om portalens struktur for opmærkning.
Resultat	Valideret serviceopmærkning.
Henvisninger	[ITILv3]: Service Catalogue Mgt., Service Validation and Testing. VIRK [MYNDIGHEDSNET]. BORGER [OMBORGER].

Foretag integration

Ansvarlig	Integrationssupport (Portalejer)
Beskrivelse	Der foretages den nødvendige tilpasning og konfigurering af portalmiljøet, således at portalservicen er integreret som planlagt. BORGER Der foretages en teknisk opmærkning af portalservicen i forhold til den kontekst, som portalservicen skal indgå i på portalen. Dette styrer bl.a. dynamisk sideopsætning og visning af portalservicen.
Input og forudsætninger	Information fra serviceudbyder om portalservicens funktionalitet og teknisk egenskaber. Viden om portalmiljøets kapacitet og tekniske egenskaber, herunder planlagte ændringer mv. Eventuelle gældende drift- og supportaftaler.
Resultat	Portalmiljø er tilpasset og konfigureret. BORGER Teknisk opmærkning er foretaget.
Henvisninger	Integrationsmodellens bilag A. [ITILv3]: Change Mgt., Service Asset and Configuration Mgt., VIRK [MYNDIGHEDSNET] BORGER [OMBORGER], [DESIGNBORGER]

Planlæg tests

Ansvarlig	Integrationssupport (Portalejer)
Beskrivelse	Undervejs i implementeringsforløbet skal der gennemføres en række tests. Serviceudbyder foretager nogle af disse tests separat, mens andre tests foretages af serviceudbyder i samarbejde med portalejer, og endelig foretager portalejer tests af portalservicen i samarbejde med serviceudbyder. Disse tests planlægges således at de nødvendige ressourcer er til stede hos de interessenter, der deltager i de enkelte tests. Vær opmærksom på afhængigheder i forhold til serviceudbyder og IdP udbyder og til ekstern leverandør. Vær opmærksom på at foretage planlægningen i tilstrækkelig god tid og på at afsætte tilstrækkelig kalendertid og ressourcer til tests og eventuelle fejlretninger, gentests etc. Vær opmærksom på tilgængelighed af kritiske ressourcer, herunder kommunikationslinier, test-certifikater, sikkerhedsmæssige adgange, specifikke versioner af tekniske komponenter mv. BORGER Der skal planlægges test af den tekniske opmærkning foretaget af portalejer og tests af integrationen.
Input og forudsætninger	Information fra serviceudbyder om portalservicens funktionalitet og tekniske egenskaber Information fra serviceudbyder om serviceudbyders infrastruktur, fx udviklings- og testmiljøer, herunder anden planlagt anvendelse heraf. Viden om testmiljøer hos IdP udbyder, herunder eventuelle begrænsninger i anvendelse heraf. Viden om egne testmiljøer, herunder eventuelle begrænsninger i anvendelse heraf. Eventuelle gældende drift- og supportaftaler. Testmiljø hos portalen skal til stadighed være til rådighed for serviceudbyder.
Resultat	Testplaner.
Henvisninger	[ITILv3]: Service Testing and Validation. VIRK [MYNDIGHEDSNET]. BORGER [OMBORGER].

Planlæg staging

Ansvarlig	Driftsansvarlig (Portalejer)
Beskrivelse	Undervejs i implementeringsforløbet skal portalmiljøet konfigureres, således at portalservicen bliver tilgængelig i de forskellige test- og produktion-miljøer. Det skal planlægges hvordan dette skal ske. Vær opmærksom på eventuelle perioder, hvor der ikke kan foretages staging til et specifikt test- eller produktion-miljø på portalen. Husk at involvere relevante interessenter, herunder eksterne leverandører. Vær opmærksom på afhængigheder i forhold til integrations- og test-aktiviteter hos serviceudbyder og IdP udbyder. Vær opmærksom på planlagte ændringer i portalmiljøet, herunder opgradering af basissoftware mv.
Input og forudsætninger	Tilslutningsaftale. Planer for integrationsforløb og test.
Resultat	Plan for staging af portalservice.
Henvisninger	[ITILv3]: Change Mgt., Release and Deployment Mgt. VIRK [MYNDIGHEDSNET]. BORGER [OMBORGER].

Gennemfør tests

Ansvarlig	Integrationssupport (Portalejer)
Beskrivelse	De planlagte test-aktiviteter gennemføres. Der kan forekomme tilbageløb til udviklingsaktiviteter hos serviceudbyder og Gennemfør staging.
Input og forudsætninger	Testplaner. Portalservice klar til test.
Resultat	Testresultater.
Henvisninger	[ITILv3]: Service Testing and Validation. VIRK [MYNDIGHEDSNET]. BORGER [OMBORGER].

Gennemfør staging

Ansvarlig	Driftsansvarlig (Portalejer)
Beskrivelse	De planlagte staging-aktiviteter gennemføres. Vær opmærksom på andre komponenter og ressourcer, som portalservicen er afhængig af.
Input og forudsætninger	Plan for staging af portalservice. Portalservice klar til staging.
Resultat	Portalservice på plads i det relevante driftsmiljø.
Henvisninger	[ITILv3]: Change Mgt., Release and Deployment Mgt. VIRK [MYNDIGHEDSNET]. BORGER [OMBORGER].

Godkend Go live for service

Ansvarlig	Beslutningstager (Portalejer)
Beskrivelse	Portalservicen godkendes til go-live på portalen. Det sikres, at portalservicen lever op til retningslinierne i integrationsmodellen. Det sikres, at portalservicen lever op til portalejers krav til portalservices, som skal integreres i portalen, eksempelvis, at de gennemførte tests er godkendt og, at der er etableret den fornødne support hos serviceudbyder og portalejer. VIRK Vær opmærksom på, at introside skal være på plads.
Input og forudsætninger	Testresultater.
Resultat	Portalservice godkendt til go-live på portalen.
Henvisninger	Integrationsmodellens bilag A. [ITILv3]: Change Mgt., Release and Deployment Mgt. VIRK [MYNDIGHEDSNET]. BORGER [OMBORGER].

Go live for service

Ansvarlig	Driftsansvarlig (Portalejer)
Beskrivelse	Produktion-miljøet konfigureres således at portalservicen gøres tilgængelig for brugere af portalen.
Input og forudsætninger	Portalservice godkendt til go-live på portalen.
Resultat	Portalservice på plads i produktion-miljø.
Henvisninger	[ITILv3]: Configuration Mgt. VIRK [MYNDIGHEDSNET]. BORGER [OMBORGER].

Resultater i processen

Kontaktinformation
Beskrivelse
Navn og kontaktinformation (mail, telefonnummer mv.) på de personer fra serviceudbyder og portalejer, som varetager kontakten i forbindelse med integration af portalservicen. Det kan også inkludere kontaktpersoner hos leverandører til serviceudbyder og portalejer.
Der er ingen formelle krav til de aftaler om integrationsforløbet, der indgås her.
Henvisninger


Initiel rådgivning
Beskrivelse
Information og vejledning fra portalejer om bl.a.
Valg af integrationsform og deraf følgende retningslinier.
Tests, der skal gennemføres.
Komponenter i portalmiljøet, som serviceudbyder skal anvende.
Henvisninger
VIRK Størstedelen af den nødvendige information er tilgængelig på [MYNDIGHEDSNET].
BORGER [OMBORGER].

Tilslutningsaftale
Beskrivelse
En formel aftale mellem serviceudbyder og portalejer om integration af en portalservice.
Henvisninger
VIRK [MYNDIGHEDSNET].
BORGER [OMBORGER].

Integrationsrådgivning
Beskrivelse
Teknisk rådgivning fra portalejer vedrørende integration af portalservice.
Henvisninger
Integrationsmodellens bilag A.
VIRK [MYNDIGHEDSNET].
BORGER [OMBORGER].

Serviceopmærkning
Beskrivelse
Den information om portalservicen, som skal være registreret i portalmiljøet fra serviceudbyders side, for at portalejer kan integrere portalservicen i portalmiljøet.
Opmærkningen foretages i portalens registreringsværktøj.
Henvisninger
VIRK [MYNDIGHEDSNET].
BORGER [OMBORGER].

Testplaner
Beskrivelse
Aftalte planer for de tests, der skal gennemføres i integrationsforløbet.
Henvisninger
VIRK [MYNDIGHEDSNET].
BORGER [OMBORGER].

Testresultater
Beskrivelse
Dokumentation for resultaterne af de gennemførte tests.
Henvisninger
VIRK [MYNDIGHEDSNET].
BORGER [OMBORGER].

Go live aftale
Beskrivelse
En formel aftale mellem serviceudbyder og portalejer om go-live for portalservicen.
Henvisninger
VIRK [MYNDIGHEDSNET].
BORGER [OMBORGER].

Trustaftale
Beskrivelse
En formel aftale mellem serviceudbyder og IdP udbyder om deltagelse i SSO føderation, således at portalservicen kan indgå i SSO.
Henvisninger
VIRK [MYNDIGHEDSNET].
BORGER [OMBORGER].

Serviceregistrering
Beskrivelse
Den information om portalservicen som skal være registreret i hos IdP udbyderen fra serviceudbyders side, for at IdP udbyder kan integrere portalservicen i IdP miljøet.
Henvisninger
VIRK [MYNDIGHEDSNET].
BORGER [OMBORGER].

Proces for integration af ny version af en portalservice på en af de to portaler

Processen for at integrere en ny version af en portalservice, der i forvejen på en af de to portaler illustreres grafisk i nedenstående diagram. Bemærk, at hvis den nye version af portalservicen skal udstilles på begge portaler, gennemløbes dele af processen som udgangspunkt to gange.

Processen gennemløbes når en ny version af portalservicen er ændret i forhold til den tidligere ud fra et integrationsmæssigt synspunkt. Eksempler på sådanne ændringer omfatter:

• Ændring af visuelt design, der påvirker integrationen med portalen, eksempelvis udskiftning af eget style sheet med portalens style sheet.
• Ændring af funktionalitet, der påvirker integrationen med portalen, eksempelvis ændring navigation og dialogforløb for en portalservice, der er integreret med iframe.
• Ændring af de parametre, som portalservicen modtager ved kald fra portalen.
• Ændring af portalservicens opmærkning, der påvirker integrationen med portalen, eksempelvis den kontekst, som portalservicen vises i.
• Ændring i forhold til portalservicens deltagelse i SSO.

Ændring af integrationsform er så gennemgribende en ændring set i forhold til integrationsmodellen, at det kan sidestilles med at fjerne én portalservice og integrere en helt ny portalservice.

Ændringer i portalservicens funktionalitet, der foretages løbende for eksempelvis at tilføje et nyt felt i en indberetningsform, behøver ikke nødvendigvis at involvere portalen og dermed integrationsmodellens proces.

Der skal foretages en vurdering ved hvær ændring af portalservicens funktionalitet og tekniske egenskaber. Processen for at integrere en ny version gennemløbes, når det vurderes, at der er behov for at serviceudbyder og portalejer i fællesskab gennem rådgivning, aftaler, tests mv. sikrer, at den nye version fungerer tilfredsstillende. Vurderingen sker på serviceudbyderens initiativ, og portalejeren kan med fordel inddrages heri i tvivlstilfælde.

∞

Aktiviteter

Aktiviteter hos Serviceudbyder

Etablér kontakt til portalejer

Ansvarlig	Projektleder (Serviceudbyder)
Beskrivelse	Portalejer kontaktes for at aftale et forløb frem mod integration af en ny version af en portalservice. Vær opmærksom på egne og eksterne deadlines og deraf afledte afhængigheder og tidsfrister mellem parterne. I samarbejde med Portalejer fastlægges behovet for tværgående projektledelse og koordinering, kontaktpersoner og kommunikation mv. Vær opmærksom på berørte parter, som kan blive påvirket af, at der skiftes version af portalservicen. Rollerne i processen skal besættes med konkrete ressourcer og der skal udpeges kontakt­personer, så der etableres den fornødne organisatoriske understøttelse til integrationsarbejdet. Vær opmærksom på eventuel eksisterende dokumentation mv. som kan anvendes.
Input og forudsætninger	Beslutning om integration af ny version er truffet. Hvis flere myndigheder er fælles om udstilling af en portalservice, er deres indbyrdes ansvarsfordeling afklaret.
Resultat	Kontaktinformation og aftale om at igangsætte et integrationsforløb.
Henvisninger	[ITILv3]: Transition Planning and Support, Change Mgt. VIRK [MYNDIGHEDSNET]. BORGER [OMBORGER].

Udvikl ny version

Ansvarlig	Udvikler (Serviceudbyder)
Beskrivelse	Her gennemføres det udviklingsarbejde, som er nødvendigt for at levere en ny version klar til test. Vær opmærksom på, at anvendelse af portalens og IdP udbyders ”sandkassemiljø” kan være begrænset til bestemte tidsrum og udvalgte ressourcer. Der kan være afhængigheder mellem disse to miljøer og serviceudbyders eget udviklings/testmiljø, som skal håndteres undervejs. Dette kræver koordinering mellem parterne. Det kan være nødvendigt at foretage en ”test-opmærkning” af den nye version og eventuelt en ”test-registrering” hos IdP udbyderen, for at kunne anvende sandkassemiljøerne undervejs, og for at kunne se om portalservicen fungerer korrekt fx med hensyn til styling.
Input og forudsætninger	Integrationsrådgivning Portal sandkassemiljø IdP sandkassemiljø
Resultat	Ny version af portalservice udviklet.
Henvisninger	Serviceudbyders/leverandørs egen udviklingsmodel Integrationsmodellens bilag A. VIRK [MYNDIGHEDSNET], [DESIGNVIRK]. BORGER [OMBORGER], [DESIGNBORGER]. Aktivitet: Opmærk ny version.

Opmærk ny version

Ansvarlig	Udvikler (Serviceudbyder)
Beskrivelse	Eventuelle ændringer af registrering og opmærkning hos portalen foretages i forhold til portalens struktur for emneord, temaer mv. samt eventuelt i forhold til ændrede support- og servicekrav. Dette gøres ved hjælp af portalens registreringsværktøj.
Input og forudsætninger	Viden om eventuelle ændringer i portalservicens funktionalitet og tekniske egenskaber. Eventuelle gældende drift- og supportaftaler.
Resultat	Ny version opmærket i portalens registreringsværktøj.
Henvisninger	Integrationsmodellens bilag A. [ITILv3]: Service Level Mgt. VIRK [MYNDIGHEDSNET]. BORGER [OMBORGER].

Planlæg tests og staging

Ansvarlig	Projektleder (Serviceudbyder)
Beskrivelse	Undervejs i integrationsforløbet skal der gennemføres en række tests, ligesom den nye version af portalservice-implementeringen og eventuelt andre nødvendige softwarekomponenter skal overføres mellem de forskellige udviklings- og testmiljøer hos serviceudbyderen (staging). Serviceudbyderen tester den nye versions funktionalitet og, at den er i overensstemmelse integrationsmodellens retningslinier og relevante standarder. Disse test- og staging-aktiviteter skal planlægges således, at de nødvendige ressourcer, definitioner, certifikater og sikkerhedsmæssige adgange mv. er til stede, når de behøves. Som udgangspunkt foretages denne planlægning ud fra serviceudbyderens egen udviklings- og projektstyringsmodel. Dog skal man være opmærksom på de afhængigheder, der er i forhold til testmiljøer mv. på portal- og IdP-siden. Det er nødvendigt, at disse aktiviteter planlægges i i god tid og i samarbejde med portalejer og IdP udbyder. Der kan være begrænsninger i forhold til hvornår portalservices kan aktiveres i eksempelvis Pre-produktion- og Produktion-miljøerne. Det er afgørende, at der afsættes tilstrækkelig kalendertid til at gennemføre tests, fejlretninger mv. Vær opmærksom på erfaringer fra det oprindelige integrationsforløb. Fokusér på test af ændringer i den nye version.
Input og forudsætninger	Viden om den nye versions funktionalitet og tekniske egenskaber samt om serviceudbyders infrastruktur, fx udviklings- og testmiljøer, herunder anden planlagt anvendelse heraf. Viden om testmiljøer hos IdP udbyder og portal, herunder eventuelle begrænsninger i anvendelse heraf. Eventuelle gældende drift- og supportaftaler. Testmiljø hos portalen skal til stadighed være til rådighed for serviceudbyder.
Resultat	Testplaner Krav og behov til test- og udviklingsmiljøer, ressourcer mv.
Henvisninger	[ITILv3]: Transition Planning and Support, Service Testing and Validation, Change Mgt., Service Operation, Information Security Mgt., Release and Deployment Mgt. VIRK [MYNDIGHEDSNET]. BORGER [OMBORGER].

Gennemfør tests og staging

Ansvarlig	Udvikler (Serviceudbyder)
Beskrivelse	De planlagte test- og staging-aktiviteter gennemføres. Der kan forekomme tilbageløb herfra til tidligere aktiviteter, herunder Udvikl ny version, og Planlæg tests og staging. Input og forudsætninger Testplaner. En ny version, som er klar til test.
Input og forudsætninger	Testmiljø hos portalen skal til stadighed være til rådighed for serviceudbyder. Viden om den nye versions funktionalitet og tekniske egenskaber samt om serviceudbyders infrastruktur, fx udviklings- og testmiljøer, herunder anden planlagt anvendelse heraf. Viden om testmiljøer hos IdP udbyder og portal, herunder eventuelle begrænsninger i anvendelse heraf.
Resultat	Testresultater. Ny version af portalservice på plads i det relevante driftsmiljø.
Henvisninger	[ITILv3]: Service Testing and Validation. VIRK [MYNDIGHEDSNET]. BORGER [OMBORGER].

Godkend Go live for ny version

Ansvarlig	Projektleder (Serviceudbyder)
Beskrivelse	Den nye version af portalservicen godkendes til go-live på portalen. Det sikres, at den nye version lever op til retningslinierne i integrationsmodellen. Det sikres, at relevante forudsætninger er på plads, eksempelvis at de gennemførte tests er godkendt og, at supportorganisationen er forberedt på den nye version. Bemærk, at der kan forekomme tilbageløb fra denne aktivitet til tidligere aktiviteter, såfremt den nye version ikke kan godkendes.
Input og forudsætninger	Testresultater.
Resultat	Ny version af portalservice godkendt til go-live.
Henvisninger	Integrationsmodellens bilag A. Tjeklister/krav i serviceudbyders egen udviklingsmodel. [ITILv3]: Change Mgt., Release and Deployment Mgt. VIRK [MYNDIGHEDSNET]. BORGER [OMBORGER].

Aktiviteter hos Portalejer
Etablér support til serviceudbyder

Ansvarlig	Servicekontakt (Portalejer)
Beskrivelse	Der etableres kontakt til serviceudbyder og der foretages en afdækning af behov for support og rådgivning i integrationsforløbet. Vær opmærksom på erfaringer fra det oprindelige integrationsforløb. Ud fra de afdækkede behov etableres den nødvendige support ved at besætte rollerne i processen med konkrete ressourcer og udpege kontaktpersoner. Det aftales med serviceudbyder at igangsætte et integrationsforløb. Vær opmærksom på eventuelle behov for fallback procedurer ved go-live.
Input og forudsætninger	Kontakt fra serviceudbyder og viden om behov. Eventuelle gældende drift- og supportaftaler.
Resultat	Kontaktpersoner og supportressourcer er udpeget og aftale med serviceudbyder om at igangsætte et integrationsforløb.
Henvisninger	[ITILv3]: Service Level Mgt. VIRK [MYNDIGHEDSNET]. BORGER [OMBORGER].

Rådgiv om integration

Ansvarlig	Integrationssupport (Portalejer)
Beskrivelse	Der ydes teknisk rådgivning til serviceudbyder med fokus på integration til portalen, herunder eventuel ændret opmærkning. Rådgivningen tager udgangspunkt i bl.a. - Den nye versions funktionalitet og tekniske egenskaber. - Integrationsform. - Integrationsmodellens retningslinier for den valgte integrationsform, og den konkrete fysiske implementering af disse i portalmiljøet. - Portalmiljøets kapacitet og tekniske egenskaber, herunder planlagte ændringer mv. - Tidshorisont. Vær opmærksom på eventuelle behov for ”test-opmærkning” undervejs. Vær opmærksom på planlagte ændringer i portalmiljøet, herunder opgradering af basissoftware mv.
Input og forudsætninger	Viden om portalmiljøets (særligt ”sandkassemiljøets) kapacitet og tekniske egenskaber, herunder planlagte ændringer mv.
Resultat	Integrationsrådgivning.
Henvisninger	Integrationsmodellens bilag A. VIRK [MYNDIGHEDSNET], [DESIGNVIRK]. BORGER [OMBORGER], [DESIGNBORGER].

Validér opmærkning af ny version

Ansvarlig	Servicekontakt (Portaljer)
Beskrivelse	Den opmærkning, som serviceudbyder har foretaget i Pre-produktion-miljøet med henblik på anvendelse i produktion valideres. Der kan forekomme iterationer mellem denne aktivitet og Opmærk ny version hos serviceudbyder.
Input og forudsætninger	Serviceopmærkning. Viden om portalens struktur for opmærkning.
Resultat	Valideret serviceopmærkning.
Henvisninger	[ITILv3]: Service Catalogue Mgt., Service Validation and Testing. VIRK [MYNDIGHEDSNET]. BORGER [OMBORGER].

Foretag integration

Ansvarlig	Integrationssupport (Portalejer)
Beskrivelse	Der foretages den nødvendige tilpasning og konfigurering af portalmiljøet, således at den nye version er integreret som planlagt. BORGER Der foretages nødvendige ændringer i den tekniske opmærkning i forhold til den kontekst, som den nye version skal indgå i på portalen. Dette styrer bl.a. dynamisk sideopsætning og visning af portalservicen.
Input og forudsætninger	Information fra serviceudbyder om den nye versions funktionalitet og teknisk egenskaber. Viden om portalmiljøets kapacitet og tekniske egenskaber, herunder planlagte ændringer mv. Eventuelle gældende drift- og supportaftaler.
Resultat	Portalmiljø er tilpasset og konfigureret. BORGER Teknisk opmærkning er eventuelt ændret.
Henvisninger	Integrationsmodellens bilag A. [ITILv3]: Change Mgt., Service Asset and Configuration Mgt. VIRK [MYNDIGHEDSNET] BORGER [OMBORGER], [DESIGNBORGER]

Planlæg tests

Ansvarlig	Integrationssupport (Portalejer)
Beskrivelse	Undervejs i implementeringsforløbet skal der gennemføres en række tests. Serviceudbyder foretager nogle af disse tests separat, mens andre tests foretages af serviceudbyder i samarbejde med portalejer, og endelig foretager portalejer tests af portalservicen i samarbejde med serviceudbyder. Disse tests planlægges således at de nødvendige ressourcer er til stede hos de interessenter, der deltager i de enkelte tests. Vær opmærksom på erfaringer fra det oprindelige integrationsforløb, og fokusér tests på ændringer. Vær opmærksom på afhængigheder i forhold til serviceudbyder og IdP udbyder og til ekstern leverandør. Vær opmærksom på at foretage planlægningen i tilstrækkelig god tid og på at afsætte tilstrækkelig kalendertid og ressourcer til tests og eventuelle fejlretninger, gentests etc. Vær opmærksom på tilgængelighed af kritiske ressourcer, herunder kommunikationslinier, test-certifikater, sikkerhedsmæssige adgange, specifikke versioner af tekniske komponenter mv. BORGER Der skal planlægges test af den tekniske opmærkning foretaget af portalejer og tests af integrationen.
Input og forudsætninger	Information fra serviceudbyder om den nye versions funktionalitet og tekniske egenskaber Information fra serviceudbyder om serviceudbyders infrastruktur, fx udviklings- og testmiljøer, herunder anden planlagt anvendelse heraf. Viden om testmiljøer hos IdP udbyder, herunder eventuelle begrænsninger i anvendelse heraf. Viden om egne testmiljøer, herunder eventuelle begrænsninger i anvendelse heraf. Eventuelle gældende drift- og supportaftaler. Testmiljø hos portalen skal til stadighed være til rådighed for serviceudbyder.
Resultat	Testplaner.
Henvisninger	[ITILv3]: Service Testing and Validation. VIRK [MYNDIGHEDSNET]. BORGER [OMBORGER].

Planlæg staging

Ansvarlig	Driftsansvarlig (Portalejer)
Beskrivelse	Undervejs i implementeringsforløbet skal portalmiljøet konfigureres, således at den nye version bliver tilgængelig i de forskellige test- og produktion-miljøer. Det skal planlægges hvordan dette skal ske. Vær opmærksom på eventuelle perioder, hvor der ikke kan foretages staging til et specifikt test- eller produktion-miljø på portalen. Husk at involvere relevante interessenter, herunder eksterne leverandører, der kan blive påvirket af den nye version. Vær opmærksom på afhængigheder i forhold til integrations- og test-aktiviteter hos serviceudbyder og IdP udbyder. Vær opmærksom på planlagte ændringer i portalmiljøet, herunder opgradering af basissoftware mv.
Input og forudsætninger	Planer for integrationsforløb og test.
Resultat	Plan for staging af portalservice.
Henvisninger	[ITILv3]: Change Mgt., Release and Deployment Mgt. VIRK [MYNDIGHEDSNET]. BORGER [OMBORGER].

Gennemfør tests

Ansvarlig	Integrationssupport (Portalejer)
Beskrivelse	De planlagte test-aktiviteter gennemføres. Der kan forekomme tilbageløb til udviklingsaktiviteter hos serviceudbyder og Gennemfør staging.
Input og forudsætninger	Testplaner. Ny version klar til test.
Resultat	Testresultater.
Henvisninger	[ITILv3]: Service Testing and Validation. VIRK [MYNDIGHEDSNET]. BORGER [OMBORGER].

Gennemfør staging

Ansvarlig	Driftsansvarlig (Portalejer)
Beskrivelse	De planlagte staging-aktiviteter gennemføres. Vær opmærksom på andre komponenter og ressourcer, som den nye version er afhængig af.
Input og forudsætninger	Plan for staging af ny version.. Ny version klar til staging.
Resultat	Ny version på plads i det relevante driftsmiljø.
Henvisninger	[ITILv3]: Change Mgt., Release and Deployment Mgt. VIRK [MYNDIGHEDSNET]. BORGER [OMBORGER].

Godkend Go live for ny version

Ansvarlig	Beslutningstager (Portalejer)
Beskrivelse	Den nye version af portalservicen godkendes til go-live på portalen. Det sikres, at den nye version lever op til retningslinierne i integrationsmodellen. Det sikres, at den nye version lever op til portalejers krav til portalservices, som skal integreres i portalen, eksempelvis, at de gennemførte tests er godkendt og, at support hos serviceudbyder og portalejer er orienteret om den nye version. VIRK Vær opmærksom på, at introside eventuelt skal være ajourført.
Input og forudsætninger	Testresultater.
Resultat	Ny version af portalservice godkendt til go-live på portalen.
Henvisninger	Integrationsmodellens bilag A. [ITILv3]: Change Mgt., Release and Deployment Mgt. VIRK [MYNDIGHEDSNET]. BORGER [OMBORGER].

Go live for ny version

Ansvarlig	Driftsansvarlig (Portalejer)
Beskrivelse	Produktion-miljøet konfigureres således at den nye version af portalservicen gøres tilgængelig for brugere af portalen. Hvis det rent teknisk ikke lykkes at udskifte portalservicen med den nye version, gennemføres aftalt fall back procedure.
Input og forudsætninger	Ny version af portalservice godkendt til go-live på portalen.
Resultat	Ny version på plads i produktion-miljø. Tidligere version er arkiveret.
Henvisninger	[ITILv3]: Configuration Mgt. VIRK [MYNDIGHEDSNET]. BORGER [OMBORGER].

Resultater i processen

Kontaktinformation

Beskrivelse
Navn og kontaktinformation (mail, telefonnummer mv.) på de personer fra serviceudbyder og portalejer, som varetager kontakten i forbindelse med integration af den nye version. Det kan også inkludere kontaktpersoner hos leverandører til serviceudbyder og portalejer.
Der er ingen formelle krav til de aftaler om integrationsforløbet, der indgås her.

Henvisninger

Integrationsrådgivning

Beskrivelse
Teknisk rådgivning fra portalejer vedrørende integration af ny version af portalservice.

Henvisninger
Integrationsmodellens bilag A.
VIRK [MYNDIGHEDSNET].
BORGER [OMBORGER].

Serviceopmærkning

Beskrivelse
Den information om den nye version af portalservicen, som skal være registreret i portalmiljøet fra serviceudbyders side, for at portalejer kan integrere den nye version i portalmiljøet.
Opmærkningen foretages i portalens registreringsværktøj.

Henvisninger
VIRK [MYNDIGHEDSNET].
BORGER [OMBORGER].

Testplaner

Beskrivelse
Aftalte planer for de tests, der skal gennemføres i integrationsforløbet.

Henvisninger
VIRK [MYNDIGHEDSNET].
BORGER [OMBORGER].

Testresultater

Beskrivelse
Dokumentation for resultaterne af de gennemførte tests.

Henvisninger
VIRK [MYNDIGHEDSNET].
BORGER [OMBORGER].

Go live aftale

Beskrivelse
En formel aftale mellem serviceudbyder og portalejer om go-live for den nye version af portalservicen.

Henvisninger
VIRK [MYNDIGHEDSNET].
BORGER [OMBORGER].

Proces for at fjerne en portalservice fra en af de to portaler

Processen for at fjerne en portalservice fra en af de to portaler illustreres grafisk i nedenstående diagram. Bemærk, at hvis portalservicen skal fjernes fra begge portaler, gennemløbes processen to gange.

Processen tager udgangspunkt i, at beslutningen om at fjerne en portalservice er taget. Beslutningen kan være truffet på initiativ af serviceudbyder eller portalejer.

Aktiviteter

Aktiviteterne i procesdiagrammet beskrives nedenfor, grupperet efter aktør. For hver aktivitet beskrives væsentlige trin, som den ansvarlige aktør udfører, relevante input og forudsætninger for aktiviteten og de resultater, som kommer ud af aktiviteten. Endelig er der henvisninger til yderligere information, som understøtter aktøren i at udføre aktiviteten. Der kan være henvisninger til retningslinier i informationsmodellen og til eksterne kilder.

Aktiviteter hos Serviceudbyder

Aftal med portalejer at fjerne service

Ansvarlig	Projektleder (Serviceudbyder)
Beskrivelse	Portalejer kontaktes for at træffe aftale om at fjerne portalservice fra portalen. Forløbet frem til at portalservicen fjernes fra portalen planlægges og aftales. Vær opmærksom på eventuelle varselsfrister mv. som skal overholdes.
Input og forudsætninger	Beslutning om at fjerne portalservice fra portal er truffet. Hvis flere myndigheder er fælles om en portalservice, er deres indbyrdes ansvarsfordeling afklaret.
Resultat	Aftale om at fjerne portalservice fra portalen.
Henvisninger	[ITILv3]: Transition Planning and Support, Change Mgt.

Advisér berørte parter

Ansvarlig	Projektleder (Serviceudbyder)
Beskrivelse	Der kan være andre parter, som bliver berørt af, at en portalservice fjernes, eksempelvis, hvis de henviser til den fra deres egne løsninger. De berørte parter, som serviceudbyder har kendskab til, adviseres i tilstrækkelig god tid til, at de kan tage deres forholdsregler. Vær opmærksom på eventuelle varselsfrister fx i forhold til IdP udbyder.
Input og forudsætninger	Viden om hvilke parter, der bliver berørt af, at portalservicen fjernes.
Resultat	Berørte parter er adviseret.
Henvisninger

Godkend at fjerne service

Ansvarlig	Projektleder (Serviceudbyder)
Beskrivelse	Det godkendes, at portalservicen fjernes fra portalen. Det sikres, at de nødvendige forudsætninger er på plads, eksempelvis, at eventuelle afhængigheder mellem portalservicen og andre komponenter er håndteret og aftalte varselsfrister er overholdt.
Input og forudsætninger	Aftale om at fjerne portalservice. Viden om gennemførte aktiviteter.
Resultat	Godkendelse af at fjerne portalservice.
Henvisninger	[ITILv3]: Change Mgt., Release and Deployment Mgt. VIRK [MYNDIGHEDSNET]. BORGER [OMBORGER].

Fjern opmærkning

Ansvarlig	Udvikler (Serviceudbyder)
Beskrivelse	Der foretages den konfigurering og ændring i serviceudbyderes eget produktion-miljø og i portalens registreringsværktøj, som er nødvendig for at portalservicen fjernes fra portalen.
Input og forudsætninger	Godkendelse af at fjerne portalservice.
Resultat	Portalservice fjernet fra portal.
Henvisninger	VIRK [MYNDIGHEDSNET]. BORGER [OMBORGER].

Aktiviteter hos IdP udbyder

Tag service ud af IdP miljø

Ansvarlig	IdP udbyder
Beskrivelse	Der foretages den konfigurering af IdP miljøet, som er nødvendig for at portalservicen ikke længere indgår i SSO i forbindelse med portalen.
Input og forudsætninger	Information fra serviceudbyder om at tage portalservice ud af IdP miljøet.
Resultat	Portalservice fjernet fra IdP miljø.
Henvisninger	[ITILv3]: Configuration Mgt.

Aktiviteter hos Portalejer

Aftal med serviceudbyder at fjerne service

Ansvarlig	Servicekontakt (Portalejer)
Beskrivelse	Forløbet frem til at portalservicen fjernes fra portalen aftales. Vær opmærksom på eventuelle interne afhængigheder og varselsfrister, der skal håndteres.
Input og forudsætninger	Information fra serviceudbyder om at fjerne portalservice. Viden om portalmiljøet, herunder planlagte ændringer mv.
Resultat	Aftale om at fjerne portalservice.
Henvisninger	[ITILv3]: Transition Planning and Support. VIRK [MYNDIGHEDSNET]. BORGER [OMBORGER].

Forbered at fjerne service

Ansvarlig	Integrationssupport (Portalejer)
Beskrivelse	Der foretages den nødvendige forberedelse, således at portalmiljø, supportorganisation mv. er klar til at fjerne portalservicen. Vær opmærksom på hvem der skal informeres og eventuelle varselsfrister mv., der skal overholdes.
Input og forudsætninger	Aftale om at fjerne portalservice.
Resultat	Portalmiljø mv. er forberedt til at fjerne portalservice.
Henvisninger	[ITILv3]: Change Mgt., Release and Deployment Mgt.

Godkend at fjerne service

Ansvarlig	Beslutningstager (Portalejer)
Beskrivelse	Det godkendes, at portalservicen fjernes fra portalen. Det sikres, at de nødvendige forudsætninger er på plads, eksempelvis, at eventuelle afhængigheder mellem portalservicen og andre komponenter er håndteret, at supportorganisation er orienteret og aftalte varselsfrister er overholdt.
Input og forudsætninger	Aftale om at fjerne portalservice. Viden om forberedelse.
Resultat	Godkendelse af at fjerne portalservice.
Henvisninger	[ITILv3]: Change Mgt., Release and Deployment Mgt. VIRK [MYNDIGHEDSNET]. BORGER [OMBORGER].

Tag service ud af portal

Ansvarlig	Driftsansvarlig (Portalejer)
Beskrivelse	Der foretages den nødvendige konfigurering og ændring af portalmiljøet, herunder teknisk opmærkning, kommunikationslinier, sikkerhedsmæssige adgange mv., således at portalservicen ikke længere er tilgængelig på portalen.
Input og forudsætninger	Godkendelse af at fjerne portalservice
Resultat	Portalservice fjernet fra portal.
Henvisninger	[ITILv3]: Configuration Mgt. VIRK [MYNDIGHEDSNET]. BORGER [OMBORGER].

Resultater i processen

Aftale om at fjerne en service
Beskrivelse
En aftale mellem serviceudbyder og portalejer om at fjerne en portalservice fra portalen.
Henvisninger


Godkendt at fjerne service
Beskrivelse
En godkendt aftale om at fjerne en portalservice fra portalen.
Henvisninger


Service fjernet
Beskrivelse
Portalservicen er fjernet fra portalen, således at den ikke er tilgængelig for brugere af portalen. Dette berører ikke muligheden for at tilgå portalservicen via andre kanaler.
Henvisninger