Digitale soevereiniteit en outsourcing: NDS 0.9

Met de publicatie van het Ontwerp Overheidsbrede Soevereine Clouddienst, versie 0.9[1] krijgt de ambitie van de Nederlandse overheid om digitaal minder afhankelijk te worden een concrete technische uitwerking.

Het ontwerp kiest daarbij voor een interessante benadering van ‘digitale soevereiniteit’. Soeverein betekent dat de overheid zeggenschap heeft over de technologiestack, de data en de operatie. Die zeggenschap moet bovendien aantoonbaar zijn en niet uitsluitend uit contractuele afspraken bestaan. Die zeggenschap moet dus niet alleen op papier bestaan, maar ook in de praktijk kunnen worden uitgeoefend. Operationele autonomie omvat bijvoorbeeld keuzevrijheid op het gebied van technologie, de aanwezigheid van voldoende kennis binnen de eigen organisatie, beperking van toegang tot cruciale onderdelen en controle over de supply chain. Het ontwerp erkent echter dat volledige technologische onafhankelijkheid op dit moment niet haalbaar is.

Om de mate van digitale soevereiniteit aan te geven, maakt het ontwerp gebruik van de Europese SEAL-classificatie (Sovereignty Effectiveness Assurance Level). Deze classificatie onderscheidt verschillende niveaus van soevereiniteit. SEAL-4 staat voor volledige soevereiniteit, waarbij de zeggenschap binnen de Europese Unie ligt en geen kritieke afhankelijkheden van partijen buiten de EU bestaan. SEAL-3 staat voor technologische autonomie, waarbij nog wel bepaalde externe afhankelijkheden kunnen bestaan.

Voor software wordt gestreefd naar SEAL-4 en voor hardware wordt SEAL-3 gehanteerd. Het ontwerp accepteert daarmee voorlopig een resterende afhankelijkheid van niet-Europese hardware leveranciers. Op het eerste gezicht lijkt dit te wringen, want hoe kan een cloud soeverein worden genoemd als de fundamentele hardware waarop die cloud draait nog steeds afhankelijk is van niet-Europese, en in de praktijk veelal Amerikaanse, technologie? Die schijnbare tegenstrijdigheid is een van de interessantste onderdelen van het ontwerp.

Betekent een Amerikaanse processor automatisch Amerikaanse zeggenschap?

Het is mijns inziens wat kort door de bocht om zonder meer te stellen dat een cloud niet soeverein kan zijn zolang er Amerikaanse processors in de servers zitten. Of de onderliggende infrastructuur nu eigendom is van de publieke instelling zelf, van een beheer- of cloudleverancier of onderdeel vormt van een IaaS- of PaaS-dienst, doorslaggevend is wie feitelijk beheerrechten en toegang heeft. Een Amerikaanse fabrikant heeft niet automatisch zeggenschap over de omgeving zolang er geen zelfstandige beheer- of toegangsrechten zijn.

Belangrijker dan alleen de herkomst van een component is wat we van de fabrikant nog nodig hebben nadat dit component eenmaal in gebruik is. Heeft de fabrikant bijvoorbeeld nog toegang tot de apparatuur of is een externe managementverbinding noodzakelijk? Van belang is of firmware- en microcode-updates door de eigen beheerorganisatie of beheerpartner kunnen worden gecontroleerd en geïnstalleerd, zonder dat de fabrikant daarvoor rechtstreeks toegang tot de productieomgeving nodig heeft. Dat is echt een andere vraag dan de vraag welk land op het etiket van een server of processor staat.

De keuze in het ontwerp voor SEAL-3 voor hardware hoeft daarom niet per se als zwakte te worden beschouwd. Deze keuze maakt vooral zichtbaar dat digitale soevereiniteit niet hetzelfde is als volledige technologische onafhankelijkheid. Er blijft een afhankelijkheid bestaan. De kunst is die afhankelijkheid zichtbaar en beheersbaar te maken en waar nodig te kunnen vervangen. Juist dat maakt Ontwerp 0.9 ook interessant voor een ander vraagstuk: de uitbesteding van ICT. Dat geldt in het bijzonder voor gemeenten en gemeentelijke samenwerkingsverbanden die hun infrastructuur, cloudvoorzieningen en het beheer daarvan geheel of gedeeltelijk bij een externe beheerpartner hebben ondergebracht. Zo’n beheerpartner kan verantwoordelijk zijn voor infrastructuur, platformen en netwerk, maar ook voor monitoring, beveiliging, technisch beheer en de contacten met fabrikanten, cloudproviders en andere toeleveranciers.

