Duurzame realisatie van software

In onze vorige [blog] vroegen we ons af wat duurzame software is – en hoe je die duurzaamheid bepaalt. In deze blog willen we het hebben over het maken vansoftware op een duurzame manier. Waaraan moet je voldoen om met recht te kunnen zeggen: deze software is duurzaam gemaakt?

Het op een duurzame wijze realiseren van een softwareproduct

Duurzame realisatie begint met een duurzame manier van produceren. Bij de productie zorgen we dat we rekening houden met de bekende duurzaamheidsaspecten: economisch, sociaal (individueel en op groepsniveau) en milieu. Maar daar blijft het niet bij. Los van de productie hebben we ook met de levensduur van de software te maken. Hoe zorgen we ervoor dat we, gedurende de gehele levensduur, duurzaam met de software om gaan? En hoe borgen we dit allemaal, in combinatie met een werkwijze zoals Scrum? Op al deze aspecten gaan we in deze blog dieper in.

Duurzaam produceren

Laten we beginnen met de productie. Als het gaat om duurzaam produceren, onderscheiden we twee factoren: de arbeidsomstandigheden waaronder wordt geproduceerd, en de toepassing van energie die nodig is bij de productie.

Eerst de arbeidsomstandigheden. Dat betreft de werkomstandigheden die voor ons gebruikelijk zijn: veilig, binnen wet- en regelgeving, en op basis van een voldoende salariëring. Onder goede arbeidsomstandigheden verstaan we ook: de beschikking hebben over voldoende en adequate hulpmiddelen. In de regel is dit alles goed verzorgd. De tijden van weleer – toen Apple-pioniers dag en nacht in een garage werkten en sliepen – liggen al ver achter ons.

Dan het energieverbruik. De duurzaamheid daarvan is al wat weerbarstiger. Het is van belang groene energie toe te passen – en daarmee zo zuinig mogelijk om te springen. Groene energie gebruiken lukt vaak wel; het energieverbruik beperken is lastiger. Denk daarbij aan reizen naar je werk en aan je werkomgeving. Werk je altijd op locatie, of kan thuis ook? Kun/wil je continu op een eigen laptop werken, of heb je een omgeving nodig met meer en grotere schermen? Voer je het werk efficiënt uit, en zoek je steeds weer naar manieren om minder gebruik te maken van computers – bijvoorbeeld door efficiënter te testen?

De stelregel is: Ontwerp en bouw alles in één keer goed. Hoe minder iteraties je maakt, des te minder energie heb je nodig voor de realisatie. Een tweede stelregel: bouw aan het energie-bewustzijn van je team. Maak zichtbaar hoeveel energie het ontwikkelteam verbruikt en bedenk een manier om je teamleden te laten meedenken over verduurzaming van de werkplek.

We hebben nog een tip, die toepasbaar is op alle aspecten van duurzaamheid: geef de teamleider de opdracht het duurzaamheidsaspect mee te laten wegen in elke fase van de realisatie van het softwareproduct. De teamleider zou bijvoorbeeld regelmatig de arbeidstevredenheid kunnen evalueren.

Inherente duurzaamheid

We breken met dat laatste een lans voor ‘levenscyclusdenken’ bij de realisatie van software. Het product moet duurzaam zijn van wieg tot graf. Met andere woorden: het zou inherent duurzaam moeten zijn. Als je deze manier van denken toepast, neem je bij productie, gebruik, beheer en uitfasering van de software steeds weer de duurzaamheidsaspecten mee. Over duurzaamheidsdenken in de productie van software zeiden we hierboven al iets. Voor gebruik en beheer kun je bijvoorbeeld denken aan:

• Houdt de software rekening met slechtzienden?
• Is de structuur zodanig dat je de software effectief kunt beheren?
• Vraagt de interface-interactie minimaal energieverbruik?
• Is per software-object zichtbaar te maken hoe groot de beheerinspanning is over de tijd?
• Is de software voldoende onafhankelijk van de onderliggende software?
• Is versiebeheer mogelijk zonder steeds weer de software te moeten aanpassen (besturingssysteem, middlewaresoftware en ontwikkelsoftware)?
• [Wat zijn de] gevolgen als de software buiten gebruik wordt gesteld: is dan een minimale inspanning nodig?
• Is de organisatie veroordeeld tot een – kostbaar – proprietary dataformaat, en daarmee tot een complex dataconversieproces?
• Bestaat het gevaar dat de backup size onhandelbaar of betaalbaar wordt, als gevolg van lange bewaartermijnen?
• Heeft het zin om ook klanten te informeren over hun voetafdruk als softwaregebruikers? Zo maak je zichtbaar wat individueel handelen voor effect heeft, en stimuleer je gebruikers om hun gedrag te veranderen.

Zoals je ziet: er zijn talloze vragen te bedenken die mee kunnen helpen om software inherent te verduurzamen.

