1 Introduction

Software (SW) development currently requires agility and speed to respond to the highly changing demands of organizations. Meeting these demands additionally requires collaboration, integration and alignment between development and operations (Al-Zahrani & Fakieh, 2020; Ebert et al., 2016; Gokarna & Singh, 2021; Hart & Burke, 2020; Wiedemann et al., 2020). This new approach is denominated as DevOps (Development and Operations) (Kromhout, 2009). DevOps is a set of practices that seeks to align the world of software development with operations, thus streamlining software production and facilitating organizations’ digital transformation(Al-Zahrani & Fakieh, 2020; Hart & Burke, 2020; Wiedemann et al., 2020).

This tendency to integrate the work of the different areas of an organization involved in software development has also produced the term BizDev (Business and Development). BizDev represents the alignment of software development with business strategy and planning (Fitzgerald & Stol, 2014). The concept of BizDevOps (Business, Development and Operations) later emerged. According to (Gruhn & Schäfer, 2015), this “reinforces the collaboration between business, development, and operation stakeholders in the organization in order to enhance the software lifecycle” (Lohrasbinasab et al., 2020). One characteristic of BizDevOps is that of proposing that the stakeholders in the business areas play an active role in SW creation efforts and the fact that this approach seeks to quickly reflect changes in requirements in the SW products, with the objective of improving Time-to-Market (Gruhn & Schäfer, 2015). Reinforcing the involvement of the business areas provides faster and better aligned responses to organizations’ changing needs, but the implementation of BizDevOps in an organization must take into account IT services and infrastructures, along with tasks, processes and roles (Sanjurjo et al., 2020a). Furthermore, some of the BizDevOps objectives shown (IT/Business alignment and Time-to-Market) in the study by Kappelman et al., (2019) are presented as the 10 most important things in IT management for IT Leaders. This leads us to believe that this approach could be in sync with the goals of IT governance and management.

The ISO/IEC 38500 (ISO/IEC, 2015) defines ‘IT Governance’ as a “system by which the current and future use of IT is directed and controlled”, and “IT Management” as the “exercise of control and supervision within the authority and accountability established by governance”. These terms differ in an operational sense, in that governance has the function of ‘guiding’ activities in the IT context, and management has the function of ‘executing’ those activities (Holt, 2013). It is now evident that if the organization does not implement adequate IT governance and management, this could have negative effects on the achievement of the set organizational objectives (Holt, 2013), which could be reflected in increased costs, decreased performance, and specifically, software quality problems.

One tool that supports IT governance and management functions is Enterprise Architecture (EA) (Lankhorst, 2017). There is also EA description, which is the representation of the enterprise from an integrated business and IT perspective with the intention of reducing the communication gap between business and IT stakeholders (Kotusev, 2017). EA is considered one of the 10 issues in which organizations should invest, and its purpose of enabling Business/IT alignment is, according to a survey of 276 organizations in Europe, considered the most important IT Management issue (Kappelman et al., 2019).Given all of the above, it is envisaged that the integration and Business-IT alignment of Enterprise Architectures and the ‘guiding activities’ of IT Governance could favor the correct functioning of a BizDevOps environment. Motivated by the above, this paper presents the development of a Systematic Mapping Study (SMS) (Petersen et al., 2008) carried out to identify proposals related to the use of EA in BizDevOps governance and management. We specifically wish to answer the following research question: Are there proposals that integrate enterprise architectures and IT governance in order to support the BizDevOps approach?

The results obtained show that there are still few studies that address the subject of interest. However, in recent years there has been a steady increase in the number of these studies. Furthermore, given the relevance of being able to align IT with business and the need to have SW development approaches that will enable this, we believe that this could indicate a possible research gap.

The remaining parts of the paper are organized as follows. The second section is conceptual in context, and presents the main concepts related to this study. Section 3 describes the research methodology used and its stages, while Sect. 4 presents the analysis by research question and a discussion of the findings. Section 5 presents related works found in literature and shows how they differ from and relate to this study. The conclusions of this work are presented in the final section.

2 Conceptual Context

This section presents the main concepts included in the scope of this study. This issue is relevant because one of the problems detected is the non-standardized use of certain concepts.

2.1 BizDevOps

In Jabbari et al., (2016), an SMS is carried out with the objective of establishing a clear definition of DevOps. Furthermore, the new standard for DevOps, IEEE 2675–2021 (IEEE, 2021), has allowed us to use a consensus definition of this concept. This definition to a great extent brings together what is currently specified in literature. The standard specifies that: “DevOps is a set of principles and practices which enable better communication and collaboration between relevant stakeholders for the purpose of specifying, developing, and operating software and systems products and services, and continuous improvements in all aspects of the life cycle”.

The term BizDev is similar to DevOps as regards the conjunction between business and development. One important aspect of this term is that it is not only used in Informatics/Computing. This is because, even before the emergence of DevOps (Kromhout, 2009), the term was already being used in the context of Business Management (Keywell & Godin, 2001). In this area of knowledge, BizDev “involves the exchange of items inside or outside the company to improve its business (e.g. intellectual property, technologies, know-how, etc.)” (Pepin, 2006). In Informatics/Computing, BizDev “represents the need for tighter integration between business strategy and software development, a complement to the DevOps concept” (Fitzgerald & Stol, 2014). This duality in the meaning of the concept has already been evidenced in other works, such as (Forbrig, 2018b).

The concept of BizDevOps emerged later (Gruhn & Schäfer, 2015). Like its predecessors, the term is presented as a combination of Business, Development and Operations. In Gruhn & Schäfer, (2015), BizDevOps is defined from three perspectives, each associated with one of the areas to which the concept is linked. This definition, which is used in our study, indicates that:

  • A BizDevOps approach allows people in the business departments to express and review requirements in a hands-on manner and thus reduces the necessary knowledge transfer from business to IT and provides fastest possible feedback cycles (the “Biz” in BizDevOps).

  • A BizDevOps approach allows IT departments to govern the whole application development process to ensure high quality of the software artifacts (the “Dev” in BizDevOps).

  • A BizDevOps approach provides an integrated and automated tool chain integration to allow as much automation and thus development pace (the “Ops” in BizDevOps).

2.2 IT Governance & Management

In the COBIT reference framework (Information Systems Audit and Control Association, 2019b), IT Governance (ITG) and Management are described as follows: Governance establishes the direction by means of IT needs, conditions, alignment and objectives. It also oversees the definition and implementation of the agreed direction and objectives (Information Systems Audit and Control Association, 2019a), while the function of Management is to plan, build, execute and monitor activities in alignment with the direction established by the governing body in order to achieve the company's objectives (Information Systems Audit and Control Association, 2019a).

According to the ISO 38500 (ISO/IEC, 2015), good ITG can positively affect organizational performance by: innovation in services, markets and business; the alignment of IT with business needs; the appropriate implementation and operation of IT assets; clarity of responsibility and accountability for both the supply of and demand for IT as regards achieving the organization’s goals, among others.

