# An Enterprise Marketplace for Unified Access to Multi-Cloud and Enterprise Products in a Large Banking Infrastructure

Richard Casetta, Thomas Brisbout, Jean-François Tur, Mariam Barry, Julien

Veybel, Jean-Michel Garcia, Nils Gesbert, Pierre Genevès

► To cite this version:

Richard Casetta, Thomas Brisbout, Jean-François Tur, Mariam Barry, Julien Veybel, et al. An Enterprise Marketplace for Unified Access to Multi-Cloud and Enterprise Products in a Large Banking Infrastructure. ICSE 2026 - IEEE/ACM International Conference on Software Engineering- SEIP, Apr 2026, Rio de Janiero, Brazil. p. 1-11, 10.1145/3786583.3786914. hal-05462351

HAL Id: hal-05462351

https://inria.hal.science/hal-05462351v1

Submitted on 16 Jan 2026

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons CC BY 4.0 - Attribution - International License
# An Enterprise Marketplace for Unified Access to Multi-Cloud and Enterprise Products in a Large Banking Infrastructure

Richard CASETTA

Thomas BRISBOUT

Jean-François TUR

Mariam BARRY

richard.casetta@bnpparibas.com

BNP Paribas

BNP Paribas

BNP Paribas

BNP Paribas

France

France

France

France

Univ. Grenoble Alpes, Inria,
CNRS, Grenoble INP, LIG
France

Julien VEYBEL

Jean-Michel GARCIA

Nils GESBERT

Pierre GENEVES

BNP Paribas

BNP Paribas

Univ. Grenoble Alpes, Inria,
CNRS, Grenoble INP, LIG
France

Univ. Grenoble Alpes, Inria,
CNRS, Grenoble INP, LIG
France

France

France

## ABSTRACT

We present the design and evaluation of an Enterprise Marketplace that unifies web-based access to multi-cloud and enterprise products within a large banking infrastructure. Building such a platform poses significant technical and organizational challenges, including the generalization of diverse APIs and the accommodation of heterogeneous user profiles. Our solution enables autonomous product publishing via a no-code interface, enforces multi-layered governance to ensure security and compliance, and integrates disparate providers through a standardized API. We demonstrate how this approach enhances product quality, producer autonomy, and user experience, supported by adoption metrics and operational data from a real-world deployment. Finally, we reflect on key lessons learned and persistent challenges after a decade of production use, serving over 200,000 users.

## CCS CONCEPTS

* Information systems → Enterprise applications; * Applied computing → Service-oriented architectures; * Human-centered computing → User centered design.

## KEYWORDS

Enterprise marketplace; Cloud Service Broker; Multi-cloud; Standardized API; Governance; No-code publishing;

### ACM Reference Format:

