Most recent edit on 2007-11-16 07:26:48 by WebMaster

Additions:
Proces for integration af en portalservice på en af de to portaler
Proces for integration af ny version af en portalservice på en af de to portaler
4 Anbefalinger til mønstre for udvikling af portalservices
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.
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 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.
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.
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.
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.
Rollen Driftsansvarlig hos Portalejer administrerer infrastrukturen hos Portalejer, og repræsenterer kompetencen til at sætte portalservices i drift i QA- og produktionsmiljøer.
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.
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.
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.
Etablér kontakt til portalejer
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.</td></tr><tr><td>
Input og forudsætninger</td><td>
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.</td></tr><tr><td>
Eventuelle gældende drift- og supportaftaler.
Kontaktinformation og aftale om at igangsætte et integrationsforløb.</td></tr><tr><td>
Vælg integrationsform, tests mv.
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:

• Serviceudbyders øvrige infrastruktur, fx udviklings- og driftsmiljø.
• Initiel rådgivning fra portalejer.

Input og forudsætninger</td><td>
Viden om portalservicens funktionalitet og tekniske egenskaber samt og serviceudbyders infrastruktur, fx udviklings- og driftsmiljø.
Initiel rådgivning fra portalejer.
Ambitionsniveau fastlagt for integrationsforløbet, særligt tests.
Indgå aftale med IdP udbyder
Der indgås trustaftale med IdP udbyderen, således at portalservicen kan indgå i SSO.
Input og forudsætninger</td><td>
Eventuelle gældende drift- og supportaftaler.
Indgå aftale med portalejer
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</td><td>
Planer for integrationsforløb.
Eventuelle gældende drift- og serviceaftaler.
Aftaler vedr. samarbejdet under integrationsforløbet.
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</td><td>
Integrationsrådgivning
Portal sandkassemiljø
IdP sandkassemiljø
Serviceudbyders/leverandørs egen udviklingsmodel
Aktivitet: Opmærk service.
Aktivitet: Registrér service hos IdP.
Opmærk service
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</td><td>
Viden om portalservicens funktionalitet og tekniske egenskaber. Eventuelle gældende drift- og supportaftaler.
Service opmærket i portalens registreringsværktøj.
Registrér service hos IdP
Input og forudsætninger</td><td>
Viden om portalservicens funktionalitet og sikkerhedsmæssige egenskaber. Eventuelle gældende drift- og supportaftaler.
Portalservice registreret i IdP miljø.
Planlæg tests og staging
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).
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</td><td>
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.
Krav og behov til test- og udviklingsmiljøer, ressourcer mv.
Gennemfør tests og staging
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</td><td>
Testmiljø hos portalen skal til stadighed være til rådighed for serviceudbyder.
Portalservice på plads i det relevante driftsmiljø.
Portalservicen godkendes til go-live på portalen.
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</td><td>
Indgå aftale med serviceudbyder
Der indgås trustaftale med serviceudbyderen, således at portalservicen kan indgå i SSO.
Vær opmærksom på eventuelle drift- og supportaftaler, der skal etableres med egne leverandører.
Input og forudsætninger</td><td>
Eventuelle gældende drift- og supportaftaler.
Konfigurér service i IdP miljø
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</td><td>
IdP miljø konfigureret.
Etablér support til serviceudbyder
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</td><td>
Eventuelle gældende drift- og supportaftaler.
Kontaktpersoner og supportressourcer er udpeget og aftale med serviceudbyder om at igangsætte et integrationsforløb.
Rådgiv om valg af integrationsform mv.
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</td><td>
Viden om portalmiljøets kapacitet og tekniske egenskaber, herunder planlagt ændringer mv.
Eventuelle gældende drift- og serviceaftaler.
Initiel rådgivning til serviceudbyder.
Indgå aftale med serviceudbyder
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</td><td>
Viden om portalmiljøets kapacitet og tekniske egenskaber, herunder planlagte ændringer mv.
Planer for integrationsforløb.
Eventuelle gældende drift- og supportaftaler.
Aftaler vedr. planlægning af samarbejdet under integrationsforløbet.
Rådgiv om integration
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.
• 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.

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</td><td>
Viden om portalmiljøets (særligt "sandkassemiljøets") kapacitet og tekniske egenskaber, herunder planlagte ændringer mv.
Integrationsrådgivning.
Validér opmærkning af service
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</td><td>
Serviceopmærkning.
Viden om portalens struktur for opmærkning.
Valideret serviceopmærkning.
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</td><td>
Viden om portalmiljøets kapacitet og tekniske egenskaber, herunder planlagte ændringer mv.
Eventuelle gældende drift- og supportaftaler.
Portalmiljø er tilpasset og konfigureret.
BORGER Teknisk opmærkning er foretaget.
Planlæg tests
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</td><td>
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.
Planlæg staging
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</td><td>
Planer for integrationsforløb og test.
Gennemfør tests
De planlagte test-aktiviteter gennemføres.
Der kan forekomme tilbageløb til udviklingsaktiviteter hos serviceudbyder og Gennemfør staging.
Input og forudsætninger</td><td>
Gennemfør staging
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</td><td>
Portalservice på plads i det relevante driftsmiljø.
Portalservicen godkendes til go-live på portalen.
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</td><td>
Portalservice godkendt til go-live på portalen.
Produktion-miljøet konfigureres således at portalservicen gøres tilgængelig for brugere af portalen.
Input og forudsætninger</td><td>
Portalservice godkendt til go-live på portalen.
Portalservice på plads i produktion-miljø.
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.
Initiel rådgivning
Valg af integrationsform og deraf følgende retningslinier.
Tests, der skal gennemføres.
Komponenter i portalmiljøet, som serviceudbyder skal anvende.
VIRK Størstedelen af den nødvendige information er tilgængelig på [MYNDIGHEDSNET].
Integrationsrådgivning
Teknisk rådgivning fra portalejer vedrørende integration af portalservice.
Serviceopmærkning
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.
Aftalte planer for de tests, der skal gennemføres i integrationsforløbet.
Dokumentation for resultaterne af de gennemførte tests.
En formel aftale mellem serviceudbyder og IdP udbyder om deltagelse i SSO føderation, således at portalservicen kan indgå i SSO.
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.

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.
Etablér kontakt til portalejer
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.
</td></tr><tr><td>Input og forudsætninger</td><td>
Hvis flere myndigheder er fælles om udstilling af en portalservice, er deres indbyrdes ansvarsfordeling afklaret.
Kontaktinformation og aftale om at igangsætte et integrationsforløb.
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</td><td>
Integrationsrådgivning
Portal sandkassemiljø
IdP sandkassemiljø
Serviceudbyders/leverandørs egen udviklingsmodel
Aktivitet: Opmærk ny version.
Opmærk ny version
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</td><td>
Viden om eventuelle ændringer i portalservicens funktionalitet og tekniske egenskaber.
Eventuelle gældende drift- og supportaftaler.
Ny version opmærket i portalens registreringsværktøj.
Planlæg tests og staging
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).
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</td><td>
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.
Krav og behov til test- og udviklingsmiljøer, ressourcer mv.
Gennemfør tests og staging
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
Input og forudsætninger</td><td>
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.
Ny version af portalservice på plads i det relevante driftsmiljø.
Den nye version af portalservicen godkendes til go-live på portalen.
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</td><td>
Etablér support til serviceudbyder
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</td><td>
Eventuelle gældende drift- og supportaftaler.
Kontaktpersoner og supportressourcer er udpeget og aftale med serviceudbyder om at igangsætte et integrationsforløb.
Rådgiv om integration
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.

• 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.

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</td><td>
Viden om portalmiljøets (særligt ”sandkassemiljøets) kapacitet og tekniske egenskaber, herunder planlagte ændringer mv.
Integrationsrådgivning.
Validér opmærkning af ny version
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</td><td>
Serviceopmærkning.
Viden om portalens struktur for opmærkning.
Valideret serviceopmærkning.
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</td><td>
Viden om portalmiljøets kapacitet og tekniske egenskaber, herunder planlagte ændringer mv.
Eventuelle gældende drift- og supportaftaler.
Portalmiljø er tilpasset og konfigureret.
BORGER Teknisk opmærkning er eventuelt ændret.
Planlæg tests
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</td><td>
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.
Planlæg staging
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</td><td>
Planer for integrationsforløb og test.
Gennemfør tests
De planlagte test-aktiviteter gennemføres.
Der kan forekomme tilbageløb til udviklingsaktiviteter hos serviceudbyder og Gennemfør staging.
Input og forudsætninger</td><td>
Gennemfør staging
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</td><td>
Ny version på plads i det relevante driftsmiljø.
Den nye version af portalservicen godkendes til go-live på portalen.
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</td><td>
Ny version af portalservice godkendt til go-live på portalen.
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</td><td>
Ny version af portalservice godkendt til go-live på portalen.
Ny version på plads i produktion-miljø.
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.
Integrationsrådgivning
Teknisk rådgivning fra portalejer vedrørende integration af ny version af portalservice.
Serviceopmærkning
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.
Aftalte planer for de tests, der skal gennemføres i integrationsforløbet.
Dokumentation for resultaterne af de gennemførte tests.
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.
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.
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</td><td>
Hvis flere myndigheder er fælles om en portalservice, er deres indbyrdes ansvarsfordeling afklaret.
Advisér berørte parter
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</td><td>
Viden om hvilke parter, der bliver berørt af, at portalservicen fjernes.
Berørte parter er adviseret.
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</td><td>
Viden om gennemførte aktiviteter.
Fjern opmærkning
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</td><td>
Tag service ud af IdP miljø
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</td><td>
Information fra serviceudbyder om at tage portalservice ud af IdP miljøet.
Portalservice fjernet fra IdP miljø.
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</td><td>
Viden om portalmiljøet, herunder planlagte ændringer mv.
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</td><td>
Portalmiljø mv. er forberedt til at fjerne portalservice.
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</td><td>
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</td><td>
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.

Deletions:
dardel
Proces for integration af en portalservice på en af de to portaler
Proces for integration af ny version af en portalservice på en af de to portaler
4 Anbefalinger til mønstre for udvikling af portalservices
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.
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 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.
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.
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.
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.
Rollen Driftsansvarlig hos Portalejer administrerer infrastrukturen hos Portalejer, og repræsenterer kompetencen til at sætte portalservices i drift i QA- og produktionsmiljøer.
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.
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.
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.
Etablér kontakt til portalejer
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.</td></tr><tr><td>
Input og forudsætninger</td><td>
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.</td></tr><tr><td>
Eventuelle gældende drift- og supportaftaler.
Kontaktinformation og aftale om at igangsætte et integrationsforløb.</td></tr><tr><td>
Vælg integrationsform, tests mv.
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:

• Serviceudbyders øvrige infrastruktur, fx udviklings- og driftsmiljø.
• Initiel rÃ¥dgivning fra portalejer.