2.3 Enterprise Architecture

Enterprise Architecture is a coherent whole of principles, methods, and models that are used in the design and realization of an enterprise’s organizational structure, business processes, information systems and infrastructure. The set of elements that make up an EA description makes it possible to attain a holistic view of the organization, which is one of its main characteristics (Lankhorst, 2017).

One of the main de-facto standards employed for the EA practice is TOGAF (The Open Group Architecture Framework) (Kornyshova & Barrios, 2021; Simon et al., 2013; The Open Group, 2022b). TOGAF states that the purpose of EA “is to optimize across the enterprise the often-fragmented legacy of processes (both manual and automated) into an integrated environment that is responsive to change and supportive of the delivery of the business strategy”. Some of its main benefits are the following (The Open Group, 2022b): more effective and efficient business operations; more effective and efficient Digital Transformation and IT operations; better return on existing investment, reduced risk for future investment, and, faster, simpler and cheaper procurement.

EA allows us to protect the core of the organization while simultaneously having great flexibility and adaptability (Lankhorst, 2017). A good EA practice could help to achieve success in the organization (Lankhorst, 2017). The useful aspects of EA for software developers and researchers have been summarized in (Pérez-Castillo et al., 2019). For example, it can be used as a tool to monitor technical resources and thus avoid redundancies; it can also be used to control and share knowledge in a modular manner.

One of the main notations for Enterprise Architecture modeling is ArchiMate (Rouhani et al., 2015). This notation uses the Architecture Viewpoint concept defined by (ISO/IEC/IEEE, 2011), with the objective of modeling each stakeholder’s specific concerns and providing a set of viewpoints that make it possible to visualize the different elements that are important for each kind of stakeholder in the organization. The ArchiMate notation, which is now in its current version (3.2) (The Open Group, 2022a), is service-oriented and has 6 layers for modeling (see Fig. 1): (i) the Strategy Layer, which allows the modeling of the enterprise at the strategic level, and in particular, the organization’s capability, resources and courses of action; (ii) the Business Layer, which provides the organization’s external users with services and products and is additionally where the Business Processes interact with the stakeholders; (iii) the Application Layer, which supports the Business layer by means of the services that are offered by the information systems (software applications and data); (iv) the Technology Layer, which delivers the IT infrastructure services, thus allowing the application layer to be realized and providing communication between the Software and Hardware elements, (v) the Physical layer, which is an extension of the technology layer and includes elements with which to model the non IT physical world, and (vi) the Implementation and Migration Layer, which supports the modeling of the architecture change process in the organization(Aldea et al., 2015; Lankhorst, 2017; The Open Group, 2022a).

Fig. 1
figure 1

Full ArchiMate 3.2 framework (Pérez‐Castillo et al., 2021); adapted from (The Open Group, 2022a)

Full size image

3 Review Methodology

This study was carried out by employing the Systematic Mapping Study (SMS) method, whose objective is to deliver a comprehensive overview of a given topic of interest. It allows the existing types of research and their respective results related to the topic at hand to be identified and categorized (Kitchenham et al., 2011; Petersen et al., 2008, 2015).

This literature review method has the characteristic of being quantitative in nature. It is, therefore, common to calculate the frequency of publications over time in order to detect trends or to classify the articles found according to a predefined classification scheme (Petersen et al., 2008).

In contrast to Systematic Literature Reviews (SLRs), which have the objective of identifying, evaluating and interpreting all available research pertinent to a particular research question, subject area, or interest phenomenon (Kitchenham & Charters, 2007), a SMS has the main goal of identifying and classifying all research associated with a distinct, broad topic (Kitchenham et al., 2011).

There are also Multivocal Literature Reviews (MLR), which differ from Systematic Mapping Studies (SMS) and are similar to SLRs, but also include 'grey literature.' Grey literature covers work from all sectors, such as government, academia, and industry. Unlike traditional literature, it is not controlled by commercial publishers. By including grey literature, Multivocal Literature Reviews can provide a broader and greater understanding of a research topic, drawing from a variety of sources and perspectives (Garousi et al., 2019).

It should be noted that in this study, in addition to the quantitative information, a small synthesis is provided of those papers selected for each of the research questions, but the studies are not examined in depth owing to the type of methodology selected.

In order to carry out an SMS, three main stages must be considered, which are defined as (1) planning, (2) conducting and (3) result reporting the mapping (Petersen et al., 2015).

3.1 Planning Stage

The planning stage was carried out by keeping in mind the systematic mapping process presented by (Petersen et al., 2008, 2015). The following steps from the aforementioned stage are used in this study:

  1. 1.

    Research Questions: to establish the research questions that the study intends to answer.

  2. 2.

    Search strategy: definition of search sources, terms, structure, and search combinations.

  3. 3.

    Screening of papers: definition of inclusion and exclusion criteria to filter the papers.

  4. 4.

    Selection Procedure: definition of a procedure with which to filter and select the papers found.

  5. 5.

    Information Extraction Strategy: definition of what information will be extracted from the documents selected and how it will be recorded, in addition to which studies will be categorized for further analysis.

The following subsections describe the design and planning of this SMS and provide a description of how each of the steps that make up this stage were carried out.

3.1.1 Research Questions

The main research question guiding the development of this SMS is:

  • RQ1. Are there proposals that integrate enterprise architectures and IT governance in order to support the BizDevOps approach?

The objective of this question was to identify whether EAs have been used in the BizDevOps approach to date, and whether any ITG practices have been used to support this approach.

The additional questions described below are complementary to the main RQ, and their purpose was to expand our research focus.

  • RQ2. What types of EA models are associated with the business and are used in the context of BizDevOps?

  • RQ3. What methods, techniques or tools are used in BizDevOps, and which of them are based on EA?

  • RQ4. What are the elements in a BizDevOps context that can and should be modeled with EA?

These additional questions aim to identify the types of proposals and focuses of interest in the study area of this paper and how enterprise architectures have been addressed in the context of BizDevOps.

3.1.2 Search Strategy

The scientific research sources used in the development of this SMS were: ScopusFootnote 1and Web of Science (WoS).Footnote 2

These scientific search sources were used because they index articles from the most relevant journals and conferences in the different branches of science. In addition, before making this decision, experimental searches were carried out in various scientific sources to determine whether the search was biased, and these results confirmed that the sources selected were appropriate and yielded the highest number of results. This eliminated bias from the selection of sources.

Furthermore, it is important to mention that all grey literature (e.g., blog posts, videos, and white papers) was discarded from our search process. This was because the preliminary searches of this type of literature did not yield any contributions that could be useful for this study.

The search expression employed had the following structure:

  •  < Topics > AND < Utility Terms > 