Richard CASETTA, Thomas BRISBOUT, Jean-François TUR, Mariam BARRY, Julien VEYBEL, Jean-Michel GARCIA, Nils GESBERT, and Pierre GENEVES. 2026. An Enterprise Marketplace for Unified Access to Multi-Cloud and Enterprise Products in a Large Banking Infrastructure. In *2026 IEEE/ACM 48th International Conference on Software Engineering (ICSE-SEIP '26)*, April 12–18, 2026, *Rio de Janeiro, Brazil*. ACM, New York, NY, USA, 11 pages. https://doi.org/10.1145/3786583.3786914

<figure><img src="image_2.png" /></figure>

This work is licensed under a Creative Commons Attribution 4.0 International License. ICSE-SEIP '26, April 12–18, 2026, Rio de Janeiro, Brazil

© 2026 Copyright held by the owner/author(s).

ACM ISBN 979-8-4007-2426-8/2026/04

https://doi.org/10.1145/3786583.3786914

## 1 INTRODUCTION

Large organizations operate complex and distributed IT landscapes that support a wide array of applications for internal teams and external clients. As part of their strategic modernization, many have initiated transitions to cloud computing, a pivotal shift aimed at improving scalability, agility, and service delivery. While public cloud adoption has gained momentum industry-wide, organizations subject to strict regulatory and operational constraints often also invest in multiple private cloud infrastructures to meet compliance and security requirements.

<figure><img src="image_3.png" /><figcaption>Figure 1: Marketplace overview</figcaption></figure>

Following this shift, organizations started to build cloud portals, such as ING Private Cloud [18], a place where users could discover and consume cloud products. This model proves effective when an organization operates within a single cloud provider by managing several catalogs. In such contexts, internal teams can build products with Infrastructure as Code (IaC) templates (like CloudFormation [1] for AWS Service Catalog [2]) atop cloud-native products and expose them through curated catalogs and portfolios, enabling secure discovery, deployment, and lifecycle management.

### 1.1 Problem statement

In multi-entity organizations, this model quickly becomes fragmented. Each entity may maintain distinct governance policies, entitlement management, service requirements and cloud providers. Consequently, users are forced to order and manage cloud products by using numerous portals, leading to a disjointed and inefficient
user experience. This is what happened at BNP Paribas, where various portals exist for different cloud providers, and where some portals even share the same underlying cloud provider, managing different resources (see Figure 2).

This challenge is not unique to cloud services, similar fragmentation has long existed in IT companies, and still exist to this day [31] where users must navigate several applications to access different services. For instance, when a BNP Paribas manager needs to provision a cloud resource, request badge access, and order software for a new team member, each action requires navigating a separate portal with distinct authentication and workflows. Conversely, a product manager seeking to make a newly created product visible to its intended audience may face delays if additional development effort is required to build a dedicated frontend or feel frustrated to rely on an existing interface that may lack adoption. This fragmented process leads to delays and duplicated effort, highlighting the need for a solution to this sprawl.

<figure><img src="image_4.png" /><figcaption>Figure 2: Proliferation of portals</figcaption></figure>

To clarify terminology used throughout this paper:

**Entity** refers to a BNP Paribas business unit, each with its own governance and security model.

**Providers** are systems and teams that build portals by exposing APIs and frontends for managing cloud and enterprise products, including provisioning, billing, and administration.

**Producers** are teams responsible for publishing and maintaining products, including IaC templates on the provider side, and a comprehensive documentation with an order form on the Marketplace side. A provider may host multiple producers, each contributing to its catalog. Depending on the provider, producers may be organized as dedicated Product Owner (PO) and developer teams, or as integrated teams jointly managing product portfolios.

**Cloud and enterprise products** refer to everything available on the Marketplace. The term “product” is used broadly to encompass all workflows, services, and offerings, including cloud services such as Infrastructure, Platform and Software as a Service (IaaS, PaaS, SaaS), enterprise workflows and services (such as training, consulting, badge requests, workstation requests), desktop applications, and many more. The catalog is continually expanding, with plans to include licenses and data in the future (like [8]).

To address the complexity of managing products across multiple cloud providers, BNP Paribas developed the Marketplace: a Cloud Service Broker (CSB) that acts as a unified web entry point for product exposure and consumption (see Figure 1). The platform's no-code interface empowers producers to publish a wide range of

offerings, including both orderable and informational display-only products, see Section 5 for details. Security and compliance are ensured through a dedicated governance model, which requires all products to undergo architecture and security reviews before publication. This process balances producer autonomy with organizational trust and compliance, further details are provided in section 4.

The design and architecture of the Marketplace have been guided by three foundational research questions, which influenced its functional and governance model:

**RQ1:** *How to ensure quality and security of exposed products in a regulated environment?* A robust governance framework is required to guarantee that all exposed products meet stringent standards for security, reliability, and compliance.

**RQ2:** *How to ensure scalability of the catalog?* Producers must be empowered to publish, maintain, and grow their products independently. This autonomy is essential to support a scalable and diverse product catalog.

**RQ3:** *What strategies can drive widespread user adoption across a large organization?* The benefits of a unified and centralized access point materialize only when it is embraced by all users, making it a central concern.

While these Research Questions were initially formulated to guide the architecture and governance of the Marketplace, we retrospectively evaluate their fulfillment and provide correlations with our solutions using a combination of qualitative feedback and quantitative metrics. For **RQ1**, we examine governance outcomes such as product taxonomy and average Customer Satisfaction Score (CSAT). For **RQ2**, we analyze the growth in autonomously published products and the time-to-market across different integration profiles. For **RQ3**, we assess user adoption through order volumes, user counts, average Customer Effort Score (CES) and the number of orders available on the Marketplace. These metrics provide empirical grounding for the architectural choices made and help validate the system's effectiveness in meeting its core objectives.

## 1.2 Contributions

This paper makes the following contributions:

1. The description of the architectural design of an Enterprise Marketplace allowing deep integration and rich interactions with cloud and enterprise providers (section 3).

2. A governance model to provide security and quality at scale (section 4).

3. A scalable and flexible no-code exposition service to ensure producer autonomy (section 5).

4. Techniques for enterprise-wide adoption (section 6).

The remainder of this paper is organized as follows: Section 2 reviews related work on service brokerage, governance, and low-code platforms. Section 3 describes the Marketplace's design and architecture. Section 4 covers governance and security mechanisms. Section 5 details the no-code publishing service for producers. Section 6 presents user adoption metrics. Section 7 discusses lessons learned and ongoing challenges, and Section 8 outlines future directions, including formal methods for error handling and observability.
## 2 RELATED WORK

**Cloud Service Brokerage and Marketplaces** CSBs aggregate and intermediate services between providers and consumers [12, 21]. Surveys classify approaches into middleware, semantic frameworks, and market-based models [9]. B2B marketplaces (e.g., Salesforce AppExchange, RapidAPI) emphasize ease of integration and manageability [24], while economic models optimize pricing [5]. However, these works focus on cloud-only services and rarely address enterprise workflows or regulated environments. Our Marketplace generalizes brokering to cloud and enterprise products, offering deep integration (status, entitlements) beyond catalog federation. Unlike OSBAPI [23], which redirects users to provider dashboards, our provider-abstraction API enables in-place lifecycle management.

**Governance and Compliance** Governance is recognized as critical for CSBs [9], and recent work explores policy-driven customization [10]. Yet, prior models lack multi-layered governance spanning provider, producer, and platform roles. Our approach enforces this structure while integrating entitlement management and quality reviews, balancing autonomy with compliance in a financial context.

**Low-Code/No-Code (LC/NC) Publishing** Low-code platforms accelerate application development [20], but prior work does not address governed product publishing in marketplaces. Our no-code service combines form-based configuration, dynamic inputs, and taxonomy-driven templates to ensure quality and autonomy, capabilities absent from existing LC/NC or marketplace studies.

**Developer Experience and Lead Time** Empirical studies link orchestration complexity and portal design to longer lead times [18]. Broader research highlights organizational enablers for fast flow [26, 27] and warns against tool sprawl [31]. Our findings align: provider abstraction and no-code publishing reduce time-to-market, while reconciliation mechanisms mitigate fragmentation.

Existing work addresses CSBs, governance, and LC/NC tooling but leaves gaps in (i) unified marketplaces spanning cloud and enterprise products, (ii) multi-layered governance in regulated settings, and (iii) no-code publishing with quality enforcement. Our Marketplace addresses these gaps with a decade of production evidence.

## 3 SYSTEM ARCHITECTURE

This section presents the high-level architecture of the Marketplace system, outlining its core components, their responsibilities, and the interactions that enable the platform's functionality. The goal is to provide a structural foundation for understanding how the system supports its intended use cases and operational requirements. Design decisions and their alignment with specific requirements are discussed in subsequent sections. We provide a public artifact including the generic API schema and product page examples in [4].

### 3.1 From single-cloud portal to Enterprise Marketplace

To tackle the issue of fragmentation, we developed a platform aimed at streamlining the customer experience across both cloud and enterprise products. The Marketplace was originally launched as a standalone portal (represented as Frontend 3 in Figure 2). From the

beginning, this is not a cloud: the portal was intended to provide more than just cloud products. Over time, it gradually evolved into a marketplace capable of aggregating, arbitrating, and intermediating with multiple portal APIs (see Figure 3). While AWS Service Catalog allows internal teams to deploy curated AWS resources through self-service, our Marketplace builds on this idea with a flexible, extensible architecture powered by a standardized API layer inspired by the Open Service Broker API (OSBAPI) [23]. This enables integration of both cloud and enterprise products from multiple providers, all managed through a single, unified interface. In this way, the platform acts as an Enterprise Marketplace, extending beyond the traditional role of a Cloud Service Broker. The no-code platform, which is also directly accessible through the Marketplace, enhances the product exposure capabilities beyond those of traditional marketplaces like AWS Service Catalog. This autonomy is possible because, unlike OSBAPI, our standardized API is a provider abstraction, not a product abstraction. It allows users to create customizable forms for parameterizing orders, called order forms, and to build rich documentation pages for customers that include embedded media, dynamic content retrieved via API calls, and even OpenAPI-based definitions for SaaS products.

<figure><img src="image_5.png" /><figcaption>Figure 3: Marketplace architecture</figcaption></figure>

We also introduced multiple reconciliation mechanisms: automated scripts, webhooks for providers and an Enterprise Service Bus that logs API events. This means that even if a user places an order or makes changes through another portal (web-based or API-based), those actions will be reflected when they return to the Marketplace. The next sections outline the architecture that enables this transformation.

### 3.2 Marketplace Frontend

The Marketplace is a web-based Single Page Application (SPA) designed for a responsive and interactive experience. It features two main interfaces: one for consumers to access products, and another for producers to publish and manage their offerings.
The consumer interface provides access to a catalog, displaying products available to the user based on Entity and access rights. It also includes entitlement pages, where users can update their entitlements, which will be synchronized with the corresponding providers, and detailed order management capabilities, allowing users to track, review, and interact with their orders.

The producer interface serves as the operational portal for producers. It enables product owners to configure and manage their offerings, access usage insights, such as a dedicated space for consumption analytics, and customer interactions (e.g. displaying news banners) across their product portfolio.

## 3.3 Backend service

At the core of the Marketplace architecture is a backend system that functions both as a proxy and a gateway to provider services. It maintains an internal database to track all products, regardless of their publication state, as well as all orders, including those submitted outside the platform, from registered providers. Central to this design is a standardized API layer, implemented using the Adapter and Facade design patterns [11], which generalises interactions with portal APIs. This standardized API has more features than OSBAPI, allowing to view products informations and managing entitlements directly on the Marketplace. Unlike OSBAPI, which does not expose detailed instance information and typically redirects users to the provider's dashboard via a URL, our API supports direct integration of product instance data. This includes displaying status information and visual workflows, enabling users to better understand the current stage of service provisioning within the Marketplace interface. This eliminates the need, in many cases, to switch to external provider portals and preserves the Marketplace's role as a unified control point for product consumption. For each provider, this API must be implemented in accordance with the provider's specific choreography, including authentication, authorization, and external API call sequences. While implementation of the API is mandatory to expose a catalog of products on the Marketplace, not all features are required to be supported. The system tracks unsupported capabilities per provider and disables them dynamically at both the backend and frontend levels to ensure a consistent and reliable user experience. This abstraction evolves over time to accommodate new provider requirements and feature enhancements. These evolutions are either defined by the Marketplace team for new features or come from provider feedbacks to better integrate their products.

This design enables the Marketplace to forward product orders to the appropriate provider while accommodating variations in authentication mechanisms, API structures, and provisioning workflows. By decoupling product exposition from underlying provider implementations, the architecture achieves extensibility and maintainability, supporting a growing ecosystem of providers. Over time, this approach has facilitated the integration of numerous providers, demonstrating its scalability and adaptability. To this day, the Marketplace interacts with 12 different providers.

## 3.4 Identity and Access Management

Identity and Access Management (IAM) is facilitated by a dedicated IAM service that integrates with BNP Paribas's internal Identity

Provider (IdP). This configuration ensures that authentication is managed directly within the Marketplace infrastructure, preserving operational autonomy from external teams. For authentication and authorization with external providers, the system supports multiple strategies. These models are validated during provider onboarding detailed in Section 4.

A critical aspect of IAM is the integration of the provider's native security model, comprising users, roles, groups, and access policies, into the Marketplace. While replicating security checks across systems is uncommon, it is essential in our case to ensure a seamless user experience. By mirroring the provider's authorization logic within the Marketplace, we enable immediate feedback on access errors directly in the frontend. This is particularly valuable in multi-provider environments, where backend validation delays can degrade responsiveness and usability.

## 3.5 Enterprise Service Bus

To support interoperability with external ordering systems, providers are encouraged to log events to an ESB that the Marketplace monitors to ingest new orders and user-driven modifications from other portals. Scripts and webhooks are also available to accommodate differences in provider implementations. This design allows users to continue interacting with their preferred interface while gradually transitioning to the Marketplace.

## 3.6 Performance

With the architecture and interoperability mechanisms in place, assessing the operational performance of the Marketplace becomes crucial. The platform is actively developed and maintained by a core team of 8–12 developers and 4 site reliability engineers (SREs), with over 50 developers having contributed throughout its history. Today, the project brings together approximately 70 people across all teams and serves the entire organization (around 15 entities). This operational strength has been key to maintaining high availability, enabling rapid onboarding of new products, and providing responsive support to a diverse user base, as seen in Table 1.

<table><caption>Table 1: Observed Service Metrics for the Marketplace</caption><thead><tr><td>Metric</td><td>Value</td></tr></thead><tbody><tr><td>Availability Service Level Indicator (SLI)</td><td>99.76%</td></tr><tr><td>Uptime SLI</td><td>99.89%</td></tr><tr><td>Mean Time to Recovery (MTTR)</td><td>2h15</td></tr><tr><td>Order Processing Time</td><td>p50: 2.1s, p90: 4.2s</td></tr><tr><td>Entitlement Synchronization Time</td><td>p50: 1s, p90: 10s</td></tr></tbody></table>

The observed availability and uptime are consistent with enterprise standards for internal platforms, indicating that the system remains accessible and functional for collaborators even in a complex, multi-provider environment. Order processing and entitlement synchronization are generally fast, with only occasional delays in the slowest cases, which is an expected outcome given the system's integration with external dependencies and legacy systems. The MTTR is well below the 4-hour objective, reflecting effective incident management. Overall, these results confirm that the platform meets operational expectations for large-scale enterprise applications.
## 3.7 Validating architecture choices

Although architectural metrics are addressed in later sections, it is important to highlight a foundational strength of our design: new platforms developed to expose products at BNP Paribas are not required to implement their own frontend applications. Instead, the Marketplace interface serves as a unified frontend, which simplifies integration and significantly reduces the development workload.

This architectural choice was tested during the onboarding of a new provider, where we introduced and validated the concept of a headless provider: one that exposes its product catalog exclusively through an API. The integration was completed successfully without the need for a custom user interface. As a result, teams aiming to expose products to all BNP Paribas collaborators (see details in section 6) now only need to manage the API layer, without concern for frontend implementation. With the architecture now established, we turn to the core features expected from a traditional CSB. These include [12, 21]:

**Arbitration**, enabled through a governance model that ensures service quality and security for users.

**Aggregation**, facilitated by the no-code platform, which empowers producers to create rich, high-quality service presentations.

**Intermediation**, which supports Single Sign-On (SSO), allows producers to monitor usage and collect feedback, and enables customer care teams to assist users effectively.

<figure><img src="image_6.png" /><figcaption>Figure 4: Marketplace workflow</figcaption></figure>

In our case, we use the same definition, but for the broader term of product instead of only service. The following sections detail how the architecture fulfills requirements RQ1-RQ3 through its core features. These are presented in the order they occur during integration: provider onboarding, autonomous product exposition, and user consumption. The user workflow and involved parties are illustrated in Figure 4.

# 4 GOVERNANCE MODEL: BALANCING AUTONOMY AND SECURITY

The first step toward enabling product consumption on the Marketplace is the integration of a new provider. This integration process spans both technical and managerial domains and is tightly coupled with IT governance requirements. Indeed, as a financial institution, BNP Paribas is subject to stringent regulatory requirements, thus, to meet these obligations, the Marketplace administers a multi-layered governance model. This includes the establishment of a dedicated governance committee responsible for reviewing products against regulatory, architectural, and operational standards.

Providers that are integrated into the Marketplace are supposed to have done this validation process with IT governance, ensuring that the catalog remains secure, compliant, and trustworthy. For financial and invoicing aspects, the Marketplace is tasked to send the mandatory consumption data to the provider, which will use it to create invoices for the customer entity who consumed the product.

In the context of cloud service brokers, arbitrage is defined as "the flexibility to choose services from multiple agencies" [21]. Unlike aggregation, which implies a fixed set of services, arbitrage allows dynamic selection based on metrics such as quality, cost, compliance, and operational fit. This governance process allows to dynamically select products that are high quality and secure.

## 4.1 Provider Governance

Each provider in the Marketplace is validated by a provider governance committee to ensure regulatory, operational, and security compliance. These constraints vary significantly across providers: some enforce strict data residency policies or require enhanced encryption standards.

In addition, the Marketplace integrates entitlement management directly into its application. For each IT application a user is part of, they can manage roles and user memberships from the application entitlement page, regardless of the underlying provider. This abstraction simplifies cross-provider security administration by consolidating access control into a single interface. The Marketplace is responsible for propagating these updates to the respective providers, ensuring synchronization and reconciliation of entitlements across systems. This design not only improves usability but also reduces latency in access validation, which is particularly beneficial in multi-provider environments where backend authorization checks can be slow.

During provider onboarding, the authentication and authorization strategies must be integrated to allow interactions with its APIs. These strategies are reviewed and validated by governance committees during integration to ensure compliance with internal security policies and regulatory requirements. This flexibility allows the Marketplace to accommodate heterogeneous provider ecosystems while maintaining a consistent and secure user experience.

## 4.2 Producer governance

The producer, responsible for developing new products via IaC templates on a chosen provider and exposing them on the Marketplace, is accountable for their quality. This includes ensuring a low provisioning failure rate, reflecting the robustness of the templates, an operational order form and order page with comprehensible documentation, and effective communication with consumers regarding updates, maintenance, and other relevant changes to prevent unexpected disruptions.

To ensure autonomy for providers and producers, governance responsibilities are primarily delegated to them for implementation and oversight. However, the Marketplace maintains its own overarching governance framework, which serves as a final checkpoint to verify customer satisfaction and monitor the effectiveness of the decentralized governance structures.
To support producers in delivering high-quality offerings, particularly for complex products, a dedicated Customer Success Management (CSM) team has been established. This team is responsible for mentoring producers, when needed, through their journeys on the platform, providing constructive feedback on product and order display in a way that enhances consumer comprehension. But also for introducing and onboarding new Marketplace features and services that could facilitate the producer experience on all levels. Dually, the producer can provide feedback, which can lead to new features on the Marketplace.

<figure><img src="image_7.png" /><figcaption>Figure 5: Distribution of rounded average CSAT scores across rated products and orders visible on the Marketplace.</figcaption></figure>

## 4.3 Marketplace Governance

Beyond provider-level validation, the Marketplace enforces its own governance layer. Only products approved by the provider are made available, and the Marketplace retains the authority, in extreme cases only, to disable ordering for products that fail to meet platform-wide quality standards. These standards include comprehensive documentation and Service Level Agreement (SLA) for their ordering workflows and products.

To uphold these standards, the Marketplace conducts regular quality reviews. These reviews incorporate consumer feedback, displayed via a 5-star rating system on each product (see Figure 5), and lifecycle metrics such as deployment success rates. This dual approach ensures that the Marketplace remains both secure and responsive to user experience.

If a product fails to meet the Marketplace's quality standards during periodic reviews, it may become temporarily unavailable for ordering. In this extreme case, while still visible in the catalog, the ordering functionality is disabled until the issues are resolved. This mechanism reflects the dynamic nature of arbitrage within the Marketplace. Assessing product quality and security in a regulated environment is inherently complex, human oversight plays a critical role. The Marketplace actively curate which products are exposed, ensuring that only those meeting compliance and operational thresholds remain orderable. Arbitrage, in this context, is not just about offering choice, it's about enabling informed, secure selection through continuous validation.

To further support informed decision-making, the Marketplace assigns quality labels to products that demonstrate exceptional

standards. These labels serve as visual indicators of trust and performance. Some are awarded based on the quality of product exposition and positive customer feedback, while others reflect stricter security and architectural validations conducted by governance committees at the BNP Paribas level. By surfacing these distinctions directly in the catalog, the Marketplace helps consumers navigate a diverse product landscape and confidently select offerings that align with their needs and compliance expectations.

## 4.4 Automating quality through product taxonomy

An illustrative example of Marketplace governance driving product quality improvement is the introduction of a product taxonomy. Early observations revealed that product descriptions and documentation often lacked critical information (such as whether a cloud product offered high availability) leading to confusion and unmet expectations among users.

<figure><img src="image_8.png" /><figcaption>Figure 6: Number of products by types (left) and categories (top) as of July 2025.</figcaption></figure>

To address this, the Marketplace team conducted a comprehensive review of the catalog and developed a taxonomy of products through types and categories (the repartition of online products can be seen in Figure 6). The product types were then linked to a structured set of mandatory and complementary fields required in product descriptions. As a result, when a producer creates a product using the no-code platform, they must select a template aligned with the product type. These templates enforce the inclusion of mandatory fields while allowing flexibility for complementary ones, thereby raising the baseline quality of all published products.

Following the implementation of this taxonomy-driven approach, most products now consistently include well-defined mandatory fields. Although complementary fields are less frequently populated, the overall effect has been a significant improvement in the completeness and reliability of essential product information.

## 4.5 Product Quality and User Satisfaction

To validate RQ1, we analyze both the distribution of CSAT [15] and the volume of orders placed shown in Figure 5.
In our case, we consider all orders available on the Marketplace, not just those placed through it, to account for heterogeneous user behaviors, such as automated API-based ordering and platform-based product rating. The figure shows that over 80% of products are rated around 4 or 5 stars, and these highly rated products also represent more than 80% of available orders. The data indicates that the Marketplace is effective in surfacing high-rated products, and that users tend to favor them, thus validating **RQ1**. However, the inversion between the number of products rated and ordered at 4 and 5 stars suggests that the correlation is not perfect: external factors like mandatory products (e.g., mailboxes) may influence ordering patterns. Introducing taxonomy-driven mandatory fields significantly improved user satisfaction and operational reliability, as evidenced by a 15% CSAT increase for newly created products and a 7% delivery success gain among the most active providers (due to limited pre-change data for other providers). This improvement may be attributed to API-required fields now being enforced in the order form, indicating promising outcomes.

At the conclusion of the provider integration and governance validation process, producers can begin building and exposing new products on the approved provider. To support this, the Marketplace offers a dedicated no-code environment that enables teams to configure, customize, and publish their offerings autonomously, while remaining within the boundaries of the validated infrastructure.

# 5 NO-CODE PRODUCT PUBLISHING

Once a provider has been approved and integrated into the Marketplace, producers can begin building and exposing products hosted on that provider. While the integration process is managed collaboratively between the Marketplace and provider teams, the responsibility for developing and configuring individual products shifts to the producers themselves. Governance committees continue to validate products before publication, but the design, implementation, and exposition of those products are fully owned by the teams, marking a transition from centralized onboarding to decentralized product creation and publication.

To support this autonomy, the Marketplace offers a no-code environment that enables POs to publish products without deep technical expertise. Once approved, POs use the no-code environment to configure and publish their offerings: defining documentation with embedded media and order forms (see Figure 4), inputs and their types, and customizing product pages. This workflow supports what NIST defines as aggregation [21].

## 5.1 Dual Interaction modes

The no-code environment supports two modes of interaction: a form-based configuration system for defining inputs and validation rules, and a full UI builder for advanced customization. This flexibility stands in contrast to fixed-parameter models like OSBAPI [23], which simplify integration but limit expressiveness and validation control. By offering a richer interface, the Marketplace ensures that products are not only compliant, but also discoverable, usable, and tailored to enterprise needs.

**Form-based configuration** POs define input fields, data types, and validation rules that bind to the product order request. Dynamic data retrieval via API calls is supported, enabling features such as

auto-populated lists. The Marketplace provides a library of reusable input components, similar to form builders like Google Forms [13], enriched with frontend and backend validation mechanisms. POs can also embed media—such as videos, images, and OpenAPI documentation, to enhance product discoverability and usability. This documentation is surfaced on the product page, offering users a comprehensive view of product configurations, architecture, usage guidelines, and contact information.

**Full UI builder** For advanced customization, POs can design bespoke user interfaces using a no-code platform akin to WordPress. This approach enables more sophisticated interactions and flexible layouts, while adhering to Marketplace design guidelines to ensure a consistent user experience.

Once a product is configured and marked as visible, it becomes available in the Marketplace catalog and can be ordered by authorized consumers. This workflow has enabled the deployment of numerous products, demonstrating the effectiveness of the no-code publishing model in supporting both cloud and enterprise product domains, as can be seen in Figure 7.

## 5.2 Marketplace catalog growth

We categorize products into three integration modes based on their integration with the Marketplace: fully-integrated products, which can be both ordered and managed entirely within the Marketplace; orderable products, which are available for ordering but require external portals for management; and display-only products, which cannot be ordered by nature or serve informational purposes. These are used to showcase interest, provide documentation and contacts, redirect to external systems, or are indicators of deprecated offerings, often reflecting feedback from users or outcomes of internal quality reviews.

<figure><img src="image_9.png" /><figcaption>**Figure 7:** Growth in fully integrated, orderable, and display-only products.</figcaption></figure>

The Marketplace now features over 1,000 products, including about 700 orderable and 300 display-only entries (see Figure 7). In the past two years, the catalog has more than doubled, with fully integrated products growing fastest. This suggests that the governance framework supports, rather than limits, catalog expansion. The no-code publishing platform appears to enhance producer autonomy and reduce friction, though the number of integrated providers may also affect these figures. Further analysis is needed
to fully understand the impact of no-code publishing on catalog growth and governance.

Based on extensive collaboration with producers integrating their products into the Marketplace, the customer success team has identified three typical integration profiles:

*Manual integration by first-time teams:* Teams unfamiliar with the Marketplace often require between one to two weeks to onboard a new product, depending on its complexity.

*Manual integration by experienced teams:* Teams with prior experience typically complete new integrations within one to two days, even for fully integrated offerings.

*Automated integration by experienced teams:* Some teams have developed internal pipelines that automatically update product metadata and configuration upon creation or modification. These teams can expose new products with no manual delay. This shows cases that the time-to-market for product exposition is fast and takes at most 5% of the average total development time observed in a similar company [18] for first-time teams, while being negligible in other cases.

## 5.3 Supporting Heterogeneous Products

To further demonstrate the adaptability of our approach, the Marketplace supports a wide range of product types beyond traditional cloud offerings. Leveraging the product taxonomy introduced in our governance framework, producers have successfully onboarded products such as badge requests, LLM as a Service (LLMaaS) tools, desktop applications, and even physical equipment. This diversity is made possible by the standardized API layer, which generalizes product lifecycle operations, such as ordering, status tracking, updates, and completion, across heterogeneous providers. For example, BNP Paribas's internal Configuration Management Database (CMDB) [25], used for incident management and badge access, is modeled as a provider. This heterogeneity is reflected in the distribution of products across categories, as shown in Figure 6, and underscores the flexibility of the no-code publishing model in supporting both cloud and enterprise products. Table 2 summarizes the differences between our Marketplace and other solutions.

<table><caption>Table 2: Feature comparison summary</caption><thead><tr><th>Aspect</th><th>AWS Service Catalog</th><th>OSBAPI</th><th>Marketplace</th></tr></thead><tbody><tr><td>Multi-cloud<br>Publishing</td><td>AWS only<br>Manual/auto via CLI</td><td>Yes<br>Auto after definition</td><td>Yes<br>Manual via no-code/auto</td></tr><tr><td>Documentation</td><td>Basic metadata + redirection</td><td>Basic metadata + redirection</td><td>Structured, enforced, integrated</td></tr><tr><td>Product type</td><td>IaaS/PaaS/SaaS</td><td>Automated, API-driven</td><td>Any orderable</td></tr><tr><td>Integration</td><td>Orderable + redirection</td><td>Orderable + redirection</td><td>Fully-integrated, orderable and display-only</td></tr><tr><td>Target Catalog Users</td><td>DevOps/Dev</td><td>DevOps/Dev</td><td>All collaborators</td></tr></tbody></table>

RQ2 focuses on the scalability of the catalog. This is achieved by allowing producers to control their product templates on the provider side and manage their product exposure on the Marketplace side, without requiring external intervention and by allowing heterogeneous products. The growing number of available products, along with the increasing number of products published on the

platform and the low time-to-market for exposing new products validates this research question.

With products now available to consumers, the Marketplace shifts its focus to ensuring a seamless experience, from ordering and provisioning to ongoing management and updates, solidifying its role as the unified entry point for cloud and enterprise product consumption.

# 6 MARKETPLACE ADOPTION AND USAGE

Now that the Marketplace aggregates multiple trusted providers and high-quality products, it must deliver a great experience that positions it as the unified central pane for web-based product discovery and consumption. This exemplifies service intermediation: enhancing a given service by improving some specific capability and providing value-added products to cloud consumers [21]. We present techniques we used to achieve widespread adoption.

## 6.1 Customer care

Abstracting over multiple providers offers significant value but introduces complexity, particularly in error handling. While our standardized API enables integration across a diverse range of providers, it also obscures the underlying orchestration logic. In a multi-provider environment, diagnosing errors becomes challenging, as each provider implements distinct workflows, dependencies, and failure modes.

In alignment with our governance model, each provider maintains a dedicated support team responsible for resolving issues specific to its products. However, from the user's perspective, errors appear to originate from the unified Marketplace interface, where provider boundaries are intentionally abstracted. To address this disconnect, our platform includes a centralized customer support function that serves as the primary point of contact for users. This team handles Marketplace-related issues directly and coordinates with provider-specific support teams when necessary.

By unifying not only product access but also support channels, the platform ensures a consistent and efficient error resolution process. Users benefit from a single entry point for inquiries, issue reporting and feedbacks, reinforcing the platform's role as a comprehensive intermediary across cloud and enterprise products, as well as engaging users to contribute to the Marketplace's improvements.

## 6.2 Adoption of the Marketplace

Before discussing organization-wide adoption, it is important to note that the Marketplace team validated the platform by using it themselves: a practice known as “dogfooding” [14]. The team initially deployed the Marketplace on bare-metal servers and, as usage increased, migrated to more robust infrastructure provisioned through the platform. This approach provided early, practical feedback and ensured reliability prior to broader rollout.

Initially designed for cloud products, the Marketplace has evolved into a central platform for a wide range of products, now serving over 200,000 collaborators. Its adoption is reflected in the continuous growth of visits, users, and order volumes (Figures 8 and 9). Centralizing essential products, such as password management, has made usage universal and helped democratize access to innovation (see 7.2).
<figure><img src="image_10.png" /><figcaption>**Figure 8: Number of monthly visits and users.**</figcaption></figure>

Figure 9 shows the steady increase in order volumes across multiple channels, essential for adoption (seen in 3.5). All these orders, made on the Marketplace or not, are visible and manageable on the Marketplace. In total, more than 1,250,000 orders have been available on the Marketplace, with more than 485,000 still active.

<figure><img src="image_11.png" /><figcaption>**Figure 9: Visualization of order volumes.**</figcaption></figure>

Ease of use is also shown by the CES [7] distribution (Figure 10), with most products rated 4 or 5 stars and accounted for nearly 100% of orders available. While only a correlation, this suggests the value of a unified consumption platform: by standardizing product access, the Marketplace consistently delivers high-quality user experiences.

<figure><img src="image_12.png" /><figcaption>**Figure 10: Distribution of products by CES average**</figcaption></figure>

These metrics indicate the Marketplace's broad adoption and effectiveness in integrating essential products and reconciling diverse order sources, thus validating RQ3, though further analysis is needed to assess the impact of these techniques. We now turn to the key lessons learned and challenges encountered throughout its deployment and scaling.

# 7 LESSONS LEARNED AND REMAINING CHALLENGES

After nearly a decade in production, the Marketplace has become a cornerstone of BNP Paribas's internal digital ecosystem. It is now the second most visited web platform within the organization, just behind Echonet (BNP Paribas's internal social and collaboration network used for sharing news and updates).