Input og forudsætninger</td><td>
Viden om portalservicens funktionalitet og tekniske egenskaber samt og serviceudbyders infrastruktur, fx udviklings- og driftsmiljø.
Initiel rådgivning fra portalejer.
Ambitionsniveau fastlagt for integrationsforløbet, særligt tests.
Indgå aftale med IdP udbyder
Der indgås trustaftale med IdP udbyderen, således at portalservicen kan indgå i SSO.
Input og forudsætninger</td><td>
Eventuelle gældende drift- og supportaftaler.
Indgå aftale med portalejer
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</td><td>
Planer for integrationsforløb.
Eventuelle gældende drift- og serviceaftaler.
Aftaler vedr. samarbejdet under integrationsforløbet.
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</td><td>
Integrationsrådgivning
Portal sandkassemiljø
IdP sandkassemiljø
Serviceudbyders/leverandørs egen udviklingsmodel
Aktivitet: Opmærk service.
Aktivitet: Registrér service hos IdP.
Opmærk service
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</td><td>
Viden om portalservicens funktionalitet og tekniske egenskaber. Eventuelle gældende drift- og supportaftaler.
Service opmærket i portalens registreringsværktøj.
Registrér service hos IdP
Input og forudsætninger</td><td>
Viden om portalservicens funktionalitet og sikkerhedsmæssige egenskaber. Eventuelle gældende drift- og supportaftaler.
Portalservice registreret i IdP miljø.
Planlæg tests og staging
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).
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</td><td>
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.
Krav og behov til test- og udviklingsmiljøer, ressourcer mv.
Gennemfør tests og staging
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</td><td>
Testmiljø hos portalen skal til stadighed være til rådighed for serviceudbyder.
Portalservice på plads i det relevante driftsmiljø.
Portalservicen godkendes til go-live på portalen.
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</td><td>
Indgå aftale med serviceudbyder
Der indgås trustaftale med serviceudbyderen, således at portalservicen kan indgå i SSO.
Vær opmærksom på eventuelle drift- og supportaftaler, der skal etableres med egne leverandører.
Input og forudsætninger</td><td>
Eventuelle gældende drift- og supportaftaler.
Konfigurér service i IdP miljø
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</td><td>
IdP miljø konfigureret.
Etablér support til serviceudbyder
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</td><td>
Eventuelle gældende drift- og supportaftaler.
Kontaktpersoner og supportressourcer er udpeget og aftale med serviceudbyder om at igangsætte et integrationsforløb.
RÃ¥dgiv om valg af integrationsform mv.
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</td><td>
Viden om portalmiljøets kapacitet og tekniske egenskaber, herunder planlagt ændringer mv.
Eventuelle gældende drift- og serviceaftaler.
Initiel rådgivning til serviceudbyder.
Indgå aftale med serviceudbyder
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</td><td>
Viden om portalmiljøets kapacitet og tekniske egenskaber, herunder planlagte ændringer mv.
Planer for integrationsforløb.
Eventuelle gældende drift- og supportaftaler.
Aftaler vedr. planlægning af samarbejdet under integrationsforløbet.
RÃ¥dgiv om integration
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.
• 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.

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</td><td>
Viden om portalmiljøets (særligt "sandkassemiljøets") kapacitet og tekniske egenskaber, herunder planlagte ændringer mv.
Integrationsrådgivning.
Validér opmærkning af service
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</td><td>
Serviceopmærkning.
Viden om portalens struktur for opmærkning.
Valideret serviceopmærkning.
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</td><td>
Viden om portalmiljøets kapacitet og tekniske egenskaber, herunder planlagte ændringer mv.
Eventuelle gældende drift- og supportaftaler.
Portalmiljø er tilpasset og konfigureret.
BORGER Teknisk opmærkning er foretaget.
Planlæg tests
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</td><td>
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.
Planlæg staging
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</td><td>
Planer for integrationsforløb og test.
Gennemfør tests
De planlagte test-aktiviteter gennemføres.
Der kan forekomme tilbageløb til udviklingsaktiviteter hos serviceudbyder og Gennemfør staging.
Input og forudsætninger</td><td>
Gennemfør staging
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</td><td>
Portalservice på plads i det relevante driftsmiljø.
Portalservicen godkendes til go-live på portalen.
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</td><td>
Portalservice godkendt til go-live på portalen.
Produktion-miljøet konfigureres således at portalservicen gøres tilgængelig for brugere af portalen.
Input og forudsætninger</td><td>
Portalservice godkendt til go-live på portalen.
Portalservice på plads i produktion-miljø.
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.
Initiel rådgivning
Valg af integrationsform og deraf følgende retningslinier.
Tests, der skal gennemføres.
Komponenter i portalmiljøet, som serviceudbyder skal anvende.
VIRK Størstedelen af den nødvendige information er tilgængelig på [MYNDIGHEDSNET].
Integrationsrådgivning
Teknisk rådgivning fra portalejer vedrørende integration af portalservice.
Serviceopmærkning
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.
Aftalte planer for de tests, der skal gennemføres i integrationsforløbet.
Dokumentation for resultaterne af de gennemførte tests.
En formel aftale mellem serviceudbyder og IdP udbyder om deltagelse i SSO føderation, således at portalservicen kan indgå i SSO.
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.

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.
Etablér kontakt til portalejer
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.
</td></tr><tr><td>Input og forudsætninger</td><td>
Hvis flere myndigheder er fælles om udstilling af en portalservice, er deres indbyrdes ansvarsfordeling afklaret.
Kontaktinformation og aftale om at igangsætte et integrationsforløb.
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</td><td>
Integrationsrådgivning
Portal sandkassemiljø
IdP sandkassemiljø
Serviceudbyders/leverandørs egen udviklingsmodel
Aktivitet: Opmærk ny version.
Opmærk ny version
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</td><td>
Viden om eventuelle ændringer i portalservicens funktionalitet og tekniske egenskaber.
Eventuelle gældende drift- og supportaftaler.
Ny version opmærket i portalens registreringsværktøj.
Planlæg tests og staging
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).
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</td><td>
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.
Krav og behov til test- og udviklingsmiljøer, ressourcer mv.
Gennemfør tests og staging
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
Input og forudsætninger</td><td>
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.
Ny version af portalservice på plads i det relevante driftsmiljø.
Den nye version af portalservicen godkendes til go-live på portalen.
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</td><td>
Etablér support til serviceudbyder
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</td><td>
Eventuelle gældende drift- og supportaftaler.
Kontaktpersoner og supportressourcer er udpeget og aftale med serviceudbyder om at igangsætte et integrationsforløb.
RÃ¥dgiv om integration
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.

• 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.

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</td><td>
Viden om portalmiljøets (særligt ”sandkassemiljøets) kapacitet og tekniske egenskaber, herunder planlagte ændringer mv.
Integrationsrådgivning.
Validér opmærkning af ny version
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</td><td>
Serviceopmærkning.
Viden om portalens struktur for opmærkning.
Valideret serviceopmærkning.
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</td><td>
Viden om portalmiljøets kapacitet og tekniske egenskaber, herunder planlagte ændringer mv.
Eventuelle gældende drift- og supportaftaler.
Portalmiljø er tilpasset og konfigureret.
BORGER Teknisk opmærkning er eventuelt ændret.
Planlæg tests
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</td><td>
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.
Planlæg staging
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</td><td>
Planer for integrationsforløb og test.
Gennemfør tests
De planlagte test-aktiviteter gennemføres.
Der kan forekomme tilbageløb til udviklingsaktiviteter hos serviceudbyder og Gennemfør staging.
Input og forudsætninger</td><td>
Gennemfør staging
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</td><td>
Ny version på plads i det relevante driftsmiljø.
Den nye version af portalservicen godkendes til go-live på portalen.
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</td><td>
Ny version af portalservice godkendt til go-live på portalen.
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</td><td>
Ny version af portalservice godkendt til go-live på portalen.
Ny version på plads i produktion-miljø.
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.
Integrationsrådgivning
Teknisk rådgivning fra portalejer vedrørende integration af ny version af portalservice.
Serviceopmærkning
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.
Aftalte planer for de tests, der skal gennemføres i integrationsforløbet.
Dokumentation for resultaterne af de gennemførte tests.
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.
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.
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</td><td>
Hvis flere myndigheder er fælles om en portalservice, er deres indbyrdes ansvarsfordeling afklaret.
Advisér berørte parter
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</td><td>
Viden om hvilke parter, der bliver berørt af, at portalservicen fjernes.
Berørte parter er adviseret.
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</td><td>
Viden om gennemførte aktiviteter.
Fjern opmærkning
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</td><td>
Tag service ud af IdP miljø
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</td><td>
Information fra serviceudbyder om at tage portalservice ud af IdP miljøet.
Portalservice fjernet fra IdP miljø.
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</td><td>
Viden om portalmiljøet, herunder planlagte ændringer mv.
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</td><td>
Portalmiljø mv. er forberedt til at fjerne portalservice.
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</td><td>
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</td><td>
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.

---

Edited on 2007-11-15 05:20:35 by VarsiToule

Additions:
dardel
Proces for integration af en portalservice på en af de to portaler
Proces for integration af ny version af en portalservice på en af de to portaler
4 Anbefalinger til mønstre for udvikling af portalservices
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.
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 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.
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.
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.
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.
Rollen Driftsansvarlig hos Portalejer administrerer infrastrukturen hos Portalejer, og repræsenterer kompetencen til at sætte portalservices i drift i QA- og produktionsmiljøer.
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.
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.
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.
Etablér kontakt til portalejer
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.</td></tr><tr><td>
Input og forudsætninger</td><td>
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.</td></tr><tr><td>
Eventuelle gældende drift- og supportaftaler.
Kontaktinformation og aftale om at igangsætte et integrationsforløb.</td></tr><tr><td>
Vælg integrationsform, tests mv.
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:

• Serviceudbyders øvrige infrastruktur, fx udviklings- og driftsmiljø.
• Initiel rÃ¥dgivning fra portalejer.

Input og forudsætninger</td><td>
Viden om portalservicens funktionalitet og tekniske egenskaber samt og serviceudbyders infrastruktur, fx udviklings- og driftsmiljø.
Initiel rådgivning fra portalejer.
Ambitionsniveau fastlagt for integrationsforløbet, særligt tests.
Indgå aftale med IdP udbyder
Der indgås trustaftale med IdP udbyderen, således at portalservicen kan indgå i SSO.
Input og forudsætninger</td><td>
Eventuelle gældende drift- og supportaftaler.
Indgå aftale med portalejer
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</td><td>
Planer for integrationsforløb.
Eventuelle gældende drift- og serviceaftaler.
Aftaler vedr. samarbejdet under integrationsforløbet.
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</td><td>
Integrationsrådgivning
Portal sandkassemiljø
IdP sandkassemiljø
Serviceudbyders/leverandørs egen udviklingsmodel
Aktivitet: Opmærk service.
Aktivitet: Registrér service hos IdP.
Opmærk service
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</td><td>
Viden om portalservicens funktionalitet og tekniske egenskaber. Eventuelle gældende drift- og supportaftaler.
Service opmærket i portalens registreringsværktøj.
Registrér service hos IdP
Input og forudsætninger</td><td>
Viden om portalservicens funktionalitet og sikkerhedsmæssige egenskaber. Eventuelle gældende drift- og supportaftaler.
Portalservice registreret i IdP miljø.
Planlæg tests og staging
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).
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</td><td>
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.
Krav og behov til test- og udviklingsmiljøer, ressourcer mv.
Gennemfør tests og staging
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</td><td>
Testmiljø hos portalen skal til stadighed være til rådighed for serviceudbyder.
Portalservice på plads i det relevante driftsmiljø.
Portalservicen godkendes til go-live på portalen.
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</td><td>
Indgå aftale med serviceudbyder
Der indgås trustaftale med serviceudbyderen, således at portalservicen kan indgå i SSO.
Vær opmærksom på eventuelle drift- og supportaftaler, der skal etableres med egne leverandører.
Input og forudsætninger</td><td>
Eventuelle gældende drift- og supportaftaler.
Konfigurér service i IdP miljø
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</td><td>
IdP miljø konfigureret.
Etablér support til serviceudbyder
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</td><td>
Eventuelle gældende drift- og supportaftaler.
Kontaktpersoner og supportressourcer er udpeget og aftale med serviceudbyder om at igangsætte et integrationsforløb.
RÃ¥dgiv om valg af integrationsform mv.
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</td><td>
Viden om portalmiljøets kapacitet og tekniske egenskaber, herunder planlagt ændringer mv.
Eventuelle gældende drift- og serviceaftaler.
Initiel rådgivning til serviceudbyder.
Indgå aftale med serviceudbyder
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</td><td>
Viden om portalmiljøets kapacitet og tekniske egenskaber, herunder planlagte ændringer mv.
Planer for integrationsforløb.
Eventuelle gældende drift- og supportaftaler.
Aftaler vedr. planlægning af samarbejdet under integrationsforløbet.
RÃ¥dgiv om integration
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.
• 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.

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</td><td>
Viden om portalmiljøets (særligt "sandkassemiljøets") kapacitet og tekniske egenskaber, herunder planlagte ændringer mv.
Integrationsrådgivning.
Validér opmærkning af service
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</td><td>
Serviceopmærkning.
Viden om portalens struktur for opmærkning.
Valideret serviceopmærkning.
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</td><td>
Viden om portalmiljøets kapacitet og tekniske egenskaber, herunder planlagte ændringer mv.
Eventuelle gældende drift- og supportaftaler.
Portalmiljø er tilpasset og konfigureret.
BORGER Teknisk opmærkning er foretaget.
Planlæg tests
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</td><td>
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.
Planlæg staging
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</td><td>
Planer for integrationsforløb og test.
Gennemfør tests
De planlagte test-aktiviteter gennemføres.
Der kan forekomme tilbageløb til udviklingsaktiviteter hos serviceudbyder og Gennemfør staging.
Input og forudsætninger</td><td>
Gennemfør staging
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</td><td>
Portalservice på plads i det relevante driftsmiljø.
Portalservicen godkendes til go-live på portalen.
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</td><td>
Portalservice godkendt til go-live på portalen.
Produktion-miljøet konfigureres således at portalservicen gøres tilgængelig for brugere af portalen.
Input og forudsætninger</td><td>
Portalservice godkendt til go-live på portalen.
Portalservice på plads i produktion-miljø.
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.
Initiel rådgivning
Valg af integrationsform og deraf følgende retningslinier.
Tests, der skal gennemføres.
Komponenter i portalmiljøet, som serviceudbyder skal anvende.
VIRK Størstedelen af den nødvendige information er tilgængelig på [MYNDIGHEDSNET].
Integrationsrådgivning
Teknisk rådgivning fra portalejer vedrørende integration af portalservice.
Serviceopmærkning
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.
Aftalte planer for de tests, der skal gennemføres i integrationsforløbet.
Dokumentation for resultaterne af de gennemførte tests.
En formel aftale mellem serviceudbyder og IdP udbyder om deltagelse i SSO føderation, således at portalservicen kan indgå i SSO.
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.

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.
Etablér kontakt til portalejer
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.
</td></tr><tr><td>Input og forudsætninger</td><td>
Hvis flere myndigheder er fælles om udstilling af en portalservice, er deres indbyrdes ansvarsfordeling afklaret.
Kontaktinformation og aftale om at igangsætte et integrationsforløb.
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</td><td>
Integrationsrådgivning
Portal sandkassemiljø
IdP sandkassemiljø
Serviceudbyders/leverandørs egen udviklingsmodel
Aktivitet: Opmærk ny version.
Opmærk ny version
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</td><td>
Viden om eventuelle ændringer i portalservicens funktionalitet og tekniske egenskaber.
Eventuelle gældende drift- og supportaftaler.
Ny version opmærket i portalens registreringsværktøj.
Planlæg tests og staging
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).
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</td><td>
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.
Krav og behov til test- og udviklingsmiljøer, ressourcer mv.
Gennemfør tests og staging
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
Input og forudsætninger</td><td>
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.
Ny version af portalservice på plads i det relevante driftsmiljø.
Den nye version af portalservicen godkendes til go-live på portalen.
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</td><td>
Etablér support til serviceudbyder
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</td><td>
Eventuelle gældende drift- og supportaftaler.
Kontaktpersoner og supportressourcer er udpeget og aftale med serviceudbyder om at igangsætte et integrationsforløb.
RÃ¥dgiv om integration
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.

