Why do we care about whether we can measure things? Our slogan may be "Architecting your Business," but we're not an architecture company...
Wanting to improve things is naturally ingrained in us IT people – when you reach for the stars, you naturally want to make the world a better place. That’s how we created p-sustainabilities – a group within Pentacor dedicated to making our company greener, more sustainable, and more environmentally friendly. Over time, we tackled all the low-hanging fruit – now we have regional drinks in the fridge, organic breakfasts on the table, and we’re probably all a bit more mindful of sustainability. Of course, we also keep the lights off in the office as long as possible in the evening (not just for sustainability reasons – after all, we all know IT people don’t like bright lights).
But somehow, it didn’t really feel like we were saving the world. So where are the tools that can truly make an impact? We realized that, as a company, we can have a greater impact by bringing the topic of Green IT to our customers – making it relevant to them and, in doing so, helping them stay competitive, future-proof, and aligned with the times. At the same time, we’re contributing to the foundation of all life. There are plenty of reasons to consider Green IT an important topic at Pentacor, even if our customers haven’t (yet) asked about it directly.
It wasn’t enough for us to simply know various ways to develop code in the spirit of Green IT – we wanted to achieve even greater impact. For us, understanding the impact of our changes to a system is a prerequisite for truly making a difference. So, we asked ourselves how we could measure and compare the impact of the status quo with the (future) impact of our changes.
When dealing with sustainability, it’s relatively easy to come across various metrics like electricity consumption, water consumption, and CO2 emissions. But when you dig deeper, it quickly becomes clear that all these metrics can be summarized by carbon footprint. So, how can we determine the carbon footprint of our software systems, and perhaps even monitor it over time and track its development?
In our search for existing approaches, we came across the Green Software Foundation (GSF) – currently the go-to organization for sustainability in the IT sector. We found a wealth of information, links, references, and a newsletter summarizing the latest developments and insights in Green IT. That’s also where we learned about the SCI (Software Carbon Intensity) Specification – a standard for assessing the sustainability of software systems. This was back in the fall of 2023, when SCI was not yet an official standard. Over time, we realized that it’s comparable to a DIN standard: not meant for direct application but as a foundation for implementing specific tools.
Not knowing this at the time, we attempted to apply the SCI specification directly to determine the carbon footprint of software systems. As part of a focus day, we analyzed a small, well-defined part of one of our customer projects. Even with this relatively small software system, collecting all the required data was extremely time-consuming. Some values had to be estimated, as the project’s split runtime environment didn’t always allow for precise measurements – or we simply couldn’t find accurate information. The necessary data had (and still has) to be gathered from various sources, and obtaining data from major cloud providers remains a challenge in itself. After spending an entire day calculating the CO2 emissions of a single API request – and still feeling uncertain about the accuracy of our results – we started wondering whether Ratiopharm might already have something to offer.
This brought us back to the GSF Impact Framework (IF), which we were already familiar with at the time but had initially dismissed as too complex. However, after our experience with the SCI specification, the perceived complexity of the IF no longer seemed daunting – especially since, according to its own description, the IF aims to make determining and sharing the environmental impact of software quick and easy.
The Impact Framework enables flexible calculation of the CO2 footprint of software systems at different points in their lifecycle. To use the IF, a rough idea of the system architecture is sufficient. Unlike other tools (such as the Cloud Carbon Footprint Tool), it does not require components to be already implemented, deployed, or under load in their target environment. This makes the IF particularly useful for evaluating different options before switching cloud providers, estimating new systems, and modeling architectural concepts for new systems.
The IF assesses a system’s carbon footprint based on the (expected) resources used in the target environment. However, it does not include fine-grained analysis at the code level, as is possible with tools like EcoSonar.
With the IF, software systems can be modeled using a pipeline consisting of three phases: Observe (data collection), Regroup (grouping and sorting collected data), and Compute (impact calculation based on the provided data). Each phase is implemented through one or more plugins, which either provide data from static or dynamic sources, transform this data, or calculate the system’s impact. These phases can be executed either sequentially or independently. For instance, data collection – often time-consuming and resource-intensive – can be performed only when necessary, allowing for different system variants to be evaluated based on previously collected data.
The system to be analyzed is modeled within a YAML file called a manifest. This file contains general information about the system (context), a representation of the system structure (tree), and the definition of the pipeline with its three phases. Each phase is described using plugins, and if required by a plugin, input values (inputs) can be specified. The manifest is then executed via the command line using the impact engine, where specific pipeline phases can be selected for execution. The output is generated in the predefined format (e.g., as a YAML file or directly in the command line). The result includes the original manifest, additional details on the individual plugins (explain), and the intermediate and final calculation results (outputs).
The values determined through an IF pipeline heavily depend on the plugins used. Currently, most plugins focus on calculating the CO2 footprint. However, with the appropriate plugins, other metrics – such as water consumption – can also be measured.
The plugins are divided into built-in and community-owned plugins.
- Built-in plugins are developed and maintained by the GSF itself and, like the framework, are published as open-source under the MIT license. While the number and functionality of built-in plugins are still somewhat limited, development is highly active.
Community-owned plugins, on the other hand, are driven by the needs and contributions of the community. These allow for custom functionality, enabling a broad range of use cases to be covered.
To familiarize ourselves with the IF, we first replicated the example from the official documentation. We then applied it to our previous case study using the SCI specification. We were pleased to see that both methods yielded very similar results. Encouraged by this, we began designing and modeling a more complex, prototype scenario based on our project experience. However, we quickly encountered one of the drawbacks of working with a project still in incubation: breaking changes. These unexpected changes ultimately prevented us from completing our model, leading us to shift our focus to other aspects instead.
We are currently working on ways to make the IF more user-friendly and, most importantly, automated. Our goal is to develop p-lugins (plugins the Pentacor way) within the observe phase that dynamically collect data from systems like Datadog. In the future, we aim to create a workflow that will enable the automatic calculation of a system’s carbon footprint within CI/CD pipelines, allowing for continuous monitoring of its environmental impact over time. This will make it possible to promptly detect when a system’s CO2 footprint changes, enabling targeted measures to be taken – such as preventing unnecessary footprint growth.
Over the past year, we have gained extensive knowledge and insights into how the environmental impact of software systems can be determined. We’ve discovered that calculating the carbon footprint of software is already feasible – and that automation will likely make it even more accessible in the future. However, as it stands, the practical usability of the IF remains limited, with only a small number of available plugins and support for select system providers. From our perspective, significant development is still needed before it can be used in production environments. That said, we see great potential in the IF and plan to keep an eye on its progress, contribute where possible, and help shape its future.
We’ve also found that green IT and sustainability in software development are excellent conversation starters. Through these topics, we’ve made valuable connections and had inspiring discussions at conferences and meetups. At the same time, the field of sustainable IT is vast, yet only a handful of aspects receive widespread attention. By focusing on measuring the CO2 footprint of software, we want to explore a less-discussed topic and help bring it into the spotlight.
Stay tuned!
