EA – SOA - G G SOA EA Det finns kopplingar mellan Enterprise Architecture (EA) och Service Oriented Architecture (SOA) och de båda ger ett stöd för G =

En presentation över ämnet: "EA – SOA - G G SOA EA Det finns kopplingar mellan Enterprise Architecture (EA) och Service Oriented Architecture (SOA) och de båda ger ett stöd för G ="— Presentationens avskrift:

1 EA – SOA - G G SOA EA Det finns kopplingar mellan Enterprise Architecture (EA) och Service Oriented Architecture (SOA) och de båda ger ett stöd för G = gemensamt. Ambitionen är att allt vi kan göra gemensamt ska vi göra gemensamt. Kod, processmönster, information, arbetssätt, mätetal, miljöer, testfall o.s.v. Samtidigt är grundkoncepten bakom EA, SOA och G inget nytt. Sådana tankar har funnits länge.

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

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

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

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

6 Per ”Pelle” Nilsson Akademiska meriter Erfarenheter 2000-
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- Arkiv o diarie Projektledning Utveckling Systemering K/N-kalkyler Arkitektur Planering Statistik Samverkan Omvärldsbevakning Modellering Fastighetstaxering Förvaltning Utbildning 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 ) 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.
Det här är en bild över Skattverkets 200 viktigaste system samt myndigheter/företag i omvärlden som vi kommunicerar med. Strecken mellan rektanglarna beskriver att någon form av informationsutbyte sker mellan dessa system. Fler informationsutbyten mellan samma system ger bara ett streck. De olika färgerna på strecken är bara till för att göra bilden överskådligare och lättare att läsa. OBS! Bilden är inte 100-procentigt pålitlig. Den är gjord genom en sammanställning av information från våra produktblad. (Det finns/ska finnas ett produktblad per system). Denna information är dock inte alltid korrekt. I produktbladet för system A kunde det stå att den hämtade information från system B men om detta nämndes ingenting i produktbladet för system B. Även om informationen inte är helt korrekt så är det den enda sammanställning som finns.

9 Agenda 0800 - 0810 Akademisk kvart
0810 – 0815 Inledning. EA, SOA och G. Inget är nytt under solen Gryning på Skatteverket Fika 0850 – Solen går upp Målarkitektur Avslutning. Revolution, evolution, involution och paradigmskifte. Som ni ser har jag fått pussla ordentligt med schemat för att få plats med allting.