• 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.

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</td><td>
Viden om portalmiljøets (særligt ”sandkassemiljøets) kapacitet og tekniske egenskaber, herunder planlagte ændringer mv.
Integrationsrådgivning.
Validér opmærkning af ny version
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</td><td>
Serviceopmærkning.
Viden om portalens struktur for opmærkning.
Valideret serviceopmærkning.
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</td><td>
Viden om portalmiljøets kapacitet og tekniske egenskaber, herunder planlagte ændringer mv.
Eventuelle gældende drift- og supportaftaler.
Portalmiljø er tilpasset og konfigureret.
BORGER Teknisk opmærkning er eventuelt ændret.
Planlæg tests
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</td><td>
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.
Planlæg staging
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</td><td>
Planer for integrationsforløb og test.
Gennemfør tests
De planlagte test-aktiviteter gennemføres.
Der kan forekomme tilbageløb til udviklingsaktiviteter hos serviceudbyder og Gennemfør staging.
Input og forudsætninger</td><td>
Gennemfør staging
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</td><td>
Ny version på plads i det relevante driftsmiljø.
Den nye version af portalservicen godkendes til go-live på portalen.
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</td><td>
Ny version af portalservice godkendt til go-live på portalen.
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</td><td>
Ny version af portalservice godkendt til go-live på portalen.
Ny version på plads i produktion-miljø.
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.
Integrationsrådgivning
Teknisk rådgivning fra portalejer vedrørende integration af ny version af portalservice.
Serviceopmærkning
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.
Aftalte planer for de tests, der skal gennemføres i integrationsforløbet.
Dokumentation for resultaterne af de gennemførte tests.
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.
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.
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</td><td>
Hvis flere myndigheder er fælles om en portalservice, er deres indbyrdes ansvarsfordeling afklaret.
Advisér berørte parter
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</td><td>
Viden om hvilke parter, der bliver berørt af, at portalservicen fjernes.
Berørte parter er adviseret.
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</td><td>
Viden om gennemførte aktiviteter.
Fjern opmærkning
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</td><td>
Tag service ud af IdP miljø
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</td><td>
Information fra serviceudbyder om at tage portalservice ud af IdP miljøet.
Portalservice fjernet fra IdP miljø.
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</td><td>
Viden om portalmiljøet, herunder planlagte ændringer mv.
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</td><td>
Portalmiljø mv. er forberedt til at fjerne portalservice.
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</td><td>
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</td><td>
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.

Deletions:
Proces for integration af en portalservice på en af de to portaler
Proces for integration af ny version af en portalservice på en af de to portaler
4 Anbefalinger til mønstre for udvikling af portalservices
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.
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 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.
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.
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.
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.
Rollen Driftsansvarlig hos Portalejer administrerer infrastrukturen hos Portalejer, og repræsenterer kompetencen til at sætte portalservices i drift i QA- og produktionsmiljøer.
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.
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.
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.
Etablér kontakt til portalejer
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.</td></tr><tr><td>
Input og forudsætninger</td><td>
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.</td></tr><tr><td>
Eventuelle gældende drift- og supportaftaler.
Kontaktinformation og aftale om at igangsætte et integrationsforløb.</td></tr><tr><td>
Vælg integrationsform, tests mv.
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:

• Serviceudbyders øvrige infrastruktur, fx udviklings- og driftsmiljø.
• Initiel rådgivning fra portalejer.

Input og forudsætninger</td><td>
Viden om portalservicens funktionalitet og tekniske egenskaber samt og serviceudbyders infrastruktur, fx udviklings- og driftsmiljø.
Initiel rådgivning fra portalejer.
Ambitionsniveau fastlagt for integrationsforløbet, særligt tests.
Indgå aftale med IdP udbyder
Der indgås trustaftale med IdP udbyderen, således at portalservicen kan indgå i SSO.
Input og forudsætninger</td><td>
Eventuelle gældende drift- og supportaftaler.
Indgå aftale med portalejer
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</td><td>
Planer for integrationsforløb.
Eventuelle gældende drift- og serviceaftaler.
Aftaler vedr. samarbejdet under integrationsforløbet.
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</td><td>
Integrationsrådgivning
Portal sandkassemiljø
IdP sandkassemiljø
Serviceudbyders/leverandørs egen udviklingsmodel
Aktivitet: Opmærk service.
Aktivitet: Registrér service hos IdP.
Opmærk service
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</td><td>
Viden om portalservicens funktionalitet og tekniske egenskaber. Eventuelle gældende drift- og supportaftaler.
Service opmærket i portalens registreringsværktøj.
Registrér service hos IdP
Input og forudsætninger</td><td>
Viden om portalservicens funktionalitet og sikkerhedsmæssige egenskaber. Eventuelle gældende drift- og supportaftaler.
Portalservice registreret i IdP miljø.
Planlæg tests og staging
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).
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</td><td>
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.
Krav og behov til test- og udviklingsmiljøer, ressourcer mv.
Gennemfør tests og staging
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</td><td>
Testmiljø hos portalen skal til stadighed være til rådighed for serviceudbyder.
Portalservice på plads i det relevante driftsmiljø.
Portalservicen godkendes til go-live på portalen.
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</td><td>
Indgå aftale med serviceudbyder
Der indgås trustaftale med serviceudbyderen, således at portalservicen kan indgå i SSO.
Vær opmærksom på eventuelle drift- og supportaftaler, der skal etableres med egne leverandører.
Input og forudsætninger</td><td>
Eventuelle gældende drift- og supportaftaler.
Konfigurér service i IdP miljø
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</td><td>
IdP miljø konfigureret.
Etablér support til serviceudbyder
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</td><td>
Eventuelle gældende drift- og supportaftaler.
Kontaktpersoner og supportressourcer er udpeget og aftale med serviceudbyder om at igangsætte et integrationsforløb.
Rådgiv om valg af integrationsform mv.
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</td><td>
Viden om portalmiljøets kapacitet og tekniske egenskaber, herunder planlagt ændringer mv.
Eventuelle gældende drift- og serviceaftaler.
Initiel rådgivning til serviceudbyder.
Indgå aftale med serviceudbyder
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</td><td>
Viden om portalmiljøets kapacitet og tekniske egenskaber, herunder planlagte ændringer mv.
Planer for integrationsforløb.
Eventuelle gældende drift- og supportaftaler.
Aftaler vedr. planlægning af samarbejdet under integrationsforløbet.
Rådgiv om integration
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.
• 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.

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</td><td>
Viden om portalmiljøets (særligt "sandkassemiljøets") kapacitet og tekniske egenskaber, herunder planlagte ændringer mv.
Integrationsrådgivning.
Validér opmærkning af service
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</td><td>
Serviceopmærkning.
Viden om portalens struktur for opmærkning.
Valideret serviceopmærkning.
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</td><td>
Viden om portalmiljøets kapacitet og tekniske egenskaber, herunder planlagte ændringer mv.
Eventuelle gældende drift- og supportaftaler.
Portalmiljø er tilpasset og konfigureret.
BORGER Teknisk opmærkning er foretaget.
Planlæg tests
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</td><td>
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.
Planlæg staging
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</td><td>
Planer for integrationsforløb og test.
Gennemfør tests
De planlagte test-aktiviteter gennemføres.
Der kan forekomme tilbageløb til udviklingsaktiviteter hos serviceudbyder og Gennemfør staging.
Input og forudsætninger</td><td>
Gennemfør staging
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</td><td>
Portalservice på plads i det relevante driftsmiljø.
Portalservicen godkendes til go-live på portalen.
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</td><td>
Portalservice godkendt til go-live på portalen.
Produktion-miljøet konfigureres således at portalservicen gøres tilgængelig for brugere af portalen.
Input og forudsætninger</td><td>
Portalservice godkendt til go-live på portalen.
Portalservice på plads i produktion-miljø.
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.
Initiel rådgivning
Valg af integrationsform og deraf følgende retningslinier.
Tests, der skal gennemføres.
Komponenter i portalmiljøet, som serviceudbyder skal anvende.
VIRK Størstedelen af den nødvendige information er tilgængelig på [MYNDIGHEDSNET].
Integrationsrådgivning
Teknisk rådgivning fra portalejer vedrørende integration af portalservice.
Serviceopmærkning
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.
Aftalte planer for de tests, der skal gennemføres i integrationsforløbet.
Dokumentation for resultaterne af de gennemførte tests.
En formel aftale mellem serviceudbyder og IdP udbyder om deltagelse i SSO føderation, således at portalservicen kan indgå i SSO.
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.

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.
Etablér kontakt til portalejer
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.
</td></tr><tr><td>Input og forudsætninger</td><td>
Hvis flere myndigheder er fælles om udstilling af en portalservice, er deres indbyrdes ansvarsfordeling afklaret.
Kontaktinformation og aftale om at igangsætte et integrationsforløb.
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</td><td>
Integrationsrådgivning
Portal sandkassemiljø
IdP sandkassemiljø
Serviceudbyders/leverandørs egen udviklingsmodel
Aktivitet: Opmærk ny version.
Opmærk ny version
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</td><td>
Viden om eventuelle ændringer i portalservicens funktionalitet og tekniske egenskaber.
Eventuelle gældende drift- og supportaftaler.
Ny version opmærket i portalens registreringsværktøj.
Planlæg tests og staging
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).
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</td><td>
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.
Krav og behov til test- og udviklingsmiljøer, ressourcer mv.
Gennemfør tests og staging
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
Input og forudsætninger</td><td>
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.
Ny version af portalservice på plads i det relevante driftsmiljø.
Den nye version af portalservicen godkendes til go-live på portalen.
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</td><td>
Etablér support til serviceudbyder
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</td><td>
Eventuelle gældende drift- og supportaftaler.
Kontaktpersoner og supportressourcer er udpeget og aftale med serviceudbyder om at igangsætte et integrationsforløb.
Rådgiv om integration
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.

• 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.

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</td><td>
Viden om portalmiljøets (særligt ”sandkassemiljøets) kapacitet og tekniske egenskaber, herunder planlagte ændringer mv.
Integrationsrådgivning.
Validér opmærkning af ny version
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</td><td>
Serviceopmærkning.
Viden om portalens struktur for opmærkning.
Valideret serviceopmærkning.
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</td><td>
Viden om portalmiljøets kapacitet og tekniske egenskaber, herunder planlagte ændringer mv.
Eventuelle gældende drift- og supportaftaler.
Portalmiljø er tilpasset og konfigureret.
BORGER Teknisk opmærkning er eventuelt ændret.
Planlæg tests
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</td><td>
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.
Planlæg staging
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</td><td>
Planer for integrationsforløb og test.
Gennemfør tests
De planlagte test-aktiviteter gennemføres.
Der kan forekomme tilbageløb til udviklingsaktiviteter hos serviceudbyder og Gennemfør staging.
Input og forudsætninger</td><td>
Gennemfør staging
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</td><td>
Ny version på plads i det relevante driftsmiljø.
Den nye version af portalservicen godkendes til go-live på portalen.
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</td><td>
Ny version af portalservice godkendt til go-live på portalen.
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</td><td>
Ny version af portalservice godkendt til go-live på portalen.
Ny version på plads i produktion-miljø.
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.
Integrationsrådgivning
Teknisk rådgivning fra portalejer vedrørende integration af ny version af portalservice.
Serviceopmærkning
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.
Aftalte planer for de tests, der skal gennemføres i integrationsforløbet.
Dokumentation for resultaterne af de gennemførte tests.
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.
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.
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</td><td>
Hvis flere myndigheder er fælles om en portalservice, er deres indbyrdes ansvarsfordeling afklaret.
Advisér berørte parter
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</td><td>
Viden om hvilke parter, der bliver berørt af, at portalservicen fjernes.
Berørte parter er adviseret.
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</td><td>
Viden om gennemførte aktiviteter.
Fjern opmærkning
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</td><td>
Tag service ud af IdP miljø
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</td><td>
Information fra serviceudbyder om at tage portalservice ud af IdP miljøet.
Portalservice fjernet fra IdP miljø.
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</td><td>
Viden om portalmiljøet, herunder planlagte ændringer mv.
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</td><td>
Portalmiljø mv. er forberedt til at fjerne portalservice.
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</td><td>
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</td><td>
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.

---

Edited on 2007-11-12 03:57:05 by WebMaster

Additions:
Proces for integration af en portalservice på en af de to portaler
Proces for integration af ny version af en portalservice på en af de to portaler
4 Anbefalinger til mønstre for udvikling af portalservices
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.
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 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.
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.
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.
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.
Rollen Driftsansvarlig hos Portalejer administrerer infrastrukturen hos Portalejer, og repræsenterer kompetencen til at sætte portalservices i drift i QA- og produktionsmiljøer.
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.
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.
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.
Etablér kontakt til portalejer
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.</td></tr><tr><td>
Input og forudsætninger</td><td>
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.</td></tr><tr><td>
Eventuelle gældende drift- og supportaftaler.
Kontaktinformation og aftale om at igangsætte et integrationsforløb.</td></tr><tr><td>
Vælg integrationsform, tests mv.
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:

