Anbefalinger for arkitektur vedrørende digitale vurderingsformer ved UiO

Sammendrag

En fremtidsrettet arkitektur er grunnleggende for at UiO skal være endringsdyktig med hensyn til innføring av digitale vurderingsformer. Digital eksamen er et relativt nytt felt der behov og funksjonalitet er i konstant endring. Dagens modell for digitale vurderingsformer er i stor grad en digitalisering av den klassiske skoleeksamen, men digitalisering åpner også for helt nye eksamensformer og vurderingsformer, som vil kunne ha stor innvirkning på hva som oppfattes som en eksamen i fremtiden. 

Målet for den ideelle arkitekturen er å identifisere klart definerte komponenter og samspillet mellom dem, slik at disse kan endres, byttes eller kjøre i parallell. Dette er for å sikre smidige endringer og tilrettelegge for gode brukeropplevelser. For eksempel vil fakultetets- eller instituttspesifikke behov kunne ivaretas i en felles digital eksamensløsning, uten å påvirke resten av virksomheten. Brukere kan forholde seg til sine vanlige arbeidsflater selv om systemet endres og man kan tilby innsyn i systemet på tvers av flere arbeidsflater.

Arbeidsgruppen har utarbeidet en referansearkitektur for digitale vurderingsformer ved UiO. Med bakgrunn i referansearkitekturen skisseres det et ideelt målbilde for en mer konkret implementasjon av arkitekturen, og det gjøres anbefalinger for hvordan UiO kan bevege seg mot målbildet, på kortere og lengre sikt.  

Hvorfor utarbeide en arkitektur?

Hovedgrunnen til å utarbeide en arkitektur er å danne seg et bilde av domenet, slik at man er i stand til å ta nødvendige grep for å understøtte prosessene i en tjeneste for digital eksamen. Det er mange krefter som presser på for å innføre ulike systemer for digitale vurderingsformer ved UiO, og dette skaper utfordringer som man ikke er i stand til å svare fornuftig på uten å gjøre et forarbeid. Gjennom å analysere behovene og utarbeide en arkitektur står man bedre rustet til å kunne peke ut en vei man ønsker å gå. Hvis man derimot opptrer passivt og ikke foretar seg noe, vil veien bli til mens man går, og man kan risikere å ende opp i en situasjon der man sitter med et antall systemer uten kontroll eller oversikt over disse.

En annen viktig grunn til å utarbeide en arkitektur er å etablere en referanseramme for vurdering av systemer. Ofte blir systemer utelukkende vurdert utfra rent funksjonelle (faglige) kvaliteter og pris, noe som ofte har uheldige konsekvenser som kommer til uttrykk etter en tid. Dersom man har etablert en arkitektur som systemer skal passe inn i medfører det at man har et rikere sett med kriterier for vurdering av slike systemer, og blir i stand til å ta mer kvalifiserte beslutninger.

Målsetninger

En (ideell) arkitektur bør være fundamentert i målsetninger. Viktige målsetninger som har vært toneangivende i arbeidet er:

Råderett over egne data Eksamensrelaterte data, som oppgavesett og besvarelser er viktige for UiO, og er noe man bør ha kontroll over.

Uavhengighet UiO ønsker ikke å binde seg til enkeltleverandører. Det er nødvendig å ha frihet til å velge nye systemer etter behov, eller utvikle egne løsninger der det ikke finnes leverandører som dekker behovene.

Endringsdyktighet Digital eksamen er et domene i konstant endring, og UiO må være rustet til å takle disse endringene.

Fleksibilitet Det er ønskelig å kunne benytte kun deler av funksjonaliteten i systemer, eller å bytte ut deler av funksjonaliteten fra en leverandør med tilsvarende fra en annen leverandør. 

Standardiserte arbeidsflater Det er uheldig hvis kandidater og andre aktører må forholde seg til mange ulike arbeidsflater på tvers av eksamenssystemer. I det minste bør man kunne standardisere de administrative aspektene ved ulike systemer.

Arkitekturprinsipper

Utarbeidelsen av arkitekturen bygger på et antall generelle arkitekturprinsipper.

Lagdeling

Arbeidsgruppen har valgt å basere seg på en lagdelt arkitektur som består av tre lag, og hvor hvert av lagene består av et sett med komponenter. 

 

Presentasjonslaget