10 EA – SOA - G G SOA EA Den här presentationen ska försöka ge lite olika perspektiv på dessa akronymer. Givetvis den historiska. (Jag har ju påbörjat den utbildningen) men också en titt på grundkoncepten från lite andra vinklar.

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 Enterprise Architecture saknas på svenska Wiki. An enterprise architecture (EA) is a rigorous description of the structure of an enterprise, which comprises enterprise compnents, the externally visible properties of those components, and the relationships between them. EA describes the terminology, the composition of enterprise components, and their relationships with the external environment, and the guiding principles for the requirement (analysis), design, and evolution of an enterprise. This description is comprehensive, including enterprise goals, business process, roles, organizational structures, organizational behaviors, business information, software applications and computer systems….. By producing an enterprise architecture, architects are providing a tool for identifying opportunities to improve the enterprise, in a manner that more effectively and efficiently pursues its purpose. (Wiki) Gartner defines EA as the process of translating business vision and strategy into effective organizational change by creating, communicating and improving the key requirements, principles and models that describe the organization’s future state and enable its evolution. “The artificial walls between business and IT are crashing down, and EA is the bridge to integrate business and IT,” said Philip Allega, research vice president at Gartner. “EA’s original promise was its ability to provide future safe guidance given the desires and vision of an organization’s senior leadership team. (Från The Institute For Enterprise Architecture Developments.

12 SOA Service Oriented Architecture = Konceptet:
Paketerade funktioner med väl beskrivet gränssnitt (indata och utdata). Kan vara parameterstyrd. Tjänsteorienterad arkitektur (service oriented architecture, SOA) innebär att ett distribuerat IT-system organiseras som en struktur av kommunicerande tjänster. En tjänst är här en betjänande funktion som är väldefinierad, självständig och oberoende av sin omgivning. Kommunikationen kan innebära ett enkelt godkännande av data eller involvera två eller flera tjänster som samordnar en aktivitet. I ett system uppbyggt enligt SOA är resurser tillgängliga för andra system inom ett nätverk som oberoende tjänster, och kan anropas och adresseras på ett standardiserat sätt. Syftet med SOA är att uppfylla de affärsmässiga kraven på ett IT-system. En av styrkorna med SOA är att den mer än andra tekniker uppmuntrar till att återanvända redan befintliga tjänster/system. SOA förknippas ofta med webbtjänster baserade på XML, SOAP, WSDL och UDDI, men är i princip inte begränsad till endast dessa tekniker. (Wiki)

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. Inom väldigt många andra områden har man sedan länge kommit på att det finns vissa gemensamma behov som det är ekonomiskt lönsamt att lösa gemensamt. I tätbebyggda områden är det otänkbart att vi skulle skapa våra egna lösningar för t.ex. vattenförsörjning, avlopp, sophämtning m.m. För Skatteverket började insikten komma 1993 när jag kom tillbaka från barnledighet och den som vikarierat på min tjänst blev över. En insiktsfull chef satte min vikarie till att utreda om det inte fanns ärenderelaterad information som var gemensam för alla verksamheter med ärendehantering. Det fanns det och inte bara information utan också processer. Det blev inledningen till en resa där vi har upptäckt fördelar med att ha mer och mer gemensamt, t.ex. mätetal. Om olika verksamheter kan jämföras med varandra är det lättare att identifiera förbättringsområden. Varför kräver vår ärendehanteringsprocess så mycket resurser och tid i denna del av processen när x- och Y-verksamheterna fixar samma hantering på en bråkdel av tiden?

14 Inget är nytt under solen
Detta avsnitt behandlar forntiden fram till slutet på det förra årtusendet. Det hände mycket redan på den tiden IT hette ADB och datorn var en datamaskin.

15 Tidigt A-skikt Det vanligaste i tidiga grottmålningar och hällristningar var att man beskrev processer. Vanligen jakter eller ceremonier av olika slag. Alltså V-skiktet! Här har man dock gett sig på A-skiktet genom att beskriva en skomakare. Detta har man gjort genom att rita av de verktyg han använde för att utföra en viss funktion i skomakeriet. Verktygen ligger på högra sidan av gubben och ovanför hans händer. Det som sticker upp mitt i bilden var nog någon form av extratjänst.

16 Tidig funktion Arkimedes princip beskriver den kraft som påverkar ett föremål vilket sänks ned i en vätska. Den säger att "ett föremål nedsänkt i vätska påverkas av en uppåtriktad kraft, som är lika stor som tyngden av den undanträngda vätskan". Lyftkraftens storlek F är alltså proportionell mot volymen V av den del av föremålet som är nedsänkt i vätskan genom sambandet F = ρ V g, där ρ är vätskans densitet och ρV därmed den undanträngda massan medan g är jordens tyngdacceleration. Principen upptäcktes av Arkimedes. Matematiska funktioner är våra tidigaste exempel på ”tjänster”. De har ett tydligt gränssnitt på vad man ska stoppa in och en tydlig beskrivning av det resultat som kommer ut. (Stoppar man in en för fet karl så får man vatten på golvet). Dessa tjänster är också flyttbara och kan användas av alla i olika miljöer och situationer.

17 Tidigt G Som sagt man upptäckte tidigt att det var lämpligt att ordna t.ex. vattenförsörjningen gemensamt i städer.

18 Skogshögskolan pionjärer?
Förutsättningar Dator = IBM 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 Autocoder was the name given to certain assemblers for a number of IBM computers of the 1950s and 1960s. The first Autocoders appear to have been the earliest assemblers to provide a macro facility… The first Autocoders were released in 1955 for the IBM 702 and in 1956 for the almost compatible IBM 705. They were designed by Roy Goldfinger who earlier had worked on New York University's (NYU) NYAP assembler.[These machines were variable word length commercial machines, as were many of the computers for which an Autocoder was released….. The most well known Autocoder is that of the IBM 1401, undoubtedly due in part to the general success of that series of machines. Autocoder was the primary language of this computer, and its macro capabilities supported use of the Input/Output Control System which eased the programming burden. Another assembler, Sybolic Programming System (SPS), was also available for the 1401 and used the same mnemonics but a different input format. It lacked Autocoder's features and was generally used only on machines with less than the minimum 4000 characters of

19 Skogshögskolan pionjärer?
Each alphanumeric character in the 1401 was represented by six bits, called A, B, 8, 4, 2 and 1. The A and B bits were called zone bits and the 8, 4, 2 and 1 bits were called numeric bits. This encoding was developed from the IBM 80 column punched card's use of zone and digit punches, with Binary-Coded-Decimal (BCD) used for the digits 1 through 9…. Associated with each character were two other bits, called C for odd parity check and M for word mark. Each memory location then, had the following bits: C B A M…. Some operations used specific memory locations (those locations were not reserved and could be used for other purposes). Read a card stored the 80 columns of data from a card into memory locations Index registers 1, 2 and 3 were in memory locations , and respectively. Punch a card punched the contents of memory locations into a card. Write a line printed the contents of memory locations (Wiki)

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. Skogshögskolan slogs ihop med Lantbrukshögskolan och Veterinärhögskolan 1977 till Sveriges Lantbruksuniversitet och verksamheten flyttade till Umeå. Datorn (IBM 1401) stod emellertid kvar i de gamla lokalerna åtminstone en stor del av 1978 och jag nyttjade an av de tjänster den kunde erbjuda – multipel regressionsanalys. Vi var ute efter att skaffa en ny värderingsmodell för lantbruksfastigheter till den allmänna fastighetstaxeringen (Värdering av lantbruk är extremt svårt jämfört med småhusvärdering. 1. Det finns så många komponenter – bostadshus, ekonomibyggnader av alla slag, åker, skog, betesmark och annan mark. 2. Det finns flera olika marknader för lantbruk. Små = bostadsändamål, medelstora = driva jordbruk, stora = kapitalplacering. 3. Det finns mycket färre köp att analysera.) Vi var mitt uppe i ett hektiskt arbete när datorn försvann men tjänsten överlevde. Ett tag mellanlandande den hos en annan dator jag tror stod i Stockholm men snart hamnade den i Umeå hos UMDAC. Jag fick en skrivare med ett telefonmodem så jag kunde ringa upp UMDAC på en vanlig telefon. När jag fått svar lägga telefonluren i modemet och börja knacka ner mina instruktioner. Sedan var det bara att vänta på svar. Svaret kom på skrivaren med såpat papper (ej arkivvärdigt). Analysera svaret och sedan knacka ner nya instruktioner.

21 En lag som EA - 79? Fastighetstaxeringslagen 1 Kap. Sammanhanget
Här ges sammanhanget i stort! Kap. Kärnprocessen 2 Kap. Indelning byggnad och mark Beskriver en strängt reglerad process. Vi hade en stor fördel när vi skrev fastighetstaxeringslagen. Det fanns i princip ingen tidigare lagstiftning (enbart §5 i kommunalskattelagen). Vi fick börja från början. Kap 2 – 7 ger olika regler men också den ordning de ska utföras i (processen). 2 kap. Indelning av byggnader och mark 1 § Byggnader skall indelas i byggnadstyper och mark i ägoslag på sätt som anges i §§. Indelning får inte ske på grundval av tillfällig användning. 2 § Byggnader ska indelas i de byggnadstyper som anges i det följande. Småhus Byggnad som är inrättad till bostad åt en eller två familjer. Till sådan byggnad ska höra komplementhus såsom garage, förråd och annan mindre byggnad. Byggnad som är inrättad till bostad åt minst tre och högst tio familjer ska tillhöra byggnadstypen småhus, om byggnaden ligger på fastighet med åkermark, betesmark, produktiv skogsmark eller skogligt impediment. Byggnad som hör till en tredimensionell fastighet eller ett tredimensionellt fastighetsutrymme kan inte utgöra småhus 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) 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 Det tredje kapitlet reglerar skatteplikt. Sedan kan vi i det fjärde kapitlet börja bygga taxeringsenheter, alltså det som ska taxeras för sig. 4 kap. Taxeringsenhet och beskattningsnatur 1 § Taxeringsenhet är vad som skall taxeras för sig. Fastighet skall utgöra taxeringsenhet, om inte annat föreskrivs. 2 § Har skilda delar av en fastighet olika ägare skall fastigheten uppdelas i taxeringsenheter enligt ägarförhållandena. 3 § För bildande av taxeringsenheter skall fastigheter och fastighetsdelar med samma ägare inom samma kommun föras samman. Den sammanförda egendomen skall utgöra en taxeringsenhet, om inte annat sägs i §§. 4 § Taxeringsenhet ska omfatta antingen skatte- och avgiftspliktig eller skatte- och avgiftsfri egendom. Lag (2007:1416). Taxeringsenhet 5 § Taxeringsenhet ska omfatta byggnadstyper och ägoslag enligt en av följande kombinationer, om inte annat sägs i andra och tredje styckena, och ha en av följande beteckningar för typ av taxeringsenhet 1. småhus och tomtmark för sådan byggnad (småhusenhet) 2. ägarlägenhet och tomtmark för sådan byggnad (ägarlägenhetsenhet) 3. hyreshus och tomtmark för sådan byggnad (hyreshusenhet) 4. industribyggnad, övrig byggnad, tomtmark för sådana byggnader, vattenverk på annans grund samt sådan fiskefastighet som avses i 10 § lagen (1970:995) om införande av nya jordabalken (industrienhet) 5. täktmark samt industribyggnad och övrig byggnad på sådan mark (industrienhet) 6. specialbyggnad och tomtmark för sådan byggnad (specialenhet) 7. ekonomibyggnad, åkermark, betesmark, produktiv skogsmark och skogligt impediment (lantbruksenhet) 8. kraftverksbyggnad, tomtmark till kraftverksbyggnad och fallrätt samt taxeringsenhet vars värde till övervägande del utgörs av rätt till andels- eller ersättningskraft (elproduktionsenhet).