Wat betekent operationele autonomie voor een outsourcingrelatie?

Het ontwerp verlangt technologische keuzevrijheid en voldoende kennis binnen de eigen organisatie om de interactie tussen het eigen applicatielandschap en afgenomen clouddiensten te begrijpen en aan te sturen. Omdat ook de toegang tot cruciale onderdelen en de supply chain daarvan moeten worden beheerst, ontstaan andere vragen:

wie beschikt over de feitelijke technische kennis van de infrastructuur?
wie beheert de configuraties?
wie heeft de noodzakelijke beheerrechten en sleutels?
en wie kent de precieze afhankelijkheden tussen componenten?

Ook is van belang wie de contacten met fabrikanten onderhoudt en wie een ernstig incident daadwerkelijk kan oplossen. De kernvraag is uiteindelijk: kan de opdrachtgever gedurende de looptijd voor een ander fabrikaat, een andere fabrikant of een wezenlijk andere technische oplossing kiezen, terwijl de bestaande beheerpartner zijn beheerrol kan blijven vervullen?

Ontwerp 0.9: een andere kijk op outsourcing

Dataopslag binnen de EER en dienstverlening door een partij die binnen de EER is gevestigd, zijn belangrijke waarborgen, maar leveren op zichzelf nog geen digitale soevereiniteit op. Daarvoor moet de opdrachtgever ook voldoende kennis, rechten en invloed behouden om andere technologische keuzes te kunnen maken en deze door zijn beheerpartner te laten uitvoeren.

Ontwerp 0.9 biedt naar mijn mening een bruikbare manier om anders naar outsourcing te kijken. Niet iedere afhankelijkheid hoeft te worden uitgesloten; dat doet het ontwerp zelf immers ook niet. De vraag is vooral wat er gebeurt wanneer zo’n afhankelijkheid daadwerkelijk een beperking wordt. Voor niet-Europese hardware kan dat bijvoorbeeld betekenen dat op langere termijn problemen ontstaan met firmware, security-updates, support, reserveonderdelen of vervanging. De apparatuur kan technisch nog prima functioneren, terwijl de afhankelijkheid van één fabrikant of technologielijn de toekomstige keuzevrijheid steeds verder beperkt.

Bij outsourcing ontstaat een vergelijkbare vraag. Hoe vrij is de opdrachtgever nog om binnen de bestaande beheerrelatie een andere technische keuze te maken? Kan de beheerpartner ook een ander fabrikaat, een andere fabrikant of een wezenlijk andere technische oplossing beheren? Zijn configuraties, scripts en Infrastructure-as-Code voldoende overdraagbaar en reproduceerbaar om een andere technische inrichting mogelijk te maken? Zijn beheerplatformen, monitoring en securityvoorzieningen sterk gekoppeld aan één specifieke technologie of leverancier? En beschikt de opdrachtgever over voldoende kennis, rechten en informatie om zo’n koerswijziging daadwerkelijk te kunnen verlangen en aansturen?

Een goed geregelde exit blijft belangrijk, maar zegt dus nog niet alles over de technologische keuzevrijheid gedurende de looptijd.

Niet alleen kunnen overstappen, maar ook van technologie kunnen veranderen

Ontwerp 0.9 maakt duidelijk dat overstappen niet alleen juridisch, maar ook technisch en praktisch mogelijk moet zijn. Daarvoor moet bekend zijn waar afhankelijkheden zitten van hardware, software, licenties, beheerinterfaces en leveranciers. Ook moet duidelijk zijn of data, configuraties en workloads daadwerkelijk naar een andere technische omgeving kunnen worden gebracht. Afhankelijkheden van specifieke hardware, software, licenties, beheerinterfaces en leveranciers moeten daarom bekend zijn. Ook moet duidelijk zijn in hoeverre data, configuraties en workloads daadwerkelijk naar een andere technische omgeving kunnen worden overgebracht. Een deel van deze problematiek is al bekend uit exit- en re-transitieregelingen. Die regelen wat er gebeurt als de overeenkomst met de beheerpartner eindigt: de leverancier moet meewerken aan de overdracht, informatie beschikbaar stellen en ervoor zorgen dat een opvolgende leverancier de dienstverlening kan overnemen.

