Building Green Software from O'Reilly is available here under a CC BY-NC-ND Creative Commons license i.e. you can read it and quote it for non commercial purposes as long as you attribute the source (O'Reilly's book) and don't use it to produce derivative works.

We will be releasing one chapter a month, accompanied by a public book club discussion by the authors (links to the book club and recordings below).

You can buy the book from good bookstores including Amazon in all regions (currently on offer in the UK). or read it on the O'Reilly site if you are an O'Reilly subscriber.

The Green Software Maturity Matrix

"I can only show you the door, you're the one that has to walk through it" – Morpheus

What is it?

The Green Software Maturity Matrix (GSMM) is a self-assessment tool from the Linux Foundation’s Green Software Foundation. 

The GSMM is designed to help organizations understand how well they’ve already implemented green principles and processes and what to do next.  It is part of the GSF’s campaign of raising the floor and the ceiling - lifting the behavior of the laggards on green tech and inspiring those doing okay to achieve more by showing what the leaders are up to. 

Its intent is to give directions to a trodden path so we get the decisive benefit of shared progress on tools and services.

<Sidebar>Anyone can comment on or contribute to the project on GitHub. You don’t need to be a GSF member. Anne is the project lead and she would be very happy to see you.</Sidebar> 

<Sidebar>Note that the GSMM is focussed on how, as part of their day-to-day working lives, software practitioners can reduce greenhouse gas emissions. It does not cover water use in DCs, species protection, or any other worthy environmental aim. As we currently understand it, those aims are mostly dictated by data center choice and developers have little scope to improve on that choice later, particularly iteratively. So, decide on your DC wisely.</Sidebar>

The history of maturity matrices

Way back in 1986, when Anne was still wearing fluorescent leg warmers and Sara and Sarah weren’t born, the first maturity matrix (sometimes called a maturity model), the Capability Maturity Model Integration (CMMI), was developed by the Software Engineering Institute (SEI) at Carnegie Mellon University. It was designed as a framework for assessing and guiding organizations' efforts at process improvement.

Maturity matrices are now used in a wide variety of fields including project management and cybersecurity to let companies assess where they stand in terms of best practice. They also point out the practical steps those organizations can take to achieve higher levels of performance. 

A maturity matrix usually has 5 levels. The aim is for an organization to adopt better processes and tools to ascend from level 1 to 5:

• Level 1: Initial - Processes are unpredictable, poorly controlled, and reactive at best.

• Level 2: Reactively Managed - Per-project processes. Often still reactive.

• Level 3: Defined - Processes are standardized, documented, well understood, and reviewed.

• Level 4: Quantitatively Managed - Processes are measured and controlled.

• Level 5: Optimizing - Continuous improvement occurs based on quantitative feedback.

We’ll go through the details of how these levels relate to green software next, but we reckon this broadly means:

• Level 1: You are floundering with no organization level strategy. You have individuals who care or are knowledgeable about being green.

• Level 2: You are starting to get some handle on stuff but without consistency. How advanced you are varies by project and team. You have the bare minimum of emissions data.

• Level 3: You are good. You have basic organization-wide knowledge and decent retrospective data. You have defined processes, which are applied across your organization. You are already acting successfully on green improvements that don’t need great data.

• Level 4: You are awesome. You can measure your progress dynamically (i.e. you have got your hands on real-time data).

• Level 5: You have ascended to the next plane of existence. You monitor and improve emissions performance based on real-time data. You give aspirational talks at tech conferences and what people are aspiring to is what you have been doing for ages. You are the tech equivalent of a being of pure energy. Think Yoda with a keyboard. 

<Sidebar>The audience for the Green Software Foundation’s Maturity Matrix is senior folk in tech organizations and internal green advocates. The aim is guiding their high-level journey and giving them something to report progress against. 

