Forsvaret med egen data-grunnlov

Silje Rognsvåg · article · 2026-08-18 Reader 🖥️

Cloud Vendor Portability & Lock-in Avoidance Data Mesh & Data Products Public-Sector Digitalization

The Norwegian Armed Forces are building a 'data constitution' (FDSA) that makes data — not the technology or vendor processing it — the stable core of digital infrastructure, so that suppliers can be swapped without disruption; Norway's Digitalization Minister argues this same data-centric logic should extend to the rest of the public sector.

practical · expository — Short news brief (~312 words) reporting a panel talk and a minister's remarks at Arendalsuka. Mostly expository (relaying quotes and bullet-point mechanics), but practical in thrust: it argues, via Markussen and Minister Tung, for adopting a specific architectural posture (data-centric, vendor-neutral) — first in the Armed Forces, then across the public sector. No argumentative development beyond assertion + analogy; sections are thin given the length.

Structure

Part	Role
Opening quotes from Bjørn Tore Markussen (Forsvaret's tech/IKT director) on the unpredictability of future decisive technology (AI models, NATO requirements)	context/motivation
"Som å holde på telefonnummeret" — the goal (avoid vendor dependency) stated via the number-portability analogy, plus the core slogan 'technology should be exchangeable, data should not'	evidence/explanation — the persuasive core of the piece
"Åpen arkitektur" — bullet-point mechanics of how FDSA works (data-first, standardized interfaces/products, attached security/access rules, easier vendor switching)	mechanism sketch
"Aktuelt også for andre" — Minister Karianne Tung generalizes FDSA's relevance beyond Forsvaret, ties it to the Dataforvaltningsloven, and the Auditor General adds an independent call for better public-sector data flow	conclusion/extension — elevates FDSA from an internal defense project to a proposed public-sector template

Key terms

data-grunnlov (data constitution)
An informal, constitution-like framing for FDSA — a foundational, durable set of data rules meant to outlast changes in technology and vendors, in contrast to an ordinary IT policy or architecture standard that gets revised alongside the tech stack.
Forsvarets datasentriske arkitektur (FDSA) / data-centric architecture
An architecture where data is the stable, primary organizing unit — decoupled from the systems that produce or consume it, exposed via standardized interfaces and products, carrying its own security/access/sharing rules — while the technology and vendors sitting on top of the data remain freely replaceable.
utbyttbar (exchangeable)
The property Markussen wants for technology specifically — swappable without disrupting the underlying data — paired against data, which he explicitly says should NOT be exchangeable/mutable in the same way (it should remain stable, standardized, and portable across whichever technology processes it).

Propositions

explicitIt is not possible to predict which technologies (AI models, NATO requirements, etc.) will be decisive for operational capability five to ten years from now, so digital transformation cannot be architected around today's technology.conf: high
explicitDigital architecture should instead be built around what persists when technology changes — i.e., around the data layer rather than the current technology stack.conf: high
explicitFDSA's goal is to avoid dependencies and lock-in to specific vendors: the technology should be exchangeable, the data should not.conf: high
extends7) Stine Haugseth: Insourcing, retning og strategi på en ølbrikke · p17 — Haugseth named beredskap and geopolitisk lock-in as reasons finance is moving toward fallback-løsninger/exit-strategi from cloud vendors; Forsvaret's FDSA operationalizes exactly that same logic as formal, named architecture, and Minister Tung explicitly proposes generalizing it beyond one regulated sector to the whole public sector.
supportsPresentation: Clean Architecture for Serverless: Business Logic You Can Take Anywhere · p4 — Both converge on the same architectural move — isolate the stable, portable core (data / business logic) from the volatile, vendor-specific periphery (technology / infrastructure layer) — to buy switching freedom, in a defense-architecture context rather than a serverless-coding context.
implicitPublic and private sector organizations today typically do the opposite of FDSA's principle — they lock in data to vendor systems while treating the underlying technology choice as comparatively fixed.conf: medium
explicitState-imposed interoperability standards (illustrated by the number-portability mandate on telecom operators) can achieve vendor-independence that market forces alone did not produce, and this same logic can be self-imposed institutionally.conf: high
explicitFDSA's operating principles are: data comes first and stands independent of systems; data is shared via standardized interfaces and products, uniformly understood by all consumers; and security, access, and sharing rules travel attached to the data itself.conf: high
supportsPresentation: Autonomous Data Products for the Autonomous Era: Rethinking Data Architecture for GenAI · p4 — FDSA's principle that data 'stands free of systems' and is shared via standardized interfaces/products carrying their own security/access rules mirrors the autonomous-data-product abstraction (data + metadata + access behind one interface) — the same design pattern applied to national-security infrastructure rather than enterprise AI/agent consumption.
explicitThe data-centric architecture principle is relevant beyond the Armed Forces and should draw interest from the wider public sector.conf: high
explicitThe recently passed Data Management Act (Dataforvaltningsloven) shares FDSA's underlying logic, suggesting legislative momentum toward this data-centric model nationally.conf: medium
explicitThe public sector needs better data flow between its constituent parts — a claim made independently by the Auditor General, not tied specifically to endorsing FDSA.conf: medium

