Virksomhetsarkitektur i NAV

Virksomhetsarkitektur i NAV Februar 2016 Versjon 100 ARBEIDS OG VELFERDSETATEN Postadresse: Postboks 5, St. Olavs plass // 0130 OSLO Besøksadresse: Økernveien 94 Tel: 21 07 00 00 // Faks: 21 07 00 01 www.nav.no //

Side: 2 av 21 DOKUMENTINFORMASJON Endringslogg Versjon Dato Kapittel Endringsbeskrivelse Produsent Godkjenningslogg Versjon Navn Dato 100 Sigrun Vågeng, Arbeids- og velferdsdirektør 17.02.2016 2

Side: 3 av 21 INNHOLDSFORTEGNELSE 1 INNLEDNING... 6 2 VIRKSOMHETSARKITEKTUR I NAV... 7 Hvorfor utvikle virksomhetsarkitektur?... 7 Hva omfatter virksomhetsarkitektur i NAV?... 7 Rammer og avgrensninger... 7 3 INTERESSENTANALYSE... 8 4 METODE... 10 En utviklingsorientert virksomhetsarkitektur... 12 Virksomhetsarkitektur beskrives med modeller... 13 Iterativ arkitekturutviklingsmetode... 16 Verktøystøtte og format... 16 5 ARKITEKTURSTYRING... 17 Roller ved utvikling av arkitekturmodeller... 18 Roller og ansvar knyttet til arkitekturbeslutninger... 19 Porteføljeplanlegging, konseptutvikling og prioritering... 20 Arkitekturstyring av prosjekt... 21 6 VEDLEGG 1: VIDERE ARBEID MED VIRKSOMHETSARKITEKTURFEIL! BOKMERKE ER 3

Side: 4 av 21 Begrep Forklaringer 1 Virksomhetsarkitektur En helhetlig beskrivelse av virksomhetens strategi, struktur, sammenhenger og planer. I NAV blir beskrivelsen strukturert i følgende områder: Forretningsarkitektur beskriver mellom annet strategi, rammer, lover, regler, brukere,, organisasjon, lokasjoner og prosesser, samt relasjoner mellom disseoversiktene.. Informasjonsarkitektur beskriver virksomhetens informasjon, informasjonsstruktur og informasjonsressurser, som begreper, og informasjonskilder samt hvordan disse er implementert i applikasjoner og prosesser. Applikasjonsarkitektur beskriver IT-systemene, hvordan de samvirker med hverandre og med forretningsprosesser Teknologiarkitektur hvor applikasjoner kjører og tjenester gjøres tilgjengelige for brukere Sikkerhetsarkitektur beskriver mellom annet beredskap, fysisk sikkerhet og informasjonssikkerhet Styringsarkitektur beskriver NAVs styringsmekanismer Løsningsarkitektur Løsningsarkitektur er ofte brukt om en IKT-løsning, men i dette dokumentet utvides begrepet til å omfatte informasjonsarkitektur og forretningsarkitektur. Løsningsarkitektur dekker en avgrenset løsning som blir realisert gjennom et utviklingstiltak eller et prosjekt. Den er nyttig for å omforme funksjonelle og ikke-funksjonelle krav til en konkret, samlet beskrivelse av hva som skal leveres, og hvordan det skal leveres. Løsningsarkitektur beskriver en helhet av forretningsmessige elementer som organisasjon, prosesser og brukergrupper, informasjonsarkitektur, regler, applikasjoner og teknologi. Arkitektur Perspektiv Utviklingstiltaket kan for eksempel være å implementere ny kontorstruktur, da beskriver løsningsarkitekturen hvilke lokasjoner som blir omfattet av endringen, hvilke lokasjoner det skal være kontor på etter at tiltaket er gjennomført, og alle nødvendige endringer i prosesser, organisasjonsstruktur, regelverk og applikasjoner som følger av tiltaket. Arkitektur forstås ofte som bygningsarkitektur, men kan også benyttes om arkitektur i musikk, i matematikk eller for skip. Begrepet arkitektur kan defineres som: 1. En formell beskrivelse av et system, eller en detaljert plan for systemets komponenter, som veileder ved implementering 2. Komponenters struktur og relasjoner, prinsipper og retningslinjer for komponentenes design og utvikling Et perspektiv er det stedet du ser fra (som bestemmer hva du kan se). 1 Der det er mulig benyttes definisjon fra standardene TOGAF eller Archimate. Det er mange begrep innen arkitektur, og for å øke lesbarheten vil de fleste begrep defineres i løpende tekst sammen med en figur. 4

