Een van de onderwerpen waarover ik de laatste tijd veel nadenk is “Digital Sovereignty”. Het afgelopen jaar is er veel veranderd in het geopolitieke speelveld, ik denk dan aan de Amerikaanse politiek, de verhouding van het westen met China en de oorlog in Oekraïne. Inmiddels is dit onderwerp bij de IT consultancy bedrijven aan beland, onze klanten vragen hiernaar.

Het onderwerp “Digital Sovereignty” lijkt een veelkoppig monster omdat je er verschillende perspectieven op kan hebben. Je kan het benaderen vanuit een bedrijfsvoering perspectief, namelijk kan ik mijn bedrijf operationeel houden? Je kan ook focus hebben op de data, waar verblijft deze? Of je kijkt naar de geldende wetgeving, is de Amerikaanse Patriot act van kracht, of is de Europese wetgeving leidend? Als laatste is er het technische perspectief, welke technische maatregelen kan of moet ik treffen? Na studie (o.a. het AWS perspectief middels een online cursus), discussie met klanten en collega’s, cloud leveranciers white papers en – niet geheel onbelangrijk – er goed over nadenken, is het volgende mijn kijk op de zaak.

Eerst studeren dan maar

De externe bronnen die ik als eerste heb geraadpleegd zijn bijvoorbeeld Gartner, wat is hun kijk op deze materie. Maar ook AWS, Microsoft en Oracle hebben aanbod op dit onderwerp. Erg nuttig vond ik zelf informatie van de Europese Commissie zelf. Zo kan je online het “Cloud Sovereignty Framework” document vinden met daarin verschillende perspectieven op dit onderwerp. Zo kijkt zij naar de “Sovereignty Objectives”, de “Sovereignty Effective Assurance Levels” en “Assessment of Sovereignty Effectiveness”. Als laatste biedt zij een rekenmodel voor een “Sovereignty Score”. Dit laatste heeft vooral betrekking op aanbestedingen.

Voor mijzelf is het technisch / IT perspectief interessanter. Wat kunnen  / moeten we doen voor onze digitale soevereiniteit? En als je er goed over nadenkt, dan hebben die maatregelen veel weg van de maatregelen die we treffen bij security-onderwerpen. Die moet ik als cloud architect (of security architect) vaak meenemen in ontwerpen en adviezen. Het gaat dan om het mitigeren van (security) risico’s. In dit geval risico’s van geopolitieke aard, maar ook die leiden tot technische maatregelen. Dus is het dan gewoon “Risk management”?

Centraal bij security risico’s is dat je als bedrijf “In control” blijft. In control van wie er toegang hebben tot data, in control van wie er gebruik maken van ons netwerk en zo verder. Waarom wil je als bedrijf “In control” zijn? Dat is om zeker te kunnen stellen dat de bedrijfsvoering doorgang kan vinden. De bedrijfsvoering vraagt (vaak) dat de IT weerstand kan bieden aan verstoringen van welke aard dan ook (“Resilience”). Daarbij wil een bedrijf of organisatie in staat blijven veranderingen in de IT aan te kunnen brengen, bijvoorbeeld als de bedrijfsvoering daarom vraagt, of wanneer wet- en regelgeving verandert.

IT capabilities

Vanuit een IT architectuur bezien gaat het wat mij betreft vooral over “IT Capabilities” – kennis, kunde en verworvenheden. Als de “IT capabilities” toenemen, is men steeds beter in staat verstoringen te weerstaan en keuzes te maken die bij de bedrijfsontwikkeling passen. Op welke zaken heeft dit dan betrekking? Wat mij betreft zie ik (minimaal) de volgende onderwerpen waarbij je “In control” moet blijven:

• software development
• security
• scalability
• availability
• licenses
• hardware
• (geo) locatie van data en
• vendoren

Ik zie eigenlijk een soort denkbeeldige ladder waarbij je omhoog klimt en steeds meer “IT capabilities’ verwerft. Helemaal onderaan de ladder is een situatie waarbij er sprake is van “Technical debt”. Er worden verouderde software en platformen gebruikt, men is niet goed in staat aan de eigen software verder te ontwikkelen, er zijn in toenemende mate security risico’s. Er is veel handwerk. En er worden proprietary software en licenties gebruikt – waarvan men moeilijk af raakt. Eigenlijk is men niet in staat enig risico te mitigeren.

Applicatie modernisatie, de eerste stap

Hierna volgt de reis van de applicatie modernisatie. Platformen worden vernieuwd (zowel hardware als software) en met behulp van moderne software development tools kan de ontwikkeling van de eigen software weer gestart worden. Er kunnen nu weer keuzes gemaakt worden, men kan operationele uitdagingen mitigeren, bijvoorbeeld op het gebied van availability, resilience, licenties en security. Men neemt voorzichtige eerste stappen met het automatiseren van IT processen, installaties en configuraties.

Digital Sovereignty “ready”

In het volgende “Plateau” is de mate van automatisering groter zodat dat men in staat is om “Workloads” op verschillende (cloud) platformen te draaien. Er komt grip op de data residency (waar staat mijn data) en zaken als hoge beschikbaarheid (multi site) kunnen gerealiseerd worden. Ook krijgt men meer grip op leveranciers, er kunnen tenslotte keuzes gemaakt worden en veelal gaat men nu Open Source Software (OSS) gebruiken. De risico’s die nu gemitigeerd kunnen worden zijn van tactische aard. Eigenlijk is het bedrijf klaar om “Digital Sovereignty” te bereiken als dat gewenst zou zijn.

Strategische controle

Naar mijn idee is het hoogste “Plateau” een niveau waarin de organisatie grip heeft op alle “IT capabilities” die er zijn. Men kiest voor Open Source Software (en containers bijvoorbeeld) waar men dat wil en waar men vrijwillig kiest voor afhankelijkheden waar mogelijk. Men is daarbij in “Control of data residency”. Eigenlijk heeft men de functionaliteit losgekoppeld van de technische implementatie. Hierdoor ontstaat ruimte om te kunnen manoeuvreren en de risico’s die daarbij dus gemitigeerd kunnen worden zijn van strategische aard.

Voor mij gaat “Digital Sovereignty” dus om het beklimmen van de “Ladder” van “IT capabilities”. Bedrijven en organisaties die hoger op deze “Ladder” staan zullen dus beter in staat zijn de “Digital Sovereignty” te bereiken. Mijn suggestie daarbij is, laten we het een discussie maken over “IT capabilities”.