• Serviceudbyders øvrige infrastruktur, fx udviklings- og driftsmiljø.
• Initiel rådgivning fra portalejer.

Input og forudsætninger</td><td>
Viden om portalservicens funktionalitet og tekniske egenskaber samt og serviceudbyders infrastruktur, fx udviklings- og driftsmiljø.
Initiel rådgivning fra portalejer.
Ambitionsniveau fastlagt for integrationsforløbet, særligt tests.
Indgå aftale med IdP udbyder
Der indgås trustaftale med IdP udbyderen, således at portalservicen kan indgå i SSO.
Input og forudsætninger</td><td>
Eventuelle gældende drift- og supportaftaler.
Indgå aftale med portalejer
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</td><td>
Planer for integrationsforløb.
Eventuelle gældende drift- og serviceaftaler.
Aftaler vedr. samarbejdet under integrationsforløbet.
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</td><td>
Integrationsrådgivning
Portal sandkassemiljø
IdP sandkassemiljø
Serviceudbyders/leverandørs egen udviklingsmodel
Aktivitet: Opmærk service.
Aktivitet: Registrér service hos IdP.
Opmærk service
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</td><td>
Viden om portalservicens funktionalitet og tekniske egenskaber. Eventuelle gældende drift- og supportaftaler.
Service opmærket i portalens registreringsværktøj.
Registrér service hos IdP
Input og forudsætninger</td><td>
Viden om portalservicens funktionalitet og sikkerhedsmæssige egenskaber. Eventuelle gældende drift- og supportaftaler.
Portalservice registreret i IdP miljø.
Planlæg tests og staging
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).
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</td><td>
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.
Krav og behov til test- og udviklingsmiljøer, ressourcer mv.
Gennemfør tests og staging
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</td><td>
Testmiljø hos portalen skal til stadighed være til rådighed for serviceudbyder.
Portalservice på plads i det relevante driftsmiljø.
Portalservicen godkendes til go-live på portalen.
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</td><td>
Indgå aftale med serviceudbyder
Der indgås trustaftale med serviceudbyderen, således at portalservicen kan indgå i SSO.
Vær opmærksom på eventuelle drift- og supportaftaler, der skal etableres med egne leverandører.
Input og forudsætninger</td><td>
Eventuelle gældende drift- og supportaftaler.
Konfigurér service i IdP miljø
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</td><td>
IdP miljø konfigureret.
Etablér support til serviceudbyder
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</td><td>
Eventuelle gældende drift- og supportaftaler.
Kontaktpersoner og supportressourcer er udpeget og aftale med serviceudbyder om at igangsætte et integrationsforløb.
Rådgiv om valg af integrationsform mv.
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</td><td>
Viden om portalmiljøets kapacitet og tekniske egenskaber, herunder planlagt ændringer mv.
Eventuelle gældende drift- og serviceaftaler.
Initiel rådgivning til serviceudbyder.
Indgå aftale med serviceudbyder
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</td><td>
Viden om portalmiljøets kapacitet og tekniske egenskaber, herunder planlagte ændringer mv.
Planer for integrationsforløb.
Eventuelle gældende drift- og supportaftaler.
Aftaler vedr. planlægning af samarbejdet under integrationsforløbet.
Rådgiv om integration
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.
• 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.

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</td><td>
Viden om portalmiljøets (særligt "sandkassemiljøets") kapacitet og tekniske egenskaber, herunder planlagte ændringer mv.
Integrationsrådgivning.
Validér opmærkning af service
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</td><td>
Serviceopmærkning.
Viden om portalens struktur for opmærkning.
Valideret serviceopmærkning.
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</td><td>
Viden om portalmiljøets kapacitet og tekniske egenskaber, herunder planlagte ændringer mv.
Eventuelle gældende drift- og supportaftaler.
Portalmiljø er tilpasset og konfigureret.
BORGER Teknisk opmærkning er foretaget.
Planlæg tests
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</td><td>
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.
Planlæg staging
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</td><td>
Planer for integrationsforløb og test.
Gennemfør tests
De planlagte test-aktiviteter gennemføres.
Der kan forekomme tilbageløb til udviklingsaktiviteter hos serviceudbyder og Gennemfør staging.
Input og forudsætninger</td><td>
Gennemfør staging
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</td><td>
Portalservice på plads i det relevante driftsmiljø.
Portalservicen godkendes til go-live på portalen.
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</td><td>
Portalservice godkendt til go-live på portalen.
Produktion-miljøet konfigureres således at portalservicen gøres tilgængelig for brugere af portalen.
Input og forudsætninger</td><td>
Portalservice godkendt til go-live på portalen.
Portalservice på plads i produktion-miljø.
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.
Initiel rådgivning
Valg af integrationsform og deraf følgende retningslinier.
Tests, der skal gennemføres.
Komponenter i portalmiljøet, som serviceudbyder skal anvende.
VIRK Størstedelen af den nødvendige information er tilgængelig på [MYNDIGHEDSNET].
Integrationsrådgivning
Teknisk rådgivning fra portalejer vedrørende integration af portalservice.
Serviceopmærkning
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.
Aftalte planer for de tests, der skal gennemføres i integrationsforløbet.
Dokumentation for resultaterne af de gennemførte tests.
En formel aftale mellem serviceudbyder og IdP udbyder om deltagelse i SSO føderation, således at portalservicen kan indgå i SSO.
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.

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.
Etablér kontakt til portalejer
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.
</td></tr><tr><td>Input og forudsætninger</td><td>
Hvis flere myndigheder er fælles om udstilling af en portalservice, er deres indbyrdes ansvarsfordeling afklaret.
Kontaktinformation og aftale om at igangsætte et integrationsforløb.
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</td><td>
Integrationsrådgivning
Portal sandkassemiljø
IdP sandkassemiljø
Serviceudbyders/leverandørs egen udviklingsmodel
Aktivitet: Opmærk ny version.
Opmærk ny version
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</td><td>
Viden om eventuelle ændringer i portalservicens funktionalitet og tekniske egenskaber.
Eventuelle gældende drift- og supportaftaler.
Ny version opmærket i portalens registreringsværktøj.
Planlæg tests og staging
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).
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</td><td>
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.
Krav og behov til test- og udviklingsmiljøer, ressourcer mv.
Gennemfør tests og staging
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
Input og forudsætninger</td><td>
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.
Ny version af portalservice på plads i det relevante driftsmiljø.
Den nye version af portalservicen godkendes til go-live på portalen.
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</td><td>
Etablér support til serviceudbyder
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</td><td>
Eventuelle gældende drift- og supportaftaler.
Kontaktpersoner og supportressourcer er udpeget og aftale med serviceudbyder om at igangsætte et integrationsforløb.
Rådgiv om integration
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.

• 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.

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</td><td>
Viden om portalmiljøets (særligt ”sandkassemiljøets) kapacitet og tekniske egenskaber, herunder planlagte ændringer mv.
Integrationsrådgivning.
Validér opmærkning af ny version
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</td><td>
Serviceopmærkning.
Viden om portalens struktur for opmærkning.
Valideret serviceopmærkning.
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</td><td>
Viden om portalmiljøets kapacitet og tekniske egenskaber, herunder planlagte ændringer mv.
Eventuelle gældende drift- og supportaftaler.
Portalmiljø er tilpasset og konfigureret.
BORGER Teknisk opmærkning er eventuelt ændret.
Planlæg tests
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</td><td>
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.
Planlæg staging
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</td><td>
Planer for integrationsforløb og test.
Gennemfør tests
De planlagte test-aktiviteter gennemføres.
Der kan forekomme tilbageløb til udviklingsaktiviteter hos serviceudbyder og Gennemfør staging.
Input og forudsætninger</td><td>
Gennemfør staging
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</td><td>
Ny version på plads i det relevante driftsmiljø.
Den nye version af portalservicen godkendes til go-live på portalen.
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</td><td>
Ny version af portalservice godkendt til go-live på portalen.
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</td><td>
Ny version af portalservice godkendt til go-live på portalen.
Ny version på plads i produktion-miljø.
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.
Integrationsrådgivning
Teknisk rådgivning fra portalejer vedrørende integration af ny version af portalservice.
Serviceopmærkning
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.
Aftalte planer for de tests, der skal gennemføres i integrationsforløbet.
Dokumentation for resultaterne af de gennemførte tests.
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.
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.
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</td><td>
Hvis flere myndigheder er fælles om en portalservice, er deres indbyrdes ansvarsfordeling afklaret.
Advisér berørte parter
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</td><td>
Viden om hvilke parter, der bliver berørt af, at portalservicen fjernes.
Berørte parter er adviseret.
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</td><td>
Viden om gennemførte aktiviteter.
Fjern opmærkning
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</td><td>
Tag service ud af IdP miljø
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</td><td>
Information fra serviceudbyder om at tage portalservice ud af IdP miljøet.
Portalservice fjernet fra IdP miljø.
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</td><td>
Viden om portalmiljøet, herunder planlagte ændringer mv.
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</td><td>
Portalmiljø mv. er forberedt til at fjerne portalservice.
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</td><td>
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</td><td>
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.

Deletions:
taolodarco
Proces for integration af en portalservice på en af de to portaler
Proces for integration af ny version af en portalservice på en af de to portaler
4 Anbefalinger til mønstre for udvikling af portalservices
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.
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 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.
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.
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.
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.
Rollen Driftsansvarlig hos Portalejer administrerer infrastrukturen hos Portalejer, og repræsenterer kompetencen til at sætte portalservices i drift i QA- og produktionsmiljøer.
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.
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.
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.
Etablér kontakt til portalejer
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.</td></tr><tr><td>
Input og forudsætninger</td><td>
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.</td></tr><tr><td>
Eventuelle gældende drift- og supportaftaler.
Kontaktinformation og aftale om at igangsætte et integrationsforløb.</td></tr><tr><td>
Vælg integrationsform, tests mv.
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:

• Serviceudbyders øvrige infrastruktur, fx udviklings- og driftsmiljø.
• Initiel rÃ¥dgivning fra portalejer.

