<img height="1" width="1" style="display:none;" alt="" src="https://px.ads.linkedin.com/collect/?pid=4958233&amp;fmt=gif">
RSS Feed

Strategy | Eoin Woods |
14 November 2022


There is scientific consensus today that Earth’s climate is changing and getting warmer, largely because of a dramatic increase in emissions of so-called “greenhouse gases” (GHGs), like carbon dioxide, since the 19th century. As NASA states, “human activities have profoundly increased carbon dioxide levels (a heat-trapping gas) in Earth’s atmosphere”.

Many very common human activities result in the emission of GHGs, including generating electricity from fossil fuels, air travel and combustion engines, agriculture and concrete production, and so it is tempting to assume that a relatively modern, post-industrial activity, like the information and communications technology (ICT) industry, is largely exempt from having to consider its emissions. Unfortunately, this simply isn’t true.

The contribution of the ICT sector to global greenhouse gas emissions is still being researched by the scientific community, but most estimates place it in the range of 2-4% in 2020 (e.g. the research of Malmodin & Lundén and Belkhir & Elmeligi). If the sector does nothing to reduce its output, this percentage is likely to grow as the sector becomes larger and other sectors actively reduce their emissions.

So, we have some work to do.


A lot of the research into the ICT sector’s greenhouse gas emissions has focused on hardware, which is a natural place to start. For example, one of the studies cited above estimates that data centres produce 45% of the sector’s emissions, networks contribute 24%, smartphones 11%, displays 7%, desktop computers 7% and laptops 7%. These estimates are for whole lifecycle emissions, so they include the emissions produced by manufacturing and disposing of the hardware (known as “embodied emissions”) as well as the emissions produced during its use.

What many of the hardware-based studies omit is the effect that the software running on the hardware can have on the lifecycle emissions of that hardware. We will return to this topic shortly.

There has been an awareness of the emissions produced by the ICT sector’s data centres and hardware for some time, and a significant amount of academic research, regulatory attention (particularly in Europe) and industrial activity has been focused on reducing these emissions.

Taking data centres as an example, in the last 10 years, data centres have become much more efficient, with studies showing that while installed capacity has increased by a factor of 10, data centre power efficiency has improved by 25%, and the efficiency of the hardware within the data centres has improved by a factor of 4-5, depending on workload type (Masanet et al). Clearly, this still amounts to a significant net increase in energy usage but also illustrates the dramatic improvements that have been achieved in data centre and hardware power consumption.

The question that remains is where the software running on this hardware fits into the picture.


Software is a series of instructions for a piece of hardware to execute, so the emissions that software is responsible for are emitted by the underlying hardware. A hardware device invariably causes some GHG emissions – whether it is used or not. GHG are emitted during its production, it uses energy whenever it is switched on, and further GHG emissions are created as part of its final destruction. However, the lifetime emissions of a long-lived piece of hardware can be significantly affected by how it is used and operated, and an important aspect of this is the software it runs.

While in operation, highly utilised hardware will consume more energy than the same hardware with low utilisation, both as a direct result of the device’s electricity consumption and indirectly because of the load that it places on its physical environment, primarily the amount of cooling it needs. However, the environmental impact of this energy can vary depending on how the electricity is generated. Electricity from renewable sources will create considerably fewer net emissions than traditional energy sources, such as fossil fuels.

We also need to be aware that the relationship between the embodied emissions of the device, the energy consumed and the load on the physical environment can be complex and subtle. For example, is it better to run a smaller number of highly utilised high-capacity, relatively inefficient, older devices than a larger number of smaller, more efficient, newer devices when you consider energy consumption and embodied emissions? The answer is rarely obvious as it depends on the relationships between the specifics of the device type and the lifespan and usage of each device, which can take a significant amount of analysis to understand.

During operation, the variable factor that we can affect with our software is the energy consumption. So, apart from using electricity from sustainable sources, the obvious place to start in order to make our software “greener” is to reduce the energy consumption that it causes in the underlying devices, including its compute nodes (CPUs, memory), storage and network devices.

When running software on a single dedicated, physical hardware device, we can estimate our energy usage relatively easily, but in today’s complex, virtualised environments, it can be difficult to know whether we are improving things or not. In a highly virtualised environment, it is difficult to measure the real energy consumption, and there are always many trade-offs to consider. To take one example, is it more energy-efficient to compress large data sets before storage to minimise the energy usage for storage but incur CPU usage for the compression and decompression operations? Well, that depends on the relative energy consumption of different devices, the data size and the access patterns of the data.

We could spend a huge amount of time performing fine-grained analyses of our system in order to understand the emissions caused by our decisions, but we will never have time to do this thoroughly unless it becomes much simpler than it is today.

