Introduktion till EIRA

EIRA ges ut av Europeiska Kommissionen och definieras där som en konceptuell referensarkitektur som definierar referensbyggblock som behövs för att bygga system som stödjer offentliga tjänster. Arkitekturen fångar grundläggande mönster och koncept som är applicerbara för olika typer av domäner inom offentlig sektor och dess samverkan med privat sektor och medborgare.

Syftet med en referensarkitektur i fleraktörsmiljöer är generellt att:

• Dokumentera kunskap inom ett arkitekturområde för att effektivisera arkitekturarbete

• Likrikta lösningar hos olika aktörer med syfte att uppnå högre interoperabilitet

• Öka möjligheterna till återanvändning av både arkitekturkunskap och lösningar

• Definiera gemensamma begrepp för att öka förståelsen mellan aktörer

• Säkerställa aktörers följsamhet gentemot riktlinjer och regler som beskrivs i arkitekturen

I EIRA Leaflet definieras följande specifika skäl till att använda EIRA:

• EIRA konkretiserar European Interoperability Framework ur ett arkitekturperspektiv

• EIRA stödjer designen av transeuropeiska system genom att belysa de viktigaste arkitekturella byggblocken

• EIRA faciliterar portföljhantering, exempelvis rationalisering

• EIRA stödjer delning och återanvändning av interoperabilitetslösningar

• EIRA möjliggör analys av lagars påverkan på arkitektur

Introduktion till metoden

Joinup programmet som skapat EIRA har även gjort en metodbeskrivning som ger vägledning för hur EIRA kan användas i de olika faserna av TOGAFs Architecture Development Metod (ADM).

Du kan ladda ner en Excel-fil med makron med all information här: https://joinup.ec.europa.eu/release/eira-guidelines-togaf-interoperability-adm-cycle/v10

Filen är också bifogad här i Confluence.

Open

Vägledningen utgår som sagt från TOGAF ADM i de olika faser som finns i nedanstående bild. Kapitlen nedan sammanfattar de rekommendationer som ges i vägledningen från Joinup och ger en del tips på hur en kommun eller region skulle kunna använda EIRA.

Open

Preliminary phase

EIRA rekommenderar att man samlar ett team med experter som har kompetens inom de olika interoperabilitetsperspektiven i IEF: Juridik, Verksamhet, Semantik och Teknik.

Det rekommenderas även att EIF-principerna läggs till i Arkitekturen. I Sverige har eSAM gjort en bearbetning av EIF-principerna och publicerat dessa i Svenskt ramverk för digital samverkan - eSam. Vill du modellera principerna enligt Arkitekturgemenskapens ramverk använder du elementtypen link Princip.

I denna fas väljer man också arkitekturramverk och verktyg vilket kan baseras på Arkitekturgemenskapens verktyg eller andra. Värt att notera är att ISA2 programmet gör ett verktyg som heter CarTool som är en Archimate modell över olika EIRA-implementationer. Du kan också använda den SPARX EA profil som tillhandahålls av Arkitekturgemenskapen.

Phase A

Architecture Vision

Här rekommenderar EIRA att man definierar Intressenter (Stakeholders) och Krav (Requirements). Utöver detta kan vi också rekommendera att dokumentera intressenternas Intressen.

I nästa steg beskrivs Mål (Goal) och Begränsningar (Constraint). EIRA rekommenderar att utgå från ett övergripande mål att “uppnå interoperabilitet” som sedan bryts ner i delmålen uppnå juridisk/verksamhet/semantisk/teknisk interoperabilitet. Begränsningar modelleras enligt metodvägledningen efter EIRAS Legal view och är nära relaterade till krav. Det är dock oklart om vägledningen är uppdaterad till version 3.0.0 av EIR där just Constraint inte verkar finnas kvar.

Vidare rekommenderar EIRA att man ska utvärdera Verksamhetsförmågor (Capability) enligt Interoperability Maturity Model (IMM). Du kan också titta på Metod för förmågebaserad planering för vägledning om hur ni kan jobba med förmågor. Se även Förmågeområdeskarta som innehåller redan definierade förmågor.

