1. Summary

The value of a data space stems from its use cases. Data space use cases are settings where two or more participants create business, societal or environmental value from data sharing. Use case development amplifies such value of a data space.

Use case development falls into three initial steps, and continuous improvement throughout the life cycle of the use case as the overarching process model (Figure 1):

1. Identifying and monitoring use case scenarios is your starting point, where you generate new ideas.

2. Refining use case scenarios is where you spend more of your time, giving detail to the use case so that you can test its viability. This includes, at the minimum, the purpose and value of the use case, the use case participants, and the necessary data flows.

3. Implementing use cases is where you take the best ideas and move from the drawing board to putting the ideas into reality.

4. Continuous improvement process is the overarching process throughout the life cycle of a use case where you analyze its performance, identify improvement opportunities, plan and implement changes.

Open

Figure 1. Elements of Use Case Development.

Use case development is particularly important for data spaces in their early phases, as use cases attract users and participants that are essential for growth. An established data space with well-functioning use cases may opt out of use case development. However, it risks becoming obsolete as its business environment evolves and competitors develop new and improved use cases. Valuable use cases attract new customers and participants to data spaces, enabling them to scale and grow.

2. Purpose of the building block

Use cases create value, which can be economic, social, or environmental. More value is created with more and better use cases. Use Case Development aims to amplify this value by fostering the creation, support, and scaling of use cases.
This building block provides guidance on developing and deploying use cases for data space initiatives. It provides guidelines on how to support participants in exploring, developing, and onboarding use cases. A data space can offer support services like brokering between partners or other resources, such as templates containing use case criteria.

3. Concepts

3.1 Use case and use case scenario

A data space use case is a specific setting in which two or more participants use a data space to create value (business, societal or environmental) from data sharing. The term use case refers to an operational use case. When referring to a planned or envisioned setting that is not yet operational, we use the term use case scenario.

The same use case scenario, or variations of it, can be implemented multiple times in one or more data spaces. For example, there could be several manufacturing supply chains that would like to share data across the chain for production planning and control. If one of the supply chains successfully implements the scenario into an operational use case, it can provide an example for the other supply chains. They can then modify the example and develop their own use case scenario, either in the same data space as the original supply chain or in a different data space.

The core of use cases is the value created in the use of data. Consider, for example, the possibility of utilising a data space to create a digital product passport. In order to develop the use case, one would need to understand, e.g., the purpose and value of having a digital product passport, who uses it, and how and why it's used. One would need to understand what kind of data and services are shared, who provides the data and who uses it. Other questions could be: Who are the participants involved in this activity? What are their roles and responsibilities? What is the value they expect to get out of the activity?

Use cases can range from being straightforward, such as one-time transactions from data providers to data recipients, to very complex situations that include multiple parties exchanging data products and other services in a complex network. As described in the Data Space Offering and pictured in Figure 3 of that building block, the basic components of use cases are data products and value creation services. Each service or data product can be considered a simple use case but can also be combined to create more advanced use cases. It is essential to understand that the more complex use cases are composed of simpler transactions of data and services.

As an example of a simple use case, imagine a component manufacturer that needs information from its supplier on materials that the supplier provides. The component manufacturer can use this information for multiple purposes, such as quality assurance, product development, or sustainability reporting. This would be a relatively simple use case of sharing information between two companies, a component manufacturer and its supplier. Another simple use case could be the component manufacturer sharing sustainability data with the final product manufacturer. A further simple use case could be a sustainability reporting service. If materials data is shared with a service provider, the service provider can then calculate sustainability indicators based on the data and share this information with relevant recipients. Data products can be created for all these data and service transactions, and they all represent simple use cases. However, they can also be combined to create a more complex use case. The materials suppliers share the materials data with the sustainability reporting service provider named by the component manufacturer. The service provider then does the calculations and shares the sustainability report with the component manufacturer as well as with the final product manufacturer named by the component manufacturer.

