SAMARBEID OM IKT-ARKITEKTUR FOR STATLIGE UNIVERSITETER OG HØYSKOLER

SAMARBEID OM IKT-ARKITEKTUR FOR STATLIGE UNIVERSITETER OG HØYSKOLER Carl-Fredrik Sørensen, NTNU Bård Henry Moum Jakobsen, UiO Geir Vangen, UiO Jan Erik Garshol, BIBSYS Arild Halsetrønning, UNINETT 17. mars 2011 Oppdragsgiver: Kunnskapsdepartementet UNINETT Abels gate 5 Teknobyen NO-7465 Trondheim telefon: +47 73 55 79 00 faks: +47 73 55 79 01 e-post: info@uninett.no web: www.uninett.no

1 SAMMENDRAG Rapporten er resultatet av et forprosjekt for å utrede samarbeid om IKT-arkitektur for statlige universiteter og høyskoler. Oppdragsgiver er Kunnskapsdepartementet. Formålet med forprosjektet er å beskrive behovet for et samarbeid, oppgavene som bør gjøres i felleskap og hvordan samarbeidet best kan organiseres. Behovet for samarbeid beskrives gjennom noen konkrete eksempler og hvordan et samarbeid kan bidra til bedre IKT-løsninger til felles beste for hele sektoren. Rapporten definerer og beskriver noen sentrale arkitekturbegreper. Et viktig begrep som beskrives er virksomhetsarkitektur. Det beskriver helheten, dvs. hvordan IKTarkitekturen støtter virksomhetens behov. Fokus kun på IKT-arkitektur kan føre til manglende helhetstenking ved å løse arkitekturbehov i et bestemt prosjekt, og ikke se muligheter og konsekvenser på tvers av prosjekter og bruksmessige behov. Vi anbefaler at et samarbeid i sektoren omfatter virksomhetsarkitektur, med IKTarkitektur som en del av dette. Det anbefales at alle institusjonene deltar i arkitektursamarbeidet. Retningslinjer og prinsipp som skapes gjennom samarbeidet må ha god nok forankring hos institusjonene og bli oppfattet som så nyttige at de blir fulgt. I tillegg til fagpersoner innenfor arkitektur, må derfor også personer som kan skape tilstrekkelig forankring gjennom sin stilling i egen organisasjon delta aktivt i samarbeidet. Det foreslås derfor en todelt organisering av arkitektursamarbeidet i sektoren, en styringsgruppe, kalt arkitekturråd, og en kjernegruppe for arkitekturarbeid. Arkitekturrådet bemannes av fagdirektører fra økonomi, personal, forskning, studier og IKT. Kjernegruppen er den utførende enheten i samarbeidet og bemannes med fagpersoner innenfor arkitektur. I tilegg kan denne på prosjektbasis suppleres med personer som arbeider innenfor det aktuelle prosess- eller fagområdet. For å sikre tilstrekkelig forpliktelse i forhold til nødvendig ressursavgivelse, foreslås det at kjernegruppen finansieres gjennom sentrale midler. Rapporten beskriver også en plan for etablering av samarbeidet, og prioriterte oppgaver som må gjennomføres deretter. For å undersøke hva andre gjør innenfor området, har forprosjektet hatt møter med Statoil, Difi og KITH (Kompetansesentret for IT i helsevesenet). Vedlegg 2 inneholder referat fra disse møtene som bekrefter et inntrykk av at mange har stor aktivitet innenfor arkitekturområdet. Side 2 av 44

INNHOLD 1 SAMMENDRAG... 2 2 BAKGRUNN OG MÅL... 4 3 OM BEHOVET FOR SAMARBEID... 6 3.1 INNLEDNING... 6 3.2 REGISTRERING AV PERSONER MED LØS TILKNYTNING TIL INSTITUSJONENE.... 7 3.3 ARKIVSYSTEM OG NOARK 5... 8 3.4 EFFEKTIVISERING AV SENSURPROSESSEN... 9 3.5 DATAVAREHUS...11 3.6 BIBLIOGRAFISK INFORMASJON...13 3.7 SYSTEM FOR UNDERVISNINGSSTØTTE...14 3.8 UTVIKLING AV GJENBRUKBARE TJENESTER OG KOMPONENTER...15 3.9 OPPSUMMERING...18 4 ARKITEKTURBEGREPER... 19 4.1 HVA ER ARKITEKTUR?...19 4.2 ULIKE ARKITEKTURRAMMEVERK...20 4.3 DEFINISJONER AV ORD OG UTTRYKK...20 5 OPPGAVER I ARKITEKTURSAMARBEIDET... 24 5.1 INNLEDNING...24 5.2 OPPGAVEBESKRIVELSER...24 6 ORGANISERING OG FINANSIERING AV SAMARBEIDET... 27 6.1 ORGANISERING...27 6.2 FINANSIERING AV ARBEIDET...28 7 PLAN FOR ETABLERING AV SAMARBEIDET... 30 VEDLEGG 1 KORT INNFØRING I TOGAF 9... 33 1.1 KJERNEKONSEPTET - ADM...33 1.2 VIRKSOMHETENS CONTINUUM...33 1.3 FIRE ASPEKT VED ARKITEKTUR...34 1.4 UTVIKLING FRA INFORMASJONSARKITEKTUR MOT VIRKSOMHETSARKITEKTUR...34 1.5 VIKTIGE LEDETRÅDER VED ARKITEKTURARBEID...35 1.6 TOGAF ADM METODEN...35 VEDLEGG 2 - OPPSUMMERING FRA MØTER MED EKSTERNE... 40 Side 3 av 44

