2012 10-24 ark2012 - arkitektur i mod

Arkitekturplanlegging for å modernisere en etat Ark2012 – Den norske dataforeningen Petter Hafskjold, sjefsarkitekt 24. oktober 2012

Moderniseringsprogrammet

NAV, 28.02.2016 Side 2

Agenda

Kort om NAV og Moderniseringsprogrammet

Arkitekturutvikling i planleggingsfasen

Forankring av arkitekturmålbildet

Erfaringer

NAV, 28.02.2016 Side 3

Kort om NAV og NAV IKT

NAV – Etablert 1. juli 2006

– 14 000 statlige ansatte

– 5 000 kommunalt ansatte

– 2,8 millioner mennesker mottar tjenester og stønader fra NAV

– Utbetalte i 2011 ca 330 milliarder kroner – Arbeid, Familie, Pensjon, Helse

NAV IKT – 300 systemer fordelt på 12 forvaltningsporteføljer

– 425 ansatte innen drift og forvaltning

– 200 personer fra leverandører for vedlikehold og videreutvikling

NAV, 28.02.2016 Side 4

Bakgrunn for modernisering av IKT i NAV

Departementet legger opp til at endringene (i IKT-løsningene) skal gjennomføres på en mest mulig kontrollert måte i to faser: en basisplattform for IKT-løsninger som skal være tilgjengelig ved etableringen av den nye arbeids- og velferdsforvaltningen, og en mer fullverdig og integrert IKT-løsning i form av et felles saksbehandlingssystem for hele eller store deler av arbeids- og velferdsforvaltningen.

”Dagens saksbehandlingssystemer vil i lang

tid framover være et hinder for at etaten kan

løse sine oppgaver effektivt. Riksrevisjonen

understreker at de negative konsekvensene av

manglende IKT-løsninger representerer en

betydelig risiko for etatens evne til å

gjennomføre sine pålagte oppgaver på kort sikt

og for å nå målene i NAV-reformen på lengre

sikt.”

NAV, 28.02.2016 Side 5

Store prosjekter skal gjennomgå Finansdepartementets kvalitetssikringsprosess

Ref. veileder nr. 3

NAV, 28.02.2016 Side 6

Faser og prosjekter i moderniseringsarbeidet

KS1

Hvorfor

Modernisering? Jan 2010 – juni 2011

KS1 & KS2 Finansdepartementets

kvalitetssikringsregime

KS2

Hvordan

Modernisering? Sept – des 2011

Prosjekt 2

2015-2017

KSP

KS2

Prosjekt 1

Aug 2012 – juni 2015

Prosjekt 3

2017-2018

KSP

KS2

Fo

rbere

de

Uførereform

Selvbetjening

Effektiv

forvaltning

Syke-

penger

Hovedmål A. Tiltak for å oppfylle absolutte krav

B. Forbedre og effektivisere samhandling

C. Effektiv behandling av ytelser

• Reform drevet

• Gevinstdrevet

D. Forbedre kvalitet i behandling av ytelser

NAV, 28.02.2016 Side 7

Arbeids- og velferdsetaten skal bli bedre!

Bedre for

bruker

Bedre for

medarbeidere

Lettere tilgang til personlige

data gjennom mitt NAV

• Synliggjøre alle vedtak,

info, dialog

Selvbetjeningsløsninger

• Lettere å søke ytelse og

stønad, innebygget

veiledning i søkeprosesser

Automatisert behandling gir

raske og riktige svar

• Likebehandling

Bygge kompetent organisasjon

rundt IKT-systemer

• Rutineoppgaver løses i større

grad av IKT

Færre ulike systemer å jobbe i

Stabil IKT-drift

• Mulig å innføre nytt

regelverk for uføre og

sykepenger uten

bemanningsøkning

• Etterleve

Økonomiregelverket/

godkjent regnskap

• Fleksible IKT-systemer

som ikke hindrer

politikkutvikling

• Betydelig samfunns-

økonomisk gevinst

• Lavere transaksjons-

kostnader pr vedtak

Bedre for

samfunnet

NAV, 28.02.2016 Side 8

Programorganisasjon

Prosjekt

Løsning

Arbeidsdepartementet

Arbeids- og velferdsdirektør Programeier

Prosjekt

Strategi & plan

Programkontor

Prosjekt

Innføring &

omstilling

Prosjekt

Forretning

Moderniseringsprogrammet Programledelse

Styringsgruppe

NAV, 28.02.2016 Side 9

Integrert modell for gjennomføring

Programmet

Styringsramme • Tid

• Kost

• Kvalitet (omfang, målbilde)

Styringsgruppe

Avtaler,

personal-

reglement,

økonomi-

fullmakter

osv)

Etter-

levelse

Strategi,

prinsipper

og

målbilder

Sponsor-

gruppe

Linjeledere

Ressurser

Løpende

prioritering av

produktkøen

Avrop på

eksisterende

avtaler

Ressurs- og

kompetanse-

behov

Funksjonelle

og ikke-

funksjonelle

løsningsvalg

Kontroll-

punkter

http://navet/ansatt/Fag/Regelverk+og+rutiner/Nytt+i+Rettskildene+-+uke+7.303062.cms

NAV, 28.02.2016 Side 10

Agenda


Arkitekturutvikling i planleggingsfasen – Hvorfor arkitektur?

– Prosessmodeller

– Informasjonsarkitektur

– Applikasjons- og teknologiarkitektur


Erfaringer

NAV, 28.02.2016 Side 11

Hvorfor arkitektur?

Oversikt over utviklingsarbeidet – Hva skal utvikles?

– Hva må endres?

– Hva skal fases ut?

– Hvilke steg skal endringene gjennomføres?

Effektivt og helhetlige applikasjonslandskap – Ikke duplisere informasjon og funksjonalitet

– Dele informasjon og funksjonalitet

Sikre at ikke-funksjonelle krav oppfylles – Vedlikeholdbarhet

– Endringsevne

– Tilgjengelighet

NAV, 28.02.2016 Side 12

Agenda



– Prosessmodeller




Erfaringer

NAV, 28.02.2016 Side 13

