BLOG – In een wereld waarin organisaties steeds afhankelijker worden van digitale diensten, is digitale soevereiniteit een strategisch thema. Digitale soevereiniteit gaat over het vermogen van een organisatie om zelf controle te houden over haar data, systemen en digitale processen, zonder ongewenste afhankelijkheid van externe partijen. Het doel is om risico’s te beperken, compliance te waarborgen en de continuïteit van de organisatie te beschermen.
De omgeving
Een uitgangspunt van digitale soevereiniteit is dat organisaties maximale controle behouden over hun digitale omgeving en de daarin opgeslagen en verwerkte gegevens. Dit betekent niet dat alle systemen en applicaties per definitie lokaal (on-premises) moeten draaien; ook binnen cloud- en hybride omgevingen is het mogelijk om regie te voeren. Essentieel is dat de organisatie zelf bepaalt hoe de omgeving wordt ingericht, geconfigureerd en beveiligd en wie daar toegang toe heeft.
Deze regie beperkt zich niet tot de technische inrichting, maar omvat ook bestuurlijke en strategische zeggenschap. Organisaties moeten in staat zijn hun eigen beveiligingsbeleid vast te stellen, te voldoen aan specifieke compliance-eisen en systemen flexibel aan te passen wanneer dat nodig is. Door bewust te kiezen voor oplossingen die deze autonomie ondersteunen – bijvoorbeeld via open standaarden, modulaire architecturen en transparante contractafspraken – kan afhankelijkheid van één specifieke leverancier worden voorkomen.
Het behouden van controle over de digitale omgeving vergroot bovendien de flexibiliteit en wendbaarheid van een organisatie. Hierdoor kan sneller worden ingespeeld op veranderingen, zoals nieuwe wet- en regelgeving, technologische ontwikkelingen of veranderende bedrijfsbehoeften. Ook worden migraties naar andere systemen of leveranciers eenvoudiger wanneer er minder sprake is van afhankelijkheid van propriëtaire technologieën of gesloten ecosystemen.
Het verminderen van afhankelijkheid van één partij verkleint het risico op vendor lock-in en versterkt de onderhandelingspositie. Daarnaast biedt het meer zekerheid op het gebied van continuïteit. Bij incidenten zoals storingen, beveiligingslekken of geopolitieke ontwikkelingen kan sneller en effectiever worden gehandeld. Organisaties behouden daarmee de mogelijkheid om tijdig passende maatregelen te nemen.
Tegelijkertijd is er een rol weggelegd voor leveranciers. Zij moeten inspelen op de groeiende vraag naar digitale soevereiniteit door oplossingen te ontwikkelen en aan te bieden die organisaties daadwerkelijk in staat stellen de regie te behouden. Het aanbieden van soevereine omgevingen – waarin data, processen en infrastructuur voldoen aan duidelijke eisen op het gebied van controle, transparantie en juridische zekerheid – wordt hierbij cruciaal. Leveranciers die dit aantoonbaar kunnen ondersteunen, zullen hun positie in de markt versterken en bijdragen aan een toekomstbestendig digitaal ecosysteem.
De data
Voor veel organisaties is de locatie van dataopslag van groot belang. Europese wet- en regelgeving, zoals de AVG, stelt eisen aan de verwerking en bescherming van persoonsgegevens. Daarom is het verstandig om contractueel vast te leggen dat data uitsluitend wordt opgeslagen en verwerkt binnen de Europese Unie. Door deze afspraken expliciet af te dwingen bij de (cloud)leverancier, verklein je het risico dat gegevens onder buitenlandse wetgeving vallen of worden verplaatst naar regio’s met minder strenge privacybescherming. Transparantie over datalocaties en eventuele subverwerkers is daarbij essentieel.
Alleen het beveiligen van de dataopslag is niet voldoende; gegevens moeten ook goed worden beschermd. Encryptie vormt hierbij een belangrijke verdedigingslaag. Door data zowel tijdens transport als tijdens opslag te versleutelen, wordt de kans op misbruik aanzienlijk verkleind.
Voor echte digitale soevereiniteit is het echter zaak dat de organisatie zelf eigenaar blijft van de encryptiesleutels en certificaten. Wanneer een leverancier de sleutels beheert, behoudt deze in theorie toegang tot de gegevens. Door certificaten en cryptografische sleutels in eigen beheer te houden, blijft de controle over de toegang tot de data volledig bij de organisatie. Deze aanpak wordt vaak aangeduid als ‘customer managed keys’ of ‘bring your own key’ en wordt steeds vaker toegepast binnen kritische en privacygevoelige omgevingen.
Het contract
Een ander essentieel onderdeel van digitale soevereiniteit is het juridisch vastleggen van eigenaarschap. In overeenkomsten met cloud- en it-leveranciers moet ondubbelzinnig worden opgenomen dat de organisatie eigenaar blijft van alle opgeslagen en verwerkte data. Daarnaast moet worden vastgelegd dat de leverancier gegevens nooit mag inzien, delen, analyseren of beschikbaar stellen aan derden zonder expliciete toestemming van de eigenaar. Ook moet duidelijk zijn hoe wordt omgegaan met verzoeken van overheden, toezichthouders of andere externe partijen.
Sleutelafspraken zijn onder meer:
- De klant blijft te allen tijde eigenaar van de data;
- De leverancier mag data niet gebruiken voor eigen doeleinden;
- Data mag niet worden gedeeld met derden zonder schriftelijke toestemming;
- Verzoeken van externe partijen worden direct gemeld aan de klant, tenzij wetgeving dit verbiedt;
- Bij beëindiging van de dienstverlening wordt alle data volledig geretourneerd en verwijderd.
Digitale soevereiniteit als strategische keuze
Digitale soevereiniteit gaat verder dan technologie alleen. Het is een combinatie van technische maatregelen, juridische afspraken en governance. Organisaties die investeren in een zelf beheerde omgeving, Europese dataopslag, eigen sleutelbeheer en duidelijke contractuele afspraken over eigenaarschap, versterken hun digitale onafhankelijkheid aanzienlijk.
In een tijd waarin data een van de meest waardevolle bedrijfsmiddelen is, wordt het behoud van controle over die data steeds belangrijker. Digitale soevereiniteit biedt organisaties de mogelijkheid om innovatie te combineren met veiligheid, compliance en autonomie. Daarmee vormt het een belangrijke pijler voor een toekomstbestendige digitale strategie.
Ruud Pieterse, enterprise-architect DXC Technology
De twee grote beloften van de afgelopen vijftien jaar waren cloud en agile.
Cloud zou ontzorgen: waarom zou je zelf alle complexiteit beheren als een gespecialiseerde provider dat veel beter en efficiënter kan? Gewoon je corebusiness doen op het platform van je leverancier.
En nu lezen we een verhaal over digitale soevereiniteit waarin we vooral weer zelf controle moeten organiseren: eigen sleutels, data in de EU, contractuele garanties, governance, kennis borgen, exitstrategieën, controle op leveranciers en zelfs controle op degenen die de controle uitvoeren. Of dat dat niet nodig zou zijn als je zelf maar denkt te weten waar je over heb (net als Trump bijvoorbeeld)
Zijn we dan inderdaad weer terug bij af?
Daarmee moest ik ook aan het Agile Manifesto denken. Weet u het nog?
* Individuals and interactions over processes and tools
* Working software over comprehensive documentation
* Customer collaboration over contract negotiation
* Responding to change over following a plan
Het manifest beperkte zich bovendien niet uitsluitend tot softwareontwikkeling.
Na jaren van ontzorging en flexibiliteit, nu dus veel energie in het formeel vastleggen en controleren van afhankelijkheden. Niet noodzakelijk omdat dat verkeerd is, maar wel omdat er blijkbaar fundamenteel wantrouwen nodig is om de beloofde autonomie alsnog te organiseren.
En dat roept bij mij een simpele klantvraag op: Als ik dit allemaal zelf moet organiseren om daadwerkelijk soeverein te blijven, wat heb ik dan precies uitbesteed — en wat heb ik daarmee eigenlijk ontzorgd?
Waar ben ik al die jaren ingetrapt en wie zijn zijn diegene die oplossingen bieden niet dezelfde die ze veroorzaakten.
Ik vermoed dat een klant die deze discussie leest uiteindelijk niet alleen aan digitale soevereiniteit denkt, maar ook een beetje aan een ivoren toren. En aan behoorlijk veel geouwehoer. 😛
“Daar begint voor mij soevereiniteit” markeert geen definitie, maar een opinie. Een mening kan niet als architectuurwaarheid worden gebruikt om Juvenalis af te sluiten want Juvenalis begint juist waar iemand zijn eigen conclusie tot het eindpunt van de controle verklaart.
De volgorde betekenis → doel → beslissing → implementatie is architectuur technisch logisch maar nog niet volledig. Controle is geen latere laag boven de architectuur maar een architectuurfunctie die in iedere stap aanwezig moet zijn. Ik wees op de andere helft van Kiplings zes eerlijke dienaren. Terug naar de tekentafel hult de opsteller van opinie zich in zwijgen waardoor er andere vormen van soevereiniteit ingebracht worden in de discussie.
Met stroop smeren door te stellen dat het een waardevol artikel is maar een fundamentele dimensie mist helpt blijkbnaar ook niet om een reactie uit lokken. Niets is namelijk zo veranderlijk als een verwachting als ik kijk naar de klacht over ontzorgen door Dino. Tekenen bij het kruisje om te ontzorgen gaat niet om architectuur maar verwachtingsmanagement.
Een doelarchitectuur, roadmap en meerjarenplan wekken al snel de indruk dat de toekomst bekend is maar ze dienen vooral de verwachtingen van vandaag. Een exit strategie voorspelt niet dat je afscheid neemt van een leverancier maar neemt de mogelijkheid om dat te doen mee in de architectuur. Afdwingen van open standaarden voorkomt dat alleen de huidige leverancier de deur kan openen maar is niet het hele verhaal als we kijken naar beschikbare implementatiekennis.
Deze kennis vastleggen gaat meer om het documenteren dan weer een oplossing beloven want het manifesto verwerpt documenteren niet maar geeft er een lagere prioriteit aan in het leveren van software. Ook de cloud beloofde nooit ontzorgen maar een grotere wendbaarheid welke uiteindelijk leidde tot nieuwe problemen in de beheersbaarheid.
Dus ja, de verkopers van vandaag proberen op te lossen wat de verkopers van gisteren verkocht hebben. De priesters van serverless bleken uiteindelijk de farizeeërs te zijn die de serversknuffelaars verloochenden.Hierdoor is de sector zo cyclisch want complexiteit verdwijnt niet wanneer je haar uitbesteedt. Zij verandert alleen van eigenaar, taal en factuuradres met de nieuwe aflaat van de soevereine cloud.
Zodra de verdwenen kennis als afhankelijkheid terugkeert verkoopt dezelfde markt herstel hiervan als een nieuwe architectuurontwikkeling. U vraagt, wij draaien want architectuur is misschien geen glazen bol maar het terrein is ook niet volledig onbekend. Wetgeving, bestaande techniek, contracten, kennisposities en afhankelijkheden zijn al zichtbaar. De onzekerheid zit vooral in wat onderweg verandert als we kijken naar geopolitieke schokgolven.
Gisteren gold nog: allen voor één en één voor allen. Vandaag is het ieder voor zich en God voor ons allen. De architectuur bleef hetzelfde maar de betekenis van afhankelijkheid veranderde onderweg van samenwerking in risico.
Volgens mij blijven we langs elkaar heen praten omdat jij controle als noodzakelijke architectuurfunctie veronderstelt en ik juist vraag waarom dat uitgangspunt nodig is.
Als betekenis, doelen en beslissingen expliciet zijn, hoeft hun toepassing niet voortdurend via een extra controlelaag bewaakt te worden. Anders controleren we achteraf wat we vooraf niet helder hebben gemaakt.
Hoe minder betekenis in de architectuur expliciet is, hoe meer controle je nodig hebt om haar gedrag te bewaken.
Daarom zie ik deze keten:
onduidelijkheid → risico → controle → complexiteit → nieuwe onduidelijkheid → meer controle
niet als onvermijdelijk, maar als een architectuurprobleem.
Betekenisgedreven architectuur probeert die cirkel te doorbreken:
betekenis → doel → beslissing → uitvoering.
Niet omdat toetsbaarheid verboden is, maar omdat controle geen primaire ordeningsfunctie meer hoeft te zijn.
En daar zit volgens mij het fundamentele verschil: jij vraagt steeds wie controleert? Ik vraag eerst wat moet er überhaupt gecontroleerd worden, en waarom?
Als daarop het antwoord is: “omdat anders niet aantoonbaar is dat de betekenis correct is toegepast”, zijn we weer terug bij het begin.
Dan gebruiken we controle om een gebrek aan expliciete betekenis te compenseren.
Precies dát probeer ik met betekenissoevereiniteit te voorkomen.
Betekenis vastleggen binnen je scope/domein/context/gebied is al lastig.
Als dit zo vanzelfsprekend was deed men dat wel.
Betekenis is nu vaak onduidelijk of vooral enigzins afleidbaar uit implementatie.
Working software over comprehensive documentation : een paradox op zich want hoe weet je of je software werkt zonder formele afspraken.
Scrum lost dat op met zn einde-sprint-demo, die vooral bestaansrecht heeft, omdat men zo’n moeite heeft met vertrouwen en specs.
Uiteindelijk wil men juist iets concreets zien (of controleren ?) om erover te kunnen oordelen.
Betekenis buiten je scope is nog veel lastiger.
Je weet niet wat je mist, welke geheime belangen en afspraken er bij je leverancier zitten.
Het is dus nog erger gesteld. Vertrouwen is zowiezo onmogelijk vanwege die verschillende belangen.
En controle is noodzakelijk, maar schiet zelfs inherent tekort, omdat je niet kunt controleren wat niet je weet.
Klanten die tekenen bij het kruisje weten bijvoorbeeld niet altijd van de Cloud Act die bestaande data-afspraken met klant overrulled.
Misschien ook wel, maar is het in hun belang om dat dat zogenaamd niet te weten.
De leverancier houdt het wellicht bewust verborgen met kruisjesvoorwaarden gecontroleerd door juristen die voor hun werken.
Specificeer die dynamiek maar eens.
De realiteit:
Een architect die probeert “alleen een licht op een onderwerp te schijnen”.
Richting de 20 reacties, het merendeel mbt betekenis.
In kader van belofte van complexiteit terugdringen ?
Artikelen zijn verder zoals ze zijn, zijn mening, zijn opinie.
“Ik probeer geen gelijk te krijgen.”
Wat heeft dat te betekenen ?
Dat opiniearchitect juist perfecte benaming is dat je de vragen die het oproept zelf maar uitzoekt.
Hier dus ook de verrassing van scope en verwachtingen die pas achteraf wordt vastgelegd.
Maar fair enough.
Nee Jack, want een duidelijke verkeersregel voorkomt niet dat iemand door rood rijdt, de regel maakt juist controleerbaar dat iemand door rood reed. Betekenisarchitectuur kan controles gerichter, eenvoudiger en goedkoper maken zoals we zien met een geautomatiseerd incassoproces maar het kan de noodzaak van controle niet beëindigen. Controle gaat tenslotte om de beheersbaarheid van een systeem als compensatie voor onzekerheid doordat de betekenis wel bekend is maar niet nageleefd wordt.
Het schoolvoorbeeld van 30 jaar geleden toen ik nog de mening van Prof.dr. Th.M.A. Bemelmans moest leren. Want een rond verkeersbord met rode rand en 100 is een normatieve betekenis, de rest is impliciete informatie die uit de context van een situatie komt in de beslissing. Tot zover zijn we het nog eens maar de afweging van tijdswinst en pakkans maakt de beslissing relevant want of je gedrag kunt sturen met een sanctie is een interessante vraag als we kijken naar de ophef over soevereiniteit. Gedrag verandert alleen wanneer de winst van afwijking lager is dan de kosten van detectie, dat is bestuurskunde anno 2026.
Dino is soms hoogst irritant in de vorm van de boodschap maar dat veranderd niks aan de klepel die hij in de klok hangt. De vraag is of de opinie architect nog wel weet waar zijn klok en de klepel zijn gebleven want kennis ontstaat niet automatisch doordat de betekenis beschikbaar is, het DIKW-model stelt namelijk dat er een synthese nodig is van actieve interpretatie, ervaring en begrip. En kennis garandeert nog geen verstandig of normconform gedrag want je kunt een snelheidsbeperking ook negeren.
Wat betreft de scope creep, soms wordt het middel een doel.
Je verkeerslichtvoorbeeld ondersteunt juist mijn punt.
Niet de verkeersregel is de norm, maar de betekenis.
“Rood betekent stoppen” geeft rechtstreeks richting aan handelen:
betekenis → handelen.
Een mens heeft geen mentale bak met verkeersregels nodig die hij bij ieder rood licht stap voor stap toepast. Hij herkent de betekenis van de situatie en handelt ernaar.
De formele verkeersregel legt die betekenis vast, zodat afwijking juridisch kan worden vastgesteld. Controle komt dus pas daarna:
betekenis → norm → controle.
Mijn punt is daarom niet dat controle overbodig is. Wel dat controle geen fundament van architectuur is.
Betekenis bepaalt wat behoort.
Regels expliciteren wat behoort.
Controle toetst of ernaar wordt gehandeld.
Als we iedere betekenis gaan vertalen naar regels, uitzonderingen en controles, creëren we juist de regel- en controlespaghetti die we vervolgens weer moeten beheersen.
Let nou niet op die regels, maar op de betekenis 🙂
Het manifesto zou het formuleren als “Meaning over rules” en “there is value on the right, but we value items on the left more”.
Die paradox is net zo grappig van modus veranderen als de architect die eerst niet reageerde, omdat iets “persoonlijk wordt” of dat “feiten ontbreken” en daarna laat weten dat hij het gewoon nooit van van plan was 😛
Betekenis die wel herkend zou worden en artikelen die zijn zoals ze zijn.
Het hoe dan is inderdaad retorisch.
Jack,
Ik denk eerder dat je mijn punt bewijst want zelfs als betekenisarchitectuur perfect zou werken blijven onzekerheid, belangenafwegingen en opportunistisch gedrag bestaan.
In mijn voorbeeld staat niet het verkeerslicht centraal maar het gedrag van de verkeersdeelnemer. Het probleem van architectuur is dus niet alleen een semantisch probleem maar ook een coördinatieprobleem en een besturingsprobleem.
Van verkeersdeelnemer naar organisatie want architectuur beschrijft immers geen werkelijkheid maar een model van de werkelijkheid. Dat leerde ik dertig jaar geleden al bij prof.dr. Th.M.A. Bemelmans alhoewel de wereld waarop die architectuur betrekking heeft fundamenteel is veranderd is door uitbesteding, globalisering van supply chains en geopolitieke afhankelijkheden daarin.
Enterprise-architectuur moet tegenwoordig een model zijn van een ecosysteem waar autonome actoren voor een groot deel buiten de directe invloedssfeer van de organisatie liggen. De wereld van prof.dr. Th.M.A. Bemelmans is dus wat groter geworden dan een polder omringd door dijken. Juist daarom blijven onzekerheid, belangenafwegingen en opportunistisch gedrag bestaan hoe expliciet de betekenis ook wordt gemaakt.
De uitdaging is: “Hoe (be)stuur je een ecosysteem waarin de relevante actoren jouw betekenis begrijpen maar niet noodzakelijk jouw belangen delen?”
Dino heeft dat al aangeven want het conflict zit dan niet in de betekenis. Het conflict zit in de belangen. Dat maakt de architectuuruitdaging van 2026 fundamenteel anders dan de wereld waarin veel klassieke architectuurtheorie is ontwikkeld. Het probleem is niet langer: “Hoe zorgen we dat iedereen dezelfde betekenis hanteert?” maar: “Hoe creëren we voldoende alignment tussen alle actoren die verschillende belangen nastreven?”
Daarmee verschuift enterprise-architectuur van een ontwerpdiscipline naar een discipline van coördinatie en beïnvloeding. Het boek Verandermanagement met behulp van TOGAF van Ruud Pieterse is geschreven rond 2010:
https://www.amazon.com/Verandermanagement-met-behulp-Togaf-Dutch/dp/1447755022
Let wel, ik zeg niet dat de visie van Ruud Pieterse op architectuur fout is maar dat de wereld en veel organisaties ondertussen radicaal veranderd zijn zonder TOGAF. Want vanuit een ivoren toren kijken naar betekenis is uiteindelijk niet zo anders dan in een loket zitten als we de metafoor ontleden. Je ziet de werkelijkheid langskomen, maar je stuurt haar niet bij.
Ik denk dat je hier drie zaken door elkaar haalt: betekenis, besluitvorming en gedrag.
Natuurlijk verdwijnen onzekerheid, belangenconflicten en opportunistisch gedrag niet doordat betekenis expliciet wordt. Dat beweer ik ook nergens.
Maar daaruit volgt niet dat architectuur daarom primair een discipline van coördinatie en beïnvloeding moet worden. Coördinatie kan pas ergens over gaan als doelen, betekenissen, beslissingen en verantwoordelijkheden expliciet zijn.
Ook je stelling dat het conflict niet in de betekenis maar in de belangen zit, vind ik te absoluut. Belangen kunnen botsen terwijl de betekenis gedeeld is, maar partijen kunnen óók hetzelfde woord gebruiken en iets anders bedoelen. Juist dat moet je expliciet kunnen maken.
Voor mij is de volgorde daarom:
betekenis → besluitvorming → handelen → waar nodig coördinatie en controle.
Niet omdat daarmee onzekerheid of menselijk gedrag verdwijnt, maar omdat je anders vooral bezig bent de complexiteit te besturen die je zelf hebt gecreëerd.
Als architectuur vooral complexiteitsmanagement wordt, heb je steeds meer coördinatie en controle nodig. Als architectuur werkelijk ontwerp is, probeer je de behoefte aan coördinatie en controle juist zoveel mogelijk te reduceren.