2 Bakgrunn og mål Universitets- og høyskolesektoren har lang tradisjon for samarbeid på IKT-området, spesielt innefor felles administrative systemer og nettverk. Det er systemer som er felles for hele sektoren, som BIBSYS og FS, og systemer som er innkjøpt i fellesskap og brukes av store deler av sektoren, som Agresso, SAP HR og Ephorte. Det er imidlertid i flere sammenhenger påpekt at det mangler en felles, overordnet strategi og arkitektur for utvikling og/eller innkjøp av slike systemer. For blant annet å utrede hvordan samarbeidet kunne videreutvikles til også å omfatte arkitektur, etablerte Administrasjonsutvalget i UHR i 2007 en prosjektgruppe. Gruppen leverte sin rapport 1 (Aagedalrapporten) våren 2009 med blant annet følgende anbefalinger: Det må utvikles en felles IKT-arkitektur for sektoren Det må bygges løsninger for integrasjon mellom IT-systemene på en mer helhetlig måte gjennom etablering av en integrasjonsplattform Prosjektgruppen foreslo at ansvaret for å etablere en slik forpliktende samordning ble lagt til et nytt organ med arbeidstittel UHIS. Resultatet av høringsrunden i sektoren ga stor tilslutning til gruppens anbefalinger vedrørende mer samordning, men liten tilslutning til å etablere et nytt organ. Dette ble blant annet begrunnet med at sektoren allerede har UNINETT og UNINETT FAS og at det lett vil bli en uoversiktlig situasjon med flere samarbeidsorganer. Det ble derfor enighet om å utrede UNINETT alternativet og i mer detalj hvilken samordning sektoren har behov for. På bakgrunn av dette, bestilte Administrasjonsutvalget høsten 2009, en utredning fra UNINETT der det ble bedt om en beskrivelse av hvordan UNINETT kan ivareta de behovene som Aagedalrapporten og høringsrunden skisserer. UNINETT leverte sitt svar i januar 2010. UHR etablerte en ad hoc-gruppe for å behandle UNINETT sitt svar og for å foreslå videre tiltak. Denne gruppens innstilling ble lagt frem for Administrasjonsutvalget i mai 2010. En sentral del av innstillingen var et forslag om å etablere et arkitekturråd oppnevnt av KD etter forslag fra sektoren ved UHR, med UNINETT som sekretariat. Det ble også gitt et forslag til mandat for et slikt arkitekturråd. Behandling av dette forslaget konkluderte med at sektoren ikke ønsker et arkitekturråd opprettet av KD, men må underlegges institusjonene gjennom UHR. Rollen til et arkitekturråd må være å gi gode faglige råd, ikke å ta avgjørelser på vegne av institusjonene. Videre var det enighet om at forslaget til mandat var for ambisiøst og må dempes noe. Ad hoc-gruppen ble bedt om å utarbeide et nytt forslag som tar hensyn til dette. 1 Aagedal m.fl.: Strategi, organisering og styring av de felles administrative systemene i UH-sektoren Side 4 av 44

Parallelt med at ad hoc-gruppen arbeidet med et revidert forslag, ble UNINETT og KD enig om å gjennomføre et forprosjekt for å utrede et formalisert samarbeid om IKTarkitektur i sektoren. Denne rapporten er resultatet av dette forprosjektet. Formålet med forprosjektet er å lage et beslutningsunderlag for å etablere et formalisert samarbeid om IKT-arkitektur i sektoren. Dette skal gjøres gjennom å beskrive innholdet i og organisering av et slikt samarbeid. Videre skal det legges vekt på å beskrive nytten av et slikt samarbeid for den enkelte institusjon og hvilken konsekvens en deltakelse vil ha for institusjonens eget arbeid med IKT-arkitektur - og styring av denne. Dette samarbeidet kan omfatte alle IKT-relaterte aktiviteter i sektoren og ikke bare de administrative systemene som var utgangspunktet for Aagedalrapporten. KD er oppdragsgiver for arbeidet og beslutter eventuelle videre tiltak på bakgrunn av innholdet i rapporten i samråd med institusjonene og UNINETT. Side 5 av 44

3 Om behovet for samarbeid 3.1 Innledning Det som hittil har skjedd og som er oppsummert som del av bakgrunnen, viser at det er stor enighet om behovet for et samarbeid på tvers av løsninger i sektoren og mer spesifikt om IKT-arkitektur. Utfordringen er å bli enige om et innhold i og organisering av et slikt samarbeid som vektlegger den positive effekten og som samtidig i stor nok grad opprettholder retten til selvbestemmelse for den enkelte institusjon. På overordnet nivå er et samarbeid om IKT-arkitektur en naturlig konsekvens av og en nødvendighet ut fra at det allerede er et utstrakt samarbeid om felles løsninger i sektoren. Et samarbeid om IKT-arkitektur vil kunne bidra til å Legge til rette for at IKT enheter på en effektiv måte kan støtte opp om nye/endrede virksomhetsprosesser Forenkle og effektivisere integrasjon mellom, og rapportering fra de ulike løsningene Redusere de totale IKT kostnadene Operasjonalisere Difi s overordnede arkitekturprinsipper Legge til rette for felles tilnærming til offentlige forskrifter og standarder Hindre fremvekst av lukkede systemer ( silosystemer ) med overlappende funksjonalitet og informasjon Forenkle og effektivisere skreddersydd/portalbasert tilgang til funksjonalitet og informasjon gjennom standardiserte tjenester og grensesnitt I tildelingsbrevene til institusjonene understreker Kunnskapsdepartementet viktigheten av SAK (samarbeid, arbeidsdeling, konsentrasjon). For at sektoren samlet skal få en god utvikling, påpekes det spesielt at de høyere institusjonene må ta andre institusjoner i betraktning i sine strategiske valg. Den enkelte institusjon oppfordres til aktivt å søke gode og effektive løsninger for samarbeid og arbeidsdeling med andre høyere utdannings- og forskningsinstitusjoner for å realisere målene om konsentrasjon og styrking av fagmiljøer. Vi mener at et samarbeid om IKT-arkitektur vil være et viktig element for å møte slike krav. Det gjøres for tiden store endringer i organisering av sektoren gjennom sammenslåinger og ulike samarbeid på tvers av institusjoner. Et samarbeid om arkitektur vil gjøre slike endringer enklere å gjennomføre. Et område det også kan være rasjonaliseringsgevinst å hente er ved et samarbeid om sektorens tilnærming til overordnede felles rammebetingelser, gitt ved de lover, offentlige forskrifter og standarder sektoren er underlagt. Det er få grunner til at den enkelte Side 6 av 44

institusjon skal etablere egne fortolkninger og implementeringer, man bør søke fellesløsninger for dette. For å synliggjøres effekten av et slikt samarbeid, beskrives konkrete eksempler fra sektoren. I eksemplene er det lagt vekt på å beskrive utfordringene som finnes, og hvordan et samarbeid om IKT-arkitektur kan møte disse utfordringene. 3.2 Registrering av personer med løs tilknytning til institusjonene. Alle institusjonene innen UH-sektoren har i dag mer eller mindre velfungerende rutiner for registrering, oppdatering og avvikling av personer som innehar rollen som student eller lønnsmottaker ved institusjonen. Disse er gjerne dokumentert knyttet til institusjonens sentrale personalavdeling og studieavdeling, og utføres i et av institusjonens autoritative system for persondata, personalsystemet eller studentregisteret. Et felles trekk ved våre institusjoner er at det finnes en betydelig gruppe som ikke passer inn under definisjonen av student eller ansatt. Eksempel på personer som faller inn under dette: Gjesteforelesere Gjesteforskere Eksterne konsulenter Eksterne vikarer (eks: Manpower el). Eksternfinansierte ansatte (eks: Ansatte i Kreftforeningen) Ansatte i eksterne institusjoner som man har nært samarbeid med Eksterne studenter Alumni osv. Felles for disse er at det foreligger en forventning om at de fleste personer av denne typen relativt enkelt skal kunne få tilgang til ulike ressurser ved institusjonen. Dette kan være ressurser i form av: tilgang til bygg eget kontor/kontorplass telefon tilgang til elementer av IKT-infrastrukturen som o nett o e-post o autentisering o autorisasjon osv Side 7 av 44