23 Här skapar vi värderings-
Mera I-skikt. 1 Kap. Sammanhanget Allmänna regler om värdering och om hur delvärden till taxeringsenheten skapas 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. Det femte kapitlet ger allmänna regler om värderingen. Det sjätte talar om hur vi bildar värderingsenheter alltså det som ska värderas för sig. Det sjunde berättar om allmänna värderingsregler. 6 kap. Värderingsenhet 1 § Värderingsenhet är den egendom som skall värderas för sig. En värderingsenhet skall endast omfatta egendom som ingår i en enda taxeringsenhet. 2 § Varje småhus, ägarlägenhet, hyreshus, industribyggnad och övrig byggnad med värde av minst kronor ska utgöra en värderingsenhet, om inte annat anges i 3 eller 5 §. Komplementhus på småhusenheten ska i regel ingå i samma värderingsenhet som det mest värdefulla småhuset på taxeringsenheten. Småhus, hyreshus, industribyggnader och övriga byggnader vilkas värde inte uppgår till kronor, ska ingå i samma värderingsenhet som den mest värdefulla byggnaden inom samma tomt. Uppgår den mest värdefulla byggnadens värde inte till kronor ska samtliga byggnader inom tomten utgöra en värderingsenhet. Lag (2009:105). 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 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 Taxerings- enheter Värderings- enheter. A-skikt 7 kap. Allmänna värderingsregler Värdefaktorer 1 § Värderingen skall ske med utgångspunkt i värdefaktorer. Med värdefaktorer avses egenskaper som är knutna till fastigheten och som har betydelse för marknadsvärdet. Värdeområden 2 § Riket skall indelas i värdeområden för byggnader och ägoslag, som skall värderas med ledning av riktvärden. Värdeförhållandena inom ett värdeområde skall i allt väsentligt vara enhetliga. Värdeområde skall därför bestämmas så att inverkan av de värdefaktorer, som särskilt beaktas vid riktvärdets bestämmande, skall kunna bedömas enligt enhetliga regler. Riktvärden m.m. 3 § För byggnader och ägoslag som avses i 8–15 kap. ska taxeringsvärde bestämmas med utgångspunkt i riktvärden. Dessa ska för varje värderingsenhet bestämmas för kombinationer av värdefaktorer, som i någon utsträckning varierar inom värdeområdet och som har särskild betydelse för marknadsvärdet. 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. Kap. Kärnprocessen 2 Kap. Indelning byggnad och mark 3 Kap. Skatteplikt 4 Kap. Indelning i taxeringsenheter 5 Kap. Allmänt om värde Kap. Värdefaktorer 6 Kap. Indelning i värderingsenheter Attribut Info.objekt Info.objekt Taxerings- enheter Värderings- enheter. A-skikt 8 kap. Riktvärde för småhus 3 § Inom varje värdeområde skall riktvärden bestämmas för skilda förhållanden för en eller flera av följande värdefaktorer. Storlek Storleken bestäms med hänsyn till ytan av småhusets boutrymmen och biutrymmen. Ålder Åldern ger uttryck för småhusets sannolika återstående livslängd. Denna bestäms med hänsyn till småhusets nybyggnadsår, omfattningen av tillbyggnader och sådana ombyggnader som innebär en utökning av boutrymme samt tidpunkten för dessa. Åldersklassen för småhus med en ålder motsvarande högst 20 år får inte göras större än att den motsvarar 5 år. Standard Standarden bestäms med hänsyn till småhusets byggnadsmaterial och utrustning. För ett nybyggt småhus skall finnas minst femton standardklasser. Byggnadskategori Byggnadskategorin bestäms med hänsyn till om småhuset utgör friliggande småhus, kedjehus eller radhus. Fastighetsrättsliga förhållanden Fastighetsrättsliga förhållanden bestäms med hänsyn till om den värderingsenhet för tomtmark på vilken småhuset ligger utgör självständig fastighet eller inte. Utgör värderingsenheten inte självständig fastighet skall hänsyn även tas till möjligheten att tomtmarken kan bilda egen fastighet. Detta gäller dock inte om värderingsenheten är belägen inom ett område med byggnader av likartad karaktär som ligger i en grupp och som har uppförts samtidigt eller under en begränsad tidsperiod (grupphusområde). Småhus som utgör brukningscentrum för lantbruksenhet skall jämställas med småhus som ligger på tomtmark som utgör självständig fastighet. Om det på en lantbruksenhet finns endast ett småhus, anses det utgöra brukningscentrum. Om det finns flera småhus på en lantbruksenhet, utgör det värdefullaste småhuset brukningscentrum, såvida inte annat visas. Värdeordning Med värdeordning avses husets ordningsnummer i värdehänseende inom tomten. 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 Kap. Kärnprocessen 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 Kap. Värdefaktorer 6 Kap. Indelning i värderingsenheter Attribut Info.objekt Info.objekt Taxerings- enheter Värderings- enheter. A-skikt 18 kap. Allmän och förenklad fastighetsdeklaration, m.m. 1 § Till ledning vid allmän och förenklad fastighetstaxering ska ägaren utan föreläggande lämna deklaration (allmän respektive förenklad fastighetsdeklaration) för varje fastighet. Detta gäller inte sådan ägare som senast den 15 oktober året före det år då allmän eller förenklad fastighetstaxering äger rum fått förslag till fastighetstaxering. Deklaration ska dock inte lämnas för försvarsfastighet som tillhör staten och som enligt 3 kap. 2 § är undantagen från skatte- och avgiftsplikt eller för fastighet som vid föregående års taxering inte åsatts högre taxeringsvärde än kronor. Deklaration ska inte heller lämnas för fastighet för allmänna kommunikationsändamål eller för distributionsbyggnad, värmecentral eller reningsanläggning som enligt 3 kap. 2 § är undantagen från skatte- och avgiftsplikt eller för byggnad på annans mark då byggnadens värde understiger kronor. Finns på sådan kommunikationsfastighet som nyss har nämnts husbyggnad som används för annat än kommunikationsändamål ska dock deklaration lämnas. Efter föreläggande är också den som inte på grund av första stycket har deklarationsskyldighet, skyldig att lämna fastighetsdeklaration. 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 Kap. Kärnprocessen 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 Kap. Värdefaktorer 6 Kap. Indelning i värderingsenheter Attribut Info.objekt Info.objekt Taxerings- enheter Värderings- enheter. A-skikt 1 kap. Bestämmelser om värderingen Allmänna bestämmelser 1 § Beteckningar i denna förordning har samma innebörd som motsvarande beteckningar i fastighetstaxeringslagen (1979:1152). 2 § Riktvärde skall bestämmas för värderingsenhet. För olika slag av värderingsenheter skall riktvärden finnas för skilda förhållanden beträffande de i 8-15 kap. fastighetstaxerings- lagen (1979:1152) föreskrivna värdefaktorerna. Riktvärdena skall bestämmas med utgångspunkt i de riktvärdeangivelser som enligt 7 kap. 3 § fastighetstaxeringslagen för varje värdeområde skall redovisas på riktvärdekartor, i tabeller och på sätt som anges i detta kapitel. En tabell skall innehålla 1. riktvärden för en värderingsenhet (riktvärdetabell) eller 2. relativa värden för en värderingsenhet, en byggnad eller byggnadsdel, ett hektar, en kvadratmeter eller en kubikmeter (relationstabell) eller 3. endera av kapitaliseringsfaktorer, brytningsfaktorer, nedräkningsfaktorer, omräkningsfaktorer, belägenhetsfaktorer eller storleksfaktorer. 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. ”Vi hade en egenutvecklad förprocessor, DOPA,70 som bland annat stöttade vår programmeringsutveckling enligt JSP.71 I JSP fanns en del verb (DOWHILE, IFNDIFF)72 som COBOL-kompilatorn inte kunde ta hand om direkt så att DOPA tog han dom specialverben och översatte till Cobolitiska. Sedan hade vi även ett fipotek73 på den tiden, alltså en fil-post-term-katalog och DOPA tog hand om information från alla programmen som kompilerades och lade upp informationen i en speciell databas som höll ordning på strukturerna, system, program, filer, poster, termer som man sedan kunde söka i och få fram vilka poster berörs exempelvis om vi gör en förändring i en specifik term.” (Citat från Kjell Ekström ur Transkript av ett vittnesseminarium vid Tekniska museet i Stockholm den 17 januari 2008 (kth.diva-portal.org/smash/get/diva2:126928/FULLTEXT01 ) 73 Fipotek = fil- post- termkatalog, dvs. en katalog över alla befintliga termer med syftet att definiera termer som fick användas och att få till stånd ett konsekvent användande av termerna inom alla systmområden.

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. Målet för arbetsgruppen AKTIV – AKTer I Verksamheten – har varit att ta fram ett ramverk för ärendehantering inom skatteförvaltningen. Fokusering har skett på indelning av verksamheten i ett antal kärnfunktioner med tillhörande styr- och stödfunktioner… En modellering har genomförts som ett första steg för att kartlägga och definiera skatteförvaltningens kunder och intressenter verksamhetsprocesser ärendetyper roller och ansvar i utvecklings- och förvaltningsarbetet (ur sammanfattningen till slutrapporten)

30 V-skikt. Processmodeller.
Processmodell - Översikt Strategisk styrning Kännetecknande för Strategisk styrning är att den inte kan inordnas i någon gemensam processyn. Den är starkt knuten till olika initiativ och aktiviteter av ledningen. Syftet med den strategiska styrningen är att bestämma mål, formulera policies och modeller samt att utforma allmänna strategier för att uppnå dessa. Verksamhetsstrategin kan delas upp i flera delstrategier, såsom förenklingsstrategi servicestrategi kontrollstrategi strategi för effektiv styrning IT-strategi personalstrategi organisationsstrategi. (ur slutrapporten)

31 I-skikt. Begreppsmodeller.
5.1 Grundläggande begrepp I utrednings- analysarbetet har en övergripande begreppsmodell definierats med de mest centrala begreppen för ärendehantering. Begreppsmodellen återges i figur 10 nedan. Definitioner till begreppen återfinns i ordlistan, kapitel 15 (ur slutrapporten)

32 Detaljering. Processmodell - Detaljer
Process nr 10 – Fånga massinformation I den gemensamma processen ska översättning ske av produktionsbestämd information som inkommer till myndigheten i betydande volym. Översättning sker till riksgemensamt standardiserat maskinläsbart data och standardiserade elektroniska bilder. Resultatet dokumenteras i rådatalager och bildarkiv. Inflöde är de produkter och den information som i process 9 – Ta emot information – har klassats som masshanteringsprodukter och ska hanteras i processen. Hanteringsinformation från olika stödsystem stödjer processen. (ur slutrapporten)

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. AKTIV startades på enheten för personbeskattning inom verksamhetsområde Skatt. (Alltså på verksamhetssidan). Under projektets gång gjordes en omorganisation så att IT-nära utveckling på verksamhetsidan samlades i en egen IT-enhet (S/IT). Arbetet med AKTIV slutfördes på denna enhet. Vid en större omorganisation fördes S/IT över till IT-avdelningen som en speciell stabsenhet (strategienheten). Tyvärr förlorades därmed den nära kopplingen till verksamhetssidan (beställarna). Verksamhetens beställare har fram till de senaste åren därför varit mycket svaga i frågor som rör utvecklandet av det gemensamma vilket fått 2 allvarliga följder: Det som utvecklats har inte varit tillräckligt generellt för att kunna användas av flera. Beställarna har inte känt sig delaktiga i utvecklingsarbetet och det har därför varit mycket svårare att sälja in gemensamma lösningar.

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. UNIX var inte ensam bov i dramat men en starkt bidragande orska till förvaltningen begynnande förfall. Införandet av UNIX sammanföll också med ett generationsskifte i ledning och styrning. Det blev ett avbrott i vårt traditions- och kulturarv.

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. RUP glömde nog inte beställarna men IT-organisationen slog in på en ny väg utan att säkerställa att det gjordes tillsammans med beställarna. Jag fick följande tänkvärda ord från en medarbetare (Rutger Langland) som kommentar till denna bild: "Om jag vill föra en människa mot ett bestämt mål måste jag först finna honom där han är och börja just där. Den som inte kan det lurar sig själv när hon tror att hon kan hjälpa andra. För att hjälpa någon måste jag visserligen förstå mer än vad han gör, men först och främst förstå det han förstår. Om jag inte kan det, så hjälper det inte att jag kan och vet mycket mer. Vill jag ändå visa hur mycket jag kan, så beror det på att jag är fåfäng och högmodig och egentligen vill bli beundrad av den andre istället för att hjälpa honom." - Sören Kirkegaard, Dansk Filosof

36 Gryning på Skatteverket för G
Detta avsnitt behandlar utvecklingen från 1998 tills nu med fokus på gemensamma lösningar.

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. Vi försökte verkligen att undvika verksamhetsspecifik kod i lösningarna men pressen från ansvariga för de system som skulle utnyttja den gemensamma lösningen blev för svår. Framför allt gjordes en hel del verksamhetsspecifika kontroller i systemet. Vi hanterade alla möjliga indatakanaler inom in- och utdata – skanning (med eller utan tolkning), magnetmedia (band eller disketter), direkt elektronisk överföring i olika former och telefon. Vi hade också vår egen hantering av certifikat. En anledning till att vi inte kunde undvika verksamhetsspecifika kontroller i lösningen kan ha varit att tekniken med generell regelhantering med hjälp av regelmotorer inte var redo. Vi håller nu på att göra en förstudie kring detta. Vi har precis samma behov av detta i den gemensamma mottagningskomponenten som vi nu håller på att bygga + givetvis på en hel del andra håll. Försäkringskassan har sedan några år kommit i gång med denna teknik och haft stora framgångar inom de områden där lagar (och andra regler) är välstrukturerade, t.ex. tandvårdsförsäkringen.

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 SHS byggdes i ett Public Private Partnership (PPP) projekt. Det förvaltades först av ett SHS-råd, sedan av Statskontoret – Kammarkollergiet och nu Försäkringskassan. på något sätt är nu också Umeå Universitet inblandat i förvaltningen. SHS har sin egen Webb-p,lats - (ur denna) ”SHS (Spridnings- och Hämtningssystem) är ett koncept för säkert och pålitligt utbyte av information mellan offentliga organisationer. Specifikationer som bygger på Internetstandarder har tagits fram och utvecklats tillsammans med myndigheter och leverantörer för att beskriva önskad funktionalitet. Funktionen säkert och pålitligt informationsutbyte beställs dels via SHS-avtalen i form av produkter som installeras och drivs i den egna tekniska miljön, dels som tjänst via avtalen inom området Infratjänst. SHS används idag av statliga myndigheter, kommuner och landsting men även företag och organisationer vid informationsutbyte i samband med e-tjänster. Ramavtalen om SHS, SHS 2004 och Infratjänst 2003 erbjuder myndigheter, kommuner och landsting lättillgängliga produkt- och tjänstelösningar för egen utveckling och drift av viktiga funktioner. De definierar också en arbetsform för myndigheternas och IT-leverantörernas utveckling av specifikationer och produktlösningar för säker överföring av information över IP-nät enligt SHS-arkitekturen”

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. Från början ett samarbete mellan Försäkringskassan och Skatteverket under namnet eDok Ett generellt sätt att paketera elektroniska dokument så att de Har de metadata som krävdes för Automatiskt knytas till ärenden (eller skapa ärenden) i ett maskinellt ärendehanteringssystem och Kunna lagras i ett elektroniskt arkiv Kan hålla samman bilder av skannade dokument med tolkat data Kan hålla samman sammansatta dokument av typen bilagor till och bilagor till bilagor etc. Skatteverket hade bråttom och gick sin egen väg under namnet gDok

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) Ur produktbeskrivningen ”Ärenderamverket (AR), övergripande information Systemområdesbeteckning ÄR …. Ärenderamverket ansvarar för processerna för hantering av ärenden som ska behandlas av Skatteverket ? maskinellt av Skatteverkets verksamhetsapplikationer, och manuellt av handläggare med hjälp av ett grafiskt gränssnitt. Ärenderamverket sköter de bakomliggande processer som driver ärendena, medan de olika verksamhetsapplikationerna utför de arbetssteg som utgör behandlingen av ärendena. Produkterna används av många. Finns i flera olika versioner. Senaste är ÄR 7.0 (ÄR = Ärenderamverket)”

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) Tina är ett av de största utvecklingsprojekt som Skatteverket har genomfört. Det hade stora problem under utvecklingstiden och blev oförklarligt dyrt. En del av förklaringen till problemen var att arkitekturen inte var tillräckligt bra beskriven och inte underhölls under utvecklingstiden. Det var många delprojekt med oklara beroenden till annat arbete, vilket ledde till stora samordningsproblem. Den begreppsmodell som togs fram var för dålig och någon informations- eller datamodell togs aldrig fram. Det ledde till att man löste informationsstrukturen i varje användningsfall som skulle realiseras (och då givetvis på olika sätt). Samtliga symptom på fenomenet Bermudatriangeln kan hittas i analysen av Tina.

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) Förutom att utveckla arkitekturen för ovanstående komponenter ska följande övergripande arbete göras: Avvikelsehantering och planering (Tinas arkitektur är inte anpassad till målarkitekturen. Avvikelser måste hanteras). Kvalitetssäkring av begrepp (med expertstöd) Remisshantering och förankring Dokumentation och publicering av arkitekturen Regelhantering (förstudie kring en generell hantering av verksamhetsregler) Standardisering av journalanvändningen Standardisering av dokument Etablerad produktförvaltning (organisation) Utbildnings- och informationsmaterial Anpassad VU-process samt KUR med avseende på hur man utvecklar med gemensamma komponenter Genomförd information och utbildning av berörd personal inom SKV

