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

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.

Referansearkitekturen er utarbeidet i et samarbeidsprosjekt Datadeling med prosjektdeltagelse fra NTNU, Universitetet i Oslo, daværende Unit og Uninett (per januar 2022 HK-dir og Sikt). Styringsgruppen består av medlemmer fra Sikt, Universitetet i Bergen, OsloMet, Universitetet i Oslo, Norges Miljø- og Biovitenskaplige universitet.

Målgruppen for referansearkitekturen er primært arkitekter og tekniske prosjektledere. De delene av dokumentet som omhandler informasjonsforvaltning er også relevant for domeneansvarlige, begrepsansvarlige, tjenesteeiere, tjenesteansvarlige, utviklere og datakonsumenter (disse rollene er definert i dette dokumentet).

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

Vi tolker definisjonen til å gjelde uansett om data flyttes til konsumenten eller om konsumenten får tilgang til data hvor de ligger. Innen forskning, for eksempel, kan det være hensiktsmessig å gi konsumenter av veldig store datamengder tilgang til å utføre analyse på data der de ligger.

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.

Figuren viser datadeling i og mellom domener. Dataprodukter tilgjengeliggjøres og deles mellom domenene i økosystemet. Domenene kan opptre som datatilbydere (tilbyr dataprodukt) og datakonsumenter (datakonsum). Datadelingsplattformen og fellestjenestene i den muliggjør datadelingen i økosystemet.

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 høyere utdannings- og forskningssektorene i ferd med å bygge en distribuert arkitektur som knytter sammen løst koblede, 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.

De grunnleggende domenene inneholder kontekst som støtter de sentrale prosessene for læring, forskning og administrasjon hos institusjonene. Denne konteksten vil omfatte begreper, informasjonsmodeller, prosesser og dersom det er hensiktsmessig, også data.

Disse domenene inneholder blant annet masterdatakilder med informasjon om, for eksempel, studenter, ansatte, forskningsprosjekt, forskningsresultater, læringsobjekter, med flere. Den semantiske betydningen av objektene og deres attributter i masterdatakildene skal reflektere en omforent forståelse av disse begrepene. 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 brukskontekst. 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 samler data.

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 samt roller og ansvar beskrevet i seksjonen Roller og ansvar for datadeling og informasjonsforvaltning.

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. 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 i størst mulig grad benytte standardiserte arbeidsprosesser og felles begreper. Lærings- og forskningsprosesser skal fremme innovasjon gjennom arbeidsprosesser som understøtter faglig autonomitet. ^[3]

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 sektorene som helhet der definisjon av prosesser og begreper skal skje. Denne tilnærming er i tråd med eksisterende harmoniseringsprosesser i sektorene. Samtidig er data som inngår i de standardiserte, administrative prosessene hovedsakelig lokale data for den enkelte institusjon hvor prosessen kjøres.

Lærings- og forskningsprosesser vil variere og være knyttet til en brukskontekst med et tilhørende informasjonsdomene. Aktører knyttet til bruksnæ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 bruksdomer 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 Repositories».

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 vist under utdyper disse samhandlingsevnene.

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.

Verktøykasse for deling av data 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 høyere utdannings- og forkninssektorene 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 sentrale i «orden i eget hus». For at datadeling skal fungere etter hensikten, 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 er utviklet gjennom som et samarbeid mellom europeiske universiteter.

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.

Hvert domene har sin egen informasjon som må forvaltes. Referansearkitekturen foreslår roller som har dette ansvaret i seksjonen Roller og ansvar for informasjonsforvaltning. Informasjonsforvaltning basert på domeneansvar forutsetter at høyere utdannings- og forskningssektorene blir enige om hvilke domener de skal forholde seg til og hvem som skal bekle rollene koblet til dem. Sektorene er allerede i gang med å definere funksjonsområder som kan være utgangspunktet for definisjon av informasjonsdomener. Arbeidet skjer både som analyse av evner (kapabiliteter) som virksomhetene skal ha og som en kartlegging av sektorenes kjernevirksomhet i en «funksjonsanalyse» for saksbehandlings- og arkiveringsformål.

Europeiske universiteter har modellert sine kapabiliteter i EUNIS kapabilitetsmodellen, en modell som nå gradvis migreres inn i HERM fra CAUDIT, støttet av EDUCAUSE og UCISA. Disse modellene er brukt som utgangspunkt for å foreslå noen informasjonsforvaltningsdomener for data som institusjonene ønsker å dele. De foreslåtte domenene er vist i figuren under. Innenfor hver domene har fageksperter eierskap til begrepsdefinisjoner i domenet.

Arbeidet med funksjonsanalyse for arkiveringsformål er en annen kilde til definisjon av informasjonsdomener. NTNUs representasjon av HERM fra CAUDIT med mapping til funksjonsanalysen er tilgjengelig her.

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 dataforvaltnings, masterdata og API Management-regime i høyere utdannings- og forskningssektorene.

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 høyere utdannings- og forskningssektorene for innovasjon. Dataforvaltning og 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:

For publisering av hendelser er det etablert et mønster der datatilbyder tilbyr lettvektsnotifikasjoner om hendelser som medfører endringer i datagrunnslaget som datakonsumenten kan abonnere på. Lettvektsnotifikasjonen inneholder en identifikator som peker til hvilke data som er relatert til notifikasjonen. Dette mønsteret er allerede i bruk i høyere utdannings- og forskningssektorene.