Disse forventningene kan ikke oppfylles uten at institusjonen skaffer seg informasjon om den enkelte, og i mange tilfeller inngå avtale om hva institusjonen skal bidra med. Det er i dag ingen felles løsning for hvordan slike personer skal registreres, dvs. i hvilket system og på hvilken måte. De ulike løsninger som er etablert ved enkelte institusjoner, dekker heller ikke alle varianter som finnes innen denne gruppen personer. Samlet for sektoren bør det etableres en felles modell for løsning, en modell som gjør at sikkerheten i identifisering av den enkelte ivaretas lokalt og kan målbæres på nett gjennom løsninger som Feide. Denne gruppen bidrar også til å gjøre lisensarbeidet ved institusjonen juridisk vanskelig ettersom man normalt gir alle identifiserte brukere ved institusjonen tilgang til generelle tjenester, samtidig som en del av disse tjenestene forutsetter at man har en formell tilknytning til institusjonen (i form av å enten være ansatt eller student). Gjennom drøftinger i et felles organ, vil man kunne komme frem til et sett med anbefalte rutiner/prosedyrer for denne gruppen personer, og få disse akseptert på tvers innen sektoren. Man kan også etter etablering av en slik anbefaling, se på om ikke de institusjonene som følger denne også skal kunne få disse personene inn i Feide for institusjonen. 3.3 Arkivsystem og Noark 5 Samhandling mellom fagsystemer og arkivsystem på institusjonene er en problemstilling som mange parter diskuterer, uten at det er noen samordning av dette på tvers av fagsystemene. Dette er et eksempel på et område som raskt fører til fremvekst av siloer der prosesstøtte og arkiv løses lokalt i det enkelte fagsystem. Noark 5 tilbyr en arkivkjerne som inneholder den minimumsfunksjonaliteten som kreves for at et system skal kunne fungere som et arkivsystem etter Noark 5-standarden. Med kjernen følger det med grensesnitt som fagsystemer kan benytte for å kommunisere med arkivsystemet, f eks for å laste opp dokumenter. Noark 5 kan implementeres på ulike vis. Det er tre hovedmodeller: 1) Hvert fagsystem har hver sin Noark 5-kjerne, som tilfredsstiller krav til å selv være et arkivsystem. 2) Noark 5-kjerne som del av et arkiv og saksbehandlersystem (som for eksempel ephorte). Fagsystemene må da kunne kommunisere med saksbehandlersystemet. 3) En selvstendig Noark 5-kjerne som både arkiv/saksbehandlersystem og fagsystem kommuniserer med. Side 8 av 44

For fagsystemer er det nødvendig å kunne gjenfinne saker som gjelder enkeltpersoner. Det er behov for enighet på tvers av institusjoner om hvordan saker, studenter og ansatte identifiseres i arkivsystemet. Støtte for saksbehandling og riktig (lovmessig) arkivering trengs for alle fagsystemer, og rutinene må være så tydelig at ikke saksbehandler må være i tvil om hvor informasjon skal måtte lagres. Dette forutsetter at fag- og støttesystemer skal kunne kommunisere med arkivsystemene via standard grensesnitt. Et felles organ kan utarbeide retningslinjer på tvers av institusjonene om en overordnet arkitektur for arkivsystem. 3.4 Effektivisering av sensurprosessen Mange av de administrative arbeidsprosessene har fortsatt preg av papirbaserte, manuelle rutiner, med manglende it-støtte. En slik arbeidsprosess som omfatter stor ressursinnsats ved alle institusjonene, er sensurering av eksamener og oppgaver. Dette er en prosess som er nokså lik på tvers av institusjonene, der fagpersonale og administrasjon utfører mange manuelle oppgaver basert på papir eller elektroniske dokumenter. Noen av disse oppgavene medfører dobbeltarbeid, og det inngår mye manuell kvalitetssikring i denne prosessen. Side 9 av 44

Pakker med eksamensbesvarelser Protokollrapport fra FS Sensurveiledning Reg. i FS Kontroll(reg) Protokollføre kunngjøringsdato Arkivere besvarelser og protokoll Sensor/ faglærer (Sam)sensur Føre protokoll Signere Sende til eks. kontor SMS/e-post om at sensur er klar Student Innsyn i resultater (studentweb) Figur 3.1 Sensurprosessen Figuren viser en forenklet skisse over sensurregistreringsprosessen. Begrunnelse og klage er ikke inkludert her, men vil være naturlig å se på i denne sammenheng. I dag tilbys få digitale hjelpemidler for å støtte sensurprosessen. Etter mottak av sensur fra kommisjon, må administrasjonen registrere resultatene i FS. Heller ikke den etterfølgende prosess med begrunnelse og klage gis noen støtte, og vil kunne bli nokså ineffektiv siden denne avhenger av den enkelte sensors egne rutiner. Det kunne derfor vært et behov for et eget verktøy til bruk av kommisjonen i sitt arbeide med sensurering. Et slikt verktøy ville også kunne legge til rette for senere arbeid med begrunnelse. For å få til en prosess der et sensureringsverktøy står sentralt, må det lages tjenester mot flere systemer for deling av informasjon. Et støttesystem for sensurering kan inkludere spesifikasjon av selve sensuren av oppgaver. Dette gjelder spesielt for fleroppgaveseksamener der de forskjellige deloppgavene har en prosentvis vekt i eksamen. Dette kan eksemplifiseres ved ett oppgavesett med fire oppgaver med vekt 10 %, 30 %, 20 %, 40 %, der deloppgaver innenfor hver oppgave også har individuell vekt. Fra FS må informasjon om kommisjonssammensetning og kandidater kunne leveres til sensureringsverktøyet. Når sensuren er registrert, må denne kunne overføres til FS. For å effektivisere den etterfølgende kontrollprosessen, bør sensuren kunne signeres digitalt av kommisjonsmedlemmene. Dermed vil det ikke være behov for manuell registrering og Side 10 av 44

