Presentasjon gjort på Software 2012: Skatteetatens målarkitektur finnes en beregningsarkitektur/-komponent for å fastsette riktig skatt og avgift. Vesentlig for denne er høy endringsevne (for informasjon, prosess og regler), lineær håndtering av store datamengder, lang levetid, fleksibel sourcing og tilbud av massiv spørring. Domain Driven Design har også her vært sentral. Designet og resultater fra Proof of Concept gjennomgås.

1. Massivt skalerbar skatteberegning
Software 2012
Tormod Varhaugvik, SKD SITS, Jan 2012
1

2. Bakgrunn
Fastsetting
• Skatteberegning i løsningsarkitekturen
• Egen informasjon, logikk og prosess
• Avlaster standardløsninger
• Finansarkitektur har likhetstrekk
• Satt sammen; Domain Driven Design, Tuple Space, CQRS,
BASE, SOA, ODS, XML-dokumenter og god gammel Java
• Skape felles forståelse rundt arkitekturdiskusjoner og valg
• Å redusere risiko i planlegging og estimering
• 1000 ganger ytelse?
• Hardware < 10%?
• Kodeforvaltning < 30%?
Skatteetaten 29.02.2012 2
Skal presentere noe som ingen i verden har fått til innenfor
Offentlig sektor (i hvert fall skatte administrasjoner) har fått til. Og
hvis du vet om noen ”SI I FRA”
Mange offentlige instanser ville kalle Fastsetting for: ”Vedtak”
Minne er allerede 10-100 ganger raskere
We did it!
Command Query Responsibility Segregation
Basicaly Available Eventuatly Consistent
Operational Data Store
2

3. Drivere og Krav
• Hendelsesdrevet
• Selvbetjening
• Automatisering
• Endringsevne
• Livsløp – åpne standarder
• Flerkjerne CPU & Mange bokser små
• Vi må designe for parallellitet
• Skalere ”ut av boksen”, ”Skriv for skyen i dag”
• Vår egen sky i dag, forberedt på det som kommer
• Ytelse, volumer, økonomi
• Ikke alle problemer passer
Skatteetaten 29.02.2012 3
Selvbetjening innebærer også mye blottlegging, man må ha kontroll på bakrommet
Med oppetid menes at systemet skal kunne ha ”fail-over” i tilfelle feil, men også at systemet skal være tilgjengelig ved høy last
En clustret løsning er mer robust i seg selv, og applikasjonen må bygges for det. (Når virket sist failover siten)?
Alle disse kan sorteres ut ved å se på systemet faktisk skal levere for hvem.
Ved å dele opp i forskjellige funksjoner vil man kunne se konturene av forskjellige komponenter i arkitekturen
Noe nedetid vil man selvfølgelig ha, men det går an å minimere det.
Facebook har 10.000 vis av servere,50 millioner transaksjoner i sekundet…,10’talls terrabyte med RAM
De største framskritt i prosessering ligger på algoritmer og ikke i HW
Parallellitet: Generelle algoritmer i dag klarer kanskje 20%
3

4. DDD i Space Based Arhitecture
Space-Based Architecture (SBA) is a software architecture pattern for
achieving linear scalability of stateful, high-performance applications,
based on Yale’sTuple-Space Model (Source Wikipedia)
Aggregate
Skatteetaten 29.02.2012 4
Aggregate slik definert i Domain Driven Design
Rett og slett en gigantisk HasMap
4

