Referansearkitektur for deling av data i høyere utdanning og forsking

image1

Tue Jun 08 2021 14:39:04 GMT+0200 (CEST)

1. Introduksjon

1.1. Bakgrunn

Denne referansearkitekturen er utarbeidet med det som mål at høyere utdanning og forskning skal få en felles datadelingsplattform, digital samhandlingspraksis og informasjonsforvaltningspraksis.

Økt deling av data er en forutsetning for å realisere flere av initiativene i ‘Handlingsplan for digitalisering i høyere utdanning og forskning’ innenfor de funksjonelle områdene utdanning, forskning og administrasjon.

1.1.1. Behov og bruksområder

Referansearkitekturen skal skape samhandling gjennom datadeling, bidra til å støtte bruksområder og dekke tilhørende behov i kunnskapssektoren.

De viktigste funksjonelle behovene er:

  • Videreutvikle datadeling for læring og forskning

  • Tilrettelegge for fleksibel læring gjennom hele livet

  • Gjøre forskning og forskningsresultater lettere tilgjengelig

  • Muliggjøre brukernær innovasjon

  • Forbedre deling av data mellom administrative tjenester for å støtte administrative prosesser

  • Fremme automatisering av saksbehandling

  • Tilrettelegge for «orden i eget hus» gjennom å bygge opp under felles praksis for informasjonsforvaltning

Tekniske behov som ønskes løst gjennom bruk av en referansearkitektur:

  • Forbedre evne til endring i IT-systemporteføljen

  • Felles integrasjonspraksis mellom IT-systemer

  • Skape felles kontekst for kravstilling i anskaffelser samt utvikling, drift og forvaltning av integrasjoner

  • Støtte implementasjonen av felles identitets- og tilgangsstyring

  • Tilby en felles begrepskatalog, datakatalog, API-katalog og notifikasjonskatalog med autorisasjon

  • Gi veiledning for definisjon av datakilder, datasett, API og notifikasjoner

  • Definere felles roller for tjenesteforvaltning, dataforvaltning og informasjonsforvaltning

  • Sørge for at kunnskapssektoren følger de nasjonale og sektorspesifikke retningslinjer som Digitaliseringsdirektoratet og andre spesifiserer

Disse behovene er beskrevet i mer detaljer i Vedlegg 4 Behov og bruksområder som skal dekkes av referansearkitekturen

1.1.2. Gevinst

En felles referansearkitektur legger til rette for at utdanning, forskning og administrasjon kan dekke sine datadelingsbehov på en måte som gir følgende gevinst. Effektiviteten økes når økt oversikt og forbedret samhandling muliggjør fjerning av unødvendige kopier av data og unødvendige varianter av begreper. Disse forbedringer reduserer administrativt byrde. Endringsevne og innovasjon økes når brukernære kontekst får tilgang til forenklet og tilpasset datasett av høy kvalitet til sitt bruk. En forbedret informasjonsforvaltningspraksis og datadelingsplattform vil gi økt tilgang til data av høy kvalitet, som igjen muliggjør datadrevet beslutninger.

1.1.3. Føringer, pågående og videre arbeid

Referansearkitekturen og dette dokumentet tar utgangspunkt i pågående arbeid og førende strategier og prinsipper nasjonalt, innen sektoren og internasjonalt.

Dette er beskrevet i Vedlegg 5 Føringer, pågående og videre arbeid

1.2. Forankring

Referansearkitekturen er utarbeidet i et samarbeidsprosjekt Datadeling med prosjektdeltagelse fra Unit, NTNU, Universitetet i Oslo og Uninett. Styringsgruppen består av medlemmer fra Unit, Universitetet i Bergen, OsloMet, Universitetet i Oslo, Norges Miljø- og Biovitenskaplige universitet og Uninett.

1.3. Målgruppe

Målgruppen for referansearkitekturen er primært arkitekter og tekniske prosjektledere. Deler av dokumentet er også relevant for domeneansvarlige, begrepseiere, tjenesteeiere, tjenesteansvarlige, utviklere og datakonsumenter (disse rollene er definert i dette dokumentet).

2. Tilnærming til utvikling av referansearkitekturen

Denne referansearkitekturen skal gi veiledning til utforming av digitale samhandlingsløsninger for deling av data i høyere utdanning og forskning. Denne seksjonen veileder gjennom en presentasjon av hva som skal oppnås ved å definere hva datadeling er, en visjon om hva vi skal bruke det til, og modellene som skal skape fundament for utforming av løsningene i visjonen.

2.1. Hva er datadeling

2.1.1. Hva er datadeling?

Følgende definisjon for datadeling er hentet fra Digitaliseringsdirektoratets temaområde for datadeling.

Formålet med datadeling er å forsyne forretningsprosesser og dataanalyse med nødvendig datagrunnlag for aktuell oppgaveløsning.

De fleste aktører sitter på begge sider i dette bildet, og må kunne både dele og innhente data. Det skilles på rollene som tilbyder og konsument.

I noen sammenhenger skilles det også mellom data og hendelser.

2.2. Økosystem

2.2.1. Visjon: Et økosystem for datadeling

I arbeidet med denne referansearkitekturen har vi tatt utgangspunkt i en idé om samhandling mellom ulike parter i et større hele. Dette er basert på visjonen om et økosystem, der aktører utfyller hverandre og samhandlingen skaper større verdi enn de enkelte aktører kan klare hver for seg. Studenter, undervisere, forskere og tjenestetilbydere med flere skal både skape, tilby, bearbeide og konsumere data på nye måter som gir alle insentiv og gevinst. I økosystemet for deling av data i høyere utdanning og forskning ser vi for oss de forskjellige aktørene i forskjellig kontekst kalt domener (se seksjonen under). Økosystemet skal etableres opp på en datadelingsplattform, og elementene i plattformen er spesifisert i referansearkitekturen.

økosystem
Figure 1. Et økosystem for deling av data i UHF-sektoren

Figuren viser datadeling i og mellom domener. Virksomhetskritiske og brukernære funksjoner som er domenespesifikke, kalles her tjenesteprodukter. Dataprodukter tilgjengeliggjøres og deles mellom domenene i økosystemet. Domenene kan opptre som datatilbydere (tilbyr dataprodukt) og datakonsumenter (datakonsum). Datadelingsplattformen og felleskomponentene tilbyr tjenester som muliggjør datadelingen i økosystemet.

2.3. Domener

Informasjonen som skal forvaltes finnes i en faglig kontekst som vi kaller et «domene».

Innen et domene definerer et fagområde sine begreper i det vokabularet som benyttes der. For eksempel vil et begrep som «Søker»[1] ha en beskrivelse, forståelse og sine egne data i et studieadministrativt domene.

Som en del av den generelle utvikling innen IT systemer, er sektoren i ferd med å bygge en distribuert arkitektur som knytter sammen løst koblet, delte datakilder.
Referansearkitekturen er laget for å støtte denne utviklingen ved å benytte domener som utgangspunkt for informasjonsforvaltning, utvikling av datakilder, datasett, API og hendelser.

Referansearkitekturen beskriver en datadelingsplattform som støtter deling av data mellom domener gjennom både API og publisering av hendelser. Vi grupperer domenene i grunnleggende domener og domener utviklet for spesielle brukstilfeller som avbildet under.

DomenerUHF
Figure 2. Domener i UHF-sektoren

De grunnleggende domenene inneholder data som støtter de sentrale prosessene for læring, forskning og administrasjon hos institusjonene.

Disse domenene inneholder blant annet masterdatakilder med informasjon om, for eksempel, studenter, ansatte, forskningsprosjekt, forskningsresultater, læringsobjekter, med flere. Disse kildene er definert ut fra en dyp forståelse av sektorenes funksjon og vil typisk være forholdsvis stabile over tid.

API og datasett definert i grunnleggende domener blir gjerne gjenbrukt av bruksnære domener.

De bruksnære domenene er definert til å støtte en spesifikk brukernær kontekst. Domener for brukskontekst inkluderer for eksempel situasjoner der studenter evaluerer emner, der studenter får automatisert tilbakemeldinger for å forbedre læringsprosessen (læringsanalyse) og der deltagere i forskningsprosjekt utfører forsøk.

Datasett og API definert her skal være spesifikke og skreddersydd til brukskonteksten.

Vi har hentet denne tilnærmingen fra faglitteratur om Data Mesh[2]» av Zhamak Dehghani]. Arkitekturen påvirker rutiner for utvikling av API, datasett og notifikasjoner beskrevet i seksjonen Rutiner for utvikling av API, notifikasjoner og datasett samt roller og ansvar beskrevet i seksjonen Roller og ansvar for datadeling og informasjonsforvaltning.

2.4. Hva er felles

Domenene beskrevet over, og rollene knyttet til disse får en definert avgrensning. Tilnærmingen til avgrensing følger fra strategiske valg i Handlingsplanen for digitalisering i høyere utdanning og forskning[3]. Disse valg er knyttet til hva som skal være standardisert, hva som skal være felles og hva som skal variere og fremme innovasjon. Administrasjons- og støtteprosesser skal benytte i størst mulig grad standardiserte arbeidsprosesser og felles begreper. Lærings- og forskningsprosesser skal fremme innovasjon gjennom ulike arbeidsprosesser og sterk grad av institusjonelt selvstyre.[4]

image6
Figure 3. Strategiske valg fra Handlingsplan for digitalisering i høyere utdanning og forskning

Disse ulike tilnærmingene har ulike behov for deling av data, og vi har benyttet disse føringene i avgrensning av domenene og rollene i referansearkitekturen.