Maar dat is een ander vraagstuk. Exit regelt wat er gebeurt als de beheerrelatie eindigt.

Technologische wendbaarheid binnen digitale soeveriniteit

Digitale soevereiniteit stelt daarnaast de vraag wat er mogelijk blijft als de beheerpartner juist wél blijft. Wat gebeurt er bijvoorbeeld als een IaaS- of PaaS-oplossing waarop zijn dienstverlening rust niet langer wenselijk of beschikbaar is? In zo’n situatie moet de beheerpartner binnen de bestaande dienstverlening een reëel alternatief kunnen aanbieden en implementeren. Dat kan betekenen dat wordt overgestapt op een andere fabrikant, een ander fabrikaat, een andere IaaS-dienst of een ander platform, terwijl de beheerpartner verantwoordelijk blijft voor het beheer en de continuïteit van de dienstverlening.

Daarvoor mag de dienstverlening niet zo sterk verweven zijn met één fabrikant, cloudprovider, beheerplatform of leverancierseigen oplossing dat een andere technische keuze feitelijk onmogelijk wordt. De beheerpartner moet voldoende kennis en mogelijkheden hebben om alternatieven toe te passen en de contractuele inrichting moet daarvoor ruimte laten.

Dat is iets anders dan exit-management. Een goed geregelde exit maakt het mogelijk om van beheerpartner te wisselen; technologische wendbaarheid betekent dat ook de technische oplossing kan veranderen zonder dat daarvoor per se de beheerpartner hoeft te worden vervangen.

Van principe naar contract

Deze gedachte sluit aan bij uitgangspunten die Emtio al in recente aanbestedingen voor IT-outsourcing heeft toegepast, maar Ontwerp 0.9 geeft aanleiding om daarin een volgende stap te zetten. Zo is in een recente aanbesteding voor de outsourcing van gemeentelijke IT-infrastructuur gekozen voor vergaande technische ontzorging, terwijl tegelijkertijd nadrukkelijk aandacht is besteed aan de toekomstige keuzevrijheid van de opdrachtgever. In de door Emtio opgestelde aanbestedings- en contractdocumentatie is de re-transitie bij het einde van de overeenkomst uitgebreid geregeld. De leverancier moet actief meewerken aan een succesvolle migratie naar een opvolgende dienstverlener, de exit met die partij afstemmen en daarvoor voldoende gekwalificeerd personeel beschikbaar stellen. Het re-transitieplan moet gedurende de overeenkomst actueel worden gehouden. De opvolgende leverancier of de opdrachtgever moet kunnen beschikken over de voor een soepele overdracht noodzakelijke data, informatie en middelen. Ook mogen geen constructies worden toegepast die een succesvolle re-transitie blokkeren.

Aan de datazijde is de overdraagbaarheid eveneens uitgewerkt. De opdrachtgever moet zijn data kunnen inzien en opslaan en deze moeten in een algemeen leesbaar elektronisch formaat beschikbaar zijn, inclusief documentatie van de onderliggende datamodellen. Dat zijn belangrijke waarborgen voor een toekomstige overstap naar een andere beheerpartner. Daarmee is de klassieke re-transitie goed afgedekt.

Het belang van platformonafhankelijkheid binnen digitale soevereiniteit

