key: cord-0058740-05fj3y9a
authors: Lohrasbinasab, Iraj; Acharya, Prameet Bhakta; Colomo-Palacios, Ricardo
title: BizDevOps: A Multivocal Literature Review
date: 2020-08-24
journal: Computational Science and Its Applications - ICCSA 2020
DOI: 10.1007/978-3-030-58817-5_50
sha: 976e567fd680a9c865f1605966fb1ccf0390af44
doc_id: 58740
cord_uid: 05fj3y9a

BizDevOps as an extension of DevOps, reinforces the collaboration between business, development, and operation stakeholders in the organization in order to enhance the software cycle. While BizDevOps has not yet received much attention in academic circles, it has gained considerable prestige in the industry area. This situation reflects a gap between theory and practice in this context. In this work and by means of a Multivocal Literature Review authors gather visions from both academic and industry spheres on the topic. The result is a gathered image of BizDevOps, including definition, characteristics, related motivating issues, and potential challenges and benefits.

assimilates any aspect or process aiming to lessening the time between changing a system and transferring that change to production, including practices like continuous monitoring or continuous deployment [9] . This is crucial for developers and quality assurance professionals, benefiting from real data on the development of new products and features [10] . The concept of DevOps surfaced in 2009 and describes a process where software developers and operations work close together in order to release software features often and learn from the end users based on their experiences [11] .

DevOps have also faced several evolutions. For instance, DevSecOps (known also as SecDevOps) is aimed to integrate security practices in the overall process [12] . Furthermore, another evolution is BizDevOps. Essentially, the idea behind BizDevOps is that, apart from Operations and Development, experts from the Business (Biz) world will join the team in order to develop user-centric products at a high pace. Although there are previous works in the field, including a Systematic Literature Review on the topic [13] , to the best of authors' knowledge, a multivocal literature review (MVLR) on this topic has not yet been conducted. In order to fill this gap, in this paper authors carry out a MVLR to investigate BizDevOps. Given the novelty of the subject, searching in the scientific literature for academic papers that deal with specific aspects of BizDe-vOps does not yield many results. In the face of this, it is observed that the phenomenon has spread significantly among the communities of consultants and software developers. This observation led the need for a MVLR. Motivated by the target contribution to diminish the conceptual gap between the professional practices and the academic publications on this topic, this research aims to clarify the BizDevOps definition and scope to provide more scientific knowledge to support the investigation of its related issues. Besides, concerning the subject's associations with co-domain topics, especially DevOps, it has been attempted to limit the scope of discussion to proprietary aspects of the subject as much as possible to avoid unnecessary rework and prolongation of this research.

The remaining of the paper is presented as follows: in Sect. 2, authors present the methods for research. In what follows, the authors present and discuss the results. Lastly, authors conclude and present suggestions for future work in Sect. 4.

To obtain an overview of the current literature, including grey literature, a MVLR was performed and is presented in this paper. A MVLR is a form of Systematic Literature Review that encompasses the so-called gray literature in addition to published academic literature (e.g., articles published in scientific journals, or presented in scientific conferences). Gray literature refers to all available means of information, including tool vendors' websites, industry reports, white papers, blogs, and so on. A documented advantage of MVLR is its capacity to converge viewpoints and knowledge between researchers and practitioners, as well as providing an overview of state-of-the-art and latest practices in a given field [14] . In order to conduct the literature review, authors will follow the guidelines proposed by Garousi et al. [14] . The stages of the literature review will be presented in the following sections. With regards to the need for this literature review, as mentioned in Sect. 1, to the best of our knowledge, a MVLR in the topic does not exist, although there is a Systematic Literature Review on the topic [13] . The underlying nature of MVLR justifies the need to conduct the study, given the amount of material published as grey literature.

The purpose of this research is to collect, review, and report on existing literature regarding BizDevOps. We aim to delineate definitions, features, as well as foreseeable benefits and challenges in BizDevOps application. In this regard, we pursue the survey, bearing in mind the aforementioned goals in the form of four research questions [15] . These questions are as follows:

• RQ 1: What is the reported meaning of the term "BizDevOps"? • RQ 2: What are the problems motivating the adoption of BizDevOps? • RQ 3: What are the main characteristics associated with BizDevOps? • RQ 4: What are the main potential benefits and challenges of adopting BizDevOps? • RQ 5: How has BizDevOps evolved since its emergence?

The study protocol describes the adopted systematic procedure, through which the surveyed literature in this research has been elicited from a mass of existing materials over the web.

Regarding procedures, authors performed a structured search out on Google and Google Scholar to find pertinent literature. The first step of the search process entails the identification of keywords. While compiling background information for this research, we found out that in some cases instead of the phrase "BizDevOps", or as an equivalent, the term "DevOps 2.0" is used. Consequently, in order to ensure that we do not miss the relevant items, we added the phrase "DevOps 2.0" to the search string. Thus, we chose the following string to acquire relevant materials:

("BizDevOps" OR "DevOps 2.0") AND ("motivations" OR "definition" OR "characteristics" OR "challenges" OR "benefits" OR "evolution")

Further, to access more relevant results, we relied on the snowballing technique to explore in some related domains such as DevOps and Agile.

Inclusion and Exclusion Criteria: After the search results were retrieved, a list of specified inclusion and exclusion criteria were applied to filter the most relevant studies. These criteria are as follows: This MVLR was performed by April 2020. Thereby, the search period was set from January 2014 -when the term "BizDev" was coined to April 2020. Moreover, considering that we are looking for those pieces of evidence containing the intended contents supporting RQs, the rest of the items that lack desired features, should be dropped. On the other hand, by Google's page ranking algorithm, we are facing a mass of results, of which only some first pages are connected to the subject. Thus, to restrict the search domain, we should cut off the search process at a specific point. Given the search criteria in this study, we decided to stop proceeding with more results once a page that did not bear relevant items was found [14] .

We designed an Excel form to collect bibliographic information of each selected literature, as well as recording additional notes on how well it relates to RQs. Furthermore, color codes were used to highlight the importance of each paper.

At the implementation stage, the structured search for gathering materials was performed by two researchers, via applying the aforementioned procedure. Essentially, the procedure consisted of the search process, followed by the analysis and sift of the preliminary results. Each process was carried out in parallel by both researchers. The primarily found items were stacked in an Excel form as a data pool. At the same time, authors controlled each other's collected results. Figure 1 depicts this procedure.

In this section, the results from the execution of the query will be presented and discussed to answer the research questions previously defined.

In Table 1 , the number of papers retrieved is displayed in each of the stages of the process. Stage 1 displays the number of studies that were retrieved by simply querying Google Scholar and Google Search. Stage 2 reflects the number of studies selected based on title, abstract, keywords and metadata, and stage 3 entails the number of selected studies after the full text has been read and analyzed.

: What is the Reported Meaning of the Term "BizDevOps"?

Terms like "culture", "movement", strategy", "method", "practice", "approach", "mindset", tools", and so on that come along with "BizDevOps" in the literature are often used with much tolerance. The most common definitions and descriptions provided in the grey literature on BizDevOps could be presented, in a high-level conceptual manner,, as follows: "BizDevOps incorporates business stakeholders into the Software Development Life Cycle (SDLC), creating a streamlined workflow from business strategy & planning to deployment and maintenance" [16] . In the purely research field, we find contributions as follows: BizDevOps, as an extension of DevOps in software development, is a combination of organizational strategies, approaches, and enabling technologies. It aims to strengthen cooperation and systematic interaction between business (Biz), development (Dev), and operations (Ops) [17] , with emphasis on the active intervention of business stakeholders in the software development process [18, 19] , providing continuous delivery Pipeline which establishes an end-to-end flow between customer demand and the fast delivery of a product or service [4] . The study conducted by Fitzgerald and Stol [4] is of utmost importance in terms of providing a comprehensive theoretical framework that explains the intellectual foundations of the subject and has been referenced broadly in later works. These authors introduce a general conceptual framework labeled as "Continuous *", divided into three main sub-phases: Business Strategy & Planning (Biz), Development (Dev), and Operations (Ops), that encompass various activities, with emphasis on being continuous, throughout the SDLC. Their proposed conceptual framework is derived from synthesizing Agile principles and Lean Philosophy and designed to establish a continuous flow of SDLC's activities that intends to realize the so-called continuous software engineering delivery pipeline.