Side: 5 av 21 Modell Modellering Interessent Interesse Styringsstruktur Strategi Utviklingsinitiativ Prosjekt Aktør Rolle Rammeverk Metode Se også TOGAF: Viewpoint Perspektivet spesifiserer hvordan en modell eller serie av modeller skal lages. En modell er det du ser. En modell er en forenklet fremstilling av virkeligheten. Den benyttes til å kommunisere og forstå vesentlige forhold sett fra et bestemt perspektiv. En modell kan uttrykkes i mange ulike format, figur, tabell, dokument, fysisk. (Se også TOGAF: View / Model) Arbeidet med å utvikle modeller. En person eller en liten gruppe som har interesser eller krav til en løsning eller leveranse, og som ofte kan påvirke eller blir påvirket. Ulike interessenter med ulike roller har ulike interesser. Interessenters interesse forstås som det som de kan påvirke eller påvirkes av. Interessen kan være mer eller mindre viktig for interessenten, og interessenten kan ha mer eller mindre makt. Interesser av mer generell karakter anses ikke som en interesse her. System for å forstå, lede og styre en organisasjon, slik at den leverer planlagt resultat Strategien beskriver hvordan virksomheten kan nå sine mål med de ressurser den har. Strategiprosessen omfatter etablering av mål, planlegging av aktiviteter og mobilisering av ressurser for å gjennomføre aktivitetene. Aktiviteter som utføres i linjen for å utvikle NAV Difi definerer et prosjekt som en midlertidig organisasjon etablert med den hensikt å levere ett eller flere produkter som bidrar til å realisere den avtalte prosjektbegrunnelsen. Prosjekter kjennetegnes ved at de er av unik karakter, har gitte mål, og er avgrenset i forhold til omfang, tid og kostnad. En person, organisasjon eller system som har en rolle som igangsetter eller samhandler med aktiviteter som etaten utfører. 1. Den vanlige eller forventede opptreden til en aktør, eller hvilket forhold noe eller noen har til en bestemt handling eller hendelse. En aktør kan fylle mange roller 2. Det et individ gjør i og overfor en organisasjon, eller det bidraget de yter ved å bruke sin kunnskap, kompetanse, erfaring og evne. Gjennom plasseringen i organisasjonen og oppgavene har individet fastsatte roller. 3. Summen av de normene og forventningene som er knyttet til en bestemt oppgave, stilling eller gruppe. En struktur for innhold eller prosesser som kan brukes som verktøy for å strukturere tanker, for å sikre konsistens og kompletthet Konkrete, repeterbare aktiviteter som løser et bestemt problem. Kan også sette krav til innhold i løsningen. 5

Side: 6 av 21 1 INNLEDNING Dokumentet beskriver hva virksomhetsarkitektur skal være i NAV, hvorfor arbeidet utføres, roller og ansvar. Det er en oppgradering, klargjøring og samling av tidligere dokumentasjon i NAV, og erstatter alle tidligere dokumenter om styring av virksomhetsarkitektur i NAV. Ekspertgruppen som vurderte NAV i 2015 hevdet at: «Det er medarbeidernes kompetanse, arbeidsprosessene, tilgjengelig informasjon, IKT- systemer, ledelse og styring som avgjør hvordan NAV leverer tjenestene og de brukeropplevelsene som dermed skapes». Virksomhetsarkitektur foreslås i dette dokumentet som et verktøy til å forstå slike sammenhenger som ekspertgruppen peker på, og et verktøy til å styre utvikling som skaper planlagte resultater Målgruppen for dokumentet er de som arbeider med eller har ansvar for virksomhetsarkitektur. Dokumentet er skrevet av en arbeidsgruppe oppnevnt av utviklingsmøtet, og er forankret og videreutviklet i møter med interessenter og ledergrupper. I arbeidsgruppen deltok representanter fra tjenestelinja, ytelseslinja, økonomiavdelingen, IKT avdelingen, styringsstab og utviklingsstab. Hensikten med å revidere dokumentet er å forankre en samlet forståelse av hvorfor NAV bør utvikle sin virksomhetsarkitektur, og hva det innebærer. Det er også nødvendig å harmonisere og tydeliggjøre begrep innen fagfeltet. Dokumentet beskriver en overbygning for arkitekturarbeidet som gjøres i NAV. Ved å bruke metoden i praksis vil NAV gradvis videreutvikle virksomhetsarkitekturen. Dokumentet gir grunnlag for å gradvis videreutvikle NAVs virksomhetsarkitektur med utgangspunkt i praktiske erfaringer. 6

