Search

Continuous deployment has been practiced for many years by companies developing web‐ and cloud‐based applications. To succeed with continuous deployment, these companies have a strong collaboration culture between the operations and development teams. In addition, these companies use AI, analytics, and big data to assist with time‐consuming postdeployment activities such as continuous monitoring and fault identification. Thus, the term AIOps has evolved to highlight the importance and difficulty of maintaining highly available applications in a complex and dynamic environment. In contrast, software‐intensive embedded systems often provide customer product‐related services, such as maintenance, optimization, and support. These services are critical for these companies as they provide significant revenue and increase customer satisfaction. Therefore, the objective of our study is to gain an in‐depth understanding of the impact of continuous deployment on product‐related services provided by software‐intensive embedded systems companies. In addition, we aim to understand how AIOps can support continuous deployment in the context of software‐intensive embedded systems. To address this objective, we conducted a case study at a large and multinational telecommunications systems provider focusing on the radio access network (RAN) systems for 4G and 5G networks. The company provides RAN products and three complementing services: rollout, optimization, and customer support. The results from the case study show that the boundaries between product‐related services become blurry with continuous deployment. In addition, product‐related services, which were conducted in sequence by independent projects, converge with continuous deployment and become part of the same project. Further, AIOps platforms play an important role in reducing costs and increasing postdeployment activities' efficiency and speed. These results show that continuous deployment has a profound impact on the software‐intensive system's provider service organization. The service organization becomes the connection between the R&D organization and the customer. In order to cope with the increased speed of releases, deployment and postdeployment activities need to be largely automated. AIOps platforms are seen as a critical enabler in managing the increasing complexity without increasing human involvement. [ABSTRACT FROM AUTHOR]

Artificial intelligence is increasingly becoming important to businesses because many companies have realized the benefits of applying machine learning (ML) and deep learning (DL) in their operations. ML and DL have become attractive technologies for organizations looking to automate repetitive tasks to reduce manual work and free up resources for innovation. Unlike rule‐based automation, typically used for standardized and predictable processes, machine learning, especially deep learning, can handle more complex tasks and learn over time, leading to greater accuracy and efficiency improvements. One of such promising applications is to use AI to reduce manual engineering work. This paper discusses a particular case within McDermott where the research team developed a DL model to do a quality check of complex blueprints. We describe the development and the final product of this case—AI‐based software for the engineering, procurement, and construction (EPC) industry that helps to find the design mistakes buried inside very complex engineering drawings called piping and instrumentation diagrams (P&IDs). We also present a cost‐benefit analysis and potential scale‐up of the developed software. Our goal is to share the successful experience of AI‐based product development that can substantially reduce the engineering hours and, therefore, reduce the project's overall costs. The developed solution can also be potentially applied to other EPC companies doing a similar design for complex installations with high safety standards like oil and gas or petrochemical plants because the design errors it captures are common within this industry. It also could motivate practitioners and researchers to create similar products for the various fields within engineering industry. [ABSTRACT FROM AUTHOR]

Artificial intelligence (AI) and the use of machine learning (ML) and deep learning (DL) technologies are becoming increasingly popular in companies. These technologies enable companies to leverage big quantities of data to improve system performance and accelerate business development. However, despite the appeal of ML/DL, there is a lack of systematic and structured methods and processes to help data scientists and other company roles and functions to develop, deploy and evolve models. In this paper, based on multi‐case study research in six companies, we explore practices and challenges practitioners experience in developing ML/DL models as part of large software‐intensive embedded systems. Based on our empirical findings, we derive a conceptual framework in which we identify three high‐level activities that companies perform in parallel with the development, deployment and evolution of models. Within this framework, we outline activities, iterations and triggers that optimize model design as well as roles and company functions. In this way, we provide practitioners with a blueprint for effectively integrating ML/DL model development into the business to achieve better results than other (algorithmic) approaches. In addition, we show how this framework helps companies solve the challenges we have identified and discuss checkpoints for terminating the business case. [ABSTRACT FROM AUTHOR]

Continuous experimentation (CE) refers to a set of practices used by software companies to rapidly assess the usage, value, and performance of deployed software using data collected from customers and systems in the field using an experimental methodology. However, despite its increasing popularity in developing web‐facing applications, CE has not been studied in the development process of business‐to‐business (B2B) mission‐critical systems. By observing the CE practices of different teams, with a case study methodology inside Ericsson, we were able to identify the different practices and techniques used in B2B mission‐critical systems and a description and classification of the four possible types of experiments. We present and analyze each of the four types of experiments with examples in the context of the mission‐critical long‐term evolution (4G) product. These examples show the general experimentation process followed by the teams and the use of the different CE practices and techniques. Based on these examples and the empirical data, we derived the HURRIER process to deliver high‐quality solutions that the customers value. Finally, we discuss the challenges, opportunities, and lessons learned from applying CE and the HURRIER process in B2B mission‐critical systems. [ABSTRACT FROM AUTHOR]

