Det finns kopplingar mellan Enterprise Architecture EA och

• 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.

• • • 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.

• Som ni ser har jag fått pussla ordentligt med schemat för att få plats med allting.

• 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.

• • • 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, ” said Philip Allega, research vice president at Gartner. EA is the bridge to integrate business and IT “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. http: //www. enterprise-architecture. info/)

• 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)

• • 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?

• 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.

• 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.

• • • 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.

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

• • • Autocoder was the name given to certain assemblers for a number of IBM computers of the 1950 s and 1960 s. 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 memory needed to use Autocoder. (Wiki)

• • • 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 8 4 2 1 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 001 -080. Index registers 1, 2 and 3 were in memory locations 087 -089, 092 -094 and 097 -099 respectively. Punch a card punched the contents of memory locations 101 -180 into a card. Write a line printed the contents of memory locations 201 -332. (Wiki)

• • • 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 1981. (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.

• • • 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 2 - 4 §§. 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

• 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 - 9 §§. 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).

• 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 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 50 000 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 50 000 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 50 000 kronor ska samtliga byggnader inom tomten utgöra en värderingsenhet. Lag (2009: 105). • • •

• • 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.

• • 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. – – – Storleken bestäms med hänsyn till ytan av småhusets boutrymmen och biutrymmen. Å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. Standarden bestäms med hänsyn till småhusets byggnadsmaterial och utrustning. För ett nybyggt småhus skall finnas minst femton standardklasser. Byggnadskategorin bestäms med hänsyn till om småhuset utgör friliggande småhus, kedjehus eller radhus. 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.

• • • 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ö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 1 000 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 50 000 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.

• • 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.

• • ”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 fipotek 73 på den tiden, alltså en fil-post-termkatalog 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. divaportal. org/smash/get/diva 2: 126928/FULLTEXT 01 ) 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.

• • 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)

• 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 för effektiv styrning IT-strategi personalstrategi organisationsstrategi. (ur slutrapporten)

• 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)

• 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)

• • 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.

• 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.

• • • 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 1813 -1855

• Detta avsnitt behandlar utvecklingen från 1998 tills nu med fokus på gemensamma lösningar.

• • 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.

• • • 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 - http: //www. openshs. se/ (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”

• • Från början ett samarbete mellan Försäkringskassan och Skatteverket under namnet e. Dok 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 sammansatta dokument av typen bilagor till och bilagor till bilagor etc. • Skatteverket hade bråttom och gick sin egen väg under namnet g. Dok

• • • 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)”

• • • 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.

• De grundläggande orsakerna har identifierats. Vilket gör att vi kan börja med arbetet att förebygga dem. Orsakerna är: – – – 1 a Bristande styrning 1 b Bristande förståelse 2 Inte bra nog 3 Hålls inte ajour 4 Överlämning till IT funkar ej 5 Förvaltas ej

• 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

• Här skildras tiden från 2008 med fokus på arbetet som föregick målarkitekturen och arbetet med att etablera en arkitekturstyrning.

• 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.

• De 5 andra var: – Samordna insatser som relaterar till e. Fö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.

§ 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

§ § § 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 Iskiktet (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.

• 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 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.

• 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.

• • 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.

• 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 (PM 3) 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.

• • • Verk. A ä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. Verk. A 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 Verk. A inte är överens med den verksamhetsansvarige. Liksom byggnadsnämnden prövar inte Verk. A enbart inkomna bygglovsansökningar utan spelar framför allt rollen av bollplank i planeringsarbetet.

• 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 e. Tjänster.

• • • 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å 1950 - 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.

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

• 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

• 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 ITutveckling.

– 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)

• • 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.

§ 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.

• 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.

• 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.

• 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.

• Då ska vi försöka att knyta ihop säcken!

• 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?

• 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

• 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!

• • 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.

• 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.

• 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.

• Det är G vi egentligen vill ha, helst av allt!

• • • När jag började med data fanns det bara 3 yrken på dataavdelningen: programmerare, driftspersonal och hålkortsoperatriser. Nu har jag identifierat följande 38 yrken på vår IT-avdelning (från deras senaste prislista) Användbarhetsdesigner CM/Systemintegratör DBA Designer Programmerare/Implementatör Projektledare Produktionsledare Projektledare (IS) Produktionsledare (ITS) • • • • • Systemanalytiker Testingenjör Verksamhetsanalytiker Verktygsspecialist Koncernarkitekt Lösningsarkitekt IT-arkivarie Metodstöd/Processingenjör Applikationsdriftkonsult Infrastrukturarkitekt IT-säkerhetskonsult Processledare Systemadministratör Tekniker Operativ inköpare Strategisk inköpare Upphandlingsjurist Webbutvecklare Produktionsledare • Säkerhetsrådgivare • Säkerhetshandläggare • • Projektledare (ITS) Materiell specialist (AS) Systemsakkunnig (AS) Verksamhetssakkunnig (AS) Systemförvaltare administrativa system Materiell specialist (ITS) Systemsakkunnig (ITS) Verksamhetssakkunnig (ITS) • •