Administrative prosesser og begreper skal være mest mulig standardisert. For å oppnå dette knyttes de til informasjonsdomener som representerer hele sektoren der definisjon av prosesser og begreper skal skje. Denne tilnærming er i tråd med eksisterende harmoniseringsprosesser i sektoren. Data som benyttes i de standardiserte, administrative prosessene derimot er knyttet til der hvor prosessen kjøres. I dag skjer dette som regel lokalt hos en institusjon.

Lærings- og forskningsprosesser vil variere og være knyttet til en brukskontekst med et tilhørende informasjonsdomene. Aktører knyttet til brukernære lærings- og forskningsdomener vil typisk ønske en bred tilgang til lærings- og forskningsressurser produsert av andre hos institusjonen, nasjonalt og internasjonalt. Det kan også være ønskelig å publisere resultater fra bruksdomene bredt. Brukernære domener innen læring og forskning vil derfor ønske støtte til å dele ressurser på tvers av institusjonene. Eksempler på tjenester som muliggjør slik datadeling er Nasjonalt Vitenarkiv og eventuelle «Learning Object Repository».

2.5. Samhandling og datadeling

Når datatilbydere og datakonsumenter deler data, skjer det som en del av en digital samhandling. For at samhandlingen skal være vellykket, må tilbydere og konsumenter sikre at de handler i henhold til loven (juridisk samhandlingsevne), at aktørene har avklart forventninger til hverandre og klarer å samarbeide (organisatorisk samhandlingsevne), at datatilbydere og konsumenter har samme forståelse av dataenes betydning (semantisk samhandlingsevne) og at de tekniske løsningene som utfører datadeling fungerer sammen slik de skal (teknisk samhandlingsevne). Rammeverk for digital samhandling[5] vist under utdyper disse samhandlingsevner.

Digital samhandling
Figure 4. Samhandling

Modellene som er utgangspunkt for referansearkitekturen for deling av data i høyere utdanning og forskning er laget for å ivareta juridisk-, organisatorisk-, semantisk- og teknisk samhandlingsevne og hjelper dermed de som benytter modellene til å lykkes med digital samhandling.

2.6. Verktøykassen for deling av data

Verktøykassen for deling av data[6] fra Digitaliseringsdirektoratet gir veiledning for de som skal bruke data fra andre (datakonsumenter) og de som skal dele data med andre (datatilbydere). Den overordnede prosessen brukt av datakonsumenter og datatilbydere for å dele data er beskrevet i verktøykassen og avbildet under.

Modellen beskriver verdistrømmer for både de som skal bruke data fra andre (datakonsumenter) og for de som skal dele data med andre (datatilbydere), samt forholdet mellom disse to verdistrømmene.

Verdistrømmene viser hvilke steg en datakonsument må gjennom for å motta data, og hvilke steg en datatilbyder må gjennom for å avgi data. Enkelte steg i verdistrømmene er tilpasset sektoren for høyere utdanning og forskning i referansearkitekturen. Dette er beskrevet senere i dokumentet

Før datatilbyderen kan utføre det første steget i verdistrømmen for datadeling må organisasjonen ha oversikt over egne data som skal deles. For å kunne utføre det andre steget i verdistrømmen må datatilbyderen ha evnen til å publisere datasettene slik at andre kan benytte disse. Disse stegene er sentral i «orden i eget hus». For at datadeling skal fungere etter hensikt, må dataene også ha god kvalitet. Dette krever kapabiliteter innen informasjonsforvaltning.  Vi har modellert disse evner som «muliggjørende kapabiliteter» i referansearkitekturen for høyere utdanning og forskning med utgangspunkt i EUNIS sin kapabilitetsmodell for europeiske universiteter som vist under. EUNIS modellen var produsert som et samarbeid mellom europeiske universiteter.

verdistrøm med orden i eget hus
Figure 5. Verktøykassen for deling av data

2.7. Muliggjørende kapabiliteter

For å være i stand til å utføre stegene i prosessen over, må organisasjoner opparbeide evner, kalt «kapabiliteter». Noen kapabiliteter er knyttet til bestemte steg i verdistrømmen over. Andre kapabiliteter er generelle og «muliggjørende» for alle steg i verdistrømmen.

God informasjonsforvaltning støtter både opp om organisatorisk samhandlingsevne gjennom å gi organisasjoner riktig data av god kvalitet og støtter opp om semantisk samhandlingsevne ved å klargjøre dataenes betydning.

Vi velger også å synliggjøre juridiske tjenester som muliggjørende kapabilitet for å støtte opp under juridisk samhandlingsevne. Alt i alt krever digital samhandling kapabiliteter som er tverrfaglige, der ingen kan fungere uten de andre.

Muliggjørende kapabiliteter image
Figure 6. Muliggjørende kapabiliteter

Vis detaljer om elementene i diagrammet (Tips: Shift-klikk for å åpne i nytt vindu)

2.8. Organisering og forvaltning av informasjon i domener for høyskoler, universiteter og forskning

Hvert domene har sin egen informasjon som må forvaltes. Disse domene er knyttet til kapabiliteter hos universiteter. Europeiske universiteter har modellert sine kapabiliteter i EUNIS kapabilitetsmodellen, og vi har brukt denne modellen som utgangspunkt for å foreslå informasjonsforvaltningsdomener som har ansvar for data institusjonene ønsker å dele. De foreslåtte domenene er vist i figuren under. Innen hver domene har fageksperter eierskap til begrepsdefinisjoner innen egen domene. Domenene er også ansvarlig for forvaltning av egen informasjon. Referansearkitekturen foreslår roller som har dette ansvaret i seksjonen Roller og ansvar for datadeling og informasjonsforvaltning.

Organisering og forvaltning av informasjon i domener for høyskoler
Figure 7. Organisering og forvaltning av informasjon i domener for høyskoler, universiteter og forskning

Vis detaljer om elementene i diagrammet (Tips: Shift-klikk for å åpne i nytt vindu)

3. Datadelingsplattformen og felles komponentene i den

Datadeling i og mellom domener i økosystemet skjer ved bruk av datadelingsplattformen i høyere utdanning og forskning. Datadelingplattformen består av felleskomponentene og bruk av disse for å realisere datautvekslingsmønstrene beskrevet i referansearkitekturen.

Saksbehandling og daglig drift hos institusjonene skjer ofte i kjernen av virksomheten, i det vi kaller de grunnleggende domener, mens arbeid i læringsgrupper og forskningsprosjekt skjer i brukersentriske domener.

I praksis betyr dette samhandling i høyere utdanning og forskning. Samhandlingen kan skje mellom medlemmer i lærings og forskningsgrupper både innenfor egne institusjoner og på tvers av institusjoner. Andre områder for samhandling kan være innen saksbehandling og annen administrasjon innen en institusjon, eller mellom institusjonene og andre sektorer i inn- og utland.

Plattformen skal støtte enkel publisering av data og effektive mekanismer for gjenfinning og tilgang til data for konsumenter som har rett til slik tilgang. Referansearkitekturen definerer prosessene og IT-støttet samhandlingsmønstrene brukt for å realisere deling av data.

Referansearkitekturen spesifiserer hvordan datasett og API skal:

  • defineres

  • brukes

  • gjenbrukes av nye konsumenter

  • brukes til nye oppgaver.

Datasett til nye formål kan være satt sammen av data fra flere andre API.
Deler av delingsplattformen skal inngå i Kunnskapsdepartementets datafellesskap der det skal bygges et økosystem for bruk av data rundt plattformen.

Virksomhetene i høyere utdanning og forskning må etablere tillit til hverandre for å kunne dele data. Datadelingsplattformen realiserer tilgangsstyring til sektorens data på en enhetlig måte gjennom bruk av felleskomponenter i plattformen. Hovedmetoden for tilgangsstyring i plattformen er API Management.

Referansearkitekturen definerer hvordan det varsles om endringer i datasett gjennom notifikasjoner. Varslene brukes til å reagere på endringene i datasettet, uten at hele datasettet konsumeres. Muligheten til å reagere på varsler om endringer tilrettelegger for hurtig behandling av data i situasjoner der tidsbruk er et sentralt kriterium for bruksmønsteret.

3.1. Føderert API management

Føderert API Management innebærer at et domene kan gi brukere i andre domener som man har et tillitsforhold til, ofte kalt fødereringspartnere, tilgang til sine egne data gjennom API. Det er flere grunner for å gjøre dette. Mange virksomheter har i dag sine virksomhetsdata lagret distribuert, fordelt mellom systemer som kjører på lokale servere («on-premise») og i skybaserte-løsninger.

Det er et sterkt politisk ønske om deling av data mellom domener. Flere initiativer, slik som Digitaliseringsdirektoratets "Orden i eget hus" og andre nasjonale og sektorvise digitaliseringsstrategier skal understøtte deling av data. I en slik sammenheng ser vi behovet for et felles API Management-regime i kunnskapssektoren.

Et slikt regime muliggjør deling av data for å oppnå sammenhengende brukerreiser, eksemplifisert ved de syv livshendelser og tjenestekjeder. Det er en forutsetning at data kan deles mellom virksomheter som betjener slike brukerreiser.

3.parts aktører kan bruke data fra sektoren for innovasjon. API management kan medvirke til deling av data til 3. part ved å gjøre data gjenfinnbart, tilgjengelig og dokumentert.

