Transcript Projektarbete - SWEAN - Svensk EA i praktiken

EA – SOA - G
G
SOA
EA
Per ”Pelle” Nilsson

Akademiska meriter


Erfarenheter 60 -
Började 1:a 1960
Fastighetstaxering
Programmering
Per ”Pelle” Nilsson

Akademiska meriter

Har ännu inte
avslutat den 3betygsuppsats i
historia som jag
påbörjade 1977.

Erfarenheter 70 Utveckling
Fastighetstaxering
Programmering
Histor.
Per ”Pelle” Nilsson

Akademiska meriter

Har ännu inte
avslutat den 3betygsuppsats i
historia som jag
påbörjade 1977.

Erfarenheter 80 Utveckling
Fastighetstaxering
Programmering
Histor.
Per ”Pelle” Nilsson

Akademiska meriter


Erfarenheter 90 -
Har ännu inte
avslutat den 3betygsuppsats i
historia som jag
påbörjade 1977.
Utveckling
Modellering
Fastighetstaxering
Programmering
Histor.
ICR + tolkning
Per ”Pelle” Nilsson

Akademiska meriter


Har ännu inte
avslutat den 3betygsuppsats i
historia som jag
påbörjade 1977.
Detta kanske kan
bli början på en ny
3-betygsuppsats?

Erfarenheter 2000Utveckling
Arkitektur
Modellering
Fastighetstaxering
Programmering
Histor.
ICR + tolkning
Perspektiv


Mina akademiska meriter väger lätt!!!
Jag kommer att fokusera mina praktiska erfarenheter

Jag har jobbat 6 decennier med utveckling! Under 60-, 70-,
80-, 90-, 00- och 10-talet.!


Prövat ett otal metoder och verktyg


(Första jobbet som 9-åring, programmerare vid 15, egna
utredningar från 17 års ålder och första lärarjobbet vid 20 - 21.)
Teori
(T.ex. PPS, Pejl, RUP/KUR, UML, TOGAF, GEAF, EIF, VUprocessen, Lots, KTT, Rose, QLM, Peng, Astrakans
modelleringsmetoder, Koll, Målmodellering, Stanly, JSP, PM3,
Scrum, Skruv-OO, etc.)
Praktik
Välkommen till den grymma
verkligheten.
Agenda
0800 - 0810
0810 – 0815
0815 - 0900
0900 - 0850
0850 – 1000
Akademisk kvart
Inledning. EA, SOA och G.
Inget är nytt under solen
Gryning på Skatteverket
Fika
Solen går upp
Målarkitektur
Avslutning. Revolution,
evolution, involution och
paradigmskifte.
EA – SOA - G
G
SOA
EA
EA





Enterprise Architecture = EA
På svenska Verksamhetsarkitektur?
Konceptet:
Beskrivningar av en verksamhet ur flera
olika perspektiv!
Skatteverkets EA har 4 skikt = perspektiv.




Verksamhet (Processer) = V-skikt
Information = I-skikt
Applikation = A-skikt
Teknik = T-skikt
SOA
Service Oriented Architecture = SOA
 Konceptet:
 Paketerade funktioner med väl
beskrivet gränssnitt (indata och
utdata).
 Kan vara parameterstyrd.

G – GM, GVM, GL, GVL
G
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.

Inget är nytt under solen
Tidigt A-skikt
EA
Tidig funktion
SOA
Tidigt G
G
Skogshögskolan pionjärer?
Förutsättningar
 Dator = IBM 1401. CPU = 12 K. (Senare
uppgraderad till 16 K.)
 Maskinnära programmeringsspråk
(Autocorder)
 Brist på programmerare => kö till dessa
 Långa bearbetningstider => kö till datorn

