Groene software: Meten om te weten en te verbeteren

Dit is blog 13 in de blogreeks over Green IT.

Meten is weten, zeker als het gaat om de CO2-uitstoot. Sinds eind jaren '90 zetten organisaties zich in voor een uniforme methode om hun voetafdruk in kaart te brengen. Dit maakt gegevens onderling vergelijkbaar en stimuleert het nemen van concrete stappen richting verbetering.

Bij de inzet van groene software is het essentieel om te begrijpen hoe de inspanningen van jouw organisatie bijdragen aan een vermindering van het energieverbruik en de daarmee samenhangende CO2-uitstoot. De laatste twee principes van groene software richten zich dan ook op het meten van prestaties en het vaststellen van de doelstellingen voor deze prestaties. Het doel is niet alleen meten om te weten, maar ook meten om te verbeteren.

Principe 5 – Meten ‘Wat je niet kunt meten, kun je ook niet verbeteren’

De bekendste manier om CO2-uitstoot te rapporteren, is via het Greenhouse Gas Protocol. Dat is de basis waarop de meeste bedrijven wereldwijd hun CO2-boekhouding meten en presenteren. (1) Om groene software echt in de praktijk te brengen en stappen naar verbetering te zetten, is het belangrijk dat je begrijpt wat dat protocol inhoudt en dat je ervoor zorgt dat jouw software is afgestemd op de industriestandaarden.

Greenhouse Gas Protocol

Het Greenhouse Gas Protocol is tot stand gekomen door een gezamenlijk initiatief van het World Resources Institute (WRI) en de World Business Council for Sustainable Development (WBSCD). Aanleiding hiervoor was de groeiende vraag eind jaren ’90 naar een internationale standaard voor het meten en presenteren van de CO2-voetafdruk van organisaties.

Het Greenhouse Gas Protocol verdeelt de uitstoot van broeikasgassen (emissies) onder in drie groepen of scopes (2):

• Scope 1: directe emissies vanuit de eigen organisatie (bijvoorbeeld bedrijfsvoertuigen).

• Scope 2: indirecte emissies afkomstig van de opwekking van ingekochte energie, zoals warmte en elektriciteit.

• Scope 3: alle andere indirecte emissies, waaronder emissies afkomstig van aangekochte goederen en diensten, zakenreizen, afvalverwerking, investeringen, vergunningen etc. IT-apparatuur en diensten vallen ook binnen deze scope. Specifiek kijkend naar de erfgoedsector vallen hier ook de fysieke bezoeken aan leeszalen of musea onder, evenals het energieverbruik van websitebezoekers. Deze laatste categorie is vaak het lastigst om te berekenen voor veel organisaties, omdat de informatie hiervoor bij veel verschillende partijen moet worden opgevraagd.

Als alle organisaties en mensen over de hele wereld hun uitstoot op deze manier zouden bijhouden, zou het totaal van alle uitstoot in scope 1 theoretisch gezien overeenkomen met het totaal van de wereldwijde uitstoot.

Het Green House Gas Protocol is verder uitgewerkt in specifieke standaarden voor bedrijven en overheden, maar ook voor het meten van beleid en actieplannen, projecten, producten en steden. Een hiervan is de Corporate Standard die door de meeste (grote) bedrijven wordt gebruikt om de broeikasuitstoot te meten.

Hoe pas je deze meetmethode toe op software?

Voor het berekenen van de totale uitstoot van software zijn gedetailleerde gegevens nodig over energieverbruik, koolstofintensiteit (de samenstelling van de energiemix) en de gebruikte hardware. Het kan een uitdaging zijn om deze informatie te verkrijgen, vooral bij open source software. Want wie draagt de verantwoordelijkheid voor welk deel van de uitstoot?

Preciezer meten? Kijk naar de software cabon intensity specification

De rapportage op basis van het Green House Gas Protocol biedt waardevolle inzichten in de samenstelling van je emissies. Het is alleen wel lastig om je inspanningen voor het vergroenen van je software hiermee meetbaar te maken. Om dit beter te kunnen aanpakken heeft de Green Software Foundation een eigen methode ontwikkeld om de uitstoot van software te meten: de Software Carbon Intensity Specification (SCI).

Het doel van de SCI is de duurzaamheid van software te kunnen meten. Op basis van de uitkomst kan een organisatie dan maatregelen nemen om de uitstoot van software te verminderen. Ook is het hiermee mogelijk om het effect van verbeteringen die je hebt doorgevoerd in je software te meten, wat organisaties aanmoedigt om te blijven verbeteren.

De SCI vervangt het GHG Protocol niet, maar dient als een aanvullende meting. De vergelijking die de Green Software Foundation maakt, is treffend: de SCI is als het meten van de brandstofefficiëntie per gereden kilometer, terwijl het GHG Protocol de totale CO2-voetafdruk van een autoproducent en al hun geproduceerde auto’s in een jaar aangeeft. De CSI is dus een specifieker radartje in het grotere geheel.

De SCI volgt niet de indeling van scopes 1 – 3 voor CO2-uitstoot, maar groepeert ze in operationele uitstoot (de uitstoot die wordt veroorzaakt door het draaien van de software) en embedded uitstoot (de uitstoot van de hardware die nodig is om de software te laten werken).

