Keywords

1 Introduction

Within the last 15 years, since the publication of Global eSustainability Inititative’s (GeSI) SMART2020 report in 2008 [1], awareness about the ICT industry’s carbon handprint and footprint has increased. According to the latest GeSI SMARTer2030 report [2] ICT has a large handprint potential of about 12,08 Gt CO2e, while the footprint is about one-tenth of this, 1,25 Gt CO2e. While the handprint potential is substantial, we can not ignore the footprint, as, according to the report, it is the fastest growing of all industries, projected to triple between 2015 and 2025.

As Freitag et al. [3] state, the ICT sector has become a significant factor in global carbon emissions. It is estimated in their study that the ICT sector creates 2.1–3.9% of global greenhouse gas emissions. It is self-evident that this is a subject that needs to be noticed if we want to achieve the objectives of the Paris AgreementFootnote 1 to “hold ‘the increase in the global average temperature to well below 2 ℃ above pre-industrial levels’ and pursue efforts ‘to limit the temperature increase to 1.5 ℃ above pre-industrial levels’.” The EU executes this with the initiative of the European Green DealFootnote 2, which shows the path for Europe to be climate-neutral by the year 2050. EU is controlling this objective through the European Climate LawFootnote 3. Currently, EU directive NFRD EU/2014/95Footnote 4 determines the need for large public interest entities with over 500 employees, such as banks, insurance companies, and bigger listed companies, to make “a non-financial statement containing information to the extent necessary for an understanding of the undertaking's development, performance, position and impact of its activity, relating to, as a minimum, environmental, social and employee matters, respect for human rights, anti-corruption and bribery matters.” EU Directive 2022/2464Footnote 5 of corporate sustainability reporting “modernizes and strengthens the rules concerning the social and environmental information that companies must report. A broader set of large companies, as well as listed SMEs, will now be required to report on sustainability.” The new directive will be implemented in reporting for the first time for the financial year 2024. The reporting should be done according to European Sustainability Reporting Standards (ESRS)Footnote 6. The company-specific Greenhouse gas emissions are to be reported within the scopes one, two, and three adopted from the GHG Protocol [4]. In short, scope one emissions are direct emissions from the company operations, scope two emissions are formed from the energy used in the company, and scope three emissions include all the indirect emissions in the value chain, in both up and downstream activities. This may become a challenge for software companies since their business operations produce immaterial products. This will be further discussed in Sect. 2.2.

1.1 Green ICT Ecosystem Project

This research is based on work done in the Finnish Green ICT ecosystem -projectFootnote 7. The project aimed to increase the environmental awareness of Finnish ICT companies and build an ecosystem around the topic of Green ICT in the Uusimaa region. The project provided webinars, online workshops, and published guides to both procurers and producers of ICT products and services. The concrete outcome besides the guides was a web-based self-assessment tool for organizations to evaluate their level of climate and environment-neutral actions and to provide a base for their development plan. In the development of the tool, a service design process was utilized. The service design process used the double diamond model [5], a widely used method in service design processes, which will be presented with a wider lens in Sect. 3.1. The design process has been used in this research as a basis for the development of the software industry-specific carbon emission model, which will then help the software companies report their carbon emissions.

1.2 Objective of the Study

The objective of this study is to define the GHG components in scopes one, two, and three for software companies. By providing these software-specific components, reporting their carbon emissions becomes a bit easier. The practical need from software companies and our project objective led to our research question: What should software companies report within scopes 1, 2, and 3?

By providing an answer to this research question through design science research, we aim to contribute to the EU-level objective of carbon emission reporting in every industry sector.

2 Background

In this Background section, we present the Greenhouse Gas (GHG) Protocol that forms a basis for our model. We also describe the software industry emissions on a general level and the challenges the software industry may have while using the general GHG Protocol.

2.1 Greenhouse Gas Protocol

With the increase in awareness of the negative effects of human activity on the climate, mainly particle pollution, international bodies and forums have started preparing mitigation measures. This raised the issue of defining and calculating the emissions to understand the challenge clearly. As with all emerging fields, varying methods of emission calculations arose early on, and standardization became a necessity as the results were about as comparable as apples and bananas. This standard needed to address factors such as emission equivalency, comparability, assigning of responsibility, and sustainability reporting usability.

