Question on emissions of development from SaaS

[ArneTR]

Hey Hey,

first of all I wanted to say thank you for the great work on the Technology Carbon Standard!

We have recently given it a spin drive internally and found it quite useful for getting a snapshot of our IT emissions.

Not sure if this is an "issue", but since you did not have the Discussion tab activated her on GitHub I thought I open an issue for now. Feel free to move it if you see it fit

Question
When listing down all of our cloud solutions we use I was wondering where to put the emissions from development of these software products.

Example: Amazon Cloudfront

It so far has to be listed under Operational Emissions (Indirect) with it's emissions from electricity but also the embodied carbon. But surely Amazon has also developed this software. Where is that filled in?

We currently put that in the category Upstream Emissions - Off the shelf software and Open Source but the wording seems to exclude SaaS products atm. Is that the intention?

[jcamilleri-scottlogic]

Hi Arne - apologies for the delayed response.

With regards to the embodied carbon of cloud services, we include it in Category C, under Operational Emissions.
From a GHG perspective, regardless of the TCS category, it falls under scope 3. If it were under Upstream Emissions (cat U), you are taking full responsibility for the embodied carbon. Our feeling is that you are only responsible for a portion of the embodied carbon whilst you are using the service. So, we currently use the CCF methodology (which includes some embodied carbon) until we can find a better alternative and account for it under Category C as an indirect, operational emission.

[ArneTR]

I feel my question was not accurate enough. Let me retry :)

When you say "embodied carbon" do you then mean the development cost, or the manufacturing cost for the hardware the services are running on?

I mean the development+testing+release etc. cost of the software in particular. for off-the-shelf software you include it in category U. But how do you handle that for cloud software?

Also: Why can I not pro-rate carbon that is in category U? Would that not happen for off-the-shelf software also? Assuming I buy Microsoft Windows. Not all the cost for "during programming, testing and releasing" which you mention in https://www.techcarbonstandard.org/impact-categories/upstream#software will be fully attributed to me. Only my share, not?

And finally: How do you estimate the cost for development+testing+release etc. for off-the-shelf and cloud software at all? So far I have not seen a single source mentioning any number on this data. Do you maybe have some references that I could read up on?

[jcamilleri-scottlogic]

Hi Arne,

I'll see if I can answer...

"When you say "embodied carbon" do you then mean the development cost, or the manufacturing cost for the hardware the services are running on?"

We've had some internal debate about this definition. Initially, when we were writing the TCS, we were considering the development cost of the software as "embodied carbon" as well as the manufacturing cost of the hardware. Some of the feedback we've had suggests that we folded too much into the term and stretched it a little. Our intention is to update the standard to break out development costs into their own term, but haven't settled on a good name yet - ideas welcome!

"I mean the development+testing+release etc. cost of the software in particular. for off-the-shelf software you include it in category U. But how do you handle that for cloud software?"

So, as I say, we've been including some overhead for embodied carbon in Category C, using the same method as the CCF Tool and Cloud Jewels Methodology as a starting point. However, the data there is getting a bit old and we recognise that further research is needed here to get more realistic estimates.

"Also: Why can I not pro-rate carbon that is in category U? Would that not happen for off-the-shelf software also? Assuming I buy Microsoft Windows. Not all the cost for "during programming, testing and releasing" which you mention in https://www.techcarbonstandard.org/impact-categories/upstream#software will be fully attributed to me. Only my share, not?"

I totally agree - this is something we need to expand the guidance on. We put it in as something of a placeholder - we recognise that it needs to be considered but we are still exploring the question of how to measure or estimate it in the absence of data from the upstream supplier.

It is also worth noting that the TCS is looking at the organisation's operations and direct supply chain, so regarding the Cloud software, the upstream emissions of developing that cloud software would be accountable by the cloud vendor and not the organisation in question.

"And finally: How do you estimate the cost for development+testing+release etc. for off-the-shelf and cloud software at all? So far I have not seen a single source mentioning any number on this data. Do you maybe have some references that I could read up on?"

Again, this is a bit of a placeholder - there is a clear need for it within the framework, but no clear way to perform the measurement or estimate. We would welcome any ideas, feedback, suggestions or contributions in this area.

[ArneTR]

Nice to hear that even for you there are still some unresolved ambiguities ... I guess this is the nature of all GHG carbon accounting anyway :)

In any case: I belive it makes sense to segment out embodied carbon as the true cost of manufacturing vs. development cost and other "lifecycle stages" from the upstream. Mostly because typically there will be no data available for anything else than manufacturing apart from very few cases.
And to have it segmented out makes it clearer what is missing and what is not. Especially for people that actually have the data and then have to sum it up under one category which makes it "false high".

2. Regarding the possbile phases, we have an academic publication on this where we map the phases from software to lifecycle stages (Only abstract published: https://dl.gi.de/items/442b63a4-8006-40c9-bcbe-378862f61de8)
   But effectively the mapping is as follows:

3. Yeah, getting data for the upstream of software is super hard. Actually I have not seen any numbers in the wild that can really be used.
   I can share how we work wth the TCS with clients: What we do is we first fill all the categories from the TCS and then "in reverse" we conclude how much carbon they have used to develop their software product and break it down on a "per client" number. This is what we then use in the upstream for the products they use.
   This number is of course not as good as getting a number from say Microsoft Windows directly, but it at least gives a reasonable estimate that is not totally un-based.

[ArneTR]

Also: We have created a quite comprehensive Excel Sheet with the TCS. Is there any interest to have that shared? I guess it makes it even easier for companies to work with the TCS ....