Prosessmodellering som utgangspunkt

Prosessmodellering av kjerneprosesser

Interaksjonsdesign, prototyping

Informasjonssarkitektur

Prioritering og planlegging: Leveranseplan og koordinering

Epos og bruker-

historier

Løsningsbeskrivelse: videre detaljering

Konstruksjon

Applikasjonsarkitektur

Estimater

NAV, 28.02.2016 Side 14

Høsten 2010 ble det gjennomført prosessmodellering med bred deltagelse

Gruppe 1:

Portal, kanalvalg og

samhandling

Gruppe 3:

Vedtak, ytelser og

økonomi

Gruppe 5:

Virksomhetsstyring

Faglige

arbeids-

grupper

Avklare, avtale og

formidle barnebidrag

Vedtaksbehandling,

klage og anke

Refusjonsbehandling

og utbetaling

Ytelseskontroll

Gruppe 4:

Støttefunksjoner

Brukerdialoger Økonomi

Innkjøp og logistikk

for varer og tjenester

Organisasjon og HR

Dokumenthåndtering

Samhandling og

oppgavehåndtering

Gruppe 2:

Oppfølging og

arbeidsmarked

Kartlegging

Oppfølging og

evaluering

Brukers plan og

aktiviteter

Arbeidsgivertjenester og

arbeidsformidling

Målstyring,

virksomhetsplan

Økonomistyring,

budsjettering, prognose

Risikostyring,

internkontroll

Produksjons- og

resursstyring

Statistikk og analyse

Virkemiddeltilbud:

Tiltak og hjelpemidler

Rettigheter –

Folketrygd og

forsikringsordninger

Tilrettelegging og

hjelpemidler for bruker

HP1: Motta bestilling

og beslutte behandling

HP2: Informere og

veilede

HP5: Bistå og følge opp

for arbeid og aktivitet

HP3: Behandle sak

HP4: Utbetale

Hoved-

grupper

Kopling

til Delta

hoved-

proses-

ser

Personlig økonomi

NAV, 28.02.2016 Side 15

Hvordan vi har dokumentert resultatene fra prosessmodelleringen – modellstruktur

Personlig økonomi

For hvert tema… …ble fremtidens prosesser modellert… …og samlet i prosessområder

Kriterier for gruppering:

• Hva er hensikten med

prosessen – hva skal vi

oppnå?

• Hva er resultatet fra

prosessen – hva skal NAV

levere?

NAV, 28.02.2016 Side 16

Hvordan vi har dokumentert resultatene fra prosessmodelleringen – prosessflyten

Prosessmodeller

Sentrale drivere i utforming av prosessene

• Arbeid først: Hvordan kan vi styrke og forbedre innsatsen mot arbeid og aktivitet?

• Selvbetjening: Hvilke prosess-steg kan med fordel gjennomføres av brukeren selv?

• Automatisering: Hvilke prosess-steg kan og bør automatiseres? Hva er forutsetningene for dette?

• Samhandling: Hvordan kan vi legge til rette for og forbedre samhandling med andre aktører som er viktige for

resultatet av prosessen?

• Organisasjons-

nøytral inndeling

• Brukerkontakt –

selvbetjening,

samhandling, dialog

med NAV

• NAV produksjon –

automatisk eller

manuelt

• Analysegrunnlag

bl.a. for å beregne

behov for

bemanning og

kompetanse

NAV, 28.02.2016 Side 17

Det ble etablert et helhetlig oversikt over NAVs fremtidige prosesser

NAV, 28.02.2016 Side 18

Hovedleveranser Forretningsarkitektur

Resultatene fra hvert

arbeidsmøte er dokumentert i en

prosessbeskrivelse

FA1.6 Samlet beskrivelse

av NAVs fremtidige

tjenester og prosesser -

Hovedprosesser

Pro

sje

ktlevera

nser

Sty

rende d

okum

ente

r

FA3.1.1 Fullstendig beskrivelse

av NAVs fremtidige

forretningsarkitektur

FA3.1.2 Oppsummering av

NAVs fremtidige

forretningsarkitektur

FA1.7 Samlet

beskrivelse av NAVs

fremtidige tjenester og

prosesser -

Støtteprosesser

FA1.8 Samlet

beskrivelse av NAVs

fremtidige tjenester og

prosesser -

Virksomhetsstyring

NAV, 28.02.2016 Side 19

I etterkant av arbeidet har arkitekturprinsippene blitt formalisert og besluttet

Forretningsprinsipper

1 Informasjon og tjenestetilbud skal være tilgjengelig og brukertilpasset

2 NAVs myndighetsutøvelse, tjenesteyting og informasjonsbehandling skal følge det

regelverk som gjelder

3 NAVs tjenester skal være stabile og forutsigbare uavhengig av konjunkturer og

endringer i saksmengde

4 NAVs behandlingsprosesser skal være fleksible i forhold til nye og endrede behov

5 Behandlingsprosessene skal sikre effektiv fremdrift

6 Intern og ekstern samhandling skal gi helhetlige tjenester til brukene

7 Styring og utvikling - All tjenesteutvikling i NAV skal være kunnskapsbasert

NAV, 28.02.2016 Side 20

Agenda



– Prosessmodeller




Arkitektur og produktkø

Erfaringer

NAV, 28.02.2016 Side 21

Prinsippene som skal styre utvikling av målbildet for informasjonsarkitekturen

Informasjonen skal styres og forvaltes som en selvstendig eiendel av høy verdi

Vi skal til enhver tid vite hva informasjonen betyr, kjenne dens kvalitet og vite hvordan den anvendes og av hvem

Målbildet for informasjons-organiseringen skal understøtte virksomhetsprosessenes informasjonsbehov

Data skal lagres og forvaltes kun på ett sted, men kan om nødvendig dupliseres kontrollert nedstrøms i prosessflyten

NAV, 28.02.2016 Side 22

Utvikling av informasjonsmodell

Deltakelse i arbeidsgruppene for prosessmodellering innenfor forretnings-arkitektur for å identifisere informasjonsbehov

Egne møter med ressurser fra de samme gruppene for å verifisere modell og krav i ettertid