3.2 Cross data space use case

A cross data space use case is a use case where the data sharing extends to two or more data spaces. In such a use case the participants of multiple data spaces aim to jointly create value from data sharing. They may utilize data products and services from several data spaces or from other data sharing infrastructures, such as e.g. platforms. An example of a cross data space use case could be to combine data from a tourism data space with data from a public transport data space to create a better travel experience. Another example of a cross data space use case could be to combine data from several local transport data spaces in order to offer travel services that cover a wider geographic area.  

3.3 Use case orchestrator

A use case orchestrator is a data space participant that represents and is accountable for a specific use case in the context of the governance framework. The orchestrator establishes and enforces business rules and other conditions to be followed by the use case participants.

In general business language, orchestration refers to assembling and managing a network of participants to achieve a joint goal. In the case of use case orchestration, the joint goal is developing the use case, and the network is the different participants of the use case. The need for orchestration is increased in situations with a high number of parties and the use cases are complex, as well as in situations where the data space needs to develop more use cases to reach a sufficient size. If a data provider and a data recipient want to agree on a single data transaction, they can probably do it without much orchestration. However, more complex use cases with many participants and various data products and value-creation services are likely to require orchestration.

It is in the interest of the data space that use cases are orchestrated since the development of use cases promotes the growth and viability of the data space. However, as the party responsible for decision-making in a data space, the governance authority has different options for organising the orchestration. The governance authority can act as a use case orchestrator or it can nominate one or more parties to act as use case orchestrators. It can nominate use case orchestrators in permanent roles or nominate them on a case-by-case basis as volunteers express interest in developing use cases. These options can also be mixed so that the governance authority takes responsibility for some use cases and appoints someone else to act as a use case orchestrator for others. Each use case orchestrator is responsible for one or more use cases. When the governance authority appoints other parties as use case orchestrators, it is in the interest of the governance authority to support them.

4. Elements and their key functions

The central elements of use case development are as follows.

Use case development is an iterative process in which the use case is gradually shaped, confirmed, and realised. The use case scenario is first drafted and then elaborated. In this process, some issues may be addressed repeatedly, first as a rough draft and then with more precision. One may also need to make changes to design decisions that have already been made. Because of this, the boundaries of the process steps may seem blurred. However, use case development is a stage-gate process.

The identifying and monitoring phase does not include substantial orchestration work. The main question in the stage gate between the identifying and monitoring stage and the refining stage is whether the idea is good enough and whether an orchestrator is willing to commit so that it is justified for the orchestrator to start investing resources in the refinement of the scenario and the orchestration work.

The refinement stage is about creating a group of committed participants and planning, designing, and negotiating the details of a joint goal. However, the participants may not be able to commit to their individual responsibilities and to the implementation of their part of the design until they know that everyone else will also do their part. The main question in the stage gate between the refining stage and the implementing stage is whether the overall design and the network are strong enough so that it is justified for the necessary partners to commit to and invest in the implementation work.

Use cases require changes and updates after the original implementation. Continuous improvement is needed throughout the life cycle of a use case, starting from the first phases of identifying use case scenarios and continuing throughout the operational stage until the use case reaches the end of its life.

4.1 Identifying and monitoring use case scenarios

Use case development begins with identifying use case scenarios – the ideas for potentially valuable use cases that require data sharing. Potential sources for ideas of use case scenarios include the needs of current and potential data space participants and their end customers, other data spaces, platform businesses, and other data-sharing contexts. Data spaces can be used to share data that has already been shared in some other way. For example, public authorities may be willing to try out data spaces for data that they already share.

