SlideShare uma empresa Scribd logo
1 de 38
Baixar para ler offline
Smidig arkitektur
Software 2013 – Den norske dataforeningen
Petter Hafskjold, sjefsarkitekt 14. februar 2013
NAV // Moderniseringsprogrammet
NAV, 28.02.2016 Side 2
Agenda
 Kort om NAV og Moderniseringsprogrammet
 Smidig arkitektur?
 Utfordringer og 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 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
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
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
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
NAV, 28.02.2016 Side 7
Agenda
 Kort om NAV og Moderniseringsprogrammet
 Smidig arkitektur?
 Utfordringer og erfaringer
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
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
NAV, 28.02.2016 Side 10
Smidig utvikling
Leveransekø LeveranseIterasjon
Daglig gjennomgang
Historier
Tilbakemeldinger
Kontroll-
punktet
NAV, 28.02.2016 Side 11
… men vi trenger mer
Arkitektur
Behov og krav
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
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
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
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
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.
NAV, 28.02.2016 Side 17
Referansemodell / inndeling av arkitekturen
Informasjon
Forretning
Applikasjon
Teknologi
Sikkerhet
Tjenesteorientering
Etterlevelse
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
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
NAV, 28.02.2016 Side 20
Referansearkitektur i forprosjektet
 Utarbeidet en rekke overordnede mønstre og prinsipper i
forprosjektet
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
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
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
NAV, 28.02.2016 Side 24
Funksjonell løsningsarkitektur
 Oversikt over
funksjonelle områder
prosjektet skal levere
– funksjonell
dekomponering
 Detaljeres i løsnings-
arkitekturer
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
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
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
NAV, 28.02.2016 Side 28
Kvalitetskrav
Forretnings-
mål
Kvalitets-
attributter
Arkitektur
Bestemmer Bestemmer
Støtter Tilfredsstiller
NAV, 28.02.2016 Side 29
ATAM for å veie funksjonalitet, kvalitetskrav
og risiko som grunnlag for arkitekturvalg
NAV, 28.02.2016 Side 30
Innarbeider ATAM i NAV IKTs
leveransemetode
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
NAV, 28.02.2016 Side 32
Agenda
 Kort om NAV og Moderniseringsprogrammet
 Smidig arkitektur?
 Utfordringer og erfaringer
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
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)
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
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!
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!
NAV, 28.02.2016 Side 38
Spørsmål?

Mais conteúdo relacionado

Destaque

Prosjektledelseprosjektoppgave Master of Management
Prosjektledelseprosjektoppgave Master of ManagementProsjektledelseprosjektoppgave Master of Management
Prosjektledelseprosjektoppgave Master of ManagementRaymond Hesthaug
 
Hvordan øke leveransehastigheten gjennom kontinuerlig leveranse
Hvordan øke leveransehastigheten gjennom kontinuerlig leveranseHvordan øke leveransehastigheten gjennom kontinuerlig leveranse
Hvordan øke leveransehastigheten gjennom kontinuerlig leveranselarsjoakimnilsson
 
Customer development og smidig - som hånd i hanske?
Customer development og smidig - som hånd i hanske?Customer development og smidig - som hånd i hanske?
Customer development og smidig - som hånd i hanske?Benjamin Sommer
 
TINE Gruppas årsresultat 2015
TINE Gruppas årsresultat 2015TINE Gruppas årsresultat 2015
TINE Gruppas årsresultat 2015TINE Gruppa
 
Foredrag smidig 2015 Eli Toftøy-Andersen Sopra Steria
Foredrag smidig 2015 Eli Toftøy-Andersen Sopra SteriaForedrag smidig 2015 Eli Toftøy-Andersen Sopra Steria
Foredrag smidig 2015 Eli Toftøy-Andersen Sopra SteriaEli Toftøy-Andersen
 
Prosjektveiviseren med Scrum
Prosjektveiviseren med ScrumProsjektveiviseren med Scrum
Prosjektveiviseren med ScrumSmidigkonferansen
 
Linda Nilsen Methi: Internkommunikasjon som endrer
Linda Nilsen Methi: Internkommunikasjon som endrerLinda Nilsen Methi: Internkommunikasjon som endrer
Linda Nilsen Methi: Internkommunikasjon som endrerNorsk kommunikasjonsforening
 