Side: 7 av 21 2 VIRKSOMHETSARKITEKTUR I NAV Hvorfor utvikle virksomhetsarkitektur? NAV har ansvar for å forvalte arbeids- og velferdsordninger og å utvikle etaten slik at oppgaver blir løst i tråd med endinger i samfunnets behov og forventninger. Virksomhetsarkitekturen er en strukturert beskrivelse av virksomhetens nåsituasjon, målbilder, utviklingsbehov og veikart.. Arbeids- og velferdsdirektøren eier virksomhetsarkitekturen, og bruker den som et verktøy for å: strukturere forretningsutvikling. prioritere prosjekter som skal utvikle NAV styre prosjekters løsningsarkitektur. Virksomhetsarkitekturen vil hjelpe prosjektene å navigere slik at de når NAVs mål Figur 1 Virksomhetsarkitektur i NAV Hva omfatter virksomhetsarkitektur i NAV? Virksomhetsarkitektur i NAV beskriver struktur og sammenhenger mellom elementer som strategi, organisasjon, prosesser, kontorstruktur, tjenester, virkemidler, begrep, lover, regler, applikasjoner og teknologi. Arkitekturen beskriver nåsituasjon, målbilde, utviklingsbehov og veikart. Rammer og avgrensninger NAV omfatter Arbeids- og velferdsforvaltningen, stat og kommune. Omfang og detaljering begrenses til det som er nødvendig for å være et godt styringsverktøy. Virksomhetsarkitekturen vil beskrive elementer utenfor styringsretten til direktoratet der det er nyttig for å oppnå formålet. 7

Side: 8 av 21 3 INTERESSENTANALYSE Arbeidsgruppen etablerte en interessentoversikt, som er justert med informasjon fra utviklingsavdelingens interessentanalyse samt møter enkelte interessenter. Interessent Arbeids- og sosialdepartem entet Arbeids- og velferdsdirektøren og Direktørmøtet Interesser - Sikre at NAV utvikler seg i tråd med endinger i samfunnets behov og forventninger - Styre utvikling av NAV på grunnlag av tydelige behov, muligheter, sammenhenger og strategi - Etablere en felles forståelse av NAV slik etaten er og slik den bør utvikles, oppgaver, virkemidler, struktur, sammenhenger og konsekvenser. MBA - Påvirke prosessen med arkitekturutvikling - Etablere en felles forståelse av NAV slik etaten er og slik den bør utvikles, oppgaver, virkemidler, struktur, sammenhenger og konsekvenser. Linjeleder - Påvirke utvikling og endre virksomheten - Forstå sammenhenger og effekter for å planlegge, prioritere og gjennomføre endringer - Øke utviklingstakten og realisere gevinster Arkitekter i NAV Seksjon for informasjonsf orvaltning Prosjekter og utviklingsinitiativ Fagavdelingene: Arbeid og tjenester, Ytelser og Økonomi og styring - Forstå NAVs arkitektur, samt hvilke forventninger, rammer og avhengigheter den setter på prosjektet - Etablere en løsningsarkitektur som passer med NAVs arkitektur - Sikre at prosjektets løsningsarkitektur er forankret og besluttet av NAV - Utvikle og forankre arkitektur innen sine ansvarsområder - Forstå roller og ansvar til arkitekter i NAV - Skape et velfungerende arkitektnettverk som jobber godt sammen - Har regimeansvar for informasjonsforvaltning og linjeansvar for informasjonsarkitektur - Skal utarbeide og godkjenne informasjonsarkitektur inkludert informasjonsmodeller - Hovedansvar for å gjennomføre kjernevirksomheten til brukerne - Styre og utvikle tjenester og ytelser basert på politiske føringer og etatsstrategier - Støtte og styre linjene ressursmessig og faglig for å sikre kvalitet og effektivitet i linjens leveranser til brukerne - et virkemiddel for effektiv og helhetlig styring - Forstå kontekst for strategier/mål - Forstå utfordringer og muligheter - et verktøy for å forstå konsekvensen av NAVs strategier og målbilder Medarbeidere - Påvirke utvikling og endre virksomheten - Få oversikt over NAVs mål og struktur - Forstå sammenhenger mellom eget og andres initiativ og prosjekter IT-avdelingen - Forståelse av hvilke mål og forretningsprosesser IT-avdelingen skal støtte opp under 8