Consultants also tend to like a maturity matrix because it helps them explain to clients the service they’re offering and what good looks like. That makes it easier to persuade those clients to invest time and effort in a project because they know they’ll be able to assess progress (and prove it isn't just greenwashing). That’s good. We want more folk offering professional services in green software.</Sidebar>

Green Software Maturity Matrix

Before we start discussing the details of the GSMM, we need to talk about the good news.

Fortunately, you don’t need to wait for great data to start being greener and move up the maturity levels from 1: Aspiring (where almost all of us are right now) to 2: Acting. That’s lucky because, as we discuss in chapter 9, measuring your greenhouse gas emissions is not yet straightforward. The tools are still evolving.

At levels 1 and 2 of the GSMM there is effective stuff you can do immediately. The author of our foreword, Adrian Cockcroft, pointed out to us that the ubiquitous quote, “You can’t improve what you can’t measure” (often attributed to the management guru Peter Drucker) isn’t true in the case of being green. 

There are well-understood actions with guaranteed payoffs in carbon reduction, which everyone can start taking. For example:

• turning off no longer utilized machines (aka “zombies”) and doing manual rightsizing,

• choosing a hosting location with a greener grid,

• moving some workloads to the cloud and using the services there, or otherwise investigating how you might leverage multi-tenancy,

• improving your ops skills, for example by starting to learn about GitOps or SRE principles.

(Almost) anything you do to cut your hosting bill will cut your emissions, so use that as an initial proxy measurement. You could get started today! 

Levels

Let’s look in more detail at the levels of the Green Software Maturity Matrix v1.0.

<Sidebar>We cover these measurement terms in more depth in chapter 9.</Sidebar>

Level 1

At level 1 of the matrix (“Aspiring”) you have: 

• Individuals in your organization who care about green targets for technology but no organization-wide interest, processes, or commitments.

• Some development teams may measure their carbon emissions but you don’t know the overall tech-derived carbon footprint of your company, even periodically (not even annual numbers, for example).

• You have no carbon zero targets or green software strategy (or you have wooly carbon zero targets like “Net Zero by 2050” with no plan behind them. That is, unfortunately, not a strategy).

Realistically, this is where most of us are today. Don’t feel bad if it’s you. It means there are a lot of improvements you can make without that much effort.

Level 2

At level 2 (“Aware”):

• You know your tech organization’s scope 1 and 2 emissions, perhaps weekly, monthly or annually.

• You have a few projects driving carbon reduction within your tech organization. Maybe using the data you have but not necessarily. 

• Your engineers have had some training in green systems and operations. 

• You are doing the “no brainer” stuff we mentioned in the Operational Efficiency chapter like manually turning off zombie services that are no longer in use or rightsizing, or switching what functionality you can to spot instances.

Five years ago, you would have just offset your scope 1 and 2 emissions, labeled your IT systems as carbon neutral, and sent out a self-congratulatory press release. Nowadays, this is only stage 2 of 5 because our expectations have risen - offsets are seen as of limited value and carbon neutral is fine but nowhere near enough. 

Nonetheless, if you are here, you are doing okay. Most folk are not.

<Sidebar>”Carbon neutral” was what you used to call yourself if you had bought stuff that could be argued to offset your own carbon emissions. Offsets were things like trees being planted or new renewable power plants being supported. Nowadays, offsetting isn’t considered to be that useful because renewables are booming without help and new trees don’t store carbon for long enough to make much difference. However, it does show you are measuring your direct emissions and in the past being an early customer for renewables was very effective.</Sidebar>

Level 3

At level 3 (“Acting”):

• You know your scope 1, 2, and 3 emissions on a daily, weekly, monthly or annual basis. 

• You know your embodied carbon.

• You have been acting on reducing your scope 1 and 2 emissions for a while and your carbon footprint is going down per some consistent org-specific unit of output - e.g per order. 

• You have defined processes for every team including regular reporting and reviewing of CO2 equivalent emissions for all IT related operations. 

• Your product management teams have a remit to avoid waste, for example by not saving more data than is necessary and not implementing functionality before need (aka a lean mindset). 

• You can easily switch off zombie or low use services whenever you like (i.e you support “LightSwitchOps”). 

• You are aware of the potential tradeoffs between carbon emissions from electricity and embodied carbon and have plans in place to minimize your embodied carbon footprint, including significantly extending the life expectancy of both the servers and end user devices you run on.

Level 3 is good. If you are already here you are well ahead of the crowd.

Level 4

At level 4 (“Awesome”):

• Your organizational tech strategy has been aligned with being green as a business goal - perhaps for reasons of ESG, cost, resilience, or market access to the EU - and delivery on emission targets is regularly discussed and reported at senior level. 

• Using the basic scope 1, 2, and 3 data you have had for a while, you have already achieved net carbon zero using no more than 10% offsets. (Most offsets are problematic but some are OK and long term carbon capture and storage is necessary). 

• You have some form of measurement system in place and have good real-time scope 1, 2, and 3 data and, although it’s not currently driving the business day-to-day, the business is aware of it. 

• You perform demand shaping; pre-calculation and caching; or time and location shifting, for example, to adapt your workloads to current conditions. 

• You automatically delete or archive data that isn’t in regular use. 

• Services no longer in use are automatically turned off and rightsizing happens automatically (i.e. you apply SRE principles). 

• Your applications are lean and you constantly review and retire functionality that is insufficiently used. 

• Your total IT carbon footprint is going down even as you grow. 

• You never cause hardware less than ten years old to become end of life either by lack of security patches or lack of backwards compatibility in your applications. 

• You are actively driving the carbon footprint of your customers to go down (beyond simply their use of your services and devices) for example by providing scope 3 reporting for your goods and services.

Level 4 is well beyond what most enterprises are doing right now and there are no commodity services that provide all the functionality required (not even spot instances provide 24/7 carbon-based demand shifting yet). So, for enterprises it is too soon. AWS, Azure and Google are only here on some axes.

Level 5

At level 5 (“Inspirational”) you’ve got there: 

• You have achieved 24/7 Carbon Free Electricity (24/7 CFE) and require no more than 1% offsets to handle hard to shift embodied carbon. 

• You have team level goals for your carbon measurements. 

• You and the services you rely on use real-time information including dynamic grid energy data to make rapid, quantitative decisions that allow you to optimize for minimal emissions. This could (and probably will) be via a service you use rather than something you built yourself. The data complies with an open standard so meaningful comparisons can be made.

• You are already an SRE-aware organization that thinks in terms of error budgets for outages and downtime and you now think about carbon emissions having error budgets in the same way as other metrics.

• Using predictions based on factors such as weather and grid congestion, you change and move almost all of your workloads ahead of time to match your electricity requirements to local green power availability and any time sensitive workloads are highly optimized for minimal electricity use. 

• You never cause hardware to become end of life either by lack of security patches for your software or lack of backwards compatibility. 

<Sidebar>24/7 CFE is a term used to describe when you are only drawing power from the grid when, at the same time, there is enough carbon-free electricity being fed into that grid to cover your use.</Sidebar>

At this stage, you are ready for the energy transition and won’t be caught by surprise by new rules or constraints. More rigorous expectations beyond 24/7 CFE will almost certainly be introduced in the future (we don’t know what they will look like yet!) but you will be ready for them.

Axes

In practical terms, no business is going to be at the same level across the entire tech organization (except maybe level 1!) Green software maturity will vary team by team. It is therefore useful to break everything down into areas (axes) and define maturity checklists for each:

• Climate commitments.

• Carbon footprint.

• CO2 equivalent metrics.

• Operational efficiency.

• Electricity use.

• End user devices.

• Servers.

• Product management.

• Education.

Responsibility for each of these areas will probably sit with different groups or teams and how green they are may differ wildly (at least, to start with). An organization might be level 2 on some of these axes and level 1, 3, or 4 on others. 

Checklists

Climate commitments:

Level 1: by 2050, net Carbon Zero.

Level 2: by 2040, net Carbon Zero for scope 1, 2, and 3 (note you may already be “carbon neutral” for your scope 1 and 2 emissions).

Level 3: already net Carbon Zero with offsets.

Level 4: already net Carbon Zero with no more than 10% offsets.

Level 5: already 24/7 CFE with no more than 1% offsets, monitored by a carbon error budget.

Carbon footprint:

Level 1: you don’t know what it is.

Level 2: you know what it is (for scope 1 and 2).

Level 3: you know what it is (for scope 1, 2 and 3) and it is reducing per defined unit of output, e.g. orders.

Level 4: it is reducing full stop and so is that of your suppliers.

Level 5: it is close to zero.

CO2 equivalent metrics:

Level 1: no metrics.

Level 2: annual, quarterly or monthly numbers from all suppliers and own systems for scope 1 and 2.

Level 3: regular numbers from all suppliers and your own systems for scope 1, 2, and 3.

Level 4: real time through an industry-standard open API.

Level 5: real time through open APIs together with projections.

Operational efficiency:

Level 1: no rightsizing takes place and you have zero knowledge about unused ”zombie” systems.

Level 2: occasional spring cleans happen where you manually turn off idle or low value systems, rightsize machines, and delete/archive unneeded data.

Level 3: all systems can be safely and automatically switched off (aka LightSwitchOps) and there are regular processes for doing so. You have knowledge of what is running on all your machines and there are never zombie services. Processes exist for regular rightsizing. You save no unnecessary data and it is maintained in the optimal medium (e.g. tape if the data is not required for real time queries).

Level 4: continuous monitoring of climate metrics. All turning off and rightsizing happens automatically (perhaps through services like burstable instances) and data that is not regularly accessed is automatically deleted or archived.

Level 5: you have a rigorous carbon error budget including for your scope 3 embodied carbon and all your resource use is tracked and managed against it. 

Electricity use:

Level 1: your systems are always on and you don’t think about electricity.

Level 2: you host in green regions or buy renewable energy.

Level 3: at least part of your systems are dynamically managed based on green electricity availability (either via direct orchestration or through a service).

Level 4: all your systems support demand shifting and shaping based on energy data.

Level 5: you run 24/7 CFE with a rigorous carbon error budget.

End user devices:

Level 1: you have no end user device longevity targets.

Level 2: some adhoc targets are in place for device longevity.

Level 3: you have defined processes in place that ensure ten year old hardware is supported by your software for most commonly used devices (90%+).

Level 4: automated processes ensure ten year old hardware is supported by your software for 95% of devices.

Level 5: automated processes ensure backwards compatibility, and security patches are available for all devices (i.e. your software never kills a working device). You support devices that last forever al la the Ship of Theseus (this is a potential future requirement for goods imported into the EU).

<Sidebar>The Ship of Theseus is the subject of a famous classical thought experiment about whether an object that has had all of its components replaced remains fundamentally the same object. Philosophy aside, continuous maintenance and repair is a way to minimize waste and thus embodied carbon. We need to treat devices like something precious and worth preserving - Theseus’s ship - not something meaningless and throwaway.</Sidebar>. 

Servers:

Level 1: you have no server utilization targets.

Level 2: some of your systems are using multi-tenancy of some form to improve utilization.

Level 3: you have defined and tracked utilization targets. All your systems use some form of multi-tenancy and any servers you run on have a 5 year life expectancy.

Level 4: optimal utilization is achieved for every server using automated, programmatic orchestration. The servers you use all have a 10 year life expectancy. 

Level 5: hardware use is minimized by using full grid-aware integration with end user devices including phones, laptops, smart clothing, fridges, etc.

Product management:

Level 1: your PM teams are not carbon aware.

Level 2: carbon awareness is part of your product design.

Level 3: all new product design supports demand shifting/shaping and lean concepts are followed. Your end user devices prompt for green/off peak charging and no more data is saved than necessary.

Level 4: carbon emissions are tracked per feature. Feature use is monitored and low use/poor carbon ROI features are retired.

Level 5: your features are tracked against your scope 1/2/3 carbon error budget. 

Education:

Level 1: all your green tech training is ad-hoc, driven by the individual.

Level 2: basic training in green software concepts is available for all software practitioners. Champions are given more advanced training.

Level 3: advanced training is mandatory for all your engineers & PMs.

Level 4: only basic training is needed for most because everything is green by default in your platforms.

Level 5: you train others in what you have achieved.

Where are we today?

The hard truth is almost all of us are at level 1 on the Green Software Maturity Matrix right now and we need to move up.

However, that means the biggest wins are directly in front of us. Low hanging fruit that gets us from level 1 to 2, like turning off unused servers, could immediately cut greenhouse gas emissions in half, whilst saving you money and making your systems more secure. 

So, let’s get cracking!