Sustainable technology is often discussed through broad promises. Engineering teams need a more useful question: what part of this system can we measure and improve without reducing the value or reliability it provides?
The answer begins with a baseline. Define the software boundary, select a functional unit such as a completed transaction or processed record, and identify the factors that drive energy use and hardware demand. Without that context, a smaller cloud bill or faster response time may be helpful, but it is not yet a complete environmental claim.
Efficiency is an operating discipline
- Remove unnecessary requests, data transfer, storage, and repeated computation.
- Right-size services using observed demand instead of permanent worst-case assumptions.
- Set performance and efficiency budgets for high-volume workflows.
- Extend the useful life of systems through maintainable architecture, documentation, and responsible upgrades.
- Re-measure after changes and report the method, boundary, and limitations with the result.
Do not claim what you have not measured
Lower latency, fewer queries, or reduced infrastructure can indicate better efficiency. Converting those improvements into a carbon figure requires an appropriate methodology and data. Transparent limits are more credible than a precise number built on hidden assumptions.
“Baseline first. Improve what matters. Report only what the evidence supports.”
— Renovative Lab principle
Reference points
- ISO/IEC 21031:2024 — Software Carbon Intensity specification: https://www.iso.org/standard/86612.html
- Green Software Foundation — SCI specification: https://sci.greensoftware.foundation/