Destaque (8)

Prosjektledelseprosjektoppgave Master of Management
Prosjektledelseprosjektoppgave Master of ManagementProsjektledelseprosjektoppgave Master of Management
Prosjektledelseprosjektoppgave Master of Management
 
Hvordan øke leveransehastigheten gjennom kontinuerlig leveranse
Hvordan øke leveransehastigheten gjennom kontinuerlig leveranseHvordan øke leveransehastigheten gjennom kontinuerlig leveranse
Hvordan øke leveransehastigheten gjennom kontinuerlig leveranse
 
Customer development og smidig - som hånd i hanske?
Customer development og smidig - som hånd i hanske?Customer development og smidig - som hånd i hanske?
Customer development og smidig - som hånd i hanske?
 
Din digitale forretning
Din digitale forretningDin digitale forretning
Din digitale forretning
 
TINE Gruppas årsresultat 2015
TINE Gruppas årsresultat 2015TINE Gruppas årsresultat 2015
TINE Gruppas årsresultat 2015
 
Foredrag smidig 2015 Eli Toftøy-Andersen Sopra Steria
Foredrag smidig 2015 Eli Toftøy-Andersen Sopra SteriaForedrag smidig 2015 Eli Toftøy-Andersen Sopra Steria
Foredrag smidig 2015 Eli Toftøy-Andersen Sopra Steria
 
Prosjektveiviseren med Scrum
Prosjektveiviseren med ScrumProsjektveiviseren med Scrum
Prosjektveiviseren med Scrum
 
Linda Nilsen Methi: Internkommunikasjon som endrer
Linda Nilsen Methi: Internkommunikasjon som endrerLinda Nilsen Methi: Internkommunikasjon som endrer
Linda Nilsen Methi: Internkommunikasjon som endrer
 

Semelhante a 2013 02-14 sw2013 - smidig arkitektur i nav

Presentasjon NAV frokostseminar anskaffelser_211010
Presentasjon NAV frokostseminar anskaffelser_211010Presentasjon NAV frokostseminar anskaffelser_211010
Presentasjon NAV frokostseminar anskaffelser_211010Devoteam daVinci
 
Gøyere med VisGI - BK2016
Gøyere med VisGI - BK2016Gøyere med VisGI - BK2016
Gøyere med VisGI - BK2016Geodata AS
 
Frokostmote 12 april 2018 Nye Veier
Frokostmote 12 april 2018 Nye VeierFrokostmote 12 april 2018 Nye Veier
Frokostmote 12 april 2018 Nye VeierIngrid Dahl Hovland
 
Strøm 1 - Kai Haakon Kristensen - Prestasjonsmålinger i prosjektering av bygg...
Strøm 1 - Kai Haakon Kristensen - Prestasjonsmålinger i prosjektering av bygg...Strøm 1 - Kai Haakon Kristensen - Prestasjonsmålinger i prosjektering av bygg...
Strøm 1 - Kai Haakon Kristensen - Prestasjonsmålinger i prosjektering av bygg...Prosjekt 2013
 
2013 - Strøm 2 - Synnøve Frafjord - Hvordan bestille lean gjennomføring
2013 - Strøm 2 - Synnøve Frafjord - Hvordan bestille lean gjennomføring2013 - Strøm 2 - Synnøve Frafjord - Hvordan bestille lean gjennomføring
2013 - Strøm 2 - Synnøve Frafjord - Hvordan bestille lean gjennomføringProsjekt 2013
 
CV, Konsulentprofil - Jan Aage Aagaard
CV, Konsulentprofil - Jan Aage AagaardCV, Konsulentprofil - Jan Aage Aagaard
CV, Konsulentprofil - Jan Aage AagaardJan Aage Aagaard
 
150617 ba2015-frokostmøte Bygg og anlegg som virker og yter - VDC og ICE/ISI
150617 ba2015-frokostmøte Bygg og anlegg som virker og yter - VDC og ICE/ISI150617 ba2015-frokostmøte Bygg og anlegg som virker og yter - VDC og ICE/ISI
150617 ba2015-frokostmøte Bygg og anlegg som virker og yter - VDC og ICE/ISILars Chr Christensen
 
Erfaringer med smidig i BarentsWatch
Erfaringer med smidig i BarentsWatchErfaringer med smidig i BarentsWatch
Erfaringer med smidig i BarentsWatchSmidigkonferansen
 
