136 97 14MB
English Pages 376 [367] Year 2022
LNBIP 463
Noel Carroll Anh Nguyen-Duc Xiaofeng Wang Viktoria Stray (Eds.)
Software Business 13th International Conference, ICSOB 2022 Bolzano, Italy, November 8–11, 2022 Proceedings
123
Lecture Notes in Business Information Processing Series Editors Wil van der Aalst RWTH Aachen University, Aachen, Germany John Mylopoulos University of Trento, Trento, Italy Sudha Ram University of Arizona, Tucson, AZ, USA Michael Rosemann Queensland University of Technology, Brisbane, QLD, Australia Clemens Szyperski Microsoft Research, Redmond, WA, USA
463
More information about this series at https://link.springer.com/bookseries/7911
Noel Carroll · Anh Nguyen-Duc · Xiaofeng Wang · Viktoria Stray (Eds.)
Software Business 13th International Conference, ICSOB 2022 Bolzano, Italy, November 8–11, 2022 Proceedings
Editors Noel Carroll University of Galway Galway, Ireland
Anh Nguyen-Duc University of South-Eastern Norway Bø, Norway
Xiaofeng Wang Free University of Bozen-Bolzano Bolzano, Italy
Viktoria Stray University of Oslo Oslo, Norway
ISSN 1865-1348 ISSN 1865-1356 (electronic) Lecture Notes in Business Information Processing ISBN 978-3-031-20705-1 ISBN 978-3-031-20706-8 (eBook) https://doi.org/10.1007/978-3-031-20706-8 © The Editor(s) (if applicable) and The Author(s), under exclusive license to Springer Nature Switzerland AG 2022 Chapters “Interrelation of Digitalization and Digital Transformation in a Maritime Company” and “On the Characteristics of Internal Software Startups” are licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/). For further details see license information in the chapters. This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed. The use of general descriptive names, registered names, trademarks, service marks, etc. in this publication does not imply, even in the absence of a specific statement, that such names are exempt from the relevant protective laws and regulations and therefore free for general use. The publisher, the authors, and the editors are safe to assume that the advice and information in this book are believed to be true and accurate at the date of publication. Neither the publisher nor the authors or the editors give a warranty, expressed or implied, with respect to the material contained herein or for any errors or omissions that may have been made. The publisher remains neutral with regard to jurisdictional claims in published maps and institutional affiliations. This Springer imprint is published by the registered company Springer Nature Switzerland AG The registered company address is: Gewerbestrasse 11, 6330 Cham, Switzerland
Preface
Welcome to the 13th International Conference on Software Business (ICSOB 2022) proceedings. This conference edition was hosted by the Faculty of Computer Science at the Free University of Bozen-Bolzano, Italy. The university is located in the beautiful city of Bolzano near the Dolomites in the Eastern Italian Alps. The faculty is top-ranked in the field of computer science among small universities in Italy. The theme of ICSOB 2022 was Software for Digital Transformation. Digital transformation has become a key priority for businesses to evolve to continuously changing market demands. Digital transformations typically require significant organizational, structural, cultural, and technological changes. These changes can fundamentally redefine key organizational activities and values in response to new opportunities through the exploration and exploitation of software business and innovation. Yet, the ongoing acceleration of digital technologies in today’s software-enabled business environment poses not only opportunities but also major challenges for organizations to continuously invest in and embed digital transformations merely to survive and compete. As a contemporary topic, digital transformation presents an intersection between software engineering, information systems, and business communities. Besides traditional topics, ICSOB 2022 welcomed research about software for digital transformations that addresses a wide range of concerns ranging from software products, software teams, software deployment, software startups, agility, strategy, and business models, among many others. For ICSOB 2022, we received 53 research paper submissions on a wide range of topics. Each submission was single-blind reviewed by three to five independent expert reviewers. After a round of discussion among reviewers and program chairs, the Program Committee accepted 19 full papers and six short papers. The research papers were primarily selected for the quality of the work and their relevance to the community. The papers covered a range of topics, including digital transformation, software startups, software ecosystems, software processes, platform economy, sustainability, people analytics, and citizen development. The authors are from Australia, Austria, Brazil, Denmark, Finland, Germany, the Netherlands, Norway, Sweden, and the United Kingdom. The conference also had keynotes on the theme of digital transformation, an industry track with tutorials and industry talks, a PhD retreat, and poster sessions. The PhD retreat received five proposals which were discussed during the conference. The PhD retreat was facilitated so that PhD students could present intermediate results on their research related to software-intensive business. The poster sessions stimulated face-toface discussions among the conference participants, including reflection on past studies, descriptions of current initiatives, visions for the future, and new results. On behalf of the organization team, we would like to thank the members of the Program Committee and the additional reviewers for their efforts in evaluating the submissions and ensuring the high quality of the conference. The efforts of the Steering and Organizing Committees and all the chairs were of enormous value in building a successful conference. We extend our gratitude to all the scholars who submitted papers
vi
Preface
to the conference, all the authors who presented papers, the audiences who participated in very inspirational discussions during the conference, and the practitioners who shared their experiences and thoughts during the workshops. November 2022
Noel Carroll Anh Nguyen-Duc Xiaofeng Wang Viktoria Stray
Organization
Conference Chair Xiaofeng Wang
Free University of Bozen-Bolzano, Italy
Program Co-chairs Noel Carroll Anh Nguyen-Duc
University of Galway, Ireland University of South Eastern Norway, Norway
PhD Retreat Chairs Luciana Zaina Abdullah Aldaeej
Federal University of São Carlos, Brazil Imam Abdulrahman Bin Faisal University, Saudi Arabia
Poster Chairs Henry Edison Dimitri Petrik
Blekinge Institute of Technology, Sweden University of Stuttgart, Germany
Proceedings Chair Viktoria Stray
University of Oslo and SINTEF, Norway
Companion Proceedings Chair Jorge Melegati
Free University of Bozen-Bolzano, Italy
Publicity Chair Sonja Hyrynsalmi
LUT University, Finland
Industry Track Chairs Eduardo Guerra Luca Miotto
Free University of Bozen-Bolzano, Italy NOI Techpark, Italy
viii
Organization
Student Volunteer Chair Usman Rafiq
Free University of Bozen-Bolzano, Italy
Local Organizing Chair Dron Khanna
Free University of Bozen-Bolzano, Italy
Program Committee Abdullah Aldaeej Andreas Drechsler Andrey Saltan Anh Nguyen Duc Awdren Fontão Des Greer Dimitri Petrik Dimitris Polychronopoulos Dirk Riehle Dron Khanna Eduardo Guerra Ehsan Zabardast Emma Forsgren Emma Gritt Eriks Klotins Georg Herzwurm Gerardo Matturro Gero Strobel Guenther Ruhe Helena Holmström Olsson Henry Edison Jari Porras João M. Fernandes Johan Linåker John McGregor Jorge Melegati Juergen Muench Kai-Kristian Kemell Kari Smolander Luciana Zaina Marcin Ocieszak
Imam Abdulrahman Bin Faisal University, Saudi Arabia Victoria University of Wellington, New Zealand Lappeenranta University of Technology, Finland University of South Eastern Norway, Norway Federal University of Mato Grosso do Sul, Brazil Queen’s University Belfast, UK University of Stuttgart, Germany University of South Eastern Norway, Norway Friedrich-Alexander University Erlangen-Nürnberg, Germany Free University of Bozen-Bolzano, Italy Free University of Bolzen-Bolzano, Italy Blekinge Institute of Technology, Sweden University of Leeds, UK University of Leeds, UK Blekinge Institute of Technology, Sweden University of Stuttgart, Germany Universidad ORT, Uruguay University of Duisburg-Essen, Germany University of Calgary, Canada University of Malmo, Sweden Blekinge Institute of Technology, Sweden Lappeenranta University of Technology, Finland University of Minho, Portugal RISE Research Institutes of Sweden, Sweden Clemson University, USA Free University of Bozen-Bolzano, Italy Reutlingen University, Germany University of Helsinki, Finland Lappeenranta University of Technology, Finland Federal University of São Carlos, Brazil Kozminski University, Poland
Organization
Marko Seppänen Matthew Ajimati Michael Unterkalmsteiner Narayan Ramasubbu Noel Carroll Pasi Tyrväinen Rodrigo Rebouças de Almeida Rodrigo Santos Salah Ahmed Sami Hyrynsalmi Sjaak Brinkkemper Slinger Jansen Sonja Hyrynsalmi Stephen McCarthy Tommi Mikkonen Usman Rafiq Viktoria Stray Xiaofeng Wang
Sponsoring Organization NOI Teckpark (SFScon)
ix
Tampere University, Finland University of Galway, Ireland Blekinge Institute of Technology, Sweden University of Pittsburgh, USA University of Galway, Ireland University of Jyväskylä, Finland Federal University of Paraíba, Brazil UNIRIO, Brazil University of South Eastern Norway, Norway Lappeenranta University of Technology, Finland Utrecht University, Netherlands Utrecht University, Netherlands Lappeenranta University of Technology, Finland University College Cork, Ireland University of Helsinki, Finland Free University of Bozen-Bolzano, Italy University of Oslo, Norway Free University of Bozen-Bolzano, Italy
Contents
Digital Transformation An Instrument for Evaluating Data-Driven Traffic Management Applications in the Context of Digital Transformation Towards a Smart City . . . Alisa Lorenz, Nils Madeja, and Aynur Cifci
3
Digital Twin Ecosystems: Potential Stakeholders and Their Requirements . . . . . Reshani Liyanage, Nirnaya Tripathi, Tero Päivärinta, and Yueqiang Xu
19
Roadmapping in the Digital Transformation Literature . . . . . . . . . . . . . . . . . . . . . . Ashna Mahmood Zada, John Stouby Persson, and Peter Axel Nielsen
35
Interrelation of Digitalization and Digital Transformation in a Maritime Company . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Rasmus Ulfsnes, Nils Brede Moe, Geir Kjetil Hanssen, and Thor Aleksander Buan Overcoming Barriers to Digital Transformation – Development of a Decision Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Henning Brink, Sven Packmohr, and Fynn-Hendrik Paul
51
67
Business Intelligence and Analytics On the Compliance of Platforms with Children’s Privacy and Protection Requirements - An Analysis of TikTok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Vinícius Polito, George Valença, Maria Wanick Sarinho, Fernando Lins, and Rodrigo Pereira dos Santos
85
Management Accounting Concepts for Inner Source Software Engineering . . . . 101 Julian Hirsch and Dirk Riehle An Investigation of Factors Influencing Online Shopping Behaviors in the Context of China and Australia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Qijun Zhai, Tanjila Kanij, and John Grundy Conducting B2B SaaS Business with a Freemium Model: A Case Study . . . . . . . 134 Teemu Nieminen, Rahul Mohanani, and Pekka Abrahamsson
xii
Contents
Qu¯o v¯adis, Data Business?: A Study for Understanding Maturity of Embedded System Companies in Data Economy . . . . . . . . . . . . . . . . . . . . . . . . 141 Sami Hyrynsalmi, Helena Holmström Olsson, Jan Bosch, and Sonja Hyrynsalmi Digital Platforms and Ecosystems The Role of Actors in Platform Ecosystems: A Systematic Literature Review and Comparison Across Platform Types . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 Martin Kauschinger, Maximilian Schreieck, and Helmut Krcmar Definition of the Enterprise Integration Platforms as a Service—Towards a Common Understanding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 Sonja M. Hyrynsalmi A Systematic Mapping Study of Empirical Research Methods in Software Ecosystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 Larry Abdullai, Hatef Shamshiri, Hasan Mahmud, Muhammad Hamza, Essi Aittamaa, Jaakko Vuolasto, Mikhail O. Adisa, Roope Luukkainen, Sonja M. Hyrynsalmi, Niina Mässeli, Nasreen Azad, Bahalul Haque, Juha-Pekka Joutsenlahti, Wondemeneh Legesse, Ahmed Abdelsalam, Anastasiia Gurzhii, Jouni Ikonen, Slinger Jansen, and Casper van Schothorst Where Does This Feature Belong to? Locating Business-to-Business Features in a Platform Ecosystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 Jaakko Vuolasto and Kari Smolander People and Technology Increasing Employees’ Willingness to Share: Introducing Appeal Strategies for People Analytics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 Valentin Zieglmeier, Maren Gierlich-Joas, and Alexander Pretschner Anti-pattern Detection in Process-Driven Decision Support Systems . . . . . . . . . . 227 Jonas Kirchhoff and Gregor Engels Democratizing Software Development: A Systematic Multivocal Literature Review and Research Agenda on Citizen Development . . . . . . . . . . . . 244 Björn Binzer and Till J. Winkler DevOps Challenges in Organizations: Through Professional Lens . . . . . . . . . . . . 260 Nasreen Azad and Sami Hyrynsalmi
Contents
xiii
Implementing AI Ethics in a Software Engineering Project-Based Learning Environment - The Case of WIMMA Lab . . . . . . . . . . . . . . . . . . . . . . . . . 278 Mamia Ori-otse Agbese, Marko Rintamaki, Rahul Mohanani, and Pekka Abrahamsson Software Startups Towards Understanding How Software Startups Deal with UX from Customer and User Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287 Joelma Choma, Leticia Machado, Cleidson R. B. de Souza, Helen Sharp, Leonor Barroca, and Luciana Zaina The Evolution of Software Startup Research: A Survey of Literature . . . . . . . . . . 304 Karl Hansen, Admir Osmanovic, Benjamin Klerens, and Henry Edison On the Characteristics of Internal Software Startups . . . . . . . . . . . . . . . . . . . . . . . . 320 Anastasiia Tkalich and Henry Edison Gender Bias in the Recruitment Process of IT Startups in the Netherlands . . . . . 328 Tea Šinik, Joeri Snippert, and Slinger Jansen Sustainability Green ICT Adoption and Challenges: Evidence from the Finnish ICT Sector . . . 337 Larry Abdullai, Antti Sipilä, and Jari Porras Digital Transformation Towards Sustainability: A Case Study of Process Views in District Heating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344 Alisa Ananjeva, John Stouby Persson, and Peter Axel Nielsen Author Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
Digital Transformation
An Instrument for Evaluating Data-Driven Traffic Management Applications in the Context of Digital Transformation Towards a Smart City Alisa Lorenz(B)
, Nils Madeja(B)
, and Aynur Cifci
Technische Hochschule Mittelhessen, Wiesenstraße 14, 35390 Giessen, Germany {alisa.lorenz,nils.madeja}@w.thm.de
Abstract. The smart city concept represents an integrated approach for mitigating the challenges resulting from ongoing urbanization by synergizing technology, data, and citizens in a sustainable manner. Smart mobility is an important aspect of a smarty city with intelligent traffic management as one of its key enablers that can contribute to making cities more attractive for living. In this article we focus on data-driven applications for traffic management and develop a new instrument for their evaluation, sharing insights from a municipal project. Drawing on digital business research, evaluation models and expertise from traffic management, we develop criteria and apply them to a Weighted Sum Model, an established modeling technique. As a result, we obtain an easy-to-use instrument for evaluating datadriven applications that can also be adjusted to other contexts. Therefore, both our instrument and the process we employed in its development can support future smart city initiatives in their instrument development and evaluation process. Keywords: Smart city · Smart mobility · Data-driven applications · Intelligent traffic management · Digital transformation
1 Introduction Population growth in cities has been accelerating globally over the last century. Today, already one in two people is living in urban areas, and the population continues to grow with an estimated increase of two billion until the year 2050 worldwide [1]. In addition, humanity is facing further challenges through demographic change, globalization, and climate change. The effects are pollution, public health problems, and mobility constraints, causing a shortage of living space and challenges for social life and coexistence, which affect cities in particular [2]. To meet these challenges, it is crucial to scrutinize the status quo and develop new strategies for living together in cities. This contributes to the sustainable development goals (SDG) of the agenda 2030 which is a mission of the United Nations and aim to “build resilient infrastructure, promote inclusive and sustainable industrialization and foster innovation” (SDG 9) and “make cities and human settlements inclusive, safe,
© The Author(s), under exclusive license to Springer Nature Switzerland AG 2022 N. Carroll et al. (Eds.): ICSOB 2022, LNBIP 463, pp. 3–18, 2022. https://doi.org/10.1007/978-3-031-20706-8_1
4
A. Lorenz et al.
resilient and sustainable” (SDG 11) [3]. The evolution of digitalization provides prospective solutions for those challenges as well as opportunities for the transformation of urban areas. The evolving concept of smart cities aspires to create public value by using advanced technology [4]. The application of sensors and interconnection of electronic devices in combination with intelligent applications enable cities to collect extensive data, resulting in insights for better decision making [5]. However, urban administrations are lacking the expertise and experience to implement digitalization projects and depend on external partners [6]. This paper is a result of “VLUID”, a joint project between the German city of Wetzlar, the Technische Hochschule Mittelhessen and further partners with expertise in mobility. The project is a response to impending traffic chaos and mobility restrictions resulting from an upcoming construction site, planned for 2024 and the following years. The goal of the initiative is to develop new traffic management strategies by using intelligent solutions in the context of a smart city. While there are many established evaluation instruments that support decision making, our project required a specific tool for evaluating data-driven traffic applications. Thus, we created an instrument to encounter this need and make well-grounded decisions for data-driven applications. With this, we hope to contribute to decision making processes within VLUID and other future projects beyond that. Our instrument is adjustable and therefore provides a flexibility to measure all kinds of applications in different smart city environments. In this paper we show the development process of our instrument. Thereby we respond to the following questions: Which are suitable criteria for evaluating datadriven applications for traffic management in the context of a smart city? What can be an instrument to define and measure these criteria? Using conceptual and argumentative-deductive analysis, we investigated different methods of valuation and incorporated subject-specific criteria to deduce our own model. By combining both specialized knowledge from traffic management with scientific and technological frameworks, we identified the key criteria and applied it to an established measuring method. To refine the instrument, we conducted focus interviews with our expert project partners. Based on our findings we will propose a practice-oriented approach that can be adjusted to any evaluation of data-driven smart city applications. Our model can contribute to the decision process of future applications beyond the city of Wetzlar. Hence, in addition to our solution approach we will discuss enhancements of the model and supplementary research to address the limitations and indicate future work.
2 Data-Driven Traffic Management in the Smart City Context 2.1 Smart Cities and Smart Mobility Smart city concepts evolved in the mid-2000s years, yet there is no single commonly accepted definition for the term. Most commonly, smart cities are not only defined as digitalized or intelligent cities, but as urban areas that enhance life quality through
An Instrument for Evaluating Data-Driven Traffic Management Applications
5
intelligent use of innovative technologies [7]. Hence, a clear trend towards sustainable development can be identified. In this paper, we use an existing definition of a smart and sustainable city which is “an innovative city that uses information and communication technologies and other means to improve quality of life, efficiency of urban operation and services, and competitiveness, while ensuring that it meets the needs of present and future generations with respect to economic, social and environmental aspects.” [8]. This definition highlights not only the sustainability aspect but also the importance of combining technology, data, and information to achieve higher standards. The increasing internet penetration and mobile phone use as well as the growth of urban areas in combination with the need to prevent the environment from pollution result in rising social relevance of smart cities [9]. They can counteract problems like pollution, traffic chaos and rising energy consumption with application of modern technology. Finding ways to encounter these challenges especially adds to the Sustainable Development Goals (SDGs) that were passed in 2015 through the global community and aim to ensure a good future for planet Earth, defined by factors like education, energy, economic growth, equality, and sustainability [10]. The concept of a smart city is therefore related to the research areas of information systems and digital business by using the opportunities of technology, software and data while also considering resilience, governance, and sustainability [11]. In this context, a smart city is able to create knowledge, rationality, subjectivity and functionality, making it a “hub of urban development” and enabling new partnerships between government, citizens and residing industry [12]. In this paper we focus on smart mobility as one important element of smart cities. Mobility facilitates social contact as it enables people to meet in person and contributes to social contacts. In addition, it is crucial for trade and logistics. Thus, it is a success factor for urban communities, making it a fundamental part of society [13]. Simultaneously, increasing automobile traffic and vehicle fleet cause pollution, resulting in CO2 emissions and traffic noise that have negative effects on both citizens and the whole ecosystem [14]. Additional healthcare costs, material defects, crop shortfall and environmental damage result in financial strain for state and society. The individual motor car is the preferred form of transportation in Germany with 47% of all traffic that increased by 8% in the last 30 years and still increasing [15]. While the negative effects seem evident, they are still not adequately considered in city and transportation planning. The development of a sustainable, health-oriented, and integrated approach for city and transportation planning is crucial for maintaining a healthy urban environment. The goal of smart mobility in this context is to ensure sustainable, effective, and safe traffic systems by using intelligent infrastructure and traffic management which is the focus of this paper [16]. 2.2 Data-Driven Traffic Management Traffic management is the influence on supply and demand of traffic and tries to influence traffic from its emergence to the target destination. Different measures can positively manipulate the impact of traffic. The main goals of traffic management are ensuring the efficiency and flow of individual traffic as well as increasing traffic safety [17]. Traditional traffic management is now increasingly supported by digitalization which allows for innovative solutions and a modern approach.
6
A. Lorenz et al.
The evolution of digitalization and the internet as a big milestone in the process paved the way for data-driven applications. Especially increasing generation and use of data led to their popularity [18]. Furthermore, the invention of microchips as well as the increasing interconnection and interaction between humans, things and processes through the internet enable new solutions. All those developments contribute to the evolution of innovative mobility concepts. As pointed out, dense traffic in cities is driving multiple negative trends such as climate change and decreasing traffic safety [19]. Intelligent traffic systems provide systems that use information and communication technology for traffic management and communication between modes of transport [20]. A key factor of these systems is the connection of citizens with hardware and software, especially concerning the Internet of Things (IoT). Through technological advances like sensors, innovative solutions such as smart parking applications or intelligent traffic screening are becoming possible. Due to the rise and improvements of artificial intelligence, processing of unstructured data is becoming easier and cheaper. Therefore, large amounts of data can be transformed, processed in real time, and used to derive predictions or recommendations [21]. In summary, digitalization provides extensive chances to rethink and improve traffic management. 2.3 Smart Mobility Applications Several projects and initiatives are already working on smart mobility solutions. We performed an extensive literature review to research the most common and practical concepts that have been established and serve as blueprint for our project. Later in this paper we will consider these applications for development of target criteria and our evaluation model. Following, we introduce some of the concepts: – International Data Spaces (IDS): IDS are multilateral platforms that enable offer and demand of data [22]. Through the secure and easy exchange of data, companies can use the platform and gain insights, e.g., through mobility data or geodata [23]. – Optimized traffic routing: A German project tries to influence citizens in their driving behavior to reduce emissions. By using models for traffic and environmental impact, traffic management measures or gamified mobility applications, traffic and its negative effects are to be minimized [24]. – Smart Parking: On average, drivers in German cities search about 10 min for a parking area, causing 30% of the total traffic volume and the related environmental consequences. Smart parking systems can identify available parking spots in real time and direct drivers to an available spot, reducing searching time [25]. – Advice to drivers: Traffic safety projects are focusing on preventing accidents by informing drivers of current risks that could cause accidents. Applications like “NordicWay” collect data from users and related companies, transforms it and provide information on local safety risks like accidents, building sites, slickness, or weather conditions. These solutions can therefore save lives and additionally reduce traffic jams which has positive impact on health and environment [26]. – Traffic light assistants: Data-driven traffic light applications can predict the recommended driving speed which enables a relaxed but effective driving experience.
An Instrument for Evaluating Data-Driven Traffic Management Applications
7
Through calculating the route ahead and minimizing stop and go, emissions are reduced [27]. Summarizing, a broad variety of data-driven traffic solutions is already available and tested. The challenge for cities that want to transform their traffic management is to choose solutions that fit their needs and solve their individual problems. This stresses the need for an evaluation instrument which we will describe further in the following section.
3 Evaluation Methods Evaluation methods are used to measure and evaluate the achievement of set goals. Innovation or product evaluations are especially focused on determining the success rates, choosing the best solutions, and eliminating less promising options [28]. For the project VLUID evaluation of possible data-driven tools and solutions for traffic management is highly relevant. Useful tools like cameras, sensors and intelligent assistants require high investment costs. In addition, implementation, and extensive testing of these applications take time and involve many resources. Therefore, an exante evaluation of possible solutions is necessary to determine practicable applications fitting to our project needs. In addition, the project also requires regular evaluation in different stages, starting from the idea and selection but also considering the prototyping, the implementation, and the operation phase. Our developed instrument is set to first analyze tools ex ante but should also be able to evaluate ex post during later project phases. Hence, we will also use evaluation methods in other stages to ensure the quality of our solution. This way, we will be able to refine our instrument for future use and make sure that our way forward is still fitting. To achieve this, we developed an instrument for evaluating different data-driven applications with focus on traffic management. We describe our instrument development in the following chapters (Fig. 1).
Fig. 1. Implementation phases and their evaluation
3.1 Comparison of Evaluation Methods Evaluation is a method that supports decision making and is used in project management for comparing different approaches and solutions. With evaluation methods, the degree of fulfillment of certain objectives can be analyzed, contributing to the selection process of alternatives [29]. The primary goal of evaluation is to assess the usefulness of tools and to test technical feasibility for which a systematic and methodical approach is recommended. By using decision models in advance, the failure of new products or
8
A. Lorenz et al.
approaches can be significantly reduced. Formal methods and specific techniques can help in making well-founded decisions. The main functions of evaluation methods are to create transparency, influence the outcome, check certain criteria and to use the result to prepare a decision. A typical evaluation process follows an established scheme: – – – – – –
Analyze the status quo Define dimensions and measurement criteria Define the importance of each criterion (and assign a related a weight) Collect data and define target measures Rate the subject of investigation according to the criteria Examine and conclude the evaluation
Different tools enable such evaluation with the use qualitative, quantitative, or semiquantitative methods [30]. To find a fitting framework, we analyzed several methods and approaches in literature. We found that qualitative methods are suitable for innovations with a low degree of maturity, whereas quantitative methods are suitable for more developed ideas in later stages [31]. Maturity in this context is defined as the degree in which an idea is fully analyzed and already feasible. Another distinction is the differentiation between one-dimensional and multidimensional evaluation. One-dimensional evaluation focuses on only one goal, e.g., cost minimization. However, most ideas and innovations are multidimensional, as they aim to achieve several goals [30]. Evaluation methods can be classified in classical methods, comparative methods, idea expanding methods and financial methods [32]. Measuring instruments can also be grouped by their dimensionality: qualitative and semi-quantitative assessment models belong to the group of multidimensional tools while quantitative tools are one-dimensional [29]. We evaluated different measuring methods according to criteria that were developed by Ahnsen [28] and are especially important to our instrument needs. Our instrument required the ability for a multidimensional analysis, meaning that more than one target should be defined and measured per application. Second, it required broad possibilities of application and ease of use. Third, we wanted to directly compare applications with one another. We applied these criteria to seven different measuring methods and evaluated them on a scale with four different values. The results can be found in Table 1 which served as a preselection for further evaluation. A detailed description and comparison of the methods can be found in Heesen (2009) [29]. – – – – – – –
Verbal argumentation (VA) Checklists (CL) Weighted Sum Model (WSM) Cost-Benefit Analysis (CBA) Prioritization (PR) Statistical Profitability Analysis (SPA) Dynamic Profitability Analysis (DPA)
An important part of our project was to evaluate different applications regarding their individual characteristics. Therefore, we decided for comparative methods since
An Instrument for Evaluating Data-Driven Traffic Management Applications
9
alternatives can be compared with one another, and then ranked and scored. Since datadriven applications cannot be rated by analyzing only one dimension, it is evident that quantitative tools are not eligible. In terms of analysis, we found that semi-quantitative models take both qualitative and quantitative information into account. Specifically, perception of subjective value is transformed into figures for quantification which is an advantage regarding openness. Quantitative criteria measured in monetary units can also be transformed into an ordinary scale, so that different criteria with different dimensions can be included in the assessment [28]. The advantage of semi-quantitative methods is that they are not limited to financial information and require less information for evaluation. In addition, they enable a ranking among the alternatives which allows for a clear comparison of alternatives. A disadvantage is that they are highly subjective since they are based on individual value judgements. Table 1. Comparison of measuring methods. Requirement
VA
CL
WSM
CBA
PR
SPA
DPA
Multidimensional analysis
++
++
++
-
-
--
--
Broad possibilities of application
++
++
+
-
+
-
-
++
++
++
+
+
-
-
-
-
++
-
-
++
++
Ease of use Direct comparability of alternatives
(++ fully applicable || + appliccable || - questionable || -- very questionable) VA: Verbal Argumentation CL: Checklist CBA: Cost-Benefit Analysis PR: Prioritization DPA: Dynamic Pofitability Analysis
WSM: Weighted Sum Model SPA: Statistical Profitability Analysis
The Weighted Sum Model, Cost-benefit analysis, and prioritization belong to the group of semi-quantitative methods which we analyzed further. The Weighted Sum Model allows a multi-criteria evaluation which is especially fitting for comparing alternative applications, while the cost-benefit analysis only analyzes one criterion at a time. In addition, the Weighted Sum Model can be applied during different phases of an innovation process. The Cost-benefit analysis can only be used at the end of an innovation process when monetary information is available, which makes it unfitting for our purpose [28]. We did not consider the prioritization as a third option further since the analysis is very subjective and does not provide enough measuring methods for our purpose. In conclusion, we decided for the Weighted Sum Model as a semi quantitative measuring method. It is a widespread and popular model for decision-making, allowing to compare and prioritize alternatives [33]. It can comprise quantitative but also qualitative criteria and apply them in a multidimensional system.
10
A. Lorenz et al.
4 Instrument Development The first step for developing a Weighted Sum Model is the determination of dimensions and indicators. To be able to measure the benefit of different applications we required not only a framework for measurement but also the corresponding criteria that are described further in the following [34]: Literature Review We performed an extensive literature review to determine target dimensions which would help us identify individual measurement criteria per dimension. To find fitting criteria for our individual purpose, we researched several projects and literature in the context of data-driven traffic management. We then summarized the criteria in a catalogue for the target application. Expert Interviews We used the catalogue of target criteria to test how fitting they are by conducting expert interviews. Subsequently, we assessed the theoretical evaluation criteria regarding their aims and importance with the feedback from experts. We also asked the interviewees to assign a weight to each target dimension to evaluate the importance in the context of all criteria. Synthesis of Findings After collecting insights from literature and the interviews, we derived our final model by combining the target dimensions, the individual criteria, and the weight per dimension. We adjusted our dimensions and the related criteria with the feedback and redistributed weight if necessary. We assembled our findings in the finished evaluation model. Figure 2 summarizes these steps in the process of our instrument development.
Fig. 2. Process of instrument development
4.1 Literature Review A fundamental challenge of evaluation models is calculating realistic and verifiable value [35]. To develop a robust evaluation model, it was important to identify and define measurement criteria that influence the factors describing our applications. We analyzed eight publications that described existing smart city projects and approaches in other cities. Using a literature review with focus on project from Germany and Austria, we derived a table with objectives and criteria that was applied in these projects. Then, we analyzed all publications accordingly and marked the resources in which the objectives and criteria occurred. We summarized the results in Table 2. We use P as an abbreviation for the publications, thus P1-P8 reference the publications analyzed. We added the
An Instrument for Evaluating Data-Driven Traffic Management Applications
11
reduction of financial burdens as another objective to consider the investment costs and the resulting costs for society. Table 2. Target dimensions and individual criteria for evaluation. (P1: Ministerium für Verkehr [19]; P2: Hessen Mobil [36]; P3: Stadt Darmstadt [37]; P4: Nationale Plattform Zukunft der Mobilität [38]; P5: Bundesministerium für Verkehr und digitale Infrastruktur [39]; P6: Landeshauptstadt Wiesbaden [40]; P7: Boltze et al. [17]; P8: Homeier et al. [41]). Target dimension Secure equal traffic participation
Optimize traffic flow
Individual criterion Support individual mobility for all citizens
P1
P2
P3
P4
P5
x
Improve accessibility
x
Prevent congestions
x
P6
x
x
x
2 4
x
x
x
x
x
5
x
x
x
x
x
5
Reduce waiting time
x
x
x
x
x
5
x
x
x
3 x
x
Improve the quality, actuality and availability of information
x x
Enhance the range of alternative traffic routes
x
x x
Strengthen intermodal mobility
1 x
4
x
3
x
x
x
x
x
x
x
x
x
6
Reduce the severity of accidents
x
x
x
x
x
x
6
Increase the acceptance of autonomous vehicles
x
Reduce emissions
x
x
x x
Reduce noise disturbance
x
Reduce traffic-related space requirement
x x
x
2
Reduce the frequency of accidents
Increase attractiveness of e-mobility
x
x
7
x
4
x
x
4
x
x
2
x
x
3
x
x
x
x
x
Strengthen bicycle and foot traffic
x
5
3
x
x
x
x x
Reduce motorized individual traffic
Other
2
Reduce disruptions
Support innovative mobility concepts
Protect the environment
Sum
x
Redirect traffic (time and location)
Increase traffic safety
P8
Reduce traffic overload
Reduce traffic searching for parking
Increase efficiency of the traffic system
P7
x
4 x
Improve the attractiveness of the city
x
1
Standardize payment processes
x
1
Generate data for research
x
x
2
4.2 Expert Interviews The criteria we derived from literature did not fully fit the context of our project. Hence, we conducted expert interviews to gain feedback on them and to incorporate practical views. Especially in new research areas qualitative interviews are a fitting instrument since new insights and information can be obtained this way [42] Interviews allow for a deeper understanding of the research subject, e.g., by describing reasons and motives. Therefore, expert interviews can reveal new points of view or perceptions that have not been considered before. We decided for semi-structured interviews that are often used
12
A. Lorenz et al.
in qualitative research due to their flexibility. We conducted the interviews according to a guideline as orientation while also paying attention on individually mentioned aspects that complemented the draft criteria catalogue. As selecting experts is an important factor in information retrieval, we made sure to find interviewees that are either involved in traffic and transportation related projects or who have experience with digitalization in traffic management. We consulted the persons who have special knowledge regarding a certain topic which they acquired through education, participation in (scientific) communities, experience or interest and involvement in those topics an [43]. We identified five experts who were fitting for our requirements and whom we interviewed. We provided them with a draft version of our instrument and asked them to rate the importance the objectives and criteria. The aim of this procedure is for the interviewees to reflect on the answers they have given and to assign a value to each [44]. We used a scale from one to four where four stands for very high importance and one for irrelevance. For a conclusion we calculated the sum and average of the retrieved data. Following, we summarize the key results from the interviews and refer to the interviewees as I1 to I5 in a random order: – I1 (city council) added the acceptance of citizens as another important criterion. – I2 (smart city project manager) rated “reduce financial burdens” as not fitting. They also would not use the criterion “reduce emissions” because it was not an objective in their opinion. They opted for adding “make traffic controllable” instead. – I3 (professor) recommended to lose the dimensions “increase efficiency of the traffic system” and split the criteria “optimize traffic flow” and “protect the environment”. – I4 (employee for local transport organization) added that subsequent costs must be considered as well as the maintenance (costs) of a solution. – I5 (department head in a traffic authority) estimated “secure equal traffic participation” as less important. The experts were also asked to rate the importance of each target dimension by assigning a weight in the context of all criteria which four of five interviewees did. After the expert interviews, the target dimensions, individual criteria, and weight were modified accordingly, and we limited them to the most important factors. The dimension “secure equal traffic participation” was eliminated and the dimensions “increase efficiency of the traffic system” and “optimize traffic flow” were merged. Consequently, the weight of the dimensions was redistributed. We assigned most of the weight to “optimizing traffic flow” and “protecting the environment” since the interviewees rated them as the most important dimensions. The rest of the weight was distributed over the other dimensions and rounded in increments of five percent afterwards. We combine these findings in Table 3 in the following chapter and show the derived weight per dimension with the related criteria. 4.3 Synthesis of Findings After the definition and testing of evaluation criteria, we applied them in the Weighted Sum Model. The objectives and individual criteria were defined and for each criterion the related weight was applied which resulted from the interviews. We determined a uniform
An Instrument for Evaluating Data-Driven Traffic Management Applications
13
scale for measuring the achievement of the objectives and decided for an ordinal scale that has a minimum value of 1 and a maximum value of 5. Each criterion can be measured differently, hence it is important to define quantitative or qualitative characteristics with their related score beforehand to minimize the influence of bias. For example, reduction of noise can be measured in decibels (dB) and factors like noise, climate and traffic can be monetized. In this specific example, certain noise level reductions could be rated in decibels and applied to the scale from 1–5. After defining the scale for each criterion, the influence of the applications can be measured to apply the related value in the instrument. In Table 3 we illustrate how to use the instrument by showing an exemplary application and applying artificial values. These serve as a demonstration of the instrument and are not derived from a specific application. Table 3. Exemplary evaluation with the instrument for application. Application 1 (example) Target dimension
Criteria
Weight ( )
Prevent congestions
3
Reduce traffic searching for parking
4
Redirect traffic Optimize traffic flow
3 0,3
Strengthen intermodal mobility
5
Make traffic controllable
2
Reduce emmissions
4
Reduce noise disturbance
3
Financial feasibility
2
Promote innovative mobility concepts (E-Mobility, autonomous vehicles, sharing concepts)
0
Strengthen bicycle and foot traffic
3
4,2
2 0,15
Reduce the severity of accidents Investment costs
0,15
Subsequent costs
0 4
0,3
0,9
2
Improve the attracitveness of the city Other
5,7
2 0,3
Reduce motorized individual traffic
Reduce the frequency of accidents Increase traffic safety
2
Improve quality, actuality and availability of information
Reduce traffic-related space requirement Protect the environment
Value
3 0,1
Generate data for research
1,0
Sum
3
0,6
11,7
The calculation of the Weighted Sum is conducted according to the general pattern as follows: Let N be the number of dimensions so that gi with i ∈ [1 … N] denotes the weights per dimension. In addition, let Mi be the number of criteria per dimension i. Further, let xi,j with j ∈ [1 … Mi ] denote the values assigned to the individual criteria. Then the total score is obtained as: A_WSM =
N i=1
gi
Mi j=1
xi,j
14
A. Lorenz et al.
As Table 3 shows, in the case of our specific model N = 5, g = (30%, 30%, 15%, 15%, 10%) and M = (6, 6, 2, 2, 2). The resulting sums according to this instrument can be easily compared for different applications. The evaluation of values per criterion can be done alone or in teams. Group evaluation has the advantage of a discussion and different views. A discussion group with five people and up to twenty criteria is recommended [45].
5 Discussion 5.1 Limitations Although we aimed for a broad analysis of evaluation criteria and tools, our approach has some weaknesses and potential for future work that we would like to address. Semi-quantitative evaluation methods, as well as purely qualitative and quantitative methods are not without limitations. Since the scores represent subjective assessments there might be different outcomes depending on criteria or interview partners. The weighing is subjective and may be biased according to personal preferences. However, full objectivity is hardly possible because of uncertain values and assumptions of the evaluators. The review of criteria is subjective, as some of the interviewees had different experiences and backgrounds. Further limitations arise in the definition of target dimensions, where we did not consider economic and technical aspects as it would make the model too complex, even though they are significant aspects for the investment. Another point is that every city is different and at a different stage of development which makes it hard to find a one-size-fits-all approach. Therefore, the maturity of a city could also be considered. Nevertheless, our instrument is a starting point for cities and municipalities to evaluate the introduction of data-driven traffic management applications. It highlights important criteria for evaluating and selecting applications which could help decision makers in smart city mobility projects. It also contributes to transparent project management since it advocates for documenting and justifying decisions. We suggest our instrument to everyone who works in or with traffic management, e.g., functionaries of municipalities, traffic planners or project managers. Since we described our development process in detail, the instrument can be adapted to specific needs of other projects. 5.2 Implications Future work could evaluate more criteria or conduct further interviews to get a broader view of opinions and estimations. It could also try to make evaluation more objective by adding quantitative evaluation parameters. Environmental factors and costs due to statistics on accidents could serve as a basis for measuring monetary units and applying the results to the model. Also, multiple points in time for evaluation may be considered. We used the tool to perform an ex-ante evaluation but plan to use it additionally for further ex-post evaluation. Depending on the point in time it could also make sense to use different evaluation methods in different stages. The instrument could be enhanced by using checklists or other tools for a combined evaluation. In addition, more interviewees with more diverse perspectives could provide better feedback for the tool, e.g.,
An Instrument for Evaluating Data-Driven Traffic Management Applications
15
by integrating citizens. Also, assessments could be done in broader workshops with more background information which could lead to different outcomes. Another addition would be a sensitivity analysis e.g., by weighing criteria differently to show to which degree results are influenced. It could also show which parameters have a high influence on the results and help to eliminate evaluation errors and inconsistencies in the next step. Further case studies could test the model in different environments. We did not consider the presumed acceptance of citizens of the applications as a criterion but recognize its importance. From our point of view, it should be ensured for all options. Therefore, involving citizens in our project and ensuring their acceptance is the focus of our upcoming project phase. It could be interesting for further research and field studies as well as Citizen Science approaches. Finally, another future field for research could be risk awareness since data-driven solutions are based on the collection and processing of data. This could influence the acceptance of the project and the solutions. Consequently, data protection is especially important and should be considered in any application.
6 Conclusion In this paper we first defined important terms such as smart city, smart mobility and data-driven traffic management. We reviewed several smart mobility projects and applications by conducting a literature review. Through their similarities we identified certain objectives and measurement criteria for evaluation which we enhanced with expert interviews. We applied the criteria to a Weighted Sum Model as measurement instrument of our choice and showed the process of evaluation. Summarizing, our instrument for evaluating data-driven applications is adjustable to different project needs and easy to use. It enables the inclusion of both quantitative and qualitative criteria and is therefore fitting for projects with a lower degree of maturity. The combination of theory with specialized knowledge from traffic management and technological frameworks is a key advantage of our development process. Both our instrument and the process we employed in its development can be adapted for future evaluation processes or taken up for future work in this field. We propose our instrument as an applied approach that can be adjusted to any evaluation of data-driven smart city applications. As proposed in earlier chapters, it is suitable to measure any kind of application from smart parking solutions, smart traffic routing, traffic light assistants or traffic safety applications, to name a few. Even though different by nature, these and other applications can be compared with our instrument to make better founded decisions and decide for specific alternatives in evaluation processes. We therefore hope that our instrument can contribute to the decision process of future applications beyond the city of Wetzlar.
References 1. Loichinger, E., Swianczny, F., Genoni, A., Sander, N., Westermann, R.: Globale Bevölkerungsneticklung. Fakten und Trends. Bundesinstitut für Bevölkerungsforschung, Wiesbaden (2021)
16
A. Lorenz et al.
2. Balova, S., de Velazco, J., Polozhentseva, I., Chernavsky, M., Shubtsova, L.: The formation of the concept of smart sustainable city with the purpose of environmental protection. J. Environ. Manag. Tour. 12(5), 1269–1275 (2021) 3. General Assembly of the United Nations: Resolution adopted by the General Assembly 71/313 Work of the Statistical Commission pertaining to the 2030 Agenda for Sustainable Development. https://ggim.un.org/documents/a_res_71_313.pdf. Accessed 05 Aug 2022 4. Dameri, R.: Smart City Implementation. Creating Economic and Public Value in Innovative Urban Systems. Springer, Cham (2017) 5. Bibri, S.: The IoT for smart sustainable cities of the future: an analytical framework for sensor-based big data applications for environmental sustainability. Sustain. Cities Soc. 38, 230–253 (2018) 6. Bundesinstitut für Bau-, Stadt- und Raumforschung (eds.): Digitalisierung und die Transformation des urbanen Akteursgefüges, Bonn (2017) 7. De Santis, R., Fasano, A., Mignolli, N., Villa, A.: Smart city: fact and fiction. MPRA Munich Personal RePEc Archive, pp. 1–19, Munich (2014) 8. International Telecommunication Union (ITU): Focus Group on Smart Sustainable Cities. https://www.itu.int/en/ITU-T/focusgroups/ssc/Pages/default.aspx. Accessed 03 Aug 2022 9. Dameri, R.: Smart city and value creation. In: Rosenthal-Sabroux, C. (ed.) Smart City - How to Create Public and Economic Value with High Technology in Urban Space, pp. 1–12. Springer, Cham (2014) 10. United Nations: The Sustainable Development Goals Report, 44–49 (2021) 11. Al Nuaimi, E., Mohamed, N.,m Al-Jaroodi, J., Al Neyadi, H.: Application of big data to smart cities. J. Internet Serv. Appl. 6 (2015) 12. Rosati, U., Conti, S.: What is a smart city project? An urban model or a corporate business plan? Procedia – Social and Behavioural Sciences (2016) 13. Flügge, B. (ed.): Smart Mobility. Springer, Wiesbaden (2016). https://doi.org/10.1007/9783-658-14371-8 14. Geravandi, S., et al.: Noise pollution and health effects. Jundishapur J. Health Sci. 7(1), 1–5 (2015) 15. Nobis, C., Kuhnimhof, T.: Mobilität in Deutschland – MiD Ergebnisbericht. Study by Infas, DLR, IVT and infas 365 on behalf of the Federal Ministry for Digital and Transport. Bonn, Berlin (2018) 16. Benevolo, C., Dameri, R.P., D’Auria, B.: Smart mobility in smart city. In: Torre, T., Braccini, A.M., Spinelli, R. (eds.) Empowering Organizations. LNISO, vol. 11, pp. 13–28. Springer, Cham (2016). https://doi.org/10.1007/978-3-319-23784-8_2 17. Boltze, M., Tuan, V.A.: Approaches to achieve sustainability in traffic management. Procedia Eng. 142, 205–212 (2016) 18. D’Onofrio, S., Stucki, T.: Digital public services: Bausteine der digitalen transformation im öffentlichen Sektor. HMD Praxis der Wirtschaftsinformatik 58(5), 958–977 (2021) 19. Ministerium für Verkehr (eds.): Digitale Mobilität - Nachhaltig und digital unterwegs in Baden-Württemberg. https://vm.baden-wuerttemberg.de/fileadmin/redaktion/m-mvi/intern/ Dateien/Brosch%C3%BCren_Publikationen/200625_MfV_Bro_Digitale_Mobilita%CC% 88t_A4_56S_WEB.pdf. Accessed 30 Aug 2022 20. Intelligente Verkehrssysteme Gesetz (IVSG) §2 Nr 1 21. von Lucke, J., Etscheid, J.: Künstliche Intelligenz im öffentlichen Sektor. HMD Praxis der Wirtschaftsinformatik 57(1), 60–76 (2019). https://doi.org/10.1365/s40702-019-00579-6 22. Otto, B., Jarke, M.: Designing a multi-sided data platform: findings from the international data spaces case. Electron. Mark. 29(4), 561–580 (2019). https://doi.org/10.1007/s12525019-00362-x 23. Otto, B., et al: GAIA-X and IDS, International Data Spaces Association, Dortmund (2021)
An Instrument for Evaluating Data-Driven Traffic Management Applications
17
24. Weißbeck, I., Miltner, T., Krampe, S.: Beeinflussung von Verkehrsverhalten durch städtisches Verkehrsmanagement – Anwendung digitaler Daten im Projekt SCHOOL. Wichmann Verlag, Berlin, Offenbach (2020) 25. Schmidt, W., Borgert, S., Fleischmann, A., Heuser, L., Müller, C. Mühlhäuser, M.: Digitale Mehrwertdienste in Smart Cities am Beispiel VerkehrIn: Meier, A., Portmann, E. (eds.) Smart City, pp. 255–274. Springer Fachmedien, Wiesbaden (2016) 26. Dieke, A., Tenbrock, S., Thiele, S., Wielgosch, J.: Innovative Anwendungen mit Mobilitätsdaten: Internationale Fallbeispiele. https://www.bmvi.de/SharedDocs/DE/Anlage/DG/Digita les/mfund-wik-studie-ausland.pdf?__blob=publicationFile. Accessed 20 June 2022 27. Urban Software Institute: [ui!] ECOMAT, https://ecomat.ui.city. Accessed 20 June 2022 28. Ahsen, A. (ed.): Bewertung von Innovationen im Mittelstand. Springer, Heidelberg (2010) 29. Heesen, M.: Innovationsportfoliomanagement: Bewertung von Innovationsprojekten in kleinen und mittelgroßen Unternehmen der Automobilzulieferindustrie. Gabler, Wiesbaden (2009) 30. Vahns, D., Brem, A.: Innovationsmanagement. Von der Idee zur erfolgreichen Vermarktung, Schäffer-Poeschel, Stuttgart (2015) 31. Ulrich, M., Bachlechner, D.: Wirtschaftliche Bewertung von KI in der Praxis – Status Quo, methodische Ansätze und Handlungsempfehlungen. HMD Praxis der Wirtschaftsinformatik 57(1), 46–59 (2019). https://doi.org/10.1365/s40702-019-00576-9 32. Wahren, H.: Erfolgsfaktor Innovation. Springer, Heidelberg (2004) 33. Hanusch, H.: Nutzen-Kosten-Analyse. Vahlen, München (2011) 34. Kunz, C.: Strategisches Multiprojektmanagement: Konzeption. Methoden und Strukturen. Deutscher Universitätsverlag, Wiesbaden (2007) 35. Kühnapfel, J.: Scoring und Nutzwertanalysen: Ein Leitfaden für die Praxis. Springer Fachmedien Wiesbaden, Wiesbaden (2021) 36. Hessen Mobil - Straßen- und Verkehrsmanagement (eds.): Verkehrsmanagement Region Frankfurt RheinMain - Leitfaden zur Anwendung. Hessen Mobil, Straßen- und Verkehrsmanagement, Wiesbaden (2014) 37. Stadt Darmstadt (ed.): Strategie der Digitalstadt Darmstadt. https://www.de.digital/DIG ITAL/Redaktion/DE/Stadt.Land.Digital/Strategien/strategie-der-digitalstadt-darmstadt. html. Accessed 20 June 2022 38. Nationale Plattform Zukunft der Mobilität: Maßnahmen zur Digitalisierung der Verkehrsinfrastruktur. Bundesministerum für Verkehr und digitale Infrastruktur, Berlin. https://www.pla ttform-zukunft-mobilitaet.de/wp-content/uploads/2020/12/20201210-NPM-Bericht-AG3DVI-final.pdf. Accessed 28 July 2022 39. Bundesministerium für Verkehr und digitale Infrastruktur: Bundesverkehrswegplan 2030. https://www.bmvi.de/DE/Themen/Mobilitaet/Infrastrukturplanung-Investitionen/Bun desverkehrswegeplan-2030/bundesverkehrswegeplan-2030.html. Accessed 17 July 2022 40. Landeshauptstadt Wiesbaden (eds.): VEK Wiesbaden 2030. https://www.wiesbaden.de/ leben-in-wiesbaden/verkehr/verkehrsentwicklung/verkehrsentwicklungsplan-2030.php. Accessed 17 July 2022 41. Homeier, I., Pangerl, E., Tollmann, J., Daskalow, K., Mückstein, G.: Smart City Wien Rahmenstrategie 2019–2050. https://www.wien.gv.at/stadtentwicklung/studien/pdf/ b008551.pdf. Accessed 28 July 2022 42. Dresing, T., Pehl, T.: Praxisbuch Interview, Transkription & Analyse: Anleitungen und Regelsysteme für qualitativ Forschende, pp. 6–8. Eigenverlag, Marburg (2018) 43. Helfferich, C.: Leitfaden-und Experteninterviews, pp. 570–571. In: Baur, N., Blasius, J. (eds.) Handbuch Methoden der empirischen Sozialforschung, Springer Gabler, Wiesbaden (2014)
18
A. Lorenz et al.
44. Bradburn, N., Sudman, S., Wansink, B.: Asking questions: the definitive guide to questionnaire design-for market research, political polls, and social and health questionnaires, pp. 126–127. John Wiley & Sons, San Francisco (2004) 45. Kühnapfel, J.: Scoring und Nutzwertanalysen: Ein Leitfaden für die Praxis, p. 77. Springer Fachmedien Wiesbaden (2021)
Digital Twin Ecosystems: Potential Stakeholders and Their Requirements Reshani Liyanage1 , Nirnaya Tripathi1(B) , Tero Päivärinta1,2 , and Yueqiang Xu1 1 M3S Research Unit, University of Oulu, Oulu, Finland {nirnaya.tripathi,yueqiang.xu}@oulu.fi, [email protected] 2 Digital Services and Systems, Luleå University of Technology, Luleå, Sweden
Abstract. Context: As industries are heading for digital transformation through Industry 4.0, the concept of Digital Twin (DT) - a software for digital transformation, has become popular. Many industries use DT for its advantages, such as predictive maintenance and real-time remote monitoring. Within DT domain, an emerging topic is the concept of an ecosystem—a digital platform that would create value for different stakeholders in an ecosystem of DT-driven products and services. The identification of potential stakeholders and their requirements provides valuable contributions to the development of healthy Digital Twin Ecosystems (DTE). However, current empirical knowledge of potential stakeholders and their requirements are limited. Objective/Methodology: Thus, the objective of this research was to explore potential stakeholders and their requirements. The research employed an empirical research methodology in which semi-structured interviews were conducted with DT professionals for data collection. Results: Data analysis of the study revealed 13 potential stakeholders who were categorized as primary (manufacturers, suppliers, subcontractors, and intelligent robots), secondary (maintenance service providers, platform integration service providers, tech companies, etc.), and tertiary (research organizations, third-party value-added service providers, cyber security firms, etc.). This study also presents the different requirements of these stakeholders in detail. Contribution: The study contributes to both research and industry by identifying possible stakeholders and their requirements. It contributes to the literature by adding new knowledge on DTEs and fills a research gap while contributing industry by providing ample knowledge to the industry’s practitioners that is useful in the development and maintenance of a healthy DTE. Keywords: Digital twin · Ecosystems · Stakeholders · Industry 4.0
1 Introduction In today’s highly competitive industrial environment, industries are seeking digital transformation through Industry 4.0, which offers a competitive edge for organizations by improving processes and products through embracing new technologies [1]. In this aspect, DTs which act as a software for digital transformation have become a promising and emerging area of technological focus through which industries can gain a number © The Author(s), under exclusive license to Springer Nature Switzerland AG 2022 N. Carroll et al. (Eds.): ICSOB 2022, LNBIP 463, pp. 19–34, 2022. https://doi.org/10.1007/978-3-031-20706-8_2
20
R. Liyanage et al.
of benefits, such as foreseeing problems in the development processes and the ability to give early warnings [2]. The initial concept of DT was brought to attention by Michael Grieves in 2002 [3] and, later, the term “digital twin” was put forward by NASA in their integrated technology roadmap [4]. DT was defined in [5] as; “a multi-physical, multi-scale, and probabilistic simulation model of a complex product. It uses updated sensors and physical models to mirror physical life in the digital world and vice versa” [5].
Due to DTs’ vast number of advantages, such as developing novel prospects and designing enhanced devices and products by means of digital representations [6], its applications can be seen in number of areas, including manufacturing, healthcare, industrial Internet of Things (IoT) environments, automobiles, retail, smart cities, etc. Another critical advantage of DTs is that they can integrate information from multiple sources and scales in real time from physical entities and then create a living model of the physical entity that can be used for predictive maintenance [7]. To cater these benefits, it uses a number of emerging technologies, such as artificial intelligence, deep learning, machine learning, and other trends, such as the IoT and big data [6]. Furthermore, to boost the improvement of the product and service development processes and to identify and develop novel product-service systems (PSS), the concept of the DT ecosystem (DTE) has been put forward [8]. In the same study, the authors stated that the DTE is a digital platform based on DTs that would help in product design and lifecycle management by creating value through an ecosystem of twin-driven products and services. The authors in [8] defined the DTE as: “an interconnected multiple instances of a digital twin or different digital twins that have been arranged into value networks using the different enabling technologies for digital twins”. [8]
Further, this concept would lead industries to achieve real-time prediction and repeated and continuous optimization of the different parameters in a system by providing intelligent optimization instructions [9]. Thus, an ecosystem will enable stakeholders to collaborate and exchange digital artifacts, which will be done in a dynamic way and generate mutual benefit [10]. 1.1 Problem Statement and Research Objectives Tsujimoto et al. in [11] mentioned that, in an ecosystem these interconnected stakeholders play an important role in providing better products and services to the customers as well as contributing to deriving value within the ecosystem. As such in a digital twin ecosystem these identified new stakeholders and their requirements can add value in a number of ways. However, the empirical research work on potential stakeholders and their requirements is limited and needs attention [12]; as most of the research is focused on the application of DTs in various industries and the use of different technologies
Digital Twin Ecosystems: Potential Stakeholders and Their Requirements
21
in developing DT applications. In this stance, this research aims to conduct an empirical study with the research objective of identifying potential stakeholders and their requirements in the DTE. The paper is divided into the following chapters. Section 2 discusses the background literature, and Sect. 3 describes the empirical study. The results, discussion, and conclusion are presented in subsequent chapters.
2 Background Literature 2.1 Industry 4.0 and Digital Twins Given the increasingly competitive nature and the need to recreate value in global industrial networks, Industry 4.0 (I4.0) has recently become a buzzword in both academia and practice [13]. While Industry 3.0 is more about the digital transformation of industrial facilities, I4.0 signifies that it is more data-oriented, with a higher degree of focus given to large amounts of data generated in industrial processes and communications between machines. In I4.0, the focus is on processing this data to generate useful information that could be used in industrial environments [14]. I4.0 is a revolution that unleashes a number of benefits for industries in the process of digital transformation. These include the reduction of costs, improved quality of products, increased scalability, and achieving a higher level of flexibility in production facilities. Further, this new paradigm also enables organizations to respond to defects and deviations in a faster and more effective way so that the product or production improvements are self-adjusting [13]. These benefits of I4.0 are derived using modern technologies, such as the IoT, Artificial Intelligence, Cyber Physical Systems (CPS), DTs, cloud computing, and big data, etc. [15]. CPS is significant for achieving virtualization. On top of this, DTs add a greater value by providing real-time monitoring capabilities of these real-world systems, and thus play an important role in the context of I4.0, allowing smart products and manufacturing systems to provide a more competitive advantage to the industries [15]. 2.2 Digital Twin Ecosystems (DTE) and Stakeholders An ecosystem is composed of different facilities and parties and includes the data generated by each party in the ecosystem [8]. When analyzing the literature on DTEs, it can be seen that there is another definition for DT ecosystems than the definition mentioned in the introduction above. In these studies, the authors considered a DTE to be an environment that includes a single DT, its sensors, the technologies used, and the users [16, 17]. Thus, going forward in this research, the authors will consider the definition proposed by [8] for DTE: an interconnected multiple instances of a digital twin or different digital twins that are connected to each other using different technologies to form a value network. This concept could lead industries to achieve real-time prediction and repeated and continuous optimization of the different parameters in a system within the ecosystem. Furthermore, this could enable advanced risk warnings, fault detection, and the provision of intelligent optimization instructions for different categories of workers, such as system operators, maintenance workers, etc. [9].
22
R. Liyanage et al.
The stakeholders in the ecosystem have different objectives, and their decisionmaking criteria can differ [11]. Additionally, the same study mentions that the decisions and behaviors of one stakeholder affect the other, and this ultimately affects the evolution and decline of the ecosystem. Thus, the identification of potential stakeholders and their requirements provides valuable insights for the management of stakeholders within DTEs and ultimately generate better value within the DTEs.
3 Empirical Study As we aim to identify stakeholders and their requirements, which involve human interaction, we need to get perspectives of those who are involved in the DTE in qualitative form to draw realistic information to achieve our aim. Therefore, empirical research methodology was selected for our research. In software engineering, interviews, questionnaires, and observations are different ways of conducting this type of empirical study [18]. In this study, semi-structured interviews were conducted with experienced DT practitioners to collect the empirical data. Accordingly, two research questions were framed as mentioned in Sect. 3.1 to achieve the study objectives and basis for our empirical research. 3.1 Research Questions (RQs) RQ1: Who are the potential stakeholders that will be involved in the digital twin ecosystem? RQ2: What are the requirements of these stakeholders for their involvement in this digital twin ecosystem? 3.2 Empirical Data Collection To collect the qualitative data, interviewees were selected through our industrial research project Oxilate (https://itea4.org/project/oxilate.html), in which they are working together to develop DT solutions. This project is aimed at developing DTs that will be used by these companies. For example, companies C2, C3, and C5 are working in a DTE, and the other companies are planning to expand to the DTE level. The general information for the interviewees in this research is shown in Table 1. To ensure anonymity, interviewees are referred to as I, while companies are referred to as C. Initially, in this research, an interview script was developed that included a set of warm-up, general (DT utilization specific), future-oriented (on DTE), follow-up, and wrap-up questions. The interview timing was set to one hour, and all the interviews were conducted and recorded online using MS Teams. These recordings were then transcribed to obtain the data. As per Table 1, almost all the interviewees had experience and knowledge regarding DTs. Furthermore, the participants were from different companies in three geographic locations that engaged in the development of DTs at different levels. This selection of study participants ensured that the collected empirical data aligned with the research objectives.
Digital Twin Ecosystems: Potential Stakeholders and Their Requirements
23
Table 1. Information about the Interviewees Interviewee (I)/Company (C)/Location Interviewee Experience Related to DT I1/C1/Belgium
Working in the company for 1.5 years as a machine learning research engineer. Mainly worked in contributing to different machine-learning-related projects and solutions used in development of DT
I2/C1/Belgium
Research manager working on developing simulation software, test software, and hardware used in different industries, such as automobile, aerospace, etc. He also had experience in developing various product and performance DTs developed in the company
I3/C2/Turkey
A software engineer, working in the company for about 1.5 years in the research and development department. The interviewee had been working on different DT projects in the automotive and food sectors
I4/C2/Turkey
Software engineer working to develop DTs for a factory in the automotive sector and a food factory
I5/C3/Turkey
Consultant with more than 10 years of experience in the IT field and currently trying to guide digital transformation and consulting with the software company, which is creating DT software for an automotive company
I6/C4/Finland
Working as a research director in one of the major software development and automation companies in Finland and has built prototypes related to digital twins
I7/C5/Finland
A senior data scientist working in a Finnish technology company for more than three years. Has been engaged in producing data-oriented solutions in which the data is analyzed to provide solutions based on data from DTs to optimize and make the process more efficient, more reliable, and to spot the possible anomalies and problems beforehand
I8/C6/Finland
Has been in a company that developed software as well as provided consultancy services for industries and public sector organizations focusing on the medical sector since 2008. Experience in developing DT systems in the automotive industry for testing autonomous vehicles
3.3 Data Analysis Procedure(s) Before the extraction of data from the interviews, the audio files were transcribed. After which the data was extracted into a spreadsheet for data analysis and then manually
24
R. Liyanage et al.
coded. The authors reviewed the extracted data several times to identify all possible codes for the study. In this study, an inductive coding approach was used, where the codes and themes were generated from the extracted data itself [19]. For example, in the text extracted below from one of the interviewees, we found that a sub-contractor (see Table 2 also) could be a potential stakeholder in DTE. “I think digital twin ecosystem, will enable a lot of different kind of development, when you don’t have to have access to a physical device or machinery. You can create solutions without ever seeing the actual end-use machinery or environment. So, I think it helps the subcontractors to provide services for this kind of environments.” This approach was used to identify all possible codes that existed in the extracted data. Later, these codes were aggregated into the main themes of stakeholders (Sect. 4.1) and requirements (Sect. 4.2). The aim was to structure the extracted data so that they could be adopted in reporting the state-of-the-art research results of the study. 3.4 Study Validity The validity and reliability of the research results can be assessed according to four main criteria for evaluating the quality of research design proposed in [20]. The evaluation criteria consist of construct validity, internal validity, external validity, and reliability. • Construct validity: To establish construct validity in this study, an interview script was designed and developed to reflect the RQs. Further, this research collected data from eight different semi-structured interviews with eight different participants who had experience with DT, such that it added insights from different points of view. Any inaccuracies in the data caused by the influence of interviewers have been minimized by conducting several interviews. Therefore, some threats to construct validity were minimized in the study. • Internal validity: This is not directly related to this study since this research does not focus on identifying causal relationships. • External validity: The study presents a generic but versatile look at different stakeholders who would be there when moving to the DTE level as well as their requirements from different perspectives. Since the study comprises an empirical study with different interviews from different companies, this reduces the possible opportunities for bias in results that would have been present if the research were focused on one interview or one company. Thus, the results of the study cannot be applied in all contexts, as the interviewees were from different industries and locations. • Reliability: To achieve reliability, this empirical study has described the research process and how the data has been analyzed to answer the RQs. However, there is a possibility that another researcher might identify different results, as the data gathered from semi-structured interviews can change depending on the interaction between the interviewer and interviewees, the situation, and the accumulated knowledge of the interviewee at the time. As such, there is a possibility that the results from the empirical study could be changed if repeated.
Digital Twin Ecosystems: Potential Stakeholders and Their Requirements
25
4 Results 4.1 Identified Potential Stakeholders in DTEs (Answer to RQ1) Based on the data gathered from the semi-structed interviews, thirteen different potential stakeholders were identified (as shown in Table 2 below) who could be involved in the DTE by providing their various services. Table 2 also shows the different roles played by these stakeholders in the DTE. Table 2. Stakeholders and their roles within the ecosystem Identified stakeholder
Role
Intelligent robots
React based on the feedback from the DT. This feedback could be about possible deviations/abnormalities in the processes or any other instructions. This enables real-time responses to these deviations in the systems in the DTE
Manufacturers (develops products and services)
Use DT within the organization to monitor products and processes, and for communication with external parties such as suppliers, subcontractors, etc., for sharing related information withing the DTE
Physical asset suppliers such as manufacturers Develop intelligent robots/machines used by of intelligent robots/machines the manufacturer’s companies within the DTE Subcontractors
Conduct subcontract work from other partners such as manufacturers and use DTs to share information with the related party
Platform integration service providers
Integrate different DT systems and equipment of different stakeholders within the DTE and enable them to share data and work together
Third-party value-added service providers (AI Use big data generated within the DTE and engineers, data scientists, developers) perform analytics to gain more knowledge that will give a competitive advantage, direct improvements of processes and systems, and generate new business models used by the stakeholders in the ecosystem External maintenance service providers
Provide maintenance for the physical systems/machines used by the manufacturer based on the feedback in intelligent instructions by data generated from DTs (continued)
26
R. Liyanage et al. Table 2. (continued)
Identified stakeholder
Role
Suppliers
Provide raw materials to manufacturers and use DT for sharing related information on supplies
Cyber security companies
Monitor the DT systems to ensure that the ecosystem is not vulnerable to cyber-attacks and take necessary remedial actions in the case of cyber-attacks
Tech companies
Develop DTs to be used by different ecosystem participants
Consultancy firms
Provide consultations for manufacturer/supplier for product, process, and service improvements based on information from the DTs
Research organizations
Conduct research and collect data for studies that will impact improvements and development of the DTE research area
Government, legal authorities
Government authorities, such as legal and regulatory authorities, can engage in the ecosystem by setting up standards, deriving policies, etc., that govern the ecosystem as well as the use of data from the DTE for providing services
4.2 Stakeholder Requirements in the DTE (Answer to RQ2) Based on the analysis of data from the interviews as shown in Table 3, the following requirements of the stakeholders can be identified, which the stakeholders expect in terms of benefits and capabilities when joining the ecosystem. These different requirements of the stakeholders would lead and direct them to use the DTs within the ecosystem, and also for them to engage in this ecosystem. Furthermore, understanding stakeholder roles will make it easy to understand stakeholder requirements, as shown in Table 3.
Digital Twin Ecosystems: Potential Stakeholders and Their Requirements
27
Table 3. Stakeholders and their requirements Stakeholders
Requirements for Engaging in DTE
Manufacturers
• To gain information on processes and system defects and respond to them in real time while ensuring and monitoring processes are operating under required conditions • To enable real-time coordination with other partners • To gain information and insights to create new products and services through the use of data from DTs • To gain information on processes and systems to make them more efficient through the analysis of DT data
Suppliers
• To identify supply needs in real time, and gain and share information on quantity and quality of supplies using DTs
Subcontractor
• To gain and share information on subcontract work and share information on predesign models, actual work, etc., among the parties in a real-time and dynamic manner
Intelligent robots
• To gain real-time and beforehand information of processes/products regarding the deviations/abnormalities that need to be responded to in real time so that the systems work properly with minimum issues and downtime • To gain instruction on necessary actions in situations of deviations in physical systems
Tech companies that develop DTs (might not use DTs)
• To gain information about products, processes, and systems of DT use for system development • Quick access to data for system maintenance
Maintenance service providers of physical systems
• To gain necessary information and access for monitoring the health of machines and real-time response to any issues • To have real-time access to information to identify upcoming maintenance requirements and provide predictive maintenance • To gain information for making future improvements and upgrades in machines through data analysis (continued)
28
R. Liyanage et al. Table 3. (continued)
Stakeholders
Requirements for Engaging in DTE
Platform integration service providers (might • To gain information about different systems not use DTs) and equipment used by stakeholders that needs to be integrated Consultancy companies
• To gain information to provide insights for products, processes, and service improvements and create more value to their partner
Physical asset suppliers for manufacturer
• To obtain information and monitor the health of the machines/robots in real time through the use of DTs • To gain information for making improvements/upgrades to these physical assets, such as machinery/ robots for better performance
Cyber security firms (might not use DTs)
• To gain security-related information and monitor the vulnerability of the systems to cyber-attacks and improve the safety of the system and its data • To gain information about cyberattacks for taking remedial actions and ensuring system safety
Third-party value-added service providers
• To obtain big data within the DTE to perform analytics, from which ecosystem participants gain competitive advantage
Research organizations (do not use DTs)
• To collect data for research that impacts the improvement and development of DTEs
Government authorities (might not use DTs)
• To have easy and quick access for the information required for activities such as taxation, development laws and standards on services provided in the ecosystem and to enable ecosystem governance
5 Discussion 5.1 Potential Stakeholder Mapping in DTE This study identifies 13 different stakeholder groups (see Table 2) which we classified here as primary, secondary, and tertiary stakeholders based on the level at which they are operating within the ecosystem, as shown in Fig. 1. • Primary stakeholders: In the diagram (Fig. 1), there are primary stakeholders in the center who engage in the value chain level of the organization (such as manufacturers, suppliers, subcontractors) and internal stakeholders (such as intelligent robots).
Digital Twin Ecosystems: Potential Stakeholders and Their Requirements
29
Fig. 1. Stakeholder mapping and their interactions within the ecosystem
• Secondary stakeholders: These stakeholders include maintenance service providers, platform integration service providers, tech companies, physical asset providers, and consultancy service providers. These stakeholders provide different services to the primary stakeholders that support and enhance the provision of the services by the primary stakeholders. • Tertiary stakeholders: The most external are the tertiary stakeholders, who interact with different stakeholders within the ecosystem in different levels with various levels of interest from the participants. Also, these stakeholders would use data from the overall ecosystem. These stakeholders include third-party value-added service providers, cyber security firms, government authorities, and research organizations. • Relationships between stakeholders: Figure 1 also shows the interactions among the different stakeholders. The direct straight lines show the primary interactions among the stakeholders, while the dashed lines show the possible secondary interactions among the stakeholders. When developing and managing healthy DT ecosystem, it is
30
R. Liyanage et al.
important identify these interactions carefully and facilitate them. This would eventually lead to satisfy most of the stakeholder requirements identified above. For example, maintenance service provider who is a secondary stakeholder is interacting with the manufacturer. From Table 3 it is clear that the intention of this interaction to share the information on health of physical systems and provide intelligent maintenance feedback on system maintenance. For this it is important that the maintenance service providers have real time information transmission to facilitate their services. Thus, by identifying these interactions and requirements of the stakeholders, organizations could identify other infrastructure requirements and challenges they would need to face when developing these DTEs. • Stakeholders’ motivations: Through data analysis, it is evident that different stakeholders engaged in the ecosystem have different interests in terms of their requirements. Although their main requirement was to seek information, this information was used to derive some capabilities within the ecosystem, such as having efficient and flexible processes that are more resilient, providing better offerings to the customer, reacting to defects and deviations faster, providing predictive maintenance, conducting better research, and deriving better policies by governments. 5.2 Implications for Research Previous literature on the context of DTEs identified stakeholders such as suppliers and subcontractors [10, 21]. Further, previous research also identified stakeholders such as government organizations, research organizations, and external analytic service providers that could be considered new stakeholders at the ecosystem level [21–23]. However, in this empirical research, the authors were able to identify another seven significant potential stakeholders in the ecosystems level of DTs, who were not specified in the previous literature. These stakeholders include intelligent robots, external maintenance service providers, physical asset suppliers (such as suppliers of robots and machinery), tech companies developing DTs, consultancy service providers, platform integration service providers, and cyber security firms. Further, the study presents the different requirements of these stakeholders and their roles and interactions with each other in the ecosystem. Apart from the identification of the potential stakeholders, this study contributes to the literature on DTEs by identifying and describing in detail the stakeholder requirements as well as the interactions and relationships that can be inferred through these interactions. Previous literature hardly discusses these in the context of DTEs, which makes this study significant in terms of the literature on DTEs and stakeholders. This knowledge can be used by researchers in their future studies on DTEs. 5.3 Implications for Practice In any ecosystem, the co-creation of value depends on the stakeholders engaging in it. Thus, the identification of possible stakeholders through this study helps organizations decide which stakeholders should be involved in the ecosystem to generate the highest possible value, based on the different services they provide. For example:
Digital Twin Ecosystems: Potential Stakeholders and Their Requirements
31
• Intelligent robots can be used in future smart manufacturing environments to streamline the manufacturing process to operate much faster and with higher accuracy [24]. • Artificial intelligence-based robots can be used to improve manufacturing processes by providing enhanced monitoring and auto-correction of the processes in the manufacturing environment. As such, these intelligent robots will be capable of selfconfiguring, self-adjusting, and self-optimizing through data from DTs [25]. Thus, they will make manufacturing processes more resilient. • Platform integration service providers could enable systems and applications from different stakeholders to integrate easily. Thus, these service providers could provide standard protocols, application programming interfaces (APIs), and automated tools in this stance [26]. • Physical asset suppliers—such as manufacturers of machinery and robots, are also an integral part of this ecosystem that will enable the improvement of manufacturing systems and processes by providing efficient and adaptive machinery and robots that will improve manufacturing processes within these organizations. As such, it can be seen that these stakeholders within the DTE provide a number of services to the ecosystem partners in the digital transformation of their systems, processes, and organizations. This study will help companies understand how these stakeholders contribute to deliver value in the ecosystem by playing different roles. This will also help the companies understand how the different stakeholders will interact with each other and their relationships. For example, as shown in Fig. 1, manufacturers interact with many stakeholders, such as suppliers, intelligent robots, subcontractors, platform integration service providers, etc., while maintenance service providers interact with manufacturers. Furthermore, the stakeholders in this ecosystem have different requirements, as discussed in this study, and their decision-making criteria can be different from each other. The decisions and behavior of one stakeholder affect another, and this ultimately affects the evolution and decline of the ecosystem. Thus, this knowledge about stakeholder requirements, interactions, and relationships will help manage these stakeholders properly within the ecosystem. Through this study, industries and practitioners benefit by enabling them to gain ample knowledge that helps in the design and development of a healthy DTE while satisfying stakeholder needs. Companies could use this study to identify the different possible stakeholders within a DTE, and the study enables the understanding of what the roles and requirements of these stakeholders are, and how these stakeholders interact with each other—through which their relationships can be understood. As a whole, this study will ease the process of digital transformation while giving fruitful results for organizations intending to develop DTEs or are already a part of such DTE.
6 Conclusion The focused area of research in this study (DTEs) is still in its infancy; only a few studies are available in this domain. The objective of this research was to generate new knowledge and fill this research gap in DTEs with regard to the identification of possible
32
R. Liyanage et al.
stakeholders and their requirements to provide a broader view of this ecosystem. As such, the authors conducted an empirical study to answer the research questions. After a comprehensive analysis and synthesis of the data, the following results were achieved from the study. • Identification of 13 possible stakeholders within the DTE, in which the study identified seven new stakeholders other than those mentioned in the existing literature. These new stakeholders are intelligent robots, maintenance service providers, consultancy service providers, physical asset suppliers, platform integration service providers, tech companies and cyber security firms. • Further, this study has analyzed and discussed the different requirements of these stakeholders in detail, which will generate valuable insights and contribute knowledge to the existing literature and well as the industry. 6.1 Study Limitations and Future Work The study may have the following limitations owing to the nature of the study and its participants. The interviews were designed as semi-structured, with open-ended questions so that there were no specific answers to these questions. Thus, the focus of each participant may change. Since the ecosystem perspective of DTs is not quite familiar to the all the participants, there is a possibility that the participants misunderstood the questions and that they also provided answers based on imagination due to a lack of experience with DTEs. Hence, there is always the possibility that the answers they provided could be subjective and biased, depending on their knowledge and experience. The interviews were conducted in English. As such, some Finnish participants had issues articulating their ideas in English. This may have had some impact on expressing ideas, which would, in turn, impact the quality of the data gathered from interviews. Future research can be done to further compare the stakeholders identified from the empirical study to those identified with the literature, and this can be further expanded to identify the possible challenges when moving from the value chain level to the ecosystem level in the DTE. Acknowledgement. This study was part of Oxilate ITEA3 project (https://itea4.org/project/oxi late.html) funded by Business Finland.
References 1. Rocha-jácome, C., Carvajal, R.G., Chavero, F.M., Guevara-cabezas, E., Fort, E.H.: Industry 4.0: a proposal of paradigm organization schemes from a systematic literature review. Sensors 22 (2022). https://doi.org/10.3390/s22010066 2. Xu, Y., Päivärinta, T., Kuvaja, P.: Digital twins as software and service development ecosystems in Industry 4.0: towards a research agenda. In: Tian, Y., Ma, T., Khan, M.K. (eds.) ICBDS 2019. CCIS, vol. 1210, pp. 51–64. Springer, Singapore (2020). https://doi.org/10.1007/978981-15-7530-3_5
Digital Twin Ecosystems: Potential Stakeholders and Their Requirements
33
3. Grieves, M., Vickers, J.: Digital twin: mitigating unpredictable, undesirable emergent behavior in complex systems. In: Kahlen, F.-J., Flumerfelt, S., Alves, A. (eds.) Transdisciplinary Perspectives on Complex Systems, pp. 85–113. Springer, Cham (2017). https://doi.org/10. 1007/978-3-319-38756-7_4 4. Rosen, R., Von Wichert, G., Lo, G., Bettenhausen, K.D.: About the importance of autonomy and digital twins for the future of manufacturing. IFAC-PapersOnLine. 28, 567–572 (2015). https://doi.org/10.1016/j.ifacol.2015.06.141 5. Durão, L.F.C.S., Haag, S., Anderl, R., Schützer, K., Zancul, E.: Digital twin requirements in the context of Industry 4.0. In: Chiabert, P., Bouras, A., Noël, F., Ríos, J. (eds.) PLM 2018. IAICT, vol. 540, pp. 204–214. Springer, Cham (2018). https://doi.org/10.1007/978-3-03001614-2_19 6. Augustine, P.: The industry use cases for the Digital Twin idea. Elsevier Inc. (2020). https:// doi.org/10.1016/bs.adcom.2019.10.008 7. Wang, T., Liu, Z., Liao, M., Mrad, N.: Life prediction for aircraft structure based on Bayesian inference: towards a digital twin ecosystem. In: Proceedings of the Annual Conference on Prognosis Health Management Soceity PHM 12, 1–8 (2020). https://doi.org/10.36001/phm conf.2020.v12i1.1261 8. Silva, H.D., Azevedo, M., Soares, A.L.: A vision for a platform-based digital-twin ecosystem. IFAC-PapersOnLine 54, 761–766 (2021). https://doi.org/10.1016/j.ifacol.2021.08.088 9. Yan, X.: Construction of digital twin ecosystem for coal-fired generating units. J. Phys. Conf. Ser. 1748 (2021). https://doi.org/10.1088/1742-6596/1748/5/052037 10. Rosen, R., Fischer, J., Boschert, S.: Next generation digital twin: an ecosystem for mechatronic systems? IFAC-PapersOnLine. 52, 265–270 (2019). https://doi.org/10.1016/j.ifacol. 2019.11.685 11. Tsujimoto, M., Kajikawa, Y., Tomita, J., Matsumoto, Y.: A review of the ecosystem concept — Towards coherent ecosystem design. Technol. Forecast. Soc. Change 136, 49–58 (2018). https://doi.org/10.1016/j.techfore.2017.06.032 12. Zheng, Y., Yang, S., Cheng, H.: An application framework of digital twin and its case study. J. Ambient. Intell. Humaniz. Comput. 10(3), 1141–1153 (2018). https://doi.org/10.1007/s12 652-018-0911-3 13. Armengaud, E., Sams, C., von Falck, G., List, G., Kreiner, C., Riel, A.: Industry 4.0 as digitalization over the entire product lifecycle: opportunities in the automotive domain. In: Stolfa, J., Stolfa, S., O’Connor, R.V., Messnarz, R. (eds.) EuroSPI 2017. CCIS, vol. 748, pp. 334–351. Springer, Cham (2017). https://doi.org/10.1007/978-3-319-64218-5_28 14. Lee, J., Cameron, I., Hassall, M.: Improving process safety: what roles for digitalization and Industry 4.0? Process Saf. Environ. Prot. 132, 325–339 (2019). https://doi.org/10.1016/j.psep. 2019.10.021 15. Aheleroff, S., Xu, X., Zhong, R.Y., Lu, Y.: Digital Twin as a Service (DTaaS) in Industry 4.0: an architecture reference model. Adv. Eng. Inform. 47 (2021). https://doi.org/10.1016/j.aei. 2020.101225 16. Bhatti, G., Mohan, H., Raja Singh, R.: Towards the future of ssmart electric vehicles: digital twin technology. Renew. Sustain. Energy Rev. 141, 110801 (2021). https://doi.org/10.1016/ j.rser.2021.110801 17. Wang, F., Lai, X., Shi, N.: A multi-objective optimization for green supply chain network design. Decis. Support Syst. 51, 262–269 (2011). https://doi.org/10.1016/j.dss.2010.11.020 18. Hove, S.E., Anda, B.: Experiences from conducting semi-structured interviews in empirical software engineering research. Proc. - Int. Softw. Met. Symp. 2005, 10–23 (2005). https:// doi.org/10.1109/METRICS.2005.24 19. Thomas, D.R.: A general inductive approach for qualitative data analysis (2003) 20. Yin, R.K.: Case study research. Des. Methods 1, 93–95 (2009)
34
R. Liyanage et al.
21. Niu, X., Qin, S.: Integrating crowd-/service-sourcing into digital twin for advanced manufacturing service innovation. Adv. Eng. Inform. 50, 101422 (2021). https://doi.org/10.1016/ j.aei.2021.101422 22. Gackstetter, D., Moshrefzadeh, M., Machl, T., Kolbe, T.H.: Smart rural areas data infrastructure (SRADI) – an information logistics framework for digital agriculture based on open standards. In: Lecture Notes Informatics (LNI), Proceedings - Series Gesellschaft fur Informatics P-309, pp. 109–114 (2021) 23. Kanak, A., Ugur, N., Ergun, S.: A visionary model on blockchain-based accountability for secure and collaborative digital twin environments. In: Conference Proceedings - IEEE Conference on Systems, Man and Cybernetics, pp. 3512–3517 (2019). https://doi.org/10.1109/ SMC.2019.8914304 24. Javaid, M., Haleem, A., Singh, R.P., Suman, R.: Substantial capabilities of robotics in enhancing Industry 4.0 implementation. Cogn. Robot. 1, 58–75 (2021). https://doi.org/10.1016/j. cogr.2021.06.001 25. Dhanabalan, T., Sathish, A.: Transforming Indian industries through artificial intelligence and robotics in Industry 4.0. Int. J. Mech. Eng. Technol. 9, 835–845 (2018) 26. Ebert, N., Weber, K., Koruna, S.: Integration platform as a service. Bus. Inf. Syst. Eng. 59(5), 375–379 (2017). https://doi.org/10.1007/s12599-017-0486-0
Roadmapping in the Digital Transformation Literature Ashna Mahmood Zada(B)
, John Stouby Persson , and Peter Axel Nielsen
Department of Computer Science, Aalborg University, Selma LagerlöfsVej 300, 9220 Aalborg, Denmark [email protected]
Abstract. Digital transformation is vital for organizations in all sectors, as it changes value creation, customer relationships, and internal processes. A key concern in digital transformations is creating and executing an effective strategy that reimagines the organization. However, structured approaches for reimagination in a digital transformation are still missing. This paper contributes to this concern by reviewing how roadmapping is used in the digital transformation literature. Roadmapping is a flexible technique to support the strategic formulation of short- and long-range changes to software, business, organizational and structural aspects. Reviewing 28 papers on digital transformation, we uncovered five types of roadmapping for reimagining organizations: Product-Technology, Strategy, Business, Data, and Design. For these five types, we unfold the landscape of obstacles, opportunities, and context for different pathways to successfully reimagining organizations in digital transformations. Keywords: Roadmapping · Process · Digital transformation · Literature review
1 Introduction Over the years, organizations in nearly all industries have conducted initiatives to explore new digital technologies and exploit their benefits. The exploration and exploitation of software technologies often result in a wide variety of societal changes [44, 50, 55]. This process involves a reimagination of organizations through adopting software technologies, called digital transformation [10]. Digital transformation goes beyond the adaptation of software technologies, instead the transformation is understood as a far more fundamental change affecting all areas of human society [44, 50, 51, 55]. With the promise of multiple benefits, many organizations pursue digital transformation. However, the painful reality is that most transformations are not effective. 70% of complex, large-scale transformation initiatives do not reach their planned goals, which suggests that a radical technological change requires much figuring out [6, 40, 51]. The main concern that resonates in both research and amongst practitioners engaged in technological transformations is creating and executing a successful strategy [60]. However, too few studies explain how the two processes of strategizing and digital transformation interrelate [5, 45]. Existing literature suggests that organizations should embrace © The Author(s), under exclusive license to Springer Nature Switzerland AG 2022 N. Carroll et al. (Eds.): ICSOB 2022, LNBIP 463, pp. 35–50, 2022. https://doi.org/10.1007/978-3-031-20706-8_3
36
A. M. Zada et al.
the digital transformation journey as filled with uncertainty, but a strategic approach supporting the journey is needed [1, 10, 38]. Roadmapping, by definition, is a strategic planning framework to navigate and analyze an organization’s business environment for potentially disruptive changes. Traditionally called Technology Roadmapping, the approach was used as a management tool for product or technology planning, forecasting and administration [46]. Since roadmapping emerged from industrial practice more than five decades ago, it has been adopted in a range of sectors to address many different strategic goals and organizational contexts [11, 28, 29]. The broad adoption of roadmapping practices emphasizes its flexibility and multi-dimensional reach, suggesting that there is no single roadmap that will be optimal for all organizations [11, 28]. Organizations engage in transformations through digital technologies with different competencies, resources, and cultures, and aim for distinctive goals. What the organizations have in common is the need to plan and determine the way forward for their digital transformation. According to the literature, organizations tend to deploy roadmapping when challenged by complexity, uncertainty, and ambiguity [29]. Multiple forms of roadmapping processes exist (e.g., product-, design- and technology roadmaps), but the application and implementation of roadmapping remain problematic, even more so when roadmapping a technological transformation [1, 10, 27, 38]. Existing literature on digital transformation has also emphasized the importance of roadmapping guiding digital transformation journeys [1, 9, 39, 45]. However, a process specifically for roadmapping digital transformations is yet to be developed [1, 39, 45]. Correspondingly, with this paper, we report an exploration of roadmapping in digital transformation literature to identify different approaches for this reimagination by addressing the research question: How is roadmapping used for reimagining organizations in digital transformation literature? The paper is organized as follows: Sect. 2 presents the theoretical background on digital transformation and roadmapping. Section 3 presents the research approach, including the chosen search strategy, the applied selection process, and the analysis. In the following, the findings of the study are presented (Sect. 4) and discussed (Sect. 5).
2 Theoretical Background This section presents how transformation through digital technologies is understood in existing literature, taking upon a broader understanding of the phenomenon. Next, the section associates digital transformation with roadmapping to identify how roadmapping can be used for reimagining organizations in the digital transformation literature. 2.1 Digital Transformation Digital transformation is reshaping the environment in which many well-established industries function [1]. Implementing or adopting a software technology alone does not correspond to technological transformation [51]. Instead, digital transformation is understood as a more fundamental change (i.e., disruptive changes) associated with the application of software technology in all aspects of human society [44, 50, 55]. The
Roadmapping in the Digital Transformation Literature
37
leverage of technology in a specific context necessitates changes in the organizational and societal structure, which opens for innovative ways to create value in this everchanging environment [3]. While leveraging technologies to create value, businesses deal with additional strategic, technological, and organizational challenges [26]. Thus, society is facing fast, radical, and uncertain changes due to the maturation of software as a mandate for organizations’ survival in all industries [1]. Digital transformation literature emphasizes the importance of organizational readiness to address the challenges and changes introduced by such transformation (e.g., resource readiness, technological readiness, cultural readiness, partnership readiness, innovation valance, and strategic readiness) [19, 58]. As digital transformation changes most areas of society [40, 47], the role of software in digital transformation encompasses paradoxes and uncalled-for burdens [56]. Unsurprisingly, many organizations pursuing digital transformation do not reach their goal and consequently miss out on the expected benefits [40, 51, 58]. The inability to reach digitalization goals indicates that while we may have an advanced understanding of specific aspects of digital transformation, the process of the transformation in information systems and software business research or practice is still not well understood [8, 44, 55]. The obstacles to technological transformation is by large the (re-)organization and (re-)structure of existing resources and capabilities to propose new value creation-paths [46]. More recently, organizations have applied roadmapping as a technique with the aim of formulating business strategies for innovation that can address disruptive changes [11]. Thus, roadmapping may provide a strategic approach to digital transformation. 2.2 Roadmapping in Digital Transformation Initially, technology roadmapping was mostly applied for product and technology planning. However, roadmapping has since been introduced to support other purposes, moving from focused units of analysis, such as product and technological platforms, to the broader context of business units, corporations, and industrial sectors [11]. While the application of roadmapping has changed, the approach’s requirements and goals, once focused on tactical and operational planning, have been customized to fit applications aimed at strategic landscaping and planning. These changes involve the customization of roadmapping to different stakeholders, types of information, and roadmap architectures [11, 56]. Thus, roadmapping is a popular and prominent tool in technology management, strategic planning, and innovation [19, 46]. The dominant roadmapping methodology over the last 30 years is structured workshops, where cross-departmental teams of the organization are put together on fast-paced workshop sessions covering market, product, technology, and providing a first-cut product-technology roadmap out of the activity [18]. Roadmapping applications are generally influenced by two main factors: (1) scope (i.e., if it involves one or more organizations) and (2) motivation (i.e., what motivates the approach – strategy exploration or specific actions to reach predefined producttechnology objectives [15].
38
A. M. Zada et al.
Existing literature (see Table 1) points toward different purposes for roadmapping applications. However, product-technology and strategic planning are frequently mentioned and therefore seem to be the most important ones [24, 28]. Despite being frequently utilized, the difference between roadmapping for product-technology planning and strategic planning remains unclear. While the purposes unfolded in the literature are primarily grounded in their information contents or roadmap architectures, we distinguish between roadmapping based on their purposes for the practitioners. The purpose of roadmapping for product-technology is to provide a plan to support the development of products and technologies accordingly to technological opportunities and existing or emergent market needs. Subsequently, this roadmapping approach often includes analysis of products, technologies, and related markets, as well as defining the technical characteristics and goals to be achieved following a timeline. Contrary to roadmapping for product-technology planning, the purpose for strategic planning is to provide narratives containing directions and choices the organization is expected to pursue in order to achieve its overall strategic aims. The analysis during this approach extends the boundaries considered in product-technology planning and includes any dimensions related to business success and strategic alignment across different organizations [11, 22]. Since product-technology and strategic roadmapping was introduced, multiple subtypes (e.g., business model, data-driven, and design-driven) have emerged (see Table 1), emphasizing how roadmapping is inherently flexible [11, 28]. Due to technological progress or competitive changes, the need to develop and adapt an organization’s business model has become an important task for many. The challenge organizations face is the (re-)organization and (re-)structure of existing resources and capabilities in order to propose new value creation for the customer. To address volatile markets and to remain competitive, business model innovation roadmapping is a suggested solution [46]. Another acknowledged approach to remaining competitive is by leveraging data. To effectively incorporate data science into their business processes, literature emphasizes data-driven roadmapping as a solution [26, 43], which is necessary when transforming in uncertain market environments [1, 11]. While technology is rapidly changing, customers are no longer just seeking products and services but experiences. Traditional approaches (i.e., product-technology and strategic) are no longer sufficient [30, 31]. Accordingly, design-driven roadmapping approaches grounded in creating customer experiences have emerged (see Table 1), as increased customer focus is a requirement for survival [30, 31]. Overall, reimagining a digital transformation may entail five roadmapping frameworks: product-technology, strategy, business, data, and design (see Table 1). The main aspects these roadmapping frameworks address are described in Table 1. These frameworks form the theoretical foundation for our analysis of digital transformation literature. The existing literature covers several aspects of roadmapping, such as methods and best practices or challenges related with this technique. However, to the best of our knowledge, research specifically targeting digital transformation strategy formulation is still scattered [1]. Exceptions to this are studies conducted by [1, 11, 26, 41, 46], who
Roadmapping in the Digital Transformation Literature
39
Table 1. Overview of roadmapping frameworks identified in digital transformation literature Roadmapping framework Exemplars references
Main aspect of digital transformation
Product-Technology
[24, 25, 27, 38, 41, 52] An approach to support alignment between product and technology planning in an environment with continuous maturation of digital technologies
Strategy
[11, 16, 29, 36]
An approach to support strategic plans, actions, and alignment across different contexts and organizations in an environment with increased collaboration
Business
[15, 22, 46]
An approach to changing business models to support new value-creation paths as a mandate for survival
Data
[20, 26, 32, 43]
An approach to support exploitation of data for competitive advantage in an environment with increasing volume, heterogeneity, and speed of data
Design
[1, 30, 31, 42]
An approach to support changing customer perspectives, needs and wants
address roadmapping associated with aspects of digital transformation (see Table 1). We will review digital transformation literature to improve our understanding of how roadmapping is used to reimagine organizations.
3 Research Approach We investigated the digital transformation literature following the guidelines by Templier and Paré [53] to increase the quality and trustworthiness of the review with transparency. The notion of transparency ensures consideration of whether the search strategy aligns with the research question and allows readers to judge if the methods used and decisions made were appropriate. The guidelines cover three major phases, once a research question is established, (1) search the literature, (2) select the papers, and (3) analyze and synthesize the papers and interpret the findings [53]. The point of departure is in the research question regarding how roadmapping processes are used for reimagining organizations in digital transformation literature (see Fig. 1). We searched the digital library, Scopus, using the search terms roadmapping or roadmaps and digitalization or digitalisation or digital transformation. Since we have a specific interest in roadmapping, we narrowed down the search to this term, thus not including connotations e.g., strategy, guideline, planning, as these differ from roadmapping. The search was performed the 20th of June 2022. As digital transformation is a contemporary topic, the search is restricted to the timespan 2015-Present. While digital transformation has evolved, it was after 2014 that research on digital transformation increased significantly [44]. The literature search resulted in a total of 229 papers. These
40
A. M. Zada et al. PROBLEM FORMULATION How is roadmapping used for reimagining organizations in digital transformation literature?
Article includedYes Yes
LITERATURE SEARCH - SEARCH STRING IN SCOPUS “Roadmapping” OR “Roadmaps” AND “Digitalization” OR “Digitalisation” OR “Digtal Transformation”
Read abstracts
- LIMITED TO ARTICLES BETWEEN 2015- Present
Does the article belong in the research scope e.g., roadmapping or roadmaps in/of digital transformation
43 Articles analyzed
- LIMITED TO ARTICLES Written in English 229
No Article excluded
28 Articles selected
186
Fig. 1. Workflow of the literature review process.
were screened for inclusion using a deductive approach based on the five identified roadmapping frameworks (see Table 1). The inclusion criteria are that a paper must refer to roadmapping a digital transformation, it must be a full paper, and it must relate to the multiple changes introduced through digital transformation (e.g., software, collaboration, innovation, re-structuring of organizations etc.). The screening process identified several papers not reporting roadmapping associated with digital transformation, leaving us with 43 papers. These were the reviewed and full text examined papers. This review led to the further exclusion of 15 papers, leaving us with the final set of 28 papers (see Table 3 in Appendix). The following phase was to inductively analyze the 28 papers to identify how roadmapping is used for reimagining organizations in digital transformations. We employed qualitative content analysis [23] to understand how roadmapping is used in digital transformation literature. Qualitative content analysis is appropriate when the purpose is to identify themes across various texts. Our content analysis entailed an examination of the selected articles to identify patterns and distinct themes of roadmapping in the selected digital transformation literature. Correspondingly themes were identified through repeat reading and conceptualized grounded in the literature, and highly based on the research question (see Sect. 1). We started by categorising the selected literature i.e., into their relations to the identified five roadmapping frameworks, so it could be managed better. From there we progressed to coding, here our main focus was the frequency a potential code occurred and the direction in which the content appeared in e.g., opposite, positive or negative. Thus, themes were developed in an highly interative process from the coding and in discussion amongst the authors. However, the analysis of the selected literature was conducted with a limited perspective, as we did not look beyond the five roadmapping frameworks to ensure understanding [23]. The results we present in the following section unfold how the five roadmapping frameworks and roadmapping in digital transformation literature intersect.
Roadmapping in the Digital Transformation Literature
41
4 Findings To answer the research question, we identified distinct themes of roadmapping approaches (i.e., obstacles, opportunities, and context) in the digital transformation literature (see Table 2). With no specific roadmapping approach for digital transformation, we unfold several roadmapping approaches which address different aspects and obstacles of digital transformation in the literature. Table 2. Overview of roadmapping themes in digital transformation literature Roadmapping framework
Obstacles
Opportunities
Context
Product-Technology An approach to support alignment between product and technology planning in an environment with continuous maturation of digital technologies Phaal et al. [41]
[4, 19, 37, 44, 55, 58]
[12, 17, 19, 36, 37, 49, 55]
[2, 4, 9, 12, 21, 34, 40, 44, 58]
Strategy An approach to support strategic plans, actions, and alignment across different contexts and organizations in an environment with increased collaboration de Oliveira et al. [11]
[2, 5, 9, 21, 34, 35, 37, 40, 45, 49, 51, 55, 59, 60]
[5, 19, 40, 45, 49]
[9, 35, 40, 45, 54, 60]
Business An approach to changing business models to support new value-creation paths as a mandate for survival Schaller et al. [46]
[14]
[2, 7, 33, 48, 49, 58]
[4, 21, 34, 44, 55]
Data An approach to support exploitation of data for competitive advantage in an environment with increasing volume, heterogeneity, and speed of data Kayabay et al. [26]
[4, 43]
[20, 43, 45, 48]
Design An approach to support changing customer perspectives, needs and wants Kim et al. [30]
[37]
[4, 5, 49, 59]
[4, 58, 59]
Table 2 provides an overview of how existing research grounds its focus. Based on the table, we argue that existing digital transformation research predominantly focus on obstacles and opportunities related to product-technology and strategy roadmapping. Consequently, research in digital transformation literature related to business, design and especially data roadmapping are scarce. Because of this, we cannot establish whether
42
A. M. Zada et al.
data has less obstacles or context, as it is at the current time, a matter of less research within this roadmapping framework. 4.1 Obstacles According to the literature, organizations might face various obstacles when reimagining their future during digital transformations. These obstacles during technological transformations stem from improper strategy formulation or implementation [9, 34, 35, 37, 49]. This literature emphasizes how digital transformation strategies seek to coordinate and prioritize the many independent threads of digital transformation [9, 37, 45, 60]. Yet, the strategy for reimagining organizations for digital transformation is predominantly limited to specific domains of the transformation (e.g., use of software, value creation, innovation, business). While committing to one domain for reimagination might pay off [49], it is mostly discouraged [5, 37]. There is a tendency to employ IT strategies for reimagination focused on managing the IT infrastructure within an organization, with a relatively limited impact on driving innovations in business development. This restricts the product-centric and customer-centric opportunities that arise from new digital technologies, which often cross organizational borders. IT strategies present system-centric roadmaps to the future use of technologies in an organization, but they do not necessarily account for the transformation of products, processes, and structural aspects that go along with the integration of technologies [21, 37, 59]. While digital technologies need to become central to how organizations operate, technologies nor software should be the organizations’ only solutions to reimagining themselves [5, 45, 58]. Accordingly, obtaining a close fit between digital transformation strategies, business software strategies, and all other organizational and functional strategies is critical [21, 37, 55, 59]. Such an aligned strategy might help overcome the significant obstacles of outlining what the target of the strategy is [14], how this target is reached [21, 37, 59], in addition to how new technology and data is embedded into existing products and services to obtain new value creation [4, 5]. Digital transformations drive increased collaboration among organizations. Interorganizational digitalization efforts represent dynamic, oftentimes random combinations of actors with various goals and motives that do not necessarily align with an organization’s actual interests [59]. Yet the literature does not offer guidance on facilitating inter-organizational digitalization efforts that aim to realize benefits beyond single organizations [2, 34]. This obstacle to reimagination is exacerbated by uncertain activities in collaborative transformation efforts in practice. A strategy may be critical for mapping organizations’ transformation, but its success depends less on strategic inspiration than on addressing the internal obstacles to digital transformations [9, 35, 40]. These internal obstacles are related to the specific organizations undergoing a transformation, typically divided into inertia (i.e., absence of resources and capabilities) and resistance to change, often caused by a lack of visibility of the potential benefits of new software [4, 19, 43, 55, 58]. Despite various efforts to guide digital transformation, there are many recent examples of organizations unable to keep pace with the new digital reality [5, 44, 51, 58]. This inability to keep up shows that the obstacles organizations face when reimagining themselves in digital transformations continue to pose a great challenge.
Roadmapping in the Digital Transformation Literature
43
4.2 Opportunities Potential opportunities of transforming using digital technology are manifold and include areas of strategy, business, data, product/technology, and design. To increase the chances of pursuing the multiple opportunities that come with digital transformations, organizations should formulate and implement strategies that go beyond IT strategies. An approach to such alignment is emphasized by [5, 36, 37, 58], who argues that organizations should balance four dimensions: (1) use of technologies, (2) changes in value creation, (3) structural changes, and (4) financial aspects, in addition to, (5) customers, (6) competition, (7) data and innovation [19]. The realization of organizational goals and objectives requires a strategizing process enacted in between IT and business strategies [5, 7]. This process results in a shared understanding across the organization that simultaneously guides the IT investment and decision-making [55]. Organizations must address changing customer demands to remain relevant by utilizing the opportunities new software brings [59]. To do so, two strategies are emphasized: customer engagement and digitized solutions strategy [49, 59]. A customer engagement strategy relies on analytics applied to a growing repository of customer data, to better understand and respond to changing customer demands [49]. Leveraging analytics provides an opportunity to build better customer experiences, which results in competitive advantage [49, 55]. While a customer engagement strategy provides an opportunity to respond to changing customer needs, a digital solutions strategy provides an opportunity to anticipate customer needs. Thus, a digital solutions strategy tries to reimagine what it could do for customers by combining existing competencies with the capabilities offered by new software [49]. The term “transformation” means that digital usages integrally enable new types of innovation [17]. Digital innovations induce significant changes in an organization’s products and services, business processes, or business models, which can only manifest if organizations are adequately prepared. To yield the competitive opportunities of digital innovations, organizations must prepare their information systems landscapes to accommodate digital innovations [59]. To do so, the digital transformation literature point to various enablers, which allows software or services to be used for the reimagination of organizations: (1) enabling organizational IT to accommodate digital innovations, (2) enabling organizational structures to enable digital innovations, (3) enabling organizational culture to accommodate digital innovations and (4) enabling organizational capabilities [59], in addition to (5) digital data to improve prediction and decision, (6) automatization, (7) digital customer access and (8) networking) [48]. Digital transformation brings increased market opportunity. The implementation of digital transformations is achievable by deploying technologies such as the IoT, AI, and big data [19, 45]. Organizations with effective transformations deploy more technologies than others [12], which might seem counterintuitive, given that a broader suite of technologies could result in more complex execution of transformation initiatives and more opportunities to fail. Consequently, having these technologies on hand is only one part of the story. To gain the multiple opportunities that come with new software, organizations should make the technology-supported changes that differentiate successful digital transformations from the rest [12, 40]. Adding technology does not automatically confer expected benefits; these benefits must be unlocked, which can only happen
44
A. M. Zada et al.
through organizational changes [2, 40]. To do so, a benefits dependency tool to identify and map all required changes is presented, so expected benefits and outcomes are delivered. Additionally, it clarifies how this change is supported and shaped by technologies [40]. Data and information are already considered commodities, meaning that organizations need to upgrade their information and digital ecosystems to acquire knowledge and wisdom, to get a competitive advantage [20, 43, 45]. Thus, the main objectives of digital transformations are obtaining new data and using this data to reimagine old processes [4]. Turning attention towards a more data-oriented approach allows for the opportunity to gain new knowledge and in turn, reimagine business models and operations [48]. Such opportunities for reimagination can be pursued by initiating five different phases (i.e., (1) digital reality, (2) digital ambition, (3) digital potential, (4) digital fit, and (5) digital implementation) [33, 48]. 4.3 Context Digital technologies alone provide little value when reimagining an organization. Their use within a specific context enables an organization to uncover new ways to reimagine itself [9, 44, 55, 60]. Accordingly, approaches to transformations are often very specialized and restricted to the reality and context of the specific organization and its activities [21, 60]. Digital transformations in a technological and software context are often viewed in terms of their impacts on markets, products, and services [12, 21, 49, 58]. However, to ensure the digital transformation initiative has momentum, the transformation of organizations needs to be considered in not only the context of technology but also business changes [2, 40] and the necessary customer orientation [58, 59]. The literature stresses how business changes should be made considering three domains (i.e., finance, marketing, and innovation management) [4, 21]. Digital transformation in the context of business may have an internal perspective (i.e., a resource-based view) and an external perspective (i.e., one of structural change) on the way value is or can be created as a result [34]. The exploration of dynamic capabilities in the digital transformation context is of particular interest. Dynamic capabilities are seen as key capabilities, not only in terms of being ready for transformation through the use of technology but also able to exploit its potential [34]. When reimagining an organization for digital transformation in the context of strategy, two circumstances should be fully understood: (1) where a specific organization want to end up, by gaining an understanding of the internal and external environment, the culture, the capabilities, and beliefs, (2) how digital tools come to be used widely and effectively so that they can create an environment that provides optimal conditions [35, 45, 54]. Overall, our review shows the most common objective for reimagining organizations in digital transformation literature relates to product-technology, strategy, and business. Thus, digital transformation literature on roadmapping is centered on typical strategy issues. Less than half of the selected papers includes roadmapping concerned with design and data, consequently providing limited views on the opportunities and existential obstacles of design and data. Additionally, what goes across the literature, is the call for
Roadmapping in the Digital Transformation Literature
45
a strategy approach, specifically targeting a multidimensional-oriented vision of digital transformation, which oversteps the restrictive technological view. However, such a strategic approach is still at its early stage. Lastly, our findings include the multiple contexts in which digital transformation must be viewed to uncover new ways of reimagining organizations.
5 Discussion This study aims to advance knowledge on how roadmapping is used for reimagining organizations in the digital transformation literature. Taking a point of departure in five roadmapping frameworks (see Table 1), our analysis of 28 papers identified three main themes: (1) obstacles, (2) opportunities, and (3) context (see Table 2) in roadmapping approaches for digital transformation. Accordingly, we uncovered how roadmapping is used for reimagining organizations during digital transformations (cf. Table 2 and Sects. 4.1–4.3). Most importantly, connecting these two different research streams is notably different from what is commonly known and focused on in the digital transformation literature. Our review expands on the existing digital transformation literature by explaining how roadmapping is used to reimagining organizations in digital transformation. To the best of our knowledge, the existing literature has not explicitly related roadmapping to digital transformation literature. The exception being one study conducted by Zaoui and Souissi [60]. The result of their study is an overview of the most significant phases of digital transformation as suggested by literature and emphasizes the need for a multidimensional approach to such transformation. Roadmapping, can offer such approach. Our research extends their findings by relating the two research streams i.e., transformation and roadmapping, thereby unfolding a new landscape of different pathways to digital transformation. What goes across digital transformation literature is that in the digital age, organizations should consider changes to the five domains of digital transformation, which are related to customers, competition, data, innovation, and value [19, 55]. Yet, the most studied dimension in existing research is constrained to software technology [19]. We do not reject the relevance of technology for targeting digital transformation. However, the attention given to technology comes across as conflicting with the understanding that digital transformation goes beyond the adaptation of technologies [4, 44, 51, 55]. Digital transformations typically require fundamental organizational, structural, cultural, and technological changes [5, 19, 44, 51, 55, 60]. Correspondingly, digital transformation literature emphasizes that a key concern in digital transformations is creating and executing an effective strategy that reimagines the organization [60]. To address this concern, most digital transformation literature tries to identify strategies or steps for designing and implementing digital transformation [17, 60]. However, the ongoing acceleration of digital technologies in today’s software-enabled environment introduces opportunities and obstacles for organizations to continuously chase digital transformations to survive and compete [1, 5]. Digital transformation is taking much longer and facing more difficulties than expected [5, 44], and many organizations have been unable to keep pace with the new digital reality [5, 6, 40, 44, 51]. This inability to keep up suggests that despite efforts
46
A. M. Zada et al.
to address a strategy for digital transformation, organizations lack specific guidelines for formulating, implementing, and evaluating digital transformation strategies [5, 45]. These gaps in our understanding require additional research. While we have an advanced understanding of specific aspects of digital transformation [55], we still know very little about creating multi-dimensional reimaginations of organizations in digital transformations. Roadmapping, by definition, is such a strategic planning and forecasting framework to navigate and analyze an organization’s business environment for potentially disruptive changes. However, software engineering innovations might emerge at any time and are almost impossible to predict [13]. Relating roadmapping to digital transformation, we provide software-enabled organizations a new landscape for technology innovation, new business models, and cross-industry collaboration. In conclusion, our study expands existing literature by relating roadmapping to the digital transformation literature. This literature study provides a landscape of how roadmapping is used to reimagine organizations during digital transformations. While digital transformation has evolved over time, this literature review unfolds how the call for a strategic approach, specifically targeting a multidimensional-oriented vision of digital transformation should be recognized as one of the main challenges in digital transformations. We acknowledge that our study is not without limitations, the most important of which we summarize as follows. First, applying restrictions, i.e., concerning the publication language and timespan, to our search strategy poses a threat to generalizability since some studies of interest may not have been captured. Additionally, the search string itself has a limitation, as some papers may deal with the research topic but use terms that were not covered by the selected search strings. To address this limitation we recommend future researchers to include connotations of roadmapping to strengthen the theoretical framework (Table 1) and to open up for any new emerging roadmapping frameworks. Second, with content analysis, challenges of achieving validity and reliability arise. While our analysis is not necessarily replicable the notion of transparency allows readers to judge if the methods used and decisions made were appropriate. To further this research, we recommend two directions for future research. First, we recommend more elaborate theorizing of a roadmapping approach targeting digital transformation with empirical insights from case studies and surveys. Second, future research should further explore the nature and implications of roadmapping used for reimagining organizations in digital transformations in practice through action research and design science research.
Roadmapping in the Digital Transformation Literature
47
Appendix
Table 3. Each table cell contains the reference to the paper and its respective authors Overview of selected literature for analysis [2] Askedal et al.
[20] Han and Geum
[44] Reis et al.
[4] Bordeleau et al.
[21] Hausberg et al.
[45] Ribeiro
[6] Brown and Brown
[33] Krey
[48] Schallmo et al.
[7] Bughin et al.
[34] Kraus et al.
[49] Sebastian et al.
[9] Chanias et al.
[35] Leonardi
[51] Tabrizi et al.
[12] de la Boutetiére
[36] Letaba & Pretorious
[54] Tongskulroongruang & Chutima
[14] Egor
[37] Matt et al.
[55] Vial
[17] Gebayew et al.
[40] Peppard
[58] Westerman & Davenport
[19] Hajishirizi et al.
[43] Pora et al.
[59] Wiesböck & Hess [60] Zaoui & Souissi
References 1. Al-Ali, A. G. and Phaal, R.: Design sprints for roadmapping an agile digital transformation. In: IEEE International Conference on Engineering, Technology and Innovation (ICE/ITMC), pp. 1–6 (2019) 2. Askedal, K., Flak, L.S., Aanestad, M.: Five challenges for benefits management in complex digitalisation efforts – and a research agenda to address current shortcomings. Electron. J. e-Govern. 17(2), 64–78 (2019) 3. Baiyere, A., Salmela, H., Tapanainen, T.: Digital transformation and the new logics of business process management. Eur. J. Inf. Syst. 29(3), 238–259 (2020) 4. Bordeleau, Fanny-Ève, Santa-Eulalia, L.A.D., Mosconi, E.: Digital transformation framework: creating Sensing, Smart, Sustainable and Social (S^4) Organisations. In: Hawaii International Conference on System Sciences (2021) 5. Brown, N., Brown, I.: From digital business strategy to digital transformation - how? - A systematic literature review. In: Proceedings of ACM SAICSIT Conference (SAICSIT 2019). ACM, Skukuza, pp. 1–8 (2019) 6. Bucy, M., Finlayson, A., Kelly, G,. Moye, C.: ‘The “How” of Transformation’, McKinsey & Company (2016) 7. Bughin, J., Deakin, J., O’Beirne, B.: Digital transformation: improving the odds of success. McKinsey Q. 22, 1–5 (2019) 8. Carroll, N.: Theorizing on the normalization of digital transformations. In: Proceedings of the 28th European Conference on Information Systems (ECIS) (2020) 9. Chanias, S., Myers, M.D., Hess, T.: Digital transformation strategy making in pre-digital organizations: the case of a financial services provider. J. Strat. Inf. Syst. 28(1), 17–33 (2019)
48
A. M. Zada et al.
10. Czachorowski, K., Haskins, C.: ’Applying systems engineering to roadmapping for digital transformation in the offshore exploration and production supply chain operations. Syst. Eng. 25(3), 191–206 (2021) 11. de Oliveira, M., Freitas, J., Pereira, B., Guerra, P.: Exploring the involvement of experts in strategic roadmapping with large groups. IEEE Trans. Eng. Manag. 69(1), 56–66 (2022) 12. de la Boutetiére, H., Montagner, A., Reich, A.: Unlocking success in digital transformations. McKinsey Co., pp. 1–14 (2018) 13. Kleinert, J.: Digital transformation. Empirica 48(1), 1–3 (2021). https://doi.org/10.1007/s10 663-021-09501-0 14. Egor, P.: Digital transformation of industrial companies: what is management 4.0? In: The 11Th International Conference on E-Business, Management and Economics (2020) 15. Freitas, J.S., Mudrik, J.A.T., de Melo, J.C.F, Bagno, R.B., de Oliveira, M.G.: On the combination of strategy and innovation tools with roadmapping: exploring taxonomies and sequences. In: 26th International Association for Management of Technology Conference IAMOT, pp. 514–528 (2017) 16. Freitas, J.S., de Oliveira, M., Bagno, R., de Melo Filho, L., Cheng, L.: A bottom-up strategic roadmapping approach for multilevel integration and communication. IEEE Trans. Eng. Manage. 69(1), 81–93 (2022) 17. Gebayew, C., Hardini, I.R., Panjaitan, G.H.A., Kurniawan, N.B.: A systematic literature review on digital transformation. In: International Conference on Information Technology Systems and Innovation (ICITSI), pp. 260–265. IEEE (2018) 18. Golkar, A., Garzaniti, N.: Model based systems engineering approach to technology roadmapping. In: Proceedings of the 2020 Summer Simulation Conference, pp. 1–12 (2020) 19. Hajishirzi, R., Costa, C., Aparicio, M., Romão, M.: Digital transformation framework: a bibliometric approach. In: Rocha, A., Adeli, H., Dzemyda, G., Moreira, F. (eds.) Information Systems and Technologies. WorldCIST 2022. Lecture Notes in Networks and Systems, vol. 470, pp.427–437. Springer, Cham (2022). https://doi.org/10.1007/978-3-031-04829-6_38 20. Han, M., Geum, Y.: Roadmapping for data: concept and typology of data-integrated smartservice roadmaps. IEEE Trans. Eng. Manage. 69(1), 142–154 (2022) 21. Hausberg, J.P., Liere-Netheler, K., Packmohr, S., Pakura, S., Vogelsang, K.: Research streams on digital transformation from a holistic business perspective: a systematic literature review and citation network analysis. J. Bus. Econ. 89(8–9), 931–963 (2019). https://doi.org/10. 1007/s11573-019-00956-z 22. Ho, J., O’Sullivan, E.: ‘Toward integrated innovation roadmapping: lessons from multiple functional roadmaps beyond technology. IEEE Trans. Eng. Manag. 69(1), 155–167 (2022) 23. Hsieh, H.F., Shannon, S.E.: Three approaches to qualitative content analysis. Qual. Health Res. 15(9), 1277–1288 (2005) 24. Hussain, M., Tapinos, E., Knight, L.: Scenario-driven roadmapping for technology foresight. Technol. Forecast. Soc. Change 124, 160–177 (2017) 25. Jeong, Y., Jang, H., Yoon, B.: ’Developing a risk-adaptive technology roadmap using a Bayesian network and topic modeling under deep uncertainty’. Scientometrics 126(5), 3697–3722 (2021) 26. Kayabay, K., Gökalp, M., Gökalp, E., Erhan Eren, P., Koçyi˘git, A.: ’Data science roadmapping: an architectural framework for facilitating transformation towards a data-driven organization’. Technol. Forecast. Soc. Change 174, 121264 (2022) 27. Kerr, C., Phaal, R., Thams, K.: Customising and deploying roadmapping in an organisational setting: the LEGO Group experience. J. Eng. Technol. Manag. - JET-M 52, 48–60 (2019) 28. Kerr, C., Phaal, R.: Defining the scope of a roadmapping initiative: a checklist-based template for organizational stakeholders. In: Portland International Conference on Management of Engineering and Technology (PICMET), pp. 1–10 (2019)
Roadmapping in the Digital Transformation Literature
49
29. Kerr, C., Phaal, R.: ’Roadmapping and roadmaps: definition and underpinning concepts. IEEE Trans. Eng. Manag. 69(1), 6–16 (2022) 30. Kim, E., Beckman, S.L., Agogino, A.: Design roadmapping in an uncertain world: Implementing a customer-experience-focused strategy. Calif. Manag. Rev. 61(1), 43–70 (2018) 31. Kim, E., et al.: User-centered design roadmapping: anchoring roadmapping in customer value before technology selection. IEEE Trans. Eng. Manage. 69(1), 109–126 (2022) 32. Kim, J., Geum, Y.: ‘How to develop data-driven technology roadmaps: the integration of topic modeling and link prediction. Technol. Forecast. Soc. Change 171, 120972 (2021) 33. Krey, M.: Digital Transformation in Swiss Hospitals: A Reference Modeling Approach. Springer, Singapore (2021) 34. Kraus, S., Durst, S.,Ferreira, J.J.,Veiga, P., Kailer, N.,Weinmann, A.: Digital transformation in business and management research: an overview of the current status quo. Int. J. Inf. Manag. 63, 102466 (2022). ISSN 0268–4012 35. Leonardi, P.: ‘You’ Re going digital-now what? Enough with the top-down strategizing’, understand how change really happens on the ground-and plan for it accordingly. MIT Sloan Management Review, Winter (2020) 36. Letaba, P.T., Pretorius, M.W.: Toward sociotechnical transition technology roadmaps: a proposed framework for large-scale projects in developing countries. IEEE Trans. Eng. Manage. 69(1), 195–208 (2022) 37. Matt, C., Hess, T., Benlian, A.: Digital transformation strategies. Bus. Inf. Syst. Eng. 57(5), 339–343 (2015) 38. Munch, J., Trieflinger, S., Bogazkoy, E., Eisler, P., Roling, B., Schneider, J.: Product roadmap formats for an uncertain future: a grey literature review. In: Proceedings - 46th Euromicro Conference on Software Engineering and Advanced Applications, SEAA, pp. 284–291 (2020) 39. Parviainen, P., Tihinen, M., Kääriäinen, J., Teppola, S.: Tackling the digitalization challenge: how to benefit from digitalization in practice. Int. J. Inf. Syst. Proj. Manag. 5(1), 63–77 (2017) 40. Peppard, J.: Tool to map your next digital initiative. Harw. Bus. Rev. 1–5 (2020) 41. Phaal, R., Farrukh, C., Probert, D.: Technology roadmapping—a planning framework for evolution and revolution. Technol. Forecast. Soc. Chang. 71(1–2), 5–26 (2004) 42. Pessôa, M.V.P., Gowda, A.: Integrated PSS roadmapping using customer needs and technology change likelihood. IEEE Trans. Eng. Manag. 69(1), 127–141 (2022) 43. Pora, U., Gerdsri, N., Thawesaengskulthai, N., Triukose, S.: ‘Data-Driven Roadmapping (DDRM): approach and case demonstration. IEEE Trans. Eng. Manage. 69(1), 209–227 (2022) 44. Reis, J., Amorim, M., Melão, N., Matos, P.: Digital transformation: a literature review and guidelines for future research. Adv. Intell. Syst. Comput. 745(March), 411–421 (2018) 45. Ribeiro, R.: Digital transformation: the evolution of the enterprise value chains. In: Proceedings of Fifth International Congress on Information and Communication Technology, pp. 290–302 (2020) 46. Schaller, A., Vatananan-Thesenvitz, R. Stefania, M.: Business model innovation roadmapping: a structured approach to a new business model. In: Portland International Conference on Management of Engineering and Technology (PICMET) (2018) 47. Schneider, S., Kokshagina, O.: Digital transformation: what we have learned (thus far) and what is next. Creat. Innov. Manag. 30(2), 384–411 (2021) 48. Schallmo, D., Williams, C., Boardman, L.: ’Digital transformation of business models – best practice, enablers, and roadmap. Int. J. Innov. Manag. 21(08), 1740014 (2017) 49. Sebastian, I.M., Ross, J.W., Beath, C., Mocker, M., Moloney, K.G., Fonstad, N.O.: How big old companies navigate digital transformation. In: Strategic Information Management, pp. 133–150. Routledge (2020)
50
A. M. Zada et al.
50. Stolterman, E., Fors, A.K.: Information technology and the good life, information systems research: relevant theory and informed practice. In: Information Systems Research. In: IFIP International Federation for Information Processing, pp. 687–692 (2004) 51. Tabrizi, B., Lam, E., Girard, K., Irvin, V.: Digital transformation is not about technology. Harv. Bus. Rev. 2–7 (2019) 52. Tansurat, P., Gerdsri, N.: Extended techniques to enhance technology roadmapping: research opportunities and challenges. In: Portland International Conference on Management of Engineering and Technology (PICMET), pp. 1–8 (2019) 53. Templier, M., Pare, G.: A framework for guiding and evaluating literature reviews. Commun. Assoc. Inf. Syst. 37, 112–137 (2015) 54. Tongskulroongruang, T., & Chutima, P.: Creation a strategic plan for supporting digital transformation. In: Proceedings of the 2020 2nd International Conference on Management Science and Industrial Engineering (2020) 55. Vial, G.: ‘Understanding digital transformation: a review and a research agenda. J. Strat. Inf. Syst. 28(2), 118–144 (2019) 56. Vinayavekhin, S., Phaal, R., Thanamaitreejit, T., Asatani, K.: Emerging trends in roadmapping research: a bibliometric literature review. Technol. Anal. Strat. Manag. 1–15 (2021) 57. Wessel, L., Baiyere, A., Ologeanu-Taddei, R., Cha, J., Jensen, B,T.: Unpacking the difference between digital transformation and it-enabled organizational transformation. J. Assoc. Inf. Syst. 22(1), 102–129 (2021) 58. Westerman, G., Davenport, T.H.: Why so many high-profile digital transformations fail. Harv. Bus. Rev. 2–6 (2018) 59. Wiesböck, F., Hess, T.: Digital innovations. Electron. Mark. 30(1), 75–86 (2019). https://doi. org/10.1007/s12525-019-00364-9 60. Zaoui, F., Souissi, N.: ’Roadmap for digital transformation: a literature review’. Procedia Comput. Sci. 175, 621–628 (2020)
Interrelation of Digitalization and Digital Transformation in a Maritime Company Rasmus Ulfsnes(B) , Nils Brede Moe , Geir Kjetil Hanssen , and Thor Aleksander Buan SINTEF, Trondheim, Norway {rasmus.ulfsnes,nils.b.moe,geir.k.hanssen,thor.buan}@sintef.no http://www.sintef.no
Abstract. Many organizations must undergo digitalization and digital transformation (DT) simultaneously; in itself, either is daunting. For 15 months, we followed the ongoing digitalization and DT activities at a maritime company with over 3700 employees through a qualitative analysis of 20 interviews, a workshop, and several documents. We see how digitalization and DT are inherently interrelated; DT and digitalization have common enablers through technology such as AI, and common processes in continuous software development. They also share many challenges, including lack of resources and internal resistance against change. Through acquiring data in the digitalization of core services, companies can undergo DT by utilizing data in new and profound ways to build services with new value propositions. In conclusion, digitalization and DT are necessary for incumbent companies and require careful balancing of resources, competence, and technology.
Keywords: Digitalization management
1
· Digital transformation · Product
Introduction
Today’s companies are challenged by being ever more efficient in how they develop and apply technology, not only for improving existing services but also for innovation and development of new services and products. Through software development or purchasing and implementation of off-the-shelf products [15], organizations aim to undergo the digitalization of services to achieve these improvements. Digitalization can be defined as how technology is used to change business processes through automation of tasks [7] or changing business processes for improved communication and coordination between business processes [19]. The maritime industry has notably been lagging behind other sectors [13]. This lag has introduced a much larger technology gap where the maritime industry not only has to consider the digitalization of internal processes but also the effects on how: 1) sensors on ships provide exponentially c The Author(s) 2022 N. Carroll et al. (Eds.): ICSOB 2022, LNBIP 463, pp. 51–66, 2022. https://doi.org/10.1007/978-3-031-20706-8_4
52
R. Ulfsnes et al.
more data, 2) artificial intelligence can be applied to generate new insights from sensors and other data sources, and 3) Big data and its ability to provide insights across more extensive data sets spanning entire fleets of ships [13]. Digitalization is a challenging and daunting task; it involves changing how a company operates by introducing technology to personnel that previously have not been using software quite that way [16]. While digitalization and improvements are well and good, this is not sufficient to compete in an ever-increasingly disruptive domain where organizations and people expect increasingly effective digital solutions. Various research has aimed to clarify and define the concept of digital transformation [14,19,20,22]. Vial [20] proclaims that digital transformation is “a process that aims to improve an entity by triggering significant changes to its properties through combinations of information, computing, communication, and connectivity technologies.” However, if digital transformation is more advanced, disruptive, or indeed a different concept than digitalization, it would need to be built on top of digitalization in incumbent companies. Motivated by the increasing digitalization of the maritime industry, the potential and uncertainty of digital transformation, and its illusive connection to digitalization, we ask the following research question: How are digital transformation and digitalization interrelated? We will first outline the interrelation by applying the notion that digitalization and digital transformation are distinct in themselves and differ in how they affect the companies’ value proposition [22] while observing how AI, business models, data, and software developments affect both phenomena. We present rich insight into a large software- and data-intensive organization that has established an innovation framework as part of a transformation initiative. Our findings provide insight into transformation strategies and challenges, and even more so, insights into how digitalization and digital transformation should be seen as a joint approach. The remainder of the paper is organized as follows: In Sect. 2, we present relevant literature on digitalization and digital transformation and a framework we use for understanding both concepts. In Sect. 3, we describe our case company and research method in detail. In Sect. 4, we present results from a case study and discuss our findings in Sect. 5. Section 6 concludes and presents key findings from the study.
2
Background
In this chapter, we explain digitalization and digital transformation as distinct concepts and how they relate to each other before looking into the capabilities that are necessary for both to succeed. 2.1
Digitalization vs. Digital Transformation
In digital transformation, technology is central in redefining companies’ value propositions, which causes the emergence of a new organizational identity. There-
Interrelation of Digitalization and Digital Transformation
53
fore, digital transformation hit barriers such as hierarchical leadership [2], poor alignment of organizational units [14], conflicts between existing and new business strategies [23], and resistance from employees [20,22]. Such barriers and frictions cause interruptions, as development, operations, and business teams constantly need to be involved in complex alignment activities to succeed in the transformation. In contrast, digitalization involves using digital technology to support an existing value proposition, implying that an organization’s existing identity is reinforced [22], although not redefined. As the identity is not changed, digitalization is less likely to experience the same internal barriers as found in a digital transformation. However, little is known about barriers and enablers when undertaking digitalization and digital transformation simultaneously as an interrelated process. Both digitalization and digital transformations are by themselves challenging and hard to undertake, and companies are required to do both at the same time [14]. Netflix shows a public example, where they started out by physically delivering DVDs to the customers’ mailboxes. Then realizing the potential of streaming, building up a streaming platform for delivering movies and tv-series to the customer, piggybacking on the increasing internet capacity. Then when challenged by other movie studios, Netflix understood the potential value of data from their streaming service about what movies and shows the users watched, how long they watched, and whether or not they liked it. Netflix could now accurately predict what type of content customers wanted and then started producing shows and movies based on the data from the streaming service. In short, Netflix went from a digitalized DVD provider to a digitally transformed tv and movie studio. However, they are still delivering all three types of services. DVDs provided Netflix in 2021 with 200M $ of revenue [11], showing a need to balance different types of services and strategies. The challenge of supporting the existing value proposition while at the same time creating new value propositions through innovation is challenging [10]. This challenge is also known as the innovator’s dilemma [3] where existing companies fail to innovate due to the success of their existing portfolio, which is further exacerbated by digital technology and digital transformation, increasing the speed and ability of smaller companies to challenge the existing companies in new ways. Nagji et al. [10] argue that a company’s innovation portfolio needs to be tailored for the company to thrive, i.e. there is a need to balance digitalization and digital transformation. 2.2
Capabilities for Digitalization and Digital Transformation
Building on the distinction between digitalization and digital transformation, there is still a question of what is needed to undertake a digitalization or digital transformation journey. Bosch and Olsson [1] outline four necessary dimensions when transitioning from traditional to becoming a digital (transformed) company.This research based on incumbent companies, is very similar to the context of MarComp as they both have existing physical services that need to be main-
54
R. Ulfsnes et al.
tained simultaneously as they undergo digitalization and digital transformation. They identify four orthogonal dimensions in which companies need to evolve: – – – –
Product upgrade Data exploitation AI/ML/DL Business Model
These dimensions are necessary vectors for change that companies have used to be able to both digitalize and digitally transform. Product upgrade outlines how software allows the product to be upgraded. Bosch and Olsson [1] describe a development going from a traditional physical product, or in the case of software products where the product is 1) “sold as-is,” developing towards 2) more frequent deployments due to quality improvements, followed by 3) data from the use of the products are used to improve the features of the product. In 4) continuous software updates, the system is continuously improved, and finally, 5) all the previous steps are combined into a fully digital product delivery. Data exploitation is a prerequisite for digitalization and digital transformation. Data can be exploited across five key areas: 1) Quality assurance and diagnostics using system behavior data. 2) Product performance and feature usage, where features and performance data are collected and used for product and software development. 3) Customer KPIs, where specific data for the customer are streamed, analyzed, and served back to the customer to provide operational insight. These can be understood as Data Products. 4) Data-as-an-asset, which is data captured from multiple customers, analyzed across the customer base, and served as insights, showing not only operational data compared to one customer, but for all customers. And 5) Secondary customer base, where data from the existing customer base is used to develop and monetize customers outside the traditional customer base. Artificial intelligence (AI), machine learning (ML), and deep learning (DL) are technologies driving the potential of digital technology forward. 1) Data analytics utilize ML for automation and optimization of processes. 2) A data set centric way of working where data permeates the applications, and machine learning models are trained on static data and used directly by the applications. 3) Dynamic data stream, where models are dynamically retrained based on data changes or system behavior changes. Data and changes across the customer base are used to retrain and expand the models. 4) Federated local training and customization, where models and data are deployed and target specific customers with their own set of customization and local models, with dynamic retraining. 5) Fully autonomous usage where the system itself has authority over decisions, mostly associated with autonomous vehicles. One notable challenge with using AI/ML is the risk aversion of top management [8], which limits the potential success of AI initiatives.
Interrelation of Digitalization and Digital Transformation
55
The business model shifts when a company is transforming. One example is going from a transactional model of selling services and products to subscriptionbased models where insight and data are an additional value add for the customers. The shift in business models is also found in other research on digital transformation; Tkalich et al. [17] outline how digital transformation and digitalization simultaneously change the four interrelated elements of a business model: product strategy, revenue logic, distribution model, and the service and implementation model. These changes introduce tensions, which require organizational changes to be overcome. 2.3
Continuous Software Development
The digital dimensions of AI, data, and products require that the company has software development practices to deliver software with higher frequency, quality, and security. Further, a fundamental principle in digitalization and digital transformation is to provide working software to users at regular short intervals to ensure an increase in customer value through feedback. In practice, there needs to be a close and continuous linkage between business, software development, and operations, described as continuous software engineering [6]. A case study by Mikalsen et al. [9] illustrates how cross-functional teams - consisting of business representatives from business development, IT developers, testers, and user experience (UX) designers achieve a continuous business planning process, development, and maintenance. The need for agile software development teams to interact with other units in the organization dynamically and responsively is why companies today aim to scale agile methods beyond software development. Mixing AI/ML/DL, data, and digital business offerings into these activities have made software development more complex. The reason is that agile software teams must cooperate with non-agile units. Agile teams work highly iterative in a sense and response manner while other organizational functions may operate at a steady pace, avoiding change [5].
3
Method
We report findings from a company that was focusing on both digitalization and digital transformation. Their product development area is our unit of study. It allows us to understand how multiple disciplines from multiple organizational units interact when improving existing and creating new software-based products. Some of the new products supported the existing value proposition while others were redefining it. Our study is a holistic case study [24]. According to Yin, case studies are the preferred research strategy when a “question is being asked about a contemporary set of events over which the investigator has little or no control” (ibid, p. 9). We followed the five-step process proposed by Yin: 1) Case study design. 2) Preparation for data collection. 3) Collecting evidence: execution of data collection on the studied case. 4) Analysis of collected data, and 5) Reporting.
56
R. Ulfsnes et al.
3.1
Case Company
MarComp (name suppressed for anonymity) is a multinational provider of services for the energy, process, and maritime industries with over 3700 employees. They were chosen because they participated in a research program on digital transformation. The company recognized a critical issue of missing interaction between software development, sales, marketing, and operations, which led to a transformation initiative. In 2019 the company established an innovation framework based on the Corporate Startup [21]. The framework consists of a six-part stage-gate process in which a committee controls which initiatives to move to the next stage or are to be stopped. MarComp has set out a dual transformation agenda, renewing and growing their existing services through digitalization and establishing new digitally transformed services on top of existing ones. Table 1. Data sources Data source
Location
Time
Participants
Data gathered
Innovation framework, lean startup
Virtual
Sep. 2020–May. 2021
15 Interviews with 5 product managers
Interviews on the startups, innovation process, work processes, software development process, context, stakeholders
Digitalization program
Virtual & physical
May. 2021–Jun. 2021
5 interviews with discipline leaders
Interviews on transformation of discipline, road-maps, transformation process, context
Workshop and meetings
Physical
Oct. 2021
1 Digital transformation workshop (1 manager, 1 data science lead, 2 leaders of software development, head of AI and data analytics, 2 program managers
Written notes, written material from participants
Strategy documents
Apr. 2021–Dec. 2021
Strategy documents, project descriptions, road-maps
Interrelation of Digitalization and Digital Transformation
3.2
57
Data Collection and Analysis
Our data collection (Table 1) started in 2020 when the company needed to rethink the product development process to reach the estimated earnings of several digital solutions. The ideas and initiatives in the innovation framework can be categorized as digitalization efforts or digital transformation efforts. The researchers participated in internal meetings, customer meetings, and workshops initiated by the innovation framework. All activities were documented by taking notes, meeting minutes, and pictures of materials produced in the workshops. Also, we got access to product documentation, contracts, and data on user activity on some of the digital products. We ended the data collection in December 2021. The results were presented back to the practitioners in feedback meetings. We used a variety of strategies to analyze the material [12]. Through several iterations, we utilized a combination of descriptive and holistic coding to build an understanding of the data. Firstly, building up a set of descriptive codes before consolidating them into groups of themes based on the dimensions (AI, data exploitation, business model, product upgrades) as outlined by Bosch and Olsson [1]. After grouping into themes, we applied Strauss and Corbin’s [4] coding paradigm that involves context, causal conditions, intervening conditions, strategies, and consequences. This method was then used to structure the strategies, intervening conditions, and consequences for the phenomenon of digitalization and digital transformation based on the distinction by Wessel et al. [22]. The qualitative coding was done using NVIVO 1.6.2 and performed on both documents and transcribed interviews. This combination of top-down and bottom-up coding ensures that the codes stay true to the data and that relevant literature is considered.
4
Results
We present the challenges and enablers for software development in digitalization and digital transformation, respectively, and demonstrate how they interrelate. Table 2 contains the complete list of identified intervening conditions and strategies uncovered in the analysis. In the following sections, we will detail some of the findings. 4.1
Strategies for Digitalization
Machine Learning is a Crucial Enabler for Digitalized Services. This is exemplified by a service where ML is used to assist customers in answers to questions with the combination of domain experts providing the learning input to the machine learning algorithms. Another example is a service used to predict the wear and tear on various parts of a ship (predictive maintenance). The strategy highlights AI’s role in current and future services, which rely on vast amounts of data. Moreover, the roadmap for the digitalization program highlights the need for a common data platform.
58
R. Ulfsnes et al. Table 2. Strategies and challenges for digitalization and digital transformation Strategies
Intervening conditions
Digitalization
Machine learning and AI capabilities Data scientists understanding the business domain and context Digital transformative services (new value proposition) are used to coerce customers into sharing data Data standards as an opportunity Customer self-service through digital services
Digitalization of services through cross-department alignment Lack of resources Key performance indicator setup Charging extra for digitalized services Aligning data science with software development Slow uptake of data standards Top management sees lean startup as a risky approach Risk aversion to AI in management and explainable AI Mixing legacy and digital solutions
Digital mation
Data from digitalized services enables digital transformation Machine learning is a key enabler for digital transformed services Organizational changes Customer contact to validate problem and solution
Aligning data science with software development Selling digital services with different value proposition is challenging Order2Cash process and ERP system do not support new services Legal basis for using data for new services Lack of resources New service might change how Marcomp is viewed Top management sees lean startup as a risky approach Risk aversion to AI in management and explainable AI
transfor-
Data Scientists Understanding the Business Domain and Context. This is presented as an essential aspect from the data scientist perspective and the business side. The program managers and the head of AI emphasize the importance of data scientist knowledge of the business domain and the project manager’s understanding of the possibilities and implications of using AI. This is shown when the data scientists and business development people have joint workshops to educate each other about the business and machine learning domains. The head of AI explains: “We did not have to bring the data scientist into the workshops, but we invited a lot of them, it is important that they get to know each other. Get to learn what is important for the business and what projects are coming”. Digital Transformative Services (New Value Propositions) are Used to Coerce Customers Into Sharing Data. One key challenge with digitalization is the change from the customers reporting information manually through documents and forms to direct data connections to sensors. However, the incentive for the customer/partner to participate in data sharing is elusive, asking the question “What’s in it for me?” One explained “It is not sufficient to deliver the same services as today, you have to a provide a new kind of value. The value lies within the new opportunities that arise. You can make it more efficient and easier for the customer, but the customer is interested in new services.” This requires collaboration with the customer vendors producing the various components that go into a product. One project manager explained: “The vendor
Interrelation of Digitalization and Digital Transformation
59
could see themselves wanting new functionality building on the sensor data. They lacked machine learning expertise, so we proposed to develop the module jointly when we had the data in our systems.” Cross Department Workshops. Digitalization is a cross-organizational effort where groups with various responsibilities, tasks, and competencies share knowledge and coordinate their action. This can be achieved through crossorganizational workshops. Digitalization represents an opportunity to understand how work processes go across departments. In addition, the digitalization effort will directly affect how the different departments’ daily work will be affected, and the personnel must have ownership of the new digital solutions. A project manager explained: “It is not just about us as a project coming in and telling them what to do, we want them to have ownership, we need to have participants from different departments in order to capture challenges across the departments.” Customer Self-service Through Digital Services. When the customer is able to assist themselves without involving MarComp personnel, the workload on both customers and internal resources is reduced. Multiple initiatives at MarComp aim to automate jobs usually performed manually by either the customers or the employees of the company. In addition, the self-service systems also provide additional capture of data about the users, both internally and externally, providing the possibility to develop services further. “The digital channels give us direct contact with the technical personnel at the company, thus providing us with the data and insight to develop new services” (Project manager). Data Standards as an Opportunity. The establishment of public data standards through ISO was seen as a strategic move to enable other vendors and technical solutions to use the standard the company used internally. This enables the company to much easier integrate different data sources into their data ingestion platform as the standards match. 4.2
Intervening Conditions for Digitalization
Aligning Data Science with Software Development. Data science as a new practice (including roles, competency, tools, etc.) extends the organization with new capabilities. This must be aligned with established software development for the two functions to coordinate and collaborate. A data analytics team cannot contribute without a coordinated effort with, e.g., software development or business development. Hence, further, development needs to clarify which parts of the organization need to align so that they together drive digitalization as a joint effort without hampering each other. Lack of Resources. Digitalization requires new competence and resources, e.g., data scientists and/or changes in the technological platform. The simultaneous software initiatives further exacerbate the issue by adding additional parallel projects. In addition, the involvement of employees in understanding the current work process is essential. One project manager complained “Even though NN
60
R. Ulfsnes et al.
does not have the capacity, he is the person we need. But he works in a small unit, so there are not many people to help out if he is not working operationally.” This also serves as an example of core personnel needing to balance the innovation of new services and the operation of existing ones. For data science, this was a particular problem as the requirement for understanding the business domain was critical. To the level that new data scientists could not understand existing code and had to rewrite it. Key Performance Indicator setup. Existing KPIs are set up as a quantitative representation of the production of, for example documents. In one initiative, we found that the goal of the digitalized solution is to reduce the number of manual document checks and instead provide a digital solution. However, the current KPIs measure the number of documents handled per week per employee. Thus, there is no incentive for the employee to help with digitalization. On a departmental level, this is also found where the departments are measured through the cost center. Still, the digital solution does not have the possibility of granulating the cost per department. Charging Extra for Digitalized Services. Investing in digitalization efforts and expecting the customer to pay extra for the new digital service is challenging. As described by a product manager, “What should it cost for the customer, if they respond ’why should I pay more for this?’. But it costs money to develop the service, how should you respond to that?” One approach was to add “buy” buttons that the users could click to measure their willingness to pay. Slow Uptake of Data Standards. Digitalization driven by increased production, sharing, and use of data increases the need for data with the right quality and transferability. One challenge is getting access to the data in a timely fashion, another critical aspect is the format and structure of the data. Each vendor with a different format and structure requires the data scientist and the managers to collaborate and discuss with the vendor to understand and contextualize the data. 4.3
Strategies for Digital Transformation
Data from Digitalization Enables Digital Transformation. Identifying new ideas is possible due to the data gathered through previous digitalization efforts. Using existing data to build new solutions has benefits, such as making it easier to explain and get user feedback due to using actual customer data. Building on this, the company can further scale the new solutions easier as the data is already captured and understood. One project manager reflected: “It is important that we take advantage of the opportunity we get from the availability of the new data. It is important not only to capture the data but to build on it.” Machine Learning is a Key Enabler for Digitally Transformed Services. However, for the digitally transformed services, the ML capabilities are not mainly used to optimize current processes but to create new solutions based on the digitalized data. Examples are utilizing ML and AI methodologies on historical data to build predictions on how ships and components will behave.
Interrelation of Digitalization and Digital Transformation
61
Organizational Changes. The digital transformed services are different in value proposition than existing services. This leads to higher uncertainty, and several iterations and pivots are needed before a working version is discovered. Further, product managers are moved out of the production line to have decision authority and the ability to work on the development of the new product. One product manager elaborated “This program gives us the possibility to take decisions on our own product, compared to previously this has dramatically reduced the amount of discussion and coordination between other initiatives.” Customer Contact to Validate Solutions. Contact customers or users to validate a service with a new value proposition. Through contact, the product managers are able to pivot the solution and try new approaches. This was made easy when the service was using existing customer data as a basis for the solution. One product manager said “We got lots of good feedback because it was based on real data. They could click around and try stuff. And we got great feedback from just four-five customers. Based on that, we were able to build a new version pretty fast.” 4.4
Intervening Conditions for Digital Transformation
Selling Digital Services with Different Value Propositions. Sales of digital services with a new value proposition are fundamentally different from sales of traditional services. The new services target different parts of the customer organization than what the current sales network knows. It also changes from a more transactional contract-based model to a more subscription or one-time buy model. One project manager explained “There is no good plan for how to take the products to market. We need someone to develop products. Previous projects have shown that the current setup does not work. Order2Cash Process and ERP System Do Not Support New Services. To support new payment models and subscription-based services, the Order2Cash process needs to accommodate new ways of ordering and invoicing services matching the new business model. Developing the necessary changes to the ERP system has high costs and is challenging to execute. A product manager told us “There was a lot of resistance. We cannot change the systems just because of one service; we need a bigger discussion around this. We have been waiting for over a year.” New Services Might Change how MarComp is Viewed as a Brand. Some concerns have been raised about the focus on new services beyond the current service offering MarComp is delivering and the effect this can have on the commercial side. Top-Management Sees Lean Startup as a Risky Approach. Through the use of lean startup concepts, there is an emphasis on getting feedback from customers as soon as possible to validate the problem and eventual solution. The idea of bringing unfinished systems and presenting them to customers is
62
R. Ulfsnes et al.
not received well by top management; one product manager said “They hold back, they are not willing to let it out for us to test, they were not negative to the product, but letting it out.” Risk Aversion to AI in Management and Explainable AI. By utilizing AI and machine learning, new predictive solutions are developed, limiting the number of manual inspections of ships that the company has to do. Implementing the system in production can be challenging due to risk aversion in management, not trusting the algorithms, and how accurate they are as compared to trusted manual services. Further, it is difficult to explain how machine learning works and how the outputs are calculated. One project manager said “We have a fantastic system, but it is very difficult to tell the users so they know how to use it properly.”
5
Discussion
Motivated by the need to understand the interrelation between digital transformation and digitalization, we conducted a longitudinal case study in MarComp, a multinational provider of services for the energy, process, and maritime industries. We have reported on strategies and intervening conditions for digitalization and digital transformation and how these factors are related. We now discuss the case in light of our research question. How are digital transformation and digitalization interrelated?
Fig. 1. Digitalization provides data
Interrelation of Digitalization and Digital Transformation
63
Firstly we note that data from digitalization is a crucial enabler for digitally transformed services, providing the underlying data for innovation which may redefine and/or create new value propositions in the company. So to succeed with digital transformation which is a data-driven process, digitalization is important as it gives access to the needed data. We observe this relationship in our results, where data is first gathered through the digitalization of some product or services; this can be seen in Fig. 1. There are multiple intervening conditions for developing digital services, one being the ability to obtain, capture, and consume data from third parties. This corroborates well with Vial [20], where data availability is seen as a key building block for digital transformation.
Fig. 2. Interrelation between digitalization and digital transformation
Further, we observe that MarComp, after gaining experience with digitalization and novel new products with a different value proposition from previous products, defines a dual digitalization and digital transformation. In Fig. 2, we observe how the relationship between digitalization and digital transformation unfolds. We also see shared strategies and intervening conditions; AI/ML integrated into the teams is a strategy for both phenomena, just as lack of resources hinders both. In addition, we find a need for a mediating role between the different aspects of the dual transformation, AI, Data, agile software engineering, and changes in work practice (internally or externally). In our case, we see that product management takes this mediating role, which is in line with other studies [18].
64
R. Ulfsnes et al.
Most notably, we see that not only is data from digitalization crucial for kick-starting digital transformation, but the promise of digital transformations, through its significantly different value proposition, is a way for the company to acquire more data for digitalization. The customers and vendors are interested in new services and the added benefit it can provide them beyond just giving data away. Especially co-creation of value through shared data and insights was perceived as valuable. The concept of delivering more value to the customers corroborates well with Bosch and Olsson [1], where the customer’s KPIs were used to provide more value to the companies, although in our case, this also involved vendors. Thus, the relationship between digitalization and digital transformation is more complex than simply that the one is enabling the other. This does not necessarily mean that an organization must fully complete digitalization before transforming, but that parts of the business model can be addressed individually. Over time, this can become a system of careful experimentation, where confidence in the ability to transform grows over time, similar to how the innovation portfolio needs to be balanced as reported by Nagji and Tuff [10], and where companies need to further engage in innovative activities on top of digitalized products. From our case study, we have found that digitalization and digital transformation share many of the same intervening conditions and strategies and are related. Wessel et al. [22] described two cases showing two distinct paths where company A chose the path of digitalization. In contrast, case B showed a big bang transition towards a new organizational identity i.e., digital transformation. Our data shows that there is no clear distinction between these two phenomena.
6
Conclusion and Future Work
We have conducted a 15-month study of professionals in a maritime company. We found that digitalization and digital transformation are interrelated and that it is more complex than simply that the one is enabling the other, i.e., it is not necessarily that an organization needs to complete digitalization before it can transform. We even found that digital transformation enables continuous digitalization. We found several intervening conditions and strategies for digitalization and digital transformation; some where shared, and some where unique to the phenomenon. In addition, we noticed that balancing digitalization and digital transformation is crucial to both concepts due to the interrelation between them. Future work should dive deeper into the strategic element of balance and what roles and processes are needed to undertake digitalization and digital transformation.
References 1. Bosch, J., Olsson, H.H.: Digital for real: a multicase study on the digital transformation of companies in the embedded systems domain. J. Softw. Evol. Process 33(5) (2021). https://doi.org/10.1002/smr.2333
Interrelation of Digitalization and Digital Transformation
65
2. Chanias, S., Myers, M.D., Hess, T.: Digital transformation strategy making in predigital organizations: the case of a financial services provider. J. Strateg. Inf. Syst. 28(1), 17–33 (2019) 3. Christensen, C.M.: The Innovator’s Dilemma: When New Technologies Cause Great Firms to Fail. Harvard Business Review Press, Boston (2013) 4. Corbin, J., Strauss, A.: Basics of Qualitative Research: Techniques and Procedures for Developing Grounded Theory. Sage Publications, Thousand Oaks (2014) 5. Dikert, K., Paasivaara, M., Lassenius, C.: Challenges and success factors for largescale agile transformations: a systematic literature review. J. Syst. Softw. 119, 87–108 (2016) 6. Fitzgerald, B., Stol, K.J.: Continuous software engineering: a roadmap and agenda. J. Syst. Softw. 123, 176–189 (2017) 7. Legner, C., et al.: Digitalization: opportunity and challenge for the business and information systems engineering community. Bus. Inf. Syst. Eng. 59(4), 301–308 (2017). https://doi.org/10.1007/s12599-017-0484-2 8. Mikalef, P., Gupta, M.: Artificial intelligence capability: conceptualization, measurement calibration, and empirical study on its impact on organizational creativity and firm performance. Inf. Manag. 58(3), 103434 (2021). https:// doi.org/10.1016/j.im.2021.103434. https://linkinghub.elsevier.com/retrieve/pii/ S0378720621000082 9. Mikalsen, M., Moe, N.B., Stray, V., Nyrud, H.: Agile digital transformation: a case study of interdependencies. In: Proceedings of the 39th International Conference on Information Systems (ICIS). Association for Information Systems (AIS) (2018) 10. Nagji, B., Tuff, G.: Managing your innovation portfolio. Harvard Bus. Rev. 90(5), 66–+ (2012). https://www.webofscience.com/wos/woscc/summary/5212a7b4e4b8-40a5-b267-3f713dcf2e44-3f746540/relevance/1. Place: Watertown Publisher: Harvard Business School Publishing Corporation WOS:000303032800014 11. Netflix: Netflix financials - annual reports & proxies. https://ir.netflix.net/ financials/annual-reports-and-proxies/default.aspx 12. Salda˜ na, J.: The Coding Manual for Qualitative Researchers, 2nd edn. SAGE, Los Angeles (2013). oCLC: ocn796279115 13. Sanchez-Gonzalez, P.L., D´ıaz-Guti´errez, D., Leo, T.J., N´ un ˜ez-Rivas, L.R.: Toward digitalization of maritime transport? Sensors 19(4) (2019). https://doi.org/10. 3390/s19040926 14. Sebastian, I.M., Ross, J.W., Beath, C., Mocker, M., Moloney, K.G., Fonstad, N.O.: How big old companies navigate digital transformation. In: Strategic Information Management, pp. 133–150. Routledge (2020) 15. Shahzad, B., Abdullatif, A.M., Ikram, N., Mashkoor, A.: Build software or buy: a study on developing large scale software. IEEE Access 5, 24262–24274 (2017) 16. Sporsem, T., Hatling, M., Mikalsen, M.: Invisible data curation practices: a case study from facility management. Norsk IKT-konferanse for forskning og utdanning (2) (2021). https://ojs.bibsys.no/index.php/NIK/article/view/952 17. Tkalich, A., Mikalsen, M., Moe, N.B., Sporsem, T.: Digital transformation of a traditional business model: a case study from the maritime industry. ECIS 2021 Research-in-Progress Papers, June 2021. https://aisel.aisnet.org/ecis2021 rip/42 18. Tkalich, A., Ulfsnes, R., Moe, N.B.: Toward an agile product management: what do product managers do in agile companies? In: Stray, V., Stol, K.J., Paasivaara, M., Kruchten, P. (eds.) XP 2022. LNBIP, vol. 445, pp. 168–184. Springer, Cham (2022). https://doi.org/10.1007/978-3-031-08169-9 11
66
R. Ulfsnes et al.
19. Verhoef, P.C., et al.: Digital transformation: a multidisciplinary reflection and research agenda. J. Bus. Res. 122, 889–901 (2021). https://doi.org/ 10.1016/j.jbusres.2019.09.022. https://linkinghub.elsevier.com/retrieve/pii/ S0148296319305478 20. Vial, G.: Understanding digital transformation: a review and a research agenda. J. Strateg. Inf. Syst. 28(2), 118–144 (2019). https://doi.org/10.1016/j.jsis.2019.01. 003 21. Viki, T., Toma, D., Gons, E.: The Corporate Startup: How Established Companies Can Develop Successful Innovation Ecosystems. Vakmedianet Management B.V. (2019). https://books.google.no/books?id= IeVwAEACAAJ 22. Wessel, L., Baiyere, A., Ologeanu-Taddei, R., Cha, J., Blegind-Jensen, T.: Unpacking the difference between digital transformation and IT-enabled organizational transformation. J. Assoc. Inf. Syst. 22(1), 102–129 (2021) 23. Yeow, A., Soh, C., Hansen, R.: Aligning with new digital strategy: a dynamic capabilities approach. J. Strateg. Inf. Syst. 27(1), 43–58 (2018) 24. Yin, R.K.: Case study research: design and methods. In: Applied Social Research Methods Series, vol. 5. Sage Publications (1989)
Open Access This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made. The images or other third party material in this chapter are included in the chapter’s Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter’s Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.
Overcoming Barriers to Digital Transformation – Development of a Decision Matrix Henning Brink1(B)
, Sven Packmohr2
, and Fynn-Hendrik Paul1
1 BOW, Osnabrück University, Osnabrück, Germany {henning.brink,fynn-hendrik.paul}@uos.de 2 DVMT, Malmö University, Malmö, Sweden [email protected]
Abstract. Digital Transformation (DT) impacts industries, non-profit sectors, higher education, and even societies. As connectivity technologies blend with physical assets, modifications in value creation processes are provoked. These modifications may have positive impacts such as higher effectivity, enhanced business models, and improved customer connection. However, realizing a DT is a complex endeavor. Specific properties, so-called barriers, hinder the DT journey. Thus, it is essential to grasp the barriers and indicate ways to overcome them. We develop a decision matrix for overcoming barriers using qualitative data from participants working in different sectors. This work builds upon a pre-study developing a barrier classification and enhances it with specific recommendations such as “define clear DT responsibilities”. Thus, our work takes the development of plain barrier classifications further. From a theoretical perspective, this work contributes to developing hypothetical models of the effects of recommendations to overcome barriers in the future. From a practical perspective, companies can use the recommendations to plan actions to take. Keywords: Digital transformation · Barrier · Countermeasures
1 Introduction The advances in overall digitalization and the association between digitalization and value creation are at the heart of digital transformation (DT). DT alters processes and workflows through the integration of information and communication technologies. Thus, transformation is described as a phenomenon bringing significant changes in “traditional ways of doing business by redefining processes and relationships” [1]. Following this viewpoint, DT includes a wide variety of research fields ranging from technology and software products to strategy and business models. In the discipline of Information Systems (IS), these fields intersect [2]. DT opens up for a combination of smart products and services, leading to servitization [3]. With the emergence of digital platforms and possibilities to capture real-time data, new business models that optimize the processes occur [4]. In corporations, expectations © The Author(s), under exclusive license to Springer Nature Switzerland AG 2022 N. Carroll et al. (Eds.): ICSOB 2022, LNBIP 463, pp. 67–82, 2022. https://doi.org/10.1007/978-3-031-20706-8_5
68
H. Brink et al.
about DT are high as it indicates improvements in efficiency, productivity, customer contact, and competition [5]. DT changes workplace settings and by this affects employee functions and competencies [3]. Thus, DT lays the foundation for gaining competitive advantages. Digital pioneers grow faster and are more profitable [6]. However, expectations are not realized easily. Companies experience difficulties in grasping DT potential [7]. Actually, an adoption, a diffusion, and a development of revised and digitalized processes face several barriers [8]. Thus, less innovative corporations are susceptible to underestimating the efforts required to drive innovations [9]. If companies do not consider and tackle these barriers, they would fail in the accomplishment of DT potentials [10]. Studies reporting failure factors are less prevalent than those that report success factors [9]. Thus, we address this research gap by focusing on the failure factors which could slow down, halt, or deform a DT. We address these failures as barriers [11]. A recognition of the nature of barriers, their causes, and related stakeholders is vital for the identification of countermeasures and reduction of the negative effects. In IS literature, structured approaches to connect barriers and countermeasures are lacking. Looking at the most frequent models for digital readiness and maturity, only a minor part provides suggestions for overcoming [12]. Thus, the research question was determined as follows: How can companies overcome barriers to digital transformation? Within this research, we matched barriers with proposals for overcoming them. Our sector-independent research contributed to a wider discussion of barriers within the IS community. As our study connected barriers with their countermeasures in a structured way and culminated in a decision matrix (DM), it lies the groundwork for hypothetical models to model causal relationships. The most common reaction to a barrier in companies is trying to avoid them or implementing ad-hoc countermeasures [9]. Our findings could be employed by industrial practitioners to map the DT barriers and to produce well-aligned countermeasures for a successful DT. Also, our results contribute to the development of readiness and maturity models. If the DM is converted from a two-dimensional into a sequential approach, it could be a base for step-wise models. We followed the succeeding structure to resolve the research problems: The introduction section was followed by a brief theoretical background. In the third section, we described our research design, including the coding approach. The fourth section discussed the connection between the barriers and the countermeasures. A DM was presented to identify countermeasures. The paper ended with discussion and conclusion sections that included the study’s limitations.
2 Theoretical Background Interest in DT has increased in research and practice. Aggregated definitions [10, 13] aim at generic descriptions of the impact of digital technologies on corporate enhancements. Specifically, these enhancements are associated with value creation, organizational structure, and distribution of finances [7], leading to a complex DT due to the requirement for adequate management [14]. DT is different compared to IT-enabled organizational transformation (ITOT). DT redefines value propositions, while ITOT supports these [15].
Overcoming Barriers to Digital Transformation
69
ITOT is similar to DT as a concept to use digital resources to set-up a differentiated value creation [16]. As the redefinition of the value propositions gets complex, barriers to DT increase more than with an ITOT. DT alters socio-technical constructs that were previously negotiated by using nondigital artifacts or relationships. Today, these constructs are negotiated by digitized artifacts and relationships [17]. Barriers originate from changes in socio-technical structures that prevent, slow down, or deform the DT process [18]. As DT is a universal occurrence, c-suite and middle managers need to overcome the barriers affecting DT. If managers understand how to better interweave physical and digital elements, barriers will decrease. As barriers are complex constructs, managers should adopt a holistic approach to DT to re-combine socio-technical elements. Often, barriers evolve from a leadership level or through environmental factors [9]. To determine the findings of previous studies on barriers to DT, we performed a systematic literature review [19]. The review was conducted using services such as Scopus, EBSCO, and AIS Electronic Library and a search string containing the words digital transformation and barriers as well as synonyms. It generated 562 articles (excluding duplicates). After a first screening, 148 articles were found applicable for our field of study. After several in-depth qualitative checks, we finally identified 99 applicable studies [20]. The number of studies demonstrated the importance of the field. In the most prominent stream of literature, authors listed barriers to a particular technology [21]. Some studies applied an interpretative approach and clustered barriers based on internal and external perspectives [22]. Whereas others take a timely perspective of short-term orientation, and strategy [23] or a certain type of companies such as micro, small and medium-sized enterprises into account [24]. Other works took a more structured approach by using interpretive structural analysis to model dependencies between barriers [25–27]. A minor research stream takes even recommendations on overcoming barriers into account. Recommendations are solutions or advice to take a certain action to overcome a barrier [28]. Often, these studies do not focus on the complex interdependencies of barriers and recommendations. Examples are that educational offers are helping to overcome the missing knowledge of employees [29] or that an IoT implementation with systemic complexity might require external technical experts [30]. Further exploration of complex causal relationships is missing. From the review, we conclude that research is focusing on identifying barriers. Research on overcoming barriers would be a logical next step but is often still missing. Thus, our current study is contributing to closing this gap and is adding relevance [31] to the field of overcoming barriers. We employed comprehensive data to come to a structured DM for decision-makers. The review revealed that no such scientific research has been conducted before regarding DT barriers. Although structured approaches exist for barriers, there are rarely recommendations to overcome them. Previous studies applied barriers in various research approaches focusing on technology-enhanced business models, better customer relations, or more well-organized operations [32]. Often, the focus was on specific technologies or stakeholders, which limited generalizability. Thus, we did not focus on specific technologies or industries to balance the view between social and technical implications. This allows a holistic analysis leading to higher generalizability [33].
70
H. Brink et al.
3 Method To answer our research question, we conducted the three phases of development of a barrier model [34], identification of recommendations to overcome barriers, and formulation of a DM with the relationships between barriers and recommendations. We present this research design in more detail below. In the first phase, we adopted a triangulation approach to develop a DT barrier model by employing comprehensive data [35] to reach findings at the cross-section of different data sets [36]. In two data series, we asked participants about perceived DT barriers. For the first data set, we conducted 46 semi-structured interviews from March 2017 to October 2018 using a joint interview guideline. Participants were asked for an introduction, the status quo of DT in their company, and potential barriers. The interviewees were experts involved in DT projects or in charge of DT in their companies. To obtain a diversified sample, which allows deriving the most insights [35], interviewees from different sectors and positions were interrogated (cf. Table 1). The interviewees are based in Germany, Austria and Switzerland. Table 1. Interview sample. Industry
Position
N
Automotive
Head of R&D, Engineer, Digital Manager, Managing Director
14
Agriculture
Head of Quality Management, Managing Director, IT Manager, Operations Manager
9
Plastics industry
Head of Production, Head of R&D, Shift Supervisor, Engineer
5
Steel industry
Managing Director, Head of Production Intelligence, Head of Production and Innovation
4
Services
Information Manager, IT Support, Managing Director
3
Consulting
Consultant
3
Manufacturing
Business Development Manager, Operations Manager, Chief Technology Officer, Head of Production
8
We analyzed the interview transcripts using an inductive coding approach [37]. The codes relating to barriers were iteratively aggregated and revised. While categorizing, we oriented towards a socio-technical perspective [33]. The result of this procedure was an initial model on DT barriers with several dimensions and characteristics. To validate and enrich the initial model, we gathered additional qualitative data from 525 completed online questionnaire. The questionnaire participants were determined in the same way as the interviewees by calls in personal and professional social networks. Three hundred forty participants responded and completed the survey. Although non-random sampling could be employed to explore a domain, it could potentially lead to bias [38]. To overcome this disadvantage, additional participants in four companies, who replied to a social network call, were surveyed. This phase of data collection was
Overcoming Barriers to Digital Transformation
71
conducted with the random sampling approach. Thus, additional 185 participants completed the same voluntary and anonymous online survey. A total of 525 participants determined with both random and non-random sampling methods participated in the survey between December 2019 and April 2021. Most of the respondents (60%) lived in German-speaking countries. The sample includes responses from European nations and non-European nations such as Turkey and the U.S. resulting in cross-country data. Detailed information on the diverse sample is presented in Table 2. Table 2. Questionnaire sample. Criteria
Attribute [Relative share of participants]
Sector
Automotive [18%] | Construction [13%] | Finance & Insurance [14%] | Food [7%] | Information and communications technology [3%] | Mechanical & plant engineering [9%] | Wholesale [16%] | Other [17%] | Not stated [3%]
Position
Manager [6%] | With personnel responsibility [26%] | Without personnel responsibility [55%] | Intern [4%] | Other [6%] | Not stated [3%]
Company size ≥1,000 [35%] | 250–999 [17%] | 50–249 [33%] | 10–49 [9%] | ≤9 [3%] | Not stated [3%]
We coded the questionnaire data deductively by using the dimensions and characteristics of the initial model. Since we could not fit all 1,372 statements on barriers from the questionnaire data into the initial model, we refined and extended it [39]. To do so, each author individually open-coded the 466 left-over statements. After, we discussed and aggregated the codes within the team and with external colleagues to determine a set of revised dimensions and characteristics. Through these rounds of individual work and consensus, we ensured inter-coder reliability [40]. The result was a revised coding guideline. Subsequently, all 1,372 statements were deductively coded again using the revised coding guideline. The result of this approach is a valid triangulated model for barriers to DT with dimensions ranging from socio to technical to cover the broad domain of IS [8]. In the second phase, we used the same data collection of the 525 completed online questionnaires mentioned above (see Table 2). In the questionnaire, the participants not only stated barriers, as described in phase 1, but also stated recommendations to overcome the perceived barriers in open-ended questions. The participants were required to link the recommendations to their stated barriers. Using this identical data collection allows us to keep track of the relation between each respective barrier and their respective recommendations. As in the case of the barriers, the recommendations were individually coded by each author with an open coding approach [39]. Again, the individually determined codes were discussed to achieve inter-coder agreement. The revised coding structure was used to code all 1,256 overcoming statements again. Thus, the interim result consists of 39 different recommendations to overcome barriers to DT. In the third phase, we use the results from the coded barriers and the coded recommendations to set up a DM consisting of two axes representing the barriers and the recommendations. Based on the first and second phase, 1,372 statements on DT barriers
72
H. Brink et al.
and 1,256 related statements on ways to overcome them were collected. By asking participants about a perceived barrier first and a recommendation then, we can indicate their relationship. We always preserved the linkage between those two in our data. Therefore, each cell of the DM indicates the relationship between a single barrier and a single recommendation.
4 Results In a pre-study, we determined a wide range of socio-technical [8, 33] barriers to DT. The barriers are divided into seven different dimensions. In total, 29 barriers were isolated based on the perceptions of the questionnaire participants. These barriers form one axis of the following DM. Therefore, they are briefly presented in Table 3. A more detailed description of the barriers can be found in the pre-study publication [34]. Table 3. Barriers to digital transformation [34]. Dimension & characteristics [code for DM] Missing skills: Missing organizational knowledge [MS1] | Missing DT potential knowledge [MS2] | Missing implementation knowledge [MS3] | Missing user technology knowledge [MS4] | Insufficient training & learning [MS5] Technical barriers: Deficient IT infrastructure [TB1] | Isolated systems [TB2] | Security issues [TB3] | Missing technical support [TB4] Organizational misalignment: Lacking DT roadmap [OM1] | Immature decision-making [OM2] | Lack of change management [OM3] | Lack of communication [OM4] Corporate cultural barriers: Deficient innovative spirit [CC1] | Missing error culture [CC2] | Sticking to the status quo [CC3] | Diffuse fears & insecurities [CC4] | Silo thinking [CC5] Structural mismatch: Bureaucracy [SM1] | Process complexity [SM2] | Lack of financial resources [SM3] | Lack of personnel resources [SM4] | Over-aged employee structure [SM5] Regulatory restrictions: Restrictive laws [RS1] | Volatile & obscure legislation [RS2] | Lack of political engagement [RS3] Market restrictions: Lacking customer pull [MR1] | Restrictive value network [MR2] | Volatile technology environment [MR3]
In the current study, we identified 39 different recommendations to overcome barriers derived from 1,256 statements. These recommendations form the second axis of the DM. To further cluster the recommendations, we sorted them into the different subsystems human, technology, organization, and the organizations’ surrounding framework [41]. These subsystems need to be considered in a socio-technical system according to the authors Dregger et al. [41]. Using this systemization allows us to group related recommendations and it creates a common perspective within the results. Table 4 shows the coded recommendations, which will be presented in detail. Starting with the human subsystem, our study provides recommendations in terms of leadership. Generally, participants recommend ensuring top management support.
Overcoming Barriers to Digital Transformation
73
This includes to accelerate decision-making. Decisions need to be implemented faster in today’s fast-paced digital competition. Reducing the level of hierarchy required to make decisions that trigger DT can enable faster action. Another important aspect is that short-term orientation needs to change to thinking with foresight. This process is lengthy and need to be supported by extrinsic motivational factors. In this respect, top management should derive and determine DT targets and develop a clear DT roadmap. The roadmap should be aligned with the company’s strategy and guiding principles. It can be inspired by best practices in the business environment. By making use of all kinds of data available, the roadmap needs to be realistic to allow for project and capacity planning. The roadmap must be communicated to provide transparency over the transformation process. If information is shared, barriers can be overcome according to the participants. It is imperative to inform employees about the targets and projects, for example in regular meetings, and keep them up to date with results. It is crucial to take employees’ fears and concerns seriously. Educating about the benefits and need of DT projects helps to take away fears of uncertainty and change. It signals top management’s serious offer to take care. “DT must not be seen as a threat, but as an opportunity not only for the company but for each individual” [Participant]. Thus, it is recommended to present the advantages and savings of new ways of working to the employees and actively support them in the changeover. Table 4. Recommendations to overcome barriers. Subsystem & recommendations [code for DM] Human: Accelerate decision-making [H1] | Thinking with foresight [H2] | Develop a clear DT roadmap [H3] | Provide transparency over the transformation process [H4] | Educate about the benefits and need of DT projects [H5] | Promote open communication and creating transparency [H6] | Involve and motivate employees [H7] | Be open-minded to changes [H8] | Engage staff to realize their ideas and projects [H9] | Create capacity among employees [H10] | Conduct a competence gap analysis [H11] | Offer or intensify demand-oriented employee training [H12] | Use external expertise [H13] | Recruit or provide suitable staff [H14] | Rejuvenate the workforce [H15] Technology: Extend or modernize IT-Systems [T1] | Harmonize IT infrastructure [T2] | Collect and analyze data [T3] | Ensure data security [T4] | Design simple and intuitive systems [T5] Organization: Release or increase a separate budget for DT [O1] | Prioritize investments in DT [O2] | Conduct (long-term) cost-benefit analysis [O3] | Take advantage of financial support from the state [O4] | Streamline organizational processes [O5] | Flatten and simplify organizational structures [O6] | Increase scope for decision-making on lower levels [O7] | Implement IT support [O8] | Centrally coordinate DT efforts [O9] | Define clear DT responsibilities [O10] | Promote cross-functional collaboration [O11] | Implement agile project management and design methods [O12] | Provide improved working conditions [O13] | Move customers to the center of attention in the development of solutions [O14] | Simplify and expand customer touchpoints [O15] Framework: Expand partnerships with external parties [F1] | Lobby [F2] | Encourage the broadband rollout [F3] | Comply with data protection laws [F4]
74
H. Brink et al.
Promoting open communication and creating transparency should not be a guideline for top management only but for every single employee. An enhanced exchange and more information about success or failure stories within the company are recommended. The use of communication managers can be a helpful step. It is vital to intensify involving and motivating employees. It is the involvement of the workforce to partake in decisionmaking processes, e.g., by allowing them to provide feedback. When employees are given the space to act, a new mindset emerges. Being open-minded to changes is a basis for overcoming barriers to DT. It is connected to being open to continuous innovation. Such a mindset calls to engage staff to realize their ideas and projects. Participants recommend motivating employees to improve processes, which make their work easier. Allowing digital projects to be carried out without reservation, promotes motivation. “Doing and not just talking about it” [Participant] should be the motto. Starting small, for example through pilot or research projects, build trust and awareness in the DT process. To allow space for own ideas and projects, it is essential to create capacity among employees and to have suitable skill sets within the company. To identify which competences are lacking, participants recommend conducting a competence gap analysis through knowledge tests and documentation in digital personnel files. By knowing central competence gaps, the targeted development of necessary skills and knowledge can be started. One way is to offer or intensify demand-oriented employee training. “By providing the necessary training, the advantages of DT can be brought to the staff” [Participant]. Setting up an education portal and coaching systems enables efficient and demand-oriented training. Another way is to use external expertise. Involvement of external organizations with expertise and best practices is recommended if internal training does not pay off. Furthermore, participants recommend recruiting or providing suitable staff to overcome the skills gap. Specialized professionals with an educational background in the field of IT are required. Here, participants emphasize that companies should focus on rejuvenating the workforce. “A new generation of young people should be recruited, and existing employees should be given mentors” [Participant]. Participants mentioned multiple recommendations, which we classified into the technology subsystem. Extending or modernizing IT-Systems is imperative for fostering DT. On a rolling basis, companies should invest in new hardware to build and keep the critical IT infrastructure up to date. This includes expanding data storage capacities as well as customized software applications. Tracking technological trends supports them in being informed about innovations in the field of IT. Harmonizing IT infrastructure is according to the participants another recommendation. Consistent implementation of the IT architecture and software systems that are unified across departments are required to avoid isolated solutions. Furthermore, collect and analyze data provides the basis for targeted decision-making. “It must be possible to store and backup large amounts of data” [Participant] and to have it available at all levels, e.g., data to analyze user feedback. In addition, data integrity is required which means setting clear storing and archiving rules. When dealing with data, it is vital to ensure data security. There should be effective database protections in place. “Vulnerability tests should be carried out regularly, durability should be measured, and open areas should be determined, and necessary precautions should be taken” [Participant]. To improve the user-friendliness of software
Overcoming Barriers to Digital Transformation
75
and hardware, designing simple and intuitive systems is recommended. An easy and simple graphical user interface for software applications together with comprehensible handbooks support user-friendliness. The next element of the socio-technical system refers to the organization subsystem. It contains numerous recommendations related to the handling of resources in the company. Releasing or increasing a separate budget for DT is seen as necessary by many participants. “The company should accept to invest” [Participant]. Budgets need to be planned and created or increased to create more scope for digital innovations. “A larger share of the overall budget must go to digitalization” [Participant]. Thus, participants see prioritizing investments in DT as necessary. Critical consideration should be given to which investments should be made by conducting (long-term) cost-benefit analysis. Participants recommended analyzing DT efforts in detail regarding operational and strategic goals. However, “investments should also be made without expecting immediate profit maximization” [Participant]. Rather the “long-term effect needs to be analyzed” [Participant]. Taking advantage of financial support from the state can increase financial flexibility. Companies should therefore monitor grant programs. Further recommendations to overcome barriers can be assigned to the structure and processes of a company. Accordingly, participants recommended streamlining organizational processes and reducing complexity. This contains optimizing and re-engineering processes. Higher process efficiency can free resources for DT. However, such an approach needs to be implemented in form of continuous improvement in the long term. Lean principles such as the 5S method were also mentioned in this context. In addition to the process view, statements also referred to flattening and simplifying organizational structures. Many participants recommended the dismantling of hierarchical levels, the restructuring of divisions, and new linkages between departments. Furthermore, an increase in scope for decision-making on lower levels is named. Companies should “give more responsibility to each individual” [Participant]. Like this, decisionmaking paths can be shortened and decentralized in independent divisions, departments, or teams. Implementing IT Support can help these subordinate levels. However, as DT encompasses the entire company, centrally coordinating DT efforts is mandatory. Innovation departments can support line departments, centralize communication, and set clear shared goals. Central coordination should also focus on ensuring that the measures of the digital strategy are carried out. Thus, defining clear DT responsibilities in the company and its departments is necessary. At the same time, silo thinking in the departments must be diminished and an exchange encouraged by promoting cross-functional collaboration. In the context of DT, this is particularly important regarding IT staff and line employees. A “stronger involvement of the business departments in the solution design of technical innovations” [Participant] is desired. This also allows “employees to learn from employees” [Participant]. The work in the team should be supported by implementing agile project management and design methods. A few statements issue providing improved working conditions to overcome some barriers, for example, the possibility of working from home was mentioned. Participants also recommend moving customers to the center of attention in the development of solutions. The customer perspective must be considered when developing the
76
H. Brink et al.
digital strategy and “customer needs should be at the center of all new customer solutions” [Participant]. Companies should “conduct market research and produce products compatible with the market” [Participant]. In addition, customers must be included in the solution development process. Especially, when they are less willing to go digital. Therefore, simplifying and expanding customer touchpoints is essential for overcoming DT barriers. Touchpoints are online stores, call centers, and social media channels which are “advertising activities that will support digital sales channels can be focused” [Participant]. Here, customers are also accessing the technological subsystem. Thus, companies need to “create simple technical procedures so that older customers can be supplied without the need for technical support” [Participant]. As companies are framed by “political regulations, functional context preconditions, networks, [and] value chains” [41], participants pointed out several recommendations to address these factors which we group into the framework subsystem. Several statements referred to expanding partnerships with external parties. These partnerships could be shaped in different ways, like getting consultancy, outsourcing processes, or even long-term cooperation by vertical integration of the supply chain. Companies can “align themselves with other digital players or lead by example to create market pressure” [Participant]. Lobbying is also mentioned by participants in this context. Companies should “work with legal & lobbying to change the rules of the market to digitize it” [Participant] as well as “improve collaboration and coordination on what and where infrastructure is needed” [Participant] such as encouraging the broadband rollout. Companies need access to fast and stable connection technology. Furthermore, participants recommend complying with data protection laws. “Always make sure that data protection is respected and submitted with the customer’s consent” [Participant]. It is crucial to eliminate non-compliant software applications and to consider and evaluate new ones. External consultancy about laws serves as support here. Combining the results of the current study with the findings of the pre-study allows us to obtain a DM (see Table 5). The barriers are plotted on the x-axis and the recommendations on the y-axis. Depending on the direction of reading, the matrix shows for which barrier which recommendations are suggested by the participants (left to right) or which barriers could be addressed with the help of a specific recommendation (top to down). In addition, the DM shows the relative frequency of mentions of the recommendations for a given barrier. The relative frequency is divided into quartiles (QX): 0 < Q1 < 25%, 25% ≥ Q2 < 50%, 50% ≥ Q3 < 75%, and Q4 > 75%. For example, to overcome barrier MS1, less than 25% but greater than 0% of the statements referring to the barrier MS1 recommended action H4. A blank cell indicates no association between the barrier and the recommended action. Some statements of the questionnaire participants were explicitly directed at other stakeholder groups, such as governments. Governments should promote broadband rollout, create incentives, and provide subsidies. Legislation is also expected to provide clarity and room for innovation. In the DM, these recommendations were not illustrated, as the DM captures the business perspective only.
Barriers
MS1 MS2 MS3 MS4 MS5 TB1 TB2 TB3 TB4 OM1 OM2 OM3 OM4 CC1 CC2 CC3 CC4 CC5 SM1 SM2 SM3 SM4 SM5 RS1 RS2 RS3 MR1 MR2 MR3
H8
H9
H6
H7
H5
H4
Q2:
(m) NOT exists((n)-[r]->(m)) r.condition="..." p=(n)-[*..]->(m) NOT exists((n)-[*..]->(m))
After the anti-pattern has been traversed, the MATCH-statements are sorted to ensure that nodes are matched before the edges they are involved in. Additional WHERE-statements are added for ensuring placeholder equality which cannot be done during edge traversal because placeholder activities may not immediately follow each other. MATCH and WHERE-statements are concatenated using a logical AND for WHERE-statements, and all matched paths variables are RETURNed. Again, we refer to Sect. 6 for exemplary Cypher queries.
6
Demonstration and Discussion
We show the technical feasibility of our anti-pattern detection approach with a publicly available demonstration2 . We prototypically implemented the translation of anti-patterns to Neo4j ’s Cypher queries and applied it in the example application domain of energy distribution network planning. Many examples from the demonstration have already been utilized to visualize concepts explained in the paper, e.g., Figs. 2, 3 and 6. Interested readers may consult the implementation for additional details such as the resulting Cypher queries. Based on the demonstration and the explanations throughout the paper, we conclude that our approach addresses the requirements presented in Sect. 4 as follows: The detection requirements D1–D4 are primarily addressed by the antipattern elements shown in Fig. 5. In particular, D1 – (Non-)Consecutiveness is addressed with elements (e) to (i), D2 – Conditionality with elements (b) and (g), D3 – Missing Elements with elements (f ) and (i), and D4 – Generalization with element (d). A sufficient expressiveness of these elements in anti-pattern construction was confirmed throughout the demonstration using our prototypical implementation based on Neo4j. However, at least to some extent, these requirements were derived from our experience in a particular application domain and additional detection functionality may be needed in other domains. 2
https://github.com/krchf/process-graph-antipattern-detection.
240
J. Kirchhoff and G. Engels
The integration requirements I1–I4 are primarily addressed by the solution architecture discussed in Sect. 5.1. Extensibility required as part of I1 – Adaptability is provided by the anti-pattern repository filled by domain experts using the anti-pattern definition application (which also addresses I2 – Expert Definition by utilizing the graphical anti-pattern notation of Sect. 5.2). Preferences of PD-DSS engineers are considered via the anti-pattern selection application. Furthermore, the architecture can be instantiated in arbitrary application domains. For I3 – Traceability, paths matching an anti-pattern can be translated to parts of the original process model. I4 – Continuous Feedback is primarily addressed by the repeated, automatic matching of anti-patterns. In our prototypical implementation, the uncached queries representing anti-patterns seldomly exceeded 15ms using Neo4j -Docker on a 2018 laptop. However, we found anti-patterns including a missing flow between activities to take significantly longer, potentially exceeding 100ms. Nevertheless, all subsequent queries usually completed in less than 3ms, most likely due to caching. We believe the utilization of caching is reasonable as process model changes do not require the re-generation of the whole graph but only updates for affected elements. Furthermore, queries could be optimized by combining node and edge matches as discussed in the prototypical implementation. While we can provide measurements for I4 – Continuous Feedback, we acknowledge that other requirements call for additional studies, e.g., with domain experts to evaluate I2 – Expert Definition or case studies in other application domains to evaluate requirement I1 – Adaptability.
7
Summary and Future Work
We presented an approach for the detection of functional and behavioral flaws in process models describing a process-driven decision support system as composition of software-based decision support services. Our approach is based on the visual definition of flaws as process anti-patterns which can be automatically detected in the original process model via graph matching. We furthermore presented an architecture to integrate our approach into a digital ecosystem for the collaborative creation of PD-DSS. The technical feasibility of the approach was demonstrated in the context of energy distribution network planning. In addition to the already discussed extensions, future work could adapt the approach to support automatic anti-pattern fixes based on graph transformations (e.g., to automatically remove redundant activities), exceptions to anti-patterns under certain conditions, or full BPMN-Q compatibility.
References 1. Awad, A.: BPMN-Q: a language to query business processes. In: Enterprise Modelling and Information Systems Architectures - Concepts and Applications, pp. 115–128. Gesellschaft f¨ ur Informatik e. V. (2007)
Anti-pattern Detection in Process-Driven Decision Support Systems
241
2. Awad, A., Decker, G., Lohmann, N.: Diagnosing and repairing data anomalies in process models. In: Rinderle-Ma, S., Sadiq, S., Leymann, F. (eds.) BPM 2009. LNBIP, vol. 43, pp. 5–16. Springer, Heidelberg (2010). https://doi.org/10.1007/ 978-3-642-12186-9 2 3. Becker, J., Bergener, P., R¨ ackers, M., Weiß, B., Winkelmann, A.: Pattern-based semi-automatic analysis of weaknesses in semantic business process models in the banking sector. In: ECIS 2010 Proceedings (2010) 4. Becker, J., Bergener, P., Breuker, D., Raeckers, M.: An empirical assessment of the usefulness of weakness patterns in business process redesign. In: ECIS 2012 Proceedings (2012) 5. Becker, J., Weiß, B., Winkelmann, A.: Automatic identification of structural process weaknesses - experiences with semantic business process modeling in the financial sector. In: Wirtschaftsinformatik Proceedings 2011, pp. 787–807 (2011) 6. Bennett, N., Lemoine, G.J.: What a difference a word makes: understanding threats to performance in a VUCA world. Bus. Horiz. 57(3), 311–317 (2014) 7. Bergener, P., Delfmann, P., Weiss, B., Winkelmann, A.: Detecting potential weaknesses in business processes. Bus. Process. Manag. J. 21(1), 25–54 (2015) 8. Delfmann, P., Steinhorst, M., Dietrich, H.A., Becker, J.: The generic model query language GMQL - conceptual specification, implementation, and runtime evaluation. Inf. Syst. 47, 129–177 (2015) 9. D¨ ohring, M., Heublein, S.: Anomalies in rule-adapted workflows - a taxonomy and solutions for vBPMN. In: 2012 16th European Conference on Software Maintenance and Reengineering, pp. 117–126 (2012) 10. Eleftheriou, I., Embury, S.M., Brass, A.: Data journey modelling: predicting risk for IT developments. In: Horkoff, J., Jeusfeld, M.A., Persson, A. (eds.) PoEM 2016. LNBIP, vol. 267, pp. 72–86. Springer, Cham (2016). https://doi.org/10.1007/9783-319-48393-1 6 11. F¨ orster, A., Engels, G., Schattkowsky, T., Van Der Straeten, R.: Verification of business process quality constraints based on visual process patterns. In: First Joint IEEE/IFIP Symposium on Theoretical Aspects of Software Engineering (TASE 2007), pp. 197–208 (2007) 12. Held, M., Blochinger, W.: Structured collaborative workflow design. Futur. Gener. Comput. Syst. 25(6), 638–653 (2009) 13. Kirchhoff, J., Burmeister, S.C., Weskamp, C., Engels, G.: Towards a decision support system for cross-sectoral energy distribution network planning. In: Energy Informatics and Electro Mobility ICT (2021) 14. Kirchhoff, J., Gottschalk, S., Engels, G.: Detecting data incompatibilities in process-driven decision support systems. In: Shishkov, B. (ed.) BMSD 2022. LNBIP, vol. 453, pp. 89–103. Springer, Heidelberg (2022). https://doi.org/10.1007/ 978-3-031-11510-3 6 15. Kirchhoff, J., Weskamp, C., Engels, G.: Decision support ecosystems: definition and platform architecture. In: Cabral Seixas Costa, A.P., Papathanasiou, J., Jayawickrama, U., Kamissoko, D. (eds.) ICDSST 2022. LNBIP, vol. 447, pp. 97–110. Springer, Heidelberg (2022). https://doi.org/10.1007/978-3-031-06530-9 8 16. Kirchhoff, J., Weskamp, C., Engels, G.: Requirements-based composition of tailored decision support systems. In: Bernhaupt, R., Ardito, C., Sauer, S. (eds.) Human-Centered Software Engineering, pp. 150–162. Springer, Cham (2022). https://doi.org/10.1007/978-3-031-14785-2 10 17. Koschmider, A., Laue, R., Fellmann, M.: Business process model anti-patterns: a bibliography and taxonomy of published work. In: Proceedings of the 27th European Conference on Information Systems (ECIS) (2019)
242
J. Kirchhoff and G. Engels
18. Kurniawan, T.A., Ghose, A.K., Lˆe, L.-S.: Resolving violations in inter-process relationships in business process ecosystems. In: Ghose, A., et al. (eds.) ICSOC 2012. LNCS, vol. 7759, pp. 332–343. Springer, Heidelberg (2013). https://doi.org/10. 1007/978-3-642-37804-1 34 19. Laue, R., Koop, W., Gruhn, V.: Indicators for open issues in business process models. In: Daneva, M., Pastor, O. (eds.) REFSQ 2016. LNCS, vol. 9619, pp. 102–116. Springer, Cham (2016). https://doi.org/10.1007/978-3-319-30282-9 7 20. Lohmann, N., Nyolt, M.: Artifact-centric modeling using BPMN. In: Pallis, G., et al. (eds.) ICSOC 2011. LNCS, vol. 7221, pp. 54–65. Springer, Heidelberg (2012). https://doi.org/10.1007/978-3-642-31875-7 7 21. Mack, O., Khare, A.: Perspectives on a VUCA world. In: Mack, O., Khare, A., Kr¨ amer, A., Burgartz, T. (eds.) Managing in a VUCA World, pp. 3–19. Springer, Cham (2016). https://doi.org/10.1007/978-3-319-16889-0 1 22. Morimoto, S.: A survey of formal verification for business process modeling. In: Bubak, M., van Albada, G.D., Dongarra, J., Sloot, P.M.A. (eds.) ICCS 2008. LNCS, vol. 5102, pp. 514–522. Springer, Heidelberg (2008). https://doi.org/10.1007/9783-540-69387-1 58 23. Mustafin, N., Kopylov, P., Ponomarev, A.: Knowledge-based automated service composition for decision support systems configuration. In: Silhavy, R., Silhavy, P., Prokopova, Z. (eds.) CoMeSySo 2021. LNNS, vol. 231, pp. 780–788. Springer, Cham (2021). https://doi.org/10.1007/978-3-030-90321-3 63 24. Object Management Group: Business process model and notation (2014). https:// www.omg.org/spec/BPMN/. Accessed 21 June 2022 25. Parnell, G.S., Bresnick, T.A., Tani, S.N., Johnson, E.R.: Handbook of Decision Analysis. Wiley, Hoboken (2013) 26. Ramadan, Q., Str¨ uber, D., Salnitri, M., Riediger, V., J¨ urjens, J.: Detecting conflicts between data-minimization and security requirements in business process models. In: Pierantonio, A., Trujillo, S. (eds.) ECMFA 2018. LNCS, vol. 10890, pp. 179–198. Springer, Cham (2018). https://doi.org/10.1007/978-3-319-92997-2 12 27. Recker, J.: Opportunities and constraints: the current struggle with BPMN. Bus. Process. Manag. J. 16(1), 181–201 (2010) 28. Sahay, A., Indamutsa, A., Di Ruscio, D., Pierantonio, A.: Supporting the understanding and comparison of low-code development platforms. In: 2020 46th Euromicro Conference on Software Engineering and Advanced Applications (SEAA), pp. 171–178 (2020) 29. Savi´c, D.A., Bicik, J., Morley, M.S.: A DSS generator for multiobjective optimisation of spreadsheet-based models. Environ. Model. Softw. 26(5), 551–561 (2011) 30. Schiffner, S., Rothsch¨ adl, T., Meyer, N.: Towards a subject-oriented evolutionary business information system. In: 18th International Enterprise Distributed Object Computing Conference Workshops and Demonstrations, pp. 381–388 (2014) 31. Schneid, K., Kuchen, H., Th¨ one, S., Di Bernardo, S.: Uncovering data-flow anomalies in BPMN-based process-driven applications. In: Proceedings of the 36th Annual ACM Symposium on Applied Computing, SAC 2021, pp. 1504–1512. Association for Computing Machinery (2021) 32. Schneid, K., Stapper, L., Th¨ one, S., Kuchen, H.: Automated regression tests: a nocode approach for BPMN-based process-driven applications. In: 2021 IEEE 25th International Enterprise Distributed Object Computing Conference (EDOC), pp. 31–40 (2021) 33. Schneid, K., Usener, C.A., Th¨ one, S., Kuchen, H., Tophinke, C.: Static analysis of BPMN-based process-driven applications. In: Proceedings of the 34th
Anti-pattern Detection in Process-Driven Decision Support Systems
243
ACM/SIGAPP Symposium on Applied Computing, SAC 2019, pp. 66–74. Association for Computing Machinery (2019) 34. Stiehl, V.: Definition of process-driven applications. In: Stiehl, V. (ed.) ProcessDriven Applications with BPMN, pp. 13–41. Springer, Cham (2014). https://doi. org/10.1007/978-3-319-07218-0 2 35. Sun, S.X., Zhao, J.L., Nunamaker, J.F., Sheng, O.R.L.: Formulating the data-flow perspective for business process management. Inf. Syst. Res. 17(4), 374–391 (2006)
Democratizing Software Development: A Systematic Multivocal Literature Review and Research Agenda on Citizen Development Björn Binzer1(B)
and Till J. Winkler1,2
1 Chair of Information Management, University of Hagen, Hagen, Germany
{bjoern.binzer,till.winkler}@fernuni-hagen.de 2 Copenhagen Business School, Department of Digitalization, Frederiksberg, Denmark
Abstract. While the ongoing digital transformation is boosting the demand for digital solutions and digital skills, organizations worldwide experience a shortage of IT professionals and particularly software developers. At the same time, the increasing prevalence of low-code development platforms (LCDP) allows organizations to introduce citizen development initiatives to promote and accelerate their digital transformations. Citizen development represents a novel software engineering paradigm which enables and supports the development of software by non-IT professionals, consequently referred to as ‘citizen developers’. While there is a vivid discourse on citizen development in the practice community, research on this phenomenon is still scarce. We conducted a systematic multivocal literature review including research and practice publications, and identified six key themes: 1) definition and characteristics of citizen development, 2) enablers and expected benefits of citizen development, 3) challenges of and criticism towards citizen development, 4) citizen development strategy and implementation, 5) citizen development governance, and 6) citizen developers’ profiles and skills. Moreover, we propose a research agenda for future work on citizen development. Our research contribution is to synthesize the existing knowledge on citizen development and to point out future avenues to propel research on this emerging and contemporary phenomenon. Keywords: Citizen development · Citizen developer · Technology democratization · Low-code development platforms · Multivocal literature review
1 Introduction The digital transformation is boosting the demand for digital solutions and digital talent [1, 2]. While an organization’s workforce is considered a key factor in succeeding with digital transformation initiatives [3, 4], most firms struggle to adequately fill their vacancies in IT jobs. For instance, the German industry association Bitkom reports that roughly 96,000 IT positions were vacant in Germany in 2021, which represents an increase of around 123% compared to 2015, and where software developers and architects are in biggest demand [5]. This IT talent gap is widening globally and is expected © The Author(s), under exclusive license to Springer Nature Switzerland AG 2022 N. Carroll et al. (Eds.): ICSOB 2022, LNBIP 463, pp. 244–259, 2022. https://doi.org/10.1007/978-3-031-20706-8_17
Democratizing Software Development
245
to intensify in near future [e.g., 6, 7]. In effect, a growing backlog is arising on central IT units’ sides [1]. Many IT units are unable to meet the demand resulting in delays, longer waiting times and frustrated business unit stakeholders [8–10]. This lack of IT responsiveness has been found as one of the major reasons for the preference of business units to act autonomously and the occurrence of the phenomenon of ‘shadow IT’ [11] and its associated risks [12]. To overcome the dilemma between the IT talent shortage and increasing demands on IT units, the concept of citizen development has gained increasing attention in practice. The term has (presumably) been coined by market research firm Gartner [13] and refers to the empowerment of employees in non-IT functions (citizen developers) to create own software applications based on IT-tools that are provided, recommended, or at least tolerated by IT units [14]. Of central relevance to the concept are low-code development platforms1 (LCDPs) such as Microsoft PowerApps, OutSystems, or Mendix [15]. LCDPs represent cloud-based environments that use advanced graphical user interfaces, visual representations, drag-and-drop facilities, and reusable components to enable a simplified and rapid process for developing lightweight software solutions [15]. The high level of abstraction of LCDPs leads to enhanced ease of use allowing employees with minimal or even without any programming skills and knowledge to create their own software applications [16, 17]. According to industry forecasts, 70% of all new software applications in organizations will be based on LCDP tools by 2025 [18]. Even more, LCDPs are expected to enable the large-scale development of over 500 million new digital solutions between 2020 and 2025, which is equivalent to the total amount of software applications developed in the last 40 years [19]. Indeed, companies such as Shell [20] or H&M [21] already jumped on the citizen development bandwagon. Shell, for instance, launched its “do it yourself” program to foster a cultural shift towards the democratization of digital skills [20]. Within one year, the program resulted in more than 1,000 citizen developers and more than 75 citizen-developed applications [20]. In addition, further studies indicate that empowering citizen developers leads to higher firm innovation [22]. While there is a vivid discourse on citizen development in the practice community, only few research articles deal with this novel phenomenon [1, 23]. The recent literature review on LCDPs by Prinz et al. [24] further supports this by highlighting that the existing literature focuses mainly on technological characteristics of LCDPs and thus largely neglects aspects such as behavior, communication, or governance of LCDP use. The authors propose a closer investigation of citizen development to obtain a social and technical perspective on this emerging phenomenon. While some recent academic papers raise the awareness for citizen development [1, 10, 25], an overview of this emerging stream of research is yet missing. Given that research on citizen development is currently in its infancy, we strive to establish a first foundation by posing the following research questions: RQ1: What are themes in current publications on citizen development? RQ2: What are potential future avenues for research on citizen development? 1 In line with Di Ruscio et al. [15], we consider LCDPs and so-called no-code development
platforms interchangeably and refer only to the term LCDP in this study.
246
B. Binzer and T. J. Winkler
Given that research on citizen development is still emerging, we deliberately refrained from incorporating a theoretical background section and approached our review as open as possible. The next section describes our literature review research methodology. Section 3 presents our results in the form of six themes related to citizen development. In Sect. 4, we discuss our findings and propose a research agenda. After discussing the limitations of our research in Sect. 5, Sect. 6 concludes our study.
2 Review Method Identifying, reviewing and evaluating prior literature is a crucial task in research and ‘an essential feature of any academic project’ [26]. A literature review furthermore constitutes a key contribution for advancing the knowledge in a particular field of research as it represents an indispensable source of information for researchers and practitioners [27]. Consequently, literature review outcomes may serve as theoretical foundation for future research, and also help to identify research problems that require more research attention [26–28]. Given the novelty of the citizen development phenomenon and the fact that the concept is discussed mainly in practice, we saw the need to recognize grey literature in addition to academic literature. Analyzing grey literature bears great potential value for understanding a research phenomenon [29, 30], especially for an emerging topic [30]. Some scholars even believe that the inclusion of grey literature has significantly improved their findings [30]. To consider both, academic and grey literature, we conducted a structured multivocal literature review (MLR). MLRs represent an established research methodology in disciplines such as education or health sciences, and they recently started to become more popular in software engineering [30]. Conducting an MLR is regarded as suitable method that provides a more complete picture by emphasizing state-of-the-art and state-of-the-practice in a given field, thus closing the gap between academia and practice [30]. Since our research objective is to shed light on the current understanding of citizen development, this study can be categorized as a descriptive review that strives to reveal interpretable patterns and trends [27]. Our review approach attempts to be as comprehensive and complete as possible in order to satisfy the levels of methodological rigor and reproducibility that is regularly demanded for literature reviews [31]. Figure 1 illustrates our two-fold approach for collecting relevant literature. In the first phase, we reviewed five scientific databases. In the second phase, we systematically searched the web using Google. We report both phases separately in the following. In total, our data set encompasses 79 articles2 consisting of 9 conference proceedings, 3 working papers (i.e., research-in-progress or workshop papers), 8 research-related publications (e.g., viewpoint, opinion), 14 white papers, 18 news or magazine articles, 23 blog posts, and 4 practice-driven research reports. Regarding the publication period, the articles were published between 2014 and 2022 with a first rising trend of 10 publications in 2020 (7 of practice origin and 3 of academic origin), and followed by a maximum of 31 publications in 2021 (21 of practice origin and 10 of academic origin).
2 [32] provide an extended and more detailed overview of these 79 articles.
Democratizing Software Development
247
Fig. 1. Data collection process.
2.1 Data Collection Strategy for Academic Research Literature We followed the instructions of Webster & Watson [26] for collecting relevant academic literature. We conducted a structured literature search in five high-quality information systems, computer science, and business-related research databases (i.e., AIS Electronic Library (AISeL), EBSCOhost Web, ACM Digital Library, IEEEXplore, and Scopus). Our search was performed in May 2022 by querying the search string “citizen develop*”3 in the aforementioned research databases. We employed a full-text search and limited our search only to articles that were written either in English or German (the first language of the authors). No other filters have been applied in order to identify all relevant publications. This strategy yielded in 631 hits. We removed 41 duplicates and 4 publications not written in English or German. To assess the relevance of each publication, we thoroughly reviewed the title, abstract, and keywords to check if the publication deals with the phenomenon of citizen development in accordance to our understanding and research background. In unclear cases, we additionally assessed the full text. As a result, we removed 443 articles due to different research foci and contexts (e.g., citizen development in the context of education, public health, or politics; such as citizens develop opinions or voices). Furthermore, reviewing the full text revealed that 53 publications referred to ‘citizen developer’ only as term without further specification or explanation (i.e., as buzzword). Similarly, other articles used the term solely for introducing the concept of LCDP. As these publications did not offer valuable insights for our endeavor, we decided to exclude them. In the next step, we temporarily omitted 77 non-peer-reviewed articles from our data set. However, as some of these articles could have been potentially promising for our research, we decided to reconsider them in our data collection of grey 3 In ACM Digital Library we used a non-wildcard search string: [All: “citizen development”]
OR [All: “citizen developer”] OR [All: “citizen developers”].
248
B. Binzer and T. J. Winkler
literature (see Sect. 2.2). Table 1 summarizes our inclusion and exclusion criteria for the surveyed academic research literature. Table 1. Inclusion and exclusion criteria for surveyed academic literature. Criteria for inclusion
Criteria for exclusion
• Publication is peer-reviewed • Publication focuses on citizen development as research phenomenon, or • Publication focuses primarily on related concept (e.g., LCDP), but extensively examines and refers to key aspects and issues of citizen development
• Publication is duplicate • Publication is written not in English or German • Publication utilizes terms such as ‘citizen developer’ or ‘citizen development’ without specification or further explanation (i.e., catchword or buzzword usage) • Publication refers to citizen development solely as introduction to LCDP
Our strategy for searching literature from academic databases resulted in an initial set of 13 relevant articles. Consequently, we performed a forward and backward search for each of them. Searching forward was executed by browsing Google Scholar. To be considered relevant, articles had to equally fulfill all inclusion criteria (see Table 1). This step was iteratively done for each article added. In sum, this process allowed us to add 6 further studies to our data set, thus it totals up to 19 scientific publications. 2.2 Data Collection Strategy for Grey Literature To identify and collect relevant grey literature, we conducted a systematic search in Google by querying the search strings individually and in quotation marks. Table 2 provides an overview of the applied search strings, -hits, and -stopping criteria. Table 2. Overview of grey literature search strings, search hits, and search stopping criteria. Search string
Source
Search hits
Search stop criteria
“Citizen development”
Google
~307,000
Theoretical saturation & effort bounded (first 15 pages)
“Citizen developer”
Google
~196,000
“Citizen developers”
Google
~148,000
The first 15 pages of hits have been reviewed in order to explore and check whether the source was appropriate and the concept of citizen development was sufficiently addressed. A threshold of 15 pages was chosen because of two reasons. First, at around the 15th page, a substantial portion of the listed hits did not provide any novel insight to our research thus assuming a certain degree of theoretical saturation [30, 33]. Second, given the large number of search hits, we had to limit our search to a specific boundary.
Democratizing Software Development
249
Adding to this, our limit of 15 pages has been rather extensive in comparison to similar MLR studies [e.g., [33]]. At the beginning, we initially pre-screened all titles of the search hits for relevance and only included those whose titles thematically matched our research background. This resulted in 617 potentially relevant sources. In addition, we considered 77 grey literature articles which have been found during the academic database search (see Sect. 2.1), thus it sums up to 694 sources. Following the initial collection, we applied specified quality criteria for the inclusion of grey literature. Here, we adjusted the guidelines by Garousi et al. [30] according to our research and subsequently established our quality criteria checklist as presented in Table 3. We used a 3-point scale (yes = 1, partly = 0.5, and no = 0) for evaluating each quality criteria leading in the assignment of a specific score per grey literature source. Table 3. Quality criteria for grey literature. Category
Criteria
Authority of the producer
• The publishing organization is reputable, or (at least) one author is associated with a reputable organization • The author has published other work in the field • The author has expertise in the area (e.g., job title)
Methodology
• • • • •
Objectivity ofthe publication • • • •
The work has a clearly stated aim The work has a clearly stated methodology Limits are clearly stated The work covers a specific question The work refers to a particular population or case The statements are objective, clear, and plausible The work seems to be balanced (i.e., neutral stance) The work seems to be independent and credible There are no vested interests
Positioning & Impact
• The work is supported by authoritative, documented references (i.e., citations and backlinks that substantiate the arguments) • Key related sources have been linked and/or discussed • The work provides state-of-the-practice advice or insight (e.g., best practices, challenges, or implications)
Date
• The work has a clearly stated date
Novelty
• The work enriches or adds something unique • The work strengthens or refutes a current position
Outlet type
• 1st tier (score = 1): High outlet control & credibility: magazines, white paper • 2nd tier (score = 0.5): Moderate outlet control & credibility: reports, news, presentations • 3rd tier (score = 0): Low outlet control & credibility: blogs, posts, emails, tweets
250
B. Binzer and T. J. Winkler
Overall, sources could achieve a maximum score of 19. In line with previous studies, sources had to satisfy a threshold value of 10 to be included [30]. In accordance with the academic search, we only considered sources written in English or German. Moreover, purely promotional, inaccessible, and off-topic sources, as well as podcasts and videos were filtered out and omitted from our research. Same applied to duplicates and irrelevant sources (e.g., webinar registration forms). As a result, we excluded 211 sources. Applying the quality criteria to our set of 483 sources resulted in 60 sources that reached the threshold value of 10. Consequently, we merged the scientific and grey literature sources into one sample as the literature under review. Thus, our total sample consists of 79 articles.
3 Results and Findings We analyzed our data set according to the recommendations of Webster and Watson [26] and vom Brocke et al. [31]. We initially captured all 79 articles of our sample into a table.4 For literature analysis and synthesis, we pursued a two-step approach. In a first step, the first author carefully read and analyzed each article by identifying and systematically extracting the topics and underlying rationales that surfaced in the respective article. Hence, our process of topic extraction is interpretive in nature. To obtain a comprehensive perspective on the citizen development phenomenon, the first author subsequently searched for interrelationships among these topics in a second step. Identical and interrelated topics were grouped together, leading to the formulation of six key themes. In cases of unclear group assignments, doubts were clarified in discussion with the second author. Figure 2 illustrates the six key themes that emerged from our analysis. In the following, we present our findings by delineating and outlining each theme.
Fig. 2. Conceptual model of current literature themes on citizen development.
4 We used MS Excel for literature analysis and the follow-up theme synthesis procedure.
Democratizing Software Development
251
3.1 Theme 1: Definition and Characteristics of Citizen Development The vast majority of articles describe the concept of citizen development as novel software engineering paradigm that strives to empower non-IT employees to design, build, and deploy their own software applications without the direct involvement of the centralized IT units. Hence, a repeatedly used key term across the literature is technology democratization [e.g., 20, 34, 35] referring to the decentralization of IT competencies to enable collective and firm-wide digital innovation. These empowered non-IT employees are then called citizen developers. Of decisive importance is that citizen developers leverage only IT-authorized tools, which largely prevents the creation of shadow IT [e.g., 36, 37]. Regularly quoted key resources in the field have been published by market research firms Gartner and Forrester Research. Even more, Gartner is credited with coining the phrase in 2009 [13, 38] and is thus inextricably linked to the concept. Given their background, citizen developers are assumed to be mainly equipped for creating applications of low complexity [9, 34] that can range from simple solutions for personal use to organization-wide ones for consumption by others [1, 39]. According to Gartner, a citizen developer is neither a title nor a targeted role, but represents a person that is legally employed by an organization [14]. However, studies also regularly refer to citizen developers in non-organizational contexts [40] and introduce terms such as ‘citizen integrator’. This highlights that the term is not always used consistently. Apart from software applications development, literature also refers to an increased workflow automation that can be achieved through citizen developers [e.g., 10, 23, 41]. In addition, it is noteworthy that almost all articles link the emergence of the citizen development phenomenon with the growing rise of advanced LCDP technologies and its propagated reduction of software development complexity. Thus, 44 articles in our data set explicitly emphasize that citizen developers have little to no coding knowledge. 3.2 Theme 2: Enablers and Expected Benefits of Citizen Development A second frequently addressed topic in the literature deals with the organizational enablers and the expected benefits of citizen development. Literature already identified an increase in the number of citizen developers [42] and indicates that firms of all sizes are interested in implementing citizen development strategies [10]. In this context, authors argue that several reasons cause its emergence. Most cited are the rising demands for digital solutions in the context of digital transformation, the increased need for faster adaptations to a fast-changing business environment, and the shortage of skilled IT resources resulting in bottlenecks and a widening gap between IT demand and supply [e.g., 1, 10, 36]. On a technology level, modern LCDPs with their easy-to-use graphical interface capabilities and pre-built components are also recognized as a crucial enabler and facilitator of the citizen development phenomenon [e.g., 42–44]. Considering the expected benefits, most organizations strive to establish an environment where citizen developers can realize a multitude of advantages. The first and foremost stated promise is that citizen developers are empowered to cut down routine work and tackle frequent pain points of daily work [35, 38]. In this context, it is believed that citizen developers can achieve a faster and more efficient development process as requirements do not need to be fully aligned and translated between business and IT
252
B. Binzer and T. J. Winkler
[8]. Hence, organizations can increase their overall capacity to develop digital solutions. Instead of waiting for available IT department resources, several studies report that citizen developers can build customized solutions within weeks or days [e.g., 38, 45–47] leading to time and cost savings, more efficient business processes, and less frustrated business stakeholders [e.g., 9, 38, 46]. Another frequently mentioned facet emphasizes the importance of collectivity as citizen development significantly broadens the number of people who can assist with their creativity and competence in an organization’s digital transformation [44, 45, 48]. Leveraging the ideas that are already existing within organizations offers the potential to unlock a new source of intrapreneurial business innovation [48]. Moreover, citizen development can potentially benefit central IT teams. If more citizen developers take on active roles in IT-related areas, core IT resources could be freed up, allowing IT professionals to focus on more complex and strategically important projects [8, 49]. 3.3 Theme 3: Challenges and Criticism Towards Citizen Development While the literature predominantly focuses on the potential benefits of citizen development, we also identified a small set of works that discuss challenges and express critique towards the concept. Much of the challenges address the limitations of contemporary LCDPs or question the abilities of citizen developers. Interestingly, and contrary to the statements of most LCDP vendors, firms perceive application development on LCDPs still as complex task that requires specialized skills [1]. Other studies point out to integration limitations [39] and quality concerns caused by improper testing [23, 50]. Similarly, articles refer to risks due to security concerns [23, 42] and citizen developers’ unawareness for governance practices or other accepted standards [1, 36, 51]. Apart from the challenges above, one article explicitly expresses critique [52]. The author is skeptical and argues that concepts such as 4th generation programming language technologies have made similar promises to LCDPs and citizen development, but have largely failed to realize these promises [52]. 3.4 Theme 4: Citizen Development Strategy and Implementation The fourth theme discusses strategic decision-making and how organizations can implement citizen development in practice. In this regard, Hoogsteen and Borgman [1] investigated factors that determine a firm’s decision to adopt citizen development. Active top management support, centralized IT governance, and external partner involvement have been found to positively affect citizen development adoption [1]. Organizations should proactively drive change management and inform their employees about the arising possibilities and how they can participate [53]. One major component of this is to foster a culture in which the workforce is encouraged to recognize and realize that digital innovation could happen on all levels of an organization [20]. To achieve this, organizations must provide the necessary tools and equip their citizen developers with the required skills and mindset. Some articles emphasize the importance of education and guidance when implementing citizen development and suggest establishing training programs [8, 53] and setting up structures such as a center of excellence or a community
Democratizing Software Development
253
of practice [35, 37]. To identify suitable citizen developers, the literature suggests holding hackathons or looking for jobs with problem-solving activities [54] such as business analysts [55]. More general, people, processes and technology are regularly highlighted as core elements of a citizen development program [9, 41]. However, studies also recognize that there is no one-size-fits-all approach and point out that the implementation can happen top down and bottom up [1]. Moreover, different implementation strategies arise from an organization’s individual context (e.g., it might be beneficial to introduce technology from vendors that are already contracted instead of building on so far unknown vendors) [1]. In addition, firms should introduce citizen development first within single departments and then scale to further [37]. With regards to processes, as citizen development promotes a collaborative and more rapid prototyping of innovative ideas, some authors link the concept to an agile mindset and agile methodologies [35, 45, 53], as well as to Scrum and DevOps [37, 56]. 3.5 Theme 5: Citizen Development Governance This theme particularly highlights a new way of collaboration between business and IT units. A large number of articles advocate for bringing citizen development programs under centralized IT governance structures in order to ensure security, compliance, data integrity, and efficiency [1]. Thus, due to the rise of empowered citizen developers, the IT department is given the new function of citizen development governance, which encompasses the provision of the LCDP infrastructure and defining guardrails for citizen developers [1, 37, 53]. However, as reported by Bevans [57], the degree of IT unit’s responsibility varies in practice-applied citizen development governance models. Authors also regularly emphasize that the IT department should seek to closely collaborate, support, and partner with citizen developers, instead of acting as a gatekeeper [e.g., 9, 37, 53, 58]. Collaboration efforts can thereby be achieved through interaction and knowledge exchange in established communities [9, 37] or the setup of cross-functional teams [44, 53]. Likewise, some articles endorse integrative models in which citizen developers create prototypes and professionals later take over finalization [44, 59], implying a shift of work from IT unit to business units [44]. Of importance is that citizen developers are aware of the IT-defined guidelines and standards. For such a citizen development strategy to work and be successfully implemented, firms must have tools and mechanisms in place to monitor and keep the control of citizen-created applications [36]. To avoid duplicate efforts, firms should also strive to establish enterprise-wide directories or app stores in which all employees can look for already available solutions and share their self-developed solutions with others [46]. 3.6 Theme 6: Citizen Developers’ Profiles and Skills The sixth and last identified theme in the literature deals with the profile and skills of the individual citizen developer. A number of articles address the question of what exactly constitutes a citizen developer in terms of personality and required skills [38, 46]. Citizen developers are typically characterized as non-IT employees who have no formal IT education, but possess great business expertise and in-depth knowledge of business processes [23, 55]. However, they are also regularly portrayed as tech-savvy
254
B. Binzer and T. J. Winkler
or tech-excited [13, 35, 53]. Other characteristics include curiosity, a desire for change, and a natural motivation for continuous learning and upskilling [13, 35, 53]. Due to their deep and first-hand business expertise, citizen developers are attributed with a thorough understanding of day-to-day business needs and existing operational inefficiencies. Unlike professional developers who often lack deep business insight, citizen developers are thus deemed the perfect candidates for developing custom digital solutions that solve operational pain points [8]. In this context, problem-solving skills are often considered a key competence of citizen developers [8, 41, 47]. Another aspect driving the rise of citizen developers are digital natives now entering business units. Having grown up with technology in their personal lives, the digital natives tend to feel more confident and comfortable using the technological toolset that organizations equip them with [38].
4 Discussion and Research Agenda Although the term ‘citizen development’ has been around for over a decade, it has just recently started to gain momentum in academia. In the last few years, the idea has received strong support among practitioners. Despite its attention, literature highlights that there is so far no uniform definition [1]. Some scholars view the concept merely as an extension of end-user development [1, 60]. Indeed, both concepts share similarities, but there are also important conceptual differences. While end-user development goes back to the 1970s and is often linked to single power users who create, modify, or extend specific software artifacts such as spreadsheets [61], citizen development builds on cloud-enabled and advanced LCDP tools that foster collaboration and allow the large-scale deployment of citizen-developed solutions across an organization [60]. Furthermore, while end-user development is often acknowledged a bottom-up approach [62], citizen development is considered more a top-down strategy often initiated by management [1]. Our multivocal literature review results suggest that there is a lot of traction and discussion on citizen development in practice. This opens up numerous research opportunities on multiple levels, as listed in Table 4. Starting with the individual level, scholars should explore the citizen developer role more deeply. So far, the literature portrays citizen developers with varying attributes and skills. Thus, scholars can examine whether there are different types of citizen developers and develop appropriate typologies. Second, research could strive to understand how citizen developers perceive and feel about their role. Having more insights might be important to ensure a lasting success and anticipate workforce resistance. Third, we propose to investigate the motivating factors of citizen developers to take on a new and time-consuming role alongside their regular work. On team level, practitioners sometimes refer to cross-functional teams as appropriate approach for implementing citizen development [44]. This raises several questions with regards to the integration, organization, collaboration, and management of work distribution. For example, it seems essential to understand how citizen developers can benefit teams and team performance. Similarly, it is largely unknown how citizen development practices diffuse within organizations. However, having a clear grasp on this is crucial for the adoption and acceptance of citizen development within and across teams.
Democratizing Software Development
255
Table 4. Research agenda for potential future research on citizen development. Level of analysis Exemplary research questions for future research avenues Individual
• Which types of citizen developers exist, and how can they be classified? • How do citizen developers perceive and feel about their role? • What motivates citizen developers, and how do they approach tasks?
Team
• How do citizen developers integrate themselves into cross-functional teams? • How do citizen development practices diffuse within and across teams? • How can teams and team performance benefit from citizen developers?
Organizational
• How do firms implement citizen development strategies? • How can citizen development training and upskilling be organized? • How should the ownership of support and maintenance for citizen-developed digital solutions be managed? • How can firms measure organization-wide citizen development success?
Ecosystem
• How do citizen development strategies differ across ecosystems? • What are market opportunities for third-party providers? • How does citizen development differ between private and public firms?
There are also research opportunities at the organizational level. While no standard implementation approach exists, the literature indicates that citizen development can be driven in two ways, top-down and bottom-up [1]. Future research may longitudinally accompany and observe firms on their citizen development journey to better understand the underlying dependencies and dynamics. This includes numerous aspects such as training, or exploring in which types of departments citizen developers primarily emerge. With so many individuals deploying self-developed digital solutions, also questions around the ownership of support and maintenance arise. Moreover, while many sources report that citizen development yields multiple benefits, research should strive to prove the business value of pursuing such a strategy by adequate measures [1]. Lastly, exploring citizen development on ecosystem levels seems to be a worthwhile undertaking. To date, it is unclear whether citizen development is applicable to all industry environments and sectors. For example, there might be fundamental differences in how public sector and private companies might implement and leverage citizen development. In a similar vein, citizen development might require established IT vendors and other third-party providers to rethink their solution portfolio in order for them to realize new market opportunities given that citizen developers will demand a capability to extend their solutions with little or no coding efforts. Our analysis reveals the need for such research as only few of the articles analyzed address these questions.
5 Limitations No work is without limitation. We performed an MLR using academic databases and the search engine Google, whose ranking algorithm is not transparent. Arguably, this limits the traceability of our results. Second, as the citizen development concept is driven by
256
B. Binzer and T. J. Winkler
practice, researchers may have addressed it under related terms such as ‘end-user development’. Hence, we may have missed potentially relevant works that do not explicitly use the term citizen development. A third limitation originates from our interpretational work and the derivation of our research agenda. Other researchers might identify different or additional themes and future research avenues. Finally, a further aspect of validity threat may occur from the data collection and data extraction as both processes were mostly conducted by the same one researcher. Those might be concerns for the reliability and reproducibility of our study results [63].
6 Conclusion ‘Software is eating the world’, as Marc Andreessen’s oft-quoted conjecture goes [64]. With the increasing launch of citizen development initiatives across all industries, it seems that this statement is truer than ever. However, it must be clear that citizen developers cannot replace professional software development [65], but rather extend and increase an firm’s overall software development capacity. With our MLR, we placed emphasis on the emerging phenomenon of citizen development and sought to manifest it in research by examining and synthesizing the existing knowledge of academia and practice. We contribute to research by outlining six citizen development key themes: 1) definition and characteristics of citizen development, 2) enablers and expected benefits of citizen development, 3) challenges of and criticism towards citizen development, 4) citizen development strategy and implementation, 5) citizen development governance, and 6) citizen developers’ profiles and skills. Moreover, we propose a research agenda which may serve as a point of orientation for future research on citizen development at different levels of analysis (individual-, team-, organizational-, and ecosystem-level).
References 1. Hoogsteen, D., Borgman, H.: Empower the workforce, empower the company? citizen development adoption. In: Proceedings of the 55th Hawaii International Conference on System Sciences, pp. 4717–4726 (2022). https://doi.org/10.24251/hicss.2022.575 2. Matt, C., Hess, T., Benlian, A., et al.: Options for formulating a digital transformation strategy. MIS Q. Executive 15(2), 123–139 (2016) 3. Eden, R., Jones, A., Casey, V., et al.: Digital transformation requires workforce transformation. MIS Q. Executive 18(1), 1–17 (2019) 4. Bughin, J., Hazan, E., Lund, S., et al.: Skill shift: automation and the future of the workforce. https://www.mckinsey.com/featured-insights/future-of-work/skill-shift-aut omation-and-the-future-of-the-workforce. Accessed 04 Aug 2022 5. Bitkom Research: IT-Fachkräftelücke wird größer: 96.000 offene Jobs. https://www.bitkom. org/Presse/Presseinformation/IT-Fachkraefteluecke-wird-groesser. Accessed 04 Aug 2022 6. Feijao, C., Flanagan, I., van Stolk, C., et al.: The global digital skills gap: current trends and future directions. https://www.rand.org/pubs/research_reports/RRA1533-1.html. Accessed 03 Aug 2022 7. Breaux, T., Moritz, J.: The 2021 software developer shortage is coming. Commun. ACM 64(7), 39–41 (2021). https://doi.org/10.1145/3440753 8. Carroll, N., Móráin, L.Ó., Garrett, D., et al.: The importance of citizen development for digital transformation. Cutter Bus. Technol. J. 34(3), 5–9 (2021)
Democratizing Software Development
257
9. Pegasystems: empowering citizen developers through Pega’s low-code factory approach. https://pega.com/de/building-your-low-code-factory. Accessed 04 Aug 2022 10. Lebens, M., Finnegan, R.J., Sorsen, S.C., et al.: Rise of the Citizen Developer. Muma Bus. Rev. 5(12), 101–111 (2021). https://doi.org/10.28945/4885 11. Kopper, A.: Perceptions of IT managers on shadow IT. In: Proceedings of the 23rd Americas Conference on Information Systems (AMCIS) (2017) 12. Klotz, S., Kopper, A., Westner, M., et al.: Causing factors, outcomes, and governance of Shadow IT and business-managed IT. IJISPM 7(1), 15–43 (2019). https://doi.org/10.12821/ ijispm070102 13. Bates, B.: Is the citizen developer the new face of agility?. https://www.toptal.com/projectmanagers/software-development/citizen-developer. Accessed 25 Jul 2022 14. Gartner: definition of citizen developer. https://www.gartner.com/en/information-technology/ glossary/citizen-developer. Accessed 05 Aug 2022 15. Di Ruscio, D., Kolovos, D., de Lara, J., Pierantonio, A., Tisi, M., Wimmer, M.: Low-code development and model-driven engineering: two sides of the same coin? Softw. Syst. Model. 21(2), 437–446 (2022). https://doi.org/10.1007/s10270-021-00970-2 16. Waszkowski, R.: Low-code platform for automating business processes in manufacturing. IFAC-PapersOnLine 52(10), 376–381 (2019). https://doi.org/10.1016/j.ifacol.2019.10.060 17. Sahay, A., Indamutsa, A., Di Ruscio, D., et al.: Supporting the understanding and comparison of low-code development platforms. In: Skavhaug, A. (ed.) 46th Euromicro Conference on Software Engineering and Advanced Application, pp. 171–178. IEEE, Piscataway, NJ (2020) 18. Wong, J., Iijima, K., Leow, A., et al.: Magic quadrant for enterprise low-code application platforms. https://www.gartner.com/doc/reprints?id=1-295WSI86&ct=220217&st=sb. Accessed 22 Jul 2022 19. Gens, F., Carvalho, L., Della Rosa, F., et al.: IDC FutureScape: worldwide IT industry 2020 predictions (2019) 20. Kappeyne, N.: “Do it yourself” software development: the power is in your hands. https:// www.shell.com/energy-and-innovation/digitalisation/news-room/do-it-yourself-softwaredevelopment-the-power-is-in-your-hand.html. Accessed 19 Jul 2022 21. Bhangar, S.: H&M Group enables citizen development at scale with Microsoft Power Platform. https://powerapps.microsoft.com/en-us/blog/hmgroup/. Accessed 19 Jul 2022 22. Srivastava, S., Trehan, K., Wagle, D., et al.: Developer velocity: how software excellence fuels business performance (2020) 23. Hintsch, J., Staegemann, D., Volk, M., et al.: Low-code development platform usage: towards bringing citizen development and enterprise it into harmony. In: Proceedings of Australasian Conference on Information Systems (ACIS) (2021) 24. Prinz, N., Rentrop, C., Huber, M.: Low-code development platforms – a literature review. In: Proceedings of the 27th Americas Conference on Information Systems (2021) 25. Carroll, N., McLafferty, B., Conboy, K., et al.: Normalising a digital transformation. In: Proceedings of the 42nd International Conference on Information Systems (2021) 26. Webster, J., Watson, R.T.: Analyzing the past to prepare for the future: writing a literature review. MIS Q. 26(2), xiii–xxiii (2002) 27. Paré, G., Trudel, M.-C., Jaana, M., et al.: Synthesizing information systems knowledge: a typology of literature reviews. Inf. Manage. 52(2), 183–199 (2015). https://doi.org/10.1016/ j.im.2014.08.008 28. vom Brocke, J., Simons, A., Riemer, K., et al.: Standing on the shoulders of giants: challenges and recommendations of literature search in is research. CAIS 37, 9 (2015). https://doi.org/ 10.17705/1cais.03709 29. Bowen, G.A.: Document analysis as a qualitative research method. Qual. Res. J. 9(2), 27–40 (2009). https://doi.org/10.3316/QRJ0902027
258
B. Binzer and T. J. Winkler
30. Garousi, V., Felderer, M., Mäntylä, M.V.: Guidelines for including grey literature and conducting multivocal literature reviews in software engineering. Inf. Softw. Technol. 106, 101–121 (2019). https://doi.org/10.1016/j.infsof.2018.09.006 31. vom Brocke, J., Simons, A., Niehaves, B., et al.: Reconstructing the giant: on the importance of rigour in documenting the literature search process. In: Proceedings of the 17th European Conference on Information Systems (ECIS) (2009) 32. Binzer, B., Winkler, T.: Extended reference overview - democratizing software development (2022). https://doi.org/10.6084/m9.figshare.21077272 33. Butijn, B.-J., Tamburri, D.A., van Heuvel, W.-J., den,: Blockchains: a systematic multivocal literature review. ACM Comput. Surv. 53(3), 1–37 (2021). https://doi.org/10.1145/3369052 34. Kolarsch, C., Mohn, C., Lászlop, Á., et al.: Do it yourself computing. https://www.dbsystel. de/resource/blob/6998390/23abdd2e9b6245f5cb45feb49376903c/Trendstudie-DIY-Comput ing-data.pdf. Accessed 03 Aug 2022 35. Steele, T.: Democratizing innovation: low-code/no-code platforms & the citizen developer. https://www.capco.com/intelligence/capco-intelligence/democratizing-innovation. Accessed 04 Aug 2022 36. KPMG: citizen developer enablement. https://advisory.kpmg.us/content/dam/advisory/en/ pdfs/2021/citizen-developer-low-code-enterprise-risk.pdf. Accessed 25 Jul 2022 37. Betty blocks: governing citizen development: a strategy guide for CIOs and IT departments. https://query.prod.cms.rt.microsoft.com/cms/api/am/binary/RE4GSjX. Accessed 04 Aug 2022 38. TrackVia: the next generation worker: the citizen developer, https://1894h511igtw1bde2p1h9 zw1-wpengine.netdna-ssl.com/wp-content/uploads/2017/11/TV_Citizen_Dev.pdf, Accessed 08 Aug 2022 39. Overeem, M., Jansen, S., Mathijssen, M.: API management maturity of low-code development platforms. In: Augusto, A., Gill, A., Nurcan, S., Reinhartz-Berger, I., Schmidt, R., Zdravkovic, J. (eds.) BPMDS/EMMSAD -2021. LNBIP, vol. 421, pp. 380–394. Springer, Cham (2021). https://doi.org/10.1007/978-3-030-79186-5_25 40. Muck, C., Voelz, A., Amlashi, D.M., et al.: Citizens as developers and consumers of smart city services: a drone tour guide case. In: The Web Conference (2022) 41. Diquez, E.: Citizen Developer Governance: Unlocking Automation at Scale, https://www. auxis.com/blog/citizen-developer-governance. Accessed 04 April 2022 42. Oltrogge, M., Derr, E., Stransky, C., et al.: The rise of the citizen developer: assessing the security impact of online app generators. In: 2018 IEEE Symposium on Security and Privacy (SP), pp. 634–647. IEEE (2018). https://doi.org/10.1109/SP.2018.00005 43. Vries, B., de & Stam, D.: Low-code and the road to Sustainable Software. Compact (2019) 44. Iho, S., Krejci, D., Missonier, S.: Supporting knowledge integration with low-code development platforms. In: Proceedings of the 29th European Conference on Information Systems (2021) 45. Jackson, D.H., Swanski, J.: Citizen developers, agile methodology and people change management for digital transformation. https://1898andco.burnsmcd.com/white-paper/citizen-develo pers-agile-methodology-people-change-management. Accessed 14 Jul 2022 46. McKendrick, J.: The rise of the empowered citizen developer. https://dbta.com/DBTA-Dow nloads/ResearchReports/THE-RISE-OF-THE-EMPOWERED-CITIZEN-DEVELOPER7575.pdf. Accessed 05 Aug 2022 47. QuickBase: The state of citizen development report. https://cdn2.hubspot.net/hubfs/172645/ eBook%20Introduction-to-Citizen-Development-Bringing-Shadow-IT-into-the-Light.pdf. Accessed 05 Aug 2022 48. Krejci, D., Iho, S., Missonier, S.: Innovating with employees: an exploratory study of idea development on low-code development platforms. In: Proceedings of the 29th European Conference on Information Systems (2021)
Democratizing Software Development
259
49. Deloitte United States: LCNC citizen development risks & governance. https://www2.del oitte.com/us/en/pages/operations/articles/citizen-development-innovation-governance.html. Accessed 04 Aug 2022 50. Khorram, F., Mottu, J.-M., Sunyé, G.: Challenges & opportunities in low-code testing. In: Proceedings of the 23rd ACM/IEEE International Conference on Model Driven Engineering Languages and Systems, pp. 1–10. Association for Computing Machinery (2020). https://doi. org/10.1145/3417990.3420204 51. Magrabi, F., Habli, I., Sujan, M., et al.: Why is it so difficult to govern mobile apps in healthcare? BMJ Health Care Inf. 26(1) (2019). https://doi.org/10.1136/bmjhci-2019-100006 52. Heijmans, J.: Low Code: wave of the future or blast from the past?. https://medium.com/ softwareimprovementgroup/low-code-wave-of-the-future-or-blast-from-the-past-7fcd61 8371b2. Accessed 25 Jul 2022 53. Hufeld, E., Bock, T.: Erfolgreiche Etablierung von Citizen Development in Großunternehmen: Ein Leitfaden für Digitalisierungsverantwortliche. https://simplifier.io/wp-con tent/uploads/Leitfaden-Citizen_Development_in-Grossunternehmen_etablieren_Executive_ Summary.pdf. Accessed 03 Aug 2022 54. Whitmore, R.: Citizen Development Part 2. https://www.projectmanagement.com/blog-post/ 69464/citizen-development-part-2--getting-started. Accessed 15 Jul 2022 55. Overeem, M., Jansen, S.: Proposing a framework for impact analysis for low-code development platforms. In: 2021 ACM/IEEE International Conference on Model Driven Engineering Languages and Systems Companion (MODELS-C), pp. 88–97. IEEE (2021). https://doi.org/ 10.1109/MODELS-C53483.2021.00020 56. Bradley, T.: Citizen developer movement: How IT can safely harness the energy. https:// techbeacon.com/enterprise-it/how-it-can-stop-worrying-learn-love-citizen-developer-mov ement. Accessed 25 Jul 2022 57. Bevans, D.: Build a Digital-first Workplace with Citizen Development. https://www.mendix. com/blog/build-a-digital-first-workplace-with-citizen-development/. Accessed 24 Jul 2022 58. Wang, Y., Feng, Y., Zhang, M., et al.: The necessity of low-code engineering for industrial software development: a case study and reflections. In: 2021 IEEE International Symposium on Software Reliability Engineering Workshops (ISSREW). IEEE (2021). https://doi.org/10. 1109/ISSREW53611.2021.00112 59. Fitzmaurice, M.: Why citizen development is the wrong model for many enterprises. https://venturebeat.com/2021/08/15/why-citizen-development-is-the-wrong-modelfor-many-enterprises/. Accessed 14 Jul 2022 60. Heuer, M., Kurtz, C., Böhmann, T.: Towards a governance of low-code development platforms using the example of microsoft powerplatform in a multinational company. In: Proceedings of the 55th Hawaii International Conference on System Sciences (2022). https://doi.org/10. 24251/HICSS.2022.831 61. Lieberman, H., Paternò, F., Wulf, V. (eds.): End User Development. Springer Netherlands, Dordrecht (2006) 62. Benson, D.H.: A field study of end user computing: findings and issues. MIS Q. 7(4), 35–45 (1983). https://doi.org/10.2307/248745 63. Runeson, P., Höst, M.: Guidelines for conducting and reporting case study research in software engineering. Empir. Softw. Eng. 14(2), 131–164 (2009). https://doi.org/10.1007/s10664-0089102-8 64. Andreessen, M.: Why Software Is Eating the World. Wall Street J. 8(20) (2011) 65. Woo, M.: The rise of no/low code software development-no experience needed? Eng. (Beijing) 6(9), 960–961 (2020). https://doi.org/10.1016/j.eng.2020.07.007
DevOps Challenges in Organizations: Through Professional Lens Nasreen Azad
and Sami Hyrynsalmi(B)
Department of Software Engineering, LUT University, Lahti, Finland [email protected]
Abstract. DevOps is a set of organizational practices as well as a culture which tries to eliminate the barriers between the Devs and Ops teams, improve the collaboration and communication among teammates. DevOps is used in different organizations because it supports quicker production, stability and reliability for software development. While the success factors of DevOps adoption have been studied in the extant literature, also the perceived challenges that a company faces during the adoption are crucial to discover. This paper explores and highlights these challenges through an open ended survey (N = 15) and in-depth interviews with DevOps professionals (N = 16). According to the findings, there are various challenges while implementing DevOps in the organizations. The research suggests that (i) lack of team coordination, (ii) risky change and development, (iii) team members expertise level, (iv) lack of focus or differences in development, (v) test and production environment, (vi) poorly defined functional and technical requirements, (vii) poor integration and test process, (viii) pipeline execution problems, (ix) tools integration challenges, (x) people challenges and silo-ed thinking, (xi) debugging challenges due to remote execution, (xii) feature release challenges, (xiii) integrating new standards, (xiv) challenges with clients, (xv) knowledge sharing, (xvi) responsibility distribution issues are the challenges while using DevOps. The founded list of perceived challenges will help future research to suggest mitigation and risk management strategies for successful use of DevOps.
Keywords: DevOps implementation
1
· DevOps challenges · DevOps adoption · Devops
Introduction
DevOps is an emerging concept for the medium- and large-sized software companies that helps to bridge the gap between the development team and operations team [13]. DevOps employs continuous software development that triggers the continuous delivery and continuous development to support DevOps overall software life-cycle [29]. While delivering the software to clients the software companies deliver through the internet, it is delivered Software as a Service (SaaS), c The Author(s), under exclusive license to Springer Nature Switzerland AG 2022 N. Carroll et al. (Eds.): ICSOB 2022, LNBIP 463, pp. 260–277, 2022. https://doi.org/10.1007/978-3-031-20706-8_18
DevOps Challenges in Organizations: Through Professional Lens
261
or sometimes it acts as a channel for delivering software directly to customers as the software runs on existing mobile platforms and technologies [17] The companies are frequently changing and adopting new development strategies to stay in the market. To ensure the good quality of the software development, companies went through different methods from waterfall to agile and gradually to DevOps. Companies are willing to increase the quality so that software can be released faster with a higher frequency [16]. When companies started using agile methods for software development the performance of the team was developed and improved. The performance was achieved with crossfunctional teams settings with a closer collaboration with customers [24]. When DevOps was introduced, the main goal was to expand the cross functional teams activities and bring the operations teams and development teams on the same page [16]. The continuous deployment of software increased opportunities for companies yet it brought many challenges as well [24]. When a company starts implementing DevOps and adopts DevOps terminology then the company faces various organizational, cultural, social, technical, managerial challenges in different phases of the software cycle [3]. As the adoption of DevOps is a challenging process for the companies, the organization supports the process through technological changes, adopting new processes, recruiting trained personnel, consultants and accepting innovations. Adopting DevOps in the company is a unique process which generates many challenges and that impacts on different factor of DevOps. In this paper, we aim to identify the challenges and adoption phase of DevOps in the various software companies and how the companies mitigate the risks and challenges. We will investigate these issues based on an online survey with openended questionnaire (N = 15) and in-depth interviews (N = 16) with DevOps professionals from different companies. Consequently, we will address the following research questions in this paper: RQ1: What are the perceived challenges of DevOps projects for professionals? RQ2: How to mitigate the challenges and risks for DevOps? In order to address the research questions we have collected data in two phases. At first we have conducted an open-ended questions through online survey with 15 DevOps professionals. In the second step, we have conducted in-depth interviews with 16 DevOps professionals. We have conducted a qualitative analysis on the data we have collected. Our findings suggests that there are various DevOps challenges, implementation and risk mitigation processes in every companies. This study will contribute to the literature of DevOps research by empirically supporting the perceived DevOps challenges, thus helping further work to form risk mitigation strategies for successful DevOps. The remaining of this study is organized as follows. Section 2 presents DevOps’ definition, DevOps implementation, DevOps adoption, DevOps benefit, DevOps challenges, risk mitigation process and their related literature. It is followed by the description of the empirical data collection and the research process in Sect. 3. Section 4 presents the results, Sect. 5 discusses on their impacts, and Sect. 6 concludes the study.
262
2 2.1
N. Azad and S. Hyrynsalmi
Related Work DevOps as a Definition
DevOps describes how cross functional teams work together to build, test and release faster software more reliably [25]. Automation plays a vital role in DevOps operations as its goal is to improve collaboration between two teams in terms of software development. Figure 1 illustrates the different aspects discussed in various definitions of DevOps. According to Macarthy and Bass [25] there are two conflicting views of DevOps. They suggested that DevOps is an organizational culture that is used to facilitate and increase software development processes rapidly. The second view suggested that DevOps is a job description lens that requires both skills for software professionals like development skills and operations IT skills for successful execution of job duties. Based on these two views of DevOps practices, we can say that DevOps is not about the automation process only. Though automation play a vital role in DevOps operations, other aspects need to be addressed too [30]. In addition, there are definitions and industrial view of DevOps from professionals. A DevOps professional from Company A—c.f. Sect. 3—stated that “Some people define DevOps as a culture. It’s partially right, but my kind of opinion would be when you asked a software developer to do operational work he will have a mindset to do it. So basically, it’s way of doing things”.
Fig. 1. DevOps definition overview (adapted from [29]).
DevOps Challenges in Organizations: Through Professional Lens
2.2
263
DevOps Implementation, Adoption and Benefit
Companies are implementing DevOps and adopting the DevOps culture to improve the software delivery process [32]. DevOps minimizes the gaps between the operation and development teams once it is successfully implemented and adopted within the software organizations. The development process triggers the software deployment and that turns the software into production for the software organizations [13]. The main aspect of DevOps in an organization is to provide continuous delivery and continuous deployment so that the software is delivered faster with short delivery cycles [17]. According to Krey et al. [22] small and medium size enterprises face six major challenges: costs, risks, scope, quality, business value, and time. There are number of factors which might lead to unsuccessful DevOps implementation. For instance, a lack of communication can make DevOps adoption process unsuccessful. The responsibility of the operations teams are specific and the teams do not pass or monitor different performances that could help the developers for executing tasks [27]. Developers and operations engineers are often concern about conflicting situations among team metrics, as the frequency of release is very important concern for developers and operations personnel [27]. The expectation of customers and users is to get software applications based on their need [18]. Due to this reason and ongoing demand companies are trying to make release frequently and deploy faster. To create this process environment efficiently there should be a proper way to work and tackle the environment. If the system is not utilized properly there will be system failures and that will lead to customer dissatisfaction. DevOps will handle these miscommunications and will fill the gaps with four guiding principlas. According to Gupta et al. [18] automation, culture, collaboration and measurement are four main principals. Gupta et al. [18] also suggested four variables which impacts the implementation process named source control, automation, cohesive teams and continuous delivery. 2.3
DevOps Challenges and Risk Mitigation Process
One of the vital issue for the development teams and operations teams is a proper tool as having different toolset can create problems for both teams [8]. Having good communication between Dev and Ops teams should be spontaneous otherwise the lacking of communication might cause delays for both teams operating process [27]. DevOps uses a variety of tools to make the process progress further. Due to the COVID-19 pandemic most of the work went remote which has affected the working process tremendously [26]. As we can understand that only electronic tools cannot solve the problems which could be solved in person. A remote work can never replace an in-person communication. Tools integration is another important issue which can be sometimes problematic and difficult in terms of maintenance and execution [7]. To overcome risk and challenges the companies could apply some strategies. Some of those strategies could be overcoming the Dev and Ops mentality, com-
264
N. Azad and S. Hyrynsalmi
mon understanding on the continuous delivery practice, shifting the infrastructure and architecture to microservices, test automation strategy implementation, prioritizing tools, release ownership of teams, resistance to change, continuous learning etc. According to Jones et al. [21] a company can introduce a job crafting that might help DevOps professionals to meet their personal needs and goals. Job crafting is an individually driven design process that initiates proactive strategies to change characteristics of some one’s jobs so that there is a better alignment of personal improvement. Job crafting can help employees to exercise three primary avenues: (i) Exercise greater control over the task, (ii) determine the way task are perceived, and (iii) deciding on the social context and relationships that will be encountered at work [6]. According to Jones et al. [21] task, relational, and cognitive are three ways of job crafting that can increase work performance while adopting DevOps in the companies. Liete et al. [23] suggested that there could be three solutions while implementing DevOps adoption in the companies. Those solutions includes (i) department collaboration, (ii) DevOps teams, and (iii) cross functional teams in the organization.
3
Research Approach
Our aim was to understand DevOps challenges and risk mitigation through professionals’ observation. In our study we have set two research questions. To answer these research questions, We have used an explorative qualitative research approach. We have used two methods for data collections. We have conducted survey with open ended questions and took semi structured interviews of DevOps professionals. From the open-ended survey questionnaire, we have got various data from professionals. Some of the answers and concepts were not clear enough from the open-ended questions. Then we have conducted semi structured interviews which gave us concrete and clear perceptions regarding DevOps challenges and risk mitigation process. Both methods (open ended questions and interviews) for were used because data triangulation in qualitative inquiry help researchers in a broader understanding of the phenomena. If researchers limit the data collection to one methods then the result might exclude many insights and the results will give a partial view of the phenomenon [20]. Below we will discuss the data collection and data analysis process elaborately. 3.1
Data Collection
For the data collection process, the first method we have used is an open-ended survey questionnaire. According to Schulter et al. [28] open-ended survey questionnaire is an efficient method for data collect from respondents. We have followed the method proposed by Schulter et al. and collected data from a specific group of respondents who are specifically working on DevOps as professionals. For the data collection we have conducted the survey through online platform. A questionnaire theme included DevOps process, DevOps adoption, DevOps challenges, DevOps implementation and DevOps risk mitigation process. There were
DevOps Challenges in Organizations: Through Professional Lens
265
Fig. 2. Thematic maps for DevOps challenges and risk mitigation (adapted from [27]).
25 questions developed for the survey and implemented by using Google Form. The survey was published in the first quarter of 2022. There were five demographic questions regarding country origin, role in the company, company size, and work experience in software development process. The respondents explained their thoughts and wrote their experience for using DevOps in their teams. For collecting our responses we have shared the survey link through different social media platform. We got the survey responses were from Finland, Netherlands, Spain, Sweden, Trinidad and Tobago, and United kingdom. We have got a good amount of data from the responses which helped us for data analysis later. Partial responses were rejected. In the end, there were 15 usable answers. The size of the company they represented had 50-20,000 employees. The position they hold in the company were Head of technology, Tech lead, Scrum Master, Site Reliability Engineer, DevOps Engineer, Software Specialist, Business Analyst, Cloud Engineer, Technical Project manager and Software Engineer. The respondents had a working experience in the software development industry from 3 to 20 years. We have also conducted interviews with DevOps professionals. This was our second research method for collecting data for the research. The researchers were intending to take the interviews to align the academic literature findings, validate concepts, challenges professionals faces with their DevOps operations, professional practices, DevOps implementation and adoption in the companies. For conducting interviews we developed an interview questions. There were 31 questions which covered five DevOps themes. Those themes included overview of challenges on Management, Integration and Deployment, Infrastructure management and monitoring, Technical and social and cultural overviews.
266
N. Azad and S. Hyrynsalmi
The interviews were conducted through an online meeting tool Microsoft Teams for 45 min. It was recorded after taking the permission from the interviewees. Those who were not comfortable with recording were skipped from recording and notes were taken instead for gathering information. The recording was done due to further revision and validation if required. Overall, 16 interviews were held. The interviewees were DevOps professionals, working mainly either with software engineering or project management duties. The interviews were done during the second quarter of 2022. The 15 survey respondents and 16 interviewees represented 18 different companies. For the data analysis and reporting phase, we put together the data concerning the same company. In the reporting of the results, we refer to these companies with letters from A to R. 3.2
Data Analysis
For data analysis part we have used thematic mapping method. According to Cruzes et al. [12] thematic analysis is a method which helps to identify, analyze, and report themes and patterns within the data. It helps to understand the dataset in an organized way and interprets many aspects of research topic [9,12]. Two researchers were involved in coding and categorizing the data in two phases. The researchers at first coded and categorized the survey data. Then the interview data was coded and analyzed separately. Both analysis process involved repeated and careful readings. Then the data was sorted and While doing the categories the researchers put sub categories based on themes of the texts. After completing the coding process the researchers compared their views with each other.
4
Results
This section presents the findings of our data analysis which identifies various challenges overviews of DevOps professionals. Our findings discusses several DevOps implementation challenges the professionals face while working in teams. Below we discuss five overviews of the professionals. 4.1
Management Overview Challenges
In our interview with 16 individuals we tried to know four management overview aspects of DevOps implementation and adoption process in the organization. We have found several challenges for management overview. Among those challenges Lack of team coordination, Risky change and development, People challenges and siloed thinking, Challenges with clients, Responsibility distribution issues, DevOps implementation challenge, DevOps adoption challenge including new skills and capabilities and DevOps adoption consequences. some of the challenges are discussed below. We will discuss more about challenges in discussion section.
DevOps Challenges in Organizations: Through Professional Lens
267
Scenario of DevOps Implementation Experience The scenario of DevOps first implementation is different experience for most of the engineers. Respondent from Company A quoted that when he “joined the company as a web developer, there wasn’t much stuff. They used AngularJS and Node. js for development purposes and then they started using Docker and GitLab very slowly and the new tools implementation made the software process faster”. A professionals from Company H stated that, “Basic principles for the base layer is same and the idea is to automate the things for internal development environment. So wherever we are developing the products, the first task is to automate most of the things like testing the deployment. It really is whatever comes up altogether, so we have to automate the whole process or the pipeline”. DevOps Adoption Challenges for Professionals According to DevOps professionals there are various challenges. The challenges could be managerial, social, administrative, technical and communication challenges. New Skills and Capabilities. The engineers faces some challenges related to different issues as DevOps is the combination of different sort of operations. Some professionals stated that when they had to move from web development to DevOps, there were lots of things like cloud, new technology, new language and development environment. Moreover good knowledge on different technology is required for developers and due to that developers needs to keep learning. So this is a challenge if someone is not very experienced with DevOps. Another challenge is the complexity in the setup process of DevOps in the company. There are various connecting factors related to to DevOps setups for the first time. It is time consuming and any new adoption takes time for companies and employees to get adjusted with the working process. This is one of the vital challenge for DevOps adoption. DevOps professionals from Company B stated that “We face challenges with the pipeline sometimes and there is a knowledge gap in teams. Because there is a lot of things to learn, so when we face something new we try to learn it and fix it”. Company H professional’s stated that “right now in the market finding the right person who is capable enough of doing all related activities is a challenge. They have lack of knowledge regarding DevOps adoption”. According to the respondents the challenges at this moment for DevOps adoption is insufficient knowledge in industries and the engineers also have a knowledge gap. Though they might have some strong understanding or knowledge or background in some specific part of the software development but DevOps practices still needs to be understood by many of them. DevOps needs proper communication with Software developer. The engineers witnesses that sometimes a developer only working on his coding but when deployment comes, he doesn’t have really much idea what’s happening in the back end or in the cloud system and also the automation is unclear to him.
268
N. Azad and S. Hyrynsalmi
Consequences of DevOps Adoption in the Companies. There are a lot of positive consequences for DevOps adoption. DevOps helps developers to think less and there is less complexity in the flow of work. When a developer works they develop codes and push it to the repository. Someone will review the codes and after that the developers do not need to do anything if there is 100 percent automation. When there is a good automation developers just wait so that continuous testing, continuous integration and all these tasks are done automatically. The adoption of Devops helps the production cycle smooth and help the companies to save time and cost. One respondents form company C stated that “Companies needs to hire good and experienced DevOps personals for DevOps implemention and adoption. Company is spending time and money on that. Though the expenditure is increasing, but on the other hand they are saving lot of mishaps in the software development process”. Another DevOps professional from the company stated that “Biggest challenge that adaptation is not much welcoming for many people or organizations”. 4.2
Technical Overview Challenges
Our second theme was to know the technical overviews of DevOps in the organization. As all companies have different setups and tools for DevOps operations, it was really important to know the overall workflows of the DevOps and how tools can be a challenge for the DevOps process. From our responses we have identified some technical challenges. Among those Test and production environment, Poorly defined functional and technical requirements, Debugging challenges due to remote execution, work flow or practices for deployment challenges are some technical challenges. Work-Flows/Practices for Deployment and Operational use in Production Process. For the technical part developers need to put 15 test or any number of tests they want to put in the testing process. Everything will be tested so the engineers don’t need to worry about small things and small details. The system needs to be setup once so that from the next time everything’s will be checked automatically without any hassle. According to a professional “At the beginning even before starting the development, various tools like JIRA is used for the task management. There they used to maintain a backlog. The product owner maintains the backlog. Four developers get the task based on the importance and requirements. The developers develop and also maintain the tasks. They develop new features, but if there is something broken then they prioritize stuff and fix it. The company has 21 d sprint. So after every 21 d the engineers have a meeting for this Sprint review and retrospective. And then the release starts”.
DevOps Challenges in Organizations: Through Professional Lens
269
From company E a professional quoted that “If there is no dependence, I just finish it and then I push my code to the Gitlab. I push my code to Gitlab and then someone from my development team has to review that one. So when I push my code. There is certain test for all the codes. when my development task is finished, I push my branch to the repository and there is certain pipeline for that. Certain taste for that. So if the pipeline succeeds, that means everything went well”. 4.3
Integration and Deployment Overview Challenges
Our third theme was related to integration and deployment. This theme has covered a helicopter view of DevOps processes in different organizations. We asked DevOps professionals about the levels and stages when software changes are integrated build and tested. To support the building and testing what tools are used, to ensure the quality what practices other than testing is required, for deploying and delivering product to customers what processes the company use, for the deployment pipelines how the quality is assured and finally what are the most important challenges regarding quality. From the responses we have found some challenges named quality of product assurance challenges, quality assurence in development pipeline, Tools integration challenges and lack of focus or differences in development. Quality of the Product Assurance. Quality of the product depends on many things. For example, most of the codes the developers use are unstable. Only testing does not contribute to the quality of the product. whenever we are pushing codes to the development container we can see the progress in the graphs. In the monitoring system we can check is everything going right. And there are lots of checks in different phases of the process. For example, there is one check going on that whether the user can log in or not to the system. So if the login fails, that means there are some problems in the log in process. Then developers fix the issues. A DevOps professional, from company F, stated that “Testing is the part like when you have kind of predefined set of logics already implemented before developing the product. We have these use cases where the test should have passed before submitting to the actual production. So this setup impacts the quality of the product, integration and deployment”. Most of the professionals believes that code review is a major issues to consider and a certified reviewer can impact on the overall development process. The most senior developers review the codes. This sort of checks ensures a good quality for the integration. Quality Assurance in the Development Pipelines. Quality assurance in the development pipeline was seens as a bit challenging. When software is deployed many times the system faces issues, which will come from the customer sides. Though
270
N. Azad and S. Hyrynsalmi
before the deployment testing, review, verification and lot of things are processed. Before deployment the engineers try always try to cover up or implement those process so that they don’t see any problem after the deployment. 4.4
Infrastructure Management and Monitoring Overview Challenges
This themes discusses about the infrastructure management and monitoring processes. We asked questions from professionals to know who is responsible for managing and maintaining infrastructure, does the development team has access to resources in production, how the non functional requirements and information about configurations are communicated to developers, how different environments of applications are managed, how the software changes deployed in production and how monitoring process is performed in production. We have found some challenges named infrastructure management challenges, Development teams production challenges due to resourses, feature release challenges,pipeline execution challenges etc. Infrastructure Management. Infrastructure management is very important for DevOps process. Cloud platform engineer and cloud engineers are responsible for maintaining the infrastructure. There are a bunch of different sections. DevOps engineers does coding. But there are some other people who are more focused on Operational side of the system. So they’re not necessarily a very good or a strong coder, but they have very good operational knowledge or at least they’re kind of guru in Linux based things. So these are a bunch of people who were responsible like maintaining or creating the infra like cloud engineer platform engineer or DevOps or site reliability engineer. Development Teams Access to Resources in Production. Development teams has a little access to the resources in production. Some companies maintain mainly development, production and infra and everything for the internal use as the companies do not need to maintain any websites or web applications. For some of the projects where the applications are customer facing the production setup is kind of untouchable or there are very few people who have the access. Most of the time the access is restricted and for the development process. 4.5
Company Cultural and Mind Set Overview Challenges
Our last theme included DevOps culture in the organization, We aimed to know does the company support DevOps approaches, mindset, development culture in the organization and the management support for the development practices with culture visibility. We have found some challenges including Integrating new standards challenges, knowledge sharing challenges, Development culture and mindset challenges and management support challenges.
DevOps Challenges in Organizations: Through Professional Lens
271
Development Culture and Mindset. The development culture and mindset of a company is very crucial for a successful DevOps implementation in the organization. The mindset of the team is to make the customer happy with the product, keep the production ongoing with efficiency and make the process bug free so that there should not be any problem. Another mindset explained by the professionals are to run the current production perfectly as much as possible and then adding more features for the production process. From a company to a company, or from a team to a team the culture and mindset varies. Although they are working with the same kind of technologies. The teams needs to have a clear mindset and purpose. In case of coding, for example, the code reviews can be done in various ways. Some people are managing the actual code base in GitHub or Beat bucket. So not all teams following the same kind of principle in this case. At the end the aim to ship the codes to the production. The mindset al. so depends on the size of the production. One respondent from company H stated that “Most important part, as a DevOps engineer or any developer is that they need to be adjusted with the changes and needs to be agile. So if they have the mindset that they will not change and will continue with the traditional way of doing then definitely they will be way behind the industry practices”. Management Support for the Development Practice. Different organizations have different kind of management support for the teams. according to the professionals the employees get support mostly but every requirements of the DevOps teams are not always accepted. According to a respondents from company C “The top management always decide what they think is good for the company. I think they decide on that and due to that all the time we don’t get what we want. Though most of the time management supports our needs for the team”. 4.6
Risk Mitigation
Risk mitigation process for better performance For risk mitigation and better performance there could be several approaches. According to the respondents there are four approaches which could help the professionals to handle risks for the organization. Those approaches includes enforcing security policy, process automation, introducucing DevsecOps model and better management strategy. It is necessary to create a comprehensive environment where the securities issues can be handled. For creating this environment effective communication and establishing governance is required. There should be a good security system or a set of cybersecurity approaches where the security processes will be easy, transparent and understandable. The security process could cover wide range of issues including code review, restrictions for access, management configuration etc. Our respondents from company D stated that “DevOps teams should work with security teams so that a secured application can be produced with good policies, tools under collaboration”.
272
5 5.1
N. Azad and S. Hyrynsalmi
Discussion Key Findings
This study addresses two aspects of DevOps. Firstly, the perceived challenges by industry professionals and, secondly, risks mitigation for DevOps. From the survey and interviews with professionals, we have got an initial list of DevOps practical challenges faced by organizations. Though these challenges are not universal. These are professionals own view regarding challenges they face while working in companies. Miscommunication between Dev and Ops teams is a major issue for DevOps process success. Some of the DevOps professionals reported that there is a lack of team coordination while working in a team [2,3,22,27]. When there is a lack of communication that make DevOps adoption process unsuccessful [2,22]. This is one of the biggest challenges in terms of performance and quick releases [4]. Respondents told that rapid release increases the chance of better performance with less time [4]. According to the respondents we have got an idea that DevOps implementation in a company for the first time is very risky and difficult, which might lead unsuccessful DevOps implementation. The changes were perceived to be always difficult. The change process creates confusion among employees and many times it is difficult for the employees to adopt and accept new changes. This new change is challenging and time consuming too [3,22]. Lack of focus or differences in development is another challenge for DevOps practices. Many times devlopers faced that there is a lack of focus in the development process. They are not sure of what they are doing, there could be miscommunication with team members. There could be misconceptions between development teams and operations team members. Due to these reasons differences occur in the development process [2,4,22,27]. Test and production environment is a challenge too. Testing and production environment is very crucial for the production process. It is very important to have a good testing for the code and the production environment should support the testing process. When there is poor integration that hampers the testing process. Due to that reason the test set ups should be proper so that the rest of the process can work well [15]. Poorly defined functional and technical requirements are another challenge faced by professionals. When DevOps engineers are working on a project, there are always some technical requirements and functional requirements. Before start working on a specific task the technical requirements should be clearly defined to teams so that there is no confusion about the task. When the requirements are not defined clearly then that become a challenge for the team to work on functional and technical requirements for the end product [10,11,19]. DevOps pipeline is a set of automated processes and tools which helps the developers and operations professionals for collaboration so that the codes can be build and deployed to the production environment. Sometimes the professionals faces pipeline execution problems. In a pipelines there are several process
DevOps Challenges in Organizations: Through Professional Lens
273
like CI/CD, continuous testing (CT), continuous deployment, continuous monitoring, continuous feedback, continuous operations, develop and build. When there is an execution problem in the pipeline that become a challenge for the developers [14]. Choosing the right tools for DevOps operations is another challenge for companies. There are several tools that are used for DevOps and the company chooses the tools based on their needs and requirements for the project. Finding or choosing the right tools is often challenging for companies. While there a plethor of tools [c.f. 1], according to the respondents sometimes the company chooses tools which are not effective and make the process even slower [4]. People challenges and siloed thinking is also a vital challenge for DevOps prctices. Sometimes people challenge is not easy to figure out. There are still siloed thinking among people and teams while working together in an organization [31]. Debugging challenges due to remote execution is also a challenge for professionals. Due to remote work most of the DevOps engineers faced debugging challenges. They said that it was difficult when they were not working from office, they could not get support for many technical issues and other issues which could have been easier to handle if they could work from office [15]. Knowledge sharing is another challenging issues for DevOps process. Knowledge sharing can be hard and team members have to be careful not to overwhelm other members [33]. There are also clear positive impacts for using DevOps in companies. From respondents we observed that in previously software developers worked in the companies and there were no DevOps practices in the organization. Gradually the developers got to know how the implementation works for DevOps operations, how the actual level of testing should be done and how to configure the CI/CD pipelines. In previous time, developers used to do many operations manually and after implementation of DevOps most of the operations become automated. Previously developers needed to prepare infrastructure for the sales engineer which were mostly manual. The previous process used by developers used to take lot of time. It was not easy to figure out how this works or doing many manual testing for the development phases. But when the developers introduced to DevOps, they found that there are quite many things which are simple and they can do it very effectively and that could save a lot of time for the software development process. Good knowledge on DevOps is perceived to be really important, and which will benefit DevOps engineers to deliver the product in time. 5.2
Research Limitations
There are some limitations of our research. First, the data was collected through an open-invitation online survey. It was not easy to get complete responses for the open-ended questionnaire. Due to the short response time, the number of received responses remained low. If we could get a good number of responses, this could reveal more information on the topic.
274
N. Azad and S. Hyrynsalmi
Second, we could take some interviews of the DevOps professionals that provided richer data and many new angles were discovered. The time for the interview was short. For future work we plan to conduct more interviews with the respondents. Third, DevOps is a specific domain. Identifying specific respondents was a real challenge. Researchers contacted many individuals personally to set up the interviews. Moreover DevOps is a progressing practice for many companies. Due to this reason finding respondents was difficult which is considered as one of the major limitations for this research. Fourth, according to our observation some respondents had a lack of knowledge on DevOps. Some of the respondents were new to the company and had little idea about DevOps culture, some respondents were explaining how DevOps are communicated among teams and still the misconceptions are present in the process. They were unable to answer some managerial, cultural and organizational questions. Fifth, in our research there could be response bias and selection bias. The answers we have received from the respondents were not specific. There could be some bindings and confidential issues regarding information sharing. Moreover this study could connect the DevOps model with empirical support. To discover more we need to do more research so that components of the CSF model, see [3], align with the challenges. However, more work is needed to both develop the model further as well as empirically validate its components. 5.3
Future Reserach
According to our findings from the literature review we got some topics which need more study in the DevOps domain. These topics could be a great opportunity for future research agenda for critical success factors of DevOps. Research model for identifying challenges Based on our literature review we have got several factors for future work in this domain. A new model could be developed for DevOps challenges along with the critical success factors. This new model could be used as a guiding framework for investigating various challenges in the organization. Combining DevOps and AI for better performance Artificial intelligence (AI) has potential which could combine DevOps for better performance. DevOps efficiency would increase more for using AI in the software development life cycle. When AI is involved with DevOps then that will increase quick development and the operation cycle performance will increase at the same time. This will provide a good experience for the users with new features of AI implementation with DevOps. This will trigger the machine learning algorithms to gather data from various sources for the DevOps system [5]. This could be a great future research agenda which will facilitate various models developed with AI and DevOps. Theory-based approach According to our literature we have observed that very few studies were conducted for theoretical frameworks for critical success factors and challenges. From our literature review we have seen that there is a lack of theoretical papers that discuss DevOps success factors along with challenges.
DevOps Challenges in Organizations: Through Professional Lens
275
Combining Blockchain and DevOps challenges The combination of Blockchain technology and DevOps Challenges has a great potential for future research agenda. DevOps helps to increase number of software releases and blockchain could help storing highly sensitive and private information for the project, industry, and product needs. Most of the time sharing sensitive files and records are challenging issues due to data sharing. In this situation use of Blockchain technology along with DevOps could be a key solution to this problem. This is a new research area and there could be many possibilities to explore blockchain and DevOps operations.
6
Conclusions
DevOps is an organizational culture which helps the development teams and operations teams to operate smoothly for software development life cycle. DevOps challenges have a strong impact on companies performance. Solving those could help the companies to improve their culture and support the future challenges for DevOps practices. We got the perspectice and view of DevOps professionals through open-ended questionnaires and in-depth interviews with the professionals. We have listed several challenges which they face for DevOps implementation and DevOps adoption process. This research will be helpful for future research agenda and investigate more on DevOps domain.
References 1. Akshaya, H., Vidya, J., Veena, K.: A basic introduction to devops tools. Int. J. Comput. Sci. Inf. Technol. 6(3), 05–06 (2015) 2. Azad, N.: Understanding devops critical success factors and organizational practices. In: 2022 IEEE/ACM IWSiB, pp. 83–90. IEEE (2022) 3. Azad, N., Hyrynsalmi, S.: What are critical success factors of DevOps projects? a systematic literature review. In: Wang, X., Martini, A., Nguyen-Duc, A., Stray, V. (eds.) ICSOB 2021. LNBIP, vol. 434, pp. 221–237. Springer, Cham (2021). https:// doi.org/10.1007/978-3-030-91983-2 17 4. Bass, L., Weber, I., Zhu, L.: DevOps: a software architect’s perspective. AddisonWesley Professional (2015) 5. Battina, D.S.: Ai and devops in information technology and its future in the united states. Int. J. Creatitve Res. Thoughts, 2320–2882 (2021) 6. Berg, J.M., Dutton, J.E., Wrzesniewski, A.: Job crafting and meaningful work (2013) 7. Bezemer, C.P., Eismann, S., Ferme, V., Grohmann, J., et al.: How is performance addressed in devops? In: Proceeding the 2019 ACM/SPEC ICPE, pp. 45–50 (2019) 8. Bou Ghantous, G., Gill, A.: Devops: concepts, practices, tools, benefits and challenges. In: PACIS 2017 (2017) 9. Braun, V., Clarke, V.: Using thematic analysis in psychology. Qual. Res. Psychol. 3(2), 77–101 (2006) 10. Broy, M.: Rethinking nonfunctional software requirements. Computer 48(5), 96–99 (2015)
276
N. Azad and S. Hyrynsalmi
11. Cleland-Huang, J.: Quality requirements and their role in successful products. In: 15th IEEE RE 2007, pp. 361–361. IEEE (2007) 12. Cruzes, D.S., Dyba, T.: Recommended steps for thematic synthesis in software engineering. In: 2011 ESEM, pp. 275–284. IEEE (2011) 13. Debois, P., et al.: Devops: a software revolution in the making. J. Inf. Technol. Manage. 24(8), 3–39 (2011) 14. Dyck, A., Penners, R., Lichter, H.: Towards definitions for release engineering and devops. In: 3rd International Workshop on Release Engineering, pp. 3–3. IEEE (2015) 15. Ebert, C., Gallardo, G., Hernantes, J., Serrano, N.: Devops. IEEE Softw. 33(3), 94–100 (2016) 16. Erich, F.M., Amrit, C., Daneva, M.: A qualitative study of devops usage in practice. J. Softw. Evol. Process, 29(6), e1885 (2017) 17. Fitzgerald, B., Stol, K.J.: Continuous software engineering: a roadmap and agenda. J. Syst. Softw. 123, 176–189 (2017) 18. Gupta, V., Kapur, P.K., Kumar, D.: Modeling and measuring attributes influencing devops implementation in an enterprise using structural equation modeling. Inf. Softw. Technol. 92, 75–91 (2017) 19. Haindl, P., Pl¨ osch, R.: Focus areas, themes, and objectives of non-functional requirements in devops: a systematic mapping study. In: 2020 46th Euromicro SEAA, pp. 394–403. IEEE (2020) 20. Heale, R., Forbes, D.: Understanding triangulation in research. Evid.-Based Nurs. 16(4), 98–98 (2013) 21. Jones, S., Noppen, J., Lettice, F.: Management challenges for devops adoption within uk smes. In: Proceeding 2nd QUDOS 2016, pp. 7–11 (2016) 22. Krey, M., Kabbout, A., Osmani, L., Saliji, A.: Devops adoption: challenges & barriers. In: 55th HICSS, pp. 7297–7309. University of Hawai’i at Manoa (2022) 23. Leite, L., Rocha, C., Kon, F., Milojicic, D., Meirelles, P.: A survey of devops concepts and challenges. ACM Comput. Surv. 52(6), 1–35 (2019) 24. Lwakatare, L.E., Kuvaja, P., Oivo, M.: Dimensions of DevOps. In: Lassenius, C., Dingsøyr, T., Paasivaara, M. (eds.) XP 2015. LNBIP, vol. 212, pp. 212–217. Springer, Cham (2015). https://doi.org/10.1007/978-3-319-18612-2 19 25. Macarthy, R.W., Bass, J.M.: An empirical taxonomy of devops in practice. In: 2020 46th SEAA, pp. 221–228. IEEE (2020) 26. Nguyen-Duc, A., et al.: Work-from-home and its implication for project management, resilience and innovation - a global survey on software companies (2022). arXiv:2202.04950 27. Riungu-Kalliosaari, L., M¨ akinen, S., Lwakatare, L.E., Tiihonen, J., M¨ annist¨ o, T.: DevOps adoption benefits and challenges in practice: a case study. In: Abrahamsson, P., Jedlitschka, A., Nguyen Duc, A., Felderer, M., Amasaki, S., Mikkonen, T. (eds.) PROFES 2016. LNCS, vol. 10027, pp. 590–597. Springer, Cham (2016). https://doi.org/10.1007/978-3-319-49094-6 44 28. Schluter, J., Seaton, P., Chaboyer, W.: Critical incident technique: a user’s guide for nurse researchers. J. Adv. Nurs. 61(1), 107–114 (2008) 29. Senapathi, M., Buchan, J., Osman, H.: Devops capabilities, practices, and challenges: insights from a case study. In: The 22nd EASE 2018, pp. 57–67 (2018) 30. S¨ ollner, D.: Devops in der praxis-handlungsfelder f¨ ur eine erfolgreiche zusammenarbeit von entwicklung und betrieb. HMD Praxis der Wirtschaftsinformatik 54(2), 189–204 (2017). https://doi.org/10.1365/s40702-017-0303-8
DevOps Challenges in Organizations: Through Professional Lens
277
31. Tsanos, C.S., Zografos, K.G., Harrison, A.: Developing a conceptual model for examining the supply chain relationships between behavioural antecedents of collaboration, integration and performance. In: The International Journal of Logistics Management (2014) 32. Velasquez, N.F., Kim, G., Kersten, N., Humble, J.: State of devops report (2014) 33. Yoon, C., Lee, K., Yoon, B., Toulan, O.: Typology and success factors of collaboration for sustainable growth in the it service industry. Sustainability 9(11), 2017 (2017)
Implementing AI Ethics in a Software Engineering Project-Based Learning Environment - The Case of WIMMA Lab Mamia Ori-otse Agbese1(B) , Marko Rintamaki2 , Rahul Mohanani1 , and Pekka Abrahamsson1 1
2
University of Jyv¨ askyl¨ a, Seminaarinkatu 15, 40014 Jyv¨ askyl¨ a, Finland {mamia.o.agbese, rahul.p.mohanani,pekka.abrahamsson}@jyu.fi Jyv¨ askyl¨ a University of Applied Sciences, Rajakatu 35, Jyv¨ askyl¨ a, Finland [email protected] https://www.jyu.fi/en, https://www.jamk.fi/en
Abstract. Increasing ethical concerns necessitate AI ethics forms part of practical software engineering (SE) foundational educational learning. Using an ethnographic approach and focus group discussions in a SE project-based learning environment, WIMMA lab, we gain insight into how AI ethics can be implemented to enable students to acquire these necessary skills. We propose a framework as an outcome to aid the implementation of AI ethics skills within SE project-based learning environments. Keywords: Artificial Intelligence · Implementing AI ethics · Software engineering · Project-based learning · AI · Software business · PBL
1
Introduction
Advances in the engineering of Artificial intelligence (AI) using Big data, the rapid rise of the internet, and machine learning (ML) enables current AI systems to harness vast amounts of data and model solutions used in areas such as retail, health, and transport and warfare [1]. These advances, however, have become associated with ethical concerns such as bias and data privacy from negatively impacting incidents. Incidents such as the failure of the COMPAS AI-based recommender system necessitate that AI systems are engineered with appropriate AI ethical practices to help mitigate these challenges [2]. Jobin and Borenstein [3,4] explain that implementing AI ethics at the practical educational level can enable it to become foundational and cultural in software engineering (SE). It can also aid SE graduates to gain relevant AI ethics skills needed to adapt in real-life environments requiring AI ethics implementation and help software businesses to spend less on training recruits and practitioners [5]. However, scarce research exists for implementing AI ethics within practical third-level education, particularly in project-based learning environments, which aids students c The Author(s), under exclusive license to Springer Nature Switzerland AG 2022 N. Carroll et al. (Eds.): ICSOB 2022, LNBIP 463, pp. 278–284, 2022. https://doi.org/10.1007/978-3-031-20706-8_19
Implementing AI Ethics
279
in competence building and practical experience. Most focus on kindergarten to middle school level with hardly any representation for third-level education. We conduct anthropological research to gain a holistic perspective in a SE projectbased learning environment, WIMMA lab, to help us understand how AI ethics practices can be implemented within this learning environment. Our research question is RQ: How can AI ethics be implemented in a project-based learning environment?. We propose a framework to aid the implementation of AI ethics practices in a SE project-based learning environment. This contribution is significant as it can help inform guidance on this topic within SE project-based learning environments.
2
AI Ethics in SE Project-Based Learning Environment
AI ethics which deals with the moral behavior of humans in the design usage and behavior of machines [6] is mainly targeted at ensuring people, processes, and organizations responsible for AI systems assume responsibility for their engineering [6]. Currently, over 80 AI principles exist from research bodies, governments, and private organizations [3,7] in response to the growing ethical challenges associated with engineering AI. They highlight the importance of implementing ethics in AI engineering and the negative impact of poorly engineered AI systems [7,8]. They also help to push the AI ethics agenda to the forefront of SE by guiding the engineering of AI and highlighting the need for effective education of AI ethics for students and practitioners [3]. While they are criticized as insufficient in translating principles to practice [9], they remain the primary measure in implementing AI ethics. There is little research for implementing AI ethics skills in SE engineering project-based learning education. Studies from [10], and [11] create an understanding of technical and ethical AI concepts awareness for kindergarten grade to grade 12 and middle schools. [12] examined the concept of AI stakeholder identification in middle school students. However, no research was identified for SE project-based learning in third-level education. 2.1
WIMMA Lab
WIMMA lab, a SE project-based learning environment at the University of Applied Science Jyvaskyla, Finland, is used for this study. The lab uses projectbased learning to enable students to gain DevOps and DevSecOps SE skills using open source materials within four simulated SE virtual companies, IoTitude, Mysticons, Overflow, and Penguin Media. The entire project is managed using an open project framework (OPF) and documented in two guidebooks or playbooks. The Black book records the virtual labs’ operation, the types of practices and routines utilized, and the green technical processes. Figure 1 illustrates the current structure at WIMMA lab.
280
M. O. Agbese et al.
Fig. 1. Current structure at WIMMA lab
3
Methodology
We use an ethnography approach which allows researchers become part of the community and perform the same or relevant tasks to understand better the underlying phenomenon under study. 3.1
Data Collection
The four participants from the information systems field in the university of Jyvaskyla were split into teams, Mysitcons, Overflow and IOTitude based on competence in SE practices however, the primary researcher was there as a researcher. The main data collection for the study was in the form of a focus group which is very valuable when in-depth information is needed about how people think about an issue, their reasoning on why things are they way they are and why they hold the views they do [13]. The interview was conducted as a semistructured interview discussion and recorded over Zoom. The participants from the university of Jyvaskyla took part in the discussions which lasted for 47 min. Each participant received adequate information about the study and gave their full consent to participate in the exercise and for the use of the audio recording of the group discussion. For supplementary data, the primary researcher engaged in discussions with other team mates unofficially to understand their stance on the research topic.
Implementing AI Ethics
3.2
281
Analysis
The recordings were manually transcribed by replaying the Zoom recording, pausing, and rewinding to ensure the right information was transcribed. The transcribed data was then analysed by coding to identify themes that emerged accordingly. The data was coded under key themes which emerged to help achieve the aim and objectives of the study. The Analysis is categorized into themes derived and suggested practices aimed at achieving the aim and objective of the study. Table 1 illustrates the analysis. Table 1. Emergent themes and suggested practices. Themes
Practices
Awareness of AI ethics con- None, personal ethics, use of security Data Managecerns ment, Data governance, Security concerns, cybersecurity threats Current AI ethics practices
None
How AI ethics can be imple- Simplified framework to enable understanding, At mented the beginning of the project, Accountability, Stakeholder identification, Security measures to enable efficient implementation in the future like GDPR, Data management, Data governance, documentation/reference (playbooks, guides)
4
Discussion
The discussion is broken down into three main themes that emerged from the data analysis. 4.1
Awareness of AI Ethical Concerns
Concerns such as data management, governance, and cybersecurity threats are identified as possible avenues for AI ethical concerns. The students currently employ initiatives such as using normative ethics, creating technical processes to help deploy regulations such as GDPR in the future, and using engineering security practices. Suggesting that current research on AI ethics awareness is impactful and the use of more effective tools and education can increase impact [3,9]. It also suggests that targeted effort is needed because engineering AI is different due to data and close interrelation between human and artificial agents, which poses an extra challenge [14].
282
4.2
M. O. Agbese et al.
Existing AI Ethics Practices in WIMMA Lab
The findings reveal virtually no implementation of AI ethics practices. AI ethics framework or tools were not identified in the open source resources used by the students. This agrees with the review of literature where AI ethics practices could not be identified in SE third level education. Implying more research needs to be carried out to help inform these practices. 4.3
How AI Ethics Can Be Implemented
The findings reveal that simplified frameworks or tools can improve understanding of AI ethics and aid implementation. Such tools or frameworks can help guide how AI practices are fused with the SE processes. Blackman [15] explains that simple and flexible frameworks and tools that suit the context of its application can improve awareness of AI ethics and aid implementation. Progress has begun in AI ethical tools and methods [16], but a gap still exists in transitioning them to practice [3]. The findings recommend tools and frameworks to be used at the beginning of the project to enable students to have a better understanding of AI ethics and aid their development of the necessary skills associated with it. A study by [17] revealed the use of an ethically aligned design tool within a classroom learning environment enabled students to elicit ethical non-functional requirements. [15] also explains that operationalizing AI ethics using existing infrastructure and an AI ethics framework at the onset can aid implementation and help mitigate AI risks. Documentation of practices as playbooks for guidance and reference also formed part of the findings. [18] explains that documentation improves capabilities by making them more accessible, usable, and available for the learning community. Documentation can also serve as a point of reference to enhance clarity in areas of confusion. 4.4
Framework
We present our proposed framework for implementing AI ethics in SE projectbased learning environment in Fig. 2. The proposed framework allows for the use of an agreed-upon AI ethics tool or framework to serve as a reference or guide to consult on how AI ethical practices can be implemented at the beginning of the project. The practices within the framework can also be infused with open source resources and serve as a reference throughout the project lifecycle to enable the students to access it for clarity and guidance on the best practices to imbibe. As explained earlier, documentation of best practices helps improve implementation and inform knowledge [15]. Therefore, current practices as they unfold can be documented or infused with the project management system, with the best practices of AI ethics recorded in playbooks to be used by students that come on board in subsequent years for them to leverage for their projects.
Implementing AI Ethics
283
Fig. 2. Framework for implementing AI ethics in SE project-based learning environment
5
Limitation
Focus group investigations typically involve six to ten homogeneous strangers in a formal setting [13], however, we follow recommendation by [19] for less structured discussions using smaller groups to better suit the purpose of the study. Another limitation is the discussion of findings relevant to the narrow setting of the WIMMA lab however, it enabled for the generation of descriptive results for the study. The use of only one project-based learning environment may also pose a validity threat to the study, [20] explains that for novel research areas such as AI ethics with the scarce literature in its implementation, a low number of case studies can be acceptable. 5.1
Future Work
Future research can employ a quantitative approach to provide breadth to the research. This may provide a holistic view with divergent findings that can lead to a re-examination of the assumptions made in the study. The feasibility of the framework will also be tested to examine its efficacy.
6
Conclusion
We study how AI ethics can be implemented in SE project-based learning environments using an ethnographic approach in WIMMA lab using focus group discussion in the investigations. The outcome reveals that AI ethics practices are not implemented in SE practices. Based on the findings, we propose a framework is aid implementation.
284
M. O. Agbese et al.
References 1. Coeckelbergh, M.: AI Ethics. MIT Press, Cambridge (2020) 2. Gupta, M., Parra, C.M., Dennehy, D.: Questioning racial and gender bias in AIbased recommendations: do espoused national cultural values matter? Inf. Syst. Front. 1–17 (2021). 10.1007/s10796-021-10156-2 3. Jobin, A., Ienca, M., Vayena, E.: The global landscape of AI ethics guidelines. Nat. Mach. Intell. 1(9), 389–399 (2019) 4. Borenstein, J., Howard, A.: Emerging challenges in AI and the need for AI ethics education. AI Ethics 1(1), 61–65 (2021) 5. Ali, M.R.: Imparting effective software engineering education. ACM SIGSOFT Softw. Eng. Notes 31(4), 1–3 (2006) 6. M¨ uller, V.C.: Ethics of artificial intelligence and robotics. (2020) 7. Morley, J., Floridi, L., Kinsey, L., Elhalal, A.: From what to how: an initial review of publicly available AI ethics tools, methods and research to translate principles into practices. Sci. Eng. Ethics 26(4), 2141–2168 (2020) 8. Hleg, A.: A definition of AI: main capabilities and disciplines. Brussels (2019). https://ec.europa.eu/digital-single 9. Mittelstadt, B.: Ai ethics-too principled to fail. arXiv preprint arXiv:1906.06668 (2019) 10. Williams, R.: How to train your robot: project-based AI and ethics education for middle school classrooms. In: Proceedings of the 52nd ACM Technical Symposium on Computer Science Education, pp. 1382–1382 (2021) 11. Lee, I., Ali, S., Zhang, H., DiPaola, D., Breazeal, C.: Developing middle school students’ AI literacy. In: Proceedings of the 52nd ACM Technical Symposium on Computer Science Education, pp. 191–197 (2021) 12. Jordan, B., Devasia, N., Hong, J., Williams, R., Breazeal, C.: PoseBlocks: a toolkit for creating (and dancing) with AI. In: Proceedings of the AAAI Conference on Artificial Intelligence. vol. 35, no. 17, pp. 15551–15559 (2021) 13. Bell, J., Waters, S.: Ebook: Doing Your Research Project: A Guide For First-time Researchers. McGraw-hill education, New York (UK) (2018) 14. Ozkaya, I.: What is really different in engineering AI-enabled systems? IEEE Softw. 37(4), 3–6 (2020) 15. Blackman, R.: A practical guide to building ethical AI. Harvard Bus. Rev 15 (2020) 16. Vakkuri, V., et al.: Time for AI (ethics) maturity model is now. arXiv preprint arXiv:2101.12701 (2021) 17. Halme, E., et al.: How to write ethical user stories? impacts of the ECCOLA method. In: Gregory, P., Lassenius, C., Wang, X., Kruchten, P. (eds.) XP 2021. LNBIP, vol. 419, pp. 36–52. Springer, Cham (2021). https://doi.org/10.1007/9783-030-78098-2 3 18. Marshall, R., Pardo, A., Smith, D., Watson, T.: Implementing next generation privacy and ethics research in education technology. Br. J. Educ. Technol. 53(4), 737–755 (2022) 19. Morgan, D.L.: Focus groups. Ann. Rev. Sociol. 22(1), 129–152 (1996) 20. Eisenhardt, K.M.: Building theories from case study research. Acad. Manage. Rev. 14(4), 532–550 (1989)
Software Startups
Towards Understanding How Software Startups Deal with UX from Customer and User Information Joelma Choma1(B) , Leticia Machado2 , Cleidson R.B. de Souza3 , Helen Sharp4 , Leonor Barroca4 , and Luciana Zaina1 1
2
Federal University of S˜ ao Carlos (UFSCar), Sorocaba, Brazil {jchoma,lzaina}ufscar.br Federal University of Jequitinhonha and Mucuri Valleys (UFVJM), Diamantina, Brazil 3 Federal University of Par´ a (UFPA), Par´ a, Brazil [email protected] 4 The Open University, Milton Keynes, UK {helen.sharp,leonor.barroca}@open.ac.uk
Abstract. Customer-centric strategies can help startups move towards successful and sustainable businesses. User eXperience (UX) has been considered a critical factor in creating value for the customers and users of startups. Software startups often collect data about the experience with the product from users. However, obtaining valuable insights to improve the UX from customer and user information can be challenging for startup professionals. In this paper, we present a multiple-case study conducted with Brazilian software startups in which we investigated how these companies deal with customer and user information. To collect data, we conducted semi-structured interviews and retrospective meetings with 28 professionals from the four startups. We found that the startups still need to improve their strategies to leverage customer and user information insights for continuous product improvement, including improving communication channels and adopting metrics to assess customer value creation and product success. As a result, this study can motivate startup professionals to reflect on the most efficient practices for collecting and managing UX information to improve their products and measure value creation. Keywords: Software startups · Customer-centric development experience · Customer feedback · Value creation · Case study
1
· User
Introduction
Nowadays, startups have drawn researchers’ attention from different fields due to their critical role in the global economy [5]. As the key drivers of economic growth, startups contribute to economic dynamism by intensifying market competition, entrepreneurial behavior, and strategy focused on technological innovation [18]. Startups are broadly defined as human institutions aiming to deliver c The Author(s), under exclusive license to Springer Nature Switzerland AG 2022 N. Carroll et al. (Eds.): ICSOB 2022, LNBIP 463, pp. 287–303, 2022. https://doi.org/10.1007/978-3-031-20706-8_20
288
J. Choma et al.
new products or services under extreme uncertainty [33]. Startups differ from established organizations in searching for a scalable, repeatable, and profitable business model [2]. Although startups operate in different areas, most are software producers or use software to manage their activities [6]. A startup should aim for growth by combining innovation, and market-driven development [22]. However, many startups go out of business even before reaching product-market fit [7]. Regardless of there is no consensus on the clear and distinct definition of a software startup [14], such companies are known for working under conditions of extreme uncertainty and suffering from a lack of resources [15]. Time pressure and no prior operating history are also challenging factors, especially when startups are dealing with disruptive technology [8,33]. Considering the challenges of innovation and market-driven development, understanding the customers and users is vital for software startups to reduce business risks [17]. Customer-centric activities such as getting to know the customer and creating solutions for their needs should contribute to value creation that can lead to business success [2,11]. However, startup teams struggle to engage users and leverage insightful customer information to improve their products and services [13,30]. Studies in this field revealed that feedback loops to customers are slow, and the process of gathering timely and continuous feedback is still challenging [29]. In the software startup context, researchers have tried to understand better the obstacles and challenges faced by startup professionals arguing the need for specific engineering practices [15,17]. Other studies have investigated customer and user-centered approaches by incorporating User Experience (UX) aspects to promote value creation for both customers and startup businesses [10,11]. Recently, Saad et al. [25] investigated UX work in software startups and found that startups have UX concerns related to user demands scarcely explored in the literature. For instance, they pointed out the following open questions: “How do startups gather user data even with a lack of resources?”; “How can UX work contribute to creating value?”; “How are informal UX practices related to the difficulty in engaging users?”; and “How can users’ data from different sources provide insightful information for product improvement?”. Taking into account the challenges and gaps mentioned above, in this study, we formulated the following research question: How do software startups deal with UX from customer and user information to improve their products? To answer this question, we qualitatively explored data collected from four Brazilian software startups at different maturity levels regarding the use of UX practices and methods. Unlike studies that investigate UX practices mainly in the early stages [8,9], we investigated startups with already stable products and an established customer base. By answering our question, we intended to identify software startups’ primary customer and user information sources, including the main touchpoints, communication channels, methods, and tools. In addition, we investigated the main issues software startup professionals face in collecting and using this information.
Towards Understanding How Software Startups Deal with UX
289
The contribution of this paper is to show four cases and describe what they do on the perceived UX issues from customer and user information. In addition to identifying the main touchpoints, we categorized the types of customer and user information available in the studied startups. This categorization can help startups grasp the focus of the information to decide which part of the UX design to use it. Furthermore, the results of this study can motivate software startup professionals to reflect on the most efficient practices for collecting and managing UX information to improve their products and measure value creation. The rest of the paper is organized as follows: Sect. 2 presents the background and related work about customer and user information and approaches to customer value creation. Then, Sect. 3 describes our research methodology, and Sect. 4 presents the study findings. After that, in Sect. 5, we discuss the results by answering the research question and pointing out the threats to study validity. Finally, we conclude the paper in Sect. 6.
2
Background and Related Work
Customer Development [2] and Lean Startup [22] are customer-centric approaches proposed to help software startups in new business development. Both approaches emphasize developing and experimenting with real customers and users by gathering feedback and gauging interest in the product from the inception phases [3]. By knowing the customers’ demands, startup professionals can achieve the product-market fit sooner, reducing the waste of time and resources [24]. The literature presents several methods for conducting continuous experimentation regarding the elicitation of qualitative and quantitative customer feedback – e.g., test A/B, analytics, landing pages, interviews, observation, prototyping, usage data, and support data [3,21]. Customer Experience (CX) and User Experience (UX) are other innovationdriven strategies for developing solutions focused on delivering a good user experience [27]. CX examines the whole customer journey and experiences across several systems, products, or services that a company offers across time [16]. UX involves designing the experience of a single interaction that a user has with a company to perform a task [20]. Despite dealing with different levels of interactions, both strategies put customers and users at the center of developing products and services to provide better experiences and value while increasing profits [27]. The customer journey can involve many touchpoints with the company. A customer touchpoint is any interaction point where companies and customers exchange information about their product, brand, business, or service using different channels [4]. These channels are where the interactions take place – e.g., phone, email, chat, social media, and website. Nowadays, customers interact with companies through countless touchpoints in multiple channels, resulting in more complex and difficult-to-manage customer journeys [12]. Based on customer interaction and feedback mechanisms observed in a multiple-case study, Sauvola et al. [29] introduced the ‘customer touchpoint model’ that provides an
290
J. Choma et al.
overall understanding of the customer touchpoints and feedback data collection. Additionally, the authors highlighted some challenges to customer-centric software development, such as (1) a lack of systematic ways to collect, analyze and incorporate customer data into the product development process; (2) indirect access to end-users; (3) a lack of understanding of the reasons behind customer requirements; and (4) a lack of continuous validation with customers. Value creation through UX practices has been pointed out as a differentiation strategy that can enable startups to minimize uncertainty, reach business value through differentiation, and expand and grow the customer base [10,11,32]. Customer value creation is the main reason startup professionals engage customers and users in the development process. However, few recognize that this is important to sustain the long-term business model as well [31]. While many user-centric approaches and methods are available to promote value creation, startups can face barriers to adopting them besides scarce resources, time pressure, and organizational culture [6,7]. Startup professionals also need to overcome issues related to the dispersion of customer and user information, lack of know-how in collecting and interpreting customer feedback and user data [11,31], and difficulty in identifying metrics to evaluate the customer value creation and product success [28].
3
Research Method
This study is part of a broader research project that explores how UX work has been applied in software startups. Acknowledging that UX includes “all aspects of the interaction between the end-user and the company, its services, and its products” [19], in this study, we report findings from empirical data on how startups deal with UX from customer and user information to improve their products. To achieve our research goal, we performed a multiple-case study following the guidelines recommended by Runeson and H¨ ost [23]. Case Selection and Description. Our study involved four software startups located in Brazil. According to Startup Genome’s report [5], Brazilian startups raised a record-setting $2.7 billion in the second quarter of 2021. The selected startups were more than five years old; their products were stable, their customer base was already established, and they had different maturity levels concerning UX work. For ethical reasons, the names of the products and companies are omitted. We refer to the startups as A, B, C, and D. A proposal for this study was previously reviewed and approved by the Ethics Committee in Brazil (CAAE: 29367020.0.0000.504) at the Federal University of S˜ ao Carlos. The study involved 28 startup professionals with different backgrounds and experiences. Table 1 presents an overview of the characteristics of startups and the roles of the participants. Our key contacts in each startup are underlined at the bottom of Table 1.
Towards Understanding How Software Startups Deal with UX
291
Table 1. Overview of startups characteristics and interviewees roles Startups ID
A
B
C
Domain
Education
e-Sport
IoT
D Logistic
Business Model
B2B
B2C
B2B
B2B2C
Foundation
2016
2015
2016
2013
# employees
80
70
11
800
# customers/users
250+ schools 180,000 users 30 companies 40,000 users
#participants in interviews 5
7
5
6
#participants in EBTR
5
6
6
–
Roles
P1 to P5
P6 to P16
P17 to P22
P23 to P28
Startup A: (P1) Technology Director; (P2) Customer Service; (P3) Full-stack Developer; (P4) Marketing; (P5) UI Designer. Startup B: (P6) Product Designer Manager; (P7) UX Designer-1; (P8) UX Designer-2; (P9) Front-end Developer; (P10) Product Designer-1; (P11) Product Designer-2; (P12) Product Designer-3; (P13) Product Designer-4; (P14) Social Media Analyst; (P15) Customer Experience (CX); (P16) Product Owner. Startup C: (P17) Chief Technology Officer (CTO)/Founder; (P18) Chief Executive Officer (CEO)/Founder; (P19) Costumer Success; (P20) Full Stack Developer1; (P21) Full Stack Developer-2; (P23) Geophonist (specialist in diagnosing noises) Startup D: (P24) Designer Director; (P25) Content Designer; (P25) Design Lead-1; (P26) Product Designer; (P27) UX Strategist; (P28) Design Lead-2
Data Collection. For methodological triangulation in data collection [23], we conducted semi-structured interviews and applied the evidence-based timeline retrospective (EBTR) method [1]. EBTR is a method based on the idea of agile retrospective meetings to support software teams to reflect on their experiences throughout a project [1]. Software teams typically organize retrospective meetings to improve their processes. All data collection activities were conducted online using Google Meet. At least two researchers participated in the interviews and EBTR meetings, leading the meetings and taking notes. We conducted individual interviews with 23 participants from startups A, B, C, and D (see Table 1). The interviews lasted from 30 to 96 min. During the interviews, we asked some semi-structured questions to obtain information on how UX work was performed in the startups under study. Some sample questions included: “How is your day-to-day work, and what roles do you play?”; “Can you give us some examples of work demands that come to you?”; “What is the work process you follow?”; “What artifacts and tools do you use in your work?”; “Which professionals do you interact with?”; “Have you participated in UX design activities?”; “Who are the professionals who have contact with customers and users?”; “Do you have any suggestions to improve UX work in the company?”. To complement the data collected in the interviews and clarify issues regarding UX work performed over time, we conducted 3 EBTR meetings involving 17 professionals from startups A, B, and C (see Table 1). The EBTR meetings lasted around two hours in each startup. Data Analysis. The data analyzed included approximately 23 h of transcripts from interviews and EBTR meetings, researchers’ notes, and information about
292
J. Choma et al.
the visual timelines and reflection boards produced during the EBTR meetings. We analyzed the data gathered following a qualitative approach based on open coding procedures with three rounds of refinement [26]. To explore the data for this study, we filtered codes related to existing touchpoints, communication channels with customers and users, type of information collected, methods and tools, and any activity involving customers and users. Additionally, we extracted statements from interviewees about issues related to collecting and using customer and user information.
4
Findings
This section presents findings for each startup related to customer and user information by exploring the existing channels, touchpoints, and how practitioners handle such information, including methods and tools. As mentioned, the findings of each startup are presented with quotes taken from the transcripts that related the participants to them (see in Table 1 the participants’ identification). We underline the main chunks of text that represent findings to answer our research question. Table 2 summarizes the main findings about customer and user information found in each studied startup. As shown in this table, in addition to identifying the main touchpoints, channels, methods, and tools, we identified different customer and user information. To support our analysis, we categorized the identified customer and user information into four types, i.e., demands, feedback, usage data, and user profile, which we describe as follows: – Demands refers to user requests involving bug and incident reporting, issues impacting users’ experience, and suggestions for new features. – Feedback refers to formal or informal information collected about reactions to a product or users’ performance when performing a task, user requirements, and needs which are used as a basis for improving the product or service. – Usage data refers to data on usage and user interaction with the product that can be automatically collected using, for example, experiments such A/B tests, analytics, and leading pages. – User profile refers to actual customer and user behavior data, including demographic characteristics collected through different techniques, such as surveys, personas, and brand personas. Startup A. At startup A, we carried out interviews and an EBTR meeting involving five professionals from the technology, customer service, and marketing areas. The tech team, in particular, is small (approx. 10), and they did not have UX experts when we collected data. The startup’s business model is mostly Business to Business (B2B). Operating in the education and robotics market segment, startup As customers are mainly preschools, elementary, and high schools. Initially, they did not have direct contact with students, only with the school managers and teachers. However, due to the COVID-19 pandemic, they quickly adapted their products, to have contact with parents and students.
Towards Understanding How Software Startups Deal with UX
293
Table 2. Summarizing findings about customer and user information. ID Touchpoints, channels, methods and tools
Issues about customer and user information
A Touchpoints: customers’ loyalty team, marketing team, pedagogical team, sales team. Channels: email, messaging app, visit to the customer. Methods and tools: ticketing system, surveys, interviews, market studies, prototypes, log file analysis, and customer service indicators.
I1 - Startup professionals collect the number of accesses and control users’ requests but the measurements are not done systematically. I2 - Although professionals use service indicators to improve their products, they often do not perform evaluations and testing with real users.
B Touchpoints: CX team, marketing team, product and UX team. Channels: chat, email, and social media (e.g., Discord, Twitter, Facebook, Instagram, and YouTube), community channel. Methods and tools: ticketing system, automated measurements, brand personas, marketing tools, surveys, interviews, prototypes, empathy maps, personas, and usability testing.
I3 - Startup professionals collect some metrics of business but still do not take automated measurements focused on continuous product improvement or quality of user experience. I4 - They receive a lot of customer feedback from social media platforms, however, the technology team still struggles to leverage insightful information from these platforms to improve their products.
C Touchpoints: customer success and founders (marketing and sales). Channels: calls, messaging app, and visit to the customer. Methods and tools: ticketing system, informal interviews (e.g., having coffee with the customer), and prototypes.
I5 - Startup professionals struggle to identify needs that meet and please as many users as possible. I6 - They recognize the need for mechanisms to monitor user data, manage their tasks, and implement a product improvement roadmap. I7 - They conduct unstructured customer interviews and develop prototypes on an ad hoc basis to gather requirements or validate ideas.
D Touchpoints: marketing, sales, CX, product design teams (e.g., UX strategists, product designers, and brand designers). Channels: customer service calls, messaging app, and visit to the customer and users. Methods and tools: ticketing system, interviews, surveys, user testing, dashboard with metrics and indicators, user data collected automatically from experiments like A/B tests, and user behavior data using HotJar tool.
I8 - Design professionals argued that the collect of feedback need to be improved. I9 - To improve their contact with customers and users, they are mapping all touchpoints and improving their communication channels. I10 - Not all product teams collect information about user behavior.
This contact is mostly through the customer service team, also known as the customers’ loyalty team. As a result, they had to enhance the customer service structure to support a large number of users’ demands: “Now, we are assisting the parents of the students, which has become a very high demand” (P2). At the time of the interviews, users’ requests, feedback, and complaints were formalized via email and registered in a ticketing system that facilitated the management and followup of open issues forwarded to the teams responsible for resolving them. They also implemented online support for schools via a messaging app. Thus, the customer service sector is the primary touchpoint of customers and users (i.e., students and school staff) with the company, providing support for problems or questions related to the startup’s software platform. Often, the customer service sector engages with users’ pain points by forwarding their suggestions and ideas to developers for product improvement: “People who usually give us these
294
J. Choma et al.
tips are the customer service team because they receive calls and questions [from users] that become a pain for them... so they talk to us ‘ah, it would be great to have this feature”’ (P3). Consequently, many improvements have been implemented by direct user suggestion or were identified through customer service indicators through which the team detects potential problems to be checked by the technology team. Sometimes, the technology team needs to analyze the log files to understand the usage issues (e.g., difficulty logging into the platform), so these customer service indicators are a basis for knowing what really needs to be improved; however, these indicators are used informally. For instance, the customer service team usually collects the number of user accesses and controls so-called problems, but the measurements are not done systematically. The marketing team is another touchpoint with customers and users. In their market studies, they usually collect customer information using surveys and interviews to understand the profile of the target audience and explore content presentation strategies, for instance. Furthermore, the startup has a pedagogical team (domain experts) who has close contact with the school staff to discuss educational content and understand their needs through periodic visits. Generally, the sales team sells the product a year before it is released: “We design [the products] using wireframes [...] we discuss internally [to define] the best flow, and work on the visual identity using high fidelity prototypes [...], then we validate it with pedagogical advisors from at least two schools [...], and our salesperson sells [the product] by presenting the high-fidelity prototype [to schools]” (P1). The development team rarely tests with end users. Most validations and tests are done internally, mainly with the pedagogical team that uploads the educational content to the platform they develop. However, they recognize user research’s importance to ground their design decisions better: “We could have avoided many troubles, but here the idea is born, we work on the idea, throw it to the market, and then get the feedback” (P4). Startup B. At startup B, interviews and the EBTR meeting involved eleven professionals from the technology, design, marketing, and CX teams (see Table 1). The startup’s business model is Business to Customers (B2C). The startup has a large active users-base (around 180,000 active players). The users are professionals and amateur players of electronic sports using video games. There are two types of players, those who pay to play and those who play using free accounts. The main touchpoint of users with the company is the CX team, which has a team of seven professionals. The CX team can receive as many as 33,000 requests in a day. Most user demands refer to incident reporting, charge-back of payments, and complaints about players’ toxic behavior. These demands arrive through different channels (e.g., chat, email, and social media). The user requests are registered on the help-desk platform through tickets that allow tag classification. Much users’ information is also collected in an automated way to verify, for example, the number of games played in the month, the number of active users, and subscription payments. However, they still do not take automated measurements focused on continuous product improvement or quality of user experience.
Towards Understanding How Software Startups Deal with UX
295
In addition, the CX team receives a lot of user feedback through social media channels (e.g., Discord, Twitter, Facebook). Regarding the amount of feedback received: “We receive a lot of feedback, but not all of them make sense because sometimes that [feature] is right and the user does not know how to use it [the platform]” (P15). Interestingly, the users’ feedback commonly stored in a single repository is rarely accessed: “We have a channel called ‘Community’, we put it [users’ feedback information] there, but we don’t know if this is being seen or not, it’s more a repository.” (P14). However, the technology team still struggles to leverage insightful information from these platforms: “Currently, we don’t have this [feedback] centralized, this is one of the most difficult processes to track because there are many channels, you have to check it on Twitter, on Discord, and verify if someone talked with the player throughout the championship into Discord support [channel]... So, there is a chance to lose some [relevant] information, and our idea is to find a way to centralize all that [users’ feedback]” (P16). The marketing team is also an important touchpoint with users, where a social media analyst (P14) monitors social networks (e.g., Facebook, Twitter, Instagram, and YouTube) and uses brand personas to target their marketing campaigns. The marketing team has easy contact with users: “UX designers think it’s nice to talk to me [because] I can engage people inside Discord to answer their surveys” (P14). By using marketing tools (e.g., push mechanisms and modals), they can easily notify and engage users for surveys elaborated by the UX team. The UX team has two UX experts focused on research, design, and evaluation activities involving users. They have already applied several UX techniques for information gathering and understanding user needs (e.g., brainstorming ideas, mind-maps, flowcharts, sketches, prototypes, empathy maps, personas, and usability testing.). However, surveys and interviews are the most common techniques used to gather feedback from users: “[...] within the competition team, they didn’t really know what we were going to do [...] there was much more doubt than certainty and many assumptions. So, I sat down with the PO and said ‘why not do a survey with the LOL players’. And then, he and I drafted some questions [and] asked the marketing team to help us to publish [the survey] on Twitter [...] We took the opportunity to understand what they [users] expected from our platform [...] we received 3,000 responses which opened our eyes, gave the team a great insight [that] was a big difference for the squad” (P8). The UX team uses information collected from users to inform their design decisions that are shared with the development team, who do not have direct contact with users. The teams’ activities (e.g., technology, design, marketing) are driven by OKRs (Objective Key Results) centered on what the company wants to achieve (e.g., increasing competition in games and making it possible to play championships). Based on these goals, UX designers use informa-
296
J. Choma et al.
tion from users to create prototypes that should guide product development and prioritize their tasks. Startup C. Startup C is a small company with 11 employees (9 developers, 1 customer success, and 1 domain specialist). The two founders have positions in the commercial and technical areas. The startup develops B2B products based on hardware and software for public and private water and gas companies. At the time of the interviews, they had 30 active contracts with different companies. The founder/CEO who works in the commercial area (P18) and the professional in the customer success area (P19) is the main touchpoints of customers with the company. The commercial contact is mainly with the company’s managers for contract negotiation and gathering of requirements, while Customer Success (CS) interacts with professionals who use their product in the field by providing product support. Through close contact with users from operational sectors, the CS person collects a lot of feedback and suggestions for product improvement, which are reported to the startup’s CEO and CTO: “I collect feedback with them, so I have notes, I have a list of [improvement suggestions], some of them are even simple to implement that make a difference, for example, the [option of ] deleting a sample that someone collected, which previously could not be deleted.” (P19). Although they seek to understand the difficulties of the clients, a concern is to discern between individual and collective needs: “Because sometimes a customer is very keen on one thing, but only he is keen on that thing, so we need to talk among ourselves to understand which needs should go into production as soon as possible, or not.” (P18). To manage customer demands, they use a ticket system that allows followup by service indicators. Due to a lack of resources, the startup does not have UX experts. However, they informally interview their customers to understand their needs and develop prototypes to validate ideas with them. New features are usually tested internally with the domain expert and customer success person who is more familiar with the users’ needs. Nevertheless, they recognize the need to have mechanisms to monitor user data as well as to enhance the management and prioritization of tasks for implementing product improvements: “We need to create a process to facilitate what we commented earlier regarding improving the requirements gathering and the prioritization of [users’] demands” (P18). Startup D. Startup D develops applications in the logistics and urban mobility market in the B2B2C (Business to Business to Consumer) model by connecting shippers and couriers of goods and documents. The startup’s customers range from large companies such as e-commerce retailers to small merchants; and deliveries are made to consumers, which include individuals or companies. This startup has a high rate of business growth, in fact, it is regarded as a unicorn. It invests in developing its leaders, which includes hiring and training qualified teams in different areas. We interviewed six professionals from the design area.
Towards Understanding How Software Startups Deal with UX
297
At that time, the design team had around 34 professionals, and open positions to hire more design experts. The company has several touchpoints with customers and users, such as marketing, sales, CX, and product design teams. In the design team, in particular, the main touchpoints are UX strategists, product designers, and brand designers. UX strategists work on discovery activities and exploratory research, conducting interviews to investigate user needs and exploratory data analysis to understand market segments. The product designers have contact with the customers who already use their products (i.e., Delivery App and Shipper App). Moreover, brand designers have UX knowledge, working on the company’s website design and with the social media audience focused on brand positioning. The product design team collaborates closely with CX team to resolve user requests. The CX team uses the ticketing system to manage customer demands ranging from bug reports to providing feedback and suggestions for product improvements. The concern for customers extends to all the company’s services and products: “This is a customer-centric company, where everything we do has a clear and direct impact on the consumer, so all money invested is reverted into a positive impact on the life of our customers” (P24). However, they recognize the need to improve their feedback collection: “We need to listen to the customer, gather more feedback, and match with the company’s business strategy, because I believe this will help us not only to further evolve the product but lead to less pain for those who currently use it, so I see that this is a point that we urgently need to look at.” (P26). At the time of the interviews, representatives from the designers, CX, marketing, and sales teams were working together on an initiative called ‘Customer Voice’ with the aim of mapping all touchpoints and improving communication channels with customers and users: “[...] there is a lot of information lost by the company, as many people talk to the customer, we end up not organizing all this feedback, so we are trying to make it closer” (P25). UX strategists have direct contact with users: “The good part of my work is doing research and going out in the field to talk with our audience who uses the product all the time [...], talking to them we generate a perception of who are these people and how they are using [the system]” (P27). In addition to activities that directly involve users (e.g., interviews, surveys, and user testing), the design team professionals use user data collected automatically, mainly through experiments carried out together with the data team. Experiments are performed (1) to validate a new feature ready to go into production with a specific group of users, (2) to evaluate a validated feature with another group of users, and (3) to optimize existing features. The data team also creates dashboards using metrics and indicators that are requested by the designer team to deeply investigate emergent issues (e.g., a high loss rate of packages). Moreover, product designers leverage user behavior data collected with the HotJar1 tool to inform their design decisions: “I particularly like to analyze how customers have used some components that we have been working on within our 1
https://www.hotjar.com/.
298
J. Choma et al.
platform [...] this has helped us understand [for example] how they use the search component and, if they use it [...] to try slightly improve search performance” (P27).
5 5.1
Discussion How Do Software Startups Deal with UX from Customer and User Information to Improve Their Products?
As aforementioned, we categorized the customer and user information as demands, feedback, usage data, and user profile (see Sect. 4). When analyzing our findings, we found that many users’ demands come through support service channels (e.g., emails, calls, chats, and social media). User demands range from bug reports and usability issues to requests for new features. Regarding touchpoints, all startups, regardless of size, have a customer service structure under different names, for example, customers’ loyalty (in startup A), customer experience (in startups C and D), and customer success (in startup C). In all studied cases, the primary touchpoint with the customer and users is the customer service teams. This type of contact from customer-to-company makes startups more reactive when responding to customer and user demands. Customer and user feedback is collected for different purposes. Marketing and sales teams collect feedback primarily for market studies, customer satisfaction surveys, and customer requirements elicitation. Customer service teams receive feedback from users, especially on product defects and suggestions for new features. When the startup has UX experts (e.g., startups B and D), the collection of feedback and user research is mainly carried out with interviews and surveys in a more structured way during product discovery activities. Startups that do not have a UX team (e.g., startups A and C) conduct informal interviews with users in an ad-hoc manner, mainly to validate ideas. As the startup grows, acquires financial resources, and hires more people (e.g., startups B and D), professionals are more likely to efficiently explore user data collected automatically, such as from experimentation with A/B testing, analytics, and log files. Usage data is collected and analyzed primarily to validate new features and discover points for improvement. The collection of user profiles using brand personas is mainly conducted by the marketing team to direct marketing campaigns and define content strategy. A lack of systematic ways to collect, analyze, and incorporate customer data into the product development process is an issue reported in the literature [29]. In our study, we also encountered this issue mainly with startups with fewer resources and a lack of UX experts, i.e., startups A and C. In more mature startups in terms of UX work (i.e., startup D), we found that collecting and incorporating customer and user information in the product development process is more common. In addition, they use experiments with customers for continuous of new features and optimization of in-use features. Even so, professionals from startup D reported the need to improve communication channels with the
Towards Understanding How Software Startups Deal with UX
299
customers and users (e.g., the Customer Voice program) and increase the user research activities to provide insights for continuous product improvement. The customer service teams are the main touchpoints with customers and users of the startups. Especially startups with a large base of users can receive hundreds to thousands of requests daily. These startups also reported issues related to the dispersion of customer and user information, as mentioned in the literature [11,31]. In startup B, for example, they cannot take advantage of user data that is scattered across different communication channels with users. On the other hand, in startup D, which has more resources, a team specializing in data analysis supports UX professionals in exploring data from CX to understand user demands. Regarding the difficulty of identifying metrics for evaluating customer value and product success [28], we found that this issue also extends to almost all the startups studied. In startups A, B, and C, professionals informally use customer service indicators to guide their actions for product improvement. However, most measurements are restricted to business metrics. For instance, Startup B’s professionals still do not collect metrics focused on product or UX quality, as at startup D. A product designer at startup D told us that they usually collect data and analyze user behavior to measure the UX improvements and customer value. Conversely, this practice seems to be a particular need for some professionals of this startup, not always adopted by other teams. 5.2
Threats to Validity
We discuss the study validity with internal validity, construct validity, external validity, and reliability as proposed by Runeson and H¨ ost [23]. For internal validity, to increase the precision of our study, we have adopted a methodological triangulation in data collection using two different methods (i.e., interviews and EBTR meetings). Moreover, this study involved various professionals from each startup with different backgrounds and expertise to gain different perspectives. For construct validity, at least two researchers participated in preparing the interview scripts, the data collection sessions, and the transcription of the video recordings. The data analysis was conducted incrementally with the participation of all the authors in different steps. All authors intensively discussed the results at all stages. For external validity, the data collected on four startup contexts allowed us to obtain a degree of abstraction about the common UX issues for distinct scenarios. However, we understand that there are contextual factors of startups that can affect our study. We do not rule out the need to conduct the same case study on other startups in future work. For reliability, more than one researcher conducted data analysis at each stage. We recorded the data collection on video; however, all data were transcribed to text, thus avoiding different interpretations for the researchers involved in creating and refining the codes.
300
6
J. Choma et al.
Conclusions and Future Work
In addition to identifying the main touchpoints, this study contributes by classifying the types of customer and user information available in the studied startups. We found that the primary touchpoint of customers and users with the companies studied is the customer service area (i.e., CX, customer success, or customer loyalty). B2C startups generally have a large customer base and receive much user feedback and demands through several different channels (e.g., emails, chats, and social media). Next, we summarize the lessons learned about our findings according to characteristics related to the UX work carried out in the studied startups by answering the research question about how software startups deal with UX from customer and user information to improve their products: – In startups where UX work is performed in an ad-hoc manner and without the support of UX experts (i.e., startups A and C), professionals handle customer and user information reactively. Often, startup professionals improve their products on demand of customers and users, i.e., by responding to users’ complaints and needs that arrive from the customer service area. UX issues are usually caught after features launch, as they are not user-tested throughout development. In these contexts, UX-related issues gleaned from actual users or informed by usage data are not part of the product development and improvement roadmap. – In the startup where UX work was recently incorporated into product development with the support of UX experts (i.e., startup B), customer and user information is leveraged reactively and proactively for product improvement. However, the UX team is small, and these professionals need the collaboration of professionals from different areas to participate in UX design activities and to promote user engagement in their research. In addition, practitioners recognize the need to better leverage user information for product improvement, including defining UX metrics to support their decisions. Nevertheless, multiple touchpoints with users and unstructured information spread across different channels hampered identifying valuable insights and main points for improvement. – In the startup where UX work is already institutionalized and its value is widely recognized (i.e., startup D), customer and user information is better leveraged to understand market segments and user behaviour to propose new features and understand user pains to improve their interaction with the product. The product and design team is large and has various UX experts. The UX work is expanding to collaborate with other areas in the company through the voice of the customer program, seeking to identify all touchpoints to improve communication with customers and users. The results of this study can motivate software startups to reflect on how they collect and manage UX information. By knowing how to deal with this information, startup professionals will be able to use it more efficiently to improve the UX of their products by focusing on delivering customer value and product suc-
Towards Understanding How Software Startups Deal with UX
301
cess. Future work may investigate effective mechanisms to measure the customer and user value achieved through UX work. Acknowledgments. We thank all study participants and financial support of the grants #2020/00615-9 and #2020/10429-8, S˜ ao Paulo Research Foundation (FAPESP), and the support of the Conselho Nacional de Desenvolvimento Cient´ıfico e Tecnol´ ogico (CNPq - Brazil), process number: 313312/2019-2.
References 1. Bjarnason, E., Hess, A., Svensson, R.B., Regnell, B., Doerr, J.: Reflecting on evidence-based timelines. IEEE softw. 31(4), 37–43 (2014) 2. Blank, S.: The Four Steps to the Epiphany: Successful Strategies for Products that Win. John Wiley & Sons, Hoboken (2020) 3. Bosch, J., Holmstr¨ om Olsson, H., Bj¨ ork, J., Ljungblad, J.: The early stage software startup development model: a framework for operationalizing lean principles in software startups. In: Fitzgerald, B., Conboy, K., Power, K., Valerdi, R., Morgan, L., Stol, K.-J. (eds.) LESS 2013. LNBIP, vol. 167, pp. 1–15. Springer, Heidelberg (2013). https://doi.org/10.1007/978-3-642-44930-7 1 4. Foundation, I.D.: Customer touchpoints - the point of interaction between brands, businesses, products and customers. https://www.interaction-design.org/ literature/article/customer-touchpoints-the-point-of-interaction-between-brandsbusinesses-products-and-customers. Accessed 08 June 2022 5. Gauthier, J., Penzel, M., Kuester, S., Kumaran, M.: The global startup ecosystem report 2021. Technical report, Startup Genome (2021) 6. Giardino, C., Unterkalmsteiner, M., Paternoster, N., Gorschek, T., Abrahamsson, P.: What do we know about software development in startups? IEEE Softw. 31(5), 28–32 (2014) 7. Giardino, C., Wang, X., Abrahamsson, P.: Why early-stage software startups fail: a behavioral framework. In: Lassenius, C., Smolander, K. (eds.) ICSOB 2014. LNBIP, vol. 182, pp. 27–41. Springer, Cham (2014). https://doi.org/10.1007/978-3-31908738-2 3 8. Guerino, G.C., Dias, N.S.B.C., Chanin, R., Prikladnicki, R., Balancieri, R., Leal, G.C.L.: User experience practices in early-stage software startups - an exploratory study. In: Wang, X., Martini, A., Nguyen-Duc, A., Stray, V. (eds.) ICSOB 2021. LNBIP, vol. 434, pp. 122–136. Springer, Cham (2021). https://doi.org/10.1007/ 978-3-030-91983-2 10 9. Hokkanen, L., Kuusinen, K., V¨ aa ¨n¨ anen, K.: Early product design in startups: towards a UX strategy. In: Abrahamsson, P., Corral, L., Oivo, M., Russo, B. (eds.) PROFES 2015. LNCS, vol. 9459, pp. 217–224. Springer, Cham (2015). https:// doi.org/10.1007/978-3-319-26844-6 16 10. Hokkanen, L., Kuusinen, K., V¨ aa ¨n¨ anen, K.: Minimum viable user experience: a framework for supporting product design in startups. In: Sharp, H., Hall, T. (eds.) XP 2016. LNBIP, vol. 251, pp. 66–78. Springer, Cham (2016). https://doi.org/10. 1007/978-3-319-33515-5 6 11. Hokkanen, L., Xu, Y., V¨ aa ¨n¨ anen, K.: Focusing on user experience and business models in startups: Investigation of two-dimensional value creation. In: Proceedings of the 20th International Academic Mindtrek Conference, pp. 59–67. AcademicMindtrek’16, ACM, New York, NY, USA (2016)
302
J. Choma et al.
12. Holmlund, M., et al.: Customer experience management in the age of big data analytics: a strategic framework. J. Bus. Res. 116, 356–365 (2020) 13. Karvonen, T., et al.: Hitting the target: practices for moving toward innovation experiment systems. In: Fernandes, J.M., Machado, R.J., Wnuk, K. (eds.) ICSOB 2015. LNBIP, vol. 210, pp. 117–131. Springer, Cham (2015). https://doi.org/10. 1007/978-3-319-19593-3 10 14. Klotins, E.: Software start-ups through an empirical lens: are start-ups snowflakes? In: Workshop on Software-Intensive Business: Start-Ups, Ecosystems and Platforms, SiBW 2018, Espoo, Finland, 3 December 2018. CEUR-WS (2018) 15. Klotins, E., Unterkalmsteiner, M., Gorschek, T.: Software engineering in start-up companies: An analysis of 88 experience reports. Empirical Softw. Eng. 24(1), 68–102 (2018). https://doi.org/10.1007/s10664-018-9620-y 16. Lemon, K.N., Verhoef, P.C.: Understanding customer experience throughout the customer journey. J. Mark. 80(6), 69–96 (2016) 17. Melegati, J., Chanin, R., Sales, A., Prikladnicki, R.: Towards specific software engineering practices for early-stage startups. In: Paasivaara, M., Kruchten, P. (eds.) XP 2020. LNBIP, vol. 396, pp. 18–22. Springer, Cham (2020). https://doi. org/10.1007/978-3-030-58858-8 2 18. Nguven-Duc, A., Dahle, Y., Steinert, M., Abrahamsson, P.: Towards understanding startup product development as effectual entrepreneurial behaviors. In: Felderer, M., M´endez Fern´ andez, D., Turhan, B., Kalinowski, M., Sarro, F., Winkler, D. (eds.) PROFES 2017. LNCS, vol. 10611, pp. 265–279. Springer, Cham (2017). https://doi.org/10.1007/978-3-319-69926-4 19 19. Norman, D., Nielsen, J.: The definition of user experience (UX). https://www. nngroup.com/. Accessed 30 Sep 2019 20. Norman, D., Nielsen, J.: User experience vs. customer experience: What’s the difference? https://www.nngroup.com/articles/ux-vs-cx/. Accessed 30 May 2022 21. Olsson, H.H., Bosch, J.: Towards continuous customer validation: a conceptual model for combining qualitative customer feedback with quantitative customer observation. In: Fernandes, J.M., Machado, R.J., Wnuk, K. (eds.) ICSOB 2015. LNBIP, vol. 210, pp. 154–166. Springer, Cham (2015). https://doi.org/10.1007/ 978-3-319-19593-3 13 22. Ries, E.: The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. Currency, Redfern (2011) 23. Runeson, P., H¨ ost, M.: Guidelines for conducting and reporting case study research in software engineering. Empir. Softw. Eng. 14(2), 131–164 (2009). https://doi. org/10.1007/s10664-008-9102-8 24. Rutitis, D., Volkova, T.: The rise and fall of a database-as-a-service latvian unicorn. In: Nguyen-Duc, A., M¨ unch, J., Prikladnicki, R., Wang, X., Abrahamsson, P. (eds.) Fundamentals of Software Startups, pp. 299–312. Springer, Cham (2020). https:// doi.org/10.1007/978-3-030-35983-6 18 25. Saad, J., Martinelli, S., Machado, L.S., de Souza, C.R., Alvaro, A., Zaina, L.: Ux work in software startups: a thematic analysis of the literature. Inf. Softw. Technol. 140, 106688 (2021) 26. Salda˜ na, J.: The Coding Manual for Qualitative Researchers, pp. 1–440 (2021) 27. van de Sand, F., Frison, A.-K., Zotz, P., Riener, A., Holl, K.: The intersection of user experience (UX), customer experience (CX), and brand experience (BX). In: User Experience Is Brand Experience. MP, pp. 71–93. Springer, Cham (2020). https://doi.org/10.1007/978-3-030-29868-5 5
Towards Understanding How Software Startups Deal with UX
303
28. Sauvola, T., Kelanti, M., Hyysalo, J., Kuvaja, P., Liukkunen, K.: Continuous improvement and validation with customer touchpoint model in software development. In: Proceedings of the 13th International Conference on Software Engineering Advances-ICSEA, vol. 18, p. 62 (2018) 29. Sauvola, T., et al.: Towards customer-centric software development: a multiple-case study. In: 2015 41st Euromicro Conference on Software Engineering and Advanced Applications, pp. 9–17. IEEE (2015) 30. Sepp¨ anen, P., Tripathi, N., Oivo, M., Liukkunen, K.: How are product ideas validated? In: Ojala, A., Holmstr¨ om Olsson, H., Werder, K. (eds.) ICSOB 2017. LNBIP, vol. 304, pp. 3–17. Springer, Cham (2017). https://doi.org/10.1007/9783-319-69191-6 1 31. Silveira, S.A.M., Choma, J., Pereira, R., Guerra, E.M., Zaina, L.A.M.: UX work in software start-ups: challenges from the current state of practice. In: Gregory, P., Lassenius, C., Wang, X., Kruchten, P. (eds.) XP 2021. LNBIP, vol. 419, pp. 19–35. Springer, Cham (2021). https://doi.org/10.1007/978-3-030-78098-2 2 32. Sirotkin, A., McCabe, B.: The new experience for business: why user experience is the differentiation strategy in the cloud context. In: Marcus, A. (ed.) DUXU 2011. LNCS, vol. 6769, pp. 491–499. Springer, Heidelberg (2011). https://doi.org/ 10.1007/978-3-642-21675-6 57 33. Sutton, S.: The role of process in software start-up. IEEE Softw. 17(4), 33–39 (2000)
The Evolution of Software Startup Research: A Survey of Literature Karl Hansen1(B) , Admir Osmanovic1 , Benjamin Klerens1 , and Henry Edison2 1 2
University of Southern Denmark, Odense, Denmark {karlh18,adosm10,bekle18}@student.sdu.dk Blekinge Institute of Technology, Karlskrona, Sweden [email protected]
Abstract. The software startup research area has grown rapidly in the recent years. It is widely known that building software startups are challenging endeavors, and the failure rate is high. However, the fascinating phenomenon keeps getting interest from academics to address those challenges, due to the potential of software startups as an effective way for disruptive innovation. The aim of this study is to provide an update on the evolution of the software startup research area through a systematic mapping study. Our contributions are two-fold. First, we provide a mapping of current research in software startups in terms of contributing disciplines and research methods and theories used. The second contribution is the identification of two new and emerging research streams termed Software Startup Education and Ethics in Software Startups. Furthermore, the findings allow us to update the research agenda and provide new examples of research questions to advance the software startup research area. Keywords: Software startups mapping study
1
· Software startup research · Systematic
Introduction
The potential of software startups has been widely acknowledged as one of the effective ways for disruptive innovation. Even though software startups are inexperienced, young, and immature, their innovative products and services are putting well-established market leaders under pressure [18]. Software startups are “organizations looking for a repeatable and scalable business model for an innovative product or service they develop where software represents a core element” [11]. Software startups offer new products, new business models, and new business value at high speed with cutting edge technology, e.g., Internet of Things (IoT), Artificial Intelligence (AI), Block-Chain, etc. However, despite the success of well-known startups such as Uber, WhatsApp, Airbnb, the failure rate of software startups remain alarmingly high. A recent report in 2019 revealed that only one in twelve startups succeed [7]. This phenomenon has caught the attention of researchers from multiple disciplines [22] to discover obstacles to be minimised, and opportunities to leverage the success of software startups. c The Author(s), under exclusive license to Springer Nature Switzerland AG 2022 N. Carroll et al. (Eds.): ICSOB 2022, LNBIP 463, pp. 304–319, 2022. https://doi.org/10.1007/978-3-031-20706-8_21
The Evolution of Software Startup Research: A Survey of Literature
305
While the earliest scientific publication on software startups can be traced back to the year 2000 [18], it was not until 2016 when software engineering academics attempted to establish software startup as a research area [19]. Some literature reviews on software startup research have been reported [3,9,12,22]. The reviews indicate a rise of software startup research that reflects its significance in today’s modern economy. There has been observed an increased acceptance of software startup research as one of the research interests in leading software engineering and information systems conferences, e.g., XP, PROFES, ICSOB, ICIS, etc. Given the rapid growth in software startup research, we are interested in updating how the software startup research area evolves over time. The most recent literature review on software startups was carried out by Wang in 2019 [22], reviewing a total of 133 studies indexed by Scopus from 1994 to 2019 examining the contributing disciplines. The paper by Wang [22] served as an inspiration for this paper, but we chose to (i) incorporate different terms for software startups into the search string, (ii) use two new digital libraries i.e., Clarivate Web of Science (WoS) and Association for Information Systems e-Library (AIS), (iii) and address new research questions not covered in earlier research. A revisit on these areas can potentially reveal how software startup research has evolved over the past years. To achieve our research objective, we formulated the following research questions: – RQ1 - What are the contributing disciplines in software startup research? – RQ2 - What research methods and theories are used in software startup research? – RQ3 - What are the past, present, and emerging topics in software startup research? To answer our research questions, we employed a Systematic Mapping Study (SMS). The purpose of a SMS is to structure a research area by examining existing literature for the nature, scope, and number of primary studies [13]. SMS provides a broader view of wide and often poorly defined research areas, and has therefore been considered more appropriate and beneficial for this study. The contributions of this paper are two-fold. The first contribution is to provide a mapping of current research in software startups area in terms of contributing disciplines and research methods and theories used. The second contribution is the identification of new and emerging research topics, which may allow us to update the research agenda to advance the software startup research area [19]. The remainder of this paper is organised as follows. Section 2 describes the related work in terms of the relevant studies for this paper. The research methodology is described in Sect. 3. Section 4 outlines the findings, followed by a discussion of the obtained results in Sect. 5. Finally, Sect. 6 concludes the overall study.
306
2
K. Hansen et al.
Related Work
To find relevant literature reviews, we run a series of searches in the Web of Science (WoS) digital library. We used different combination of terms for the search strings such as “software startup” AND “systematic mapping”. Following the identification of a relevant publication, the related work section was examined to find more related publications. We identified four literature reviews [3,9,12,22] that are relevant. A summary of the related work is presented in Table 1. Table 1. Overview of relevant literature reviews. Facet
Paternoster et al. (2014)
Klotins et al. (2015)
Berg et al. (2018)
Wang (2019)
Objective
“... aims to structure and analyze the literature on software development in startup companies, determining thereby the potential for technology transfer and identifying software development work practices reported by practitioners and researchers.”
“... identifies and categorises software engineering knowledge areas utilised in startups to map out the state-of-art, identifying gaps for further research.”
“... with a focus on engineering perspective, this study aims at identifying the change in focus of research area and thematic concepts operating startup research.”
“... the evolution of the software startup research field is inspected in this paper through an examination of the scientific publications and contributing disciplines.”
Total primary studies
43
14
74
133
Research Method
Systematic Mapping Study Systematic Mapping Study
Systematic Mapping Study
Bibliometric Analysis
Data Source
Inspec/Compendex, IEEE Xplore, Scopus, Clarivate Web of Science, ACM Digital Library, Google Scholar
Scopus, Scopus Clarivate Web of Science, Engineering Village Compendex
Google Scholar
The first SMS on software startup research appeared in 2014 [12] by Paternoster et al. to review state-of-art research in software startups. A year later Klotins et al. [9] conducted a SMS to identify the gaps for future research into software startups by categorising the software engineering knowledge areas utilised in the software startups. The SMS by Paternoster et al. [12] received a lot of citations, and inspired Berg et al. [3] to conduct a SMS in 2018 to identify how engineering activities in software startups have changed over time, and identify potential research gaps. In contrast to the two previous SMS [9,12], Berg et al. attempted to synthesize startup descriptions in research and its associated knowledge areas of software engineering [3]. The review by Wang [22] focused on the evolution of software startup research area through an examination of the scientific publications and contributing disciplines. Even though these studies are focusing on software startup literature, Table 1 highlights the variety of paper counts used in the existing literature reviews
The Evolution of Software Startup Research: A Survey of Literature
307
(i.e. 43/14/74/133). A reason could be because of the combination of the digital libraries used. For example, the coverage of the digital libraries used in the reviews vary. Furthermore, each review has different selection criteria. For example, the study by Paternoster et al. [12] included papers that presented a contribution (i.e in the form of an experience report, applied engineering practices, development models, or lessons learned). The level of maturity in the software startup research area may also play a role, as indicated by the later literature reviews greater quantity of papers. The review protocol used by Paternoster et al. [12], Klotins et al. [9], and Berg et al. [3] adhered to the mapping study guidelines in [13], while the study by Wang [22] used a research method designed by Coccia [5]. In terms of data sources, both reviews by Paternoster et al. [12] and Berg et al. [3] used multiple data sources, e.g. Compendex, Web of Science, Scopus, etc., while the reviews by Klotins et al. [9] and Wang [22] used only one data source.
3
Research Methodology
To address the research questions, a systematic mapping study [13] was conducted to provide an overview of the growing research area of software startups. 3.1
Search Process
To find relevant literature for the systematic mapping a search string was constructed to generate search results within the field to select and analyse. The generic search string is: “software startup” OR “internet startup” OR “digital startup” OR “web startup” OR “computer startup” OR “software entrepreneurship” OR “internet entrepreneurship” OR “digital entrepreneurship” OR “web entrepreneurship” OR “computer entrepreneurship” The search string was used on two digital libraries: WoS (as it also covers IEEE Xplore and ACM Digital Library) and AIS for information systems literature coverage. A total of 407 papers were identified using the search string, of which 370 were discovered in WoS, and 37 in AIS. 3.2
Selection Process
Duplicates discovered between the two digital libraries were removed. Then, a screening of the papers was carried out on the metadata level, in particular on the title, abstract and keywords. In this study we have established inclusion and exclusion criteria, as listed in Table 2. We are only interested in the primary studies, and therefore exclude the secondary and tertiary studies. Texts not written in English, missing abstracts, or we cannot access the resource through the university library portal are excluded from this study.
308
K. Hansen et al. Table 2. Inclusion and exclusion criteria. Inclusion criteria
Exclusion criteria
Peer reviewed full research papers, published in journal or conference
Non-research papers e.g., editorial, paper talk, review, workshop summary, book or research in progress
Studies related to software development in startups or software startup evolution
Studies on customers, community, or policy perspective on software startups
An research paper should have empirical work
Secondary and tertiary studies
Availability of full text written in English
Studies that did not have anything to do with software startups
Each paper was evaluated by all reviewers. Any disagreement or confusion was resolved in the present of the reviewers. Applying the selection criteria in Table 2, we excluded 291 papers from WoS and 21 from AIS. In total 95 primary studies were included for further analysis. 3.3
Categorisation
The objective of this study was to investigate the contributing disciplines, the research methods and theories employed, and the research topics covered in the software startup research area. As a result, three categories have been constructed, each attempting to answer the corresponding research question, which are detailed in the next subsections. 3.3.1 Contributing Discipline. Every research paper in the WoS digital library may be categorised according to multiple research areas, e.g. Computer Science and Business & Economics. However, in this study we only used one categorisation per primary study. It was decided based on the primary categorisation of the paper that appear in the list of research areas. For example, papers published in the proceedings of International Conference on Software Business are categorised into Computer Science and Business & Economics, but in this study they are categorised only into the Computer Science discipline. AIS is a special digital library for information systems, thus all papers retrieved from this digital library are categorised into the Information Systems discipline. In addition, the contributing discipline was decided by also taking into consideration the affiliation (e.g., department, school, and university) of the contributing authors of the publications. In most cases, an author’s discipline corresponded with their school or department affiliation.
The Evolution of Software Startup Research: A Survey of Literature
309
3.3.2 Research Method. The research methods listed in [6] were used as the basis for this category. The listed research methods are as follows: Controlled Experiments, Case Studies, Survey Research, Action Research, and Ethnographies. If a research method did not fit into any of these categories, we extracted the research method as it was reported. The categorisation of the research methods was performed by examining the abstract and research methodology section for each paper. Similarly, we also extracted the theory that was explicitly mentioned in the paper. 3.3.3 Research Topic. The paper by Unterkalmsteiner et al. (2016) [19] was used as the basis for this category. The six research topics are as follows: 1. Supporting Startup Engineering Activities deals with papers that supports software engineering activities, for instance, Test Driven Development. 2. Startup Evolution Models and Patterns focuses on the progression of software startups over time. 3. Human Aspects in Software Startups covers research that investigates factors related to the actors involved in software startups. 4. Applying Startup Concepts in Non-Startup Environments investigates the effect of applying successful software startup practices in traditional environments. 5. Startup Ecosystems and Innovation hubs examines how supportive and thriving environments for software startups can be designed. 6. Theory and Methodologies for Software Startup Research covers research that develops methodologies and theories for software startup research. The categorisation of the research topics was determined by primarily inspecting the keywords, abstract, and conclusion section of the paper. If the topic of the paper remained unclear, a deeper examination of the paper was carried out until it could be categorised. 3.4
Data Extraction and Mapping Process
The categorisation process was carried out by splitting up the research papers, such that each reviewer was given a part to categorise. For each paper a confidence level was included along with the category. A high confidence level indicated how certain the reviewer was of the categorisation. For instance if the paper contained the phrase “...in this study we performed a case study” it would subsequently be added to the Case Study-category, and given a high confidence level. Papers marked with low confidence level required an additional reviewer to read the paper and categorise it. Any ambiguities were discussed and addressed with the present of the reviewers. Excel was used to further structure the extracted data, allowing the data to fit the classification schemes, and finally the data was visualised using a histogram and a three faceted bubble plot.
310
4
K. Hansen et al.
Findings
This section details the evolution of software startup research uncovered from the SMS. This section reveals the distribution of publication per year, what the contributing disciplines are, and their preferred research methods, theories, and research topics. All of this information is captured in a histogram and a three faceted bubble plot. 4.1
Publication Sources and Years1
The distribution of the years and venues of the primary studies is shown in Fig. 1. The first research paper in software startups in this study was published in the year 2000. There were few research papers published on software startups in this period until 2015. The year 2015 saw the first significant peak of publications in software startup with 6 papers. Since 2015, the number of research papers published has approximately doubled every other year, peaking in 2019 at 25 papers. However, a sudden decline in the number of publications is observed from 2020 to 2022.
Fig. 1. Temporal distribution of primary studies.
Most primary studies (68%) are published in computer science related conferences, e.g. International Conference on Software Business (ICSOB), XP Conference, Euromicro Software Engineering and Advanced Application (SEAA) and Product-Focused Software Process Improvement (PROFES). In the Information Systems-discipline, the majority primary studies are published in the International Conference on Information Systems. 1
The complete list of primary studies can be found: https://figshare.com/articles/ dataset/The Evolution of Software Startup Research A Survey of Literature/ 19204776.
The Evolution of Software Startup Research: A Survey of Literature
4.2
311
RQ1 - The Contributing Disciplines in Software Startup Research
Figure 2 shows a three faceted bubble plot with the mapping of the contributing disciplines, research methods, and topics. The larger the point radius, the greater number of research papers published in that category. Our results identified 4 disciplines that were responsible of contributing the 95 primary studies. The contributing disciplines to the software startup research area are, in the descending order, Computer Science (58 papers), Information Systems (16 papers), Business and Economics (13 papers) and Engineering (8 papers). The earliest publication in the software startup research area uncovered in this study came from the Engineering discipline (Engineering Management Society Conference) back in 2000, followed by the Computer Science discipline in 2002 (IEEE Software) and the Business and Economics discipline in 2003 (Systems Dynamic Review). This indicates the closely tight aspects of engineering and business in the software startup research phenomenon. The first paper published in the Information Systems discipline was in 2013 (Asian Conference on Information Systems). As software startups grow and mature, the evolution models and patterns are becoming evident and may attract Information Systems researchers. Examining the affiliation of the contributing authors, majority of the papers are written by authors with similar affiliations and/or disciplines. For example, publications in the Information Systems discipline are typically written by researchers affiliated with School of Business, Economics and Management. Only four studies are inter-disciplinary: Computer Science and Business [2], Computer Science and Engineering [10], Engineering and Economics [17], Engineering and Administration [16]. 4.3
RQ2 - Research Methods and Theories Used in Software Startup Research
Figure 2 illustrates the distribution of research methods used in the software startup research area. This study identified a total of 13 research methods for studying the software startup phenomenon. Qualitative approach is the most common research approach, as the majority of the primary studies focus on qualitative properties of the software startup phenomenon, e.g., engineering activities, evolution process, interaction process with ecosystems, etc. However, we have found two studies use statistical analysis to establish causal relation between different factors e.g., AI or ecosystem infrastructure to the growth of software startups. A total of 52 research papers employed Case Studies as their primary research method, followed by Action Research method (9 studies). We have also seen research papers use methods such as Design Science Research and Delphy Study to investigate the software startup phenomenon. Out of 95 primary studies, only 7 studies used theories to explain how and why some phenomenon occurred, e.g., causation and effectuation theory (3
312
K. Hansen et al.
Fig. 2. The mapping of contributing disciplines, research methods, and topics.
papers), behavioural theory (2 papers), socio-technical theory (1), structuration theory (1 paper). These studies are published in all disciplines, except Engineering. 4.4
RQ3 - The Past, Present, and Emerging Topics in Software Startup Research
The distribution of past, present, and emerging topics in the software startup research area is shown in Fig. 2. Among the six major clusters of software startup research agenda as discussed in [19], our study found Supporting Startup Engineering Activities and Software Evolution and Patterns to be the most researched areas with 31 and 30 papers each. Research on Supporting Startup Engineering Activities addresses specific software engineering challenges encountered by software startups. Computer Science is the largest contributors with 24 papers in Supporting Startup Engineering Activities as illustrated in Fig. 2. Surprisingly, the Business and Economics discipline also contributes 4 papers in this area, compared to Engineering with 3 papers. Startup Evolution Models and Patterns focuses on the progression of software startups over time to understand the underlying factors that contribute to success or failure of software startups. Computer Science and Information Systems discipline are the largest contributors with 13 papers each in Startup Evolution Models and Patterns as seen in Fig. 2. We have found two new research clusters emerged from the primary studies, which are Software Startup Education (9 papers) and Ethics in Software Startups
The Evolution of Software Startup Research: A Survey of Literature
313
(1 paper) since 2015. Software Startup Education focuses on pedagogical activities on teaching software startups approaches, for instance the Lean Startup Approach using a development of challenges-based framework [4] or a Massive Open Online Course (MOOC) [21]. Ethics in Software Startups examines ethics in a software startup environment, for instance best practices when developing AI software [20]. Within the Supporting Startup Engineering Activities research cluster, we identified a new emerging topic Experimentation in Software Startups (2 papers). This research topic focuses on identifying and evaluating processes, methods, and tools to conduct experiment to validate products and customer related assumptions or hypotheses. One study within the Cooperative and Human Aspects in Software Startup research cluster investigates learning in software startups at both individual and team level. Finally, one study within the Startup Evolution Models and Patterns research cluster investigate the process, methods and tools to support decision making in software startups.
5
Discussion
Our findings show that the software startup research area started to take off in 2015, doubling the number of publications every two years until the COVID-19 pandemic hit. The effects of the COVID-19 pandemic, which has led to the shutdown of universities and research institutions worldwide, can potentially be the cause for the sudden drop in publications. The shutdown of research institutes may have hindered research, as well as travel restrictions, infection risks, and other precautions taken by the authorities, may have led to the cancellation of several conferences [1]. However, we can expect to see the number bounce up, as we are at the beginning of 2022 and the COVID-19 restrictions worldwide are gradually lifted. This study used an expanded version of Wang’s search string, which included additional terms, and it was therefore anticipated that a greater number of publications would be discovered. However, this study mapped 95 primary studies using the WoS and AIS digital libraries compared to Wang [22], where 133 publications were identified published and indexed in the Scopus digital library, in which 35 overlapped with our study. A reason for the smaller number of publications included in this study compared to Wang’s can be attributed to the stricter selection criteria as this study only included publications that report empirical work as primary studies, additionally to using different digital libraries. It is important to note that the two disciplines that contributed the most Computer Science and Information Systems focus on different research clusters. For example, the Computer Science discipline emphasises on Supporting Startup Engineering Activities, while the Information Systems discipline emphasises on Startup Evolution Models and Patterns. There are often perceptions that Computer Science research focuses on technical issues while Information Systems emphasises on the behavioral and social implications of technology. Our analysis on the research topic support that this may be the case.
314
K. Hansen et al.
With the complexity of the scientific system, many social and engineering problems cannot be solved by one discipline, and thus interdisciplinary research has become an indispensable model of modern science [14]. However, this is not the case in the software startup research area. Contrary with the findings reported by Wang [22], our results did not show significant evidence in increasing inter-disciplinary studies. Most studies are conducted by researchers within the same disciplines and only 4% inter-disciplinary studies were identified in this study. A further analysis of the primary studies allowed us to update the research agenda in [19]. As discussed in Sect. 4, two new research clusters emerged: Software Startup Education and Ethics in Software Startups, as illustrated in Fig. 3. We discuss these new research clusters and list some examples of relevant research questions in the next section. These research questions draw on the findings, analysis, and limitations of the primary studies.
Fig. 3. Updated Overview of the Software Startup Research Agenda from [19]).
5.1
(adapted
Software Startup Education
The importance to provide entrepreneurial skills to engineering students has been widely recognised [15]. Technical proficiency is required but may not be enough for students, when they land their first job or seek to launch a software startup. In addition, the high failure rate of software startups is mainly due to software engineering practices [12].
The Evolution of Software Startup Research: A Survey of Literature
315
The phenomenon has attracted both industry and academic community, and several attempts have been made to address the issues startups are facing. For instance, by offering entrepreneurship-focused programs and courses to better prepare students to create a startup or to be employed in a startup environment. However, there are not many studies that focused on how software startup processes based on, for instance, Lean startup approach is taught to computer science and engineering students [4]. This new research cluster investigates pedagogical approaches, frameworks, and tools to teach software startup in both a formal setting, for example at a university, as well as an informal setting, such as a MOOC. 5.1.1 Formal Software Startup Education. Many universities now offer entrepreneurship courses to computer science students or students with similar backgrounds. This sub-cluster includes anything that involves improving existing courses or testing new courses in an effort to improve their software startup education in a formal setting. The idea is to equip students with the necessary skills to become value creators early in their careers. Examples of relevant research questions regarding this research track can be formulated as follows: – RQ1 – How can we bridge the gap between the classroom and the real world? – RQ2 – What are the most effective approaches for teaching software startup? – RQ3 – How can we encourage more students to launch their own software startup company? 5.1.2 Informal Software Startup Education. Many new software startup practitioners have emerged as a result of the everincreasing availability of free to low-cost educational resources, such as MOOCs and other online self-learning resources. How do these practitioners compare to others who have a more formal education, such as from a university? A common problem among self-learners is the low completion rate in online courses, for instance, It is 15% or less in MOOC Certificate programs [8]. Therefore, it is necessary to investigate how these self-learners traverse the wealth of online resources, select what is relevant to learn, ensure the quality of what they are learning, and maintain discipline to follow through on their plans. In broad terms this sub-cluster tries to answer the research questions such as: – RQ1 – How can self-learners tell the difference between bad and good learning sources? – RQ2 – How do successful self-learners stay motivated and disciplined? – RQ3 – Are there differences between those who have received informal software startup education and those who have received formal software startup education?
316
5.2
K. Hansen et al.
Ethics in Software Startups
The use of cutting-edge technologies such as AI, IoT, blockchain etc. have been common practice in software startups as part of their business models development [23]. For instance, the database Crunchbase2 lists over 79,000 startups related to AI as of February 2022. While these technologies can be seen as enablers to promote entrepreneurship and work well at the technical level, they also come with socio-cultural issues, that are rooted in ethics [20]. This new research cluster examines the role of ethics in software startups in terms of software development, organisational policies, and business practices. 5.2.1 Software Development Ethics in Startups. This sub-cluster encompasses questions regarding the ethics in relation to how software development is conducted in startups. For instance, how privacy is handled, licensing, and the creation of blackbox systems using AI. In order to better understand and explore the role of ethics in the software development in a startup context, examples of research questions such as the following can be formulated: – RQ1 – What are the potential ethical challenges in software development in startups? – RQ2 – How do software startups follow best practices when it comes to protecting their clients’ privacy? – RQ3 – What are the ethical implications of the development of AI in software startups? 5.2.2 Organisational and Business Ethics in Software Startups. This sub-cluster is responsible for all aspects of organizational and business ethics. All organizational practices and policies for ensuring a healthy and ethical work environment is covered. These practices and policies could for example be the code of conduct or more specific challenges, such as outsourcing, and the negotiation of salary. The following are examples of research questions for organizational and business ethics in software startups: – RQ1 – What organisational regulations do software startups need, to establish an ethical culture? – RQ2 – What business regulations do software startups need, to establish an ethical business culture? – RQ3 – How can software startups ensure that salary negotiations are ethical and fair? – RQ4 – What makes software startups outsource part of their work? 5.3
Threats to Validity
In this subsection, we identify and discuss the threats to validity of this study. 2
https://www.crunchbase.com/.
The Evolution of Software Startup Research: A Survey of Literature
317
5.3.1 Research Methods that are Not Clearly Stated. Most primary studies specifically stated the research method used, but a small number did not. Therefore, we sometimes had to derive the research method by reading the paper. Papers that were hard to categorise had more than one reviewer to reduce the threat to validity. Ambiguities in the papers were discussed before the final categorisation. 5.3.2 The Chosen Digital Libraries. WoS assigns every research paper in their collection to multiple categories. In such case, we took into consideration the first keyword appeared in the category defined by the digital libraries and the affiliation of the authors. Similar to Wang [22], we also used the category given by the digital library. However, WoS and Scopus may not use the same categorisation scheme, which makes it difficult to compare papers. For instance, Scopus has a Business, Management and Accounting category while WoS has a Business & Economics. AIS is known as the digital library for the Information Systems discipline. Thus, the classification was done straightforward. By including only two digital libraries, there are still many papers that are yet to be mapped, and this may be the reason why we found only one paper on Ethics in Software Startups. 5.3.3 Selection Process. It is probable that some primary studies have been excluded from this study, because they were wrongly deemed irrelevant in relation to software startup research. This study used synonyms for “software startup”, such as “internet startup” and “digital entrepreneurship” as part of the search string. However, not everyone uses these terms the same way, and therefore made it harder to distinguish relevant papers in relation to software startup research. To minimise this threat, the reviewers discussed ambiguous papers until a consensus was made to include the paper or not.
6
Conclusion
Software startup is a growing research area. Due to its product-business nature, research in software startups has attracted academics from multiple disciplines. In this study, we identified four disciplines that give significant contributions to establish software startup as a research area. Computer Science and Information Systems are the two top contributors. Our study also revealed that the Case Study is the most common research method to investigate the software startup phenomenon. In terms of research topic, our study found that Supporting Startup Engineering Activities has received the largest interest since 2014. Finally, this paper also identified two emerging research topics: Software Startup Education and Ethics in Software Startups.
318
K. Hansen et al.
In terms of implications, this paper makes two contributions. The first contribution is to provide the map of contributing disciplines, research methods, and topics in the software startup research area. Moreover, our study identified the emergence of two research topics since 2015, which makes our second contribution. The findings of our study allow us to update the research agenda paper on software startup [19] 6 years after its publication in 2016. For researchers, our findings may be used to inform and navigate their current and future research. Moreover, our study calls for more empirical research in particular topics including Software Startup Education and Ethics in Software Startups. To help achieve this goal, we have provided examples of research questions within these topics. In terms of limitations, the findings of our study are limited due to the fact that we only used two digital libraries, Clarivate Web of Science and AIS eLibrary. This may also be the reason why we only got one paper on Ethics in Software Startups. There is a high probability that we did not cover all important and relevant studies, as they are not indexed by the two libraries. Future research could add different digital libraries for example Inspec and Compendex or EBSCOHost, which might give better coverage to relevant literature. In addition, future research could also examine grey literature to confirm or refute if the identified research topics are relevant for actual software startups. Future research could replicate the study by [15] to measure the trend in interdisciplinary research in the software startup research area.
References 1. A year without conferences? how the coronavirus pandemic could change research (2020). https://www.nature.com/articles/d41586-020-00786-y 2. Almohri, H.M., Almohri, S.A.: Security evaluation by arrogance: Saving time and money. In: Proceedings of IEEE/ACM International Workshop on Software Engineering for Startups, pp. 12–16 (2017) 3. Berg, V., Birkeland, J., Nguyen-Duc, A., Pappas, I.O., Jaccheri, L.: Software startup engineering: a systematic mapping study. J. Syst. Softw. 144, 255–274 (2018) 4. Chanin, R., Sales, A., Santos, A., Pompermaier, L., Prikladnicki, R.: A collaborative approach to teaching software startups: findings from a study using challenge based learning. In: Proceedings of the 11th International Workshop on Cooperative and Human Aspects of Software Engineering (2018) 5. Coccia, M.: The laws of the evolution of research fields. arXiv preprint. arXiv:1805.03492 (2018) 6. Easterbrook, S., Singer, J., Storey, M.A., Damian, D.: Selecting empirical methods for software engineering research. In: Shull, F., Singer, J., Sjøberg, D.I.K. (eds.) Guide to Advanced Empirical Software Engineering, pp. 285–311. Springer, London (2008). https://doi.org/10.1007/978-1-84800-044-5 11 7. Genome, S.: Global startup ecosystem report 2019 (2019) 8. Hollands, F., Kazi, A.: Benefits and costs of mooc-based alternative credentials. Center for Benefit-Cost Studies of Education (2018) 9. Klotins, E., Unterkalmsteiner, M., Gorschek, T.: Software engineering knowledge areas in startup companies: a mapping study. In: Fernandes, J.M., Machado, R.J.,
The Evolution of Software Startup Research: A Survey of Literature
10.
11.
12.
13.
14. 15.
16. 17.
18. 19. 20.
21.
22.
23.
319
Wnuk, K. (eds.) ICSOB 2015. LNBIP, vol. 210, pp. 245–257. Springer, Cham (2015). https://doi.org/10.1007/978-3-319-19593-3 22 Korper, A.K., Patr´ıcio, L., Holmlid, S., Witell, L.: Service design as an innovation approach in technology startups: a longitudinal multiple case study. Creativity Innov. Manag. 29(2), 303–323 (2020) Melegati, J., Edison, H., Wang, X.: XPro: a model to explain the limited adoption and implementation of experimentation in software startups. IEEE Trans. Softw. Eng. 48(6), 1929–1946 (2020) Paternoster, N., Giardino, C., Unterkalmsteiner, M., Gorschek, T., Abrahamsson, P.: Software development in startup companies: A systematic mapping study. Inf. Softw. Technol. 56(10), 1200–1218 (2014) Petersen, K., Feldt, R., Mujtaba, S., Mattsson, M.: Systematic mapping studies in software engineering. In: Proceedings of the International Conference on Evaluation and Assessment in Software Engineering, pp. 1–10 (2008) Porter, A.L., Rafols, I.: Is science becoming more interdisciplinary? measuring and mapping six research fields over time. Scientometrics 81, 719–745 (2009) Porter, J., Morgan, J., Lester, R., Steele, A., Vanegas, J., Hill, R.: A course in innovative product design: a collaboration between architecture, business, and engineering. In: Proceedings of IEEE Frontiers in Education Conference, pp. 1–5 (2015) dos Santos, E.A., Torkomian, A.L.V.: Characteristics of the digital entrepreneuership: A multicase study in startups. Int. J. Innov. 9(2), 219–238 (2021) de Souza, M.L.P., de Souza, W.C., Freitas, J.S., de Melo Filho, L.D.R., Bagno, R.B.: Agile roadmapping: a management tool for digital entrepreneurship. IEEE Trans. Eng. Manag. 69(1), 49–108 (2022) Sutton, S.M., Jr.: Role of process in a software start-up. IEEE Softw. 17(4), 33–39 (2000) Unterkalmsteiner, M., et al.: Software startups-a research agenda. e-Informatica Softw. Eng. J. 10(1), 89–123 (2016) Vakkuri, V., Kemell, K.K., Jantunen, M., Abrahamsson, P.: “This is just a prototype”: how ethics are ignored in software startup-like environments. In: Proceedings of International Conference on Agile Software Development (2018) Vorbach, S., Poandl, E.M., Korajman, I.: Digital entrepreneurship education the role of moocs. In: Proceedings of International Journal of Engineering Pedagogy, pp. 99–111 (2019) Wang, X.: The rise of software startup research: an insider’s view. In: Hyrynsalmi, S., Suoranta, M., Nguyen-Duc, A., Tyrv¨ ainen, P., Abrahamsson, P. (eds.) ICSOB 2019. LNBIP, vol. 370, pp. 11–18. Springer, Cham (2019). https://doi.org/10.1007/ 978-3-030-33742-1 2 Weber, M., Beutter, M., Weking, J., B¨ ohm, M., Krcmar, H.: AI startup business models. Bus. Inf. Syst. Eng. 64, 1–19 (2021). https://doi.org/10.1007/s12599-02100732-w
On the Characteristics of Internal Software Startups Anastasiia Tkalich1(B)
and Henry Edison2
1
2
SINTEF, Trondheim, Norway [email protected] Blekinge Institute of Technology, Karlskrona, Sweden
Abstract. In recent years, more attention has been given to internal software startups in practice and in research alike, yet the concept is not fully understood. Nor is it clear whether or not it significantly differs from stand-alone software startup, and if yes, then how. In this position paper, we propose to conceptualize internal software startups as a hybrid of two related concepts: stand-alone software startup and internal corporate venture (ICV). We derive characteristics of the both concepts from the earlier literature and use our previous research on internal software startups to uncover the differences and the similarities across the three concepts. Keywords: Internal software startup · Internal corporate venture Software Startup · Lean Startup · Innovation
1
·
Introduction
Innovation is becoming very important in an ever-paced world. Corporations must look beyond their trusted walls for opportunities to lead in the business competition. Over the years, corporations have been looking externally to tap into the right skills, which usually includes acquisition (e.g., the acquisition of Skype by Microsoft, Whatsapp by Facebook or Waze by Google) and corporate venture capital (e.g., Google Venture, Intel Capital) to improve their innovation capabilities. In fact, the practice of corporate venturing has grown in its popularity from 2% to 44% in six years [17]. According to the latest report [8], total venture capital hits a new record high in 2021 - reaching $171.1 billion worldwide. In recent years, an increasing amount of attention is being given to “copycat” startups by corporations, which are called internal startups [1]. The maturity of the startup approach with the constant growth of investment and proven business models have attracted corporations who look for new ways to expand their business development. Today, internal startup is a new normal as we have seen more and more corporations launching new software products or services as a startup e.g. Niantic (Google) or MESH (Sony). This phenomenon has caught the attention of software engineering (SE) researchers. For example, Marijarvi c The Author(s) 2022 N. Carroll et al. (Eds.): ICSOB 2022, LNBIP 463, pp. 320–327, 2022. https://doi.org/10.1007/978-3-031-20706-8_22
On the Characteristics of Internal Software Startups
321
et al. [11] reported the experience of large Finnish companies in developing new software through internal startups. The SE literature refers to the phenomenon differently (e.g., internal startups [18], Lean internal startups [5], or internal software startups [20,23]) and there is no consistency in its definition. A clearly stated definition and/or defining characteristics are necessary for scientific understanding, explanation, and prediction [12]. Moreover, it helps researchers to build on each other’s work and for practitioners to decide whether research findings are relevant and applicable to their particular situation. As the field of software startup is still in its infancy, the time is ripe to work on the clarification of the existing terminology. The objective of this position paper is to differentiate an important type of software innovation initiatives, which we call internal software startup, from other similar types of initiatives, such as stand-alone software startups and internal corporate ventures (ICVs). To illustrate our point, we look back at our own research on internal software startups and summarize their characteristics. Based on what is already known about software startups and ICVs with their key characteristics, we show how the three concepts differ and where they overlap.
2
Software Startups and ICVs
In this section, we present relevant literature on the both concepts to show which characteristics have been put forward as defining. 2.1
Software Startup
There is a lack of consensus regarding the definition and central characteristics of software startups. In one of the earliest and most-cited papers that used “software startup” term [22], Sutton identified four major characteristics of software startups: youth and immaturity, limited resources, multiple influences and dynamic technologies and markets. Paternoster et al. [16] extended the list further and enumerated 15 characteristics of software startups where the most frequent were: 1) lack of resources and dependency on external sponsors, 2) time pressure, 3) innovation, 4) rapidly evolving, 5) lack of experience, and 6) highly risky. After analysing these six characteristics, Klotins [7] argued that while some of these characteristics have but anecdotal evidence (e.g., lack of experience), others are not unique to software startups (e.g. innovation, lack of resources, time pressure). Nevertheless, many of the aforementioned characteristics are typically used to specify what one means by software startups. For example, Melegati [14] highlights the following characteristics: 1) innovation, 2) software-intensive, 3) searching for repeatable and scalable business model, and 4) high uncertainty. Combining the insights from earlier literature, in this paper we use the following six characteristics of stand-alone software startups: 1) innovation - given the highly competitive ecosystem, startups need to focus on highly innovative segments of the market [14,16]; 2) high uncertainty - due to the innovative
322
A. Tkalich and H. Edison
nature of the products, startups face high level of uncertainty which they handle through experimentation (e.g., lean startup) [14]; 3) intention to create a repeatable and scalable business model [14] - startups are not only about new functionality but intend to create new revenue; 4) rapidly evolving unlike established companies that are constrained by their existing processes and infrastructure, startups can quickly react to changes in the underlying market and technologies, thus rapidly changing in their several aspects all at once [7,16]; 5) dependency on external sponsors - due to a lack of resources software startups heavily rely on external solutions (e.g., APIs, Open Source Software, outsourcing, COTS,) and investment [7,16]; software as outcome or ubiquity - the “software” aspect is present in startups where software is a ubiquity in entrepreneurial operations [21] or outcome of such operations [13]. 2.2
Internal Corporate Venture (ICV)
Internal software startups have a lot in common with the concept of internal corporate ventures (ICVs), which has been scrutinized by corporate entrepreneurship (CE) literature for decades. ICV is one of four routes (i.e. research and development - R & D, joint ventures, and acquisitions) to CE [10]. CE research focuses, in its turn, on ways that companies can use to create new businesses that generate new revenue streams and create value for shareholders, thus achieving innovation [15]. There are several important distinctions between ICV and other ways of CE. First, R & D is responsible for leveraging resources in the company to support the main core of the business [2]. The goal of ICV is to create a new business model empowered by a new product, extension of a current product to the existing market or extension of the current product to a new market [9]. Second, participants in ICVs are responsible for driving the end-toend innovation process while at the same time they may continue to fulfill their other responsibilities in the company, whereas the R&D is fully dedicated to the innovation process [2]. This approach is also known as employee-driven innovation [6]. The employees can be gradually reassigned to the ICVs full-time as the products mature [10]. Third, ICVs are different from joint ventures (JVs) because they primarily rely on the resources (skills, finances, marketing) of the parent company [15], while JVs rely on the pool of resources from several firms. For example, the ideas of ICVs frequently emerge and are carried out in-house [15] (at least in the initial stages), which is different from acquisition where the ideas are a result of purchase or merger. In recent SE literature, ICVs are sometimes studied under the term Lean internal startups [3] There are three characteristics of lean internal startups [4]: institution, innovation, and extreme uncertainty. Institution is about the startup being integrated within the parent company and relying on its resources functions (e.g. sales, marketing, testing, security). Innovation encompasses the need for different ways of working compared to the routines to allow teams to move fast but at the same time do not threaten the product in the parent company. Extreme uncertainty is the main reason for the lean startup
On the Characteristics of Internal Software Startups
323
approach, which is basically about reducing the uncertainty. Internal startups are often assigned to an untapped market segment. Thus with all resources from the parent company, there is no guarantee that the internal startup will succeed [4]. To summarise, the defining characteristics of ICV are: 1) innovation [4], 2) high uncertainty [3,4,19], 3) intention to create a new business model [2,9], 4) reliance on the resources of the parent company [4,15], and 5) being driven and owned by individuals or teams of employees [2,6,9,10].
3
Internal Software Startups: Defining Characteristics and Case Illustrations
Examining the characteristics of software startups and ICVs, as discussed in the previous section, one can see that some of them overlap, whereas others are distinct. As shown in Fig. 1 we mapped both lists of the characteristics and used them to illustrate how they relate to each other and to internal software startups that we studied earlier.
Fig. 1. Internal software startups: characteristics and case examples
The figure shows that software startups and ICVs share three characteristics: innovation, high uncertainty and intention to create a scalable business model. There are some characteristics that are inherent to software startups, but not to ICVs, i.e. rapidly evolving, dependency on external sponsors, and software as outcome or ubiquity of entrepreneurial operations. ICVs are in their turn unique because they rely of the resources of the parent company and are driven by people that are already employed there. When it comes to our previously published cases
324
A. Tkalich and H. Edison
of what we believe were internal software startups, the figure shows that most of them contained some characteristics that are inherent to software startups but not to ICVs (e.g. rapidly evolving, software as outcome or ubiquity), some that are only typical to ICVs but not to software startups (e.g. reliance on the resources of the parent company, driven by internal employees), and those that are common for the both concepts. Our first conclusion is, therefore, that internal software startups are entities on their own, which cannot be described by the related concepts, but at the same time partly overlap with them. Looking at which characteristics were prominent in the cases of internal software startups (the green checks), we see that many of them were surprisingly consistent across all the cases, while others were less consistent. For example, dependency on external resources was only identified in one case, which can suggest that this trait may occur in certain internal software startups but is not as central as the others. In the same way, there was not consistency in terms of whether all of the internal software startups were rapidly evolving or not. This may be due to the lack of clarity of what exactly “rapidly evolving” means and how it can be observed. Klotins [7] argues that this trait is inherent to software startups, be because unlike the established organizations, they are not constrained by the existing structures and routines, and can thus change is several aspects at once. However, it is hard to specify which exactly aspects one should look for and how rapid should the change be for this characteristic to be present. Another explanation is that while some internal software startups evolve faster, others are constrained by their parent companies. To conclude, we encourage further research on whether this characteristic is significant for internal software startups, how it can manifest, and how it is influenced by the parent companies. Further, the figure demonstrates that innovation, high uncertainty, software as ubiquity, reliance on resources of the parent company and being driven by internal employees were present in all our cases. This suggests that these are candidates for defining characteristics of internal software startups. Indeed, the most internal software startups we had studied, provided new offerings that could be scaled and that were expected to bring stable income after a while. Since the offerings were new, the initiatives inevitably faced uncertainty - for example with regard to the market segment, the functionality or the user needs. The internal software startups also relied on the resources of the parent companies who function not only as investors, but also as infrastructure, often providing work stations, competency, and salary to the startups teams. In return, the teams were often accountable for the result of their initiatives and functioned is main drivers behind the new product while still fulfilling other responsibilities at the parent companies (which is different from conventional R&D innovation initiatives that do not have to result in new business models and are fully dedicated to the innovation process [2]). While ICVs concern all sorts of innovations, the internal software startups we studied, had software as the essence of their business or their outcome (see Fig. 1). This implies that the lessons learned from software engineering literature can and should be applied to understand and
On the Characteristics of Internal Software Startups
325
succeed with internal software startups. This implication is important because we have so far seen that internal software startups in established companies are sometimes being developed using elements from conventional approaches (e.g. top down decision-making, centralized budgeting, silo-formed context [20]).
4
Conclusions and Further Work
To summarize, we have used earlier literature on software startups and ICVs to derive possible key characteristics of what we argue is internal software startup. Using our previous research on this phenomenon, we showed that internal software startups cannot be described by the related concepts, but at the same time overlap with them. Internal software startups are a subset of ICVs, as they have software as their essence, which is not specifically addressed in the ICV literature. However, it is still unclear how internal software startups evolve equally rapidly as stand-alone startups. Future research should address this inconsistency. Other avenues of research should concern validation of the characteristics suggested in this position paper and whether they can be used to further data collection and analyses on internal software startups. Overall, the characteristics we have suggested are a first step toward conceptual understanding of internal software startups that can help researchers better specify their objects of study. Acknowledgements. This study was supported by the 10xTeams and Digital Class research projects; and by the Research Council of Norway through grants 309344 and 309631.
References 1. Babych, M.: Internal startups: the new normal for business? (2021) 2. Bart, C.K.: New venture units: Use them wisely to manage innovation. MIT Sloan Manag. Rev. 29(4), 35 (1988) 3. Edison, H.: Lean internal startups: challenges and lessons learned. In: Nguyen-Duc, A., M¨ unch, J., Prikladnicki, R., Wang, X., Abrahamsson, P. (eds.) Fundamentals of Software Startups, pp. 251–268. Springer, Cham (2020). https://doi.org/10.1007/ 978-3-030-35983-6 15 4. Edison, H., Wang, X., Abrahamsson, P.: Lean startup: why large software companies should care. In: Scientific Workshop Proceedings of the XP, pp. 1–7 (2015) 5. Edison, H., Wang, X., Jabangwe, R., Abrahamsson, P.: Innovation initiatives in large software companies: a systematic mapping study. Inf. Softw. Technol. 95, 1–14 (2018) 6. Høyrup, S.: Employee-driven innovation and workplace learning: basic concepts, approaches and themes. Transf. Eur. Rev. Labour Res. 16(2), 143–154 (2010) 7. Klotins, E.: Software start-ups through an empirical lens: are start-ups snowflakes? In: CEUR Workshop Proceedings, Volume 2305, CEUR-WS (2018) 8. KPMG: Q3 2021 venture pulse report - global trends (2021) 9. Kuratko, D.F., Covin, J.G., Garrett, R.P.: Corporate venturing: insights from actual performance. Bus. Horiz. 52(5), 459–467 (2009)
326
A. Tkalich and H. Edison
10. Lengnick-Hall, C.A.: Innovation and competitive advantage: what we know and what we need to learn. J. Manag. 18(2), 399–429 (1992) 11. M¨ arij¨ arvi, J., et al.: The cookbook for successful internal startups. In: Digile N4S (2016) 12. McKelvey, B.: Organizational Systematics: Taxonomy, Evolution, Classification. University of California Press, Berkeley (1982) 13. Melegati, J., Edison, H., Wang, X.: XPro: a model to explain the limited adoption and implementation of experimentation in software startups. In: IEEE Transactions on Software Engineering 1–1 Conference Name: IEEE Transactions on Software Engineering (2020) 14. Melegati, J., Guerra, E., Wang, X.: Understanding hypotheses engineering in software startups through a gray literature review. Inf. Softw. Technol. 133, 106465 (2021) 15. Narayanan, V.K., Yang, Y., Zahra, S.A.: Corporate venturing and value creation: a review and proposed framework. Res. Policy 38(1), 58–76 (2009) 16. Paternoster, N., et al.: Software development in startup companies: a systematic mapping study. Inf. Softw. Technol. 56(10), 1200–1218 (2014) 17. Prats, M., Siota, J., Canonici, C., Contijoch, X.: Corporate venturing: challenges and best practices of large firms innovating with start-ups (2018) 18. Raatikainen, M., Komssi, M., Kiljander, H., Hokkanen, L., M¨ arij¨ arvi, J., Mohout, O.: Eight paths of innovations in a lean startup manner: a case study. In: Abrahamsson, P., Jedlitschka, A., Nguyen Duc, A., Felderer, M., Amasaki, S., Mikkonen, T. (eds.) PROFES 2016. LNCS, vol. 10027, pp. 15–30. Springer, Cham (2016). https://doi.org/10.1007/978-3-319-49094-6 2 19. Ries, E.: The lean startup: how today’s entrepreneurs use continuous innovation to create radically successful businesses. In: Crown Books (2011) 20. Sporsem, T., Tkalich, A., Moe, N.B., Mikalsen, M.: Understanding barriers to internal startups in large organizations: evidence from a globally distributed company. In: Proceedings of 16th ICGSE (2021) 21. Steininger, D.M.: Linking information systems and entrepreneurship: a review and agenda for IT-associated and digital entrepreneurship research. Inf. Syst. J. 29(2), 363–407 (2019) 22. Sutton, S.M., Jr.: Role of process in a software start-up. IEEE Softw. 17(4), 33–39 (2000) 23. Tkalich, A., Moe, N.B., Ulfsnes, R.: Making internal software startups work: how to innovate like a venture builder? In: Wang, X., Martini, A., Nguyen-Duc, A., Stray, V. (eds.) ICSOB 2021. LNBIP, vol. 434, pp. 152–167. Springer, Cham (2021). https://doi.org/10.1007/978-3-030-91983-2 12
On the Characteristics of Internal Software Startups
327
Open Access This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made. The images or other third party material in this chapter are included in the chapter’s Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter’s Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.
Gender Bias in the Recruitment Process of IT Startups in the Netherlands ˇ Tea Sinik, Joeri Snippert(B) , and Slinger Jansen(B) Utrecht University, Utrecht, The Netherlands {t.sinik,j.snippert}@students.uu.nl, [email protected] Abstract. In today’s fast-changing and innovative world, startups must compete amongst themselves and other well-established companies to hire the best talent in order to succeed. Diversity within the recruitment process is typically not a priority, even though it is well known that a diverse team is beneficial for (business) outcomes. Through a multiple case study performed at 5 IT startups based in the Netherlands, we observed that gender bias is introduced from the first moment that the need for an employee has been identified until candidate hiring. This is a direct result from (1) a lack of resources (e.g., time and money), (2) urgency to find the first and best candidate, or (3) the awareness of the startup founders. Keywords: Diversity & Inclusion
1
· IT Startup(s) · Gender bias
Introduction
Diversity - both acquired (e.g., cultural background and experience) and inherent (e.g., gender and race) - results in business success [11]. An example study of McKinsey & Company showed that from the 366 public companies that were in the top quartile for ethic a (racial) diversity within the management, were 35% more likely to have financial returns above the industry mean [10]. This research reaffirmed the (global) importance of creating diverse and heterogeneous teams, because they produce better (business) outcomes, customer success and a higher job satisfaction [3]. Johnson, Hekman, & Chan [4] investigated the relationship between finalist pools and the actual hiring decisions. Their results suggested that if there is only one woman in a pool of four job finalists, the likelihood of hiring the woman will be 0%. Moreover, Johnson et al. state that by creating a new status quo amongst the finalist, by adding an additional woman, the decision makers may consider hiring a woman. However, the following issue remains: what if women do not get the chance to be selected from the hiring pool? We cannot expect that every single IT startup in the Netherlands is able to reach a fair ratio of 50:50 between their female and male employees. Simply put, there are not enough women to fill these seats [2]. However, we can aim to reduce gender bias within Supplementary Information The online version contains supplementary material available at https://doi.org/10.1007/978-3-031-20706-8 23. c The Author(s), under exclusive license to Springer Nature Switzerland AG 2022 N. Carroll et al. (Eds.): ICSOB 2022, LNBIP 463, pp. 328–334, 2022. https://doi.org/10.1007/978-3-031-20706-8_23
Gender Bias in the Recruitment Process of IT Startups
329
the recruitment process of IT startups in the Netherlands. So that at least the women in the hiring pool have an equal chance to get hired such as their male colleagues. Section 2 describes the research method including the case selection and case description. In Sect. 3 we analyse the observed findings, which we combine with the literature study. Finally, we identify 7 types of bias that are introduced in several phases of a Dutch IT startup recruitment phases. In addition to the identified biases, we provide a conclusion, and future work in Sect. 4.
2
Research Method
The objective of this research is to raise awareness of the lack of gender diversity. We are particularly interested in observing and analysing biases in the Dutch IT startup domain. That is why the research question is stated as:“What are possible sources of gender bias within the recruitment process of IT startups in the Netherlands?” We performed two steps in the research: (1) a small literature study, (2) a multiple case study consisting of a case survey and a case interview. The interview is a semi-structured interview in which six themes were followed as proposed by Krenzi [7]: (1) Identifying needs, (2) Drafting Job Description, (3) Publishing, (4) Screening, (5) Assessment(s), and (6) Selecting and offering. We followed an open interview protocol, for the semi-structured interview we created (introductory) open-ended questions to allow the participants to introduce themselves, their startups and to elaborate on their responses before proceeding with followup questions. Due to the sensitive topic, any points regarding the confidentiality or publication of data were regulated in the informed consent form, as published on Zenodo1 . Case Selection. The context of this research are the IT startups in the Netherlands. The selected participants were IT startup founders with at least one employee besides the founder(s), to ensure that the founders are able to provide sufficient insights into the recruitment phase. Furthermore, the IT startups were no older than ten years. In total, 87 IT startups have been contacted using various methods (participated/contacted) e.g., face-2-face (2/10), email (0/31), LinkedIn (3/25), official website of an association or incubator (0/1), or a combination of approaches (0/20). In the end, 5 startups agreed to partake in the interviews. Case Description. We present a summary of the cases and an overview in Table 1. We wanted the study to be inclusive, so we also included an “X” gender in our research. However, we did not encounter anyone who stated their gender as non-binary.
3
Observations and Analysis
This section presents the findings of the case studies performed at 5 IT startups. For six of Krenzi’s [7] seven phases, we describe how potential bias was identified. 1
https://doi.org/10.5281/zenodo.6554766.
330
ˇ T. Sinik et al.
Table 1. The case studies of the Dutch IT startups and their employee numbers. The final column addresses the genders of the employees, no non-binary genders were encountered. ID Founded Location
# Founders # Employees M/F/X (excluding founder(s))
A 2021
Utrecht
1
B 2018
Amsterdam 1
12
M: 6, F: 6, X: 0
C 2020
Utrecht
1
13
M: 7, F: 6, X: 0
D 2020
Utrecht
1
10
M: 6, F: 4, X: 0
E 2019
Eindhoven 3
5
M: 5 (2 full-time and 3 part-time), F: 0, X: 0
9
M: 4 (2 full-time and 2 part-time), F: 5 (1 full-time and 4 part-time), X: 0
The potential bias is scoped to the level of surface diversity, which is concerned with visible characteristics of an individual. The statements are solely applicable to the situation of the five startups, thus the aim is not to generalise outside of the scope of the research. The main goal was to observe what is currently happening and to illuminate the findings as a result of the interviews. 1a. Identification of Needs. Hiring new employees starts with the identification of needs [7]. Drafting a job description and the identification of the needs are (observed in each startup) considered as activities which are done simultaneously. None of the startups formalise the exactly identified need (e.g., recruitment policy). Founder A: “I trust my experience whilst defining the needs, documentation is not a priority”. Founder E concurs and states “each project and situation results in a different need, we do not have time for unnecessary documentation”. Each founder has unique reasons for hiring new staff. Founders A and D emphasise that the urge to hire an employee comes from the existing employees and their heavy workload. Whereas the other startups’ urge starts from the founders perspective or its partners, which is a third party with whom the startup has a collaboration agreement e.g., the bank (loan requirement), educational institutions, or recruitment agencies. The interview revealed that the core values and intrinsic motivation of the startup founder will shape the values of the startup. 1b. Bias in Identification of Needs: We observed a lack of policies within the startups. Founder D stated “the majority of startups do not have a policy. We aim to include (gender) diversity (and bias) from the start, whilst accepting the consequences in terms of investments in time and money”. We noticed that startups only look at surface-level diversity (gender) at a later stage, which is typically already too late for bias elimination, either because they do not have the resources or because they do not deem this to be of interest. 2a. Drafting a Job Description. The job description communicates the requirements to the potential new employee or third parties. A formalisation of a job description is legally required in case that an employee’s contract must be terminated. However, Kaleva [6] emphasises that biased formalization occurs when rules treat certain biases as neutral. As the job description is typically
Gender Bias in the Recruitment Process of IT Startups
331
drafted during the needs identification in startups, there is insufficient consideration for bias. 2a. Bias in Drafting a Job Description. The lack of a guideline and the direct translation from needs to job description (without taking the time to take gender bias into account) could be a significant cause of bias. 3a. Publishing Strategy. LinkedIn is the only social media platform used by the founders to (1) post vacancies, (2) ask their network for leads, and (3) if the previous activities do not result in any leads then the founders actively search for people themselves. Startups A - D are a direct result of relationships made during their time at the university. Startup E, started out as an university research project and is still mostly active and/or recruiting at the university. In this case, the founders’ educational network is also the business network. The founders state that the reason for using these methods is that it is completely free. In case that no leads are found, then the founders use a HR specialist and/or mediator, which usually is a friend that offers their services for free. Founder A: “I try to find candidates by either posting a vacancy on LinkedIn or asking my network. I only invest my own time if there are no suitable candidates. Per open vacancy I usually spend two days”. Founder B found his senior employee during a hackathon, whereas founder C used its educational network to find his CTO (former fellow student). Startup B, D and E have a partnership with educational institutions to recruit students. However, none of the startups have a paid-based collaboration with employment agencies. The founders state that they find it hard to find candidates with technical skills and are willing to invest more time and money in recruiting and/or training the candidates (e.g., bootcamp) program). 3b. Bias in the Publishing Strategy. LinkedIn does not offer an anonymization function, so the introduction of gender bias within this phase may be the result of the Similarity-Attraction Paradigm, which states that individuals encounter positive reactions to similar individuals in terms of e.g., characteristics or experience. Moreover, this may also introduce (unconscious) bias within the recruitment, which can limit the potential for building a heterogeneous team. The Justification-Suppression Model explains that every single individual acts on their prejudice [1], this may be against gender, race or ethnic groups. Searching for candidates on LinkedIn, where the entire background of the candidate is presented (e.g., photo, race and professional experience) may cause for prejudice. Lastly, the Social Identity Theory provides an excellent explanation regarding the lack of diversity within a startup (e.g., filter bubble). If your network consists of young, white men with a technical background, then the platform’s algorithm will primarily show similar individuals. 4a. Screening. Screening is the process of filtering candidates to scope down from a long-list to a short-list. The founders admit that they are not in the position to filter on other variables other than the minimal requirements due to having a small candidate pool of 1 to 10 applicants. Founder C states: “I only filter out nonsense applications”. Only startup D has completely anonymized the hiring (and screening) process and stated “I am a young, white man, so by
332
ˇ T. Sinik et al.
default we (as in similar men) get a bunch of opportunities. We need to respect those who do not have the same privileges. Our job description explicitly stated that the hiring process would be completely anonymized, and that the applicants had to refrain themselves of sharing personal information. All documents were shared with an external mediator, a friend of mine. The mediator was forced to scrap a substantial amount of information from the documents, because none of the 10 applicants complied. This indicates that people are unaware of the impact of certain details. For instance, providing years informs us of your age but also gaps in your CV”. 4b. Bias in Screening. Only startup D has taken measures to minimize bias, even though all founders are interested in reducing bias. The presence of gender bias could be caused by (1) the (unconscious) bias of the person(s) who perform the filtering, and (2) the lack of predefined requirements during filtering. One of the biggest causes for gender bias is motherhood. The majority of women have gap(s) in employment, which may result that the startup favours a male candidate. Startup A confirmed this: “the importance of a CV and motivation letter is to see if the person believes in our mission and vision. We are aware that the documents include personal information which may introduce a certain bias”. Founder D: “we have noticed that [even in anonymized CVs] there is still a certain (unconscious) bias present, because the entire team speculates on the gender of the candidate based on the experience”. 5a. Assessment. Every founder states that they assess the application on the organisational fit and then on the skills or experience. Depending on the type of job (e.g., consulting or a technical role), this phase also includes a test or mock case. The aim to understand the thought process of the candidate. Startups C - E, also asses the technical skills of the applicants with an informal interview. Startup C stated: “My belief is that you should want to have a diverse team. We have a diverse and multidisciplinary team, and we seek to have an equal balance in introvert/extrovert, in terms of interests and hobbies and male/female/nonbinary ratio or sexual orientation. We are looking for the right fit, seeing as we are very open about the aforementioned topics and everyone knows and accepts this about each other”. Startup D invests more time in assessing whether the applicant fits the team, using a personality test. The vision of the founder is that “organisations only look at diversity afterwards, but our aim is to get it right from the start”. 5b. Bias in Assessment. The founders state that there are some predefined interview questions, however this is highly dependent on the situation, context, or the urgency to find a suitable candidate. Moreover, in most cases only the founders are involved in this process. 6a. Selection. The founder has the final saying. Founders A and D emphasise that they do discuss their final decision with the team, because the fit is the final deciding factor, and not the skills or experience. Founder E said: “startups have small teams, therefore there is no point in hiring a person if they do not fit within the team. Perhaps in more reputable companies there would be the oppor-
Gender Bias in the Recruitment Process of IT Startups
333
tunity to move the person to another department, if there is not fit. However, for us this is not possible”. 6b. Bias in Selection. All founders of the observed startups are young, white men, therefore their perspective may be limited and/or (unconsciously) biased. Which may result that their preference is a similar candidate (white, young man) instead of a woman. Startup B commented: “We are aware that this is not an ideal hiring process. There is no anonymization, randomization or best practices, because we do not check nor verify on bias. If we would have the needed resources e.g., time and budget, then improving and standardizing the hiring process would be our priority”.
4
Recommendation and Conclusion
We observed that gender bias is present within each moment of the recruitment process of IT startups. From the first moment when the founder identifies its need until they select the candidate(s) to fill the position(s). Therefore, to answer the main research question, we recommend IT startup founders to be aware of the following seven observed gender bias sources per recruitment phase: Justification Bias (1, 2, 3, 4, 5, 6) - The lack of time could increase the prejudices of IT startup founders about time, culture, national boundaries, and languages [1]. Possible countermeasures: HR Policy Document, Hiring Team, and Awareness Training. Lack of Cognitive Diversity (1, 2, 3, 4, 5, 6) - The lack of formalization could increase the preference of IT startup founders for homogeneous groups over heterogeneous groups [13]. Possible countermeasures: External Recruitment Expertise, and HR Policy Document. Blind Spot Bias (1, 2, 3, 4, 5, 6) - IT startup founders tend to think they have no (gender) bias, and they see it more in others than in themselves [9]. Possible countermeasures: Awareness Training, and Anonymized Hiring. In-Group Favoritism (4, 5, 6) - The founders of IT startups prefer their own (social) network, which consists of comparable characteristics, behaviors, and attitudes (Social Identity Theory) [12]. Possible countermeasures: Using Other Recruitment Channels, and External Recruiter. Automation Bias (4, 5, 6) - The founders of IT startup rely on automated systems and trust that the algorithms are actually correct (e.g., Filter Bubble phenomenon in combination of the Similarity-Attraction Paradigm) [8]. Possible countermeasures: Inviting More Candidates, and Awareness Training. Confirmation Bias (5, 6) - IT startup founders tend to find and remember information that confirms their perception (e.g., lack of anonymized hiring and/or lack of formalization) [5]. Possible countermeasures: External Recruiter. Stereotyping Bias (5, 6) - IT startup founders adopt generalized beliefs that members of a group will have certain characteristics (e.g., lack of anonymized hiring and/or lack of formalization) [5]. Possible countermeasures: Awareness Training, and Anonymized Hiring.
334
ˇ T. Sinik et al.
Based on the observations we conclude that there are various reasons as to why gender bias is present within the recruitment process of IT startups in the Netherlands. First and foremost, the startups are faced with a lack of available resources (e.g., money and time). Their focus is solely based on survival, which means (1) finding new customers, (2) securing funding, and (3) if money and time allows, find new employees. However, as stated by 4 out of 5 founders, they are either not in the position to explicitly search for a woman to fill the position. Or, they simply do not want to spend additional time (which in most cases is already scarce) to do this. We could provide a policy recommendation to provide incentives to startups for hiring a more diverse workforce, as diverse teams can be more productive and innovative and it benefits society when more diverse staff are working. We also noted a general willingness to work on diversity within the five startups, leading to the observation that there is a healthy ground for improvement. As future work we want to do more case studies with startups in other countries to see what other types of biases can be found.
References 1. Crandall, C.S., Eshleman, A.: A justification-suppression model of the expression and experience of prejudice. Psychol. Bull. 129(3), 414 (2003) 2. Eurostat: Girls and women among ict students: What do we know? (2020). https:// ec.europa.eu/eurostat/web/products-eurostat-news/-/edn-20200423-1 3. Hunt, V., Yee, L., Prince, S., Dixon-Fyle, S.: Delivering through diversity (2018). https://www.mckinsey.com/business-functions/people-and-organizationalperformance/our-insights/delivering-through-diversity# 4. Johnson, S., Hekman, D., Chan, E.: If there’s only one woman in your candidate pool, there’s statistically no chance she’ll be hired. Harvard Bus. Rev. 26(04), 1–7 (2016) 5. Kahneman, D., Lovallo, D., Sibony, O., Torrance, A., Von Hippel, C.: A Structured Approach to Strategic Decisions. MIT Sloan Management Review, Cambridge (2019) 6. Kalev, A.: How you downsize is who you downsize: biased formalization, accountability, and managerial diversity. Am. Sociol. Rev. 79(1), 109–135 (2014) 7. Krenzi, L.: How to optimize the talent acquisition strategy and recruitment process in swiss startups and young ventures to build a winning team? Ph.D. thesis, Haute ´ecole de gestion de Gen`eve (2020) 8. Parasuraman, R., Manzey, D.H.: Complacency and bias in human use of automation: An attentional integration. Hum. Factors 52(3), 381–410 (2010) 9. Pronin, E., Lin, D.Y., Ross, L.: The bias blind spot: perceptions of bias in self versus others. Pers. Soc. Psychol. Bull. 28(3), 369–381 (2002) 10. Rock, D., Grant, H.: Why diverse teams are smarter (2016). https://hbr.org/2016/ 11/why-diverse-teams-are-smarter 11. Rock, D., Grant, H., Grey, J.: Diverse teams feel less comfortable - and that’s why they perform better (2016). https://hbr.org/2016/09/diverse-teams-feel-lesscomfortable-and-thats-why-they-perform-better 12. Tajfel, H.: Social identity and intergroup behaviour. Soc. Sci. Inf. 13(2), 65–93 (1974) 13. Watson, W.E., Kumar, K., Michaelsen, L.K.: Cultural diversity’s impact on interaction process and performance: comparing homogeneous and diverse task groups. Acad. Manag. J. 36(3), 590–602 (1993)
Sustainability
Green ICT Adoption and Challenges: Evidence from the Finnish ICT Sector Larry Abdullai1(B)
, Antti Sipilä2 , and Jari Porras1
1 LUT University, Lappeenranta, Finland
{larry.abdullai,jari.porras}@lut.fi 2 TIKE Finnish Information Society Development Centre, Helsinki, Finland
[email protected]
Abstract. For better or worse, information, communication, and technology (ICT) is taking over most part of our lives. During the past few years, organizations, industries, and educational and health institutions that could utilize the power of ICT and digitalization maintained high productivity, efficiency, economic and social resilience. Yet, at the same time, the trend towards digital transformation is contributing its fair share to increased energy consumption, e-waste, and carbon emissions. The challenge is how to ensure that organizations successfully embark on their digital strategy with sustainability at the center of the digital transformation. In this study, we aim to understand the motivations and needs of organizations towards adopting green ICT as a response to the sustainable development agenda. Through an exploratory and qualitative study, we surveyed ICT-related organizations to understand their motivations and challenges to adopting green ICT. Our findings show a lack of green ICT awareness and a vague corporate strategy for green ICT adoption. This study provides a foundation for practitioners and policymakers to develop strategies and support systems to enhance the organizational green ICT transformation agenda. Keywords: ICT ecosystem · Sustainability awareness · Green ICT · Sustainable ICT business development · Motivations · Challenges
1 Introduction The climate crisis poses an unprecedented risk to humanity and our common planet. As result, many countries are making commitment towards achieving carbon neutrality by 2050, as agreed upon during the UN Climate Change Conference in Glasgow (COP26), and the demand for zero-carbon goods and services is set to grow correspondingly. At the same time, the digital transformation trend is becoming pervasive, and organizations are racing towards it. As companies race to innovate and roll out their digital transformation strategies, there is the need to ensure that these transformations are done with sustainability in mind. Digital technologies which was once an enabler to sustainable development is now also contributing its fair share to the environmental and climate change problem. As such, Finland is setting the pace in developing an ambitious climate target for the information, communication, and technology (ICT) sector to reach carbon neutrality © The Author(s), under exclusive license to Springer Nature Switzerland AG 2022 N. Carroll et al. (Eds.): ICSOB 2022, LNBIP 463, pp. 337–343, 2022. https://doi.org/10.1007/978-3-031-20706-8_24
338
L. Abdullai et al.
by 2035 [1]. Hence, how organizations adopt green ICT practices towards sustainable digital transformation becomes pertinent to achieving Finland’s 2035 carbon neutrality target. To this end, our study set out to understand the motivation and challenges of organizations in adopting green ICT practices in their digital transformation journey. The findings in this study becomes an initial step towards building a green ICT ecosystem in the Uusimaa region, a research project focused on boosting the competitiveness and sustainability of ICT and software related businesses in Finland.
2 Background and Green ICT Related Studies The green ICT concept is gaining popularity among scholars and practitioners whether to save the planet, improve energy efficiency, promote sustainable development, or increase information systems’ reliability [2]. The term often refers to either greening the ICT sector itself or using ICT to green other industries. Despite evidence of the role of ICT in responding to grand global challenges [3], a handful of studies have empirically investigated the motivations and challenges to developing and adopting green ICT initiatives in organizations. In the study of Thabit and Yaser [4], the authors posited that factors such as costs, political and social pressure, government legislation, environmental responsibilities, enlightened self-interest, and new opportunities in the market were the six drivers for developing green ICT in developing economies. Hernandez [5] also identified factors such as individual attitude, managerial support, and budget availability as the internal success factors for green ICT adoption in organizations. Regarding the external factors, Hernandez argued that availability and accessibility of IT infrastructure, industry pressure, and government support significantly facilitate Green IT adoption among SMEs. The green ICT aims to encourage stakeholders engaged ICT and software business to consider environmental problems and find solutions to them [6]. Thus, green ICT adoption in organizations concerns not only ICT’s energy efficiency or the environment, it includes various organizational processes and socio-technical, economic, and managerial practices related to ICT [7]. For instance, Radu [8] identified and classified the main motivating factors for green ICT adoption in organizations such as the quest for competitiveness, organization strategies and policies towards sustainability, as well as social and environmental responsibility commitment are the key motivations for organizations to adopt green ICT principles. Despite the motivation from business stakeholders towards green ICT, many organizations have challenges in adopting green ICT principles in their business operation. For example, a recent study [9] identified factors such as lack of technical human resource and training programs, lack of budget allocation for green ICT implementation and the lack of government strict regulations as the main barriers to green ICT implementation in organizations. As Finland happens to be one of the first countries to set ambitious climate strategy for the ICT sector, the contribution of our study provides a better understanding to whether having government policy on sustainable ICT is enough for organizations to adopt green ICT practices in their operations. Thus, the study identifies the state-of-the-art on green ICT adoption challenges and discusses the findings in relation to organizations’ digital transformation agenda. The result of this study will serve as a basis to orchestrate a green
Green ICT Adoption and Challenges: Evidence from the Finnish ICT Sector
339
ICT ecosystem in the southern part of Finland where stakeholders involve in ICT and software business come together to share green ICT best practice as well as produce and source ICT products and services.
3 Methodology This study aims to understand needs of stakeholders in the ICT and software business in implementing green ICT practices, which then serves as a foundation for building a green ICT ecosystem. As such, this study employed a survey-based investigation methodology to collect data and gain insights on why organizations are interested in green ICT and the barriers to green ICT adoption so that support systems can be provided for these organizations towards realizing Finland’s 2035 carbon-neutrality ambition. For this reason, we used an explorative and qualitative research method [10] focusing on the motivations and challenges of Finnish-based organizations to adopt green ICT practices. We chose the qualitative approach because of the size of respondents and since generalization of the findings was not the focus. We designed a semi-structured questionnaire to collect data from 36 respondents. The primary data was collected in Finnish language from employees of different sizes of ICT and software related organizations through Webropol, an online survey tool, between September and October 20211 . We adopted a non-probabilistic convenience sampling and snowballing strategy [11], to reach as many potential respondents as possible based on the following criteria: (i) the respondents’ organizations must be stakeholders in the ICT and software business, (ii) the respondents’ organizations must be Finnish-based and (iii), the organizations must be conducting business or have presence in the Uusimaa region. The rationale for meeting these criteria was because the results of this study will form the basis to orchestrating a green ICT ecosystem in the Uusimaa region of Finland. Based on the set criteria, we sent the link to the survey questionnaire to 1850 separate emails out of which 36 people completed the survey. Among the 36 respondents, only 16 preferred to mention their gender, roles and company of affiliation which consisted of 4 Top level managers (all male), 9 Middle-level managers (4 females) and 3 Specialists (2 females). These 16 respondents represented 3 state-owned organizations, 5 public enterprises and 8 private businesses. Finally, two of the authors who are native Finns translated the answers and compared them with the text in Finnish to ensure that we retained the original meaning and content. Miro board and NVivo software were employed to code and analyze the survey responses based on the research questions. We formulated the following two research questions to help fulfill the research aim: RQ1: What factors drive ICT firms towards adopting green ICT practices? RQ2: What are the barriers to green ICT adoption among organizations during digital transformation?
1 Research data available at http://lnnk.in/driy.
340
L. Abdullai et al.
4 Results Under this section, we present the survey responses considering the research questions. RQ1: Organizations’ Motivations in Adopting the Green ICT Although the questions in our survey did not directly ask respondents about their motivations for adopting green ICT, motivation as a theme emerged through our exploratory analysis. For example, when asked whether the organizations were interested in acquiring green ICT products and services, 29 out of 36, thus, almost 81% of organizations who responded to this question showed their motivation to procure green ICT products and services. Either “at approximately the same price range or more expensive”. Similarly, we asked respondents to choose what kind of green ICT products or services their organizations are interested in purchasing of which “carbon neutral products and services”, “recycled equipment”, “equipment made from recycled materials”, or “services and products that reduce the carbon footprint of our business”. Overall, we observed that respondents’ motivation towards green ICT revolved around carbon-neutrality commitment, climate and environmental responsibility, CSR fulfillment, energy efficiency, and optimizing premise usage. RQ 2: Organizations Support Needs in Implementing Green ICT Initiatives The results revealed the lack organizational policy and strategy on green ICT as one of the main challenges of adopting green ICT in organization as summarized in Fig. 1. We asked respondents whether their organizations have tried to procure Green ICT services or products but have not found supply in the market? 75% of the respondents answered, “we have not attempted to acquire green ICT services or products so far.” On the other hand, 6 respondents answered that “we have tried to find Green ICT services, but we have not found them…”. Another interesting result from the survey worth noticing is the issue of monitoring energy consumption and emission. When asked whether the organizations monitor the energy consumption of their information and communication technologies, 19 out of 36, representing 53% of the organizations, said they do not monitor their energy consumption. Similarly, 18 respondents mentioned that “the principles of reducing emissions are not taken into account in tenders and procurement.” Furthermore, the results show that the lack of trained sustainability experts in organizations is also a challenge in adopting green ICT as 77% of the respondents. Finally, when asked whether employees in their organizations are trained in using equipment following Green ICT principles said, “we do not train our staff in the use of equipment in accordance with Green ICT”. Finally, we identified the lack of budget allocation for Green ICT transformation as another challenge when 86% of the respondents stated that” we do not take Green ICT into account when budgeting”. Threat to Validity Construct validity refers to the extent to which the operational measures that are studied represent the researcher’s objective and whether they asked the research questions correctly [12]. All three authors are part of the nine-member green ICT ecosystem project team and were involved in drafting the survey questionnaire. Internal validity: Internal
Green ICT Adoption and Challenges: Evidence from the Finnish ICT Sector
341
Fig. 1. Challenges of adopting Green ICT practices in organizations
validity refers to unforeseen factors that might influence the study’s outcome that the researchers are unaware [12, 13]. One possible threat is the bias in interpreting and analyzing the survey findings. Hence, during the data analysis of the responses, the authors first discussed the survey questions among themselves to ensure that we did not go out of the scope of our research questions. Based on this iterative process, we are confident that the potential bias of a single author was minimized. External validity: This aspect of validity refers to the extent to which the findings of this study can be generalized and to what extent the findings are of interest to other people outside the investigated case [12, 13]. As with all qualitative studies, the results of this study cannot be generalized because the number of respondents is not representative of the entire ICT sector. As such, there is the possibility that had there been more responses to the survey, different themes and insights might have emerged. However, given the rigorous process that we followed, we are confident about the findings that emerged from this study.
5 Discussion and Conclusion The results showed an interesting trend in what motivates organizations to adopt green ICT practices (RQ1). We noticed that most of the organizations’ interests were related to the environment and social factors while and governance factors which concern the alignment of sustainable digital transformation strategies with the organization’s sustainability goals, were least considered. Again, we realized that respondents did not mention economic reasons such as competitiveness or demand and supply factors as shown in [8]. Perhaps, organizations see investment in green ICT as cost-draining investment and could not promise shareholders on the return on their investment (ROI) in green ICT. Regarding RQ2 (Challenges in adoption green ICT), we can categorize the challenges to internal and external challenges. The lack of alignment of green ICT initiatives with corporate strategy, lack of sustainability awareness, training, and resources as well as the lack of green ICT expertise and budget allocation could be addressed by management. Leaders must support their organizations’ green ICT interests with solid commitments and clear corporate strategies [2]. Furthermore, organizations need support systems from
342
L. Abdullai et al.
other ICT stakeholders to overcome the external challenges such as the accessibility to market and green ICT best practices. Despite Finland setting ambitious goal to achieve carbon neutral by 2035 and announcing climate strategy for the ICT sector, organizations still have challenges in adopting green ICT principles. This also comes as a surprise despite organizations expressing motivations and interest in at least environmental and social dimensions of sustainability. We envisage that, when organizations continue to face challenges in implementing their green ICT initiatives due to for instance unavailability of best practices, trained human resource, guide on how to develop green ICT initiatives that is aligned with their digital transformation strategies, overtime, motivation to adopt and implement green ICT practices will decrease and eventually abandoned. In other words, the success of green ICT implementation in organization depends not only on the motivations but also on the availability of resources, commitments from company leadership, and having an ecosystem where organizations can learn, share best practices, and source green ICT and software solutions. Overall, this study supports the relevance of creating green ICT awareness [14] and the need to build a green ICT ecosystem where various stakeholders collaborate to cocreate and co-design sustainable ICT products and services to ensure the convergence of sustainability and digital transformation. This will provide organizations better opportunities to innovate sustainably, reduce their negative environmental impact and leverage the power of co-creation and co-design of the ecosystem to remain competitive. From this study, several future research directions emerged. As our study is based on limited survey participants, another exciting avenue will be to include interviews and company annual reports to compare statements on sustainable digital transformation and actual commitments on those initiatives. Also, another avenue is to investigate the implementation of sustainable digital transformation among organizations operating in countries with climate strategy for the ICT sector and those operating in countries without government policy on sustainable ICT. Acknowledgements. This research is part of the Green ICT Ecosystem project: boosting competitiveness and sustainability of businesses in the Uusimaa region. The project has received funding from the European Regional Development Fund under REACT-EU programme grant number 2014–2021. The authors in this publication accept all responsibilities for the content and views expressed in this study and that the results and conclusions do not reflect the opinions of the funders.
References 1. Ojala, T., Mettälä, M., Heinonen, M., Oksanen, P.: The ICT sector, climate and the environment (2020) 2. Bachour, N., Chasteen, L.: Optimizing the value of green IT projects within organizations. In: IEEE Green Technologies Conference, pp. 1–10 (2010). https://doi.org/10.4018/978-14666-4153-2.ch062 3. Blair, G.S., et al.: The role of digital technologies in responding to the grand challenges of the natural environment: the windermere accord. Patterns 2(1), 8 (2021). https://doi.org/10. 1016/j.patter.2020.100156
Green ICT Adoption and Challenges: Evidence from the Finnish ICT Sector
343
4. Hassan Thabit, T., Sid Ahmed, H.A., Jasim, Y.A.: The impact of green ICT adoption in organizations of developing countries. Al-riyada Bus. Econ. J. 07, 9–18 (2021). https://ssrn. com/abstract=3764001 5. Hernandez, A.A.: Exploring the factors to green IT adoption of SMEs in the Philippines. J. Cases Inf. Technol. 20(2), 49–66 (2018). https://doi.org/10.4018/JCIT.2018040104 6. Chai-Arayalert, S., Nakata, K.: The evolution of green ICT practice: UK higher education institutions case study. In: Proceedings - 2011 IEEE/ACM International Conference on Green Computing and Communications, GreenCom 2011, pp. 220–225 (2011). https://doi.org/10. 1109/GreenCom.2011.45 7. Loeser, F., Recker, J., vom Brocke, J., Molla, A., Zarnekow, R.: How IT executives create organizational benefits by translating environmental strategies into Green IS initiatives. Inf. Syst. J. 27(4), 503–553 (2017). https://doi.org/10.1111/isj.12136 8. L. D. Radu, ‘Determinants of green ICT adoption in organizations: A theoretical perspective’, Sustain., vol. 8, no. 8, 2016, doi: https://doi.org/10.3390/su8080731 9. Ara, F.: Barriers to implement green ICT in Bangladesh: a study on organizations. Int. J. Comput. Appl. 179(34), 43–47 (2018). https://doi.org/10.5120/ijca2018916775 10. Dybå, T., Prikladnicki, R., Rönkkö, K., Seaman, C., Sillito, J.: Qualitative research in software engineering. Empir. Softw. Eng. 16(4), 425–429 (2011). https://doi.org/10.1007/s10664-0119163-y 11. Kitchenham, B., Pfleeger, S.L.: Principles of survey research (parts 1–6). ACM SIGSOFT Softw. Eng. Notes 26(6), 16–18 (2001) 12. Runeson, P., Höst, M.: Guidelines for conducting and reporting case study research in software engineering. Empir. Softw. Eng. 14(2), 131–164 (2009). https://doi.org/10.1007/s10664-0089102-8 13. Wohlin, C., Runeson, P., Höst, M., Ohlsson, M.C., Regnell, B., Wesslén, A.: Experimentation in Software Engineering. Springer, Heidelberg (2012). https://doi.org/10.1007/978-3-64229044-2 14. Din, N., Haron, S., Ahmad, H.: The level of awareness on the green ICT concept and self directed learning among Malaysian Facebook users. Procedia Soc. Behav. Sci. 85, 464–473 (2013). https://doi.org/10.1016/j.sbspro.2013.08.375
Digital Transformation Towards Sustainability: A Case Study of Process Views in District Heating Alisa Ananjeva(B)
, John Stouby Persson , and Peter Axel Nielsen
Department of Computer Science, Aalborg University, Selma Lagerlöfs Vej 300, 9220 Aalborg Øst, Denmark [email protected]
Abstract. Digital transformation (DT) has the potential to change our society toward the United Nation’s sustainable development goals. However, developing software for the DT towards sustainability is a complex process that may entail an emphasis on optimization, eco-feedback, reflection, and participation. This paper contributes to a better understanding of how organizations navigate this complexity of different process views with a case study of a DT in district heating. Based on ten interviews with a software development company, eight interviews with a district heating supplier, and 14 interviews with consumers, we analyze the process views on their DT. This analysis shows how organizations navigate the different process views in a DT journey when encountering and solving problems. We conclude the paper by providing propositions on what navigating DT implies. Furthermore, we discuss how these insights can help practitioners navigate different process views and how our findings nuance the understanding of the DT process. Keywords: Digital transformation · Process views · Navigating · Sustainability
1 Introduction Climate change is one of the greatest challenges of our time, and digital transformation (DT) has great potential to enable sustainable development [1, 2]. In the face of climate change, the scope of DT is expanding, including an increased focus on society and the individual and their role in sustainable development [3, p. 1]. In this process, digital technology can be seen as “a contributor and a potential solution to environmental degradation” [4, p. 1278]. That being said, the DT process towards sustainability is a tortuous journey with many proposed solutions, including optimizing the life cycle of the physical and digital artifacts [5], pro-active strategies [6], infrastructuring [7, 8], and increasing people’s engagement in sustainability [9]. This diversity illustrates the wickedness of the climate change problem [10]. Wicked problems are “problems for which no single computational formulation of the problem is sufficient, for which different stakeholders do not even agree on what the problem really is” [11, p. 45]. We have identified four streams of literature with distinct process views on the DT towards © The Author(s), under exclusive license to Springer Nature Switzerland AG 2022 N. Carroll et al. (Eds.): ICSOB 2022, LNBIP 463, pp. 344–358, 2022. https://doi.org/10.1007/978-3-031-20706-8_25
Digital Transformation Towards Sustainability
345
environmental sustainability: optimization, eco-feedback, reflection, and participation. These processes differ in their view on the problem, solution, and sustainability. Thus, there is no silver bullet and no clear path that helps organizations navigate sustainable development – the practitioners must manage problems and solutions that unfold in realtime. However, the literature falls short in describing how this dynamic process develops over time. Against this backdrop, we present our research question: How do organizations navigate the different process views in the digital transformation towards sustainability? To answer our research question, we conducted a longitudinal single-case study [12] of the DT of district heating [13] in a municipality in North Jutland, Denmark. In this case study, we followed the development of the Green Assistant - an application that provides hourly consumption data on heat, water, and electricity. This application is developed in a partnership between multiple organizations. In this article, we follow two organizations – Joules A/S (a software development company) and NortHeat (the heating domain expert) – and how they navigate the different process views in their DT journey. Furthermore, we interviewed district heating consumers in NortHeat’s municipality to understand how the solutions made in the partnership influenced them. With this case study, we build and illustrate a theory of how organizations can navigate the different process views in a DT journey. We use the distinction between the four identified process views – optimization, eco-feedback, reflection, and participation – to build a theory of multiple process views on DT towards sustainability. Furthermore, we provide propositions on what navigating DT implies. These insights can help practitioners navigate different process views on DT and nuance the understanding of the DT process. Lastly, we present limitations of our study and an agenda for future research.
2 Process Views on DT Towards Sustainability In the relevant literature, we identified four process views that illustrate how the processes of DT towards sustainability can unfold: Optimization, Eco-feedback, Reflection, and Participation. The optimization process view on DT towards sustainability promotes effectiveness and efficiency. Using fewer resources is seen as competitively and economically beneficial, e.g., optimizing resource-excessive services [14]. For example, in a study of support systems for transport logistics, focusing on sustainability reporting and analysis, it was found that a support system could reduce CO2 emissions by 80% in a year [14]. From the optimization perspective, transforming the physical infrastructures through digital technology contributes to organizational and governmental sustainability goals [14–16]. However, these interventions require significant investments, and the lack of adoption of these technologies can undermine this investment in sustainable technology [16]. Thus, this process view is also concerned with how people can adopt these technologies and live up to the technology’s potential to support sustainable consumption. The eco-feedback process view on DT towards sustainability promotes behavioral change through consumer data. The Eco-feedback process is built on the assumption that people will act per the information available and consume in a manner that “provides them with the most personal gain at the least personal cost” [17, p. 2136]. From this process view, the purpose of digital technology is to provide meaningful information about
346
A. Ananjeva et al.
consumer consumption [18]. Furthermore, it is argued that digital technology can help change consumers’ perceptions of energy and increase energy literacy [19]. Consumers can learn about energy by following their consumption data over time [19]. However, it has also been shown that some consumers have difficulty understanding and acting upon the information [17]. Thus, it is essential to consider how this information should be visualized to become meaningful, thus leading to sustainable consumer behavior. The reflection process view on DT towards sustainability promotes challenging the status quo through design towards deliberate practices. The reflection process view advocates that digitalization at a societal level ought to change social practices and initiate reflection as a prerequisite for social change [20]. The reflection process view advocates a thorough understanding of everyday practices (e.g., cleaning and cooking) to challenge the unsustainable structures that shape them [21, 22]. From this process view, the prevailing practices characterized by instant service, high quality, and ubiquity are unsustainable [23]. The proposed solution is to make the consumers reflect on their consumption practices and increase their awareness of environmental sustainability [24, 25]. Thus, the reflection process view is about learning, awareness, and deliberate practices. The participation process view on DT towards sustainability promotes achieving change through increased people’s engagement. Organizations can lose the users’ process view and limit users’ experiences with sustainable technologies in the race towards effectiveness. A proposed solution regards involving citizens in designing through codesigning activities, thus democratizing digital solutions [26] or introducing a sustainability champion - a person who fights for sustainable values - to disseminate sustainable values among the employees [27]. In this view, the role of digital solutions is not to feed information passively to the consumer but to give a space where experiences and assumptions can be challenged and shared [9]. Thus, enabling decision-making and developing a capacity to act sustainably [28, 29]. Furthermore, when stakeholders share experiences, this allows for critical reflection [30] and mutual inspiration, strengthening the community feeling [31]. In this process view, human engagement in sustainable development becomes the key to achieving sustainability. Therefore, digital technology assumes a supportive role in establishing shared values, practices, activities, and knowledge. We have summarized and operationalized the four process views by identifying their different success criteria for developing software for DT towards sustainability (see Table 1). These different process views offer alternative explanations of the problem, the solution, and sustainability. The alternative explanations to the climate change problem are inevitable because “there are no right or wrong answers, only answers that are better or worse from different points of view” [11, p. 45]. Thus, we theorize that DT towards sustainability is a single process [32, p. 121] that can unfold in a multiplicity of ways [33].
Digital Transformation Towards Sustainability
347
Table 1. The process views on the digital transformation towards sustainability Process views The problem, the solution, and view on sustainability Optimization
The problem is that people are bound by unsustainable processes, infrastructures, and services The solution is a continuous search for processes, infrastructures, and services to enhance Sustainability pertains to efficiency and effectiveness
Eco-feedback The problem is that people are unaware and, therefore, less sustainable The solution is to provide actionable consumption feedback to increase environmental literacy Sustainability is actionable information Reflection
The problem is that people are bound by the status quo The solution is to create provocative and speculative designs to challenge the status quo Sustainability is a radical change in the state of mind
Participation
The problem is that people are not activated or engaged The solution is to increase people’s engagement in design activities and design to support sustainable user activities Sustainability is increased human engagement
3 Method To unfold the four process views on DT towards sustainability, we conducted a longitudinal single case study [12] of how NortHeat and Joules A/S navigate different process views on the DT of district heating. Our units of analysis were problem-solving actions, and to identify what actions constitute the different process views, we applied the success criteria for DT towards sustainability (see Table 1). One way of capturing a process is through narrative [34]. Therefore, in our inquiry into actions that constitute the DT of the district heating process, we conducted narrative interviewing [35] with several relevant stakeholders from both organizations over two years. The relevant stakeholders were organizational employees who had a decisive role that impacted how both organizations navigated the different process views. Based on this criterion, we interviewed the CEO at Joules A/S, the R&D Section Manager from Joules A/S, the Head of Energy Supply, and the IT Project Manager from NortHeat (see Table 2). The interviews’ purpose was to gather insight into how the two organizations viewed and solved situated problems that guided this DT journey. This DT journey started in 2018 as a collaboration between NortHeat and Joules A/S to exploit data from the installed smart meters in the district heating area’s 110.000 households. NortHeat has been working towards producing renewable energy heat and sought to transform district heating digitally. Therefore, NortHeat partnered with Joules A/S – an electricity provider and an application developer. They did not buy or sell services or products from each other. Instead, they pooled their resources and capabilities into developing a consumer-oriented mobile application for tracking and predicting heat consumption. Joules A/S benefited from this collaboration regarding data access, a large
348
A. Ananjeva et al. Table 2. The number of interviews and the stakeholder description
Data collection
Stakeholders
Joules A/S 10 Semi-structured interviews (February 2020–February 2022)
• 5 × Section Manager responsible for R&D • 3 × Section Manager responsible for partnering with Utility companies • 2 × CEO responsible for vision and mission for Joules A/S
NortHeat • 5 × Project Manager responsible for Green Assistant 8 Semi-structured interviews roll-out (September 2020–February 2022) • 2 × IT-Project Manager responsible for digital infrastructure • 1 × Head of Energy Supply er responsible for providing vision and mission for the DT of district heating Green Assistant users 14 Semi-structured interviews (April 2020–November 2020)
• 2 × Finn, a Construction Engineer – uses the app monthly • 2 × Svend, a Municipal Worker – uses the app weekly • 2 × Anne, a Municipal Worker – uses the app daily • 2 × Erik, a Taxi Driver – uses the app monthly • 2 × Karen, a retired Secretary – uses the app monthly
user base, and expertise in district heating. NortHeat, on the other hand, benefited from access to skilled developers and an already working solution that had proven its worth for electricity consumption. Nevertheless, both organizations shared an overall concern for sustainable energy consumption in their digitalization efforts. Yet, as shown by the subsequent unfolding of the four process views, they still entailed ambiguity when navigating the more specific concerns in practice. Furthermore, we have conducted two rounds of semi-structured interviews with seven citizens of NortHeat’s municipality (see Table 2). We used insights from these interviews to illustrate how the consumers perceived the solutions made in the partnership. For all the interviews, we used interview guides and recorded them through Microsoft Teams or a recording device (the interview guides will be provided on request). In our analysis of the interviews, we identified problem-solving actions conducted by various stakeholders that illustrate how organizations navigate the different process views on the DT towards sustainability through the following steps (adapted from [36]): 1) We listened to all recordings, transcribed them, and read the transcriptions to familiarize ourselves with the empirical data. 2) Critically identify quotes in the data and code these appropriately in relation to the four identified process views (see Table 1): i)
We searched for problems, solutions, and views on sustainability in the empirical data.
Digital Transformation Towards Sustainability
349
ii) We operationalized four process views by codifying their different success criteria for developing software for sustainability (e.g., the optimization process view had codes such as service, infrastructure, process, efficiency, and effectiveness). iii) We checked if the identified problems, solutions, and different views on sustainability work in relation to the identified four process views (e.g., if a quote referred to any kind of efficiency and effectiveness, we related it to optimization). 3) The chosen quotes were analyzed to illustrate how organizations navigated this DT journey: i) We searched for decisive action in the DT process that enabled the organizations to continue their journey (e.g., reciprocating each other’s process views). ii) From these actions, we have abductively [37] elicited three propositions on what navigating DT towards sustainability entails.
4 Analysis In the following sections, we unfold how NortHeat and Joules A/S navigate the four process views in their DT journey. In addition, we incorporated the consumers’ experience with the Green Assistant to gain an understanding of how the actions made in the partnership influenced and were perceived by the consumers. 4.1 The Optimization Process View The optimization process promotes effectiveness and efficiency; sustainability is viewed as using fewer resources to complete a task. This process view was pervasive in Green Assistant and NortHeat’s actions and overall vision for their DT journey. One of the significant challenges was unreliable access to consumption data. NortHeat was ambitious to create a digital service that offers consumers fast and frequent consumption data; thus, they installed smart meters in 110.000 households. The old flow-based system did not support the new task of providing consumers with a frequent and detailed consumption overview. The new smart meters could provide each household’s heating data hourly; thus, it was essential to ensure that data flow is constant and seamless to the consumer: Our largest challenge, almost from day one, is the delay in the data. Sometimes it’s two days, and it’s funny because that’s fast compared to what we are used to, but the consumer, for instance, is used to looking things up on Facebook and not having to wait days before it gets into the app (Head of Energy Supply, NortHeat). The Head of Energy Supply at NortHeat describes this optimization challenge as an issue of consumers’ expectations towards what is immediate consumption. He believes that consumers’ expectations are formed by using other digital technologies, not their current heating practices. Therefore, the organization sought to make a robust digital infrastructure without delay in data. As a result, the two organizations – Joules A/S and NortHeat – had a workshop in which they jointly solved this optimization problem:
350
A. Ananjeva et al.
We make linear smoothing of data and other calculations before sending data to Joules. Our role is to make sure that Joules receives quality data that fits with their neural network, which makes “the budget” (IT Project Manager, NortHeat). After the workshop, the two organizations designed a solution that accommodated the needs of both organizations. When receiving smart meter data from the third-party data supplier, NortHeat processed the received data to accommodate the digital infrastructure at Joules A/S. Thus, NortHeat ensured the best possible consumer experience with the Green Assistant. This optimization issue is currently partially resolved. The delays in data are still occurring; however, these occurrences are less frequent and less perceivable by the consumers. Furthermore, as described by the R&D Section Manager, the goal of this DT journey is a complete automatization of energy flow in a household: We have a saying at our parent organization – “We create energy to live life.” This sound fluffy, but we want to help people so that it becomes easy to live their lives. We want to take care of everything else and try to make it as green as possible – complete automation of the energy flow in the home (R&D Section Manager, Joules A/S). The ambition to automate the energy flow in the home presents an insight into how Joules A/S perceives sustainability and the consumers’ role in the sustainability movement. Sustainability is viewed as an automated and reduced energy flow in a household. Thus, from the optimization process view, the part of a consumer becomes passive – they should be able to live their lives while the optimized infrastructure supports their everyday practices. This view is shared by Finn, a construction engineer: It would be way more convenient to buy something that could be more efficient, and then you wouldn’t have to think about it again for some time (Finn, Interview 1). Finn prefers not to frequently interact with his energy system, which endorses Joules A/S’s ambition to create a “complete automation of the energy flow in a home.” During the optimization process, the two organizations navigated through consumers’ expectations of digital services and the limitations of the digital infrastructure. 4.2 The Eco-feedback Process View The eco-feedback process view on DT towards sustainability promotes behavioral change through consumer data; sustainability is viewed as actionable information enabling energy-conservation behavior. The eco-feedback process view is predominant when NortHeat and Joules A/S are working on solving a need to increase the consumers’ energy literacy about heat and sustainability. One of the significant challenges from this process view is communicating consumption in an understandable and actionable way. This challenge is particularly evident in how to communicate sustainable consumption. Initially, the consumption was provided through a budget. However, providing the monetary value of the consumption does not necessarily promote conservation behavior – the assumption is that if the energy is cheap, people will use it. A proposed solution was to communicate the CO2 emissions of a household. However, this solution is limited by the consumers’ (lack of) knowledge about the CO2 emissions: CO2 is difficult to understand. A hundred grams CO2 , how much is it? We see our task to explain consumption differently. We can tell you how green you are. But how do we define “green”? One way is to show a percentage in reduction. This is at least
Digital Transformation Towards Sustainability
351
something we hear a lot about and something that could be more intuitive for consumers (R&D Section Manager, Joules A/S). Joules A/S found that the CO2 emissions are not intuitive for the consumers and are challenging to understand and act upon. This solution is not feasible from the ecofeedback process view, which emphasizes the actionability of the information. Therefore, Joules A/S, in collaboration with NortHeat, is currently working on solving this energyliteracy issue. In heating, one of the eco-feedback issues is teaching the consumers what good and sustainable heating consumption is. Joules A/S and NortHeat work iteratively on finding a design that provides enough information so that the consumer understands the nuances of heating consumption and can act on it: First, we did some reasonably complex mock-ups and ran a demo for NortHeat. And we were told that “It may be too complex, they [consumers] cannot understand it,” - so we took a few iterations where we cut it to simplify it (CEO, Joules A/S). As exemplified in the quote by the CEO of Joules A/S, providing enough information without increasing the complexity of the Green Assistant is a tricky balance to find. In navigating this issue, Joules A/S relies on NortHeat’s understanding of the heating domain and its consumers. Both organizations are collaborating on designing a solution that balances the need for simplicity and detail. That being said, this issue does not only belong to the heating domain - balancing simple and detailed eco-feedback is an issue within all areas of energy and resources (water and electricity): We swing a lot between different extremes when we design this app; it should be as simple as possible, but […] if we have any relevant information, we should not hide it (Pod Owner, Joules A/S). As described by the Pod Owner from Joules A/S, identifying the balance between simplicity and detail is an iterative process, which requires reflection from the designers and developers. The reflection regards identifying what is relevant information and how it could be presented without increasing the complexity. However, the interface of an application can also become too simple. For example, Svend became frustrated while using the Green Assistant because he could not get the information the way he was used to: I don’t understand why they’ve chosen to show consumption as money spent. Down on my meter, it’s written in m3 and temperature, but there’s no simple way to show that in Green Assistant unless you, of course, download the raw data, but then I might as well read [the meter] myself (Svend, Interview 2). Svend is a knowledgeable consumer who was already frequently interacting with his energy system. Svend argues that presenting the consumption as money spent did not necessarily represent actual consumption. His understanding of relevant information is firmly rooted in his previous experience with his heating system – going down to his cellar to read his meter, which provided the consumption information in m3 and inflow temperature. Svend’s assessment of the application illustrates how difficult it can be to balance the needs of consumers with varying levels of knowledge. In the eco-feedback process, the two organizations navigated the delicate balance between the consumers’ knowledge about sustainability and what is perceived as relevant information by the consumer.
352
A. Ananjeva et al.
4.3 The Reflection Process The reflection process view on DT towards sustainability promotes challenging the status quo through design towards deliberate practices. In our case, deliberate practices imply a greater consciousness about energy production and consumption. The status quo to be disrupted is how consumers understand energy consumption and their role in energy production, consumption, and trading. The reflection process view is predominant when Joules A/S presents its vision for the future of electricity in Denmark: The next thing we look at is energy communities; if a household has too much electricity, then it should be able to sell it to its neighbor. Why should we not be able to make use of surplus energy and sell it at better prices while alleviating the electricity grid? Something should be done about that, and we view it as our future mission (R&D Section Manager, Joules A/S). As described by the R&D Section Manager from Joules A/S, the ultimate goal of this DT journey is to disrupt the energy system. They view the disruption as democratizing energy trading and deliberate peer-to-peer trading, enabling a stronger energy community. Joules A/S views its role as a mediator promoting and supporting the energy community. However, NortHeat does not have the same ambition: We do not have an exaggerated expectation that consumers will have to sit daily and trade energy. The energy flow must run automatically, but consumers must be involved somehow (Supply Manager, NortHeat). As described by the Supply Manager at NortHeat, they view the end goal of this DT journey as a full automatization and an increased involvement of the consumers. This difference in the end goal may be due to differences in the resources the organizations produce. For example, Joules A/S is a daughter company of a larger electricity concern in Denmark, and electricity is one of the resources consumers can produce themselves. NortHeat is, however, among other things, a heat provider. Unfortunately, heat is a resource that is difficult to make and trade peer-to-peer. Furthermore, from the reflection process view, consumer involvement implies changes in practices towards more deliberate energy consumption through the Green Assistant. Anne is an illustrative example of how an application can change consumers’ practices: You bet it has worked […]! It’s almost a game for us, you know, getting to the next level by using less than the day before […]. [When] it was a bit cold in the morning, I thought “no” to myself. Because I can read the heat consumption, I choose to put on one more sweater instead of turning up the heat (Anne, Interview 1). Anne explains that her heating practices were changed due to the Green Assistant, e.g., putting on a sweater instead of turning up the heat, thus, enabling a more deliberate energy conservation practice. With this process view, we illustrate how two organizations can have different aspirations for the DT journey while collaborating. In the reflection process, the two organizations navigated by accepting different end-goals of the journey. 4.4 The Participation Process View The participation process view on DT towards sustainability promotes achieving change through increasing people’s engagement. This process view is predominant in how
Digital Transformation Towards Sustainability
353
NortHeat and Green Assistant’s A/S view the consumers’ role in the sustainability movement. In the sustainable transition of district heating, consumer engagement is vital because energy use and energy production are mutually dependent – a utility company must supply energy that meets the consumers’ demand. Therefore, they are not just passive stakeholders but critical actors that can further or hinder this sustainability transition: The system is as strong as its’ weakest link. […] Consumers must be a part of this transition, but that is a difficult task. For the past ten years […], we have looked into it and found that there’s almost nothing as uninteresting for people as energy use in their houses. […] So, our task is to get consumers more engaged (Supply Manager, NortHeat). The Supply Manager sees the consumers as the weakest link in this sustainable transition. NortHeat’s decade-long experience has shown that consumers are not interested in their heat consumption, and increasing engagement is not an easy task. Therefore, in distributing the Green Assistant, NortHeat is trying to increase the consumer’s interest. Both NortHeat and Joules A/S see this task as one of the shared goals of this DT journey: Our goal is to engage our customers and help them become more sustainable. But more importantly, to make it easy for them to do and be green (R&D Section Manager, Joules A/S). The R&D Section Manager at Joules A/S emphasizes the need to engage the consumers to act sustainably and “more importantly” make it easy to do and be sustainable. This emphasis on easiness demonstrates that Joules A/S does not view engagement as activism, which might imply radical and ongoing action for change. Instead, Joules A/S views engagement as a long-term commitment to sustainable living by investing in automation (e.g., smart thermostats or smart power outlets). This view is based on the assumption that consumers, on average, are not willing to engage with their energy system often and deliberately. For example, Erik, a taxi driver, used the application to engage more with his heating system from a more informed position: Yeah, it’s nifty because I usually can see […]whether we’re good or bad that day and if we need to improve. If it’s red, I probably have to turn down the thermostats or something. Before, you didn’t really have a clue (Erik, Interview 1). Another way Joules A/S and NortHeat have engaged the consumers in this DT journey is by viewing them as co-creators. For example, NortHeat has a focus group of consumers commenting on interface design in the Green Assistant. Furthermore, NortHeat and Joules A/S use customer support to gain consumer feedback on their experience with the application for future application iterations. The participation process view presents a new insight into consumers’ role in navigating this DT journey. The consumer is essential in this journey in two ways. Firstly, the consumer’s engagement in DT is vital because energy use directly influences how energy is produced. Secondly, the consumers are value co-creators by helping identify new ways of improving the application.
5 Discussion There is no clear path that helps organizations navigate sustainable development because “there are no right or wrong answers, only answers that are better or worse from different points of view” [11, p. 45]. Thus, a DT process towards sustainability can unfold
354
A. Ananjeva et al.
in a multiplicity [33] of ways (see Table 1), which increases the process’s complexity. We theorize that this process consists of at least four process views: optimization, eco-feedback, reflection, and participation. In illustrating our theory through a longitudinal case study, we found that the DT towards sustainability is a process that can non-sequentially encompass all four process views. In the relevant literature, process views can be perceived as mutually exclusive. For example, the eco-feedback process view is criticized for viewing people as rational and autonomous. The critique is that designers and software developers fail to recognize that human consumption “is shaped by infrastructures, technologies, and institutions” [17, p. 2136]. However, our process theory of four views on DT suggests that all four process views can be present in a DT process without being mutually exclusive – a single journey can have multiple paths toward the desired outcome. Based on our illustrative case study, we present three propositions on what the process of navigating a DT journey implies: Involvement of Multiple Stakeholders that Reciprocate Each Other’s Process Views: In our case of DT towards sustainability, the organizations pooled their resources and capabilities into a solution meeting the needs of both organizations and the consumers. For example, NortHeat processed the received data to accommodate the digital infrastructure at Joules A/S. This finding supports previous research stating that the DT process goes beyond the collaborative efforts of a single team, a single organization, or a single project process [38]. Developing software for DT requires involving customers in becoming value co-creators [39, 40] and establishing strategic partnerships with external organizations [41]. To successfully navigate a DT journey, the partnering organizations must collaboratively move towards a shared vision [42]. In the case we studied, this collaboration implied the different stakeholders reciprocated each other’s process views. For instance, Joules A/S and NortHeat view consumer engagement as a long-term commitment to sustainable living by actively investing in automation and participation, which is also evident in their effort to increase the consumers’ energy literacy about heat and sustainability through eco-feedback. Responding to Turbulence in the Environment While Encompassing Multiple Process Views: In navigating the DT towards sustainability, the two organizations had to deal with turbulence in the environment. Turbulence is the condition of “unpredictability in the environment because of rapid changes in customer needs, emerging technologies, and competitive actions” [43, p. 444]—for example, the consumers’ expectations towards what is immediate heating consumption. The two organizations recognized that consumers’ expectations were formed by using other digital technologies, and their digital infrastructure needed further development to solve this problem. Thus, our case study corroborates the previous research that responding to turbulence or changes in the environment is a vital organizational capability in a DT process [44]. However, we add that successfully responding to the turbulence in the environment encompasses multiple process views. For example, while responding to the consumers’ expectations, the organizations simultaneously (i) accommodated what consumers view as immediate eco-feedback, (ii) sought to increase (and accommodate) the consumers’ energy literacy, (iii) supported (and challenged) consumers energy practices, and (iv) involve the consumers as co-creators or value. Thus, in terms of process multiplicity theory [33],
Digital Transformation Towards Sustainability
355
responding to the turbulence in the environment can open the space of possible paths to follow, which helps in discovering paths not yet taken. Reassessing the Past Process with Different Views to Adjust the Plan of Action: We found that navigating DT is not a simple sequential process; it is an ongoing reassessment of past process views to adjust the course for the future. For instance, the Green Assistant provided consumption through monetary value, which did not further the overall goal of the two organizations to engage the consumers to act sustainably – navigating in the ‘wrong’ direction. The two organizations had to reassess the decisions made in the past to identify a new way of providing consumption information in a manner that promotes sustainable behavior. A single decision is not self-contained; it changes over time and has consequences for future work. Our third proposition thus corroborates the process multiplicity theory [33] that the past carries the potential for what can happen in the future [33, 45]. Our findings are helpful for practitioners in two ways. Firstly, organizations should be aware that there are multiple process views. This awareness can contribute to developing more multifaceted software that addresses more than one problem. Secondly, when collaborating with other stakeholders on developing software for the DT, simply being aware of other processes’ views is not enough. To successfully navigate the DT process, the organizations must i) reciprocate each other process views, ii) respond to the turbulence with a multiplicity of process views, and iii) reflectively reassess the past to improve and plan for the future. Our process theory has limitations that invite future work. The first limitation is regarding the small scale and scope of our inquiry. For example, we examined two organizations in Denmark’s district heating context and how they collaborate in navigating their DT journey. Therefore, exploring whether our findings are scalable and transferable to other DT journeys, e.g., waste sorting [46] or the transport sector [47] would be interesting. The second limitation is the focus on problems and solutions – there might be another way of differentiating the paths in the DT process. For example, a literature review [48] distinguishes the processes in DT by identifying the advantages and disadvantages. We, however, did not find any of the process views superior to the others.
References 1. Hasan, H., Smith, S., Finnegan, P.: An activity theoretic analysis of the mediating role of information systems in tackling climate change adaptation. Inf. Syst. J. 27, 271–308 (2017) 2. Thomas, O., Hagen, S., Frank, U., Recker, J., Wessel, L., Kammler, F., Zarvic, N., Timm, I.: Global crises and the role of BISE. Bus. Inf. Syst. Eng. 62(4), 385–396 (2020). https://doi. org/10.1007/s12599-020-00657-w 3. Ågerfalk, P.J., Axelsson, K., Bergquist, M.: Addressing climate change through stakeholdercentric information systems research: a Scandinavian approach for the masses. Int. J. Inf. Manag. 63, 102447 (2022) 4. Seidel, S., Recker, J., vom Brocke, J.: Sensemaking and sustainable practicing: functional affordances of information systems in green transformations. MIS Q. 37, 1275–1299 (2013)
356
A. Ananjeva et al.
5. Zeiss, R., Ixmeier, A., Recker, J., Kranz, J.: Mobilising information systems scholarship for a circular economy: review, synthesis, and directions for future research. Inf. Syst. J. 31, 141–183 (2021) 6. Benitez-Amado, J., Walczuch, R.M.: Information technology, the organizational capability of proactive corporate environmental strategy and firm performance: a resource-based analysis. Eur. J. Inf. Syst. 21, 664–679 (2012). https://doi.org/10.1057/ejis.2012.14 7. Biørn-Hansen, A., Håkansson, M.: Building momentum: scaling up change in community organizations. In: CHI 2018: Proceedings of the 2018 CHI Conference on Human Factors in Computing Systems, Montreal, Canada, 21–26 April 2018, pp. 1–13. Association for Computing Machinery, New York (2018) 8. Svangren, M.K., Ananjeva, A., Persson, J.S., Mouritsen, L.K., Nielsen, P.A., Sperling, K.: Infrastructuring in digital transformation: an action case study of district heating. In: 29th European Conference of Information Systems: Human Values Crisis in a Digitizing World, p. 1189. Association for Information Systems (2021) 9. Seidel, S., Chandra Kruse, L., Székely, N., Gau, M., Stieger, D.: Design principles for sensemaking support systems in environmental sustainability transformations. Eur. J. Inf. Syst. 27, 221–247 (2018) 10. Gimpel, H., Graf-Drasch, V., Laubacher, R.J., Wöhl, M.: Facilitating like darwin: supporting cross-fertilisation in crowdsourcing. Decis. Support Syst. 132, 113282 (2020) 11. Introne, J., Laubacher, R., Olson, G., Malone, T.: Solving wicked social problems with sociocomputational systems. KI-Künstl. Intell. 27, 45–52 (2013). https://doi.org/10.1007/s13218012-0231-2 12. Pettigrew, A.M.: Longitudinal field research on change: theory and practice. Organ. Sci. 1(3), 267–292 (1990) 13. Lund, H., et al.: 4th Generation District Heating (4GDH): integrating smart thermal grids into future sustainable energy systems. Energy 68, 1–11 (2014) 14. Bengtsson, F., Ågerfalk, P.J.: Information technology as a change actant in sustainability innovation: Insights from Uppsala. J. Strat. Inf. Syst. 20, 92–112 (2011) 15. Cooper, V., Molla, A.: Information systems absorptive capacity for environmentally driven IS-enabled transformation. Inf. Syst. J. 27, 379–425 (2017) 16. Wunderlich, P., Veit, D.J., Sarker, S.: Adoption of sustainable technologies: a mixed-methods study of German households. MIS Q. 43, 673–691 (2019) 17. Strengers, Y.A.: Designing eco-feedback systems for everyday life. In: CHI 2011: Proceedings of the 2011 CHI Conference on Human Factors in Computing Systems, Vancouver, Canada, 7–12 May 2011, pp. 2135–2144. Association for Computing Machinery, New York (2011) 18. Froehlich, J., Findlater, L., Landay, J.A.: The design of eco-feedback technology. In: CHI 2010: Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, Atlanta, Georgia, USA, 10–15 April 2010, pp. 1999–2008. Association for Computing Machinery, New York (2010) 19. Schwartz, T., Denef, S., Stevens, G., Ramirez, L., Wulf, V.: Cultivating energy literacy: results from a longitudinal living lab study of a home energy management system. In: CHI 2013: Proceedings of the 2013 CHI Conference on Human Factors in Computing Systems, Paris, France, 27 April–2 May 2013, pp. 1193–1202. Association for Computing Machinery, New York (2013) 20. DiSalvo, C., Sengers, P., Brynjarsdóttir, H.: Mapping the landscape of sustainable HCI. In: CHI 2010: Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, Atlanta, Georgia, USA, 10–15 April 2010, pp. 1975–1984. Association for Computing Machinery, New York (2010) 21. Entwistle, J.M., Rasmussen, M.K., Verdezoto, N., Brewer, R.S., Andersen, M.S.: Beyond the individual: the contextual wheel of practice as a research framework for sustainable HCI.
Digital Transformation Towards Sustainability
22.
23.
24.
25.
26.
27. 28. 29.
30.
31.
32. 33. 34. 35. 36.
357
In: CHI 2015: Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, Seoul, South Korea, 18–23 April 2015, pp. 1125–1134. Association for Computing Machinery, New York (2015) Raptis, D., Jensen, R.H., Kjeldskov, J., Skov, M.B.: Aesthetic, functional and conceptual provocation in research through design. In: DIS 2017: Proceedings of the 2017 Conference on Designing Interactive Systems, Edinburgh, UK, 10–14 June 2017, pp. 29–41. Association for Computing Machinery, New York (2017) Preist, C., Schien, D., Blevis, E.: Understanding and mitigating the effects of device and cloud service design decisions on the environmental footprint of digital infrastructure. In: CHI 2016: Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, San Jose, California, USA, 7–12 May 2016, pp. 1324–1337. Association for Computing Machinery, New York (2016) Jensen, R.H., Raptis, D., Kjeldskov, J., Skov, M.B.: Washing with the wind: a study of scripting towards sustainability. In: DIS 2018: Proceedings of the 2018 Conference on Designing Interactive Systems, Hong Kong, China, 9–13 June 2018, pp. 1387–1400. Association for Computing Machinery, New York (2017) Clear, A., Friday, A., Hazas, M., Lord, C.: Catch my drift? Achieving comfort more sustainably in conventionally heated buildings. In: DIS 2014: Proceedings of the 2014 Conference on Designing Interactive Systems, Vancouver, Canada, 21–25 June 2014, pp. 1015–1024. Association for Computing Machinery, New York (2014) Heitlinger, S., Bryan-Kinns, N., Comber, R.: The right to the sustainable smart city. In: CHI 2019: Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, Glasgow, Scotland, 4–9 May 2019, pp. 1–13. Association for Computing Machinery, New York (2019) Hedman, J., Henningsson, S.: Developing ecological sustainability: a green IS response model. Inf. Syst. J. 26, 259–287 (2016) Corbett, J.: Designing and using carbon management systems to promote ecologically responsible behaviors. J. Assoc. Inf. Syst. 14, 339–378 (2013) Corbett, J., Mellouli, S.: Winning the SDG battle in cities: how an integrated information ecosystem can contribute to the achievement of the 2030 sustainable development goals. Inf. Syst. J. 27, 427–461 (2017) Lessel, P., Altmeyer, M., Krüger, A.: Analysis of recycling capabilities of individuals and crowds to encourage and educate people to separate their garbage playfully. In: CHI 2015: Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, Seoul, South Korea, 18–23 April 2015, pp. 1095–1104. Association for Computing Machinery, New York (2015) Normark, M., Tholander, J.: Performativity in sustainable interaction: the case of seasonal grocery shopping in ecofriends. In: CHI 2014: Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, Toronto, Canada, 26 April–1 May 2014, pp. 271–280. Association for Computing Machinery, New York (2014) Vial, G.: Understanding digital transformation: A review and a research agenda. J. Strat. Inf. Syst. 28, 118–144 (2019) Pentland, B.T., Mahringer, C.A., Dittrich, K., Feldman, M.S., Wolf, J.R.: Process multiplicity and process dynamics: weaving the space of possible paths. Organ. Theory 1(3), 1–21 (2020) Pentland, B.T.: Building process theory with narrative: from description to explanation. Acad. Manag. Rev. 24, 711–724 (1999) Jovchelovitch, S., Bauer, M.W.: Narrative interviewing. In: Qualitative Researching with Text, Image and Sound, pp. 57–74 (2000) Braun, V., Clarke, V.: Using thematic analysis in psychology. Qual. Res. Psychol. 3(2), 77–101 (2006)
358
A. Ananjeva et al.
37. Brinkmann, S.: Doing without data. Qual. Inq. 20, 720–725 (2014) 38. Sebastian, I.M., Ross, J.W., Beath, C., Mocker, M., Moloney, K.G., Fonstad, N.O.: How big old companies navigate digital transformation. In: Strategic Information Management, pp. 133–150. Routledge (2020) 39. Carroll, N., McLaffery, B., Conboy, K., Donnellan, B.: Normalising a digital transformation. In: ICIS 2021 Proceedings. AIS, p. 12 (2021) 40. Piccini, E., Gregory, R.W., Kolbe, L.M.: Changes in the producer-consumer relationshiptowards digital transformation. In: Wirtschaftsinformatik Proceedings. AIS, pp. 1634–1648 (2015) 41. Bitran, G.R., Gurumurthi, S., Sam, S.L.: The need for third-party coordination in supply chain governance. MIT Sloan Manag. Rev. 48, 30 (2007) 42. Adner, R.: Ecosystem as structure: an actionable construct for strategy. J. Manag. 43, 39–58 (2017) 43. Pavlou, P.A., El Sawy, O.A.: The “third hand”: IT-enabled competitive advantage in turbulence through improvisational capabilities. Inf. Syst. Res. 21, 443–471 (2010) 44. El Sawy, O.A., Pereira, F.: Business Modelling in the Dynamic Digital Space: An Ecosystem Approach. Springer, Heidelberg (2013). https://doi.org/10.1007/978-3-642-31765-1 45. Hernes, T.: Understanding Organization as Process: Theory for a Tangled World. Routledge (2007) 46. Thieme, A., et al.: We’ve bin watching you: designing for reflection and social persuasion to promote sustainable lifestyles. In: CHI 2012: Proceedings of the 2012 Conference on Human Factors in Computing Systems, Austin, Texas, 5–10 May 2012, pp. 2337–2346. Association for Computing Machinery, New York (2013) 47. Hasselqvist, H., Hasselgren, M., Bogdan, C.: Challenging the car norm: opportunities for ICT to support sustainable transportation practices. In: CHI 2016 Proceedings of the 2016 Conference on Human Factors in Computing Systems. San Jose, California, 7–12 May 2016, pp. 1300–1311. Association for Computing Machinery, New York (2016) 48. Hanelt, A., Bohnsack, R., Marz, D., Marante, C.A.: A systematic review of the literature on digital transformation: Insights and implications for strategy and organizational change. J. Manag. Stud. 58, 1159–1197 (2021)
Author Index
Abdelsalam, Ahmed 182 Abdullai, Larry 182, 337 Abrahamsson, Pekka 134, 278 Adisa, Mikhail O. 182 Agbese, Mamia Ori-otse 278 Aittamaa, Essi 182 Ananjeva, Alisa 344 Azad, Nasreen 182, 260
Klerens, Benjamin 304 Krcmar, Helmut 151
Barroca, Leonor 287 Binzer, Björn 244 Bosch, Jan 141 Brink, Henning 67 Buan, Thor Aleksander
Machado, Leticia 287 Madeja, Nils 3 Mahmud, Hasan 182 Mässeli, Niina 182 Moe, Nils Brede 51 Mohanani, Rahul 134, 278
51
Choma, Joelma 287 Cifci, Aynur 3 de Souza, Cleidson R. B.
287
Edison, Henry 304, 320 Engels, Gregor 227 Gierlich-Joas, Maren 213 Grundy, John 117 Gurzhii, Anastasiia 182 Hamza, Muhammad 182 Hansen, Karl 304 Hanssen, Geir Kjetil 51 Haque, Bahalul 182 Hirsch, Julian 101 Hyrynsalmi, Sami 141, 260 Hyrynsalmi, Sonja M. 141, 167, 182 Ikonen, Jouni 182 Jansen, Slinger 182, 328 Joutsenlahti, Juha-Pekka 182 Kanij, Tanjila 117 Kauschinger, Martin 151 Kirchhoff, Jonas 227
Legesse, Wondemeneh 182 Lins, Fernando 85 Liyanage, Reshani 19 Lorenz, Alisa 3 Luukkainen, Roope 182
Nielsen, Peter Axel 35, 344 Nieminen, Teemu 134 Olsson, Helena Holmström 141 Osmanovic, Admir 304 Packmohr, Sven 67 Päivärinta, Tero 19 Paul, Fynn-Hendrik 67 Persson, John Stouby 35, 344 Polito, Vinícius 85 Porras, Jari 337 Pretschner, Alexander 213 Riehle, Dirk 101 Rintamaki, Marko 278 Santos, Rodrigo Pereira dos 85 Sarinho, Maria Wanick 85 Schreieck, Maximilian 151 Shamshiri, Hatef 182 Sharp, Helen 287 Šinik, Tea 328 Sipilä, Antti 337 Smolander, Kari 196 Snippert, Joeri 328
360
Author Index
Tkalich, Anastasiia 320 Tripathi, Nirnaya 19
Winkler, Till J. 244 Xu, Yueqiang
19
Ulfsnes, Rasmus 51 Valença, George 85 van Schothorst, Casper 182 Vuolasto, Jaakko 182, 196
Zada, Ashna Mahmood 35 Zaina, Luciana 287 Zhai, Qijun 117 Zieglmeier, Valentin 213