Arnold van der Veen Meerstadt schreef een reflectie over “Wat kost digitale autonomie écht?” waarin hij probeert de discussie over de prijsvergelijking tussen een klassieke Microsoft stack tegenover een klassieke open source stack zoals de Noord-Duitse regio Sleeswijk-Holstein implementeert. Het is een interessante lectuur en voegt heel facetten toe die vaak over het hoofd gezien worden.

Hieronder volgen een aantal quotes uit de analyse van Arnold - hopelijk doe ik hiermee eer aan de teneur van de tekst - en plaats ik er enkele kanttekeningen bij.

(…) Opvallend is echter dat het debat dat daarop volgt zich vooral richt op principes en waarden, terwijl de kostenkant slechts fragmentarisch wordt besproken. Wanneer kosten ter sprake komen, gaat het meestal over licenties of eenmalige migratiebudgetten. Daarmee blijft een belangrijk deel van de werkelijkheid buiten beeld.

Dit is een zeer terechte vaststelling: het is bijzonder moeilijk om een TCO-plaatje op te stellen. Maar dit geldt in beide richtingen. Veel zal ook afhangen van wat in deze TCO opgenomen wordt. Vaak zal dit zich reflecteren in de wijze waarop een aanbesteding uitgeschreven wordt.

Een heldere en ondubbelzinnige definitie van wat wel en niet inbegrepen moet zijn in de bepaling van deze TCO, is dan ook een sleutelcomponent van een sterke aanbesteding.

De vraag die hier centraal staat, is daarom niet normatief maar analytisch: wat betekent de keuze voor digitale autonomie financieel en organisatorisch, wanneer niet alleen naar softwareprijzen wordt gekeken, maar naar het volledige kostenbeeld over meerdere jaren?

Kostenbeeld is inderdaad maar één facet. Het Europese “Cloud Sovereignty Framework” voegt inderdaad een aantal criteria toe die terecht thuishoren in een aanbesteding (of evaluatie). Er zal bepaald moeten worden voor elk van de SOV-domeinen welk SEAL-level nodig is voor een veilige werking. Waar het framework echter tekortschiet, is in de manier waarop de weging naar voor geschoven wordt. Deze zal afhangen van de lokale context, en dus niet een of ander gewogen gemiddelde zijn. Hoe bepaal je überhaupt de kost van een datalek? Ik neem aan dat hiervoor ook rekenmodellen zullen bestaan, en logischerwijs zullen deze in grote mate afhangen van de gevoeligheid van de dataset en ook de grootte ervan.

Voor bijzonder gevoelige omgevingen (bijv. advocatuur, jurisprudentie, geneeskundige diensten) zal een zeer hoge SEAL-level belangrijker zijn. Echter, reeds meermaals stelde ik Microsoft medewerkers de vraag welke SEAL-levels voor de verschillende SOV-domeinen gerealiseerd kunnen worden op Microsoft-servers op Europese grond. Nog geen enkele keer kreeg ik hierop enig antwoord.

Aan de ene kant staat een geïntegreerd hyperscaler-model, waarin e-mail, documenten, samenwerking, security, lifecycle-management en innovatie sterk zijn geïntegreerd en grotendeels extern worden ontwikkeld en beheerd. Aan de andere kant staat een autonomie-model op basis van open source, waarin licentiekosten lager zijn, maar architectuur, integratie, beveiliging en doorontwikkeling expliciet onder eigen verantwoordelijkheid vallen, vaak met meerdere leveranciers en interne teams.

De scope is daarbij bewust beperkt tot de digitale werkplek en samenwerking. Vakapplicaties en primaire bedrijfsprocessen zijn buiten beschouwing gelaten om de vergelijking zuiver te houden.

De kernvraag is wat er met de totale kosten gebeurt wanneer een organisatie er bewust voor kiest om industriële schaal en collectieve innovatie los te laten en daarvoor autonomie en regie terug te nemen.

Dit blok raakt inderdaad de essentie van de problematiek aan - en illustreert ook waarom het belangrijk is om deze vendor-wurggreep op een bepaald moment in vraag te stellen. Was het inderdaad alleen een kwestie van één office suite te vervangen door een andere office suite, één mail-service te vervangen door een andere - dan was deze migratie een simpel verhaal. Voor deze zaken zijn er eenvoudige migratiepaden. Voor dit soort toepassingen is het gebruik van open standaarden al ruim een decennium lang ingeburgerd.

Echter, omdat bestaande integraties geen gebruik maken van open standaarden - bijvoorbeeld voor account management, authenticatie, lifecycle-management, integraties, … zijn deze veel moeilijk over te zetten. De kost hiervan kan vaak moeilijk ingeschat worden. Daarom zal het ook belangrijk zijn bij toekomstige aanbestedingen, om ook egress-cost en ownership over custom development op te nemen in de kostenbepaling.

Het geïntegreerd hyperscaler-model zoals het hier genoemd wordt, is essentieel alleen maar sterk geïntegreerd omdat in essentie alle harmonisatie uitbesteed wordt. De keerzijde hiervan is dat custom development grotendeels zal afhangen van de good-will van de beherende partij.