Arguments

Forsvaret's (and by extension, other public-sector) digital architecture should be organized around durable, standardized, vendor-neutral data rather than around current technology or vendor choices. strength: medium

Explicit premises:

Future decisive technology is unpredictable over a 5-10 year horizon.
Data can in principle be kept stable and standardized independent of whichever technology or vendor processes it.
Today's vendor lock-in happens because data — not just technology — gets bound to specific systems.

Implicit premises:

Decoupling data from application/vendor technology is technically achievable at the scale of a national defense organization working with NATO, NSM, and FFI — the article treats this as a design choice rather than an open engineering problem.
Vendor switchability is valuable enough (implicitly for operational resilience/beredskap) to justify the cost of building and enforcing a formal 'data constitution.'
An institution can self-impose a regulatory-style mandate (as the state once imposed number portability on telecom operators) and have it hold with comparable force, even without external legal compulsion.

Inferences:

If FDSA succeeds, today's dominant technology and cloud/AI vendors become substitutable within defense-relevant infrastructure — a geopolitically loaded implication (reduced dependence on incumbent, often foreign, vendors) that the article gestures at (NATO, NSM involvement; 'KI-modeller' as an example of unpredictable future tech) but never states directly.

Narratives

The number-portability analogy — being able to keep your phone number when switching telecom operator, which wasn't possible before the state mandated it of the industry.
→ Carries the article's central persuasive move: it recasts an abstract, hard-to-visualize architecture principle (data-centric, vendor-neutral infrastructure) into a concrete, universally-experienced precedent, making FDSA's vendor-independence goal feel both intuitive and achievable via regulation-style precedent rather than purely technical argument.

Questions addressed

✅ How can Forsvaret build digital infrastructure that survives being wrong about which technology or vendor will matter in 5-10 years?
Answered at the level of strategic direction (build around data, not technology) via FDSA, but the actual engineering/enforcement mechanism is only sketched in bullet points and explicitly deferred — 'flere detaljer kommer på Forsvarets leverandørkonferanse 5. oktober' — so resolution is directional, not implemented.
⭕ How will existing legacy systems and current vendor contracts be transitioned or retrofitted into this data-centric model?
Not addressed at all — the article only describes the target-state principles, not a migration path from the current state.

Gaps

incompleteNo mechanism is given for how FDSA's vendor-neutrality will actually be enforced or verified. 'Standardized interfaces and products' is asserted, but nothing shows that switching a real defense-relevant vendor (cloud provider, sensor system, AI model supplier) would in practice be low-cost rather than merely relabeled lock-in — the same tooling-level-vs-artifact-level portability gap this corpus has already flagged elsewhere.
Read next: Read extract-clean-architecture-for-serverless (its gap on Terraform CDK's 'tooling portability ≠ infrastructure portability' distinction applies almost directly here) or Gregor Hohpe on multi-cloud exit costs, before taking FDSA's vendor-independence claim as demonstrated rather than aspirational.
incompleteThe article never states the geopolitical/beredskap driver explicitly — NATO and NSM involvement gesture at it, but the reader is left to infer whether this is driven by the war in Ukraine, concern about foreign (especially US) tech-vendor dependency, cloud-sovereignty debates, or purely internal efficiency goals. This is a sharper version of the same gap the corpus flagged for a finance-sector parallel (beredskap and geopolitisk lock-in as explicit drivers of exit-strategy work).
Read next: Read NSM/PST/E-tjenesten public risk assessments on tech-vendor dependency in critical infrastructure, or follow-up Kode24/Digital Norway coverage of the October 5 leverandørkonferanse, for the strategic rationale FDSA's public unveiling doesn't spell out.
incompleteMinister Tung's claim that the Dataforvaltningsloven shares FDSA's 'logic' is asserted via a single sentence, not demonstrated — the article doesn't explain what the law actually requires or how closely it maps onto data-centric architecture principles (standardized interfaces, data-attached security rules, vendor exchangeability), leaving the reader unable to judge whether this is a genuine policy convergence or a rhetorical bridge built for the Arendalsuka panel debate.
Read next: Read the Dataforvaltningsloven text or Digitaliseringsdirektoratet's guidance on it to assess actual overlap with FDSA's principles.