EA – SOA - G

1. EA – SOA - G G SOA EA

2. Akademiska meriter Började 1:a 1960 Erfarenheter 60 - Per ”Pelle” Nilsson Statistik Fastighetstaxering Utredning Programmering

3. Akademiska meriter Har ännu inte avslutat den 3-betygsuppsats i historia som jag påbörjade 1977. Erfarenheter 70 - Per ”Pelle” Nilsson Utveckling Statistik Samverkan Fastighetstaxering Utbildning Förvaltning Juridik Utredning Programmering Histor.

4. Akademiska meriter Har ännu inte avslutat den 3-betygsuppsats i historia som jag påbörjade 1977. Erfarenheter 80 - Per ”Pelle” Nilsson Utveckling Planering Statistik Samverkan Fastighetstaxering Utbildning Förvaltning Juridik Utredning Test Programmering Ekonomi Histor.

5. Akademiska meriter Har ännu inte avslutat den 3-betygsuppsats i historia som jag påbörjade 1977. Erfarenheter 90 - Per ”Pelle” Nilsson Arkiv o diarie Projektledning Utveckling Systemering K/N-kalkyler Planering Statistik Samverkan Omvärldsbevakning Modellering Fastighetstaxering Utbildning Förvaltning Juridik Utredning Test Programmering Ekonomi Uppföljning Offentlig upphandling Histor. ICR + tolkning

6. Akademiska meriter Har ännu inte avslutat den 3-betygsuppsats i historia som jag påbörjade 1977. Detta kanske kan bli början på en ny 3-betygsuppsats? Erfarenheter 2000- Per ”Pelle” Nilsson Arkiv o diarie Projektledning Utveckling Systemering K/N-kalkyler Arkitektur Planering Statistik Samverkan Omvärldsbevakning Modellering Fastighetstaxering Utbildning Förvaltning Juridik Utredning Test Programmering Ekonomi Uppföljning Offentlig upphandling Histor. ICR + tolkning

7. Perspektiv • Mina akademiska meriter väger lätt!!! • Jag kommer att fokusera mina praktiska erfarenheter • Jag har jobbat 6 decennier med utveckling! Under 60-, 70-, 80-, 90-, 00- och 10-talet.! • (Första jobbet som 9-åring, programmerare vid 15, egna utredningar från 17 års ålder och första lärarjobbet vid 20 - 21.) • Prövat ett otal metoder och verktyg • (T.ex. PPS, Pejl, RUP/KUR, UML, TOGAF, GEAF, EIF, VU-processen, Lots, KTT, Rose, QLM, Peng, Astrakans modelleringsmetoder, Koll, Målmodellering, Stanly, JSP, PM3, Scrum, Skruv-OO, etc.) • Teori Praktik

8. Välkommen till den grymma verkligheten.

9. Agenda 0800 - 0810 Akademisk kvart 0810 – 0815 Inledning. EA, SOA och G. 0815 - 0900 Inget är nytt under solen Gryning på Skatteverket 0900 - 0850 Fika 0850 – 1000 Solen går upp Målarkitektur Avslutning. Revolution, evolution, involution och paradigmskifte.

10. EA – SOA - G G SOA EA

11. EA • Enterprise Architecture = • På svenska Verksamhetsarkitektur? • Konceptet: • Beskrivningar av en verksamhet ur flera olika perspektiv! • Skatteverkets EA har 4 skikt = perspektiv. • Verksamhet (Processer) = V-skikt • Information = I-skikt • Applikation = A-skikt • Teknik = T-skikt

12. SOA • Service Oriented Architecture = • Konceptet: • Paketerade funktioner med väl beskrivet gränssnitt (indata och utdata). • Kan vara parameterstyrd.

13. G – GM, GVM, GL, GVL • Gemensamt = • Konceptet: • Alla ska inte behöva uppfinna hjulet på nytt! • Allt som är lönsamt att göra gemensamt ska vi göra gemensamt. Kod, processmönster, information, arbetssätt, mätetal, miljöer, testfall o.s.v.

14. Inget är nytt under solen

15. Tidigt A-skikt

16. Tidig funktion

17. Tidigt G

18. Skogshögskolan pionjärer? • Förutsättningar • Dator = IBM 1401. CPU = 12 K. (Senare uppgraderad till 16 K.) • Maskinnära programmeringsspråk (Autocorder) • Brist på programmerare => kö till dessa • Långa bearbetningstider => kö till datorn

19. Skogshögskolan pionjärer?