administrativ kontroll av det enkelte resultat. Sensurlister vil videre også kunne arkiveres digitalt, og behov for papirbasert arkivering bortfaller. Eksemplet over beskriver en virksomhetsprosess som i større eller mindre grad er felles, både innenfor og mellom institusjoner i UH-sektoren. Det vil være hensiktsmessig å utvikle en arkitektur som spesifiserer tjenester for hele eller deler av sensurprosessen med tanke på å etablere grensesnitt mellom de forskjellige systemene som inngår som en del av prosessen. Sett fra sensor, faglærer og studenten sitt synspunkt, vil det være prosessstøtten og måten informasjon blir formidlet på, som vil være viktigst for å effektivisere og optimalisere samhandling og presentasjon. Samarbeid om etablering av grensesnitt, tjenester og systemer vil være kostnadsbesparende både på kort og lang sikt ved at man etablerer standarder og systemuavhengige måter å kommunisere på. Et organ for arkitektursamarbeid vil kunne gi overordnede retningslinjer for samhandling mellom systemer. Det er her behov for digitale signaturer, noe som forutsetter felles løsninger på tvers av systemer. Også samhandling med arkivsystemer inngår i prosessen, noe som også forutsetter felles retningslinjer for integrasjon mot elektronisk arkiv. 3.5 Datavarehus Datavarehus er betegnelsen på en type databasesystem som søker å organisere data på en tematisk rettet måte. Med andre ord, å strukturere dataene/infrastrukturen slik at de egner seg for analytisk behandling. (kilde: Wikipedia) Kilder for informasjon som benyttes i datavarehus ligger som regel i fagsystemer, for eksempel FS, økonomisystemer, personal/lønnssystemer, etc. For å bygge ett datavarehus, må det etableres informasjonsmodeller som kan ivareta både informasjonsmodeller i kildesystemene og samtidig kunne benyttes til andre formål tilknyttet for eksempel virksomhetsstyring, budsjettering, rapportering etc. Informasjonsmodeller inngår som en naturlig del av en informasjonsarkitektur. Informasjonsarkitektur er en fagdisiplin som har som viktigste aktivitet å beskrive en modell eller et konsept for informasjon. For systemer og teknologier kan formålet være å gjøre informasjonen håndterbar for eksempelvis søkemotorer, publiseringsverktøy eller databaser. Side 11 av 44

Fig. 3.1 Datavarehus Figuren over viser en skisse over sammenhengen mellom kildesystemer, datavarehus og presentasjoner. ETL er betegnelsen på verktøy benyttes for å flytte data fra kildesystemer til datavarehus. Data kan lastes inn i ett generelt datavarehus basert på en standardisert informasjonsmodell og/eller til temavarehus (DataMarts). Temavarehus lages normalt for spesifikke formål/forretningsprosesser basert på forretningsmessige behov eller tema. I UH-sektoren vil forretningsbehov og prosesser ofte være sammenfallende for de forskjellige institusjonene. Dette gjelder spesielt offentlig rapportering og i forhold til økonomi og studieadministrative prosesser hos den enkelte enhet. Datavarehustankegangen representerer en synsvinkel for hvordan man kan organisere informasjon for tilgjengeliggjøring i forretningsprosesser Grunnlaget for ett datavarehus ligger i kildesystemene som benyttes til mer spesifikke forretningsprosesser. Det vil derfor være viktig å kunne ha et omforent bilde av hvilke informasjonselementer som ligger i kildesystemene og hva disse betyr modellmessig. Felles utvikling av disse elementene, vil gi ett grunnlag for en felles informasjonsarkitektur og en delvis felles integrasjonsarkitektur, noe som kan spare ressurser for alle enheter i sektoren. Et felles organ kan koordinere standardisering av sektorens informasjonsmodeller gjennom innsamling av informasjon rundt hvilke systemer inneholder hvilke data og hvilke er autoritative. I samarbeid kan et felles organ etablere en konsensus for en felles informasjonsarkitektur i sektoren. Side 12 av 44

3.6 Bibliografisk informasjon Lagring og tilgjengliggjøring av elektroniske dokument og bibliografisk metadata er et viktig område i sektoren, for eksempel i forbindelse med vitenskaplige publikasjoner. Første gangs registrering av bibliografiske metadata for vitenskaplige publikasjoner skjer (eller skal skje) som regel i Cristin. Disse metadataene blir så registrert i åpne publiseringsarkiv og i biblioteksystemet. Dermed finnes allerede tre ulike forekomster av de samme bibliografiske dataene - med små variasjoner. I Norge er NORA (Norwegian Open Research Archives) etablert for å samle (ofte omtalt som høste) alle bibliografiske data fra de ulike arkivene, slik at alle relevante dokument blir søkbare på en plass. Dette blir den fjerde forekomsten av de same bibliografiske dataene. Selve dokumentet blir lagret i det åpne publiseringsarkivet, men vil i mange tilfeller være av interesse for Nasjonalbiblioteket og vil derfor bli lagret der også. Dermed blir også dokumentet duplisert. I figuren under er dataflyten vist som Dokument og Bibliografiske data, igjennom ulike trinn. Figuren er delvis et bilde på dagens situasjon og delvis et ønsket senario. Vitenskaplig publikasjon 1 D og B registreres 1 D og B registreres Cristin 2 D og B høstes 6 - B eksport BIBSYS Bibl.sys. 4 - B registreres manuelt Nora 3 - B høstes Åpent Publiserings arkiv 5 D høstes eller avleveres Nasjonalbiblioteket Side 13 av 44

Figuren viser at vi har en komplisert systemstruktur med mange systemer som har delvis overlappende funksjonalitet og som baseres seg på de samme informasjonstypene. Cristin har som hovedoppgave å rapportere vitenskaplig publisering til KD. Åpne publiseringsarkiv lagrer institusjonens vitenskaplige publikasjoner og gir fri tilgang til disse. NORA er en felles inngang til innholdet i åpne publiseringsarkiv i Norge. BIBSYS Biblioteksystem organiserer bibliotekenes beholdninger og tilbyr både søk og tilgang til disse. Nasjonalbiblioteket har en langtidsbevarings- og tilgangsoppgave. Da åpne publiseringsarkiv er administrative system er det lite å hente for institusjonene på å konkurrere om å ha det beste, spesielt når alle unntatt to institusjoner i UH-sektoren bruker DSpace. Sektoren har i dag minst fem ulike realiseringer av DSpace i produksjon 1. For alle praktiske formål så er disse systemene tilnærmet identiske. Majoriteten av sektoren bruker et felles system (BIBSYS Brage), også basert på DSpace. Unntaket er NTNU og UiO, som begge har et system med tilsvarende funksjonalitet men ikke basert på DSpace. DSpace baserte systemer finnes også i tilgrensende sektorer - for eksempel innen helsesektoren. Begge sektorene har sammenfallende krav til åpne publiseringsarkiv. Det er igangsatt anskaffelse av et nytt biblioteksystem for staten. Dette vil i økende grad importere metadata fra alle større forlag og utgivere. Cristin importerer i dag metadata fra ISI, biblioteksystemet og Nasjonalbiblioteket. Dermed vil mengden av delvis duplisert informasjon øke. Det er duplisering av informasjon og mangel på definerte autoritative kilder (masterdata) som forårsaker dagens situasjon, der problemene vil vokse de nærmeste årene ved realisering av nytt biblioteksystem og Cristin. Sektoren mangler i dag en samarbeidsfunksjon som kan gå inn i pågående prosesser, se helheten og gi råd før lokale grupper binder besluttende organ. Et slikt samarbeid vil kunne gi faglige råd på rett tidspunkt før viktige beslutninger i prosjektgjennomføringen. 3.7 System for undervisningsstøtte IKT-system for undervisningstøtte (LMS) inneholder funksjonalitet for å administrere og å støtte gjennomføring av undervisningen. Slike system (for eksempel Fronter og Its Learning) er i bruk ved alle institusjoner. 1 ODA/HiO, Bora/UiB,HiB,NHH, Munin/UiT, Teora/HiT og BIBSYS Brage Side 14 av 44