Øyvind Aarvig: Hvordan blir livet i framtidens byer?
Øyvind Aarvig: Hvordan blir livet i framtidens byer?Øyvind Aarvig: Hvordan blir livet i framtidens byer?
Øyvind Aarvig: Hvordan blir livet i framtidens byer?IKT-Norge
 
Jens Nørve: Utvikling gjennom samarbeid - deling og gjenbruk
Jens Nørve: Utvikling gjennom samarbeid - deling og gjenbrukJens Nørve: Utvikling gjennom samarbeid - deling og gjenbruk
Jens Nørve: Utvikling gjennom samarbeid - deling og gjenbrukFriprogsenteret
 
SIK Fredrikstad - Presentation om övergripande projekt
SIK Fredrikstad - Presentation om övergripande projektSIK Fredrikstad - Presentation om övergripande projekt
SIK Fredrikstad - Presentation om övergripande projektSvenskt Projektforum
 
Statnett Balance settlement conference 2015 - Ole Marius Haugene Nansdal, En...
Statnett Balance settlement conference 2015 -  Ole Marius Haugene Nansdal, En...Statnett Balance settlement conference 2015 -  Ole Marius Haugene Nansdal, En...
Statnett Balance settlement conference 2015 - Ole Marius Haugene Nansdal, En...eSett
 
Utvikling av webløsning ved hjelp av fri programvare og cloud computing, bjør...
Utvikling av webløsning ved hjelp av fri programvare og cloud computing, bjør...Utvikling av webløsning ved hjelp av fri programvare og cloud computing, bjør...
Utvikling av webløsning ved hjelp av fri programvare og cloud computing, bjør...ErgoGroup
 
Når kunden driver smidig utvikling
Når kunden driver smidig utviklingNår kunden driver smidig utvikling
Når kunden driver smidig utviklingSmidigkonferansen
 
20220818 - Arendalsuka organisering av produtviklingsteam i store organisasjo...
20220818 - Arendalsuka organisering av produtviklingsteam i store organisasjo...20220818 - Arendalsuka organisering av produtviklingsteam i store organisasjo...
20220818 - Arendalsuka organisering av produtviklingsteam i store organisasjo...Jan Henrik Gundelsby
 
Prosjektoppgave_Vidar_Egil_Avinor_final_version
Prosjektoppgave_Vidar_Egil_Avinor_final_versionProsjektoppgave_Vidar_Egil_Avinor_final_version
Prosjektoppgave_Vidar_Egil_Avinor_final_versionEgil Tellevik
 

Semelhante a 2013 02-14 sw2013 - smidig arkitektur i nav (20)

Presentasjon NAV frokostseminar anskaffelser_211010
Presentasjon NAV frokostseminar anskaffelser_211010Presentasjon NAV frokostseminar anskaffelser_211010
Presentasjon NAV frokostseminar anskaffelser_211010
 
Gøyere med VisGI - BK2016
Gøyere med VisGI - BK2016Gøyere med VisGI - BK2016
Gøyere med VisGI - BK2016
 
GoOpen 2010: Jens Norve
GoOpen 2010: Jens NorveGoOpen 2010: Jens Norve
GoOpen 2010: Jens Norve
 
Frokostmote 12 april 2018 Nye Veier
Frokostmote 12 april 2018 Nye VeierFrokostmote 12 april 2018 Nye Veier
Frokostmote 12 april 2018 Nye Veier
 
Fellesforstelinje 2018 Januar
Fellesforstelinje 2018 JanuarFellesforstelinje 2018 Januar
Fellesforstelinje 2018 Januar
 
Strøm 1 - Kai Haakon Kristensen - Prestasjonsmålinger i prosjektering av bygg...
Strøm 1 - Kai Haakon Kristensen - Prestasjonsmålinger i prosjektering av bygg...Strøm 1 - Kai Haakon Kristensen - Prestasjonsmålinger i prosjektering av bygg...
Strøm 1 - Kai Haakon Kristensen - Prestasjonsmålinger i prosjektering av bygg...
 