De discussie over digitale soevereiniteit legt echter nog een andere vraag op tafel: kan binnen de bestaande beheerrelatie ook de technische oplossing worden vervangen? Daarmee verschuift een deel van de aandacht van alleen overdraagbaarheid van de dienstverlening naar veranderbaarheid van de technische oplossing. De gedachte achter Haven laat zien hoe zo’n vorm van technologische wendbaarheid technisch kan worden ondersteund. Haven is een door de VNG ontwikkelde standaard voor platformonafhankelijke cloudhosting, gebaseerd op Kubernetes. Deze standaard maakt het mogelijk om applicaties op vergelijkbare wijze te laten functioneren bij verschillende cloud- en infrastructuurleveranciers. Een toepassing die geschikt is gemaakt voor Haven, kan daardoor in beginsel ook in een andere Haven-omgeving draaien, terwijl de onderliggende infrastructuur kan verschillen.

Haven lost daarmee uiteraard niet alle afhankelijkheden op. Wie veel gebruikmaakt van specifieke diensten van één cloud- of PaaS-aanbieder kan nog steeds moeilijk verplaatsbaar zijn. Het principe is hier vooral interessant: voorkom dat een keuze voor de onderliggende infrastructuur automatisch ook de toekomstige technische route vastlegt.

Bij toekomstige outsourcingcontracten verdient daarom niet alleen exit en re-transitie aandacht, maar ook de mogelijkheid om tijdens de looptijd een andere technische oplossing toe te passen. Open standaarden, overdraagbare configuraties, Infrastructure-as-Code en het vermijden van onnodige leveranciers-eigen afhankelijkheden kunnen daar concreet aan bijdragen. Waar dat bij het applicatielandschap past, kan ook een benadering als Haven behulpzaam zijn.

Regie vraagt om meer dan contractmanagement

Het Cloudmanifesto legt de regie nadrukkelijk bij de overheid. Richting, architectuur, technische standaarden en inrichting kunnen volgens het manifest niet volledig aan marktpartijen worden overgelaten als de overheid daadwerkelijk soevereiniteit wil behouden. Dat betekent niet dat de overheid de uitvoering weer zelf moet doen. Regie is iets anders dan uitvoering. Regie betekent wel meer dan SLA-rapportages beoordelen, wijzigingen goedkeuren en periodiek overleg voeren. Een opdrachtgever die daadwerkelijk regie wil voeren, moet voldoende technische kennis, informatie en bevoegdheden behouden om alternatieven te kunnen beoordelen en een andere koers te kunnen kiezen. Wie alle technische kennis uitbesteedt, kan op papier opdrachtgever blijven maar wordt in de praktijk steeds afhankelijker van de partij die die kennis bezit.

En natuurlijk betekent dit niet dat outsourcing moet verdwijnen. Ook de Overheidsbrede Soevereine Clouddienst zal afhankelijk blijven van marktpartijen, en vaak dus specialistische externe expertise, en zoals de keuze voor SEAL-3 laat zien, voorlopig zelfs van niet-Europese hardware. Werkzaamheden kunnen prima worden uitbesteed zonder ook de zeggenschap over de architectuur uit handen te geven. Voor specialistische kennis geldt hetzelfde: die kan worden ingekocht zonder dat één beheerpartner daarmee onvervangbaar wordt. Ook het gebruik van niet-Europese hardware hoeft niet te betekenen dat de fabrikant structurele beheerrechten krijgt.

Een beheerpartner kan dus vergaande verantwoordelijkheid krijgen voor de dagelijkse operatie, zolang de opdrachtgever voldoende kennis, rechten en invloed behoudt om ook een andere technische koers te kunnen verlangen en aansturen.

Nieuwe clouddiensten naast bestaande overheidsvoorzieningen

De nieuwe clouddienst wordt naast bestaande overheidsvoorzieningen en marktaanbod opgebouwd. Ook erkent het ontwerp dat niet alle bestaande workloads onmiddellijk naar het nieuwe cloud-native platform kunnen worden gemigreerd. Daarmee ontstaat voor overheidsorganisaties een belangrijke tussenperiode. De vraag is niet alleen wanneer de nieuwe soevereine cloud beschikbaar komt. Voor gemeenten en andere overheidsorganisaties is vooral relevant of de ICT die zij vandaag inkopen en gebruiken later ook naar een andere, meer soevereine omgeving kan worden overgebracht.

