Den Offentlige Integrationsmodel, OIM

Introduktion til integrationsmodellen

Introduktion til centrale begreber

Her introduceres en række begreber, som anvendes i integrationsmodellen.

• Portal. Da integrationsmodellen er rettet mod Borgerportalen og Virksomhedsportalen, er det disse to specifikke portaler, der henvises til med ordet ”portal”. Betegnelserne ”en portal” eller ”portalen” henviser til en vilkårlig af de to portaler. Betegnelserne ”portaler” eller ”portalerne” henviser til en vilkårlig af de to portaler eller begge portaler. Hvis der specifikt menes kun en af de to portaler, nævnes den eksplicit: ”Borgerportalen” eller ”Virksomhedsportalen”. Betegnelsen ”begge portaler” anvendes, hvis der eksplicit menes både borgerportalen og virksomhedsportalen.
• Portalservice. En ”portalservice” (eller ”tjeneste”) er i integrationsmodellen en it-løsning med en brugergrænseflade, som udstilles i portalen, således at brugere af portalservices får adgang til brugergrænsefladen via portalen. I denne sammenhæng er en typisk bruger af en portalservice således en slutbruger, dvs. en person i sin egenskab af borger eller som ansat i en virksomhed.1
• Fælleskomponent.2 En fælleskomponent betragtes i integrationsmodellen som en portalservice på lige fod med øvrige portalservices, hvis den udstilles i portalen. En fælleskomponent er særligt kendetegnet ved, at den løser opgaver for andre portalservices. Integrationen mellem disse portalservices og fælleskomponenten ligger uden for integrationsmodellens emneområde. En fælleskomponent er typisk et resultat af behovsafdækning foretaget i et af de to portalprojekter, men kan også være udviklet udenfor disse projekter.
• Integrationsform. Foranalysen til projektet vedrørende udvikling af en fællesoffentlig borgerportal har peget på fire alternative tekniske integrationsformer, som kan anvendes, når en portalservice skal udstilles på portalen. Integrationsmodellen angiver retningslinier for to anbefalede integrationsformer Link, Iframe og beskriver nogle kommende integrationsformer, herunder WSRP.3
• Portalservicetype. Integrationsmodellen arbejder med to typer portalservices:
• Transaktionsportalservices, hvor brugeren kan gennemføre en transaktion, som medfører tilstandsskift i data, som administreres af den pågældende portalservice.
• Informationsportalservices, der stiller information til rådighed for brugeren, uden mulighed for at gennemføre transaktioner.
• Portalservice-implementering. En portalservice-implementering er den eller de softwarekomponenter, der - når de eksekverer i et run-time miljø - leverer den funktionalitet, som portalservicen stiller til rådighed for anvenderen.
• Serviceudbyder. En serviceudbyder er en myndighed - eller flere myndigheder i fællesskab - som udstiller en portalservice på portalen. Hvis flere myndigheder i fællesskab udvikler en portalservice, som udstilles på portalerne, betragtes disse myndigheder i integrationsmodellen som én serviceudbyder. En privat leverandør kan også fungere som serviceudbyder på vegne af en eller flere myndigheder.
• Portalejer. En ejer af en af de to portaler, dvs. Erhvervs & Selskabsstyrelsen som ejer af virksomhedsportalen, og IT- og telestyrelsen som ejer af borgerportalen. Hvis der eksplicit menes kun en af de to portalejere, fremgår det af teksten.
• IdP udbyder. Den organisation, som driver den løsning, som portalen anvender til autentifikation (single sign-on). For virksomhedsportalens vedkommende er det Erhvervs & Selskabsstyrelsen. For borgerportalens vedkommende er det den fællesoffentlige IdP aktør.

Scenarier for brug af integrationsmodellen

Integrationsmodellens primære målgruppe er myndigheder, der som serviceudbydere udstiller portalservices i portalerne, og deres leverandører, samt portalejerne og deres leverandører.

De enkelte serviceudbydere kan anvende integrationsmodellen forskelligt afhængig af deres it-kompetencer, erfaring med udstilling af portalservices på portalerne, og også fordeling af opgaverne mellem dem og deres leverandører. Eksempelvis kan en serviceudbyder anvende en af processerne i integrationsmodellen som hjælp til planlægning af et internt projekt, hvor retningslinierne efterfølgende anvendes ved udstilling af en ny version af en portalservice, der allerede findes på portalen. En anden serviceudbyder kan vælge at vedlægge integrationsmodellen som bilag til en kravspecifikation for en ny portalservice, som serviceudbyderen ønsker udviklet hos en leverandør.