To ensure maintaining business value along the DevOps loops, a tighten alignment between people, processes, and technologies is essential. Nevertheless, the arduousness of translation and expressing desires and goals of the business domain into software engineering domain has always been a challenging issue, coupled with the lack of active participation of the business management team in the software development process [17, 20, 21] and [22] in the gray literature. This issue has been discussed as the requisition of convergence between business strategy and software development [4] . Summarizing what has been cited in various sources as motivations for using BizDevOps, the focus is on the need to facilitate the active participation of the business stakeholders in the software development. By doing so, it amplifies the feedback process, as well as ensures the maximum fulfillment of business goals and customer expectations. As a result, providing higher customer satisfaction and higher quality software, leads to maintaining the organization competitive and innovative [20] .

BizDevOps characteristics could be classified into some general layers, including values, principles, practices (theoretical and technical approaches), and toolchains. It is noteworthy that, despite its novelty, BizDevOps is rooted in some long-established topics across the evolution of the software industry. In fact, most of its principles and approaches have been widely discussed, particularly in the grounding domains, such as Agile methods and DevOps. In this context, integrating the infrastructural components under an umbrella concept like "Continuous *" by [4] provided a methodological model that is distinguishable in most of the subsequent researches, too. For instance, Forbrig [23] has extended this framework by augmenting continuous requirements engineering, continuous business process modeling, and continuous human-centered design. In requirements engineering continuous compliance validation is a nascent need for a good set of current projects [24, 25] . Given the similarity and commonality of the principles, it should not be assumed that DevOps is trying to replace Agile. Rather, DevOps is trying to introduce areas where Agile can expand [26] .

The approach adopted by most authors in describing the BizDevOps characteristics is to follow the hierarchical classification pattern of concepts in the Agile Manifesto and to recreate these concepts, in accordance to BizDevOps's specific facts and features. However, in some gray literature sources, this alignment is not very precise, and the boundaries seem to be blurred in the interpretation and use of terms such as "value", "principle", or "approach". Therefore, authors followed the scheme that is analyzed in what follows: • Culture There is consensus on the fact that BizDevOps and its predecessor DevOps, are above all, about changes in the culture of the organization [27] [28] [29] . DevOps is mostly focused on innovation and productivity. It replaces the traditional managerial habits and beliefs with a culture of collaboration and an "IT value stream" by merging trusted principles and practices from physical manufacturing to software arena [26, 27] DevOps culture is strengthened by the practices it borrows from Agile and Lean principles, with a further concentration on service and quality [26] . That is, delivery of high-quality software to the end-user entails the cultural conversion in accepting joint responsibility [4] .

Despite the wide range of BizDevOps commonalities with DevOps, the two differ in terms of the influenced area and involved stakeholders. Unlike DevOps, which focuses on development and operation functions and stakeholders, BizDevOps reinforces responsibility over the whole customer journey in one unified team, consisting of business management, development, and operation people [30] thoroughly. From this view, transforming the traditional relationship of business and IT from the employerexecutive model to an interactive collaboration, with distributed responsibility, in the form of a unified team, is one of the significant cultural changes needed to become BizDevOps [31] . It is a critical prerequisite to enabling the company to execute end-toend holistic experiments, building new features that stretch across product lines and improve the entire customer experience [30] .

• Automation A BizDevOps method offers an integrated and automated toolchain to allow as much automation and, as a consequence of this, development speed (the "Ops" in BizDe-vOps) as possible [17, 18] . It is based on orchestrating and automating business activities, and information into the DevOps lifecycle [32] and strongly advocates workflow automation and monitoring at all phases of software construction, including integration, testing, and releasing to deployment and infrastructure management [22] .

• Measurement Monitoring and getting feedback from the entire ecosystem of the process, including business-side metrics and end-user experience, as well as development, test, and operations metrics [33, 34] is a fundamental part of Agile [27] , which ultimately maps to business outcomes. The risk across the value chain must be measured by a uniform mechanism [35] . Some of the key performance indicators (KPIs) [28, 35, 36] • Sharing Agile goals are achieved through the association between self-organizing and crossfunctional teams, concentrating on bringing the highest business value in the shortest time [37] . Further, sharing points to a common vision, language, and knowledge, as well as sharing resources [35, 38] .