Generalisert for å passe alle ytelser

Modellert i verktøyet Enterprise Architect

NAV, 28.02.2016 Side 23

Domenemodell

NAV, 28.02.2016 Side 24

Agenda



– Prosessmodeller




Erfaringer

NAV, 28.02.2016 Side 25

Problemer med dagens arkitektur og løsninger ble identifisert

UnikID(P1, P2,…n)

Prio

riterin

g

Problemstilling(Legg inn et kort men tydelig

navn)

Beskrivelse(Legg inn en beskrivelse av hvorfor dette er en

problemstilling / utfordring)

Mulig konsekvens hvis tiltak

ikke blir adressert i 3a og 3b(Bruk evt til spørsmål i sjekklisten)

Fle

ksib

ilitet

Økonom

iregle

mente

t Sik

kerh

et

Sta

bil IK

T d

rift

Ufø

re

Sykdom

Arb

eid

og a

ktiv

itet

Pensjo

n

Inte

gra

sjo

nssente

r

Felle

ssyste

mer

Fam

ilie

Bid

rag

Selv

betje

nin

g o

g

porta

l

Hels

e

Sta

tistik

k o

g

data

vare

hus

Basis

Bre

v o

g a

rkiv

Økonom

i og

logis

tikk

HR

Unik

ID Beskrivelse TypeP069 2 REFACTORING -GSYNK: Burde ikke vært en batch, men heller en

live oppdatering via buss

-RUTING: Tett kopling mellom komplekse

businessregler og programkode. Mye duplisert og

uoversiktlig kode gir lite fleksibel løsning og høy

risko for feil ved endringer.

X X T100 - Erstatte integrasjonsmekanismer som

gir høy risiko for nedetid og feil

3abc

P070 BREVLØSNING Brevløsningen - lang responstid og dårlig

funksjonell løsning.

X X X T016 - Erstatte Arenas opprinnelige

brevløsning med dagens SYFO-

brevløsning

Utgår

P071 2 AUTOMATISERING Mer automatisering.

Ruting for avhengig av Infotrygd/Arena, automatisk

start av jobben når andre jobber er ferdig.

Kjøretidsvindu for knapt.

X X

P072 1 KATASTROFESIKRING Avhengighter til basissystmer som ikke bekreftet er

katastrofesikret (GOSYS/GSAK). Klassifisering

X X

P073 2 Kritikalitet klassifisering DVH er ikke kritikalitet klassifisert. Sette

sikkerhetstiltak og sikkerhetsnivå kan ikke settes

korrekt. Det er dermed uklart hvor viktig DVH er for

NAV gir uklare konsekvenser og tiltak dersom

Datavarehust har nedetid.

Det blir ikke gjort korrekte sikkerhetstiltak og

sikkerhetsnivå. Det kan oppstå feilbehandling av

sensitive data og viktige rapporter har ikke korrekt

beredskap for å rette feil.

X X X X T470 - Oppdatere systemdokumentasjon Forvaltning

P074 1 Store og økende

datamengder

Store og økende datamengder uten slette og

historiseringstrategi

DVH inneholder store og økende datamengder.

Ytelsen vil over tid være synkende. Det kan medføre

at jobber ikke er ferdig i tide for å kunne produsere

statistikk innenfor fristen.

X X

P075 1 Katastrofesikring DVH har ikke en eksplisitt katastrofeløsning på

servernivå, kun på data.

Dersom det skjer servercrash som krever ny

levereanse og oppsett av DVH servere kan det

medføre at statistikk ikke blir levert innenfor fristen.

X X

P076 2 Beredskap DVH porteføljen har ikke beredskap på feil i de ca.

250 jobbene som kjøres ved faste intervall. Kun IKT-

Drift-PAD har beredskap. PAD kan kun se at feil er

oppstått ikke i hvilket steg, eller årsak. DVH

portefølje får først beskjed om feil, og kan sette

igang tiltak ved oppmøte på jobb, eller etter kontakt

fra PAD.

Kan medføre at statistikk ikke blir levert innenfor

fristen og at periodiske dataset ikke kan hentes ut

fra kildene.

X X

P077 2 Ytelse og responstid DVH løsningen yter ikke tilfredsstillende ytelse for

brukerne av løsningen. Oppgradering til siste

versjon av rapportprogramvare førte til betydelig

mer stabil løsning, men med sideeffekt dårligere

ytelse.

Over tid med økende datamengder og antall

rapporter vil ytelsen gradvis forverres.

X X

Referanse til tiltakBeskrivelse av problemstillinger / utfordringer Krav Berørte porteføljer

360 problemstillinger identifisert og gruppert

Tiltak ble beskrevet og estimert

NAV, 28.02.2016 Side 26

Tiltak ble beskrevet og estimert

Absolutt kravområde

Tiltak i Alternativ 3c Innfrielse av kravet

Kommentar

Stabil IKT-drift HT03: Videreutvikle og forbedre dagens

brevløsninger og ta den forbedrede løsningen i bruk

i de fagsystemer som har uakseptable løsninger i

dag. Gir i tillegg arkiv i Joark for disse løsningene.

Fase 1 og 2 Ny brevløsning etableres som del av Uføre (T804) i Fase 1.

Tiltaket reduseres dermed til å ta i bruk ny brevløsning for

identifiserte løsninger, som gjennomføres i Fase 2

HT11: Redusere kjøretid på batcher I linjen Tiltaket gjennomføres delvis av linja i forkant av modernisering. I

Fase 1 skal det etableres bedre ikke-funksjonelle krav til batcher,

og eventuelt justeringer i arkitektur for å unngå at dette blir et

problem for nye løsninger. Gjenstående batcher utbedres i Fase 2.

HT13: Forbedre feilhåndtering og øke

automatiseringsgraden i batcher

Fase 1 og 2 Gjennom utvikling av applikasjonsrammeverket forbedres ikke-

fuksjonelle krav til batcher og kontroll av disse i Fase 1. Tiltaket

med å forbedre eksisterende batcher gjennomføres i Fase 2.

HT22: Trekke Java ut av Arena-databasen for å

redusere teknisk risiko