Virksomheter i høyere utdanning og Forskning har mange fellestrekk og noen fellestjenester på tvers. Deres autonomi gjør likevel at de er ulike på enkelte områder, for eksempel når det gjelder teknisk infrastruktur. Disse likhetene og forskjellene understreker behovet for en føderert API Management-løsning. En slik løsning er mer fleksibel med tanke på tekniske løsninger og produktvalg lokalt.

Felleskomponentene relatert til API-management i referansearkitekturen (se under) er laget for å støtte følgende karakteristikk:

  • Institusjonene er sikret råderett over egne data gjennom tilgangstjeneste i ressursportalen og API gateway hos institusjonen som kan styre og holde oversikt over datatilgang

  • Institusjonene har valgfrihet over API Gateway så lenge funksjoner og grensesnitt er ivaretatt

  • Deling av data på tvers av institusjoner er støttet gjennom felles ressursportal

3.2. Publisering av hendelser

For publisering av hendelser er det etablert et mønster der datatilbyder utsteder en lettvektsnotifikasjon som datakonsumenten kan abonnere på. Lettvektsnotifikasjonen inneholder en lenke til et API der datakonsumenten kan hente data relatert til notifikasjonen. Dette mønsteret er allerede i bruk i UHF-sektoren.

Lettvektsnotifikasjonen i en eNotifikasjon blir overført mellom datatilbyder og konsument av en meldingsformidler (event broker). Meldingsformidleren tar imot hendelser fra produsenter, og overfører hendelsen til de konsumenter som abonnere på i hendelsestypen, samtidig som den sørger for at eventuell leveransegaranti overholdes.

I likhet med behovet for en API katalog som beskriver hvilke APIer som finnes, er det nødvendig med en Notifikasjonskatalog som gir et overblikk over hvilke datatilbydere som publiserer notifikasjoner om endring i datagrunnlag.

3.3. Felleskomponenter

Datadelingsplattformen består av felleskomponentene beskrevet under. De fleste felleskomponenter skal realiseres som fellestjenester med en delt instans. API gateway er en funksjonell beskrivelse av en komponent som skal realiseres med instanser nær datakildene som skal tilbys.

Felleskomponenter image
Figure 8. Felleskomponenter

Vis detaljer om elementene i diagrammet (Tips: Shift-klikk for å åpne i nytt vindu)

3.4. Datadeling integrert med IAM

Infrastruktur for identitetshåndtering og tilgangsstyring (IAM) utfyller API management og notifikasjoner og må fungere sammen.

Autentisering er det som sjekker at brukeren er kjent for virksomheten og forsikrer at brukeren er den vedkommende gir seg ut for å være når brukeren ber om tilgang til ressurser.

Autorisering identifiserer hvilke tilganger en bruker skal ha til virksomhetens ressurser. Autorisasjon kan tildeles roller. Brukere kan tildeles roller og gjennom dette få autorisasjon til virksomhetens ressurser som er knyttet til rollen. Det kan skilles på disse to måtene å få tilgang på delte data:

  • Systemtilgang
    Brukeren har implisitt tilgang gjennom tilgang til konsumenten sitt system i domenet. Konsumentens system har tilgang til API hos tilbyder. Det er konsumenten som må sikre at brukeren har rettighet til å få tilgang til tilbyders data

  • Brukersentrisk datadeling
    Brukeren må ha eksplisitt tilgang til tilbyder sine delte data i tilbyders system i domenet. Her er det tilbyder som har kontroll over brukerens tilgang på data og kan spore brukerens bruk av disse

IAM utfører autentisering ved bruk av en autentiseringstjeneste og en identitetstilbyder, som vist i figuren under.

IAM autoriserer sluttbrukeres tilgang til tjenester. Dette er basert på både autentisering av deres identitet, det vil si hvem brukeren er, og de roller brukeren er tildelt hos en eller flere institusjoner.

API management styrer tilgang til data gjennom API basert på policy eller godkjenning fra dataforvalter. Brukers tilgang til beskyttet tjeneste hos datakonsument kan være tilstrekkelig til at bruker ikke trenger å autoriseres eksplisitt hos datatilbyder. Avgjørelsen om å godkjenne tilgang til data kan være basert på en sluttbrukers rolle hos en institusjon. ​

I UHF autorisasjon inngår autorisering og tildeling av en sikkerhetsbillett (token) ved bruk av en autorisasjonstjener og en token-tjeneste. Denne sikkerhetsbilletten brukes for å få tilgang til API eller notifikasjon hos datatilbyder.

UHF Autorisasjon er en tjeneste som samordner tildeling av sikkerhetsbilletter til datakonsumenter. Sikkerhetsbilletten gir tilgang til en ressurs hos datatilbyderen for en autentisert datakonsument. Tjenesten samordner autorisasjon gjennom verifisering av konsument i konsumentregisteret og sjekk av konsumentens roller og tilganger til API eller notifikasjon.

Ressursportalen og tjenesten for tildeling av rettigheter til datakonsumenter deltar i begge funksjoner.

3.5. Datadeling på tvers av sektorer

Det er behov for datadeling og API Management på tvers av sektorer. Høyere utdanning og forskning ønsker utstrakt bruk av nasjonale felleskomponenter, som omtalt i Digitaliseringsrundskrivet og vist i figuren over. For å oppnå dette må både sektorens og den nasjonale infrastrukturen videreutvikles.​

Føderert tilgangsstyring for datadeling på tvers av sektorer er ønskelig, og det krever blant annet standardisering av sikkerhetsbilletter (tokens) for å oppnå gjennomgående tillitskjeder. ​Det er også ønskelig at brukere kan styre samtykke til sine data fra et sted nasjonalt, inklusivt til data i kilder i høyere utdanning og forskning. Det hadde vært ønskelig om en felles Norsk samtykketjeneste kunne være integrert med funksjonalitet som vi forvente skal realiseres i IAM løsningen til høyere utdanning og forskning. Samtykke til kilder i vår sektor fra Altinn autorisasjon er en mulig fremtidig løsning.

Det er planlagt automatisert høsting av API katalogen fra høyere utdanning og forskning til Felles API-katalog som visst i figuren under.

FelleskomponenterUHF nasjonale
Figure 9. Datadeling integrert med IAM og nasjonal infrastruktur

4. Datautveksling

4.1. Delegere rettigheter til databehandler - UHF

Delegering av rettigheter til databehandler er det en konsument må gjøre for at en leverandør kan identifisere seg med sitt eget virksomhetssertifikat og opptre på vegne av konsumenten som er den som innehar behandlingsgrunnlaget for å innhente data.

Delegere rettigheter til databehandler - UHF image
Figure 10. Delegere rettigheter til databehandler - UHF

Vis detaljer om elementene i diagrammet (Tips: Shift-klikk for å åpne i nytt vindu)

4.2. Datautveksling ved oppslag

4.2.1. Datautvekslingsmønster

Synkront oppslag

Synkront oppslag er realiseringen av eOppslag. I dette mønsteret hentes data fra datakilden ved behov. Et typisk eksempel på synkront oppslag kan være uthenting av aktuelle konteringsregler fra økonomisystemet ved prevalidering av regnskap før det føres i hovedbok.

Provisjonering via synkront oppslag

Synkront oppslag kan også benyttes til provisjonering. I et slikt tilfelle hentes all informasjon det er nødvendig at blir lagret i et system fra datakilden, før det lagres. Ved provisjonering med synkront oppsalg er det ofte store mengder data i bevegelse, og overføringen tar tid. Disse egenskapene medfører at provisjonering via synkront oppslag utføres sjelden. Denne metoden blir ofte kalt batch-provisjonering.

Provisjonering via lettvekts eNotifikasjoner

I de tilfellene provisjonering via synkrone oppslag ikke kan besørge en propageringshastighet som understøtter brukerenes behov, kan lette eNotifikasjoner benyttes i kombinasjon med eOppslag. De lette eNotifikasjonene bærer informasjon om hvilke data som har endret seg i datakilden, og leveres umiddelbart til de som måtte være interessert i dataendringene. Dette tillater systemet som er avhengig av provisjonering å hente kun den informasjonen som har blitt endret.

Et typisk eksempel på bruk av dette mønsteret er visning av kontaktinformasjon i personprofiler. En professor kjøper seg ny telefon, og melder nummeret inn til sin arbeidsgiver. Telefonnummeret er reflektert i personprofilen snarlig etter registrering i HR-systemet.

Fremtidige utvidelser

Digitaliseringsdirektoratets referansearkitektur definerer to varianter av eNotifikasjon, den tidligere omtalte lettvektsvarianten, og en basert på hendelseslister.

Hendelseslister består av notifikasjoner som konsumeres via eOppslag. Notifikasjonene kan inneholde varierende mengde informasjon, og propageres ikke like hurtig som lettvektsvarianten beskrevet ovenfor. Hendelseslistene er persistente av natur (til forskjell fra lettvektsvarianten, der notifikasjonene «forsvinner» når de er konsumert), og lar sådan datakilden beskrive en historikk. Et typisk eksempel på en slik historikk kan være de forskjellige stegene i en saksbehandlingsprosess, der de forskjellige stegene må være klart definert for å kunne foreta videre steg i saksbehandlingsprosessen, eller realisere etterlevelse av juridiske krav.

I neste versjon av referansearkitekturen vil det vurderes å inkludere varianten basert på hendelseslister. Det vil også vurderes å utvide definisjonen av lettvektsnotifikasjoner slik at de kan bære konkrete data (også kalt Event Carried State Transfer), til forskjell fra eksisterende definisjon der de kun bærer en referanse til dataene som er endret.

