Angelägenhet (Concern)

En angelägenhet beskriver vad en intressent eller målgrupp anser vara viktigt i ett system eller en arkitektur. Det kan vara mål, behov, krav eller frågor som påverkar hur något ska utformas eller fungera.

Definition enligt ISO 42010

Enligt standarden ISO 42010:2022 är en "concern" ett intresse som är av betydelse för en eller flera intressenter i relation till ett system och dess arkitektur.

Typer av angelägenheter

Funktionella angelägenheter

• Användbarhet: Hur lätt är systemet att använda?
• Prestanda: Uppfyller systemet prestandakrav?
• Funktionalitet: Ger systemet rätt funktioner?

Kvalitetsaspekter

• Säkerhet: Är systemet säkert mot hot?
• Tillförlitlighet: Fungerar systemet konsekvent?
• Skalbarhet: Kan systemet hantera ökad belastning?

Affärsangelägenheter

• Kostnadseffektivitet: Ger systemet värde för pengarna?
• Time-to-market: Hur snabbt kan lösningen levereras?
• Compliance: Följer systemet regelverk?

Relation till arkitekturvyer

Angelägenheter driver utformningen av arkitekturvyer:

• Varje vy adresserar specifika angelägenheter
• Vyernas innehåll och struktur anpassas för att besvara concerns
• Olika intressenter har olika angelägenheter som kräver olika vyer

Identifiering av angelägenheter

Workshop-metoder

• Intressentanalys
• Concern mapping
• Riskanalyser

Strukturerade intervjuer

• Målgruppspecifika frågor
• Prioritering av concerns
• Konfliktidentifiering

Hantering av konflikter

Olika intressenters angelägenheter kan vara motstridiga och kräver:

• Prioritering baserad på affärsvärde
• Kompromisser mellan konkurrerande concerns
• Tydlig kommunikation om designbeslut

Arkitekturperspektiv

Arkitekturperspektiv beskriver hur en referensarkitektur framställs för att möta olika målgruppsperspektiv. Det består av vyer som visualiserar arkitekturen samt vyspecifikationer som definierar hur vyerna ska utformas.

Komponenter

Vyer

Strukturerade visualiseringar som visar arkitekturen från ett specifikt perspektiv:

• Visuella representationer av arkitektoniska element
• Fokus på specifika aspekter eller angelägenheter
• Anpassade för målgruppens behov

Vyspecifikationer

Definierar hur vyerna ska konstrueras:

• Syfte och målgrupp för vyn
• Notation och symboler
• Innehåll och detaljeringsgrad
• Kvalitetskriterier

Vanliga arkitekturperspektiv

Funktionellt perspektiv

• Fokus: Vad systemet gör
• Vyer: Use case-diagram, funktionsöversikter
• Målgrupp: Verksamhetsanalytiker, produktägare

Logiskt perspektiv

• Fokus: Systemets struktur och organisation
• Vyer: Komponentdiagram, klassdiagram
• Målgrupp: Arkitekter, utvecklare

Fysiskt perspektiv

• Fokus: Deployment och infrastruktur
• Vyer: Infrastrukturdiagram, nätverkstopologier
• Målgrupp: Systemadministratörer, infrastruktursarkitekter

Säkerhetsperspektiv

• Fokus: Säkerhetsarkitektur och hotskydd
• Vyer: Säkerhetsdomäner, trustzones
• Målgrupp: Säkerhetsarkitekter, CISO

Anpassning till målgrupper

Teknisk djup

Olika perspektiv kräver olika nivåer av teknisk detalj beroende på målgrupp.

Visualiseringsformat

Val av diagram och notationer anpassas efter målgruppens förtrogenhet.

Fokusområden

Varje perspektiv betonar de aspekter som är mest relevanta för dess primära målgrupp.

Aspekter

Aspekter är tvärgående perspektiv som används för att säkerställa att en referensarkitektur täcker in viktiga frågeställningar. De belyser olika egenskaper hos en lösning, exempelvis funktionella, informationsmässiga, säkerhetsmässiga eller infrastrukturella aspekter.