5. Kontinuerlig utveksling av Aggregater
Tuple er et xml- Løs kobling
Alle aggregater Skiller
dokument som mellom aggregater
innkapsles i et produksjon
inneholder (Skattyter, context
super-dokument fra bruk
aggregat og årsversjoner)
Fastsetting Forskjellige
XML for lang
aggregater side-om-
holdbarhet jon
side for skattyter
ras
kla
Skatt
SkatteInfo
de
Avgif regning
en
SkatteInfo er en
ebe
Kontinuerlig
Eg
ts- o
Fast- Ilagt
super-repository
g
satte
verdier
skatt /
avgift tilrettelegging
Module har en Verdier Prog- For- Modulene avgir
nose skudd
bounded context tjenestekomponenter
In
ns
a m
lin
rs
dd
ku til SkatteInfo
g
Fo
Processing unit Last et sett
er en module aggregater og
produserer et nytt
Massiv spørring
Unik produsent Uavhengige
Alle aggregater Tilstand på
av aggregat contexts
på samme sted aggregatet styrer
http://tormodv.blogspot.com/2010/11/concept-for-datastore-and-processing.html prosessen
Skatteetaten 29.02.2012 5
Continual Aggregate Hub.
Viktig å poengtere at dette er design for å la mange Moduler
samarbeide om de samme informasjonsobjektene. Grid / skalering
er det kun for ytelse.
Tenk også på SkatteInfo som et lager over alt som er produsert av
systemene. All spørring foregår hit.
Slikt sett likt med Operational data store, men det er dette med
arkitekturen rundt som gjør den spesiell
Tid er løs kobling. Har bedre tid når man utarbeider noe enn når
man spør etter det.
Høy spørre til beregn ratio
Skatteinfo er til enhver tid fasiten.
Soft state
Bedrer muligheten for gode metadata, enhetlig master
Aggregater: utfordringen er å finne riktig granularitet.
5

6. Tekniske egenskaper
• Parallelliserbar
• Skill utvalg…
• … fra behandling
• … fra lagring av resultat
• Prosessfokus
• Automatisk saksbehandling
• Manuell saksbehandling
• Kontinuerlig tilrettelegging
• Åpne standarder
• Kapsle inn forretningslogikk
• xml, java, kontainer, web
• Leverandør / plattformuavhengig
• Plattform i utvikling
• Objektorientert
• Rik semantikk, DSL
• xml 1:1 med java (aggregatet)
• Test og drift
• Automatisk / avgrenset test
• Omkjøring ifbm feilretting
• Enkel simulering
http://tormodv.blogspot.com/2010/12/continual-data-hub-architecture-and.html
Skatteetaten 29.02.2012 6
Åpne standarder gir handlingsrom. Beste valget man kan gjøre i dag
Lisens uavhengighet, flytt prosesseringsbehov ut til noe gratis
Varighet!
Skille utvalg, fra prosessering, fra lagring
Tenk en og en når man utvikler.
Snakk om container og komponenter
Presenter en case!
Tilrettelegge, man går ikke i butikken mens man lager mat
Dramatisk forenkling av concurrency
Fantastisk mulighet til å planlegge cache-pre-load…
6

7. Lagringsarkitektur - Aggregater
• Tenke Aggregater (info+use)
• Forretningslogikk styrende
• Part i fokus, ikke datatype
• Robusthet og skalerbarhet
• Redusert I/O og mindre låsing
• Endringsevne og testbarhet
• Serialisering er lik
• Søkemotor
<hode>
• Alle dokumenter har skjema <nøkler>
• Vilkårlige data fra 3. part <prosess>
• Kan ha ustrukturert info også <aggregat>
<beslutning>
• Hva med funksjoner på tvers av
<avvik>
aggregater/dokumenter? <logg>
http://tormodv.blogspot.com/2011/02/document-store-for-enterprise.html
Skatteetaten 29.02.2012 7
Dramatisk forenkling av concurrency mekanismer
7

8. Proof of Concpt mål
• Enkel; ved at regler, informasjon og prosess er tettest opp
mot forretningsbegrep
• Logisk gruppering, ikke teknisk oppstykking
• Helhet i skatteprosessen gir forenkling totalt sett (gjenbruk)
• Testbar; ved at moduler lar seg teste hver for seg i en tydelig
verdikjede
• Faser i saksbehandlingen
• Steg i prosesseringen
• Uavhengige informasjonselementer
• 400+70+25+20 er mindre enn 400*70*25*20
• Skalerbar; ved at volum og svartider lar seg løse ved kjøp av
mer hardware, og ikke igjennom å skrive om regler,
informasjon eller prosess.
• Lavere kostnad
• Mindre risiko
http://tormodv.blogspot.com/2011/09/tax-norways-proof-of-concept.html
Skatteetaten 29.02.2012 8
Kinderegg!
Kan ikke abstrahere seg bort fra forretningslogikk
8

