Jämförda versioner

Nyckel

  • Dessa rader lades till.
  • Denna rad togs bort.
  • Formateringen ändrades.

Bakgrund

En förbättrad användarupplevelse kräver i flera fall att arkitekturella förändringar behöver genomföras. Detta för att 1177-tjänster fram till nu har skapats, förvaltats och utvecklats som solitärer - vilket har medfört att en tjänst i de flesta fall inte har någon koppling till andra tjänster. Detta är ännu mer påtagligt mellan öppna och inloggade tjänster, där avståndet är ännu längre.

Och i arbetet med att definiera en ny målarkitektur i linje med Målbild 1177 så har det här identifierats som ett problem som behöver adresseras och är en förutsättning för att bl.a. kunna skapa översiktsvyer som utgår från invånarens behov och inte är inlåsta i en specifik tjänst.

Idag innehåller 1177 ett flertal e-tjänster som i många fall är framtagna för att lösa ett specifikt problem och i sig självt erbjuder tillräckligt med förmågor och funktionalitet för att lösa det specifika problemet. Det här har lett till att det i vissa fall finns flera implementationer av samma förmåga, som ska lösa samma/liknande behov, men de vet inte om varandra. Och nya tjänster kan inte återanvända bra lösningar som har gjorts sedan tidigare. Detsamma gäller information som har inhämtats från externa källor (regioner, kommuner, etc); varje tjänst hämtar bara den information som behövs i den specifika tjänsten. Och om behovet av samma information finns i andra tjänster så behöver de bygga funktionalitet och hämta den själva. Återanvändning och resurseffektivisering stödjs inte på ett bra sätt i dagens lösning.

Svaret på frågan om specifika lösningar för en viss tjänst vs. generella lösningar för flera tjänster är inte alltid glasklar och ibland är det mest kostnadseffektivt att ta fram specifika lösningar; och ibland är det även juridiska skäl som spelar in. Men för varje given situation bör vi analysera och ifrågasätta detta och undersöka om det finns en större nytta med att lösa ut problemet med en generell lösning.

En anledning till att det ser ut som det gör är att Inera och kunder kommit överens om lagom stora beställningar, som då ofta har kunnat definierats som en tjänst i omfattning. Ett sätt att se på det är att Inera har ett tjänsteorienterat angrepssätt, och inte ett användarcentrerat angreppssätt.

Men större initiativ som Sammanhållen plan och Målbild 1177 har påvisat behovet av att 1177 behöver tänka bredare och större, ett enterprise-arkitekturperspektiv: 1177 som helhet vs. de ingående 1177-tjänsterna. Och utmaningarna att gå från regioners och Ineras behov till att istället utgå från användarens (invånarens) unika behov och situation är således stora - och behöver även förhålla sig till gällande lagar & förordningar.

Lösningsförslag

Många behov som skönjas inom Förbättrad användarupplevelse kan lösas med ett nytt grepp som vi inom arkitekturen har valt att kalla “Vyer” - ett lager ovanpå dagens e-tjänster. Ett intressant grepp där användarupplevelse och arkitektur möts på ett nytt sätt. Detta grepp har möjliggjort att istället för att bygga om alla e-tjänster, så lägger vi ett skal ovanpå för att stödja en förbättrad användarupplevelse:

...

Definitionen på “Vyer” är:

...

Det här är ett exempel på hur användarbehov leder till förslag på arkitekturella lösningar, som i sin tur leder till innovativa förslag på hur användares behov kan mötas, som i sin tur pekar på behov även på vilka informationskällor som behöver stärkas för att nyttan ska uppnås. Se exempel nedan:

...

Begrepp inom 1177

Givet det ovanstående är den arkitekturella målbilden att kunna särskilja följande begrepp:

...

De definitioner av gränssnitt som vi har försökt beskriva (utöver vyer) är:

...

1177 API-lager

Att införa Vyer som begrepp har inneburit en kanske ännu större förtjänst - tankarna på ett införande av ett API-lager inom 1177 innebär inte bara att Vyer kan realiseras, men också att annat informationsutbyte inom 1177 tjänster kan realiseras och eventuellt centraliseras.
Att erbjuda “Vyer”, e-tjänster och sidor en möjlighet att medelst API:er kunna bygga upp innehållet för att förbättra användarupplevelsen är kanske den största förändringen på länge inom 1177.

...

API-stödtjänster

Ytterligare ett sätt att komma bort från enskilda och isolerade tjänster är att se över vilka förmågor inom 1177 som bör generaliseras och låta dem bli ett stöd för flera vyer och e-tjänster som har samma behov.

Vi har idag inget stödjande koncept för denna typ av generella tjänster inom 1177, men har sedan något år tillbaka skissat på att införa ett affärslager som vi definierar som 1177 Infrastruktur. Det omfattar infrastrukturella tjänster som är:

  • 1177-generella, men inte Inera-generella

  • 1177-specifika, men inte tjänstespecifika.

...

Förmågor

Inom målarkitekturarbetet pågår mycket arbete med att kartlägga vilka förmågor som 1177 behöver besitta för att uppnå Målbild 1177. Dels handlar det om att identifiera framtida behov av nya förmågor, förändring av existerande förmågor, upprätthållande av existerande förmågor, samt avveckling av icke-nyttodrivande förmågor. Och dels att identifiera vilka förmågor som finns i existerande tjänster och vilka som inte finns idag (GAP-analys).

Förmågekarta med utvecklingsbehov:

...

GAP-analys:

...

Kontentan är att arbetet med Förbättrad användarupplevelse inom 1177 behöver analyseras ihop med förmågeutveckling och arkitektur.

Arbetssätt

För att säkerställa att arbetet med Förbättrad användarupplevelse linjerar med det arkitekturella arbetet, så behöver inititativ både taktas och prioriteras gentemot helheten.
Ett sätt att tänka på detta är att Inera och 1177 successivt behöver lösa ut problem - både för användare och ur ett tekniskt perspektiv.
Nedan är en illustration av ett arbetssätt som vi arkitekter och UX-leads tillsammans förespråkar.

...

Ett annat angreppssätt är att se hur Målarkitektur och Målbild för förbättrad användarupplevelse (“Målbild UX”) relaterar till varandra och andra större strategiska initiativ.

...

Ett nära samarbete mellan Arkitektur och UX är en förutsättning för att Målbild 1177 ska kunna
genomföras. Ett koordineringsarbete mellan Arkitektur och UX behöver etableras mer formellt än dagens.
Att ha förmånen att få jobba strategiskt med både arkitekturella vägval och innovativa designförslag, i linje med Målbild 1177, innebär att samarbetsmöjligheter kring relevanta och genomförbara förslag kan prioriteras och taktas i rätt ordning.

Och för att säkerställa att både projekt och förvaltningar går i rätt riktning, så kan vi knyta an till avdelningen Arkitektur & Digital infrastrukturs krav på att införa begreppet Design Authority i ett bredare perspektiv:

...

  • Vilka 1177-tjänster besitter de önskade förmågorna?

  • Vad har vi för glapp mellan önskvärda och befintliga förmågor?

  • Hur kan vi börja röra oss mot målbilden (givet var vi är idag)?

...