Planet Erde als Stakeholder

Nachhaltigkeit in der Softwareentwicklung umfasst zwei Dimensionen: ökologische und soziale. Ökologisch geht es um den Energieverbrauch von Systemen, die Wahl von Rechenzentren mit erneuerbarer Energie und ressourcenschonende Software, die Hardware länger nutzbar hält. Sozial bedeutet es, Barrierefreiheit und Inklusion aktiv einzuplanen, statt nachträglich anzupassen.

Das Wichtigste in Kürze

• Elektroschrott entsteht fast immer durch Software: Wer alte Hardware mit neueren Softwareversionen unterstützt, verlängert die Lebensdauer von Geräten und reduziert damit direkt den Ressourcenverbrauch.
• Nachhaltigkeit als Stakeholder-Frage zu formulieren, “Was wäre anders, wenn die Erde ein Stakeholder wäre?”, erzeugt im Team sofort konkrete Überlegungen ohne vorab eine Schulung zu brauchen.
• Barrierefreie Systeme werden für alle Nutzenden einfacher, weil viele Einschränkungen temporär sind: Lärm, Krankheit oder eine veraltete Hardware treffen deutlich mehr Menschen als nur dauerhaft betroffene Gruppen.
• Die Green Software Foundation und das kostenfrei zugängliche Digital-Sustainability-Programm der Vereinten Nationen bieten Entwicklern und Testern strukturierte Einstiege in nachhaltige Softwareentwicklung.

Nachhaltigkeit in der IT hat mehr als eine Dimension

Nachhaltigkeit in der Softwareentwicklung umfasst nicht nur Ökologie, sondern auch soziale Aspekte. Wer nur an den Energieverbrauch denkt, übersieht die halbe Geschichte.

Die soziale Seite betrifft Fragen wie Barrierefreiheit, Inklusion und den Umgang mit Daten. Bei Sicherheit, Safety und Privacy ist die Branche inzwischen recht weit. Diese Themen wurden lange diskutiert, ohne dass viel passierte. Heute sind sie als nicht-funktionale Anforderungen Standard, weil das Risiko sonst zu hoch wäre.

Jutta Eckstein zieht daraus Hoffnung für andere Nachhaltigkeitsthemen. Was bei Sicherheit und Datenschutz funktioniert hat, lässt sich auf weitere Felder übertragen. Der gleiche Weg steht der ökologischen und der restlichen sozialen Nachhaltigkeit noch bevor.

Warum schließt Software ungewollt Menschen aus?

Software schließt Menschen aus, wenn sie Annahmen über Nutzer hart codiert, die nicht für alle gelten. Ein binäres Eingabefeld kann zur Barriere werden.

Ein Beispiel sind Body-Scanner an Flughäfen. Die Software erwartet eine Auswahl zwischen Mann und Frau, und je nach Auswahl läuft der Scan unterschiedlich ab. Für Transgender-Personen funktioniert das nicht, mit teils traumatischen Folgen. Letztlich ist es die Software, die diese Null-oder-Eins-Logik verlangt. Man könnte sie auch anders bauen.

Die Teams, die solche Systeme entwickeln, handeln meist nicht in böser Absicht. Sie haben einen Auftrag und setzen ihn um. Genau deshalb liegt es an den Entwicklerinnen und Entwicklern, solche Vorgaben zu hinterfragen.

Das Problem steckt auch in den eigenen Werkzeugen. Beim Einreichungstool der OOP fiel auf, dass die Anrede eine starre Unterscheidung zwischen Herr und Frau verlangte. Die Frage dahinter: Braucht das System diese Angabe überhaupt? In diesem Fall nicht. Was nicht gebraucht wird, kann auch keine Barriere sein.

Barrierefreiheit macht Systeme für alle besser

Wer Software barrierefrei baut, verbessert sie für alle Nutzer, nicht nur für eine kleine Gruppe. Das ist das stärkste Argument gegen die Annahme, der Aufwand lohne sich nicht.