The term < Topics > is used to indicate the main theme of the document, while < Utility Terms > serves to filter the application context in which the terms are presented in the search results. It is important to mention that utility terms were defined in a general manner in order to broaden the search and include all documents that might be relevant and interesting for the study.

With regard to the topics, 'devops' and 'bizdev' are included because they are directly related to BizDevOps and can sometimes be confused with each other. One example of this is that, a search for BizDevOps in a search engine (such as Google or Bing), may also produce references to this approach as DevOps 2.0.

Moreover, the unfamiliarity with the term BizDevOps, its recent emergence, or the popularity of the term DevOps, may have led valuable proposals for BizDevOps to be associated with DevOps and/or BizDev rather than BizDevOps.

The list of terms in each part of the search was, therefore:

  •  < Topics > : devops, bizdevops, or bizdev.

  •  < Utility terms > : management, governance, business, enterprise, or company.

And the resulting search expression was:

  • (devops OR bizdevops OR bizdev) AND (management OR governance OR business OR enterprise OR company)

In order to allow the replication of the searches performed in this literature review, a web siteFootnote 3 with detailed information on the search query used in each research source has been made available to those who require it. In addition, this site provides complementary information on this study and a full experimental material kit.

3.1.3 Screening of Papers

The search filters used in the scientific search sources selected to develop this SMS were inclusion and exclusion criteria. The inclusion and exclusion criteria used were the following:

  • Inclusion Criteria: All journal articles and scientific communications from conferences that meet the following restrictions were included: those that address the search terms and combinations, those that address the topic covered in the research questions.

  • Exclusion Criteria: Articles with the following criteria were excluded: papers created before 2009(since DevOps is consider to have emerged in that year), and those that were not written in English.

3.1.4 Selection Procedure

The paper-selection procedure comprised two steps. The first step considered the level of relevance as regards the main topics of this research, while the second considered whether the focus covered by the paper was the same as that of this research.

The first step, i.e., considering the results obtained after screening the papers and defining the level of relevance of the works found, was carried out by analyzing the title, abstract and keywords of each paper. Three levels of relevance were established, which are defined as follows:

  • Low: Although the paper fits the scope of the research and the search terms, it makes no relevant contributions to our study.

  • Medium: It contains relevant and interesting information, which could be useful for the development of the study.

  • High: The information described in the paper is directly related to the study.

The papers with medium and high levels of relevance were selected as a result of this step.

In the second step, all the papers selected in the first step were read in their entirety, and those related to specific topics were subsequently selected (see Table 1). This was done with the objective of filtering out the papers selected in the previous step, thereby focusing those papers that dealt with the topics of interest.

Table 1 Focus topics
Full size table

3.1.5 Information Extraction Strategy

For each document analyzed, relevant information was extracted in order to facilitate its synthesis and contribution to answering the research questions.

In addition to the information extraction process, a categorization procedure was also developed in this step with the objective of facilitating the quantitative analysis to be carried out. This procedure considered two types of categories (Research Type Facet and Contribution Type Facet), which are described as follows.

Research Type Facet: In Wieringa et al., (2006), categories are specified in order to facilitate the analysis of the documents obtained in a literature review. These categories are easy to interpret and use for classification without having to evaluate each paper in detail (as occurs in a systematic review). The details of this categorization are provided in Table 2.

Table 2 Research type facet (Wieringa et al., 2006)
Full size table

Contribution Type Facet

It is common to take understood concepts such as architecture, method, tool, framework, among others, signifying those ambiguities may arise when conducting similar studies and replications of this study. It is for this reason that a brief definition of the Contribution Type Facet identified and used in this study is presented (see Table 3). It is worth noting that most of the definitions are drawn from the ISO/IEC/IEEE 42010 (ISO/IEC/IEEE, 2011), ISO/IEEE 24765 (ISO, 2017) standards and the work of Ouhbi et al., (2015).

Table 3 Contribution type facet
Full size table

The rationale behind the use of the aforementioned types of categories is the perspectives they offer when analyzing the selected works. These make it possible to establish more easily how the works help answer each of the research questions established.

Each paper was consequently categorized according to its ‘Research Type Facet’ (see Table 2) and one or more ‘Contribution Type Facet’ (see Table 3). Table 4 provides a description of the information extracted from each paper analyzed.

Table 4 Items of information extraction from the papers
Full size table

3.2 Conducting Stage

The first searches were carried out between December 2020 and February 2021, with the objective of adjusting the protocol presented above. The searches were replicated between January 2022 and February 2022, and the results obtained are detailed in this subsection. The classification and selection procedures were performed by one author, but each stage and its results were reviewed and validated by all the authors of this study. Figure 2 shows the process developed in this SMS.

Fig. 2
figure 2

Summary of the search protocol

Full size image

First, a total of 1287 raw results were obtained from two sources. The duplicates were then removed: first the duplicates in the same source, and then duplicates between the two sources. This resulted in a total of 802 potentially useful papers.

After applying the selection by relevance level (First Stage Selection), the number of useful papers, i.e., with high or medium levels of relevance, was reduced to 278. Upon applying the selection by topics of interest (Second Stage Selection) 97 results remained: 86 primary studies and 11 secondary studies. The latter were distributed as follows: SLR, SMS and MLR.

Of the 86 articles selected, 42 papers were found only in SCOPUS, 4 papers were found only in Web of Science, while the remaining 40 papers were found in both sources (see Fig. 3).

Fig. 3
figure 3

Numbers of paper by source

Full size image

3.3 Report Results Stage

Hereafter, all results and statistics refer to the set of 86 relevant papers found.

The categorization of papers according to type of research (Research Type Facet, see Table 2) led to the attainment of the results shown in the table below (Table 5). It should be noted that 56.98% of the papers correspond to ‘Solution Proposal’, followed by the category of ‘Opinion Papers’ with 26.74%. It is noteworthy that there are no papers in the categories ‘Validation Research’ and ‘Experience Papers’. The reason for this is that we identified papers on the topics of BizDevOps, DevOps, or BizDev that were associated (directly or indirectly) with enterprise architectures or IT governance and management in these categories. However, it is important to note that despite detecting this type of work, it was linked to more technical aspects of software development, which did not meet the inclusion criteria of this study.

Table 5 Papers by research type facet
Full size table

The distribution of the 86 relevant papers is shown graphically in Fig. 4, scattered by main topic (vertical axis), contribution type facet (horizontal axis, left side) (see Table 3) and research type facet (horizontal axis, right side) (see Table 2). As can be seen, the highest concentration of papers is in the DevOps topic and in Solution proposal, as a type of research. It is worth noting that the total number of documents in the ‘Contribution Type Facet’ amounts to 88, as two papers each describe two contributions. This is the case of Rong et al., (2020), who propose a contribution in the forms of an ‘Approach’ and ‘Tools’, and that of Austel et al., (2015), who propose an ‘Architecture’ and a ‘Method’ as contributions.