Syfte och funktion

Heltäckande analys

Aspekter säkerställer att alla viktiga dimensioner av arkitekturen beaktas och inte förbises.

Strukturerad genomgång

Ger ett systematiskt sätt att granska och utvärdera arkitektoniska lösningar.

Kvalitetssäkring

Hjälper till att identifiera potentiella brister eller risker i olika områden.

Vanliga aspekter

Funktionella aspekter

• Omfattning: Vad systemet ska göra
• Kapacitet: Vilken volym som ska hanteras
• Prestanda: Svarstider och genomströmning
• Användbarhet: Användarupplevelse och tillgänglighet

Informationsaspekter

• Datamodeller: Struktur och relationer
• Informationsflöden: Hur data rör sig genom systemet
• Datakvalitet: Precision, aktualitet, kompletthet
• Datahantering: Lagring, backup, arkivering

Säkerhetsaspekter

• Confidentiality: Skydd mot obehörig åtkomst
• Integrity: Skydd mot manipulation
• Availability: Tillgänglighet när det behövs
• Accountability: Spårbarhet och revision

Infrastrukturaspekter

• Plattform: Operativsystem, middleware, molntjänster
• Nätverk: Kommunikationsvägar och protokoll
• Kapacitet: Beräknings- och lagringsresurser
• Skalbarhet: Förmåga att hantera ökad belastning

Tvärgående karaktär

Påverkan på multipla komponenter

Aspekter är sällan isolerade till enskilda komponenter utan påverkar hela systemet.

Integration mellan aspekter

Olika aspekter kan ha beroenden eller konflikter som behöver hanteras.

Holistiskt perspektiv

Kräver helhetssyn där alla aspekter balanseras mot varandra.

Tillämpning i arkitekturarbete

Checklistor

Aspekter kan användas som checklistor för att säkerställa fullständig täckning.

Reviewkriterier

Ger struktur för arkitekturgranskningar och kvalitetsbedömningar.

Designriktlinjer

Varje aspekt kan ha associerade principer och riktlinjer som ska följas.

HERAM

Higher Education Reference Architecture Model (HERAM) är en modell som utgör den teoretiska och strukturella grunden för ramverket HERAF.

Vad är HERAM?

HERAM består av en konceptkarta, konceptbeskrivning samt ett styrande dokument för ramverket HERAF. Modellen säkerställer att referensarkitekturer skapas på ett konsekvent och strukturerat sätt.

Komponenter

Konceptkarta

En visuell representation av alla centrala begrepp inom HERAF och hur de förhåller sig till varandra.

Konceptbeskrivning

Detaljerade definitioner och förklaringar av alla begrepp som används inom ramverket.

Styrande dokument

Gemensamma principer, riktlinjer och regler som säkerställer att alla referensarkitekturer följer samma kvalitetsstandard.

Syfte

HERAM-modellen säkerställer att alla referensarkitekturer inom HERAF:

• Följer samma grundläggande struktur och terminologi
• Adresserar samma typer av angelägenheter och aspekter
• Kan jämföras och kombineras på ett meningsfullt sätt
• Uppfyller kvalitetskrav för användbarhet och ändamålsenlighet

Användning

När du skapar en referensarkitektur använder du HERAM-modellen för att säkerställa att alla nödvändiga aspekter täcks in och att strukturen följer ramverkets standarder.

HERAM fungerar som den teoretiska grunden för HERAF medan vägledningen ger praktiska instruktioner för genomförandet.

Intressenter

Intressenter är de roller som har ett intresse av en referensarkitektur men inte nödvändigtvis kommer vara den primära målgruppen som kommer använda den.

Inkluderande roller beror mycket på innehållet av en referensarkitektur där tex. Säkerhet och riskhanteringsteam kan ha ett intresse hur en referensarkitektur för IAM utformas även om de nödvändigtvis inte kommer använda dem.

