Your SCI score is composed of other SCI scores

[jawache]

Some components in your software boundary will be components you manage, for these you will need to calculate an SCI score from the ground up, quantifying E, I and M.

Some components in your software boundary will be components managed by others and provided as a service. These may either have calculated and published their own SCI scores which you can simply add into your own aggregate SCI score. Or the SCI Data project may have calculated a generalised SCI score for that type of service, e.g. networking.

For example say your software boundary is:

• Servers which you manage.
• Database managed by another organisation which has calculated and published an SCI score of 2.3 g/MB stored.
• Networking managed by others for which the SCI Data project has published a generalised score of 10g/GB transferred.

You applications total SCI score will be the sum of

1. SCI score of your servers.
2. SCI score of your database.
3. SCI score of you networking.

• For (1) you quantify the SCI score from the ground up by quantifying the E, I and M
• For (2) + (3) you leverage previously calculated SCI score and just translate them to this SCI scores R.

Let's say the R is User and we have modelled that a single User stored 20MB of data and transfers 2GB of data.

1. SERVER SCI = (E + I) + M per User
2. DATABASE SCI = (2.3 * 20)g per User
3. NETWORKING SCI = (10 * 2)g per User

(2) + (3) are just scaled so the denominator, the R, is the same across all. That way all the components can be summed up into one total.

Eventually, in the far future, every service will have an SCI score all published to the GSF via the SCI Reporting project. So theoretically calculating your applications SCI score will become easier and easier as more and more of it's dependant components will have calculated their own SCI score which you can leverage.

[Sealjay]

I think in future, we might need to recommend R units for different services - I can see otherwise it might make it difficult to compare different reported scores

[Sealjay]

I think this pull request is still waiting- https://github.com/Green-Software-Foundation/Dictionary/pull/2 - but I've always envisaged your SCI score as having been composed of other scores.

Some of the dictionary items I proposed were:

Term	Definition
Ability to Act	The possession of means or skills by an agent has to take an action, which may vary depending on technical aptitude, influence over the software development lifecycle, or control over the hardware selection process.
Activity	The operations being instrumented or measured in order to quantify the total carbon emissions of software within the SCI specification.

I think @ElmarBorgmeier has already covered this in detail, so rather than being duplicative, I will only confirm I agree; and also add that you will probably need to simulate or use different scenarios in order to identify some SCI scores. For example, a lot of our scenarios like websites, etc, are relatively easy to measure. One page load = one unit. But what about interactive calling applications? The SCI would differ greatly if you spend your day in video calls, versus in messaging.

Maybe you consider an application like a state machine, and measure the SCI for each individual state

[atg-abhishek]

I really like the framing as a state machine @Sealjay , would love for you to expand that on the call this week!

[Henry-WattTime]

Working Group:

Do functional units scale the same for all services? -HDR

Might get a managed database score in functional units of GB
Need to translate that into the functional unit you are using

Can aggregate scores into your score.

Common lifecycle scoring approach - Elmar
Every LCA tends to do this
Show this works for SCI as well

Can leverage other scores for higher

SDIA - digital infrastructure alliance
Project to make lower level services to make API to share energy consumption
-report electricity consumption upward (i.e. to kubernetes)
-Virtual machine above container above hardware. Aggregate upwards
-Project is in infancy, needs cooperation from different providers.

Future versions of SCI will must report specific functional units. Otherwise not comparable.
Specific 'ontology' for specific applications.

If application use specific resources, must include certain things.

People dropping parts of the SCI score
Tooling may help improve

[ElmarBorgmeier]

The database example highlights the risks of this approach:
Suboptimal SQL-statements and missing DB-indexes (indices?) can seriously increase CPU-usage on the database server. Checking these two items should probably be on the top of your todo list when you look for potential improvements for the system.

We can probably fix this by addtionally factoring in query execution.
So, the amount of data used on the DB server might give you a value for M to be included.
The execution time for your SQL statements would give you a value for E to be included.
Based on these two values, you can calculate a "sub-sci for the DB and its interaction with the application" to be included in the overall SCI.

In a nutshell: When composing an SCI from the SCIs of subsystems, inefficiencies in the interfaces between these subsystem are easily lost.

"The whole ist (sometimes) greater than the sum of its parts."

[ElmarBorgmeier]

My previous comment nonwithstanding, I definitively believe that we need to use decomposition and aggregation approaches. Even on different levels:

• aggregating the overall SCI from sub-SCIs for services that are being called. (Fo example any remote webservice you include. Or: for Internet data transfer)
• aggregating M from the different hardware components involved.
• decompositing the impacts that different libraries etc. have on the SCI. This is important to understand where your inefficiencies are hidden. For example, moving from Spring to Go will probably have a way larger impact on the SCI than optimizing the code your wrote yourself on top of these. In most cases, at least.

This kind of composition is common when emissions are to be calculated. I mean, you can never really get to the bottom of things. For example, we will select a value for I and that's it. We don't go into the details of how this has been calculated from the actual emissions from powerplants and the power grid. Nobody expects us to.

The same can be done with other values. If a web-service publishes an SCI per call, than we can use this value as a base value and don't dig into it any further.

Eventually, we will have an inventory of such SCIs that can be used. Same as with LCA: There, you have LCIs (Life Cycle Inventories) made up of items to which an emission value has been assigned (or "attributed").

[atg-abhishek]

For example, moving from Spring to Go will probably have a way larger impact on the SCI than optimizing the code your wrote yourself on top of these. In most cases, at least.

This comment also sparked for me something else: to what extent should the developers be nudged towards considering existing implementations that are optimized for the task at hand (but which may require integration costs) vs. trying to roll their own? We see this happen quite a few times when available solutions aren't exactly tailored to meet the needs and developers can embark on creating something from scratch which may not have all the efficiencies that come from a set of tools / software that has been developed over time by a team that has experience in optimizing it all the way to the nuts and bolts.

The only thing in that case then we would have to consider if we will be able to get the SCI score for that piece of software (say if it is being executed somewhere in a remote environment and called via an API) and what might be the best ways to integrate that to minimize SCI score (such as local caching results of common queries, etc.).

[Henry-WattTime]

When I was helping @tmcclell with the case study she was working on for the WTF, we found that the time variable was also really important, otherwise it didn't make sense. Like, this service for a year requires this much energy. The service alone was not sufficient. I think this relates to the 'score of scores' because the time duration between them must be normalized as well.

[Sealjay]

Are there ways you could bake that in, via API call, or page load? Or does it not work, because the server is constantly running even when the website isn't being opened

[Henry-WattTime]

It's a sensor array that is always running to track growing conditions. I wasn't sure how to slice that.

Storage/accessed data might have the same problem? Per database year might be important?

[Henry-WattTime]

WG: once we have conducted the case studies, we add a sentence describing how scores can be aggregated from other scores. On hold.

[atg-abhishek]

@Henry-WattTime don't we kinda already say that under "Quantify" here?

Quantify: Calculate a rate, an SCI value, for every software component. The SCI value of the whole application is the sum of the SCI values for every software component in the system.