20. Skogshögskolans svar! • Identifiera gemensamma behov • Separera det helt gemensamma från specifika, parametrar och data som ska bearbetas • Programmera gemensam lösning. Ett tydligt och publicerat gränssnitt. • Namn på tjänsten • Beskrivning av input • Parametrar för åtgärd • Beskrivning av output • Välordnat bibliotek med tjänster. Buntar med hålkort + beskrivningar av tjänsten och gränssnittet.

21. En lag som EA - 79? 1 Kap. Sammanhanget Här ges sammanhanget i stort! 2 - 15 Kap. Kärnprocessen 2 Kap. Indelning byggnad och mark Beskriver en strängt reglerad process. Första steget i processen beskrivs i detta kapitel. Fastighetstaxeringslagen

22. V-skiktet klart. Nu till I-skiktet. 1 Kap. Sammanhanget 3:e kap ger reglerna för skatteplikt vilket tillsammans med indelningen i byggnadstyper och ägoslag är styrande för indelningen i taxeringsenheter (första informationsobjektet) 2 - 15 Kap. Kärnprocessen 2 Kap. Indelning byggnad och mark 3 Kap. Skatteplikt 4 Kap. Indelning i taxeringsenheter Attribut Info.objekt Här skapar vi taxeringsenheter! Taxerings- enheter

23. Mera I-skikt. 1 Kap. Sammanhanget Allmänna regler om värdering och om hur delvärden till taxeringsenheten skapas 2 - 15 Kap. Kärnprocessen Här skapar vi värderings- enheter 2 Kap. Indelning byggnad och mark 3 Kap. Skatteplikt 4 Kap. Indelning i taxeringsenheter 5 Kap. Allmänt om värde 6 Kap. Indelning i värderingsenheter Attribut Info.objekt Info.objekt Allmänna värderings- regler Taxerings- enheter Värderings- enheter. 7 Kap. Värderingsregler Attribut Attribut

24. Här börjar vi också titta på A-skiktet. 1 Kap. Sammanhanget Här lägger vi också fast den övergripande nivån i applikationsarkitekturen 2 - 15 Kap. Kärnprocessen 2 Kap. Indelning byggnad och mark 3 Kap. Skatteplikt 4 Kap. Indelning i taxeringsenheter 5 Kap. Allmänt om värde 6 Kap. Indelning i värderingsenheter Attribut Info.objekt Info.objekt A-skikt Taxerings- enheter Värderings- enheter. 7 Kap. Värderingsregler Attribut Attribut

25. Ökad detaljering. 1 Kap. Sammanhanget Här beskrivs i detalj vilka faktorer som ska bestämma värdet. 1 kap per typ av taxeringsenhet. 2 - 15 Kap. Kärnprocessen 2 Kap. Indelning byggnad och mark 3 Kap. Skatteplikt 4 Kap. Indelning i taxeringsenheter 5 Kap. Allmänt om värde 8 - 15 Kap. Värdefaktorer 6 Kap. Indelning i värderingsenheter Attribut Info.objekt Info.objekt A-skikt Taxerings- enheter Värderings- enheter. 7 Kap. Värderingsregler Attribut Attribut Attribut

26. Omvärlden. 1 Kap. Sammanhanget Här beskrivs lite omkring kärnprocessen. Deklarationen mm och vad som kan hända efter taxeringen 2 - 15 Kap. Kärnprocessen 16 - 24 Kap. Före o efter 2 Kap. Indelning byggnad och mark 3 Kap. Skatteplikt 4 Kap. Indelning i taxeringsenheter 5 Kap. Allmänt om värde 8 - 15 Kap. Värdefaktorer 6 Kap. Indelning i värderingsenheter Attribut Info.objekt Info.objekt A-skikt Taxerings- enheter Värderings- enheter. 7 Kap. Värderingsregler Attribut Attribut Attribut

27. Specifikation av A-skiktet. 1 Kap. Sammanhanget A-skiktet specificeras slutligen i regeringen förordning (FTF) och i Skatteverkets föreskrifter (RSV:FS). Där ges detaljerade regler för tabellernas uppbyggnad och andra värderingsregler. FTF +RSV:FS 2 - 15 Kap. Kärnprocessen 16 - 24 Kap. Före o efter 2 Kap. Indelning byggnad och mark 3 Kap. Skatteplikt 4 Kap. Indelning i taxeringsenheter 5 Kap. Allmänt om värde 8 - 15 Kap. Värdefaktorer 6 Kap. Indelning i värderingsenheter Attribut Info.objekt Info.objekt A-skikt Taxerings- enheter Värderings- enheter. 7 Kap. Värderingsregler Attribut Attribut Attribut