Det øverste laget i arkitekturen, hvor brukergrensesnittene befinner seg. I dette laget skal det normalt ikke utøves forretningslogikk, hovedformålet er å oversette operasjoner og datarepresentasjoner fra underliggende lag til noe brukere kan forholde seg til. 

Logisk lag

Det logiske laget består av et sett med komponenter som tilsammen tilbyr de operasjonene som er nødvendige for å realisere funksjonaliteten i presentasjonslaget.

• Kommunisere med datalaget og tilby logiske datasammenstillinger og funksjoner til visningslaget.
• Forretningslogikk hører til dette laget
• Komponenter i det logiske laget kan samarbeide med andre komponenter i det samme laget for å tilby en tjeneste. 

Lagringslag

Består av flere komponenter som har ansvar for persistering av data, i form av databaser eller andre lagringsmekanismer. Tilbyr oppslag i og skriving av (ikke-sammensatte) data til det logiske laget, aller helst gjennom abstraksjoner som skjuler de faktiske lagringsmekanismene.

Fordeler ved lagdeling

Ved å gjøre en slik lagdeling oppnår man visse fordeler:

• Man står fritt til å bytte ut eller legge til komponenter på hvert lag, såfremt de støtter det eksisterende kommunikasjonsgrensesnittet.
• Med et presentasjonslag har man mulighet til å bygge nye grensesnitt mot det samme logiske laget, for eksempel i form av mobil- eller webapplikasjoner, på det samme logiske laget.
• Tilsvarende kan man innføre nye komponenter på det logiske laget, som har annen opførsel, men som benytter det samme brukergrensesnittet og lagringslaget.
• Man frigjør logiske komponenter og presentasjonskomponenter fra å måtte forholde seg til konkrete lagringsmekanismer, de jobber i stedet mot standardiserte lagringsgrensesnitt.

Bruk av web services for kommunikasjon

Det forutsettes at kommunikasjon mellom komponentene (mellom arkitektoniske lag eller innenfor samme lag) fortrinnsvis foregår gjennom en form for web service. I visse tilfeller er dette ikke mulig, og da kan man se for seg at kommunikasjonen går indirekte via et underliggende lag (for eksempel ved at én komponent skriver til persisteringslaget og en annen komponent leser data på et senere tidspunkt).

Åpne arkitekturer

I denne sammenhengen er det nyttig å skille mellom åpne og lukkede arkitekturer. Åpne arkitekturer kjennetegnes ved følgende egenskaper:

• Modularisert: systemer består av moduler som kan fungere uavhengig av hverandre.
• Komponentene har klart definerte grensesnitt
• Komponentene kan utveksle data på standardiserte formater, som en del av grensesnittene

I motsetning til systemer med åpne arkitekturer står systemer med lukkede arkitekturer. Noen typiske karakteristikker ved slike  systemer er:

• Monolittiske (liten grad av modularisering)
• Mangel på åpne grensesnitt
• Bruk av ikke-standardiserte formater
• Datautveksling er ofte basert på import/eksport

Faser og komponenter i eksamenssystemer

Man kan se for seg at man splitter opp de fagrelaterte oppgavene i et eksamenssystem i ulike faser med tilhørende komponenter. Hver slik komponent fungerer slik at den utfører sin oppgave basert på gitte inndata og leverer fra seg et resultat, som igjen kan benyttes som inndata til neste komponent. For de relevante aspektene ved eksamenssystemer er disse komponentene identifisert: utforming, gjennomføring og sensurering.

• Utforming: faglærer produserer oppgaver og oppgavesett 
• Gjennomføring: dette er grenseflaten kandidater forholder seg til ved besvaring av eksamen. Det vil typisk omfatte skriving (eller en annen form for besvaring), og innlevering av besvarelsen.
• Sensur: sensor vurderer en eller flere besvarelser og produserer et resultat. Dette omfatter også eventuell klagesensur.

 

Hovedargumenter for å gjøre denne oppsplittingen:

• Man står fritt til å kunne bytte ut komponenter. Mange eksamenssystemer tilbyr overlappende eller lignende funksjonalitet, hvor de ulike fasene er støttet på forskjellige måter. Det kan i mange tilfeller være ønskelig å benytte ulike systemer i ulike faser, basert på hvilket system som løser de aktuelle oppgavene på best måte.
• Man får tilgang til data som blir produsert i en komponent, slik at man på den måten kan benytte dataene i nye arbeidsflyter som ikke omfattes av eksamenssystemet.