Fig. 4
figure 4

The 86 relevant papers by topic and contribution type facet (left-hand side, 88 contribution facet) and topic and research type facet (right-hand side, 86 research facet)

Full size image

In Fig. 4, the topics of BizDevOps and BizDev are grouped together in order to classify the results. This is because both topics focus on the business cycle (Fitzgerald & Stol, 2017; Forbrig, 2018a), and differ only in the sense that BizDevOps incorporates the operations cycle of DevOps.

The presence of empty points on the left-hand side of Fig. 4, within the ‘BizDevOps OR BizDev’ topics, was expected. This can largely be attributed to the nascent nature of these topics and the comparably limited use of these terms as opposed to the more common term ‘DevOps’. It additionally highlights research gaps for which no contributions were identified.

Upon considering the left-hand side of Fig. 4, where the ‘Contribution type facet’ is grouped (see Table 3), it will be noted that the larger bubbles are associated with the ‘Recommendation’ type in both topic groupings. We believe that this is a natural outcome of research, as it often leads to the generation of recommendations, opinions, or lessons learned, which provide valuable contributions for other researchers. An example of this is the work of Forbrig, (2018b), which suggests that user stories can be an effective tool for communication among business, development, and operations stakeholders.

Furthermore, upon considering the right-hand side of Fig. 4, where the ‘Research type facet’ (see Table 2) is grouped, it will be noted that the larger bubbles in both topics are concentrated under the ‘Solution Proposal’ type. We believe that this concentration of work is to be expected, as the objective of the majority of research efforts is to provide proposals that address identified problems.

Table 6 shows the distribution of papers by contribution type facet. Those papers with a research type facet other than ‘Solution Proposal’ were grouped into the contribution type facet 'Recommendations'. The contributions with the most papers are recommendations (42.2%), framework (15.7%) and model (13.3%).

Table 6 Distribution of papers by contribution type facet
Full size table

Figure 5 also shows that the highest number of papers with contributions is concentrated in the period 2018–2021, which would appear to confirm a growing interest in this topic.

Fig. 5
figure 5

Numbers of papers by year and contribution type facet

Full size image

Figure 6 presents the distribution of works by "Focus Topic", as shown in Table 1. This figure clearly shows a predominance of the topic "Agile Methodology", which is to be expected, as our search was focused on software development approaches.

Fig. 6
figure 6

Numbers of papers by Focused Topic (see Table 1)

Full size image

As already described in Fig. 2 (summary of the search and selection process), the final set of papers yielded 11 formal literature reviews. Of these reviews: 7 are SLRs, 2are SMS and 2 are MLRs. Moreover, 9 of them were published between 2018 and 2019 (see Fig. 7). These studies will be discussed in Related Work section.

Fig. 7
figure 7

Number of literature reviews distributed by year and type

Full size image

4 Analysis and Discussion

This section provides a synthesis of the main results and findings of this study. It is important to note that none of the proposals found in this work directly answer the research questions set out. However, these proposals allow us to address possible answers to the research questions and contribute to this unexplored area.

4.1 Analysis Per Research Question

This section analyses the results of this study, which found eighteen proposals related to RQ1, five proposals related to RQ2, twenty-one proposals related to RQ3, and nine proposals related to RQ4.

4.1.1 RQ1. Are there Proposals that Integrate Enterprise Architectures and IT Governance in Order to Support the BizDevOps Approach?

Strictly speaking, no papers integrate enterprise architecture and IT governance in a BizDevOps context. However, some papers are partially related to what we seek to answer. In particular, three of them describe the use of EA in the context of DevOps, and these are applicable to BizDevOps and/or could be used as a foundation to extend them by incorporating a business cycle. In Hadar & Hadar, (2016), there is a description of a reference architecture, denominated as CURA (Complex-systems Unified Reference Architecture), which is structured in 4 high-level layers compatible with the TOGAF standard. This solution proposal uses DevOps to deliver not a single automated solution, but rather a composite solution. Moreover, in the context of the DevOps approach and its guidelines, the authors conclude that it “cultivates knowledge reuse, harvests information, reduces erroneous interpretation, and contributes to the cohesion of the professional community”. Furthermore, in the work of Austel et al., (2015), an architectural proposal is presented in which a holistic view of solutions with which to enable the integration of development into operations is defined. In the case of Shahin et al., (2021), conceptual architecture designs are presented to guide the way in which software is developed with DevOps.

Another five papers, classified as Solution Proposal, address BizDevOps and IT governance and management tasks, but do not consider EA. These papers are detailed in Table 7.

Table 7 Solution proposals related to BizDevOps for RQ1, organized by contribution type facet
Full size table

In the work of Gruhn & Schäfer, (2015), an approach is presented that relates to end users, at the business level, who participate in BizDevOps environments. This approach encourages these users to participate in the creation of applications and even to have the necessary tools at their disposal that will allow them to create their own applications. This helps reduce the gap between business and IT department. Another approach is presented in Forbrig, (2018a), in which the author proposes a way in which to represent knowledge by means of a formal notation based on BPM, called S-BPM, to be used in BizDevOps environments. This knowledge representation allows domain experts to express their ideas and make them understandable, in a cross-cutting manner, to all the stakeholders in the organization. However, we believe that formal notations are not understood by most users and are even difficult for non-specialized technical personnel. In another context, the work of Sung et al., (2016) presents a prediction framework based on the use of Data Science techniques with which to collect and analyze information in BizDevOps environments. The result of the analysis is predictions that benefit the organization and fill the gap between business goals and DevOps deliverables (Sung et al., 2016).In Petana & Rosa, (2020), the MATSKI framework is presented as a holistic framework that supports the transformation of raw data into knowledge in an efficient just-in-time manner in BizDevOps environments. In Sanjurjo et al. (2020b), a maturity reference model for BizDevOps is presented. This maturity model is based on widely recognized international standards (such as the ISO/IEC 33000, ISO/IEC 20000, and ISO/IEC 27000 family of standards, the ISO/IEC/IEEE 12207:2017 standard, among others) and gathers technical and business viewpoints with the purpose of guiding and improving BizDevOps implementations.