Side: 9 av 21 - Grunnlag for å vurdere innføring og utfasing av nye applikasjoner og teknologi eller kapasitet. - Formidle teknologiske utfordringer og muligheter - Forankring av IKT arkitektur og målbilder - Prioritering av prosjektinitiativ - Forstå funksjonelle og tekniske avhengigheter mellom planlagte leveranser og initiativ - Kvalitetssikre og styre prosjekter som er i gang Utviklingsmøtet HR avdeling - Utvikle hensiktsmessig organisasjon ut fra arbeidsoppgaver og prosesser Kunnskapsavdelingen Ekstern kvalitetsikrer Kommuner / KS - ivaretasitt lovtolkningsansvar og ansvar for helhetlig politikk og regelverksutvikling - Forstå og forklare hvordan regelendringer påvirker hele eller deler av arkitekturen, og hvordan planlagte endringer påvirker regler. - Sikre at prosjekter er i samsvar med virksomhetsarkitekturen og planlagt utvikling. - Forstå og påvirke planer som påvirker kommunalt partnerskap og NAVs virkemidler Leverandører - Bidra med kompetanse og erfaringer slik at NAV får god virksomhetsarkitektur, gode løsninger og gode planer - Forstå NAVs arkitektur, samt hvilke forventninger, rammer og avhengigheter den setter til leverandøren og leverandørens leveranser - Utvikle og implementere løsninger i henhold til NAVs virksomhetsarkitektur Samhandlere - Forstå NAVs arkitektur og samhandlerens egen rolle i arkitekturen - Forstå hvilke forventninger, rammer og avhengigheter NAVs arkitektur setter til samhandleren - Forstå hvordan NAVs initiativ og planer vil påvirke dem - Vise hvordan samhandlers planer og initiativer vil påvirke NAV Brukere - Sikre en god brukeropplevelse og gode virkemidler - Vise hvilke mål og behov som understøttes for brukeren, og hvordan Arbeidsgiverog arbeidstakeror ganisasjoner - Forstå hvordan NAVs initiativ og planer vil påvirke dem - Vise hvordan egne planer og initiativer vil påvirke NAV - Forstå hvordan utviklingstiltak understøtter NAVs mål og strategier samt hvordan tiltakene påvirker NAVs arbeidsprosesser og organisering. 9

Side: 10 av 21 4 METODE NAV benytter TOGAF 2 som rammeverk og metode ved utvikling av virksomhetsarkitektur. TOGAF beskriver en iterativ 3 arkitekturutvikling, som kan gjennomføres i fire ulike faser: 1. Arkitekturkontekst Beskrivelse som setter arkitekturen i sammenheng, svarer på hvorfor og hvordan virksomheten etablerer en virksomhetsarkitekturfunksjon, og hvordan den samvirker med andre styringsmekanismer 2. Arkitekturutvikling - Styring av prosessen for å beskrive, skape, vedlikeholde, godkjenne, forankre og formidle dokumentasjon av virksomhetsarkitekturen 3. Porteføljeplanlegging Planlegging og prioritering av prosjekter og utviklingsinitiativ som utvikler NAV 4. Styring av arkitektur - Arkitekturstyring av prosjekt og endringsinitiativ som implementerer endringer Figur 2 TOGAF arkitekturutviklingsmetode 2 TOGAF er et rammeverk for arkitektur utviklet av Open Group (The Open Group Architecture Framework). NAV bruker dette rammeverket for å utvikle og forstå virksomhetsarkitektur. Se www.opengroup.org 3 Iterativ: om verb som uttrykker at en handling stadig blir gjentatt 10

