Presentasjon på SW2010. Skatteetaten skal modernisere systemporteføljen. Målet er å øke endringsevnen og å redusere forvaltningskostnadene. Vesentlig i dette arbeidet er å redusere kompleksitet ved å reindyrke de funksjoner som skal utføres. Arkitekturen skal ha lang levetid (15-30 år), mens komponenter skal kunne byttes ut. Foredraget tar for seg resonnementene fra designarbeidet og egenskaper i målarkitekturen.

1. Forenkling og framtidsretting hos
Skatteetaten
Software 2012
Tormod Varhaugvik, SKD SITS, Jan 2012
1

2. Innhold
•Motivasjon
•Hva er det med siloen?
•Tilnærming
•Målbilde
2

3. Motivasjon
•Endringsevne
ne
•Rimeligere forvaltning gsev
Endrin
Handlingsrom
•Skattyter i fokus Forv
altni
ngsk
•Hendelsesdrevet ost
•Virksomhetsarkitektur, prosessen
•Målbilde å styre etter
•Veikart (herding, scenario)
•Metodisk inspirert av TOGAF (ISA, TA)
Information Systems Architecture ISA
Technology Architecture (TA)
Disse henger sammen, Rammefinansiering i det offentlige
Tjenesteorientering
Gjenbruk
Samtidighet
Laget illustrasjoner som formidler, ikke brukt EA verktøy eller ”UML”
Vi er allerede en av verdens mest effektive skatteinkrevere
I endringsevne ligger det på ikke binde for mye sammen. ”no ring to rule them all”
3

4. Systemenes livsløp
•8% investering, 92% i levetiden
•Markedsstøtte i levetiden
•COTS -
”Commercial of The Shelf”
•Varige egenskaper
•”Noen skal betale skatt av noe”
•Skiftende egenskaper
•”Hva skal betales i skatt”
•Eie egen kompleksitet
•Logikk, informasjon og prosess
•Testbar
Kompleksitet blir ikke borte selv om man kjøper noe
Lang historikk 10-14 år.
COTS er først og fremst en forretningsutfordring
Løsningsarkitekturen i Målbildet fordeler spesifikt fra mer generelt
COTS er mer ”Build or Buy”
4

5. Hva er det med siloen?
•Ikke mat siloen!
•Selvsentrisk
•Lite samarbeidsvillig
•Lite endringsvillig
•Ingen forstår den
•Eser utover tiltenkt funksjon
•Lite testbar
•Bærer ikke konsistens, oppetid, ytelse og endringsevne
•Størrelse er ikke synonymt med silo
•Slankekur! (men ikke uten risiko)
Det er ingen som forstår alt
Lav endringskapasitet
Så stor og ting at den kveles av egen vekt
Hele stacken i samme system
Oversikt på tvers av disse er vanskeig og nesten umulig å automatisere
Spør leverandør om sanneringsstrategi, hvordan ta data ut av systemet på en
kontrollert måte
Omskriving er dyrt. Gartner har sagt at skriver man om mer enn 20% bør man
vurdere å sannere hele.
det er mange siloer! å få de til å virke sammen er ett mareritt. Samtidig ”ikke
umyndiggjør”
Blir ikke sprekere av å kjøpe en treningsdess! Hjelper ikke å pakke inn.
Arv eller alderdom (==legacy; man må leve med aldrende systemer)
Heterogene (teknologien utvikler seg)
Komplekse (definisjonen i Patterns of Enterprise Application Architecture )
Forskjellige eiere
Ufullkommen (==imperfection; det er alltid noe som ikke virker, mangler eller ikke
passer sammen) (sitat Winston Churchill: Perfectionism spells P-A-R-A-L-Y-S-I-
S)
Duplikat / overflod (==redundant; både data og funksjonelt)
Flaskehalser er døden (ikke bare IT runtime, men også organisasjon og
endringsmulighet…)
5

6. Splitt og hersk
•Bestem systemer
•Funksjonelt, teknisk og organisatorisk
•God tjenesteorientering
•Domain Driven Design
•Bestem unik eier av informasjon
•Del opp problem innad i system
•… for å oppnå parallellitet
•Tid er løs kobling
•Store oppgaver trenger store systemer
•Ulike systemer trenger ikke lik arkitektur
•SOA på toppen er ingen forenkling
System, Modul, Komponent kjært barn har mange navn.
Vi er nødt til å dele opp problemet
SOA overser tilstand
Se på bruksmønster
Siloene er resultat av ensidig fokusering på løs kobling på organisatorisk plan
Lag algoritmer og data strukturer som skalerer!
Funksjonalitet, ikke bare domene som i DDD, men også mellom lag og oppgaver
i systemene
Teknisk
Organisatorisk gunstig å konsolidere
Husk at tjenesten er bare toppen av isfjellet! Kan ikke gi bedre SLA enn det
underliggende systemet kan gi. Disse må involveres og skjønne hva og hvordan
tjenesten brukes.
Husk også at overdreven konvertering eller mapping mellom systemer medfører
at de involverte ikke snakker så godt sammen lengre!
TID er løs kobling, ref. Eventualy Consistent BASE
Essensiell kompleksitet må møtes i retten
Utfordringene fra 90-taller var lik. ”Samformatet” ble paralyse
6