Furthermore, with regard to relationships between IT Governance and Management and DevOps, there is the work of Wiedemann et al. (2019a, b), in which the authors present a model for the alignment and control of DevOps activities. In this work, the authors aim to identify the interactions of development and operations activities, and how they affect the work teams. In the same context, Wiedemann, (2018) describes IT Governance mechanisms focused on DevOps teams. These mechanisms describe how DevOps teams are organized and how decision-making authority is implemented within an IT function. Another proposal that is related to IT Governance and Management but does not specifically consider BizDevOps, although it is applicable to this approach, is presented in Wettinger et al., (2015). These authors present an approach for knowledge management in environments in which DevOps is used. It is an interesting proposal for resource management activities in IT governance and work environments such as BizDevOps. The proposal of Nielsen et al., (2017) is similar in that it describes a framework with which to share an important resource for IT Governance: information. This framework is applied to work environments that use DevOps. Related to this type of proposal is the work of Jaatun, (2018), which presents an approach for and analysis of incident management in DevOps environments. The author states that the inclusion of developers in the incident management lifecycle allows risks to be reduced to manageable proportions and encourages more organizations to use DevOps. The work of Raj & Sinha, (2020) presents a conceptual framework for the impact of Agile DevOps methodologies on Project Management Practices and Team structure. This framework is a source of information that can be considered when establishing software project governance with BizDevOps, given the shared practices and team structure in the two cycles considered by DevOps. A framework is also presented in the work of Marrero & Astudillo, (2021) and has the objective of assessing the readiness of SMEs to adapt and adopt DevOps practices, culture and tools. The utility of this proposal is not relative to SMEs, but rather considers activities with which to adapt and adopt DevOps practices, culture and tools that could be extended to include the business cycle.

Two works related to maturity models were identified, but were in this case focused on DevOps (Hemon et al., 2019; Teixeira et al., 2020a, b). In the particular case of the work of Hemon et al., (2019), it should be noted that the maturity model aims to assess the maturity for the transition from Agile to DevOps. These DevOps maturity model proposals can be taken as a basis and extended to the business cycle in order to establish the maturity of organizations so as to govern software projects with BizDevOps.

4.1.2 RQ2. What Types of EA Models are Associated with the Business and are Useful in the Context of BizDevOps?

We were unable to find any Enterprise Architecture artifacts, such as viewpoints, views or models, that are directly associated with BizDevOps and that could, therefore, contribute to answering this research question. However, we successfully identified viewpoints and models related to DevOps environments. The latter are a significant contribution, considering that BizDevOps is essentially DevOps with an integrated business component.

The proposal by Pérez-Castillo et al., (2021) provides EA viewpoints in the ArchiMate notation, which result from a reverse engineering process carried out on the organization’s various sources of knowledge (source code, execution logs, database schema, data model specifications, operational data, among others). In Babar et al., (2015), a business process architecture modeling technique with BPMN notation is described. The purpose of this technique is to identify different software domains that can be reconfigured using a DevOps approach. In the study of Ben Mesmia et al., (2021), the authors illustrate the DevOps workflow approach using BPMN notation. They subsequently outline a transformation from BPMN to Stochastic Petri Nets (SPNs) whose objective is to identify properties linked to the actors involved in the approach, the interaction between these actors, and the potential for detecting execution failures associated with the DevOps workflow. This finding suggests the potential use of business-oriented models to manage workflows in software development approaches such as BizDevOps. The work of Furfaro et al., (2016), meanwhile, presents a framework denominated as ‘ResDevOps’ which aims to keep systems running for longer by including a continuous research and innovation process. This process is carried out using a series of UML models that seek to model the context, scenario, and the application of system requirements. Regarding the aforementioned work, we believe that EA notations such as ArchiMate are more suitable for modeling the context and the scenario. This type of proposals could additionally lay the groundwork required to support ongoing IT/Business alignment activities in software development approaches, as is the case of BizDevOps. With regard to the work of Forbrig, (2018a), the use of the S-BPM notation in BizDevOps environments to specify business processes from a stakeholder perspective is presented.

Despite not finding any papers that fully answer this research question, the aforementioned proposals show the possible applicability of industrial modeling standards concerning EAs and Business Process Architecture to BizDevOps scenarios. This is a good sign, given that there is an important background to the modeling and understanding of ArchiMate and BPMN that could serve as a basis for new proposals in the scope of this research question.

Furthermore, when considering the proposals identified, it is plausible to assert that at least the core of the ArchiMate notation (business layer, application layer, and technology layer) has been indirectly explored. This is owing to the fact that notations such as BPMN and UML are complementary to ArchiMate across its various layers. In Fig. 8, the coverage of the ArchiMate layers is depicted, considering the previously presented proposals.

Fig. 8
figure 8

Coverage analysis of the ArchiMate 3.2 full framework (The Open Group, 2022a) taking into account the proposals derived from RQ2

Full size image

4.1.3 RQ3. What Methods, Techniques or Tools are Used in BizDevOps, and Which of them are Based on EA?

There were also no proposals for methods, techniques and tools used in BizDevOps environments and based on or related to EA that would allow this research question to be answered. We, therefore, considered those proposed solutions related to DevOps that could be applied to a BizDevOps environment (see Table 8).

Table 8 Solution proposals related to RQ3, organized by contribution type facet
Full size table

With regard to the tools, we have identified 8 works that contribute with proposals that could be used in the governance and management of software development projects implementing BizDevOps. This includes proposals originally intended for DevOps but that are useful for BizDevOps. Rong et al., (2019, 2020) present a tool that facilitates the process of generating continuous documentation and which can be used in DevOps environments. These proposals prove beneficial for BizDevOps, considering that one of its foundational pillars (shared with DevOps) is knowledge sharing. The efficient management of documentation significantly aids this knowledge exchange. In Hosono, (2012); Hosono & Shimomura, (2012), tools that support application lifecycle management in DevOps environments are presented. Proposals of this nature could be broadened to encompass the business cycle of BizDevOps, given their proven successful implementation within the DevOps context. In Magoutis et al., (2015), a collaborative platform is described for the construction, and subsequent consultation, of a knowledge base that brings together DevOps best practices. In their work, Doukoure & Mnkandla, (2018) present a tool with which to consolidate internal company information and improve the management of DevOps activities with the objective of centralizing all project information in one place. These proposals could be expanded to take into account the business cycle in BizDevOps, thereby sharing this knowledge base with stakeholders external to development and operations, which could facilitate IT/Business alignment. Furthermore, Figalist et al., (2019) describe a monitoring tool that detects anomalies in application components and identifies the root of the problem with the purpose of obtaining feedback and making improvements to each DevOps iteration. Governance inherently involves monitoring, i.e., assessing how well various activities are being conducted, and proposals of this nature could be very beneficial. This monitoring could be implemented in BizDevOps. The insights gathered would not only benefit stakeholders within the development and operations realms but could also enable business roles to adjust development priorities in, for example, light of detected anomalies. Finally, Angara et al., (2020) present a tool for management and decision making in DevOps projects, through the use of Machine Learning and Go/No-Go techniques. Although this proposal is linked to DevOps, it involves business-related tasks that are highly valuable for BizDevOps.

