SODA als praktisch model voor digitale soevereiniteit
Inzicht is nog geen beslissing
In de eerste blog in deze serie stelden we dat digitale soevereiniteit niet moet worden teruggebracht tot een keuze tussen twee uitersten. Volledige digitale autonomie is voor de meeste organisaties niet realistisch, terwijl simpelweg accepteren hoe de situatie nu is belangrijke afhankelijkheden buiten beeld laat. Een bruikbaarder midden ligt in het begrijpen van die afhankelijkheden, ze in de juiste context plaatsen en vervolgens bewuste afwegingen maken.
In de tweede blog maakten we onderscheid tussen drie dimensies van soevereiniteit: data, operationele en technische soevereiniteit. Dat onderscheid is belangrijk. Een discussie over dataresidentie gaat over iets anders dan de vraag wie een dienst kan herstellen, en beide zijn weer iets anders dan langdurige vendor lock-in. Welke dimensie het zwaarst weegt, verschilt per workload.
De derde blog liet zien waarom die gesprekken desondanks vaak vastlopen. Afhankelijkheden zijn verspreid over architectuur, contracten, identity, operations, support, licenties, datastromen, leveranciers en specialistische kennis bij individuele mensen. Zolang die afhankelijkheden niet zichtbaar en gevalideerd zijn, rusten beslissingen over soevereiniteit op aannames in plaats van feiten.
Maar inzicht alleen is nog geen beslissing. Een dependency map kan laten zien waar een organisatie van afhankelijk is, maar bepaalt niet of die afhankelijkheid ook acceptabel is. Leiders moeten nog steeds bepalen hoeveel controle nodig is, of een dienst onder druk kan worden beheerd, hoe moeilijk vervanging werkelijk is en welke juridische autoriteiten uiteindelijk invloed op de dienst kunnen uitoefenen.
Daarvoor is SODA bedoeld: een gestructureerde manier om dat inzicht te vertalen naar eisen, beoordelingen, afwegingen en besluiten met duidelijk eigenaarschap.
SODA vertelt organisaties niet dat ze afhankelijkheden moeten elimineren. Het helpt bepalen welke afhankelijkheden acceptabel zijn, waar waarborgen nodig zijn en welke moeten worden verkleind.
Digitale soevereiniteit als Non-Functional Requirement
Digitale soevereiniteit kun je het best behandelen als een Non-Functional Requirement. Non-Functional Requirements beschrijven niet welke businessfunctie een systeem uitvoert, maar onder welke voorwaarden het moet kunnen functioneren. Security, beschikbaarheid, performance, onderhoudbaarheid en compliance zijn bekende voorbeelden. Soevereiniteit hoort in dezelfde categorie, omdat het eisen stelt aan zeggenschap, beheer, weerbaarheid, afhankelijkheid en jurisdictie.
Dat verandert het gesprek. In plaats van te vragen of een applicatie soeverein is, kunnen leiders en deliveryteams bepalen welk niveau van soevereiniteit een workload daadwerkelijk nodig heeft. Een publieke marketingwebsite vraagt niet om dezelfde waarborgen als een patiëntendossier, betaalplatform of digitale overheidsidentiteit. Een innovatief digitaal product kan bewust meer platformafhankelijkheid accepteren in ruil voor snelheid en onderscheidend vermogen. Een kritieke publieke dienst kan juist meer juridische controle, operationele continuïteit en geloofwaardige alternatieven nodig hebben.
Soevereiniteit is daarmee geen binaire eigenschap. Net als andere kwaliteitsattributen kun je het versterken, toetsen en afwegen tegen kosten, snelheid, gemak, weerbaarheid en toegang tot innovatie. Meer is niet automatisch beter, omdat iedere extra maatregel ook kosten en complexiteit kan toevoegen.
Soevereiniteit is niet iets wat ieder systeem moet maximaliseren. Voor ieder kritisch systeem moet wel duidelijk zijn welk niveau nodig is.
Het SODA-model
SODA beoordeelt een workload vanuit vier invalshoeken die elkaar aanvullen: Sovereign Control, Operational Independence, Dependency en Authority and Jurisdiction. Samen vormen ze een praktisch profiel van de controle die een organisatie zelf moet behouden en de afhankelijkheden die zij bereid is te accepteren.
S — Sovereign Control
Sovereign Control draait om de vraag wie uiteindelijk controle heeft over het systeem en de beslissingen eromheen. Het gaat om controle over infrastructuur en configuratie, identiteiten en beheerdersrechten, encryptiesleutels, de levenscyclus van data en de mogelijkheid om toegang te verlenen of in te trekken. Ook speelt de vraag of een derde partij de dienst kan opschorten, beperken of wezenlijk kan wijzigen zonder dat de organisatie zelf kan ingrijpen.
Vragen die hierbij horen zijn bijvoorbeeld:
Kan de organisatie alle externe toegang intrekken?
Wie beheert de beheerdersrechten en encryptiesleutels?
Kan een derde partij de dienst opschorten of beperken?
Heeft de organisatie controle over hoe data wordt bewaard, verplaatst en verwijderd?
Sterke controle betekent niet automatisch dat een organisatie ieder onderdeel zelf moet bezitten. Ook een dienst die door een externe provider wordt beheerd kan betekenisvolle sovereign control bieden, zolang rollen, toegangsgrenzen, sleutels, logs, beslisrechten en contractuele waarborgen duidelijk en afdwingbaar zijn.
O — Operational Independence
Operational Independence kijkt naar de vraag of een organisatie de dienst zelf kan blijven draaien, herstellen en aanpassen. Het gaat om het praktische vermogen om te handelen wanneer een provider, supportteam of cruciale specialist niet beschikbaar is. Kennis, documentatie, tooling, privileged access, back-up en herstel, incidentonderzoek, controle over updates en geteste continuïteitsmaatregelen spelen daarin allemaal een rol.
Vragen die hierbij horen zijn bijvoorbeeld:
Kunnen we de dienst herstellen zonder de primaire leverancier?
Hebben we de kennis, toegang, tooling en documentatie om de dienst zelf te beheren?
Kunnen kritieke processen doorgaan als externe support wegvalt?
Zijn herstel- en continuïteitsmaatregelen in de praktijk getest?
Deze invalshoek voorkomt dat organisaties eigendom verwarren met handelingsvermogen. Een on-premises systeem kan weinig operationele onafhankelijkheid hebben wanneer het afhankelijk is van één leverancier of een paar schaarse specialisten. Een cloudworkload kan juist meer operationele onafhankelijkheid hebben wanneer toegang, automation, herstel, kennis en escalatiepaden bewust zijn ingericht en getest.
D — Dependency
Dependency kijkt naar hoe vervangbaar een component, leverancier, platform of capability werkelijk is. Vendor lock-in, propriëtaire diensten, concentratie in het ecosysteem, schaarse kennis en migratie-inspanning komen daarmee in hetzelfde gesprek terecht. De relevante vraag is niet óf er afhankelijkheid bestaat, maar of de gevolgen ervan worden begrepen en acceptabel zijn.
Vragen die hierbij horen zijn bijvoorbeeld:
Is er een geloofwaardig alternatief in de vorm van een andere leverancier of technologie?
Welke propriëtaire API's, formaten of diensten maken vervanging lastig?
Hoe lang zou vervanging realistisch duren en hoeveel inspanning vraagt dat?
Kan de business doorgaan wanneer de leverancier stopt met dienstverlening aan ons?
Iedere propriëtaire capability vermijden is zelden een verstandige strategie. Providerspecifieke diensten kunnen veel snelheid, betrouwbaarheid en innovatie opleveren. De keuze wordt verantwoord wanneer het voordeel expliciet is, de gevolgen van een eventuele exit duidelijk zijn en helder is wie eigenaar is van het resterende risico.
A — Authority and Jurisdiction
Authority and Jurisdiction kijkt naar het juridische en institutionele gezag waaronder een dienst valt. Daaronder vallen de juridische entiteiten die de dienst leveren en ondersteunen, toepasselijke wetgeving, locaties waar data wordt opgeslagen en verwerkt, onderaannemers, extraterritoriale wetgeving, toegang tot metadata en managementomgevingen en de mogelijkheid om contractuele en technische waarborgen aantoonbaar te maken.
Vragen die hierbij horen zijn bijvoorbeeld:
Welke juridische entiteit levert de dienst?
Welke rechtsgebieden kunnen een provider verplichten om informatie te verstrekken of toegang te beperken?
Waar worden data, metadata, logs en back-ups opgeslagen en verwerkt?
Welke technische en contractuele waarborgen kunnen we aantonen?
Data die in Europa staat, valt dus niet automatisch uitsluitend onder Europese zeggenschap. De fysieke locatie is relevant, maar zegt op zichzelf nog niet wie toegang heeft tot de dienst, welk bedrijf de ondersteunende systemen beheert of welke wetgeving dat bedrijf kan verplichten om te handelen.
Hoe SODA zich verhoudt tot de drie dimensies van soevereiniteit
SODA vervangt de drie dimensies uit de eerdere blogs niet. Die drie dimensies beschrijven waar soevereiniteitsrisico's zich voordoen. SODA biedt vier invalshoeken om die risico's te vertalen naar toetsbare eisen en concrete beslissingen.
Het model maakt Dependency bewust expliciet. Twee workloads kunnen technisch sterk op elkaar lijken en toch een heel ander risicoprofiel hebben. De ene heeft geloofwaardige alternatieven en overdraagbare kennis, terwijl de andere leunt op één unieke provider, propriëtaire diensten en kennis die bij een klein extern team zit.
Van vragen naar scores, zonder schijnprecisie
Een vijfpuntsschaal kan teams helpen om per SODA-lens de benodigde en de huidige positie met elkaar te vergelijken. De schaal is geen wetenschappelijke meting, compliancecertificaat of volwassenheidsscore. De waarde zit erin dat aannames expliciet worden en dat mensen vanuit business, technologie, operations, security, legal, risk en procurement moeten uitleggen welk bewijs achter hun beoordeling zit.
Iedere score moet worden onderbouwd met bewijs, bekende onzekerheden, realistische scenario's, gevolgen voor de business en een duidelijke eigenaar van het risico. Een lage score is niet automatisch een probleem. Een score van twee kan prima passen bij een dienst met beperkte impact. Een score van vier kan nog steeds onvoldoende zijn voor een systeem waarvan verstoring de publieke veiligheid of kritieke processen in gevaar brengt.
Het doel is niet om een perfecte SODA-score te behalen. Het doel is een profiel dat past bij de workload.
Bepaal eerst het benodigde profiel en beoordeel daarna de huidige situatie
Organisaties beginnen vaak met het beoordelen van het huidige platform. Daarmee dreigt de bestaande architectuur onbedoeld het referentiepunt te worden. Een betere volgorde is om eerst het benodigde profiel van de workload te bepalen, op basis van bedrijfskritikaliteit, gevoeligheid van data, wettelijke verplichtingen, impact van uitval, strategisch belang en risicobereidheid. Pas daarna beoordeel je de huidige situatie.
Het verschil tussen het benodigde en het huidige niveau maakt duidelijk waar actie nodig is. Neem bijvoorbeeld een kritieke klantdienst met het volgende illustratieve profiel:
Zo'n profiel levert geen algemeen oordeel op dat een workload wel of niet soeverein is. Het laat zien waar het ontwerp aan de eisen voldoet en waar gerichte actie nodig is. Tegelijk voorkomt het dat organisaties iedere score proberen te maximaliseren, ongeacht kosten of businesswaarde.
Pas SODA toe op één workload tegelijk
Een universeel soevereiniteitsbeleid leidt al snel tot onnodig hoge kosten of een vals gevoel van zekerheid. Pas SODA daarom toe op een concrete workload, een bedrijfsproces of een kritieke dienst. Een praktische beoordeling bestaat uit zeven stappen:
1. Selecteer de workload. Kies een duidelijk afgebakende applicatie, dienst of bedrijfsproces.
2. Bepaal de context. Breng bedrijfskritikaliteit, gevoeligheid van data, regelgeving, impact van uitval, stakeholders en risicotolerantie in beeld.
3. Breng de afhankelijkheden in kaart. Kijk naar hosting, data, identity, netwerk, logging, support, sleutels, licenties, integraties, onderaannemers en specialistische kennis.
4. Bepaal het benodigde SODA-profiel. Leg vast welk niveau van controle, onafhankelijkheid, vervangbaarheid en zekerheid rond jurisdictie de workload nodig heeft.
5. Beoordeel het huidige profiel. Baseer de score op bewijs in plaats van architectuurlabels, claims van providers of alleen de hoofdlijnen uit een contract.
6. Toets realistische scenario's. Denk aan het stopzetten van een dienst, een overname, beperkte support, een verzoek van een toezichthouder om bewijs, sancties of een noodzakelijke exit binnen een vastgestelde termijn.
7. Neem een besluit en wijs eigenaarschap toe. Accepteer, monitor, beperk of elimineer/vervang de afhankelijkheid, met een eigenaar en een datum voor herbeoordeling.
Het resultaat moet een besluit zijn, geen generiek label. Bijvoorbeeld: deze workload voldoet aan de eisen voor juridische zeggenschap en controle, maar operationeel herstel is nog te afhankelijk van de primaire leverancier. Dat gat moet binnen drie maanden worden verkleind, waarbij de service owner verantwoordelijk is voor het testen van de nieuwe herstelvoorziening.
Soevereiniteit is een afweging, geen gratis upgrade
De vier SODA-invalshoeken maken de spanningen zichtbaar. Meer Sovereign Control kan extra governance en duurdere servicemodellen vragen. Sterkere Operational Independence vraagt om kennis, tooling, documentatie, oefeningen en soms dubbele capabilities. Minder Dependency kan betekenen dat je minder gebruikmaakt van propriëtaire diensten die juist veel innovatie en productiviteit opleveren. Sterkere juridische waarborgen kunnen de keuze uit leveranciers beperken of internationale dienstverlening complexer maken.
Die kosten maken eisen rond soevereiniteit niet minder relevant. Ze maken prioritering noodzakelijk. Een organisatie kan bewust een lagere score accepteren wanneer de impact beperkt is, het businessvoordeel groot is, er alternatieven bestaan en het restrisico een duidelijke eigenaar heeft. Andersom kan een afhankelijkheid ook om actie vragen wanneer vervanging duur is, als de mogelijke impact groter is dan de risicotolerantie van de organisatie.
Een afhankelijkheid wordt een governanceprobleem wanneer die onzichtbaar, verkeerd begrepen of zonder eigenaar is, niet simpelweg omdat de afhankelijkheid bestaat.
Zet iedere wezenlijke afhankelijkheid om in een besluit
Een SODA-assessment moet voor iedere wezenlijke afhankelijkheid tot één van vier uitkomsten leiden:
Accepteren. De afhankelijkheid past binnen het benodigde profiel en de waarde rechtvaardigt het restrisico.
Monitoren. De afhankelijkheid is nu acceptabel, maar veranderingen in eigendom, wetgeving, kosten, technologie of geopolitiek kunnen dat oordeel veranderen.
Beperken. Aanvullende maatregelen zijn nodig, bijvoorbeeld sleutels onder controle van de klant, scherpere toegangsgrenzen, contractuele waarborgen, open dataformaten, interne kennis, een alternatieve herstelmogelijkheid of een getest exitplan.
Elimineren of vervangen. De afhankelijkheid past niet bij het benodigde profiel en kan met aanvullende waarborgen onvoldoende worden teruggebracht.
Hier wordt inzicht in afhankelijkheden daadwerkelijk governance. De organisatie praat niet langer in abstracte termen over de vraag of een leverancier, cloudmodel of technologie 'soeverein' is. Er wordt besloten welke specifieke afhankelijkheden acceptabel zijn, welk bewijs nodig is, welke maatregelen moeten worden toegevoegd en wie eigenaar is van de uitkomst.
Maak SODA onderdeel van bestaande governance
SODA moet geen losse compliance-oefening worden. De waarde neemt juist toe wanneer benodigde profielen en besluiten worden geïntegreerd in bestaande architectuurreviews, cloud- en SaaS-selectie, vendor due diligence, inkoop, contractverlenging, risicobeoordeling, business continuity-planning en applicatieportfoliomanagement.
Net als andere Non-Functional Requirements is een SODA-profiel niet permanent. Het moet opnieuw worden bekeken wanneer een leverancier van eigenaar verandert, wetgeving wijzigt, de architectuur wezenlijk verandert, de bedrijfskritikaliteit toeneemt, een contract wordt verlengd of een incident een belangrijke aanname onderuit haalt. Het profiel biedt een gezamenlijk referentiepunt om te bepalen of zulke veranderingen nog binnen de geaccepteerde grenzen vallen.
Bewuste afhankelijkheid is het doel
Deze serie begon met het loslaten van de valse tegenstelling tussen volledige autonomie en passieve acceptatie. De drie dimensies van soevereiniteit gaven organisaties vervolgens een duidelijkere taal voor verschillende soorten risico. Het in kaart brengen van afhankelijkheden verving aannames door feiten. SODA maakt de stap af door die informatie te vertalen naar eisen per workload, concrete gaps, maatregelen en eigenaarschap.
Digitale soevereiniteit vraagt niet dat organisaties zich terugtrekken uit wereldwijde technologie-ecosystemen. Wel dat ze er met open ogen aan deelnemen. Het doel is niet onafhankelijkheid tegen elke prijs, maar bewuste afhankelijkheid: weten waar de organisatie op leunt, begrijpen wat daarvan de gevolgen zijn, bepalen hoeveel controle nodig is en het resterende risico bewust accepteren of veranderen.
SODA biedt daar een praktische structuur voor: één workload, één besluit en één duidelijke eigenaar tegelijk.
Soevereiniteit draait niet om het ontbreken van afhankelijkheden. Het gaat erom dat je er bewust over kunt beslissen.
Bert Ertman
A frequent speaker on Java, Cloud, and software architecture all over the world. Book author, and serial conference organizer.
