2 Konceptuell lösningsarkitektur

Klicka här för att förstora bild "Konceptuell skiss"

2.1 Konsument och producentförmågor

2.1.1 Hämta kundhändelser

Kundhändelser finns lagrade i infrastrukturen hos producenten men de gör ingen nytta där innan de hämtas till en tjänst hos en konsument och visas för en användare.

På kort sikt behöver tjänster kunna hämta kundhändelser för en viss kund. I ett första steg kan man tänka sig att lämna ut alla kundhändelser för en viss kund och låta tjänsten sortera vilka som har betydelse i det aktuella fallet. Senare kan man tänka sig att förfina urvalskriterierna så att en större del av urvalsanvaret läggs i frågan till producenten.

På längre sikt kan det addera funktionalitet för att visa hur olika kundhändelser hänger ihop med varandra, t.ex. kronologi eller hur de hänger ihop i ett visst ärende. Till en början kanske infrastrukturen endast tillhandahåller den senaste händelsen i ett visst urval, detta kan på längre sikt kompletteras med historik så att en hel händelsekedja hämtas.

Detta är den basala processen inom Mina ärenden. Allt värde kring att kunder får överblick och får samlad ärendeåterkoppling realiseras genom att kundhändelserna hämtas från producenter till konsumenter. Dock behövs naturligtvis ett antal andra processer för att få detta att fungera.

2.1.2 Skapa kundhändelser

Kundhändelser skapas i olika verksamhetssystem hos olika producenter. Dessa kundhändelser skall sedan exponeras till infrastrukturen inom Mina ärenden. Kundhändelser behöver utformas så att de fungerar lika bra oavsett om användarna tar del av de hos Mina sidor som hos en extern konsument.

För kundhändelser kopplade till producentprocesser som finns hos flera producenter, t.ex. kommuner, är det önskvärt med en omfattande och kontinuerlig ensning. När kundhändelser som rör samma producentprocesser ensas blir igenkänningen högre hos användare med ökad trygghet som följd. Detta bör primärt uppnås genom samordning mellan producenter i de forum som etableras inom ramen för Mina ärenden. Vidare behövs en samsyn kring livscykler för kundhändelser och ett enhetligt språk för att säkerställa att kundhändelser fungerar när de exponeras för en användare tillsammans med kundhändelser från flera producenter.

2.1.3 Avisera kundhändelser

När förmågan att skapa kundhändelser finns på plats hos en producent kan det finnas behov av att avisera att något har hänt i ett ärende. Det skulle kunna handla om att ett beslut är fattat i ett ärende eller att kunden behöver agera på något så som att ett tillstånd är på väg att gå ut.

Det kan även finnas andra behov av att avisera, t.ex. kundhändelser av servicekaraktär. Detta är sådan som ger värde till kunden men inte tvunget måste kommuniceras t.ex. ”Ditt ID-kort löper ut om 6 månader” eller en påminnelse om att en deklarationsperiod har öppnat.

Aviseringen kan skickas ostrukturerat i Digital post eller papperspost men de kan också skickas via nya kanaler som etableras inom Mina ärenden. Genom att använda de nya kanalerna kan producenter påbörja processer hos sig som skapar värde för kunden, t.ex. sätta samman deklarationsunderlag för en deklarationsperiod som just öppnat.

2.1.4 Koppla kundhändelser

När en tjänst hämtat kundhändelser och vill visa dessa för en användare kan det framöver behövas en möjlighet att koppla ihop olika kundhändelser med varandra. Kopplingarna har oftast att göra med att kundhändelserna hör till samma kundärende/livssituation. Kopplingarna kan ske på kundhändelser genererade hos en producent (t.ex. olika steg i ett skatteärende hos Skatteverket) men kan också ske med flera producenter inblandade (t.ex. starta företag där Bolagsverket, Skatteverket och eventuellt andra producenter är inblandade).

Kortsiktigt kan ett kundämne användas för att knyta ihop kundhändelser. Om händelserna spänner över flera producenter behöver producenterna komma överens om ämnesdefinition.

