Autor: Yelle Lieder
Es gibt immer mehr Software auf der Welt. Die Anzahl der Webseiten hat sich in den letzten zehn Jahren mindestens verdoppelt und analoge Trends sind – mit Ausnahme von Main Frame Anwendungen vielleicht – für nahezu alle Arten digitaler Lösungen zu beobachten. Gleichzeitig haben immer mehr Menschen Zugang zu Software und die Nutzungsintensität
nimmt ständig zu. Als wäre das nicht genug, steigt auch die Komplexität der digitalen Lösungen stetig an. So ist eine Website, die 2012 rund 800 kB groß war, heute beinahe dreimal so groß.
eine Website, die 2012 rund 800 kB groß war, ist heutE beinahe dreimal so groß.
Dieser Anstieg ist nicht nur der gestiegenen Leistung und rechnerischen Komplexität zuzuschreiben, sondern auch dem Umstand, dass wir zunehmend weniger sparsam im Umgang mit Medien werden. Ein Hintergrundvideo hier, ein GIF dort und schon wird die einfache Webseite zur buchstäblichen CO 2 -Schleuder. Aber es geht nicht nur um Webseiten.
Insbesondere Trend-Technologien wie Maschinelles Lernen, Blockchain-Anwendungen und Extended-Reality-Umgebungen kommen als völlig neue Anwendungsfälle auf den Plan. Diese Technologien sind oft schon seit Jahrzehnten gut erforscht, werden jedoch jetzt erst massentauglich, weil günstige Rechenleistung in den letzten Jahren scheinbar im Überfluss vorhanden war. Sie fügen der Gesamtbilanz der digitalen Gesellschaft also weiteren Ressourcenbedarf hinzu und sind noch ressourcenhungriger als klassische Anwendungssoftware.
Umweltauswirkungen unserer digitalen Gesellschaft
Nicht alle Umweltauswirkungen unserer digitalen Gesellschaft liegen direkt auf der Hand. Software wird auf Hardware betrieben und diese benötigt Strom. Diesen Zusammen-
hang begreifen schnell alle, die sich am Ende des Tages über den leeren Akku des Smartphones wundern. Da es weltweit nur wenige Regionen gibt, die ihren Strombedarf zum Großteil aus CO2 -armen Energieträgern decken, werden Treibhausgase durch die Nutzung digitaler Technologien emittiert. Es geht aber nicht nur um Treibhausgase. Auch wenn in Deutschland die Wasserkühlung in Rechenzentren wenig verbreitet ist, stellt diese in anderen Regionen jedoch eine massive Herausforderung dar.
Durch die Verwendung nicht geschlossener Wasserkreisläufe für die Kühlung leiden weltweit Gemeinden unter akutem Wassermangel. Bei aller Virtualisierung und der friktionslosen Buchung neuer Ressourcen in der Cloud verlieren selbst Techies leider häufig den Bezug dazu, dass hinter Software vor allem viel physische Infrastruktur steckt. Diese muss hergestellt, transportiert, gewartet und am Lebensende der Verwertungskette wieder zugeführt werden. Seltene Erden müssen abgebaut, Baugrundstücke erschlossen und Kabeltrassen gepflügt werden, um dem wachsenden Ressourcenbedarf unserer digitalen Gesellschaft gerecht zu werden.
Aktuell verursacht der Informations- und Telekommunikationssektor (ITK), einschließlich der Herstellung physischer Ressourcen, Schätzungen zufolge rund 2 bis 4 Prozent der weltweiten Treibhausgasemissionen. Die Auswirkungen auf den Zugang zu Frisch-
wasser und auf die Ökotoxologie – etwa durch den Abbau seltener Erden – lassen sich noch viel schwerer quantifizieren. Wie schaffen wir es also, die Umweltauswirkungen dessen
so gering wie möglich zu halten? Der erste Schritt ist Nachhaltigkeit als Anforderung an die Systeme, die wir bauen, zu begreifen.
Aktuell verursacht der Informations- und Telekommunikationssektor (ITK), […] rund 2 bis 4 Prozent der weltweiten Treibhausgasemissionen.
Nachhaltigkeit als Anforderung
Es stellt sich somit die Frage, um was für eine Anforderung es sich bei Nachhaltigkeit überhaupt handelt. Versuchen wir einmal eine Einordnung in die klassische Trinität der
Anforderungen im Requirements Engineering: Funktionale Anforderungen, Qualitäts-anforderungen und Constraints.
Wenn man als Arbeitshypothese davon ausgeht, dass jedes System Aspekte der Nachhaltigkeit berücksichtigen sollte, fallen die funktionalen Anforderungen schon einmal raus. Immerhin handelt es sich bei Nachhaltigkeit nicht um eine Funktion als solche. Vor dem Hintergrund steigender regulatorischer Anforderungen sowie einem steigenden gesellschaftlichen Bewusstsein für Nachhaltigkeit liegt der Gedanke nahe, Nachhaltigkeit als Constraint in der klassischen Requirements-Engineering-Taxonomie einzuordnen.
In der Literatur herrscht jedoch weitestgehend Konsens darüber, dass Nachhaltigkeit zunächst als Qualitätskriterium von Software zu betrachten ist. So lassen sich
Aspekte der Nachhaltigkeit, etwa der Stromverbrauch oder der Wasserfußabdruck einzelner Systeme, mit den richtigen Tools durchaus präzise und reproduzierbar quantifizieren. Auch
der Vergleich zu anderen Qualitätskriterien zeigt, dass Nachhaltigkeit viele ähnliche Charakteristiken aufweist, wie etwa Sicherheit, wenn man sich am Software-Quaitätsbegriff
nach ISO 25010 orientiert.
Sicherheit gilt heute in jeder gesunden IT-Organisation als Faktor, bei dem kein Zweifel bestehen sollte, dass jede digitale Lösung auch sicher sein muss. Genau so muss es in Zukunft selbstverständlich sein, dass digitale Lösungen einen angemessenen
Ressourcenverbrauch haben und abwärtskompatibel sind, sodass sie auch auf älterer Hardware betrieben werden können.
Die detaillierten Anforderungen müssen natürlich von offizieller Seite noch genauer spezi-
fiziert werden und hängen wie immer vom konkreten Use Case ab. Deutlich wird jedoch, dass sich auf einem ähnlichen Abstraktionsniveau wie bei anderen ISO-Qualitätskriterien
allgemeingültige Charakteristiken für nachhaltige Software definieren lassen.
Maßnahmen im Requirements Engineering für mehr Nachhaltigkeit
Sollte also ökologische Nachhaltigkeit von Software – wie von diversen Akteuren (u. a. dem W3C) aktuell verfolgt – zukünftig eine Standardisierung erfahren, stellt sich dennoch die
Frage, wie man von den abstrakten Anforderungen in die Umsetzung kommt. Die konkrete Ausgestaltung wird sich nach der entsprechenden Norm richten müssen, jedoch lassen sich auch ohne offizielle Vorgaben bereits sinnvolle Maßnahmen im Requirements Engineering für mehr Nachhaltigkeit benennen.
Frequenz, Häufigkeit und Aktualität
So sollte bei der Definition von Anforderungen stets darauf geachtet werden, wie oft bestimmte Aktivitäten in den Systemen tatsächlich sinnvoll oder notwendig sind.
- Wie oft sind Back-ups und Synchronisationen tatsächlich nötig?
- Müssen Videos wirklich mit 70 Frames per second (FPS) ausgeliefert wer-
den, auch wenn die meisten Menschen nur 30 FPS mit ihren Augen er-
fassen können? - Muss die App auf meinem Smartphone wirklich drei Mal am Tag mit Updates versorgt werden, auch wenn ich in der Nutzung keine signifikanten Unterschiede erkennen kann?
- Läuft mein System auch auf einem
Smartphone aus 2015?
Indem wir unsere Anforderungen an die Aktualität und Häufigkeit kritisch hinterfragen und proaktiv in Systemen umsetzen, lässt sich vor allem der Overhead für die Übertragung von Daten sowie für das Anstoßen von Prozessen reduzieren. Mit Blick auf die Abwärtskompatibilität kann zudem ein Beitrag dazu geleistet werden, dass Nutzende nicht alle zwei Jahre auf die neueste Hardware umsteigen müssen.
Präzision, Auflösung und Genauigkeit
Ähnliche Fragen – wie in der Frequenz von Daten – lassen sich auch bezogen auf die Auflösung von Daten stellen.
- Müssen tatsächlich alle Sensoren mit der maximalen Anzahl an Dezimalstel-
len (Präzision) messen? - Müssen Hochrechnungen immer auf die Nachkommastelle genau sein, oder genügt eine approximative Berechnung?
- Müssen alle Daten in Echtzeit in der höchsten Auflösung vorliegen, nur für
den Fall, dass man sie mal brauchen könnte?
Derartige Fragen müssen zukünftig insbesondere bei der initialen Planung neuer Funktionen beantwortet werden. Insbesondere dort, wo viele Daten erfasst, generiert und übertragen werden, bieten diese Überlegungen zudem nicht nur einen Vorteil mit Blick auf die Nachhaltigkeit, sondern können aktiv einen Beitrag zur Kostensenkung für Energie und
Speicher leisten.
Tolenranz und Latenz
Viele der vorgestellten Aspekte eines nachhaltigen Requirements Engineerings, lassen sich nicht nur in der Anforderungsdefinition für die Umsetzung, sondern ebenso für die Definition von Service Level Agreements (SLAs) im Betrieb nutzen.
- Muss meine Webseite wirklich in Sekundenbruchteilen laden, oder genügt es vielleicht, wenn Teile der Seite erst später nachgeladen werden?
- Muss jedes Datenpaket, das bei der Übertragung verloren geht, noch einmal übertragen werden, oder genügt für bestimmt Anwendungsfälle nicht die Übertragung per User Datagram Protocol (UDP)?
Indem zukünftig nicht nur Minimalanforderungen, sondern auch Maximalanforderungen an Zuverlässigkeit und Performanz definiert und umgesetzt werden, lässt sich ein Schuss
übers Ziel hinaus vermeiden. Denn solange weiterhin viele Systeme um ein Vielfaches mit Hardwareressourcen und Cloud-Instanzen überversorgt werden, wird es schwer, einen an-gemessenen Ressourcenverbrauch unserer digitalen Infrastruktur zu erzielen.
Mit Fokus auf die Grundlagen zur qualitativ hochwertiger und nachhaltiger Software
Die genannten Anforderungen lassen sich ausnahmslos auf bestehende ISO-Qualitätskriterien mappen. Denn qualitativ hochwertige Software ist nachhaltig. Wir müssen das Rad nicht neu erfinden, sondern zunächst das in den Fokus rücken, was
wir im Software Engineering ohnehin seit Jahrzehnten anstreben: Nicht verschwenderisch sein, performante Software bauen und dafür sorgen, dass unsere Systeme keine ungewollten Nebeneffekte haben. Wer sich darauf besinnt und sicherstellt, dass diese Basisanforderungen an gute Software erfüllt sind, kann sich durchaus auch an fortgeschritteneren Anforderung versuchen.
- Ist der Server in der Cloud vielleicht effizienter als das Smartphone, sodass es sich lohnt, dort Berechnungen hin auszulagern?
- Wird dieser Effizienzgewinn durch die Übertragung im 4G-Netz schon wieder zunichte gemacht?
- Führt mein System ressourcenintensive Prozesse dann aus, wenn viel erneuerbare Energie im Netz vorhanden ist?
Neben all diesen technischen Fragestellungen müssen zudem organisatorische und fachliche Fragestellungen berücksichtigt werden.
- Macht das System seinen Ressourcenverbrauch transparent?
- Wirkt die Funktion des Systems positiver auf Nachhaltigkeitsziele, als die
darunter liegende Technologie negative Umweltauswirkungen verursacht? - Werden Videokonferenzen nur dort durch Reisen ersetzt, wo es wirklich nötig ist?
Zudem ist es essentiell, die relevanten Stakeholder zu identifizieren und einzubeziehen. Wenn es um Nachhaltigkeit geht, kommen dabei ganz neue Rollen auf die Landkarte, mit denen es im Software Engineering bisher oft weniger Berührungspunkte gab. Was sind die Herausforderungen von Nachhaltigkeitsmanager:innen, woran wird ihr Erfolg gemessen und worauf legen sie in ihrer Organisation beim Thema Nachhaltigkeit den Fokus?
Dies sind nur einige Fragen, die gestellt werden müssen, wenn neue Stakeholder in die Anforderungserhebung eingebunden werden.
Fazit: Mit neuen Anforderungen an Software einen Beitrag zur globalen Nachhaltigkeit leisten
Nicht nur Auftraggebende, Kundinnen und Kunden präferieren zunehmend nachhaltige Produkte und Dienstleistungen. Auch Mitarbeitende und Bewerbende entscheiden sich lieber für Arbeitgeber, die sich nachhaltig positionieren. Und selbst die Kapital-
märkte haben Nachhaltigkeit längst als Kriterium für die Allokation von Kapital ausgemacht. Unternehmen, die nicht auf Kundinnen und Kunden, Personal und Kapital verzichten
können, müssen handeln. Die Nachhaltigkeitstransformation muss in
allen Bereichen passieren. Natürlich verursacht der ITK-Sektor “nur” so viele CO 2 -Emissionen, wie der weltweite Flugverkehr. Zudem steht völlig außer Frage, dass auch andere Branchen ihren Beitrag zu leisten haben. Dennoch muss am Ende jede Branche zur Erreichung der globalen Nachhaltigkeitsziele mitwirken, auch wenn das ein Umdenken bezüglich der Anforderungen an Software bedeutet.