4.2.2. eOppslag Verdistrøm med kapabiliteter for tilbyder og konsument - UHF

eOppslag Verdistrøm med kapabiliteter for tilbyder og konsument - UHF   image
Figure 11. eOppslag Verdistrøm med kapabiliteter for tilbyder og konsument - UHF

Vis detaljer om elementene i diagrammet (Tips: Shift-klikk for å åpne i nytt vindu)

4.2.3. Publiser API

En prosessflyt som datatilbyder må gjennomføre for å gjøre et API synlig og tilgjengelig gjennom kataloger og søkeløsninger. Metadata om APIet blir registrert i API-katalogen. Metadata inkluderer begreper og datamodeller omfattet av datasettet som APIet tilgjengeliggjør, samt tilganger (scopes) knyttet til APIet som kan tildeles konsumenter.

APIet registrert i UHF API katalog blir høstet inn i Felles API katalog. Vi ønsker at tilganger (scopes) i tillegg skal registreres i Maskinporten slik at konsumenter utenfor UHF sektoren kan oppdage APIet og be om tilgang på et senere tidspunkt.

Publiser API image
Figure 12. Publiser API

Vis detaljer om elementene i diagrammet (Tips: Shift-klikk for å åpne i nytt vindu)

4.2.4. Tilgjengeliggjøre data etter forsepørsel løsningsmønster UHF

En prosessflyt som datatilbyder må gjennomføre for å tildele rettigheter til en konsument som ber om tilgang til data. En datatilbyder mottar forespørsel om tilgang til et API på vegne av en organisasjon eller bruker. Dataeieren tar stilling til om konsumenten skal få tilgang til data gjennom APIet. Tilgang registreres knyttet til konsumentens klient (applikasjonen som benytter APIet) i klientregisteret.

Tilgjengeliggjøre data etter forsepørsel løsningsmønster UHF image
Figure 13. Tilgjengeliggjøre data etter forsepørsel løsningsmønster UHF

Vis detaljer om elementene i diagrammet (Tips: Shift-klikk for å åpne i nytt vindu)

4.2.5. Få tilgang til data - løsningsmønster UHF

En prosessflyt en konsument av data må gjennomføre for å få tildelt rettigheter til data gjennom et API. Det omfatter å få kjennskap til aktuelt API gjennom API-katalogen, autentisere konsumenten, inngå avtale om bruk av data, samt å registrere tilganger hos den tekniske komponenten som skal utføre tjenestekallet. Dersom det dreier seg om tilgang til et åpent tilgjengelig API, kan enkelte delaktiviteter i prosessene hoppes over, men for å kunne logge informasjon om bruk av APIer bør alle konsumenter av et API registreres i klientregisteret.

Viewet bør strengt tatt vise at konsumenten kan finne APIet enten i UHF sektorens API katalog eller i Felles datakatalog. Vi velger å vise prosessflyten kun med UHF sektorens komponenter både for å kunne presentere en oversiktlig prosessflyt og fordi forholdet til de nasjonale felleskomponenter er ennå ikke helt avklart.

Få tilgang til data - løsningsmønster UHF image
Figure 14. Få tilgang til data - løsningsmønster UHF

Vis detaljer om elementene i diagrammet (Tips: Shift-klikk for å åpne i nytt vindu)

4.2.6. Innhente data - løsningsmønster UHF

En prosessflyt en konsument utfører når det utføres et tjenestekall for å innhente data gjennom et API. API-adressen hentes i API-katalogen. Tilgang til APIet byttes inn mot et kjøretids-token i autoriseringstjenesten. Tjenestekall til APIet utføres gjennom API gateway der tokenet benyttes for å få tilgang. Dersom det er et åpent API er det kun relevante prossessteg som utføres.

Innhente data - løsningsmønster UHF image
Figure 15. Innhente data - løsningsmønster UHF

Vis detaljer om elementene i diagrammet (Tips: Shift-klikk for å åpne i nytt vindu)

4.2.7. Avgi data - løsningsmønster UHF

En prosessflyt en tilbyder av data utfører for å svare på en dataforespørsel. Tilbyder mottar forespørsel om oppslag med et aksesstoken. Klienten som forespør autentiseres og token valideres. Eventuelt mer fin-granulert tilgangskontroll utføres og data returneres. Tilgang kontrolleres kun dersom det er snakk om et sikret API.

Avgi data - løsningsmønster UHF image
Figure 16. Avgi data - løsningsmønster UHF

Vis detaljer om elementene i diagrammet (Tips: Shift-klikk for å åpne i nytt vindu)

4.3. Datautveksling ved publisering – konsumering (hendelsesbasert)

Datautveksling ved publisering og konsumering av hendelser er basert på publisering-konsumering i Referansearkitektur for datautveksling fra Digitaliseringsdirektoratet.

4.3.1. Publisering av hendelser - basiskonsept UHF

Hendelsestrømmer kan implementeres som Hendelseslister eller en Publisert meldingskø (publiser/abonner)

Publisering av hendelser - basiskonsept UHF image
Figure 17. Publisering av hendelser - basiskonsept UHF

Vis detaljer om elementene i diagrammet (Tips: Shift-klikk for å åpne i nytt vindu)

4.3.2. eNotifikasjon - oversikt over verdistrømmer UHF

Den overordnede verdistrømmen vist under skisserer handlingene hos datatilbyder og datakonsument som inngår i dette utvekslingsmønsteret. Datatilbyderen oppretter en hendelsesstrøm som datakonsumenten oppdager og abonnerer på. Datatilbyderen publiserer notifikasjoner om hendelser i hendelsesstrømmen, og datakonsumenten innhenter disse. Når konsumenten har mottatt en notifikasjon, vurderer konsumenten om det er behov for å innhente mer informasjon om hendelsen. I så fall benytter konsumenten synkront oppslag som beskrevet tidligere for innhentingen.

notifikasjon verdistrøm
Figure 18. eNotifikasjon verdistrøm

4.3.3. Grunnleggende begreper for publisering av hendelser - Hendelsesliste og Publiser og Abonner UHF

Notifikasjoner blir publisert enten i form av en hendelsesliste eller i form av en publisering i form av publisering/abonnering til en publisert meldingskø

Grunnleggende begreper for publisering av hendelser - Hendelsesliste og Publiser og Abonner UHF image
Figure 19. Grunnleggende begreper for publisering av hendelser - Hendelsesliste og Publiser og Abonner UHF

Vis detaljer om elementene i diagrammet (Tips: Shift-klikk for å åpne i nytt vindu)

4.3.4. Notifikasjonsinnhold - basiskonsept UHF

Som et minimum må en notifikasjon inneholde en identifikator. Anbefalt innhold er basert på standarden CloudEvents (se Utvikling av ytre API i dette dokumentet)

Notifikasjonsinnhold - basiskonsept UHF image
Figure 20. Notifikasjonsinnhold - basiskonsept UHF

Vis detaljer om elementene i diagrammet (Tips: Shift-klikk for å åpne i nytt vindu)

4.3.5. Inngå avtaler om tilgang og levering av hendelsesstrømmer - Publiser og Abonner UHF

Datatibyder mottar forespørsel om å inngå avtale om tilgang og innhenting av hendelsesstrømmer Hendelsesstrømmen kan være i form av en hendelsesliste eller abonnement på et emne (publisert meldingskø)

Inngå avtaler om tilgang og levering av hendelsesstrømmer - Publiser og Abonner UHF  image
Figure 21. Inngå avtaler om tilgang og levering av hendelsesstrømmer - Publiser og Abonner UHF

Vis detaljer om elementene i diagrammet (Tips: Shift-klikk for å åpne i nytt vindu)

4.3.6. Inngå avtaler om tilgang og innhenting av hendelsesstrømmer - Hendelsesliste og Publiser og Abonner UHF

Datakonsument inngår avtale om tilgang og innhenting av hendelsesstrømmer Hendelsesstrømmen kan være i form av en hendelsesliste eller abonnement på et emne (publisert meldingskø)

Inngå avtaler om tilgang og innhenting av hendelsesstrømmer - Hendelsesliste og Publiser og Abonner UHF image
Figure 22. Inngå avtaler om tilgang og innhenting av hendelsesstrømmer - Hendelsesliste og Publiser og Abonner UHF

Vis detaljer om elementene i diagrammet (Tips: Shift-klikk for å åpne i nytt vindu)

4.3.7. Generere og publisere notifikasjoner - Publiser og Abonner UHF

Datatilbyder publiserer en notifikasjon til en Notifikasjonsdistubusjon i form av en publisering/abonneringsløsning

Generere og publisere notifikasjoner - Publiser og Abonner UHF  image
Figure 23. Generere og publisere notifikasjoner - Publiser og Abonner UHF

Vis detaljer om elementene i diagrammet (Tips: Shift-klikk for å åpne i nytt vindu)

4.3.8. Konsumer notifikasjoner - Publiser og Abonner UHF

Datakonsumentlytter på emner som konsumenten abonnerer på hos Datatilbyder. Når en ny melding kommer i meldingskøen trigges konsumsjonen av notifikasjonen. Datakonsumenten vurderer relevans og foretar videre behandling av notifikasjon

Videre behandling består av å gjøre et eOppslag (via API) som beskrevet i "Løsningsmønster forespørsel UHF"

Konsumer notifikasjoner - Publiser og Abonner UHF image
Figure 24. Konsumer notifikasjoner - Publiser og Abonner UHF