In eerdere blogs over groene software hebben we gezien dat het verbeteren van zowel de energie-efficiëntie en hardware-efficiëntie als het koolstofbewustzijn van je applicatie een positief effect heeft. Dit zie je ook terug in je SCI-score, die omlaag gaat. Dit is ook de enige manier om de score te verlagen. Je moet dus echt aan de slag. De SCI kan niet worden gemanipuleerd door CO2-uitstoot af te kopen. Als een organisatie geen concrete inspanningen levert om de uitstoot te verminderen, zal ze geen goede SCI-score behalen.

Voor de wiskundige details van deze methode verwijs ik graag naar de website van de Green Software Foundation (3), waar de methode uitgebreid wordt toegelicht, inclusief de richtlijnen voor het afbakenen van projecten en hoe je verantwoording aflegt.

Principe 6 – Klimaatverplichtingen ‘CO2-uitstoot besparen is niet gelijk aan compenseren’

We zijn aangekomen bij het laatste principe van groene software: de klimaatdoelstellingen van jouw organisatie. Uiteindelijk moeten de inspanningen op het gebied van groene software bijdragen aan het verminderen van je CO2-uitstoot. Hoe ambitieus je hierin bent, hangt af van de keuze van jouw organisatie. Sommige organisaties streven naar ‘net zero’, terwijl andere gaan voor ‘CO2-neutraal’ of zelfs ‘CO2-negatief’. Maar wat betekenen deze termen nu eigenlijk?

Verschillende manieren om emissies terug te brengen

Science Based Targets (SBT) zijn doelen die gebaseerd zijn op wetenschappelijke inzichten. Door te werken met deze doelen weet je of je doelstellingen (kijkend naar de aard en omvang van je organisatie) voldoende zijn om het Klimaatakkoord van Parijs te halen. Deze doelen vallen uiteen in drie categorieën:

• koolstofeliminatie (reductie) – de meest effectieve manier om klimaatverandering tegen te gaan;

• koolstofvermijding (compensatie) – inzetten van hernieuwbare energiebronnen, aanpassingen in levensstijl, recycling en het planten van bomen;

• koolstofverwijdering (neutralisatie) – het verwijderen en permanent opslaan van koolstof uit de atmosfeer om het effect van het vrijkomen van CO2 te neutraliseren.

Organisaties kunnen verschillende doelen nastreven, bijvoorbeeld:

• ‘carbon neutral’ of koolstofneutraal: de totale uitstoot is gelijk aan het totaal van de CO2-compensaties door reductieprojecten;

• ‘net zero’ of netto nul: een organisatie richt zich op het zoveel mogelijk elimineren van CO2-uitstoot en compenseert alleen de overgebleven emissies die niet geëlimineerd kunnen worden.

De Europese Commissie heeft zichzelf als doel gesteld om in 2050 ‘net zero’ te zijn. Alle maatregelen die door de EU-lidstaten worden genomen, moeten dus uiteindelijk tot dit doel leiden. Hier moeten wij als organisaties gevestigd in de EU dus ook aan bijdragen!

Aan de slag

Ongeacht de gekozen doelstelling kan groene softwareontwikkeling een belangrijke rol spelen. Groene software streeft altijd naar maximale beperking van de uitstoot, met energie-efficiëntie, hardware-efficiëntie en CO2-bewustzijn als kernprincipes. In deze blogserie heb je praktische handvatten gekregen om met deze onderwerpen aan de slag te gaan.

Als je zelf geen software-ingenieur bent, zijn hier de vragen samengevat waarmee je het gesprek met ontwikkelaars of leveranciers kunt aangaan:

• Hoe kan de gebruikte apparatuur zo efficiënt mogelijk worden belast (energieproportionaliteit)?

• Hoe kan statisch stroomverbruik zo veel mogelijk worden voorkomen?

• Wat is de verhouding tussen groene en grijze stroom in de energiemix die we gebruiken? (CO2-intensiteit)

• Hoe kunnen we CO2-intensiteit verminderen? Welke mogelijkheden zijn er om de vraag te verplaatsen (andere locatie, ander tijdstip) of aan te passen aan het aanbod?

• Hoe kan de levensduur van de gebruikte hardware worden verlengd?

Door rekening te houden met deze vragen, kun je de CO2-uitstoot gerelateerd aan software verminderen. Wil je de impact van je inspanningen meten, bereken dan de CSI-score.

Over deze blogserie

Deze blogpost is onderdeel van een serie blogposts over Green IT geschreven in opdracht van de gelijknamige netwerkgroep van het Netwerk Digitaal Erfgoed (NDE). Deze netwerkgroep monitort de ontwikkelingen rondom Green IT en de impact van de voortschrijdende digitalisering op het klimaat. Specifiek wordt daarbij gekeken naar de (toenemende) digitalisering binnen de erfgoedsector.

Eerder verschenen in deze blogserie

Thema: Introductie Green IT

1 De dubbele rol van IT in duurzaamheid

2. De noodzaak van een duurzaamheidskader voor de erfgoedsector

Thema: Dataopslag

3. De digitale databerg

4. De verborgen impact van cloudopslag

5 1% van alle data ter wereld bewaren – wat kost dat aan CO2-uitstoot?

6 De zoektocht naar duurzame alternatieven voor disks en tapes

7 Dataopslag in synthetisch DNA: coderen en decoderen in geheimschrift

8 Dataopslag in atomen: sciencefiction of toekomstige realiteit?

9 Dataopslag in glas: Superman is alvast vereeuwigd

Thema: Groene Software

10 Groene software: minder energie = minder CO2-uitstoot

11 Groene software: Meer doen als de energie schoner is

12 Groene software: Verleng het leven van je (gebruikte) IT apparatuur