Greenhouse Gas Protocol [4] has emerged as the most popular and is widely regarded as the golden standard method of emission calculations. International Standardisation Organisation’s (ISO) standard for carbon emission calculations, ISO 14064 [6] is compatible with the GHG Protocol, and it is being used by, for example, Global Reporting Initiative (GRI)Footnote 8 and Science Based Targets Indicators (SBTi)Footnote 9.

GHG Protocol calculates emissions as carbon dioxide equivalent (CO^2e), in which all different greenhouse gas emissions can be measured. The equivalency is calculated in relation to each emission’s atmospheric warming potential in comparison to carbon dioxide for conversion into a comparable metric. The protocol divides emissions into three scopes according to the source (see Fig. 1) [4]. Figure 1 presents these scopes, as depicted by the Environmental Protection Agency of the United States. It represents these emissions in the three scopes of the GHG Protocol, divided between the upstream and downstream activities of the reporting company. Upstream of the value chain pertains to anything that is procured by the reporting company, and downstream pertains to anything produced and sold by the reporting company. Scope one contains the direct emissions from the operations of the measured company, such as equipment and office. Scope two pertains to indirect emissions that are caused by energy usage of the reporting company and are caused in upstream of the value chain. Scope three emissions are divided into the upstream and downstream activities. Upstream Scope three emissions are caused by different products and services used by the reporting company, including, for example, diverse emissions from employee commutes and purchased services. Downstream Scope three emissions pertain to activities conducted in advertising, sales, distribution, and usage of the reporting company’s products, in addition to investments made and financial assets held by the reporting company.

Fig. 1.
figure 1

Greenhouse Gas Protocol Scope Definitions (EPA) [7]

Full size image

According to A Corporate Accounting and Reporting Standard [8], these scopes are defined as follows:

  • Scope one emissions represent the direct emissions “owned or controlled by the company” from the business operations of the company in question, such as its equipment and offices.

  • Scope two emissions represent the indirect emissions from the generation of the electricity used in the company.

  • Scope three expands the emissions to the company’s value chain and considers both the upstream and downstream activities, such as sub-contractors and clients.

2.2 Challenges of the Software Industry for Emissions Reporting

Adopting the GHG Protocol for specific industries requires identifying the relevant business operations and their effects. Software companies are a special case in this regard, as their products are digital instead of physical. On the other hand, these products are dependent on physical hardware infrastructure, which means they require electricity and thus produce emissions [9]. In addition, modern software uses a client-server model, which runs on a server in a data center environment or a cloud service. This affects the emissions and makes the emissions calculation fuzzy. This is something that has emerged among companies – how should one measure the carbon footprint in such an ecosystem, in which its code and software run on an external data center or services of a third party and are used by another third party? All these factors need to be considered, and decide what of those needs to be calculated.

Software lifecycle can be broadly seen in three stages: the requirement and design phase, the development phase, and the use phase [10,11,12]. Software is coded to fulfill a specific purpose, whether professional or recreational. In both cases, the purpose defines the requirements that are used in its design [13]. Many of the most relevant decisions that define the software’s climate and environmental impact are made in this first phase of requirements and design [14, 15]. In the development phase, the software is programmed and tested on how well it fulfills these requirements [13].

Digital products are not limited by physical resources and manufacturing, which makes them easily replicable and scalable. Combined with digital distribution, physical media can be bypassed entirely. On the one hand, the non-dependence on physical resources lessens the environmental impact of the products; on the other, the replicability increases the climate impact specifically. This is an issue in downstream scope three emissions.

Another challenge with the software is the variety of client devices used by the end users. These devices have different hardware architectures and energy usage patterns, which raises further challenges in calculating the use phase emissions. This is an issue in downstream scope three emissions.

3 Research Process

In this Research process section, we present the methods used in this study. We also visualize the process of developing the Software Company Scopes model.

3.1 Methods