I linjen Tiltaket gjennomføres i regi av linja i forkant av modernisering.

T019: Forbedre katastrofesikring I linjen Tiltaket gjennomføres i hovedsak av linja i forkant av

modernisering. Resten av dette tiltaket gjennomføres i Fase 1

T100: Erstatte integrasjons-mekanismer som gir

høy risiko for nedetid og feil

Fase 1, 2 og 3 Fase 1 vil forbedre arkitekturen for integrasjonsmekanismer

gjennom utvikling av applikasjonsrammeverket. Fase 2 og 3 vil

migrere eksisterende applikasjoner over på forbedret arkitektur

T624: Forbedre sikkerhet i eksisterende

integrasjonsløsninger (MQ-køer med mer)

Fase 1, 2 og 3 Fase 1 vil forbedre arkitekturen for integrasjonsmekanismer

gjennom utvikling av applikasjonsrammeverket. Fase 2 og 3 vil

migrere eksisterende applikasjoner over på forbedret arkitektur

T908: Konsolidere til to datahaller for å

tilrettelegge for større grad av katastrofesikring

I linjen Tiltaket gjennomføres i sin helhet av linja.

Tiltakene ble lagt i prosjekt 1, 2 og 3, eller som del av forvaltning

NAV, 28.02.2016 Side 27

Nå-situasjon for sentral applikasjoner ble kartlagt

Selvbetjening og portaler

Pensjon Familieytelser og bidrag Arbeid og aktivitet

PEN PREG ARENA Amelding Infotrygd

Fellessystemer

GSAK GOSYS Ruting

nav.no Ditt NAV

Brev og arkiv

Statistikk og datavarehus

Lønn og personal (HR) Økonomi-systemer

JOARK Brevserver Agresso

lønn Wintid OS UR

DVH SAS

Helse

Elektronisk

mottak

eResept

KuHR

Regnskap

Inte

gra

sjo

ns

se

nte

r

NAV

tjenestebuss

Fagsystemer SBL, helse og

basissystemer Administrative systemer SKILL

SBL Arbeid

BISYS

Basis

TPS

TSS

AA-reg Avgift

Remedy FR TP Medl

BPROF INNT

INST NORG

NAV, 28.02.2016 Side 28

Nå-situasjonen vurderte løsningene i flere dimensjoner

Applikasjon Plattform Veiledning til vurdering

Lisenskostnad Lisenskostnad

Lisensmodell Lisensmodell

Markedssituasjon Markedssituasjon

Forvaltningskostnad Maskinvarekostnad

Funksjonalitet Funksjonalitet

Selvbetjening

Universell tilgjengelighet

Automatiseringsgrad

Elektronisk samhandling

Økonomireglement

Datakvalitet Database

Datamodell Annen lagring

Arkivløsning

Bruk av fellesdata

Tilbyr informasjonstjenester

Tilgangsstyring

Virksomhetsroller

Tilgangskontroll

Personopplysningslov

Brukergrensesnitt Klientprogramvare?

Programmeringsspråk Mellomvare

Prosessimplementasjon Prosessmotor

Regelimplementasjon Regelmotor

Operativsystem

Maskinvare

Tjenesteorientering Plattformoppgradering

Lagdeling Plattformbytte

Kodekvalitet

Rammeverk

Testbarhet

Åpne standarder

Forvaltningsavtale Supporterte versjoner

Feilretting Patching

Ny funksjonalitet Produksjonssetting

Overvåkningsløsning Overvåkning

Feilhåndtering Feilsøking

Tredjelinjesupport Drift

Dokumentasjon Dokumentasjon

Kompetanse Kompetanse

<Applikasjon>

Fakta om det foreligger forvaltningsvatale og om plattformens komponenter er supportert.

Kvalitativ vurdering av evne til feilretting /patching og utvikling av ny funksjonalitet og

produksjonssetting innen akseptable tids- og kostnadsrammer. Vurdering av

Forvaltbarhet /

driftbarhet

Fakta om brukergrensesnitt og programmeringsspråk.

Vurdering av om implementasjon av eventuelle prosesser og regler er hensiktsmessig.

Fakta om hvilke plattformkomponenter som brukes og vurdering basert på strategiske

valg for NAV,

Kvalitativ vurdering av om applikasjonen er hensiktsmessig bygd opp og kan bruke og

tilby hensiktsmessige grensesnitt (tjenester eller annet). Vurdering av bruk av åpne

standarder.

Vurdering av om plattformen kan oppgraderes eller byttes uten store konse

Sikkerhet Fakt om felles tilgangsstyring benyttes og virksomhetsroller ligger tilgrunn for tilganger i

applikasjonen.

Vurdering av tilgangskontrollens implementering (modell/rammeverk eller programmert)

og plassering (i brukergrensesnitt eller nær data). Oppfyller

Teknologi

Endringsevne

Kvalitativ vurdering av applikasjonens datakvalitet og datamodell.

Fakta om applikasjonen bruker felles arkiv og fellesdata samt om den tilbyr

informasjonstjenester.

Fakta om databaseteknologi og eventuell annen lagringsteknologi som benyttes.

Informasjons-

behandling og

datalagring

Funksjonalitet Kvalitativ vurdering av applikasjonens funksjonalitet og om denne er i tråd med målbilde.

Vurdering av mulighet for selvbetjening hvis relevant, universell tilgjengelighet og grad av

automatisering og bruk av elektronisk samhandling. Vurdering om applikas

Kvalitativ vurdering av økonomien for gitt applikasjon og tilhørende teknisk plattform.

Vurdering av kostnader for drift og forvaltning og hvordan kostnader til lisenser,

investeringer, drift og forvaltning vil endres ved økt bruk (gjenbruk). Vurdering av

Økonomi

NAV, 28.02.2016 Side 29

Strategisk nivå

IKT-prinsipper DIFI-prinsipper

Metode

Referanse-

arkitektur Arkitekturkrav

Arkitektur i linja

Ikke-funksjonelle

krav

Grunnlag for

program Krav til løsning

Løsnings-

arkitektur

IKT-

prinsipper

Arkitektur-

krav

Målbilde

applikasjon