28. FIPOTEK och subbor -82. • Riksskatteverkets tekniska avdelning 1982 • FIPOTEK stod för fil-, post- och termkatalog • Stenkoll på alla filer, postbeskrivningar och termer som användes. • Ingen fick lägga till en term om motsvarade begrepp redan fanns. • Testgruppen var stenhårda poliser • Subbor och copyelement. • Ett stort antal sub-program och copyelement som funktionellt motsvarade SOA-tjänster. Kodade för vanliga gemensamma funktioner. • Användningen av dem och deras gränssnitt var väl dokumenterade • Subprogrammen anropades inifrån andra program. • Copyelementen kopierades in i koden på det program man utvecklade. • Handböckerna var i pärmsystem med versionshanterade uppdateringar.

29. AKTIV en tidig EA 94 – 95. • AKTer I Verksamheten. • Kunde det inte vara så att den information vi använde vid ärendehanteringen kunde vara generell för olika verksamheter? • 1 projektledare, 40 – 50 olika deltagare i ett stort antal work-shops senare. • Jo – inte bara det utan även processerna var gemensamma. • AKTIV tog fram både processbeskrivningar och informationsmodeller.

30. V-skikt. Processmodeller. • Processmodell - Översikt

31. I-skikt. Begreppsmodeller. • Begreppsmodeller

32. Detaljering. • Processmodell - Detaljer

33. Fortsättningen. • Slutsats = Bygg ett gemensamt ärendehanteringssystem. • Skatteverket hade dock stora problem med de s.k. 98-projekten. (Skattekonto var beslutat. Sedan såg man att om Skattekontot skulle fungera så måste man först göra det och det och det och det). • Ledningen därför tveksam att starta ny större utveckling. • Börja med in- och utdata- delarna så får vi se sedan.

34. Pesten slår till 1 – Unix. • På 80-talet drabbades Skatteverket – liksom många andra – av ett allvarligt bakslag för förvaltningen: Unix! • Unix och liknande operativsystem erbjöd nya möjligheter. Relationsdatabaser, direktåtkomst till data, kraftigare språk mm. • Vi började använda dessa. Först folkbokföring och fastighetstaxering men sedan alla andra. • Unix sas vara självdokumenterande! • Men var inte det. • Första problemen var med driftdokumentationen. • Beställarnas arbete med process- och informationsmodeller försämrades. • FIPOTEKET började förfalla.

35. Pesten slår till 2 – RUP. • På 00-talet drabbades Skatteverket – liksom många andra – av ett andra allvarligt bakslag för förvaltningen: RUP! • RUP och liknande styrverktyg erbjöd nya möjligheter att standardisera och rationalisera IT-utvecklingen. • Vi började använda dessa. • RUP styrde upp IT-utvecklingen och gav en del goda hjälpmedel och mallar. De snabba iterationerna var till stor hjälp. • Men RUP/KUR stödde IT-utveckling. Inte verksamhetsutveckling. • Och RUP/KUR nonchalerade informationsarkitekturen. • I-skiktet har misshandlats sedan millennieskiftet.

36. Gryning på Skatteverket för G

37. In- och utdata • Stort projekt 1996 – ? (Avvecklingen inledd nu) • Generella lösningar framför allt för indata. • Tyvärr för mycket verksamhetsspecifika kontroller mm in i lösningarna. • Därför dyrt att underhålla. • Anledning fanns att (tillsammans med Försäkringskassan och Statskontoret) titta på en renodlad lösning = SHS.

38. Spridnings- och Hämtningssystem (SHS) • SHS utvecklades av Skatteverket och Försäkringskassan med stöd av Statskontoret. • SHS är ett koncept för säkert och pålitligt utbyte av information mellan offentliga organisationer. • Specifikationer byggda på Internetstandarder har tagits fram • Funktionen informationsutbyte beställs via SHS-avtalen i form av produkter som drivs i den egna tekniska miljön, • Kan också beställas som tjänst inom området Infratjänst. • SHS För mer info http://www.openshs.se/

39. eDok => gDok => ? • gDok är i XML-format. • gDok har varit i drift ett tiotal år och fungerar utmärkt. • Försäkringskassan har uttryckt önskemål om att gå (tillbaka) till gDok-tankarna • Det skulle vara önskvärt om gDok blev en standard. • SHS är den stora distributören som levererar paket mellan organisationer. gDok innehåller adresserna på de brev som ryms i paketen och ser till att de hamnar rätt i organisationen.