In this research, we have conducted design science research methodology (DSRM) by Peffers et al. [16]. According to Peffers et al. [16] the design science process consists of six steps. These steps are

  1. 1.

    problem identification and motivation

  2. 2.

    definition of the objectives for a solution

  3. 3.

    design and development

  4. 4.

    demonstration

  5. 5.

    evaluation and

  6. 6.

    communication.

The core of this method is an artifact created during the research process to solve the problem identified in the beginning (Fig. 2). In this study, we present the Software Company Scopes model as an artifact to solve the challenges in the software industry to calculate carbon emissions as presented in Sect. 2.2.

Fig. 2.
figure 2

DSRM Process Model according to Peffers et al. [16]

Full size image

In this study, we identified the problem (step 1) within the Green ICT project and formed the research question presented in Sect. 1.2. For steps 2–5, we have utilized the double diamond service design process model [5] (Fig. 2) for developing the self-assessment tool described in Sect. 1.1. The double diamond model includes similar components and phases to the DSRM model presented above. The first phase in the double diamond model is understanding, followed by the phase of brainstorming. After these phases, an outcome will be tested and implemented. In this study, the outcome was the web-based self-assessment tool (Fig. 3).

Fig. 3.
figure 3

Double diamond service design model [5]

Full size image

The primary method for data collection used in this study is an interview. Interviews were utilized as expert interviews during the service design process, where there were three rounds of interviews conducted with five different companies from the IT sector. Interviews were executed online via Teams meetings. Participated companies are presented in Table 1. Company E participated only in the first and the second rounds of interviews hence the total number of interviews was 14. The objectives for every round of interviews were different. Objectives and types of interviews follow the double diamond service design process model used in the study and were as follows.

  1. 1.

    Understanding the state of the art in companies and the need for the tool through semi-structured group interviews (companies A-E)

  2. 2.

    Testing the preliminary questions for the tool (companies A-E)

  3. 3.

    A pilot study of the beta version of the tool (companies A-D)

Table 1. Participants in the service design process.
Full size table

3.2 Analysis Process

The analysis of the interviews, which are presented in Sect. 4, was supplemented with an analysis of six webinars and eight ecosystem meetingsFootnote 11 held during the Green ICT project within the time period of October 2021 until August 2023. In the webinars, three companies or organizations represented their work as a business case, product case, or general work in green ICT. These cases included carbon calculation of both software products and SME companies. At the end of the webinar, there was a panel discussion between the participants on the themes of their presentation.

Ecosystem meetings were more varied, and there were discussions and workshops about innovation & research, emission calculations, green coding, green procurement, ICT equipment and its lifetime impact, and sustainable software business models and tools. Analysis of the transcripts from the webinars and ecosystem meetings formed the base information for the questions used in the interview process.

In addition to these webinars, four workshops on the service design process replenished the analysis of interviews. These multi-stakeholder workshops were executed during October and November 2022. The relation between these data collection sets and the structure of the development of the Software Company Scopes model is presented in Fig. 4. With the visualization (Fig. 5), we also present the relation of the GHG Protocol to our model.

Fig. 4.
figure 4

Steps in this research in relation to the double diamond service design model.

Full size image
Fig. 5.
figure 5

Visualization of the data collection for the framework.

Full size image

4 Results

This section presents the software company-specific scopes as a result of our study and the results that led to the model.

4.1 Interviews

The main objective of the first round of interviews was to gain an understanding of the current situation in the companies and the possible challenges they are facing with taking climate and environmental impacts into account in their operations. The main findings from the first round were as follows:

  • Information about software-specific climate and environmental impacts is here and there

  • What should we as a software company calculate in scopes 1, 2, and 3?

  • It is hard to find concrete information or guidance on what to do and how towards more climate-neutral actions

  • Regardless of the remote work, there are several offices

  • “We produce intellectual property, so it's hard to have the same way influence on climate issues”

  • “A complex thing [climate and environmental impacts of software company] and many things affect another”

From these findings, we generated the analysis:

  • There is an obvious need for some concrete guidance on what to include in software companies into the GHG Protocol scopes

  • The core of the company requires basically only some facility (office), a computer, and a network.

  • The effects of the operations of software companies extend far into subcontracting chains

  • The layered structure of software companies (see Fig. 6)

