No full-text available
To read the full-text of this research,
you can request a copy directly from the authors.
Toward Design Decisions to Enable Deployability: Empirical Study of Three Projects Reaching for the Continuous Delivery Holy Grail
Abstract
There is growing interest in continuous delivery practices to enable rapid and reliable deployment. While practices are important, we suggest architectural design decisions are equally important for projects to achieve goals such continuous integration (CI) build, automated testing and reduced deployment-cycle time. Architectural design decisions that conflict with deploy ability goals can impede the team's ability to achieve the desired state of deployment and may result in substantial technical debt. To explore this assertion, we interviewed three project teams striving to practicing continuous delivery. In this paper, we summarize examples of the deploy ability goals for each project as well as the architectural decisions that they have made to enable deploy ability. We present the deploy ability goals, design decisions, and deploy ability tactics collected and summarize the design tactics derived from the interviews in the form of an initial draft version hierarchical deploy ability tactic tree.
... The memo presents modifiability as a factor for delivery capability [12]. Furthermore, the modifiability quality attribute motivates architecting for CD, which explains why several deployability tactics in [5] are, actually, new CD is a practice targeting the delivery of valuable software in frequent and constant pacing. As the product team deploys software releases into production regularly, it is not feasible to make it with larger software modules. ...
... In addition, Bellomo et al. [5] shows how these principles work together describing that SRP improves testability and deployability. The authors express that when teams achive the modularization of features, "then lower coupling, and increased cohesion enable deployment and continuous delivery... " [5]. ...
... In addition, Bellomo et al. [5] shows how these principles work together describing that SRP improves testability and deployability. The authors express that when teams achive the modularization of features, "then lower coupling, and increased cohesion enable deployment and continuous delivery... " [5]. ...
Context: As the adoption of continuous delivery practices increases in software organizations, different scenarios struggle to make it scales for their products in long-term evolution. This study looks at the concrete software architecture as a relevant factor for successfully achieving continuous delivery goals. Objective: This study aims to understand how the design of software architectures impacts the continuous deployment of their software product. Method: We conducted a systematic literature review to identify proper evidence regarding the research objective. We analyzed the selected sources adopting a synthesis and analysis approach based on Grounded Theory. Results: We selected 14 primary sources. Through our analysis process, we developed a theory that explains the phenomenon of Architecting for Continuous Deployment. The theory describes three other phenomena that support Architecting for Continuous Deployment: Supporting Operations, Continuous Evolution, and Improving Deployability. Furthermore, the theory comprises the following elements: contexts, actions and interactions, quality attributes, principles, and effects. We instantiated these elements and identified their interrelationships. The theory is supported by providing bi-directional traceability from the selected sources to the elements and vice-versa. Conclusions: Developing adequate architecture plays a crucial role in enabling continuous delivery. Supporting operations becomes vital to increase the deployability and monitorability of software architecture. These two outcomes require that developers accept responsibility for maintaining the operations. The continuous evolution of the architecture is essential, but it must consider balanced management of technical debt. Finally, improving deployability requires attention to the test strategy and how it affects downtime to enable efficient pipelines.
... With the support of modern practices, technology and tools, the division between the development and production environment is increasingly being blurred, creating a combined ecosystem (Bellomo, Ernst, Nord & Kazman, 2014), so, in the digital age, agile architecture extends to a complete combined ecosystem, which has been particularly influenced by new approaches: Continuous (Erder & Pureur, 2015), Lean (Coplien & Bjørnvig, 2010) and Evolutionary (Ford, Parsons & Kua, 2017) architecture, which add new practices, but essentially share the same goals (Booch, 2010;Holmes & Nicolaescu, 2017). ...
... Speed drives everything else, therefore continuous delivery (CD), with increased focus on CI (Bellomo, Ernst, et al., 2014;Nord et al., 2014), becomes important to enable continuous flow (CF) delivering new software to the production environment in a safe and reliable way (Poppendieck & Cusumano, 2012), even in the case of critical and very large online systems . Therefore, interest in the CD is growing steadily (Bellomo, Ernst, et al., 2014). ...
... Speed drives everything else, therefore continuous delivery (CD), with increased focus on CI (Bellomo, Ernst, et al., 2014;Nord et al., 2014), becomes important to enable continuous flow (CF) delivering new software to the production environment in a safe and reliable way (Poppendieck & Cusumano, 2012), even in the case of critical and very large online systems . Therefore, interest in the CD is growing steadily (Bellomo, Ernst, et al., 2014). On the other hand, Continuous Learning (CL) minimizes the effort to create functionality that STRATEGIC MANAGEMENT, Vol. ...
The speed of response to change and fluidity are key preconditions for the next generation of IT solutions in the digital world. We are witnessing a rather unimaginable expansion of the use of technology in everyday life, on the one hand, and a continuous increase in the speed of software delivery, on the other, which significantly increased expectations and contributed to the adoption of agile methods and practices, shifting the pendulum of software architecture from traditional to agile methods and practices. Agile architecture, as a result of the transformation of a traditional and agile approach to software development, is a new approach that uses agile techniques to deliver a flexible architecture, adaptable to changing demands, tolerant to changes, which is the result of the iterative-incremental design of the agile process of software development. In recent years, there has been a shift in focus, in practice and research, from people and processes to integration technologies and application's hosting, which has led to the emergence of microservices and increased interest in software architecture and design. One consequence of this is the emergence and development of new approaches in the process of building Agile architecture, such as Continuous Architecting, Lean Architecting or Evolutionary Architecting, which essentially share the same goals. In this connection, in order to understand better the concept and the new role of Agile architecture in the digital era, it is necessary to study the genesis of Agile architecture, as a special approach in software development, to identify current trends and practices that are adapted to the contemporary digital environment (scalability, distribution, complexity). The results of conducted systematic literature review will help researchers and practitioners in better understanding of what Agile architecture is and its role, the current trends and directions of future development, and practices that are particularly useful in the development of complex software, with the aim of broadening the application and improvement of the agile software development process.
... It has recently been claimed that the fundamental limitations to adopting CD practices are deeply ingrained in the architecture of a system and these practices may bring substantial architectural implications [1,2,18,19]. Whilst the industrial community, through white papers and practitioners' blogs, has investigated the role of software architecture in CD adoption [2, 20,21], there is little empirical effort to study how software architecture is being impacted by or is impacting CD practices [22][23][24]. This is evident in the recently published systematic reviews on CD [18,19,25], in which a new line of research has been called to explore how an application should be (re-) architected for CD. ...
... Furthermore, to succeed in the DevOps/CD movement, which emphasizes treating operations teams and operational aspects as first-class entities in the software development process, modern architectures should deal with both design and runtime considerations (e.g., predictive monitoring) [1,[26][27][28][29]. For example, software architecture in a CD context should ensure the desired level of quality attributes (e.g., deployability), and reduce the feedback cycle time from operations to development [23]. We assert that an appropriate software architecture (SA) is required to maximize the potential benefits of CD practices. ...
... It is asserted that the maximum benefits of continuous delivery are achieved by effectively satisfying the aforementioned quality attributes. Bellomo et al. [23] studied three projects involving continuous integration and delivery to understand deployability goals of those projects. The study [23] reveals that most of the decisions made to achieve the desired state of deployment (i.e., the deployability quality attribute) were related to the architecture of the systems in those projects. ...
Recently, many software organizations have been adopting Continuous Delivery and Continuous Deployment (CD) practices to develop and deliver quality software more frequently and reliably. Whilst an increasing amount of the literature covers different aspects of CD, little is known about the role of software architecture in CD and how an application should be (re-) architected to enable and support CD. We have conducted a mixed-methods empirical study that collected data through in-depth, semi-structured interviews with 21 industrial practitioners from 19 organizations, and a survey of 91 professional software practitioners. Based on a systematic and rigorous analysis of the gathered qualitative and quantitative data, we present a conceptual framework to support the process of (re-) architecting for CD. We provide evidence-based insights about practicing CD within monolithic systems and characterize the principle of "small and independent deployment units" as an alternative to the monoliths. Our framework supplements the architecting process in a CD context through introducing the quality attributes (e.g., resilience) that require more attention and demonstrating the strategies (e.g., prioritizing operations concerns) to design operations-friendly architectures. We discuss the key insights (e.g., monoliths and CD are not intrinsically oxymoronic) gained from our study and draw implications for research and practice.
... It has recently been claimed that the fundamental limitations to adopting CD practices are deeply ingrained in the architecture of a system and these practices may bring substantial architectural implications [1,2,18,19]. Whilst the industrial community, through white papers and practitioners' blogs, has investigated the role of software architecture in CD adoption [2, 20,21], there is little empirical effort to study how software architecture is being impacted by or is impacting CD practices [22][23][24]. This is evident in the recently published systematic reviews on CD [18,19,25], in which a new line of research has been called to explore how an application should be (re-) architected for CD. ...
... Furthermore, to succeed in the DevOps/CD movement, which emphasizes treating operations teams and operational aspects as first-class entities in the software development process, modern architectures should deal with both design and runtime considerations (e.g., predictive monitoring) [1,[26][27][28][29]. For example, software architecture in a CD context should ensure the desired level of quality attributes (e.g., deployability), and reduce the feedback cycle time from operations to development [23]. We assert that an appropriate software architecture (SA) is required to maximize the potential benefits of CD practices. ...
... It is asserted that the maximum benefits of continuous delivery are achieved by effectively satisfying the aforementioned quality attributes. Bellomo et al. [23] studied three projects involving continuous integration and delivery to understand deployability goals of those projects. The study [23] reveals that most of the decisions made to achieve the desired state of deployment (i.e., the deployability quality attribute) were related to the architecture of the systems in those projects. ...
Recently, many software organizations have been adopting Continuous Delivery and Continuous Deployment (CD) practices to develop and deliver quality software more frequently and reliably. Whilst an increasing amount of the literature covers different aspects of CD, little is known about the role of software architecture in CD and how an application should be (re-) architected to enable and support CD. We have conducted a mixed-methods empirical study that collected data through in-depth, semi-structured interviews with 21 industrial practitioners from 19 organizations, and a survey of 91 professional software practitioners. Based on a systematic and rigorous analysis of the gathered qualitative and quantitative data, we present a conceptual framework to support the process of (re-) architecting for CD. We provide evidence-based insights about practicing CD within monolithic systems and characterize the principle of “small and independent deployment units” as an alternative to the monoliths. Our framework supplements the architecting process in a CD context through introducing the quality attributes (e.g., resilience) that require more attention and demonstrating the strategies (e.g., prioritizing operations concerns) to design operations-friendly architectures. We discuss the key insights (e.g., monoliths and CD are not intrinsically oxymoronic) gained from our study and draw implications for research and practice.
... Architectural choices and design decisions have a great impact on the amount of ATD [18], [19], and can be incurred by either explicit or implicit architecture decisions [11] and be made either consciously or unconsciously [20]. These decisions affect several different categories of debt, and one of the main categories of ATD are architectural dependencies [4], [21] including module dependencies, external dependencies, external team dependencies [22]. ...
... Dependency violations [22], [32], [38], [34], [28], [41], [20], [33], [4], [31], [35] , [17], [39], [5], [19], [21] Non-Uniformity of patterns and policies [27], [38], [11], [20], [5], [24] Code issue [23], [32], [33], [4], [35], [24] Inter-dependent resources [31], [26], [4], [17] Lack of mechanisms for addressing None Functional Requirements [26], [4], [41] Detection [17], [24], [25], [28], [41], [20], [21] Time perspective [32], [28], [41], [4], [5], [31], [35] Complexity [24], [37], [20], [12], [19], [21] Flexibility [27], [26], [32], [17] Maintenance and evolvability [24], [11], [28], [41], [20], [25], [4], [5], [31] Innovation and system growth [5], [32], [31] Performance degradations [23] Reliability [23], [26], [17] ATDM Process [41], [28], [11] Measuring [22], [24], [38], [34], [11], [41], [31] Tracking [22], [32], [34], [11], [28], [41], [4], [31] Evaluating [22], [34], [11], [31] Extent none/ partial/full) [4], [5], [31] Timing [24], [33], [4], [5], [31], [35] Resources [34], [31] Cost-Benefit analysis [34], [33], [5], [31], [35], [29] A. ATD identification checklist (RQ1.1) The research question RQ1.1 is addressed with an ATD identification checklist, in the form of a unified model (Fig.4). ...
... Dependency violations [22], [32], [38], [34], [28], [41], [20], [33], [4], [31], [35] , [17], [39], [5], [19], [21] Non-Uniformity of patterns and policies [27], [38], [11], [20], [5], [24] Code issue [23], [32], [33], [4], [35], [24] Inter-dependent resources [31], [26], [4], [17] Lack of mechanisms for addressing None Functional Requirements [26], [4], [41] Detection [17], [24], [25], [28], [41], [20], [21] Time perspective [32], [28], [41], [4], [5], [31], [35] Complexity [24], [37], [20], [12], [19], [21] Flexibility [27], [26], [32], [17] Maintenance and evolvability [24], [11], [28], [41], [20], [25], [4], [5], [31] Innovation and system growth [5], [32], [31] Performance degradations [23] Reliability [23], [26], [17] ATDM Process [41], [28], [11] Measuring [22], [24], [38], [34], [11], [41], [31] Tracking [22], [32], [34], [11], [28], [41], [4], [31] Evaluating [22], [34], [11], [31] Extent none/ partial/full) [4], [5], [31] Timing [24], [33], [4], [5], [31], [35] Resources [34], [31] Cost-Benefit analysis [34], [33], [5], [31], [35], [29] A. ATD identification checklist (RQ1.1) The research question RQ1.1 is addressed with an ATD identification checklist, in the form of a unified model (Fig.4). ...
Large Software Companies need to support the continuous and fast delivery of customer value in both the short and long term. However, this can be impeded if the evolution and maintenance of existing systems is hampered by what has been recently termed Technical Debt (TD). Specifically, Architectural TD has received increased attention in the last few years due to its significant impact on system success and, left unchecked, it can cause expensive repercussions. It is therefore important to understand the underlying factors of architectural TD. With this as background, there is a need for a descriptive model to illustrate and explain different architectural TD issues. The aim of this study is to synthesize and compile research efforts with the goal of creating new knowledge with a specific interest in the architectural TD field. The contribution of this paper is the presentation of a novel descriptive model, providing a comprehensive interpretation of the architectural TD phenomenon. This model categorizes the main characteristics of architectural TD and reveals their relations. The results show that, by using this model, different stakeholders could increase the system’s success rate, and lower the rate of negative consequences, by raising awareness about architectural TD.
... Architectural choices and design decisions have a great impact on the amount of ATD [18], [19], and can be incurred by either explicit or implicit architecture decisions [11] and be made either consciously or unconsciously [20]. These decisions affect several different categories of debt, and one of the main categories of ATD are architectural dependencies [4], [21] including module dependencies, external dependencies, external team dependencies [22]. ...
... Dependency violations [22], [32], [38], [34], [28], [41], [20], [33], [4], [31], [35] , [17], [39], [5], [19], [21] Non-Uniformity of patterns and policies [27], [38], [11], [20], [5], [24] Code issue [23], [32], [33], [4], [35], [24] Inter-dependent resources [31], [26], [4], [17] Lack of mechanisms for addressing None Functional Requirements [26], [4], [41] Detection [17], [24], [25], [28], [41], [20], [21] Time perspective [32], [28], [41], [4], [5], [31], [35] Complexity [24], [37], [20], [12], [19], [21] Flexibility [27], [26], [32], [17] Maintenance and evolvability [24], [11], [28], [41], [20], [25], [4], [5], [31] Innovation and system growth [5], [32], [31] Performance degradations [23] Reliability [23], [26], [17] ATDM Process [41], [28], [11] Measuring [22], [24], [38], [34], [11], [41], [31] Tracking [22], [32], [34], [11], [28], [41], [4], [31] Evaluating [22], [34], [11], [31] Extent none/ partial/full) [4], [5], [31] Timing [24], [33], [4], [5], [31], [35] Resources [34], [31] Cost-Benefit analysis [34], [33], [5], [31], [35], [29] A. ATD identification checklist (RQ1.1) The research question RQ1.1 is addressed with an ATD identification checklist, in the form of a unified model (Fig.4). ...
... Dependency violations [22], [32], [38], [34], [28], [41], [20], [33], [4], [31], [35] , [17], [39], [5], [19], [21] Non-Uniformity of patterns and policies [27], [38], [11], [20], [5], [24] Code issue [23], [32], [33], [4], [35], [24] Inter-dependent resources [31], [26], [4], [17] Lack of mechanisms for addressing None Functional Requirements [26], [4], [41] Detection [17], [24], [25], [28], [41], [20], [21] Time perspective [32], [28], [41], [4], [5], [31], [35] Complexity [24], [37], [20], [12], [19], [21] Flexibility [27], [26], [32], [17] Maintenance and evolvability [24], [11], [28], [41], [20], [25], [4], [5], [31] Innovation and system growth [5], [32], [31] Performance degradations [23] Reliability [23], [26], [17] ATDM Process [41], [28], [11] Measuring [22], [24], [38], [34], [11], [41], [31] Tracking [22], [32], [34], [11], [28], [41], [4], [31] Evaluating [22], [34], [11], [31] Extent none/ partial/full) [4], [5], [31] Timing [24], [33], [4], [5], [31], [35] Resources [34], [31] Cost-Benefit analysis [34], [33], [5], [31], [35], [29] A. ATD identification checklist (RQ1.1) The research question RQ1.1 is addressed with an ATD identification checklist, in the form of a unified model (Fig.4). ...
Fast software deliveries are hindered by high maintenance efforts due to internal quality issues and Technical Debt (TD) and specifically, Architectural Technical Debt (ATD) has received increased attention in the last few years. ATD has a significant influence and impact on system success and, left unchecked, it can cause expensive repercussions; it is, therefore, of maintenance and evolutionary importance to understand the basic underlying factors of ATD. Thus, with this as background, there is a need for a descriptive model to illustrate and explain the different ATD issues. The aim of this study is to synthesize and compile research efforts with the goal of creating new knowledge with a specific interest in the ATD field. The contribution of this paper is the presentation of a novel descriptive model, providing a comprehensive interpretation of the ATD phenomenon. This model categorizes the main characteristics of ATD and reveals their corresponding relations. The model is based on a systematic literature review (SLR) of currently recognized knowledge concerning ATD.
... According to [3], among DevOps practices, continuous deployment and treating operations team as first class stakeholder may necessitate the architectural modifications. Recently, a couple of academic and white papers voiced this concern, stating that software architecture should take lead in moving to CD practice [1,4,6,25]. It has been recognized that different domains and contexts bring new challenges for architects. ...
... We assert that a critical dimension of CD is to explore and understand the role of software architecture in transition to CD practice, i.e., how software should be (re-) architected to enable and support CD principles (e.g., frequent and reliable deployment). A sound architecture is expected to help ensure a desired level of quality attributes (e.g., deployability), and reduce the feedback cycle time including instant feedback from operation time [4]. This empirical study is aimed at filling this gap by systematically collecting, analyzing and classifying architectural challenges and principles for enabling and promoting CD practice. ...
... To the best of our knowledge, there are only two studies, which have explored the role of SA as a contributing factor when adopting CD [4,6]. Chen reported an experience of architecting 25 software applications for continuous delivery [6]. ...
Context: Development and Operations (DevOps) is an emerging software industry movement to bridge the gap between software development and operations teams. DevOps supports frequently and reliably releasing new features and products-- thus subsuming Continuous Deployment (CD) practice. Goal: This research aims at empirically exploring the potential impact of CD practice on architecting process. Method: We carried out a case study involving interviews with 16 software practitioners. Results: We have identified (1) a range of recurring architectural challenges (i.e., highly coupled monolithic architecture, team dependencies, and ever-changing operational environments and tools) and (2) five main architectural principles (i.e., small and independent deployment units, not too much focus on reusability, aggregating logs, isolating changes, and testability inside the architecture) that should be considered when an application is (re-) architected for CD practice. This study also supports that software architecture can better support operations if an operations team is engaged at an early stage of software development for taking operational aspects into considerations. Conclusion: These findings provide evidence that software architecture plays a significant role in successfully and efficiently adopting continuous deployment. The findings contribute to establish an evidential body of knowledge about the state of the art of architecting for CD practice
... According to [3], among DevOps practices, continuous deployment and treating operations team as first class stakeholder may necessitate the architectural modifications. Recently, a couple of academic and white papers voiced this concern, stating that software architecture should take lead in moving to CD practice [1,4,6,25]. It has been recognized that different domains and contexts bring new challenges for architects. ...
... We assert that a critical dimension of CD is to explore and understand the role of software architecture in transition to CD practice, i.e., how software should be (re-) architected to enable and support CD principles (e.g., frequent and reliable deployment). A sound architecture is expected to help ensure a desired level of quality attributes (e.g., deployability), and reduce the feedback cycle time including instant feedback from operation time [4]. This empirical study is aimed at filling this gap by systematically collecting, analyzing and classifying architectural challenges and principles for enabling and promoting CD practice. ...
... To the best of our knowledge, there are only two studies, which have explored the role of SA as a contributing factor when adopting CD [4,6]. Chen reported an experience of architecting 25 software applications for continuous delivery [6]. ...
... It is argued that one of the most pressing challenges which the organizations may encounter is how software applications should be (re-)architected to support DevOps practices such as Continuous Integration (CI), Continuous DElivery (CDE) and Continuous Deployment (CD) [2,5]. A sound architecture helps ensure a desired level of quality attributes (e.g., deployability, testability, and loggability) and can enable short feedback cycle time including instant feedback from operations [3]. However, there has been a little research on what implications DevOps/CD can have on architecting [3,5]. ...
... A sound architecture helps ensure a desired level of quality attributes (e.g., deployability, testability, and loggability) and can enable short feedback cycle time including instant feedback from operations [3]. However, there has been a little research on what implications DevOps/CD can have on architecting [3,5]. We assert that there is an important and urgent need of research to gain a deep understanding of how DevOps/CD adoption can influence the architecting processes and their outcomes in an organization. ...
... It has been reported in [5,9] that continuous delivery and deployment provide the following benefits: (i) getting more and quick feedback from software development process and customers; (ii) having frequent and reliable release, which leads to improved customer satisfaction and product quality. To date, there are only two studies, which have explored the role of software architecture as a contributing factor when adopting CD and DevOps [3,5]. Chen reported an experience of architecting 25 software applications for continuous delivery as well as proposed a set of architecturally significant requirements that should be effectively met in order to achieve the maximum benefits from continuous delivery [5]. ...
Development and Operations (DevOps) in the context of Continuous Deployment (CD) have emerged as an attractive software development movement, which tries to establish a strong connection between development and operations teams. CD is defined as the ability to quickly put new releases into production. We believe that DevOps/CD brings new challenges for architects, which considerably impacts both on their (architectural) design decisions and their organizational responsibilities. We assert that there is an important and urgent need of sufficient research work to gain a deep understanding of how DevOps/CD adoption can influence architecting, architectural decision-making processes and their outcomes in an organization. This PhD research is aimed at understanding and addressing new challenges for designing architectures for supporting DevOps in the context of CD.
... DevOps is a collection of activities and cultural principles aimed at raising the gaps that exist between engineering teams and operations. Various research studies have tried to define and explain DevOps due to its increasing popularity and inaccurate definitions [5]. ...
... Chen reported on architecting 25 continuous deliveries software applications and proposed a set of architecturally significant requirements to maximize the benefits of continuous delivery [11]. (Bellomo et al., 2014) performed analysis on three initiatives that continuous integration and continuous delivery had been implemented. The analysis concluded that most of the decisions taken to achieve deployment desire state (i.e., Deployability) were architectural [12]. ...
DevOps- a portmanteau of development and operations that come together to improve the software quality as well as to speed up the software development with its continuous delivery to its clients and customers. DevOps, emerging as an attractive software development movement, appears to be well regarded, but it is proving difficult to adopt fully in reality. Therefore, this paper contributes to understanding DevOps and addressing its challenges and practices while considering the real-world scenarios where organizations implement DevOps to pace their productivity. This paper also proposes a model which shows the key contributors in DevOps and how they are used to achieve the desired outcomes. We have carried out an exploratory case study by understanding how businesses adopt DevOps in real life. A case study is considered an effective form of analysis for studying current trends within their real-life context. DevOps is commonly described as collaborative work done between development and operations team by continuous communication and cooperation as well as featuring a cross-functional team having a common goal to achieve.
... Software architecture is expected to be the keystone for reaching the highest level of DevOps success 2,4 . Most of the reported research on software architecture and DevOps relatedness studied software architecture in continuous delivery and deployment as a key practice of DevOps 19,20,21 or only focused on the microservices architecture style as a promising style to enable DevOps 22,23,24,25,26 . For example, Shahin et al. 19 focused on the perception of practitioners from different organizations around the world on how software architecture being impacted by or impacting continuous delivery and deployment, resulting in a conceptual framework to support the process of (re-) architecting for continuous delivery and deployment. ...
... The studies 19,36 found that monoliths are the main source of pain to practice continuous delivery and deployment in the industry. In a retrospective study on three projects adopting continuous integration and delivery, Bellomo et al. 20 and "Continuous Deployment" topics were the most complicated. ...
Software architecture is critical in succeeding with DevOps. However, designing software architectures that enable and support DevOps (DevOps-driven software architectures) is a challenge for organizations. We assert that one of the essential steps towards characterizing DevOps-driven architectures is to understand architectural design issues raised in DevOps. At the same time, some of the architectural issues that emerge in the DevOps context (and their corresponding architectural practices or tactics) may stem from the context (i.e., domain) and characteristics of software organizations. To this end, we conducted a mixed-methods study that consists of a qualitative case study of two teams in a company during their DevOps transformation and a content analysis of Stack Overflow and DevOps Stack Exchange posts to understand architectural design issues in DevOps. Our study found eight specific and contextual architectural design issues faced by the two teams and classified architectural design issues discussed in Stack Overflow and DevOps Stack Exchange into 11 groups. Our aggregated results reveal that the main characteristics of DevOps-driven architectures are: being loosely coupled and prioritizing deployability, testability, supportability, and modifiability over other quality attributes. Finally, we discuss some concrete implications for research and practice.
... Software architecture is expected to be the keystone for reaching the highest level of DevOps success 2,4 . Most of the reported research on software architecture and DevOps relatedness studied software architecture in continuous delivery and deployment as a key practice of DevOps 19,20,21 or only focused on the microservices architecture style as a promising style to enable DevOps 22,23,24,25,26 . For example, Shahin et al. 19 focused on the perception of practitioners from different organizations around the world on how software architecture being impacted by or impacting continuous delivery and deployment, resulting in a conceptual framework to support the process of (re-) architecting for continuous delivery and deployment. ...
... The studies 19,36 found that monoliths are the main source of pain to practice continuous delivery and deployment in the industry. In a retrospective study on three projects adopting continuous integration and delivery, Bellomo et al. 20 and "Continuous Deployment" topics were the most complicated. ...
Software architecture is critical in succeeding with DevOps. However, designing software architectures that enable and support DevOps (DevOps-driven software architectures) is a challenge for organizations. We assert that one of the essential steps towards characterizing DevOps-driven architectures is to understand architectural design issues raised in DevOps. At the same time, some of the architectural issues that emerge in the DevOps context (and their corresponding architectural practices or tactics) may stem from the context (i.e., domain) and characteristics of software organizations. To this end, we conducted a mixed-methods study that consists of a qualitative case study of two teams in a company during their DevOps transformation and a content analysis of Stack Overflow and DevOps Stack Exchange posts to understand architectural design issues in DevOps. Our study found eight specific and contextual architectural design issues faced by the two teams and classified architectural design issues discussed in Stack Overflow and DevOps Stack Exchange into 11 groups. Our aggregated results reveal that the main characteristics of DevOps-driven architectures are: being loosely coupled and prioritizing deployability, testability, supportability, and modifiability over other quality attributes. Finally, we discuss some concrete implications for research and practice.
... A number of studies [40]- [45] have explicitly studied the management of NFRs in a CSE context; however, none of them focus on the associated lack of shared understanding. Feitelson describes how Facebook uses an open source tool, Perflab, to provide metrics which Facebook monitors to evaluate the PERFORMANCE of their system [43]. ...
... Other studies [41], [42], [45] examine how to architect a system to be used in CSE, primarily focusing on deploying as a serverless cloud-based platform. These studies focus on NFRs, such as SCALABILITY and DEPLOYABILITY, that have significant influence on a system's architecture, including positives, negatives, and trade-offs. ...
Building shared understanding of requirements is key to ensuring downstream software activities are efficient and effective. However, in continuous software engineering (CSE) some lack of shared understanding is an expected, and essential, part of a rapid feedback learning cycle. At the same time, there is a key trade-off with avoidable costs, such as rework, that come from accidental gaps in shared understanding. This trade-off is even more challenging for non-functional requirements (NFRs), which have significant implications for product success. Comprehending and managing NFRs is especially difficult in small, agile organizations. How such organizations manage shared understanding of NFRs in CSE is understudied. We conducted a case study of three small organizations scaling up CSE to further understand and identify factors that contribute to lack of shared understanding of NFRs, and its relationship to rework. Our in-depth analysis identified 41 NFR-related software tasks as rework due to a lack of shared understanding of NFRs. Of these 41 tasks 78% were due to avoidable (accidental) lack of shared understanding of NFRs. Using a mixed-methods approach we identify factors that contribute to lack of shared understanding of NFRs, such as the lack of domain knowledge, rapid pace of change, and cross-organizational communication problems. We also identify recommended strategies to mitigate lack of shared understanding through more effective management of requirements knowledge in such organizations. We conclude by discussing the complex relationship between shared understanding of requirements, rework and, CSE.
... Software Architecture (SA) is expected to be the keystone for reaching the highest level of DevOps success [2,4]. Most of the reported research on SA and DevOps relatedness has been conducted in the context of CD as a key practice of DevOps [18] [19] [20]. In our previous paper [18], we focused on the perception of practitioners from different organizations around the world on how SA being impacted by or impacting CD, resulting in a conceptual framework to support the process of (re-) architecting for CD. ...
... The studies [18,65] found that monoliths are the main source of pain to practice CD in the industry. In a retrospective study on three projects adopting continuous integration and delivery, Bellomo et al. [19] revealed 14 https://puppet.com/ that the architectural decisions made in those projects played a significant role in achieving the desired state of deployment (i.e., deployability). ...
Development and Operations (DevOps), a particular type of Continuous Software Engineering, has become a popular Software System Engineering paradigm. Software architecture is critical in succeeding with DevOps. However, there is little evidence-based knowledge of how software systems are architected in the industry to enable and support DevOps. Since architectural decisions, along with their rationales and implications, are very important in the architecting process, we performed an industrial case study that has empirically identified and synthesized the key architectural decisions considered essential to DevOps transformation by two software development teams. Our study also reveals that apart from the chosen architecture style, DevOps works best with modular architectures. In addition, we found that the performance of the studied teams can improve in DevOps if operations specialists are added to the teams to perform the operations tasks that require advanced expertise. Finally, investment in testing is inevitable for the teams if they want to release software changes faster.
... Software Architecture (SA) is expected to be the keystone for reaching the highest level of DevOps success [2,4]. Most of the reported research on SA and DevOps relatedness has been conducted in the context of CD as a key practice of DevOps [18] [19] [20]. In our previous paper [18], we focused on the perception of practitioners from different organizations around the world on how SA being impacted by or impacting CD, resulting in a conceptual framework to support the process of (re-) architecting for CD. ...
... The studies [18,65] found that monoliths are the main source of pain to practice CD in the industry. In a retrospective study on three projects adopting continuous integration and delivery, Bellomo et al. [19] revealed 14 https://puppet.com/ that the architectural decisions made in those projects played a significant role in achieving the desired state of deployment (i.e., deployability). ...
Development and Operations (DevOps), a particular type of Continuous Software Engineering, has become a popular Software System Engineering paradigm. Software architecture is critical in succeeding with DevOps. However, there is little evidence-based knowledge of how software systems are architected in the industry to enable and support DevOps. Since architectural decisions, along with their rationales and implications, are very important in the architecting process, we performed an industrial case study that has empirically identified and synthesized the key architectural decisions considered essential to DevOps transformation by two software development teams. Our study also reveals that apart from the chosen architecture style, DevOps works best with modular architectures. In addition, we found that the performance of the studied teams can improve in DevOps if operations specialists are added to the teams to perform the operations tasks that require advanced expertise. Finally, investment in testing is inevitable for the teams if they want to release software changes faster.
... Such differences delay feedback because problems specific to production environments will not be discovered until code is deployed to production. Given these challenges, research has described the transition to continuous feedback practices as the quest for the holy grail [4], a "hump of pain" [48,67], or a process that requires high levels of top management support and months or years to complete [28]. ...
... In line with the principle of constant comparison, we sampled to maximize our ability to make comparisons. Our final sample of 16 software development teams (see Table 1) includes teams that vary in a number of dimensions, specifically (1) the software development rationale (i.e., why and for whom the team developed software), (2) whether they used PaaS, (3) the PaaS product, (4) whether the PaaS provider was external, (5) team size, (6) project duration, (7) organization size, and (8) the dominant software development methods in their organizations. ...
Although software development teams increasingly use Platform-as-a-Service (PaaS), little is known about the impact of PaaS on software development. We explored the impact of PaaS on software development through a grounded-theory study, conducting 48 interviews in 16 teams. The data turned our attention to the affordances, or potentials for action, that PaaS provides to software development teams. Two key affordances emerging from our data analysis were self-organizing and triggering continuous feedback. Actualizing these affordances helped accelerate the collective learning processes that underlie software development, thus supporting software development teams in their quest for agility. Our emerging theory explains how, why, and when these affordances arise. The key contribution of our paper lies in unveiling how the use of cloud computing technology can transform technology-mediated collective learning activities by helping to remove barriers to rapid feedback. Our findings also imply that organizations can leverage PaaS to facilitate the transition to agile and continuous software development practices, in particular in conjunction with cross-functional team designs.
... Bellomo et al. [60] investigated CD practice in relation to deployability improvement goals and architectural design decisions in three projects from different organizations. Their analysis shows that the main deployability improvement goals are "build and continuous integration," "'test automation," "deployment and robust operations" and "synchronized and flexible environments". ...
... Their analysis shows that the main deployability improvement goals are "build and continuous integration," "'test automation," "deployment and robust operations" and "synchronized and flexible environments". Consequently, they state that the transition to CD practice requires new tactics for architectural design such as "an integrated test framework," "script-driven process shutdown," "web service consolidation," "parameterization," "self-monitoring," "adapter container," "singleresponsibility principle and distributed service architecture," "managing and reproducing state," "self-initiating version update," "monitoring and auto-scaling," "removing web services and collapsing the middle tier," "load balancer," and "bundle and rollback feature and data layer change" [60]. Architecture-related requirements and tactics for the transition to IES have also been addressed in other studies and contexts: support for A/B testing [22,23], modularity [22,23], instrumentation for data collection [23], testability [22], run-time functionality variation [22] and the independent deployability of functionalities [22]. ...
Agile release engineering (ARE) practices are designed to deliver software faster and cheaper to end users; hence, claims of such impacts should be validated by rigorous and relevant empirical studies.
... The monolithic architecture of legacy systems, including those built in an agile manner, is unsuited for several daily builds and deployments (Laukkanen et al. 2017) and a comprehensive, lengthy and costly refactoring of the software product into smaller components, e.g., microservices, is needed to meet the needs of CSE (Laukkanen et al. 2017;Leppänen et al. 2015;Shahin et al. 2018) CSE cannot be reduced to a single set of practices and technologies ) but selecting the most suited approach to CSE is complicated (Shahin et al. 2018). Bellomo (2014) describes 15 different architectural and design tactics that companies must consider for CSE. The tactics range from a complete architectural overhaul, such as moving to microservices, to parametrization of database and server names. ...
... Besides technical challenges, Claps et al. [11] focused also on social challenges companies are faced with and present mitigation strategies. Bellomo et al. [6] investigated architectural decisions companies take to enable CD and introduced deployability and design tactics. ...
Despite substantial recent research activity related to continuous delivery and deployment (CD), there has not yet been a systematic, empirical study on how the practices often associated with continuous deployment have found their way into the broader software industry. This raises the question to what extent our knowledge of the area is dominated by the peculiarities of a small number of industrial leaders, such as Facebook. To address this issue, we conducted a mixed-method empirical study, consisting of a pre-study on literature, qualitative interviews with 20 software developers or release engineers with heterogeneous backgrounds, and a Web-based quantitative survey that attracted 187 complete responses. A major trend in the results of our study is that architectural issues are currently one of the main barriers for CD adoption. Further, feature toggles as an implementation technique for partial rollouts lead to unwanted complexity, and require research on better abstractions and modelling techniques for runtime variability. Finally, we conclude that practitioners are in need for more principled approaches to release decision making, e.g., which features to conduct A/B tests on, or which metrics to evaluate.
... Besides technical challenges, Claps et al. [11] focused also on social challenges companies are faced with and present mitigation strategies. Bellomo et al. [6] investigated architectural decisions companies take to enable CD and introduced deployability and design tactics. ...
Despite substantial recent research activity related to continuous delivery and deployment (CD), there has not yet been a systematic, empirical study on how the practices often associated with continuous deployment have found their way into the broader software industry. This raises the question to what extent our knowledge of the area is dominated by the peculiarities of a small number of industrial leaders, such as Facebook. To address this issue, we conducted a mixed-method empirical study, consisting of a pre-study on literature, qualitative interviews with 20 software developers or release engineers with heterogeneous backgrounds, and a Web-based quantitative survey that attracted 187 complete responses. A major trend in the results of our study is that architectural issues are currently one of the main barriers for CD adoption. Further, feature toggles as an implementation technique for partial rollouts lead to unwanted complexity, and require research on better abstractions and modelling techniques for runtime variability. Finally, we conclude that practitioners are in need for more principled approaches to release decision making, e.g., which features to conduct A/B tests on, or which metrics to evaluate.
... Software Architecture (SA) is slated to be the foundation for reaching the highest level of DevOps success [6,55]. Most of the noted research related to SA and DevOps carried on in the context of CD as a key practice of DevOps [7,56,57]. Shahin et al. [7] have conducted a mixed-methods study to explore how SA is being impacted by or is impacting CD. They present a conceptual framework to support (re-) architecting for CD. ...
Quality pressure is one of the factors affecting processes for software development in its various stages. DevOps is one of the proposed solutions to such pressure. The primary focus of DevOps is to increase the deployment speed, frequency and quality. DevOps is a mixture of different developments and operations to its multitudinous ramifications in software development industries, DevOps have attracted the interest of many researchers. There are considerable literature surveys on this critical innovation in software development, yet, little attention has been given to DevOps impact on software quality. This research is aimed at analyzing the implications of DevOps features on software quality. DevOps can also be referred to a change in organization cultures aimed at removal of gaps between the development and operations of an organization. The adoption of DevOps in an organization provides many benefits including quality but also brings challenges to an organization. This study presents systematic mapping of the impact of DevOps on software quality. The results of this study provide a better understanding of DevOps on software quality for both professionals and researchers working in this area. The study shows research was mainly focused in automation, culture, continuous delivery, fast feedback of DevOps. There is need of further research in many areas of DevOps (for instance: measurement, development of metrics of different stages to assess its performance, culture, practices toward ensuring quality assurance, and quality factors such as usability, efficiency, software maintainability and portability).
... Recently, Chen [2017] presented six strategies to overcome adoption challenges and in addition proposed possible directions for future research. Bellomo et al. [2014] investigated architectural decisions companies take to enable CD and introduced deployability and design tactics. Itkonen et al. [2016] investigated the adoption of CD in a single case study company and report on the benefits it enables for both customers and developers. ...
... substantial architectural implications [1,7,9,33]. Whilst the industrial community through white papers and practitioners' blogs has investigated the role of software architecture in CD adoption [9,37,39], there is little empirical effort to study how software architecture is being impacted by or is impacting CD practices [38,40,139]. This is evident in the recently published systematic reviews on CD [1,33,34], in which a new line of research has been called to explore how an application should be (re-) architected for CD. ...
Attracted by increasing the need of being able to improve business competitiveness and performance, many organizations have started to optimize themselves to develop and deliver high-quality values more quickly and reliably. Development and Operations (DevOps) is emerging as a promising approach in the software industry to help organizations to realize this goal. However, establishing DevOps practices, specifically continuous delivery and continuous deployment practices, in the industry is a challenge as it requires new organizational capabilities and novel techniques, methods and tools for application design, testing and deployment.
Most research on DevOps focuses on tooling support, improving automation in testing and deployment, improving performance and integrating security into the deployment process to initiate and implement DevOps. To date, little is known about the impact of continuous delivery and deployment as two main DevOps practices on organizational structure (i.e., team structure) and the architecture of a system, those that are supposed to be fundamental limitations to adopt these practices.
This thesis aims at filling this gap by conducting a set of empirical studies. We first design and conduct a systematic literature review to gain a comprehensive understanding of the concept of continuous delivery and deployment and the current state of research in this regard. Second, we design, implement and analyze a large-scale mixed-methods empirical study, consisting of 21 interviews and 98 survey responses. Finally, we conduct an in-depth industrial case study with two teams in a case company to explore the role of software architecture in DevOps transition. The empirical studies contribute to (1) provide detailed insights into the specifics of challenges moving from continuous delivery to continuous deployment; (2) find how teams are organized in software industry for adopting continuous delivery and deployment; and (3) develop evidence-based guidelines on how to (re-) architect an application to enable and support continuous delivery and deployment.
... Bellomo [6] X X X The time of a deployment cycle, ideally to be shortened to shorten the feedback cycle; binding time (to be deferred sometimes); application runtime in distributed systems, with focus on issues of synchronization Guo [11] X X X Guo [12] X X Project deadlines, including very hard deadlines that must be met at the risk of losing business. Current vs. future technical debt. ...
Technical Debt arises from decisions that favour short-term outcomes at the cost of longer-term disadvantages. They may be taken knowingly or based on missing or incomplete awareness of the costs; they are taken in different roles, situations, stages and ways. Whatever technical or business factor motivate such decisions, they always imply a trade-off in time, a 'now vs. later'. How exactly are such decisions made, and how have they been studied?
This paper analyzes how decisions on technical debt are studied in software engineering via a systematic literature review. It examines the presently published Software Engineering research on Technical Debt, with a particular focus on decisions involving time. The findings reveal surprising gaps in published work on empirical research in decision making. We observe that research has rarely studied how decisions are made, even in papers that focus on the decision process. Instead, most attention is focused on engineering measures and feeding them into an idealized decision making process. These findings lead to a set of recommendations for future empirical research on Technical Debt.
... My previous work presents ASRs that CD amenable applications should meet [6], but it does not tell how to meet those ASRs. Bellomo, et al. [14] provided an in-depth description of deployability. However, the description does not cover modifiability. ...
Businesses today need to respond to customer needs at unprecedented speeds. Driven by this need for speed, many companies are rushing to the DevOps movement and implementing Continuous Delivery (CD). I had been implementing DevOps and CD for Paddy Power, a multi-billion-euro betting and gaming company, for four years. I had found that software architecture can be a key barrier. To address the architectural challenges, we tried an emerging architectural style called Microservices. I have observed increased deployability, modifiability, and resilience to design erosion. At the same time, I also observed new challenges associated with the increased number of services, evolving contracts among services, technology diversity, and testing. I share the practical strategies that can be employed to address these new challenges, discuss situations for which Microservices may not be a good choice, and outline areas that require further research.
... Similarly, in Publication II and Publication IV, the system design made the automated testing and deployment of the system more difficult, as the system tests were not reliable enough and deploying the systems was not possible without downtime. The results of this dissertation align with other studies that have 37 investigated the relationship between the system design and modern release engineering practices [9,45,46,47,48]. ...
Release engineering means the process of bringing the individual changes made to a software system to the end users of the software with high quality. The modern release engineering practices emphasize using build, test and deployment automation and facilitating collaboration across functional boundaries, so that it is possible to achieve both speed and quality in the release engineering process. While some companies have been successful in adopting modern release engineering practices, other companies have found the adoption to be problematic.
In this dissertation, we aim to understand what prevents organizations from adopting modern release engineering practices. First, we conducted a systematic literature review to survey the literature about the adoption problems, their causes and solutions. In addition, we conducted four case studies which included qualitative interviews and software repository mining as data collection methods. In the first case study, we investigated the adoption problems in a distributed organization. The case study was extended in a follow-up case study, in order to see how the release stabilization period could be reduced after the adoption efforts. In the third case study, we focused on the consequences of the stage-gate development process and how it explained the adoption problems. Finally, we compared two organizations with different organizational contexts working with similar products in the fourth case study, in order to compare the effects of different organizational contexts.
This dissertation identifies, that adopting modern release engineering practices decreases the time needed for stabilizing a software system before it can be deployed. Problems during the adoption of modern release engineering practices are categorized under problem themes of technical adoption and social adoption. Technical adoption problems include build automation (slow, complex or inflexible build), test automation (slow, unreliable or insufficent tests) and deployment automation (slow, complex or unreliable deployment) problems, and social adoption problems include organizational adoption (lack of resources or coordination) and individual adoption (lack of motivation or experience) problems. These primary problems can be explained with three identified explanations: system design (system not testable or deployable) explains technical adoption problems, organizational distribution (more difficult communication, motivation and coordination) explains social adoption problems and limited resources explain both adoption problem themes. Organizations can use the results of the dissertation to design their software processes and practices accordingly to suit modern release engineering practices.
... To meet the second objective, these scenarios will be used for architecting a CubeSat system such that the selected architecture optimizes its key quality attributes (NFRs). The key justification for architecting for non-functionalities, as discussed in [21] [15], is that it provides a context under which design decisions and their consequences can be systematically analyzed as the system evolves through continuous integration and validation. The selected software architecture (ATAM [20]) will then be precisely defined using the AADL model-based engineering language [20, 22, 23] and analyzed using OSATE [24] to ensure that the software architecture supports the specified qualities. ...
... To meet the second objective, these scenarios will be used for architecting a CubeSat system such that the selected architecture optimizes its key quality attributes (NFRs). The key justification for architecting for non-functionalities, as discussed in [21] [15], is that it provides a context under which design decisions and their consequences can be systematically analyzed as the system evolves through continuous integration and validation. The selected software architecture (ATAM [20]) will then be precisely defined using the AADL model-based engineering language [20,22,23] and analyzed using OSATE [24] to ensure that the software architecture supports the specified qualities. ...
The OpenOrbiter CubeSat Development Initiative is working to build a small spacecraft system using open source software and open hardware principles. Some important design considerations for the CubeSat are nonfunctional requirements. The key contribution of this work is presenting the design of a requirement engineering tool that can be used to speed up the requirement elicitation and specification of system-wide qualities such as availability, performance, and security based on the use of quality attribute scenarios. A prototype application, utilizing the concept of quality attribute scenarios which was originally proposed by the Carnegie Mellon Software Engineering Institute (SEI), was designed and implemented. These quality attribute scenarios are the equivalent of UML scenarios and use-cases. They are built specifically to document the nonfunctional requirements and use a quality scenario template.
... To fully automate testing the system needs to provide architectural (system-wide) test capabilities such as interfaces to record, playback, and control system state. Cases 7-10, and many others [9], validated that (Lesson 7) an architectural approach to DevOps was critical to achieving strategic control over continuous delivery goals. ...
This article contributes an architecture-centric methodology, called AABA ( A rchitecture-centric A gile B ig data A nalytics), to address the technical, organizational, and rapid technology change challenges of both big data system development and agile delivery of big data analytics for Web-based Systems (WBS). As the first of its kind, AABA fills a methodological void by adopting an architecture-centric approach, advancing and integrating software architecture analysis and design, big data modeling and agile practices. This article describes how AABA was developed, evolved and validated simultaneously in 10 empirical WBS case studies through three CPR (Collaborative Practice Research) cycles. In addition, this article presents an 11th case study illustrating the processes, methods and techniques/tools in AABA for cost-effectively achieving business goals and architecture agility in a large scale WBS. All 11 case studies showed that architecture-centric design, development, and operation is key to taming technical complexity and achieving agility necessary for successful WBS big data analytics development. Our contribution is novel and important. The use of reference architectures, a design concepts catalog and architectural spikes in AABA are advancements to architecture design methods. In addition, our architecture-centric approach to DevOps was critical for achieving strategic control over continuous big data value delivery for WBS.
... Bellomo et al. [6] presented an architectural framework together with tactics to projects that address SCD. The main contribution of this work is a collection of SCD tactics in order to get software products performing with a higher level of reliability and monitoring into production environment. ...
... To meet the second objective, these scenarios will be used for architecting a future CubeSat system such that the selected architecture optimizes its key quality attributes (NFRs). The key justification for architecting for nonfunctionalities, as discussed in [35], is that it provides a context under which design decisions and their consequences can be systematically analyzed as the system evolves through continuous integration and validation. The selected software architecture (ATAM [17]) then will be precisely defined using the model-based engineering language AADL [17,36,37] and analyzed using OSATE [8] to ensure that the software architecture supports the specified qualities. ...
... The most relevant tactics include parameterization, self-monitoring, and selfinitiating version-update support. While these tactics are also relevant in building the system architecture, they become more significant when managing the alignment of the architecture with the production environment and supporting large-scale operations [23]. ...
For large-scale software-development endeavors, agility is enabled by architecture, and vice versa. The iterative, risk-driven life cycle inherent in agile approaches allows developers to focus early on key architectural decisions, spread these decisions over time, and validate architectural solutions early. Conversely, an early focus on architecture allows a large agile project to define an implementation structure that drives an organization into small teams, some focusing on common elements and their key relationships and some working more autonomously on features. Architects in agile software development typically work on three distinct but interdependent structures: architecture of the system, the structure of the development organization, and the production infrastructure. Architectural work supports the implementation of high-priority business features without risking excessive redesign later or requiring heavy coordination between teams. Architectural tactics provide a framework for identifying key concerns and guide the alignment of these three structures throughout the development life cycle.
Architectural tactics are a key abstraction of software architecture, and support the systematic design and analysis of software architectures to satisfy quality attributes. Since originally proposed in 2003, architectural tactics have been extended and adapted to address additional quality attributes and newer kinds of systems, making quite hard for researchers and practitioners to master this growing body of specialized knowledge. This paper presents the design, execution and results of a systematic mapping study of architectural tactics in software architecture literature. The study found 552 studies in well-known digital libraries, of which 79 were selected and 12 more were added with snowballing, giving a total of 91 primary studies. Key findings are: (i) little rigor has been used to characterize and define architectural tactics; (ii) most architectural tactics proposed in the literature do not conform to the original definition; and (iii) there is little industrial evidence about the use of architectural tactics. This study organizes and summarizes the scientific literature to date about architectural tactics, identifies research opportunities, and argues for the need of more systematic definition and description of tactics.
Editor’s note: Open Science material was validated by the Journal of Systems and Software Open Science Board.
Context
Complying with privacy regulations has taken on new importance with the introduction of the EU’s General Data Protection Regulation (GDPR) and other privacy regulations. Privacy measures are becoming a paramount requirement demanding software organizations’ attention as recent privacy breaches such as the Capital One data breach affected millions of customers. Software organizations, however, struggle with achieving privacy compliance. In particular, there is a lack of research into the organizational practices and challenges involved in compliance, particularly for small and medium enterprises (SMEs), which represent a sizeable portion of organizations. Many SMEs use a continuous software engineering (CSE) approach, which introduces additional adoption and application challenges. For example, the fast pace of CSE makes it harder for SMEs that are already more resource constrained to prioritize non-functional requirements such as privacy.
Objective
This paper aims to fill a gap in the under-researched area of continuous compliance with privacy requirements in practice, by investigating how a continuous practicing SME dealt with GDPR compliance.
Method
Using design science, we conducted an in-depth ethnographically informed study over the span of 16 months and iteratively developed two artifacts to help address the organization’s challenges in addressing GDPR compliance.
Results
We identified 3 main challenges that our collaborating organization experienced when trying to comply with the GDPR. To help mitigate the challenges, we developed two design science artifacts, which include a list of privacy requirements that operationalized the GDPR principles for automated verification, and an automated testing tool that helps to verify these privacy requirements. We validated these artifacts through close collaboration with our partner organization and applying our artifacts to the partner organization’s system.
Conclusions
We conclude with a dicussion of opportunities and obstacles in leveraging CSE to achieve continuous compliance with the GDPR. We also highlight the importance of building a shared understanding of privacy non-functional requirements and how risk management plays an important role in an organization’s GDPR compliance.
With highly increased competition, intelligent product manufacturing based on interpretable knowledge bases has been recognized as an effective method for building applications of explainable Artificial Intelligence that is the hottest topic in the field of Artificial Intelligence. The success of product family directly depends on how effective the viability mechanisms are laid down in its design. In this paper, a systematic cloud-based set of tool family is proposed to develop viable knowledge-based systems. For productive participation of domain and cognitive specialists in manufacturing, the knowledge base should be declarative, testable and integratable with other architectural components. Mechanisms to ensure KBS viability are provided in an ontology-oriented development environment, where each component is formed in terms of domain ontology by using the adaptable instrumental support.
Due to the explicit separation of ontology from knowledge, it became possible to divide competencies between specialists creating an ontology and specialists creating a knowledge base. We rely on the fact that the activity of creating an ontology is significantly different from the activity of creating a knowledge base. Creating an ontology is a creative process that requires a systematic analysis of the domain area in order to identify common patterns among its knowledge.
The characteristic properties of knowledge-based systems related to viability are described. It is explained, how these properties are provided in development environments implemented on cloud platform. The concept of a specialized manufacturing environment for knowledge-based system is introduced. The necessary set of tools for such ontology-oriented environment construction is determined.
The example of tools for creating specialized manufacturing environments is the instruments implemented on the «IACPaaS» platform. The IACPaaS is already used for collective development of thematic cloud knowledge portals with viable knowledge-based systems. This specialized manufacturing environment has enabled the creation of multi-purpose medical software services to support specialist solutions based on knowledge being remotely improved by experts.
The term DevOps grew out of conversations that Patrick Debois, a system administrator at the time, and Andrew Shafer, a software developer, were having in 2009 along with others sharing their frustrations in how difficult it was to move development to operations. They observed that the agility, automation, and communication barriers between development and operations teams were common across many organizations. The developers put the responsibility on operations and mismatches in the deployment environment. The operations teams assumed that the problems culminated from the implementation. The teams clearly lacked a common deployment and operations view of the system, one of the key aspects of any system's architecture.
Context
Continuous experimentation guides development activities based on data collected on a subset of online users on a new experimental version of the software. It includes practices such as canary releases, gradual rollouts, dark launches, or A/B testing.
Objective
Unfortunately, our knowledge of continuous experimentation is currently primarily based on well-known and outspoken industrial leaders. To assess the actual state of practice in continuous experimentation, we conducted a mixed-method empirical study.
Method
In our empirical study consisting of four steps, we interviewed 31 developers or release engineers, and performed a survey that attracted 187 complete responses. We analyzed the resulting data using statistical analysis and open coding.
Results
Our results lead to several conclusions: (1) from a software architecture perspective, continuous experimentation is especially enabled by architectures that foster independently deployable services, such as microservices-based architectures; (2) from a developer perspective, experiments require extensive monitoring and analytics to discover runtime problems, consequently leading to developer on call policies and influencing the role and skill sets required by developers; and (3) from a process perspective, many organizations conduct experiments based on intuition rather than clear guidelines and robust statistics.
Conclusion
Our findings show that more principled and structured approaches for release decision making are needed, striving for highly automated, systematic, and data- and hypothesis-driven deployment and experimentation.
The practice of continuous integration has firmly established itself in the mainstream of the software engineering industry, yet many questions surrounding it remain unanswered. Prominent among these is the issue of scalability: continuous integration has been reported to be possible to scale, but with difficulties. Understanding of the underlying mechanisms causing these difficulties is shallow, however: what is it about size that is problematic, which kind of size, and what aspect of continuous integration does it impede? Based on quantitative data from six industry cases encompassing close to 2,000 engineers, complemented by interviews with engineers from five companies, this paper investigates the correlation between the continuity of continuous integration and size. It is found that not only is there indeed a correlation between the size and composition of a development organization and its tendency to integrate continuously; there is evidence that the size of the organization influences ways of working, which in turn correlate with the degree of continuity, raising the question of software manufacturability. It is further observed that developer behavior in ostensibly continuously integrating cases does not necessarily match expectations, and that frequent integration of the product itself does not automatically imply that each individual developer commits frequently.
Context: Technical debt (TD) is a metaphor that is used to communicate the consequences of poor software development practices to non-technical stakeholders. In recent years, it has gained significant attention in agile software development (ASD). Objective: The purpose of this study is to analyze and synthesize the state of the art of TD, and its causes, consequences, and management strategies in the context of ASD. Research Method: Using a systematic literature review (SLR), 38 primary studies, out of 346 studies, were identified and analyzed. Results: We found five research areas of interest related to the literature of TD in ASD. Among those areas, “managing TD in ASD” received the highest attention, followed by “architecture in ASD and its relationship with TD”. In addition, eight categories regarding the causes and five categories regarding the consequences of incurring TD in ASD were identified. “Focus on quick delivery” and “architectural and design issues” were the most popular causes of incurring TD in ASD. “Reduced productivity”, “system degradation” and “increased maintenance cost” were identified as significant consequences of incurring TD in ASD. Additionally, we found 12 strategies for managing TD in the context of ASD, out of which “refactoring” and “enhancing the visibility of TD” were the most significant. Conclusion: The results of this study provide a structured synthesis of TD and its management in the context of ASD as well as potential research areas for further investigation.
Context: Continuous delivery is a software development discipline in which software is always kept releasable. The literature contains instructions on how to adopt continuous delivery, but the adoption has been challenging in practice.
Objective: In this study, a systematic literature review is conducted to survey the faced problems when adopting continuous delivery. In addition, we identify causes for and solutions to the problems.
Method: By searching five major bibliographic databases, we identified 293 articles related to continuous delivery. We selected 30 of them for further analysis based on them containing empirical evidence of adoption of continuous delivery, and focus on practice instead of only tooling. We analyzed the selected articles qualitatively and extracted problems, causes and solutions. The problems and solutions were thematically synthesized into seven themes: build design, system design, integration, testing, release, human and organizational and resource.
Results: We identified a total of 40 problems, 28 causal relationships and 29 solutions related to adoption of continuous delivery. Testing and integration problems were reported most often, while the most critical reported problems were related to testing and system design. Causally, system design and testing were most connected to other themes. Solutions in the system design, resource and human and organizational themes had the most significant impact on the other themes. The system design and build design themes had the least reported solutions.
Conclusions: When adopting continuous delivery, problems related to system design are common, critical and little studied. The found problems, causes and solutions can be used to solve problems when adopting continuous delivery in practice.
Since 2009, DevOps, the combination of development and operation, has been adopted within organizations in industry, such as Netflix, Flickr, and Fotopedia. Configuration management tools have been used to support DevOps. However, in this paper we investigate which Knowledge, Skills, and Abilities (KSA) have been employed in developing and deploying modern web applications and how these KSAs support DevOps. By applying a qualitative analysis approach, namely grounded theory, to three web application development projects, we discover that the KSAs for both Software Development and IT Operator practitioners support the four perspectives of DevOps: collaboration culture, automation, measurement, and sharing.
Scaling a web applications can be easy for simple CRUD software running when you use Platform as a Service Clouds (PaaS). But if you need to deploy a complex software, with many components and a lot users, you will need have a mix of cloud services in PaaS, SaaS and IaaS layers. You will also need knowledge in architecture patterns to make all these software components communicate accordingly. In this article, we share our experience of using cloud services to scale a web application. We show usage examples of load balancing, session sharing, e-mail delivery, asynchronous processing, logs processing, monitoring, continuous deployment, realtime user monitoring (RUM). These are a mixture of development and system operations (DevOps) that improved our application availability, scalability and performance.
Large open and closed source organizations like Google, Facebook and Mozilla are migrating their products towards rapid releases. While this allows faster time-to-market and user feedback, it also implies less time for testing and bug fixing. Since initial research results indeed show that rapid releases fix proportionally less reported bugs than traditional releases, this paper investigates the changes in software testing effort after moving to rapid releases. We analyze the results of 312,502 execution runs of the 1,547 mostly manual system level test cases of Mozilla Fire fox from 2006 to 2012 (5 major traditional and 9 major rapid releases), and triangulated our findings with a Mozilla QA engineer. In rapid releases, testing has a narrower scope that enables deeper investigation of the features and regressions with the highest risk, while traditional releases run the whole test suite. Furthermore, rapid releases make it more difficult to build a large testing community, forcing Mozilla to increase contractor resources in order to sustain testing for rapid releases.
The DevOps community advocates communication between the operations staff and the development staff as a means of ensuring that the developers understand the issues associated with operations. This paper argues that “communication” is too vague and that there are a variety of specific and well known sources that developers can examine to determine requirements to support the installation and operations of an application product. These sources include standards, process descriptions, studies about sources of failure in configuration and upgrade, and models that include both product and process.
Internet companies such as Facebook operate in a "perpetual development" mindset. This means that the website continues to undergo development with no predefined final objective, and that new developments are deployed so that users can enjoy them as soon as they're ready. To support this, Facebook uses both technical approaches such as peer review and extensive automated testing, and a culture of personal responsibility.
The task of managing large installations of computer systems presents a number of unique challenges related to heterogeneity, consistency, information flow and documentation. The emerging field of DevOps borrows practices from software engineering to tackle complexity. In this paper we provide an insight in how automation can to improve scalability and testability while simultaneously reducing the operators' work.
The essence of stability in software development is the ability to produce quality software with infrastructure that will meet long-term business goals. The essence of rapid and agile development is the ability to deliver capabilities quickly based on customer priorities. Stability often requires cross-functional analysis and infrastructure support that will build foundational technology for the capabilities to stand on, which takes time and resources. But today's organizations must attend to both agility and enduring design. This article presents three tactics that support rapid and agile stability: aligning feature-based development and system decomposition, creating an architectural runway, and using matrix teams.
Modern Enterprise Software Systems entail many challenges such as availability, scalability, complexity and providing business agility. Ensuring the systems to be up and running for 24 × 7 has become a mandate for operations. Agile development has been adopted to keep pace with the demands of business and IT. Test Driven Development (TDD) and Behavior Driven Development (BDD) are practices, which enable agile development. So far the agile approach has been limited to development. For ensuring business to be truly agile, we need to take forward the agile approach to operations. In this paper, we discuss the behavior driven approach for operations specifically on the core sub-systems like infrastructure provisioning, deployment and monitoring. We share our explorations and experiments with Behavior Driven Monitoring (BDM) and how the same can be adopted for infrastructure provisioning and deployment. We used Cucumber-Nagios to detect behavior of an enterprise application. We close this paper with a note on the benefits to business and IT showing its relevance to DevOps, Continuous Delivery and Cloud Computing.
An IT system's setup and configuration affects developers mainly due to the proliferation and complexity of Internet-facing systems. Fortunately, we can control and conquer this complexity by adopting IT-system configuration management tools. By stipulating that all modifications to a system's configuration can only be performed through its configuration management system and by treating the system's rules as code, an organization ensures that the IT systems it delivers to its clients are not inscrutable monoliths that just happen to work but documented modular engines that work by design.
Nowadays, many software companies are shifting from the traditional 18-month release cycle to shorter release cycles. For example, Google Chrome and Mozilla Firefox release new versions every 6 weeks. These shorter release cycles reduce the users' waiting time for a new release and offer better marketing opportunities to companies, but it is unclear if the quality of the software product improves as well, since shorter release cycles result in shorter testing periods. In this paper, we empirically study the development process of Mozilla Firefox in 2010 and 2011, a period during which the project transitioned to a shorter release cycle. We compare crash rates, median uptime, and the proportion of post-release bugs of the versions that had a shorter release cycle with those having a traditional release cycle, to assess the relation between release cycle length and the software quality observed by the end user. We found that (1) with shorter release cycles, users do not experience significantly more post-release bugs and (2) bugs are fixed faster, yet (3) users experience these bugs earlier during software execution (the program crashes earlier).
The metaphor of technical debt in software development was introduced two decades ago to explain to nontechnical stakeholders the need for what we call now "refactoring." As the term is being used to describe a wide range of phenomena, this paper proposes an organization of the technical debt landscape, and introduces the papers on technical debt contained in the issue.
This paper proposes a cloud application framework, which integrates both the development and production environment seamlessly. The framework consists of the client-side integrated development environment (IDE), and the server-side service portfolio and cloud controller. The IDE has requirement definition, architecture design and application prototyping tools, and it can simulate execution of large-scale applications in developers' PCs. The service portfolio incorporates data from these tools and enables automatic data sharing between them, thereby avoiding setback and redundancy. To accommodate the applications on the cloud, the cloud controller utilizes the resource structures designed in the IDE and generates virtual machines (VMs) from templates, in which a verified OS and middleware for large-scale data processing are packaged. The behavior of VMs and applications will be automatically monitored and catalogued as a guideline for the next project. With these comprehensive approaches, the system integration methods can be streamlined and the acceleration of development can be easily demonstrated.
A package management system organizes and simplifies the installation and maintenance of software by standardizing and organizing the production and consumption of software collections. As a software developer, you can benefit from package managers in two ways: through a rich and stable development environment and through friction-free reuse. Promisingly, the structure that package managers bring both to the tools we use in our development process and the libraries we reuse in our products ties nicely with the recent move emphasizing DevOps (development operations) as an integration between software development and IT operations.