With over 1,000 products available and nearly 15,000 orders placed each month, the Marketplace has demonstrated its scalability, resilience, and relevance across a wide range of use cases. Its sustained adoption over time reflects not only technical robustness but also the value it delivers to both consumers and producers within the bank. This section distills the key insights gained from operating the Marketplace at scale in a regulated, multi-provider environment.

## 7.1 Adoption is the Greatest Challenge

While the idea of a unified, web-based entry point for product exposition and consumption is compelling in theory, realizing it within a large organization has required a significant effort. Bringing together providers, producers, and consumers on a single platform has been a true *tour de force*, driven by a dedicated Marketplace team.

Adoption efforts have involved extensive outreach: presentations, demos, and continuous communication to articulate the platform's value. A pivotal moment came with the integration of the password change application, a mandatory tool for all BNP Paribas collaborators. Its onboarding into the Marketplace (see Figure 8) effectively made the platform a necessity for every employee.

Despite this success, adoption remains an ongoing effort. New providers continue to emerge, especially in areas like AI, and often seek to build their own ordering portals. The Marketplace must therefore remain proactive, continuously demonstrating its broader reach and long-term value. We cannot rest on our laurels: sustained engagement and adaptability are key to maintaining momentum and expanding platform usage.

While adoption is a continuous journey, it is deeply intertwined with the platform's ability to scale technically and accommodate diverse product models, a lesson learned we explore next.