To cut through this complexity, we can adopt a simplifying principle: the more efficient our software is, the less hardware it will need and the less energy it will cause the hardware to consume, which should minimise its lifetime emissions.

Maximising the efficiency of software can be an involved process, but there is a lot of established knowledge that we can draw on. As well as long-standing industrial practice in software efficiency, there is also an emerging body of knowledge developed by the research community that considers efficiency specifically from a sustainability perspective, such as research by Procaccianti et al and Vos et al, to name just two.

This principle is a useful simplification to help us consider the emissions of our software in operation, but there are some other factors we need to bear in mind as well. What emissions do we cause with our software development work? Test environments, continuous delivery pipelines, code repositories, analysis tools, developer workstations and IDEs and all the other parts of a modern software delivery environment are also responsible for emissions. For example, if we run a full “pre-live” environment to simulate production operation and run workload through it regularly, we may be nearly doubling the emissions created by our software.

We also have to consider our indirect emissions, such as those from office space, people commuting to the office, air travel and so on. These may well be counted elsewhere in a corporate emissions study, so we don’t want to double count, but we need to acknowledge that they are the side effect of our software development activity.

In summary, it is quite difficult to assess whether a particular piece of software is “green” or not. Software development and operation certainly generate GHG emissions, directly and indirectly, but estimating the exact level of emissions is hard, and it can be even harder to know how to reduce them.

Our advice is to use cloud platforms powered by sustainable energy sources wherever possible as, for most people, these are the lowest-emission platforms available to them. Most cloud platforms also offer tools which can provide a rough estimation of the emissions generated by your cloud environment, giving insight into the environmental impact of design decisions. We should also increase our awareness of the emissions generated by our software production process, as discussed above.

If we can take these simple steps and consider these factors throughout our software development activities, we can start to understand the environmental impact of our software and, over time, reduce our overall emissions. However, we currently believe that deciding whether a piece of software is really “green” or not is probably beyond us, and claims that certain software is greener than others should be treated with scepticism.


If we cannot confidently assess the environmental impact of a piece of software today, what does the future hold? How do we move closer to that goal?

Other participants in the ICT ecosystem have led the way to solve this problem, notably the engineers who build data centres and the teams who design hardware devices. In the last decade, both of these parts of the ICT sector have dramatically increased awareness of their environmental impact and made huge improvements in measurement, standardisation and then efficiency, significantly reducing their environmental impact.

We believe that people truly desire for software to follow the same path and that the next phase of environmental awareness in ICT will be the development of measurement methods for the environmental impact of software. These will allow us to understand – and then reduce – the emissions that our software is responsible for. Indeed, in the future, the regulatory forces that have encouraged data centre and hardware designers to take these factors seriously may also emerge for software.

So, we hope that in the not-too-distant future, we’ll be able to take the same quantitative approach to software GHG emissions that we already have for hardware devices and data centres, but in the meantime, there are plenty of simpler ways that we can increase awareness of the environmental impact of our software development and operation.


Belkhir, Lotfi, and Ahmed Elmeligi. “Assessing ICT global emissions footprint: Trends to 2040 & recommendations.” Journal of Cleaner Production 177 (2018): 448-463.

Malmodin, Jens, and Dag Lundén. “The energy and carbon footprint of the global ICT and E&M sectors 2010–2015.” Sustainability 10.9 (2018): 3027.

Masanet, Eric, et al. “Recalibrating global data center energy-use estimates.” Science 367.6481 (2020): 984-986.

Procaccianti, Guiseppe, Héctor Fernández and Patricia Lago, “Empirical evaluation of two best practices for energy-efficient software development”, Journal of Systems and Software, 117(2016): 185-198.

Vos, Sophie, Patricia Lago, Roberto Verdecchia and Ilja Heitlager, “Architectural Tactics to Optimize Software for Energy Efficiency in the Public Cloud”, International Conference on ICT for Sustainability, 2022.

Eoin Woods

Chief Engineer

Eoin provides technical strategy advice to our major clients and works with our delivery organisation to ensure that the right people, tools, technologies, and processes are in place. Outside work, he is an enthusiastic amateur trumpet player, dwelling in a wide range of styles including wind band, brass band, big band jazz and classical. He also likes anything with an engine that can move quickly, particularly Alfa Romeo, Audi and Jaguar road cars and saloon car, Formula-E and Formula 1 racing.