Eksempel på samspill i en åpen arkitektur

Figuren under viser hvordan en åpen arkitektur tillater samspill mellom forskjellige systemer i de ulike fasene.  I dette eksempelet foregår oppgaveutforming og gjennomføring i «System X», mens sensur gjøres i «System Y». I tillegg blir eksamensoppgaver bevart i en oppgavebank, med tanke på gjenbruk og kvalitetsheving. På samme måte kunne man for eksempel se for seg at besvarelser ble gjenstand for ekstern plagiatkontroll i etterkant av gjennomføring, basert på at de er tilgjengelig som følge av en åpen arkitektur.

For at dette skal være mulig må visse forutsetninger være på plass:

• Standardisering av data: Eksamen, oppgavesett, besvarelser og resultat må kunne utveksles på standard formater.
• Komponentene bør tilby veldefinerte API-er, slik at integrasjon kan foregå på det logiske laget.

Begrensninger ved lukkede arkitekturer

En lukket arkitektur karakteriseres ved at komponentene i systemene ikke er tilgjengelige for eksterne aktører. For et eksamenssystem innebærer dette at de eneste fasene som tillater innsyn er den initielle (representert ved inndata av type Eksamen), og den siste fasen (Resultat). Dette kan illustreres ved hjelp av følgende figur:

Referansearkitektur

Bakgrunn

Arbeidsgruppen har tatt utgangspunkt i kartleggingen som er gjort i Forslag til digital arbeidsflyt for eksamen ved UiO, utredet av hovedprosjektet UiO digital eksamen. Denne kartleggingen representerer en oversikt over alle kjente arbeidsprosesser rundt dagens eksamensgjennomføring og vurderinger opp mot en fremtidig digitalisert virkelighet. 

Den digitale arbeidsflyten er svært omfattende, og for å håndtere denne kompleksiteten var det nødvendig å gå systematisk til verks. Det ble brukt følgende metodikk: 

1. Ekstrahere alle roller, oppgaver og entiteter fra den digitale arbeidsflyten
2. Eksperimentere med ulike sorteringer av disse for å belyse alle aspekter
3. Utarbeide de grove arbeidsflatene i presentasjonslaget for de forskjellige aktørene
4. Identifisere operasjoner i det logiske laget, gruppere disse i logiske komponenter
5. Plassere de viktigste entitetene i lagringslaget
6. Definere fornuftige avhengigheter mellom komponenter i de ulike lagene i arkitekturen

Skisse over arkitekturen

Arkitekturen er skissert i følgende figur. Skissen representerer arbeidsgruppens virkelighetsbilde på det nåværende tidspunkt, og det er mulig det blir nødvendig å gjøre justeringer etterhvert som forståelsen av domenet øker og man har høstet flere erfaringer.

Beskrivelse av referansearkitekturen

Roller

Faglærer: vitenskapelig ansatt, faglig ansvarlig for eksamen. Typiske oppgaver er å utforme oppgavesett og sensorveiledninger, samt enkelte administrative oppgaver.

Eksamensadministrator: administrativt ansatt, utfører oppgaver i alle faser (planlegging, avvikling, etterarbeid). 

Kandidat: person som skal ta eksamen. Melde seg opp til, gjennomføre og levere eksamen. Tilgang til sensur og klage.

Eksamensvakt: praktisk koordinator under gjennomføring av eksamen, inkludert IT-støtte.

Sensor: vitenskapelig ansatt (eller ekstern) som har ansvar for å sensurere besvarelser

Visningslaget

Presentasjonslag som brukere forholder seg til. Formålet med dette laget er å gi brukere tilgang til funksjonalitet som er realisert i underliggende lag i arkitekturen. Dette kan skje i form av websider eller dedikerte applikasjoner på mobiltelefoner eller lignende. Har ikke direkte tilgang til datalaget, må forholde seg til det logiske laget. Komponentene i dette laget tilsvarer disse arbeidsflatene:

Oppgaveutforming: benyttes av faglærere og eksamenskonsulenter for å produsere og ferdigstille oppgaver og oppgavesett

Eksamensadministrasjon: arbeidsflate for eksamenskonsulenter som inneholder diverse administrative funksjoner, blant annet:

• knytte sammen oppgaver, oppgavesett og sensorveiledninger
• sette sammen komponenter for utforming, gjennomføring og sensur for gitte eksamener
• Registrering av rom, dato/tid, kommisjoner med sensorer, eksamensvakter, tilrettelegging
• kontrollere formalia knyttet til oppgavesett

Gjennomføring: en del av et eksamenssystem hvor kandidaten gjennomfører eksamen. Innebærer blant annet å gi presentere oppgaven for kandidaten, tilby skriving av besvarelse, mellomlagring, stavekontroll, levering.

Egenadministrasjon: arbeidsflate hvor kandidater får tilgang til funksjonalitet rundt eksamen, som f.eks. oppmelding, avmelding, informasjon om tid og sted, sensur og resultater.

Sensurering: funksjonalitet som er rettet mot sensorer (ofte del av et konkret eksamenssystem). Gir tilgang til relevante besvarelser for retting, begrunning, sensurering. Kan tilby funksjoner for samarbeid om sensur med medsensor.

Klaging: En flate hvor kandidater får mulighet til å registrere klage på et resultat.

Logisk lag

Det logiske laget er gruppert i følgende komponenter:

Oppgave: Operasjoner for å tilgjengeliggjøre oppgaver og sensurveiledninger for andre komponenter

Eksamensadministrasjon: Holde orden på metadata rundt eksamen, eksamensmeldinger, sensorer og eksamensvakter, samt koblinger mellom disse. I tillegg har den ansvar for å ha oversikt over hvilke tjenester som skal benyttes til utforming, gjennomføring, sensur og klage.

Besvaring: Dette er bindeleddet mellom gjennomføringskomponenten i eksamenssystemet og det logiske laget. De viktigste operasjonene i denne komponenten er å gi tilgang til oppgavesett, og ta i mot besvarelser fra eksamenssystemet.

Gjennomføringsadministrasjon: en logisk komponent som skal understøtte administrative oppgaver i forbindelse med avvikling av eksamen. Typiske oppgaver vil være å gi tilgang til eksamensmetadata, diverse opplistinger over leverte besvarelser fremmøtte kandidater osv., og operasjoner for å stoppe/pause eksamen eller gi kandidater tilleggstid.

Sensur: Skal tilby operasjoner for opplisting av kommisjoner og eksamener som skal sensureres, sammenslåing av delresultater, og skriving av resultater og begrunnelser. Her kan det også være aktuelt å bygge inn funksjonalitet rundt plagiatkontroll.

Klage: registrere klager på sensur, og trigge at eksamenskonsulent får beskjed om at klage er registrert

Lagringslag

I arkitekturen er lagringskomponentene gruppert logisk etter informasjonstype:

• Lagring av faglige data relatert til oppgaver: oppgavesett, sensorveiledninger
• Lagring av administrativ informasjon relatert til eksamen: eksamensmetainformasjon (eksamensgjennomføringssystem, tilrettelegging osv.), eksamensmeldinger
• Lagring av eksamensbesvarelser og innleveringer
• En komponent for lagring av resultater (sensur)
• Egen lagringskomponent for informasjon rundt klager
• Arkiv: ekstern langtidslagring av arkivpliktige data (kan være ulike systemer, f.eks. Riksarkivet og ePhorte)

Aktuelle scenarier for UiO

Ideelt målbilde

Det er lite realistisk å tro at ett system alene skal kunne dekke alle UiOs behov rundt digital eksamen, og at det er derfor nødvendig å ta høyde for at mange slike løsninger skal kunne sameksistere. I en slik virkelighet er det ønskelig at flest mulig av disse systemene kan integreres på bakgrunn av en åpen arkitektur, med de fordelene det innebærer.

Arbeidsgruppen har derfor skissert et ideelt målbilde i form av et eksempel hvor flere av dagens kjente systemer for digital eksamen er tatt med:

 

Denne figuren relaterer seg til referansearkitekturen på den måten at det logiske laget er representert gjennom «Eksamens-API» og «StudWS», og de ulike eksamenssystemene representerer hver for seg en eller flere av grenseflatene «Oppgaveutforming», «Eksamensadministrasjon», «Gjennomføring», «Gjennomføringsadministrasjon» og «Sensurering».

Figuren viser ikke et realistisk scenario, ettersom alle eksterne og interne systemer er tenkt å støtte full integrasjon gjennom veldefinerte API-er i alle faser. Likefullt er det nyttig å ha dette som en referanse når man vurderer andre, mer pragmatiske tilnærminger.