## 7.2 A Unified Platform Introduces Complexity but Foster Innovation

Behind the seamless user experience lies a complex architecture that must reconcile diverse product models, legacy systems, and evolving provider needs.

Technically, consolidating multiple portals into a single interface requires careful abstraction. Without thoughtful design, the API can become fragmented, offering provider-specific methods that undermine consistency and usability. Achieving true standardization demands ongoing collaboration with providers and a commitment to iterative feedback and refinement.

Humanly, the challenge lies in aligning diverse teams with varying expectations, workflows, and legacy systems. Encouraging adoption, fostering trust, and ensuring that producers feel empowered, not constrained, requires continuous engagement and support.
Building a unified platform is not just an engineering effort: it's an organizational transformation. Success depends on balancing technical rigor with empathetic change management, ensuring that simplicity for users does not come at the cost of complexity for producers.

Conversely, an Enterprise Marketplace accessible to all collaborators fosters widespread innovation. This was especially clear with AI, as the platform enabled teams across the organization to quickly publish and share new AI-driven tools, such as LLM-based products.

## 7.3 Challenge: Standardized Error Handling

Although inputs can frequently be generalizable across providers due to the similar abstractions presented by their APIs, this equivalence does not extend to error handling. Due to provider-specific orchestration logic, error models and messages vary significantly, resulting in challenges for consistent cross-provider error handling. The Marketplace platform cannot easily pinpoint provider-specific failures. Generic errors cause users to blame the platform and reduce trust. Logging is siloed by provider, making unified monitoring and cross-provider correlation difficult. As a result, error attribution and diagnosis are challenging, even if input schemas can be standardized. To address concerns regarding end-user perception, the Marketplace team established a centralized customer care team that works with provider-specific support units. While this approach streamlines coordination, diagnosing issues across varied and evolving provider ecosystems continues to present significant complexity.