Distinction från målgrupp

Målgrupp (primär)

• Huvudanvändarna av referensarkitekturen
• Designen anpassas specifikt för deras behov
• Direkt påverkade av arkitektoniska beslut

Intressenter (sekundär)

• Har legitima intressen men är inte primärt fokus
• Kan påverka eller påverkas av arkitekturen
• Behöver information men inte nödvändigtvis full detaljeringsgrad

Typer av intressenter

Governance-roller

• Säkerhetsteam: Intresserade av säkerhetsaspekter
• Riskhanterare: Fokus på riskidentifiering och mitigation
• Compliance-ansvariga: Regelefterlevnad och revision

Operationella roller

• Driftteam: Systemdrift och övervakning
• Support: Användarstöd och problemlösning
• Leverantörer: Externa tjänsteleverantörer

Strategiska roller

• Verksamhetsledning: Strategisk riktning och budget
• IT-ledning: IT-strategi och resurstilldelning
• Projektledare: Projektgenomförande och koordination

Hantering av intressenter

Identifiering

• Systematisk kartläggning av alla berörda roller
• Analys av påverkan och inflytande
• Dokumentation av specifika intressen

Kommunikation

• Anpassad information för olika intressentgrupper
• Regelbunden uppdatering om arkitekturutveckling
• Transparens kring designbeslut och motiveringar

Engagemang

• Involvering i designprocess där relevant
• Feedback-kanaler för kontinuerlig input
• Balansering av konkurrerande intressen

Målarkitektur

Målarkitektur är ett koncept som syftar till att skapa en långsiktig vision och plan för hur Universitetets IT-resurser och system ska utvecklas och integreras för att stödja verksamhetens behov.

Målarkitekturen fungerar som en kompass som hjälper medarbetare, projekt och ledning att välja rätt väg vid stora och små designbeslut. Vidare bidrar målarkitekturen till att skapa en sammanhållen arkitektur där komponenter fungerar i en helhet och stödjer varandra.

Konkretisering

För att konkretisera och vägleda realiseringen av målarkitekturen används:

Referensarkitekturer

Strukturerade nedbrytningar av målarkitekturen som fungerar som praktiska verktyg för att omsätta visionen i konkreta lösningar inom olika domäner.

Arkitekturprinciper

Definierar ramarna för arkitekturarbetet och säkerställer att beslut fattas i linje med den övergripande visionen.

Egenskaper

• Visionär - beskriver det önskade framtida tillståndet
• Vägledande - ger riktning för beslut och projekt
• Sammanhållen - säkerställer att alla delar fungerar tillsammans
• Flexibel - kan anpassas när behov förändras

Målgrupp

Målgrupp är primära rollen eller rollerna som en referensarkitektur riktar sig till. Denna grupp påverkas helt av mot vem referensarkitektur riktar sig till och kan vara allt från verksamhetsledningen, IT-arkitekter eller tom. IT-tjänsteleverantörer.

Betydelse för referensarkitektur

Anpassning av innehåll

Referensarkitekturens struktur, detaljeringsgrad och fokus anpassas efter målgruppens behov och kunskapsnivå.

Kommunikationsstil

Språk, terminologi och presentationsformat väljs för att vara mest effektivt för den specifika målgruppen.

Perspektiv och vyer

Arkitekturperspektiv och vyer utformas för att besvara målgruppens specifika frågeställningar.

Vanliga målgrupper

IT-arkitekter

• Behov: Detaljerade tekniska specifikationer, designmönster, integrationslösningar
• Fokus: Teknisk implementation och systemdesign
• Vyer: Tekniska arkitekturvyer, komponentdiagram

Verksamhetsledning

• Behov: Strategisk översikt, kostnad-nytta, riskbedömningar
• Fokus: Affärsvalue och strategisk riktning
• Vyer: Högnivåöversikter, roadmaps

Utvecklare

• Behov: Konkreta implementationsguider, kodexempel, API-specifikationer
• Fokus: Praktisk implementation
• Vyer: Detaljerade tekniska vyer, sekvensdiagram