Retningslinjer Kurs/

sertifiseringer

IKT-strategi

Referanse-

arkitektur

Målbilde

teknologi

Andre

strategidokumenter

Leveranser fra

Modernisering Applikasjons- og teknologiarkitektur

Nå-situasjon

app. og teknologi

Nå-situasjon

applikasjoner

og teknologi

NAV, 28.02.2016 Side 30

Nye IKT-prinsipper ble utarbeidet

IKT1 Virksomhetsbehov IKT-løsninger skal støtte virksomhetens behov.

IKT2 Livsløp Ved nyetablering eller større endringer av IKT-løsninger skal helhetlige behov og

langsiktige kostnader og gevinster legges til grunn.

IKT3 Informasjons-forvaltning Informasjon er en selvstendig eiendel av høy verdi, og skal styres og forvaltes deretter.

IKT4 Tjenesteorientering IKT-løsninger skal tjenesteorienteres for å understøtte standardisert deling av

funksjonalitet og informasjon.

IKT5 Helhetlig informasjons-

arkitektur

Informasjonsarkitekturen skal understøtte hele virksomhetens informasjonsbehov.

IKT6 Endringsevne IKT-løsninger skal kunne endres i takt med regelverk, organisering og brukerbehov.

IKT7 Universell tilgjengelighet NAVs IKT-løsninger skal være tilgjengelige for alle som har behov for dem.

IKT8 Sikker behandling IKT-løsninger skal sørge for sikker behandling og tilfredsstille krav til konfidensialitet,

integritet, tilgjengelighet og sporbarhet.

IKT9 Stabil, kontinuerlig og

effektiv drift

IKT-løsninger skal utformes for stabil, kontinuerlig og effektiv drift.

IKT10 Automatisering IKT-løsninger skal benytte automatisering for å understøtte effektivisering av

virksomhetsprosesser.

IKT11 Selvbetjening IKT-løsninger skal understøtte NAV-brukere, samhandlere og medarbeidere i størst

mulig grad kunne løse oppgavene sine selv.

IKT12 Samhandling NAV skal benytte elektronisk samhandling for å sikre god informasjonskvalitet og

understøtte det offentlige tjenestetilbudet.

IKT13 Åpne standarder IKT-løsninger skal baseres på etablerte åpne standarder.

NAV, 28.02.2016 Side 31

Arkitekturkrav ble utarbeidet

Overordnet

Tjeneste og prosess

Brukerinteraksjon

Elektronisk samhandling

Informasjon

Datavarehus

Sikkerhet

Drift

Infrastruktur

NAV, 28.02.2016 Side 32

Absolutte krav identifisert og beskrevet

Område Beskrivelse

Stabil IKT-drift IKT-systemene skal være stabile og effektivt understøtte

tjenesteproduksjonen i NAV i et 10 til 15-års perspektiv når det tas

høyde for naturlige svingninger i etterspørsel og volum. IKT-

løsningene skal ha tilstrekkelig tilgjengelighet,

produksjonskapasitet og responstid til at NAV kan nå sine

produksjonsmål.

Fleksibilitet Innføring av endringer og reformer i arbeids- og

velferdsforvaltningen skal ikke unødig hindres av IKT. Fleksibilitet

realiseres gjennom tjenesteorientert arkitektur med gjenbrukbare

komponenter og tjenester, som gir reelle valgmuligheter til å

renovere, endre, erstatte eller nyutvikle.

Oppfylle kravene i

Økonomireglementet

IKT-løsningene skal bidra til at NAV oppfyller kravene i

økonomireglementet; kravene til sporbarhet er sentrale.

Reglement for økonomistyring i staten og bestemmelser om

økonomistyring i staten, §2 i Folketrygdloven (jfr. /32/)

Sikkerhet

(personvern)

NAV skal ivareta personvernet og tilby en sikker og etterrettelig

tilgang til informasjon og dokumenter. NAV skal oppfylle krav i

Personopplysningsloven med forskrifter med særlig vekt på

konfidensialitet, integritet, lagring og logging.

NAV, 28.02.2016 Side 33

Basert på prosessmodellarbeidet ble funksjonelle komponenter identifisert

NAV, 28.02.2016 Side 34

Applikasjonskomponenter identifisert og beskrevet

001

Distribusjons-

kanal Dokumentdistribusjon

004

eAktør-

samtykke Dokumentdistribusjon

023

Brukerprofil Brukeroversikt

Dokument-

produksjon

002

Elektronisk-

distribusjon Dokumentdistribusjon

021

Sentral utskrift Dokumentdistribusjon

022

Lokal utskrift Dokumentdistribusjon

Journal og

arkiv

Applikasjonskomponent

Annet

Fysisk

oppmøte

Postkasse

003

Varsel om

elektronisk

dokument Dokumentdistribusjon

005

Redistribusjon

ulest dokument Dokumentdistribusjon

IKT-tjeneste

006

Meldingsboks Brukers meldinger

007

Min

meldingsboks Brukers meldinger

NAV, 28.02.2016 Side 35

Enkle løsningsskisser laget for KS2

NAV, 28.02.2016 Side 36

Teknologibeslutninger

Distribuert plattform videreføres som preferert plattform

Operativsystem

Språk

Hardware

Database

PlattformnavnPlattformnavnPlattformnavn

Operativsystem

Språk

Hardware

Database

Operativsystem

Språk

Hardware

Database

PlattformnavnPlattformnavnPlattformnavnzOS

Cobol

IBM Mainframe

DB2

Stormaskin

zOS

Cobol

IBM Mainframe

DB2

zOS

Cobol

IBM Mainframe

DB2

Stormaskin

Linux*

4-GL/PL-SQL

x86*

Oracle

Oracle Forms

Linux*

4-GL/PL-SQL

x86*

Oracle

Linux*

4-GL/PL-SQL

x86*

Oracle

Oracle Forms

Linux

Java

x86

Leverandørnøytral

Distribuert

Linux

Java

x86

Leverandørnøytral

Linux

Java

x86

Leverandørnøytral

Distribuert

NAV, 28.02.2016 Side 37

Lagdeling av teknologiarkitekturen

Data