Vis detaljer om elementene i diagrammet (Tips: Shift-klikk for å åpne i nytt vindu)

4.4. Oppdatering

Datatilbyder kan gjøre oppdatering av data tilgjengelig for datakonsument gjennom et API. Prosessen for en datakonsument å be om tilgang til oppdatering (se Få tilgang til data) og for en datatilbyder å gi tilgang til oppdatering (se Tilgjengeliggjøre data etter forespørsel) er tilsvarende som for tilgang til å lese data. Det vil ofte være forskjellige kriterier som må oppfylles for å få lov til å oppdatere data enn for å lese data. Dette kan inkludere både kvalitetssikring og juridiske hensyn.

4.4.1. Be om oppdatering - løsningsmønster i UHF sektoren

En prosessflyt en konsument utfører når det utføres et tjenestekall for å innhente data gjennom et API. API-adressen hentes i API-katalogen. Tilgang til APIet byttes inn mot et kjøretids-token i autoriseringstjenesten. Tjenestekall til APIet utføres gjennom API gateway der tokenet benyttes for å få tilgang. Dersom det er et åpent API er det kun relevante prossessteg som utføres.

Be om oppdatering  - løsningsmønster i UHF sektoren  image
Figure 25. Be om oppdatering - løsningsmønster i UHF sektoren

Vis detaljer om elementene i diagrammet (Tips: Shift-klikk for å åpne i nytt vindu)

4.4.2. Håndtere forespørsel om oppdatering - løsningsmønster UHF

En prosessflyt en tilbyder av data utfører for å svare på en dataforespørsel. Tilbyder mottar forespørsel om oppslag med et aksesstoken. Klienten som forespør autentiseres og token valideres. Eventuelt mer fin-granulert tilgangskontroll utføres og data returneres. Tilgang kontrolleres kun dersom det er snakk om et sikret API.

Håndtere forespørsel om oppdatering  - løsningsmønster UHF  image
Figure 26. Håndtere forespørsel om oppdatering - løsningsmønster UHF

Vis detaljer om elementene i diagrammet (Tips: Shift-klikk for å åpne i nytt vindu)

5. Rutiner

Vi forutsetter og bygger på en viss fremgang i arbeid med orden i eget hus hos deltagende virksomheter der noen datasett er dokumentert i en datakatalog. Dette kan enten være Digitaliseringsdirektoratets felles datakatalog, eller en fremtidig katalog for høyere utdanning og forskningssektoren som høstes inn i felles datakatalogen.

Vi skisserer en tilnærming til indre og ytre API basert på Gartners MASA arkitektur[7] som var brukt i evalueringen av Felles Studentsystem i 2020

5.1. Indre API

Indre API eksponerer masterdata (informasjon om objekter i domenet) som er strukturert i henhold til semantikk i domenet den tilhører, og må ta ansvar for den semantiske validiteten til data den eksponerer. Indre API er laget for å være mest mulig generell og ikke laget for noen spesifikk prosesskontekst.

[Vi tenker å utdype her på et senere tidspunkt.]

5.2. Ytre API

Ytre API benyttes i en forretningsprosesskontekst og datasett eksponert gjennom en ytre API er laget for å møte behovene til prosessen. Ytre API kan benyttes i både grunnleggende og bruksnære domener. En tilnærming til definisjon av APIer og datasett for prosesstøtte er beskrevet under.

  1. Melde behov, gjerne av datakonsumentene

    1. Tjenesteansvarlig kjører periodisk prosess for å samle innspill og prioritere

    2. Vurder å kjøre tjenestedesign workshop for å beskrive bruksscenariene

  2. Analysere behov og finne ut hvilke domener, kilder og datasett som er involvert

    1. Tjenesteansvarlig identifiserer berørte interessenter, potensielt andre tjenesteansvarlige, dataforvalter, domeneansvarlig og begrepsansvarlig

    2. Tjenesteansvarlig må vurdere og eventuelt sette i gang juridiske avklaringer omkring deling av data

  3. Kjør begrepsharmonisering etter behov med relevante interessenter

  4. Publiser nye eller oppdaterte begreper i felles begrepskatalog

  5. Identifiser hva må skapes, harmoniseres eller videreutvikles. Pass på at funksjonaliteten spesifisert i grensesnittet dekker kun det som trengs for å støtte brukstilfellet under utvikling.

  6. Sikre at data i alle steg i verdikjeden passer til den tenkte anvendelsen.

  7. Definere API/datasett i team med representasjon fra både bruksmiljø og produsent. Det kan ta noen iterasjoner med utprøving av API før man er fornøyd. Senere oppdateringer kan kjøres som iterasjoner da man allerede har resultatene fra tidligere steg.

    1. Designe nødvendig API for brukskonteksten.

    2. Mappe nødvendig funksjonalitet til API fra grunnleggende domener.

    3. Designe «API mediation», det vil si hvordan datasettet spesifisert i det ytre APIet tilgjengeliggjøres. Oppgaven inkluderer mapping til indre API som benyttes med nødvendig oversetting av protokoller, formater og datastrukturer, samt etterlevelse av policy for sikkerhet og volumbegrensninger.

    4. Implementere tjenestene

    5. Koordinere mellom APIene for å sikre sammenhengende brukeropplevelse mellom APIene

    6. Publisere APIene og datasett i UHF API katalog (eventuelt felles datakatalog) i henhold til DCAT-AP-NO

5.3. Notifikasjoner

Når en hendelse endrer data hos en datatilbyder, og disse data er deles gjennom datadeling med notifikasjon, skal det sendes en notifikasjon til datakonsument.
Notifikasjoner omhandler hvilke data i det tilhørende API som er endret.

For å utvikle notifikasjoner følges tilsvarende prosess som for API over. Det vil si at notifikasjoner, som beskrevet i denne referansearkitekturen, er knyttet til API der datakonsumenten henter ut data. Det vesentlige av beskrivelse for datautvekslingen ligger derfor til utviklingen av API som hører sammen med notifikasjonen.

Spesielt for notifikasjoner gjelder følgende:

  1. Notifikasjonen skal gi en meningsfull indikasjon på hvilke data som er endret i form av identifikator (nøkkelinformasjon)

  2. Notifikasjonen skal inneholde en referanse til ressursen (i APIet) der data kan hentes fra

  3. Etterstreb å modellere notifikasjoner etter etablerte standarder

  4. Sørg for at meningen notifikasjonene bærer er godt dokumentert i notifikasjonskatalogen

  5. Ressursen, det vil si det API som er knyttet til notifikasjonen, må være utformet slik at uthenting av data alltid gir siste gyldige versjon. På den måten vil innhenting hos datakonsument kunne være idempotent

Med «idempotent» er det i denne sammenheng ment at man kan kalle på den samme ressursen flere ganger og alltid få samme resultat.

Per i dag er CloudEvents den eneste generaliserte standarden for hvordan notifikasjoner bør utformes. Referansearkitekturen anbefaler at CloudEvents tas i bruk som standardformat for notifikasjoner. CloudEvents er utviklet i regi av Cloud Native Computing Foundation.

En notifikasjon utformet etter minstekravene til CloudEvents med JSON Event Format ser typisk ut:

\{"id": "935ec740-d4a4-418d-b6c3-282d6fd2305b",

"specversion": "1.0",

"time": "2020-11-19T17:30:41.244Z",

"source": "urn:no-edu-orgreg:ntnu:ou:1260",

"type": "orgreg.v1.ntnu.dev.ou.create"}

I eksempelet på en notifikasjon ovenfor meddeles det at det har blitt opprettet en organisatorisk enhet ved NTNU med identifikatoren 1260.

Bruk av et felles notifikasjonsformat tilrettelegger for gjenbruk av komponenter på tvers av tjenester da en notifikasjon er velstrukturert og de informasjonsbærende elementer er strengt definert. I de tilfeller det er nødvendig å inkludere informasjonsbærende elementer som ikke er inkludert i standarden, er standarden mulig å utvide. Standarden legger også til rette for en rekke operasjonelle kapabiliteter (eksempelvis deduplisering) gjennom informasjonselementene som er påkrevet i standarden.

6. Roller og ansvar for informasjonsforvaltning

Digitaliseringsdirektoratet har definert rollene til datatilbydere og datakonsumenter. Forventning til datatilbydere og datakonsumenter og også beskrevet i Nasjonal verktøykasse for deling av data. Vi anbefaler at disser ressursene brukes, samtidig som vi definerer mer fingranulerte roller.

Rollene spesifisert under er for både datatilbydere i IT-tjenesteorganisasjoner og for informasjonsforvaltning i domenene de støtter.

Vi hadde ønsket å definere rollen «dataeier» men opplevde juridisk uklarhet i dataeierskap, særlig når det gjaldt data om studenter i en livslang læringskontekst. Denne rollen må derfor defineres senere. Følgende roller er definert under.

Roller hos datatilbydere:

  • Tjenesteeier

  • Tjenesteansvarlig

  • Dataforvalter

Roller relatert til informasjonsdomener:

  • Behandlingsansvarlig

  • Domeneansvarlig

  • Begrepseier

Koordinerende aktør for hele Kunnskapsdepartementets sektor (Unit)

Rolle: Tjenesteeier

Beskrivelse av rollen:

Tjenesteeier er den organisasjon/virksomhet/enhet som eier en tjeneste.

Tjenesteeier vil i de fleste tilfellene være en eller flere ledere av de fagavdelingene som benytter seg av løsningens funksjonalitet og som oppnår gevinster ved å benytte tjenesten.