7. Samarbeidende systemer
Lager Butikk
Livssyklus
Egenskaper
Prosess
Brukerdialog
Informasjons systemer = IS…
Ingen ”One ring to rule them all”
Store organisatoriske effekter
Tydelig ansvarsfordeling
Samarbeid
Identifikatorer!
Metadata og eierskap til informasjon er viktig
7

8. Helhetlig syn på Part
Partsmappe
Virksomhetsprosesslogg Korrespondanse
(hendelser for parten) med parten
Partinformasjon
(navn / adresse /
klassifisering / manntall)
Beregnet informasjon
Grunnlagsinformasjon
(det vi har beregnet i skatt,
(alt vi vet om partens materielle
avgift og annet:
verdier; LTO, Saldo/ Rente,
eks. skattekort, utkast til
MVA grunnlag)
likning, likning)
Oppgaver som kan utføres
av saksbehandler
Pågående saker vedr. parten
Partsreskontro
Nettleserbaserte grensesnitt som i nettbank, nettbutikk og lignende
Følge lenker for å navigere i informasjonen, og med felles tilgangskontroll
Tilgang til alle tilgjengelige opplysninger om en part; grunnlagsdata, dokumenter,
pågående saker, reskontro, historikk etc.
Logge på kun en gang
Forvaltningsmessig skal det være lav innsats programmeringsmessig å lage:
1) Egnet brukerflate for mindre brukergrupper (som i dag ikke er dekket)
2) Egnet brukerflate for å presentere forskjellige typer parter (selskap, person,
…)
3) Egnet brukerlate for mindre skjermer (devicer)
Brukerflaten ikke laget for et system, men knytter sammen tilgjengelige tjenester
for brukeren.
Forventer ikke lik ”look and feel” i hele porteføljen. Tiden går og ting vil se
annerledes ut, selv om vi skal prøve å ha det likt.
Web gir lav brukerterskel. Skal fungere slik vi ser ellers i verden.
8

9. Kompleksitet i dybden
Ekstern
Mottak
Kontroll og analyse
Beregning
Avregning
Ekstern
Innsyn
Kompleks
Oppetid
Det som truer oppetid er kompleksitet, ikke HW.
Det som flyter inn er en trinnvis berikelse
det som flyter tilbake er kvitteringer, feil eller avvik, instrukser, informasjon og
resultater av behandling
Mer sky jo nærmere kunden man er
Ikke forvent oppetid fra et datavarehus, det skal vi kunne ta opp og ned som vi
vil, men resultat derfra kan asynkront trille tilbake.
9

10. Målbilde
Part Etterlevelse
!
Prosess
Tilgang Dokument
Fastsetting Innkreving
Parter er skattesubjektet. Hvem er det, hvor oppholder den seg, hvilke roller,
hvilken tilstand, hva forventes, kategorisering, segmentering
Eventene er født, flytte,. sivilstand, familie, konkurs, død…
Skatteberegning er avgiftsberegning på skatteobjekt
Penger er det som betales inn og skal avstemmes mot skatteberegning og
Partens egenskaper
Penger skal fordeles
Målbildet er ikke noe mer enn ett stykke papir. Utfordringen ligger i å klare å gå
retningen; både forretningsutvikling og it utvikling (governance) +++ er
utfordringen.
Ulik arkitektur til ulike oppgaver
Blueprint for mange offentlige etater?
10

11. Oppsummering
•Forstå hensikten med oppgaven
•Splitt og hersk (Domain Driven Design)
•Gartner: ”Application Overhaul”
•God tjenesteorientering
•SOA på toppen ingen forenkling
•Ta ansvar for egen kompleksitet
•COTS er en forretningsutfordring
•Finn det som kommuniserer til interessentene
• Mye mer på: http://tormodv.blogspot.com
• http://tormodv.blogspot.com/2011/01/migration-strategy-and-cloud.html
• http://tormodv.blogspot.com/2011/09/dont-let-enterprise-service-bus-lead-to.html
• http://tormodv.blogspot.com/2011/09/enterprise-wide-business-process.html
http://tormodv.blogspot.com/2011/01/migration-strategy-and-cloud.html
http://tormodv.blogspot.com/2011/09/bam-challenge.html
http://tormodv.blogspot.com/2011/09/dont-let-enterprise-service-bus-lead-to.html
http://tormodv.blogspot.com/2011/09/enterprise-wide-business-process.html
God tjenesteorientering er også en forretningsmessig utfordring
og mange flere…
11