Med udgangspunkt i livsforløbet for en portalservice, beskrives tre overordnede scenarier for brug af integrationsmodellen kort, og de processer, som serviceudbyder gennemløber i hvert af de tre scenarier, beskrives efterfølgende.

Hvis der er tale om flere myndigheder, som i fællesskab udstiller portalservicen, betragtes de som én serviceudbyder. Deres indbyrdes fordeling af ansvar og opgaver og deres øvrige mellemværender er uden for integrationsmodellens emneområde..

Serviceudbyder skal udstille ny portalservice på portalen

I dette scenarium udstiller en serviceudbyder en portalservice på portalen, som ikke er udstillet på portalen i forvejen. Der kan være tale om en portalservice, som skal udvikles, eller den pågældende portalservice kan eksistere i forvejen, men er blot ikke udstillet på portalen. Eksempelvis kan portalservicen være udstillet på serviceudbyderens egen hjemmeside, eller portalservicen er udstillet på Borgerportalen, og skal nu udstilles på Virksomhedsportalen.

Scenariet tager udgangspunkt i, at serviceudbyderen har truffet beslutning om at udstille en portalservice på portalen. Integrationsmodellen forholder sig ikke til beslutningsprocessen, men fokuserer på den del af udviklingsprocessen, som vedrører integration af portalservicen på portalen.

Serviceudbyder skal udstille ny version af en portalservice på portalen

I dette scenarium har serviceudbyder en portalservice kørende i drift på portalen.

Scenariet tager udgangspunkt i, at serviceudbyderen har truffet beslutning om at udstille en ny version af portalservicen på portalen, der erstatter den eksisterende version. Integrationsmodellen forholder sig ikke til beslutningsprocessen, men fokuserer på den del af udviklingsprocessen, som vedrører integration af den nye version af portalservicen på portalen.

Dette scenarium dækker ikke den situation, hvor der tale om et tidsmæssigt sammenfald mellem at udstille en ny portalservice og fjerne en anden portalservice fra portalen. I dette tilfælde bør serviceudbyder gennemføre de to relevante processer koordineret.

Serviceudbyder skal fjerne portalservice fra portalen

I dette scenarium har serviceudbyder en portalservice kørende i drift på portalen.

Scenariet tager udgangspunkt i, at serviceudbyderen har truffet beslutning om at fjerne portalservicen fra portalen. Integrationsmodellen forholder sig ikke til beslutningsprocessen, men fokuserer på den del af udviklingsprocessen, som vedrører det at fjerne portalservicen fra portalen.

Generelle principper for integrationsmodellen

Nedenstående otte principper udgør sideordnede pejlemærker, som integrationsmodellens retningslinier skal tilgodese inden for de overordnede rammer, som integrationsmodellen udfylder. Principperne er indgået i udarbejdelsen af de retningslinier, som udgør de operationelle krav og anbefalinger til integration af portalservices i de to portaler.

1.Én integrationsmodel for de to portaler

Beskrivelse	Integrationsmodellen skal anvise fælles retningslinier for integration af portalservices på de to portaler.
Rationale	Det er en målsætning for de to portalprojekter, at myndighederne skal spare tid og penge i forbindelse med det arbejde, som de skal udføre ved udstilling af portalservices. Integrationsmodellen kan ved at anvise fælles retningslinier for de to portaler understøtte denne målsætning. En fælles integrationsmodel kan understøtte de væsentlige udviklingstiltag, der foregår omkring de to portaler.
Konsekvenser	Serviceudbydere, der skal udstille portalservices på begge portaler, vil kun skulle sætte sig ind i én model.

2.Brug af åbne standarder

Beskrivelse	Integrationsmodellen skal så vidt muligt pege på åbne standarder. Brug af leverandørspecifikke løsninger skal kun undtagelsesvist anvendes.
Rationale	Det må forventes, at der til stadighed vil være softwareprodukter fra forskellige leverandører i brug hos portalejere og serviceudbydere, ligesom der løbende kan ske udskiftning af disse. Øget brug af åbne standarder i den offentlige sektor er medvirkende til at fremme interoperabilitet og uafhængighed af specifikke softwareprodukter, og kravet er bl.a. udtrykt i folketingsbeslutningen B103.
Konsekvenser	Det kan forekomme, at ønsket funktionalitet begrænses eller forsinkes afhængig af standardernes udvikling og leverandørernes implementering af disse. Eventuelle afvigelser eller udvidelser i forhold til standarder skal fremgå tydeligt, hvor det er relevant, eller alternativt foretages sådanne udvidelser i konkrete situationer, uden for rammerne af integrationsmodellen.

3.Ansvaret for udvikling og drift af portalservices ligger hos myndighederne

