An Architectural Viewpoint for Managing BizDevOps Software
Guillermo Fuentes-Quijada
, Francisco Ruiz-González
and Angélica Caro
Institute of Technology and Information Systems, University of Castilla-La Mancha, Ciudad Real, Spain
Computer Science and Information Technologies Department, University of Bío-Bío, Chillán, Chile
Keywords: Enterprise Architecture, IT-Business Alignment, Software Development, BizDevOps, Viewpoint.
Abstract: BizDevOps extends the DevOps approach by integrating a business cycle that encompasses stakeholders
beyond the realm of information technology, aiming to support the alignment between IT and business while
also fulfilling organizational objectives. This approach could be augmented with the use of enterprise
architecture descriptions and customized architectural viewpoints, which facilitate the analysis,
communication, and management of team-specific concerns. This study introduces BizDevOps-VP,
proposing a viewpoint designed to enhance communication and decision-making within BizDevOps teams,
focusing on their concerns, with the goal of supporting IT/business alignment without compromising agility.
Numerous innovative software (SW) development
approaches have been proposed to address the ever-
evolving requirements of organizations (Gokarna &
Singh, 2021). Many of these approaches emphasize
fostering communication and collaboration between
Information Techonologies (IT) and business teams.
Among these methodologies, one noteworthy
approach is BizDevOps, which comprises three
seamlessly integrated cycles: business, development,
and operations cycle. These cycles collectively aim to
implement an organization's software requirements
effectively (Gruhn & Schäfer, 2015). BizDevOps has
evolved from the well-established DevOps
methodology, which primarily focuses on aligning
software development and operations teams to
optimize software production and delivery processes
(Hart & Burke, 2020; IEEE, 2021). However,
BizDevOps takes a step further by introducing a third
cycle that incorporates the business perspective into
SW development (Gruhn & Schäfer, 2015). The
primary goal of this approach, coupled with its
dedicated business cycle, is to enhance the
participation of business units in IT processes,
facilitating better alignment with the dynamic needs
of organizations (Sanjurjo, Pedreira, Garcia, &
Piattini, 2020). Achieving alignment between IT and
business is a substantial challenge in the realms of IT
management, a point underscored by Kappelman,
Johnson, Torres, Maurer, and McLean (2019).
However, BizDevOps does not account for a
favorable handling of agility in the business cycle, as
is done in the development and operations cycles.
This can create a bottleneck in the software
development lifecycle and lead to a loss of overall
agility. This problem is detrimental to the
organization as it misses out on the benefits that
agility brings in DevOps. Some of these benefits
include early error detection, improved team
communication, reduced resource consumption
(time, money), and enhanced software quality (Raj &
Sinha, 2020).
On the other hand, descriptions of Enterprise
Architectures (EAs) allow for controlling and sharing
the knowledge and concerns of different stakeholders
in an organization, which can be important in medium
or high complexity software engineering projects
(Pérez-Castillo, Ruiz, Piattini, & Ebert, 2019). An
enterprise architecture is a set of principles, methods,
and models used in designing and implementing the
organizational structure, business processes,
Fuentes-Quijada, G., Ruiz-González, F. and Caro, A.
An Architectural Viewpoint for Managing BizDevOps Software Projects.
DOI: 10.5220/0012538000003690
Paper published under CC license (CC BY-NC-ND 4.0)
In Proceedings of the 26th International Conference on Enterprise Information Systems (ICEIS 2024) - Volume 2, pages 643-650
ISBN: 978-989-758-692-7; ISSN: 2184-4992
Proceedings Copyright © 2024 by SCITEPRESS Science and Technology Publications, Lda.
information systems, and IT infrastructure of a
company (Lankhorst, 2017). The descriptions of EAs
can be represented through models based on different
viewpoints, which enable managing concerns in
various contexts and for different stakeholders
(PérezCastillo, Caivano, Ruiz, & Piattini, 2021).
In Fuentes-Quijada, Ruiz-Gonzalez, and Caro
(2023), it is indicated that a viewpoint (VP) could be
a very useful artifact since they allow the analysis and
sharing of concerns and interests of each type of
stakeholder, thus promoting alignment between
IT/Business and establishing a standardized
communication approach within BizDevOps teams.
This type of artifact has already been successfully
used to support software development approaches
like DevOps, in which the concerns of the DevOps
team are analyzed and shared through a viewpoint
(Pérez-Castillo et al., 2019).
The motivation of this effort is guided by the
following research question:
“Could a viewpoint prove beneficial in managing
software projects that employ BizDevOps?”
To address this question, we have employed the
Design Science Research (DSR) Methodology
(Hevner & Chatterjee, 2010) and the ArchiMate
"Viewpoint mechanism" (The Open Group, 2022) to
design, develop, and initially evaluate a viewpoint
aimed at enhancing the communication of concerns,
needs, and requirements within the BizDevOps team.
This viewpoint is called BizDevOps-VP (Viewpoint
for managing BizDevOps SW projects). This artifact
is specifically designed to facilitate the management
of SW projects within the BizDevOps approach while
ensuring alignment between IT and the business, all
without compromising agility throughout the process.
The structure of this paper is as follows: Section 2
details the background to this work. Section 3 details
the viewpoint specification. Section 4, present an
initial validation of the viewpoint. Finally, Section 5
outlines the conclusions and future work.
The following section presents the key concepts
addressed in this study.
2.1 BizDevOps
The concept of BizDevOps represents the active and
joint participation of business, development and
operations roles (see Figure 1) for the purpose of
developing software (Gruhn & Schäfer, 2015).
BizDevOps is a natural extension that
organizations using DevOps as a software
development approach can undertake. This extension
includes activities aimed at facilitating IT/business
alignment and involvement of business stakeholders.
Figure 1: BizDevOps cycles from (Fuentes-Quijada et al.,
2.2 Viewpoint
The ISO 42010 standard (ISO/IEC/IEEE, 2022)
establishes that a viewpoint is a set of agreements for
constructing, interpreting, using, and analyzing an
architectural view, with a focus on the concerns of a
In terms of ISO 42010 standard, Archimate is an
Architecture Description Framework (ADF) used to
describe, analyze, and communicate many of the
concerns of enterprise architectures as they change
over time (ISO/IEC/IEEE, 2022). This standard
provides us with a set of entities and relationships
along with their corresponding icons for representing
architecture descriptions (The Open Group, 2022).
Considering the above, the generic concepts of
viewpoint and view from the ISO 42010 standard are
realized in Archimate as follows:
An Archimate viewpoint is a relevant subset of
the entities and relationships defined in the
Archimate metamodel.
An Archimate view is a set of one or more
models representing a portion of an architecture,
using the concepts and relationships of the
corresponding viewpoint.
ArchiMate provides a mechanism, which is
aligned with the ISO 42010 standard (ISO/IEC/IEEE,
2022), for specifying a viewpoint. This mechanism
requires the specification of the following elements.
(The Open Group, 2022):
Stakeholders: it should be established for which
stakeholders the viewpoint is specified.
Concerns: the concerns or concerns that are
intended to be communicated through the
viewpoint should be identified.
ICEIS 2024 - 26th International Conference on Enterprise Information Systems
Purpose: The establishment of the viewpoint's
purpose is crucial, and ArchiMate categorizes
them into three distinct types: (Design) Design
viewpoints support architects and designers in the
design process from initial sketching to detailed
design; (Decide) Decision-support viewpoints
assist managers in the decision-making process by
providing information on cross-domain
architectural relationships; and, (Inform)
Informative viewpoints help inform any
stakeholder about Enterprise Architecture to
achieve understanding, obtain commitment, and
persuade opponents.
Scope: the scope of the viewpoint should be
established. In ArchiMate, this corresponds to the
layers and aspects to be used, and in standard ISO
42010, it relates to the perspectives of
stakeholders and aspects.
Elements: The notation elements that are part of
the viewpoint should be detailed.
3 BizDevOps-VP
In this section, a specific viewpoint is defined to
communicate the concerns of the BizDevOps team.
3.1 Concerns
The concerns of this viewpoint focus on managing
software development projects with BizDevOps
while aligning IT with the business objectives and
attempting to preserve the agility of the software
development process intact.
3.2 Rationale
The viewpoints delineated within the ArchiMate
specification range from being excessively broad, as
detailed in the document (available online
) that we
have compiled, where the scope of each viewpoint
described by this standard is elaborated in terms of
ArchiMate elements. Considering this and the
concern outlined in the previous subsection, we
maintain that a specialized viewpoint could prove
beneficial for the BizDevOps team.
3.3 Scope
Considering the above subsection, the scope of this
viewpoint is solely the management of SW
development projects; therefore, governance aspects
such as the organization's strategy are not considered.
To mitigate stakeholder distraction from
ArchiMate's broad notation in enterprise architecture
modeling, we employed a top-down strategy to
establish the BizDevOps-VP scope. This approach
facilitates precise refinement of architectural
components. By initially identifying stakeholder
viewpoints and then detailing specific aspects, we
align with ArchiMate's structured layers and facets.
This ensures our application is both focused and
impactful, faithfully adhering to its original purpose.
This is detailed graphically shown in Figure 2.
Figure 2: Stakeholder Perspective and Aspect compliance
in ArchiMate 3.2, adapted from (ISO/IEC/IEEE, 2022; The
Open Group, 2022).
Considering the stakeholders and concerns for
BizDevOps-VP, the following decisions have been
derived regarding the ArchiMate layers:
Strategy: This layer is used to model the
organization's strategic direction and choices
concerning their impact on architecture. This
layer can be used to express how the company
intends to create value for its stakeholders, the
capabilities it needs, and the resources required to
support these capabilities (The Open Group,
2022). Considering the above and that the scope
of this viewpoint is solely SW project
management, the ability to communicate the
company's capabilities and how it creates value is
not useful for this viewpoint. Therefore, this layer
is excluded.
Business: this layer is used to model the
operational organization of a company
independently of technology. It also allows
representing business services offered to
customers, which materialize in the organization
through business processes carried out by
An Architectural Viewpoint for Managing BizDevOps Software Projects
business actors (The Open Group, 2022).
Considering that this viewpoint encompasses
business roles, it's highly beneficial for them to
have the ability to communicate their concerns,
for instance, regarding business services and
processes that IT elements need to support. This
layer should be included in the viewpoint.
Application: this layer is used to model
application services that support the business and
the applications that materialize them, as well as
to describe the structure, behavior, and interaction
of the company's applications (The Open Group,
2022). The concern of this viewpoint is the
management of SW development projects with
BizDevOps, and such software can be represented
through this layer. Additionally, this viewpoint's
concern considers the need for aligning
IT/Business and maintaining agility during the
process. Therefore, both elements from this layer
and the business layer should be visible. For this
reason, it is necessary to include this layer in the
Technology: this layer is used to model both IT
and operational technologies. This includes
technologies such as processing, storage, and
communication supporting the application and
business layers. It also allows modeling physical
or tangible elements like facilities, equipment,
materials, and distribution networks (The Open
Group, 2022). The BizDevOps team may also
consider IT operations roles; therefore, it is
appropriate to include this layer. Furthermore, as
indicated, it allows modeling technologies
supporting the application and business layers,
which could be essential for maintaining agility or
achieving alignment. However, physical elements
that can be modeled are not part of the BizDevOps
team's concern. Taking all of this into account, the
technology layer is included, excluding physical
layer components.
Migration and Implementation: this layer is
used to model elements that support the
implementation and migration of architectures.
This includes modeling implementation programs
and projects to support program, portfolio, and
project (The Open Group, 2022). Considering the
focus of this layer and the objective of this
viewpoint being the management of SW
development projects and not the implementation
and/or migration of architectures, this layer is
Based on the previous analysis, the layers that are
useful for this viewpoint are: Business, Application,
and Technology. Now, let's identify the aspects that
are useful for the BizDevOps-VP objective. This
analysis is carried out considering the order in which
the aspects are presented in Figure 2.
Passive Structure: This aspect is used to model
objects upon which behavior is performed;
typically, these are information objects in the
business layer and data objects in the application
layer, but they can also be used to represent
physical objects (The Open Group, 2022). The
elements of this aspect could be useful to express
the "what" regarding the concerns of the
BizDevOps team. Therefore, this aspect is
Behavior: This aspect is used to model elements
that describe behavior (processes, functions,
events, and services) performed by actors (The
Open Group, 2022). These elements could be of
great utility for the viewpoint when describing the
"how" related to the concerns of the BizDevOps
team. This aspect is included in the viewpoint.
Active Structure: This aspect is used to model
structural elements (business actors, application
components, and devices that exhibit real
behavior; in other words, the 'subjects' of activity)
(The Open Group, 2022). The elements of this
aspect could be very useful to establish "who" or
"what" performs some behavior in the context of
software project management. This aspect is
included in the viewpoint.
Motivation: This aspect is used to model the
motivations or reasons that guide the design or
change of an Enterprise Architecture (The Open
Group, 2022). The elements of the motivation
aspect could be useful when establishing the
"why" of the concerns of the BizDevOps team.
Additionally, it could be useful when
communicating the drivers and objectives related
to IT/Business alignment, thus facilitating the
understanding of the BizDevOps team.
3.4 Element Selection
The analysis presented below delves deeper, down to
the level of the elements that ArchiMate includes in
each layer-aspect combination. Below are the
elements that were not selected because they are not
relevant to the purpose of the BizDevOps-VP and
may degrade the team's ability to facilitate
BizDevOps communication.
In Table 1, the not selected elements are presented
along with their corresponding layer and aspect,
along with the justification for that decision.
ICEIS 2024 - 26th International Conference on Enterprise Information Systems
Table 1: Justification for not selecting ArchiMate elements.
Layer Aspect Element Justification
The audience for this VP should not have the need to model representations
of a business object.
The interactions that occur in the business layer are not of interest to the entire
audience of this VP and it could be confusing for IT stakeholders.
Business Event
The events that occur in the business layer are not of interest to the entire
audience of this VP and it could be confusing for IT stakeholders.
Business Actor
For audience of this VP, it is not of interest to know which specific actor can
carry out an activity.
Business collaborations can be confusing for stakeholders outside the
business area. Therefore, this element would not be useful for the VP.
The behaviors that an application component may describe are not of interest
to the entire audience of this VP because they are specific to IT stakeholders
The collective behaviors of an application may not be of interest to the entire
audience of this VP because they are specific to the IT area's analysis.
The sequence of behaviors that describe an application is not of interest to the
entire audience of this VP because it is specific to the IT area's analysis.
The change of state of an application is not of interest to the entire audience
of this VP because it is specific to the analysis of the IT area.
The aggregation of elements in the active structure of the application layer to
represent collective behavior is of interest only to the IT audience of this VP.
The representation of data artifacts used or produced in a SW development
process is of interest only to the IT audience of this VP.
The representation of behaviors specific to the active structure of the
technology layer is of interest only to the IT audience of this VP.
The representation of a sequence of behaviors in the technology layer is of
interest only to the IT audience of this VP.
The collective behavior of elements in the active structure of the technology
layer is of interest only to the IT audience of this VP.
A change of state in the technology layer is not of interest to the entire
audience of this viewpoint because it is specific to the analysis of the IT area.
The representation of computational and/or physical resources in the
technology layer is of interest only to the IT audience of this VP.
The representation of physical IT resources in the technology is of interest
only to the IT audience of this VP.
The representation of software systems in the technology layer is not of
interest to the entire audience of this viewpoint because it is specific to the
analysis of the IT area.
The representation of collective behavior in the technology layer is not of
interest to the entire audience of this viewpoint because it is specific to the
analysis of the IT area rather than the business area.
The access points to the technological layer services are of interest only to the
IT audience of this VP.
The links between elements of the active structure in the technological layer
are not of interest to the entire audience of this viewpoint.
The connection structure of elements in the technology layer is not of interest
to the entire audience of this viewpoint.
The outcome of a certain situation is not of interest to represent because the
BizDevOps approach is a cyclic approach, and there is no final state.
The relative value of a concept is not useful to represent in this viewpoint
because it has no utility in the SW project management process with
An Architectural Viewpoint for Managing BizDevOps Software Projects
3.5 Viewpoint Specification
Considering the specification requirements set by the
‘Viewpoint Mechanism’ of ArchiMate 3.2 (The Open
Group, 2022), BizDevOps-VP is detailed in Table 2.
Table 2: BizDevOps-VP Specification.
Elements Specification
The BizDevOps team, composed of the
following roles: Product Owner, Agility
Manager (or ‘SCRUM Master’ if
following SCRUM), and Other DevOps
Managing a software project with
BizDevOps while aligning IT/Business
attempting to preserve the agility.
Decide: The BizDevOps team needs to
make decisions based on this
perspective to align, maintain agility,
and manage projects effectively.
Inform: The BizDevOps team aims to
ensure clear communication of software
project management among all
In summary, it is multi-layered and
multi-aspect, and in detail: (i) layers:
Business, Application, and Technology
(excluding the physical layer), and (ii)
aspects: Passive and Active Structure,
Behavior, and Motivation.
The elements for this viewpoint are:
Business Layer: Business Object,
Contract, Product, Business Role,
Business Interface, Business Process,
Business Function, Business Service
Application Layer: Data Object,
Application Component, Application
Technology Layer: Technology
Motivation Aspect: Assessment,
Constraint, Driver, Goal, Meaning,
Principle, Requirement, Stakeholder
To validate the applicability of the viewpoint, we
have chosen one case study from the company Arnia
, and we have conducted a proof of concept.
As developers, testers, designers, operations managers,
among others (ISACA, 2020).
4.1 Case Study: Prepaid Card
The selected case study
is related to the finances of
an organization and require a software solution.
The company needed to implement an efficient
way to manage corporate expenses through prepaid
cards. The company developed a versatile product
accessible through web and mobile interfaces, backed
by a unified set of RESTful web services. This
developed system was required to ensure high
availability, zero downtime during maintenance and
updates, and compliance with PCI DSS standards.
Key features of the solution include issuing
prepaid cards, tracking and reporting on transactions,
configuring and managing expense limits, enabling
monitoring and approval by accounting departments,
secure PCI-compliant storage of credit card
information, and comprehensive transaction and
balance management, including authorization
acceptance and decline, as well as payments and
virtual card capabilities.
From the outset of each project, the company
leverages the benefits of Scrum and Kanban
methodologies. Development team, based at the
company's headquarters, consists of six members:
three backend developers, one frontend developer,
and two quality assurance specialists. The company
maintain close collaboration with the Customer
Service team and the infrastructure team, which
includes project managers, sales, marketing experts,
and specialized designers. The company Arnia
Software approaches all projects with agility and
flexibility, conducting daily Scrum meetings with
sprints and delivering demonstrations every two
The architecture of the solution implemented by
the company follows a client-server model with
multiple clients, including a Single Page Application
(SPA) for web browsers developed in Angular, as
well as mobile applications for iOS and Android. The
backend acts as a server and provides REST services
written in Java 7 using the vert.x framework. The
back office is kept completely isolated with separate
frontend and backend components, accessible
through a dedicated VPN. The solution was designed
as a Software as a Service (SaaS) platform and
supports multiple organizations within the same
application cluster. The technologies used in the
frontend include Angular, Grunt, and Bootstrap.
Development tools encompass Jira, Jenkins, Github,
and Ansible.
ICEIS 2024 - 26th International Conference on Enterprise Information Systems
Figure 3: Result of Proof of Concept for the applicability of BizDevOps-VP to the case study.
4.2 Proof of Concept: Using
An EA model has been created using BizDevOps-VP
applied to the case study. The results can be seen in
Figure 3. Using the components comprising
BizDevOps-VP, we successfully captured all
pertinent aspects of the case study. Certain elements
within the application layer, as described in the case
study, were intentionally excluded from the modeling
to avoid potential distractions for non-IT team
members. Nevertheless, fostering familiarity among
business-oriented team members with IT concepts is
a valuable goal. To illustrate, we included models of
Back-end and Front-end services to emphasize the
presence of software-related elements offering
internal services.
The modeled case study currently employs an
agile methodology based on Scrum and DevOps, as it
has proven challenging to secure a real-world case
where BizDevOps is already in practice. However,
we contend that this is not a hindrance, given that
BizDevOps is essentially an organic extension of
DevOps, incorporating a business cycle. This
presents an opportunity for us to validate its
By leveraging this model, we are confident that it
will enhance communication among team members
involved in business, development, and operations.
This benefit arises from the adoption of a
comprehensive notation, filled with elements that
enable a thorough description of the critical aspects
they need to consider when managing the project.
Figure 3 illustrates an architectural view using the
specified viewpoint, which emphasizes its potential to
strengthen the software project management process.
This potential is evident in how the development team
can model and visualize internal agreements,
constraints, and requirements within the team.
Additionally, they can outline the services provided
by various areas (business, development, and
operations), understand the project's goals, and
identify the involved stakeholders. Such an approach
greatly facilitates a comprehensive understanding and
management of the project, aligning the multifaceted
aspects and the teams involved.
With the extensive descriptive capabilities of
BizDevOps-VP, the team can amass information and
make informed decisions regarding software project
management, and likewise, effectively communicate
their concerns.
In turn, the BizDevOps team can graphically
illustrate how software services and components
correspond with business requirements. This
approach could considerably simplify the process of
aligning IT with business strategies.
An Architectural Viewpoint for Managing BizDevOps Software Projects
In this study, we introduce BizDevOps-VP, which is
potentially beneficial for the management of software
projects. BizDevOps-VP is promising in improving
communication and decision-making within project
teams, effectively fulfilling its designated goals.
Our proposal aims to support individuals
responsible for overseeing BizDevOps initiatives
who may not have prior experience with enterprise
architecture practices. By utilizing architectural
models with standardized notations, such as
ArchiMate, we can improve comprehension of all
facets that influence SW development with this
We posit that BizDevOps-VP can assist in two
crucial areas: (i) managing the inherent complexity
associated with transitioning from DevOps to
BizDevOps, and (ii) ensuring the proper balance
between DevOps agility and alignment of software
with the business. In this context, the proof of concept
represents an initial step demonstrating the feasibility
of our proposal. However, we think it's crucial to
thoroughly validate our work. In the future, we plan
to carry out detailed case studies in different
organizations and survey field experts.
This work has been supported by the OASSIS project
(PID2021-122554OB-C31, funded by MCIN / AEI /
10.13039/501100011033 / FEDER, EU), Grant
PRE2019-087303, funded by MCIN/AEI/
10.13039/501100011033, and by “ESF Investing in
your future”.
Fuentes-Quijada, G., Ruiz-Gonzalez, F., & Caro, A. (2023).
Towards Agile IT/Business Alignment at BizDevOps.
Paper presented at the Proceedings of the 25th
International Conference on Enterprise Information
Systems - Volume 2: ICEIS.
Gokarna, M., & Singh, R. (2021). DevOps: A Historical
Review and Future Works. Paper presented at the
International Conference on Computing,
Communication, and Intelligent Systems (ICCCIS),
Greater Noida, India.
Gruhn, V., & Schäfer, C. (2015). BizDevOps: Because
DevOps is Not the End of the Story. Paper presented at
the Intelligent Software Methodologies, Tools and
Techniques. SoMeT 2015. Communications in
Computer and Information Science.
Hart, M., & Burke, J. (2020). An Exploratory Study on the
DevOps IT Alignment Model. Interdisciplinary
Journal of Information, Knowledge, and Management,
15, 127-154. doi:10.28945/4595
Hevner, A., & Chatterjee, S. (2010). Design Science
Research in Information Systems. In A. Hevner & S.
Chatterjee (Eds.), Design Research in Information
Systems: Theory and Practice (pp. 9-22). Boston, MA:
Springer US.
IEEE. (2021). IEEE 2675: 2021 IEEE Standard for
DevOps. IEEE Standard for DevOps. Retrieved from
ISACA. (2020). COBIT Focus Area: DevOps. In ISACA
(Ed.), (pp. 156).
ISO/IEC/IEEE. (2022). International Standard for
Software, systems and enterprise--Architecture
description. ISO/IEC/IEEE 42010:2022(E), 1-74.
Kappelman, L., Johnson, V., Torres, R., Maurer, C., &
McLean, E. (2019). A study of information systems
issues, practices, and leadership in Europe. European
Journal of Information Systems, 28(1), 26-42.
Lankhorst, M. (2017). Enterprise Architecture at Work (4
ed.). Berlin, Heidelberg: Springer Berlin Heidelberg.
Pérez-Castillo, R., Ruiz, F., Piattini, M., & Ebert, C. (2019).
Enterprise Architecture. IEEE Software, 36(4), 12-19.
PérezCastillo, R., Caivano, D., Ruiz, F., & Piattini, M.
(2021). ArchiRev—Reverse engineering of information
systems toward ArchiMate models. An industrial case
study. Journal of Software: Evolution and Process,
33(2), e2314-e2314. doi:10.1002/smr.2314
Raj, P., & Sinha, P. (2020). Project Management In Era Of
Agile And Devops Methodlogies. International
Journal of Scientific & Technology Research, 9, 1-1.
Sanjurjo, E., Pedreira, O., Garcia, F., & Piattini, M. (2020).
Process Reference Model for BizDevOps. Paper
presented at the 15th Iberian Conference on
Information Systems and Technologies (CISTI),
Seville, Spain.
The Open Group. (2022). ArchiMate® 3.2 Specification.
Retrieved from
ICEIS 2024 - 26th International Conference on Enterprise Information Systems