Duurzaam mèt software

Wie zijn wij?

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. Gezamenlijk behandelen we onderwerpen op het gebied van duurzaamheid en IT in een blogserie.

Duurzaam zijn mét software

Kijkend naar de stikstofcrisis in Nederland zie je dat de oplossing niet bij één partij gezocht kan worden, en dat deze integraal denken en (samen)werken vergt. Één partij de lasten laten dragen of de oplossing laten verzorgen is bij duurzaamheidsproblemen onvoldoende. De reden is eenvoudig: een duurzame wereld is een wereld waarin structureel aan ieders belang tegemoet wordt gekomen om zo tot handelingen te komen die naast economisch en sociaal ook milieubewust zijn.

Met dit in gedachten ziet u vanzelf een veelheid aan stakeholders ontstaan, temeer omdat milieuproblematiek een ketenprobleem is en geen éénpuntsoplossing verdraagt omdat alles met alles verbonden is. Binnen een organisatie is dit niet anders.

Als we naar de duurzaamheidseisen kijken, Economisch, Sociaal (voor het individu en de groep), Technisch, en Milieu, dan zie je al snel dat al deze factoren doorgaans, buiten Milieu, op één of andere wijze wel worden afgedekt. We lopen dit even na:

Economisch: Geld is altijd een issue. Activiteiten moeten rendabel of zo goedkoop mogelijk zijn.

Sociaal:   We letten al op Privacy, Veiligheid, en Bruikbaarheid. Voor groepen maken we in de regel al gebruik van samenwerkingsmogelijkheden.

Technisch: Ontwikkelaars besteden veel aandacht aan energie-efficiency en het goed functioneren van de software op de hardware. Daarnaast gelden gebruikelijke kwaliteitseisen als: onderhoudbaarheid; langdurig kunnen ondersteunen; betrouwbaarheid; overdraagbaarheid.

Milieu: Dit aspect is in de regel onderbelicht. Denk bijvoorbeeld aan het aspect Tijd. Wat voor impact heeft het technisch gebruiken van software op lange termijn? Wat is de impact van het gebruik van de geleverde functionaliteit?
Wat vaak tekortschiet in requirements engineering is de analyse van de levenscyclus van software zelf, alsmede een impactanalyse van de korte- en lange termijn impact bij het gebruik van de software (de bekende 1e, 2e en 3e orde effecten, zie ook het einde van dit artikel).

Wat u ziet is dat al impliciet bij de definitie van software het nodige omtrent duurzaamheid wordt meegenomen. De hamvraag blijft echter: wat is dan de werkwijze waarbij je juist expliciet rekening met duurzaamheid kan houden wetende dat je dat aspect dan in één keer afdekt?

Bij het werken onder architectuur is, binnen dit vakgebied, een begin gemaakt om duurzaamheid structureel mee te kunnen nemen bij de opzet van een softwarearchitectuur. Daarbij kan een architect gebruik maken van The Open Group Architecture Framework (afkorting: TOGAF) of, specifiek van Capgemini’s Integrated Architecture Framework (afkorting: IAF). In IAF is het aspect Duurzaamheid inmiddels ingebouwd. In versie 10 van TOGAF wordt dit nu nader uitgewerkt.

Echter binnen de wetenschap is al veel eerder nagedacht over het Requirements Engineering proces (RE-proces) in combinatie met duurzaamheid. Hierbij hebben ze het aspect duurzaamheid vervlochten in alle bestaande/huidige producten van het RE-proces. Dit is ook gedaan om te voorkomen dat er weerstand zou ontstaan tegen de extra stappen in het RE-proces.

Doordat duurzaamheid nu in het RE-proces gevlochten is, kunnen we tegemoet komen aan de toenemende wens om duurzaamheid mee te nemen in het software-definitieproces. Ook nemen we zo een mogelijke weerstand weg, omdat duurzaamheid expliciet wordt geadresseerd en de invlechting tot versnelling en betere kwaliteit zal leiden. De onderstaande figuur verbeeldt deze werkwijze. Hierna gaan we kort in op de verschillende benodigde producten.

Als we bij het vaststellen van de requirements van een systeem alle voorgestelde producten of een deel hiervan gebruiken, zullen we uiteindelijk uitkomen op een systeem dat óók duurzaam is mét software.

Als we, ‘zuchtend’, denken: “Maar er zijn al zoveel systemen gedefinieerd”, dan is er geen man overboord. We kunnen het systeem dan met deze producten herbeoordelen op duurzaamheid. Na deze analyse is bekend wat nodig is om duurzaam mét software te zijn en kan men gefundeerd besluiten wat wél en wat niet te realiseren. Én voor architecten ontstaat de mogelijkheid het bestaande landschap opnieuw te beoordelen en mogelijk aan te sturen op veranderingen richting duurzaamheid op een hoger abstractieniveau.

Vooraf is het zinvol zich af te vragen of er voldoende draagvlak is om duurzaamheidseisen te bepalen. Daarvoor zijn deze vragen belangrijk:

1. Heeft het systeem al een expliciet duurzaamheidsdoel?
2. Heeft het systeem een duurzaamheids-impact?
3. Is er een stakeholder die duurzaamheid belangrijk vindt?
4. Heeft het systeem al duurzaamheidsdoelen en -beperkingen zonder dat dit expliciet is gesteld?

Als op die vragen voldoende duidelijkheid is verkregen, kan men besluiten al dan niet op zoek te gaan naar de duurzaamheidsrequirements.

