Der Blaue Engel für Software - ein Erfahrungsbericht aus dem eigenen Unternehmen
Der Blaue Engel ist das Ökolabel des deutschen Bundesumweltministeriums, wobei das Umweltbundesamt, der RAL und die Jury Umweltzeichen für die praktische Vergabe zuständig sind. In Deutschland ist der Blaue Engel sehr bekannt, vor allem für Papiererzeugnisse oder Putzmittel. Es gibt ihn jedoch für eine sehr breite Palette an Produkten, von Lacken über Car Sharing bis Elektrogeräte — und seit 2020 auch für Software!
- Ein kleiner Blick auf die Entwicklung des Labels
- Was soll der Blaue Engel für Software leisten?
- Welche Kriterien gelten und was dahinter steckt
- Warum wir uns für die Zertifizierung entschieden haben
- Zertifizierungsprozess, Teil 1: Aufbau der Nutzungsszenarien
- Zertifizierungsprozess, Teil 2: Messungen durchführen
- Zertifizierungsprozess, Teil 3: Dokumente anfertigen
- Was kostet es und war’s das wert?
Ein kleiner Blick auf die Entwicklung des Labels
In ihrer ersten Version von 2020 sahen die Vergabekriterien zunächst ausschließlich die Zertifizierung von Desktop-Software-Anwendungen vor, weshalb es lange Zeit nur eine einzige zertifizierte Software gab: den PDF-Reader Okular von KDE.
Mitte 2024 wurden die Vergabekriterien schließlich überarbeitet. Seitdem erstreckt sich der Geltungsbereich auch auf Anwendungen, die auf einem Server, auf einem PC Device, auf einem mobilen Gerät — oder auf einer Kombination dieser drei Hardware-Typen — installiert werden können und bei denen mindestens 90% des Energiebedarfs gemessen werden kann.
Zusammen mit den neuen Kriterien wurden auch Auditor:innen eingeführt. Ihre Aufgabe besteht darin, den Blauen Engel und das zertifizierende Unternehmen vor Reputationsverlust zu schützen, indem sie prüfen, ob beim Vergabeprozess alles korrekt verlaufen ist und die geltenden Kriterien eingehalten wurden.
Die Überarbeitung der Vergabekriterien sorgte, nach der langen Durststrecke zuvor, für einen kleinen Ansturm — innerhalb eines Jahres kamen fünf weitere zertifizierte Anwendungen hinzu:
- das Software-Messwerkzeug Green Metrics Tool von Green Coding Solutions
- die Nextcloud
- die E-Commerce-Such-Software HOLMES von neuland — Büro für Informatik
- die Task-Management-Software KADAI von envite und
- die OpenCloud.
HOLMES ist dabei die bisher einzige nicht-Open-Source-Software, die die Auszeichnung bekommen hat. Die Software muss also nicht Open Source sein, um für eine Zertifizierung in Frage zu kommen, aber Open-Source-Projekte haben tatsächlich ein paar Vorteile, auf die ich später noch eingehen werde.
Beginnen möchte ich aber erst einmal mit der Vorstellung des Blauen Engels.
Was soll der Blaue Engel für Software leisten?
Es gibt vier grundlegende Ziele:
1. TRANSPARENZ
Der Blaue Engel ist weltweit das erste und bisher einzige Öko-Label für Software. Ein Grund dafür ist, dass es sehr schwierig ist, vergleichende Kriterien für die Effizienz eines Typs von Software-Anwendungen zu definieren - aus der Branche kommt dann sehr schnell der Einwand, dass man Anwendung X und Anwendung Y aufgrund ihrer unterschiedlichen Features gar nicht vergleichen könne.
Um dieses Problem zu umgehen, verfolgt der Blaue Engel nicht direkt das Ziel von Vergleichbarkeit und Standards für den Energieverbrauch von Anwendungen. Stattdessen ist der Gedanke, dass erst einmal Transparenz geschaffen werden soll, die dann perspektivisch zu Vergleichbarkeit und mehr Ressourceneffizienz führt.
Beispiele für den Erfolg dieses Vorgehens finden sich bereits in anderen Branchen, z.B. bei Kühlschränken oder Autos: Erst kam die Offenlegung des Verbrauchs, die dann ein Anreiz für die Hersteller war, ihre Produkte effizienter zu machen.
Heute haben wir bei Elektro-Ware auf jedem Gerät eine Skala, die den Vergleich mit anderen Geräten ermöglicht und Verbraucher:innen in die Lage versetzt, qualifizierte Kaufentscheidungen zu treffen. Dahin soll es perspektivisch auch bei Software gehen!
2. EFFIZIENZ
Natürlich ist Ressourceneffizienz für den Blauen Engel trotzdem nicht unwichtig - nur "Daumenschrauben" gibt es dafür noch keine. Stattdessen besagen die Vergabekriterien z.B., dass die Entwicklung der Software nicht mehr Energie kosten darf als ein Jahr Produktiv-Einsatz bei einer durchschnittlichen Anzahl von Nutzenden.
Ich gehe davon aus, dass da im Moment keiner ganz genau nachmisst, jedoch könnten kritische Nachfragen von der Auditorin oder dem Auditor kommen, die dann entkräftet werden und im Zweifelsfall belegt werden müssten.
3. LÄNGERE HARDWARE-NUTZUNG
Wer sich bereits ein wenig mit Green IT bzw. Green Software befasst hat, hat sicher schon von "embodied emissions“ gehört — den Emissionen, die bei Herstellung und Transport von physischen Produkten entstehen. Bei IT-Hardware gilt: Der größte Teil der negativen Umweltauswirkungen wird bereits verursacht, bevor die Hardware zum ersten Mal produktiv eingesetzt wird. Deshalb ist es sehr wichtig, sie so lange wie möglich im Einsatz zu halten. Vor allem sollten nicht steigende Anforderungen von Software dazu führen, dass noch funktionstüchtige Hardware ersetzt werden muss.
Beim Blauen Engel gibt es mehrere Kriterien, die auf dieses Ziel einzahlen und die ich später noch ausführen werde.
4. NUTZUNGSAUTONOMIE
Dieses Ziel ist vielleicht das überraschendste, hat es doch erst einmal keinen direkten Bezug zu Ressourceneffizienz und Ökologie.
Nachhaltigkeit hat jedoch immer mehrere Aspekte: ökologische, ökonomische und soziale. Bei diesem Ziel geht es deshalb darum, dass die Software keine Abhängigkeiten zum Hersteller erzeugt und auch nach dem Ende des Supports weiter genutzt werden kann — aber auch, dass die Software werbe- und Tracking-frei ist. Das vermeidet unnötigen Datentransfer und ist somit auch ökologisch nachhaltig.
Welche Kriterien gelten und was dahinter steckt
Die Ziele finden sich in den drei Bereichen der Vergabekriterien wieder:
- Ressourcen- und Energieeffizienz
- potenzielle Hardware-Nutzungsdauer und
- Nutzungsautonomie
1. RESSOURCEN- UND ENERGIEEFFIZIENZ
Dieses Kriterium ist wahrscheinlich das aufwendigste an der ganzen Zertifizierung — die Software muss nämlich vermessen werden, um Energieverbrauch, Hardware-Inanspruchnahme und Datenverkehr während der Nutzung zu ermitteln.
Dafür gibt es zwei Möglichkeiten:
Entweder man misst den Verbrauch im echten Live-Betrieb über einen Zeitraum von mindestens einer Woche und bis zu einem Monat mit einer repräsentativen Anzahl an Nutzenden und dokumentiert den tatsächlichen Verbrauch während dieses Zeitraums.
Oder man führt einen Szenario-Test durch — das ist der Weg, den alle bisherigen Zertifizierungen gegangen sind und der sicherlich auch am besten geeignet ist, wenn man z.B. nach einem Jahr eine Re-Zertifizierung anstrebt und Vergleichbarkeit mit vergangenen Messungen haben will. Für den Szenario-Test definiert man alle repräsentativen Standard-Nutzungsszenarien der Software und vermisst diese in einer Umgebung, in der nichts Anderes läuft — mindestens zehn und bis zu dreißig Mal.
Das Messen kann man z.B. auf eigener Hardware machen, mit einem Messgerät zwischen Device und Steckdose. Spätestens bei mobilen Endgeräten wird das aber knifflig. Empfehlen würde ich daher einen anderen Weg: mit einem Messpartner, z.B. Green Coding Solutions und einem geeigneten Mess-Tool.
Das Green Metrics Tool der kleinen Berliner Firma ist genau auf die Anforderungen des Blauen Engels ausgelegt. Das beginnt damit, dass das Mess-Tool die Spezifikation eines Nutzungsszenarios vorsieht, wie auch der Blaue Engel es fordert. Dafür muss die Anwendung dockerisiert werden — alles, was die Software braucht, um lauffähig zu sein, muss automatisiert aufgebaut und später wieder abgeräumt werden. Dann stellt z.B. ein Playwright oder ein Last-Tool typische Interaktionen der Nutzer:innen automatisiert nach. Wichtig ist dabei, dass die Szenarien wirklich repräsentativ für die Nutzung der Software sind.
Das Green Metrics Tool erfasst alle Lebenszyklus-Phasen der Software: die Grundauslastung des angeschalteten Servers ohne die installierte Software (um sie später herausrechnen zu können), die Installation und den Leerlauf der Software, die eigentliche Durchführung des Nutzungs-Szenarios und schließlich die Deinstallation aller Komponenten. Hat man mehrere Nutzungs-Szenarien, werden diese einzeln gemessen, jedes mindestens zehn Mal.
Während jedes Durchlaufs erfasst das Green Metrics Tool eine große Anzahl an Kennzahlen — von CPU Power über RAM-Auslastung und Disk I/O bis zu Netzwerk-Traffic — und stellt die Ergebnisse anschließend übersichtlich grafisch dar. Zudem gibt es einen (kostenpflichtigen) Blauer-Engel-Exporter, der die benötigten Messwerte direkt als Excel-Dateien für das Audit passend aufbereitet.
Die Zusammenarbeit mit einem Mess-Partner hat aber noch weitere Vorteile: Z.B. bekommt man die geforderte Dokumentation des Mess-Aufbaus inklusive ausführlicher Begründung, wie die Messungen durchgeführt wurden und weshalb Virtualisierung als Mess-Methode überhaupt geeignet ist, direkt mit dazu. Auch das Ermitteln der minimalen Systemvoraussetzungen der gemessenen Software übernimmt das Tool.
2. POTENZIELLE HARDWARE-NUTZUNGSDAUER
Für den Blauen Engel muss man nachweisen, dass die Software auf mindestens fünf Jahre alter Hardware lauffähig ist. Da die Messungen bei Green Coding Solutions auf einem 7 Jahre alten Server laufen, kann diese Anforderung bei dieser Variante einfach abgehakt werden. Auch ohne Mess-Partner würde ich deshalb empfehlen, die Messungen direkt auf einem ausreichend alten System durchzuführen, um diese Anforderung zu erfüllen.
3. NUTZUNGSAUTONOMIE
Dieses Kriterium hat eine Reihe an Unterpunkten, die sicherstellen sollen, dass die Software auch für den Fall, dass der Hersteller den Support einstellen sollte, noch eigenständig weitergenutzt werden kann und nicht ersetzt werden muss.
Zunächst muss man für die Software eine ausreichende Dokumentation zur Verfügung stellen: Was tut sie und wie benutzt man sie, unter welcher Lizenz wird sie veröffentlicht, welche Datenformate nutzt sie (proprietäre Formate dokumentieren!), API-Schnittstellen mit Endpunkten und Parametern, Datenbank-Schema, Antwortformate, Authentifizierung, Fehlerbehandlung… — das Mindset hierbei sollte sein: "Was braucht eine Kundin dieser Software, um sie auch ohne die Hilfe des Herstellers eigenständig weiter betreiben zu können?"
Dokumentiert werden muss auch, wie man die Software restlos deinstallieren kann und ggf. wie sie installiert wird, falls das nicht mit einem Doppelklick auf einen Installer geschieht.
Ein Unterkriterium von Nutzungsautonomie, das tatsächlich auch der Ressourceneffizienz zugute kommt, ist Modularität. Es fordert, dass die Software modular aufgebaut sein sollte und es möglich sein muss, die Features, die man nicht nutzen möchte, einzeln abzustellen — und diese dann auch keine Energie verbrauchen dürfen.
Ein gutes Beispiel, warum das sinnvoll ist: Der KI-Hype hat dafür gesorgt, dass heute in fast jeder Software für Endanwender:innen ein KI-Feature integriert ist, das man meist nicht abstellen kann und das den Energieverbrauch in die Höhe treibt, ob man das Feature nun nutzen möchte oder nicht.
Schließlich fordert der Blaue Engel, dass die Software keine Werbung enthält (ausgenommen ist Werbung für die eigenen Anwendungen des Unternehmens) und ihre Nutzenden nicht trackt. Ein nicht personenbezogenes "Tracking" der Anwendungs-Performance im Sinne von Observability ist aber erlaubt.
Warum wir uns für die Zertifizierung entschieden haben
Unsere eigene Zertifizierung war nicht der erste Punkt, an dem ich mit dem Blauen Engel in Berührung kam. Ich hatte die Entwicklungen rund um das Label schon verfolgt, seit Okular ihn bekommen hatte.
Als die Kriterien dann überarbeitet wurden, habe ich die Gelegenheit genutzt und wurde Auditorin, um tiefer einzusteigen. Zu diesem Zeitpunkt war neuland auch schon Mitglied im Bundesverband Green Software und als Verband waren wir vom Konzept des Blauen Engels überzeugt und wollten ihn gerne pushen — da liegt es nahe, dass Unternehmen des Verbands auch zu den ersten gehören, die sich zertifizieren lassen.
Ich war inzwischen Co-Vorsitzende im Verband geworden und wollte gerne, dass neuland mit gutem Beispiel vorangeht und wir über die Zertifizierung die Gelegenheit bekommen, eigene Erfahrungen mit dem Prozess zu sammeln und uns mit dem Green Metrics Tool beim Einsatz in einem echten Projekt vertraut zu machen.
Es gab aber zunächst ein Problem: Wir hatten keine Software, die für den Blauen Engel in Frage gekommen wäre. Wir bauen bei neuland überwiegend Custom Software für unsere E-Commerce Kunden, z.B. self-contained Systems als Teil eines großen Shop-Systems. Diese Software ist zum einen nicht für den eigenständigen Einsatz gedacht (mind. 90% Messbarkeit!). Zum anderen gehört sie unseren Kunden, nicht uns. Ohne deren Erlaubnis wäre also gar nichts gegangen.
Es ergab sich aber schließlich doch noch die Gelegenheit für eine eigene Zertifizierung, als im Frühjahr 2025 HOLMES in einer ersten Version fertiggestellt wurde. Dabei handelt es sich um eine Software, die neuland in Zusammenarbeit mit Tudock entwickelt und die auf Open-Source-Suchtechnologien wie Solr oder OpenSearch aufbaut, aber die Konfiguration der Suche, Versionierung der Konfiguration etc. in einem Backoffice erlaubt.
Damit hatten wir also einen geeigneten Kandidaten für den Blauen Engel — aber seien wir mal ehrlich: All die Arbeit und Kosten dafür hätte neuland sicher nicht auf sich genommen, nur um mir einen Gefallen zu tun. Der Blaue Engel genießt in Deutschland ein hohes Ansehen und ist auch immer mit einem Schub an Sichtbarkeit und Aufmerksamkeit verbunden. Bei einem neuen Software-Produkt kommt das dem Marketing durchaus zugute und ist in meinen Augen ebenfalls ein guter Grund für eine Zertifizierung.
Nicht zuletzt war der Blaue Engel für neuland eine Möglichkeit, unserem Green IT-Engagement einen spürbaren Schub an Glaubwürdigkeit zu verleihen: Schnacken kann jeder, aber machen ist krasser!
Zertifizierungsprozess, Teil 1: Aufbau der Nutzungsszenarien
Ich habe es weiter oben im Text bereits erwähnt: Man benötigt einen Auditor oder eine Auditorin für die Zertifizierung, der oder die vom Umweltbundesamt akkreditiert wurde und im Prozess prüft, ob alles mit rechten Dingen zugegangen ist. Diese Person muss neutral sein und darf nicht aus dem zu zertifizierenden Unternehmen kommen — ich selbst kam also nicht in Frage.
Unser erster Schritt war deshalb, eine Auditorin/ einen Auditor zu finden. Es gibt eine ganze Reihe an Personen, die dafür in Frage kommen (man findet die Liste auf der Website des Blauen Engels). Wir entschieden uns für Philipp Kersting, der bereits mehrere Audits gemacht hatte und den ich aus der Vorstandsarbeit im Bundesverband Green Software als gewissenhaften Kassenwart kenne.
Egal, für wen man sich entscheidet — wichtig ist, dass man die Person frühzeitig kontaktiert und von Anfang an in Austausch geht. Neben der Vereinbarung einer Vergütung für das Audit gibt es auch eine Reihe an Fragen zu klären:
1. BEZOGEN AUF DIE SOFTWARE SELBST
- was tut die Software und welchen Mehrwert stellt sie dar?
- Fällt sie wirklich in den Geltungsbereich?
- Wird sie unternehmensextern genutzt? Wenn nicht, fällt sie ebenfalls nicht in den Geltungsbereich!
- Wie viele Nutzer:innen hat die Software üblicherweise?
2. BEZOGEN AUF DIE NUTZUNGSSZENARIEN
- Auf welche unterschiedlichen Arten wird diese Software üblicherweise genutzt?
- Wie viele Szenarien sind angemessen? (Mindset: die üblichen 80% abdecken)
- Wie viele Nutzer:innen gibt es bei den unterschiedlichen Szenarien?
- Woher bekommt man repräsentative Daten zum Befüllen der Datenbank?
- Sind diese Szenarien wirklich repräsentativ für die echte Nutzung, z.B. bezogen auf das Datenaufkommen?
Hierfür empfiehlt es sich, frühzeitig ein Treffen mit der Auditorin/ dem Auditor zu vereinbaren und ihr/ ihm die Software vorzustellen, sie/ ihn durch die Anwendung zu führen und offene Fragen zu klären. Ich halte es auch für wichtig, Vertrauen und einen "guten Draht" zu der Person aufzubauen, da der Auditierungsprozess mit hoher Wahrscheinlichkeit die eine oder andere knifflige Situation bereithalten wird und es gut ist, wenn man die einvernehmlich geklärt bekommt.
Zur Vorbereitung der Messungen muss die Anwendung dockerisiert werden und zwar so, dass der gesamte Prozess vollautomatisch ablaufen kann. Das heißt, alles, was die Anwendung benötigt, um laufen und eine Nutzung simulieren zu können, muss automatisiert auf- und später wieder abgebaut werden.
Im Fall von HOLMES bedeutet das, dass u.a. eine Postgres-Datenbank und ein ZooKeeper installiert werden, Solr installiert, mit ca. 50000 Produkten befüllt und der Index erzeugt wird, die eigentliche Anwendung aufgesetzt wird und ein Playwright installiert wird. All das muss automatisiert in der richtigen Reihenfolge passieren und mehrmals müssen Schritte aufeinander warten, damit es überhaupt weitergehen kann.
Jeder Service bekommt dabei seinen eigenen Docker-Container. Das ist wichtig, damit das Green Metrics Tool all diese Teile einzeln erkennen und z.B. Client und Server unterscheiden kann.
Falls es mehrere Szenarien gibt, die unterschiedliche Container benötigen, sollte man darauf achten, wirklich nur die genutzten Container hochzufahren. Bei HOLMES ist das der Fall: Wir haben ein Szenario für die Konfiguration der Suche im Backoffice, welches einen Playwright nutzt, und ein Szenario für die Suche im Online-Shop, das nicht von einem Browser gesteuert wird, sondern über JMeter, ein Last-Tool.
Anfangs fuhren beide Szenarien sowohl den Playwright-, als auch den JMeter-Container mit hoch, bis uns klar wurde, dass das gar nicht nötig ist und das Auftrennen den gemessenen Energieverbrauch nochmal senkt.
In der Spezifikation des Nutzungsszenarios lassen sich Logausgaben mit Zeitstempel und einer Ausgabe-Nachricht einbauen. Das sollte man auch auf jeden Fall nutzen, um zu markieren, welche Aktion jeweils ausgeführt wird: "Klick auf Button X", "Textfeld befüllen", "Wechsel der Ansicht auf Y" etc.
Diese Logausgaben werden später vom Green Metrics Tool in die Mess-Ausgaben eingebaut und helfen sowohl dem Auditor als auch einem selbst, viel leichter nachzuvollziehen, welcher Verbrauchsanstieg der Software durch welche Aktion ausgelöst wurde. Sie tauchen auch mit Zeitstempel und ausgeführter Aktion als übersichtliche Liste in dem Excel-Dokument auf, das der Blaue-Engel-Exporter des Green Metrics Tools erzeugt und helfen so dem Auditor und dem Prüfer beim RAL nachzuvollziehen, was das gemessene Nutzungsszenario ist.
Zertifizierungsprozess, Teil 2: Messungen durchführen
Wie bereits erwähnt, haben wir uns der Einfachheit halber dafür entschieden, mit Green Coding Solutions als Messpartner zusammenzuarbeiten. Auch da empfiehlt es sich, frühzeitig in Austausch zu gehen und kontinuierlich zusammenzuarbeiten.
So einige Schwierigkeiten, die uns während der Messungen begegneten, konnten mit der Hilfe von Arne Tarara, dem CEO von Green Coding Solutions, sehr schnell und unbürokratisch gelöst werden. Selbst ein paar Änderungen am Green Metrics Tool wurden während des Prozesses vorgenommen, um die Nutzung zu erleichtern.
Ein paar unserer Schwierigkeiten möchte ich hier erwähnen, in der Hoffnung, dass es Anderen nützt.
Zunächst muss man sagen: Das Green Metrics Tool ist wirklich ein super Werkzeug, aber in der Benutzung anfangs nicht ganz einfach, und der Teufel sitzt häufig im Detail. Inzwischen gibt es aber einige auf Github veröffentlichte Case Studies und Dokumente, die die Nutzung erleichtern, darunter sämtliche Nutzungsszenarien der Nextcloud-Zertifizierung.
Open Source Software hat den Vorteil, dass der Code in einem öffentlichen Repository liegt und das Green Metrics Tool ihn problemlos auschecken kann. Da HOLMES aber nicht Open Source ist, brauchten wir für die Messungen einen anderen Weg, um dem Tool Zugang zum Quellcode zu verschaffen. Bei neuland lag dieser in einer Umgebung, die auf Sicherheit und Abschottung ausgelegt war, nicht auf leichten Zugriff von außen. Um die Messungen zu ermöglichen, haben wir das interne Repo auf ein passwortgeschütztes externes Repo gespiegelt und die Zugangsdaten dafür an Green Coding Solutions gegeben.
Die Nutzungsszenarien für den Blauen Engel müssen zehn bis dreißig Mal ausgeführt werden, um verlässliche Messergebnisse garantieren zu können. Als verlässlich gelten die Ergebnisse dann, wenn über diese Mess-Reihe hinweg die relative Standardabweichung des Energieverbrauchs unter 5% liegt. Dieser Wert wird vom Green Metrics Tool berechnet und nach Abschluss der Mess-Reihe ausgegeben.
Bei unseren Messungen dauerte es ziemlich lang, bis wir unter 5% Abweichung lagen. Der Großteil unserer Messungen war sehr konstant, aber dazwischen gab es immer wieder einzelne, die wirklich deutlich länger dauerten und auch deutlich mehr Energie verbrauchten. Nach einigem Suchen nach der Ursache stellte sich heraus, dass der Speicher für Solr zu knapp bemessen war, was gelegentlich zu großem Durchtauschen von Speicherplatz führte und unsere Messungen unbrauchbar machte. In diesem Fall führte also spannenderweise das Erhöhen des Speichers für Solr dazu, dass der Energieverbrauch der Messungen sank und wir bei einer Standardabweichung von nur noch gut einem Prozent landeten.
Zu guter Letzt sollte man während der Messungen tunlichst die Finger vom Repository lassen, denn das Green Metrics Tool checkt vor jeder Messung die neueste Version des Codes aus. Wenn sich daran etwas geändert hat — und sei es nur ein entfernter Typo in einem Kommentar — geht es davon aus, dass zwei unterschiedliche Versionen der Software vorliegen. Die kann es dann zwar miteinander vergleichen, aber im Sinne des Blauen Engels handelt es sich nicht mehr um eine gültige Mess-Reihe derselben Softwareversion und man muss mit allen zehn Messungen nochmal von vorn anfangen.
Zertifizierungsprozess, Teil 3: Dokumente anfertigen
Wenn die Mess-Reihen gültig sind und die gemessenen Werte als Excel-Dokument vorliegen, ist es an der Zeit, die benötigten Einreichungsdokumente zu erstellen. Das sind so einige:
- ein allgemeines Dokument über die vorliegende Software, das vom beantragendem Unternehmen und Auditor:in unterschrieben werden muss und in dem beide Seiten versichern, dass die Prüfung erfolgt ist und alles seine Richtigkeit hat
- eine Excel-Datei mit den Messergebnissen pro Nutzungsszenario
- ein Archiv mit Screenshots aller Messungen, jeweils für Baseline, Leerlauf und Szenario-Messung
- mehrere Dokumente, in denen alle Angaben ausgeführt sind, die in den Vergabekriterien gefordert werden
- ein Dokument, das diese Angaben nochmal in Kurzform enthält und direkt auf der Website der Software zum Download zur Verfügung stehen muss
Der Inhalt dieser Dokumente ist nur grob und damit nicht bis ins Detail vorgegeben und wird sich von Software zu Software unterscheiden. Es geht hier darum, Auditor:innen und dem RAL — der Institution, die alle Blauer-Engel-Anträge final prüft und das Siegel vergibt — ein gut verständliches Bild der vorliegenden Software zu vermitteln und die Angaben zu liefern, die einer Kundin nützen würde, wenn sie die Software eigenständig betreiben will.
Auch in dieser Phase gab es bei uns noch ein paar Schwierigkeiten. Zum Beispiel arbeite ich auf einem Mac, unser Auditor Philipp aber mit einem Windows-Rechner. Wir mussten mehrfach Excel-Dokumente hin- und herschicken, bis mit den eingetragenen Zahlenwerten alles passte. Irgendwann war bei mir die Excel-Datei durch das häufige Konvertieren korrupt und zeigte bei Philipp nichts mehr an. Ich musste dann von vorn beginnen mit dem Ausfüllen der Angaben und Überprüfen der Zahlenwerte.
Ein Kriterium, das ich bisher nicht erwähnt habe und das in unserem Prozess auch erst kurz vor Ende zur Sprache kam, ist, dass sich das zu zertifizierende Unternehmen verpflichtet, kostenlose Sicherheitsupdates für die Software zur Verfügung zu stellen, und zwar für mindestens fünf Jahre nach Bereitstellungsende. Der Hintergrund ist wieder: Die Software soll lange sicher genutzt werden können.
An diesem Punkt stand die Zertifizierung bei uns intern auf der Kippe. Sich über einen so langen Zeitraum zu kostenlosen Sicherheitsupdates zu verpflichten, auch für die Open Source Software, auf die HOLMES aufbaut, und das "nur für ein Öko-Label", schien verrückt. Das neuland-Herz in mir konnte die Reaktion meiner Kolleg:innen gut verstehen; das Nachhaltigkeits-Herz in mir sah aber deutlich, wie wichtig die Eindämmung von Software-Obsoleszenz ist und weshalb dieses Kriterium also sinnvoll ist. Ich bin froh, dass ich an dieser Stelle Rückendeckung von meiner Geschäftsführung bekam und der Prozess weitergehen konnte.
Was kostet es und war’s das wert?
So eine Zertifizierung kostet nicht nur Zeit und Nerven, sondern natürlich auch Geld:
- Die Vergütung von Auditor:innen wird individuell verhandelt und richtet sich u.a. nach der Anzahl der zu prüfenden Nutzungsszenarien.
- Das Green Metrics Tool kostet pro Monat 250 € für den Premium-Tarif, der u.a. eine unbegrenzte Anzahl an Messungen erlaubt.
- Der Blauer-Engel-Exporter ist für 750 € einzeln zubuchbar.
- Der RAL nimmt pro Vertrag eine Gebühr von 600 €.
- Dazu kommt eine individuelle Jahresgebühr beim RAL für die Nutzung des Siegels, die sich danach richtet, wie viel Umsatz man mit der zertifizierten Software macht.
Bei Open-Source-Anwendungen, die sich die Gebühren des RAL nicht leisten können — z.B. weil kein Umsatz damit erzielt wird — entfällt sowohl die einmalige Gebühr pro Antrag als auch die jährliche Gebühr für das Tragen des Siegels.
Bleibt die Frage, ob sich all das gelohnt hat.
Ja, finde ich, allein schon für die Messungen. Man bekommt dadurch ganz andere Einblicke in die eigene Software und sammelt wertvolle Erfahrungen im Umgang mit dem Mess-Tool, die so nur das praktische Tun mit sich bringen.
Das Label lohnt sich aber auch für potenzielle Kundinnen, die sich sicher sein können, dass sie eine effiziente Software bekommen, die sie über viele Jahre hinweg sicher nutzen werden können.
Der gesamte Prozess dauerte deutlich länger, als ich vorher gedacht habe. Wir brauchten alles in allem ca. drei Monate, wovon allein drei Wochen auf den RAL entfielen.
Als wir dann endlich die Urkunde bekamen, waren aber alle bei neuland stolz! Ein schöner Abschluss war auch die feierliche Übergabe der physischen Urkunde durch das Umweltbundesamt während der ecoCompute Konferenz in Berlin.
Den Blauen Engel darf man ein Jahr lang tragen, bevor eine erneute Zertifizierung mit neuen Messungen nötig wird. Der Energiebedarf darf dann (ohne triftigen Grund) maximal 10% höher sein als im Jahr zuvor.
Wir haben beschlossen, nächstes Jahr zu re-zertifizieren und werden dafür in absehbarer Zeit wieder mit den Vorbereitungen beginnen. Besonders spannend werden die ersten Messungen werden, da HOLMES immer noch konstant weiterentwickelt wird: Laufen die Nutzungsszenarien noch? Hat sich der Energieverbrauch verändert? Und wenn ja, warum?
Wir unterstützen übrigens gern auch andere Unternehmen auf dem Weg zum Blauen Engel, denn je mehr Unternehmen diesen Schritt gehen und auch langfristig Sichtbarkeit für den Energieverbrauch ihrer Anwendungen schaffen, desto näher kommen wir der Vision unseres Bundesverbands Green Software von einer Zukunft, in der Software sparsam mit Umweltressourcen umgeht.