På längre sikt kan man tänka sig en lösning där en händelsekedja, eller producentprocess är allmänt känd inom ett kundämne. I så fall kan konsumenter placera in händelser i producentprocessen och på så sätt hjälpa kunden att förstå vad nästa steg är och vem som har bollen att få processen att fortskrida. Det kan behövas tekniska och eventuellt centraliserade lösningar för att nå en gemensam förståelse av producentprocesserna.

2.2 Centraliserade förmågor inom Mina ärenden

För att Mina ärenden ska kunna tjäna som en nationell standard för utbyte av kundhändelser behöver man på sikt ta fram några centraliserade förmågor som bidrar med effektivitet, skalbarhet och tillgänglighet.

Lösningen inom Mina ärenden avser inte på något sätt centralisera information om enskilda ärenden eller för den delen metadata om ärenden. Däremot finns ett behov att på sikt centralisera överordnad funktionalitet inom Mina ärenden. Det kan t.ex. handla om ett standardiserat sätt för anslutning av både producenter och konsumenter eller någon form av indexering som visar till vilken producent man kan ställa en fråga om specifika kundhändelser.

Ett sätt att visualisera vad dessa centrala komponenter innehåller i förhållande till ett enskilt ärende hos en producent finns nedan.

Klicka här för att förstora bilden "Nivåer av möjliga informationssamlingar"

2.2.1 Centraliserad anslutning (Tjänstekatalog)

I takt med att fler producenter ansluter till Mina ärenden ökar den potentiella nyttan och förutsättningarna för konsumenterna att skapa mer sammanhålla och heltäckande tjänster. En viktig aspekt för att Mina ärenden ska bli hela Sveriges lösning för ärendeåterkoppling är att det är enkelt att ansluta sig till infrastrukturen som producent och konsument.

Med att vara ”ansluten” avses i detta sammanhang att en konsument eller producent har förbundit sig att hämta eller lämna ut kundhändelser i enlighet med det regelverk som tas fram inom Mina ärenden. För att detta ska fungera i praktiken måste lösningen som tas fram inom Mina ärenden vara skalbar ur ett rättsligt och tekniskt perspektiv.

Rättslig skalbarhet tar sikte på primärt två aspekter. Dels att själva förutsättningarna för att använda Mina ärenden vilar på grunder som går att tillämpa hos alla anslutna aktörer och inte på särskilda förutsättningar som gäller hos en enskild producent. Dels att en aktör kan ansluta nya aktörer till Mina ärenden och genom detta skapa de förutsättningar som krävs för att kundhändelser ska kunna lämnas ut av/hämtas av den nya producenten/konsumenten. Anslutna konsumenter och producenter överlåter således till en aktör, förslagsvis byggblocksansvarig, att teckna avtal med de konsumenter och producenter som är intresserade och uppfyller kraven för att ansluta till Mina ärenden. Detta avtal ska därefter kunna tillämpas mellan alla anslutna parter och reglera rättigheter och skyldigheter som följer av en anslutning till Mina ärenden. En sådan lösning finns redan idag inom t.ex. Digital post där Digg i egenskap av infrastrukturansvarig kan teckna anslutningsavtal med nya avsändare/brevlådeoperatörer genom fullmakt från de aktörer som redan är anslutna.

Teknisk skalbarhet krävs när nya konsumenter och producenter ansluts. Det måste kunna ske smidigt utan att redan anslutna måste vidta en åtgärd för att den nya konsumenten eller producenten ska få tillgång till Mina ärenden. Även här kan exempel hämtas från Digital post där aktörer som ansluter löpande förs in i ett centralt register - förmedlingsadressregistret (FaR). När en aktör finns inlagd i FaR är den också betrodd att kunna agera inom ramen för sin roll gentemot andra anslutna aktörer.

Ett centraliserat anslutningsförfarande är på sikt en viktig förmåga för att införandet av Mina ärenden ska bli framgångsrikt. Ett centraliserat anslutningsförfarande möjliggör också för att skapa låga trösklar för anslutning eftersom en enda aktör har ansvaret för att löpande utveckla anslutningsprocessen. Behovet av ett centraliserat anslutningsförfarande ökar i takt med att fler aktörer ansluter.