For example, we occasionally encounter a rare issue where a service provider times out during the ordering process. While this may appear straightforward, a timeout does not clearly indicate whether the user's request has been successfully fulfilled (and will be billed) or not. To address this ambiguity, we employ a reconciliation mechanism to verify the status of such orders. However, in certain cases, reconciliation cannot be fully automated, resulting in inconsistent states in the user interface: one order remains in a pending state while another appears as completed. That's where the customer care team and collaboration with providers to improve the process are essentials.

The challenges associated with error handling and diagnosis underscore the importance of implementing robust, transparent, and standardized mechanisms. To this end, our future work will examine how formal methods can facilitate problem resolution and enhance platform reliability.

# 8 FUTURE WORK: LEVERAGING FORMAL METHODS

In our future work, to improve observability and error resolution in multi-provider environments, we propose the use of formal methods [29] to rigorously model and verify interactions within the Marketplace. Formal methods offer a principled approach to specifying and analyzing system behavior, enabling proactive detection of inconsistencies, improved traceability, and stronger guarantees of correctness across distributed components. Lightweight formal methods have been successfully used in large organizations [19, 22].

Our goal is to apply these techniques to the orchestration logic embedded in the Marketplace, particularly in the way services interact through the standardized API. By formalizing these workflows, we aim to support automated reasoning about communication patterns, integration boundaries, and failure scenarios, even in heterogeneous and partially observable environments.