40. GÄHS (Generellt ÄrendeHanteringsSystem) • GHÄS startades som en fortsättning på AKTIV och In- och Utdata. • Målet. Ta fram en generell maskinell ärendehantering tillsammans med nyttjandeprojekt. • Tidspressen var hård på GÄHS. • Bemanningen var skev - ett dussintal människor arbetade med den generella. Mångdubbelt flera arbetade i nyttjandeprojekten. • Förankring saknades på verksamhetssidan och produkterna blev svårsålda. • GÄHS lyckades dock leverera generella tjänster i form av • Processtjänst (Föra ärendet framåt längs den maskinella processen) • Akt- och ärendetjänst (Hålla reda på ärendets status och hålla en journal i ärendet) • Dokumenttjänst (Lagra dokumenten och kunna visa dem kopplat till ärendet) • Bemannings- och fördelningstjänst (Kunna skapa en ”virtuell” organisation för ärendehanteringen. Sätta upp regler för fördelning av ärenden och kunna fördela ärenden efter dessa regler)

41. GÄHS => Tina => • I slutet på 1990-talet startades en förnyelse av inkomsttaxeringen. Senaste kallad TINA. • Tina har använt ÄR. • Tidigt stora problem men nu nöjda användare. • I dag endast stöd åt det som kallas Ink 2 (d.v.s. vanliga företag). • För Ink 1 (vanliga medborgare), Ink 3 (handelsbolag) och Ink 4 (Stiftelser mm) saknas modernt IT-stöd. • Stödet är en monolit i strid mot riktlinjerna. SOA-tänket fullföljdes ej. • Nu ska monoliten bli SOA i en generell Verksamhets- och Informationsplattform (VIP)

42. GÄHS => Tina => VIP • Under året ska en VIP 1.0 tas i drift med följande komponenter: • Mottagning (ta emot elektroniska dokument och förmedla dem) • Kontrolltjänster (valideringskontroller på indata) • Huvudapplikation med Inkorg (GUI för manuell åtgärd) • Arbetsuppgift (skapa underlag för åtgärd) • Signalhantering (mellan och inom system) • Korrespondensstöd (blankettmallar, ordbehandling mm) • Leverans (skapa och leverera utdata) • Anslutande system ska inte enbart erbjudas lösa komponenter utan också hela paket av funktionalitet. • Anstånd (med att lämna t.ex. deklaration) • Omprövning (och överklagande av myndighetens beslut) • Övervägande/beslut (när myndigheten vill göra en ändring) • Föreläggande (för den som inte lämnat t.ex. deklaration) • Förseningsavgift (dito)

43. Solen går upp vid Skatteverket

44. Den IT-strategiska planen 1 • Skatteverket har alltid legat i framkant när det gäller IT-utveckling och bemötande. • Det har till stor del berott på att vi haft ganska generösa IT-anslag. • När anslagen på allvar började att strypas (2008) så ökade kostnadsmedvetandet. • Vi hade bl.a. mycket höga kostnader för underhåll av gamla system och vi hade i stort sett inte avvecklat några system. Bara byggt nya som också skulle underhållas! • Arbetet med en IT-strategisk plan inleddes (2008 – 2009).

45. Den IT-strategiska planen 2 • Det konstaterades tyvärr också att vi kommer att drunkna och självdö i ökade förvaltningskostnader! • Sex utvecklingsområden identifierades varav 4 direkt relaterade till IT-stödet: Ett av dem var: • Stärka verksamhetsarkitekturen och en skapa en modern, flexibel och kontrollerad IT-arkitektur som främjar återanvändning och kostnadseffektivitet

46. Målarkitektur - Syfte • Målarkitekturen utvecklades 2009. • Målarkitekturens starka fokus på samverkan och förbättrad kundservice ger Skatteverket möjlighet att: • Ta en aktiv roll i att utveckla myndighetsövergripande samverkan • Erbjuda ett effektivt standardiserat informationsutbyte med olika intressenter • Utveckla verksamheten och erbjudanden utifrån tydliga kundbehov • Öka förtroendet för Skatteverket genom en utvecklad kundservice • Målarkitekturen utgår ifrån ett gemensamt arbetssätt, vilket skapar förutsättningar för att: • Driva en harmonisering och effektivisering av verksamheten • Konsolidera och standardisera det underliggande IT-stödet • På sikt få ett mer flexibelt IT-stöd, en snabbare IT-utveckling och en rimlig kostnad för IT

47. VerkA och arkitekturstyrning • VerkA (Funktionen för en sammanhållen VERKsamhetsutveckling och Arkitekturstyrning) startades årskiftet 2009/2010 • Efter många turer fastställdes den övergripande arkitekturstyrningen i arbetsordningen i april 2011.

48. Analogier med byggsektorn

49. Planer

50. Ritningar