På kort sikt bör det dock vara tillräckligt med ett decentraliserat anslutningsförfarande. Så länge antalet aktörer är litet är merkostnaden för att sinsemellan reglera relationer och teknik relativt små. I detta decentraliserade anslutningsförfarande skulle Mina ärenden kunna tillhandahålla avtalsmallar med tillhörande villkor för att sänka merkostnaden.

2.2.2 Tillhandahålla katalog över kundhändelsetyper och producentprocesser

En realistisk förväntan vid ett införande av Mina ärenden är att några få aktörer som ser stor nytta och har resurser för ett tillämpa en lösning under utveckling ansluter tidigt. I ett senare skede när lösningen blir mer mogen och anslutna aktörer kan visa på faktisk nytta så kommer fler aktörer att vara intresserade. Utöver att nya aktörer successivt ansluter till Mina ärenden så kommer även redan anslutna aktörer att löpande utveckla sin förmåga att skapa eller konsumera kundhändelser. Ovanstående innebär att det kommer vara svårt att få insyn och en överblick över vilka aktörer och vilka kundhändelser som är tillgängliga vid ett givet ögonblick.

Om transparensen är låg eller obefintlig kring tillgängliga kundhändelser försvårar det för intresserade konsumenter som har att bedöma huruvida de ska investera och ansluta till Mina ärenden. Detta eftersom det är svårt att förstå om det finns förutsättningar att kunna leverera lösningar som efterfrågas av deras kunder.

Av detta skäl bör den lösning som tas fram inom Mina ärenden innefatta en ”kundhändelsetypskatalog”. Med detta avses en centralt strukturerad datasamling som håller samtliga kundhändelsetyper som anslutna producenter för tillfället kan lämna ut. Med katalogen kan en konsument t.ex. ta del av att Skatteverket som producent i dagsläget kan lämna ut kundhändelser på momsområdet men inte inom folkbokföringsområdet.

En annan aspekt av kundhändelsetypskatalogen är att det skapar förutsättningar för en mer precis hämtning av relevanta kundhändelser. När konsumenten kan ta del av vilka kundhändelser som potentiellt kan hämtas hos en producent kan den vid hämtning av kundhändelser utforma frågan till att endast omfatta de kundhändelser som specifikt efterfrågas av användaren. När ”frågan” till producenten blir mer precis krävs också mindre filtrering och urval av kundhändelser innan dessa presenteras för användaren. Förmågan att hämta kundhändelser med ökad precision är önskvärd eftersom det innebär att mindre ”oönskad” information utlämnas från producenten och underlättar för konsumenten att ta fram tjänster som endast innehåller relevanta och efterfrågade kundhändelser.

Kundhändelsetypskatalogen skulle med fördel även kunna innehålla varje ansluten producents producentprocesser och hur respektive kundhändelsetyp förhåller sig till denna. När detta är tillgängligt kan en konsument förstå hur kundhändelsetyper ska förstås sekventiellt och i sin tjänst visualisera det för användaren vid behov. Vidare ges konsumenterna möjlighet att börja binda samman och förstå mer komplexa samband hos producentprocesser inom och mellan olika producenter. På så sätt kan konsumenter stödja sina kunder och ge en samlad ärendeåterkoppling som tar sin utgångspunkt i t.ex. en kundsituation eller kundbehov snarare än efter varje enskild producent och deras respektive ”stuprör”.

På kort sikt med få anslutna aktörer skulle en kundhändelsetypskatalog kunna göras tillgängligt i ett mer ostrukturerat och manuellt förvaltat format, t.ex. publiceras på byggblocksansvarigs webbplats. I takt med att fler aktörer ansluter och fler typer av kundhändelser görs tillgängliga måste lösningen bli mer strukturerad och automatiserad, t.ex. genom en databas som kan nås via publikt API likväl som gå att söka igenom ett användargränssnitt. Kundhändelsetypskatalogen bör förvaltas av byggblocksansvarig för Mina ärenden och på sikt göras tillgänglig via Sveriges Dataportal.

2.2.3 Tillhandahålla index över var kundhändelser är lagrade

