EA – SOA - G. G. SOA. EA. Akademiska meriter Började 1:a 1960. Erfarenheter 60 -. Per ”Pelle” Nilsson. Statistik. Fastighetstaxering. Utredning. Programmering. Akademiska meriter Har ännu inte avslutat den 3-betygsuppsats i historia som jag påbörjade 1977. Erfarenheter 70 -.
Une image / un lien ci-dessous est fourni (tel quel) pour télécharger la présentation
Politique de téléchargement : le contenu du site vous est fourni TEL QUEL pour votre information et votre usage personnel ; il ne peut être vendu, concédé sous licence ni partagé sur d’autres sites sans l’accord de son auteur.Le contenu vous est fourni TEL QUEL, pour votre information et votre usage personnel uniquement.Téléchargez la présentation en cliquant sur ce lien.Lors du téléchargement, si vous ne parvenez pas à télécharger une présentation, l’éditeur a peut-être supprimé le fichier de son serveur.Pendant le téléchargement, si vous ne parvenez pas à obtenir une présentation, le fichier a peut-être été supprimé par l’éditeur.
Akademiska meriter Började 1:a 1960 Erfarenheter 60 - Per ”Pelle” Nilsson Statistik Fastighetstaxering Utredning Programmering
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.
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.
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
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
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
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.
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
SOA • Service Oriented Architecture = • Konceptet: • Paketerade funktioner med väl beskrivet gränssnitt (indata och utdata). • Kan vara parameterstyrd.
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.
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
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.
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
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
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
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
Ö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
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
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
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.
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.
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.
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.
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.
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.
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/
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.
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)
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)
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)
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).
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
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
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.
