1 Introduction
Computing systems form the backbone of our factories, traffic control systems, healthcare, telecommunication, financial systems, and so forth. When software plays a vital role in their design, construction, and operation, these systems are often referred to as software-intensive systems [
21]. The trustworthiness and sustainability of these systems is vital for our society [
5,
32]. Yet, building and maintaining trustworthy and sustainable systems is challenging due to complexity that arises from the growing demands on these systems, their continued integration, the uncertain operating conditions they face, the fast speed of technological progress, and so forth. These challenges have been a continuous driver for new and innovative approaches to design, develop, and operate software-intensive systems. One common approach today is the so-called DevOps in which development and operation are blended, allowing system components to be easily evolved and redeployed without impacting their operation [
7].
A classic approach to address the increasing complexity of software-intensive systems is transferring control from humans [
27] to software components by equipping systems with feedback loops that automate tasks that otherwise need to be performed by human operators. These feedback loops monitor the system and its environment, reason about the system behaviour and its goals, and adapt the system to ensure its goals under changing conditions, or gracefully degrade if necessary. Such goals can be quite diverse, ranging from ensuring a required level of performance under uncertain workload conditions, dealing with errors caused by external services that are difficult to predict, or defending the system against malicious attacks and the problems they may cause. A typical example is a feedback loop deployed in a cloud environment that expands or decreases computing resources to meet changing demands while minimising the cost of operation. Another example is a container framework that performs auto-scaling in a microservice deployment.
The principles of applying feedback control to software-intensive systems have been the subject of active study in academia. Back in 1998, Oreizy et al. [
33] presented a seminal paper at the International Conference on Software Engineering (ICSE), where the authors introduced the notion of
self-adaptation that comprises two simultaneous processes: system adaptation that is concerned with detecting and handling changing circumstances, and system evolution that is concerned with the consistent application of change over time. A few years later, Garlan et al. [
15] stated the crucial role of architectural models as first-class citizens that enable a system to reason about system-wide change and adapt itself accordingly to achieve or maintain its goals. Blair et al. [
4] consolidated and elaborated on these principles in what is now generally known as “models at runtime.” In 2007, Kramer and Magee [
25] stated the crucial role of software architecture in the realisation of self-adaptive systems, distinguishing adaptation management from goal management. Over the past decade, the research community has developed a vast body of knowledge and know-how on principles, e.g., see [
2,
4,
13,
37], models and languages [
23,
31,
43,
52,
54], processes and methods [
1,
6,
8,
48], patterns [
26,
35,
53], and frameworks [
10,
15,
36] to engineer self-adaptive systems. Researchers have documented a substantial number of literature reviews and surveys on various topics in self-adaptive systems, such as the benefits of self-adaptation [
51], requirements for self-adaptive systems [
56], approaches to realise self-adaptation [
26,
28,
30,
39], the use of formal methods in self-adaptive systems [
49], self-protection [
57], the notion of uncertainty [
20,
29], and the use of machine learning in the realisation of self-adaptation [
17], among others. There are several basic research works in the field of self-adaptation, e.g., see [
7,
9,
22,
38,
44].
In parallel, the principles of feedback control have been studied and applied in industry. For example, about two decades ago, IBM launched its legendary initiative on autonomic computing [
24]. Inspired by the autonomic nervous system of the human body, the central idea of autonomic computing was to enable computing systems to manage themselves based on high-level goals. Four classic goals are self-optimisation, self-healing, self-protection, and self-configuration. Autonomic computing delegates the complexity of system operation to the machine aiming to reduce the time required by operators to resolve system difficulties and other maintenance tasks such as software updates. Over the years, industrial solutions based on feedback loops have found their way to practical applications—for instance, in the domain of elastic cloud to adapt computing resources and automated management of server parks to deal with changing business needs (e.g., [
3,
40]).
Although the output of academic research is documented in research articles, journal volumes, and books, the current practice of self-adaptation in industry has never been systematically described.
1.1 Objective and Research Questions
Our general objective is to better understand the state of practice of self-adaptation in industry. To that end, we perform a large-scale survey with active practitioners. Concretely, this survey aims at shining a light on what motivates practitioners to apply self-adaptation, what kind of problems they solve using self-adaptation, how practitioners design and develop self-adaptive systems, whether they follow any established practices, what difficulties and risks they face in adopting self-adaptation, and what future opportunities industry sees for the application of self-adaptation.
To the best of our knowledge, no systematic study has been done that investigates these issues. Investigating industrial practice on self-adaptation and answering the questions targeted by this study will help narrow the gap between industry and academia. It aims at helping researchers in academia to get a better picture of how self-adaptation is applied in practice, the industrial needs in realising self-adaptation, and what problems practitioners face. We conjecture that having a better picture about industry practice will help the research community to position their efforts with respect to industrial needs and make well-informed decisions to set future research objectives, both fundamental and applied. However, drawing a picture of the state of the practice can also benefit industry by sharing the motivations and potential benefits of self-adaptation, directing them towards relevant sources of information such as best practices, and identifying opportunities for collaboration with researchers to address the problems they face.
We aim to answer the following concrete research questions:
RQ1:
What drives practitioners to apply self-adaptation in software-intensive systems?
RQ2:
How do practitioners characterise self-adaptation?
RQ3:
How do practitioners apply self-adaptation in industrial software-intensive systems?
RQ4:
What are the experiences of practitioners with applying self-adaptation, and do they see opportunities for how and where to apply self-adaptation?
With RQ1, we want to investigate the motivations of practitioners for applying self-adaptation, the kinds of industrial systems for which self-adaptation is applied, and the types of problems they solve using self-adaptation. In academic research, self-adaptation has been proposed for two main complementary problems [
44]: (1) to automate the management of complex software-intensive systems based on high-level goals provided by operators, and (2) to deal with operating conditions that are hard to predict before deployment and need to be resolved during operation (i.e., mitigating uncertainties). Key management tasks for self-adaptation are self-healing, self-optimisation, self-protection, and self-configuration. We want to understand whether industry uses the principles of self-adaptation to deal with the same or different problems, and whether and how they relate to the classic system and software management tasks. Answering RQ1 will shine a light on application areas, motivations, and concrete problems for which self-adaptation is applied by practitioners or could be applied by practitioners who currently do not use self-adaptation. This may provide academics with insights in relevant areas to drive and validate research results on self-adaptation. The results may also indicate applications and problems that are not yet explored in industry and may benefit both academia and industry.
With RQ2, we aim to investigate the perception of practitioners on the concept of self-adaptation. We are particularly interested in how practitioners characterise self-adaptation as a property that enables a system to adapt itself at runtime. To that end, we will elicit concrete examples of what they understand by self-adaptation. This will give us better understanding of whether and how practitioners understand the concept of self-adaptation, what terminology they use, whether there are any differences in the viewpoints on what constitutes self-adaptation, and whether they consider self-adaptation altogether useful. This may also shine a light on whether there are any (emerging) industrial standard practices (e.g., a technology stack or tools). Answering RQ2 will help researchers get a better picture of how practitioners understand the concept of self-adaptation. However, the insights may reveal potential opportunities for practitioners to benefit from expertise of other practitioners as well as knowledge developed by researchers.
With RQ3, we aim at examining how self-adaptation has been realised and used in industry. We are particularly interested in mechanisms, tools, benchmarks, and processes employed in the industry to engineer self-adaptive solutions. We will pay attention to the degree of automation and the role of humans in runtime adaptation, as this is commonly considered important for trust in software-intensive systems (e.g., see [
50]). Furthermore, we are interested in comparing industrial practices with solutions developed by academics, such as modelling techniques, frameworks, and verification techniques. We also want to understand how practitioners obtain trust in the self-adaptive solutions they employ. Answering RQ3 will provide insights into best practices on how practitioners realise self-adaptation. It will highlight the criteria that practitioners use to apply and realise self-adaptation solutions and may shine a light on to what extent solutions from the research community have been adopted in industry. These insights will open opportunities for both academia and industry to steer future research and improve practical applications.
Finally, with RQ4, we want to understand the difficulties and risks, if any, that practitioners experience in the design, implementation, and other engineering activities of self-adaptive systems. We also will probe whether practitioners face problems for which they would appreciate support from researchers. Finally, we elicit opportunities that practitioners see for applying self-adaptation that are not exploited yet. Answering RQ4 may help fill the gap between academia and industry. Furthermore, identifying problems and risks may trigger new collaborative studies to investigate and address these challenges. Such studies are likely to bridge the gap and result in more targeted research and improved industrial applications of self-adaptive systems.
1.2 Contributions
By drawing a landscape of the use of self-adaptation in industry, the survey results benefit both researchers and practitioners. Concretely, the contributions of this study are as follows:
•
An empirically grounded overview of the state of the practice in the application of self-adaptation
•
Insights for researchers to assess their current research in relation to industrial needs
•
Insights for practitioners to assess the level of their current practice in applying self-adaptation
•
Additional prospects for applying self-adaptation in practice and opportunities for industry-research collaborations.
Preliminary results of this study were reported in previous work [
46].
That work only considered a small subset of questions (focusing on the motivations of practitioners to apply self-adaptation, concrete use cases in practice, and difficulties practitioners face when applying self-adaptation) and reported initial results based on one batch of data (113 participants). This work extends that study with the view of practitioners on self-adaptation, the drivers for using self-adaptation, methods used, experiences with applying self-adaptation in industry, and opportunities for the future. In this article, we consider the full dataset of 184 participants from more parts of the world.1.3 Outline
In Section
2, we present the study design with the survey questions and analysis methods used. Section
3 presents the results for each research question and provides key insights for each research question. In Section
4, we derive insights from the study results for researchers and practitioners. Section
5 discusses threats to validity. Finally, we wrap up and conclude in Section
6.
2 Research Method
In this study, we use a survey as the research method [
18]. Subsequently, we discuss the population and sample, the questionnaire, and the data analysis methods we used.
2.1 Population and Sampling
Our target population included practitioners actively involved in the engineering of industrial software-intensive systems in any domain—architects, designers, developers, testers, maintainers, operators, and other people who have technical expertise and are actively involved in the development and maintenance of these software systems.
Concretely, we contacted 355 practitioners from a wide variety of companies
1 via the networks of the researchers involved in this study (i.e., the authors of this article) to complete the survey. We used two criteria to invite people: (1) participants should be active in different domains that are representative of software-intensive systems, and (2) participants have the required expertise to answer the questions. The invited practitioners were spread over 21 countries.
2 The invitations were sent by personalised emails in two batches during the period from November 30, 2020 until July 31, 2022. We sent reminders according to a predefined schedule of 1, 2, and 6 weeks after the invitation.
2.2 Survey Instrument
The survey used a questionnaire to collect data based on a set of predefined questions [
18]. Because practitioners are not necessarily familiar with the term
self-adaptation, the survey started with a gentle introduction of the core idea of what constitutes a self-adaptive system using basic terminology commonly used in industry, and illustrated this with a few characteristic examples to make it concrete. We used both closed and open questions. Closed questions have a predefined set of answers, such as yes/no or multiple choice. We also allowed participants to add extra options for answering several closed questions using a text field. Open questions provide a space that participants can use to provide an answer. Closed questions allow acquiring a clear view on a particular topic using basic statistics, whereas open questions allow acquiring in-depth insights using qualitative analysis. We provide a replication package with all study materials, including the study protocol, the questionnaire, the raw data, and the analysis results.
3For this study, we used a self-administered anonymous online questionnaire (Survey & Report hosted by Linnaeus University, Sweden). The main motivation to use an online questionnaire is to involve a large set of participants with relatively low cost (both time-wise and financially). We created an initial list of survey questions that were directly derived from the research questions of this study. The initial list of questions was composed by two members of the research team and then crosschecked by the other team members.
We validated the questionnaire in a pilot with eight randomly selected participants from the target population. For this pilot, we added additional meta-questions to the questionnaire about clarity of terminology and questions, relevance of the questions, scope of the questions, and the time required to complete the survey. For both clarity of terminology and clarity of the questions, we obtained an average score of 4.38 on a scale from 1 (Not clear at all) to 5 (Very clear). None of the participants indicated that questions should be removed or modified. Six participants indicated that no important aspects were missing. One participant hinted that we may also probe whether the use of self-adaptation requires a specialised team in the company or alternatively infrastructure to share knowledge. Another participant suggested adding a question about scalability of solutions for self-adaptation. One participant stated that the example system we used to introduce self-adaptation may create some bias, and further that answers to questions may differ depending on roles on the engineering teams. The average reported time to complete the survey was 24 minutes. Based on the feedback, we adjusted the introductory part of the questionnaire. We did not revise the questions, as they were perceived as clear and well scoped. The finalised questionnaire was then distributed to the participants as explained earlier.
The first part of the questionnaire (Table
1) solicited whether the participant applies self-adaptation and collected general demographic information. This allowed us to check whether the participant had experience with self-adaptation (Q0.1), confirm a good coverage of kinds of software-intensive systems across participants (Q0.2), the size of the companies of participants (Q0.3), as well as a confirmation of the participant’s role (Q0.4) and years of experience (Q0.5).
The second part of the questionnaire aimed at questions related to RQ1 collecting data about the problems for which the participants apply self-adaptation (Q1.1), the main business motivations for using self-adaptation (Q1.2), and the benefits obtained from applying self-adaptation (Q1.3) (Table
2). The first two questions had multiple options.
4The third part of the questionnaire covered a question related to RQ2 on how practitioners characterise self-adaptation (Table
3). This part included only one question that asked participants to describe a concrete self-adaptive system they had worked with (Q2.1).
The fourth part of the questionnaire addressed RQ3 on how practitioners apply self-adaptation in their practice (Table
4). The first three questions investigated the mechanisms that participants use to monitor (Q3.1) and analyse (Q3.2) the system during operation, and change the system when needed (Q3.3). The next question investigated the degree of automation of self-adaptation (Q3.4). The next three questions investigated reuse of solutions (Q3.5–Q3.7). The last question of this part of the questionnaire probed whether and how practitioners establish trust in the self-adaptation solutions they build (Q3.8).
Finally, the fifth part of the questionnaire addressed RQ4 on difficulties, risks, and opportunities of applying self-adaptation in practice (Table
5). The first two questions investigated difficulties (Q4.1 and Q4.2); the next three questions focused on risks and risk mitigation (Q4.3–Q4.5). The next two questions probed the interest of practitioners to get support from researchers for solving problems with self-adaptation (Q4.6 and Q4.7). The last two questions investigated opportunities for applying self-adaptation beyond the current practice (Q4.8 and Q4.9).
The questionnaire ended with a question (Q5.1) about how confident participants were in general about the answers they gave when answering the survey questions with the following possible answers: Very confident; Confident; Sufficiently confident; Neutral; Somewhat unconfident; Not confident; Not confident at all.
This question is not about answering a particular research question, but the answers to this question are important for the validity of the study, as discussed in Section 5.2.3 Data Analysis
To analyse closed questions, we used descriptive statistics and quantitative data analysis. Therefore, we mostly report frequencies of answers, percentages relative to the respective number of responses, and relationships between answers to questions based on contingency matrices (based on the categorisation of answers). We only report relationships that led to relevant insights.
To analyse comments to open questions, we used qualitative data analysis. In particular, we used inductive reasoning to construct codes and infer categories from the data by labelling occurrences of codes and grouping them into categories [
41]. Similar to others (e.g., Prechelt et al. [
34]), we tried to keep coding simple. We did not have a predefined coding schema or a predefined granularity or semantic style for the codes. However, we interpreted comments in the context of the question for which they were given. We used a simple version of open coding [
42]. Similar to Méndez Fernández et al. [
12], we used open coding to add codes to small coherent fragments of the comments. We then categorised the developed concepts in a hierarchy of categories as an abstraction of the codes. In sub-teams of two or three coders, we coded 886 comments of 12 open questions. Coding was first done individually and then consolidated in the sub-team. Two other researchers crosschecked the consolidated coding. Where necessary, the coding was adjusted in consensus between the sub-team and the researchers. For example, we excluded some comments from coding if they did not provide any additional insights or if they were too generic, such as a participant answering “Always” to a closed question and stating “This is how we work” in the comments. Additionally, we did not map the answers to a closed question to comments for that question. For example, a participant may have answered that they never reused solutions for self-adaptation but in their comments indicated reasons they “might” do so (i.e., one comment may cover several concepts, which may not necessarily match the answer to the closed question). When reporting example quotes from comments in Section
3, we use verbatim excerpts, including spelling and punctuation errors.
4 Discussion
We start the discussion by highlighting several observations that we derived from the data analysis. Then we perform several additional analyses based on cross analyses of selected data of the answers to different questions. With these cross analyses, we aim to gain further insights into three topics of interest: benefits of applying self-adaptation in practice, difficulties and risks with engineering self-adaptation in practice, and research support to address problems in practice.
4.1 Observations
The problems addressed by industry generally are similar to those studied by academics. Yet, one particular difference is the lack of emphasis of practitioners on the use of self-adaptation to mitigate uncertainties, which has been a key focus in research [
11,
14,
20,
54]. A possible explanation is that practitioners avoid the term
uncertainty, that may be perceived as “doubt,” “not clearly defined,” or “not under control.” Instead, they refer to uncertainty indirectly by using a different vocabulary, such as “conditions are not always obvious” and “available metrics are not always fully transparent.”
Although practitioners apply self-adaptation to deal with a variety of problems, changes in business goals are less frequently solved by using self-adaptation. One possible explanation may be that business goals are usually about higher-level requirements, whereas the focus of self-adaptation is often targeting “lower-level” technical problems. Additionally, there is the challenge of the mapping between business goal and technical/system metrics, which touches the line or work on dynamic software product lines [
19]. Yet, another explanation may be that self-adaptation has not yet been fully utilised in industry to deal with bigger system changes. We hypothesise that the latter is the case, but further study is needed to obtain deeper insight.
The four classic management tasks of self-adaptation studied by researchers (self-healing, self-optimising, self-protecting, and self-configuring) are also relevant to practitioners. Yet, differently from academics, practitioners also emphasise the importance of improving user satisfaction, reducing costs, and mitigating risks.
Practitioners make extensive use of tools and infrastructures to realise the different functions of self-adaptation. This points to the need for more emphasis on tools and supporting infrastructure in research. Related to that is the need for reusing solutions, such as in the form of references architectures and patterns. Although some research efforts have been taken in these directions, these issues deserve more attention. An interesting step in this direction is the development of industry-relevant artifacts as outlined in previous work [
47].
Self-adaption in software-intensive systems is often not completely automated. Several participants indicated that their main focus is on monitoring and analysis. This does not necessarily mean that their perception on self-adaption differs compared to most researchers who look at self-adaptation realised by a closed loop. In fact, practitioners emphasise that humans remain involved in adaptation, either to provide parts of functions or just to supervise the system. On one hand, for some companies this is the first step towards further automation; on the other hand, practitioners often express the need for involving humans to ensure trust by overseeing the system and take action when something unexpected happens. As such, we expect the role of humans in self-adaptation to remain important also for future industryrelevant research in self-adaptation.
It is remarkable that more than 50% of the participants report that they at least sometimes face risks with applying self-adaptation. At the same time, about half of the practitioners express that they would appreciate support from researchers to deal with the problems they face. This suggests that the engineering of efficient and trustworthy self-adaptive systems is a challenge in practice and that practitioners believe that support from research could benefit them to deal with these challenges. This opens opportunities for joint efforts between industry and academics.
4.2 Benefits of Applying Self-Adaptation in Practice
When we crosscheck adaptation problems (Q1.1) versus kinds of systems (Q0.2), we observe that most adaptation problems are applied to all kinds of systems, and each adaptation problem is applied in one or two champion kinds of systems. The three most frequently addressed adaptation problems are applied by all kinds of systems. Specifically, the problem “to optimise system performance” is applied to all kinds of systems except transportation, where “to detect and resolve errors” is the main adaptation problem (six occurrences), finances, where “to deal with changes in the environment” is the main problem (five occurrences), and manufacturing, where “to automate tasks” is the main problem (seven occurrences). Table
23 summarises the top occurrences—that is, the types of adaptation problems solved (top occurrences) versus the kind of system for which that adaptation problem is applied (top kind of systems).
We now look at the problems for which self-adaptation is applied (Q1.1) versus the benefits of using self-adaptation (Q1.2). Table
24 shows the contingency matrix. The results show that “improving user satisfaction” and “reducing costs” are by far the most frequently perceived benefits across all types of problems solved with self-adaptation. In particular, these two benefits are mentioned approximately 70% (+/–4%) on average across all problems, whereas “mitigating risks” and “penning up new application opportunities” are respectively mentioned 53% (+/–11%) and 28% (+/–5%) on average across all problems solved with self-adaptation.
Finally, we look at the potential benefits of reuse using the data of the kind of software systems built by organisations (Q0.2) versus reuse when applying self-adaptation (Q3.5–3.7). The top domains where solutions are frequently reused are data management with 11 occurrences and embedded/cyber-physical/IoT systems with seven occurrences. Manufacturing is the top domain, where practitioners very frequently reuse solutions with seven occurrences. The most frequent type of reused artifact is module with 11 occurrences, with embedded/cyber-physical/IoT as the top domain with four occurrences used for monitoring/analytics/control. Overall, there is no specific artifact that is more reused than other, and no domain that clearly reused more or fewer artifacts. Only five participants mention the reuse of patterns when engineering solutions for self-adaptation.
4.3 Difficulties and Risks of Applying Self-Adaptation in Practice
Large and small/medium organisations (Q0.3) are equally concerned about difficulties with design (Q4.1–4.2). Both types of companies are also concerned about tool support, although in different ways: difficulties with debugging is more important for large organisations, whereas limitations of tools and methods are more important for small/medium organisations.
When comparing large companies (>100) and small/medium companies (<100) (Q0.3), we observe no major difference in the reported frequency of encountered risks (Q4.3–4.4). The only relevant difference is that larger companies mention faults twice as much as small/medium ones—14 occurrences for 30 large companies versus six occurrences for 70 small/medium companies.
To crosscheck the size of companies (Q0.3) versus mechanisms used to realise self-adaptation (Q3.1–3.3), we performed dedicated coding distinguishing mechanisms that rely on tools/infrastructure versus custom mechanisms.
The data summary shown in Table
25 indicates that smaller/medium companies (<100) rely on tools and infrastructure to provide support for self-adaptation mechanisms, whereas in large companies (>100) custom solutions are more prevalent. Zooming into the data of mechanisms for the different stages of self-adaptation shows that almost all companies that apply self-adaptation have mechanisms in place for monitoring, but not necessarily for analysis and change, regardless of company size, but the differences are small. This suggests a progression from monitoring to analysis to change.
Cross analysis of subject of adaptation (Q2.1) versus difficulties and risks (Q4.1–4.2) shows that the reported difficulties and risks are similarly distributed across subjects of adaptation. The most frequently reported difficulties are design issues and people and process issues at the system level (both 11 instances). The most frequently reported risks are difficulties development/operation and impact on business also at the system level (six and five occurrences, respectively).
4.4 Research Support to Address Problems in Practice
Table
26 shows the main results of the cross analysis of the data of the concrete self-adaptive systems built by the participants (Q2.1) and the problems for which practitioners would appreciate, sometimes to always, support from researchers (Q4.6).
The analysis shows that the system, module, and application layer make a total of 64.4% of the problems for which practitioners would appreciate support from researchers. In terms of type of adaptation, 84.6% of the problems for which practitioners would appreciate support from researchers concern auto-tuning, auto-scaling, and monitoring and analysis. Finally, 74.1% of the problems for which support would be appreciated concern adaptation triggered by system properties, environment properties, and system load.
When crosschecking the kind of software systems built by the practitioners (Q0.2) versus the problems for which they would appreciate at least sometimes support from researchers (Q4.6), we found that except for one kind of system, support from researchers would be appreciated across all kinds of systems built by the practitioners. For e-commerce, none of the 7 participants expressed interest in regular support from researchers (4 of them would very rarely appreciate support). However, 8 out of 11 (72.2%) participants who work in the domain of ICT communication and networks would regularly appreciate support to address their problems. The numbers for the other domains range from 22.9% to 56.3%.
6 Conclusion
In this article, we studied the application of self-adaptation in industry. To that end, we conducted a questionnaire-based survey with practitioners from all over the world. We received valid responses from 184 participants, 100 of them with experience in engineering self-adaptive systems.
By analysing the data, we contributed an empirically grounded overview of the state of the practice in the application of self-adaptation. A selection of key observations includes the following: (1) self-adaptation is extensively applied in industry across a wide variety of domains; (2) the dominating types of adaptations applied in industry are auto-scaling, auto-tuning, and monitoring/analysis; (3) practitioners rely extensively on tools and infrastructure to realise the different functions of self-adaptation; (4) human supervision is important to ensure trust in industrial self-adaptive systems; (5) about half of the participants encounter risks with applying self-adaptation; and (6) on the other hand, about half of the practitioners would appreciate support from researchers to deal with problems they face. Figure
14 summarises the main findings.
The results offer insights for researchers that enable them to compare the focus of their current research with industrial needs. A selection of related key insights includes the following: (1) different from academics that study adaptation for mitigating uncertainty of classic maintenance tasks (self-*), practitioners also emphasise the importance of improving user satisfaction, reducing costs, and mitigating risks; (2) practitioners (particularly those of small- and medium-sized companies) rely on tools and infrastructure to realise self-adaptation; (3) ensuring trust in industrial self-adaptive systems is mainly achieved through extensive testing, runtime monitoring and alerting, and human supervision; and (4) risks with self-adaptation in practice relate mainly to incorrect functionality, difficulty in managing environment uncertainty, degraded performance, and increased cost.
The results also offer insights for practitioners to assess the level of their current practice in applying self-adaptation. A selection of related key insights includes the following: (1) practitioners broadly confirm that the use of self-adaptation improves robustness and performance while reducing costs and required resources, and improves user experience while reducing the burden of engineers; (2) a wide range of mechanisms are used to enact self-adaptation in industrial systems; (3) tools and infrastructure, such as auto-scaling and container-orchestration platforms, are available and commonly used to support the realisation of self-adaptation in practice; (4) important challenges when engineering self-adaptation in practice are reliable/optimal design, design complexity, and tuning/debugging; and (5) there is a relevant match between industrial practice in realising self-adaptation and the body of work performed by the research community of self-adaption.
The survey results provide prospects for applying self-adaptation in practice and opportunities for industry-research collaborations in this area. The prospects include the following: (1) realising full autonomous operation, (2) exploiting machine learning, (3) improving quality and security, and (4) applying self-adaptation for maintenance. Key opportunities for industry-research collaborations are in (1) consolidating best practices (architecture, patterns, and reuse), (2) modelling paths for the adoption of self-adaptation in industry, (3) supporting advanced features to realise self-adaptation such as dealing with the evolution of self-adaptive systems, (4) rigorous methods for ensuring trustworthiness of self-adaptive systems, (5) governance of data, and (6) moving the human in the loop (performing adaptation functions) to the human on the loop (overseeing the system to ensure trust).
It is our hope that the results of this survey will propel industry-relevant research in the field of self-adaptive systems, enhance collaboration between industry and academia, and the application of self-adaptation in practice, paving the way for self-adaptation to reach full maturity as a discipline.