Bij het vinden van duurzaamheidsrequirements volgen we het RE-proces, benoemen we de stappen waar duurzaamheid wordt ingevlochten, en stellen we de vragen die bij een bepaald RE-product horen.  De stappen uit het RE-proces zijn dan^[2]:

1. Stel de context vast waarbinnen duurzaamheid een rol zal spelen. Beschrijf de bedrijfsprocessen en de tastbare of logische objecten waarmee de organisatie haar werkzaamheden verricht. Dit heet ook wel het domeinmodel* van de organisatie.
2. Bepaal wie de stakeholders* zijn voor duurzaamheid.
3. Verrijk het bedrijfsdoelstellingenschema met doelstellingen en meetbare duurzaamheidsdoelen.
4. Maak zichtbaar welke beperkingen en regels van toepassing zijn op duurzaamheid.
5. Stel een systeemvisie op waaraan duurzaamheid is toegevoegd, en maak een usecase-model dat zich ook op duurzaamheid richt.
6. Definieer specifieke duurzaamheidsrequirements die voortvloeien uit algemeen geldende risico’s bij invoering van een systeem zoals invoerings-, kwaliteits- en procescrisico’s en relevante systeembeperkingen.

Met deze minimale artefacts kunt u de duurzaamheidsspecificaties inventariseren en beschrijven.

Als duurzaamheid zo wordt uitgewerkt, zijn daarop nog wat aanvullingen te maken die meespelen tijdens de uitwerking van de duurzaamheidsrequirements. Een aantal voorbeelden om het te verlevendigen:

1. In het verleden werden milieu-effecten bij een keuze niet altijd meegewogen. Simpelweg omdat er geen waarde aan kon worden toegekend of nie tvan belang werden geacht voor de besluitvorming. Een voorbeeld is bijvoorbeeld het vrijkomen van stoffen die ogenschijnlijk geen impact hebben op ons milieu maar nu op de lange duur dat toch blijken te hebben (stikstof, nutritie sloten, gebruik zeldzame materialen zonder recycling etc.). Dit soort effecten konden buiten beschouwing worden gelaten terwijl dat nu zelfs impact op het imago van een organisatie kan hebben.
2. Als een organisatie als doel stelt de leefomgeving te willen beschermen dan is dit niet altijd in cijfers meetbaar te maken en zijn kwalitatieve ciriteria nodig. Voor een kosten/baten analyse in een bedrijf is dit lastig bruikbaar en dan kan verwezen moeten worden naar meer algemene duurzaamheidsdoelen zoals geformuleerd in “Vision 2050” van de WBCSD^[3]. Op deze manier wordt toch op een of ander wijze invulling gegeven aan een duurzaamheidsdoel.
3. Voor een software product gelden requirements omtrent beveiliging en veiligheid steeds zwaarder. De wetgeving stelt ook meer en meer eisen aan software. Zo verlangt de overheid dat slechtzienden gebruik moeten kunnen maken van het Internet, dat iemand veilig het internet kan gebruiken en wordt minder geaccepteerd dat schermgedrag en ingevoerde gegevens worden geregistreerd. Net zoals van fysieke producten verlangd wordt dat ze veilig zijn. Dit zijn feitelijk allemaal eisen die terug zijn te leiden naar allerlei duurzaamheidaspecten waar invulling aan moet worden gegeven. Dus sluiten dit soort requirements impliciet aan op duurzaamheidsdoelstellingen van een organisatie. Daar kan gebruik van worden gemaakt bij het behalen van duurzaamheidsdoelen met software.
4. Als laatste is het van belang mee te wegen bij het opstellen van de requirements wat het duurzaamheidseffect is bij het daadwerkelijk gebruik van het hulpmiddel om de software te gebruiken (bijvoorbeeld je mobiel). Dan het gevolg van het gebruik van de te maken software. Welke effecten heeft dit als wordt ingevoerd, gezocht of gegevens overgedragen. Dit kost op meerdere plaatsen energie, capaciteit etc. En wat bij dit gebruik ook nog een rol spelt is het lange termijn effect. Wat gaat er gebeuren als deze software voor lange termijn wordt gebruikt met grote groepen gebruikers? Wat voor wenselijke of mogelijk onwenselijke gevolgen heeft dit? Ook dit zijn aspecten die meetellen bij het duurzaam zijn mèt software.

In dit artikel heeft u kennis kunnen maken met een werkwijze om mét software duurzaam te kunnen zijn. De werkwijze is vervlochten in het RE-proces, zodat gaandeweg duurzaamheid kan worden uitgewerkt. Dit maakt duurzaamheid toepassen makkelijker te accepteren. De kans is reëel dat een systeemeigenaar, gezien de tijdsgeest, daar positief op zal reageren.

In een volgende blog gaan we weer een stap verder. We weten nu hoe we mét software duurzaam willen zijn. Hierna komt de volgende horde: hoe maken we de software zèlf als product duurzaam? Doen we daar al genoeg aan en kunnen we dan ook vol trots zeggen: Wij leveren een duurzaam product?

^[1] Zoek op Penzenstadler: Artefact-based Requirements Engineering: The AMDiRE Approach

^[2] Voor wie bekend is met de IAF-methode van Capgemini is het raadzaam daar de beschikbaarheid van de producten bij op te zoeken. Voor het gemak is in de opsomming een * toegevoegd voor het betreffende product dat onderdeel is van IAF.

^[3] World Business Council for Sustainable Development.