43 Solen går upp vid Skatteverket
Här skildras tiden från 2008 med fokus på arbetet som föregick målarkitekturen och arbetet med att etablera en arkitekturstyrning.

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). Arbetet fokuserade på att matcha verksamhetens mål mot strategiska krav på IT. Det konstaterades att det fanns ett ganska stort antal system som var kandidater till avveckling. Det konstaterades också att nuvarande IT-portfölj inte stödde det tänkta framtida arbetssättet – med fokus på personen i stället för enskilda ärenden.

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 De 5 andra var: Samordna insatser som relaterar till eFörvaltning och kundmötet. Beskriva behov av IT-stöd för att möta framtidens arbetssätt. Utdela ett tydligt ansvar avveckling och konsolidering. Skapa tydligare samarbete, roller och ansvar för att snabbare kunna anpassa IT-stöd efter verksamhetens behov. Leda IT-utvecklingen med en tydligare och mer operativ styrning. Skapa en tydligare kostnadsbild för IT-stödet.

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 Vi arbetar med att etablera förutsättningarna Förankring (fokus på ledningsnivå) Styrning av aktiviteter för att säkra arbete mot målarkitekturen Ansvar inom primärt verksamhets- och informationsarkitekturen Tydliga och lättkommunicerade ariktekturprinciper som stöd till införandet Business Case för kostnadsreducerande insatser, med fokus på kundärendeflödet

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. I bilden visas skikten i arkitekturen V- (Verksamhet), I- (Information), A (Applikation) och T (Teknik). Den översta nivån i staplarna är övergripande. Ju djupare man kommer i staplarna desto mer ökar detaljeringsgraden. Även om verksamhet och IT måste samverka så behövs en viss fördelning av ansvaret. Det är inte så enkelt som att ge verksamhetssidan V- och I-skiktet och låta IT ta A- och T-skikten. Verksamhetssidan har ett mycket djupgående ansvar för V-skiktet (processbeskrivningar ner till work-flow) och möter IT i användningsfall e.dyl. Verksamhetssidan har också ett stort ansvar för I-skiktet (Begreppsmodeller och informationsmodell) och möter IT i datamodeller. Men verksamhetssidan har också ett visst ansvar i A-skiktet (Verksamhetens ”synliga” funktioner) och i T-skiktet (övergripande krav på prestanda, tillgänglighet mm). Ansvargränsen kan sägas gå diagonalt genom arkitekturen (enligt bilden). Samtidigt är det en glidande övergång av ansvaret. Ingen knivskap gräns. På den övergripande nivån är det helt avgörande att helheten i arkitekturen hålls och att Verksamhet och IT samverkar fullt ut.