Erfaring fra sammenslåingen av Universitetet i Tromsø og Høgskolen i Tromsø (ref. Øyvind Edvardsen) tyder på at slike systemer brukes noe forskjellig med bakgrunn i institusjonenes egenart ved at et universitet har fokus på emner mens en høgskole har fokus på studieprogram og kull. Konsekvensen av dette er at selv om disse hadde samme system (Fronter) hentet de ulike data fra FS. Det viste seg derfor at selv om disse to hadde samme LMS-system, medførte sammenslåingen mange og tunge utfordringer dels knyttet til selve systemet og dels knyttet til nødvendigheten av å harmonisere de to ulike synsvinklene nevnt ovenfor (emner kontra studieprogram og kull). Når det gjelder grensenittet mellom FS og Fronter, er denne etter hvert blitt standardisert. Det finnes imidlertid fremdeles en del ulike grensesnitt rundt omkring som delvis er laget før standarden ble etablert, og delvis på grunn av at standarden ikke passer helt til behovet, blant annet når det gjelder behovet for fokus på studieprogram og kull. Funn som er gjort i en undersøkelse 1 utført ved NTNU, tyder på at LMS-systemene inneholder mye funksjonalitet som er i lite bruk. Dette gjelder spesielt funksjoner tenkt å gi en pedagogisk eller fagdidaktisk støtte. Det viser seg også at på noen av områdene tas det i bruk andre, mer utbredte løsninger med tilsvarende funksjonalitet (Wiki, diverse Google verktøy, MSN, doodle, Facebook, etc.). Denne situasjonen har skapt en diskusjon om det ikke er fornuftig å rendyrke kjernefunksjonalitet i LMS-systemene (administrasjon av emner og studieprogram) og løse øvrige behov ved hjelp av mer utbredte løsninger som kan oppfattes som mer brukervennlige. Det er behov for et samarbeid i sektoren som kan etablere en felles kjernefunksjonalitet i LMS-systemene med tilhørende standardisering av grensesnitt mot aktuelle fagsystemer slik som FS og ulike standardsystemer (Wiki, diverse Google verktøy, MSN, doodle, Facebook,..), som kan tenkes brukt som del av undervisningen. 3.8 Utvikling av gjenbrukbare tjenester og komponenter Tradisjonelle systemer er gjerne koblet tett sammen slik at data/informasjon er direkte knyttet til prosessering og visning av data, dvs. at systemene er organisert som siloer. Gjenbruk av informasjon og funksjonalitet har derfor vist seg vanskelig siden det eksisterer så mange avhengigheter mellom datamodell, funksjonalitet og brukergrensesnitt. Dette illustreres gjennom flere eksempler i dette kapitlet. Økt gjenbruk av forskjellige deler av systemer har både en økonomisk og praktisk effekt: Reduserer duplisering av informasjon, noe som gjør det lettere å konsolidere og kvalitetssikre informasjon. Komponenter kan brukes på tvers av flere systemer, kan ha stor kostnadsbesparende effekt både på utvikling og vedlikehold 1 Evalueringsrapport. Bruk av It s learning ved NTNU (juni 2010) Side 15 av 44

IT-systemer blir mer smidige i forhold til endringer i forretningsbehov og - prosesser Enklere tilgjengeliggjøring av applikasjoner/forretningslogikk på mange klientplattformer. Standardisering av grensesnitt, både for systemer og mot brukere. Forenkler integrasjon mellom systemer, både for informasjonstjenester og annen funksjonalitet Det er en trend innenfor virksomheter at man ønsker å samle alle forretningsapplikasjoner gjennom en felles web-basert forretningsportal. Arbeidsflyt og arbeidsflytverktøy fremstår som viktige elementer for å binde sammen systemer på en slik måte at ITverktøy kan yte tilfredsstillende støtte til de arbeidsprosesser som er definert, spesifisert og konfigurert for en gitt bruker og/eller brukerrolle. Fokusert arbeidsprosesstøtte tilpasset spesifikke brukere og/eller roller, vil gjøre de underliggende fag/støttesystemer mindre synlig. Dette betyr i praksis at det eneste systemet som brukeren ser er forretningsportalen og funksjonalitet og brukergrensesnittet som skal/kan tilbys vil være knyttet til brukeren og underliggende arbeidsprosesser. Operasjoner kan bli realisert i mange underliggende systemer uten at brukeren må forholde seg til hvert enkelt system. I en tjenestebasert IT-arkitektur vil fokuset endre seg fra spesifikke fagsystemer som støtter spesifikke arbeidsprosesser (IT-verktøy bestemmer arbeidsprosess), til en arkitektur som kan tilpasse seg til gjeldende arbeidsprosesser og virksomhetsbehov (arbeidsprosess bestemmer hvilke tjenester som må realiseres i verktøy). Disse prosessene kan bygges basert på tilgjengelig gjenbrukbare tjenester realisert gjennom sammensetning av funksjonalitet fra potensielt forskjellige undersystemer. En slik endring i gir mulighet til i større grad å forvalte hvordan informasjon og funksjonalitet blir generert, lagret, benyttet og gjenbrukt i virksomheten. Side 16 av 44

HR Økonomi FDV HMS Studieadm IKT og bibliotek Aksesskontroll Forskningsadm Organisasjon og samfunn Gjester, potensielle studenter, offentlig forvaltning, bedrifter, samarbeidspartnere, NFR, alumni etc. Ansatt Student Andre Brukertjenester Virksomhet Styrings- og ledelsesprosesser Arbeidsflyt Forskning Utdanning Nyskaping Formidling Kompetanse Forretningstjenester Applikasjon HR LMS Studentsystem Økonomi Datatjenester Strategi, Rammebetingelser, Behov, Sikkerhet, Lovgivning, Protokoller, Standarder Informasjon Data Data Data Data Data Data Semantikk, domenemodeller, fysiske datamodeller Figur 3.2 Tjenesteorientert arkitektur Figuren over viser en generisk tjenesteorientert arkitektur med fokus på forskjellige tjenestelag som ivaretar spesifikke oppgaver relatert til informasjon, forretningslogikk og presentasjon. Lagdelingen gir en naturlig separasjon av data og informasjon fra de applikasjonene som benytter disse, og for hvordan informasjon og funksjonalitet blir tilgjengeliggjort for brukeren. Applikasjonene tilbyr forretningstjenester som kan samles og konfigureres for spesifikke virksomhetsbehov definert gjennom virksomhetsprosesser og arbeidsflytverktøy. Brukeren kan gjennom forskjellige typer klienter, få tilgang til brukertjenester tilgjengeliggjort som arbeidsflyt gjennom en virksomhetsportal. Side 17 av 44