Beskrivelse	Ansvaret for udvikling af de portalservices, der udstilles på de to portaler, ligger hos de myndigheder, som har ansvaret for forretningsprocesserne på det pågældende område. Eventuel samordning af forretningsprocesser, herunder sags- og processtyring, på tværs af myndigheder, skal ske i samarbejde mellem de relevante myndigheder.
Rationale	Ansvaret for udvikling af de portalservices, som udstilles på de to portaler, ligger både i dag og fremover hos de enkelte myndigheder, jf. det overordnede princip om, at de enkelte myndigheder har ansvaret for egen digitalisering.
Konsekvenser	Myndighederne forestår selv kravspecifikation og udvikling af portalservices. Dette inkluderer integration i portalerne, hvortil integrationsmodellen er et redskab. På tilsvarende måde ligger ansvaret hos myndighederne i de tilfælde, hvor to eller flere myndigheder i fællesskab, udstiller en portalservice. Integrationsmodellen gælder også for eventuelle fælles­komponenter, som udstilles i portalen, mens ansvaret for udviklingen af fælleskomponenter ligger hos en eller flere myndigheder.

4.Portalservices udvikles uafhængigt af portalprodukter

Beskrivelse	Integrationsmodellen skal understøtte, at portalservices kan udvikles hos serviceudbyderne uafhængigt af portalejernes valg af specifikke portalprodukter.
Rationale	Idet det må forventes, at de softwareprodukter, som anvendes hos parterne, vil udvikle sig og eventuelt blive udskiftet, uafhængigt af hinanden, er det hensigtsmæssigt, så vidt muligt at gøre integrationsmodellen uafhængig af specifikke produkter.
Konsekvenser	Portalservices og portaler kan udvikles uafhængigt af hvilke specifikke produkter der anvendes til implementering, bl.a. via integrationsmodellens alternative integrationsformer. Portalservices baseret på .NET kan integreres ved hjælp af link eller Iframe eller på sigt potentielt ved hjælp af WSRP. Idet JSR168 er Java-baseret, er den ikke anvendelig ved portalservices baseret på .Net. Integrationsmodellen fokuserer på logiske specifikationer frem for fysisk implementering, hvilket medvirker til at gøre integrationsmodellen uafhængig af specifikke produkter.

5.De to portaler er udstillingsvinduer for myndighedernes portalservices

Beskrivelse	De to portaler skal fungere som udstillingsvinduer til myndighedernes portalservices. Forretningslogik, herunder sags/processtyring eksekveres inden for inden for rammerne af de portalservices, som myndighederne udstiller, og ikke i portalen.
Rationale	Portalerne skal være tynde både teknisk (udstillingsvinduer) og organisatorisk, idet ansvaret for udvikling af portalservices fortsat ligger hos myndighederne, også i de tilfælde, hvor to eller flere myndigheder udstiller en portalservice i fællesskab.
Konsekvenser	Der skal ikke afvikles forretnings/proceslogik i portalerne, og procesmæssig integration mellem portalservices implementeres uden for portalerne. Integrationsmodellen skal således ikke forholde sig til processtyring, hverken i relation til myndighedernes udviklingsproces eller den tekniske integration af portalservices i portalerne, men derimod fokusere på integration mellem portalerne og de portalservices, der udstilles der.

6.Krav og anbefalinger til visuel integration og navigation

Beskrivelse	Integrationsmodellen fremmer fælles look and feel på tværs af de to portaler og de portalservices, som udstilles der, gennem krav og anbefalinger til de integrationsmekanismer, der anvendes til den visuelle integration af portalservices.
Rationale	Visuel integration, dvs. ensartet visuelt design og navigation på tværs af portalservices, medvirker til at gøre portalerne mere brugervenlige set fra et slutbruger-synspunkt. Integrationsmodellen kan fremme dette ved at stille visse fælles minimumskrav, der ligeledes kan medvirke til at hæve det fælles niveau for de portalservices, som udstilles. Dette kan eksempelvis imødekomme behov for at synliggøre ansvarsfordeling mellem portalejere og serviceudbydere.
Konsekvenser	Graden af fælles look and feel bliver ikke fastlagt af integrationsmodellen, men af hvor ens designmanualerne for de to portaler er, og i hvor høj grad de fastlægger retningslinier for de portalservices, der udstilles.

7.Bruger/rettighedsstyring baseres på fællesoffentligt koncept

