Das übergeordnete Ziel war es, eine verlässliche, transparente Plattform zu schaffen, über die alle relevanten Treibhausgasemissionen einer Hochschule erfasst und ausgewertet werden können. Und das nicht als Insellösung für nur eine Institution, sondern als System, das mehrere Hochschulen gleichzeitig bedienen kann, mit dem Komfort, Bilanzen zu vergleichen und zukünftig miteinander zu teilen. Gegenüber dem klassischen Excel-Ansatz bedeutete das einen echten Qualitätssprung. Automatisierte Berechnungen, standardisierte Prozesse, historische Daten und direkte Vergleichbarkeit sind in Tabellenkalkulationen eher ungeeignet und wenig anschaulich. Die Berechnungsmethodik wurde im laufenden Prozess mehrfach angepasst, was bei einem Projekt, das von mehreren Hochschulen gemeinsam getragen wird, kaum anders zu erwarten war. Für uns hat das trotzdem eine Menge Flexibilität erfordert und uns noch einmal mehr gezeigt, wie wichtig es ist, Software so zu bauen, dass sie mit den Anforderungen wachsen kann.

Zu Beginn des Projekts stand die zugrundeliegende Datentabelle für Emissionsfaktoren fest. Entsprechend haben wir auch unsere Architekturentscheidungen früh getroffen. Als die Tabelle sich später doch änderte, hatte das für uns zur Folge, Daten manuell aus der Tabelle in den Code zu übertragen. Das war ein aufwändiger Schritt, der im Nachhinein vielleicht vermeidbar gewesen wäre. Aber auch eine wertvolle Erfahrung, die uns noch stärker für die Risiken bestimmter Architekturannahmen sensibilisiert hat. Eine weitere grundlegende Entscheidung betraf das Rollen- und Rechtesystem. Setzen wir auf eine etablierte Lösung wie Keycloak, oder bauen wir etwas Eigenes? Wir haben uns für eine maßgeschneiderte Eigenentwicklung entschieden, weil sie uns die nötige Kontrolle und Flexibilität für das Nutzer- und Organisationsmodell gibt, ohne mit Features von etablierten Lösungen aufgebläht zu sein, die wir nicht benötigen.