DIFI har utarbeidet en del generelle arkitekturprinsipper til statlige systemer. Disse spesifiserer en del egenskaper som moderne systemer bør inneha. Utvikling av en tjenestebasert strategi og arkitektur for IKT-utvikling vil imøtekomme de krav som er satt i forhold til en felles IKT-arkitektur i offentlig sektor (FAOS-rapporten, 2007). Et felles organ kan utarbeide retningslinjer slik at utvikling og innkjøp av nye applikasjoner og videreutvikling av eksisterende, tilpasses til å støtte en tjenesteorientert arkitektur som møter krav og prinsipper i forhold til gjenbruk, integrasjon, endringsmulighet og samhandling i sektoren 3.9 Oppsummering Gjennom eksemplene i dette kapitlet har det blitt synliggjort noen områder der UHsektoren gjennom et samarbeid om arkitektur, kan oppnå mer helhetlige og effektive IKT-løsninger. Tabellen viser hvordan et slikt samarbeid kan bidra til målsettingen som ble beskrevet tidlig i kapitlet. Eksempel Mål Registrering av personer (3.2) Operasjonalisere Difi s arkitekturprinsipp Forskrifter og standarder, felles tilnærming x Hindre silosystemer Skreddersydd/ portalbasert tilgang Effektiv integrasjon og rapportering Nye virksomhetsprosesser x Redusere totale IKT kostnader Arkivsystem og NOARK 5 (3.3) x x x x x Sensurprosessen (3.4) x x x x Datavarehus (3.5) x x x Bibliografisk informasjon(3.6) x x x x System for undervisningsstøtte (3.7) Utvikling av gjenbrukbare tjenester og komponenter(3.8) x x x x x x x x x For noen av eksemplene snakkes det om en effektivisering på et IKT-nivå gjennom en sanering og/eller samordning av eksisterende systemer. For andre er det snakk om å legge til rette for at IKT på en enda bedre måte kan støtte opp om virksomhetenes behov. Utgangspunktet er da endrede eller nye arbeidsprosesser i virksomheten og de krav disse stiller til utformingen av underliggende IKT-systemer. Et slikt arkitekturarbeid må omfatte mer en IKT-arkitekturen og gi en beskrivelse av helheten, dvs. hvordan de virksomhetsmessige behov på en effektiv måte kan betjenes av IKT. Side 18 av 44

4 Arkitekturbegreper 4.1 Hva er arkitektur? Ordet er avledet fra det latinske architectus, lånt fra det greske ordet arkhitekton - som betyr byggmester. Arkitektur blir ofte omtalt som moderkunsten, da den har helheten i fokus. Kilde:wikipedia 2010. I den betydning som arkitekturbegrepet er benyttet, så er det et ungt fagfelt. Noe som gjør at det er mange ulike definisjoner. En definisjon av Keen (1991) som også sier noe om fravær av arkitektur er: The technical blueprint for the corporate resource that can be shared by many users and services. This blueprint is how things fit together and so must concern itself with standards. The opposite of architecture is to select every element on a project by project basis. Kjernen i denne definisjonen er: tekniske skisser, sier noe om omfanget og gjensidige avhengigheter virksomhetens ressurser, sier noe om prioritering deling mellom mange, sier noe om fordeling og ansvar standarder, sier noe om hvordan ISO/IEC 42010: 2007 definerer arkitektur som: Den fundamentale organisering av ett system, konkretisert gjennom sine komponenter, deres relasjoner mellom hverandre og omgivelsene og de prinsipper som styrer systemets design og utvikling Andre relevante kilder til arkitektur er for eksempel ISO/IEC 9126-1 og ISO 25000 som begge omhandler karakteristikker og metrikker relatert til programvarekvalitet det vil si kvalitetsaspekter knyttet til ett system, eller system av systemer. Litt for mange organisasjoner har arkitekturer som er arvet; det er slik vi gjør det her, eller har ubevisst adopterte arkitekturer fra en eller flere systemleverandører, uten at de nødvendigvis passer organisasjonens strategi eller behov. Tilsvarende blir det hvis mange organisasjoner innen den samme sektoren har arkitekturer som er ubevisst valgt, da er det lite sannsynlig at disse organisasjonene underbygger sektorens intensjon om gjenbruk og samhandling på en best mulig måte. Det siste Keen sier om fravær av arkitektur er det viktigste siden arkitektur er noe alle systemer alltid vil ha. Fravær av en bevisst arkitektur vil bli en tilfeldig arkitektur. Hvert enkelt arkitekturvalg kan være bevisst, men totalen kan bli tilfeldig - siden Side 19 av 44

enkeltprosjekter eller systemer i en virksomhet kan velge strategier eller drivere som i beste fall kan være motstridende og i verst fall motarbeide hverandre 4.2 Ulike arkitekturrammeverk Selv om arkitektur som fagfelt relatert til IKT-systemer er forholdsvis ungt, så kan en spore samling rundt noen sannheter. Det finnes rammeverk som støtter både i valg av ulike prosesser for å komme fram til en arkitektur, og for å forme innholdet i arkitekturen. Sett fra et norsk ståsted, så er følgende publikasjonene relevante (i kronologisk rekkefølge): Leavitts diamant (1960) Zachmanns rammeverk (1987) The Open Group Architecture Framework, TOGAF (1995) US Clinger-Cohen Act (1996) IEEE's Arkitekturanbefalinger (2000) Offentlig Informasjon Online, OIO (2004) St.m. 17 om arkitektur i det offentlige (2007) Difi's Overordnede IKT-arkitekturprinsipper for offentlig sektor (2009) TOGAF er ansett som et nøytralt, komplett og modent arkitekturrammeverk fra publiseringen av versjon 9 i 2009. Dette rammeverket er derfor valgt som bakgrunn for bruk av ord og uttrykk i denne rapporten, uten at det av den grunn er en direkte anbefaling av TOGAF som rammeverk for UH-sektoren. Av de andre rammeverkene så er det spesielt Zachmann og OIO, sistnevnte er etablert av det danske Ministeriet for Videnskap, Teknologi og udvikling, som kan være relevante for bruk i sektoren. Zachmann er det eldste av de komplette og sektornøytrale rammeverkene og er mye brukt. OIO er et rammeverk spesielt tilpasset dansk offentlig sektor. Viktige fordeler med de sektornøytrale rammeverkene er bedre tilgang på kompetent arbeidskraft og overføringsverdien til andre sektorer i staten. 4.3 Definisjoner av ord og uttrykk TOGAF versjon 9 er kilden for definisjonene om ikke annet er oppgitt. Virksomhet (Enterprise): Enhver samling av organisasjon(er) som har felles mål. Dette kan være statsforvaltningsenheter, firma, avdelinger i et firma, en avdeling eller mange organisasjoner med felles eierskap. Arkitektur kan ha to meninger: 1. En formell beskrivelse av et system, eller en detaljert implementeringsplan som beskriver systemets ulike deler Side 20 av 44