Scenario 1: Minimal integrasjon

I dette scenariet ser man for seg at UiO i størst mulig grad velger totalleverandører med sky-tjenester for digitale vurderingsformer. I tillegg til eventuelle nye systemer har UiO allerede i dag et knippe systemer som i varierende grad tilbyr løsninger for digital eksamen. Felles for disse systemene er at de i liten grad tilbyr integrasjon utover å skrive resultater til FS. Dette kan illustreres med følgende figur:

 

 

I denne arkitekturen blir FS det eneste integrasjonspunktet. Integrasjonen er stort sett begrenset til administrative data og karakterer. Andre data som er produsert fortløpende (f.eks. oppgavetekster og besvarelser) er ikke tilgjengelige, de eksisterer kun i de respektive eksamenssystemene. 

At en integrasjon på et høyere nivå enn FS ikke eksisterer her er selvfølgelig naturlig, ettersom det ikke finnes et integrasjonslag å integrere mot. Fraværet av et integrasjonslag innebærer også at det ikke er mulig å tilby funksjonalitet i Mine studier og StudWeb utover å presentere det som befinner seg i FS.

Scenario 2: Etablering av en arkitektur og gradvis integrasjon av løsninger

I dette scenariet ser man for seg at UiO etablerer rammer for integrasjon av ulike eksamenssystemer gjennom å utvikle egne løsninger for sentrale komponenter, i tråd med den skisserte referansearkitekturen. På denne måten er man ikke tvunget til å velge mellom scenario 1 og det ideelle målbildet. Dette er en mer pragmatisk tilnærming, som innebærer at man starter med dagens situasjon og arbeider for en gradvis overgang mot målet, gjennom å flytte enkeltsystemer over til det nye grensesnittet. Denne prosessen kan pågå parallellt med at andre systemer fortsetter å eksistere med en lukket arkitektur, og er forsøkt illustrert nedenfor:

 

 

I eksempelet i figuren har visse systemer (Inspera, Obligatoriske innleveringer og Hjemmeeksamen) blitt fullintegrert gjennom eksamens-API-et, mens andre fortsetter å jobbe mot FS direkte. Allerede her kan man begynne å høste gevinster, for eksempel:

• Tilgang på oppgaver og besvarelser fra de fullintegrerte systemene
• Kandidater kan få tilgang til eksamensdata og selvbetjening via Mine studier, slik at det ikke er nødvendig å logge inn i Studentweb for alle slike formål.
• Mulighet for å levere hjemmeeksamen og obligatoriske oppgaver direkte fra Mine studier
• Mulighet til å bytte ut en modul i ett system med en mer avansert variant fra et annet system (f.eks. sensurmodul)

Vurderinger av scenariene

En kvalitativ sammenligning av de to scenariene kan presenteres side om side i en matrise slik:

Vurdering av fordeler og ulemper ved de to scenariene

	Scenario 1	Scenario 2
Fordeler	Kan innføres i dag (allerede delvis innført) Kan gi et forutsigbart kostnadsbilde (lisenskostnad per student) gitt at man finner produkter som dekker behovene til UiO. Stiller ingen eller få krav til utvikling internt på UiO Stiller ingen krav til applikasjonsdrift internt på UiO	Det etableres en arkitektur som kan benyttes som en referanseramme når nye systemer skal vurderes Man har et eksplisitt forhold til integrasjon av ulike komponenter Setter en terskel for «minimumsintegrasjon»,  Mange komponenter kan være utskiftbare UiO vil kunne tilby en mer fleksibel eksamenstjeneste, med mulighet for ulike løsninger for ulike behov. Økt råderett over data  Kan innføres gradvis over tid Kan bidra til at det kan tilbys mer sammensatt informasjon og tilgang til funksjonalitet i Mine studier, og dermed begrense antall kanaler en kandidat må forholde seg til. Tilsvarende funksjonalitet kan også tilbys for andre roller og oppgaver, for eksempel sensorer og faglærere.
Ulemper	Man er låst til leverandøren, utvikling man betaler for blir låst inne i løsningen og er tapt den dagen man sier opp avtalen. Utvikling må gjøres av den enkelte leverandøren, kan ikke konkurranseutsettes eller utvikles på UiO Gir en lite fleksibel løsning Vanskelig å benytte forskjellige systemer til ulike deler av eksamensløpet	Fordrer utvikling og etablering av et (ikke-trivielt) integrasjonslag. Dette er et ambisiøst arbeid som vil kreve en del ressurser i flere iterasjoner. Medfører driftsansvar for UiO for visse komponenter Vil antageligvis kreve et arbeid med tilpassing rundt integrasjon for hvert nytt system som innføres

 

