Datacenterlabels: ik wil ook weten wat onze dienst verbruikt

Een gunstig datacenterlabel vertelt nog niet of onze digitale dienstverlening zuinig is ingericht. De Europese Commissie presenteerde op 21 september 2026 een nieuwe beoordelingsregeling voor datacenters. Mijn voorstel is om die ontwikkeling te gebruiken voor een bredere ontwerpvraag: welke rekenactiviteit hebben klanten en medewerkers werkelijk nodig, en welk verbruik hoort daarbij? 1

Wat het nieuwe label wel vertelt

De Commissie wil de energie- en waterprestaties van individuele datacenters beter vergelijkbaar maken. Volgens haar aankondiging volgt eerst een toetsingsperiode van twee maanden door het Europees Parlement en de Raad. De eerste labels worden in 2027 verwacht. Op 27 september is dit dus geen reden om te stellen dat alle datacenters al een nieuw label moeten tonen. 1

Het beoordelingsstelsel kijkt onder meer naar energie-efficiëntie, waterefficiëntie en energiebronnen met lage uitstoot. Ook de bijdrage aan het elektriciteitsnet en de mogelijkheden voor hergebruik van restwarmte krijgen aandacht. De Commissie ziet het label als hulpmiddel voor transparantie en inkoop. 3

Daarnaast loopt een afzonderlijke consultatie over mogelijke minimumprestaties. Reacties kunnen tot 14 december 2026 worden ingediend; een wetgevingsvoorstel is voorzien voor het tweede kwartaal van 2027. Een beoordeling, een consultatie en een geldende minimumeis zijn verschillende zaken. Die zou ik ook in een architectuurbesluit apart benoemen. 2

Voor een organisatie die cloudsoftware afneemt, begint hiermee wat mij betreft het leveranciersgesprek. Op welke locaties wordt onze dienst uitgevoerd? Welke informatie is beschikbaar? En kunnen we die informatie verbinden aan ons eigen gebruik?

Een efficiënter gebouw is nog geen zuinigere dienst

De Commissie benoemt zelf een belangrijke beperking: groei van de geïnstalleerde capaciteit gaat gepaard met groei van het absolute energie- en waterverbruik. Betere efficiëntie vertelt dus niet het hele verhaal. 3

Ook over de vergelijking tussen datacenters bestaat discussie. Branchevereniging CCIA Europe stelt dat de beoordelingsklassen onvoldoende rekening houden met klimaatverschillen en met afwegingen tussen water- en energiegebruik. Dit is de positie van een belangenorganisatie van technologiebedrijven, geen onafhankelijk bewezen oordeel over de regeling. De Commissie benadrukt op haar beurt vergelijking binnen dezelfde regio. 4 3

Ik zou daarom geen leverancierskeuze baseren op één letter of één gunstig percentage. Vraag om de betekenis van de score, de meetperiode en de omstandigheden. Een vergelijking moet ons helpen een besluit te nemen, niet alleen een duurzaamheidsparagraaf vullen.

Stel dat een organisatie een rapport voortaan ieder uur laat verversen, terwijl medewerkers er alleen bij de ochtendstart op handelen. Dan wil ik eerst weten welk besluit die extra actualiteit verbetert. Als niemand die vraag kan beantwoorden, ligt er een concrete ontwerpkans vóórdat we over een ander datacenter praten.

Begin bij het werk dat waarde oplevert

Hier ligt voor mij de bijdrage van businessarchitectuur: expliciet maken welke prestatie nodig is voor de dienstverlening. Hoe snel moet een klant antwoord krijgen? Wanneer moet informatie actueel zijn? Wie ondervindt hinder als verwerking later plaatsvindt?

Mijn advies is om bij een gekozen dienst zowel het resultaat als het verbruik te beschrijven. Een afgeronde aanvraag kan bijvoorbeeld een bruikbare eenheid zijn, mits ook de kwaliteit wordt vastgesteld. Een technisch geslaagde verwerking die de medewerker opnieuw moet doen, telt dan niet zonder meer als goed resultaat.

Zo voorkom je in het ontwerp dat alleen de verwerking goedkoper of sneller lijkt, terwijl extra herstelwerk buiten beeld blijft. Laat de proceseigenaar bepalen wat een aanvaardbaar resultaat is en laat het technische team onderzoeken welke middelen daarvoor nodig zijn.

Ik zou daarbij ook het totale volume blijven volgen. Lager verbruik per aanvraag en lager totaalverbruik zijn twee afzonderlijke doelen. Het management moet kunnen zien wanneer de organisatie efficiënter werkt, maar door groei toch meer capaciteit nodig heeft.

Maak meetgegevens bruikbaar, inclusief hun beperkingen