Side: 11 av 21 Hvert steg i TOGAF-metoden beskrives kort i tabellen under. TOGAF metoden kan benyttes av arkitekter i en virksomhet som skal utvikle virksomhetsarkitektur. Den er også egnet for arkitekter i et prosjekt som skal utvikle løsningsarkitektur for prosjektet. Den forberedende fasen benyttes til å sette riktige rammer for arbeidet med utvikling av arkitektur. Forberedende fase: Rammer og prinsipper Behovshåndtering Fase A: Arkitekturvisjon Fase B: Forretningsarkitektur Fase C: Informasjons og applikasjons-arkitektur Fase D: Teknologiarkitektur Fase E: Muligheter og løsningsalternativ Fase F: Migrasjonsplanlegging Fase G: Styring av innføring Fase H: Endringsledelse av arkitektur Forbereder organisasjonen på et arkitekturarbeid, ved å beskrive rammeverk, prinsipper og prosesser for arkitektur og forankrer arbeidet Sikre at alle aktiviteter bygger på forretningsbehov, og støtter eller oppdaterer forretningsbehovene. Fastsetter omfang, rammer og forventninger for arkitekturarbeidet. Etablerer en arkitekturvisjon Kartlegger interessenter og deres interesser Validerer forretningsforståelse og etablerer arbeidsomfang Sikre arkitekturressurser Forankring og godkjenning Iterativ utvikling av arkitektur for 1. Forretning 2. Informasjon og applikasjoner 3. Teknologi Omfatter dagens og ønsket arkitektur, samt en beskrivelse av utviklingsbehovet Planlegger implementering og leveransepakker. Forslag til realisering av leveransepakker i et veikart/plan. Analyser kostnader, gevinster og risiko Etabler en detaljert utviklingsplan Veileder og kontroller implementeringsprosjektene. Etablerer klare forventinger til hva og når prosjektene skal rapportere og levere Sikrer at prosjektenes løsningsarkitektur samsvarer med virksomhetsarkitekturen Kontinuerlig oppmerksomhet og endringshåndtering for å sikre at arkitekturen samsvarer med NAVs behov og maksimerer nytteverdien for virksomheten 11

Side: 12 av 21 En utviklingsorientert virksomhetsarkitektur Indre og ytre krefter og muligheter driver en utvikling av NAV. Virksomhetsarkitekturen er et verktøy for å kunne forstå virksomheten, og planlegge en fremtidig arkitektur og å planlegge leveransepakker som vil realisere planen. Prosjekter eller program vil levere leveransepakker. Leveransepakker vil beskrives med en løsningsarkitektur. Figur 3 En utviklingsorientert virksomhetsarkitektur Målbilde Beskriver den virksomhetsarkitektur som NAV planlegger å etablere Nåsituasjon Beskriver den virksomhetsarkitekturen NAV har i dag Utviklingsbehov 4 Beskriver forskjellen mellom nåsituasjon og målbilde. Utviklingsbehovet bør begrunnes med en forventet gevinst ved å dekke behovet. Leveransepakker Innbyrdes avhengige endringer som må leveres samtidig, eller i en viss rekkefølge. En sekvens av leveransepakker utgjør et veikart. 4 Utviklingsbehov kalles også «gap» 12

Side: 13 av 21 Virksomhetsarkitektur beskrives med modeller Virksomhetsarkitekturen blir beskrevet med modeller som er gruppert i oversikter. Oversiktene er gruppert i arkitekturområdene Forretning, Informasjon, Applikasjon, Teknologi, Styring og Sikkerhet. Figur 4 Oversikter som beskriver virksomhetsarkitektur i NAV Tabellen under detaljerer hvilke oversikter som vil benyttes til å beskrive virksomhetsarkitektur. Oversikt Forretning Drivere Rammer Hvorfor finnes oversikten? Gir en samlet oversikt over interne og eksterne drivere som påvirker virksomhetsarkitekturen. En driver skaper, motiverer og gir krefter til en endring. Drivere kan være både eksterne eller interne. De er ofte knyttet til en interessent, som dermed utøver driverrolle. Beskriver de rammer og føringer som NAV må forholde seg til, og som kan begrense handlingsrommet, eller også gi muligheter. Omfatter også en samlet fremstilling av lover og regler, og hvordan de er implementert i for eksempel virkemidler, prosesser og applikasjoner. 13

