Sustainability as non-functional requirements for software applications.
Climate change and global warming have been hot topics in recent years, especially with sudden weather heatwaves and other dramatic weather changes. While I quite like hot weather and blissful sunbathing, more considerate people are trying to reduce the impact of our activities on the planet. According to scientists, in order to preserve our planet that can sustain life, global temperature increase needs to be limited to 1.5°C above pre-industrial levels. And according to Paris Agreement, emissions need to be reduced by 45% by 2030. In fact, more than 3,000 conscientious businesses and financial institutions are working to reduce their emissions in line with climate science and the Paris Agreement.
So how does this all influence software development? Well, organisations who are aware of carbon emissions would want their software products to be greener and go in line with their principles about the environment. This means that the demand for greener software will influence software non-functional requirements and therefore software development. This blog briefly explains what sustainability software non-functional requirements are, lists some actions we might need to consider to meet sustainability requirements, and highlights the challenges of meeting those non-functional requirements.
What is sustainability in software applications?
Sustainability is:
meeting the needs of the present without compromising the ability of future generations to meet their own needs (Penzenstadler et al. 2012)
That is, we need to develop our application with minimal effect on the planet and minimal carbon footprint.
When we develop, test, deploy, run, and maintain our software, we cause carbon emissions because all those processes require energy consumption.
Sustainability creates the need for new, augmented, and adjusted business capabilities with additional requirements around data and processes to do things you couldn’t do before. These include understanding the complete end-to-end value chain carbon footprint or supporting initiatives with renewed imperatives, such as recycling products in circular economy initiatives. (Paul Homan, RedHat, January 2023)
Sustainability awareness in software has already influenced software development and is likely to become part of Non-functional requirements (NFRs).
There are a number of studies that propose frameworks for sustainability requirement engineering. The main challenge in sustainability as a non-functional requirement is that it is difficult to define as well as difficult to meet because carbon emissions are not easy to measure in software engineering. In addition, it is difficult to define the scope of sustainability NFR, because, unlike other NFRs, sustainability can imply all stages/lifecycle of software engineering: from software development to end-user experience and usage.
Furthermore, sustainability NFR may result in some NFR trade-offs such as availability. These trade-offs will need to be defined and discussed with all stakeholders.
Actions to ensure lower carbon emissions in software engineering.
As software developers, in order to meet sustainability NFR we will have to go through certain actions, choices, and trade-offs.
Green Software Foundation – a non-profit organisation under the Linux Foundation, defines the following categories for actions that are aimed at reducing carbon emissions in software:
- Energy Efficiency: Actions taken to make software use less electricity to perform the same function.
- Hardware Efficiency: Actions taken to make software use fewer physical resources to perform the same function.
- Carbon Awareness: Actions taken to time- or region-shift software computation to take advantage of cleaner, more renewable or lower-carbon sources of electricity.
Some of the actions under these categories that we might have to do in order to meet sustainability NFRs include:
- Choice of languages and design. For example, Java consumes less energy than JavaScript. So if our backend service is written in Java we can make sure that all the complex business logic is done on the backend. JavaScript only deals with the view of our application.
- Choice of AI Model. We might want to choose an AI model that consumes less energy: https://cacm.acm.org/magazines/2020/12/248800-green-ai/fulltext
- Deployment environment. Cloud is considered a greener environment than on-premises. This is because the cloud typically provides data centres at scale and has higher utilisation. In addition, most cloud providers use renewable energy and have better infrastructure with data centres located closer to electrical facilities that power them. Furthermore, most cloud providers have enabled tracking of carbon emissions in the form of tools and dashboards. This makes it easier for us to monitor the carbon emissions of our software running in the cloud.
- Deployment-aware testing. Running automation tests after every single commit and push can consume a lot of energy. Depending on the scope of our sustainability NFR we might want to invest into running our automation tests depending on the changes that have been introduced.
- Time of deployment. We might want to move our deployment time to a time when the electricity is less used.
How to measure carbon footprint in software engineering.
Green Software Foundation highlights that the most common means of measuring carbon footprint in software is the GHG protocol (Greenhouse Gas protocol) which divides emissions into three scopes: direct emissions, indirect emissions, and other indirect emissions. To calculate the total software carbon emissions we need to have the full picture of energy consumption, carbon intensity, and hardware. If we are running our software on one of the popular cloud providers, then we can utilise their tools that enable us to calculate and monitor the carbon footprint of our software running on the cloud. For example, Google provides Google Carbon Footprint, AWS provides Customer Carbon Footprint Tool, and Azure has Microsoft Sustainability Manager.
However, if we only use tools available to us through cloud providers, we might not have a complete picture of the carbon emissions of our software and it might give us false assertions that we are meeting our sustainability NFRs. This is because we also need more information on software carbon emissions that is not visible to the cloud, for example, indirect emissions, such as emissions produced by the client using our software. In addition, even if we do manage to get the full calculation of software carbon emissions, we need to take into account other metrics, such as carbon intensity to make any conclusions.
In real life, when we are under pressure to deliver software, there is a possibility that we will tend to cut corners and produce calculations that will show that we are meeting our sustainability NFRs, by concentrating more on the existing tools that can show visually in a form of a dashboard that we are “meeting” our NFRs. And possibly omit some metrics required for more accurate calculation.
Conclusion.
More businesses and organisations are becoming aware of carbon footprint and greenhouse effect on our planet. As a result, they are trying to change the way their business operates to ensure they have a greener way of working. This also includes software applications that they are using or providing. As a result, sustainability will soon become one of the NFRs of software engineering.
To create greener software we might have to have some reasonable trade-offs with other NFRs, choose a programming language, AI and data models based on energy consumption, and change our deployment patterns based on the time when less energy is consumed.
However, sustainability in software seems to be difficult to measure and calculate accurately. Hence it would be difficult to define as a measurable non-functional requirement as well as provide proof that we have met those requirements. In addition, delivery pressure in software engineering, and the lack of accurate sustainability measurement may result in cutting corners and providing evidence that the software is meeting sustainability NFRs when in fact it might not quite meet them.
Bibliography.
- Developing a Sustainability Non-Functional Requirements Framework . Anika Raturi et al. 2014
- Energy Efficiency across Programming Languages. Rui Pereira et al. 2017
- Green Software Requirements. Carl Austin et al.
- The role of green it in the non-functional requirements : Perspectives of functional design. T. Velasquez et al. 2019
- Green AI. Roy Schwartz et al. 2020
- Software carbon intensity specification. Green software foundation. 2022
- What IT architects can do to design for sustainability. Paul Hauman. 2023
About the Author:
Tanya Maslova is a senior Java Developer here at Version 1.
