An empirical study of architecting for continuous delivery and deployment

Abstract

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 indepth, 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.

The Role of Agile Software Architect in the Age of Digital Disruption and Transformation

“…Architectural vision and decomposition strategy: The architect delivers architecture as a service (Blair et al, 2010;Faber, 2010); defines the architectural vision and gives good examples (Buschmann, 2012; Martensson et al, 2019); provides a coherent and sustainable product architecture (Erder & Pureur, 2016); understands the system, its parts, and how they communicate (Bass, 2017); drives decomposing strategies (Shahin et al, 2019); designs loosely coupled architectures (Shahin et al, 2019); plans for integration in steps (Martensson et al, 2019).…”

“…Fast delivery before reuse: The architect designs systems for rapid delivery in different environments (Erder & Pureur, 2016); avoids overthinking about reusability, but understand that a lack of explicit control on reuse makes CD harder (Shahin et al, 2019); uses a balanced approach where system design and architecture effort is focused on the system's most important characteristics (Martensson et al, 2019).…”

“…The architect for the decisions the team makes is consistent throughout the system (Madison, 2010;Buschmann, 2012); influences design decisions that affect the whole system (Buschmann, 2012); protects the conceptual integrity of product architecture and design (Buschmann, 2012;Poort, 2014;Erder & Pureur, 2016); manages technical debt (Zimmermann, 2016); reduces risk to a level that's satisfactory to the team and stakeholders (Waterman, 2018b); balances between risk and agility (Waterman, 2018b); designs for failure in which, instead of preventing failures (reliability), learn how to deal with failures (resilience) (Shahin et al, 2019).…”

Untitled

“…Horizontal and vertical organization structuring: The architect deals with the organization structure (Nord et al, 2014;Shahin et al, 2019); connects parts of the organization horizontally and vertically (Hohpe et al, 2016); builds bridges between and across different levels of organization (Hohpe et al, 2016); considering highly skilled teams (Shahin et al, 2019); architects in the organization must work better together, e.g. working as an "expert council" (Martensson et al, 2019).…”

“…Organizing and coordinating teams: The Architect provides communication and avoids the "ivory-tower" trap (Blair et al, 2010;Faber, 2010;Erder & Pureur, 2016;Holmes & Nicolaescu, 2017); can be a team member as the first among equals (Blair et al, 2010;Britto et al, 2016); aligns multi-team coordination requirements and opportunities (Nord et al, 2014); builds bridges between teams (Hohpe et al, 2016); influences team morale (Bass, 2017); considers highly skilled teams (Shahin et al, 2019); supports the team members conventionally more business-oriented (Bass, 2019).…”