Side: 14 av 21 Prinsipper Mål Behov Bruker Samhandler Leverandør Tjeneste Ytelse Domene Prosess Organisasjon Sted Kanal Informasjon Begrep Prinsipper gir veiledning, retning og støtte for arkitekturbeslutninger. De skal være begrunnet opp mot et mål, og prioriteres. Gir en samlet oversikt over en ønsket tilstand som en og eller flere interessenter ønsker å realisere. Mål bør være SMARTe, Spesifikke, Målbare, Aksepterte, Realistiske og Tidsbestemte Gir en samlet oversikt over de behov og krav som stilles til virksomheten og virksomhetsarkitekturen, noe som skal eller bør leveres for å oppnå et mål virksomheten har. Grupperer brukere i brukergrupper, og gir slik en samlet oversikt over aktører og roller som mottar en tjeneste eller ytelse fra NAV Gir en samlet oversikt over aktører som utveksler informasjon og tjenester med NAV i kraft av en rolle de har. Gir en samlet oversikt over NAVs leverandører Gir en samlet oversikt over hvilke tjenester NAV leverer til brukere og samhandlere, og er en delmengde av NAVs virkemidler Gir en samlet oversikt over hvilke ytelser NAV leverer til ulike behovsgrupper, og er en delmengde av NAVs virkemidler Gir en samlet fremstilling av forretningsfunksjoner som kobles til ulike virkemidler, prosesser og organisasjonsenheter. En forretningsfunksjon grupperer aktiviteter etter krav til kompetanse og ressurser. Domener benyttes til å utvikle en funksjon, synliggjøre avhengigheter og strukturere diskusjoner på tvers av enheter og prosesser. Beskriver aktivitetene som NAV utfører for å skape verdi, og hvordan de er ordnet i rekkefølge. Prosesser kan beskrives i ulike nivåer, mer eller mindre detaljert. Kjerneprosesser produserer virkemidler (tjenester eller ytelser), i tillegg kommer styrings- og støtteprosesser. Beskriver NAVs organisasjonsenheter, stillinger og roller, og hvordan de samvirker med andre deler av virksomhetsarkitekturen. En rolle er den måten en aktør opptrer og forholder seg til andre på i en bestemt sammenheng. Utøvelse av en rolle medfører krav til kompetanse. Gir en fremstilling av de fysiske lokasjonene som NAV er representert på, med koblinger til organisasjonen og virkemiddelproduksjonen Gir en samlet oversikt over de kommunikasjonskanaler som NAV bruker til kommunikasjon med brukere, samhandlere, medarbeidere og andre Målet med å samle NAVs viktigste begreper på ett sted er å standardisere begrepsbruk internt og å synliggjøre likheter og forskjeller i informasjonen 14

Side: 15 av 21 Applikasjon IKT-prinsipper Integrasjon Teknologi Styring Forretningsobjekt Informasjonskilder Applikasjonskatalog Applikasjonstjenester Teknologikatalog Plattformtjenester Infrastrukturtjenester Virksomhetsstyring Sikkerhet Referansemodell for sikkerhet som brukes og hvordan begrep blir brukt Samlet fremstilling av informasjonsobjekter som forretningssiden forholder seg til, som søknad, sak, vedtak, regel, kundereskontro, kontoplan Samlet fremstilling av autorative informasjonskilder Prinsipper som skal ligge til grunn for hvordan NAV utvikler IKT-arkitektur og IKT-løsninger. Beskriver de applikasjoner som finnes, og koblinger til organisasjon, domene, teknologi og prosess Beskriver en avgrenset funksjonalitet som tilbys av en applikasjon og som understøtter definerte behov i en eller flere av NAVs virksomhetsprosesser Beskriver grensesnitt mellom applikasjoner for utveksling av informasjon, både med eksterne brukergrupper og samhandlere, og internt mellom applikasjoner i NAV Teknologikatalogen gir oversikt over teknologi NAV bruker og strategi for bruk av den enkelte teknologien. Teknologikatalogen skal sikre styrt bruk, innføring og avvikling av teknologi i NAV. Beskrivelse av de tjenestene som tilbys til applikasjoner som kjører på dem Beskriver de tjenestene som den fysiske infrastrukturen produserer, som datasentre, servere og nettverk. Beskriver NAVs styringsmekanismer Beskriver modeller for sikkerhetsstyring i NAV, som mellom annet omfatter beredskap, fysisk sikkerhet og informasjonssikkerhet 15

Side: 16 av 21 Iterativ arkitekturutviklingsmetode Arkitektur i NAV utvikles i en iterativ metode, ved at man utvikler arkitektur ved å svare på spørsmål om hvorfor, hva, hvordan og med hva flere ganger. Med en slik iterativ metode kan resultatet forbedres ved å bygge på resultatet fra forrige iterasjon. Iterativ metodikk benyttes for å stykke opp og løse kompliserte problemer med mange gjensidige avhengigheter. Figur 5 Faser i iterativ arkitekturutvikling Verktøystøtte og format NAV har valgt MEGA frå Bizcon som verktøy for modellering av virksomhetsarkitektur. For de øverste nivåene skal NAV i utgangspunktet benytte Archimate 5. Ved behov for høyere detaljeringsgrad kan det være hensiktsmessig å benytte andre format og verktøy(eksempelvis «metode for prosessutvikling» og BPMN). Dagens verktøystøtte for virksomhetsarkitektur er PowerPoint for noen modeller, og Sparx Enterprise Architect med Archimate for mange modeller i Applikasjon og Teknologi. NAV økonomi bruker Qualiware, også andre verktøy er i bruk i NAV. Disse modellene planlegges konvertert inn i MEGA. 5 Archimate er et modelleringsspråk utviklet av Open Group, som beskriver arkitektur, teknisk standard.. NAV bruker dette språket til mange modeller for arkitektur. 16