A rich inventory of use case scenarios can accelerate the time needed for a data space to reach its full potential. Data spaces also benefit from monitoring the progress of developing use case scenarios. It would be helpful to keep a list of identified use case scenarios, their development stage, which ones became successfully implemented use cases, and which ones were abandoned and for which reason. Successful use cases are inspirational examples and sources of good practice. Based on the gathered knowledge of use case scenarios and operational use cases, the data space can recognise patterns that summarise the essentials of successful use cases. Keeping track of which use case scenarios were tried and abandoned and for what reason (lack of market demand, challenges in implementation, etc.) helps to avoid repeating mistakes.

In addition to monitoring use cases, it also makes sense to keep track on data products and value creation services available on the market – also outside one’s own data space. They are the components or “raw material” for use cases. Data products and value creation services offered by other data spaces could be utilized for cross data space use cases or the ideas could be copied for the data space and its own use cases.

Not every idea for a use case should be taken to the potentially laborious refinement stage. Instead, promising ideas should undergo an initial stage-gate screening to decide which ones should be further developed. Before committing resources, a data space would be interested in how well the use case fits. This would include questions about the scope and objectives of the data space and its market potential. Some use cases may be critical to reach the wider objectives of a data space. The development of these use cases would naturally be a high priority. It makes sense for the data space to consider what are such high level use cases and how to support them. The development order should also be considered – which use cases are to be focused on first and which can wait for future development?

It is also good to give some initial thought to the data and participants needed for a use case before progressing to the refinement phase. What data and services are needed, and which parties could provide them? Which other participants would be needed? Does the data space already have such parties, or does it need to attract new parties to join?

An essential part of identifying use case scenarios is to find use case orchestrators. A use case orchestrator is needed before moving to the refinement stage so that the development work has an owner. The governance authority can take on the role of the use case orchestrator, or it can nominate another party for the role. In the latter case, the data space should offer tools and support to the orchestrator.

Gathering a library of use case scenarios, monitoring their progress, and screening the best ideas for the refining stage should be carried out centrally. Someone else can do this if the governance authority does not want this task, but the governance authority should handle the nomination procedure.

When identifying and monitoring use case scenarios, it is good to look for collaboration possibilities in other data spaces. Rather than to create a use case internally within a single data space, it sometimes makes sense to share data between two or more data spaces and to develop a joint use case.

As an example, to generate better forecasts on crop yields, it might make sense to join data from a data space focused on agriculture and a data space focused on earth observation. A single company that wants to offer crop yield forecasts for farmers could join both data spaces to create such a cross data space use case. It is however inefficient, if a large number of companies need to join a large number of data spaces and to deal with all the different rules, contracts, standards, and participant agent services. In addition to yield forecasts, earth observation data enables many other new use cases for the agricultural sector. The agriculture data space might want to make it easy to exchange data with the earth observation data space if it thinks that this draws in new service providers and thereby makes the agriculture data space more attractive for all participants. Therefore, the agriculture data space could opt for a strategy to become interoperable with the earth observation data space.

Also, the viability of a use case might depend on e.g., a large base of participants or a wide geographical coverage. As an example, use cases around complex international supply chains might require extensive geographical coverage as well as coverage of a large number of different kinds of companies. In such situations, it makes sense to consider if the use case is best covered within a single data space or as a cross data space use case. More information on interoperability can be found in the section cross data space interoperability considerations in data space design and operation.

4.2 Refining use case scenarios

Once an idea has been initially screened and found promising, the orchestrator can refine the use case scenario. The use case scenario’s scope will determine the complexity of the refinement process. With a very simple use case, such as a transaction of a dataset from a data provider to a data recipient, the two parties can usually agree on the details easily. In the case of a complex use case, refinement of the use case scenario is an iterative design process involving the different participants in co-creation. The more participants, the more challenging it is to manage the network towards a joint goal. In this process, the role of the use case orchestrator is essential to facilitate and coordinate the design process. The description here focuses on the more complex use cases.