Fig. 6.
figure 6

Visualization of software company functionality

Full size image

Scopes one, two, and three can be directly derived from the image: core functions belong to Scope One, needs for the software company core to function belong to Scope Two, and the effects and operations in subcontracting and distribution chain belong to Scope Three.

4.2 Scopes of a Software Company Framework

After completing the understanding phase of the service design process of the self-assessment tool, we divided the software production process into the following parts based on the analysis of the interviews in the brainstorming and testing phases (see Fig. 2).

  1. 1.

    Organization strategy

  2. 2.

    Software production

    1. a.

      Design

    2. b.

      Coding and testing

    3. c.

      Usage and maintenance

  3. 3.

    Support functions

This division, while somewhat artificial, sheds light on the different Scopes in both upstream and downstream factors and is a useful categorization. In this approach, the decision of how to react to the legislative and public moral pressure is covered in the organization’s strategic work. This contains the values, vision, mission, strategy, and action plan of the company. It also includes how the company’s staff is informed on how to take climate and environment into account in their work. As the demands pertaining to the company's supply chain are strategic choices, the emission demands from subcontractors are included here.

The practice of how well the Scopes are covered is in the second part, the software production. The first step, design, is the phase where most of the critical decisions concerning the emissions are made [13]. These include architecture choices [17, 18], programming language [19,20,21], integrated development environment, graphical choices [22], etc. These choices influence both the coding and testing phase and the usage and maintenance phase. As such, it seems to influence many of the scope three emissions in both the downstream and upstream.

The coding and testing phase is the source of Scope One and Two emissions, as it is the main business activity of the company. It is where they use their equipment and offices, and it causes a lot of its direct use of energy. It also includes some Scope Three emissions from the upstream, such as employee commuting.

The usage and maintenance phase is composed mostly of Scope Three emissions from downstream, such as distribution and tech support.

Support functions include the climate and environmental choices made by the company in its everyday operations not directly related to its main business activity. This also includes human resources and marketing. The most important of these are the sourcing of energy, local energy generation, employee training in sustainability competence, and environmental systems present in the offices.

From the division together with the GHG Protocol, we have derived and named the factors to be included in Scopes One, Two, and Three for software companies (Table 2).

Table 2. Factors for a software company to include in Scopes 1, 2, and 3.
Full size table

As a final result of this study, we have created a Software Company Scopes model similar to GHG Protocol to present the result in an understandable but also comparable form (see Fig. 7).

Fig. 7.
figure 7

The Software Company Scopes model presents an overview of scopes and emissions across the value chain of a software company with visualization adopted from the GHG Protocol Corporate Value Chain Accounting Reporting standard [8].

Full size image

5 Discussion and Conclusion

Software companies have raised the question “What should we do to be able to calculate and report our emissions accurately?” and with this paper, we are trying to answer that question with our Software Company Scopes model.

Verifying the model needs academy-industry collaboration with both ICT companies and companies that calculate CO^2 emissions based on the GHG Protocol. Validating the model with a larger sample of companies can show its strengths and weaknesses and will open the way for future adjustments if needed. This can be achieved by calculating pilot companies’ emissions and comparing the results from the model against current emission calculations. To be reliably validated, there needs to be collaboration with companies that have not considered these issues widely before.

We acknowledge that the model needs validation through case studies where it is applied to software-producing companies. We also acknowledge that the sample of five companies represents SMEs, and the model might need adjustments in large companies. The important question to research more is to find the largest emission sources and the low-hanging fruits. The largest sources for software company’s emissions can vary between different kinds of software companies, depending on variables such as whether the company operates on a B2B or B2C model; the type of the software in question, such as SaaS, licensed software product, or tailored software; and architecture choices such as modular or client-server architecture. According to our research, the largest sources of emissions in software companies are located in Scope Three.

The model also needs to be customized for, e.g., consulting companies, digital marketing companies, and ICT hardware and infrastructure companies, which have their own characteristics. Consulting companies especially have quite a varying array of services provided, which raises the need for customization.