The transformation towards sustainable development practices is an emerging area, I learned a lot in my previous roles working for Amazon, and now I'm working part time as a technology and strategy advisor, I'm planning to share some of the ideas and mental models needed to make sense of this from a developer perspective in a series of short posts here.
I was part of the team that published the Well Architected Pillar for Sustainability which has detailed advice on how to optimize a workload to be more sustainable, I'll incorporate some of this advice as I go along.
To start with, most people are familiar with the phrase "Digital Transformation". It's become over-used and is a bit tired now. In essence though, it refers to the new businesses that were enabled by pervasive Internet and mobile connected customers, and the changes needed in old businesses to compete. We've had a decade or so to get used to this, so it's well understood, even if some of the laggards are still struggling to figure it out.
On the other hand "Sustainability Transformation" is an emerging topic, poorly understood and with immature solutions to support it. It refers to the changes driven by our need to reduce the impact of business on the environment, including reducing greenhouse gas emissions, clean water and zero waste to landfill. The biggest of these is carbon dioxide reduction, as we need to move from extracting and burning fossil fuels to an economy based on renewable energy. This reaches throughout business operations, from the fuel burned to heat buildings and power vehicles (which is called scope 1), to the fuel used to generate the electricity we consume (which is called scope 2), to the energy used by things we buy, own and sell (which is called scope 3).
The first problem is figuring out how much greenhouse gas is being generated. There are several different gases that matter, with different impacts. The main one is Carbon Dioxide, but Methane and CFC refrigerants are also a problem. They are combined together for measurement and reporting as Carbon Dioxide Equivalent - CO2e. The methodology published by the Green House Gas Protocol is used to calculate carbon equivalents and to get detailed guidance on what to include in scope calculations.
There are a few different ways to calculate carbon.
The economic carbon intensity of a product or a business may be reported as the grams of carbon per dollar that is spent, gCO2e/$, or metric tonnes of CO2 per million dollars mtCO2e/$M. There are a million grams in a metric tonne, so the value is the same. Most companies start out by making an estimate of their carbon footprint using an Economic Input/Output (EIO) model that is based on the financial flows and uses industry average factors to relate spend to carbon. This is good enough for reporting, and to find out where most of the carbon is likely to be generated by the business. It's not useful for optimizing carbon reduction, because if you spend more on a low carbon energy source or raw material you will end up reporting more carbon not less.
To get more accurate and actionable measurements, business processes need to be instrumented to calculate the carbon generated by raw material and product flows. For raw materials, carbon intensity is often reported as grams of CO2 per kilogram of the material - gCO2e/Kg. For fuels that are burned this provides a more accurate way to estimate scope 1 than just basing it on the total amount spent on fuel.
The carbon intensity of energy for scope 2 is measured as grams of CO2e per KWh. It depends how and when that electricity was generated, and changes all the time. For example when it's sunny or windy, there's more solar and wind energy. The "grid mix" is usually reported by an energy supplier on an average monthly basis, however you have to wait for the bill, so an accurate scope 2 report will be delayed by a month or more.
The embodied carbon from manufacturing is amortized over the lifetime of the item: gCO2e/year. This is part of scope 3. For example if you use something like a mobile phone for longer, the gCO2e that was emitted to make it is having a useful purpose for longer.
For a sustainability transformation, a business has to figure out how to measure its carbon footprint, and come up with a plan to change the way it powers everything, and change the products it's making, and even the markets that it operates in. That takes time, and I'll talk about timescales in my next post.
From a developer perspective there are three main areas of interest. The first is that most companies start with a manual spreadsheet based approach, but new disclosure regulations are driving the need to build some kind of data lake to report their carbon footprint, and to model their risk exposure to the impacts of climate change. The second is that sustainability is becoming a product attribute of the things companies do and build, so it's turning up in design decisions. The third is that the efficiency of the code we write and how we deploy it affects the carbon footprint of our IT systems. I call this DevSusOps, adding sustainability concerns to development and operations.
That's enough to start with, there's lots more to talk about, but I'd like to break up this discussion into a bunch of short posts. To learn more, a good readable document to study is this Green House Gas Protocol paper.
photo taken by Adrian at Point Lobos, California
Top comments (0)