IT-tjänsteleverantörer

• Behov: Servicenivåer, integrationskrav, leveransstandarder
• Fokus: Tjänsteleverans och drift
• Vyer: Servicearkitektur, operationella vyer

Primär vs sekundär målgrupp

• Primär målgrupp: Huvudanvändarna som referensarkitekturen främst är utformad för
• Sekundär målgrupp: Andra intressenter som kan ha nytta av innehållet men inte är huvudfokus

Målgruppsperspektiv

Målgruppsperspektiv är synvinkeln från en specifik målgrupp och beskriver vilka frågeställningar, eller concerns, som är viktiga att besvara eller addressera.

Definition och syfte

Varje målgrupp har unika behov, kunskaper och ansvar som påverkar vilka aspekter av arkitekturen som är mest relevanta för dem. Målgruppsperspektiv säkerställer att arkitekturdokumentation och -kommunikation anpassas för att vara maximalt värdefull för varje specifik grupp.

Viktiga dimensioner

Kunskapsnivå

• Teknisk djup som målgruppen behöver
• Förtrogenhet med arkitekturkoncept
• Tidigare erfarenhet av liknande system

Ansvarsområden

• Beslut som målgruppen fattar
• Uppgifter de ska utföra
• Resultat de är ansvariga för

Tidsperspektiv

• Strategiskt (långsiktig planering)
• Taktiskt (projektgenomförande)
• Operationellt (daglig drift)

Vanliga målgruppsperspektiv

Utvecklarperspektiv

• Frågeställningar: Hur implementerar jag detta? Vilka API:er finns?
• Behov: Tekniska detaljer, kodexempel, integrationsmönster
• Fokus: Konkret implementation och teknisk utformning

Ledningsperspektiv

• Frågeställningar: Vad kostar det? Vilka risker finns? Hur bidrar det till affärsmålen?
• Behov: Strategisk översikt, kostnad-nyttaanalys, riskbedömningar
• Fokus: Affärsvalue och strategisk riktning

Driftperspektiv

• Frågeställningar: Hur övervakas systemet? Vilka backup-rutiner behövs?
• Behov: Operationella procedures, övervakningsstrategier
• Fokus: Stabilitet, prestanda, säkerhet i drift

Arkitektperspektiv

• Frågeställningar: Följer detta våra principer? Hur påverkar det andra system?
• Behov: Designrationale, beroenden, konsekvensanalys
• Fokus: Systemhelt och arkitekturell konsekvens

Anpassning av arkitekturvyer

Innehållsval

Olika perspektiv kräver olika typer av information och detaljeringsgrad.

Presentationsformat

Visualiseringar och dokumentationsformat anpassas efter målgruppens preferenser och arbetskontext.

Kommunikationsstil

Språk, terminologi och förklaringsnivå justeras för optimal förståelse.

Mönster / Patterns

Mönster är återanvändbara och standardiserade lösningar på återkommande problem. De fungerar som mallar eller riktlinjer för hur system kan designas och kan ingå i en referensarkitektur för att underlätta och styra implementationer.

Definition och egenskaper

Återanvändbarhet

Mönster representerar lösningar som har bevisat sig effektiva i olika sammanhang och kan tillämpas på liknande problem.

Standardisering

Ger gemensamma designpraktiker som förenklar kommunikation och förståelse mellan arkitekter och utvecklare.

Beprövade lösningar

Baseras på erfarenhet och har testats i verkliga implementationer.

Typer av mönster

Arkitekturmönster

Övergripande strukturer för systemorganisation:

• Layered Architecture: Organisering i logiska lager
• Microservices: Uppsplittring i små, autonoma tjänster
• Event-driven Architecture: Kommunikation via händelser
• Service-oriented Architecture: Tjänstebaserad arkitektur

Designmönster

Lösningar på vanliga designproblem:

• Observer: Meddelanden om tillståndsförändringar
• Factory: Objektskapande utan specifik klassspecifikation
• Strategy: Utbytbara algoritmer
• Facade: Förenklad åtkomst till komplex funktionalitet

Integrationsmönster

Kommunikation mellan system:

• Message Queue: Asynkron meddelandehantering
• API Gateway: Centraliserad API-åtkomst
• Database per Service: Databasseparation i microservices
• Saga Pattern: Distribuerade transaktioner

Fördelar med mönster

Accelererad utveckling

Färdiga lösningar minskar tid för design och implementation.

Kvalitetsförbättring

Beprövade mönster minskar risken för designfel och teknisk skuld.

Kommunikationsförenklar

Gemensamt språk mellan teammedlemmar och organisationer.

Kunskapsöverföring

Strukturerat sätt att dela arkitekturerfarenheter.

Integration i referensarkitekturer

Rekommenderade mönster

Referensarkitekturer specificerar vilka mönster som är lämpliga för olika situationer.

Kombinationer

Beskriver hur olika mönster kan kombineras för optimala lösningar.

Anti-mönster

Identifierar patterns som ska undvikas i specifika kontexter.

Anpassningsriktlinjer

Vägledning för hur mönster ska modifieras för organisationens specifika behov.

Nulägesarkitektur

Nulägesarkitektur beskriver den aktuella arkitekturen som finns i drift i organisationen idag. Den ger en överblick över befintliga system, tekniska komponenter, informationsflöden, integrationer och verksamhetsprocesser.

Syftet med nulägesarkitekturen är att skapa en gemensam förståelse för hur saker fungerar just nu, identifiera styrkor och svagheter, samt utgöra en grund för vidare analys och planering.

Den är ofta teknikberoende och speglar både historiska beslut och nuvarande begränsningar.

Användningsområden

• Kartläggning av befintliga system
• Analys av teknisk skuld
• Grund för förändringsprojekt
• Riskbedömning

Relation till andra arkitekturtyper

Nulägesarkitekturen är startpunkten för övergången till målarkitektur via övergångsarkitektur.

Område

Område anger kontexten för en referensarkitektur, det vill säga inom vilken domän eller vilket problemområde arkitekturen är giltig. Det avgränsar fokus och tydliggör ramarna för principer, begrepp och lösningar.

Funktion

Avgränsning

Definierar tydliga gränser för var och när en specifik referensarkitektur ska tillämpas.

Fokusering

Möjliggör specialisering och djupare kunskap inom ett specifikt verksamhets- eller teknikområde.

Sammanhang

Ger kontext som hjälper arkitekter och utvecklare att förstå relevansen och tillämpbarheten av olika arkitektoniska beslut.

Exempel på områden

Identitet och behörighetshantering (IAM)

Omfattar autentisering, auktorisation, användarhantering och åtkomstkontroll.

Integration

Fokuserar på systemintegration, API-hantering, meddelandehantering och dataflöden.

Artificiell intelligens (AI)

Täcker ML-pipelines, datahantering, modellhantering och AI-governance.

Internet of Things (IoT)

Hanterar enhetshantering, datainhämtning, edge computing och IoT-säkerhet.

Viktiga egenskaper

• Tydligt avgränsat - klara gränser för vad som ingår
• Verksamhetsrelevant - kopplat till faktiska behov
• Tekniskt coherent - sammanhängande teknisk domän

Övergångsarkitektur

Övergångsarkitektur beskriver ett tillfälligt eller stegvis mål på vägen mot en framtida målarkitektur. Den används för att planera och styra förändringsresan – särskilt när det inte är möjligt eller önskvärt att gå direkt från nuläge till mål.

Övergångsarkitekturen innehåller de förändringar som behöver ske i ett visst skede, inklusive nya komponenter, avveckling av gamla lösningar, och anpassningar som krävs för att möjliggöra fortsatt utveckling.

Den är ett viktigt verktyg för att hantera komplexitet, risker och beroenden i större transformationsinitiativ.

Karakteristika

