Chapter 12 - The Green Software Maturity Matrix

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:


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


<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:


(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: 


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”):


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”):


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

Level 4

At level 4 (“Awesome”):


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: 


<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:


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! 



Buy the Book

Buy Building Green Software on Amazon or at any good bookstore