Forenkling og framtidsretting hos skatteetaten
0 likes841 views
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.
Forenkling og framtidsretting hos skatteetaten
- 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