Skogshögskolan pionjärer?
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.
SOA
En lag som EA - 79?
1 Kap.
Sammanhanget
Här ges
sammanhanget i
stort!
2 - 15 Kap.
Kärnprocessen
2 Kap.
Beskriver en
strängt reglerad
process.
Indelning byggnad
och mark
Första steget i
processen beskrivs i
detta kapitel.
Fastighetstaxeringslagen
EA
V-skiktet klart. Nu till I-skiktet.
1 Kap.
Sammanhanget
2 - 15 Kap.
Kärnprocessen
2 Kap.
Indelning byggnad
och mark
4 Kap.
3 Kap.
Indelning i
taxeringsenheter
Skatteplikt
Attribut
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)
Info.objekt
Här skapar vi
taxeringsenheter!
Taxeringsenheter
EA
Mera I-skikt.
1 Kap.
Sammanhanget
Allmänna regler om
värdering och om hur
delvärden till
taxeringsenheten skapas
2 - 15 Kap.
Kärnprocessen
2 Kap.
Indelning byggnad
och mark
4 Kap.
3 Kap.
Skatteplikt
Attribut
5 Kap.
Indelning i
taxeringsenheter
Info.objekt
Taxeringsenheter
Info.objekt
Allmänt om värde
6 Kap.
Indelning i
värderingsenheter
7 Kap.
Värderingsenheter.
Attribut
Här skapar vi
värderingsenheter
Allmänna
värderingsregler
Värderingsregler
Attribut
EA
Här börjar vi också titta på A-skiktet.
1 Kap.
Sammanhanget
Här lägger vi också fast
den övergripande nivån i
applikationsarkitekturen
2 - 15 Kap.
Kärnprocessen
2 Kap.
Indelning byggnad
och mark
4 Kap.
3 Kap.
Skatteplikt
Attribut
5 Kap.
Indelning i
taxeringsenheter
Info.objekt
Taxeringsenheter
Info.objekt
Allmänt om värde
6 Kap.
Indelning i
värderingsenheter
7 Kap.
Värderingsenheter.
Attribut
Värderingsregler
Attribut
A-skikt
EA
Ökad detaljering.
1 Kap.
Sammanhanget
Här beskrivs i detalj vilka
faktorer som ska
bestämma värdet. 1 kap
per typ av taxeringsenhet.
2 - 15 Kap.
Kärnprocessen
2 Kap.
Indelning byggnad
och mark
4 Kap.
3 Kap.
Indelning i
taxeringsenheter
Skatteplikt
Attribut
Info.objekt
Taxeringsenheter
Info.objekt
8 - 15 Kap.
Allmänt om värde
Värdefaktorer
6 Kap.
Indelning i
värderingsenheter
7 Kap.
Värderingsenheter.
Attribut
5 Kap.
Värderingsregler
Attribut
Attribut
A-skikt
EA
Omvärlden.
1 Kap.
Här beskrivs lite omkring
Sammanhanget
kärnprocessen.
Deklarationen mm och vad
2 -hända
15 Kap.
som kan
efter
Kärnprocessen
taxeringen
2 Kap.
Indelning byggnad
och mark
4 Kap.
3 Kap.
Indelning i
taxeringsenheter
Skatteplikt
Attribut
16 - 24 Kap.
Före o efter
Info.objekt
Taxeringsenheter
Info.objekt
8 - 15 Kap.
Allmänt om värde
Värdefaktorer
6 Kap.
Indelning i
värderingsenheter
7 Kap.
Värderingsenheter.
Attribut
5 Kap.
Värderingsregler
Attribut
Attribut
A-skikt
EA
Specifikation av A-skiktet.
2 Kap.
Indelning byggnad
och mark
1 Kap.
A-skiktet specificeras
Sammanhanget
slutligen i regeringen
förordning (FTF) och i
2 - 15 föreskrifter
Kap.
Skatteverkets
Kärnprocessen
(RSV:FS).
Där ges detaljerade regler
för tabellernas uppbyggnad
4 Kap.
3 Kap.
Indelning i
och andra värderingsregler.
Skatteplikt
FTF +RSV:FS
16 - 24 Kap.
Före o efter
taxeringsenheter
Attribut
Info.objekt
Taxeringsenheter
Info.objekt
8 - 15 Kap.
Allmänt om värde
Värdefaktorer
6 Kap.
Indelning i
värderingsenheter
7 Kap.
Värderingsenheter.
Attribut
5 Kap.
Värderingsregler
Attribut
Attribut
A-skikt
EA
FIPOTEK och subbor -82.


Riksskatteverkets tekniska avdelning 1982
FIPOTEK stod för fil-, post- och termkatalog




EA
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.
SOA
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.
EA
V-skikt. Processmodeller.

Processmodell - Översikt
Skatteförvaltningens verksamhetsprocesser
Strategisk styrning
Taktisk styrning
Operativ styrning
Beskattning
Indatahantering
Ärendehandläggning
Utdatahantering
Fastighetstaxering
Folkbokföring
Verksamhetsnära stöd
Gemensamt stöd
EA
I-skikt. Begreppsmodeller.