2. En beskrivelse av strukturen til de ulike delene, deres gjensidige forhold og bakenforliggende prinsipp som styrer både design og utvikling over tid Arkitekturrammeverk: Et hjelpemiddel ved utvikling av arkitekturer. Rammeverket bør: 1. beskrive hvordan utforme et informasjonssystem i form av delsystem og vise hvordan disse forholder seg til hverandre 2. definere noen felles verktøy og definere et felles vokabular 3. inneholde en liste med anbefalte standarder og egnede produkter for å implementere de ulike delsystemene Dermed vil rammeverket gi praktisk støtte ved oppstart av en arkitekturaktivitet. Arkitekturdomener: TOGAF 9 skiller mellom fire ulike domener for arkitektur: 1. Forretningsarkitektur: Forretningsstrategi, styring, organisering og kjerne forretningsprosesser 2. Dataarkitektur: Strukturen til organisasjons logiske og fysiske data elementer og hvordan disse blir administrert. Dataarkitekturen er en realisering av en informasjonsarkitektur. 3. Programvarearkitektur: En skisse for det enkelte program i produksjon, dets integrasjon og relasjon med organisasjonens kjerneforretningsprosesser 4. Teknologiarkitektur: All nødvendig programvare og maskinvare for å støtte forretningsprosesser, data og tjenester. Dette inkluderer all infrastruktur, mellomvare, nettverk, kommunikasjon, utførelse og standarder Arkitekturprinsipp: Et målbart utsagn som gir intensjonen som arkitekturen skal oppfylle. Har i tillegg minst et rasjonale og en prioritering. Difi's overordnede IKTarkitekturprinsipper for offentlig sektor (2009) er et viktig eksempel. Programvare (Application): Et utviklet og operasjonelt IT-system som støtter en forretningsprosess. Den bruker data og er understøttet av mange andre teknologiske komponenter som ikke er en inkludert del av programmet. Side 21 av 44

Fig. 4.1 TOGAF rammeverket Programvarearkitektur: Samling av mange omsluttende aspekter av et system, inkludert primære beslutninger om organisering av systemet, de eksterne egenskaper som påvirker disse beslutningene, strukturen av de elementer som representerer organiseringen, grensesnittene på elementene, systemets oppførsel uttrykt som samarbeid mellom elementene, og sammensetningen av elementene inn i progressive delsystemer. (Kruchten,2009). Figur 4.1 viser strukturen i TOGAF rammeverket med de ulike domene og strukturen innenfor hver domene. Områder gjort uskarpe i figurene behandles ikke i denne rapporten. I vedlegg 1 gis en nærmere beskrivelse av TOGAF rammeverket. Virksomhetsarkitektur (Enterprise Architecture) er: 1. Logikken bak forretningsprosessen og IT-infrastrukturen som gjenspeiler integrasjon og standardiserte krav som former virksomhetens operasjonelle modell. Kilde: MIT Center for Information System Research 2. Eller: det konseptet som definerer struktur og operasjon i en organisasjon. Intensjonen til en virksomhetsarkitektur er å vise hvordan en organisasjon kan mest effektivt oppnå sine mål - både i nåtid og framtid. Kilde: SearchCIO.com Side 22 av 44

Av disse definisjonene framgår det at virksomhetsarkitektur omfatter helheten, det vil si alle arkitekturdomenene nevnt ovenfor. IKT-arkitektur utgjør således en del av denne helheten, dvs. teknologiarkitektur, programvarearkitektur og dataarkitektur. Som del av en slik helhetlig beskrivelse, vil det framgå hvordan IKT-arkitekturen støtter forretningsarkitekturen og det gir muligheter for en arkitektur der IKT på en mest mulig effektiv måte møter virksomhetens behov og raskt kan tilpasses nye behov. Side 23 av 44

5 Oppgaver i arkitektursamarbeidet 5.1 Innledning Både i kapitel 3 og 4 er det pekt på fordelen med at et arkitekturarbeid omfatter hele virksomheten og ikke bare IKT-systemene. Gartner [Forskingsnotat, ID nummer: G00206910] påpeker at begrepene IKT-arkitektur og virksomhetsarkitektur ofte brukes om hverandre og som oftest ved at begrepet IKT-arkitektur benyttes selv om det dreier seg om virksomhetsarkitektur. Fokus kun på IKT-arkitektur fører ofte til manglende helhetstekning ved å løse arkitekturbehov i ett bestemt prosjekt, og dermed ikke se muligheter og konsekvenser på tvers av prosjekter og bruksmessige behov. Vi anbefaler at et samarbeid i sektoren omfatter virksomhetsarkitektur, med IKT - arkitektur som en del av dette. Et arbeid med virksomhetsarkitektur vil omhandle både selve arbeidsprosessene eller forretningsprosessene, og hvordan disse støttes av den underliggende programvare- og teknologiarkitektur slik som definert i kapittel 4. Faren er at et slikt arbeid fort kan bli svært omfattende. En pragmatisk tilnærming der man forsøker å unngå å bli for detaljert og gjerne prioriterer å starte med et begrenset område av virksomheten, vil derfor være fordelaktig. Slik kan man bygge en felles arkitekturmessig beskrivelse og retningslinjer i område for område og dermed skape et felles fundament for sektoren. I neste delkapittel beskrives noen hovedoppgaver som må gjøres i et arkitektursamarbeid. 5.2 Oppgavebeskrivelser 5.2.1 Felles modeller og verktøy Et arbeid med å etablere arkitekturbeskrivelser må baseres på felles modeller og verktøy, for eksempel: - arkitektur rammeverk (TOGAF, Zachman, OiO,..) - modelleringsverktøy (Qualiware, ARIS, ) Oppgaven her blir å anbefale et valg for sektoren og legge til rette for en nødvendig kompetanseoppbygging for personer i sektoren som skal bidra i videre arbeid. Side 24 av 44

5.2.2 Pilot for bruk av valgt modell og verktøy Å beskrive sektorens virksomhet og hvordan IKT-systemene understøtter denne, både dagens situasjon (as-is) og ikke minst som en ønsket situasjon (to-be), er en svært omfattende oppgave. Erfaring viser at mange slike initiativ mislykkes fordi man starter en for omfattende beskrivelse og produserer en mengde dokumentasjon som aldri kommer til nytte. Det foreslås derfor å starte med noen få piloter. Disse kan enten velges horisontalt, for eksempel med fokus på informasjonsstruktur/arkitektur på tvers av virksomhetsområder og applikasjoner, eller vertikalt med fokus på et virksomhetsområde. 5.2.3 Fasemodell med sjekklister I tillegg til å etablere felles arkitekturmessige beskrivelser, prinsipp og retningslinjer, er det også viktig å sikre styring i forhold til disse. En måte å gjøre dette på, er å innføre en felles, overordnet fasemodell med sjekklister i forhold til aktuelle retningslinjer og prinsipp. Som et grunnlag, defineres noen felles, overordnede prosjektfaser som vist i Figur 5.1. Forutsetningen for å gå videre til neste fase er å besvare en sjekkliste, ref S1, S2, S3 i figuren. S1: Start planfase S2: Start spek. fase S3: Start implementering Forslagsfase Planfase Spesifikasjonsfase Implementering Figur 5.1 Faser og sjekkpunkter Sjekkliste S1 benyttes i en tidlig fase før et prosjekt er besluttet startet og inngår som en del av utformingen av et mandat. Sjekklisten her må spesielt ha fokus i forhold til andre systemer, for eksempel: Er behovsområdet klart definert? Er tilsvarende behov (evt. deler av) løst i eksisterende system? Er forholdet til andre system innenfor samme behovsområde klart definert? osv Sjekkliste S2 kan benyttes når detaljplan er utarbeidet og før spesifikasjonsfasen starter. På det tidspunkt vil man ha en enda større forståelse for sammenhengene, og spørsmålene fra S1 kan gjentas. I tillegg kan spørsmål som avdekker detaljer i forhold til grensesnitt og konsekvenser for interessenter og eksisterende systemportefølje. Side 25 av 44