2013 - Strøm 2 - Synnøve Frafjord - Hvordan bestille lean gjennomføring
2013 - Strøm 2 - Synnøve Frafjord - Hvordan bestille lean gjennomføring2013 - Strøm 2 - Synnøve Frafjord - Hvordan bestille lean gjennomføring
2013 - Strøm 2 - Synnøve Frafjord - Hvordan bestille lean gjennomføring
 
CV, Konsulentprofil - Jan Aage Aagaard
CV, Konsulentprofil - Jan Aage AagaardCV, Konsulentprofil - Jan Aage Aagaard
CV, Konsulentprofil - Jan Aage Aagaard
 
150617 ba2015-frokostmøte Bygg og anlegg som virker og yter - VDC og ICE/ISI
150617 ba2015-frokostmøte Bygg og anlegg som virker og yter - VDC og ICE/ISI150617 ba2015-frokostmøte Bygg og anlegg som virker og yter - VDC og ICE/ISI
150617 ba2015-frokostmøte Bygg og anlegg som virker og yter - VDC og ICE/ISI
 
Erfaringer med smidig i BarentsWatch
Erfaringer med smidig i BarentsWatchErfaringer med smidig i BarentsWatch
Erfaringer med smidig i BarentsWatch
 
Øyvind Aarvig: Hvordan blir livet i framtidens byer?
Øyvind Aarvig: Hvordan blir livet i framtidens byer?Øyvind Aarvig: Hvordan blir livet i framtidens byer?
Øyvind Aarvig: Hvordan blir livet i framtidens byer?
 
Jens Nørve: Utvikling gjennom samarbeid - deling og gjenbruk
Jens Nørve: Utvikling gjennom samarbeid - deling og gjenbrukJens Nørve: Utvikling gjennom samarbeid - deling og gjenbruk
Jens Nørve: Utvikling gjennom samarbeid - deling og gjenbruk
 
SIK Fredrikstad - Presentation om övergripande projekt
SIK Fredrikstad - Presentation om övergripande projektSIK Fredrikstad - Presentation om övergripande projekt
SIK Fredrikstad - Presentation om övergripande projekt
 
Statnett Balance settlement conference 2015 - Ole Marius Haugene Nansdal, En...
Statnett Balance settlement conference 2015 -  Ole Marius Haugene Nansdal, En...Statnett Balance settlement conference 2015 -  Ole Marius Haugene Nansdal, En...
Statnett Balance settlement conference 2015 - Ole Marius Haugene Nansdal, En...
 
Utvikling av webløsning ved hjelp av fri programvare og cloud computing, bjør...
Utvikling av webløsning ved hjelp av fri programvare og cloud computing, bjør...Utvikling av webløsning ved hjelp av fri programvare og cloud computing, bjør...
Utvikling av webløsning ved hjelp av fri programvare og cloud computing, bjør...
 
Når kunden driver smidig utvikling
Når kunden driver smidig utviklingNår kunden driver smidig utvikling
Når kunden driver smidig utvikling
 
20220818 - Arendalsuka.pdf
20220818 - Arendalsuka.pdf20220818 - Arendalsuka.pdf
20220818 - Arendalsuka.pdf
 
20220818 - Arendalsuka organisering av produtviklingsteam i store organisasjo...
20220818 - Arendalsuka organisering av produtviklingsteam i store organisasjo...20220818 - Arendalsuka organisering av produtviklingsteam i store organisasjo...
20220818 - Arendalsuka organisering av produtviklingsteam i store organisasjo...
 
Prosjektoppgave_Vidar_Egil_Avinor_final_version
Prosjektoppgave_Vidar_Egil_Avinor_final_versionProsjektoppgave_Vidar_Egil_Avinor_final_version
Prosjektoppgave_Vidar_Egil_Avinor_final_version
 
Vi lever for å levere
Vi lever for å levereVi lever for å levere
Vi lever for å levere
 

2013 02-14 sw2013 - smidig arkitektur i nav

  • 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
  • 10. NAV, 28.02.2016 Side 10 Smidig utvikling Leveransekø LeveranseIterasjon Daglig gjennomgang Historier Tilbakemeldinger Kontroll- punktet
  • 11. NAV, 28.02.2016 Side 11 … men vi trenger mer Arkitektur Behov og krav
  • 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
  • 30. NAV, 28.02.2016 Side 30 Innarbeider ATAM i NAV IKTs leveransemetode
  • 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!
  • 38. NAV, 28.02.2016 Side 38 Spørsmål?