Software eco-design: software products features
This article aims at presenting features specific to software during a life cycle assessment (LCA). For each issue raised by these features, we will explain what approach we recommend to assess environmental impacts.
Find the complete Methodological Guide to software LCA as well as a use case on assessment of an application’s environmental impacts.
Software: tangible or intangible?
Software is a very special type of good:
• It doesn’t produce any direct tangible waste.
• It isn’t connected directly to power supply, hence isn’t seen as « consuming ».
• However, it does have an environmental impact represented by the consumption of resources and energy, due to hardware needs for its development and usage.
The goal of a LCA is to evaluate environmental impacts of manufactured goods, services and processes. But here, the question is: which category does software belong to?
As an initial reaction, it seems obvious that software has similarities with tangible goods, like the ones produced by the traditional industry, as they are materialized by a set of computer data (source code / executable code) that we can trade, own and use to answer a specific need.
However, it is important to make the difference between storage medium and physical interfaces of software interaction itself: software simply is a « state » of the storage medium (made of a unique and well-defined sequence of 0 and 1), a « state » of the network moving data around, a set of « states » of the screens displaying the software graphical representation, etc. So, should we consider software more as an intangible good?
To answer these questions, it is key to distinct the software itself from the service it offers. This way, we can consider software as an intangible good, offering one or more specific services (features or content). As an intangible product, its environmental impacts will result from consumption of resources (human, physical, tangible…) needed for the implementation of different phases of its life cycle: manufacturing/development, operating phase, distribution, decline.
Should we isolate software from its operating environment?
It is rather obvious software doesn’t function by itself, but always in an ecosystem of software it depends on, starting with OS (exploitation system), or with which it communicates and interacts. With this method, measuring impacts generated by an only studied software during usage phase is pretty tough.
Software impact never goes without the hardware and OS it works with: during a LCA, identifying environmental impacts linked to OS or hardware correctly isn’t possible. However, these impacts can be retrieved thanks to comparative LCAs, which means by comparing LCA of two very specific configurations. Let’s illustrate with an example: Software A on Hardware X with OS1 versus Software A on Hardware X with OS2. Or for instance, conducting sensitivity analyses would allow to asses impact deltas linked to different hardware.
IT equipment doesn’t’ necessarily work only for the studied software. Most of the time other applications and software are running at the same time, on the same equipment, thus, are consuming resources. As a consequence, the power consumed by the equipment cannot be associated with the studied software only. In order to assign a software the energy it consumes, the strategy implemented as part of the Web Energy Archive research project was to subtract the energy consumption induced by the OS and specific services such as antivirus (it is called consumption in idle mode) to the whole consumption of the equipment.
Software: what perimeter to consider?
One of the main issues we encounter when we think of environmental impact evaluation of a software is that it evolves quite a lot from one version to another (correction, features, etc) and it can have a modular architecture, or even work simultaneously on different equipments.
Software keeps changing.
Software breaks down in a variety of versions and sub-versions with different features. We may be tempted to say it doesn’t lead to any major issue as versions are spaced out in time… but it rarely is the case. When an official release of a well-identified version is available, software can quickly become the core subject of corrective patches or complementary modules, which may be very numerous and frequent. It has been very common and has been the trend in the last few years.
It is important to differentiate minor evolutions of a software from major ones:
• Major evolutions carry new features, or even a complete application restructuration.
• Minor evolutions mainly carry bugg corrections or addition of minor features.
As talking about a « finished » version of a software is tricky, we suggest limiting the study to the « latest stable version that is the most used ». No matter what version you study, it will have to be mentionned explicitly in the study assumptions. The impact of corrective and/or operational versions, whether minor or major, will be taken into account only with a sensitivity analysis. This means we model the impact of a bug correction or feature evolution by adding resources (HR, paper consumption, hardware…) during the manufacturing/development phase or in a new specific phase (maintenance).
Often, software is modular.
Software itself can be broken down into different modules we choose whether or not to install, or it can offer the possibility to install plugins and add-ons (like it is the case for most internet browser). We cannot model this concept of modularity per se with a LCA, for a simple reason: it would be tough, almost impossible, to identify specific resources needed for the development of each and each modules. You’ll have to consider the most standardized configuration possible, then you’ll be able to run sensitivity analysis in order to assess impacts of resources needed to develop specific modules (HR, hardware…).
To continue this serie on software LCA, the next blog article will be covering life cycle of software. As a matter of fact, life cycle of a basic tangible product is rather simple to figure out, however it isn’t the case for software.
Discover the whole Methodological Guide to software LCA, downloadable for free, as well as a use case on environmental impacts of an application.