Ansvars-områder og oppgaver:

Er ansvarlig for at tjenestens data/masterdata deles iht. Referansearkitektur (dvs. generiske grensesnitt og notifikasjoner, eksempel IntArk).

Er ansvarlig for at tjenestenivå (fullstendig sett av krav til tjenesten med tilhørende beskrivelser: eks. omfang, volum, hyppighet, varighet, rapportering) er definert i henhold til brukeres behov, at det inneholder kvalitetssikret faglig innhold og at brukerne får faglig støtte.

Er ansvarlig for at tjenesten følger gjeldende lover og regler, har myndighet til å foreta finansielle beslutninger og signere avtaler.

Er ansvarlig for at det er utpekt en tjenesteansvarlig for tjenesten.

Typiske roller/stillinger som rollen skal samarbeide med:

Tjenesteansvarlig, behandlingsansvarlig, domeneansvarlig

Rolle: Tjenesteansvarlig

Beskrivelse av rollen:

Rollen har et helhetlig ansvar for å hente inn og bidra til prioritering av ønsker og behov som en kunde eller konsortium har til tjenesten.

Tjenesteansvarlig er operativt ansvarlig og har detaljert kunnskap om behov og praktisk bruk av tjenesten. Han/hun jobber i tett samarbeid med brukere/brukerrepresentanter. Tjenesteansvarlig og tjenesteeier kan være samme person for mindre/enklere tjenester.

Ansvars-områder og oppgaver:

Budsjett- og resultatansvar i forvaltning og utvikling av tjenesten

  • Etablere og oppdatere betalingsmodell for tjenesten​.

  • Bidra til veikart for tjenesteområdet​

  • Årsbudsjett, kostnadsvarsel og fakturering

  • Løpende økonomioppfølging og –rapportering, håndtering av avvik ​

Koordinere beslutningsprosess for tjenesten

  • Bidra til styring og medvirkning i tjenesteråd​

  • Bidra til veikart for tjenesteområdet​

  • Årlig leveranseplan for tjenesten

  • Bidra til porteføljeforvaltning gjennom statistikk, rapportering, vurderinger​

  • Gjøre løpende livsløps- og utviklingsvurderinger for tjenesten

Brukermedvirkning i utvikling og forvaltning av tjenesten

  • Være en ledende aktør i videreutvikling a tjenesten ved å formidle tekniske løsningsmuligheter som er i trå med eksisterende standarder, best practices og referansearkitekturen

  • Sørge for at eventuelle avvik/forbedringer i forhold til referansearkitekturen meldes tilbake til forvaltningsorganet for referansearkitekturen

  • Sikre kundemedvirkning gjennom konsortiestyre/arbeidsutvalg/andre fora​

  • Sikre brukermedvirkning gjennom testing, undersøkelser, andre metoder​

  • Bidra til gevinstrealisering hos brukerinstitusjonene

Kundeoversikt, kundeoppfølging og avtaleforvaltning

  • Merkantil/administrativ kontakt med kunder og brukere (eksisterende og nye)​

  • Sørge for oppdatert avtaleverk rundt tjenesten, inkl. databehandleravtaler​

  • Avtaleoppfølging mot brukerinstitusjoner og underleverandører/leverandører​

  • Sørge for tilstrekkelig dokumentasjon, brukerstøtte og opplæring

Kvalitet og sikkerhet

  • Sørge for at utvikling av tjenesten skjær iht. referansearkitekturen og evt. andre (for eks. institusjonelle eller sektorielle) retningslinjer som gjelder.

  • Sørge for oppdatert dokumentasjon om tjenesten, internt og eksternt

  • Sørge for nødvendige sikkerhets- og risikovurderinger rundt tjenesten (minimum ROS-analyse)

  • Brukerstøtte og opplæring

  • Oppfølging av evt. eksterne leverandører

  • Sørge for relevante SLAer og tjenestenivåavtaler for tjenesten

  • Sørge for overvåking, varsling og oppfølging av avvik

  • Sørge for måling, analyse og oppfølging av relevante måleparametere

  • Gjøre løpende vurderinger av behov og tiltak for tjenesten

Tjenesteansvarlig omfatter Databehandler roller som beskrevet hos Datatilsynet[8]. Denne rollen har ansvar for behandling av personopplysninger på vegne av den behandlingsansvarlige.

Typiske roller/stillinger som rollen skal samarbeide med:

Tjenesteeier, Datakonsument, Begrepseier, Domeneansvarlig, Dataforvalter.

Rolle: Dataforvalter

Beskrivelse av rollen:

Den som har overordnet ansvar hos en datatilbyder for å administrere informasjon/data som skal deles (evt. kan ansvaret/rollen fordeles videre per grunnleggende domener innenfor datatilbyder organisasjonen).

Ansvars-områder og oppgaver:

Leveranse og forvalting av data. Datakvalitet, sikkerhet, tilgjengelighet (inkl. lisensiering hvor det er hensiktsmessig)

Motta, registrere, endre og fjerne forekomster.

Sikre at bruk av data som eies av tredjepart samsvarer med vilkårene som gis.

Overholde krav i arkivloven når det gjelder kassasjon.

Rådgivning og bistand i spørsmål vedrørende bruk av data (som angår begrepsdefinisjoner og juridiske føringer).

Kommunikasjon med alle interessenter

Oppgaver:

  • Innhente data

  • Kvalitetssikre data

  • Bearbeide, berike data

  • Lagre data

  • Rettighetsklarering av data

Typiske roller/stillinger som rollen skal samarbeide med:

Begrepseier, Domeneansvarlig, Behandlingsansvarlig, Tjenesteansvarlig

Rolle: Behandlingsansvarlig

Beskrivelse av rollen:

Behandlingsansvarlig er en fysisk eller juridisk person, en offentlig myndighet, en institusjon eller ethvert annet organ som alene eller sammen med andre bestemmer formålet med behandlingen av personopplysninger og hvilke midler som skal benyttes;

Ansvars-områder og oppgaver:

Uttømmende informasjon om rollen finnes hos Datatilsynet (behandlingsansvarlig) [9].

Typiske roller/stillinger som rollen skal samarbeide med:

Tjenesteeier, Tjenesteansvarlig, Dataforvalter, Begrepseier, Domeneansvarlig.

Rolle: Domeneansvarlig

Beskrivelse av rollen:

Har ansvar for aktiviteter og tiltak innen domenet for å sikre riktig kvalitet, utnytting og sikring av informasjon i domenet.

Ansvars-områder og oppgaver:

Være prosessdriver for informasjonsforvaltning

Følge med at begrepene blir utarbeidet etter retningslinjer i domenet.

Passe på at forvaltningsprosessen blir fulgt og at begrepene har riktig status i forhold til begrepsforvaltningsprosessen.

Ha oversikt over helheten og bidra til koordinering, harmonisering og godkjenning av innhold, inklusiv samordning av konsumenter med sammenfallende behov og eksisterende begreper i begrepskatalogen.

Publisering av begreper i felles begrepskatalog (data.norge.no)

Drive opplæring knyttet til forvaltning av informasjon i domenet.

Typiske roller/stillinger som rollen skal samarbeide med:

Begrepseier, Datakonsument, Tjenesteansvarlig

Rolle: Begrepseier

Beskrivelse av rollen:

Rollen som har det faglige ansvaret for et begreps innhold.

Ansvars-områder og oppgaver:

Sørge for at begrepene blir definert i henhold til retningslinjene i rammeverket.

Involvere eventuelle interessenter i definisjonsarbeidet

Sørge for at begrepene er vurdert i henhold til eksisterende begrepsdefinisjoner i domenet og i felles begrepskatalogen (data.norge.no).

Typiske roller/stillinger som rollen skal samarbeide med:

Dataforvalter, Datakonsument, Domeneansvarlig, Tjenesteansvarlig

Rolle: Koordinerende aktør

Beskrivelse av rollen:

Ansvar for koordinering og samhandling på tvers av alle dataprodusenter organisert under Kunnskapsdepartementet. Ansvaret inkluderer en infrastruktur for publisering og gjenfinning av datasett for analyseformål samt analyse av kunnskapsdata i sikre analyserom.

Ansvars-områder og oppgaver:

Prosessarbeid

  • Sikre en helhetlig forvaltning av data i kunnskapssektoren

  • Tydeliggjøre roller og ansvar i forvaltningen av sektorens data

  • Koordinere prosesser knyttet til harmonisering av data (med beslutningsmyndighet når nødvendig)

  • Retningslinjer for klassifisering av data

  • Følge/støtte opp dataprodusentenes arbeid med «orden i eget hus» og deling av data.

Tjenesteansvar

  • Etablere og forvalte en felles metadatakatalog for alle data i kunnskapssektoren for viderebruk

  • Felles søknadstjeneste ved behov for tilgang til data med begrenset offentlighet, på tvers av dataprodusentene som gir økt grad av selvbetjening

  • Eksplorative tjenester som gjør det enkelt å utforske analysepotensialet som ligger i dataene

  • Gi tilgang til sikre analyserom for analyser av data med begrenset offentlighet

Etablere et rådgivende forum for juridiske avklaringer knyttet til deling og utlevering av data

Typiske roller/stillinger som rollen skal samarbeide med:

Domeneansvarlig, Begrepseier, Dataforvalter, Tjenesteeier og Tjenesteansvarlig

7. Vedlegg A; Definisjoner

Datakvalitet innebærer at data skal være korrekte, komplette, oppdaterte og konsistente og har evnen til å støtte de informasjonsformål de brukes til [kilde: data.norge.no, SKATTEETATEN]