Mellomvare

Operativsystem

Virtualisering

Server

Lagring

Nettverk

Datahall

Applikasjon

Plattform

Applikasjon

Infrastruktur

Applikasjoner konsumerer

plattformtjenester

Plattform konsumerer

datakraft og lagring

Distribuert plattform består av flere lag, hvor et lag tilbyr tjenester til overliggende.

Lagene er inndelt i 3 hovedområder; Applikasjon, Plattform og Infrastruktur (API)

NAV, 28.02.2016 Side 38

Distribuert plattform Teknologivalg

Løsnings-

komponenter

Mellomvare /

Database

Operativsystem

Virtualisering

Underliggende

infrastruktur

Strategisk gjenbruk og videreutvikling av teknologi.

Kun behov for å videreutvikling

Java/JEE

<velges>

Red Hat Linux

VMWare

x86

Arkitektur Teknologi Arkitektur Arkitektur

NAV, 28.02.2016 Side 39

Agenda




Erfaringer

NAV, 28.02.2016 Side 40

Prosessmodeller gjennomgått og besluttet i D-møte

NAV, 28.02.2016 Side 41

Informasjon må ses på som en felles ressurs

Løsning A

Informasjon

Løsning B

Informasjon

Løsning C

Informasjon

Hver løsning dekker

eget informasjons-

behov og integrerer

med nødvendige

kilder

Løsning A

Informasjon

Løsning B Løsning C Informasjon ses på

som en felles

ressurs

Informasjon

Nå-s

ituasjo

n

Må

lbild

e

NAV, 28.02.2016 Side 42

Løsningsprinsipp Selvdokumenterende dokumentasjon

Langtlevende informasjonen skal dokumentere seg selv (metadata)

Dokumentsentrisk tilnærming – fokusere på informasjon, ”ikke struktur”

All bruk av informasjon, nå og i fremtiden, sjekkes mot gjeldende regler for tilgang

Ved overføring av informasjon, også til eksterne, følger også metadata med slik at bruk av og tilgang til informasjonen kan sjekkes i den videre informasjonsbehandlingen

•Formål

•Kilde

•Sikkerhetsnivå

•Informasjon

• …

• …

Løsning

•(Sikkerhetsnivå)

•Informasjon

• …

• (Formål)

Løsning

•Informasjon

• …

• …

• (Sikkerhetsnivå)

• (Formål)

Nå-situasjon Målbilde

Løsning Løsning

NAV, 28.02.2016 Side 43

Løsningsprinsipp Klassifisering av informasjon

Behov for sikkerhet og kvalitet er utgangspunktet

Risikovurdering og klassifisering bestemmer hvilket sikkerhetsnivå implementert løsning og underliggende infra-struktur (ressurser) skal oppfylle

Konsekvens: – Informasjon (og tjenester) må

ha dokumentert hvilket sikkerhetsnivå de krever

– Infrastruktur må ha dokumentert hvilket sikkerhetsnivå de leverer

– Enhetlig sikkerhetsarkitektur nødvendig for å gjennomføre

Tjeneste

Info

Selvbetjening NAV

Tjeneste

Info

Tjeneste

Info

Tjeneste

Info

IKT-omgivelser

Implementert løsning

Informasjonsbehandlingsprosess (forretningsprosess)• Kvalitetskrav

• Sikkerhetskrav

• Risikovurdering

• Klassifisering

Sikkerhetsnivå

Krav til kvalitet,

konfidensialitet,

integritet,

tilgjengelighet og

sporbarhet

NAV, 28.02.2016 Side 44

Hendelser og prosesser

Virksomhetsprosesser startes basert på hendelser

Overgang mellom virksomhetsprosesser gjøres ved bruk av

hendelser for å sikre løs kobling

Hendelsesstyring

Hendelse

Regler for

hendelserKø

Virksomhets-

prosess

Hendelse

Hendelsesstyring

Regler for

hendelserKø

Virksomhets-

prosess

Krav mottatt

Behandle krav

Utbetaling

Positivt vedtak

NAV, 28.02.2016 Side 45

Oppgavestyring og oppgaveutførelse

Oppgavestyring og prosesser skal ikke være tett koblet – Prosessen skal ikke vite om et steg gjøres automatisk eller manuelt

Saksbehandlere får tilgang til oppgaver gjennom oppgavekø og

utfører oppgaven ved hjelp av brukergrensesnitt som

aktivitetstjenesten tilbyr

OppgavekøOppgavekø

Prosess-

steg

Prosess-

steg

Prosess-

steg

Prosess-

steg

Aktivitets-

tjeneste

Aktivitets-

tjeneste

Aktivitets-

tjeneste

Aktivitets-

tjeneste

Manuel oppgave

opprettes av

aktivitetstjenesten

Oppgave

NAV, 28.02.2016 Side 46

Felles arkitektur for brukerinteraksjon

Sammensatte brukerflater – Brukerflateelementer som fritt kan settes sammen til brukerflater for

en spesifikk arbeidsoppgave eller målgruppe

Håndtere overgang fra en

brukerflate (applikasjon)

til en ny

Benyttes både internt og

i selvbetjeningsløsninger

Informasjons-

tjeneste

Innsyn

Generell

informasjon

Veiledning og simulering

Aktivitets-

tjeneste

Regel-

tjenestePubliserings

løsning

NAV, 28.02.2016 Side 47

Hovedelementer i løsningsarkitektur prosjekt 1 Informasjons-

plattform

Dialogarena Ytelser Virksomhets-

styring

Sikkerhet Teknisk

plattform

Ditt NAV nav.no

Innsending

AM-løsn

Te

kn

isk

pla

ttfo

rm

Innsyn

Dialoger

Sikkerhets-

rammeverk

Infrastruktur tilpasning (soner, nettverk)

Org og

ansatte Virksomhetsroller

Tilgj.het

Skalering

Info.forv.

Synk

Sam-satt

Prosesstyring

Vilkår og

beregn.

Krav-

dialog

Behandl-

info Fakta-

innsaml

Iverk-

setting

Linja Delvis implementering Modernisering

SU

auto

Uføre

auto

Produksjonsstyring