With digitalization and with technologies such as software, data, and artificial intelligence, companies in the embedded systems domain are experiencing a rapid transformation of their conventional businesses. While the physical products and associated product sales provide the core revenue, these are increasingly being complemented with service offerings, new data‐driven services, and digital products that allow for continuous value creation and delivery to customers. However, although there is significant research on digitalization and digital transformation, few studies highlight the specific needs of embedded systems companies and what it takes to transform from a traditional towards a digital company within business domains characterized by high complexity, hardware dependencies, and safety‐critical system functionality. In this paper, we capture the difference between what constitutes a traditional and a digital company and we detail the typical evolution path embedded systems companies take when transitioning towards becoming digital companies. [ABSTRACT FROM AUTHOR]

Digitalization is transforming industry to an extent that we have only seen the beginnings of. Across domains, companies experience rapid changes to their existing practices due to new technologies and new entrants that current businesses. While digitalization brings endless opportunities, it comes with challenges that require companies to strategically engage with partners in their surrounding ecosystems. In this paper, we study how companies in the embedded systems domain experience the process of transitioning from product‐based companies to businesses where software, data, and artificial intelligence (AI) play an increasingly important role. To manage this, these companies need to evolve their existing ecosystems while at the same time create new ecosystems around new technologies. This involves maintaining existing technologies such as mechanics and electronics while at the same time expanding these with software, data, and AI. We provide a strategic decision framework that helps software‐intensive embedded systems companies to successfully navigate the digital transformation. We do this in two steps. First, we present three models that provide the technical content of the strategic decision framework. Second, we provide an overview of the strategic alternatives that incumbents and new entrants have available when existing technologies are commoditizing and new technologies are introduced. [ABSTRACT FROM AUTHOR]

A known problem in large software companies is to balance the prioritization of short-term and long-term business goals. As an example, architecture suboptimality (Architectural Technical Debt), incurred to deliver fast, might hinder future feature development. However, some technical debt generates more interest to be paid than other. We conducted a multi-phase, multiple-case embedded case study comprehending 9 sites at 6 large international software companies. We have investigated which architectural technical debt items generate more interest , how the interest occurs during software development and which costly extra-activities are triggered as a result. We presented a taxonomy of the most dangerous items identified during the qualitative investigation and a model of their effects that can be used for prioritization, for further investigation and as a quality model for extracting more precise and context-specific metrics. We found that some architectural technical debt items are contagious, causing the interest to be not only fixed, but potentially compound, which leads to the hidden growth of interest (possibly exponential). We found important factors to be monitored to refactor the debt before it becomes too costly. Instances of these phenomena need to be identified and stopped before the development reaches a crises. [ABSTRACT FROM AUTHOR]

Recently, business ecosystems have been recognized as one of the most interesting phenomenon in software engineering research. Companies experience a paradigm shift where product development and innovation is moving outside the boundaries of the firm and where networks of stakeholders join forces to co-create value. While there is prominent research focusing on the managerial perspective of business ecosystems, few studies provide strategic guidance for how to intentionally manage the different ecosystems that companies operate in. Therefore, and on the basis of multicase study research, we provide empirical evidence on the challenges that software-intensive companies experience in relation to the different types of business ecosystems they operate in. We conduct a 'state-of-the-art' literature review to identify strategies that are used to manage ecosystem engagements, and we develop a conceptual model in which we identify strategies for managing the innovation ecosystem, the differentiating ecosystem, and the commoditizing ecosystem. By categorising the different strategies in relation to the different types of ecosystems for which they are valid, the 'three-layer ecosystem strategy model' provides comprehensive support for strategy selection. We validate the use of the identified strategies in 6 software-intensive case companies, and we provide empirical insights on the 'relevance' and the 'desired use' of these strategies as experienced by the case companies. [ABSTRACT FROM AUTHOR]

An introduction is presents in which the editor discusses various reports within the issue on topics including use of Bayesian networks for assisting continuous improvement of Scrum projects, portfolio management and adoption level of scaled agile development.

Many consumer electronics firms are adopting an ecosystem-centric approach for supporting third-party applications. In an emerging market, a consumer electronics firm may need to create a new ecosystem or adopt a newly developed platform, both which has significant commercial and technical implications. In this paper we identify three types of ecosystems that are used today: vertically integrated hardware/software platforms, closed-source software platforms, and open-source software platforms. We introduce a first step towards a multi-criteria decision support method, which determines what type of ecosystem is most suitable for a specific product category from a software engineering perspective. We use this method to analyze a wide range of consumer electronics products. The analysis shows that the vertically integrated platform type is most suitable for product with a high degree of innovation, and open-source software platforms are more suitable when a large amount of variants are needed. The closed-source software platform type is less suitable for most types of consumer electronics devices. This first step towards a full-fledged decision support method can be used by platform owners to decide whether their platform can also be successfully transferred to another product type. [ABSTRACT FROM AUTHOR]