Op 15 september nam de Green Software Foundation het Software Water Handbook op als project. Het bundelt gegevensbronnen, voorbeelden en methodische keuzes voor het bepalen van de waterimpact van software. De aankondiging benoemt nadrukkelijk dat ontbrekende energiegegevens per verwerking en ontbrekende verdeelsleutels een verdedigbare berekening kunnen verhinderen. 5

Dat is een relevante waarschuwing voor dataarchitectuur. Ik zou ieder gebruikt cijfer verbinden aan een bron, locatie, periode, meetmethode en afbakening. Is het daadwerkelijk gemeten voor onze dienst, verdeeld over meerdere afnemers of geschat? Leg dat onderscheid vast voordat het cijfer op een dashboard verschijnt.

Ook de begrippen verdienen aandacht. Water onttrekken en water verbruiken betekenen niet hetzelfde; de lokale omstandigheden beïnvloeden bovendien de impact. Het Handbook bespreekt juist die verschillen. 5

De bijbehorende Software Water Intensity-specificatie staat op de projectpagina nog als *pre-draft*: een vroege ontwikkelversie. Ik zou haar gebruiken om meetvragen te verkennen, zonder te suggereren dat er al een definitieve, algemeen vastgestelde norm beschikbaar is. 6

Ontbrekende informatie hoeft een eerste verbetering niet te blokkeren. Wel zou ik dan de onzekerheid zichtbaar maken en precies benoemen welk besluit de beschikbare gegevens wél ondersteunen. Een schatting voor intern vergelijken vraagt een andere onderbouwing dan een publieke claim over de impact van een product.

Ontwerp ruimte om verwerking te verschuiven

De Green Software Foundation bepleitte op 8 september om de verwachte behoefte aan energie en water al vóór infrastructuurbesluiten zichtbaar te maken. Daarbij noemt zij het uitstellen of verschuiven van geschikte werkzaamheden, zoals batchverwerking en indexering. Dat is een voorgestelde ontwerpbenadering, geen bewijs dat iedere toepassing flexibel kan worden uitgevoerd. 7

Voor solution- en cloudarchitectuur vertaal ik dit naar een praktische keuze: welke verwerking moet direct, en welke mag binnen een afgesproken tijdvenster? Daarmee krijgt een technisch mechanisme een betekenis voor de gebruiker.

In het hypothetische rapportvoorbeeld zou ik onderzoeken of verversing vóór de werkdag volstaat. Het ontwerp moet dan ook regelen wat medewerkers zien als gegevens vertraagd zijn, wie een spoedverversing mag starten en hoe mislukte verwerking wordt hersteld. Eerst meten, daarna vergelijken: ik zou vooraf geen besparing beloven.

Voor het infrastructuurteam betekent dit dat capaciteit, locatie en koeling samen met het gebruikspatroon worden beoordeeld. Voor inkoop betekent het dat informatie over de onderliggende dienst onderdeel wordt van de leveranciersafspraken. Een wijziging in uitvoeringslocatie of planning zou ik steeds ook op beveiliging en continuïteit laten toetsen.

Een besluit waarmee een team verder kan

Ik zou beginnen met één bestaande digitale dienst waarvoor de eigenaar en het gebruik duidelijk zijn. Laat het team beschrijven welk resultaat nodig is, welke verwerking daarvoor plaatsvindt en welke gegevens over het verbruik ontbreken.

Kies daarna één wijziging die toetsbaar is: bijvoorbeeld minder vaak verversen of overbodige verwerking wegnemen. Leg vooraf vast welke kwaliteit behouden moet blijven, hoe je vergelijkt en wanneer je terugdraait. Bespreek de uitkomst met de mensen die dagelijks met de dienst werken.

Het nieuwe datacenterlabel kan dat gesprek ondersteunen. Mijn voorgestelde architectuurkeuze is om de verantwoordelijkheid verder te laten lopen: van de behoefte van de gebruiker, via het ontwerp van de dienst, tot de middelen die daarvoor werkelijk worden ingezet.

Bronnen

1. Europese Commissie — Making data centres energy efficient thanks to a new EU rating system (2026-09-21).

1. Europese Commissie — DG Energy — Minimum performance standards for data centres in Europe - public consultation launched (2026-09-21).

1. Europese Commissie — DG Energy — Questions and answers on the Data centre energy efficiency package (2026-09-21).

1. CCIA Europe — EU’s First-Ever Data Centre Rating Scheme Overlooks Engineering And Geographic Realities (2026-09-21).

1. Green Software Foundation — Welcoming the Software Water Handbook as a GSF Project (2026-09-15).

1. Green Software Foundation — SWI — Software Water Intensity (projectpagina; status gecontroleerd op 27 september 2026).

1. Green Software Foundation — What an AI Data Center Takes: Eight Questions to Ask Before We Build (2026-09-08).

Bronnen geraadpleegd op 27 september 2026.