• Tidsbegränsad - har ett tydligt slutdatum
• Stegvis - möjliggör gradvis transformation
• Riskhantering - minskar risker genom mindre förändringar
• Praktisk - tar hänsyn till verkliga begränsningar

Användningsområden

• Stora systemmigrationer
• Teknisk modernisering
• Organisatoriska förändringar
• Compliance-anpassningar

Referensarkitektur

En referensarkitektur är en mall eller ramverk som beskriver en rekommenderad struktur och organisering inom ett specifikt område. Den fungerar som en överenskommen vägledning och standardiseringsgrund för vad en lösning inom ett visst område bör implementeras.

Syfte

Syftet med en referensarkitektur är att etablera en gemensam strategisk inriktning för samtliga aktörer inom ett specifikt verksamhetsområde. Genom att på ett konsekvent sätt beskriva grundläggande principer, centrala komponenter samt deras inbördes relationer, möjliggörs ett gemensamt språkbruk som underlättar koordinering av initiativ och minimerar risken för kommunikativa missförstånd.

Fördelar

Accelererad utveckling

Eftersom referensarkitekturen vilar på ackumulerad erfarenhet och beprövade lösningar, elimineras behovet av att påbörja utvecklingsinsatser från grunden. Istället kan förändringsarbetet koncentreras till att anpassa och vidareutveckla befintliga strukturer.

Reducerad risk

Bidrar till reducerad tidsåtgång och lägre risknivå vid införande av nya tjänster eller vid utvärdering av befintliga miljöer.

Systematisk analys

Tillhandahåller ett systematiskt ramverk för att analysera och jämföra den aktuella IT-miljön med ett definierat mål- eller referenstillstånd.

Beslutsunderlag

Skapar ett robust underlag för beslutsfattande, argumentation och kommunikation – särskilt gentemot intressenter som efterfrågar välgrundade motiveringar till tekniska vägval.

Referensarkitekturmodell

En referensarkitekturmodell är en abstrakt och generell modell som beskriver grundläggande begrepp, strukturer och relationer för en referensarkitektur.

Syftet är att skapa en gemensam förståelse och ett ramverk för att designa, jämföra eller utvärdera specifika lösningar, arkitekturer eller system.

Karakteristika

Abstrakt nivå

Modellen arbetar på en konceptuell nivå som är oberoende av specifika tekniska implementationer.

Generell tillämpbarhet

Kan användas inom olika domäner och organisationer som grund för utveckling av specifika referensarkitekturer.

Strukturerad approach

Tillhandahåller en systematisk metod för att organisera och beskriva arkitektoniska element.

Relation till referensarkitektur

Medan en referensarkitektur är specifik för ett visst område eller domän, utgör referensarkitekturmodellen det övergripande ramverket som definierar hur referensarkitekturer ska struktureras och beskrivas.

HERAM som referensarkitekturmodell

HERAM (Higher Education Reference Architecture Model) är ett exempel på en referensarkitekturmodell specifikt utvecklad för högre utbildning, som tillhandahåller ramverket för att skapa domänspecifika referensarkitekturer inom universitets- och högskolekontexten.

Regel

En regel är en tvingande riktlinje. Den definierar vad som måste följas i syfte att säkerställa att personer agerar i enlighet med styrande principer, lagkrav eller andra obligatoriska förhållningssätt.

Karakteristika

Obligatorisk

Regler är tvingande och måste följas utan undantag eller endast med formella avsteg.

Specifik

Ger tydliga, mätbara krav som kan kontrolleras och följas upp.

Kontrollerbar

Måste vara möjlig att verifiera efterlevnad av, ofta genom automatiserade kontroller.

Typiska källor för regler

Lagkrav

• GDPR och dataskydd
• Tillgänglighetslagstiftning
• Branschspecifika regleringar

Säkerhetspolicyer

• Kryptografiska standarder
• Åtkomstkontrollkrav
• Incident management

Tekniska standarder