Beskrivelse	Integrationsmodellen skal indrettes efter det fællesoffentlige koncept for bruger- og rettighedsstyring herunder single sign-on.
Rationale	Det fællesoffentlige koncept er en central del i en række store offentlige projekter, og er en del af forudsætningerne for den nye borgerportal. Dertil kommer, at ved at basere integrationsmodellen herpå, styrkes myndighedernes muligheder for at høste gevinsterne ved det fælles arbejde ved ikke at skulle udvikle samme funktionalitet flere gange.
Konsekvenser	Portalservices, der skal integreres på de to portaler, skal kun forholde sig til og anvende et og samme koncept for bruger/rettighedsstyring. Integrationsmodellen er afhængig af udviklingen af det fællesoffentlige koncept, både indholds- og tidsmæssigt.

8.Organisatoriske og tekniske trends indarbejdes løbende

Beskrivelse	Integrationsmodellen skal ajourføres med passende mellemrum efter version 1.0, således at de muligheder, som den tekniske udvikling giver, vil blive indarbejdet, lige som eventuelle konsekvenser af organisatoriske forandringer omkring de to portaler, indarbejdes i det omfang, det ikke kan undgås.
Rationale	Udviklingen af standarder og produkter inden for serviceorienteret arkitektur og portalteknologi fortsætter også fremover. På tilsvarende måde kan det forventes myndighederne i den offentlige sektors opgaver og fordeling heraf vil udvikle sig. Det er derfor naturligt og nødvendigt, at integrationsmodellen også udvikler sig efter den første version.
Konsekvenser	Der skal i integrationsmodellen fokuseres på logiske specifikationer (fx interfaces) frem for at lægge den tekniske implementering fast (konkrete produkter og tekniske løsninger der anvendes på portalsiden) således at implementeringen kan ændre sig uafhængig af og uden at påvirke de portalservices, der integreres i portalerne.

Valg af integrationsform

Ved integration af en portalservice er valget af integrationsform centralt. Integrationsmodellen anbefaler de to integrationsformer Link og Iframe. Integrationsmodellen peger endvidere på en række kommende integrationsformer, herunder WSRP, som potentielt kan anvendes på sigt. Anvendelse af disse kan kun ske efter aftale med portalejeren.

Valget mellem Link og Iframe foretages i den konkrete situation af serviceudbyder i dialog med portalejer, der kan yde integrationsrådgivning. Valget af integrationsform afhænger af en række faktorer, hvoraf følgende indgår:

• Er der tale om en eksisterende portalservice tages dens tekniske egenskaber vedrørende integration i betragtning.
• Iframe vælges så vidt det er muligt inden for de rammer, som gælder serviceudbyderens integrationsforløb. Her er der tale om en tættere visuel integration, hvor portalservicen bør følge portalens visuelle design og benytte [OIMCSS]. Undtagelser herfra aftales nærmere med portalejer.
• Hvis portalservicen skal integreres med Link kan portalservicen følge portalens design og kan benytte [OIMCSS]. Serviceudbydere opfordres til at følge portalens design.
• Er der tale om en portalservice, som endnu ikke er udviklet, er de tekniske egenskaber ved serviceudbyderens udviklings- og driftsmiljø en faktor. Antallet af portaler, hvori portalservicen skal udstilles, kan også indgå. Økonomien er også en faktor. Det må forventes at link er billigst og iFrame er dyrere.
• Hvis serviceudbyders udviklings- og driftsmiljø tillader at udvikle en portalservice, der følger portalens design og benytter [OIMCSS] er dette at foretrække. Herigennem afkobles implementering af det visuelle design fra den øvrige portalservice-implementering.

Noter

1. Begrebet ”portalservice” anvendes her i en mere specifik betydning end det generelle ”service”, der i relation til Service Orienteret Arkitektur ofte anvendes om en funktionalitet, som en it-løsning stiller til rådighed for andre it-løsninger (”system til system” integration).

2. "Fælleskomponent" er et meget generisk udtryk, som anvendes om en komponent, der løser opgaver, som er fælles for en række andre komponenter. Disse andre komponenter kan så anvende fælleskomponenten frem for at løse de fælles opgaver hver især.

3. Foranalysen til projektet vedrørende udvikling af en fællesoffentlig borgerportal pegede foruden de tre integrationsformer, som integrationsmodellen giver retningslinier for, på JSR-168 samt ”web clipping” (en variant af Iframe). JSR-168 er fravalgt ud fra erfaringerne i det tekniske Proof of Concept projekt. JSR-168 fastholdes som en taktisk integrationsform til intern anvendelse i Virksomhedsportalen. Web clipping er generelt fravalgt af arbejdsgruppen. Der henvises til foranalysen til projektet vedrørende udvikling af en fællesoffentlig borgerportal [FORANALYSE] for yderligere beskrivelse.



CategoryOIM