Die urgentie is begrijpelijk. Maar de suggestie dat digitale soevereiniteit iets is wat je snel “regelt” door van platform of cloud te wisselen, is misleidend. Soevereiniteit is geen eindstaat die je bereikt met één besluit. Het is het resultaat van een reeks bewuste ontwerpkeuzes, gemaakt over een langere periode.
Digitale soevereiniteit is geen sprint, maar een ontwerpkeuze
Digitale soevereiniteit is in korte tijd uitgegroeid tot een dominant thema. Kranten, nieuwsbrieven en beleidsstukken wekken de indruk dat we ons op een kantelpunt bevinden: wie nu niet handelt, loopt onherroepelijk vast in afhankelijkheid van buitenlandse leveranciers en geopolitieke krachten.
"Soevereiniteit begint niet bij de cloud waar je draait, maar het is de architectuur die bepaalt of je op de goede weg bent."
Waar gaat het over?
Een belangrijk deel van de verwarring ontstaat doordat digitale soevereiniteit vaak als één ding wordt gepresenteerd, terwijl het in werkelijkheid meerdere vragen tegelijk raakt. Wie heeft zeggenschap over data en infrastructuur? Wie kan technisch of juridisch toegang afdwingen? Welke wetgeving is van toepassing? En misschien wel de meest onderschatte vraag: hoe eenvoudig kun je weg als omstandigheden veranderen?
Zodra deze vragen expliciet worden gesteld, wordt duidelijk dat “Europese cloud”, “on-premises” of “goedkoop en dichtbij” geen garanties zijn. Een Cloud omgeving in Europa kan juridisch alsnog onder buitenlandse wetgeving vallen. Een goedkope infrastructuur kan afhankelijkheden introduceren in kennis, ondersteuning of continuïteit. En maximale kostenoptimalisatie betekent vrijwel altijd het accepteren van strategische afhankelijkheden.
Digitale soevereiniteit gaat dus niet over één juiste keuze, maar over het bewust afwegen van controle, kosten, snelheid en risico.
Van paniek naar richting
De neiging om in reactie op de hype alles in één keer te willen vervangen, is begrijpelijk maar zelden verstandig. Applicaties vervangen is zichtbaar, maar pakt zelden de kern van afhankelijkheid aan. Die zit meestal dieper: in koppelingen, datastromen, impliciete definities en ontbrekende governance.
Daarom is het zinvoller om digitale soevereiniteit te benaderen als een richtinggevend principe: niet “we moeten nu soeverein zijn”, maar “elke beslissing die we vanaf nu nemen, vergroot of verkleint onze toekomstige handelingsvrijheid”.
Waar de echte hefboom zit
Wie serieus werk wil maken van digitale soevereiniteit, begint niet bij applicaties, maar bij de fundamenten:
- integraties die losstaan van leverancier specifieke technologie,
- data die niet opgesloten zit in één platform of één applicatielogica,
- expliciete API-contracten en datadefinities,
- governance op datastromen en verantwoordelijkheden, niet alleen op systemen.
Dit zijn geen ideologische keuzes, maar vormen van risicomanagement. Ze bepalen of een organisatie kan meebewegen als wetgeving verandert, leveranciers verdwijnen of politieke omstandigheden verschuiven.
"Een organisatie die haar integraties, data en governance niet op orde heeft, zal ook in een 'soevereine cloud' afhankelijk blijven."
Compliance is niet het einddoel
Regelgeving zoals AVG, NIS2 en initiatieven rond Europese cloud-principes helpen om afhankelijkheden zichtbaar te maken. Maar compliance is geen bewijs van soevereiniteit; het is hooguit het minimale niveau van verantwoord handelen. Echte soevereiniteit vraagt dat organisaties zélf begrijpen waar hun kwetsbaarheden zitten en daar architectonisch op sturen.
Digitale soevereiniteit vraagt geen paniekreacties, maar consistent ontwerp. Niet één grote migratie, maar een reeks bewuste keuzes over integratie, data en governance. Organisaties die dat pad volgen, hoeven niet morgen “soeverein” te zijn. Ze bouwen wel elke dag aan het vermogen om te kiezen en dát is waar soevereiniteit uiteindelijk over gaat.
Kees Verhoeven: keynote speaker op Connecting Everything
Op 5 maart verzorgt Kees Verhoeven, onafhankelijk tech-expert en voormalig Kamerlid namens D66 en auteur van artikelen over de digitale toekomst van Europa en verantwoordelijk voor de uitspraak ‘Decennialang zwommen we vrolijk een digitale fuik in’ de closing keynote met de titel “Technologie, ethiek & gedrag“ tijdens Connecting Everything: De data en integratie Summit van Enable U.
Schrijf u vandaag nog in!
Plaats een reactie
U moet ingelogd zijn om een reactie te kunnen plaatsen.
Goed artikel! Soevereiniteit is natuurlijk geen doel op zich, maar een richtinggevend principe dat de handelingsvrijheid van een organisatie (in dit geval een cluster publiek-rechterlijke organisatie die samen de Staat vormen, dus dan is soevereiniteit wel prettig) waarborgt: het behouden van controle over data, processen en systemen in een wereld van toenemende afhankelijkheden. Je zult die afhankelijkheden dus (met terugwerkende kracht) in beeld moet zien te krijgen. We zouden meteen kunnen beginnen door de huidige IT-architectuur nou eens te zien voor wat het is: organisch gegroeide spaghetti. Een soort Tapijt van Bayeuz, maar dan geweven door mensen die allemaal ongeveer iets anders in hun hoofd hadden en af en toe aan de achterkant van het borduurwerkje wat knoopjes legden waar je aan de voorkant minder van ziet ... maar het werd er niet mooier van. Tenzij we holistisch kijken door de bril van een data ecosysteem. Kan ook BINNEN je organisatie. Dan ga je vragen stellen als 'wie heeft er eigenlijk toegang heeft tot welke data? Waarbevinden die data zich? Wat is daar eigenlijk ooit over afgesproken qua juridische en technische afhankelijkheden? Weten de verantwoordelijke verantwoordelijken dat ook? Als die ene API eruit klapt, wie belt dan wie en wat zeg je dan en vooral, wat doet 'het' dan niet meer? Een "Dependency Mapping Framework" zeg maar, met kernvragen als: welke data flows zijn cruciaal voor onze businesscontinuïteit? Welke leveranciers of platforms hebben impliciete controle over onze kritieke processen? Welke juridische risico's lopen we door extraterritoriale wetgeving (bijvoorbeeld de CLOUD Act)? Zo krijg je snel de ingrediënten in de hand om ook de legacy IT conceptueel op te knippen en de samenwerking (het werkt nu al, dus het 'doet' het blijkbaar) te herdefiniëren als kleine ini-data spaces Waarom?
Traditionele legacy IT-systemen zijn vaak monolithisch en afhankelijk van specifieke leveranciers of technologieën. Door deze nu als mini-data spaces te leren bekijken, ga je automatisch denken en werken vanuit modulaire interoperabiliteit die de afhankelijkheden reduceert, maar vooral inzichtelijk maakt. Daar zijn briljante referentie architecturen voor, zoals het IDS-RAM (International Data Spaces Reference Architecture Model) en slimme software, zoals context brokers, die je weer prachtig aan kunt sturen met API's zoals NGSI-LD om meteen semantische interoperabiliteit te waarborgen tussen systemen binnen je eigen IT-landschap. Dus je DOET niets, maar je bekijkt het anders. Een beetje het verschil tussen een rommelkamer en een interieur architect. Zelfde spullen, zelfde kamer, toch een heel ander gezicht. Data blijven betekenisvol zoemen tussen systemen, maar alleen al de vragen stellen die je nu eenmaal moet stellen om een NGSI-LD API te configueren legt alle verbanden die je op het eerste gezicht nooit ziet ... omdat het een multidisciplinair samenspel vereist. Een CISO kijkt naar andere dingen dan een inkoper. Een jurist lijkt niet op een CIO. Combineer ze en je krijgt een aardige röntgenfoto. Door alle data-uitwisselingen meteen onder expliciete Trust & Governance te laten vallen ontstaan echt duidelijke afspraken over wie toegang heeft, onder welke voorwaarden en hoe data mag worden gebruikt. Dit voorkomt niet alleen ambiguïteit in verantwoordelijkheden, maar het lijnt ook mooi al die verschillende afdelingen en disciplines op die nu hun eigen management software hebben.
Nu kunnen we ook alle datastromen binnen de legacy systemen identificeren en herdefinieren vanuit een "data space"-benadering. Technisch werkt dat dankzij API-first principes en zeer expliciete API-contracten, open standaarden en technologieën die niet vendor-gebonden zijn. De helderheid die zo ontstaat maakt het mogelijk om een exit-strategie te ontwikkelen voor kritieke leveranciers. Software die eigenlijk niet meer gemaakt wordt of software die nog kwam van bedrijven die allang zijn overgenomen door andere bedrijven die er een heel ander businessmodel op na bleken te houden. Zo ontstaan de alternatieven en systemen die je deze eenvoudig kunt migreren.
Meer helderheid over doelbinding, minder lock-in, minder contracten, minder applicaties, dus kleinere blast rate door een kleinere digitale footprint. Minder mensen nodig. Lagere kosten. Meer flexibiliteit. Een opgeruimde kamer lijkt ook altijd groter.
lijkheden helder zijn vastgelegd. Dit is een iteratieve aanpak. Je hoeft niet én je kasten te demonteren, je boeken te sorteren, te behangen en plamuren en ... op 1 dag.
Je moet wel een plan hebben voor de gehele kamer. Incrementele verbeteringen aanbrengen, waarbij je begint met de meest kritieke systemen en datastromen. Dus eerst dat lekke raam repareren. Hierbij kun je een maturity model gebruiken, zoals het IDS Information Security Evaluation Scheme - IDSA ISES) om te bepalen waar je organisatie staat en welke stappen nodig zijn om digitale soevereiniteit te vergroten.
Zo wordt digitale soevereiniteit een functie van risicomanagement, waarbij compliance slechts een basisniveau is. Het wordt pas echt leuk als we stress-tests gaan doen. "Wat gebeurt er als een buitenlandse leverancier ons toegang tot kritieke systemen blokkeert?" of "Hoe reageren we als wetgeving ons dwingt om data-infrastructuur te verplaatsen?" Nu wel te handlen dankzij architectuur principes, zoals "decoupling" van systemen en processen (Separation of Concerns), data portability en vendor-neutrality en transparantie in datastromen. Digitale soevereiniteit is dus een continu proces en niet iets dat met één technische of juridische maatregel kan worden bereikt. Het vereist een fundamenteel andere manier van denken over IT-architectuur en governance. Door legacy IT te herzien als mini-data spaces binnen het IDS-RAM-raamwerk, kun je prima (en snel) een modulaire, interoperabele en toekomstbestendige architectuur opbouwen. Het zou de handelingsvrijheid vergroten en afhankelijkheden verminderen, maar het zou vooral consistentie bieden in ontwerpkeuzes: elke beslissing moet bijdragen aan het vergroten van je autonomie. Soevereiniteit is inderdaad niet het eindpunt, maar een pad dat je stap voor stap bewandelt.