Green Software: Seven traps when calculating carbon emissions from software
In our last post in our Green Software Series, we looked at the case for green design principles and how they can be put into action to reduce the environmental impact of software. Now we're shifting the focus to look at how organisations measure the impact of the solutions they use. There are common pitfalls people run into when calculating carbon emissions from software. Peter Campbell, Director of Green Software, shares Kainos' recent experiences of applying the Green Software Foundation's Software Carbon Intensity (SCI) specification to enterprise software, identifying 7 traps for CIOs and CTOs to avoid.
Understanding and optimising the environmental footprint for IT means calculating the carbon emissions for each software service. We now have a model to do this with the SCI specification from the Green Software Foundation. But it's not a straightforward calculation and there are a few traps if you haven't done it before.
Many organisations in 2023 voluntarily report their carbon emissions for their operations, based on Green House Gas (GHG) Protocol accounting guidance. This is broken into emissions from the fuel you burn (scope 1), the electricity you buy (scope 2) and everything else in your value chain (scope 3).
This provides investors, customers and employees with a view of the progress organisations are making towards their Net Zero climate goals in published sustainability reports. We're increasingly seeing new Environmental, Social, and Governance (ESG) regulations being formulated to make this more standardised and mandatory, for example with TCFD/SDR in the UK and CSRD in the EU.
This reporting of carbon emissions is retrospective and typically done annually. It's also reported at a macro-level for an entire organisation not typically broken down by product or service. Given this, it isn't suitable (yet) for businesses' operational decision-making.
Estimating carbon emissions
We've already established in this Green Software Series that digital sustainability is part of the climate problem and an important part of the solution. Given this, CIOs and CTOs need a way to calculate the carbon footprint for software within their organisation-wide carbon reporting.
There are two main methods for calculating software carbon emissions for IT:
- The granular approach: calculating from utilisation data of hardware used. This is a bottom-up approach where you do most of the hard work. The calculation is based on the specific hardware you have deployed and how much you use it. It is most suited to local data centres and infrastructure-as-a-service.
- The aggregate approach: calculating from cloud spend data. This is an estimate that infers carbon emissions for a service based on spend data for a cloud subscription as a percentage of the carbon emissions for the subscription provided by the cloud provider. It is most suited to platform-as-a-service where the granular approach is not possible.
The software carbon intensity (SCI) process
The Software Carbon Intensity (SCI) process was released by the Green Software Foundation in 2021. It promotes the granular approach to estimating carbon emissions. Starting with the energy used and converting this to the carbon emitted. It also incorporates carbon emitted during manufacturing not just operational use.
The SCI is likely to become the industry-standard way to calculate emissions for software services with a view to reducing the impact of IT. The calculation seen above is fairly straightforward, however attempting to apply this to a complex enterprise software service is not trivial. It's worth spending time to understand the specification with the SCI Guide. We really like the specification, which is why we have put it at the core of the Kainos Green Software Commitment to all our customers. If you're not familiar with the SCI:
- It is an intensity calculation, so it measures the rate of use for a functional unit that is relevant to the software service.
- It is intended to include embodied carbon and operational carbon. So, it covers carbon emissions from manufacturing as well as the running of the software.
- It aims to reduce emissions from software and does not allow offsetting.
- It encourages an end-to-end view of the footprint not just compute and so includes compute, data, networking and devices.
- It works for software whether deployed on the cloud or local data centre and virtual or physical machines.
7 traps to avoid when using the SCI
This year in Kainos we've been applying the SCI to some of the digital services we've built on different clouds. This has given us an insight into the benefits and some of the pitfalls of applying the SCI to complex production enterprise software. This is important because the process needs to work well for complex software, given these will likely have a greater footprint. We'll be revealing more about the results of this in the coming weeks, but we wanted to share some experiences from this process.
And so, we're sharing 7 traps we've encountered that you will want to avoid when you apply the SCI to your software:
- Cloud calculations: Being deployed on the cloud does not make it any easier. Applying the SCI calculation is a non-trivial process. In 2023 it's a manual process that requires data wrangling and lots of hand-cranked calculations. At Kainos we have cloud economists who have the skills necessary to navigate this for public cloud platforms. But don’t expect the cloud providers to make this any easier for you. Deciphering usage, utilisation and energy use is all down to you and your experience. We're hoping Microsoft, AWS (Amazon Web Services) and Google will improve this with new sustainability platform reporting features.
- Platform data: If you use cloud platform services, you will have difficulty calculating emissions. Platform services (aka Platform-as-a-service) provide fully managed services that allow developers to deploy and manage their software with less effort than managing their own virtual machines, such as serverless, monitoring services and application load balancers. But the flip side of this convenience is cloud providers do not yet provide this usage data for specific services (they may provide an estimate for a whole subscription). We need the cloud providers to provide more detailed usage metrics from platform services so that we can have more accurate carbon emissions calculations.
3. Understanding the results: The SCI result is just a baseline, neither good nor bad. After your initial elation of finishing your first SCI calculation, you will ask yourself is it a good or bad result? It is neither. As you get started you should understand that it's providing you with a valuable baseline. This baseline can be used to compare the trend over time with subsequent calculations. And it is this trend that we think is the most valuable output from the SCI calculation to allow operational validation of sustainable design changes. Think of the SCI as something you can use to compare with itself, over time.
4. You can't predict the future: The SCI is always a retrospective calculation not a forecast. You will need a running service (at a representative scale and load) as a starting point. So, it isn’t useful during software development, but only when your software is operational or close to operational. Once operational, you acquire usage and cloud spend data as an input. Given cloud providers bill monthly, this will typically mean looking back at the month's usage. Don't expect that the SCI is a forecast of what your carbon emissions will be in future, it's not.
5. Keep your data: Historic calculations are impossible if usage data has not been retained. Usage data for each server, database, storage device etc. is the foundational input dataset for the calculation. But how long do you retain this log data? If you are hoping to look back and compare this month's carbon emissions with one year ago, do you have all the usage data? If not, you can't do historical calculations. Some changes to retention policies for these specific logs are needed to allow this in future.
6. Hidden costs: There are unexpected costs to doing the SCI calculation. To complete the calculation, you will be reliant on third-party datasets. This could be for regional electricity mix at a point in time for data centres you are deployed to, conversion factors from kWh to CO2e or cloud usage data. New climate data aggregators are appearing that make this process much easier, e.g., Climatiq or Boazvita if you buy a commercial license to use. This is a hidden cost you need to be aware of before you begin.
7. Missing pieces: SCI doesn't include the calculation of carbon emissions from the software development process. This is a missing piece of the picture for software carbon emissions. Of course, SCI is not attempting to calculate this but as we see significant cost, energy and carbon emissions used for AI model training, for example. This will fall outside any SCI calculation you have.
The SCI is a new specification and one we'd like to see being applied to more software services. If you take away one thing from this article, it's that the SCI is intended as a specification to encourage the reduction of the carbon emissions of software. But to achieve this kind of reduction, we recommend you build it into your regular operational process so that you can start to see the monthly trends. It is this repeated calculation that will provide the most benefit from the SCI result. It can be used to demonstrate the reduction in carbon emissions from new features and optimisations. If you want help to do this, please get in touch by completing the form on our Green Software Commitment page.