Input og forudsætninger</td><td>
Viden om portalservicens funktionalitet og tekniske egenskaber samt og serviceudbyders infrastruktur, fx udviklings- og driftsmiljø.
Initiel rådgivning fra portalejer.
Ambitionsniveau fastlagt for integrationsforløbet, særligt tests.
Indgå aftale med IdP udbyder
Der indgås trustaftale med IdP udbyderen, således at portalservicen kan indgå i SSO.
Input og forudsætninger</td><td>
Eventuelle gældende drift- og supportaftaler.
Indgå aftale med portalejer
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</td><td>
Planer for integrationsforløb.
Eventuelle gældende drift- og serviceaftaler.
Aftaler vedr. samarbejdet under integrationsforløbet.
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</td><td>
Integrationsrådgivning
Portal sandkassemiljø
IdP sandkassemiljø
Serviceudbyders/leverandørs egen udviklingsmodel
Aktivitet: Opmærk service.
Aktivitet: Registrér service hos IdP.
Opmærk service
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</td><td>
Viden om portalservicens funktionalitet og tekniske egenskaber. Eventuelle gældende drift- og supportaftaler.
Service opmærket i portalens registreringsværktøj.
Registrér service hos IdP
Input og forudsætninger</td><td>
Viden om portalservicens funktionalitet og sikkerhedsmæssige egenskaber. Eventuelle gældende drift- og supportaftaler.
Portalservice registreret i IdP miljø.
Planlæg tests og staging
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).
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</td><td>
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.
Krav og behov til test- og udviklingsmiljøer, ressourcer mv.
Gennemfør tests og staging
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</td><td>
Testmiljø hos portalen skal til stadighed være til rådighed for serviceudbyder.
Portalservice på plads i det relevante driftsmiljø.
Portalservicen godkendes til go-live på portalen.
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</td><td>
Indgå aftale med serviceudbyder
Der indgås trustaftale med serviceudbyderen, således at portalservicen kan indgå i SSO.
Vær opmærksom på eventuelle drift- og supportaftaler, der skal etableres med egne leverandører.
Input og forudsætninger</td><td>
Eventuelle gældende drift- og supportaftaler.
Konfigurér service i IdP miljø
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</td><td>
IdP miljø konfigureret.
Etablér support til serviceudbyder
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</td><td>
Eventuelle gældende drift- og supportaftaler.
Kontaktpersoner og supportressourcer er udpeget og aftale med serviceudbyder om at igangsætte et integrationsforløb.
RÃ¥dgiv om valg af integrationsform mv.
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</td><td>
Viden om portalmiljøets kapacitet og tekniske egenskaber, herunder planlagt ændringer mv.
Eventuelle gældende drift- og serviceaftaler.
Initiel rådgivning til serviceudbyder.
Indgå aftale med serviceudbyder
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</td><td>
Viden om portalmiljøets kapacitet og tekniske egenskaber, herunder planlagte ændringer mv.
Planer for integrationsforløb.
Eventuelle gældende drift- og supportaftaler.
Aftaler vedr. planlægning af samarbejdet under integrationsforløbet.
RÃ¥dgiv om integration
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.
• 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.

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</td><td>
Viden om portalmiljøets (særligt "sandkassemiljøets") kapacitet og tekniske egenskaber, herunder planlagte ændringer mv.
Integrationsrådgivning.
Validér opmærkning af service
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</td><td>
Serviceopmærkning.
Viden om portalens struktur for opmærkning.
Valideret serviceopmærkning.
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</td><td>
Viden om portalmiljøets kapacitet og tekniske egenskaber, herunder planlagte ændringer mv.
Eventuelle gældende drift- og supportaftaler.
Portalmiljø er tilpasset og konfigureret.
BORGER Teknisk opmærkning er foretaget.
Planlæg tests
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</td><td>
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.
Planlæg staging
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</td><td>
Planer for integrationsforløb og test.
Gennemfør tests
De planlagte test-aktiviteter gennemføres.
Der kan forekomme tilbageløb til udviklingsaktiviteter hos serviceudbyder og Gennemfør staging.
Input og forudsætninger</td><td>
Gennemfør staging
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</td><td>
Portalservice på plads i det relevante driftsmiljø.
Portalservicen godkendes til go-live på portalen.
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</td><td>
Portalservice godkendt til go-live på portalen.
Produktion-miljøet konfigureres således at portalservicen gøres tilgængelig for brugere af portalen.
Input og forudsætninger</td><td>
Portalservice godkendt til go-live på portalen.
Portalservice på plads i produktion-miljø.
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.
Initiel rådgivning
Valg af integrationsform og deraf følgende retningslinier.
Tests, der skal gennemføres.
Komponenter i portalmiljøet, som serviceudbyder skal anvende.
VIRK Størstedelen af den nødvendige information er tilgængelig på [MYNDIGHEDSNET].
Integrationsrådgivning
Teknisk rådgivning fra portalejer vedrørende integration af portalservice.
Serviceopmærkning
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.
Aftalte planer for de tests, der skal gennemføres i integrationsforløbet.
Dokumentation for resultaterne af de gennemførte tests.
En formel aftale mellem serviceudbyder og IdP udbyder om deltagelse i SSO føderation, således at portalservicen kan indgå i SSO.
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.

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.
Etablér kontakt til portalejer
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.
</td></tr><tr><td>Input og forudsætninger</td><td>
Hvis flere myndigheder er fælles om udstilling af en portalservice, er deres indbyrdes ansvarsfordeling afklaret.
Kontaktinformation og aftale om at igangsætte et integrationsforløb.
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</td><td>
Integrationsrådgivning
Portal sandkassemiljø
IdP sandkassemiljø
Serviceudbyders/leverandørs egen udviklingsmodel
Aktivitet: Opmærk ny version.
Opmærk ny version
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</td><td>
Viden om eventuelle ændringer i portalservicens funktionalitet og tekniske egenskaber.
Eventuelle gældende drift- og supportaftaler.
Ny version opmærket i portalens registreringsværktøj.
Planlæg tests og staging
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).
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</td><td>
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.
Krav og behov til test- og udviklingsmiljøer, ressourcer mv.
Gennemfør tests og staging
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
Input og forudsætninger</td><td>
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.
Ny version af portalservice på plads i det relevante driftsmiljø.
Den nye version af portalservicen godkendes til go-live på portalen.
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</td><td>
Etablér support til serviceudbyder
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</td><td>
Eventuelle gældende drift- og supportaftaler.
Kontaktpersoner og supportressourcer er udpeget og aftale med serviceudbyder om at igangsætte et integrationsforløb.
RÃ¥dgiv om integration
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.

• 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.

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</td><td>
Viden om portalmiljøets (særligt ”sandkassemiljøets) kapacitet og tekniske egenskaber, herunder planlagte ændringer mv.
Integrationsrådgivning.
Validér opmærkning af ny version
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</td><td>
Serviceopmærkning.
Viden om portalens struktur for opmærkning.
Valideret serviceopmærkning.
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</td><td>
Viden om portalmiljøets kapacitet og tekniske egenskaber, herunder planlagte ændringer mv.
Eventuelle gældende drift- og supportaftaler.
Portalmiljø er tilpasset og konfigureret.
BORGER Teknisk opmærkning er eventuelt ændret.
Planlæg tests
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</td><td>
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.
Planlæg staging
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</td><td>
Planer for integrationsforløb og test.
Gennemfør tests
De planlagte test-aktiviteter gennemføres.
Der kan forekomme tilbageløb til udviklingsaktiviteter hos serviceudbyder og Gennemfør staging.
Input og forudsætninger</td><td>
Gennemfør staging
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</td><td>
Ny version på plads i det relevante driftsmiljø.
Den nye version af portalservicen godkendes til go-live på portalen.
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</td><td>
Ny version af portalservice godkendt til go-live på portalen.
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</td><td>
Ny version af portalservice godkendt til go-live på portalen.
Ny version på plads i produktion-miljø.
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.
Integrationsrådgivning
Teknisk rådgivning fra portalejer vedrørende integration af ny version af portalservice.
Serviceopmærkning
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.
Aftalte planer for de tests, der skal gennemføres i integrationsforløbet.
Dokumentation for resultaterne af de gennemførte tests.
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.
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.
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</td><td>
Hvis flere myndigheder er fælles om en portalservice, er deres indbyrdes ansvarsfordeling afklaret.
Advisér berørte parter
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</td><td>
Viden om hvilke parter, der bliver berørt af, at portalservicen fjernes.
Berørte parter er adviseret.
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</td><td>
Viden om gennemførte aktiviteter.
Fjern opmærkning
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</td><td>
Tag service ud af IdP miljø
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</td><td>
Information fra serviceudbyder om at tage portalservice ud af IdP miljøet.
Portalservice fjernet fra IdP miljø.
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</td><td>
Viden om portalmiljøet, herunder planlagte ændringer mv.
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</td><td>
Portalmiljø mv. er forberedt til at fjerne portalservice.
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</td><td>
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</td><td>
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.

---

Edited on 2007-11-11 23:32:11 by CcrolBoboz

Additions:
taolodarco
Proces for integration af en portalservice på en af de to portaler
Proces for integration af ny version af en portalservice på en af de to portaler
4 Anbefalinger til mønstre for udvikling af portalservices
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.
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 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.
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.
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.
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.
Rollen Driftsansvarlig hos Portalejer administrerer infrastrukturen hos Portalejer, og repræsenterer kompetencen til at sætte portalservices i drift i QA- og produktionsmiljøer.
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.
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.
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.
Etablér kontakt til portalejer
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.</td></tr><tr><td>
Input og forudsætninger</td><td>
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.</td></tr><tr><td>
Eventuelle gældende drift- og supportaftaler.
Kontaktinformation og aftale om at igangsætte et integrationsforløb.</td></tr><tr><td>
Vælg integrationsform, tests mv.
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:

• Serviceudbyders øvrige infrastruktur, fx udviklings- og driftsmiljø.
• Initiel rÃ¥dgivning fra portalejer.

Input og forudsætninger</td><td>
Viden om portalservicens funktionalitet og tekniske egenskaber samt og serviceudbyders infrastruktur, fx udviklings- og driftsmiljø.
Initiel rådgivning fra portalejer.
Ambitionsniveau fastlagt for integrationsforløbet, særligt tests.
Indgå aftale med IdP udbyder
Der indgås trustaftale med IdP udbyderen, således at portalservicen kan indgå i SSO.
Input og forudsætninger</td><td>
Eventuelle gældende drift- og supportaftaler.
Indgå aftale med portalejer
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</td><td>
Planer for integrationsforløb.
Eventuelle gældende drift- og serviceaftaler.
Aftaler vedr. samarbejdet under integrationsforløbet.
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</td><td>
Integrationsrådgivning
Portal sandkassemiljø
IdP sandkassemiljø
Serviceudbyders/leverandørs egen udviklingsmodel
Aktivitet: Opmærk service.
Aktivitet: Registrér service hos IdP.
Opmærk service
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</td><td>
Viden om portalservicens funktionalitet og tekniske egenskaber. Eventuelle gældende drift- og supportaftaler.
Service opmærket i portalens registreringsværktøj.
Registrér service hos IdP
Input og forudsætninger</td><td>
Viden om portalservicens funktionalitet og sikkerhedsmæssige egenskaber. Eventuelle gældende drift- og supportaftaler.
Portalservice registreret i IdP miljø.
Planlæg tests og staging
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).
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</td><td>
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.
Krav og behov til test- og udviklingsmiljøer, ressourcer mv.
Gennemfør tests og staging
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</td><td>
Testmiljø hos portalen skal til stadighed være til rådighed for serviceudbyder.
Portalservice på plads i det relevante driftsmiljø.
Portalservicen godkendes til go-live på portalen.
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</td><td>
Indgå aftale med serviceudbyder
Der indgås trustaftale med serviceudbyderen, således at portalservicen kan indgå i SSO.
Vær opmærksom på eventuelle drift- og supportaftaler, der skal etableres med egne leverandører.
Input og forudsætninger</td><td>
Eventuelle gældende drift- og supportaftaler.
Konfigurér service i IdP miljø
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</td><td>
IdP miljø konfigureret.
Etablér support til serviceudbyder
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</td><td>
Eventuelle gældende drift- og supportaftaler.
Kontaktpersoner og supportressourcer er udpeget og aftale med serviceudbyder om at igangsætte et integrationsforløb.
RÃ¥dgiv om valg af integrationsform mv.
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</td><td>
Viden om portalmiljøets kapacitet og tekniske egenskaber, herunder planlagt ændringer mv.
Eventuelle gældende drift- og serviceaftaler.
Initiel rådgivning til serviceudbyder.
Indgå aftale med serviceudbyder
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</td><td>
Viden om portalmiljøets kapacitet og tekniske egenskaber, herunder planlagte ændringer mv.
Planer for integrationsforløb.
Eventuelle gældende drift- og supportaftaler.
Aftaler vedr. planlægning af samarbejdet under integrationsforløbet.
RÃ¥dgiv om integration
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.
• 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.

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</td><td>
Viden om portalmiljøets (særligt "sandkassemiljøets") kapacitet og tekniske egenskaber, herunder planlagte ændringer mv.
Integrationsrådgivning.
Validér opmærkning af service
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</td><td>
Serviceopmærkning.
Viden om portalens struktur for opmærkning.
Valideret serviceopmærkning.
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</td><td>
Viden om portalmiljøets kapacitet og tekniske egenskaber, herunder planlagte ændringer mv.
Eventuelle gældende drift- og supportaftaler.
Portalmiljø er tilpasset og konfigureret.
BORGER Teknisk opmærkning er foretaget.
Planlæg tests
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</td><td>
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.
Planlæg staging
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</td><td>
Planer for integrationsforløb og test.
Gennemfør tests
De planlagte test-aktiviteter gennemføres.
Der kan forekomme tilbageløb til udviklingsaktiviteter hos serviceudbyder og Gennemfør staging.
Input og forudsætninger</td><td>
Gennemfør staging
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</td><td>
Portalservice på plads i det relevante driftsmiljø.
Portalservicen godkendes til go-live på portalen.
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</td><td>
Portalservice godkendt til go-live på portalen.
Produktion-miljøet konfigureres således at portalservicen gøres tilgængelig for brugere af portalen.
Input og forudsætninger</td><td>
Portalservice godkendt til go-live på portalen.
Portalservice på plads i produktion-miljø.
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.
Initiel rådgivning
Valg af integrationsform og deraf følgende retningslinier.
Tests, der skal gennemføres.
Komponenter i portalmiljøet, som serviceudbyder skal anvende.
VIRK Størstedelen af den nødvendige information er tilgængelig på [MYNDIGHEDSNET].
Integrationsrådgivning
Teknisk rådgivning fra portalejer vedrørende integration af portalservice.
Serviceopmærkning
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.
Aftalte planer for de tests, der skal gennemføres i integrationsforløbet.
Dokumentation for resultaterne af de gennemførte tests.
En formel aftale mellem serviceudbyder og IdP udbyder om deltagelse i SSO føderation, således at portalservicen kan indgå i SSO.
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.

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.
Etablér kontakt til portalejer
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.
</td></tr><tr><td>Input og forudsætninger</td><td>
Hvis flere myndigheder er fælles om udstilling af en portalservice, er deres indbyrdes ansvarsfordeling afklaret.
Kontaktinformation og aftale om at igangsætte et integrationsforløb.
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</td><td>
Integrationsrådgivning
Portal sandkassemiljø
IdP sandkassemiljø
Serviceudbyders/leverandørs egen udviklingsmodel
Aktivitet: Opmærk ny version.
Opmærk ny version
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</td><td>
Viden om eventuelle ændringer i portalservicens funktionalitet og tekniske egenskaber.
Eventuelle gældende drift- og supportaftaler.
Ny version opmærket i portalens registreringsværktøj.
Planlæg tests og staging
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).
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</td><td>
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.
Krav og behov til test- og udviklingsmiljøer, ressourcer mv.
Gennemfør tests og staging
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
Input og forudsætninger</td><td>
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.
Ny version af portalservice på plads i det relevante driftsmiljø.
Den nye version af portalservicen godkendes til go-live på portalen.
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</td><td>
Etablér support til serviceudbyder
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</td><td>
Eventuelle gældende drift- og supportaftaler.
Kontaktpersoner og supportressourcer er udpeget og aftale med serviceudbyder om at igangsætte et integrationsforløb.
RÃ¥dgiv om integration
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.

