Methodology

[seanmcilroy29]

The Methodology Itself submitted by Ben Logan [UBS]

I wonder whether the current approach to embodied emissions weighs too heavily on legacy apps? Could we potentially be encouraging/rewarding a hardware migration that might appear to reduce embodied emissions, but results in redundant hardware that was otherwise doing an OK job and becomes scrap (I guess hardware recycling is assumed)? Let me rephrase – are we including embodied emissions over the lifetime of an application?

So, for example;
Today you have embodied emission of 100gCO2eq resulting from the use of some physical hardware that is a few years old.
You purchase new hardware that has embodied emissions of 50gCO2eq – this significantly drives down your score (point in time).
Great news – but you’ve unnecessarily retired hardware and so you have net positive embodied emissions over the lifetime of the app. The new hardware is not significantly more energy efficient than the old, so the introduction of it has not lowered your E (energy consumed). i.e. you are actually in a worse place than you started, but your score has lowered?

Am I making sense? Might be easier to talk this one through. I might well be missing something obvious!

The other thing that I’m a little worried about is the choice of R.

Are we making it too easy for people to pick an R that results in a lower score. I guess we have to assume some integrity on the part of the user! Might be worth a mention in the spec?
Perhaps also worth adding something like this;
You MUST use a consistent choice of R across all applications, if you intend to use the SCI score for comparison, for example when evaluating different vendor solutions.

One final thing - I know we are adding use cases and I think these will really help. I think the introduction of a basic ‘working example’ inline in the spec itself, would also greatly help with readability and understanding? Something like this;
Working Example

The average server will consume between 500 and 1000watts an hour. If the average use is 850 watts per hour, multiplied by 24 that equals 20,400 watts daily, or 20.4 kilowatts (kWh).
For the sake of argument, let’s assume that your ‘functional unit of work’ is the execution of code (e.g. report generation) that takes 24 hours and utilises 100% of the CPU.

So, E = 20.4 kWh

Let’s assume the server is running in the UK, where the average carbon intensity of the grid is 261

So, I = 261 gCO2eq/kWh

Let’s assume you are running on a dedicated physical server, a Dell PowerEdge R710 rack server. Dell suggest that about 90% of the footprint of that server is from use, so let’s use 10% of their stat to account for manufacturing and disposal/recycling. Embodied emissions would be 636 kg CO2eq. To keep things simple, let’s just assume that this server is used exclusively for this app, always has been and always will be.

So, M = 636000 g CO2eq

Our Functional Unit is Data Volume. Let’s assume it is processing 1TB of data in the 24 period and to process more, if the app scaled, would naturally take longer.

Our SCI = (20.4 * 261) + 636000 per 1TB

SCI = 641324 (per 1TB)

I have to say, I found this a little tricky to work through first time and I’ve probably made a few mistakes!? I think it’s definitely worth us including a small inline example like this, to help people out?

Just coming back to my earlier concern with M/embodied. I shouldn’t be able to introduce new kit and dramatically lower my score – so, technically M needs to include all historical hardware used during the lifetime of the app?

One other more small change;
C = O + M = Amount of carbon the software is emitting.
Should perhaps read;
C = O + M = Amount of carbon the software is emitting (and has emitted in the past or will emit in the future, resulting from hardware creation/disposal).

[Henry-WattTime]

WG: maybe this should become a 2.0/1.1 issue? Important issue to incentivize the right behavior.

Add statement to spec? Add to FAQ?
Include statement about why M is included in spec. And prevent bad practices like hardware churn.

Current Calc:
Pros:
-People will provision less hardware (on prem or cloud) (Asim)
-Incentivize prolonging life of hardware (Sara)

Cons:
-Accelerate hardware retirement by moving to lower embodied emissions hardware ("software driven hardware obsolescence) (Ben)