Kundhändelsetypskatalogen som beskrevs ovan löser problemet för konsumenten att hitta hos vilken myndighet som en viss typ av händelser finns att hämta. Men om det istället är kommuner eller regioner som äger informationen som konsumenten är intresserad av stöter vi också på ett annat problem. Det finns flera kommuner och flera regioner. Det räcker alltså inte att veta att händelserna konsumenten är intresserad av finns hos kommun, man måste också få reda på vilken kommun som äger händelser associerade med den aktuella kunden.

Här finns ett behov av ett kundhändelseindex. Detta kan konsumenten eller dess tjänster använda för att få reda på hos vilken specifik organisation som den aktuella kundens efterfrågade händelser finns hos. Att bygga upp ett index kräver mer information än kundhändelsetypskatalogen. Indexet behöver information om specifika kunders händelser medans kundhändelsetypskatalogen endast kräver generell information om vilken sorts organisation som hanterar händelser av en viss typ.

Nyttan med ett kundhändelseindex är att konsumenters tjänster inte behöver fråga alla anslutna kommuner eller alla anslutna regioner efter händelser (förutsatt att efterfrågade händelsetyper hanteras av kommuner eller regioner). Istället frågar tjänsten först indexet som pekar ut vilka specifika kommuner eller regioner som har händelser för den aktuella kunden. Därefter kan tjänsten rikta frågan till endast de kommunerna eller regionerna.

Kundhändelseindexet kommer inte att behövas innan producenter där det finns flera av samma sort (kommuner eller regioner) ansluter till infrastrukturen. Om ett fåtal sådana är anslutna ger inte indexet så mycket nytta, men efterhand som fler och fler ansluter ökar nyttan successivt.

2.2.4 Organisera producent och konsumentforum

Mina ärenden som byggblock är ett s.k. förutsättningsskapande byggblock utan användargränssnitt gentemot användaren. För att kunna förstå behov, samordna insatser mellan aktörer och få heltäckande underlag för byggblockets fortsatta utveckling bör ett producent- och konsumentforum inrättas.

2.3 Möjliga implementationssätt

Det finns ett antal vägval som behöver göras för implementationen av Mina ärenden. Här kommer vi att beskriva några av dessa vägval med olika alternativ. Vi börjar med en diskussion kring centralisering där byggblocksansvarig tar en större eller mindre del av ansvaret. Därefter följer en diskussion i olika sätt som en producent kan ansluta till infrastrukturen.

Exakt vilken väg lösningen kommer att ta för dessa vägval är ännu inte bestämt. Fortsatt arbete kommer att behövas för att avgöra detta i samråd med producenter och konsumenter.

2.3.1 Centralisering eller sammansatta bastjänster

Den totala lösningen kan innebära olika grad av centralisering. Här kommer vi att beskriva två alternativ för att illustrera skillnader. Notera att illustrationerna för tydlighetens skull endast är skrivna utifrån perspektivet av förmågan Hämta kundhändelser.

2.3.1.1 Endast index

Klicka här för att förstora bilden "Schematisk bild inblandade tekniska komponenter"

Figuren visar en schematisk bild över inblandade tekniska komponenter. Vi tänker oss scenariot att en användare är intresserad av att söka kundhändelser i ett kundärende som sträcker sig över flera producenter. Användaren gör detta via en tjänst, t.ex. ett affärssystem. I bakgrunden jobbar tjänsten ”Mina ärenden” som samordnar trafiken och dessutom finns ett antal stödjande tjänster för t.ex. identitet och auktorisation. Notera att alla inblandade system och tjänster kan driftas hos olika organisationer (både offentliga och privata) och att varje kommunikation behöver vara betrodd så att eventuellt känsliga uppgifter kan skickas.

Ett schematiskt scenario i en sådan här lösning skulle kunna se ut så här:

1. Användaren är intresserad av kundhändelser av en viss avgränsning (kund och tid samt t.ex. kundhändelsetyp eller kundärende). Användaren visar detta intresse mot tjänsten. En förutsättning för detta är att användaren redan är inloggad i tjänsten och därmed är både autentiserad och auktoriserad där.
2. Tjänsten meddelar Mina ärenden om behovet att visa kundhändelser
3. Mina ärenden använder ett antal stödjande tjänster för att: (fler saker kan tillkomma)
   1. Kontrollera att tjänsten är betrott i infrastrukturen
   2. Kontrollera att tjänsten har rätt att ställa den typ av fråga som ställts
   3. Kontrollera att tjänsten har rätt att ställa frågan för aktuell användare
   4. Om användaren är ett ombud för en annan person kontrolleras att ombudet har rätt att företräda personen
4. Om alla kontroller fallit väl ut svarar Mina ärenden till tjänsten. Svaret innehåller pekare till producentsystemen (flera i detta fall) som kan svara på olika delar av aktuell fråga.
5. Tjänsten går ut och frågar varje aktuell producent om informationen som kan hämtas där.
6. Varje producent använder samma stödjande tjänster som Mina ärenden gjorde för att göra samma (eller liknande kontroller). Eventuellt kan vissa kontroller utlämnas eftersom de redan är kontrollerade av Mina ärenden.
7. Producenterna svarar tjänsten med var sin delmängd av svaret.
8. Tjänsten sammanställer och presenterar informationen för användaren

2.3.1.2 Sammansatt bastjänst

En nackdel med lösningen ovan är att den ställer stora krav på konsumenterna att själva implementera uppdelning av frågor och sammanställning av resultat. Detta kan försena och försvåra anslutning till Mina ärenden bland konsumenter. För att lösa detta problem kan sammansatta bastjänster skapas, antingen av offentliga aktörer eller privata som kan se en affärsmöjlighet att sammanställa information och agera inom infrastrukturen för Mina ärenden.

Klicka här för att förstora bilden "Schematisk bild inblandade tekniska komponenter med bastjänst"

I en situation med en sammansatt bastjänst blir scenariot så här:

1. Användaren är intresserad av kundhändelser av en viss avgränsning (kund och tid samt t.ex. kundhändelsetyp eller kundärende). Användaren visar detta intresse mot konsumentens tjänst. En förutsättning för detta är att användaren redan är inloggad i tjänsten och därmed är både autentiserad och auktoriserad där.
2. Tjänsten meddelar Mina ärenden om behovet att visa kundhändelser
3. Mina ärenden använder ett antal stödjande tjänster för att: (fler saker kan tillkomma)
   1. Kontrollera att tjänsten är betrott i infrastrukturen
   2. Kontrollera att tjänsten har rätt att ställa den typ av fråga som ställts
   3. Kontrollera att tjänsten har rätt att ställa frågan för aktuell användare
   4. Om användaren är ett ombud för en annan person kontrolleras att ombudet har rätt att företräda personen
4. Om alla kontroller fallit väl ut svarar Mina ärenden till tjänsten. Svaret innehåller pekare till en sammansatt bastjänst som svarar på hela frågan.
5. Tjänsten ställer frågan till den sammansatta bastjänsten
6. Den sammansatta bastjänsten använder de stödjande tjänsterna för att göra erforderliga kontroller
7. Den sammansatta bastjänsten går ut och frågar varje aktuell producent om informationen som kan hämtas där. Vilka producenter som skall frågas vet den sammansatta bastjänsten (alternativt så frågar den Mina sidor om detta på samma sätt som i index-lösningen)
8. Varje producent använder de stödjande tjänsterna för att göra erforderliga kontroller.
9. Producenterna svarar med var sin delmängd av svaret.
10. Den sammansatta bastjänsten sammanställer svaren och skickar ett aggregerat svar tillbaka till tjänsten
11. Tjänsten presenterar det sammanställda svaret för användaren.

2.3.1.3 För- och nackdelar inom centralisering

Den första lösningen (index) har fördelen att den är flexibel i infrastrukturen. Däremot ligger hela bördan att sammanställa svar ifrån flera producenter på konsumenterna och deras tjänster. Eventuella förändringar i information och struktur behöver hanteras helt och hållet av dessa tjänster. Detta kan försvåra och fördröja anslutning av konsumenter.

