Presentasjon på ARK2012 om arkitekturen som legges til grunn for Modernisering av IKT i NAV

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

2. NAV, 28.02.2016 Side 2
Agenda
 Kort om NAV og Moderniseringsprogrammet
 Arkitekturutvikling i planleggingsfasen
 Forankring av arkitekturmålbildet
 Erfaringer

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

4. 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.”

5. NAV, 28.02.2016 Side 5
Store prosjekter skal gjennomgå
Finansdepartementets kvalitetssikringsprosess
Ref. veileder nr. 3

6. 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
Forberede
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

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

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

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

10. NAV, 28.02.2016 Side 10
Agenda
 Kort om NAV og Moderniseringsprogrammet
 Arkitekturutvikling i planleggingsfasen
– Hvorfor arkitektur?
– Prosessmodeller
– Informasjonsarkitektur
– Applikasjons- og teknologiarkitektur
 Forankring av arkitekturmålbildet
 Erfaringer

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

12. NAV, 28.02.2016 Side 12
Agenda
 Kort om NAV og Moderniseringsprogrammet
 Arkitekturutvikling i planleggingsfasen
– Hvorfor arkitektur?
– Prosessmodeller
– Informasjonsarkitektur
– Applikasjons- og teknologiarkitektur
 Forankring av arkitekturmålbildet
 Erfaringer

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

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

15. 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?

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

17. NAV, 28.02.2016 Side 17
Det ble etablert et helhetlig oversikt over NAVs
fremtidige prosesser

18. 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
ProsjektleveranserStyrendedokumenter
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

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

20. NAV, 28.02.2016 Side 20
Agenda
 Kort om NAV og Moderniseringsprogrammet
 Arkitekturutvikling i planleggingsfasen
– Hvorfor arkitektur?
– Prosessmodeller
– Informasjonsarkitektur
– Applikasjons- og teknologiarkitektur
 Forankring av arkitekturmålbildet
 Arkitektur og produktkø
 Erfaringer

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

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

23. NAV, 28.02.2016 Side 23
Domenemodell

24. NAV, 28.02.2016 Side 24
Agenda
 Kort om NAV og Moderniseringsprogrammet
 Arkitekturutvikling i planleggingsfasen
– Hvorfor arkitektur?
– Prosessmodeller
– Informasjonsarkitektur
– Applikasjons- og teknologiarkitektur
 Forankring av arkitekturmålbildet
 Erfaringer

25. NAV, 28.02.2016 Side 25
Problemer med dagens arkitektur og
løsninger ble identifisert
UnikID
(P1, P2,…n)
Prioritering
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)
Fleksibilitet
Økonomireglemente
t
Sikkerhet
StabilIKTdrift
Uføre
Sykdom
Arbeidogaktivitet
Pensjon
Integrasjonssenter
Fellessystemer
Familie
Bidrag
Selvbetjeningog
portal
Helse
Statistikkog
datavarehus
Basis
Brevogarkiv
Økonomiog
logistikk
HR
Unik
ID Beskrivelse Type
P069 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

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

27. NAV, 28.02.2016 Side 27
Nå-situasjon for sentral applikasjoner ble
kartlagt
Selvbetjening og portaler
Pensjon Familieytelser og bidragArbeid 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
Integrasjonssenter
NAV
tjenestebuss
Fagsystemer
SBL, helse og
basissystemer
Administrative systemer SKILL
SBL Arbeid
BISYS
Basis
TPS
TSS
AA-reg Avgift
RemedyFR TPMedl
BPROF INNT
INST NORG

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

29. 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
ModerniseringApplikasjons- og teknologiarkitektur
Nå-situasjon
app. og teknologi
Nå-situasjon
applikasjoner
og teknologi

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

31. NAV, 28.02.2016 Side 31
Arkitekturkrav ble utarbeidet
 Overordnet
 Tjeneste og prosess
 Brukerinteraksjon
 Elektronisk samhandling
 Informasjon
 Datavarehus
 Sikkerhet
 Drift
 Infrastruktur

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