As a concrete instantiation of this direction, we plan to explore Multiparty Session Types (MPST) [16]. MPST provide a type-theoretic framework for specifying structured communication protocols, allowing verification of properties such as communication safety, deadlock freedom, and liveness. We intend to infer local types from Marketplace components and synthesize them into global types [6], enabling automated protocol validation and enhancing support transparency.

This approach complements the Marketplace's capability-based architecture and aligns with ongoing research on extending MPST to handle failures [3], timeouts [17], and stateful behavior [30, 32] in real-world web applications.

While [28] demonstrate the potential of AI-driven techniques for automating log analysis and error diagnosis, future research could investigate how integrating formal methods with AI can further automate error diagnosis and resolution across heterogeneous providers, enhancing observability and support transparency in multi-provider settings.

Finally, we plan to conduct deeper analyses to better understand the causal impact of specific interventions on delivery and user adoption.

# 9 CONCLUSION

This paper presented the design and deployment of an Enterprise Marketplace that transforms fragmented cloud usage into a unified, governed, and scalable product ecosystem within a large-scale banking infrastructure. The Marketplace integrates cloud and enterprise products via a no-code interface and standardized API, enabling autonomous publishing and robust governance. Metrics confirm its effectiveness in quality, autonomy, and user experience. The Marketplace now serves as a central entry point for over 1,000 products, with rapid expansion driven by scalable governance and producer empowerment.