From This Author

  • 12 July 2019

    The Rising Cost of Poor Software Security



  • 13 November 2023

    Delving Deeper Into Generative AI: Unlocking Benefits and Opportunities

  • 07 November 2023

    Retrieval Augmented Generation: Combining LLMs, Task-chaining and Vector Databases

  • 19 September 2023

    The Rise of Vector Databases

  • 27 July 2023

    Large Language Models Automating the Enterprise – Part 2

  • 20 July 2023

    Large Language Models Automating the Enterprise – Part 1

  • 11 July 2023

    Boost Your Game’s Success with Tools – Part 2

  • 04 July 2023

    Boost Your Game’s Success with Tools – Part 1

  • 01 June 2023

    Challenges for Adopting AI Systems in Software Development

  • 07 March 2023

    Will AI Transform Even The Most Creative Professions?

  • 14 February 2023

    Generative AI: Technology of Tomorrow, Today

  • 25 January 2023

    The Joy and Challenge of being a Video Game Tester

  • 14 November 2022

    Can Software Really Be Green

  • 26 July 2022

    Is Data Mesh Going to Replace Centralised Repositories?

  • 09 June 2022

    A Spatial Analysis of the Covid-19 Infection and Its Determinants

  • 17 May 2022

    An R&D Project on AI in 3D Asset Creation for Games

  • 07 February 2022

    Using Two Cloud Vendors Side by Side – a Survey of Cost and Effort

  • 25 January 2022

    Scalable Microservices Architecture with .NET Made Easy – a Tutorial

  • 04 January 2022

    Create Production-Ready, Automated Deliverables Using a Build Pipeline for Games – Part 2

  • 23 November 2021

    How User Experience Design is Increasing ROI

  • 16 November 2021

    Create Production-Ready, Automated Deliverables Using a Build Pipeline for Games – Part 1

  • 19 October 2021

    A Basic Setup for Mass-Testing a Multiplayer Online Board Game

  • 24 August 2021

    EHR to HL7 FHIR Integration: The Software Developer’s Guide – Part 3

  • 20 July 2021

    EHR to HL7 FHIR Integration: The Software Developer’s Guide – Part 2

  • 29 June 2021

    EHR to HL7 FHIR Integration: The Software Developer’s Guide – Part 1

  • 08 June 2021

    Elasticsearch and Apache Lucene: Fundamentals Behind the Relevance Score

  • 27 May 2021

    Endava at NASA’s 2020 Space Apps Challenge

  • 27 January 2021

    Following the Patterns – The Rise of Neo4j and Graph Databases

  • 12 January 2021

    Data is Everything

  • 05 January 2021

    Distributed Agile – Closing the Gap Between the Product Owner and the Team – Part 3

  • 02 December 2020

    8 Tips for Sharing Technical Knowledge – Part 2

  • 12 November 2020

    8 Tips for Sharing Technical Knowledge – Part 1

  • 30 October 2020

    API Management

  • 22 September 2020

    Distributed Agile – Closing the Gap Between the Product Owner and the Team – Part 2

  • 25 August 2020

    Cloud Maturity Level: IaaS vs PaaS and SaaS – Part 2

  • 18 August 2020

    Cloud Maturity Level: IaaS vs PaaS and SaaS – Part 1

  • 08 July 2020

    A Virtual Hackathon Together with Microsoft

  • 30 June 2020

    Distributed safe PI planning

  • 09 June 2020

    The Twisted Concept of Securing Kubernetes Clusters – Part 2

  • 15 May 2020

    Performance and security testing shifting left

  • 30 April 2020

    AR & ML deployment in the wild – a story about friendly animals

  • 16 April 2020

    Cucumber: Automation Framework or Collaboration Tool?

  • 25 February 2020

    Challenges in creating relevant test data without using personally identifiable information

  • 04 January 2020

    Service Meshes – from Kubernetes service management to universal compute fabric

  • 10 December 2019

    AWS Serverless with Terraform – Best Practices

  • 05 November 2019

    The Twisted Concept of Securing Kubernetes Clusters

  • 01 October 2019

    Cognitive Computing Using Cloud-Based Resources II

  • 17 September 2019

    Cognitive Computing Using Cloud-Based Resources

  • 03 September 2019

    Creating A Visual Culture

  • 20 August 2019

    Extracting Data from Images in Presentations

  • 06 August 2019

    Evaluating the current testing trends

  • 23 July 2019

    11 Things I wish I knew before working with Terraform – part 2

  • 12 July 2019

    The Rising Cost of Poor Software Security

  • 09 July 2019

    Developing your Product Owner mindset

  • 25 June 2019

    11 Things I wish I knew before working with Terraform – part 1

  • 30 May 2019

    Microservices and Serverless Computing

  • 14 May 2019

    Edge Services

  • 30 April 2019

    Kubernetes Design Principles Part 1

  • 09 April 2019

    Keeping Up With The Norm In An Era Of Software Defined Everything

  • 25 February 2019

    Infrastructure as Code with Terraform

  • 11 February 2019

    Distributed Agile – Closing the Gap Between the Product Owner and the Team

  • 28 January 2019

    Internet Scale Architecture