Kostnader

Når det gjelder kostnader knyttet til de ulike scenariene er det rimelig å anta at scenario 1 (skybaserte tjenester uten særlig grad av integrasjon) vil ha de laveste kostnadene, og at det skisserte målbildet vil være det mest kostnadskrevende alternativet. Scenario 2 vil antageligvis kunne plasseres kostnadsmessig et sted mellom de to andre alternativene.

Når det gjelder kostnader over tid er det flere faktorer som må vurderes, blant annet:

• Eksterne systemer har ofte kostnader relatert til gjennomførte eksamener (kostnaden varierer med volum)
• Nye systemer som innføres bidrar til kostnad i form av lisenser og bruk, men medfører også kostnader i form av brukerstøtte og teknisk tilpasning
• Videreutvikling for eksterne systemer koster like mye som andre systemer
• Egenutviklete systemer har ofte en høyere initiell kostnad (hvis man flytter over alle systemene samtidig)
• Innføring av standardisering har i seg selv en kostnad i form av tilpasning, men etter at standardiseringen er på plass vil den kunne skalere til mange systemer uten ekstra kostnad.

Ambisjonsnivå

For å kunne komme med en anbefaling med hensyn til arkitekturvalg er det nødvendig å vurdere hvilket ambisjonsnivå man ønsker å legge seg på. Det kan være fristende å si at man ønsker å innføre det ideelle målbildet, men dette er urealistisk å få til og vil antageligvis være for kostnadskrevende til at det er verdt det. På den andre siden har scenario 1 visse fordeler, særlig med hensyn til kostnader, men gjør at ambisjonsnivået må senkes betraktelig.​

Man kan se for seg at ambisjonsnivå og kostnader kan veies mot hverandre på følgende måte:

Merk at scenario 2 representerer en gradvis overgang fra scenario 1 til målbildet. Det kan for eksempel plasseres nærmere scenario 1 ved å senke ambisjonsnivået, men da vil også kostnadene gå tilsvarende ned.

Anbefalinger

På kort sikt

Arbeidsgruppen anbefaler at de systemene som eksisterer i dag videreføres, med integrasjon mot FS som et minimum. Det samme gjelder også ved innkjøp av nye systemer, som for eksempel Inspera. På denne måten får UiO innført digital eksamen og får verdifull erfaring med slike systemer.

Det anbefales videre at det settes i gang et arbeid med å innføre sentrale komponenter i arkitekturen, nærmere bestemt eksamens-API og webtjenester for studieinformasjon. For å kvalitetssikre og realitetsorientere dette arbeidet er det ønskelig at det samtidig arbeides med å integrere en eksisterende eller ny eksamensløsning mot disse komponentene.

På lengre sikt

Det er arbeidsgruppens oppfatning at UiO bør ha en langsiktig strategi om å bevege seg i retning av det skisserte målbildet, mot en enhetlig tjeneste rundt digitale vurderingsformer.

En overordnet målsetning bør være at man forsøker å standardisere flest mulig av de administrative prosessene rundt eksamen, samtidig som man ønsker å tilby fleksibilitet når det gjelder vurderingsformer. Man bør imidlertid bestrebe å unngå mange løsninger med overlappende funksjonalitet, gjennom å ha klare planer og mål rundt forvaltning av tjenestene.

Hvordan komme dit?

Det er naturlig at man tar utgangspunkt i det arbeidet som skisseres i det mer kortsiktige perspektivet. Her legges det et grunnlag for en integrasjonsplatform, og det er ønskelig å kunne benytte denne platformen til å høste erfaringer og kvalitetssikre arkitekturen gjennom integrasjonen av de systemene som UiO selv kontrollerer.

Etterhvert som arkitekturen modnes vil det være naturlig at eksisterende og nye systemer, både egenutviklede og fra tredjepartsleverandører, blir integrert på et mer fullverdig nivå. For tredjepartsleverandører betyr dette at UiO må sette spesifikke krav til disse, for eksempel om åpenhet i arkitekturen (API-nivå) og om standardiserte dataformater for utveksling.