While having a considerable role in refinement phase, the orchestrator does not work alone. It orchestrates the co-creation efforts across use case participants. Also, the data space or the governance authority as a representative of the data space has a role (if it does not act in the role of the use case orchestrator). It can support use case orchestrators by giving them structured approaches and templates to further explore and refine the use case scenario. Some existing approaches are the Business Model Radar, the Data Space Canvas, the Data Cooperation Canvas, the Use Case Playbook, and the Use Case Blueprint. Links to these can be found in the further reading section. Many data space initiatives adapt one or more of these templates to better suit their needs. It is also possible to create a template of one's own.

The existing approaches differ and use different vocabulary, but they do share characteristics. Most of them are interested in the participants of the use case, their role or activity in the joint value creation, the flow of data and services, the value for participants, and the joint purpose or value of the use case. Based on this, in the early refinement stage, the orchestrator should manage the co-creation process in such a way that all the participants in the network can identify the joint goal and their role in it. The core structure of the use case scenario includes at least the participants of the use case with their roles and responsibilities, the purpose and value of the use case, value propositions for the use case participants, and the necessary data products and value creation services and their flows. Once this core structure of the use case scenario has been defined, the scenario can be assessed, improved, and refined by adding more detail and content.

A use case scenario will only be pursued if the relevant actors are convinced of the idea's value and it becomes a joint goal. The value needs to be high enough so that actors invest in further developing and implementing the use case. Also, if the use case scenario contains too many uncertainties, one might reconsider investments in further refining the use case scenario.

It is important to identify and design the relevant data products and value creation services in the refinement phase. Efficiency can be improved, and network effects created if the data products and value creation services are designed to be modular so that they can be combined in different ways to serve multiple use cases. It is advisable that the data space ensures that the most important data products and value creation services that work for the most important use cases are developed early on.

When further refining use case scenarios, the different approaches and templates guide the focus to additional issues such as the business case, regulation, contractual issues, interoperability, and security.

The business case of a use case can be based on higher profits, lower costs, or market growth. Such benefits can arise from various sources, such as a joint user base of several use cases or common resources like infrastructure, services, and data sources. The implementation and operational costs of individual use cases can be divided into infrastructure-related and other expenses. The data space offers a shared base infrastructure for all use cases within. Use cases may build on top of this, but using common infrastructure should reduce costs for individual use cases, lowering overhead and making it easier to scale. Further synergy can be achieved by using the same data products across several use cases.

The value and costs of a use case vary among participants. Often, the idea and motivation for a use case come from those who want to use the data. On the other hand, data providers and rights holders face costs and risks, such as investments in data quality and tools. Furthermore, organisations often fear losing strategic control over data and its value. The viability of use cases depends on the willingness of data rights holders to share data. Some use cases and participants may be financially supported due to the high value they bring to the data space or use case through other means (e.g., essential data products or services). Agreeing on compensation and fees while balancing the monetary and non-monetary costs and benefits in a manner that benefits all parties is crucial.

Regulation typically needs to be considered at an early stage when refining use case scenarios. As explained in the Regulatory Compliance Building Block, certain characteristics of a use case may trigger legal requirements. These could be, for example, the type of data, the nature of the participants, or the domain. Depending on the use case, different horizontal, sectoral, and national regulations may apply.

Regarding contracts, data product contracts and contracts regarding different value creation services are of particular importance for use case development, as data products and value creation services are the basic components of use cases. Naturally, use cases also function under the general institutional agreements and governance framework of a data space. In many cases these contract types can be sufficient for the purposes of developing use cases. However, a lawyer should examine in the refinement stage whether other agreements or contracts are necessary for the use case.

It is particularly important to design for security early in use case development and keep re-evaluating it throughout the lifecycle of the use case. Different use case contexts may impose different security needs. Security should always be a priority but may be particularly important in critical industries covered by the NIS2 Directive. Also, a higher security level may be required if the use case involves processing sensitive data. There may also be national or sectoral security-related legislation that needs to be considered depending on the use case and the data exchanged.