Looking ahead, we propose the use of MPST to formalize provider interactions and improve observability in multi-provider environments. By enabling automated inference and verification of communication protocols, MPST offer a promising path toward enhancing runtime reliability and support transparency—bridging formal methods with practical enterprise needs.

# ACKNOWLEDGMENTS

We thank all teams whose expertise made the Marketplace possible, especially development, UX, data, CSM, and Customer Care. We appreciate the contributions and guidance of Christophe Boulangé's cloud teams, the production teams, and reviewers Sarah Antunes, Salomé Grillé, and Romain Soufflet. Special thanks to Laurent Philippart for insightful discussions, Loïc Bourhis for the workflow diagram, Solveig Bachellery for leading the AI research team and driving forward innovations, and Emmanuel Salzard, whose insight and leadership laid the project's foundation.
REFERENCES

[1] Amazon Web Services. 2025. AWS CloudFormation. https://aws.amazon.com/cloudformation/. Accessed: 2025-09-18.

[2] Amazon Web Services. 2025. AWS Service Catalog. https://aws.amazon.com/servicecatalog/. Accessed: 2025-09-18.

[3] Adam D. Barwell, Ping Hou, Nobuko Yoshida, and Fangyi Zhou. 2025. Crash-Stop Failures in Asynchronous Multiparty Session Types. *Logical Methods in Computer Science* Volume 21, Issue 2 (April 2025), 1262. https://doi.org/10.46298/lmcs-21(2:5)2025

[4] Richard Casetta, Thomas Brisbout, Jean-François Tur, and Julien Veybel. 2026. Enterprise Marketplace Artifact. https://gitlab.inria.fr/tyrex-public/enterprise-marketplace. Accessed 2026-01-05.

[5] Georgios Chatzithanasis, Evangelia Filiopoulou, Christos Michalakis, and Mara Nikolaïdou. 2022. A Brokering Model for the Cloud Market. In *Cloud Computing – CLOUD 2021*, Kejiang Ye and Liang-Jie Zhang (Eds.). Springer International Publishing, Cham, 1–16.

[6] Pierre-Malo Deniélou and Nobuko Yoshida. 2013. Multiparty Compatibility in Communicating Automata: Characterisation and Synthesis of Global Session Types. In *Automata, Languages, and Programming*, David Hutchison, Takeo Kanade, Josef Kittler, Jon M. Kleinberg, Friedemann Mattern, John C. Mitchell, Moni Naor, Oscar Nierstrasz, C. Pandu Rangan, Bernhard Steffen, Madhu Sudan, Demetri Terzopoulos, Doug Tygar, Moshe Y. Vardi, Gerhard Weikum, Fedor V. Fomin, Rüsinš Freivalds, Marta Kwiatkowska, and David Peleg (Eds.). Vol. 7966. Springer Berlin Heidelberg, Berlin, Heidelberg, 174–186. https://doi.org/10.1007/978-3-642-39212-2_18

[7] Matthew Dixon, Karen Freeman, Nicholas Toman, et al. 2010. Stop trying to delight your customers. *Harvard business review* 88, 7/8 (2010), 116–122.