48 Analogier med byggsektorn
Det här med arkitektur eller ännu värre Enterprise Architecture är skrämmande för många som inte har arbetat med sådana frågor. Genom att göra jämförelser med byggsektorn kan man på ett enkelt sätt belysa vad det handlar om. Dessa jämförelser har bemötts mycket positivt. ”Jaha är det det handlar om! Självklart vill jag ha ritningarna klara innan jag bygger min nya villa.” Analogier kan givetvis göras med andra verksamheter också men just byggsektorn innehåller väldigt många träffande analogier inom en rad olika områden.

49 Planer Bygg-branschen Verksam-hets-arkitektur Kommentar
Region-plan e.dyl Saknas oftast. En tydlig beskrivning av vår plats på medborgarens och företagarens verklighetskarta. Den stora helhetsbilden! Översikts-plan Mål-arkitek-turen Var vill vi ha villorna, radhusen, hyreshusen, köp- och nöjescentra hyreshus och industrier i framtiden? Var ska fritidsbebyggelse och rekreationsområden ligga. Vilka behov finns av speciell gemensam infrastruktur? Detaljplan Kvarter (bygg-block) Regler för avgränsade områden. T.ex. maximal takhöjd, typ och färg på fasad etc. Även regler om vad som ska användas av gemensamma lösningar som sophämtning året runt eller tvång att ansluta till kommunalt VA-nät. Situations-plan Byggblock Mer detaljerade regler för enskilda byggen för att de ska passa in i kvartersmiljön. Inom byggsektorn finns planer på olika nivåer, med lite olika syften. Motsvarande gäller arkitekturen. Dessa planer är viktiga både för utveckling och underhåll. Kvarter- och byggblock används inom V- och A-skiktet för att peka ut delområden där det kan finnas gemensamma lösningar, t.ex. inom kvarteret ”Kanaler”. För sådana delområden kan det finnas särskilda regler, riktlinjer och guidelines.