33. NAV, 28.02.2016 Side 33
Basert på prosessmodellarbeidet ble
funksjonelle komponenter identifisert

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

35. NAV, 28.02.2016 Side 35
Enkle løsningsskisser laget for KS2

36. 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
PlattformnavnPlattformnavnPlattformnavn
zOS
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

37. 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)

38. 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 TeknologiArkitekturArkitektur

39. NAV, 28.02.2016 Side 39
Agenda
 Kort om NAV og Moderniseringsprogrammet
 Arkitekturutvikling i planleggingsfasen
 Forankring av arkitekturmålbildet
 Erfaringer

40. NAV, 28.02.2016 Side 40
Prosessmodeller gjennomgått og
besluttet i D-møte

41. 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å-situasjonMålbilde

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

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

44. 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
hendelser
Kø
Virksomhets-
prosess
Hendelse
Hendelsesstyring
Regler for
hendelser
Kø
Virksomhets-
prosess
Krav mottatt
Behandle krav
Utbetaling
Positivt vedtak

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

46. 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-
tjeneste
Publiserings
løsning

47. 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
Teknisk
plattform
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
LinjaDelvis implementeringModernisering
SU
auto
Uføre
auto
Produksjonsstyring
Manuell
behandl.
SU
manuell
Uføre
manuell
EDAG
Info.forv.
Egen-
vurdering
Lev1Lev2Lev3Lev4
Ny sonemodell To driftshallerDriftskonsolidering
……………………..
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
Leveranse0
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

48. 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
Teknisk
plattform
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 ytelserSamhandling Ø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 driftshallerDriftskonsolidering
……………………..
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
Lev1Lev2Lev3Lev4Leveranse0
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

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

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

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

52. NAV, 28.02.2016 Side 52
Agenda
 Kort om NAV og Moderniseringsprogrammet
 Arkitekturutvikling i planleggingsfasen
 Forankring av arkitekturmålbildet
 Erfaringer

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

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

55. 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?

56. 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…

57. NAV, 28.02.2016 Side 57
Spørsmål?

58. NAV, 28.02.2016 Side 58
Ekstra foiler

59. 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)
OverordnetFunksjoneltTverrgående

60. NAV, 28.02.2016 Side 60
Roller i arkitekturstyringen
FA
Test
Ark
PL
UtvUtv
Utv
Utv
FA
Test
Ark
PL
UtvUtv
Utv
Utv
Løsningsarkitekt
Leveransestrø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

61. NAV, 28.02.2016 Side 61
Arkitektur og NAVs leveransemetode
Produksjons-
sette
Akseptanseteste
og godkjenne
Konstruere
Etablere og
planlegge
Bearbeide
produktkø
Avklare
behov
Prosjektmed
leverandører
Løsnings-
beskrivelse
Bruker-
historie
Epos
Tjeneste-
beskrivelse
System-
dokumentasjon
ArkitekturkontrollArkitekturstyring
Løsnings-
arkitektur
Prosjekt
Llinje-
funksjon
Prosess-
modeller
Informasjons-
modell
Andre
artefakter
Varig dokumentasjon
Prosjektdokumentasjon
Applikasjons-
arkitektur

62. NAV, 28.02.2016 Side 62
JiraogConfluence
Forenklet metamodell
virksomhetsarkitektur for Modernisering
Logisk entitet
Fase C Informasjon
Fysisk entitet
Er avledet av
RealisererRealiserer
Fysisk teknisk
komponent
Kjører på
Realiserer
IKT-tjeneste
Realiserer
Prosess/
Aktivitet
Fase B
Benytter
Fase D
Fase E
Epos
Bruker-
historie
Består
avTogaf-fase
Logisk
tjeneste
Tjeneste
Hendelse
Klassifisering
EnterpriseArchitect
Krav/ behov
Ikke-
funksjon
elle krav
Klassifisering
RolleUtfører
Klassifisering
Relasjon som ikke modelleres i EA
Fysisk
applikasjon
Logisk
applikasjon
Logisk
teknisk
komponent
Plattform-
tjeneste
Krever
Realiserer
Forenklet metamodell virksomhetsarkitektur

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