Side: 17 av 21 5 ARKITEKTURSTYRING I dette kapittelet drøftes roller og ansvar knyttet til tre ulike aspekter av arkitekturstyring slik de ble beskrevet i kapittel 4 om TOGAF arkitekturutviklingsmetode: 1. Utvikling av virksomhetsarkitektur - Styring av prosessen for å definere, skape, vedlikeholde, godkjenne, forankre og formidle oversikter og modeller. Se kapittel 5.1 og 5.2 2. Porteføljeplanlegging Planlegging og prioritering av prosjekter som utvikler arkitekturen. Se kapittel 5.2 og 5.3 3. Styring av prosjekters løsningsarkitektur - Arkitekturstyring av prosjekt som utvikler løsningsarkitektur og implementerer endringer i virksomhetsarkitekturen. Se kapittel 5.2 og 5.4 Styringsprinsipper: Arbeids- og velferdsdirektøren eier virksomhetsarkitekturen Beslutninger skal være basert på NAVs helhetlige, forretningsmessige behov Oppgaver, beslutningsmyndighet og ansvar delegeres så langt det er hensiktsmessig og forsvarlig. Det skal være klare ansvars og rollebeskrivelser. Interessenter skal kartlegges og involveres for å sikre gode løsninger og forankring Virksomhetsarkitektur utvikles iterativt og oppdateres jevnlig 17

Side: 18 av 21 Roller ved utvikling av arkitekturmodeller Hensikten med å etablere rollene under er å arbeide strukturert og helhetlig med virksomhetsarkitektur. Figur 6 Regimeansvar for arkitektur Modeller brukes for å beskrive prosesser, begrep eller applikasjoner. Modellene eies av eksempelvis prosesseier, begrepseier eller applikasjonseier. Slike eiere vil komme fra ulike deler av NAV. Regimeansvarlig 6 sørger for at modeller som inngår i en felles oversikt beskrives med samme rammeverk. Eksempler på slike roller vil være eksempelvis «Ansvarlig for prosessrammeverk», «Ansvarlig for begrepskatalogen», «Ansvarlig for applikasjonskatalogen». Arkitektturrådet sørger for at det utvikles oversikter som samlet beskriver NAVs virksomhetsarkitektur. Arkitekturrådet ledes av seksjonsleder for virksomhetsarkitektur. Arbeids- og tjenesteavdelingen, ytelsesavdelingen, økonomi og styringsavdelingen, HR avdelingen og ITavdelingen er representert med en person fra hver avdeling, i tillegg er seksjon for informasjonsforvaltning representert med en informasjonsarkitekt. Andre staber og avdelinger kan møte når saken angår dem. 6 Ansvarsdokumentet definerer regimeansvar slik: Ansvar for å utarbeide rammer og retningslinjer som etaten skal følge. I regimeansvar ligger også et ansvar for å forankre og følge opp praksis. Ansvaret for etterlevelse ligger i linjen. 18