För att utvärdera hur redo verksamheten är att förändras rekommenderar EIRA en vy som heter “Key Interoperability Enablers viewpoint”. Denna innehåller ett urval av byggblock från EIRA som betraktas som de viktigaste möjliggörarna. Som kan utläsas av vyn nedan så består dessa möjliggörare till största del av dokument (verksamhetsobjekt), exempelvis avtal, men även av en datasetkatalog och ett tjänsteregister. Utvärderingen består därmed av att beskriva om elementen i vyn finns i organisationen och till vilken grad de tillämpas vilket resulterar i en förståelse för vad som behöver förändras. Detta är en analys på mycket hög nivå som man kan ifrågasätta värdet av. För en mer detaljerad analys rekommenderas Interoperability Maturity Model.

Open

Ett viktigt steg i denna fas är att definiera de principer som ska gälla för arkitekturen. Eftersom vi redan rekommenderat att inkludera principer från EIF och Svenskt ramverk för digital samverkan - eSam handlar det här om att eventuellt utöka och detaljera dessa till den specifika arkitekturens kontext.

Tabellen nedan summerar de typer av arkitekturelement som föreslås användas i fas A.

Phase B

Business Architecture

I denna fas rekommenderar EIRA att utveckla arkitekturen med EIRAs Legal view och Organisational view som utgångspunkt. De element som rekommenderas att fokusera på beskrivs i tabellen nedan:

Enligt TOGAFs ADM tar man först fram en nulägesarkitektur och sedan en målarkitektur (nyläge). Sedan gör man en gap-analys mellan dessa två för att identifiera vad som behöver utvecklas och skapa en plan för utvecklingen. Här kan lämpligen en Modelltyp - Förmågeutvecklingsplan användas.

EIRA rekommenderar även att man utvecklar ett antal möjliggörare som exempelvis Security & Privacy Policy, Organisational policy, Interoperability skill etc. Dessa beskrivs lämpligen som Verksamhetsobjekt i arkitekturen.

Phase C

Information Systems Architecture

I denna fas föreslår EIRA att man använder den semantiska vyn och de två tekniska vyerna (Application & Infrastructure) för att ta fram nuläges och nylägesarkitekturer. Följande hög-nivå aktiviteter från TOGAF ADM föreslås:

• Ta fram nulägesarkitektur

• Ta fram nylägesarkitektur

• Genomför gapanalys

• Definiera färdplan/utvecklingsplan

• Genomför gransking

• Färdigställ informationsystemarkitekturen

EIRA vägledningen pekar framförallt på ett antal utvalda elementtyper som bör användas för att beskriva nuläge och nyläge, enligt tabellen nedan:

I övrigt ger vägledningen inga konkreta detaljer om hur EIRA kan användas i denna fas utöver vad som finns beskrivet i TOGAF ADM.

Phase D

Technology Architecture

Denna fas innehåller samma steg som fasen C och EIRAs vägledning pekar bara på en specifik skillnad - nämligen att endast ett element är av huvudsakligt intresse:

Bilden nedan summerar de element som vägledningen rekommenderar används i respektive fas. Dessutom visas de relationer som finns i Arkitekturgemenskapens ramverk. Med hjälp av elementtyper och relationer kan man skapa en spårbarhet mellan de olika delarna i arkitekturen.

Phase E - H

För dessa faser ger EIRA inte speciellt mycket vägledning utöver vad som finns i TOGAF. Man pekar på Interoperability Quick Assessment Toolkit (IQAT) som ett verktyg att använda tillsammans med det tidigare nämnda IMM. IQAT är en excelfil som kan användas av lösningsägare för att utvärdera om deras lösningar stödjer interoperabilitet för offentliga tjänster. Här analyseras fyra områden:

• Ledning och styrning

• Systemarkitektur

• Grafiska gränssnitt

• Maskinella gränssnitt

Observera att när detta skrivs i Mars 2020 refererar IQAT till EIRA version 1 vilket kan indikera att verktyget inte underhålls.