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

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

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ø Leveranse Iterasjon

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

Utv Utv

Utv

Utv

Løsningsarkitekt

Utviklings-

team

Produkt-

eier

Arkitekt

NAV, 28.02.2016 Side 13

Hvor mye arkitektur?

FA

Test

Ark

PL

Utv Utv

Utv

Utv

Fu

nksjo

nelt

om

råd

e

Utviklings-

team

FA

Test

Ark

PL

Utv Utv

Utv

Utv

Utviklings-

team

FA

Test

Ark

PL

Utv Utv

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

Utv Utv

Utv

Utv

Fu

nksjo

ne

lt

om

råd

e

Utviklings-

team

FA

Test

Ark

PL

Utv Utv

Utv

Utv

Utviklings-

team

FA

Test

Ark

PL

Utv Utv

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)

Overo

rdnet

Funksjo

nelt

Tve

rrgå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

Sik

ke

rhet

Tje

neste

ori

en

teri

ng

Ett

erl

evels

e

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 tingene Gjø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?