Practicality in SCER

[seanmcilroy29]

From Charlene Wong (IMDA)

• We are measuring “greener” rather than “green” here.
• There are challenges for us when trying to use the ratings and like to understand what approach would provide a better proxy info for the scenarios below?
  • Infra Environment – moving from on-prem to cloud, the SCI core would be vastly different compared to cloud to cloud green interventions.
  • Unit of Software Function – if a software require operations from AI to IoT, one execution would use several software components.
• The trials we are conducting are more enterprise solutions example financial pricing tool, remote inspection tool etc. How would they be categorized?

[chrisxie-fw]

These are great questions. This could be one of the use cases for SCER specification. SCER defines the framework, or guidelines, if you will, for rating the carbon efficiencies of software. SCI focuses on the "benchmarking" side of the SCER, while SCER as a whole handles the full lifecycle of the "greenness" assessment of software. The end result of applying SCER spec is the rating label, or some kind of "energy star" rating and labelling for software.

In the use case that Charlene mentioned, the definitions for each step of the SCER spec could be:

1. Categorization: the service (whatever services that are to be migrated from onprem to cloud)
2. Benchmarking: SCI scores of onprem and cloud
3. Rating: may apply simple percentile algorithms to compute from grade letters such as A, B, C, D, etc
4. Labelling: could simply be the result of the rating in letters, or number of stars, whichever your organization prefers to use to make it easy for people to intuitively recognize and understand its carbon efficiency ratings.

The above 4 steps constitutes the SCER standard specification for your specific use case, and you can apply the same standard/measuring/rating guidelines to other instances of similar service offerings whose carbon efficiencies are to be assessed.