9. Hva gjør vi?
• Valgt noe vanskelig; selvangivelse og skatt
• Selvangivelsen har ca. 800 felter / 300 poster
• Settes sammen av 28 grunnlagsdata, samt 47 underskjema
• Bare Lønn og trekkoppgaven har ca. 250 mappinger
• Essensiell kompleksitet skal håndteres
• Vise at helhet i skatteprosessen gir forenkling totalt sett
• Konvertert del-mengde fra produksjon (60 millioner dokumenter)
• Det skal kjøres for ca. 1 million skattytere
• Dobbelt så mange maskiner skal gi dobbel ytelse
Skatteetaten 29.02.2012 9
I dag ca 4000 beregningsregler og 3000 kontroller. Dette er en
teknisk oppdeling og gir ikke forretningsnivå regler.
Infrastruktur
Etablert servermiljø hos EDB og
Installert grid-løsning (utvidelse av AURORA)
Funksjonalitet
Lastet grunnlagsdata, produsert selvangivelse og beregnet
skatt
Bygget et eksempel på 360° brukergrensesnitt
Vurdert konsepter for automatisk og manuell saksflyt
Helhetlig ramme på plass med fasene; skal utvide med
Skattekort
Full dekning innenfor ansettelser til Skatt. (50 – 60
summeringer)
Skatt ca 70% av befolkningen. 30-40% av logikken?
Saksbehandling på SA er godt dekket (hvem gjorde hva når)
Løsning for årsversjoner; både små og store endringer
Data 9
Full saldo/rente og LTO for 2009 og 2010
60% volum av GLD 2 av 17 oppgavetyper

10. Lagring av Aggregater i super-dokument
id, Tilstand på
tidspunkt,
Hode gjelder, tilstand [privat, åpen, fjernet, erstattet] dokumentet
rapportert av, erstatter
skjematype,
gyldighetsperiode [inntektsår, datoperiode],
Lik for alle i
fase [prognose, PSA, levert, fastsatt, klage]
SkatteInfo
Sak versjon
tilstand [ny, behandles, ferdig ]
post2.1.1 Tilstand på
Selv- text aggregatet
angivelse verdi
ref Id
post3.1.12.7 Spesifikk pr
…
post5 skjematype
Selvangivelse
Avvik avvikbeskrivelse aggregat
gjelderPoster
brukernavn
Logg tidspunkt
Lik for alle i
hendelse
begrunnelse SkatteInfo
endredePoster
Skatteetaten 29.02.2012 10
Analogi med bøker Header er ISBN, Forfatter, tittel etc. Boka kan
inneholde hva den vil.
10

11. Modul: Selvangivelse
EndreView BrukView
View
-”GUI for Saksbehandler”
-”GUI for innsyn”
-Lag ny
-Se på familie
-Se på familie
-Se på selvangivelse
-Se endring over tid
-Fastsett- (verdi, type og part)
-Fastsett (-fase)
VPL VPL
BPM BPM
EndreService BrukService
Application
-”Services for å endre på Selvangivelse” -”Sevices for bruk av Selvangivelse”
-Lag -Søk
-Endre etc… -List
-listner- (selvangivelse, familie) -Se på (versjoner)
-Subscribe / event handler
Familie SelvangivelseService LookupService
-Utgjevn -Opprett
-søk
-Endre -Lagre i kontekst (fase)
-list
-Fastsett -Endre / Fastsett
Business
-Valider -Valider / Diff Factory -se på
-Diff -Fase -Nå situasjon
-Fase -Lås
KildeRepo PartRepo SelvangivelseRepo
”Data til bruk i selvangivelsen” -Navn -Fase og versjon
-LTO, S&R, (GLD - 17) -Organisasjon -Prosess og sakstilstand
-RF-1088 (etc) -Familie -RF-1030
-Kommune -Avvik
Infrastructure /
-Logg og audit
SkatteInfo
Skatteetaten 29.02.2012 11
Reell forretningslogikk ligger i Selvangivelse Service:
La deg ikke villede til å tro at datamodellen er i stand til å ha full
konsistens. det er forretningslogikken som har den.
11