Sjekkliste S3 kan inneholde spørsmål for utsjekk i forhold til felles arkitekturprinsipp og andre kvalitetskrav i sektoren. Oppsummert kan følgende skje som del av et samarbeid: etablere og innføre en overordnet fasemodell etablere sjekklister etablere et felles sted der maler og besvarte sjekklister kan lagres revisjon av sjekklister utarbeide anbefalinger/kommentarer til besvarte sjekklister Dette er tiltak som kan forbedres etter hvert som samarbeidet utvikles. Et eksempel er sjekkliste S3 som neppe blir god nok før sektoren har operasjonalisert Difi s arkitekturprinsipp for statlige virksomheter. Side 26 av 44

6 Organisering og finansiering av samarbeidet 6.1 Organisering UH sektoren består av mange selvstendige institusjoner av forskjellig størrelse og dermed behov. Dette gjør at rammebetingelsene for et arkitekturarbeid innen vår sektor er forskjellig fra en virksomhet der et slikt arbeid på en enklere måte kan gis et klart mandat og et krav om at rutiner og retningslinjer som er et resultat av arbeidet blir fulgt. Hovedfokuset i samarbeidet må være på områder der sektoren har felles virksomhetsmessig behov, og har eller kan ha felles IKT- løsninger. Retningslinjer og prinsipp som skapes gjennom samarbeid, må ha god nok forankring hos institusjonene og bli oppfattet som så nyttige at de blir fulgt. Det anbefales at alle institusjonene knytter seg til et slik samarbeid. For å utføre oppgavene som skal gjøres i samarbeidet, må det etableres en gruppe av fagpersoner innenfor arkitektur. For å sikre nytte av arbeidet, må i tillegg personer som kan skape tilstrekkelig forankring gjennom sin stilling i egen organisasjon, delta aktivt i samarbeidet. På denne bakgrunnen foreslås en todelt organisering av arkitektursamarbeidet i sektoren, en styringsgruppe, kalt arkitekturråd), og en kjernegruppe for arkitekturarbeid. Arkitekturrådet Arkitekturrådet bemannes med beslutningstagere fra sektoren, med UNINETT som sekretariat. Arkitekturrådet utarbeider selv forslag til mandat som godkjennes av deltakende institusjoner, UHR og Kunnskapsdepartementet. Det forventes ikke at mandatet vil innbære at arkitekturrådet kan utøve myndighet. Det er derfor viktig at arkitekturrådet får nødvendig tyngde og forankring i sektoren gjennom de som er medlem der. Arkitekturrådet møtes 5-6 ganger i året eventuelt flere ved behov. Antall medlemmer kan være 5-7 og bør bestå av CIO er (Chief Information Officer), IKT-direktører og ledere fra ulike virksomhetsområder i sektoren. Arkitekturrådet velger selv sin leder og bestemmer funksjonstider med planlagt utskifting av medlemmer som del av mandatet. I den første perioden vil arkitekturrådet sikre etablering av arkitektursamarbeidet ved å initiere og følge opp samarbeidsprosjekter og oppgaver, som beskrevet i Kapittel 5. Etter hvert antas det at fokus dreies mer over på å sikre at etablert, felles arkitektur blir fulgt. Side 27 av 44

Andre oppgaver vil være å sikre vedlikehold av arkitekturen, behandle avvik fra arkitekturen og å være eskaleringsnivå ved uenighet i sektoren. Det vil være viktig for arkitekturrådet å synliggjøre seg og å opprette god kontakt med andre styringsgrupper i sektoren, konsortier og paragraf 1.4.4 samarbeidstiltak. Tilsvarende også i forhold til Difi og andre sektorer i staten. Kjernegruppe for arkitekturarbeid Kjernegruppen skal sammen bygge nødvendig kompetanse innenfor arkitekturområdet og være sentral i utføring av de aktivitetene som prioriteres av arkitekturrådet. Gruppen bemannes av fagpersoner innenfor arkitektur fra institusjonene og UNINETT, til sammen 5-6 personer. Fortrinnsvis er dette personer som har en arkitekturrolle i egen institusjon. UNINETT kan eventuelt koordinere innspill og sikre innflytelse fra institusjoner som ikke kan bidra med personer som har tilstrekkelig med kompetanse og/eller ledig tid. Kjernegruppen kan ved behov på prosjektbasis knytte til seg ressurser. Kjernegruppen skal representere kundesiden, dvs. at grupperinger som representerer leveranser i intern regi (FS, Bibsys, etc.), ikke skal delta. Ansvarlige for slike leveranser skal imidlertid følge retningslinjer og prinsipp som er resultat av arbeidet i kjernegruppen, og ved behov trekkes inn i arbeidet som omhandler disse systemene. Kjernegruppen bør ha en leder som møter i arkitekturrådet. Det er viktig at kjernegruppen er synlig ovenfor og oppretter god kontakt med ulike prosjekter i sektoren. På en løpende basis skal gruppen ha ansvar for å: Forberede saker for arkitekturrådet Foreslå og gjennomføre aktiviteter besluttet i arkitekturrådet Bidra til kompetanseoppbygging og økt modenhet i forhold til virksomhetsarkitektur og utvikling basert på en felles IKT-arkitektur i sektoren Følge opp at arkitekturanbefalinger og -prinsipper blir fulgt Identifisere behov og muligheter for tjenester og komponenter som kan gjenbrukes, og gi anbefaling om styring av disse. En slik gruppe har behov for å arbeide tett sammen samtidig som de vil sitte geografisk spredt. Det er derfor viktig med gode samarbeidsløsninger både i forbindelse med fjernmøter og deling av informasjon. 6.2 Finansiering av arbeidet Kjernegruppen for arkitektur vil være den utførende enheten i samarbeidet. For oppnå formålet med samarbeidet, vil det være viktig med tilstrekkelig og forpliktende avgivelse Side 28 av 44