Manuell

behandl.

SU

manuell

Uføre

manuell

EDAG

Info.forv.

Egen-

vurdering

Lev 1

L

ev 2

L

ev 3

L

ev 4

Ny sonemodell To driftshaller Driftskonsolidering

……

……

……

……

..

Dok-

produksj.

Samtale-

støtte

Meldings-

boks

Full-

makter

Tilgangs-

admin Statistikk

SU mm

Oppgave-

kø

Statistikk

uføre

Over-

våkning

Alarmer og varsler

Over-

våkning

Dis-

covery

Testdata

auto

Nye

soner

Utfase gamle soner

Tilpasn.

PESYS

Avstem.

Dis-

covery

App.ram

meverk

Testdata

auto

Utbet-

dialog

Virtuell plattform

Integr.ra

mmeverk

EDAG

Le

ve

ran

se

0

Begreper

Begreper

Kodeverk

Statistikk

prosesser

Statistikk

prosesser

Statistikk

dialoger

Disp.regn

SU

kravdialog Krav

dagpeng.

Ytelsesktr

Statistikk

prosess Konfig-

kontroll

Deploy.-

ment

2-site

app.serv.

2-site

database

App.ram

meverk

Integr.ra

mmeverk

Testdata

auto

Over-

våkning

Applikasjonsrammeverk

Plattformtjenester

Sikkerhets-

rammeverk

Uføre

dialog

Uføre

forutsetn.

Tilpasn.

økonomi

NAV, 28.02.2016 Side 48

Knytning til absolutte krav i prosjekt 1 Informasjons-

plattform

Dialogarena Ytelser Virksomhets-

styring

Sikkerhet Teknisk

plattform

Ditt NAV nav.no

Innsending

AM-løsn

Tekn

isk

pla

ttfo

rm

Innsyn

Dialoger

Sikkerhets-

rammeverk

Infrastruktur tilpasning (soner, nettverk)

Org og

ansatte Virksomhetsroller

Tilgj.het

Skalering

Info.forv.

Synk

Sam-satt

Prosesstyring

Vilkår og

beregn.

Krav-

dialog

Behandl-

info Fakta-

innsaml

Iverk-

setting

Behandling av ytelser Samhandling Økonomireglement

SU

auto

Uføre

auto

Applikasjonsrammeverk

Produksjonsstyring

Manuell

behandl.

SU

manuell

Uføre

manuell

Uføre

dialog

EDAG

Info.forv.

Egen-

vurdering

Ny sonemodell To driftshaller Driftskonsolidering

……

……

……

……

..

Dok-

produksj.

Uføre

forutsetn.

Samtale-

støtte

Meldings-

boks

Full-

makter

Tilgangs-

admin Statistikk

SU mm

Oppgave-

kø

Statistikk

uføre

Tilpasn.

økonomi

Over-

våkning

Alarmer og varsler

Over-

våkning

Dis-

covery

Testdata

auto

Nye

soner

Utfase gamle soner

Tilpasn.

PESYS

Avstem.

Dis-

covery

App.ram

meverk

Testdata

auto

Utbet-

dialog

Virtuell plattform

Integr.ra

mmeverk

Fleksibilitet Sikkerhet (personvern) Stabil IKT-drift

Plattformtjenester

Sikkerhets-

rammeverk

EDAG

Begreper

Begreper

Kodeverk

Lev 1

L

ev 2

L

ev 3

L

ev 4

L

eve

ran

se

0

Statistikk

prosesser

Statistikk

prosesser

Statistikk

dialoger

Disp.regn

SU

kravdialog Krav

dagpeng.

Ytelsesktr

Statistikk

prosess Konfig-

kontroll

Deploy.-

ment

2-site

app.serv.

2-site

database

App.ram

meverk

Integr.ra

mmeverk

Testdata

auto

Over-

våkning

NAV, 28.02.2016 Side 49

Endringsevnen styres av krav og realiseres gjennom arkitektur

Løsning Løsning

Sluttbruker

Utvikler

Sluttbruker

System-

forvalter

Fagperson

Utvikler

Tekster, skjermbilder,

satser, vilkår,

beregninger,

grunnlagsdata

Regler

Tekster

Satser

Skjerm-

bilder

Brev-

maler

Grunnlags

data

Kodeverk

vilkår

1 dag

1-4 uker

1-6 måneder

Eksempel

NAV, 28.02.2016 Side 50

Pålitelighet i plattform og infrastruktur (stabil IKT-drift)

Parallell drift på to

driftssteder

Løpende synkronisering av

data

Full kapasitet servere,

nettverk lagring og annen

infrastruktur

Automatisk failover i alle lag

og mellom driftsstedene

Overvåkning

Løsning

A

Driftssted 1 Driftssted 2

Løsning

B

Løsning

A

Løsning

B

NAV, 28.02.2016 Side 51

Pålitelighet i løsninger

Løsningene skal takle at

andre løsninger ikke er

tilgjengelig og gir feil svar

Asynkron kommunikasjon der

det er hensiktsmessig

Online og batch i parallell

Enhetlig logging for effektiv

feilsøking

Løsning A

Løsning C Kø

Løsning D

X

X

Løsning B

X

NAV, 28.02.2016 Side 52

Agenda




Erfaringer

NAV, 28.02.2016 Side 53

Erfaringer – metode og verktøy Metode

– Helhetlig metode vs pragmatisk tilnærming

– Spesialist vs generalist

– Linje vs prosjekt

Modellering og verktøy – Behov for modellering – modelleringsverktøy bra

– Behov for presentasjon – modelleringsverktøy mindre bra

– Pragmatisk – ikke alt kan automatiseres

Dokumentere og formidle – Felles forståelse av metode og verktøy

– Tydelig hvilke perspektiver som modelleres og hvordan

– Gjennomføre opplæring – nytt for mange

Erfaring – Nødvendig med bred metodeforståelse sammen med praktisk

verktøykompetanse

– Sette av tilstrekkelig ressurser til å forstå behov, dokumentere

metode, tilpasse verktøy og formidle og følge opp bruk

NAV, 28.02.2016 Side 54

Erfaringer – eierskap