• Arkitektoniska constraints
• Plattformskrav
• Integrationsstandarder

Exempel på regler

Säkerhet

"All kommunikation med externa system MÅSTE använda TLS 1.2 eller senare"

Dataskydd

"Personuppgifter SKALL raderas inom 30 dagar efter avslutad relation"

Arkitektur

"Nya system MÅSTE exponera API:er enligt OpenAPI 3.0 specifikation"

Implementation

Regler implementeras ofta genom:

• Automatiserade kontroller i CI/CD-pipelines
• Policysystem som blockerar regelbrott
• Compliance-verktyg för kontinuerlig övervakning
• Granskningsprocesser för manuell kontroll

Riktlinje

En riktlinje är en konkretisering av en styrande princip. Den beskriver hur principen bör tillämpas i praktiken och ger vägledning för handling och beslut.

Egenskaper

Konkret vägledning

Riktlinjer översätter abstrakta principer till praktiska handlingsanvisningar som arkitekter och utvecklare kan följa.

Flexibilitet

Till skillnad från regler är riktlinjer rekommendationer som kan anpassas efter specifika omständigheter.

Kontextuell

Ger vägledning som är relevant för specifika situationer eller tekniska områden.

Relation till principer och regler

Styrande princip → Riktlinje → Regel
   (Varför)         (Hur)      (Vad)

Exempel: Säkerhetsprincip

• Princip: "Säkerhet först"
• Riktlinje: "Använd HTTPS för all extern kommunikation"
• Regel: "TLS 1.2 eller senare är obligatoriskt"

Användningsområden

API-design

Riktlinjer för hur API:er ska utformas för att vara konsekventa och användarvänliga.

Säkerhet

Rekommendationer för säkerhetsimplementation utan att vara för restriktiva.

Kodning

Stilguider och bästa praxis för programutveckling.

Arkitektur

Vägledning för arkitektoniska beslut och designmönster.

Viktiga aspekter

• Praktiska - kan tillämpas direkt i utvecklingsarbete
• Motiverade - tydlig koppling tillbaka till styrande principer
• Uppdaterbara - kan anpassas när teknik eller behov förändras

Styrande principer

Styrande principer är den grundläggande riktningen som finns på ett lärosäte eller för ett område. Den påverkar vilka beslut en arkitekt gör när hen designar lösningar.

Genom att följa principerna kan lärosäten säkerställa att deras arkitektur samt underliggande design går mot den gemensamma tilltänkta riktningen.

Karakteristika

Riktningsgivande

Principer ger övergripande vägledning för arkitektoniska beslut utan att vara för specifika eller tekniska.

Långsiktiga

Ska vara stabila över tid och inte förändras med varje teknisk trend eller kortsiktigt behov.

Verksamhetsförankrade

Måste vara kopplade till organisationens mål och strategier.

Hierarki av styrning

Styrande principer operationaliseras genom:

1. Riktlinjer - konkretiserar hur principerna ska tillämpas
2. Regler - tvingande krav som måste följas

Exempel på styrande principer

Säkerhet först

All design ska prioritera säkerhet och integritet från början.

Öppna standarder

Föredra öppna, välbeprövade standarder framför proprietära lösningar.

Användarcentrerat

Designbeslut ska utgå från användarnas behov och upplevelser.

Modulär arkitektur

System ska byggas med löst kopplade, återanvändbara komponenter.

Implementation

Principer realiseras genom arkitektoniska beslut, designmönster och tekniska standarder som följer principernas anda.

Vy-specifikation

En vy-specifikation definierar hur en vy ska utformas genom att ange dess syfte, målgrupp, innehåll, notation och detaljnivå, vilket säkerställer att vyer är konsekventa, jämförbara och uppfyller sitt arkitektoniska syfte.

Komponenter av en vy-specifikation

Syfte

• Varför existerar denna vy?
• Vilka angelägenheter (concerns) adresseras?
• Vilket problem löser vyn?

Målgrupp