• 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.

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</td><td>
Viden om portalmiljøets (særligt ”sandkassemiljøets) kapacitet og tekniske egenskaber, herunder planlagte ændringer mv.
Integrationsrådgivning.
Validér opmærkning af ny version
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</td><td>
Serviceopmærkning.
Viden om portalens struktur for opmærkning.
Valideret serviceopmærkning.
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</td><td>
Viden om portalmiljøets kapacitet og tekniske egenskaber, herunder planlagte ændringer mv.
Eventuelle gældende drift- og supportaftaler.
Portalmiljø er tilpasset og konfigureret.
BORGER Teknisk opmærkning er eventuelt ændret.
Planlæg tests
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</td><td>
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.
Planlæg staging
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</td><td>
Planer for integrationsforløb og test.
Gennemfør tests
De planlagte test-aktiviteter gennemføres.
Der kan forekomme tilbageløb til udviklingsaktiviteter hos serviceudbyder og Gennemfør staging.
Input og forudsætninger</td><td>
Gennemfør staging
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</td><td>
Ny version på plads i det relevante driftsmiljø.
Den nye version af portalservicen godkendes til go-live på portalen.
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</td><td>
Ny version af portalservice godkendt til go-live på portalen.
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</td><td>
Ny version af portalservice godkendt til go-live på portalen.
Ny version på plads i produktion-miljø.
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.
Integrationsrådgivning
Teknisk rådgivning fra portalejer vedrørende integration af ny version af portalservice.
Serviceopmærkning
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.
Aftalte planer for de tests, der skal gennemføres i integrationsforløbet.
Dokumentation for resultaterne af de gennemførte tests.
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.
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.
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</td><td>
Hvis flere myndigheder er fælles om en portalservice, er deres indbyrdes ansvarsfordeling afklaret.
Advisér berørte parter
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</td><td>
Viden om hvilke parter, der bliver berørt af, at portalservicen fjernes.
Berørte parter er adviseret.
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</td><td>
Viden om gennemførte aktiviteter.
Fjern opmærkning
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</td><td>
Tag service ud af IdP miljø
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</td><td>
Information fra serviceudbyder om at tage portalservice ud af IdP miljøet.
Portalservice fjernet fra IdP miljø.
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</td><td>
Viden om portalmiljøet, herunder planlagte ændringer mv.
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</td><td>
Portalmiljø mv. er forberedt til at fjerne portalservice.
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</td><td>
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</td><td>
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.

Deletions:
Proces for integration af en portalservice på en af de to portaler
Proces for integration af ny version af en portalservice på en af de to portaler
4 Anbefalinger til mønstre for udvikling af portalservices
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.
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 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.
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.
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.
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.
Rollen Driftsansvarlig hos Portalejer administrerer infrastrukturen hos Portalejer, og repræsenterer kompetencen til at sætte portalservices i drift i QA- og produktionsmiljøer.
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.
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.
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.
Etablér kontakt til portalejer
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.</td></tr><tr><td>
Input og forudsætninger</td><td>
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.</td></tr><tr><td>
Eventuelle gældende drift- og supportaftaler.
Kontaktinformation og aftale om at igangsætte et integrationsforløb.</td></tr><tr><td>
Vælg integrationsform, tests mv.
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:

• Serviceudbyders øvrige infrastruktur, fx udviklings- og driftsmiljø.
• Initiel rådgivning fra portalejer.

Input og forudsætninger</td><td>
Viden om portalservicens funktionalitet og tekniske egenskaber samt og serviceudbyders infrastruktur, fx udviklings- og driftsmiljø.
Initiel rådgivning fra portalejer.
Ambitionsniveau fastlagt for integrationsforløbet, særligt tests.
Indgå aftale med IdP udbyder
Der indgås trustaftale med IdP udbyderen, således at portalservicen kan indgå i SSO.
Input og forudsætninger</td><td>
Eventuelle gældende drift- og supportaftaler.
Indgå aftale med portalejer
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</td><td>
Planer for integrationsforløb.
Eventuelle gældende drift- og serviceaftaler.
Aftaler vedr. samarbejdet under integrationsforløbet.
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</td><td>
Integrationsrådgivning
Portal sandkassemiljø
IdP sandkassemiljø
Serviceudbyders/leverandørs egen udviklingsmodel
Aktivitet: Opmærk service.
Aktivitet: Registrér service hos IdP.
Opmærk service
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</td><td>
Viden om portalservicens funktionalitet og tekniske egenskaber. Eventuelle gældende drift- og supportaftaler.
Service opmærket i portalens registreringsværktøj.
Registrér service hos IdP
Input og forudsætninger</td><td>
Viden om portalservicens funktionalitet og sikkerhedsmæssige egenskaber. Eventuelle gældende drift- og supportaftaler.
Portalservice registreret i IdP miljø.
Planlæg tests og staging
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).
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</td><td>
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.
Krav og behov til test- og udviklingsmiljøer, ressourcer mv.
Gennemfør tests og staging
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</td><td>
Testmiljø hos portalen skal til stadighed være til rådighed for serviceudbyder.
Portalservice på plads i det relevante driftsmiljø.
Portalservicen godkendes til go-live på portalen.
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</td><td>
Indgå aftale med serviceudbyder
Der indgås trustaftale med serviceudbyderen, således at portalservicen kan indgå i SSO.
Vær opmærksom på eventuelle drift- og supportaftaler, der skal etableres med egne leverandører.
Input og forudsætninger</td><td>
Eventuelle gældende drift- og supportaftaler.
Konfigurér service i IdP miljø
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</td><td>
IdP miljø konfigureret.
Etablér support til serviceudbyder
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</td><td>
Eventuelle gældende drift- og supportaftaler.
Kontaktpersoner og supportressourcer er udpeget og aftale med serviceudbyder om at igangsætte et integrationsforløb.
Rådgiv om valg af integrationsform mv.
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</td><td>
Viden om portalmiljøets kapacitet og tekniske egenskaber, herunder planlagt ændringer mv.
Eventuelle gældende drift- og serviceaftaler.
Initiel rådgivning til serviceudbyder.
Indgå aftale med serviceudbyder
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</td><td>
Viden om portalmiljøets kapacitet og tekniske egenskaber, herunder planlagte ændringer mv.
Planer for integrationsforløb.
Eventuelle gældende drift- og supportaftaler.
Aftaler vedr. planlægning af samarbejdet under integrationsforløbet.
Rådgiv om integration
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.
• 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.

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</td><td>
Viden om portalmiljøets (særligt "sandkassemiljøets") kapacitet og tekniske egenskaber, herunder planlagte ændringer mv.
Integrationsrådgivning.
Validér opmærkning af service
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</td><td>
Serviceopmærkning.
Viden om portalens struktur for opmærkning.
Valideret serviceopmærkning.
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</td><td>
Viden om portalmiljøets kapacitet og tekniske egenskaber, herunder planlagte ændringer mv.
Eventuelle gældende drift- og supportaftaler.
Portalmiljø er tilpasset og konfigureret.
BORGER Teknisk opmærkning er foretaget.
Planlæg tests
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</td><td>
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.
Planlæg staging
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</td><td>
Planer for integrationsforløb og test.
Gennemfør tests
De planlagte test-aktiviteter gennemføres.
Der kan forekomme tilbageløb til udviklingsaktiviteter hos serviceudbyder og Gennemfør staging.
Input og forudsætninger</td><td>
Gennemfør staging
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</td><td>
Portalservice på plads i det relevante driftsmiljø.
Portalservicen godkendes til go-live på portalen.
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</td><td>
Portalservice godkendt til go-live på portalen.
Produktion-miljøet konfigureres således at portalservicen gøres tilgængelig for brugere af portalen.
Input og forudsætninger</td><td>
Portalservice godkendt til go-live på portalen.
Portalservice på plads i produktion-miljø.
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.
Initiel rådgivning
Valg af integrationsform og deraf følgende retningslinier.
Tests, der skal gennemføres.
Komponenter i portalmiljøet, som serviceudbyder skal anvende.
VIRK Størstedelen af den nødvendige information er tilgængelig på [MYNDIGHEDSNET].
Integrationsrådgivning
Teknisk rådgivning fra portalejer vedrørende integration af portalservice.
Serviceopmærkning
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.
Aftalte planer for de tests, der skal gennemføres i integrationsforløbet.
Dokumentation for resultaterne af de gennemførte tests.
En formel aftale mellem serviceudbyder og IdP udbyder om deltagelse i SSO føderation, således at portalservicen kan indgå i SSO.
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.

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.
Etablér kontakt til portalejer
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.
</td></tr><tr><td>Input og forudsætninger</td><td>
Hvis flere myndigheder er fælles om udstilling af en portalservice, er deres indbyrdes ansvarsfordeling afklaret.
Kontaktinformation og aftale om at igangsætte et integrationsforløb.
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</td><td>
Integrationsrådgivning
Portal sandkassemiljø
IdP sandkassemiljø
Serviceudbyders/leverandørs egen udviklingsmodel
Aktivitet: Opmærk ny version.
Opmærk ny version
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</td><td>
Viden om eventuelle ændringer i portalservicens funktionalitet og tekniske egenskaber.
Eventuelle gældende drift- og supportaftaler.
Ny version opmærket i portalens registreringsværktøj.
Planlæg tests og staging
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).
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</td><td>
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.
Krav og behov til test- og udviklingsmiljøer, ressourcer mv.
Gennemfør tests og staging
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
Input og forudsætninger</td><td>
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.
Ny version af portalservice på plads i det relevante driftsmiljø.
Den nye version af portalservicen godkendes til go-live på portalen.
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</td><td>
Etablér support til serviceudbyder
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</td><td>
Eventuelle gældende drift- og supportaftaler.
Kontaktpersoner og supportressourcer er udpeget og aftale med serviceudbyder om at igangsætte et integrationsforløb.
Rådgiv om integration
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.

• 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.

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</td><td>
Viden om portalmiljøets (særligt ”sandkassemiljøets) kapacitet og tekniske egenskaber, herunder planlagte ændringer mv.
Integrationsrådgivning.
Validér opmærkning af ny version
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</td><td>
Serviceopmærkning.
Viden om portalens struktur for opmærkning.
Valideret serviceopmærkning.
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</td><td>
Viden om portalmiljøets kapacitet og tekniske egenskaber, herunder planlagte ændringer mv.
Eventuelle gældende drift- og supportaftaler.
Portalmiljø er tilpasset og konfigureret.
BORGER Teknisk opmærkning er eventuelt ændret.
Planlæg tests
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</td><td>
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.
Planlæg staging
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</td><td>
Planer for integrationsforløb og test.
Gennemfør tests
De planlagte test-aktiviteter gennemføres.
Der kan forekomme tilbageløb til udviklingsaktiviteter hos serviceudbyder og Gennemfør staging.
Input og forudsætninger</td><td>
Gennemfør staging
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</td><td>
Ny version på plads i det relevante driftsmiljø.
Den nye version af portalservicen godkendes til go-live på portalen.
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</td><td>
Ny version af portalservice godkendt til go-live på portalen.
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</td><td>
Ny version af portalservice godkendt til go-live på portalen.
Ny version på plads i produktion-miljø.
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.
Integrationsrådgivning
Teknisk rådgivning fra portalejer vedrørende integration af ny version af portalservice.
Serviceopmærkning
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.
Aftalte planer for de tests, der skal gennemføres i integrationsforløbet.
Dokumentation for resultaterne af de gennemførte tests.
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.
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.
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</td><td>
Hvis flere myndigheder er fælles om en portalservice, er deres indbyrdes ansvarsfordeling afklaret.
Advisér berørte parter
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</td><td>
Viden om hvilke parter, der bliver berørt af, at portalservicen fjernes.
Berørte parter er adviseret.
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</td><td>
Viden om gennemførte aktiviteter.
Fjern opmærkning
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</td><td>
Tag service ud af IdP miljø
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</td><td>
Information fra serviceudbyder om at tage portalservice ud af IdP miljøet.
Portalservice fjernet fra IdP miljø.
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</td><td>
Viden om portalmiljøet, herunder planlagte ændringer mv.
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</td><td>
Portalmiljø mv. er forberedt til at fjerne portalservice.
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</td><td>
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</td><td>
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.

---

Edited on 2007-10-17 06:08:43 by KristianHjortMadsen