Masterdata: Autoritative data for gitte opplysningstyper. [kilde: data.norge.no, NAV]

Grunndata: Basisinformasjon innen en gitt sektor. [kilde: data.norge.no, NAV]

8. Vedlegg B; Behov for avklaringer og utfordringer i sektorens kontekst

8.1. Issues mot nasjonale felleskompontenter (Maskinporten, ID Porten og Altinn autorisasjon)

  1. Harmonisering av autorisasjon

    1. Det er ønskelig at UHF autorisasjonstjener og Maskinporten godkjenner hverandres tokens. Dette forutsetter at informasjonsmodellen benyttet i tokens er felles. Løsningsvarianter:

      1. Klienter forholder seg til flere autentiseringstjenere og standardisere token struktur

      2. Innbytte av tokens (token exchange) fra andre “trusted” autorisasjonstjenere. En konsekvens av dette er at man mister (?) koblingen til bruker og dermed kjennskap til autentiseringsstyrken som ligger bak.

      3. Software Statement Assertion (https://tools.ietf.org/html/rfc7521 – løsning benyttet av Open Banking UK

  2. Harmonisering av samtykke

    1. Altinn autorisasjon benytter «Self-contained OAuth2 token» for samtykke. Men da vi ikke kan godkjenne tokens på tvers, har vi utfordringer med å benytte Altinn autorisasjon direkte. I hvert fall dekker det ikke skopes vi har anvar for i UHF autorisasjonstjeneren

    2. Hjelper User Managed Access (UMA) her?

  3. Delegering av rettigheter (fullmakt??): Altinn har per i dag ingen god mekanisme for å delegere rettigheter under organisasjonsgranulariteten i Enhetsregisteret. Vi tror ikke dette er et problem siden vi forventer at IGA innenfor UHF sektoren vil dekke våre behov.

8.2. Issues internt i UHF sektor

  1. Klientregister inneholder den samme klientoversikten i IAM og i datadeling. Hvordan den totale oversikten skal vedlikeholdes må defineres. Skal det være repliserte, konsistente registre? Skal det være disjunkte subsett?

  2. Tilgang til API-er kan ha basis i roller (da er man vel virkelig i overlapp med IGA)

  3. Dersom forskjellige autorisasjonstjenere ikke kan dele tokens, har vi vel også det samme problemet vi har mot de nasjonale fellestjenestene at den ene domenen ikke kan forholde seg til tokens fra den andre domenen.

  4. Sektoren har tre uavhengige SSO løsninger: IDporten, Feide og Azure AD. Dette gir både redusert brukervennlighet, og en sikkerhetsutfordring dersom man ikke kan garantere for at det er samme person i de ulike SSO dokenene.

9. Vedlegg C; Muliggjørende økosystem

Før oppstart av Datadelingsprosjektet fasiliterte UNIT en tjenestedesign prosess rettet mot behovene til IT-støtte fra studenter, forskere, lærere og ledere. I tillegg kartla prosessen behovene til tjenesteleverandører, både interne og eksterne, som ønsker å tilby tjenester til sektoren. Resultatene fra prosessen ble benyttet som brukstilfeller i datadelingsprosjektet for å forstå krav til deling av data. Prosessen definerte et Muliggjørende økosystem som målbilde.

muliggjørende økosystem
Figure 27. Muliggjørende Økosystem i høyere utdanning og forskning

Økosystemet er definert som en modell for samspill og innovasjon der komplementære aktører tilbyr tjenester og ressurser til studenter, lærere, forskere og ledere.  Data som sektoren har tilbys til nye anvendelser «inside-out» samtidig som forståelse av behovene til aktørene leder til utvikling av tiltak i økosystemet «outside-in». Økosystemet er avhengig av tillit skapt gjennom kravstilling til aktørene som samarbeider om deling og gjenbruk av data, harmonisering av begreper benyttet på tvers og utvikling av nye tjenester. Kravene skal sikre tilgang til data av hensiktsmessig kvalitet for de som har rett til det på en måte som ivaretar sikkerhet og personvern. Kravene skal også fremme innovasjon gjennom standardisering “på de rette stedene” som for eksempel en nasjonal profil for aktivitetsdata brukt i læringsanalyse og rettferdig markedstilgang. Økosystemet skal utvikles for å støtte sektorens bruksscenarier, som for eksempel individuelt tilpasset læring i et livslangt perspektiv og forbedret, digitalisert administrativt forskningsstøtte. Økosystemet må samtidig fremme god samhandling juridisk, organisatorisk, semantisk og teknisk.

Økosystemets innhold er:

  • Infrastruktur

  • Data og tjenester

  • Krav og føringer

  • Insentiver og betalingsmodeller

  • Harmonisering

Økosystemets nytte er:

  • Tillitsbasert samhandling

  • Enkel, trygg og riktig tilgang til nødvendige digitale ressurser

  • Endringsevne og innovasjon

  • Effektivitet

10. Vedlegg D; Behov og bruksområder

10.1. Forskning og læring

Det er behov for å videreutvikle datadeling for læring og forskning. I henhold til utkast til ny digitaliseringsstrategi[10] skal studenter tilbys fleksible og studentaktive undervisningsformer. Eierskap til egne data ligger hos den enkelte, lett tilgjengelig gjennom hele livet. Dette krever endringer i informasjonsforvaltningspraksis. Praksisen må kunne støtte læringsprosessen på en måte som gir studenten mulighet til å utnytte egne data for best mulig læring.

Forskning må gjøre tilgang til resultater og data lettere. Forskningsgrupper som kan inkludere deltagere fra Norske institusjoner, utenlandske institusjoner og næringslivet skal ha enkel tilgang til data når de har rett til det.

For å være smidig og effektive må virksomhetsprosesser som understøtter læring og forskning enkelt kunne gjenbruke dataressurser nasjonalt. Disse dataressurser inkluderer læringsressurser, undervisningsressurser, datasett og forskingspublikasjoner.

Når dataressurser er lett tilgjengelig, kan sektoren oppnå mer brukernær innovasjon.
Det innebærer at blant annet studenter, lokale IT-avdelinger og Ed Tech leverandører, gis mulighet til å bygge lettvekts brukerapplikasjoner gjennom tilgang til data.
Dette kan være både fra de tunge tjenestene og mer smale tjenester som timeplan-/bookingsystem, posisjonsdata, etc. Smart Campus (Uninett) er et eksempel på et slikt konsept.

10.2. Administrative prosesser

Behovene til datadeling i høyere utdanning og forskning forsterkes av at det er identifisert store, akutte behov knyttet til deling av data mellom administrative tjenester.

Kjerneprosessene hos institusjonene må støttes med administrative data, slik at personer og organisasjoner får støtte for saksbehandling og annen nødvendig drift av organisasjonene. Dette gjelder særlig de store prosjektene i BOTT-regi for etablering av fellesløsninger på økonomi og lønn (BOTT:ØL) og saksbehandling og arkiv (BOTT:SA) og et felles identitets- og tilgangsstyring (IAM). Disse skal dekke helt sentrale arbeidsprosesser i sektoren.

Saksbehandlingsstøtte innen forskningsfinansiering kan også automatiseres ved hjelp av tjenestekjeder i datadelingsplattformen.

10.3. Gjenbruk og viderebruk av data

For å gi fleksibel og effektiv støtte for behovene over skal data som benyttes i virksomhetens sentrale prosesser plasseres i kilder som er modulære og kan kobles til de prosesser som trenger de.

Disse kilder defineres som «masterdatakilder» og de inneholder informasjon om blant annet studenter, ansatte, organisasjoner, emner, forskningsprosjekter, og vitenskapelige resultater.

Data fra disse kildene blir gjenbrukt i de ulike arbeidsprosesser som har behov for dem. I tillegg til de mest sentrale virksomhetsprosesser, blir data fra masterdatakilder også brukt på nye måter (viderebrukt). Disse kan være spesifikke for enkeltbrukere, som for eksempel evaluering av et emne.

10.4. Datakonsumenter

I tillegg til behov knyttet til funksjonsområdene læring, forskning og administrasjon er det behov knyttet til utvidelse av hvem man har tenkt å dele data med.

Målsetningen i første fase av UH:IntArk har vært deling av virksomhetsinterne data i interne forretningsprosesser, herunder også deling av disse med tjenester som ligger på utsiden av virksomheten og som understøtter virksomhetens forretningsprosesser. Eksempler på slike tjenester er økonomi- og lønnstjenester, sak og arkiv, og så videre.

Det som kjennetegner dataflyten i denne dimensjonen, er at dataene betraktes som virksomhetsinterne og ikke ønskes delt til 3. part ut over spesifikke forretningstjenester på utsiden av virksomheten.

Denne referansearkitekturen omfatter også deling av data til 3. part, det vil si at dataene skal eksponeres på utsiden av virksomheten. Slike data omfattes av orden i eget hus og skal i henhold til digitaliseringsrundskrivet beskrives i

  • en felles datakatalog

  • en felles API-katalog

  • en felles begrepskatalog,

Disse skal ligge i Digdirs Felles datakatalog (data.norge.no).

Per februar 2021 tilbyr ikke Digdir noen felles autorisasjonstjeneste knyttet til API som er beskrevet i API-katalogen.

Det betyr at autorisasjon må håndteres, i ytterste konsekvens, av den enkelte API-eier. Referansearkitekturen beskrevet her tar høyde for at dette kan håndteres som en fellestjeneste i høyere utdanning og forskning.

10.5. Overordnede behov

De viktigste overordnede behovene adressert i referansearkitekturen for datadeling i høyere utdanning og forskning er:

  • Sikre at UHF følger arkitekturprinsippene nedfelt i nasjonal referansearkitektur for datautveksling[11]

  • Sikre at sektoren har en enhetlig og sikker måte for å håndtere tilganger til sektorens data gjennom kravstilling utrykt i referansearkitekturen

  • Sikre at referansearkitekturen utnytter/samhandler med nasjonale felleskomponenter der disse kan dekke sektorens behov på en tilfredsstillende måte, jamfør Digitaliseringsrundskrivet 2020, kap. 1.5 Bruk nasjonale felleskomponenter og fellesløsninger3

  • Sikre effektiv datautveksling mellom virksomheter i UHF og med andre sektorer

  • Sikre at data som sektorens virksomheter eksponerer utad, er beskrevet på en måte som gjøre det enkelt for konsumenter å få kjennskap til hvilke data som er tilgjengelig, hva de beskriver (ved hjelp av begreper som er beskrevet og harmonisert), kriterier for tilgang til bruk av dataene og beskrivelse av API som benyttes for å aksessere dataene

  • Sikre tilstrekkelig kvalitet i data som er delt gjennom felles forvaltningsroller og -prosedyrer

  • Sikre at API, datasett og hendelser tilgjengeliggjort defineres i henhold til konsumentenes behov gjennom prosedyrer for samspill mellom datakonsument og datatilbyder

  • Sikre forvaltning og videreutvikling av API, datasett og hendelsesnotifikasjoner på en måte som både sikrer drift og muliggjør innovasjon (lifecycle management)

10.6. Bruksområder for datadeling

Datadeling skal støtte virksomhetene innen høyere utdanning og forskning i sine oppgaver. Arbeid med referansearkitekturen tar derfor utgangspunkt i følgende bruksområder som første steg i en brukerfokusert tilnærming:

  • Innovativ, individuelt tilpasset læring

  • Livslang læring

  • Forskning

  • Automatisert administrativ støtte

    • Forskningssøknader

    • Datahåndteringsplan innen forskning og andre prosjekter

    • Arkivering

    • HR prosesser for ansettelse og utsjekk

Innen bruksområdene over ser vi sektoren produserer og ønsker å tilby følgende hovedkategori av data for deling:

  • Utdannings- og forskningsressurser til gjenbruk og viderebruk

    • Forskningsresultater

    • Forskningsdata

    • Digitale læringsressurser

  • Administrative data

    • Grunndata for driftsformål

    • Data brukt og produsert i saksbehandling

    • Rapporteringsdata om egen saksbehandling og produksjon

  • Analysedata om utdanning og forskning

Sektoren har også bruk for data fra andre. Vi ser behov for følgende kategori av data:

  • Grunndata i nasjonale felleskomponenter (for eksempel fra folke- og enhetsregister)

  • Autentiseringsdata fra utlandet

  • Informasjon om grunnutdanning i Norge

  • Informasjon om utdanning i utlandet

  • Informasjon om forskning i utlandet og forskningsresultater fra utlandet

  • Informasjon om forskning i privatnæringsliv og resultater fra forskning i privat næringsliv

  • Informasjon om forskningsfinansiering i Norge (fra Forskningsrådet, med flere)

Bruksområdene over er utgangspunktet for forståelse av behovene som referansearkitekturen skal dekke.

11. Vedlegg E; Føringer, pågående og videre arbeid

Dette dokumentet beskriver de føringene til organisasjoner og IT-løsninger som vi ønsker å bruke videre i sektoren til å skape en effektiv plattform for datadeling. Referansearkitekturen tar utgangspunkt i følgende pågående arbeid i sektoren i dag:

  • Integrasjonsarkitektur UH:IntArk

  • Arbeid med Sak og Arkiv i sektoren

  • Arbeid med nytt API for Felles Studentsystem, FS

  • Arbeid med masterdatakilder for forskning

Referansearkitekturen innarbeider også føringer fra:

En viktig forutsetning for videre arbeid med samhandling og datadeling er Digitaliseringsdirektoratets «Orden i eget hus»:

«Med orden i eget hus mener vi at “den enkelte virksomhet skal ha oversikt over hvilke data den håndterer, hva dataene betyr, hva de brukes til, hvilke prosesser de inngår i, og hvem som kan bruke dem (informasjonsforvaltning)֦ . Dette innebærer også å ta stilling til hvilke data som kan gjøres tilgjengelig for gjenbruk i offentlig sektor, og viderebruk av privat sektor. Offentlige virksomheter må prioritere utveksling av informasjon som andre virksomheter har krav på https://www.regjeringen.no/no/dokumenter/digitaliseringsrundskrivet/id2826781/[(Digitaliseringsrundskrivet)].”

Referansearkitekturen forutsetter at virksomheter i UHF-sektoren har gjennomført eller er i gang med å gjennomføre prosesser for å skape «orden i eget hus».

11.1. UH:IntArk-prosjektet

UH:IntArk-prosjektet som tidligere er gjennomført i regi av UH-IT har utarbeidet et forslag til referansearkitektur for integrasjon. Denne er testet ut med en proof-of-concept. Dette proof-of-concept er videreutviklet i Datadelingsprosjektet for leveranse til hele UH sektoren som UH: IntArk fase 1.

Referansearkitekturen beskrevet i dette dokumentet er et målbilde for neste fase, som vi her kaller UH:IntArk fase 2. Mange element i målbildet kan med fordel rulles ut så tidlig som mulig, for eksempel tiltak rettet mot orden i eget hus.

11.2. Dette notatet og videre

Arbeidsgrupper i datadelingsprosjektet har samarbeidet i utformingen av referansearkitekturen for deling av data i høyere utdanning og forskning (UHF). Denne referansearkitekturen vil danne grunnlag for videreutvikling av UH:IntArk i fase 2. Arbeidsgruppen har i sitt arbeid tatt utgangspunkt i den nasjonale referansearkitekturen og tilpasset denne til UHF.

Den anbefalte referansearkitekturen er beskrevet i dette notatet.

Deler av referansearkitekturen beskrevet her vil inngå i referansearkitekturen for Kunnskapssektorens datafellesskap (en infrastruktur for deling av data til sekundær- og viderebruk fra hele KDs sektor), og arbeidet er koordinert med dette tiltaket som er i skrivende stund i en forprosjektfase.

Referansearkitekturer gir mønstre og veiledning til utforming av løsninger. Denne referansearkitekturen beskriver både eksisterende samhandling formulert som beste praksis og nødvendig neste steg i generelle datadelingsmønster som kan gjenbrukes i sektoren. Disse mønstrene er dokumentert gjennom videreutvikling av referansearkitekturene fra digitaliseringsdirektoratet. Hensikten med arbeidet er å fremme en koordinert utvikling av informasjonsforvaltning og datadeling som resulterer i «orden i eget hus», økt gjenbruk av data «kun en gang» og nye, innovative anvendelser av data i sektoren.

Vi forventer at referansearkitekturen vil videreutvikles over tid. Vi mener at innholdet som finnes nå har tilstrekkelig veiledning til å føre til gevinst, samtidig er vi klar over mangler som vi ønsker skal være dekket så snart som praktisk mulig:

  • Rutinen for utvikling av indre API burde være detaljert

  • Retningslinjer for spesifikasjon av API burde vært definert. Vi tenker å benytte Open API spesifikasjon som en del av retningslinjene for REST APIene. GraphQL vurderes i tillegg.

  • Prosesser for rettighetsklarering av dataprodukter bør defineres

  • Føringer til beskrivelser av dataprodukter bør defineres. Det er et mål at dataprodukter skal være mest mulig selvbeskrivende.

  • Begrepsdefinisjoner bør suppleres og publiseres i begrepskatalogen

  • Notifikasjoner som er realisert ved bruk av hendelseslister vurderes ut fra behov

  • Bearbeide IntArk arkitekturprinsipper og annen kildemateriale for å konkretisere føringer fra Overordnede arkitekturprinsipper og "FAIR Guiding Principles for scientific data management and stewardship" for deling av data.

11.3. Om arkitekturprinsippenes føringer for datadeling

De Overordnede arkitekturprinsippene fra digitaliseringsdirektoratet er gjeldende for referansearkitekturen. For å forenkle bruk av prinsippene, har vi valgt ut noen av føringene fra de overordnede prinsipper som er spesielt relevant for integrasjoner og inkludert disse i referansearkitekturen når vi ruller ut UH:IntArk fase 1, som integrasjonsprinsipper.

image11


1. Person som har søkt opptak til et studieprogram eller enkeltemner ved et universitet eller en høyskole.
2. Fra «https://martinfowler.com/articles/data-monolith-to-mesh.html#DomainDataAsAProduct[How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh
4. Disse strategiske valg er basert på arbeid med valg av operasjonelle modeller beskrevet i «Enterprise Architecture as Strategy» av Ross, Weill og Robertsen.
7. MASA: How to Create an Agile Application Architecture With Apps, APIs and Services Published 3 February 2020 - ID G00451136; Gartner
10. INNOVATIV UTDANNING OG FREMRAGENDE FORSKNING DIGITALISERINGSSTRATEGI FOR UNIVERSITETS- OG HØYSKOLESEKTOREN (2021-2025) hentet fra https://www.unit.no/ny-digitaliseringsstrategi-uh-sektoren