12. Kjøremiljø
• Alle noder er funksjonelt like • Plass tar mer tid enn beregning
• Noder har forskjellig datasett • Flytte data mellom servere tar tid
• Skattefamilie samlokalisert som forventet
• Grid håndterer partisjonering, søk, • Redundans tar tid
jobber, redundans, overflow, lagring, • Lasting av data er ikke fult så
failover, indekser, med mer. parallell
• Transparent for logikken
Maskin (server) Maskin (server) Maskin (server)
Grid-node (JVM) Grid-node (JVM) Grid-node (JVM)
PSA PSA PSA
Saldo- og rentemeldinger Saldo- og rentemeldinger Saldo- og rentemeldinger
Lønns- og trekkoppgaver Lønns- og trekkoppgaver Lønns- og trekkoppgaver
Skattefamilie Skattefamilie Skattefamilie
Skatteetaten 29.02.2012 12
Mao. dyrere å flytte data enn å regne på dem (samme erfaring for
hovedfaget fra IFI: Distribuertedatabaser og design mhp ytelse.fra
1992)
Eneste stor HashMap
12

13. Estimert fullskala produksjon
• 28.000 Selvangivelser i sekundet (ca 3 minutter)
• 56.000 Skatteberegninger i sekunder (ca 90 sekunder)
• 5.100.000 Selvangivelse & Skatt og Skattekort
• 80.000.000 Grunnlagsdata & Underskjemaer
• 120 Gb RAM netto
• 370 Gb RAM brutto med 1x redundans og indekser
• 12 Servere (Intel i7) a 32 Gb
• Last av XML fra fil: 6000tps => 5 timer
• Ekstrem ytelse ikke så viktig i seg selv, men gir handlingsrom
• Kost ca 400.000 i servere og 1 million i lisens
• Alt behøver ikke være i minne
http://tormodv.blogspot.com/2012/01/tax-norways-poc-results.html
Skatteetaten 29.02.2012 13
ca 3kb pr selvangivelse
HW og lisenser
PoC: 3 std. servere á 25.000 kr
GemFire lisenser: 1 mill
Server 25.000, 1Tb RAM 200.000, $12.000 pr 6core-CPU
(vi har 13.000 på 3 servere). Selv disse i sekvens er raskere enn
dagens
13

14. Erfaring
• Konseptet innfrir!
• Forretningsnær og vedlikeholdbar kode kan yte sykt bra
• Funksjonelle tester som regneark
• Kode som fagperson kan lese (DSL)
putSumPost("3.4", sum(post("3.1.14"), minus(post("3.3.13"))))
putSumPost("3.5.1",hvis(post("3.3.7.3")).er(kr(0)).brukDa(hvis(post("3.5.1.1")).ikke
Er(kr(0)).brukDa(post("3.5.1.1"))))
• Informasjonsmodellen er også viktig
• Åpne standarder gir verktøy, komponenter og markedsstøtte
• Handlingsrom for valg av kjøreplattform, skalere ved behov
• Omskriving er høyst oppnåelig
• La POJO utvikling være styrende, ikke xml-definisjoner
• Passer også for andre applikasjonstyper
• Lagre aggregatet når det passer
Skatteetaten 29.02.2012 14
Svært fleksible deployment modeller
Speilet Grid for Operasjonelt Datavarehus
Enda enklere failover
Rimelig HW fordi den kan feile
Bruk failover ved høy last
Regelmotor vil aldre helt ta av. DSL ruler!
14