50 Ritningar Bygg-branschen Verksam-hets-arkitektur Kommentar
Byggnads-ritningar i.e. plan- och fasadritningar Process-beskrivningar, modeller i I-skiktet, funk-tioner i A-skiktet Beskriver verkligheten, nuvarande eller planerad, ur olika perspektiv. OBS även om perspektiven är olika så är det samma objekt som beskrivs. Ritningar över ventilation, VA, etc T-skiktet Ritningar över den teknik som behövs för att byggnaden ska fungera och kunna användas på avsett vis. Ska bara funka tycker beställare men ritningarna behövs. Korrigerade ritningar Anpassningar under utvecklings-arbetet. Både vid byggen och vid verksamhetsutveckling blir det ofta nödvändigt att göra justeringar av de ursprungliga ritningarna. Dessa måste då dokumenteras. Våra ritningar är Processbeskrivningar Olika begrepps- och informationsmodeller Applikationskarta Ritningar över den tekniska strukturen. Återigen N.B. Dessa måste underhållas på alla nivåer. För den som bor i sin egen villa kanske detta inte känns så akut. Man vet ju själv vad man gjort med den. För en professionell fastighetsförvaltare med ett stort byggnadsbestånd är det emellertid nödvändigt. Att man klarar sig bra i sin egen villa utan att ajourhålla ritningarna beror på att man själv vet, d.v.s. en tydlig form av personberoende som vi vill undvika i organisationen. Det blir väldigt tydligt om villan säljs och en ny ägare tillträder. Då är korrekta ritningar bra att ha.

51 Roller 1 Byggbranschen Verksamhetsarkitektur Kommentar Fastighetsägare
Processägare Objektägare (PM3) Den som vill något med sin verksamhet/fastighet och bestämmer. Fastighetsförvaltare Förvaltningsledare (PM3) Den som förvaltar fastigheten/verksamheten. Byggherre (om annan än fastighetsägaren) Delegerad beställare Den som operativt bestämmer över bygget. Byggmästare Projektledare Ansvarar för att koordinera byggprocessen och föra dialogen med byggherren Kvalitetsansvarig Inre och yttre kvalitetsfunktion Ansvarar för att arbetet drivs effektivt och att resultatet blir bra. Frågan om roller och ansvar i en organisation blir krånglig om man försöker att bryta upp linjeorganisationen. Skatteverket håller nu (samtidigt) att införa På:s Maintenance Management Model (PM3) och arkitekturstyrning. Båda förutsätter en matrisorganisation där delar av linjechefens (stuprörsägarens) ansvar förs över till andra funktioner i organisationen.

52 Roller 2 Byggbranschen Verksamhetsarkitektur Kommentar
Snickare, målare, murare, elektriker etc De olika specialistroller som behövs i utvecklingen. T.ex. arkitekt, analytiker, utvecklare. Byggnadsnämnden VerkA Arkitekturledningen Informerar allmänt. Bollplank under planeringen. Ger eller vägrar bygglov Länsstyrelsen CIO-forum (PA-led) Behandlar överklaganden. Inspektörer Q-funktionen på PA VITA-granskningar Under större byggarbeten sker olika typer av inspektion. Alltid slutbesiktning. VerkA är en funktion för en sammanhållen Verksamhetsutveckling och Arkitekturstyrning. Inom ramen för arkitekturstyrningen finns nya roller såsom kvarters- och blockägare samt informationsägare. VerkA har en funktion som byggnadsnämnd och kan ge eller vägra ”bygglov” för ett planerat utvecklingsprojekt. Det finns därtill en ”överklagande-process” som reglerar hur frågor ska lösas där VerkA inte är överens med den verksamhetsansvarige. Liksom byggnadsnämnden prövar inte VerkA enbart inkomna bygglovsansökningar utan spelar framför allt rollen av bollplank i planeringsarbetet.

53 Regler Byggbranschen Verksamhetsarkitektur Kommentar
PBL (Plan- och Bygglagen) Övergripande regler och riktlinjer för förvaltning och utveckling. T.ex. VU-processen, Pejl, RUP Utarbetas av VerkA. Beslutas av CIO eller arkitekturledningen efter ett remissförfarande. Byggnormer (Boverket) Är egentligen byggregler, konstruktionsregler och tillämpning av EU-standard Detaljerade regler för ett visst kvarter eller byggblock. Även detaljerade regler för ett visst informationsområde eller delområde. Utarbetas av kvarters- eller blockansvarig. Beslutas av VerkA eller arkitekturledningen efter ett remissförfarande. Motsvarande förfarande på tekniska sidan. Arkitekturen är inte bara modeller över verksamheten. I arkitekturen ingår mängder med regler, riktlinjer och goda råd. På övergripande nivå t.ex. riktlinjer om arkivering och diarieföring av elektroniska dokument. På mer detaljerad nivå t.ex. style-guide för utveckling av eTjänster.

