The increasing usage of machine learning (ML) coupled with the software architectural challenges of the modern era has resulted in two broad research areas: i) software architecture for ML-based systems, which focuses on developing architectural techniques for better developing ML-based software systems, and ii) ML for software architectures, which focuses on developing ML techniques to better architect traditional software systems. In this work, we focus on the former side of the spectrum with a goal to highlight the different architecting practices that exist in the current scenario for architecting ML-based software systems. We identify four key areas of software architecture that need the attention of both the ML and software practitioners to better define a standard set of practices for architecting ML-based software systems. We base these areas in light of our experience in architecting an ML-based software system for solving queuing challenges in one of the largest museums in Italy.

Software Architecture for ML-based Systems: What Exists and What Lies Ahead

Software is of increasing importance in all industries and it’s efficient creation an important factor in the success of corporations. Using the data generated during the entire software life cycle to create understanding and derive actionable insights, decisions can be made on a factual basis. One of the key requirements to making these objective decisions possible is the collection, composition, and communication of data to the correct stakeholders. To further these goals, the most complete collection of data artifacts available in the software life cycle is presented. These are abstracted to be independent of programming language, development process and toolset. As value is derived from the connection of entities, a set of possible connections is introduced as well as challenges and solutions in their creation discussed. The theoretical observations, and results are verified in the context of a large development organization with more than a thousand developers working from multiple global locations. Our results show that the combination of multiple data sources and their systematic composition are paramount to deriving value from life cycle data in large corporations.

Towards identifying and linking data silos along the software life cycle

To build successful software products, developers continuously have to discover what features the users really need. This discovery can be achieved with continuous experimentation, testing different software variants with distinct user groups, and deploying the superior variant for all users. However, existing approaches do not focus on explicit modeling of variants and experiments, which offers advantages such as traceability of decisions and combinability of experiments. Therefore, our vision is the provision of model-driven continuous experimentation, which provides the developer with a framework for structuring the experimentation process. For that, we introduce the overall concept, apply it to the experimentation on component-based software architectures and point out future research questions. In particular, we show the applicability by combining feature models for modeling the software variants, users, and experiments (i.e., model-driven) with MAPE-K for the adaptation (i.e., continuous experimentation) and implementing the concept based on the component-based Angular framework. 

Model-driven Continuous Experimentation on Component-based Software Architectures

Supporting customers after they acquire the prod-uct is essential for companies producing and selling software-intensive embedded systems products. Generally, customer sup-port is the first interaction point between the product users and the product vendor. Customer support is often engaged with answering customers' questions, troubleshooting, fault identification, and fixing product faults. While continuous deployment advocates for closer cooperation between the ones operating the software and the ones developing it, the means of such collaboration in general and the role of customer support, in particular, has not been addressed in the context of software-intensive embedded systems. Therefore, to better understand the impact that continuous deployment has on customer support and the role customer support should play in this context, we conducted a case study at a multinational company developing and selling telecommunications networks infrastructure. We focused on the 4th and 5th Generation (4G and 5G) Radio Access Networks (RAN) products, which can be considered a high volume product as they cover more than 80% of the world's population. Our study reveals that customer support needs to transition from a transaction-based and passive function triggered by customer support requests, to take an active role characterized by being proactive and preemptive to cope with the shorter operational time of a software version introduced by continuous deployment. In addition, customer support plays an essential role in making the feedback actionable by aggregating and consolidating feedback data to the R&D organization. 

Customer Support In The Era of Continuous Deployment: A Software-Intensive Embedded Systems Case Study

After the formal introduction of the Agile Manifesto in 2001 (Beck et al., 2001), previously conventional life-cycle models were at first slowly and then very rapidly augmented, or replaced outright, by approaches that emphasised rapid iterations or increments of idea-developmentdeployment cycles (Boehm et al., 2019a; Bruel et al., 2019). In the last decade this has been followed by adoption of ‘continuous *’ (or ‘continuous everything’) thinking (Fitzgerald and Stol, 2017), and rapid continuous data-driven software engineering (Gerostathopoulos et al., 2019; Konersmann et al., 2020). This was seen first in activities such as continuous integration and continuous delivery (CI/CD) of software features, releases, products and services. Subsequently, the traditional development phases of requirements, design, implementation and the like, and the often separately treated catch-all phase called maintenance, have been melded into a continuous deployment pipeline of new features alongside bug fixes, enhancements and refactorings (Cheriyan et al., 2020; Kersten, 2019).

Quality Assurance in the Context of Contemporary Software Practice

The rapid pace with which software needs to be built, together with the increasing need to evaluate changes for end users both quantitatively and qualitatively calls for novel software engineering approaches that focus on short release cycles, continuous deployment and delivery, experiment-driven feature development, feedback from users, and rapid tool-assisted feedback to developers. To realize these approaches there is a need for research and innovation with respect to automation and tooling, and furthermore for research into the organizational changes that support flexible data-driven decision-making in the development lifecycle. Most importantly, deep synergies are needed between software engineers, managers, and data scientists. This paper reports on the results of the joint 5th International Workshop on Rapid Continuous Software Engineering (RCoSE 2019) and the 1st International Workshop on Data-Driven Decisions, Experimentation and Evolution (DDrEE 2019), which focuses on the challenges and potential solutions in the area of continuous data-driven software engineering.

/pdf/continuous-data-driven-software-engineering-towards-a-3g3re2nha9.pdf

Continuous Data-driven Software Engineering - Towards a Research Agenda: Report on the Joint 5th International Workshop on Rapid Continuous Software Engineering (RCoSE 2019) and 1st International Works

Putra Manggala

Papers

Continuous Data-driven Software Engineering - Towards a Research Agenda: Report on the Joint 5th International Workshop on Rapid Continuous Software Engineering (RCoSE 2019) and 1st International Works