FOR SHARE - JULY SNAPSHOT - Marketplaces & Usage Accounting - Two pages description

Created by
Last updated: 3 July 2023, 10:38

Early draft

Please be aware that the Data Spaces Blueprint content shared in these pages are a very early draft published on 2023-07-01. The current draft is incomplete and the content might still change.

SAVE-THE-DATE 01-10/09/2023: We will welcome your feedbacks to future improve the Data Spaces Blueprint during the Public consultation that will open on September the 1st 2023 until September the 10th. Please mark these dates in your calendar and get ready!

Overview

The overarching objective of this building block is to generate value out of sharing of data among participants in the data space, through marketplace functionalities delivered on top of the catalogue developed in previous building blocks of this pillar. In a nutshell, the marketplace helps customers to discover available data products and support the procurement process, as well as monetization of those data products.

The mentioned general objective (generation of value out of data sharing, not only by data monetization through marketplace capabilities, but also from other mechanisms that have to be considered as the technical implementation of what is defined in the business building blocks of the data space) reflects the ultimate goal of the whole data space, therefore it is conditioned by many functionalities defined in other building blocks (legal, governance, business models, publication & discovery, …) and at the same time affects the definition of such building blocks.

Therefore, the scope of this building block can be dfined as the “implementation of marketplace capabilities on top of the data space catalogue (which includes different types of data products) and the required functionalities (managing of data catalogue(s), supporting the discovery of services, monetization, contract management, log, accounting, billing, etc …)”, while its boundaries are a bit blurred since some of these features are shared with other building blocks.

Finally, the specifications of this building block depends significantly on the architecture / topology of the data space (centralized, fully distributed, hybrid, federated, etc …). Therefore, all possible options have to be considered when defining this building block, so it is aligned with the decided topology of the data space.

Key elements