• Vem är den primära användaren?
• Vilken kunskapsnivå förutsätts?
• Vilka roller och ansvar har målgruppen?

Innehåll

• Vilka element ska inkluderas?
• Vilka relationer ska visas?
• Vilken information är relevant?

Notation

• Symboler och ikoner som ska användas
• Konventioner för representation
• Standarder som följs (UML, ArchiMate, etc.)

Detaljnivå

• Granularitet av information
• Abstraktionsnivå som är lämplig
• Omfattning av vyn

Fördelar med vy-specifikationer

Konsekvens

Säkerställer att liknande vyer skapas på samma sätt oavsett vem som producerar dem.

Kvalitet

Definierade kriterier och standarder höjer kvaliteten på arkitekturdokumentation.

Effektivitet

Färdiga mallar och riktlinjer accelererar vyproduktion.

Kommunikation

Gemensam förståelse för vad olika vytyper innehåller och varför.

Exempel på vy-specifikationer

Systemkontextvy

• Syfte: Visa systemets relation till omgivningen
• Målgrupp: Verksamhetsanalytiker, projektledare
• Innehåll: System, externa aktörer, informationsflöden
• Notation: Enkla rektanglar och pilar
• Detalj: Högnivå, inga tekniska detaljer

Komponentarkitekturvy

• Syfte: Visa systemets interna struktur
• Målgrupp: Systemarkitekter, utvecklare
• Innehåll: Komponenter, gränssnitt, dependencies
• Notation: UML-komponentdiagram
• Detalj: Medeldetaljnivå med teknisk fokus

Standarder och ramverk

• TOGAF ADM: Definierade vytyper för enterprise architecture
• ISO 42010: Standard för arkitekturbeskrivning
• ArchiMate: Språk för enterprise architecture modeling

Vy

En vy är en strukturerad och visualiserad representation av en arkitektur ur ett specifikt perspektiv, som syftar till att göra arkitekturen begriplig och relevant för olika intressenter genom att illustrera komponenter, relationer och egenskaper såsom systemkomponenters samspel, informationsflöden, säkerhetslager, infrastruktur och tjänstegränssnitt, i syfte att besvara målgruppens frågeställningar (concerns).

Syfte och funktion

Kommunikation

Vyer gör komplexa arkitekturer förståeliga genom visuell representation anpassad för specifika målgrupper.

Fokusering

Genom att visa endast relevanta aspekter kan vyer minska komplexitet och öka förståelsen.

Beslutsunderlag

Ger strukturerad information som stödjer arkitektoniska och tekniska beslut.

Viktiga aspekter av vyer

Målgruppsanpassning

• Innehåll anpassas efter målgruppens kunskaper och behov
• Detaljeringsgrad varierar beroende på användningsområde
• Notation väljs för optimal förståelse

Angelägenhetsfokus

Varje vy adresserar specifika angelägenheter (concerns):

• Säkerhetsvy fokuserar på säkerhetsaspekter
• Integrationsvyer visar systemsamverkan
• Prestandavy belyser prestandakritiska element

Exempel på vytyper

Kontextvy

• Syfte: Visa systemets relation till omgivningen
• Innehåll: Externa aktörer, systemgränser
• Målgrupp: Verksamhetsanalytiker, projektledare

Komponentvy

• Syfte: Visa systemets interna struktur
• Innehåll: Komponenter, gränssnitt, dataflöden
• Målgrupp: Arkitekter, utvecklare

Deployment-vy

• Syfte: Visa fysisk utplacering
• Innehåll: Servrar, nätverk, miljöer
• Målgrupp: Infrastrukturteam, drift

Säkerhetsvy

• Syfte: Visa säkerhetsarkitektur
• Innehåll: Säkerhetszoner, kontroller, hot
• Målgrupp: Säkerhetsarkitekter, CISO

Kvalitetsaspekter

• Konsekvens mellan relaterade vyer
• Aktualitet - vyer måste hållas uppdaterade
• Verifierbarhet - vyer ska kunna valideras mot implementationen