De hier vooropgestelde kernvraag is een kortetermijnvraag. “Als je er bewust voor kiest om industriële schaal en collectieve innovatie los te laten” impliceert dat er geen collectieve innovatie gebeurt in een open source ecosysteem. En de logica gaat op als het gaat over twee gemeentes die hun eigen dingetje gaan doen. Maar als op Europese schaal geïnvesteerd wordt in een aantal collectief gebruikte open source oplossingen (die bovendien open standaarden respecteren), zetten we hier een nieuwe standaard voor collectieve innovatie. En bovendien wordt dit dan een innovatie die niet gebonden is aan één leverancier. Het is paradoxaal hoe “openstellen voor de marktwerking” verkocht wordt als essentieel om innovatie mogelijk te maken… behalve als ’t opeens een groot bedrijf die een monopolie heeft. Dan is het opeens beter om een geïntegreerd model te hebben waarbij er één speler is.

De bepalende aannames

• Een eerste aanname is dat autonomie structureel meer regie vergt. Open source verlaagt licentiekosten, maar vervangt deze door keuzevrijheid. Die keuzevrijheid betekent dat architectuurkeuzes, integraties, security-afwegingen en roadmapbesluiten niet langer impliciet in het platform besloten liggen, maar expliciet door de organisatie zelf moeten worden genomen en afgestemd. Bij hyperscalers zijn veel van deze keuzes vooraf gemaakt en technisch afgedwongen, wat autonomie beperkt maar coördinatie- en regiekosten verlaagt. In een autonome opzet verdwijnen deze kosten niet, maar verschuiven ze naar arbeid, governance en afstemming. Dat is geen tekortkoming van open source, maar een logisch gevolg van autonomie.

Naarmate de schaal waarin een bepaalde open source oplossing ook (zelfs decentraal) geïmplementeerd wordt toeneemt, zal de regiekost ook systematisch afnemen: niet alleen zullen beter UX-implementaties ontwikkeld worden om het beheer te optimaliseren voor bepaalde doelgroepen. Dus op een bepaald moment zal het voordeel van schaal ook van toenemen voor de open source toepassingen naarmate deze meer ingang vindt.

• Een tweede aanname betreft productiviteit. Het gaat hier niet om grote efficiëntiesprongen, maar om dagelijkse frictie. In sterk geïntegreerde ecosystemen zijn e-mail, agenda, documenten, samenwerking, workflow-automatisering en steeds vaker ook AI-ondersteuning nauw met elkaar verweven. Dat vermindert contextwissels en afstemming, vooral in organisaties met veel ketensamenwerking en externe partijen. Open-source-alternatieven zijn functioneel volwassen en verbeteren snel, maar missen vaak die mate van end-to-end-integratie. Het gevolg is geen dramatisch verlies, maar een klein en persistent verschil in dagelijkse handelingen. Individueel is dat nauwelijks merkbaar; op organisatieniveau telt het op.

Dit is een tijdelijk fenomeen - naarmate er meer geïnvesteerd wordt in een ecosysteem van open source toepassingen die open standaarden hanteren, zal ook deze integratie verder toenemen. Hier opnieuw: dit is een probleem van schaal.

• Een derde aanname is dat schaal, en niet softwareprijs, het dominante kostenverschil verklaart. Hyperscalers zijn goedkoper in een integrale kostenbenadering omdat zij innovatie, security, platformontwikkeling en technische schuld collectiviseren over miljoenen klanten. In een autonome opzet worden diezelfde kosten expliciet en lokaal gedragen. Wat in het ene model impliciet en verpakt is, wordt in het andere model zichtbaar en organisatorisch voelbaar.

Hyperscalers hebben het voordeel van schaal - maar vormen ook een single point of failure. De hele filosofie die het internet groot gemaakt heeft, is het concept van resilience. Als een node plat gaat, zal net netwerk zich organisch herstellen door packets te rerouten. Door opnieuw alles naar één ecosysteem te brengen, wordt het hele concept van het ARPAnet weer weggehaald.

• Daarnaast veronderstelt deze analyse dat hoogwaardige IT-regie, architectuur- en securitycapaciteit schaars is, met name in grote publieke organisaties. Autonomie vraagt niet alleen technische mogelijkheden, maar ook structurele beschikbaarheid van mensen die keuzes kunnen maken, afdwingen en over langere tijd kunnen volhouden. Zonder deze aanname zou elke kostenvergelijking triviaal zijn; de praktijk laat zien dat juist deze capaciteit structureel onder druk staat.

Daarom ook is het essentieel dat ook overheden aan schaalvergroting doen. Laat ons inderdaad geen servertje per gemeente opzetten, maar bijvoorbeeld op provinciaal niveau NOC’s opzetten die zowel voor operations als security kunnen instaan. Door dit te combineren met een overleg-orgaan op landelijk (of zelfs interlandelijk) niveau, wordt het al een pak beter haalbaar om competente systeembeheerders en security experts te vinden. Bovendien zullen deze experts een veel hogere sense of ownership hebben over hun infrastructuur.