Lettvektsnotifikasjonen i en eNotifikasjon blir overført mellom datatilbyder og konsument av en meldingsformidler (message broker). Meldingsformidleren tar imot notifikasjoner om hendelser fra produsenter, og overfører notifikasjonene til de konsumenter som abonnerer på 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.

Datadelingsplattformen består av felleskomponentene beskrevet under. Disse komponentene tilbyr fellestjenestene benyttet i datadelingsprosessene som detaljeres i neste kapittel. De fleste felleskomponenter skal realiseres med en delt instans for høyere utdannings- og forskningssektorene. API gateway er en funksjonell beskrivelse av en komponent som skal realiseres med instanser nær datakildene som skal beskyttes.

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 med basis i 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:

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.

Det er behov for datadeling og API Management på tvers av offentlig sektoren og mot privat næringsliv. Høyere utdanning og forskning ønsker utstrakt bruk av nasjonale felleskomponenter, som omtalt i Digitaliseringsrundskrivet og vist i figuren under. For å oppnå dette må både høyere utdannings- og forskningssektorene 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 forventer skal realiseres i IAM løsningen til høyere utdanning og forskning. Samtykke til kilder i sektorene våre 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.

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.

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

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.

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

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.

Når en hendelse endrer data hos en datatilbyder, og disse data deles gjennom datadeling med notifikasjon, skal det sendes en notifikasjon til datakonsument.
Notifikasjoner omhandler hvilke data i det tilhørende API som er endret. Notifikasjonen er sådan operasjonell, den melder fra om hvilke data som er endret, men ikke hvilken forretningshendelse som har inntruffet.

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:

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:

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.

Arkitekturen er formgivende for tjeneste- og systemlandskapet, som igjen skal gjenspeile hva brukerne trenger. Stadige endringer er normaltilstanden. Derfor må arkitekturen være fleksibel, slik at den kontinuerlig kan tilpasses brukermassens skiftende behov.

Se også Digitaliseringsdirektoratets arkitekturprinsipp 1: Ta utgangspunkt i brukernes behov og arkitekturprinsipp og 5.3: Sørg for arkitektur som gir systemer og tjenester evne til endring og vedlikehold over tid.

Integrasjonsgrensesnitt skal utformes slik at tjenester og bakenforliggende systemer kan flyttes og byttes ut uten at konsumenter av tjenesten må gjøre endringer i sin ende, og omvendt. Dette prinsippet legger føringer på hvilken programvare vi kan anskaffe, hvilke grensesnitt som tilbys av egenutviklede applikasjoner, og hvordan vi kobler sammen egenutviklede applikasjoner.

Se også Digitaliseringsdirektoratets arkitekturprinsipp 5.7: Ta hensyn til anerkjente designprinsipper for tjenesteorientert arkitektur, slik som løse koplinger, modularisering, standardiserte tjenestekontrakter med videre.

Data skal være tilgjengelig for konsumenter. Tilgjengelighet manifesterer seg på flere plan:

For at kravet om teknisk tilgjengelighet skal være oppfylt, må data tilbys gjennom åpne grensesnitt som er teknisk dokumentert, samtidig som det forutsetter at grensesnittet er tilgjengelig over tid og bakoverkompatibelt.

For at data skal være tilgjengelige forståelsesmessig, må dataenes semantiske betydning være dokumentert.

Oppdagbarhet forutsetter at definisjoner av grensesnitt og tilhørende teknisk og semantisk dokumentasjon er publisert. Avhengig av dataenes størrelse, struktur og bruksområde, kan det være nødvendig å melde fra til konsumenter om at data har endret seg ved å benytte notifikasjoner.

Se mer om dette under Utforming av notifikasjoner og Utforming av API.

Se gjerne:

Gjenbruk av løsninger forutsetter at det samarbeides i fagmiljøer på tvers av institusjoner om å homogenisere forretningsprosesser.

Se gjerne Digitaliseringsdirektoratets arkitekturprinsipp 5: Del og gjenbruk løsninger, spesielt:

Konsum av API-er skal skje gjennom API Manager. Dette medfører at institusjonen har oversikt over hvem som konsumerer hvilke data.

Se også Digitaliseringsdirektoratets arkitekturprinsipp 7.3: Virksomhetene må ha styring og kontroll som sørger for at informasjonssikkerhet og personvern er ivaretatt i tjenestene.

Avvik fra prinsippene om Tjenesteorientert arkitektur og Tilgjengelige data er lov, så lenge det kan begrunnes at avviket er hensiktsmessig for sektoren.

Et eksempel er at det kan være hensiktsmessig å bruke en leverandørspesifikk integrasjon, hvis kostnadene ved å innføre en løsere kobling blir høyere enn konsekvensene og risikoen for institusjonen ved å låse seg til en leverandør.

Det er behov for å videreutvikle datadeling for læring og forskning. I henhold til ny digitaliseringsstrategi skal studenter tilbys fleksible og studentaktive undervisningsformer. Data om studentenes læring forvaltes hos og tilbys fra den enkelte institusjonen. Institusjonen er ansvarlig for at data opprettholder nødvendig kvalitet, inklusiv samordning med relaterte datakilder. Data om gjennomført utdanning er 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.

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.

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.

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.

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

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.

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

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:

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

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

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