54 Standardisering Byggbranschen Verksamhetsarkitektur Kommentar
Hela byggmarknaden är standardiserad från minsta skruv till C/C mellan reglar och djup på bänk . Standardisera mera. EA ger oss bättre möjligheter att identifiera möjligheter till standardisering och vi bör alltid tänka på de möjligheterna. Framför allt anpassning till internationella standards avseende I-skiktet. Standardkomponenter GM Gemensamma lösningar. Ve den som bygger i dag utan att använda standard-komponenter? Försök att platsbygga ett kök med enbart användande av lösvirke i olika dimensioner. Ålder > år Ålder 50 – 60 år. Kan kanske förklara att vi inte kommit längre i standardiseringsarbetet för verksamhets- och IT-utveckling. Om man analyserar byggsektorn närmare så slås man av hur otroligt standardiserat allt är. (Även om man som jag blir galen på denna djungel av olika skruvhuvuden och bits så finns det en bit som passar till varje form av skruvhuvud) Om man som jag är otålig och få en snabb standardisering av det vi utvecklar så kan man bli lite irriterad om man jämför med byggbranchen. En kollega försökte lugna mig med att byggbranschen är en mycket gammal verksamhet medan IT-branschen startade på till 1960-talet. Det ligger en hel del i det men jag har inte lust att vänta i 1000-tals år. Dessutom inleddes standardiseringen av byggbranschen på allvar först under 1900-talet.

55 Bermudatriangeln. Vad är det?
Är lokaliserad till detta område i arkitekturen! Vad är det för positivt med det? Allt som produceras här försvinner spårlöst! De grundläggande orsakerna har identifierats. Vilket gör att vi kan börja med arbetet att förebygga dem. Orsakerna är: 1a Bristande styrning 1b Bristande förståelse 2 Inte bra nog 3 Hålls inte ajour 4 Överlämning till IT funkar ej 5 Förvaltas ej

56 Målarkitektur Detta avsnitt fokuserar på en övergripande nivå beskriva själva målarkitekturen.

57 Syftet Skatteverket är en utvecklings- och IT-intensiv myndighet.
Målarkitekturen är ett styrdokument som beskriver hur Skatteverkets verksamhet och IT-stöd bör utvecklas Målarkitekturen skapar förutsättningar för att utveckla Skatteverket till en öppen och samverkande myndighet Målarkitekturen syftar till att stödja en effektivisering av verksamheten och en rimlig kostnadsutveckling för IT-stödet 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

58 Verktyg 2 ramverk för arkitekturarbetet
TOGAF (The open groupe architectural framework) samt GEAF (Gartners enterprise architectural framework) Vi har köpt in QLM (Qualiware lifecycle manager) som verktyg för att dokumentera arkitekturen. QLM är ett av de verktyg som täcker en mycket stor del av utvecklingsprocessen. QLM ger en mycket god spårbarhet mellan olika modeller. ”Allt” kan göras i Qualiware. Vi arbetar nu med att ta fram riktlinjer för vad som ska göras och vad som bör göras. Vi arbetar också med att få en spårbarhet mellan QLM (verksamhetsutveckling) och de verktyg som ska användas för IT-utveckling.

59 Målbild för verksamhetsarkitekturen
Består av kvarter och byggblock. Processerna kan ritas in som flöden genom byggblocken (syns ej i målbilden). Angreppssättet bygger på ett helhetsperspektiv Synsättet vänds; gemensamt är utgångspunkt. Bort från silotänk. Målbilden för verksamhetsarkitekturen har utvecklats med bakgrund i fyra teman, som samlar framtida behov* Kundservice Samverkan Exploatera interna synergier Minska skattefelet Målbild verksamhetsarkitektur: Bärande princip: gemensamt arbetssätt Gemensamt ärendeflöde som styrs av verksamhetsregler Effektiv interaktion och kundservice via enhetliga kanaler Standardiserat informationsutbyte internt och externt Målbild informationsarkitektur: Samling kring begreppet ”person” möjliggör förbättrad service Enhetlig hantering av verksamhetens centrala information, t.ex. ”ärende”, ”underlag” och ”beslut” Indelning i informationsområden för styrning Ramverk för informationsspridning (masterdata) Målbild applikationsarkitektur: Behov av ny funktionalitet (t.ex. kundbild och paketering av e-tjänster) Möjlighet till konsolidering (framför allt inom kundärendeflödet)

60 Verksamhetsarkitekturen
Målarkitekturen innehåller kvarter och byggblock. Dessa avses samspela med verksamhetsflöden (processer) enligt följande: Byggblock Uttrycks normalt i termer av ”vad som görs” och är därigenom mer stabila över tid. Innehåller normalt en (eller flera) processer som beskriver ”hur det görs”. Använder information och nyttjar IT-stöd Verksamhetsflöde Binder samman ett antal byggblock i ett för verksamheten centralt flöde. Kan ses som ”makroprocess” med ett utifrån och in-perspektiv.

61 Informationsarkitekturen
Informationsmängder och informationsstruktur En informationsmängd är en gruppering av liknande information, med liknande struktur, som används med liknande syfte i verksamheten. Exempel är information som används med syftet att beskriva: Personer Ärenden Underlag Varje informationsmängd har en informationsstruktur som beskriver informationsinnehållet och hur informationsstrukturer relaterar till varandra. Informationsstrukturen ska i största möjliga utsträckning vara gemensam för hela Skatteverket. Informationen behöver däremot inte vara gemensam.

62 Centrala informationsmängder
Genom att placera begreppet Person i centrum och koppla Kundprofil och Ärenden till denna informationsmängd förbättras Skatteverkets möjligheter att ge god service till kunder. Dessutom skapas nödvändiga förutsättningar för framtidens analys och riskhantering. Genom att förtydliga begreppet Ärende och förstärka kopplingarna till Underlag och Beslut möjliggörs ett mer enhetligt ärendeflöde, vilket är en förutsättning för att harmonisera underliggande IT-stöd och dessutom skapar möjlighet till standardiserad rapportering och uppföljning. Genom att skilja på information och informationsstruktur skapas möjligheter till synergier även i de fall där informationen av legala skäl måste hållas separerad, t.ex. Folkbokföring och Beskattning. Sammantaget skapas förutsättningar för ett mer flexibelt och kostnadseffektivt IT-stöd.

63 Ramverk för informationsspridning
Ramverket är baserat på tre principer: Det finns bara en källa (eller master) för varje informationsmängd. All information har en ägare. Det klargör ansvar och befogenheter. Varje källa är inkapslad och skyddad Information är bara tillgänglig genom informationstjänster All information ska ha en ägare – Att det finns en och endast en ägare för specifik information klargör ansvar och befogenheter Informationsområden, eller delområden, definierar en förvaltningsstruktur för informationsmängder och informationsstruktur. Regeln ovan gör att detta ansvar blir väl definierat. Informationsområden och delområden kan därför användas som utgångspunkt vid tilldelning av ansvar för masterdata. Ett klassiskt verktyg i jakten på dataintegritet är inkapsling. Inga informationsmängder synliggörs utanför inkapslingen. Enheten för inkapsling (källan) kan vara ett helt informationsområde, ett delområde, eller en mindre del. Kornigheten på inkapslingen beror på behoven av skydd och/eller delning av informationen.

64 Extern och intern användning
Informationstjänster för spridning av info utanför informationsområdet skapas. Alla delade informationsmängder exponeras enbart i standardiserade format via informationstjänster. Informationstjänsterna publiceras i en tjänstekatalog som innehåller alla informationstjänster. Tjänster kan exekveras enligt principen ”post för post” eller per batch. Alla informationstjänster skall följa Skatteverkets regler för behörighetskontroll och informationssäkerhet. OBS: Att vara ansvarig för en tjänst är inte samma sak som att vara ansvarig för information eller struktur.

