Do we need Energy Labels for software?
Software is eating the world, they say. And as software needs underlying infrastructure to run, the amount of energy used to power our digitized lives is constantly increasing. This 2020 paper (link) estimated that Information and Communication Technology consumed 7% of overall electricity and it is safe to assume that this fraction will be increasing.
Considering the climate catastrophe and the dependence on fossil fuels with all its terrible political and socio-economic consequences it is clear that sustainability is an important topic also for Information Technology.
Infrastructure providers have been trying to decrease the amount of fossil fuels they use to power their data centers and to increase the fraction of used energy that is produced in a CO2-neutral way with the promise to be powered by fully renewable resources in a couple of years.
The efforts are undeniably credible and helpful but ultimately our goal must be to use renewable energy to substitute fossil fuels as quickly as possible and not to increase the overall level of energy consumption by ICT — even if renewable.
To achieve this we need to operate our IT service as efficiently as possible from an energy perspective.
Obviously there is a strong impact by the policies around energy pricing, e.g. taxing CO2 emissions can provide strong incentives to substitute fossil fuels. But one can also think of another potentially useful instrument that could guide end-users of IT solutions in their purchasing decisions and thus also provides companies with a strong incentive to offer their solutions as energy-efficient as possible: An Energy Label for Software.
Why an Energy Label?
Energy Labels are widely used in products like consumer electronics and household devices. They provide a simplified and easily understandable way to figure out if a device works efficiently or not from an energy perspective.
Sure, there are many things that can be criticized about this approach but generally it provides useful guidance and enables consumers to select the product not only based on features but also on energy efficiency.
Something similar can be envisioned for software.
As an example, think about two software products with similar functionality, a slightly different feature set and different energy labels. In this case the consumers can make their purchasing decision not only based on visual appearance and functionality but also based on the energy efficiency of the offered implementation.
How can energy efficiency of software be measured?
This is a complex topic and can’t be covered in detail here but it is clear that the energy consumption of a software product is impacted by many factors:
Besides intrinsic complexity related to richness of functionality there are aspect of software architecture, technology stack, efficiency of infrastructure usage and generally the energy consumption of the underlying infrastructure to take into account. If we talk about absolute energy consumption, the number of users is obviously also relevant.
So it is clear that a highly aggregated metric is needed that takes all of these aspects into account and in the best case also considers energy consumption across the whole life cycle.
Some very simple ideas for SaaS applications could be energy consumption per typical user/day or energy consumption per transaction.
But generally it is undeniable that energy consumption is a proxy for complexity and less complex solutions have potentially lower energy consumption.
Feature drift and gold plating
In that sense a label assessing the energy consumption of a software product may also be an incentive to minimize feature drift and gold plating. Every additional function implemented in a system will drive complexity and thus energy consumption.
Customers may decide to go for a simpler solution that still caters their needs but with a smaller environmental footprint. Simple software with lower complexity is certainly something appealing to many consumers.
What is in it for vendors?
Selling energy efficiency as a desired property of a product and monetizing on Energy Labels is common practice for a lot of product categories. It certainly can also be done for software.
But keeping complexity at bay (and thus taking care of energy efficiency) is also one of the key rules of good software engineering.
Reduced complexity will increase the maintainability of applications and changes can be introduced quickly with lower risk. This will allow vendors to react faster to customer demands and make sure that the focus is on the delivery of customer value. It will also allow vendors with limited resources who can’t compete on functionality alone to be competitive in other dimensions important to potential customers.
A focus on energy efficiency may help optimizing architecture and infrastructure footprint, resulting in considerably reduced operational expenses across the application’s life cycle.
Conclusion
Making the energy efficiency of applications transparent could have considerable upsides. It incentivizes a lot of desired software properties: simplicity, small footprint and maintainability. A well established and easy to understand visual language is readily available.
Finding a good way to measure the energy efficiency across the wide range of software solutions existing will be challenging but possible solutions surely exist.
The overall impact of a Energy Label may not be huge but even small contributions help!