Begreppsmodeller
Begreppsmodell för planering och
styrning av resurser
Begreppsmodell för planering och
styrning av ärendefördelning
KOMPETENS
ANSTÄLLD
- profil
besitter
ANSVARIG
FÖRDELNINGS
GRUNDER
- handläggare
- kompetens
BEMANNINGSPLAN
BEHÖRIGHETS- INF
ORMATION
har
tilldelats
kan vara
- klasser
- koder
- kategori
- signaltyp
- geografisk
indelning
ingår
i
innehåller
innehåller
underlag
för
RESURSER
ANSVARSMATRIS
fördelas
via
ÄRENDE
ARBETSLÄGE
framgår
av
ÄRENDEPLAN
BEMANNINGSPLAN
- behandlingsregler
knyts till
- för omfördelning
definieras
i
ORGANISATORISK
INDELNING
beskriver
påverkar
FÖRDELARE
ÄRENDEPLAN
- sektion
- grupp
- projekt
- förväntat
- aktuellt
upprättar
tar initialt
hänsyn till
RESURSLÄGE
- behandlingsregler
består
av
är grund för
ÄRENDEVOLYM
INKORGAR
UPPDRAG
LAGSTIFTNING
VERKSAMHETSINSTRUKTIONER
- postkorg
- ärendekorg
- urvalskorg
framgår
av
EA
Detaljering.

Processmodell - Detaljer
10. Fånga massinformation
Administrativt
inkommen
verksamhetsinformation
Elektroniska
bilder
10.1
Konvertera
Bildarkiv
De elektroniska bilderna
hanteras vidare i process 12.
Rådata
Rådata lager
Hanteringsinformation
Rådatat hanteras vidare i process 12.
Produkter
från process 9.
Arkiverings-/
övervakningsinformation
Gemensamt stöd
Det inkomna materialet
skickas för arkivering.
- Arkivhanteringssystem
- Diarieföringssystem
- Övervakningssystem
EA
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.
EA
Pesten slår till 1 – Unix.
På 80-talet drabbades Skatteverket – liksom många
andra – av ett allvarligt bakslag för förvaltningen: Unix!
 Unix och liknande operativsystem erbjöd nya
möjligheter. Relationsdatabaser, direktåtkomst till
data, kraftigare språk mm.
 Vi började använda dessa. Först folkbokföring och
fastighetstaxering men sedan alla andra.
 Unix sas vara självdokumenterande!
 Men var inte det.
 Första problemen var med driftdokumentationen.
 Beställarnas arbete med process- och
informationsmodeller försämrades.
 FIPOTEKET började förfalla.

Pesten slår till 2 – RUP.







På 00-talet drabbades Skatteverket – liksom många
andra – av ett andra allvarligt bakslag för
förvaltningen: RUP!
RUP och liknande styrverktyg erbjöd nya möjligheter
att standardisera och rationalisera IT-utvecklingen.
Vi började använda dessa.
RUP styrde upp IT-utvecklingen och gav en del goda
hjälpmedel och mallar. De snabba iterationerna var till
stor hjälp.
Men RUP/KUR stödde IT-utveckling. Inte
verksamhetsutveckling.
Och RUP/KUR nonchalerade
informationsarkitekturen.
I-skiktet har misshandlats sedan millennieskiftet.
Gryning på Skatteverket för G
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. G

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 SHSavtalen i form av produkter som drivs i den egna
tekniska miljön,
Kan också beställas som tjänst inom området
Infratjänst.
SHS För mer info http://www.openshs.se/
G
eDok => gDok => ?





gDok är i XML-format.
gDok har varit i drift ett tiotal år och fungerar utmärkt.
Försäkringskassan har uttryckt önskemål om att gå
(tillbaka) till gDok-tankarna
Det skulle vara önskvärt om gDok blev en standard.
SHS är den stora distributören som levererar paket
mellan organisationer. gDok innehåller adresserna på
de brev som ryms i paketen och ser till att de hamnar
rätt i organisationen.
G
GÄHS (Generellt ÄrendeHanteringsSystem)