With regard to methods, Delgado et al., (2023) propose a BizDevOps-based approach with which to support the development of business process applications founded on microservices, placing special emphasis on the alignment between Information Technology and Business. In Austel et al., (2015), the authors present a continuous delivery (CD) method, with the integration of new roles and the configuration of rules and parameters, as a means to improve this CD method. This method could serve as the foundation on which to specify a continuous alignment method in BizDevOps and supplement the activities undertaken in the business cycle. In Waits & Yankel, (2014), a method for the continuous generation of technical documentation in environments that have adopted DevOps is specified. This method can be applied to technical or business documents. The work by Ardulov & Shchemelinin, (2017) concerns a method with which to monitor and control distributed environments in order to provide quality services that are aligned with business goals and objectives, while in Aggarwal et al., (2019), a DevOps-based method for software defect management is described. These monitoring and control proposals result in a significant source of knowledge for decision making in BizDevOps. One of the works related to EA but not to BizDevOps, is that of Pérez-Castillo et al., (2021), which describes an extensible reverse engineering method with which to automatically generate ArchiMate models by analyzing different sources of information systems knowledge.

Finally, in the case of techniques, only the work of Babar et al., (2015) was identified, in which a business process architecture modeling technique whose objective is to illustrate the possible dimensions of software process reconfigurability using the DevOps approach is presented.

There are, however, some Solution Proposals (not included in Table 8) that are not related to the topics analyzed by RQ3, BizDevOps and EA, but that do relate to DevOps. These proposals are commented on below, as they could be useful in a BizDevOps environment. One proposal is the paper of Ambler & Lines, (2016), which describes a framework that has similarities to the BizDevOps approach in that its aim is to attempt to bridge the gap between business and IT. Furthermore, in Hosono & Shimomura, (2017) and Rong et al., (2019), two proposals are presented that support IT management by facilitating the documentation process and providing good design practices. In Wiedemann et al., (2020), a model is presented that provides a mechanism with which to solve misalignment between development and operations in DevOps teams. In Hart & Burke, (2020), the proposed solution describes a DevOps IT-Business alignment model in which categories and factors that affect this process are established. Finally, another alignment model is presented in Colavita, (2016), but is focused on helping public and private companies to accelerate digital transformation using a holistic approach to DevOps implementation.

4.1.4 RQ4. What are the Elements in a BizDevOps Context that can and Should be Modeled with EA?

As occurred in the aforementioned cases, the findings of this study do not directly answer this RQ. Nevertheless, some useful ideas can be attained as regards identifying the elements that should be modeled in an EA when working in a BizDevOps scenario.

In Fitzgerald & Stol, (2014) and Fitzgerald & Stol, (2017), it is stated that some of the main components of BizDevOps are continuous engineering activities. It may, therefore, be useful to include and model these activities in an EA with the purpose of discovering their scope and possible aspects to improve. Some of these activities are: ‘Continuous Delivery’, ‘Continuous Integration’ and ‘Continuous Planning’. Furthermore, the usefulness of modeling these activities is shown in the framework and case study proposed by Karvonen et al., (2016). In this work, the authors conclude that the systematic and intensive use of these activities can improve organizations’ competitiveness.

In the paper of Gruhn & Schäfer, (2015), the authors reflect that BizDevOps requires the participants, who will usually be on the boundaries between IT and business departments, to work together. Keeping this in mind, one of the elements to consider in an EA are the actors and roles, as regards both business and IT, that participate in BizDevOps scenarios, thus facilitating knowledge of the activities and services to which they are linked. This coincides with the architectures proposed for the DevOps context in Austel et al., (2015). Moreover, the actors in the system must be specified, since many of the main tasks in this type of approach are carried out in an automated manner. It is, therefore, important to model the type of actors and the way in which they interact and communicate with the human actors; this is in line with the proposal of Cois et al., (2014), who emphasize the relevance of this interaction in their approach.

Furthermore, we believe that reflecting those elements or components that can be reused by the organization should be modeled in the EA. This is owing to the positive experimental results attained after employing reuse approaches in work environments that use the synergy of teams (Ali et al., 2020). These results show improved efficiency and effectiveness in software development that bring gains which, depending on the context and the organization, can translate into time or money. While the approach of Ali et al., (2020) is proposed for DevOps, the main idea of the approach could be applied to BizDevOps in different contexts, especially when EA is used.

In order to facilitate the definition and modeling of an appropriate EA, it should also describe the layers or levels related to BizDevOps and IT governance and management, taking as references the architecture proposals identified for DevOps in the works of Austel et al., (2015) and Hadar & Hadar, (2016). This idea could, for example, be brought to fruition by taking advantage of the layers in the ArchiMate notation (see Fig. 1). This would make it possible to describe continuous BizDevOps activities at Strategic/Business levels, such as Continuous Planning or at Application/Technology/Migrations, and Implementation levels with activities such as Continuous Integration, Continuous Delivery or Continuous Deployment (Fitzgerald & Stol, 2017). In the case of ITG, the set of layers could provide the set of elements required to describe and guide this difficult task (Lankhorst, 2017).

Finally, keeping in mind that BizDevOps contemplates the values of the CAMS (Culture, Automation, Measurement, and Sharing) model (Gruhn & Schäfer, 2015), if these are modeled in the EA, these elements will serve to support and guide the BizDevOps environment and, in general, the organization as a whole. In this respect, it is important to highlight that representing these values in EA models has the advantages mentioned in Sect. 1.3.

4.2 Discussion

In this section, we present a discussion and the main results and findings obtained after carrying out the Systematic Literature Mapping. An assessment of its validity and the threat to this validity is also provided.

Several interesting works can be considered in the context of the findings whose Research Type Facet is not a ‘Solution Proposal’ (see Table 5), some of which are discussed below. This is the case of Drews et al., (2017), which describes a case study. The authors conclude that an integration of BizDevOps with an EA standard, such as TOGAF, is possible and feasible. The opinion paper of Forbrig & Dittmar, (2019) states that one of the most important aspects in BizDevOps is communication between stakeholders. In the work carried out the previous year, Forbrig, (2018b) stated that user stories could be the right tool for communication between business, development and operations people. Furthermore, the review by Fox, (2020) describes that DevOps implies many challenges for IT governance, because the DevOps approach is less rigid and does not have a hierarchical communication structure.

The work of Galup et al., (2020) highlights that the community is getting closer to a consensus that 'DevOps = Agile + Lean + ITIL' can help establish a base set of skills and knowledge that transcends enterprise environments and toolchains.

Moreover, (Díaz et al., 2021)present recommendations to allow practitioners to be better informed about the issues that trigger a transition to DevOps. For example, it is highlighted that an uninformed transition can have more negative effects than benefits, since it implies a change in organizational culture, and this is magnified if other changes occur simultaneously.

4.2.1 Principal Findings

