When Software Heats Up the Planet

What we develop – and how we develop it – has a tremendous impact on the energy consumption of IT systems. Software archi­tects can provide meaningful impulses toward greater energy efficiency through delib­erate design decisions. While function­ality, cost, and time have tradi­tionally been the primary criteria when evalu­ating systems in operation, the climate impact criterion is becoming increas­ingly important. This article explores how climate protection and software architecture can be meaning­fully connected.

How Software Architecture Can Reduce the CO₂ Footprint

The climate crisis is a pressing issue. The IT industry signif­i­cantly contributes to global CO₂ emissions: various studies [1] yield different results, but estimates for 2020 range from 2.1% to 3.9% of global CO₂ emissions attributed to data centers. Research also suggests that energy consumption will continue to rise, driven primarily by increasing digiti­zation and artificial intel­li­gence. As a result, the project management triangle for software devel­opment is evolving to include a new constraint: in Climate—alongside in Budget, in Time, and in Function­ality.

Figure 1: Estimated share of ICT in global CO₂ emissions. Based on [2]

The Role of Software Architects

With their expertise and experience, software archi­tects bear a signif­icant respon­si­bility – one that goes well beyond the tradi­tional requirements of software architecture. The following areas are crucial to reducing CO₂ emissions in IT projects:

Requirements:
Not every functional requirement is strictly necessary – some are even disputed among stake­holders. Repri­or­i­tizing or rejecting requirements based on sustain­ability and avail­ability consid­er­a­tions is one way to improve energy efficiency. It’s easy to let services run contin­u­ously or deploy them across multiple cloud regions to ensure low response times. But is this truly necessary? Do all services need to be available 24/7 and worldwide? By identi­fying actual usage needs and adjusting active services accord­ingly, signif­icant energy savings can be achieved.

Architecture/Implementation:
Software can be imple­mented in energy-efficient or ineffi­cient ways. Architectural and design decisions directly affect energy efficiency. The goal is to find a solution that satisfies quality requirements while minimizing CO₂ emissions.

Architectural styles also play a role. Microser­vices have clear advan­tages, such as enabling horizontal scala­bility – but is this always needed? In many cases, a more energy-efficient modulith (modular monolith) might be better suited to the same requirements. Can we combine both styles and only use microser­vices where scala­bility is truly necessary?

Opera­tions:
Even software designed with energy efficiency in mind can lose its benefits during operation. Examples of sustainable opera­tions include: maximizing hardware utilization, limiting operating hours, deploying in regions with high shares of renewable energy in the power grid, and shutting down unnec­essary services.

Redun­dancy:
Redundant services with high avail­ability requirements consume additional resources, which increases energy demand. Instead, small services that can be restarted quickly offer a viable alter­native – providing compa­rable behavior with far less resource consumption.

Energy Efficiency as a Quality Attribute

Energy efficiency is an emerging quality that must be balanced with other system charac­ter­istics. Figure 2 illus­trates how scala­bility-related architectural decisions can influence this balance. [3]

Figure 2: Possible architectural decisions for scalability

You Can’t Manage What You Don’t Measure

All the afore­men­tioned fields require the expertise of software archi­tects. But to make informed decisions, we need reliable data. Measuring and monitoring CO₂ emissions is essential – without it, any form of optimization becomes questionable.

However, accurately measuring a software system’s actual emissions is difficult or even impos­sible, as emissions depend on many factors, such as: local electricity mix, time of day, or even the weather.

That’s why proxy metrics are often used – indicators that correlate with CO₂ emissions. Examples include system energy consumption or cost (e.g., in cloud environ­ments, lower resource usage typically leads to lower costs). Under­standing and using tools provided by cloud providers to monitor one’s own systems must become a core compe­tency for software archi­tects – as well as using tools to measure workload energy [4] consumption or estimate CO₂ emission efficiency [5].

Software Archi­tects as Multi­pliers for Green IT

Because of their central role, software archi­tects act as multi­pliers within projects and organi­za­tions. They can bring Green IT into the spotlight and inspire everyone involved to develop and operate energy-efficient and low-carbon software.

The climate crisis won’t wait: it’s up to us, the software archi­tects, to make in Climate a standard requirement.

Sources:

[1] Roussilhe: Explaining the environ­mental footprint of the digital sector, https://gauthierroussilhe.com/en/articles/explaining-the-environmental-footprint-of-the-digital-sector, 2021
[2] Belkhir, Elmeligi: Assessing ICT global emissions footprint: Trends to 2040 & recom­men­da­tions, Journal of Cleaner Production, Volume 177, March 10, 2018, Pages 448–463
[3] Wanner, Kutschera: CO2-Emissions-Effizienz trifft auf Qualitätsmodell, ITSpektrum 5/2024
[4] Kuber­netes Efficient Power Level Exporter (Kepler), https://sustainable-computing.io/
[5] Cloud Carbon Footprint, https://www.cloudcarbonfootprint.org/

Author
Prof. Dr.-Ing. Gerhard Wanner (wanner@hft-stuttgart.de) has over 30 years of experience as a consultant and software architect, and more than 20 years as a professor of computer science at HFT Stuttgart, focusing on software engineering and architecture. Green IT is his passion – in research, as an author, and in teaching.