Sustainability Architecture Assessment: [Workload or system name]

Assessment of the environmental impact of a software system and of the architecture decisions that reduce it: boundary and functional unit, data sources, a Software Carbon Intensity (SCI) score with its operational and embodied parts, hotspots, levers (region and time shifting, demand shaping, efficiency, hardware lifetime, data), scenarios with recomputed scores, trade-offs with other qualities, targets, monitoring and decisions. The score follows the SCI method of ISO/IEC 21031:2024 (published from the Green Software Foundation SCI specification); levers are mapped to the AWS Well-Architected Sustainability pillar, the Azure Well-Architected sustainable workloads guidance and the Google Cloud Well-Architected Framework sustainability pillar; corporate reporting terms follow the GHG Protocol scopes. Replace every [bracketed] value and every row marked Example. The examples follow an order API running on eight dedicated servers.

Document control

Approvals

Revision history

Contents

1. Scope, boundary and functional unit
2. Method and data sources
3. Component inventory
4. SCI baseline calculation
5. Hotspot analysis
6. Provider framework mapping
7. Levers
8. Scenarios and recomputed scores
9. Trade-offs with other qualities
10. Targets and indicators
11. Monitoring and reporting
12. Decisions and action plan
13. Review checklist and traceability
14. Glossary and references

1. Scope, boundary and functional unit

1.1 Purpose and questions

[State why this assessment is done and which decisions it will inform.] Example: Compare three hosting options for the order API before the 2027 platform renewal, and set a carbon intensity target per order that the product team can track release by release.

Questions this assessment answers:

1. What is the carbon intensity of the workload per functional unit today?
2. Which components and which part (operational or embodied) dominate it?
3. Which architecture options reduce it, by how much, and at what cost to reliability, performance and spend?
4. Which target and which indicators will the team own?

1.2 Software boundary

1.3 Functional unit

2. Method and data sources

2.1 SCI method

The SCI score is a rate of carbon emissions per functional unit, not a total. ISO/IEC 21031:2024 and the Green Software Foundation SCI specification express it as:

SCI = ((E x I) + M) per R

E  energy consumed by the software in the boundary (kWh)
I  location-based carbon intensity of that energy (gCO2e per kWh)
M  embodied emissions of the hardware, apportioned to the software (gCO2e)
R  functional unit

M  = TE x (TiR / EL) x (RR / ToR)
TE total embodied emissions of the hardware
TiR time the hardware is reserved for the software in the period
EL expected lifespan of the hardware
RR resources reserved for the software (for example vCPUs)
ToR total resources of the hardware

The method has five steps, which this template follows: bound the system (section 1.2), choose the functional unit (section 1.3), choose a quantification method per component (section 3), quantify (section 4), and report the score with its boundary and method (section 11). The score is the sum of the scores of its components. Offsets, renewable energy certificates and other market-based instruments do not reduce an SCI score; the score can only fall by using less energy, using lower-carbon energy or using less hardware.

2.2 Relation to corporate reporting

Keep the SCI score for engineering decisions and leave the corporate inventory to the sustainability team; agree with them which factors both use. The GHG Protocol is revising its Scope 2 guidance (public consultation 2025 to 2026); check ghgprotocol.org for the current status before relying on market-based rules.

2.3 Factors and sources

3. Component inventory

Note: in the worked example below, CMP-02 and CMP-04 run on the eight servers of CMP-01, and CMP-03 and CMP-06 are in the 150 kWh storage and network figure; CMP-05 is shown separately in section 4.3 to illustrate apportioning on shared hardware.

4. SCI baseline calculation

4.1 Operational emissions (E x I)

4.2 Embodied emissions (M)

4.3 Apportioning on shared hardware

Example: The test environments (CMP-05) use 16 of 64 vCPUs on a shared host with TE of 1,500 kgCO2e and EL of 5 years (43,800 hours). For 720 hours: M = 1,500,000 x (720 / 43,800) x (16 / 64) = 6,164.38 gCO2e. Add their energy, apportioned by the same share, to E when they are in the boundary. The worked baseline below covers CMP-01 to CMP-04 and CMP-06 only, so that the arithmetic stays easy to follow.

4.4 Score