The adoption of Agile Software Development in large companies is a recent phenomenon of great interest both for researchers and practitioners. Although intra-team interaction is well supported by established agile practices, the critical interaction between the agile team and other parts of the organization is still unexplored in literature. Such interactions slow down the development, hindering the achievement of business goals based on speed: short time to market, quick replication of products of a product-line, and reaction time for product evolution. We have employed a two-year long multiple-case case-study, collecting data through interviews and a survey in three large companies developing embedded software. Through a combination of qualitative and quantitative analysis, we have found strong evidence that interaction challenges between the development team and other groups in the organization hinder speed and are widespread in the organizations. This paper also identifies current practices in use at the studied companies and provides detailed guidelines for novel solutions in the investigated domain. Such practices are called boundary-spanning activities in information system research and coordination theory. We present a comparison between large embedded software companies employing agile and developing a line of products based on reused assets and agile companies developing pure software. We highlight specific contextual factors and areas where novel spanning activities are needed for mitigating the interaction challenges hindering speed. Copyright © 2015 John Wiley & Sons, Ltd. [ABSTRACT FROM AUTHOR]

Based on 25 interviews with participants from four case study companies that develop large‐scale software embedded systems, this paper presents the Test Activity Stakeholders (TAS) model. The TAS model shows how the continuous integration and delivery pipeline can be designed to include test activities that support four stakeholder interests: "Check changes," "Secure stability," "Measure progress," and "Verify compliance." The model is developed to show how each of the stakeholder interests are best supported by unit/component tests or system tests, by automated testing or manual testing and by tests executed in simulated environments or on real hardware. The TAS model may serve as a starting point for companies when evaluating and designing their continuous integration and delivery pipeline. The validation of the TAS model included twelve individuals from three case study companies. The validation showed that the TAS model is actionable and useful in practice, enabling the identification of stakeholders and showing where improvement efforts should be focused in order to support all stakeholder interests in the continuous integration and delivery pipeline. The Test Activity Stakeholders (TAS) model shows how the continuous integration and delivery pipeline can be designed to include test activities that support four stakeholder interests: "Check changes," "Secure stability," "Measure progress," and "Verify compliance." The validation of the TAS model showed that the model is actionable and useful in practice, showing where improvement efforts should be focused in order to support all stakeholder interests in the continuous integration and delivery pipeline. [ABSTRACT FROM AUTHOR]

Companies need to know how much value their ideas deliver to customers. One of the most powerful ways to accurately measure this is by conducting online controlled experiments (OCEs). To run experiments, however, companies need to develop strong experimentation practices as well as align their organization and culture to experimentation. The main objective of this paper is to demonstrate how to run OCEs at large scale using the experience of companies that succeeded in scaling. Based on case study research at Microsoft, Booking.com, Skyscanner, and Intuit, we present our main contribution—The Experiment Growth Model. This four‐stage model addresses the seven critical aspects of experimentation and can help companies to transform their organizations into learning laboratories where new ideas can be tested with scientific accuracy. Ultimately, this should lead to better products and services. [ABSTRACT FROM AUTHOR]

Today, companies operate in business ecosystems where they collaborate, compete, share, and learn from others with benefits such as to present more attractive offerings and sharing innovation costs. With ecosystems being the new way of operating, the ability to strategically reposition oneself to increase or shift power balance is becoming key for competitive advantage. However, companies run into a number of traps when trying to realize strategical changes in their ecosystems. In this paper, we identify 5 traps that companies fall into. First, the "descriptive versus prescriptive trap" is when companies assume that current boundaries between partners are immutable. Second, the "assumptions trap" is when powerful ecosystem partners assume that they understand what others regard as value‐adding without validating their assumptions. Third, the "keeping it too simple trap" is when companies overlooks the effort required to align interests. Fourth, the "doing it all at once trap" is when companies disrupt an ecosystem assuming that all partners can change direction at the same time. Finally, the "planning trap" is when companies are unable to move forward without a complete plan. We provide empirical evidence for each trap, and we propose an ecosystem engagement process for how to avoid falling into these. Key findings: Repositioning in the ecosystem is fraud with risks. We identify the key traps that companies fall into, as well as provide guidance on how to avoid them when transitioning from current to desired state by shifting power between ecosystem partners. [ABSTRACT FROM AUTHOR]