Dit zal ook de brain-drain (minstens voor een deel) tegengaan, waardoor onze grootste IT-talenten systematisch verkassen naar andere continenten. Wie op vandaag een ernstige carrière ambieert, is bijna genoodzaakt om te verkassen naar de VS of naar Zuid-Oost-Azië.

• Tot slot wordt aangenomen dat de beschreven effecten niet tijdelijk zijn. De extra lasten in regie, productiviteit en innovatie verdwijnen niet vanzelf na een transitieperiode. Niet omdat open source niet volwassen wordt, maar omdat hyperscalers gelijktijdig blijven doorontwikkelen en hun schaalvoordelen behouden. De verhoudingen verschuiven, maar lossen zichzelf niet op.

Praktijk leert ons dat vendor lock-in ervoor zorgt dat winst voor de aandeelhouder regelmatiger de kop opsteekt dan we zouden willen. Er zijn weinig publieke records van prijszetting rond Microsoft producten, maar bijvoorbeeld in het Finse Pirha is een rapport te vinden dat een prijsverhoging van grofweg 25% aankondigt. En omdat een overheid zo afhankelijk is van dit product, kan een bedrijf hier ook mee wegkomen.

De meerkosten zitten niet in software, maar in organisatie: in regie, afstemming, productiviteit en investeringen die in andere modellen collectief worden gedragen.

Akkoord: het kostenverhaal is niet de belangrijkste factor (al is het wel de meest zichtbare remmende factor op dit ogenblik). Andere factoren die meespelen op de achtergrond en een verdere integratie met deze grote bedrijven verder bestendigen, zijn vermoedelijke de geopolitieke situatie waarin bilaterale akkoorden met de VS gesloten worden. En net zoals er voor wapens en handel zowel publieke als diplomatieke akkoorden zijn, zal dit voor IT-infrastructuur niet anders zijn. De vraag dient echter gesteld te worden of braaf pootje geven en kwispelen ertoe zal blijven leiden dat we af en toe een kluif toegeworpen krijgen. En of deze nog wel genoeg vlees bevat om onze te verzadigen.

De analyse die hier wordt geschetst laat zien dat digitale autonomie gepaard gaat met een structurele meerprijs. Die meerprijs is geen gevolg van falen, inefficiëntie of tijdelijke kinderziektes, maar vloeit logisch voort uit het loslaten van industriële schaal en het terugnemen van verantwoordelijkheid naar het niveau van de individuele organisatie.

De relevante beleidsvraag verschuift daarmee. Het gaat niet primair om de vraag of autonomie goedkoper kan worden georganiseerd, maar om de vraag of organisaties bereid en in staat zijn deze expliciete kosten te dragen en de bijbehorende regie duurzaam te organiseren.

Akkoord… maar misschien moet ook het tijdskader breder gezien worden dan een electorale periode.

In Technische appendix Sleeswijk-Holstein | LinkedIn zal ik de onderliggende berekeningen en aannames expliciet publiceren, zodat deze analyse kan worden getoetst, herrekend en bekritiseerd. Want het debat over digitale autonomie is gebaat bij minder overtuiging en meer transparant rekenwerk.

Een sleutelwaarde in de bepaling van de TCO-berekening, is de Work Trend Index, opgesteld door Microsoft. Het lijkt me evident dat een studie door hen uitgevoerd, wel degelijk de bevindingen in hun voordeel zal keren. Zoekende naar die Work Trend Index, vond ik niet meteen de precieze bron van die cijfers. Mocht het gaan over dit rapport, dan gaat dit eerder over CoPilot dat gepromoot wordt. Even de omstreden rol van LLM’s in de workflow terzijde latend, kunnen in cloud-omgevingen zoals NextCloud ook LLM’s geïmplementeerd worden. Productiviteit moet dus niet gemeten worden door appelen met peren te vergelijken.

Voor de TCO-metingen, werd in de appendix gewerkt met een termijn van 10 jaar. Andere simulaties (resultaten volgen hopelijk binnenkort), leiden inderdaad tot de conclusie dat de eerste acht jaar de kost aanzienlijk groter is, dat ergens tussen het achtste en negende jaar het break-even punt bereikt wordt en dat daarna de jaarlijkse kost in het voordeel van een FOSS oplossing zal neigen. Na 14 à 15 jaar (afhankelijk van de snelheid van het migratietraject) zou de TCO voordeliger uitdraaien voor een FOSS-implementatie.

Slotbedenkingen

Deze analyse voert een interessante denk-oefening uit, en maakt een potentieel wel doordachte analyse van de directe kosten en winsten van een soevereine cloud, en erkent ook de directe voordelen voor de overheden en organisaties terzake.

De indirecte winsten - voor afgeleide bedrijven en lokale economie, voor de kennisontwikkeling en voor het ondernemerschap binnen eigen land of Europa - worden echter volledig buiten beschouwing gelaten.

Ook de grote risico’s verbonden aan een single point of failure (ten gevolge van technische, politieke, economische of militaire factoren), komt niet aan bod in de genoemde analyse.

Ik wil Arnold bij deze in elk geval graag bedankt door via deze analyse het debat op gang te trekken op een genuanceerde en analytische manier. Laat ons op deze toon verdergaan.