Løsningsarkitekturbeskrivelse (skabelon)

Skabelon for løsningsarkitekturbeskrivelse i Program DOT – Views with Perspectives integreret med NAF v4.1
Skabelon Skabelon ejer DOT
Skabelonversion
0.1
Status
Udkast
Sidst opdateret
april 2026
Relevante roller
Arkitekt, Projektleder
Download skabelon (Markdown)

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.
  • 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:

flowchart TB
    user1(["Bruger"]):::actor
    user2(["Bruger"]):::actor
    ext1["Eksternt system<br>eller organisation"]:::ext
    ext2["Eksternt system<br>eller organisation"]:::ext
    ext3["Eksternt system<br>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):

flowchart BT
    MRS["«Service»<br>Maritime Recovery Service"]:::service
    SitS["«Service»<br>Situational Service"]:::service
    IRS["«Service»<br>Inshore Rescue Service"]:::service
    Rec["«Capability»<br>Recovery"]:::capability
    SA["«Capability»<br>Situational Awareness"]:::capability
    MSAR["«Capability»<br>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):

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):

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):

flowchart LR
    dev(["Udvikler"]) -->|push| repo
    subgraph devops["DevOps-platform (3. part)"]
        repo["Kildekode-repos<br>frontend / backend"] --> ci["CI: build &amp; test"]
        ci --> cd["CD: levering"]
    end
    cd --> nonprod["Non-production"]
    cd --> prod["Production"]
    cd --> cdn["CDN (3. part)"]
    cd --> stores["App Stores<br>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):

flowchart TB
    browser["Browser (3. part)<br>Chrome / Safari / Firefox"] --> lb
    mobile["Mobil-app<br>Android / iOS"] --> lb
    subgraph vpc["VPC – production / non-production"]
        lb["Public Load Balancer + firewall"] --> k8s["Kubernetes-cluster<br>microservices · message broker<br>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.
  • 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