The reason for carrying out this Systematic Mapping Study was to determine the status of EA in the context of BizDevOps and the elements of ITG that are applicable to this approach. Related research has been identified, evaluated, and understood. The main findings are:

  • This study found that there are no proposals that simultaneously involve or relate to the concepts of BizDevOps, EA, and IT Governance, but there are proposals that use combinations of two of these concepts. The paper emphasizes works related to BizDevOps or DevOps, which are applicable to this approach, and enterprise architectures, with the work of Pérez-Castillo et al. (2021) serving as a prime example. In this work, a reverse engineering proposal is presented that aligns with the BizDevOps approach to obtain EA models with ArchiMate. We also found works related to BizDevOps and IT governance, which are presented in Table 7. One of these works is that of Forbrig, (2018a), in which a proposal with domain orientation is presented for knowledge representation and management aligned with the BizDevOps approach, with knowledge management being a pillar of IT Governance. No papers combining IT governance and enterprise architectures are shown, as the core topic of our work (BizDevOps) is not included in them. We believe the inability to identify papers encompassing all three central topics of this study is owing to the nascent state of the subject, indicating that it is an area of research that has potential for further exploration.

  • The BizDevOps approach is still immature when compared to the DevOps approach. This is probably owing to the amount of time that has passed since its emergence and mainly because the BizDevOps approach is related not only to the software development area, but also to organizational issues such as culture, principles, practices, and others, which directly affect alignment with the business. Despite this, we identified promising proposals related to BizDevOps that could pave the way toward interesting research opportunities, particularly within the context of aligning IT with Business (Fitzgerald & Stol, 2017; Gruhn & Schäfer, 2015).

  • When analyzing the proposals that attempt to respond to RQ1, it can be concluded that the topics of EA and ITG in the context of the BizDevOps approach have been explored to a very small extent but present us with great challenges. This is evidenced by the non-existence of papers that consider all three topics simultaneously, although there are papers with characteristics related to the topics, for example, IT/Business Alignment.

  • With respect to RQ2, we have identified that de facto standard notations such as BPMN, UML, and ArchiMate are used to describe DevOps-related elements that could be applied to BizDevOps.

  • Considering the proposals that could respond to research questions 1, 2, and 4, we believe that ArchiMate appears to be the most appropriate notation for modeling an EA in a scenario where BizDevOps is used. This is due to the breadth and completeness of its notation, especially because it includes a business layer and mechanisms (relationships) for managing the alignment between business and IT through relationships between business elements and information systems or IT infrastructure elements. Moreover, different domains of an EA could be modeled using notations such as BPMN and UML. However, it would be more appropriate for the various stakeholders of an organization to interact with a common notation that can consider the aspects modeled by BPMN and UML, which makes ArchiMate useful for this purpose.

  • When considering the relevant papers by research type facet (see Table 5), it is significant that no papers of the 'experience paper' or 'validations research' types were found. We believe that this lack of findings is owing principally to the incipience of BizDevOps in the software industry and research community. The total absence of real cases seems to indicate the difficulty involved in finding organizations that are willing to participate in this type of study. This is possibly owing to the implications for companies as regards making public or sharing valuable and critical information.

4.2.2 Challenges

The literature selected presents numerous solutions to the issues explored in this work. However, supporting the governance of software development projects with BizDevOps requires an integrated approach that blends various strategies. Some ways in which to tackle agile IT/Business alignment in BizDevOps through the use of governance and enterprise architecture proposals are discussed in Fuentes-Quijada et al., (2023). In our previous work, we have identified several alternative approaches of interest with which to address this challenge.

Enterprise reference architectures (The Open Group, 2022b) could be highly beneficial for IT governance, as they can be tailored to specific purposes. This work has identified some DevOps proposals that can be extended to the third business cycle of BizDevOps. Utilizing these proposals (methods, techniques, processes, among others) for BizDevOps is an interesting challenge. It could enable the governance of software projects developed in this framework by establishing guidelines, principles and other elements related to enterprise architectures, such as viewpoints. Furthermore, it could facilitate the alignment between IT and business, and even enhance agility if proposals from the agile architecture practice of TOGAF 10 are employed or adapted.

This work shows that enterprise architecture models could be widely utilized in BizDevOps. This is because they enable the integrated collaboration between business and technology, which is essential in BizDevOps. However, no proposals employing notations from this field have been identified. ArchiMate can enhance communication among diverse stakeholders. This approach aligns well with BizDevOps, in which communication, values, and principles are foundational.

The practice of enterprise architecture is not limited solely to the strategic domain of organizations; it can be highly beneficial across all BizDevOps cycles. In the business cycle, it can guide and facilitate the alignment between IT and the business, while in the development and operations cycles, it can direct, manage, and govern software development processes and activities related to IT infrastructure operations. It additionally incorporates mechanisms such as 'realization' and 'service' relationships between system and technology elements with business elements, thus making it possible to demonstrate the alignment of IT with the business.

4.2.3 Threats to Validity

This section presents the threats to the validity of the Systematic Mapping, according to the five types of validity proposed by Petersen & Gencel, (2013):

  • Descriptive validity: “Descriptive validity concerns threats to the ability to accurately capture and depict observations made” (Badampudi et al., 2016). This threat relates to data extraction. In order to reduce this threat, a data extraction form was designed and reviewed by the two most experienced researchers, who had already conducted several systematic literature reviews and mappings. Moreover, the traceability of all the papers was always maintained, even if they were not part of the group eventually selected.

  • Theoretical validity: “Theoretical validity threats may lead to a lack of ability to capture what is intended to be captured, for example, owing to confounding factors that the researcher may not be aware of” (Badampudi et al., 2016). A major threat to the validity of this study was that an individual author conducted the data selection and extraction processes, and it is, therefore, possible that important studies were omitted. In order to reduce this threat and gain confidence in the results, these processes were monitored and validated by the most experienced authors. Another threat detected in this study is the multiplicity of definitions for the main concepts discussed (BizDevOps, EA, IT Management & Governance). In order to minimize this threat, a conceptual context and terminologies based on standardized and/or contrasted sources were, therefore, established. This was done in order to agree on a clear definition of the concepts and the way in which they interact in the selection of works. An example of this is provided in Table 2 and Table 3, in which categories are provided for classification with a contrasted and accepted terminology.

  • Generalizability: “The generalizability is concerned with generalizing within groups (i.e. the same community or organization) and between groups (i.e. between different communities and groups)” (Badampudi et al., 2016). One of the major threats in this area is publication bias. Based on the number of sources of information that can be accessed today, we believe that it is impossible to achieve complete coverage of all published work in the areas studied. In this SMS, we have used the two major scientific search databases (Scopus and Web of Science). This was done to ensure the quality of the studies and to access the main journals and conferences in the areas studied. However, we do not know whether there may be relevant contributions from the world of industry outside these digital sources.

  • Interpretive validity: “Interpretive validity is concerned with threats related to the ability to draw objective and valid conclusions based on the data collected” (Badampudi et al., 2016). With regard to this threat, all the researchers participated in the various meetings concerning the process of selecting and classifying studies in order to analyze the data and discuss the findings, thereby ensuring that everyone interpreted the data in the same way. Standardized terminology was also used to minimize this threat and facilitate a homogeneous interpretation of the data.

  • Reliability: “In order to achieve reliability, the research steps must be repeatable. Repeatability is the ability of other researchers to replicate the results” (Badampudi et al., 2016). This threat was addressed by specifying a very detailed protocol for the realization of this SMS, for which all the steps required to replicate the studies are provided. In addition, a websiteFootnote 4 is provided in which all the results are presented in detail.