(ii) PRINCIPLES The cross-functional autonomous teams, i.e. the unified BizDevOps teams are composed of people with a variety of skills [39] from the business team and/or application owner, development, and operation sectors team members to effectively tackle the variety in their external environments [39] . Their focus could be a product company deliveries, or a business process, business component, or business service [40] . They have a higher degree of safety regarding planning [20, 41] .

• End-To-End Responsibility: Unlike traditional organizations in which development responsibility ends up by handing over the product to operation team, in a DevOps environment teams are vertically organized such that they are fully accountable over the product's lifetime including performance support of products or services created and delivered by them [39] . • Value stream and process mapping: You have integrated business leaders, developers, and operations folks who all are working on a streamlined flow from your company's strategy to the deployment and ongoing operations of the product, service, or component. Organizations need to visualize as-is and to-be processes and how they feed higher-level value streams. These aspects are aimed to be used by business stakeholders without the need for training [32, 40] . • Identifying and monitoring the key performance metrics: requisition of key performance indicators, which include customer-centric metricse.g., user behavior and 'feature analytics', which in turn will enable gauging the value-add of specific features [4] , to DevOps metrics such as time-to-business-impact and speed of remediation. It is essential for establishing continuous innovation [39, 40] . • Automation toolchain: BizDevOps leverages a range of automation platforms socalled "Toolchain", that allow to collaborate and automate across the different process and data items [40] . The toolchain is a combination of the most effective infrastructures for developing, delivering, and maintaining software according to agile principles [42] . It is essential to choose and leverage a proper set of tools in maintaining a healthy software development pipeline [34]. • "Shift left" strategy: that is, the need to identify and address the technical debt that accrues, at the time issues are first encountered, in order to prevent potentially problematic issues [4] .

(iii) PRACTICES The practices listed here are based on the "Continuous *" conceptual framework provided by Fitzgerald and Stol [4] , appending the terms continuous requirements engineering, continuous business process modeling, and continuous human-centered design, proposed by Forbrig latter [23] .

• Business strategy and planning: It implies in the form of Continuous Planning & Continuous Budgeting, that planning and budgeting become continuous activities, instead of the traditional annual approach hindering the fast response to the emergent needs and flexibility against changes in software projects. • Improvement and Innovation: the activities mentioned within this category are not seen as a separate phase but implied as to the steady implicit endeavors across the software life cycle. These activities include Continuous Improvement (a concept rooted in Lean principles, that of data-driven decision making, and removing waste), Continuous Innovation (an endless process fed by monitoring metrics through SDLC, responding to the changing market conditions), and Continuous Experimentation (iterative cycles of Build-Measure-Learn, based on stakeholders experiments) [4] .

(iv) TOOLCHAIN Adopting a DevOps/BizDevOps model of software development in order to manage complex systems and scale workflows is strongly connected to effective tooling and choosing the proper technology. The toolchain in DevOps/BizDevOps is a categorization method that indicates what tools are used in which stages of the SDLC. The toolchain presented here is the most reported in the related grey literature [22, 34] .

• PLAN -A set of continuous activities, including system requirements definition, metrics development, determining the transposition of new and improved features as well as security and release planning. • CREATE -The tasks regarding code, namely, creation, release candidate, designing, building, test, and so on. • VERIFY -Activities related to quality assurance, such as verification, various types of tests. • PACKAGE -The required activities, before deploying new releases.

• RELEASE -The activities required for moving software into the product, including release and fallback/recovery. • CONFIGURE -Preparing and configuration of hardware and software.

• MONITOR -Activities aimed at monitoring the fitness of production environments, including measuring the performance, availability, and other non-functional metrics. Further, observing the end-user experience and feedback from these activities is factored back into Planning activities.

The four upfront stages that comprise the Biz Loop:

• ADAPT-It refers to the consolidation of the latest feedbacks from the customer, business, and market, in order to define business initiatives, road map, and upfront plans [34]. • DEFINE-In this step, through a visual, well-understood solution model, visions of various stakeholders are defined. The solution is then parsed into functional components that determine the different activities over the toolchain. In defining a solution supporting the business needs, concerns from a variety of stakeholders are addressed. • ALIGN -In this step, stakeholders across the organization can align by means of a shared model of what must be delivered, through visual models and automated workflows. • APPROVE -At this step, stakeholders agree that the solution designed supports their business needs.

3.5 RQ4: What are the main potential benefits and challenges of adopting 'BizDevOps'?

With regards to the challenges, some of the challenges are derived from the ones in the implementation of continuous practices, as indicated by [4] . In the organizational sphere, literature reports the following challenges: Prerequisite investments: in order to adopt BizDevOps, companies need to invest heavily in upgrading the required hardware and software infrastructure, as well as providing well-trained human resources. This issue is an essential inhibitory factor which can deter many organizations from using BizDevOps [16] .

People's Behavioral Change: People's style of working is changing. This change introduces difficulties for the habits and culture of a large development organization that is deeply engrained [31] . Without a clear focus on the goal [43] along with motivation issues, it is an obvious reason for making such a change [31] .

Lack of Skilled Product Owners in the Business Side: Transferring the traditional business-IT relationship, from the bureaucratic and inflexible employer-contractor framework, to a context of plenary interaction between these sectors and participation of business stakeholders in the SD process, is one of the cultural challenges ahead for moving to BizDevOps. Further, for such a change, business stakeholders in crossfunctional teams, and business managers, are needed to be trained and familiar with technologies used in BizDevOps [31] . Due to the skill gap, selecting skilled employees is a challenging task [44] . Besides, for starting BizDevOps, the organization needs to improve its management process and application architecture [45] . Management Process: Teams need to be unified and collaborate with each other [37] . Collaboration sharing equal productivity, focusing on human touch is the major issue [46] . Due to the misunderstanding between the employees, what output needs to get at last was not clear [43] . Observation needs to be done on how the work is carried on [47] . Using the traditional approach for managing service will experience continued incident handling [48] . Thereby, it is essential to enabling communication between biz and DevOps [49] . However, it has been reported that it is hard for the business side to understand the programming code written by developers [50] . Due to this, biz are not able to adapt quickly into the application [51] . Difficulty in understanding what work is going on and what has been sent in the sprint has been noted [33] . Therefore, the business side needs to be integrated from the starting phase of the development process. Describing the new development process of application, which is fast enough for the customer side, was the main issue [44] .

Inadequately addressing the business implications prevent DevOps from being the strategic IT capability business line [52] . To deliver enterprise-wide services, costeffective shared services were necessary to be interfaced with team members [53] . In agile environments, the chance of releasing features every day is an unquestionable attractive. In contrast, it is needed for almost all business functions counting on with functionalities in a synchronized way as their processes change over time [54] .

In reviewing the literature, what has excessively emphasized and repeated, as the benefit of BizDevOps, is the ability of this method to improve the various aspects of product or service and its capability to accelerate the value creation process, by removing the barriers between business, development, and operation teams. Authors in [17] impute three main achievements to BizDevOps approach:

• BizDevOps approach facilitates the exploration and review of requirements in a firsthand fashion. Hence, it catalyzes feedback cycling and reduces the need for knowledge-exchange between IT and Business (the "Biz" in BizDevOps). • BizDevOps enables IT departments to have more control over the application development process, promising to guarantee the high quality of the software artifact (the "Dev" in BizDevOps). • BizDevOps approach affords an assimilation of the automated and integrated toolchain to allow as much automation as possible and, consequently, accelerate development (the "Ops" in BizDevOps).

The increasing number of studies from 2015 indicates the growing rate of attraction to the subject. The number of studies per year are as follows: 

In this research, authors attempted to provide a comprehensive and accurate portrait of the BizDevOps phenomenon. The research questions focus on recognizing the different dimensions of BizDevOps including definition, characteristics, motivating issues, potential challenges and benefits, and its evolution trend. We used Google Search and Google Scholar databases to find subject materials in both gray and scientific literature.

Summarizing and analyzing the results shows that:

RQ1: there seem to be some disagreements over the exact definition, naming, and describing the term BizDevOps. However, it is a matter of consensus that BizDe-vOps is an extended model of DevOps and goes along with developing and generalizing it, in the scope of Agile software development. The transition flow of philosophy, principles, and methodologies used, from Agile methods to DevOps, and now to BizDevOps, indicates hierarchical originality and continuity, something like Russian Matryoshka dolls. RQ2: the motivation for adopting BizDevOps could be expressed as follows: integration between the three sectors of business, development, and operations so that it establishes the active participation of business stakeholders in the software development process. It improves the continuous and efficient flow of product/service, agility, quality, flexibility, which ultimately leads to the promotion of the organization's competitiveness. RQ3: BizDevOps characteristics have been presented in terms of values, principles, practices, and toolchain. RQ4: Some of the potential BizDevOps challenges and benefits are expressed in different aspects. RQ5: The data collected in this study shows the rapid growth of this phenomenon in the industry. However, in the academic sphere, this paradigm has not received the attention it deserves.

Given the current high focus on the technological aspects of the subject, and considering that BizDevOps involves the mutual relationship between IT and business, affixing the business insight can help complete the picture in this discussion.

A replicated survey of IT software project failures

Perceived causes of software project failures -an analysis of their relationships

Agile transition and adoption frameworks, issues and factors: a systematic mapping

Continuous software engineering: a roadmap and agenda

Continuous software engineering-a microservices architecture perspective

A case analysis of enabling continuous software deployment through knowledge management

Emerging themes in agile software development: Introduction to the special section on continuous value delivery

Microservices architecture enables DevOps: migration to a cloud-native architecture

Adopting DevOps practices in quality assurance

Adoption issues in DevOps from the perspective of continuous delivery pipeline

DevSecOps: a multivocal literature review

BizDevOps: A Systematic Literature Review

Guidelines for including grey literature and conducting multivocal literature reviews in software engineering

Characterizing DevOps by hearing multiple voices

A Quick Guide to BizDevOps for Developers

BizDevOps: because DevOps is not the end of the story

BizDevOps and the role of S-BPM

Use cases, user stories and BizDevOps

Implementing the planning process within DevOps teams to achieve continuous innovation

BizDevOps: A process model for the Alignment of DevOps with Business Goals

Blueprint: Agile and DevOps (and BizDevOps

Continuous software engineering with special emphasis on continuous businessprocess modeling and human-centered design

Applying modeldriven paradigm for the improvement of web requirement validation

A systematic literature review on compliance requirements management of business processes

Smartsheet: Support Your DevOps Practice with Tools for Success

What is DevOps? A Complete History: Waterfall to DevOps 2

Delivering Value with BizDevOps

Do we need a DevOps 2.0? Yes, if you want to get back to "startup

The Complete Guide to Scaling Agile Software Development

How to integrate business priorities into the DevOps process. https:// appdevelopermagazine.com/how-to-integrate-business-priorities-into-the-devops-process

Smartsheet: The Way of DevOps: A Primer on DevOps Principles and Practices

Connecting the Business, Development, and Operational dots in an enterprise

15 Metrics for DevOps Success

How ING moves to real enterprise agility

Bringing Certainty and Speed to Decision Making with BizDevOps. http:// sites.tcs.com/campaigns/framework-for-bringing-certainty-and-speedy-decision-makingretail

DASA: DASA DevOps Principles

What is BizDevOps?

Bimodal enterprise architecture management: the emergence of a new EAM function for a BizDevOps-based fast IT

What is a DevOps Toolchain

Working together: BizDevOps for competitive advantage

Mendix: Redefining app development with a low-code approach | Cloud Computing | Gigabit Magazine

DevOps 2.0 is here, and it's time to put end-to-end continuous delivery pipelines behind every project

BizDevOps Breaks Down Silos, Improves User Experience

@Papa-fire: BizDevOps: business-first approach to DevOps

Modern Service Management For Azure

What Does DevOps 2.0 Look Like? -DZone DevOps

Why DevOps must become BizDevOps for business and IT collaboration

BizDevOps: Gaining a competitive advantage in an app-centric world

Why ignoring market responsiveness paves the way for Enterprise DevOps 2

How CVP Puts the Biz in DevOps

BizDevOps. Next level in your Enterprise Agile Maturity