## 6 Discussion
### Relationships between RQs  
Next, we refer to how selected papers respond to each RQ. A Sankey diagram is shown in Figure 18. This diagram represents the relationships between the approaches to runtime variability management (RQ1), the applied methodology (RQ2), and the existing challenges mentioned by the authors (RQ3). The Sankey diagram allows focusing on the flows within a system. Figure 18: Relationships between approaches to runtime variability management (RQ1), applied methodology (RQ2), and challenges mentioned by the authors (RQ3). The first vertical axis represents the approaches defined for RQ1. These approaches consider closed dynamic variability, open dynamic variability, collaborative features, and No proposed approach to manage runtime variability. The second vertical axis represents the methodology defined for RQ2. The methodologies comprise a Proprietary architecture, the MAPE-K control loop, Agent-Oriented Software Engineering, the use of Third-party software, and works with No specific methodology presented. The third vertical axis represents the challenges defined for RQ3. These challenges considered Techniques, Open Variation, Proposal Validation, Explicit Variation Points, Support of defaults, Variant Isolation, Granularity, Binding Time, Non-code Artifacts, and works that do not mention challenges. The variability mechanisms (RQ1) and the methodology applied to manage DSPL (RQ2) are intrinsically related. Twenty-nine papers related to closed dynamic variability are managed based on a proprietary architecture, where variability modeling constraints and optimization models to improve the variant selection process predominate. To a lesser extent, three papers used third-party software. In the case of open dynamic variability, twenty-one papers considered the MAPE-K control loop. Nineteen papers are under a proprietary architecture, most of which are based on optimization models to compute the best reconfiguration that satisfies the environment requirements. Proposals managed under Agent-Oriented Software Engineering, with six papers, ending with one work associated with third-party software and non-specific methodology. The management of runtime variability through Collaborative features is addressed in two papers with their own architectures to manage a DSPL environment. One paper presents an approach based on Agent-Oriented Software Engineering. Finally, the paper that does not propose an approach to manage variability because it only presents problems and challenges exposes a theoretical model with the edges the architecture should contain. The relationship between the methodologies for managing DSPLs (RQ2) and their challenges (RQ3) presents seventeen papers defining a Proprietary architecture. Also, these papers highlight challenges in Techniques, such as [48], that present the need to apply DSPL concepts to build adaptive multi-cloud environments, i.e., cloud systems composed of services that operate through different providers. Nine papers present challenges concerning Open variation, seeking to extend the concept of closed dynamic variability towards an open one. Proposal Validation is highlighted by eight authors, who mention that such an architecture should be validated in the industry or the application areas should be extended. To a lesser extent, there are challenges in the area of Explicit variation points, where the need to apply the context variability approach presented for the dynamic behavior of the features is exposed. It mentions that the context functions must be activated and deactivated depending on the context conditions [77]. Two papers present the need for challenges in Variant isolation and Binding times in their architectures. One architecture presents the need to apply defined granularity to variants and Support defaults. This need considers traceability and history of DSPL evolutions to support the reversal of faulty reconfigurations or to apply proactive adaptations [78]. Finally, nine architectures do not mention challenges.