Oslo Software Architecture: Skatteetatens målarkitektur og PoC
1. Skatteetatens målarkitektur
Softwaredesign for «in-memory» arkitektur
Hvordan utnytte den nye plattformen?
Oslo Software Architecture, 2013.02.27
Tormod Varhaugvik, SKD SITS, Februar 2013
tormodv.blogspot.com
2. The Governmental Financial Institution
• Tax Norway
• 110 billion € in revenue from a population of 5 million
• 610 million € in operating cost
• 6.000 employees, 10.000 users, supported by 120 systems
• 700 working in IT
• Status
• Enterprise Architecture program started 2009
• This Architecture was defined and committed in 2010
• We have managed to change a large Government Organisation
• Major projects are now building the future
• We are establishing a private Cloud
• Me
• Some sort of Architect in the Enterprise Architecture practice
• Technical background, Enterprise Application domain since 1993
NTA – Equity –transparent and live risk assessment 2/27/2013 2
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
Skatteetaten 27.02.2013 4
5. Hva er det med siloen?
• Ikke mat siloen!
• Selvsentrisk
• Lite samarbeidsvillig
• Lite endringsvillig
• Eser utover tiltenkt funksjon
• Lite testbar
• Ingen forstår den
• Bærer ikke konsistens, oppetid, ytelse og endringsevne
• Størrelse er ikke synonymt med silo
• Kan ikke kjøpe en treningsdress og forvente forbedring
Skatteetaten 27.02.2013 5
6. En håndterbar Portefølje
• 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
• Federerte Samarbeidende Systemer
Skatteetaten 27.02.2013 6
8. Muligheter
• Markedssituasjon, nå og framover
• Kompetanse og infrastruktur
En mengde data
• Involvere markedet som endres
samlet
Dokument
• Flerkjerne CPU
• Mange billige standard maskiner
• Vi må designe for parallellitet
• Skalere ”ut av boksen”
• Ikke alle problemer passer
Skatteetaten 27.02.2013 8
9. Softwaredesign
(For in-memory og Big Data)
Domain Driven Design, CQRS, SOA, ODS,
BASE, Tuple Space, XML-dokumenter og god gammel Java
Skatteetaten 27.02.2013 9
10. Del opp problemet – ”Aggregate design”
Nøkkel-objekt
Nøkkel-objekt
Tydelig tilgang,
konsistens og root”
”Aggregate
innkapsling Informasjon
C og oppførsel
henger
B sammen!
A
Nå har vi 3
•God innkapsling er egentlig bare god softwaredesign dokumenter.
•God tjenesteorientering Eks. Lønn, Konto
•Det gir forvaltbare og testbare komponenter og Selvangivesle
•Der gir uavhengige informasjonsmengder
•Uavhengighet gir parallellitet
Skatteetaten 27.02.2013 10
11. «In-memory»: Monster minne
A
Minne og prosessering som Key Value
omfatter flere maskiner
Disklager i bakkant
B
Key Value
Applikasjon
C
Key Value
• Frikoble fra datalagret (disk)
• Sammensetting skjer i Applikasjon
(B kan inngå i flere sammenhenger)
• Forretningslogikk skjer i Applikasjon
• Nøkkelobjektet kan være sammensatt
• Applikasjon er upåvirket av volum og krav til svartid
Skatteetaten 27.02.2013 11
12. Dokument - Lagringsarkitektur (Big Data)
• Robust, konsistent og testbar
• Redusert I/O og mindre låsing
• Uavhengig og skalerbar
• Historisk korrekt
• Superdokument
• Alle dokumenter har skjema
Superdokument
• Fra samfunnet, på standard formater <hode/>
• Fra samfunnet, når det skjer <prosess/>
• Søkemotor <aggregat/>
<beslutning/>
<avvik/>
• Hva med funksjoner på tvers av
<logg/>
aggregater/dokumenter?
• «Utilityspråk» som SQL?
http://tormodv.blogspot.com/2011/02/document-store-for-enterprise.html
Skatteetaten 27.02.2013 12
13. Skattedomene
(Domain Driven Design, Tuple Space, CQRS, BASE, SOA, ODS,
XML-dokumenter og god gammel Java)
Skatteetaten 27.02.2013 13
14. Skatteetatens målbilde (Fastsetting)
• Enhetlig prosessering rundt ett stort datalager
• Tenk massivt arkiv med dokumenter
• … hvor vedtakene ligger utenfor
• Fakta ett sted, gjenbruk i flere dimensjoner
• Uavhengig funksjonalitet og informasjon
• Gjenbrukbar, løs koblet og eksakt
• Unik eier av informasjon
• Testbar = Forvaltbar
• Dokumentene er grensesnittene
• Migreringsvennlig Dette blir nå implementert.
1. versjon er i produksjon.
Snart: Alle lønnsslipper live.
• Hvilken prosesseringsarkitektur skal vi velge? Tilby: 24/7 spørring til NAV.
• Hvilken lagringsarkitektur skal vi velge?
Skatteetaten 27.02.2013 14
15. 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
• Simulering / ”dry run”
http://tormodv.blogspot.com/2010/12/continual-data-hub-architecture-and.html
Skatteetaten 27.02.2013 15
16. XML dokumentstruktur
id, Nøkkel til
tidspunkt,
Hode gjelder, tilstand [privat, åpen, fjernet, erstattet] dokumentet
rapportert av, erstatter
skjematype,
gyldighetsperiode [inntektsår, datoperiode],
fase [prognose, PSA, levert, fastsatt, klage] Lik for alle
Sak versjon
tilstand [ny, behandles, ferdig ]
post2.1.1 Tilstand på
Selv- text Selvangivelsen
angivelse verdi
ref Id
post3.1.12.7 Spesifikk pr
…
post5 skjematype
Selvangivelsen
Avvik avvikbeskrivelse
gjelderPoster
brukernavn
Logg tidspunkt
hendelse
begrunnelse
Lik for alle
endredePoster
Skatteetaten 27.02.2013 16
18. Utfordringen => Proof of concept
• Hvordan skifte kurs?
• Beslutningstagerne kan ikke dette
• Skape felles forståelse rundt arkitekturdiskusjoner og valg
• Å redusere risiko i planlegging og estimering
• Innsalg og troverdighet Okt ’09: Utfordringen VA
• 1000 ganger ytelse?
Mars ’10: Godkjent VA
• Hardware < 10%?
Mai ’11: Gjør PoC
• Kodeforvaltning < 30%?
Jan ’12: PoC Suksess!
• => Særlig! Mars ’12: Endre kurs…
http://tormodv.blogspot.com/2011/09/tax-norways-proof-of-concept.html
Skatteetaten 27.02.2013 18
19. Realiserbart!
• Erfaring med Smalltalk viste meget stor effektivitet
når man kunne ha forretningslogikk horisontalt
• Ekte objektorientering
• Lekker og veldikeholdbar kode (DSL)
• Kommer langt med en enkel programmeringsmodell
• Erfaring med domene-orientert distribuert system viser at
meldinger til sammen bygger opp ett system
• En Moduls data kan bygges opp ”fra ingenting”
• Fikk kontroll på datamodellen og forretningshendelser
• Dokumentene er grensesnitt mellom Modulene
• En stor datamodell kan (og bør) deles opp i Aggregater
• Likhet med Finans og Gambling er slående
• Det John Davies / Cameron Purdy har messet om lenge!
Skatteetaten 27.02.2013 19
20. Proof of Concept mål
• Enkel; ved at regler, informasjon og
prosess er tettest opp mot
forretningsbegrep
• Testbar; ved at moduler lar seg teste hver
for seg i en tydelig verdikjede
• 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
http://tormodv.blogspot.com/2011/09/tax-norways-proof-of-concept.html
Skatteetaten 27.02.2013 20
21. Kjøremiljø
• Alle noder er funksjonelt like • Flokkoppførsel
• Hver node har sin andel data • Elastisitet, omkonfigurasjon
• Skattefamilie samlokalisert • Overvåkning (teknisk)
• ”Grid” skjermer teknisk kompleksitet • Konsistens (funksjonelt)
(partisjonering, søk, jobber, redundans, overflow,
lagring, failover, indekser, med mer.) • ”Rett på jernet”, ikke virtualiser
• Transparent for logikken • Hva hvis strømmen går?
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 27.02.2013 21
22. Deployment-arkitektur (årsversjoner)
Maskin (server) Maskin (server) Maskin (server)
Node Node Node
2010 2009
Web server (v 1)
Node Node Node
http://localhost:2009/selvangivelse/{fnr}
[{... 2009 (v 1)
Web server JSON}]
Node Node Node
2011
Web server (v 1)
Web-server
[{... Gen.Skatteetaten
JSON}] http://intern.skd.no/selvangivelse/{fnr}/2009
23. Hvor går linja for endringsevne?
Level
• ) Strategy
Domain code (schemas, POJOs,tests) In project
Libraries (internal, external) Branching (VCS, Copy)
Compiler Virtual image (dev/build)
JVM Virtual image (runtime)
OS Virtual image (runtime)
Virtualization software Fixed version
Hardware Fixed hardware
Skatteetaten 27.02.2013 23
24. 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 (800 poster, 14 skatter)
• 80.000.000 Grunnlagsdata & Underskjemaer (5000 info, 7000 regler)
• 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
• Forretningsnær og vedlikeholdbar kode kan yte sykt bra
http://tormodv.blogspot.com/2012/01/tax-norways-poc-results.html
Skatteetaten 27.02.2013 24
25. Konseptet innfrir!
• Forretningsnær og vedlikeholdbar kode kan yte sykt bra
• Funksjonelle tester som regneark
• Kode som fagperson kan forstå
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
• In-memory – Processing Grid (~GemFire, HazelCast)
• In-memory – Data Grid (~Terracotta)
• Distributed database – Big Data (~Hadoop)
• Omskriving er høyst oppnåelig
• La POJO utvikling være styrende, ikke xml-definisjoner
Skatteetaten 27.02.2013 25
26. Softwaredesign er gull
• Ta det på alvor, det er lov å tenke seg om
• Fysiske lover kan ikke knekkes,
… men ting kan gjøres smart
• Isoler foretningslogikk fra teknisk arkitektur
• Kompleksitet er din største trussel
• Software må skrives om for å dra nytte av ”dette nye i skyen”
• Testbarhet, enkelhet og parallellitet går hånd i hånd
• Gull også for de som ikke har store datamengder
• Frikoble fra tregt datalager
Lev deg inn i DDD. POJO er din beste venn
http://tormodv.blogspot.no/2012/02/module-and-aggregate-design-in-cah.html
Skatteetaten 27.02.2013 26