Consequences: [state what the numbers mean for the design.] Example: Operational emissions dominate, so region choice and right-sizing are the first levers; once the grid factor falls, embodied emissions will dominate and hardware lifetime and utilisation become the main levers (section 8).

5. Hotspot analysis

Working for the shares (Example): the eight servers emit 1,382.4 x 350 = 483,840 g operational plus 197,260.27 g embodied, that is 681,100.27 g or 92.8% of 733,600.27 g. Each server carries the same power and embodied factors, so each is 1/8 of that, about 11.6% of the score: the six API and database servers are about 69.6% and the two DR servers about 23.2%. Storage, network and logs together are 150 x 350 = 52,500 g, about 7.2%. Region carbon intensity (rank 3) is not a share: it scales the whole operational 73.1%.

6. Provider framework mapping

Provider tools to source data, where available: the AWS Customer Carbon Footprint Tool, Carbon optimization in Azure (Microsoft has announced that the Power BI Emissions Impact Dashboard for Azure retires on 31 March 2027, so export its history before then) and Google Cloud Carbon Footprint. Check each tool's current name and method page before use. Each uses its own method and boundary; record the method version and do not mix their outputs with your own factors in one score without saying so.

7. Levers

8. Scenarios and recomputed scores

Working for scenario A: E = 5 x 0.2 x 720 x 1.2 + 150 = 1,014.0 kWh; E x I = 1,014.0 x 350 = 354,900 g; M = 5 x 24,657.53 = 123,287.67 g; SCI = (354,900 + 123,287.67) / 45,000,000 = 10.63 mg per call. Scenario B keeps E and M and changes I: 1,014.0 x 50 = 50,700 g; SCI = 173,987.67 / 45,000,000 = 3.87 mg. Scenario C changes EL to 52,560 hours: M = 5 x 1,200,000 x 720 / 52,560 = 82,191.78 g; SCI = 132,891.78 / 45,000,000 = 2.95 mg.

Consequences: Example: After scenario B, embodied emissions are about 71% of the score (123,287.67 / 173,987.67), so further gains come from utilisation and hardware lifetime, not from more region changes. Moving to a managed or serverless service would transfer M to the provider's shared hardware at a higher utilisation; model it with the provider's data before deciding.

9. Trade-offs with other qualities

Cost and carbon usually move together (removing waste reduces both), but not always: a cheaper region can have a higher grid intensity, and commitments bought for three years can lock in oversized capacity. Review these levers together with FinOps Cost Review (ops/finops-cost-review).

10. Targets and indicators

11. Monitoring and reporting

12. Decisions and action plan

12.1 Decisions

12.2 Actions

13. Review checklist and traceability

13.1 Review checklist

• The boundary includes standby, non-production, CI/CD and observability, or states why not.
• The functional unit is the same in every scenario and in the baseline.
• Every factor has a value, a source, a date and a quality class.
• Location-based carbon intensity is used for I; no offsets or certificates reduce the score.
• Embodied emissions use the reserved time and reserved share of shared hardware.
• Every scenario shows absolute values for E x I, M and the score.
• Each accepted lever has a trade-off row signed off by the owner of the affected quality.
• Targets cover both intensity and absolute emissions, with owners and dates.
• Recalculation is scheduled and its data pipeline exists.

13.2 Traceability

14. Glossary and references

14.1 Glossary

14.2 References

Standard and licence note

Structure aligned with the Software Carbon Intensity method of ISO/IEC 21031:2024: only the formula, the names of its terms and the order of its steps are used, and no text, tables or definitions of the ISO/IEC publication are reproduced; obtain the standard for normative requirements. Based also on the openly published Green Software Foundation SCI specification (cited, not copied), on the area and principle names of the AWS Well-Architected Sustainability pillar, the Azure Well-Architected sustainable workloads guidance and the Google Cloud Well-Architected Framework sustainability pillar, and on the scope terms of the GHG Protocol. AWS, Microsoft Azure and Google Cloud and their products are trademarks of their owners; this template is not affiliated with or endorsed by them. This template is original text written for this collection; all factors and figures are illustrative examples, not benchmarks. Check the current official versions before use. Template licence: MIT.