Den andra lösningen (sammansatt bastjänst) löser några av problemen i den första lösningen. Dock blir det fler komponenter som behöver byggas, komplexiteten ökar och man kan möjligen hamna i ett läge där man inte gärna vill utveckla och förändra eftersom man ”byggt fast sig” i en viss lösning i den sammansatta bastjänsten.

2.3.2 Anslutning av en producent

När en ny producent skall ansluta behöver denna organisation exponera kundhändelser ifrån sina egna system ut på infrastrukturen för Mina ärenden. Detta kommer att göras via en eller flera tjänster där dessa tjänster behöver följa de regler och mönster som stipulerats centralt. Dessutom kommer icke-funktionella krav att ställas på dessa tjänster, t.ex. avseende säkerhet, tillgänglighet och prestanda.

Med stor sannolikhet kommer de intressanta kundhändelserna att finnas i flera olika IT-system hos producenten. Dessa behöver samordnas på något sätt så att man kan exponera kundhändelser ifrån flera system. Det finns då ett antal sätt att göra detta på, alla med sina egna för- och nackdelar.

2.3.2.1 Proxy

En relativt enkel lösning är att bygga upp en tjänst som agerar proxy

Klicka här för att förstora bild "Proxy figur 1"

I en sådan här lösning lagras informationen om kundhändelser i bakomliggande system. Proxyn arbetar bara när den får en fråga utifrån och den går då ut till bakomliggande system och hämtar efterfrågad information. Proxyn står också för eventuell format-översättning av kundhändelser ifrån det format som gäller i bakomliggande system till det format som gäller nationellt på infrastrukturen för Mina ärenden.

Funktioner som inte direkt har med att hämta kundhändelser att göra, t.ex. hantering av accesskontroll, notifieringar etc. har också en naturlig hemvist i proxyn i en sådan här lösning.

Fördelen med en proxy-lösning är att den blir relativt enkel och därför inte så kostsam. Nackdelen kan vara att den kan ha utmaningar vad gäller prestanda då man vid varje fråga utifrån behöver gå och fråga om information i bakomliggande system, vilket kan vara tidskrävande och dessutom lastar ned bakomliggande system vid frågetillfället.

En annan nackdel är att ansvaret för kundhändelser (i Mina ärendens mening) är utspritt, dels på proxyn men även i bakomliggande system som faktiskt lagrar ärendena. Detta kan leda till att eventuella förändringar i regelverk och definitioner av kundhändelser riskerar att slå på många system som eventuellt utvecklas och underhålls på olika ställen i producentens organisation.

2.3.2.2 Mellanliggande datalager

Om problemen med proxy-lösningen ovan blir för stora kan man tänka sig en annan lösning med ett mellanliggande datalager. Skatteverket har valt denna lösning där systemet Mimer är just detta datalager.

Klicka här för att förstora bild "Proxy figur 2"

Här finns fortfarande en proxy vars uppgift nu ”endast” är att hantera accesskontroll och vara en väg in i producentens IT-miljö. Proxyn läser data direkt ifrån en databas som vi kallar för datalagret. Denna databas fylls regelbundet på med kundhändelser ifrån bakomliggande system via en synkningstjänst.

Datalagret kan lagra kundhändelser i det format som krävs externt i infrastrukturen för Mina ärenden. På så sätt kommer frågorna som ställs att kunna exekveras fortare eftersom ingen formatöversättning behövs. Eventuell formatöversättning sker istället vid synkningstillfället så eventuell logik för detta hanteras av synkningstjänsten.

En fördel med denna lösning är att man kopplar loss exekvering av att svara på externa frågor ifrån den dagliga hanteringen i bakomliggande system. På så sätt får man prestandavinster både i svaret på frågorna men även i bakomliggande system.

En annan fördel är att det blir en naturlig hemvist i organisationen att ansluta till Mina ärenden. Proxyn, datalagret och synkningstjänsten utvecklas naturligt tillsammans och kan därför hanteras inom en organisatorisk enhet hos producenten.

En nackdel med denna lösning är att den är mer komplicerad och därför mer kostsam. Man riskerar också att datalagret inte är fullt synkat med bakomliggande system så man riskerar därmed att de kundhändelser som lämnas ut inte är fullt uppdaterade mot verkligheten i de bakomliggande systemen.