---
title: "[Løsningsnavn] – Løsningsarkitekturbeskrivelse"
ejer: "DOT"
skabelon_version: "0.1"
status: "Udkast"
---
Denne side er en **skabelon** til at skrive en *løsningsarkitekturbeskrivelse* (Architecture Description). Brug knappen ovenfor til at downloade skabelonen som Markdown – så kan du udfylde afsnittene og slette den vejledende tekst undervejs. Formålet er at give læseren en god forståelse af den tilsigtede løsningsarkitektur. Undgå lange beskrivelser – brug modeller, diagrammer og referencer til mønstre, hvor det formidler pointerne præcist og kort.
Skabelonen bygger på den view-baserede tilgang **"Views with Perspectives"** fra *Software Systems Architecture* (Rozanski & Woods) og integrerer **NAF v4.1**-viewpoints, så beskrivelsen lever op til NATO's arkitekturstandarder. Den er et kompromis mellem den simple C4-model, det dateret-teoretiske TOGAF og den stærkt standardiserede ISO/IEC/IEEE 42010.
**Sådan bruger du skabelonen**
- Tilpas skabelonen til den konkrete løsning. Irrelevante view-afsnit kan markeres **NIL** ("nothing-in-line"). Nye views kan tilføjes under *Andre views*.
- NAF kræver hverken brug af alle viewpoints eller udelukker ekstra viewpoints, hvis de adresserer interessenters bekymringer.
- Den vejledende tekst (som denne) er ikke en del af selve beskrivelsen – slet den, efterhånden som du udfylder afsnittene.
## Versionshistorik
| Version | Dato | Forfatter | Bemærkninger |
|---|---|---|---|
| 0 | 2013.10 | Rozanski, Woods | Oprindelig skabelon fra *Software Systems Architecture*, 2. udgave |
| 0.1 | 2026.04 | FMI DOT-DE | Integreret NAF v4.1-viewpoints og eksempler |
## Sådan bruger du NAF
Viewpoints i NAF v4.1 er organiseret i **NAF-grid'et** efter *Subject of Concern* (rækker) og *Aspect of Concern* (kolonner). I VIDAR kan du klikke dig direkte ind i hvert viewpoint:
- Se det fulde, klikbare grid på **[NAF 4.1-oversigten](/arkitekturbibliotek/standarder/rammevaerk/naf/4-1/)**.
- Læs viewpoint-beskrivelserne for at sikre, at du overvejer relevante aspekter og ikke overser noget vigtigt.
Anbefalinger til notation og diagrammer:
- Brug en passende notation: NAF Information Model (NAF IM), **ArchiMate**, BPMN eller UML. NAF v4.1 anbefaler ArchiMate som standardreference (se *ArchiMate Modeling Guide for the NATO Architecture Framework Version 4*).
- NAF Capabilities og Services kan diagrammeres i både NAF IM og ArchiMate. Bemærk, at Services, Service Interfaces og Functions findes på tre ArchiMate-lag (Business, Application, Technology).
- Logiske flows, operative aktiviteter og høj-niveau-interaktioner kan tegnes som ArchiMate Business process – eller i BPMN, hvor det passer bedre.
- UML er ofte nødvendig for datamodeller (klassediagram), tilstandsmaskiner (state machine) og interaktioner (sekvens-/kommunikationsdiagram).
- Hvis du bruger andre modeller end NAF IM og ArchiMate, så forklar brugen og begrundelsen for læseren.
**C3-taksonomi:** Referér til den relevante Consultation, Command and Control (C3) Taxonomy, hvor det giver mening. Taksonomierne giver en ensartet klassifikation på tværs af løsninger. Kilde: `https://tide.act.nato.int/`
## Centrale begreber
Termer for *View*, *Viewpoint* og *Perspective* er overlappende på tværs af kilderne – vær opmærksom på konteksten.
| Begreb | Betydning |
|---|---|
| **Architecture Description (AD)** | Arbejdsprodukt, der beskriver en arkitektur. Denne skabelon bruges til at dokumentere en konkret arkitektur for en *løsning*. |
| **Solution (løsning)** | Generisk term, der kan omfatte mere end et IT/CIS-system. Svarer til *Entity-of-Interest* i ISO 42010 (enterprise, system, delsystem, proces, data, applikation, service m.m.). |
| **Architecture View** | "A View is what you see." Den konkrete, strukturelle udsigt til arkitekturen set gennem en linse – fx "Informationsview". |
| **Viewpoint** | "A Viewpoint is where you are looking from." De linser, der kan anlægges. Her primært **NAF-viewpoints** fra NAF-grid'et – fx L5 (Logical States). |
| **Architecture Perspective** | Komplementært til View. En samling af aktiviteter, taktikker og retningslinjer, der sikrer, at løsningen udviser bestemte **kvalitetsegenskaber** (tværgående). |
# Kapitel 1: Introduktion
## Formål og afgrænsning
Forklar dokumentets formål og afgrænsning. Primært dokumenteres arkitekturen for interessenterne, så det sikres, at den opfylder deres mål og bekymringer, og at den foreslåede arkitektur er korrekt, komplet og egnet til formålet.
Overvej at medtage: projektets kontekst, mål og formål; bekræftelse af scope og afgrænsninger; overblik over mål, drivere og krav; vigtige beslutninger og deres rationale; overvejede alternativer og begrundelser for fravalg.
**NAF-vejledning:** Læs NAF v4.1 kapitel 1 som introduktion til "Architecting", "Architectures" og "Architecture Frameworks".
## Målgruppe
Definér dokumentets målgruppe. De vigtigste er typisk arkitekter, ingeniører og udviklere, der designer og bygger løsningen, samt sponsoren. Se de øvrige interessenter i kapitel 3.
**NAF-vejledning:** Identificér målgruppen via en interessentanalyse. Interessenter identificeres i A2 (Architecture Products); A1 (Metadata Definitions) og C2 (Enterprise Vision) kan give værdifuldt input.
## Status
Forklar den aktuelle status for arkitekturen og for denne beskrivelse. Er den under udarbejdelse? Under implementering? I produktion? Beskriv evt. fremtidige planer for dokumentet.
**NAF-vejledning:** Følg arkitekturstatus via A5 (Architecture Status) og A6 (Architecture Versions).
## Arkitektonisk tilgang
Forklar den overordnede tilgang til at beskrive og udvikle indholdet (viewpoints, views og perspektiver). Forklar om nødvendigt, hvilke views du bruger og hvorfor.
**NAF-vejledning:** Dette dokument bruger NAF-grid-repræsentationen til at organisere viewpoints efter *Subject of Concern* (rækker) og *Aspect of Concern* (kolonner). Guid læseren ved at referere til relevante NAF-viewpoints og C3-taksonomier.
# Kapitel 2: Ordliste
Definér termer, akronymer og forkortelser, der kan være ukendte for målgruppen – både forretnings- og teknologi-/arkitekturtermer. Er ordlisten lang, så opret et separat dokument og referér til det her.
**NAF-vejledning:** Brug A1 (Metadata Definitions) til at holde ordlisten konsistent.
| Term | Definition | Reference |
|---|---|---|
| | | |
| | | |
# Kapitel 3: Interessenter og krav
## Interessenter
Definér de vigtigste interessenter og interessentgrupper, og forklar deres interesse, behov og bekymringer for løsningen. En interessent er enhver, der har en interesse i eller bekymring om løsningen. Overvej grupperne: anskaffere, assessorer, kommunikatører, udviklere, vedligeholdere, driftsingeniører, leverandører, support, systemadministratorer, testere og brugere – og arkitekten selv.
**NAF-vejledning:** NAF v4.1 kapitel 2-5 lister generiske interessenter. Interessenter identificeres i A2 (Architecture Products); A1 og C2 kan give input.
## Overblik over krav
Opsummér de vigtigste funktionelle og kvalitetsmæssige (ikke-funktionelle) krav.
- **Funktionelle krav** definerer, hvad løsningen skal gøre.
- **Kvalitetsegenskaber** (ikke-funktionelle krav) definerer, hvordan løsningen skal opføre sig i drift eller design (fx svartid, tilgængelighed, udvidbarhed).
Undgå detaljer, der findes andetsteds; referér til kravspecifikationer, SLA'er m.m. hvor muligt.
**NAF-vejledning:** NAF Service Specifications (pink række) og Logical Specifications (blå række) beskriver løsningens tilsigtede funktionelle og kvalitetsmæssige egenskaber. Services og logiske specifikationer bør mappes til de tilsigtede Capabilities fra Concepts (grøn række). Et godt udgangspunkt: map funktionelle krav til L4 (Logical Activities) og S4 (Service Functions); kvalitetskrav til C7 (Performance Criteria) og P8 (Resource Constraints).
| Reference | Kravbeskrivelse | NAF-viewpoint |
|---|---|---|
| | | |
| | | |
### Compliance- og interoperabilitetskrav
List compliance-krav af relevans for løsningen. Dæk relevante NATO-, FMN- og lignende militære standarder og krav. I tidlige faser angives gældende standarder og rammeværk; senere refereres til løsningens tiltag for at opfylde dem (eller til ekstern dokumentation).
## Løsningsscenarier
Skitsér kort de vigtigste scenarier for de centrale interessenter, og som illustrerer løsningens evne til at opfylde de vigtigste krav. Overvej både **funktionelle scenarier** (noget løsningen skal gøre som svar på en hændelse) og **kvalitetsscenarier** (hvordan løsningen reagerer på ændringer i sit miljø). Tunge scenarier dokumenteres ofte bedst i et separat dokument.
**NAF-vejledning:** S6 (Service Sequence) og L6 (Logical Sequence) kan bruges til modellering af funktionelle scenarier. Brug C5 (Effects) til kvalitetsscenarie-analyse.
### Funktionelle scenarier
| Felt | Beskrivelse |
|---|---|
| Scenariereference | |
| Overblik | |
| Systemtilstand | |
| Systemmiljø | |
| Eksternt stimulus | |
| Krævet systemrespons | |
### Systemscenarier
| Felt | Beskrivelse |
|---|---|
| Scenariereference | |
| Overblik | |
| Systemmiljø | |
| Miljøændringer | |
| Krævet systemrespons | |
# Kapitel 4: Arkitektoniske kræfter
## Mål
List de vigtigste arkitektoniske mål og forretningsdrivere. Et *mål* er noget projektet vil opnå; en *driver* er en ekstern kraft, der former projektet. Spørg fx: Hvad er dine nøgletargets som arkitekt? Genbrug af eksisterende software? Minimale omkostninger? Høj pålidelighed?
**NAF-vejledning:** Mål dokumenteres i C2 (Enterprise Vision) og C8 (Planning Constraints).
## Begrænsninger
List de vigtigste arkitektoniske begrænsninger, projektet skal respektere – herunder overordnede arkitekturbegrænsninger, modeller, krav, standarder og gældende referencearkitekturer. En begrænsning indskrænker dine valg (fx deadline, implementeringssprog, operationsmodel). Sourcing-beslutninger kan udgøre stærke begrænsninger. Referér til specifikke standarder og regulering, der styrer arkitekturen.
**NAF-vejledning:** Dokumentér begrænsninger i C8 (Planning Constraints), L8 (Logical Constraints) og P8 (Resource Constraints).
## Arkitekturprincipper
Forklar de arkitekturprincipper, der har formet arkitekturen. Et princip er en grundlæggende erklæring om overbevisning, tilgang eller hensigt. Et godt princip er konstruktivt, begrundet, velformuleret, testbart og betydningsfuldt. Hvert princip bør begrundes med et rationale og kan suppleres med implikationer.
**NAF-vejledning:** NAF kapitel 2, afsnit 6.5 beskriver arbejdet med arkitekturprincipper i NAF v4. Start med enterprise-principperne – **"DOTs styrende arkitekturprincipper"**. I tidlige faser: beskriv hvordan hvert princip guider arkitekturen. I senere faser: beskriv hvordan projektet efterlever hvert princip. Efterlevelse kan være et nøgleelement i arkitekturreviews.
**DOTs styrende arkitekturprincipper** (udfyld hvordan løsningen forholder sig til hvert):
| Princip | Hvordan løsningen forholder sig |
|---|---|
| Operationel handlekraft og sikkerhed | |
| Design til krig | |
| Secure by design | |
| Bevar digital suverænitet og handlekraft | |
| Retning og strategisk værdiskabelse | |
| Kapabilitetsdrevet udvikling | |
| Data er en strategisk ressource | |
| Innovationskraft skaber kampkraft | |
| Teknologisk realisering | |
| Design til interoperabilitet | |
| Byg på platforme | |
| Design til fleksibilitet | |
| Brug velafprøvede turn-key-løsninger | |
Projektspecifikke principper (én tabel pr. princip):
| Felt | Beskrivelse |
|---|---|
| Princip-reference/navn | |
| Princip-erklæring | |
| Rationale | |
| Implikationer | |
| Yderligere information | |
# Kapitel 5: Arkitekturviews
## Kontekstview
Kontekstviewet beskriver relationer, afhængigheder og interaktioner mellem løsningen og dens omgivelser (mennesker, løsninger og eksterne aktører). Det viser løsningens scope og grænser ved at beskrive interaktionerne med eksterne aktører – ikke de interne detaljer. Arbejd med dette view gennem hele processen: start med det givne miljø, begrænsninger og scope.
Mulige diagrammer: Capabilities som løsningen leverer/forbruger (fx C3-capabilities); Services (C3-services er et godt udgangspunkt); værdistrømme/processer; API'er; infrastruktur-faciliteter og -services løsningen afhænger af.
### Kontekstdiagram
Brug et kontektsdiagram til at vise det miljø, løsningen opererer i, og de eksterne aktører den interagerer med. Løsningen vises typisk som én boks; eksterne aktører som enkeltbokse. Interaktioner kan være dataflows (interfaces) eller kontrolflows (fx kald af en service). Nedenfor et generisk eksempel i neutral "boxes-and-lines"-notation – brug gerne ArchiMate i stedet:
```mermaid
flowchart TB
user1(["Bruger"]):::actor
user2(["Bruger"]):::actor
ext1["Eksternt system
eller organisation"]:::ext
ext2["Eksternt system
eller organisation"]:::ext
ext3["Eksternt system
eller organisation"]:::ext
subgraph boundary["Organisatorisk afgrænsning"]
solution["**[Løsning]**"]:::solution
end
user1 -->|"interface-beskrivelse"| solution
user2 -->|"interface-beskrivelse"| solution
solution -->|"interface-beskrivelse"| ext1
solution -->|"interface-beskrivelse"| ext2
ext3 -->|"interface-beskrivelse"| solution
classDef solution fill:#cfe2f3,stroke:#1F4E79,color:#000
classDef ext fill:#e2e2e2,stroke:#666,color:#000
classDef actor fill:#fff2cc,stroke:#bf9000,color:#000
```
**NAF-vejledning:** Brug fx C2 (Enterprise Vision), L2 (Logical Structure) og L3 (Logical Interactions) til at lave et **L2-L3 Logical Concept**-diagram (et operationskoncept, fx en billedlig "SAR Concept"-oversigt). Lav andre diagrammer fra viewpoints som C3 (Capability Dependencies), hvor det giver mening.
### Interaktionsscenarier
Hvor interaktionerne mellem løsningen og eksterne aktører er komplekse, så modellér de forventede interaktionssekvenser. Det afdækker implicitte krav og begrænsninger (rækkefølge, volumen, timing). Beskriv kun de overordnede scenarier, hvor løsningen ses som en "black box".
**NAF-vejledning:** Brug fx elementer fra L6 (Logical Sequence) og S6 (Service Sequence). Forretningsprocesser modelleres ofte bedst i BPMN.
## Funktionelt view
Det funktionelle view definerer løsningens arkitektonisk væsentlige funktionelle elementer, deres ansvar, de interfaces de tilbyder, og afhængighederne mellem dem. Fokusér på de vigtigste funktionelle elementer. Ved kompleks funktionalitet: modellér på højt niveau og dekomponér udvalgte elementer.
**NAF-vejledning:** Lav funktionelle modeller med fx Capabilities, Services og deres kobling til det logiske niveau. Brug C1-S1 (Service to Capability Mapping). Inkludér aspekterne Structure, Connectivity og Behaviour (processes, states, sequences) efter behov – fx L4 (Logical Activities), S4 (Service Functions) og C4 (Standard Processes).
Eksempel på en **C1-S1 Service to Capability Mapping** (services *aims to achieve* capabilities):
```mermaid
flowchart BT
MRS["«Service»
Maritime Recovery Service"]:::service
SitS["«Service»
Situational Service"]:::service
IRS["«Service»
Inshore Rescue Service"]:::service
Rec["«Capability»
Recovery"]:::capability
SA["«Capability»
Situational Awareness"]:::capability
MSAR["«Capability»
Maritime SAR"]:::capability
MRS -->|"aims to achieve"| Rec
SitS -->|"aims to achieve"| SA
IRS -->|"aims to achieve"| MSAR
IRS -->|"aims to achieve"| SA
classDef capability fill:#a5ce3a,stroke:#5b7a1f,color:#000
classDef service fill:#de8fc4,stroke:#7B4F7B,color:#000
```
### Funktionelle elementer
Definér ansvar og tilbudte/krævede interfaces for hvert funktionelt element. Opsummér de vigtigste her, og referér til detaljerede modeller efter behov.
| Felt | Beskrivelse |
|---|---|
| Elementnavn | |
| Ansvar | |
| Interfaces – indgående | |
| Interfaces – udgående | |
### Funktionelle scenarier, interaktioner og interfaces
Beskriv de centrale dele af løsningens dynamiske adfærd – fra høj-niveau-forretningsprocesser over event-flows til komponentkald og API'er. Brug et eller flere diagrammer til at vise, hvordan de funktionelle elementer interagerer via deres interfaces.
Eksempel på en **L6 Logical Sequence** (sekvensdiagram):
```mermaid
sequenceDiagram
participant S as «Node» Search
participant SAC as «Node» SAR Asset Controller
participant RV as «Logical Equipment» Onshore Rescue Vessel
S->>SAC: request rescue
SAC->>RV: control rescue
RV-->>SAC: status
SAC-->>S: status
```
### Løsningsdækkende behandling
Definér hvordan al løsningsdækkende behandling (ende-til-ende-flows) håndteres – fx hvordan events i en værdistrøm flyder, eller hvordan event-flow-fejl håndteres på tværs af løsningen.
## Informationsview
Informationsviewet beskriver struktur, semantik, lagring, brug og flow af data i løsningen – samt ejerskab, aktualitet, latens, livscyklus og opbevaring.
### Informationsstrukturmodeller
Definér eller referér arkitektonisk væsentlige datastrukturer for lagrede og transiente data (informations-/datamodeller, event-skemaer). Vis kun de vigtigste entiteter og relationer; udelad ikke-vitale attributter. Brug simple notationer eller forenklede klassediagrammer; referér til store/detaljerede modeller.
**NAF-vejledning:** Brug fx L7 (Information Model) og P7 (Data Model).
### Informationsflowmodeller
Hvis det ikke fremgår af det funktionelle views interaktionsdiagrammer, så definér hvordan data flyder gennem løsningen og til eksterne komponenter. Hold det simpelt.
**NAF-vejledning:** Brug fx L3 (Logical Interactions), L4 (Logical Activities) og P3 (Resource Interactions).
### Informationslivscyklusmodeller
Har nøgleentiteter komplicerede livscykler, så modellér hvordan deres tilstand ændrer sig over tid. Fokusér på få nøgleentiteter, hvis overgange belyser arkitekturen.
**NAF-vejledning:** Brug fx L5 (Logical States) og P5 (Resource States).
### Øvrige informationshensyn
Eksempler på hensyn at adressere: **Informationsejerskab** (hvem ejer hvilke data ved delt ejerskab); **Aktualitet og latens** (hvis data kopieres rundt eller opdateres jævnligt); **Arkivering og opbevaring** (hvordan krav opfyldes).
## Samtidighedsview
Samtidighedsviewet definerer centrale runtime-interaktioner mellem dele af løsningen. Det afdækker synkroniseringsbehov for at undgå race conditions/deadlocks, ressourcekonflikter eller midlertidig inkonsistens (fx "eventual consistency"). Beskriv kun komplekse områder, der er nøgle til at forstå adfærd, eller hvor problemer kan opstå.
### Samtidighedsmodel
Modellér processer, procesgrupper og tråde samt kommunikationskanalerne mellem dem. Du kan også modellere mekanismer, der beskytter integriteten af delte ressourcer.
**NAF-vejledning:** Start med S6 (Service Sequence), L6 (Logical Sequence) eller P6 (Resource Sequence) for at vise timing, og uddyb med komponenter, tilstande og andre elementer efter behov.
### Tilstandsmodel
Modellér de tilstande, runtime-elementerne kan være i, overgangene mellem dem, og de events der driver overgangene. Fokusér på få nøgleelementer, hvis tilstande belyser arkitekturen.
**NAF-vejledning:** Brug fx S5 (Service States), L5 (Logical States) og P5 (Resource States).
Eksempel på en **L5 Logical States**-model (tilstandsdiagram – NAF's strukturelle ejerskab via Node/Organisation er udeladt for overskuelighed):
```mermaid
stateDiagram-v2
[*] --> Waiting: Search Start
Waiting: Waiting for Distress Signal
Determined: Location determined
NeedRescue: In need of rescue
Rescued: Rescued
Waiting --> Determined: receive signal
Determined --> NeedRescue: assistance required
Determined --> Waiting: no assistance required
NeedRescue --> Rescued: crew stable
Rescued --> Waiting: crew secure
Rescued --> [*]: Search Exit
```
## Udviklingsview
Udviklingsviewet definerer løsningens interne arkitektur – for mange løsninger softwarearkitekturen. Det beskriver høj-niveau-strukturer og organisering af softwareudviklingen: arkitekturlag, sikkerhedszoner, design-/build-time-strukturer, moduler, forbrugte services, platforme og biblioteker. Det kan beskrive arbejdsgange (fx DevSecOps) og fælles faciliteter (logging, event-håndtering, API-management, ICAM, SCM).
Eksempel **til inspiration** (frit format – her en CI/CD-pipeline fra en DevOps-platform til miljøer og distributionskanaler):
```mermaid
flowchart LR
dev(["Udvikler"]) -->|push| repo
subgraph devops["DevOps-platform (3. part)"]
repo["Kildekode-repos
frontend / backend"] --> ci["CI: build & test"]
ci --> cd["CD: levering"]
end
cd --> nonprod["Non-production"]
cd --> prod["Production"]
cd --> cdn["CDN (3. part)"]
cd --> stores["App Stores
Google / Apple"]
```
**NAF-vejledning:** Undersøg viewpoints i NAF's *Architecture Foundation* (A-rækken i grid'et) for at afdække områder, der påvirker udviklingsviewet.
### Modeller og beskrivelser for udviklingsviewet
Placér væsentlige modeller her. Forslag: **Modulstruktur** (softwaremoduler og afhængigheder – fx pakkediagram); **Fælles design** (logging, sikkerhed, tracing – fx via designmønster eller kodebibliotek); **Standarder** for design, kode og test (ofte via eksternt dokument); **Kodeorganisering** (mappestruktur, build- og leveringsværktøjer).
## Deploymentview
Deploymentviewet definerer de vigtigste karakteristika ved løsningens driftsmiljø: hvordan løsningen deployeres på tværs af hardware, hosting og runtime-miljøer. Det kan detaljere hardware, netværk og driftskonfigurationer (fx container-baseret deployment) samt softwareafhængigheder (platform-services som ICAM/SCM, kodebiblioteker). Fokus er på arkitektur og design – ikke implementeringsdetaljer, der dokumenteres bedre andetsteds.
Eksempel **til inspiration** (frit format – clients via load balancer ind i et Kubernetes-cluster i et VPC, med eksterne platforme):
```mermaid
flowchart TB
browser["Browser (3. part)
Chrome / Safari / Firefox"] --> lb
mobile["Mobil-app
Android / iOS"] --> lb
subgraph vpc["VPC – production / non-production"]
lb["Public Load Balancer + firewall"] --> k8s["Kubernetes-cluster
microservices · message broker
databaser · observability"]
k8s --> nat["NAT"]
nat --> az1["Availability Zone 1"]
nat --> az2["Availability Zone 2"]
nat --> az3["Availability Zone 3"]
end
devops["DevOps-platform (3. part)"] -->|"deploy artifacts"| k8s
k8s -->|"observability"| obs["Observability-platform (3. part)"]
ops(["Engineers / Support"]) -->|"drift"| lb
```
**NAF-vejledning:** Brug P8 (Resource Constraints) til generelle fysiske ressource-begrænsninger (platforme, netværk, sikkerhedszoner), og A8 (Architecture Standards) til softwarestandarder og -afhængigheder.
### Runtime-platformmodel
Vis løsningens runtime-platform (nodes, links og mapping af funktionelle elementer/processer til nodes). Brug et deployment-diagram eller et simplere boxes-and-lines-diagram.
**NAF-vejledning:** Brug P2 (Resource Structure) og P3 (Resource Interactions).
### Softwareafhængigheder
Definér den software, der kræves på de forskellige nodetyper (cloud-platform, platform-services, OS, systemsoftware, biblioteker). Præsenteres ofte i tabelform.
### Netværksmodel
Er netværkskravene komplekse, så medtag en netværksmodel med nodes, links og netværkshardware – og gør quality-of-service-krav tydelige.
## Driftsview
Driftsviewet fokuserer på den tilsigtede drift og vedligehold: hvordan løsningen installeres/deployeres i produktion, hvordan data migreres, og hvordan den konfigureres, styres, overvåges og supporteres. Beskriv ikke detaljerede procedurer eller information, der hører hjemme andetsteds (fx "Løsningsdesign"-dokumentet).
Overvej: værktøjer/processer/metrikker til pålidelig drift; konfigurationsstyring, systemadministration og incident-support; release-strategier (feature flags, canary, blue-green); overvågning, logging og alerting (kobling til Service Control & Management, SCM); backup, recovery, failover, disaster recovery; datamigrering og evt. periodisk synkronisering/parallel drift.
**NAF-vejledning:** Brug fx Pr (Resource Roadmap) for konfigurationsstyring af løsningen og A6 (Architecture Versions) for arkitekturstyring. Brug Cr (Capability Roadmap) og Sr (Service Roadmap) til migreringsplanlægning, og A8 (Architecture Standards) for administrative standarder.
## Andre views
Dokumentér øvrige views her efter behov.
# Kapitel 6: Arkitekturperspektiver
Dette kapitel forklarer, hvordan arkitekturen opfylder hver af de krævede kvalitetsegenskaber. Meget vil være indlejret i viewene ovenfor, men hvor en kvalitet (fx sikkerhed eller performance) afhænger af features i flere views, så saml det her. Behandles kvaliteterne som ikke-funktionelle krav, kan det være nok at referere til projektets NFR-dokumentation.
**NAF-vejledning:** Kvalitetsperspektiver dækker oftest flere viewpoints.
## Sikkerhed
Sikkerhedsperspektivet sikrer, at løsningen er beskyttet mod uautoriseret adgang, angreb og databrud, og opretholder integritet, fortrolighed og tilgængelighed. Beskriv nøglemekanismer og -mønstre, fx hvordan løsningen bruger zero-trust-paradigmet, og hvilke konkrete services den bruger til at realisere mønsteret.
### Fortrolighed
### Integritet
### Tilgængelighed
## Performance og skalerbarhed
Beskriv de ønskede performance- og skalerbarhedsegenskaber:
- Hvordan håndteres normal- og spidsbelastning?
- Hvordan håndteres DDIL-forhold (Disrupted, Degraded, Intermittent, Low-Bandwidth)?
- Hvordan skaleres ved vækst i data, brugere eller processeringsbehov?
## Tilgængelighed og robusthed
Sikrer, at løsningen er pålideligt tilgængelig og bevarer kritiske data over tid – via redundans, failover-mekanismer og backups, der minimerer nedetid og beskytter mod katastrofale fejl.
## Evolution
Sikrer, at løsningen kan tilpasse sig skiftende krav, teknologier og forretningsmiljøer – via modularitet, styring af afhængigheder og iterative opdateringer.
## Øvrige kvaliteter
Dokumentér andre relevante kvalitetsperspektiver, fx **tilgængelighed/accessibility**, **internationalisering/lokalisering**, **lokation** (geografisk placering), **regulering/compliance** og **brugbarhed/usability**.
# Appendiks
## Appendiks: Beslutninger og alternativer
Forklar de primære arkitektoniske designbeslutninger, deres rationale og de overvejede alternativer. Referér til relevante Architectural Decision Records (ADR'er) fra arkitekturstyringen.
## Appendiks: Spørgsmål og svar
Saml tilbagevendende spørgsmål og svar her. Det kan også bruges til spørgsmål, du ønsker, at læserne stiller sig selv for at sikre forståelse.
## Appendiks: Referencer
- *Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives*, 2. udgave. Nick Rozanski og Eoin Woods, Addison Wesley, 2011.
- *NATO Architecture Framework Version 4.1*. NATO Architecture Capability Team, Digital Policy Committee, 2026.02. Se [NAF 4.1 i VIDAR](/arkitekturbibliotek/standarder/rammevaerk/naf/4-1/).
- *ISO/IEC/IEEE 42010:2022 — Software, systems and enterprise — Architecture description.*
- *The Open Group Architecture Framework (TOGAF) Version 9.1.*
- Viewpoints and Perspectives: `https://www.viewpoints-and-perspectives.info`