Duurzaamheid in combinatie met Scrum

Al met al is het integreren van duurzaamheid in de werk- en handelwijze van softwareontwikkelaars een zinvol idee. Het kan zelfs een tweesnijdend zwaard zijn: Integratie van duurzaamheid is goed voor de medewerkertevredenheid, maar ook voor de tevredenheid van afnemers van het product. Je maakt immers zichtbaar welke moeite er is gestoken in de duurzame productie van het product.

Hoe pas je dit soort inzichten toe op een iteratief ontwikkelproces als Scrum? Schematisch gezien ziet dat er zo uit:

Hieronder bespreken we de aandachtspunten zoals weergegeven in de figuur.

1. Duurzaamheidsreview & -preview
   Hiermee kijk je naar de gedane arbeid, beoordeel je deze vanuit duurzaamheid, en tracht je voor de komende sprint nieuwe meeteenheden en -waarden te bepalen. De gevonden meetwaarden kun je dan beoordelen op basis van de plan/do/act-kwaliteitscirkel. Zo probeer je stap voor stap de duurzaamheid van het product te verbeteren. Enige voorbeelden van onderwerpen die van invloed kunnen zijn op duurzaamheid zijn: de gevraagde requirements, de architectuur waarbinnen de software resideert, het hardwarelandschap en de code zelf.
2. Procesbeoordeling om de duurzaamheid van het realisatieproces te verbeteren
   Hierbij verzamel je continu gegevens over de duurzaamheid van het ontwikkelproces. Deze gegevens zijn dan een bron voor de duurzaamheidsterugblik.
3. Duurzaamheidsterugblik
   De terugblik dient om verbeterpunten te vinden in het maakproces van de software. Hierin bespreek je geleerde lessen, tips & trucs of besluiten voor volgende projecten; alles gericht op verbetering van de duurzaamheid voor lopende en toekomstige softwareprojecten.
4. Duurzaamheidsrapportage
   In de duurzaamheidsrapportage leg je alle resultaten, meetgegevens, verbeterpunten en besluiten vast omtrent het duurzaam produceren van software. Deze rapportage kan dienen als bron om verantwoording af te leggen over de duurzaamheid van de software, of om te gebruiken bij een levenscyclusanalyse van het softwareproduct.

Meten is weten

Een alternatief op de voorstellen hierboven is de introductie van meetvariabelen in het ontwikkelproces, en het meten hiervan tijdens de bouw van de software; niet alleen binnen de eigen ontwikkelomgeving, maar ook in het rekencentrum, het netwerk en de databases. Hier bestaat geschikte energieverbruik-meetsoftware[1] voor. Door een model op te zetten van het verwachte gebruik en dit te vergelijken met het daadwerkelijk gerealiseerde gebruik, kun je het model steeds verder verfijnen – en daardoor steeds beter voorspellen wat de duurzaamheidsimpact van software zal zijn.

Nog interessanter wordt het als softwareleveranciers dit doen voor de software die ze leveren. Op die manier maken ze de duurzaamheidsimpact van door hun geleverde software zichtbaar, voor de gehele levenscyclus van de software bij de gebruikersorganisatie. Deze cijfers zou de leverancier kunnen afleiden van implementaties bij andere klanten. Ze zijn dan dus gebaseerd op het daadwerkelijk gebruik van de software (Eerste orde-effect).

Het gebruik van de functionaliteit van de software heeft ook een duurzaamheidseffect. De leveranciers kunnen bij direct gebruik van de functionaliteit (Tweede orde-effect) de duurzaamheidseffecten meten en zelfs de lange termijneffecten van het gebruik van de functionaliteit (Derde orde-effect).

Er is nog een aangenaam neveneffect: door de duurzaamheid van software zichtbaar te maken en op een overtuigende manier cijfermatig te onderbouwen, stel je potentiële klanten beter in staat een weloverwogen, duurzame keuze te maken. In het volgende blog gaan we hier dieper op in. Lopen leveranciers risico’s door de duurzaamheid van hun software niet zichtbaar te maken? Hoe zouden afnemers daar duidelijkheid over kunnen vragen en zelfs gaan afdwingen dat ze er meer zicht op krijgen? Een leuk onderwerp om deze cyclus mee af te sluiten, in onze volgende blog!

Over ons

Wij zijn een groep van business analisten, architecten en projectleiders bij Capgemini. Ons doel is om bewustzijn over (milieu)duurzaamheid te creëren en de kennis van onze collega’s en onze klanten te vergroten. De groep bestaat uit Nienke van der Burg, John Christiaanse, Frans van der Lek, Timo Haakman, Hans van Rijs, en Hans van Zanten. In een serie blogs behandelen we onderwerpen op het gebied van duurzaamheid en IT.

---

[1] Bijvoorbeeld: Simplepower, Wattch, SoftWatt. Joulemeter, PowerTOP for Linux, Greentracker of PowerScope.