[8] Rebecca Eichler, Christoph Gröger, Eva Hoos, Christoph Stach, Holger Schwarz, and Bernhard Mitschang. 2023. Introducing the enterprise data marketplace: a platform for democratizing company data. *J. Big Data* 10, 1 (2023), 173. https://doi.org/10.1186/S40537-023-00843-Z

[9] Abdessalam Elhabbash, Faiza Samreen, James Hadley, and Yehia Elkhatib. 2019. Cloud Brokerage: A Systematic Survey. *ACM Comput. Surv.* 51, 6, Article 119 (2019), 28 pages. https://doi.org/10.1145/3274657

[10] Evangelia Filiopoulou, Georgios Chatzithanasis, Christos Michalakis, and Mara Nikolaïdou. 2024. Cloud Broker: Customizing Services for Cloud Market Requirements. *Information* 15 (04 2024), 232. https://doi.org/10.3390/info15040232

[11] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. 1995. *Design patterns: elements of reusable object-oriented software*. Addison-Wesley Longman Publishing Co., Inc., USA.

[12] Gartner Inc. 2024. Cloud Services Brokerage (CSB). https://www.gartner.com/en/information-technology/glossary/cloud-services-brokerage-csb. Accessed: 2025-07-24.

[13] Google. 2025. Google Forms. https://forms.google.com. Accessed: 2025-09-18.

[14] W. Harrison. 2006. Eating Your Own Dog Food. *IEEE Software* 23, 3 (2006), 5–7. https://doi.org/10.1109/MS.2006.72

[15] Nigel Hill, Greg Roche, and Rachel Allen. 2007. *Customer satisfaction: the customer experience through the customer's eyes*. The Leadership Factor, London.

[16] Kohei Honda, Nobuko Yoshida, and Marco Carbone. 2008. Multiparty asynchronous session types. In *Proceedings of the 35th annual ACM SIGPLAN-SIGACT symposium on Principles of programming languages*. ACM, San Francisco California USA, 273–284. https://doi.org/10.1145/1328438.1328472

[17] Ping Hou, Nicolas Lagaillardie, and Nobuko Yoshida. 2024. Fearless Asynchronous Communications with Timed Multiparty Session Protocols. *LIPICS, Volume 313, ECOOP 2024* 313 (2024), 19:1–19:30. https://doi.org/10.4230/LIPICS.ECOOP.2024.19

[18] Hennie Huijgens, Eric Greuter, Jerry Brons, Evert A. van Doorn, Ioannis Papadopoulos, Francisco Morales Martinez, Mauricio Aniche, Otto Visser, and Arie van Deursen. 2019. Factors affecting cloud infra-service development lead times: a case study at ING. In *Proceedings of the 41st International Conference on Software Engineering: Software Engineering in Practice* (Montreal, Quebec, Canada) (ICSE-SEIP '19). IEEE Press, Montreal, Quebec, Canada, 233–242. https://doi.org/10.1109/ICSE-SEIP.2019.00033

[19] Leslie Lamport. 1994. The temporal logic of actions. *ACM Transactions on Programming Languages and Systems* 16, 3 (May 1994), 872–923. https://doi.org/10.1145/177492.177726

[20] Yajing Luo, Peng Liang, Chong Wang, Mojtaba Shahin, and Jing Zhan. 2021. Characteristics and Challenges of Low-Code Development: The Practitioners' Perspective. In *Proceedings of the 15th ACM / IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM) (Bari, Italy) (ESEM '21)*. Association for Computing Machinery, New York, NY, USA, Article 12, 11 pages. https://doi.org/10.1145/3475716.3475782

[21] Peter Mell and Timothy Grance. 2011. *The NIST Definition of Cloud Computing*. Technical Report Special Publication 800-145. National Institute of Standards and Technology. https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf

[22] Chris Newcombe, Tim Rath, Fan Zhang, Bogdan Munteanu, Marc Brooker, and Michael Deardeuff. 2015. How Amazon web services uses formal methods. *Commun. ACM* 58, 4 (March 2015), 66–73. https://doi.org/10.1145/2699417

[23] Open Service Broker API. 2024. Open Service Broker API. https://www.openservicebrokerapi.org/ Accessed: 2025-08-06.

[24] Victoria Paulsson, Vincent C. Emeakaroha, John Morrison, and Theo Lynn. 2020. *Cloud Service Brokerage: Exploring Characteristics and Benefits of B2B Cloud Marketplaces*. Springer International Publishing, Cham, 57–71. https://doi.org/10.1007/978-3-030-43198-3_4

[25] Stuart Rance and Monika Dauer. 2014. *ITIL® Service transition* (2. ausg., 3. nachdr., ausg. 2011 ed.). TSO, London.

[26] DevOps Research and Assessment (DORA). 2024. *2024 Accelerate State of DevOps Report*. Technical Report. Google Cloud. https://cloud.google.com/devops/state-of-devops

[27] Matthew Skelton and Manuel Pais. 2020. *Team Topologies: Organizing Business and Technology Teams for Fast Flow*. IT Revolution Press.

[28] Miroslaw Staron, Silvia Abrahão, Gregory Gay, and Alexander Serebrenik. 2024. Testing, Debugging, and Log Analysis With Modern AI Tools. *IEEE Software* 41, 2 (2024), 99–102. https://doi.org/10.1109/MS.2023.3339408

[29] Maurice H. ter Beek, Rod Chapman, Rance Cleaveland, Hubert Garavel, Rong Gu, Ivo ter Horst, Jeroen J. A. Keiren, Thierry Lecomte, Michael Leuschel, Kristin Yvonne Rozier, Augusto Sampaio, Cristina Seceleanu, Martyn Thomas, Tim A. C. Willemse, and Lijun Zhang. 2024. Formal Methods in Industry. *Form. Asp. Comput.* 37, 1, Article 7 (Dec. 2024), 38 pages. https://doi.org/10.1145/3689374

[30] Martin Vassor and Nobuko Yoshida. 2024. Refinements for Multiparty Message-Passing Protocols: Specification-Agnostic Theory and Implementation. *LIPICS, Volume 313, ECOOP 2024* 313 (2024), 41:1–41:29. https://doi.org/10.4230/LIPICS.ECOOP.2024.41

[31] Roman Vorel. 2025. *Fragmented Software Development: Why DevOps Isn't Always Enough*. Apress, Berkeley, CA, 21–37. https://doi.org/10.1007/979-8-8688-1694-9_2

[32] Fangyi Zhou, Francisco Ferreira, Raymond Hu, Rumyana Neykova, and Nobuko Yoshida. 2020. Statically verified refinements for multiparty protocols. *Proceedings of the ACM on Programming Languages* 4, OOPSLA (Nov. 2020), 1–30. https://doi.org/10.1145/3428216