Transcript Målbild informationsarkitektur

• 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
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
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 097099 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 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 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.
–
–
–
–
–
–
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.
•
•
•
•
•
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 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 fipotek73 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/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.
•
•
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
strategi 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 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
•
•
•
•
•
•
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:
–
–
–
–
–
–
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
•
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 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.
 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 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 (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.
•
•
•
•
•
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.
• 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.
•
•
•
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 1900talet.
• 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:
•
•
•
•
–
Målbild informationsarkitektur:
•
•
•
•
–
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
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, 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)
•
•
•
•