GHÄS startades som en fortsättning på AKTIV och In- och Utdata.
Målet. Ta fram en generell maskinell ärendehantering tillsammans med
nyttjandeprojekt.
Tidspressen var hård på GÄHS.
Bemanningen var skev - ett dussintal människor arbetade med den
generella. Mångdubbelt flera arbetade i nyttjandeprojekten.
Förankring saknades på verksamhetssidan och produkterna blev
svårsålda.
GÄHS lyckades dock leverera generella tjänster i form av
 Processtjänst (Föra ärendet framåt längs den maskinella processen)
 Akt- och ärendetjänst (Hålla reda på ärendets status och hålla en
journal i ärendet)

Dokumenttjänst (Lagra dokumenten och kunna visa dem kopplat till
ärendet)

Bemannings- och fördelningstjänst (Kunna skapa en ”virtuell”
organisation för ärendehanteringen. Sätta upp regler för fördelning av
ärenden och kunna fördela ärenden efter dessa regler)
G
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 Verksamhetsoch Informationsplattform (VIP)
SOA
G
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)
SOA
G
Solen går upp vid Skatteverket
Den IT-strategiska planen 1





Skatteverket har alltid legat i framkant när det gäller
IT-utveckling och bemötande.
Det har till stor del berott på att vi haft ganska
generösa IT-anslag.
När anslagen på allvar började att strypas (2008) så
ökade kostnadsmedvetandet.
Vi hade bl.a. mycket höga kostnader för underhåll av
gamla system och vi hade i stort sett inte avvecklat
några system. Bara byggt nya som också skulle
underhållas!
Arbetet med en IT-strategisk plan inleddes (2008 –
2009).
Den IT-strategiska planen 2

Det konstaterades tyvärr också att vi kommer att drunkna och självdö i
ökade förvaltningskostnader!

Sex utvecklingsområden identifierades varav 4 direkt relaterade till ITstödet: Ett av dem var:

Stärka verksamhetsarkitekturen och en skapa en modern, flexibel och
kontrollerad IT-arkitektur som främjar återanvändning och
kostnadseffektivitet
Målarkitektur - Syfte

Målarkitekturen utvecklades 2009.

Målarkitekturens starka fokus på samverkan och förbättrad
kundservice ger Skatteverket möjlighet att:





Ta en aktiv roll i att utveckla myndighetsövergripande samverkan
Erbjuda ett effektivt standardiserat informationsutbyte med olika
intressenter
Utveckla verksamheten och erbjudanden utifrån tydliga kundbehov
Öka förtroendet för Skatteverket genom en utvecklad kundservice
Målarkitekturen utgår ifrån ett gemensamt arbetssätt, vilket
skapar förutsättningar för att:



Driva en harmonisering och effektivisering av verksamheten
Konsolidera och standardisera det underliggande IT-stödet
På sikt få ett mer flexibelt IT-stöd, en snabbare IT-utveckling och en
rimlig kostnad för IT
EA
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.
Chefsarkitekt – Skatteverkets koncernarkitektur
Arkitekturledning
V
I
A
T
VerkA
Huvudarkitekt –
verksamhetsarkitektur
Huvudarkitekt –
teknisk arkitektur
Arkitekturforum
EA
Analogier med byggsektorn
Planer
Byggbranschen
Verksamhetsarkitektur
Kommentar
Regionplan e.dyl
Saknas
oftast.
En tydlig beskrivning av vår plats på medborgarens och
företagarens verklighetskarta.
Den stora helhetsbilden!
Översiktsplan
Målarkitekturen
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
(byggblock)
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- Byggblock
plan
Mer detaljerade regler för enskilda byggen för att de ska passa in i
kvartersmiljön.
Ritningar
Byggbranschen
Verksamhetsarkitektur
Kommentar
Byggnadsritningar i.e.
plan- och
fasadritningar
Processbeskrivningar,
modeller i Iskiktet, funktioner i Askiktet
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
utvecklingsarbetet.
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.
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.
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.
Regler
Byggbranschen
Verksamhetsarkitektur
Kommentar
PBL (Plan- och Bygglagen)
Övergripande regler och
riktlinjer för förvaltning och
utveckling. T.ex. VUprocessen, 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.
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 standardkomponenter?
Försök att platsbygga ett kök
med enbart användande av
lösvirke i olika dimensioner.
Ålder > 5.000 år
Ålder 50 – 60 år.
Kan kanske förklara att vi inte
kommit längre i
standardiseringsarbetet för
verksamhets- och ITutveckling.
Bermudatriangeln. Vad är det?
Chefsarkitekt – Skatteverkets koncernarkitektur
Arkitekturledning
V
I
A
T
Är lokaliserad
till detta
område i
arkitekturen!
VerkA
Huvudarkitekt –
verksamhetsarkitektur
Huvudarkitekt –
teknisk arkitektur
Arkitekturforum
Allt som produceras
här försvinner
spårlöst!
Vad är det
för positivt
med det?
Målarkitektur
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
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.
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
Verksamhetsarkitekturen
M ål b i l d f ö r v er k sam h et sar k i t ek t u r
Privatperson
Företag
Myndighet
Uppdragsgivare
Tillhandahåll kanaler för interaktion
E-kanal
Telefon
Lagstiftare
Tillgängliggör standardiserad information
Fysiskt möte
Info-tjänster till
extern part
Papper
Info-tjänster
från extern part
Hantera
verksamhetsregler
Paketera tjänster
mot kund
Hantera
kundrelation
Interagera med
lagstiftaren
Hantera sammanhållet kundärendeflöde
Urval
Fördelning
Info-tjänster för
internt bruk
Interagera med
omvärlden
Hantera kundärenden
Mottagning
Media
Beslut/
verkställande
Åtgärd
Leverans
Extern
kommunikation
Riskhantering, segmentering, uppföljning och analys
Riskhantering
Segmentering
Gemensamma
mätetal
Analys
Ledning och styrning
Ledning,
uppföljning
Rättslig styrning
Stöd
Verksamhetsutveckling
IT
Personal
Ekonomi
Informationsarkitekturen
Informationsområde Tillhandahåll kanaler för interaktion
(Innehåller inga egna centrala informationsmängder)
Informationsområde Tillgängliggör standardiserad
information
Standardiserad
information
Informationsområde Hantera kundärenden
Informationsområde Interagera
med omvärlden
Gemensam information för Kundärenden
Gemensam information för Beskattning
Info för
Beskattning
Info för Fastighetstaxering
Info för
Brottsbekämpning
Info för Folkbokföring
Info för Bouppteckning
Info för
Interaktion
Info för ID-kort
Informationsområde Analys
Info för Analys
Informationsområde Ledning och
styrning
Informationsområde Rättslig
styrning
Info för Ledning och styrning
Info för Rättslig styrning
Informationsområde Adm. stöd
Info för
Ekonomi
Info för
Organisation
Info för
Personal
Info för Utv.
och förv.
Info för
Övrig admin.
Centrala informationsmängder
Kundprofil
kan ha
relation till
kan ha
relation till
Personakt
har
har
Person
styr
hantering av
Ärende
läser och
uppdaterar
Ärendeakt
kan lämna
beskrivs av
…för
skattskyldighet
…för skatt
Beslut
…för t.ex. frågor
och besök
…om
skattskyldighet
…om
skatt
Journal
…för
fastighetstaxering
…för
folkbokföring
Verksamhetsspecifik
information
kan resultera i
Underlag
beskrivs
av
Verksamhetsregel
…om
fastighetstaxering
…om
folkbokföring
kan
resultera i
Ekonomisk
transaktion
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

Extern och intern användning
Ansvarsområde
V-skiktet
a
I-skiktet
c
A-skiktet
Tillgängliggöra
standardiserad
information
b
a
c
b
14. Observera att
tjänster och andra
kataloger som
”Tillgängliggöra
standardiserad information”
ansvarar för även
används internt, t.ex.
i byggblocket
”Leverera”
och således ligger till
grund även för t.ex.
utskrifter.
Avtal
Begreppsmodell
Informationsmodell
Datamodell
Utbytesformat
Databas
BEGREPP
Begrepp
XML
XML
CRUD
Tjänster
Byggblock
Leverera
Avslutning
Revolution
 Evolution
 Involution
 Konklusion

@Paradigmskifte
Revolution

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
verksamhetsutvecklarna
har ännu inte
börjat på dagis.
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
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!
Konklusion
G
Underlättar
att hitta
gemensamma
behov.
Underlättar
gemensam
användning.
SOA
EA
Underlättar skapandet
av applikationsarkitekturen.
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!
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.
Konklusion 
Skatteverket ansvarar för:
















G.
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!
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!