Arkitektur, der kan deles med allierede, forstås af direktionen og bruges i beslutninger
Når en organisation i forsvarsdomænet skal beskrive sine kapabiliteter, systemer og informationsstrømme på en måde, som kan forstås på tværs af nationer, myndigheder og leverandører, er NATO Architecture Framework (NAF) det fælles sprog. EA Fellows arbejder med NAF version 4.1 som formel arkitekturstandard i vores forsvars- og beredskabsopgaver, og vi kobler standarden til en styringstænkning, der gør arkitekturen brugbar i praksis. Denne side beskriver, hvad NAF er, hvordan vi anvender det, og hvordan det spiller sammen med vores egne rammeværker LEAF og EA⁶ Cube.
Hvad NAF v4.1 er
NAF er NATOs standard for at udvikle og beskrive arkitekturer. Standarden er udviklet til, at arkitekturer fra forskellige organisationer kan forstås, sammenlignes, begrundes og relateres til hinanden. Det grundlæggende problem, NAF adresserer, er velkendt: systemer, der er anskaffet hver for sig, kan godt være forbundne uden at være interoperable, og så udebliver de gevinster, man havde regnet med i form af hastighed, fleksibilitet og omkostningsreduktion.
NAF v4 består af fire dele, der hænger sammen:
| Del | Indhold | Hvad det giver |
|---|---|---|
| Metodik | Otte arkitekturstadier på enterprise- og projektniveau, styret af arkitekturens motivationsdata (vision, mål, drivere, principper) | En fælles arbejdsgang for at etablere, beskrive, evaluere og styre arkitektur |
| Viewpoint-grid | Et todimensionelt gitter af standardiserede viewpoints ordnet efter emne (rækker) og aspekt (kolonner) | Et fælles katalog over, hvilke arkitekturbeskrivelser der findes, og hvad de skal indeholde |
| Metamodel | Realisering gennem kommercielle metamodeller: ArchiMate og UAF DMM. NISP angiver, hvilke versioner der kræves for compliance | Værktøjsuafhængighed og genbrug af eksisterende modelleringskompetencer |
| Glossary og referencer | Fælles terminologi forankret i ISO/IEC/IEEE 42010 | Præcision i sproget, når arkitektur skal deles på tværs af organisationer |
Version 4.1, udgivet i marts 2026, er den mest gennemgribende revision siden v4 blev introduceret. Den indfører NAF Information Model som konceptuelt fundament for alle viewpoints, tilføjer formål og scope for hvert enkelt viewpoint, og omdøber en række viewpoints, så navnene bedre afspejler indholdet. L7 hedder nu Information Model, P7 Data Model, A7 Architecture Compliance, og roadmap-viewpoints hedder konsekvent Capability Roadmap (Cr), Service Roadmap (Sr), Logical Roadmap (Lr), Resource Roadmap (Pr) og Architecture Roadmap (Ar). Rækken for arkitekturens egne metadata er omdøbt fra Architecture Meta-Data til Architecture Foundation. Alle eksempler i standarden bygger på et gennemgående Search and Rescue-scenarie, der viser samspillet mellem civile og militære aktører.
Gridet: NAFs vigtigste bidrag
Det mest praktiske bidrag i NAF v4 er viewpoint-grid’et. Det organiserer arkitekturbeskrivelser efter, hvad de handler om, og hvilket aspekt de belyser.
| Række (emne) | Hvad rækken beskriver |
|---|---|
| C: Concepts | Kapabiliteter, effekter, strategi og vision. Det, organisationen skal kunne |
| S: Service | Tjenester, deres grænseflader, funktioner og politikker. Det, der tilbydes |
| L: Logical | Logiske noder, roller, informationsudveksling og processer. Det, der sker uafhængigt af konkret teknologi |
| P: Physical Resource | Systemer, ressourcer, konfigurationer og datamodeller. Det, der faktisk er anskaffet og drives |
| A: Architecture Foundation | Metadata, arkitekturprodukter, standarder, compliance og den samlede roadmap |
Kolonnerne skærer på tværs: Taxonomy (hierarkier), Structure (opbygning), Connectivity (forbindelser og afhængigheder), Behaviour (processer, tilstande og sekvenser), Information, Constraints (regler) og Roadmap (tidsdimensionen). Hver celle er et viewpoint med eget formål, scope og anbefalet repræsentation.
Pointen med grid’et er ikke, at man skal udfylde alle celler. NAF siger udtrykkeligt, at udvælgelsen af viewpoints skal tilpasses den konkrete opgave, og at yderligere viewpoints kan defineres, hvis interessenternes bekymringer kræver det. Grid’et er et kort over, hvad der kan beskrives, ikke en tjekliste over, hvad der skal.
Metodikken: fra motivation til styring
NAFs metodik grupperer arkitekturarbejdet i otte stadier, der besøges iterativt: etablering af arkitekturlandskabet, arkitekturvision, beskrivelse af alternativer, evaluering og trade-off, migrationsplan, styring af anvendelsen, beslutning om ændringer og vedligehold af motivationsdata og dashboard. Metodikken findes i to udgaver, en for enterprise-niveauet og en for projektniveauet, og NATOs egen EA-politik indskyder et kapabilitetsniveau imellem dem.
Et centralt træk er, at arkitekturprincipper er placeret som den første aktivitet i etableringen af landskabet, og at principperne skal have navn, statement, rationale og implikationer. Det er den struktur, EA Fellows følger, når vi formulerer principper for vores kunder. Et andet centralt træk er, at arkitektur i NAF ses som en teknik til at håndtere kompleksitet, ikke som en aktivitet for at producere modeller. Arkitekturer skal, som standarden formulerer det, omsætte strategi til styrbar og eksekverbar forandring.
Hvorfor NAF ikke står alene
NAF er et fremragende beskrivelsessprog og en solid metodisk ramme, men det svarer ikke i sig selv på tre spørgsmål, som enhver chefarkitekt stilles over for:
- Hvor lidt kan vi nøjes med? NAF definerer over 40 viewpoints. En teknologifunktion med begrænsede arkitekturressourcer har brug for et minimumssæt, der løfter modenheden hurtigt.
- Hvor modne er vi, og hvornår er arkitekturen i brug? NAF beskriver, hvad der skal produceres, men ikke hvordan man måler, om det faktisk bruges i beslutninger.
- Hvordan hænger det sammen med organisationens øvrige styring? Kapabiliteter, systemer og tjenester skal ses i sammenhæng med organisationsstruktur, risiko, værdi og kompetencer, hvis arkitekturen skal have styringskraft.
Det er disse tre huller, EA Fellows fylder ud. Vi bruger NAF som den formelle standard og lægger tre komplementære lag oven på: et modenhedsmål (DYA Architecture Growth Model), en fælles referencetaksonomi (NATO C3 Taxonomy) og en styringslinse (EA⁶ Cube). Tilsammen udgør de en praksis, hvor vi siger: ingen leverance uden ramme, og ingen overlevering uden anbefaling.
LEAF: NAF sat i drift i en teknologifunktion
LEAF (Landdivisionens Enterprise Architecture Framework) er det rammeværk, EA Fellows har udviklet sammen med chefarkitektfunktionen i Forsvarsministeriets Materiel- og Indkøbsstyrelses Landdivision. LEAF viser, hvordan NAF kan tilpasses en konkret teknologifunktion, der arbejder med førings- og informationssystemer som Battle Management System (BMS), Danish Integrated C4 Environment (DIC4E) og Cross Domain Solutions (CDS), hvor interoperabilitet med allierede og sikker datadeling på tværs af klassifikationsniveauer er designpræmisser.
LEAF integrerer fire rammeværker med hver sin rolle:
| Rammeværk | Rolle i LEAF |
|---|---|
| NAF v4.1 | Formel arkitekturstandard: viewpoints, arkitekturstadier og ArchiMate-notation |
| EA⁶ Cube | Styrings- og analyselinse: kobler arkitekturen til organisation, risiko, værdi, kompetencer og produkter |
| DYA Architecture Growth Model | Modenhedsmålestok: niveau A (findes og bruges), B (bruges i beslutninger), C (integreret i styring) |
| NATO C3 Taxonomy (Baseline 7) | Referencetaksonomi for kapabiliteter, tjenester, roller og informationsprodukter |
Kernen i LEAF er et “just enough”-sæt af arkitekturartefakter, hver med tydelig ejer, opdateringsrytme, NAF-viewpoint og DYA-kriterier. Artefakterne implementeres i tre bølger, hvor bølge 1 udgør et minimumssæt, der typisk kan etableres på 8 til 12 uger. Dette sæt kunne for eksempel se ud som nedenfor:
| # | Artefakt | NAF v4.1-viewpoint | Bølge |
|---|---|---|---|
| 1 | Capability map | C1 Capability Taxonomy, C2 Enterprise Vision (+ Cr) | 1 |
| 2 | Systemportefølje | S1 Service Taxonomy (+ Sr) | 1 |
| 3 | Solution data model | L7 Information Model, P7 Data Model | 2 |
| 4 | Interface-katalog med information exchange | S3 Service Interfaces, L3/P3 Interaction | 1 |
| 5 | Deployment view | P1 Resource Taxonomy, Pr Resource Roadmap | 2 |
| 6 | Standards profile | A8 Standards | 3 |
| 7 | Security profile | A7 Architecture Compliance, L8/P8 Constraints | 1 |
| 8 | Arkitekturprincipper | Ar Architecture Roadmap, A3 Architecture Correspondence | 2 |
| 9 | Roadmap | Ar (+ Cr, Sr, Lr) | 1 |
| 10 | Patterns-katalog | L3, S3 | 3 |
| 11 | Governance- og compliance-matrix | Ar samt C3 Business Roles og Business Processes | 1 |
Hertil kommer tre understøttende artefakter: Business Outcome Statement, Architecture Decision Record og System Context View. Alle artefakter forankres i et arkitekturforum, der fungerer som review- og beslutningsorgan, og klassifikationsniveau behandles som en primær arkitekturel driver, ikke som en formatering, der tilføjes til sidst.
Det, LEAF demonstrerer, er, at NAF-konformitet og pragmatisme ikke udelukker hinanden. Hvert artefakt kan læses af en NATO-arkitekt, fordi det følger standardens viewpoints, og det kan læses af en direktør, fordi det er skrevet beslutningsklart med tabeller frem for punktlister og med klar angivelse af, hvilken beslutning artefaktet understøtter.
EA⁶ Cube og NAF: to rammeværker, der supplerer hinanden
EA⁶ Cube er det enterprise architecture-rammeværk, John Gøtze har udviklet i forlængelse af Scott Bernards EA³-tradition, og som undervises på Carnegie Mellon Universitys certificeringsprogram i enterprise architecture. Kuben har seks sider, der hver repræsenterer en dimension af organisationsdesign: struktur (1), funktion (2), risiko (3), værdi (4), mennesker (5) og produkter og tjenester (6), lagt omkring en kerne af fem arkitekturlag fra strategiske mål til infrastruktur.
Hvor NAF beskriver arkitekturen i dybden, beskriver EA⁶ den i bredden. NAFs rækker (Concepts, Service, Logical, Physical) svarer i store træk til EA⁶’s arkitekturlag, men EA⁶ tilføjer de perspektiver, som en styringsbeslutning altid indeholder: Hvem ejer det? Hvad kan gå galt? Hvad er det værd? Hvem har kompetencerne? Hvad leverer det til brugerne?
| EA⁶-side | Spørgsmål | Typiske NAF-viewpoints, der besvarer det |
|---|---|---|
| Face 0: Arkitekturlag | Hvordan hænger strategi, proces, data, systemer og infrastruktur sammen? | C2, L7, P7, P1, A8 |
| Face 1: Struktur | Hvem ejer og styrer? | L4 Logical Activities (roller), Ar, governance-matrix |
| Face 2: Funktion | Hvad skal organisationen kunne? | C1, C4, C5 Effects |
| Face 3: Risiko | Hvad kan gå galt, og hvilke regler gælder? | A7, L8, P8, C8 Planning Constraints |
| Face 4: Værdi | Hvad er investeringen værd, og hvornår realiseres den? | C7 Performance Criteria, Cr, Ar |
| Face 5: Mennesker | Hvem har kompetencerne? | C1 koblet til P1 (personelressourcer), L4 |
| Face 6: Produkter og tjenester | Hvad tilbydes, og hvordan hænger det sammen? | S1, S3, L3, P3 |
Koblingen bliver operationel gennem EA⁶’s komposit-viewpoints (CV). Et komposit-viewpoint vælger tre sider af kuben og besvarer en sammensat styringsbekymring, for eksempel “porteføljestyring”, “risikojusteret anskaffelse” eller “afbetaling af teknisk gæld”. I LEAF oversætter vi hvert komposit-viewpoint til en sekvens af NAF-arkitekturstadier og en konkret pakke af NAF-viewpoints. På den måde er hver leverance både styringsmæssigt forankret (via EA⁶) og formelt arkitekturkonform (via NAF).
Et eksempel: Skal en kunde afstemme sine kapabiliteter mod NATOs C3-taksonomi og prioritere investeringer, arbejder vi i komposit-viewpointet for funktion, værdi og produkter. NAF-leverancen bliver C1 og C2 (kapabiliteter og vision), C5 (effekter), C7 (præstationskriterier) og Cr/Ar (roadmap). Direktionen får et beslutningsgrundlag; NATO-partnere får arkitektur i et format, de genkender.
NAF uden for forsvaret
Selvom NAF er udviklet af NATO, er standarden eksplicit designet til både militære og civile arkitekturer. Den bygger på ISO/IEC/IEEE 42010 og realiseres i ArchiMate, som er de facto-standard for enterprise architecture i den offentlige sektor i Danmark og Europa. Det gør NAF direkte anvendeligt uden for det snævre forsvarsdomæne:
- Kritisk infrastruktur og beredskab. Organisationer omfattet af NIS2, herunder nationale CSIRT-funktioner, forsyning og transport, har brug for arkitekturbeskrivelser, der kan deles med samarbejdspartnere og tilsynsmyndigheder. NAFs viewpoints for tjenester, informationsudveksling og constraints er skabt til præcis det.
- Totalforsvar og civil-militært samarbejde. Når civile myndigheder skal kunne arbejde sammen med Forsvaret, er NAF det sprog, der gør begge parters arkitektur læselig for den anden.
- Leverandører til forsvarsindustrien. Virksomheder, der leverer til FMI eller NATO, møder krav om NAF-konforme arkitekturbeskrivelser i udbud og kontrakter. Vi hjælper med at forstå kravene og levere arkitektur, der opfylder dem.
- Store offentlige it-porteføljer. NAFs enterprise-metodik med arkitekturlandskab, migrationsplan og governance af anvendelsen er en moden alternativ eller supplement til TOGAF ADM, især hvor kapabilitetsplanlægning og roadmapping står centralt.
For os er NAF ikke et forsvarsrammeværk. Det er et interoperabilitetsrammeværk, der tilfældigvis er udviklet i en sammenhæng, hvor interoperabilitet er et spørgsmål om liv og død, og som derfor er blevet usædvanligt gennemtænkt.
Sådan arbejder vi konkret
EA Fellows leverer NAF-baseret arkitektur i fire typer af opgaver:
| Opgave | Hvad vi leverer | Typisk varighed |
|---|---|---|
| Etablering af arkitekturfunktion | Tilpasset rammeværk (som LEAF), artefaktkatalog, principper, governance-model og modenhedsbaseline | 3 til 6 måneder |
| Minimumssæt af artefakter | Capability map, portefølje, interface-katalog, security profile, roadmap og governance-matrix i NAF-konform form | 8 til 12 uger |
| Review og kvalitetssikring | Struktureret gennemgang af eksisterende arkitektur eller leverandørleverancer mod NAF, C3 Taxonomy og kundens egne principper, med prioriterede fund og handlingsplan | 2 til 4 uger |
| Undervisning og kompetenceopbygning | Kurser og workshops i NAF v4.1, ArchiMate, C3 Taxonomy og EA⁶, herunder rolleprofiler for arkitekter | Efter aftale |
Fælles for alle opgaver er nogle faste arbejdsprincipper. Vi skriver på dansk, medmindre modtagerne kræver engelsk, og følger da britiske stavekonventioner som NAF selv. Vi bruger tabeller frem for punktlister til matricer, kriterier og milepæle, fordi tabeller kan læses hurtigt af beslutningstagere. Vi behandler klassifikation som en arkitekturel driver fra første dag. Og vi anser enhver arkitekturleverance, der ikke eksplicit er forankret i et rammeværk, en taksonomi og et modenhedsmål, for at være ufærdig.
Kom i gang
Overvejer I at indføre NAF, står I over for krav om NAF-konform arkitektur i et udbud, eller vil I have et eksternt blik på jeres eksisterende arkitekturpraksis? Vi begynder typisk med en kort afklaring af, hvilke beslutninger arkitekturen skal understøtte, og hvilke interessenter der skal kunne læse den. Derfra udpeger vi de viewpoints, der faktisk gør en forskel.
Kontakt EA Fellows på naf@eafellows.com for en indledende samtale.