Wie nu een nieuwe infrastructuur- of outsourcingovereenkomst sluit, kan al rekening houden met open standaarden, portabiliteit, overdraagbare configuraties, Infrastructure-as-Code, kennisborging en de mogelijkheid om tijdens de looptijd andere technische oplossingen toe te passen. Voor bestaande outsourcingovereenkomsten is het evenmin noodzakelijk dat deze vanwege Ontwerp 0.9 worden opengebroken. Wel kan de publicatie aanleiding zijn om gedurende de looptijd opnieuw te kijken naar portabiliteit, kennisborging, beheerrechten, afhankelijkheden van toeleveranciers en de vraag of binnen de bestaande beheerrelatie voldoende ruimte bestaat om later een andere technische oplossing te kiezen.

Bredere beleidsontwikkeling binnen digitale soevereiniteit

Dat sluit ook aan bij de bredere beleidsontwikkeling. De overheid werkt aan vermindering van afhankelijkheid van een klein aantal externe leveranciers en betrekt digitale soevereiniteit nadrukkelijker bij sourcing en inkoop. Open Kamer Digitale soevereiniteit is daarmee geen onderwerp dat pas relevant wordt zodra de nieuwe overheidscloud gereed is, want er kan vandaag al op worden voorgesorteerd.

Het document kan niet alleen worden gelezen als architectuurontwerp voor een nieuwe overheidscloud. Het kan ook als spiegel worden gebruikt voor de ICT die overheidsorganisaties vandaag inkopen en uitbesteden. Als voor de nieuwe overheidscloud open architectuur, open standaarden, overdraagbaarheid, expliciete afhankelijkheden, controle over de supply chain, beperkte externe toegang en aantoonbare exit-mogelijkheden belangrijke uitgangspunten zijn, ligt het voor de hand om dezelfde principes ook te betrekken bij reguliere outsourcing.

De spanning tussen SEAL-4 voor software en SEAL-3 voor hardware maakt daarbij iets belangrijks duidelijk en dat is dat digitale soevereiniteit niet vereist dat iedere afhankelijkheid onmiddellijk wordt geëlimineerd. Zij vereist wel dat we weten waar de afhankelijkheden zitten, welke gevolgen zij hebben en of we ze kunnen beheersen, vervangen of verlaten.

Als we straks daadwerkelijk workloads naar een soevereinere omgeving willen kunnen brengen, moeten we vandaag al voorkomen dat architectuur, kennis en beheer zo met één leverancier of technologie verweven raken dat een toekomstige technologische koerswijziging praktisch onmogelijk wordt.

Wat betekent Ontwerp 0.9 voor aanbestedingen?

Voor Emtio wordt de discussie over digitale soevereiniteit vooral praktisch zodra zij wordt vertaald naar sourcingstrategie, architectuurkeuzes, aanbestedingseisen, beoordelingscriteria en uiteindelijk de overeenkomst. Er zijn enkele vragen te beantwoorden:

Welke afhankelijkheden zijn aanvaardbaar en welke niet?
Welke kennis, rechten en informatie moet de opdrachtgever zelf behouden om een andere technische keuze te kunnen maken?
Hoe zorgen we ervoor dat de beheerpartner tijdens de looptijd een alternatief kan aanbieden en implementeren als de bestaande oplossing niet langer wenselijk of beschikbaar is?

Het zijn geen vragen die pas aan het einde van een contract thuishoren. Ze horen al thuis bij de sourcingstrategie en moeten vervolgens hun weg vinden naar de aanbesteding en de overeenkomst.

Emtio adviseert overheidsorganisaties bij juist die vertaling: van strategische keuzes over cloud, outsourcing en digitale soevereiniteit naar een aanbestedings- en contractarchitectuur die ontzorging mogelijk maakt zonder de toekomstige keuzevrijheid van de opdrachtgever weg te contracteren. De hiervoor beschreven praktijk laat zien dat veel bouwstenen daarvoor al beschikbaar zijn. Ontwerp 0.9 geeft aanleiding om daar een volgende dimensie aan toe te voegen: naast een goed geregelde exit ook voldoende technologische wendbaarheid tijdens de looptijd.

Dit alles leidt tot het advies: besteed de uitvoering uit waar dat verstandig is, maar besteed nooit het vermogen uit om van koers te veranderen.