5 Related Works

As Fig. 7 show, a total of 11 literature reviews related to our study were found. Of these reviews, only one has BizDevOps as a topic, while the other 10 reviews are contextualized in DevOps. Figure 9 shows the number of papers by type of literature review and research topic. About 70% of these papers describe the realization of SLRs with a focus on DevOps.

Fig. 9
figure 9

Number of papers by type of review and topic

Full size image

The primary focus of our study is BizDevOps, which requires an understanding of the BizDev and DevOps methodologies in order to obtain a holistic view of the approach. This helps identify means of supporting BizDevOps, especially in contexts in which organizations have taken steps toward employing IT Governance.

The multivocal literature review shown in Lohrasbinasab et al.. (2020) seeks to define BizDevOps and determine its characteristics and challenges. This review aligns with our focus on BizDevOps. However, our study is more specific, since its objective is to identify artifacts that aid in the proper management and governance of IT.

There is a need to explore BizDevOps further, as also occurs with DevOps. As highlighted in Jabbari et al., (2018) and Teixeira et al., (2020a, b), the DevOps approach, while promising, is still in its infancy owing to the lack of empirical evidence demonstrating its usefulness. The same is true of BizDevOps – it is considered promising but sufficient proof of its efficacy is lacking.

The work of Gasparaite et al., (2020) identifies models proposed for DevOps. Since our study focuses on identifying proposed solutions of this nature, the models presented in this work could potentially be extended to a BizDevOps environment.

The objective of the Systematic Literature Review (SLR) by Qumer Gill et al., (2018) is to promote an informed, effective and less risky adoption of DevOps for information management systems. Despite its narrow focus, this review shows the paucity of literature on DevOps artifacts, which also affects BizDevOps.

The objective of the study carried out in Crowley et al., (2018) is to define DevOps and its practices, and the authors underscore that in order for organizations to reap maximum benefits, DevOps must be understood and applied throughout the organization. This demands a broader approach that includes all organizational stakeholders and helps identify existing BizDevOps approaches and the gaps yet to be filled.

The literature review by van Belzen et al., (2019) identified critical success factors for DevOps continuous practices. This review is significant for BizDevOps, which incorporates business aspects into the software development process.

The objective of the SLR shown in the study by Muñoz et al., (2019) is to establish the current state of DevOps with a focus on its adoption by organizations, underlining that DevOps represents a significant cultural shift. Despite the fact that our study does not focus primarily on DevOps, understanding its adoption is useful. The study concluded that one of the main challenges of DevOps is the lack of management activities, which aligns with our goal of identifying elements with which to manage software development in BizDevOps contexts.

Finally, Aguiar Monteiro et al., (2020) present an SMS whose objective is to identify the existing gaps in DevOps as regards implementation methods, maturity models and the definition of participant roles.

While many studies that are parallel our work tend to focus solely on DevOps, our work takes a more targeted approach. We aim to identify both primary and secondary studies pertaining to BizDevOps, Enterprise Architectures, and IT Governance and Management. Our research, therefore, goes beyond just DevOps, since it explores the intricacies of BizDevOps and its role within broader IT strategies and organizational structures in greater depth.

6 Conclusions and Future Work

This Systematic Mapping Study collects, filters, and classifies the main proposals found in relation to BizDevOps and its governance, particularly when using Enterprise Architecture. We have selected a total of 83 primary studies and 11 relevant secondary studies from an initial set of 982 papers, which were retrieved from Web of Science and Scopus.

The results of this study have led us to conclude that BizDevOps could take advantage of ITG best practices. These best practices can be reflected in the activities that this approach provides in order to facilitate the alignment between business and IT when developing software. One of the main objectives of BizDevOps is to break down the silos that exist between business and technology departments in organizations.

One of the drawbacks we found is that the literature related to BizDevOps is limited, and even more so if it is restricted only to Enterprise Architecture or ITG topics. However, we were able to obtain valuable information for each of the research questions.

In this context, we believe that one of the main conclusions we have reached in this study is that of seeing the usefulness of using Enterprise Architectures and the models that describe them to support and manage the processes in the BizDevOps approach. This makes more sense to us when using an EA model with the ArchiMate notation, which would make it possible to reflect the three cycles of this approach, which fit with the three main ArchiMate layers (Business, Applications/Development, Technology/Operations), the stakeholders in each cycle, and the IT infrastructure ecosystem that supports each cycle, especially development and operations (denominated as the DevOps toolchain).

We are also of the opinion that there are many challenges to address in BizDevOps. This is because this approach has not been addressed as extensively and in as much detail as DevOps. In this context, we believe that there is a need for primary studies dealing with the benefits and uses of potential synergies between the concepts of BizDevOps, Enterprise Architecture and ITG. A possible example of this is the application of EA modeling, an ITG tool, in order to manage and visualize the software development processes using the BizDevOps approach.

To summarize the findings of this study, we can highlight that no papers were found in our search that specify the performance of empirical validations. Furthermore, 42.2% of the relevant papers detail only recommendations and/or lessons learned without describing a specific solution proposal in the scope of this work.

In relation to RQ1, this study shows that no proposals consider the joint use of BizDevOps, EA and ITG. However, there are indeed proposals that address the combination of two of these three concepts. In addition, it is necessary to keep in mind that proposals that consider the use of EA indirectly imply the use of ITG, given that EA is a governance and management approach.

With regard to RQ2, the EA models used in the proposals found in this work in the context of BizDevOps are mainly Archimate and BPMN. The former is principally used in the context of EAs, while the latter is used mainly for business process modeling.

In the case of RQ3, and owing to the results of RQ1, no solutions, such as methods, techniques or tools that consider the three main concepts of this study, are proposed. However, useful proposals have been found in the context of DevOps that can be exploited in BizDevOps. For example, in this study we report an IT-Business alignment model for DevOps.

Finally, with regard to RQ4, the works found lead us to believe that the relevant elements to model should be the processes, concerns and stakeholders linked to a BizDevOps context. Considering this and the findings of RQ2, we believe that the notation with the best characteristics and expressiveness with which to model these elements could be ArchiMate.

As part of our future work, we shall continue with this study by investigating the possible synergies between BizDevOps, EA and IT Governance. Furthermore, we shall focus on generating a new governance and management framework (models, methods, patterns, and techniques) to support BizDevOps approach in organizations.