Additions:
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.
I samarbejde med Portalejer fastlægges behovet for tværgående projektledelse og koordinering, kontaktpersoner og kommunikation mv.
Eventuelle gældende drift- og supportaftaler.
[ITILv3]: Transition Planning and Support, Change Mgt.
[ITILv3]: Service Level Mgt., Service Operation.
Eventuelle gældende drift- og supportaftaler.
[ITILv3]: Information Security Mgt.
Eventuelle gældende drift- og serviceaftaler.
[ITILv3]: Service Level Mgt.
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.
Viden om portalservicens funktionalitet og tekniske egenskaber. Eventuelle gældende drift- og supportaftaler.
[ITILv3]: Service Level Mgt.
Viden om portalservicens funktionalitet og sikkerhedsmæssige egenskaber. Eventuelle gældende drift- og supportaftaler.
[ITILv3]: Information Security Mgt.
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.
[ITILv3]: Transition Planning and Support, Service Testing and Validation, Change Mgt., Service Operation, Information Security Mgt., Release and Deployment Mgt.,
Testmiljø hos portalen skal til stadighed være til rådighed for serviceudbyder.
[ITIL v3]: Service Testing and Validation.
[ITILv3]: Change Mgt., Release and Deployment Mgt.
Vær opmærksom på eventuelle drift- og supportaftaler, der skal etableres med egne leverandører.
Eventuelle gældende drift- og supportaftaler.
[ITILv3]: Service Level Mgt., Supplier Mgt., Security Mgt.
[ITILv3]: Configuration Mgt.
Eventuelle gældende drift- og supportaftaler.
[ITILv3]: Service Level Mgt.
Eventuelle gældende drift- og serviceaftaler.
[ITILv3]: Capacity Mgt., Service Level Mgt.
Eventuelle gældende drift- og supportaftaler.
[ITILv3]: Transition Planning and Support, CapacityMgt., Service Level Mgt.
[ITILv3]: Service Catalogue Mgt., Service Validation and Testing.
Eventuelle gældende drift- og supportaftaler.
[ITILv3]: Change Mgt., Service Asset and Configuration Mgt.,
Eventuelle gældende drift- og supportaftaler.
Testmiljø hos portalen skal til stadighed være til rådighed for serviceudbyder.
[ITILv3]: Service Testing and Validation.
[ITILv3]: Change Mgt., Release and Deployment Mgt.
[ITILv3]: Service Testing and Validation.
[ITILv3]: Change Mgt., Release and Deployment Mgt.
[ITILv3]: Change Mgt., Release and Deployment Mgt.
[ITILv3]: Configuration Mgt.
I samarbejde med Portalejer fastlægges behovet for tværgående projektledelse og koordinering, kontaktpersoner og kommunikation mv.
[ITILv3]: Transition Planning and Support, Change Mgt.
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.
Eventuelle gældende drift- og supportaftaler.
[ITILv3]: Service Level Mgt.
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.
[ITILv3]: Transition Planning and Support, Service Testing and Validation, Change Mgt., Service Operation, Information Security Mgt., Release and Deployment Mgt.
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.
[ITILv3]: Service Testing and Validation.
[ITILv3]: Change Mgt., Release and Deployment Mgt.
Eventuelle gældende drift- og supportaftaler.
[ITILv3]: Service Level Mgt.
[ITILv3]: Service Catalogue Mgt., Service Validation and Testing.
Eventuelle gældende drift- og supportaftaler.
[ITILv3]: Change Mgt., Service Asset and Configuration Mgt.
Eventuelle gældende drift- og supportaftaler.
Testmiljø hos portalen skal til stadighed være til rådighed for serviceudbyder.
[ITILv3]: Service Testing and Validation.
[ITILv3]: Change Mgt., Release and Deployment Mgt.
[ITILv3]: Service Testing and Validation.
[ITILv3]: Change Mgt., Release and Deployment Mgt.
[ITILv3]: Change Mgt., Release and Deployment Mgt.
[ITILv3]: Configuration Mgt.
[ITILv3]: Transition Planning and Support, Change Mgt.
[ITILv3]: Change Mgt., Release and Deployment Mgt.
[ITILv3]: Configuration Mgt.
[ITILv3]: Transition Planning and Support.
[ITILv3]: Change Mgt., Release and Deployment Mgt.
[ITILv3]: Change Mgt., Release and Deployment Mgt.
[ITILv3]: Configuration Mgt.

Deletions:
I samarbejde med Portalejer fastlægges behovet for koordinering, kontaktpersoner og kommunikation mv.
Portalservicen registreres hos portalen og opmærkes ud fra funktionalitet, målgruppe mv. i forhold til portalens struktur for emneord, temaer mv.
Viden om portalservicens funktionalitet og sikkerhedsmæssige egenskaber.
I samarbejde med Portalejer fastlægges behovet for koordinering, kontaktpersoner og kommunikation mv.
Eventuelle ændringer af registrering og opmærkning hos portalen foretages i forhold til portalens struktur for emneord, temaer mv.

---

Edited on 2007-09-02 17:18:17 by KristianHjortMadsen

Additions:
4 Anbefalinger til mønstre for udvikling af portalservices
Bilag A Anbefalede integrationsformer
Bilag B Kommende integrationsformer

Deletions:
4 Overordnede retningslinier for integration af portalservices
5 Anbefalinger til mønstre for udvikling af portalservices
Bilag 1 Retningslinier vedr. integrationsformen Link m/ SSO
Bilag 2 Retningslinier vedrørende integrationsformen IFrame m/ SSO
Bilag 3 Retningslinier vedrørende integrationsformen WSRP

---

Edited on 2007-09-02 14:09:05 by KristianHjortMadsen

Additions:
</td></tr><tr><td>Input og forudsætninger</td><td>

Deletions:
</td><td>Input og forudsætninger</td><td>
</td><td>
</td><td>
</td><td>
</td><td>
</td><td>
</td><td>
</td><td>
</td><td>
</td><td>
</td><td>
</td><td>
</td><td>
</td><td>
</td><td>
</td><td>
</td><td>
</td><td>
</td><td>
</td><td>
</td><td>
</td><td>
</td><td>
</td><td>
</td><td>

---

Edited on 2007-09-02 14:04:02 by KristianHjortMadsen

Additions:
</td><td>Input og forudsætninger</td><td>
Udvikl ny version
Her gennemføres det udviklingsarbejde, som er nødvendigt for at levere en ny version klar til test.
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.
</td><td>
Ny version af portalservice udviklet.
Aktivitet: Opmærk ny version.
Opmærk ny version
Eventuelle ændringer af registrering og opmærkning hos portalen foretages i forhold til portalens struktur for emneord, temaer mv.
</td><td>
Viden om eventuelle ændringer i portalservicens funktionalitet og tekniske egenskaber.
Ny version opmærket i portalens registreringsværktøj.
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.
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.
</td><td>
Viden om den nye versions funktionalitet og tekniske egenskaber samt om serviceudbyders infrastruktur, fx udviklings- og testmiljøer, herunder anden planlagt anvendelse heraf.
Der kan forekomme tilbageløb herfra til tidligere aktiviteter, herunder Udvikl ny version, og Planlæg tests og staging.
En ny version, som er klar til test.
</td><td>
Viden om den nye versions funktionalitet og tekniske egenskaber samt om serviceudbyders infrastruktur, fx udviklings- og testmiljøer, herunder anden planlagt anvendelse heraf.
Ny version af portalservice på plads i det relevante driftsmiljø.
Godkend Go live for ny version
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.
</td><td>
Ny version af portalservice godkendt til go-live.
Vær opmærksom på erfaringer fra det oprindelige integrationsforløb.
Vær opmærksom på eventuelle behov for fallback procedurer ved go-live.
</td><td>
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.

Vær opmærksom på eventuelle behov for ”test-opmærkning” undervejs.
</td><td>
Viden om portalmiljøets (særligt ”sandkassemiljøets) kapacitet og tekniske egenskaber, herunder planlagte ændringer mv.
Validér opmærkning af ny version
Der kan forekomme iterationer mellem denne aktivitet og Opmærk ny version hos serviceudbyder.
</td><td>
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.
</td><td>
Information fra serviceudbyder om den nye versions funktionalitet og teknisk egenskaber.
BORGER Teknisk opmærkning er eventuelt ændret.
Vær opmærksom på erfaringer fra det oprindelige integrationsforløb, og fokusér tests på ændringer.
</td><td>
Information fra serviceudbyder om den nye versions funktionalitet og tekniske egenskaber
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.
</td><td>
</td><td>
Ny version klar til test.
Vær opmærksom på andre komponenter og ressourcer, som den nye version er afhængig af.
</td><td>
Plan for staging af ny version..
Ny version klar til staging.
Ny version på plads i det relevante driftsmiljø.
Godkend Go live for ny version
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.
</td><td>
Ny version af portalservice godkendt til go-live på portalen.
Go live for ny version
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.
</td><td>
Ny version af portalservice godkendt til go-live på portalen.
Ny version på plads i produktion-miljø.
Tidligere version er arkiveret.

Resultater i processen

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.
Teknisk rådgivning fra portalejer vedrørende integration af ny version af portalservice.
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.
En formel aftale mellem serviceudbyder og portalejer om go-live for den nye version af portalservicen.
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 hos Serviceudbyder
Aftal med portalejer at fjerne service
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.
</td><td>
Aftale om at fjerne portalservice fra portalen.
Advisér berørte parter
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.
</td><td>
Viden om hvilke parter, der bliver berørt af, at portalservicen fjernes.
Berørte parter er adviseret.
Godkend at fjerne service
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.
</td><td>
Aftale om at fjerne portalservice.
Viden om gennemførte aktiviteter.
Godkendelse af at fjerne portalservice.
Fjern opmærkning
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.
</td><td>
Godkendelse af at fjerne portalservice.
Portalservice fjernet fra portal.
Tag service ud af IdP miljø
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.
</td><td>
Information fra serviceudbyder om at tage portalservice ud af IdP miljøet.
Portalservice fjernet fra IdP miljø.
Aftal med serviceudbyder at fjerne service
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.
</td><td>
Information fra serviceudbyder om at fjerne portalservice.
Viden om portalmiljøet, herunder planlagte ændringer mv.
Aftale om at fjerne portalservice.
Forbered at fjerne service
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.
</td><td>
Aftale om at fjerne portalservice.
Portalmiljø mv. er forberedt til at fjerne portalservice.
Godkend at fjerne service
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.
</td><td>
Aftale om at fjerne portalservice.
Viden om forberedelse.
Godkendelse af at fjerne portalservice.
Tag service ud af portal
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.
</td><td>
Godkendelse af at fjerne portalservice
Portalservice fjernet fra portal.

Resultater i processen

Aftale om at fjerne en service
En aftale mellem serviceudbyder og portalejer om at fjerne en portalservice fra portalen.
Godkendt at fjerne service
En godkendt aftale om at fjerne en portalservice fra portalen.
Service fjernet
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.

Deletions:
Ansvarlig
Projektleder (Serviceudbyder)
Resultat
Portalejer kontaktes for at aftale et udviklingsforløb frem mod integration af en ny version af en portalservice på portalen.</td></tr><tr><td>
Portalservice er allerede i drift på portalen.
Beslutning om integration af ny version på portal er truffet.
Kontaktinformation og aftale om udviklingsforløb.</td></tr><tr><td>
www.virk.dk/myndighedsnet (Virksomhedsportal)
http://www.borger.dk/forside/om-borgerdk/til-myndigheder∞ (Borgerportal)

Aktiviteter hos IdP udbyder

Aktiviteter hos Portalejer

I version 1.0 af integrationsmodellen vil der være beskrivelser af de enkelte aktiviteter. Nedenstående er et eksempel.
Aftal med portalejer at fjerne portalservice
""<table>
<tr>
<td>Ansvarlig</td>
<td>Projektleder (Serviceudbyder)</td></tr>
<tr><td>
Portalejer kontaktes for at træffe aftale om at fjerne portalservice fra portalen.</td></tr><tr><td>
</td></tr>
<tr>
<td>Resultat</td><td>-</td></tr>
<tr>
<td>Henvisninger</td><td>-

Aktiviteter hos IdP udbyder

Aktiviteter hos Portalejer

---

Edited on 2007-09-02 13:02:58 by KristianHjortMadsen

Additions:
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)
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.
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.

Deletions:
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 processen som udgangspunkt to gange.
For aktiviteter, som er fælles med aktiviteter i processen for at integrere en ny portalservice, kan der endvidere være henvisninger til disse aktiviteter.

---

Edited on 2007-09-02 12:32:23 by KristianHjortMadsen