Eierskap og involvering – Behov for felles, helhetlig målbilde og eierskap til dette

– Eierskap til detaljerte målbilder må også plasseres

– Samhandling linje og prosjekt – Linja har langsiktig eierskap

– Prosjektet har behov for rask framdrift

Erfaringer – Alle har det travelt, linje og prosjekt har forskjellig prioritering

– Involvering er nødvendig – men tar tid

– Åpenhet og tiltro – felles mål

– Eierskap, prosesser og myndighet må avklares og forankres

– Etablere prosesser for å forvalte arkitekturen

– Tydelig kommunisere hvordan beslutninger tas, hvem tar

beslutninger og hvilke beslutninger er tatt

NAV, 28.02.2016 Side 55

Erfaringer – arkitektur

Arkitekturmodeller – Top-down vs buttom-up

– Overordnet vs detaljer

– Virksomhetsarkitekter vs modellerere

– Forretning vs informasjon vs applikasjon

Arkitekturdokumentasjon – Arkitekturen må være tilgjengelig – modelleringsverktøy ikke nok

– Arkitekturbeslutninger må begrunnes og dokumenteres tilstrekkelig

– Formidling og informasjonsdeling er viktig – og tidskrevende

Erfaringer – Alle har det travelt, områdene har forskjellig fokus

– Start modellering tidlig og gjør løpende endringer

– Modeller i felles verktøy slik at de kan henge sammen

– Verktøy og modelleringskompetanse må være på plass

– Felles modelleringsteam?

NAV, 28.02.2016 Side 56

Oppsummering

Tilpass omfang og fremgangsmåten til situasjonen

Finn balanse mellom metode og pragmatisk tilnærming

Plasser ansvar for arkitekturen i både linje og prosjekt

Plasser ansvar og etabler tilstrekkelig med metode og

verktøy og bruk tid på å formidle og følge opp

Sørg for nok ressurser til å modellere og dokumentere

Aksepter at det går mye tid til formidling og forankring

Innse at arkitekter ikke alltid er gode prosjektledere…

NAV, 28.02.2016 Side 57

Spørsmål?

NAV, 28.02.2016 Side 58

Ekstra foiler

NAV, 28.02.2016 Side 59

NAVs arkitekter i programmet

Løsning

Ytelser Dialogarena Virksomhets-

styring

Tjenester

Områdearkitekt NAV (3)

Løsningsarkitekt leverandør

Løsningsarkitekt NAV (9)

Informasjons-

sikkerhet Informasjon

Virksomhetsarkitekt NAV (4)

Infrastruktur,

plattform og

rammeverk

Informasjonsarkitekt NAV (4)

Forretning

Forretningsarkitekt NAV (1)

Overo

rdnet

Funksjo

nelt

Tve

rrgående

NAV, 28.02.2016 Side 60

Roller i arkitekturstyringen

FA

Test

Ark

PL

Utv Utv

Utv

Utv

FA

Test

Ark

PL

Utv Utv

Utv

Utv

Løsningsarkitekt

Leve

ran

se

str

øm

Leverandørene

utarbeider

løsningsbeskrivelser

• Løsningsarkitekt utarbeider løsningsarkitektur

• QA fra NAV

• Løsningsarkitekten kvalitetssikrer

leverandørenes løsningsbeskrivelser

Leveranseledelse

MOD Arkitektur

Arkitekturbeslutninger

løftes til MODs

arkitekturteam

Sjefsarkitekt NAV og sjefsarkitekt

MOD koordinerer kvalitetssikring

av arkitekturen

NAV IKT

SKILL

Arkitektur

Arkitektur-

forum IKT

IKT-

ledelsen

Ved behov eskaleres

arkitekturbeslutninger

i NAV IKT

LBF-

team

LBF-

team

SKILL Integrasjons-

senteret

NAV, 28.02.2016 Side 61

Arkitektur og NAVs leveransemetode

Produksjons-

sette

Akseptanseteste

og godkjenne Konstruere

Etablere og

planlegge

Bearbeide

produktkø

Avklare

behov

Pro

sje

kt m

ed

levera

ndø

rer

Løsnings-

beskrivelse

Bruker-

historie Epos

Tjeneste-

beskrivelse

System-

dokumentasjon

Arkitekturkontroll Arkitekturstyring

Løsnings-

arkitektur

Pro

sje

kt

Llin

je-

funksjo

n Prosess-

modeller

Informasjons-

modell

Andre

artefakter

Varig dokumentasjon

Prosjektdokumentasjon

Applikasjons-

arkitektur

NAV, 28.02.2016 Side 62

Jira

og

Co

nflu

en

ce

Forenklet metamodell virksomhetsarkitektur for Modernisering

Logisk entitet

Fase C Informasjon

Fysisk entitet

Er avledet av

Realiserer Realiserer

Fysisk teknisk

komponent Kjører på

Realiserer

IKT-tjeneste

Realiserer

Prosess/

Aktivitet

Fase B Benytter

Fase D

Fase E

Epos

Bruker-

historie

Består

av Togaf-fase

Logisk

tjeneste

Tjeneste

Hendelse

Klassifisering

Ente

rprise A

rchitect

Krav/ behov

Ikke-

funksjon

elle krav

Klassifisering

Rolle Utfører

Klassifisering

Relasjon som ikke modelleres i EA

Fysisk

applikasjon

Logisk

applikasjon

Logisk

teknisk

komponent

Plattform-

tjeneste

Kre

ve

r

Re

alis

ere

r

Forenklet metamodell virksomhetsarkitektur

NAV, 28.02.2016 Side 63

Løsningsprinsipp Arkitektur og endringsevne

Utforming av løsningsarkitekturen

må ta hensyn til hvert områdes

endringstakt

Gartners tredeling av arkitektur: – Systems of Innovation (levetid 1-3 år)

– Systems of Differention (levetid 8-10 år)

– Systems of Records (levetid 20-25 år)

Strenge krav til arkitekturstabilitet

for infrastruktur, sikkerhet,

informasjon og elektronisk

samhandling mellom løsninger

Software

2012 10-24 ark2012 - arkitektur i mod