Recognising security requirements stemming from legislation, threats, and vulnerabilities is essential. The likelihood and potential impact of each threat affects the needed level of security. The data space’s infrastructure provides some security measures, but additional measures may be required. Threat modelling can be used for systematically identifying and evaluating potential threats to an application, system, or organisation. More and more regulators are making it mandatory in critical contexts and require evidence that it is performed.

More support for security can be found in the Data Sharing Canvas and the Rulebook for Fair Data Economy.

Not all use case scenarios make it from the refinement stage to the implementation stage. Those that do may be implemented gradually. Some parts of the use case can be implemented before other parts. It is up to each partner to assess whether and when they can commit to the implementation work planned for them in the use case scenario.

4.3 Implementing use cases

Before a use case can become implemented and operational, all the preconditions need to be met. For example, the data space infrastructure needs to be operational, and the use case participants need to have joined and connected to the data space. Further, the necessary contracts for the use case need to have been made, and the necessary data products and value creation services need to have been developed and made available through the data space. After that, the use case is implemented and operational once the participants have started to use the data products and value creation services, so that the system creates value in the planned way.

The data space infrastructure sets the boundaries for the kinds of use cases that can be implemented. For example, implementing a use case may require specific data models or services provided by the data space. Further boundaries are set by the willingness of the use case participants to participate in the role suggested for them and in the general setting of the use case.

The use case orchestrator continues the discussion with the participants that was started in the earlier phases, ensuring the viability of the use case. Making a use case operational from the refined description may require additional work, such as further development of the data space infrastructure, creating the necessary data products, adding new participants to the data space, making agreements, and setting up connectors.

Organisational, technical, and business aspects need to be implemented. The use case orchestrator acts as the process owner, arranging and agreeing on the implementation details with relevant participants. The governance authority as the representative of the data space can act as the orchestrator. If it does not act as the orchestrator, it still needs to support this activity, especially regarding the readiness of the data space infrastructure.

The implementation of complex use cases typically takes place in a stepwise manner. The use case orchestrator may want to start by implementing a minimum viable use case resembling a minimum viable product in product development. A minimum viable use case is a partial implementation, that includes only essential functionality and allows at least part of participants to use it. This functionality is created by implementing specific central data products and value-creation services. At later stages, more functionalities can be created by adding new data products and value creation services, and more participants can start using it. Further development can be done through prototypes that are used to test the technical feasibility of certain aspects of the design and whether the use case fulfils the needs of the customer and any other expectations set for it.

The EU co-funded project deployEMDS (Deployment of Mobility Data Space in Europe) has carried out a stepwise implementation process in the Barcelona-based use case “Multi-operator data governance ecosystem for bus fleets and demand-responsive transport”. The deliverable D4.2 of deployEMDS presents how they set their objectives based on an analysis of the use case’s context and its challenges and opportunities for value creation. They explored the possible implementation pathways in more detail by inspecting the most ideal implementation in an idealised, fictional scenario. The ideal use case was broken into sub-cases, and the focus was first set on low-hanging fruit. Then, they identified barriers to the ideal implementation stemming from the real world and planned alternate pathways to address them. The use case will be implemented in an agile manner and divided into sub-cases.

4.4 Continuous improvement process

The development work does not stop when a use case has been originally implemented and is operating. Continuous improvement is needed due to e.g., changes in technology, available data, and market conditions – or to simply make the use case function better. Changes in one aspect of a use case, such as e.g., a data product, a value creation service, a participant, or an agreement, may have implications on the other aspects and participants, and therefore it is important to manage carefully the changes made. This especially applies to complex use cases.