Additions:
Den nødvendige konfigurering af IdP miljøet foretages, således at portalservicen kan fungere i sammenhæng med SSO infrastrukturen.
Serviceregistrering.
IdP miljø konfigureret.
Aktiviteter hos Portalejer
Etablér support til serviceudbyder
Servicekontakt (Portalejer)</td></tr><tr><td>
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.
Kontakt fra serviceudbyder og viden om behov.
Kontaktpersoner og supportressourcer er udpeget og aftale med serviceudbyder om at igangsætte et integrationsforløb.
Rådgiv om valg af integrationsform mv.
Integrationssupport (Portalejer)</td></tr><tr><td>
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.
Information fra serviceudbyder om portalservicens funktionalitet og tekniske egenskaber.
Viden om portalmiljøets kapacitet og tekniske egenskaber, herunder planlagt ændringer mv.
Initiel rådgivning til serviceudbyder.
Beslutningstager (Portalejer)</td></tr><tr><td>
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.
Information fra serviceudbyder om portalservicens funktionalitet og tekniske egenskaber.
Viden om portalmiljøets kapacitet og tekniske egenskaber, herunder planlagte ændringer mv.
Aftaler vedr. planlægning af samarbejdet under integrationsforløbet.
Rådgiv om integration
Integrationssupport (Portalejer)</td></tr><tr><td>
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.
Viden om portalmiljøets (særligt "sandkassemiljøets") kapacitet og tekniske egenskaber, herunder planlagte ændringer mv.
Integrationsrådgivning.
Validér opmærkning af service
Servicekontakt (Portaljer)</td></tr><tr><td>
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.
Serviceopmærkning.
Viden om portalens struktur for opmærkning.
Valideret serviceopmærkning.
Foretag integration
Integrationssupport (Portalejer)</td></tr><tr><td>
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.
Information fra serviceudbyder om portalservicens funktionalitet og teknisk egenskaber.
Viden om portalmiljøets kapacitet og tekniske egenskaber, herunder planlagte ændringer mv.
Portalmiljø er tilpasset og konfigureret.
BORGER Teknisk opmærkning er foretaget.
VIRK [MYNDIGHEDSNET]
BORGER [OMBORGER], [DESIGNBORGER]
Planlæg tests
Integrationssupport (Portalejer)</td></tr><tr><td>
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.
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.
Planlæg staging
Driftsansvarlig (Portalejer)</td></tr><tr><td>
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.
Planer for integrationsforløb og test.
Plan for staging af portalservice.
Gennemfør tests
Integrationssupport (Portalejer)</td></tr><tr><td>
De planlagte test-aktiviteter gennemføres.
Der kan forekomme tilbageløb til udviklingsaktiviteter hos serviceudbyder og Gennemfør staging.
Portalservice klar til test.
Gennemfør staging
Driftsansvarlig (Portalejer)</td></tr><tr><td>
De planlagte staging-aktiviteter gennemføres.
Vær opmærksom på andre komponenter og ressourcer, som portalservicen er afhængig af.
Plan for staging af portalservice.
Portalservice klar til staging.
Godkend Go live for service
Beslutningstager (Portalejer)</td></tr><tr><td>
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.
Portalservice godkendt til go-live på portalen.
Go live for service
Driftsansvarlig (Portalejer)</td></tr><tr><td>
Produktion-miljøet konfigureres således at portalservicen gøres tilgængelig for brugere af portalen.
Portalservice godkendt til go-live på portalen.
Portalservice på plads i produktion-miljø.

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].
Tilslutningsaftale
Beskrivelse
En formel aftale mellem serviceudbyder og portalejer om integration af en portalservice.
Henvisninger
VIRK [MYNDIGHEDSNET].
Integrationsrådgivning
Beskrivelse
Teknisk rådgivning fra portalejer vedrørende integration af portalservice.
Henvisninger
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
Testplaner
Beskrivelse
Aftalte planer for de tests, der skal gennemføres i integrationsforløbet.
Henvisninger
Testresultater
Beskrivelse
Dokumentation for resultaterne af de gennemførte tests.
Henvisninger
Go live aftale
Beskrivelse
En formel aftale mellem serviceudbyder og portalejer om go-live for portalservicen.
Henvisninger
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
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

Deletions:
NÅET HERTIL

---

Edited on 2007-09-02 11:46:41 by KristianHjortMadsen

Additions:
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 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.</td></tr><tr><td>
Kontaktinformation og aftale om at igangsætte et integrationsforløb.</td></tr><tr><td>
VIRK [MYNDIGHEDSNET].
BORGER [OMBORGER].
Vælg integrationsform, tests mv.
Udvikler (Serviceudbyder)</td></tr><tr><td>
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.

</td></tr><tr><td>
Viden om portalservicens funktionalitet og tekniske egenskaber samt og serviceudbyders infrastruktur, fx udviklings- og driftsmiljø.
Initiel rådgivning fra portalejer.
</td></tr><tr><td>
Integrationsform for portalservicen er valgt.
Ambitionsniveau fastlagt for integrationsforløbet, særligt tests.
</td></tr><tr><td>
Integrationsmodellens bilag A.
VIRK [MYNDIGHEDSNET].
BORGER [OMBORGER].
Indgå aftale med IdP udbyder
Der indgås trustaftale med IdP udbyderen, således at portalservicen kan indgå i SSO.
</td></tr><tr><td>
Viden om portalservicens funktionalitet og tekniske egenskaber.
Viden om serviceudbyders sikkerhedsinfrastruktur.
</td></tr><tr><td>
Trustaftale
</td></tr><tr><td>
Integrationsmodellens bilag A.
VIRK [MYNDIGHEDSNET].
BORGER [OMBORGER].
Indgå aftale med portalejer
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.
</td></tr><tr><td>
Viden om portalservicens funktionalitet og tekniske egenskaber.
Planer for integrationsforløb.
</td></tr><tr><td>
Tilslutningsaftale.
Aftaler vedr. samarbejdet under integrationsforløbet.
</td></tr><tr><td>
VIRK [MYNDIGHEDSNET].
BORGER [OMBORGER].
Udvikl service
Udvikler (Serviceudbyder)</td></tr><tr><td>
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.
</td></tr><tr><td>
Integrationsrådgivning
Portal sandkassemiljø
IdP sandkassemiljø
</td></tr><tr><td>
Portalservice udviklet.
</td></tr><tr><td>
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
Udvikler (Serviceudbyder)</td></tr><tr><td>
Portalservicen registreres hos portalen og opmærkes ud fra funktionalitet, målgruppe mv. i forhold til portalens struktur for emneord, temaer mv.
Dette gøres ved hjælp af portalens registreringsværktøj.
</td></tr><tr><td>
Viden om portalservicens funktionalitet og tekniske egenskaber.
</td></tr><tr><td>
Service opmærket i portalens registreringsværktøj.
</td></tr><tr><td>
Integrationsmodellens bilag A.
VIRK [MYNDIGHEDSNET].
BORGER [OMBORGER].
Registrér service hos IdP
Udvikler (Serviceudbyder)</td></tr><tr><td>
Portalservicen skal registreres hos IdP udbyder.
</td></tr><tr><td>
Viden om portalservicens funktionalitet og sikkerhedsmæssige egenskaber.
</td></tr><tr><td>
Portalservice registreret i IdP miljø.
</td></tr><tr><td>
Integrationsmodellens bilag A.
VIRK [MYNDIGHEDSNET].
BORGER [OMBORGER].
Planlæg tests og staging
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.
</td></tr><tr><td>
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.
</td></tr><tr><td>
Testplaner
Krav og behov til test- og udviklingsmiljøer, ressourcer mv.
</td></tr><tr><td>
VIRK [MYNDIGHEDSNET].
BORGER [OMBORGER].
Gennemfør tests og staging
Udvikler (Serviceudbyder)</td></tr><tr><td>
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.
</td></tr><tr><td>
Testplaner.
En portalservice, som er klar til test.
</td></tr><tr><td>
Testresultater.
Portalservice på plads i det relevante driftsmiljø.
</td></tr><tr><td>
VIRK [MYNDIGHEDSNET].
BORGER [OMBORGER].
Godkend Go live for ny service
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.
</td></tr><tr><td>
Testresultater.
</td></tr><tr><td>
Portalservice godkendt til go-live.
</td></tr><tr><td>
Integrationsmodellens bilag A.
Tjeklister/krav i serviceudbyders egen udviklingsmodel.
VIRK [MYNDIGHEDSNET].
BORGER [OMBORGER].
Aktiviteter hos IdP udbyder
Indgå aftale med serviceudbyder
IdP udbyder</td></tr><tr><td>
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.
</td></tr><tr><td>
Viden om portalservicens funktionalitet og tekniske egenskaber.
Viden om serviceudbyders sikkerhedsinfrastruktur.
Viden om IdP infrastruktur og de krav, den stiller til portalservicen.
</td></tr><tr><td>
Trustaftale.
</td></tr><tr><td>
Integrationsmodellens bilag A.
VIRK [MYNDIGHEDSNET].
BORGER [OMBORGER].
Konfigurér service i IdP miljø
IdP udbyder</td></tr><tr><td>
NÅET HERTIL
</td></tr><tr><td>
Viden om portalservicens funktionalitet og tekniske egenskaber.
Viden om serviceudbyders sikkerhedsinfrastruktur.
Viden om IdP infrastruktur og de krav, den stiller til portalservicen.
</td></tr><tr><td>
Trustaftale.
</td></tr><tr><td>
Integrationsmodellens bilag A.
VIRK [MYNDIGHEDSNET].
BORGER [OMBORGER].

Deletions:

Portalejer kontaktes for at aftale et udviklingsforløb frem mod integration af en portalservice på portalen.</td></tr><tr><td>

---

Edited on 2007-09-02 11:13:45 by KristianHjortMadsen

Additions:
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.
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
Udvikler
Integrationssupport
Service kontakt
Driftansvarlig
Beslutningstager

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.

Deletions:
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 myndighed skal arbejde med en konkret portalservice i en konkret portal. Procesbeskrivelserne fokuserer på fælles elementer, men peger også på steder, hvor der kan være tale om særlige forhold i forhold til de enkelte integrationsformer eller forskelle mellem de to portaler. Eksempelvis skal processen som udgangspunkt udføres to gange, hvis den samme portalservice skal udstilles på – eller fjernes fra – begge portaler. Dog skal nogle aktiviteter kun 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.
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 forventes det afklaret maj-juni 2007.
I procesdiagrammerne er de tre aktører er 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
Udvikler
Integrationssupport
Service kontakt
Driftansvarlig
Beslutningstager

---

Edited on 2007-06-06 04:48:23 by WebMaster

Additions:

3 Processer omkring integration af en portalservice i portalerne

Deletions:

2 Processer omkring integration af en portalservice i portalerne

---

Edited on 2007-06-06 04:48:14 by WebMaster

Additions:
2 Introduktion til integrationsmodellen 3 Processer omkring integration af en portalservice i portalerne<- du er her!
4 Overordnede retningslinier for integration af portalservices
5 Anbefalinger til mønstre for udvikling af portalservices

Deletions:
2 Processer omkring integration af en portalservice i portalerne<- du er her!
3 Overordnede retningslinier for integration af portalservices
4 Anbefalinger til mønstre for udvikling af portalservices

---

Edited on 2007-06-03 17:18:57 by WebMaster

Additions:
Indhold

---

Edited on 2007-05-30 17:46:28 by WebMaster

Additions:

2 Processer omkring integration af en portalservice i portalerne

Deletions:

Processer omkring integration af en portalservice i portalerne

---

Edited on 2007-05-30 17:43:07 by WebMaster

Additions:
1 Indledning

Deletions:
1 Indledning

---

Edited on 2007-05-30 17:42:26 by WebMaster

Additions:

Processer omkring integration af en portalservice i portalerne

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

OIM Oversigt

Deletions:

Processer omkring integration af en portalservice i portalerne

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

OIM Oversigt

---

Edited on 2007-05-30 17:40:56 by WebMaster

Additions:

Den Offentlige Integrationsmodel, OIM

---

Oldest known version of this page was edited on 2007-05-30 17:38:43 by WebMaster []





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 myndighed skal arbejde med en konkret portalservice i en konkret portal. Procesbeskrivelserne fokuserer på fælles elementer, men peger også på steder, hvor der kan være tale om særlige forhold i forhold til de enkelte integrationsformer eller forskelle mellem de to portaler. Eksempelvis skal processen som udgangspunkt udføres to gange, hvis den samme portalservice skal udstilles på – eller fjernes fra – begge portaler. Dog skal nogle aktiviteter kun 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.

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 forventes det afklaret maj-juni 2007.

I procesdiagrammerne er de tre aktører er 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.

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

I version 1.0 af integrationsmodellen vil der være beskrivelser af de enkelte aktiviteter. Nedenstående er et eksempel.

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 udviklingsforløb frem mod integration af en portalservice på portalen.
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.
Resultat	Kontaktinformation og aftale om udviklingsforløb.
Henvisninger	www.virk.dk/myndighedsnet (Virksomhedsportal) http://www.borger.dk/forside/om-borgerdk/til-myndigheder (Borgerportal)

Aktiviteter hos IdP udbyder

Aktiviteter hos Portalejer

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 processen som udgangspunkt to gange.

∞

Aktiviteter

I version 1.0 af integrationsmodellen vil der være beskrivelser af de enkelte aktiviteter. Nedenstående er et eksempel.

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.

For aktiviteter, som er fælles med aktiviteter i processen for at integrere en ny portalservice, kan der endvidere være henvisninger til disse aktiviteter.

Aktiviteter hos Serviceudbyder

Etablér kontakt til portalejer

Ansvarlig	Projektleder (Serviceudbyder)
Beskrivelse	Portalejer kontaktes for at aftale et udviklingsforløb frem mod integration af en ny version af en portalservice på portalen.
Input og forudsætninger	Portalservice er allerede i drift på portalen. Beslutning om integration af ny version på portal er truffet. Hvis flere myndigheder er fælles om udstilling af en portalservice, er deres indbyrdes ansvarsfordeling afklaret.
Resultat	Kontaktinformation og aftale om udviklingsforløb.
Henvisninger	www.virk.dk/myndighedsnet (Virksomhedsportal) http://www.borger.dk/forside/om-borgerdk/til-myndigheder (Borgerportal)

Aktiviteter hos IdP udbyder

Aktiviteter hos Portalejer

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.

Aktiviteter

I version 1.0 af integrationsmodellen vil der være beskrivelser af de enkelte aktiviteter. Nedenstående er et eksempel.

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 portalservice

Ansvarlig	Projektleder (Serviceudbyder)
Beskrivelse	Portalejer kontaktes for at træffe aftale om at fjerne portalservice fra portalen.
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	-
Henvisninger	-

Aktiviteter hos IdP udbyder

Aktiviteter hos Portalejer