As mentioned, the objective of this building block is to materialize the data value creation by applying the functionalities implemented in other building blocks of this pillar (self-description, publication and discovery) to allow marketplace capabilities so that providers can offer their different types of data products, and receivers or users can make use of those products. To be more specific about roles, the following types of stakeholders can be considered as starting point:

  • Data product providers, offer data products that can be consumed by receivers or users, including services providing access to data, application services that can gather and process data, infrastructure services supporting the deployment and execution of the previous ones, but also potentially third parties services (certification, audit, standardization, external billing and payment, …). This type of stakeholder can play the role of both data provider and data intermediary, as they are described in the DSSC glossary.

  • Data product receivers or users, including actors, looking for data products, and accessing the marketplace from multiple ways: through the catalogue itself, or through the different associated marketplaces. This stakeholder plays the role of data users or data receivers, as they are considered in DSSC Glossary.

  • Marketplace governance body, to ensure that the operation of the marketplace is run according to the data space governance framework. This should consider, at least, liability of published assets, QoS (Quality of Service) & SLA (Service Level Agreement), compliance with regulations (e.g.: GDPR https://eur-lex.europa.eu/eli/reg/2016/679/oj and AI act https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex:52021PC0206 ), and other ethical aspects. This body should be part or aligned with the data space governance body, as it is reflected in the DSSC Glossary.

  • Operators of the infrastructure, who will ensure the proper functioning of the technical infrastructure, including security aspects. This role corresponds to the data space enabler, as they are considered in the DSSC Glossary.

  • Marketplace providers, actors that offer marketplace capabilities on top of the data product catalogue provided by the previous building block. Notice that some data products may be made visible by multiple marketplace providers. On the other hand, a given marketplace provider may only offer a subset of the products listed in the shared catalogue. This role could be seen as a different type of data space enabler, as they are considered in the DSSC Glossary.

The functional specification might also describe the journey when interacting with marketplaces for data product providers, covering, at least, the following steps:

  • Subscription: this stage includes registration as a provider, registration of the specification of the data product and verification of compliance with criteria and standards of the data space, product catalogue and marketplace.

  • Reference: the service provider might establish visibility rules and/or update the product specifications and offerings.

  • Sell: the product is procured by a customer and a product order is created

  • Follow: to monitor consumption, provide after-sale support and leverage the experience to innovate and continuously strengthen the product offering.

and users:

  • Discover: Customers use available search and filter functionalities to discover certain service offerings.

  • Select: Customers select certain product offerings on the marketplace.

  • Contract: This stage contains the checkout process of the cart, a verification and validation and also signing the contract. Payment providers might be already involved in order that customers can provide their payment details.

  • Consume & Pay: Customers access the service or product and pay for the usage. The access and authorization to the actual service is part of another building block.

  • Advocate: This stage comprises different activities like sharing of feedback about the product/service, after sale services or promotion activities.

Key functions

According to providers and customers journeys defined in the previous section, this building block should offer the following basic functionalities (to be further developed during the functional specifications phase):

  • Catalogue(s) management: this functionality will provide all the tools required to manage the existing catalogues (more from a data sharing and trading perspective), and that are not considered in previous blocks. More specifically, this building block will rely on the catalogue functionalities implemented in previous building blocks (publication and discovery), and on top of them it will implement advance features to extract value out of interactions between providers and users.

  • Customized publication and discovery of services, allowing providers to establish visibility rules and/or update the product specifications and offerings, and customers to use search and filter functionalities to discover certain service offerings, and select certain product offerings on the marketplace

  • Product order management, including creation and issue of the order by the user, monitoring of the order until the product is delivered, management of the different states of the order (acknowledge, cancellation, completation, etc.).

  • Contract lifecycle management, including the checkout process of the cart, a verification and validation and also signature of the contract and procurement of the product.

  • Payment for the usage of data products.

  • Data transactions / usage log / accounting: to store information associated with services specifications, services offerings, service orders, etc. The usage log will typically be used to calculate how much can be charged to customers and paid to providers (if not calculated in advance, if pay-per-use model, if intermediaries in the provisioning of the product, etc …) or conduct audit logging for data transactions including provenance tracking. Additionally, it will be used by providers to monitor the service consumption by reporting and analytics features.

  • Aftersales: allowing sharing of feedback about the product/service, after sale services or promotion activities. This functionality should also consider the eventuality of a “rainy day” scenario, including contingency plan or backup solution for unexpected events or failures that may occur during the operations.

The implementation of these key functions should rely on the adoption of common open standards.

Dependences and relationships

As mentioned above, due to the specific objective of this building block, there exist several dependences and relationships with many other building blocks, both inside and outside this pillar. It means that a clear alignment with those building blocks will be needed during the following phases, to define boundaries between building blocks, avoid overlapping and reinforce some functionalities. At this stage, most relevant dependances are the following:

  • Publication and discovery services: the marketplace will manage the catalog comprising Data Specifications and Data Product Offerings from multiple Providers, and based on that will perform the actions needed to allow the monetization of those products.

  • Governance: how the governance of the catalogue and the marketplace is linked with that of the data space

  • Business models: how the catalogue and the marketplace generate value according to the data driven business models of the data space. In this regard, we should consider other ways to generate value out of data, beyond monetization, and depending also on the type of the data space (public service, research, industry, etc.)

  • Legal: how regulation is enforced by the legal block so operations in the federated catalogue and marketplaces are compliant by default (e.g. global privacy policy, code of conduct or terms of reference, etc.). Federated marketplaces and third parties have to adhere to these rules.

Relevance for the data space

This building block reflects one of the potential ultimate goals of the whole data space: to materialize the generation of value out of sharing data among participants through marketplace capabilities. This building block also represents the real involvement of providers and receivers / users (and other stakeholders) in the data space (in principle, in this scenario no user will register if not to provide or require services through the marketplace). This building block is the end point towards which all the rest of activities within the data space are headed and converge.