The life cycle of a use case starts from its development and introduction to the market and continues until it is removed from the market. This is much like the life cycle of any product or service offered to the market. However, when the use case consists of several data products and services provided by various participants, the life cycle becomes more complex than that of a single product provided by a single company. A simple use case may be introduced to the market at once, while a more complex use case may be introduced piece by piece, one or a few data products or services at a time. Once the use case is at least partly operational and has its first real users, participants can learn from the operation and improve the use case. The use case may grow either through addition of new data products and services or through addition of more participants. During this process, the use case may also change. At some point the original use case starts to decline. It may be that some data products and services decline faster than others. Instead of decline, some data products and services may continue in other use cases. Between the growth and the decline stages, there may also be a maturity phase, in which the use case is more stable. It may also happen that the original use case does not reach sufficient adoption, or it may prove to be financially unfeasible, and the idea will not fly. Then the design will need to be changed or the use case will quickly reach the end of its life.

Change management is also needed in all the phases of the life cycle. The more important the use case is for the data space, the more important it is to have effective change management and continuous improvement processes in place. It is the use case orchestrator that has overall responsibility for these tasks, but they should be done in collaboration with all the essential participants. Managing the change and the continuous improvement process starts with a clear shared vision of the use case. The essential participants need to have a say in the changes. They need to see the changes as valuable and to feel themselves safe while changes are made. When there are multiple changes to be made, they need to be prioritized and a roadmap made. The success of the use case and the changes made needs to be measured and further actions planned based on the analysis.

5. Co-creation questions

6. Links to other building blocks

The choices made regarding different data space building blocks and the whole data space as an infrastructure set the boundaries of what kind of use cases can be implemented in that data space. These boundaries need to be considered in Use Case Development. On the other hand, the type of use cases that a data space wants to be able to provide set requirements for the choices made regarding other building blocks. 

Business Model: Use cases are an important source of value creation in the business model of a data space.

Data Space Offering: Data products and value creation services are fundamental components of data space use cases.

Value Creation Services: The Value Creation Services Building Block provides a framework with the technical capabilities to deliver the services in the use case.

Intermediaries and Operators: Data space intermediaries and operators may contribute significantly to defining and developing data space use cases and act as use case orchestrators.

Organisational Form and Governance Authority: The type of use cases a data space wants to attract may affect the choice of organisational form. Governance authorities may also contribute to Use Case Development and act as use case orchestrators.

Regulatory Compliance: Attributes of use cases such as the context, domain, location, and type of data may trigger different regulations.

Contractual Framework: Contracts are an important part of use cases. When developing use cases, it should be considered if the data product contracts, contracts regarding value creation services, and general institutional agreements provide a sufficient contractual framework for the use case, or if other agreements or contracts are necessary at the use case level.

Data Models: Use cases set the requirements for data models, while data models set the boundaries for possible use cases. Data models must be developed to enable the desired use cases.

7. Future topics

The next version of this building block will focus on further refinement, clarification, and consistency with the other building blocks rather than introducing new topics.

8. Further reading

Documents and guidelines to implement building blocks
Further reading on some tools that can be used for refining use case scenarios:

• Business Model Radar: Starter Kit for Data Space Designers | Version 1.0 | March 2023 - Starter Kit - Data Spaces Support Centre (dssc.eu)

• Data Space Canvas: Rulebook for a fair data economy - Sitra

• Data Cooperation Canvas: The Data Cooperation Canvas

• Data Sharing Canvas: Tools - Centre of Excellence for Data Sharing & Cloud (coe-dsc.nl)

• Use Case Playbook: Tools - Centre of Excellence for Data Sharing & Cloud (coe-dsc.nl)

• Use Case Blueprint: Tools - Centre of Excellence for Data Sharing & Cloud (coe-dsc.nl)

Other reading

• Deliverable D4.2 Barcelona - Detailed Implementation Plan (Part A) of the EU co-funded project deployEMDS (Deployment of Mobility Data Space in Europe)

• Multi-sided platforms: Parker, G. G., Van Alstyne, M. W., & Choudary, S. P. (2016). Platform revolution: How networked markets are transforming the economy and how to make them work for you. WW Norton & Company.

9. Glossary