Målarkitektur 1177

Målarkitektur är en beskrivning av ett framtida tillstånd för den arkitektur som utvecklas för en organisation. Det kan finnas flera framtida tillstånd presenterat i en färdplan för att visa utvecklingen av arkitekturen till ett måltillstånd.

Ett syfte med målarkitekturen är att skapa underlag för medvetna beslut kring tekniska lösningar så att man bygger dem utifrån behov och verksamhetsnytta samtidigt som det görs så effektivt som möjligt, till exempel genom att undvika onödig dubbelfunktionalitet.

I det här avsnittet beskrivs hur 1177-arkitekterna arbetat med målarkitektur parallellt med UX-arbetet i uppdraget Förbättrad användarupplevelse i 1177.

Innehåll:

Bakgrund

En förbättrad användarupplevelse kräver i flera fall arkitekturella förändringar. 1177-tjänsterna har fram till nu skapats, förvaltats och utvecklats som solitärer, som självständiga tjänster, vilket har medfört att en tjänst i de flesta fall inte har någon koppling till andra tjänster. Det märks allra mest mellan de öppna och inloggade tjänsterna.

I arbetet med att definiera en ny målarkitektur i linje med Målbild 1177 har det här identifierats som ett problem att lösa, bland annat för att skapa förutsättningar för översiktsvyer som utgår från invånarens behov.

Idag innehåller 1177 ett flertal e-tjänster framtagna för att lösa ett specifikt problem. Varje tjänst erbjuder tillräckligt med förmågor och funktionalitet för att lösa det specifika problemet. Det här har lett till att i vissa fall finns det flera implementationer av samma förmåga för att lösa samma eller liknande behov utan att de vet om varandra. Det innebär också att nya tjänster inte kan återanvända bra lösningar som finns 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. Om behov av samma information finns i andra tjänster så behöver varje tjänst bygga funktionalitet för att hämta den. Återanvändning och resurseffektivisering stödjs inte på ett bra sätt i dagens lösning.

Det är inte alltid glasklart om specifika lösningar för en viss tjänst eller generella lösningar för flera tjänster är det bästa. Ibland är det mest kostnadseffektivt att ta fram specifika lösningar. Ibland finns det även juridiska skäl som avgör. 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 ett problem 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 ofta har kunnat definierats som en tjänst. Det kan beskrivas som att Inera har ett tjänsteorienterat angreppssätt, inte ett användarcentrerat angreppssätt.

Större initiativ som Sammanhållen planering på 1177.se och Målbild 1177 har visat på behovet av att 1177 behöver tänka bredare och större, genom att tänka på 1177 som helhet visavi de ingående 1177-tjänsterna. Det är att ta ett enterprise-arkitekturperspektiv. 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 stora - och behöver även förhålla sig till gällande lagar och förordningar.

Lösningsförslag

Många behov som visas inom uppdraget Förbättrad användarupplevelse i 1177 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. Istället för att bygga om alla e-tjänster, lägger vi ett skal ovanpå för att stödja en förbättrad användarupplevelse:

Open

Definitionen på “Vyer” är:

Open

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. Detta i sin tur pekar på vilka informationskällor som behöver stärkas för att nytta 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 - för att Vyer ska kunna realiseras, behöver ett API-lager inom 1177 etableras. Detta innebär inte bara att Vyer kan etableras. Det gör 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 med hjälp av API:er 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 innehålla för att uppnå Målbild 1177. Det handlar dels 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 och taktas ihop med arkitekturen och med utveckling av nya förmågor.