The Sustainable IT Framework

Our goal is simple: help teams cut the environmental impact of their digital work without slowing them down. The SITM Framework gives you a clear way to see where energy is used, make practical changes, and keep improving over time.

Four plain-spoken ideas guide everything:

• Be Aware — Know what you run and how much energy and time it uses.
• Be Conscious — Set sensible targets and simple rules that teams can follow.
• Be Enabled — Make changes in code, infrastructure, and process that actually stick.
• Be Empowered — Watch the results, learn from them, and scale what works.

These ideas turn into a repeatable cycle:

1. Measure what matters (for example: energy per build, carbon per request, device reuse).
2. Decide on targets and guardrails.
3. Do the work: right-size, switch to greener regions when practical, remove waste, improve reuse.
4. Review outcomes and improve the next round.

Small steps add up. Right-sizing services, scheduling heavy jobs at cleaner times, or extending device lifecycles can lower energy use and cost—and often improve reliability too. The framework keeps the focus on changes that are easy to adopt and easy to maintain.

The framework doesn’t replace your current ways of working; it plugs into them.

• Agile: add simple acceptance criteria (e.g., “no increase in energy per request”).
• DevOps/CI/CD: add lightweight checks and dashboards; use feature flags and safe rollbacks.
• FinOps: track cost and energy together to find the best trade-offs.
• IITIL/Change/Incident: treat greener settings as standard changes; agree on clear fallback plans.

Pick a short list of metrics you can actually influence:

• Energy or carbon per request/page/view
• Energy per build or test run
• Share of workloads in cleaner regions (where possible)
• Device reuse and repair rates

Start with baselines, set a realistic target, and revisit monthly.

• Less energy use and lower emissions
• Leaner spend on compute and devices
• Fewer surprises, thanks to simple rules and clear rollbacks
• A steady rhythm for improvement that teams can live with

Days 0–30

• Name an owner.
• Measure a couple of services.
• List the top three easy wins.

Days 31–60

• Pilot one change in staging.
• Add one check to CI/CD (for example, alert if a change raises energy per request).
• Write a short exception path for edge cases.

Days 61–90

• Roll out the win to production with a safe rollback.
• Share the results.
• Add the practice to onboarding and plan the next round.

• Leaders who want progress they can explain and measure.
• Platform and SRE teams who can make guardrails easy to follow.
• Product and app teams who want simple, steady gains—not a big rewrite.

• A white paper that explains the framework in depth
• A methodology you can use as a step-by-step playbook
• A short adoption guide with checklists and a scorecard

Will this slow us down?

No. Start with small, low-risk changes and add guardrails that are easy to meet.

What if a greener option hurts performance?

Use safe rollout patterns (canary, blue-green) and clear rollback rules. Keep your service-level goals in front of you.

Do we need new tools?

Probably not. Most teams can start with what they already use for builds, monitoring, and cost tracking.

Start by measuring one service this week. Then pick one simple change, try it safely, and share what you learn. That’s the framework in action.