Het meten van de effecten van verduurzaming in softwareontwikkeling

Een groene verschuiving

De noodzaak voor bedrijven om milieubewuste praktijken toe te passen in softwareontwikkeling wint snel aan momentum. Deze verschuiving wordt gedreven door uiteenlopende motieven: idealistische ambities (bijdragen aan een beter milieu), pragmatische overwegingen (groene softwareontwikkeling blijkt kostenefficiënt), het vooruitlopen op regelgeving die vrijwel zeker zal volgen, of zelfs door een meer cynisch streven naar een beter imago.

In deze tijd van toenemend bewustzijn zien steeds meer bedrijven de transitie naar duurzamere softwareontwikkeling als een interessante investering. Naast de duidelijke voordelen kan deze groene verschuiving ook het volledige ontwikkelproces – direct en indirect – efficiënter maken. Hoe dan? Door een professionelere en meer integrale aanpak af te dwingen bij het bouwen en onderhouden van software. Een groene aanpak vereist grondige analyse, wat niet alleen als documentatie kan dienen, maar ook verborgen inefficiënties aan het licht kan brengen. Door deze inefficiënties op te lossen, kunnen ontwikkel- en onderhoudskosten dalen, ontwikkelsnelheid toenemen, en prestaties en codekwaliteit verbeteren.

Maar dan rijst de vraag: wat moet een organisatie concreet doen om deze groene verschuiving in te zetten – en misschien nog belangrijker – hoe meet je het succes?

Overwegingen bij het minimaliseren van uitstoot en verbruik

Het doel van groene softwareontwikkeling is koolstofefficiëntie: zo min mogelijk CO₂-uitstoot per eenheid werk. Toch zijn er meer aspecten dan alleen emissie. Denk bijvoorbeeld aan het beoogde gebruik van de software: draagt het bij aan schadelijke praktijken zoals fracking, of helpt het juist het regenwoud beschermen? Softwareontwikkeling heeft ook een indirecte invloed op de productie en afvoer van hardware – en die hardware kan schadelijke of zelfs giftige materialen bevatten. Desondanks blijft het terugdringen van CO₂-uitstoot de hoogste prioriteit.

De ambitie om CO₂-uitstoot te beperken betekent vanzelfsprekend ook een streven naar energie-efficiëntie, met het besef dat elektriciteit een goede indicator is voor CO₂-uitstoot. Een energiezuinige applicatie is dus ook een koolstofefficiënte applicatie, en het minimaliseren van stroomverbruik is een vorm van verantwoordelijkheid nemen.

Het kwantificeren van het energieverbruik van een applicatie is hierbij een essentiële stap – maar niet de enige. Begrippen als Power Usage Effectiveness (PUE) en energy proportionality voegen extra lagen van complexiteit toe. Ze bieden inzicht in hoe efficiënt hardware wordt benut en maken transparant hoe applicaties zich in de praktijk gedragen qua energieverbruik.

Gebruik energie wanneer deze schoner is

Wat het complexer maakt, is dat carbon awareness een dynamisch element introduceert: koolstofintensiteit. Koolstofintensiteit geeft aan hoeveel koolstof (CO₂-equivalent) wordt uitgestoten per kilowattuur (kWh) verbruikte elektriciteit. Dit varieert per locatie en per moment van de dag.

Handelingen zouden afgestemd moeten worden op de koolstofintensiteit van energiebronnen – door middel van vraagverschuiving en vraagsturing. Dit houdt in dat energieverbruik verplaatst wordt naar andere locaties of tijdstippen, zodat middelen optimaal worden ingezet tijdens perioden van lage koolstofintensiteit – en juist worden beperkt tijdens momenten met een hoge uitstoot.

Verminder de hoeveelheid embodied carbon

Embodied carbon – de CO₂-uitstoot die vrijkomt bij de productie en afdanking van een apparaat – benadrukt het belang van het verlengen van de levensduur van hardware om de uitstoot te spreiden over een langere periode. Hardware zal uiteindelijk altijd defect raken, maar applicaties die soepel blijven draaien op oudere systemen verlengen indirect de levensduur van die apparaten en verlagen zo de totale CO₂-uitstoot.

Door embodied carbon komt cloud computing naar voren als een energie-efficiënter alternatief voor on-premises software. Het is beter om één server voor 100% te benutten dan vijf servers op 20%, juist vanwege de uitstoot die gepaard gaat met de productie van hardware. Cloudoplossingen bieden bovendien de flexibiliteit om vraagsturing en -verschuiving toe te passen.

Waar begin je met meten?

Het meten van CO₂-uitstoot biedt niet alleen inzicht in de huidige situatie, maar vormt ook het vertrekpunt voor een strategie. Het geeft een basislijn waaraan toekomstige metingen kunnen worden gespiegeld. Het doel: een reeks metingen over de tijd heen.

Meestal wordt gemeten volgens het GHG-protocol, dat uitstoot indeelt in drie categorieën:

1. Directe uitstoot;
2. Indirecte uitstoot door ingekochte energie;
3. Andere indirecte uitstoot, zoals die uit de toeleveringsketen, zakelijke reizen en het gebruik van producten.

Het berekenen van software-gerelateerde uitstoot binnen deze scopes is bijzonder complex en vaak zeer uitdagend. De meeste organisaties hebben hulp van gespecialiseerde consultancy nodig om überhaupt tot een bruikbare schatting te komen.

Een alternatief is de Software Carbon Intensity (SCI)-maatstaf, ontwikkeld door de Green Software Foundation. Deze methode kwantificeert software-emissies op basis van energieverbruik, locatiegebonden marginale CO₂-uitstoot, en embodied emissions, gecombineerd met een functionele eenheid.

Om een SCI-score te berekenen, doorlopen bedrijven de volgende stappen:

1. Bepalen wat er binnen scope valt, zodat alle belangrijke onderdelen die bijdragen aan de werking van de software worden meegenomen;
2. Kiezen van een functionele eenheid die het beste past bij hoe de applicatie schaalt (bijv. per gebruiker, per verzoek, per transactie);
3. Vaststellen van een kwantificatiemethode: meten met echte data of berekenen via modellen – hierbij biedt de Software Carbon Intensity Guide houvast;
4. Kwantificeren van de SCI-score voor elk softwarecomponent binnen de afgebakende scope, rekening houdend met meerdere scenario’s om inzicht te krijgen in gedrag onder diverse omstandigheden.

Een probleem bij zowel het GHG- als het SCI-model is dat bedrijven grotendeels zelf kunnen bepalen wat ze wel of niet meenemen in de berekeningen. Dit ondermijnt de objectiviteit van de metingen. Een ander knelpunt is dat het proces vaak veel handmatig werk vereist. Maar softwareontwikkeling draait om automatisering – en gelukkig is automatisering ook op dit vlak goed mogelijk.