Oft wird Barrierefreiheit als Spezialfall abgetan: Wie viele blinde oder taube Menschen nutzen das System schon? Diese Rechnung greift zu kurz. Eine Einschränkung muss nicht dauerhaft sein. Eine Ohrenentzündung kann das Bedienen per Audio vorübergehend erschweren. Eine laute Umgebung erzeugt dasselbe Problem situativ.

Sobald Teams diese Bandbreite mitdenken, werden Systeme einfacher zu bedienen, quer durch alle Nutzungssituationen. Hilfreich ist hier ein Persona-Spektrum, das permanente, temporäre und situative Einschränkungen nebeneinanderstellt.

Ein Teil des Problems liegt in der Zusammensetzung der Teams. Software entsteht stark männerdominiert. Um die gesellschaftliche Vielfalt abzubilden, muss man dieser Schieflage bewusst entgegenarbeiten.

Braucht es Regulierung oder reicht das Eigeninteresse?

Bei sozialen Themen war der regulatorische Druck bislang der stärkste Hebel. Bei ökologischer Nachhaltigkeit könnte das Eigeninteresse genügen.

Datenschutz zeigt das Muster. Vor der DSGVO fluchten viele, einzelne Anbieter wollten Europa lieber meiden oder separate Webseiten bauen. Heute ist die Umsetzung gang und gäbe. Bei Barrierefreiheit zeichnet sich derselbe Verlauf ab, getrieben durch die anstehende Pflicht. Manche erwarten, dass der EU AI Act denselben Weg nimmt.

Bei ökologischer Nachhaltigkeit liegt der Fall anders. Wer sich damit beschäftigt, spart auf fast allen Ebenen Kosten und macht die Software performanter. Das ist Win-Win.

Wenn man mal die Prinzipien und Praktiken verinnerlicht hat und das einfach macht, weil es auf vielen Ebenen positiv ist, dann braucht es da vielleicht gar nicht den gesetzlichen Hebel.

Jutta Eckstein

Selbst Greenwashing lässt sich ambivalent lesen. Wenn Firmen so tun müssen, als ob, haben sie zumindest erkannt, dass etwas passieren muss. Das kann ein erster Schritt sein, im Sinne von fake it till you make it. Die Lösung ist noch nicht gut, aber im Kopf hat sich etwas bewegt.

Wie bringst du Nachhaltigkeit ins Team?

Der einfachste Einstieg ist eine Frage: Was wäre, wenn einer unserer Stakeholder der Planet wäre? Diese Frage setzt das Denken sofort in Gang.

Für manche Storys ändert die Frage nichts, für andere schon. Plötzlich überlegt das Team, ob sich eine Funktion anders implementieren lässt. Sobald das Gespräch erst einmal angestoßen ist, wird es oft zum Selbstläufer. Es geht zuerst um Awareness, vieles ist danach technisch lösbar.

Den nächsten Schritt liefert die Definition of Done. Ein Team kann ein Monitoring für den Energieverbrauch aufnehmen, bevor das nächste Release rausgeht. So weiß man zumindest, ob der Verbrauch steigt, gleich bleibt oder sinkt.

Am wirksamsten ist Nachhaltigkeit als Kultur von Anfang an. Wer die Frage von Beginn an stellt, verankert sie in jeder Entscheidung, von der Cloud-Auswahl bis zum Entwicklungsstil. Die Frage lässt sich auch in einer Retrospektive stellen, mit dem Planeten als Stakeholder.

Der größte Hebel liegt in Infrastruktur und Architektur

Aktuell stecken die größten Einsparungen in grundsätzlichen Infrastruktur- und Architekturentscheidungen, nicht in einzelnen Codezeilen. Die Entwicklung trägt bei, aber die großen Baustellen liegen davor.