65 Avslutning Revolution Evolution Involution Konklusion @Paradigmskifte
Då ska vi försöka att knyta ihop säcken!

66 Revolution De allra starkaste verksamhets- utvecklarna har ännu inte
När det gäller planering gäller det av vara revolutionär. Att vara kreativ och våga tänka utanför ramarna. Att våga ifrågasätta. De allra starkaste verksamhets- utvecklarna har ännu inte börjat på dagis. Den största utmaningen ligger framför oss. Den handlar om att förändra vårt sätt att tänka, hur vi organiserar oss och de tjänster och den service vi tillhandahåller. Inte minst handlar det om att bortse från de organisatoriska gränser som funnits tidigare, se på oss själva från företagens och medborgarnas synvinkel och börja samverka. (ur På väg mot 24-timmarsmyndigheten, Regeringskansliet). Nyfikenhet är en framträdande egenskap hos framgångsrika verksamhetsutvecklare. En annan egenskap som krävs är att vara ifrågasättande. Vafför gör di på detta viset? Varför, varför, varför?

67 Evolution I genomförandet måste vi jobba evolutionärt. Se till att analysera alla skikt i arkitekturen och alla relevanta omvärldsfaktorer och sedan systematiskt förfina våra modeller (med beslutspunkter mellan varje steg). Utveckling m. full AU-bredd Målarkitekturen i allt väsentligt genomförd. V-skikt I-skikt A-skikt T-skikt De tio budorden: Helhetssyn i allt arbete Rätt från början. Tänk efter före. Våga pröva och ompröva allt Arbete med och för användarna Alla ska med och veta varför Samverkan är värd sitt pris Kommunicera mera och tydligt God planering och systematiskt arbetet med rätt bemanning Levande dokumentation En god förvaltning är basen för en lyckad utveckling

68 Involution i utveckling
Metoder och verktyg är bra att ha men de kan också vara en fälla. Om man tappar fokus på vad man verkligen vill åstadkomma, för vem man producerar något och för vilket ändamål är risken stor att Vi får en organisation där mängder med arbete läggs ner på att ta fram produkter som inte används alls inte är användningsbara används på fel sätt eller inte ajourhålls (och därmed snart är obsoleta) Granskningarna fokuserar på om produkten finns där eller inte och bryr sig inte om hur och om den används. Det finns vidare en risk att en sådan organisation när de upptäcker problemen fokuserar på att öka efterlevnaden (till verktyg och metoder) snarare än förståelsen – och därmed förvärrar problemen. Organisationen vecklar in sig själv i sina metoder och producerar mindre och mindre nytta med mer och mer arbetskraft. Organisationen har blivit verktygens slavar. I det här sammanhanget skulle jag vilja tala om involution. Det är jätteviktigt att man betraktar metoder och verktyg som hjälpmedel och vet vad man använder dem till! I Wiki hittar man olika definitioner beroende på område. Inom filosofin ungefär ”Att man vänder sig in i sig själv”. Inom lantbruk finns en intressant betydelse. Ordet har använts för att beskriva lantbrukets utveckling i Indonesien, där svedjebruk och den specialiserade risodlingen dominerar. Externa ekonomiska krav har jämte det interna trycket från befolkningstillväxten tvingat fram en intensifiering av risodlingen snarare än försök att hitta nya vägar. Mer och mer arbetskraft krävs för risodlingen, vilket – i och för sig – ökar produktionen per kvadratmeter men inte produktionen per capita. Liknande fenomen uppträder i verksamhets- och systemutveckling och jag vill introducera begreppet där!

69 G SOA EA Konklusion Underlättar att hitta Underlättar gemensamma
behov. Underlättar gemensam användning. SOA EA EA ger ett bra stöd till både SOA och till G. Den ger stöd till SOA genom att det blir lättare att hitta de gemensamma funktioner som är lämpliga att skapa som gemensamma tjänster. EA bör också göra det lättare att skilja mellan det som är helt generellt och det som är verksamhetsspecifikt och på så sätt kunna skapa tjänster med optimal granularitet. SOA ger också stöd till G. Det är ju själva grundtanken med SOA att tjänsterna ska kunna användas av vem som helst. Gemensamt är oftast lönsamt. Vi bör vända på det gamla synsättet att ”Min verksamhet är unik” till att utgå från att allting är gemensamt och generellt tills motsatsen kan bevisas. Underlättar skapandet av applikationsarkitekturen.

70 Konklusion - EA Grundtanken med arkitekturen är att beskriva verksamheten med olika modeller sedda ur olika perspektiv. Det nya är att göra det på ett standardiserat sätt för flera olika verksamheter. Spårbarheten inom en modell ökar! Spårbarheten mellan olika perspektiv är bättre! Dagens verktyg är mycket bättre! Den främsta fördelen är att olika verksamheter kan beskrivas på samma sätt och därmed jämföras! Det blir lättare att hitta de perfekta tjänsterna! och Gemensamma lösningar! Spårbarheten mellan verksamhetskraven och det realiserade IT-stödet är en av de viktigaste frågorna för att Få kontroll på utvecklingen (och utvecklingskostnaderna) Minska kostnaderna för underhåll Minska personberoendet i organisationen. Spårbarheten måste underhållas. En flera år gammal begreppsmodell har tappat allt värde (vi kan inte lita på den). En processmodell tappar värde ännu snabbare.

71 Konklusion - SOA Grundtanken med SOA är att isolera en bestämd funktion, isolera det generella i funktionen och publicera ett väldefinierat gränssnitt där det specifika kan anges i form av parametrar. Det är en gammal tanke men nu har teknikutveckling och standardisering gjort det lättare. En gammal svårighet återstår. Att hitta rätt nivå på tjänsterna. Med för hög nivå (många tjänster i ett paket) blir det för få som kan använda dem. Med för låg nivå (specialiserade IT-nära tjänster) blir det för mycket arbete att sätta ihop dem till en fungerande helhet. Det är inte tekniken som är det centrala i SOA. Det är att hitta gemensamma behov och att kunna skilja det generella från det specifika för att kunna bygga så bra tjänster som möjligt.

72 Konklusion - . Skatteverket ansvarar för:
Inkomstskatt (4 typer) Kontrolluppgifter Företagsregistrering Moms (inkl spec. EU-system) Arbetsgivaravgifter Punktskatter och avgifter (ca 35 st) Fastighetstaxering Skattekonto Folkbokföring (ca 100 ärendetyper) Kassaregister EKO-brott Internationellt ID-kort E Legitimationer Bouppteckningar Klart att vi är intresserade av Gemensamma lösningar! Det är G vi egentligen vill ha, helst av allt!

73 Paradigmskifte Vi lever just nu i ett samhälleligt paradigmskifte. Förmodligen någonstans mellan kris och fastställande av nytt paradigm! Genomgripande förändringar sker överallt och fort. Flexibilitet, ständigt lärande och kreativitet är nödvändigt. En följd av paradigmskiftet är att ni just nu utbildas till yrken som ännu inte finns!