There's been a focus on carbon emissions at BJSS for some time now. We've been carbon neutral since 2019 and are committed to achieving Net Zero emissions by 2025. Recently, I've seen a lot of chatter about tools available to measure carbon emissions from the use of cloud services, both as a topic of interest (or marketing pushed by cloud vendors) but also as something we've used on projects to monitor and improve the emissions impact of cloud platforms.  

As a result, I've been thinking a lot lately about how it might be possible to build greener software. In this article, I’m going to share my thoughts on the topic – although bear in mind they are just thoughts, they’re not based on cold, hard implementation experience. For the purposes of this article, I'm just going to focus on the technical side of things. Of course, there are plenty of other aspects that feed into overall environmental impact – for example, designing a user interface to minimise energy use, applying software to make business processes more sustainable, or changing the ways we work to be more efficient. While those may have a large impact on reducing carbon emissions, I’m going to put them to one side. 

I mentioned the availability of cloud emissions tools. These are a positive step, though they only paint some of the picture: 

  • They only measure the impact of cloud-based services (not front-end, onward network, or other hardware, for example). This is certainly a step forward, especially as it measures direct and indirect emissions, but the impact of reducing figures on the dashboard can be potentially misleading (e.g., switching from server-side to client-side rendering, potentially reducing overall energy efficiency). 
  • While they can support a business looking to reduce its overall environmental impact, they can also be more cynically used simply as a reporting or accountability tick-box. 
  • There is only so much information service-level granularity can give you about how to reduce the environmental impact of your software. 

While you can use these tools throughout development, the approach that they support is designed to be an operations optimisation – it’s an incremental improvement mechanism and the starting point is reliant on how the solution was designed and developed in the first place. To ensure we have a good starting point from which to improve, we need to look at things like requirements, architecture, and even the approach to development taken. 

Carbon Emissions As A Non-Functional Requirement

Carbon emissions feel like costs in terms of non-functionals. In many cases, the cost is not actually listed as a hard non-functional requirement, but every architect knows that we strive to minimise it where possible and we’re often working to a rough budget. This is how I see carbon emissions too. It's a non-functional need that I want to minimise initially and reduce further incrementally over time. It's not necessarily a fully-fledged non-functional requirement with well-defined criteria to meet. We speak to our clients and business owners about budgets and cost appetite; to ensure carbon emissions have the same type of treatment, we should discuss it early and throughout delivery.

Much like cost, it will be important to understand the priority of carbon emissions from the off. To some, cost will be less of a priority than other factors and the same goes for emissions – knowing the value of it will help decision-making throughout delivery. In those cases where it is a high priority, we can balance other requirements around this, potentially reducing availability, scalability, or performance, or changing how we apply existing patterns (for example, ramping down auto-scaling more quickly after a peak in throughput). Where it is a lower priority, we may simply have to optimise it within greater constraints, though I suspect there is still a lot that can be done.

Greener Approaches To Architecture

The way solutions and software are architected can significantly impact the carbon emissions produced. Network transfer, PaaS vs IaaS, resource utilisation, among many other things, have a part to play.

The impact of our architectural decisions on cost is well understood and architects excel at understanding the cost implications of their designs. I expect in five years’ time the same will be said about emissions impact, but it's certainly not the case yet. And for web-based solutions, there's a whole side of the equation that we can't easily monitor: end-user energy use.

It's not easy to know what your decisions may mean in the context of environmental impact, and it's certainly not simple (or possibly even feasible) to calculate hard numbers outside of those provided by cloud tools. There isn't really a framework to guide us, shared knowledge is limited, and this seems to be backed up by the views of those I've spoken to. I did come across a few things that I felt could help architects (or anyone else) wanting to think about the emissions impact of their decisions.

First is this snippet from the Green Software Foundation's Software Carbon Intensity Specification, which provides three categories that all actions to reduce emissions of a piece of software will fall into:

  • Energy Efficiency - Actions taken to make software use less electricity to perform the same function.
  • Hardware Efficiency - Actions taken to make software use fewer physical resources to perform the same function.
  • Carbon Awareness - Actions taken to time or region-shift software computation to take advantage of clean, renewable, or low-carbon sources of electricity.

I personally find this a simple mechanism to consider, at a high-level, how specific architectural decisions might impact emissions, especially when combined with information from cloud providers about the granular emissions impact of different services.

Secondly, I came across Principles of Green Software Engineering. This provides a starting place for some high-level principles, as well as a few examples of how to apply them (click through each one to see a more detailed description, it’s not immediately obvious you can do this!).

The eight principles within look to be a reasonable starting point for making greener architecture and design decisions, though I can't claim to have had the chance to see them in action. A concern I have is that they could be quite hard to apply; I find a good principle is easy to understand, providing a simple decision-making framework – I’m not sure how true that is here. The principles are not all immediately obvious and on the surface feel like they overlap. However, I do think the examples demonstrating the application of the principles are useful. It occurs to me that open sharing of more of these tangible, by-example implementation patterns, considerations and guidance would be incredibly useful to the technology delivery community.

Finally, I also came across the Green Software Foundation projects page, which, in addition to a number of other interesting projects, has a project to create and share “research, tools, code, libraries and training for building applications that emit less carbon”, which you can find here. This looks to provide a curated list of available tools as well as articles and research in this area. Unfortunately, much like the Principles of Green Software Engineering, I feel this is lacking tangible implementation details. There is no easily consumable list of specific things you might apply to your design or development approach to reduce carbon emissions. Additionally, the list has had few updates, with none in the last six months. While a useful point-in-time view, it doesn’t appear to be a living list.

Sustainability And Continuous Delivery

Many of the things we do as part of the development and release process could have an environmental impact: automated tests running on every change, repeatedly rebuilding assets that have had no changes, intense scale and performance tests, non-production environments sitting around under-utilised. It feels like some of the ideals of continuous delivery could even run counter to the ideals of green software delivery.

I expect several environmentally conscious things could be implemented in the development and release processes, though some will come with a considerable implementation cost and most will need factoring into plans early to avoid costly changes down the line. Change-aware automated testing and asset build, well-managed ephemeral environments, delaying build activities to reduce carbon intensity – these are just a few things that came to mind, but none are simple, iterative changes, they would all require being designed early.

Another thought that came to mind was Environmental Debt, when, in a similar way to technical debt, we know we could do something in a way that has less carbon impact but chose not to, instead of expediting delivery. We could log these instances as items of Environmental Debt, which would be refactored in a later release or as part of continuous improvement time. While this risks creating a dumping ground of tickets that are never revisited, in a team that is bought into this approach and has non-functional requirements of sustainability, it may provide a continuous improvement mechanism that is well understood by engineering teams today.


It feels like the time is right to start widening the environmental lens to software development, share experiences, and raise awareness. The drive to improve the sustainability of technology solutions is a real thing and this article has considered some areas that could support this drive during the development of software: considering sustainability as a non-functional need, discussing sustainability goals with clients and business owners, architecting solutions to reduce carbon emissions, and developing software approaches that give due consideration to environmental impact, such as Environmental Debt. Even where these things may not be possible, considering cost as a reasonable analogue for carbon emissions may aid those delivering software by providing an easily accessible lever to achieve greener solutions.

I’d be keen to hear from anyone who has applied green software principles to software delivery, especially those who may have experience of those implementation patterns and thoughts on which provided the greatest benefits. You can find me on LinkedIn here.