All information and communication technologies (ICT) have an environmental footprint, even when devised and used sustainably. As such, they play a role in sustainable development challenges.
The lifecycle of ICT, from raw material acquisition to production to disposal, has some direct environmental impacts. Production of ICT equipment requires resources and energy, the use of these types of equipment also requires energy, and at the end of their lifecycle, the devices are toxic e-waste. The same applies to software and services, even if their development does not directly require specific natural resources or produce e-waste. However, new software or services may indirectly require natural resources for energy consumption, as adopting a new service may require updating devices or increasing an existing device’s electricity usage. The same applies to the evolution of ICT equipment and human behaviour. Devices may be updated for the sake of acquiring trendy new mobile phones or gaming machines (user behaviour), thus increasing the footprint of ICT.
Thus, the footprint of the (Green) ICT sector represents the use of resources and energy as well as emissions and waste linked with the production, use, and disposal of ICT products. These ICT products may be tangible (physical) devices and infrastructure or intangible (non-physical) software and services. In the following subsections, we encipher the carbon footprint of the ICT sector.
2.1. Green ICT Hardware
The importance of increasing ICT hardware lifespans is apparent in calculating total emissions. As each device has embodied emissions from manufacturing and disposal, typically more significant than the emissions from the usage stage of the device, a longer device lifespan becomes beneficial for ecological factors. Especially as a lot of effort has lately been placed into Green ICT, i.e., making ICT equipment even more efficient and environmentally friendly. The disparity of manufacturing emissions as opposed to the use of ICT devices implies that to decrease the footprint of ICT; we should use our devices longer by keeping them updated and repairing them when necessary. However, the responsibility of hardware sustainability is shared with software developers, as new software should not always require new devices.
Life Expectancy of ICT Hardware
- End-user devices are known to have a life cycle of 3-8 years.
- Some devices, like PCs, may have a longer lifespan, while phones have an average lifespan of 2,5 years.
- Servers have a somewhat longer lifecycle of 7-10 years.
- Data centres typically have an even longer lifetime of 10-15 years.
- Some sections in data centres need to be updated earlier than others.
- A core network infrastructure (wired and wireless) has a life expectancy of 10-15 years.
- Wireless access points or routers typically last only a few years.
2.2. Green Software and Software Engineering
Software is an integral part of all ICT solutions and has been closely integrated into the sustainability of the ICT solutions, as shown in Figure 6. The software always runs on some kind of hardware and is thus dependent on hardware efficiency. However, software in itself also has similar manufacturing, usage, and disposal phases to hardware. When manufacturing or engineering software, we focus on sustainable software development processes, and when using the software, we consider software efficiency-related issues (i.e., Green Software).
As software is intangible, the carbon footprint of the software is related to the energy used in the development and usage phases. Some attempts have been presented to model the carbon footprint of software. In 2010, Taina presented a formula for this calculation, but many formula elements must be measured, which is a rather complex task. Johann et al. (2012) created a power measurement system for calculating software energy usage, but measuring the software’s actual energy usage has proven to be very complex. This is partly due to the results being highly contextual. For example, in the work of Temesgene (2019), it was demonstrated that the same software behaves very differently in different environments (Android devices, in this case). Similarly, it has been shown by Pereira et al. (2021) that the programming language influences software’s energy efficiency. The complexity of measuring software efficiency has led to a more holistic approach to software sustainability.
In general, energy efficiency is just one quality attribute of the software, so software sustainability should be considered in the software development process. Kern et al. (2013) have presented a general model (GreenSoft) for green software engineering. Similarly, Jagroep et al. (2016) present an approach wherein software architecture includes calculating energy consumption. However, due to the complexity of the field, there are currently no models that could capture all the aspects of the process with the required detail. Instead, companies need to narrow down the options by selecting their environments, programming languages, etc., and create guidelines that, in their case, lead to an optimal or at least close-to-optimal solution.
One recent approach to battling the inefficiencies in current solutions is, from the perspective of one’s organisation, to review the list of possible software wastes proposed by Janne Kalliola in his book Green Code. His list is not only software specific, but focuses on the efficiency of organisations when utilising various software, not just educating individual users. Kalliola emphasises that unnecessary software, or software employed for wrong purposes, generates surplus energy usage. Unsuitable architecture and information models may lead to a system’s suboptimal behaviour and non-optimal or unnecessary information that increases communication needs. A user’s role needs to be carefully considered, as dark patterns may lead the users to make mistakes, and thus, the software needs to run longer. This applies to all extra features included in the software. Kalliola’s list also includes some characteristics of energy-efficient software aspects that should be considered, such as choosing the right programming language, the amount of code needed (e.g., excess libraries), or even algorithms employed that affect the software’s execution.
Kalliola presents a list of guidelines that are applicable to practise, considering the context of the company. These guidelines do not guarantee optimal software footprint, but may help in optimising the software’s climate and environmental effects.
Kalliola’s list from his Green Coding book
Minimise stored data.
● Minimise the data model.
● Minimise static data.
● Minimise user inputs.
● cold storage for the data
● Minimise analytics data.
Minimise transferred data.
● Adjust transmission frequency.
● data compression
● selection of proper protocol and syntax
● removal of presentation information
● transfer of only changed data
● identification of unchangeable data
● verification and validation of transmitted data to avoid resubmissions
● HTTP optimization (headers, rerouting)
● optional data sizes
Reduction of code
● removal of obsolete code
● reduction (optimization) of the libraries used
● reduction of software features
● compiling the software for different environments
Improving the software efficiency
● selection of right algorithm
● selection of proper data structures
● optimising the right (known) parts of the software
● refactoring
● selection of proper execution framework
● selection of efficient programming language
● use of background execution
Use of external services
● use of Content Delivery Networks
● use of caches and load balancing
2.3. Green Services
ICT services can be viewed as digital data-based services provided for internal or external users via ICT systems. These ICT services may be adopted as part of a transition process, replacing local server-based services through cloud-based solutions or by providing devices (equipment) as a service.
Although a relatively old concept, cloud transformation has become a prominent ICT service driver since the beginning of this century. Initially, cloud infrastructures enabled the transition from organisation-specific servers to managed computing resources. Thus companies were able to focus better on their core operations. In addition to this economy-related perspective, cloud services also offer environmental and social benefits, some of which were unforeseen. With the use of data centres, operating a cloud service can involve better resource optimisation, energy efficiency, and reductions in emissions. Virtualisation of resources within the cloud enables resource sharing and thus reduces the aggregate need for hardware, saving natural resources. Although it has been claimed that the power usage efficiency of data centres has remained at a relatively constant level, their large size has attracted research on how to optimise energy usage. One approach to increasing the climate-friendliness of data centres is to utilise the waste heat these computing facilities generate, though this is not as simple as it might seem, as explained by Pärssinen (2019). Cloud-based implementation of ICT services may offer a tempting environment for global service delivery. Still, we must remember that these globally available services will increase network traffic and, thus, energy usage and possible carbon emissions.
Another very interesting climate-friendly transformation in ICT services is the transition towards the lifecycle management of devices as a service. Various leasing approaches have for years enabled device management, but only recently, DaaS (Device as a Service) and NaaS (Network as a Service) have emerged with a clear sustainability focus. For example, a Finnish company called SwanIT has focused on a vision of sustainable use and extended lifetime of devices, thus minimising device footprints. These kinds of new XaaS (Anything as a Service) services do not decrease the footprint of an ICT service itself, but make sure that the footprint embedded in a device is minimised as much as possible.3
2.4. Desiging with a Carbon footprint in mind
Sustainable design has been defined as “fundamentally a subset of good design. The description of good design will eventually include criteria for the creation of a healthy environment and energy efficiency.” (Stelzer 2006.) It has been recognized that over 80% of environmental impacts are determined in the design phase of any energy-related product.
Minimising stored or transferred data can affect the carbon footprint of software. Minimisation should be considered from the design phase. If the software’s functionalities are designed so that a significant amount of data is required, there are limited ways to reduce these impacts in the development phase. The amount of data transferred can also be excessive, if the user interface of the software is designed in a way that permits misunderstandings to happen.
The energy efficiency of a fixed network is clearly better than that of a mobile network. Whenever possible, a fixed network should be favoured.
● Utilise different behaviours when using a different network connection. For example, exclude some features or reduce video quality when using the mobile network.
● Utilise selection design and embedding in application design (Kanerva 2018). Place more data-intensive functions on the side of the user’s base path.
● Give the user the freedom to choose, but offer more data-intensive operations, for example, only as a paid service.
● Use the most energy-efficient options by default.
● Inform the user of activities that require heavy data transfer. Also, allow the user to disable such activity.
To reduce transferred data
- avoid video content (approximately 80% of all global data transfer on the Internet is caused by video content)
- avoid animation
- use graphics instead of pictures
- keep the structure and layout of the user interface simple and clear
- avoid extra visual noise in GUI
- optimise the user flows to be as short as possible
- avoid misunderstanding
- colours should follow the general understanding of colour codes and should be clearly distinguishable from each other (considering various restrictions e.g. red-green blindness
- use clear and targeted language
Find out more about user-centric and sustainable design
- Anna Savisaari / Exove Design in Green ICT & Koodia Suomesta: Kestävä koodaus 11.5.2022. In Finnish.
Find out more about the carbon footprint in the ICT sector
- Green ICT: kuinka myydä ilmastoviisaita digipalveluita? 21.10.2021. In Finnish.
- Tieke, AamuAreena: Kestävä kehitys ja datan monet kasvot, 19.11.2021. In Finnish.
- Green ICT: Ilmasto- ja ympäristöystävällisyys lisäarvona B2B- ja kuluttajamarkkinoilla 24.11.2021. In Finnish.
- Green ICT: Kestävä ohjelmistotuotanto 12.2022. In Finnish.
References
- Taina, J. (2010). How Green Is Your Software? In: Tyrväinen, P., Jansen, S., Cusumano, M.A. (eds) Software Business. ICSOB 2010. Lecture Notes in Business Information Processing, vol 51. Springer, Berlin, Heidelberg. https://doi-org.ezproxy.cc.lut.fi/10.1007/978-3-642-13633-7_13
- Johann, Timo, et al. “How to measure energy-efficiency of software: Metrics and measurement results.” 2012 First International Workshop on Green and Sustainable Software (GREENS). IEEE, 2012.
- Temesgene, Dagnachew, Jari Porras, and Janne Parkkila. “Offloading for Mobile Device Performance Improvement.” (2019).
- Pereira, Rui, et al. “Ranking programming languages by energy efficiency.” Science of Computer Programming 205 (2021): 102609.
- Kern, Eva, et al. “Green software and green software engineering–definitions, measurements, and quality aspects.” First International Conference on Information and Communication Technologies for Sustainability (ICT4S2013), 2013b ETH Zurich. 2013.
- Jagroep, Erik, et al. “Extending software architecture views with an energy consumption perspective: A case study on the resource consumption of enterprise software.” Computing6 (2017): 553-573.
- Pärssinen, Matti, et al. “Waste heat from data centers: An investment analysis.” Sustainable Cities and Society 44 (2019): 428-444.
- Stelzer, K. (2006). An article of the journal Les ateliers de l’éthique / The Ethics Forum. Volume 1, Number 2, Fall 2006, p. 26–40.