Side: 19 av 21 Roller og ansvar knyttet til arkitekturbeslutninger Hensikten med å etablere en egen beslutningsmodell for arkitekturbeslutninger er å kunne delegere beslutninger så langt det er mulig, samtidig som beslutninger ivaretar NAVs helhetlige interesser. Modellen beskriver også NAVs arkitekturstyring av prosjekter. Figur 7 Roller og ansvar ved arkitekturbeslutninger Modelleier utvikler arkitekturmodeller og er ansvarlig for å kartlegge interessenter og håndtere interessentenes interesser i modellen. Modelleier vil fremme forslag om nye eller endrede modeller til regimeansvarlig. Regimeansvarlig utvikler rammeverk og retningslinjer for de modeller som dekkes i oversikten. Regimeansvarlig kan fremme forslag til arkitekturbeslutninger til arkitekturrådet, og godkjenne og publisere modeller innen sitt område. NAVs ansvarlige arkitekt har ansvar for å ivareta NAVs arkitekturstyring av prosjekter. Ved behov vil ansvarlig arkitekt lede et utvidet arkitektteam, Ansvarlig arkitekt vil formidle NAVs virksomhetsarkitektur og føringer til prosjektets løsningsarkitekt, og drøfte forslag fra prosjektet. Ved behov vil forslag til arkitekturbeslutning fremmes til arkitekturrådet. Prosjektets løsningsarkitekt er utvikler prosjektets løsningsarkitektur, og er ansvarlig for å kartlegge interessenter og interesser i prosjektets løsningsarkitektur, og å ha en dialog med nødvendige interessenter. Løsningsarkitekten forholder seg til NAVs virksomhetsarkitektur, og kan fremme forslag til arkitekturbeslutning til arkitekturrådet. Arkitekturrådet drøfter forslag til arkitekturbeslutninger. Leder av seksjon for virksomhetsarkitektur har beslutningsmyndighet innen mandat gitt fra utviklingsmøtet. Beslutningsmyndighet kan delegeres til regimeansvarlige eller ansvarlige arkitekter. Arkitekturrådet er ansvarlig for å publisere arkitekturbeslutninger. Utviklingsmøtet tar arkitekturbeslutninger innen mandat gitt fra Arbeids- og velferdsdirektøren. Utviklingsmøtet kan delegere beslutningsmyndighet til arkitekturrådet. Arbeids- og velferdsdirektøren er ansvarlig for alle arkitekturbeslutninger, og kan delegere beslutningsmyndighet. 19

Side: 20 av 21 Porteføljeplanlegging, konseptutvikling og prioritering NAV bruker porteføljestyring som samlebegrep for prosesser og beslutninger som til sammen sikrer en best mulig prosjektportefølje i henhold til NAVs strategi. Hensikten med porteføljestyring er å velge de beste initiativene, gitt at NAV har begrensede ressurser. Prosessen kan illustreres med følgende figur som viser kobling mellom strategi, idefase, porteføljedefinisjon, prosjektgjennomføring og gevinstrealisering: Figur 8 Fra strategi til gevinstrealisering Arbeids- og velferdsdirektøren fastsetter strategi og fokusområder, slik at medarbeidere, brukere, samhandlere og leverandører kan utvikle gode ideer og initiativ. Prosjektideer og initiativ kan utvikles med metode for arkitekturutvikling, slik det er beskrevet i kapittel 3. Virksomhetsarkitekten er en interessent som skal involveres i prosjekters konseptutvikling, for å bidra med innsikt og føringer basert på virksomhetsarkitekturen. Forslag til arkitekturbeslutninger eller prinsipielle avklaringer kan løftes til arkitekturrådet. 20

Side: 21 av 21 Arkitekturstyring av prosjekt NAV innfører i løpet av 2016 prosjektmodellen som er beskrevet i prosjektveiviseren til Difi. Konseptfasen brukes til å utvikle prosjektideer, de påfølgende fasene dekker gjennomføringen av prosjekter.. Figur 9 Difi prosjektmodell Når prosjekter går inn i planleggingsfasen vil en ansvarlig arkitekt ivareta NAVs arkitekturstyring av prosjekter. For større prosjekt vil det være et arkitektteam som ledes av ansvarlig arkitekt. Prosjektet skal ha en løsningsarkitekt, som har overordnet ansvar for løsningens arkitektur, som omfatter forretnings-, informasjons-, applikasjons-, teknologi og sikkerhetsarkitektur. Prosjektets løsningsarkitekt utvikler løsningsarkitektur, dokumenterer denne, og varsler ansvarlig arkitekt om eventuelle avvik fra godkjent arkitektur. Ansvarlig arkitekt og løsningsarkitekt skal samarbeide, slik at virksomhetsarkitekturen formidles til prosjektet. Ansvarlig arkitekt vil formidle krav og føringer på vegne av arkitekturrådet til prosjektets løsningsarkitekt. (I tillegg kan det komme andre krav og føringer til løsningen, for eksempel detaljerte krav fra IKT og andre) Ansvarlig arkitekt skal gi en anbefaling og vurdering av prosjektets løsningsarkitektur og samsvar med virksomhetsarkitekturen ved prosjektets beslutningspunkter. Prosjektets løsningsarkitekt har et ansvar for å tilbakeføre informasjon om endringer som gjennomføres av prosjektet, og forslag til utvikling av virksomhetsarkitekturen. 21