Planera förmågeimplementationen
- arkitekturgemenskapen@inera.se
1. Introduktion
Att planera förmågeimplementationen handlar om att ytterligare konkretisera vilka delar av förmågan som behöver förändras och utgår ifrån det arbetet som gjort i tidigare faser med kartläggning, analys och planering av förmågeutvecklingen.
Att planera förmågeimplementation hänger tätt ihop med organisationens projektstyrning och projektets initieringsfas. I denna del av processen bryts arbetspaket ned för att konkretisera vad i arkitekturen som behöver förändras och identifiera vilka arkitekturella artefakter som kan behöva skapas eller ändras för att stödja planering och genomförande av projektet.
I många organisationer etableras arkitekturbeskrivningar i projekten med hjälp av verksamhetsarkitekter, säkerhetsarkitekter, lösningsarkitekter, informationsarkitekter med flera. Arbetet behöver granskas och kvalitetssäkras av Koncernarkitekter så att det ligger i linje med den koncernövergripande arkitekturen.
Förmågeutvecklingsplanen som togs fram i tidigare processteg används som underlag för att förstå vilka förmågor som ska utvecklas. Förmågorna i arbetspaketen kopplas till olika element i arkitekturperspektiven verksamhet, information, säkerhet och teknik. Resultatet användas för att upptäcka faktorer som kan komplicera eller underlätta utvecklingen av förmågan. Det kan till exempel vara beroenden mellan applikationer som används av flera förmågor, avsaknaden av följsamhet mot branschstandard som försvårar skalning av lösningar eller avsaknad av tillräckliga säkerhetsfunktioner.
Sambandet mellan de olika perspektiven i AG:s ramverk kan beskrivas utifrån bilden nedan. Förmågan kopplas till perspektiven verksamhet, information, teknik och säkerhet för att ge en mer konkret prognos över vilka systemelement som ska förändras i realiseringen.
En av de viktigaste fördelarna med att använda arkitektur i en förmågebaserad utveckling är att förmågorna kan kopplas till andra delar i arkitekturen. Relationer till element i verksamhets- informations- och teknikperspektiven kan användas för att beskriva hur en förmåga realiseras genom processer, informationsobjekt, applikationer etc. Dessa relationer är naturligtvis relevanta i planeringsarbete som utgår från strategiska mål (uppifrån-ner), men även då förmågeutveckling kan ske genom enskilda möjliggörare, exempelvis nya tekniska lösningar (nerifrån-upp).
Bilden nedan sammanfattar förmågors relationer till andra element gällande verksamhet, information, teknik och säkerhet.
Relationerna kan naturligtvis visualiseras på många olika sätt, men framförallt är Modelltyp - Verksamhetskarta (Vintergatan) en användbar modelltyp för att visa relationen mellan förmågor och deras implementation. Verksamhetskartor är i grunden diagram med förmågor och relationer som visar informationsutbyten mellan dessa. Ovanpå dessa kartor kan sedan olika relaterade element visas. Exempelvis kan man visa vilka processer och tekniska system som stöttar de olika förmågorna.
EXEMPEL: Utifrån gapanalyser och förmågeutvecklingsplaner kan konceptuella arkitekturer börja ta form. Det handlar i grunden om att omsätta behov till nya lösningar. Arkitekter kan tillsammans med andra verksamhetsutvecklare detaljera de förändringar som behöver ske utifrån analyser som gjorts i förmågornas dimensioner. I exemplet Omställning till nära vård har man identifierat att en ökad användning av egenmonitorering leder till de effekter som man önskar. Men för att kunna skala upp användningen föreslås flera stora förändringar:
Styrning. Utveckla klara riktlinjer och policys som reglerar användningen av egenmonitorering, inklusive dataskyddspolicyer, patientens rättigheter och ansvarsfördelning mellan alla inblandade parter.
Organisering. En ny organisation för logistik och teknisk support som krävs för att underhålla och distribuera de enheter och applikationer som används för egenmonitorering.
Process: Utveckla och implementera standardiserade vårdprocesser som inkluderar egenmonitorering som en integrerad del av patientvården. Detta kan inkludera protokoll för hur och när data ska samlas in, samt hur denna information ska användas i kliniska beslut.
Information: Etablera valideringsmekanismer för att säkerställa datakvaliteten och riktigheten i patienternas hälsoinformation.
Teknologi: Upphandling av en ny lösning för egenmonitorering som har öppna API:er och stöd för öppna informationsstandarder och som kan integreras med befintliga IT-system och e-hälsoapplikationer.
Modelltypen Modelltyp - Förmågeutvecklingsplan kan också visualisera relationen mellan förmågor och andra systemelement, t.ex. applikationer och verksamhetstjänster. Se Metamodell Realisering för mer information.
2. Aktiviteter
2.1 Koppla arkitekturvyer till faser
Som framgår av ovanstående bild av metamodellen kan kopplingen mellan förmågor och andra element blir många till antalet. Den direkta kopplingen är användbar för olika ändamål, men bidrar inte enkelt svaret på frågan hur arkitekturen ser ut som ska bidra till en specifik uppsättning förmågor.
Partitionering är strategier för att dela upp en större modell eller system i mindre, hanterbara delar. Det blir lättare för arkitekter och utvecklare att förstå, analysera, och arbeta med systemet. Detta underlättar även för nya teammedlemmar att snabbt sätta sig in i systemets struktur och funktion.
Genom att relatera arkitekturvyer till fas-elementen (förflyttning, mission, värdeström eller permanent uppdrag) uppnås en slags relationsbaserad partitionering av modellen. Det blir enkelt att peka ut de arkitekturelement som specifikt bidrar till en viss fas och till den samling förmågor som är relaterade till fasen.
Genom att beskriva arkitekturer (dvs skapa arkitekturvyer) som implementerar en viss fas uppnås en indirekt koppling till utpekade förmågor. Arkitekturvyer (t.ex. logisk arkitektur, säkerhetsarkitektur, fysisk arkitektur) kan skapas som tillsammans pekar ut vilka delar av den totala arkitekturen som har ett beroende till fasen.
2.2 Koppla förmågor till verksamhetsperspektivet
Förmågor har täta band till verksamhetsarkitekturen. Framförallt kan de relateras till vad som görs i verksamheten (processer, verksamhetsfunktioner & verksamhetstjänster), men också till vem som realiserar eller använder förmågorna (aktörer och organisationsenheter). Genom dessa relationer kan man beskriva kopplingarna mellan den strategiska arkitekturen och den mer operativa verksamhetsarkitekturen.
Relevanta underlag för denna aktivitet är förmågeutvecklingsplaner och analyser samt verksamhetsarkitektur vilken exempelvis kan bestå av processmodeller, verksamhetskartor, aktörsmodeller etc.
Följande element kan vara aktuella att koppla till Förmågor:
Aktör – har eller behöver Förmåga. Används ofta i verksamhetskartor för att beskriva externa aktörers interaktion med förmågor.
Organisation – använder Förmåga. Kan användas i verksamhetskartor för att beskriva vilka funktioner som är inblandade i att leverera eller använda en förmåga.
Process – operationaliserar Förmåga. Kan användas som ett sätt att knyta processmodeller till förmågekartor och verksamhetskartor och visa vilka processer som stödjer vilka förmågor.
Verksamhetsfunktion – levererar Förmåga. Kan användas i verksamhetskartor för att beskriva vilka funktioner som är inblandade i att leverera en förmåga.
Verksamhetstjänst – möjliggör Förmåga. Kan användas i verksamhetskartor för att beskriva vilka tjänster som är inblandade i att leverera en förmåga.
Begränsning – påverkar Förmåga. Även om begränsningar tillhör det strategiska perspektivet i metamodellen så används dessa för att uttrycka verksamhetsregler, lagar mm. Därmed kan man definiera vilka regler som gäller för olika förmågor.
2.3 Koppla förmågor till informationsperspektivet
I organisationer som jobbar med både informationsstyrning och förmågebaserad planering kan det vara lämpligt att koppla förmågor direkt till information. Detta kan till exempel vara ett sätt att visa vilka informationsområden, informationsgrupper eller till och med specifika informationsobjekt som är viktiga för att förmågor ska kunna uppnås.
Ett tänkbart scenario skulle kunna vara att en förmågeanalays visar att det saknas information eller att nuvarande information har för dålig kvalitet för att en förmåga ska kunna utvecklas till den nivå som verksamheten önskar. I realiseringsplaneringen kan man då beskriva vilka informationsobjekt som behöver adresseras av vilka arbetspaket.
Ytterligare skäl som kan ligga till grund för att koppla förmågor till informationsobjekt:
Integrationer - förmågan saknar information från andra förmågor eller har andra problem relaterat till informationsförsörjning
Informationssäkerhetsklassning - förmågan har bristfällig hantering av känsliga informationsobjekt vad gäller exempelvis åtkomst och behörighet
Masterdata - förmågan saknar grundinformation eller har andra utmaningar med att bibehålla format, kvalitet etc.
Standarder - förmågan använder informationsobjekt där det finns brister i att förhålla sig till bransch och/eller nationell/internationella standarder
Relevant ingångs material till denna aktivitet är framförallt informationsmodeller, men även informationsflödesmodeller kan vara relevanta.
Följande element är aktuella att koppla till Förmågor:
Informationselement – bidrar till Förmåga. Observera att enligt Metamodell Information så kan informationsobjekt vara av olika typ: Informationsområde, grupp, objekt eller entitet. Vanligtvis används här grupp och objekts-nivåerna för att uppnå en hanterbar, men ända meningsfull abstraktionsnivå.
2.4 Koppla förmågor till teknikperspektivet
I förmågeimplementationen handlar kopplingen till teknikperspektivet om att beskriva vilka delar av den tekniska miljön som ska förändras. I huvudsak berör detta applikationer och infrastruktur, där applikationer kan omfatta både applikationer eller tjänster som dessa tillhandahåller. När det gäller infrastruktur används noder eller tekniska tjänster för att beskriva påverkan.
Baserat på dessa relationer kan projekt eller produktägare skapa mer detaljerade beskrivningar (exempelvis User Stories) av vad som behöver förändras i applikationen för att förbättra verksamhetsförmågan.
Relevant ingångs material till denna aktivitet är framförallt olika typer av beskrivningar av den tekniska miljön och applikationsportföljen, exempelvis applikationskommunikationsdiagram, systemnedbrytningsdiagram etc.
Relationer mellan förmågor och applikationer visas även ofta som en överlagring i Modelltyp - Verksamhetskarta (Vintergatan) för att ge en förståelse för hur olika applikationer stödjer hela förmågelandskapet.
Följande element är aktuella att koppla till Förmågor:
Applikation – bidrar till att möjliggöra förmågor genom att de antingen hjälper användare att utföra aktiviteter eller att automatiskt utföra aktiviteter. Själva möjliggörandet är därmed starkt knutet till de funktioner som applikationerna har och det data de hanterar.
Applikationstjänst – dessa kan också bidra till att möjliggöra förmågor, särskilt om det behövs datautbyten till eller från förmågan för att den ska kunna realiseras.
Nod – kan också vara möjliggörare till förmågor, även om det är mindre vanligt. I detta fall handlar det om att beskriva hur delar av infrastrukturen bidrar till olika förmågor. Det kan exempelvis vara så att vissa datacenters, eller andra tekniska komponenter är viktiga för att förmågor ska fungera.
Teknisk tjänst – är också en möjliggörare till förmågor om dessa är beroende av specifika tekniska mekanismer för att fungera. Det är dock relativt ovanligt att denna typ av beroenden beaktas i den strategiska planeringen.
2.5 Koppla förmågor till säkerhetsperspektivet
I realiseringen av förmågor är det naturligtvis viktigt att säkerställa att de informationstillgångar förmågan behöver också skyddas på adekvat sätt.
Enligt metamodell säkerhet som beskrivs nedan kan utläsas att säkerhetsåtgärder möjliggör förmågor och att säkerhetsåtgärder utgörs av antingen processer, verksamhetsfunktioner, teknikfunktioner, utrustningar eller applikationsfunktioner. Det är alltså dessa som kan kopplas till förmågorna.
Bedömningen av vilka säkerhetsåtgärder som är lämpliga eller nödvändiga för respektive förmåga görs lämpligen av säkerhetsarkitekter tillsammans med verksamhetsteam och verksamhetsarkitekt, eventuellt med stöd av informationsarkitekt och lösningsarkitekt om det finns särskilda krav på skydd av informationstillgångar.
Följande element är aktuella att koppla till Förmågor:
Process – Säkerhetsåtgärd i form av process, exempelvis incidenthantering.
Verksamhetsfunktion– Säkerhetsåtgärd i form av verksamhetsfunktion, exempelvis Security Operations Center.
Teknikfunktion - Säkerhetsåtgärd i form av teknikfunktion, exempelvis stark autentisering.
Utrustning - Säkerhetsåtgärd i form av utrustning, exempelvis larmsystem.
Applikationsfunktion - Säkerhetsåtgärd i form av applikationsfunktion, exempelvis gallring av data.
Arkitekturgemenskapens publika sidor © 2025 by Arkitekturgemenskapen is licensed under