Ein konkreter Hebel ist die Wahl der Region für ein Datenzentrum. Google bietet einen Region Picker, der anzeigt, wie hoch der Anteil erneuerbarer Energie an einem Standort ist, teils bis zu hundert Prozent. Die Auswahl folgt dann nicht nur Verfügbarkeit und Kosten, sondern auch der Energiequelle.

Dasselbe Prinzip gilt für asynchrone Jobs. Ein Job, der nicht sofort laufen muss, kann starten, wenn am Ausführungsort gerade erneuerbare Energie verfügbar ist, statt zu einem beliebigen Zeitpunkt.

In der Entwicklung helfen die alten Tugenden. Früher zwangen knapper Speicher und schmale Bandbreite zu sparsamen Systemen. Genau diese Sparsamkeit ist wieder gefragt, statt davon auszugehen, dass Hardware nichts kostet.

Elektroschrott entsteht fast immer durch Software

Der meiste Elektroschrott geht auf Software zurück, nicht auf defekte Hardware. Das gibt der Branche einen großen Hebel in die Hand.

Wann kaufst du dir ein neues Smartphone? Meist dann, wenn das Betriebssystem nicht mehr unterstützt wird, Sicherheitsprobleme auftauchen oder die Apps nicht mehr laufen. Die Hardware funktioniert oft noch, die Software macht sie unbrauchbar.

Software kann das Gegenteil leisten und ältere Hardware länger unterstützen. Ein Mittel dafür sind Sustainability Toggles, eine Variante der bekannten Feature Toggles. Erkennt das System einen alten Client, der eine Funktion nicht tragen kann, bekommt dieser eine abgespeckte Version oder die Funktion gar nicht. Das System bleibt trotzdem nutzbar.

Der Unterschied liegt in der Vorgabe. Statt zu verlangen, dass alle Nutzer auf bestimmte Hardware umsteigen, lässt die Software auch alte Geräte weiterlaufen. Das verlängert die Nutzbarkeit und reduziert den Schrott.

Brauchen KI und Blockchain so viel Energie?

KI und Blockchain verbrauchen viel Energie, sind aber unverzichtbar, um überhaupt mehr Nachhaltigkeit zu erreichen. Klimamodelle ohne KI sind kaum denkbar.

Die Frage ist weniger, ob man diese Technologien nutzt, sondern wie man sie entwickelt. Bei Large Language Models lautet die Leitlinie Reduce, Reuse. Modelle werden kleiner gebaut und für andere verfügbar gemacht, damit nicht jedes Team von vorn anfängt und den Energiebedarf vervielfacht. Dasselbe gilt für Testdaten, die ebenfalls ressourcenintensiv sein können.

Beim Mining von Kryptowährungen liegt das Problem oft am Standort. Ein großer Teil findet in Regionen statt, in denen die Energie hauptsächlich aus Kohle stammt. Das Gleiche trifft jedes Datenzentrum, das vor allem mit fossiler Energie betrieben wird. Diese Entscheidung lässt sich beeinflussen.

Wo du anfangen kannst, mehr zu lernen

Zum Einstieg gibt es kostenfreie Kurse und eine einfache Frage, die kein Vorwissen braucht. Beides funktioniert ab morgen.

Die Green Software Foundation, ein Non-Profit, das von einigen Firmen gestartet wurde und inzwischen breiter aufgestellt ist, sammelt Prinzipien und Patterns für Entwicklerinnen und Entwickler. Sie bietet einen kostenfreien Kurs zum Sustainability Practitioner an, der das Thema einordnen hilft.

Auch die Vereinten Nationen bieten ein Trainingsprogramm namens Digital Sustainability. Der Kurs ist im Aufbau, geplant sind vier Module, von denen aktuell zwei verfügbar sind. Zu finden ist er über den UN Campus, ebenfalls kostenfrei.

Den ersten Schritt brauchst du dafür gar nicht. Es reicht, in der nächsten Diskussion zu fragen, was anders wäre, wenn die Erde ein Stakeholder wäre. Diese Frage allein stößt oft schon viel an.