1. Smidig arkitektur
Software 2013 – Den norske dataforeningen
Petter Hafskjold, sjefsarkitekt 14. februar 2013
NAV // Moderniseringsprogrammet
2. NAV, 28.02.2016 Side 2
Agenda
Kort om NAV og Moderniseringsprogrammet
Smidig arkitektur?
Utfordringer og 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 2012 ca 350 milliarder kroner
– Arbeid, Familie, Pensjon, Helse
NAV IKT
– 300 systemer fordelt på 12 forvaltningsporteføljer
– 425 ansatte innen drift og forvaltning
– 200 innleide fra leverandører for forvaltning og utvikling
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
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
D. Forbedre kvalitet i behandling av ytelser
Utvikling av sikkerhetsarkitektur
6. NAV, 28.02.2016 Side 6
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
7. NAV, 28.02.2016 Side 7
Agenda
Kort om NAV og Moderniseringsprogrammet
Smidig arkitektur?
Utfordringer og erfaringer
8. NAV, 28.02.2016 Side 8
Målsetning med arkitekturarbeidet
Sikre at arkitekturen i programmet følger NAVs prinsipper,
målbilder og krav
Sikre helhetlig arkitektur internt i programmet og samspill
ned NAVs totale arkitektur
– Utarbeide overordnet løsningsarkitektur, referansearkitektur mm
– Utarbeide løsningsarkitektur for hvert funksjonelt område
Legge premisser for prioritering av produktkøen
Sikre riktig kvalitet i programmets leveranser
– Kvalitetssikre leverandørenes løsningsbeskrivelser
9. NAV, 28.02.2016 Side 9
Manifest for smidig programvareutvikling
Personer og samspill fremfor prosesser og verktøy
Programvare som virker fremfor omfattende
dokumentasjon
Samarbeid med kunden fremfor kontraktsforhandlinger
Å reagere på endringer fremfor å følge en plan
Utvalgte prinsipper
– Den mest effektive måten å formidle informasjon inn til og innad i et
utviklingsteam, er å snakke ansikt til ansikt.
– De beste arkitekturer, krav og design vokser frem fra selvstyrte team
12. NAV, 28.02.2016 Side 12
Hvor mye arkitektur?
Et team med definert mål, lite avhengighet til andre og må
stor frihet kan ta stort ansvar for sin arkitektur
FA
Test
Ark
PL
UtvUtv
Utv
Utv
Løsningsarkitekt
Utviklings-
team
Produkt-
eier
Arkitekt
13. NAV, 28.02.2016 Side 13
Hvor mye arkitektur?
FA
Test
Ark
PL
UtvUtv
Utv
Utv
Funksjonelt
område
Utviklings-
team
FA
Test
Ark
PL
UtvUtv
Utv
Utv
Utviklings-
team
FA
Test
Ark
PL
UtvUtv
Utv
Utv
Utviklings-
team
Produkt-
eier
Arkitekter
Mange team med avhengigheter og målsetning om felles
arkitektur krever mer arkitektur og styring
14. NAV, 28.02.2016 Side 14
Arkitekturstyringen
MOD Arkitektur
NAV IKT
Arkitektur
Arkitektur-
forum IKT
IKT-
ledelsen
Integrasjons-
senteret
FA
Test
Ark
PL
UtvUtv
Utv
Utv
Funksjonelt
område
Utviklings-
team
FA
Test
Ark
PL
UtvUtv
Utv
Utv
Utviklings-
team
FA
Test
Ark
PL
UtvUtv
Utv
Utv
Utviklings-
team
Produkt-
eier
Arkitekter
15. NAV, 28.02.2016 Side 15
MOD Arkitektur
NAVs arkitekter i programmet
Ytelser Dialogarena
Virksomhets-
styring
Tjenester
Løsningsarkitekt leverandør
Løsningsarkitekt NAV (10)
Informasjons-
sikkerhet
Informasjon
Virksomhetsarkitekt NAV (4)
Infrastruktur,
plattform og
rammeverk
Informasjonsarkitekt NAV (5)
Forretningsarkitekt NAV (4)
OverordnetFunksjoneltTverrgående
Sikkerhetsarkitekt NAV (2)
Ca 25 arkitekter på kundesiden
16. NAV, 28.02.2016 Side 16
Helhetlig arkitektur betyr forskjellige ting
for forskjellige grupper
Oppstrøms: Gjøre de rette tingene
Identifisere, finansiere
og gi ressurser til de
viktigste prosjektene, i
tråd med forretnings-
strategi, innenfor
budsjett, i riktig
rekkefølge og med
effektiv prosjektledelse
og kontroll.
Kilde: Doing the right things right,
Enterprise Architecture for UK Government Organisations IBM, 2007
Nedstrøms: Gjøre tingene riktig
Sikre at løsninger
prosjektene leverer
møter forretningens
behov, virker sammen
med eksisterende
IKT-miljø og bidrar til
å realisere IT-
strategien.
17. NAV, 28.02.2016 Side 17
Referansemodell / inndeling av arkitekturen
Informasjon
Forretning
Applikasjon
Teknologi
Sikkerhet
Tjenesteorientering
Etterlevelse
18. NAV, 28.02.2016 Side 18
Informasjon
Forretning
Applikasjon
Teknologi
Løsnings-
arkitektur
Løsninger
Referanse-
arkitekturer
Arkitekturarbeid i to dimensjoner
Referansearkitektur er en av flere input til målbilder
Nå-situasjon
Målbilder
Gap og
migrering
Presentasjon
Tjenester
Prosesser
Forretnings-
komponenter
Datakilder
Plattform
Infrastruktur
Brukerdialog
Saks-
behandling
Økonomi
Dokumenter
og innhold
Plattform
Infrastruktur
Virksomhets-
styring
19. NAV, 28.02.2016 Side 19
Gjøre de rette tingeneGjøre tingene riktig
Informasjon
Forretning
Applikasjon
Teknologi
Løsnings-
arkitektur
Løsninger
Referanse-
arkitekturer
Arkitekturarbeid i to dimensjoner
Nå-situasjon
Målbilder
Gap og
migrering
Presentasjon
Tjenester
Prosesser
Forretnings-
komponenter
Datakilder
Plattform
Infrastruktur
Brukerdialog
Saks-
behandling
Økonomi
Dokumenter
og innhold
Plattform
Infrastruktur
Virksomhets-
styring
20. NAV, 28.02.2016 Side 20
Referansearkitektur i forprosjektet
Utarbeidet en rekke overordnede mønstre og prinsipper i
forprosjektet
21. NAV, 28.02.2016 Side 21
Det etableres applikasjonsrammeverk for
å sikre kvalitet og enhetlig utvikling
Rammeverks-
team
• Teammedlemmer fra de
forskjellige leverandørene
• Utviklere bytter mellom
rammeverksteam og
utviklerteam
Applikasjons-
rammeverk
Eksempel-
applikasjoner
Utviklerhåndbok
NAV IKT
Arkitektur
Detaljering og videreutvikling
av referansearkitektur
22. NAV, 28.02.2016 Side 22
Rammeverk må være på rett nivå
Retningslinjer: Bruk av felles prinsipper, retningslinjer, patterns, beste
praksis osv
Standard: Krav til bruk av standarder, for eksempel Wicket, Web
Services, SAML etc
Standard rammeverk: Krav til bruk av rammeverk og standard
biblioteker
Egenutviklet rammeverk: Egenutvikling eller overbygg på
standardrammeverk.
Retningslinjer
Standard
Standard rammeverk
Egenutvikling
Lav kostnad
Lav grad av styring
Høy endringstakt
Høy kostnad
Høy grad av styring
Lav endringstakt
23. NAV, 28.02.2016 Side 23
Bruker-
historie
Bruker-
historie
Løsningsarkitektur
Prosessmodeller (på mange nivåer), epos og
brukerhistorier beskriver funksjonelle krav
Løsningsarkitekturen beskrives overordnet funksjonelt og
mer teknisk for hvert funksjonelt område
Leverandørene utarbeider mer detaljerte
løsningsbeskrivelser som grunnlag for utvikling
Epos
Funksjonell løsningsarkitektur
Bruker-
historie
Løsnings-
arkitektur
Løsnings-
arkitektur
Prosesser
Epos
Løsnings-
beskrivelse
Løsnings-
beskrivelse
Bruker-
historie
Bruker-
historie
Bruker-
historie
24. NAV, 28.02.2016 Side 24
Funksjonell løsningsarkitektur
Oversikt over
funksjonelle områder
prosjektet skal levere
– funksjonell
dekomponering
Detaljeres i løsnings-
arkitekturer
25. NAV, 28.02.2016 Side 25
NAVs systemleveransemetode - SLEM
Behov, arkitektur og løsningsbeskrivelse utvikles gradvis i
prosesstegene Avklare behov, Bearbeide produktkø, Etablere
og planlegge og Konstruere
Beslutningspunkter ligger mellom hvert prosessteg
Behov, arkitektur og løsning beskrives kun til det detaljnivået
som er tilstrekkelig for det aktuelle beslutningspunktet
Avklare
behov
Bearbeide
produktkø
Etablere og
planlegge
Konstruere
Akseptanse-
teste og
godkjenne
Produksjon-
sette
Produktkø Leveranse
26. NAV, 28.02.2016 Side 26
Behov, arkitektur, løsningsbeskrivelse og
utvikling skjer i parallell
Løsningsbeskrivelse
Behov og krav
Arkitektur
Utvikling
• Brukerhistorier
• Løsningsarkitektur
• Brukerhistorier med scenarier
• Løsningsbeskrivelser
• Prosessmodeller
• Epos
• Funksjonell arkitektur
27. NAV, 28.02.2016 Side 27
Arkitekturen formes i stor grad av ikke-
funksjonelle krav / produktkvalitet
Stor menge ikke-funksjonelle krav fra linjeorganisasjonen
Strukturert etter ISO 25010 + etterlevelse og informasjonsforvaltning
28. NAV, 28.02.2016 Side 28
Kvalitetskrav
Forretnings-
mål
Kvalitets-
attributter
Arkitektur
Bestemmer Bestemmer
Støtter Tilfredsstiller
29. NAV, 28.02.2016 Side 29
ATAM for å veie funksjonalitet, kvalitetskrav
og risiko som grunnlag for arkitekturvalg
31. NAV, 28.02.2016 Side 31
Verktøystøtte for produktkø og arkitektur
• Prosessmodeller
• Informasjonsmodell
• Løsningsarkitektur
• Kobling til epos og
brukerhistorier
• EPOS og brukerhistorier
og sammenhenger
• Arkitekturbeslutninger
• Dokumentasjon av epos og brukerhistorier
• Grunnlag for arkitekturbeslutninger
• Beskrivelse av løsningsarkitektur
• Løsningsbeskrivelser
• Drift- og systemdokumentasjon
• Figurer fra Sparx EA ved behov
32. NAV, 28.02.2016 Side 32
Agenda
Kort om NAV og Moderniseringsprogrammet
Smidig arkitektur?
Utfordringer og erfaringer
33. NAV, 28.02.2016 Side 33
Personer og samspill fremfor prosesser
og verktøy
Personer skalerer ikke godt nok…
De riktige personene (eierskap) må identifiseres, ansvar
tydeliggjøres og tid settes av
Dokumentasjon både for å huske og formidle –
dokumentasjon må være lett tilgjengelig og det må settes
av tid til å formidle arkitekturen
Prosesser og verktøy er nødvendig for å sikre oversikt,
fremdrift og etterprøvbarhet – men de må brukes i praksis
og en må være pragmatisk (ikke alt kan bli automatisk og
metoden kan ikke lages perfekt i forkant)
Smidig er også en prosess og krever kompetanse hos både
kunde og leverandør – nødvendig å dokumentere og følge
opp metode med teamene
34. NAV, 28.02.2016 Side 34
Programvare som virker fremfor
omfattende dokumentasjon
Modeller og «nok» dokumentasjon er nødvendig for å få
gjennomsiktighet i arkitekturvalg og sikre at overordnet
arkitektur følges
Dokumentasjon av arkitektur, beslutninger og grunnlag for
disse hindrer unødvendige diskusjoner og omkamper
For sene endringer i behov gir mer kostbar utvikling
Dokumentasjon er nødvendig for en effektiv langsiktig
forvaltning og hindre leverandørbinding
Smart dokumentasjon (inkluder f.eks. Javadoc, feilrapport
fra Jira etc)
35. NAV, 28.02.2016 Side 35
Samarbeid med kunden fremfor
kontraktsforhandlinger
Smidige kontrakter som grunnlag
– Omfattende kontraktsarbeid i forkant av prosjektet
Oppdragsavtaler som dekker noen sprinter
– Løsningsbeskrivelser med estimater nødvendig for å vurdere
kost/nytte og om budsjett er tilstrekkelig for god nok løsning
Målpris for å sikre fremdrift uten å beskrive løsning
unødvendig detaljert
36. NAV, 28.02.2016 Side 36
Å reagere på endringer fremfor å følge en
plan
Tidsfrister og avhengigheter mellom funksjonelle områder
og leverandører gir behov for plan
Grad av styring fra linjeorganisasjonen påvirker hvor mye
endring det er rom for – tidlig avklaring av funksjonelt
omfang og overordnet arkitektur kan gi mer endringsevne i
selve prosjektet
Arkitektur og teknologivalg må ligge tilstrekkelig i forkant
av utvikling og plan er nødvendig for å ikke hindre
utvikling
Både prosjektledere og arkitekter er nødvendig
– mye mer en arkitekturen må på plass for å få godt
arkitekturarbeid og god arkitekturstyring!
37. NAV, 28.02.2016 Side 37
Oppsummering
Smidig arkitektur krever ovenfra og ned-tilnærming –
kontroll på helhet gir frihet for teamene
Smidig arkitektur krever klare roller, klart eierskap og nok
dokumentasjon
Smidig arkitektur krever arkitekter som er tett på, formidler
og tar valg
Smidig arkitektur er krevende, men gøy!