Introduction

Motivation

Spurred by the rise of technology companies such as Apple and Facebook, digital platforms are receiving increasing attention both in the scientific and in the practitioners’ community. Generally speaking, such platforms allow different parties to build complementary products and services (Cusumano 2010; Gawer and Cusumano 2014). Two basic forms of digital platforms can be distinguished: two-sided platforms and multi-sided platforms. Whereas two-sided platforms mediate between two groups of users, e.g. buyers and sellers from a certain domain (Hagiu 2009), multi-sided platforms (MSPs) bring together multiple groups of users (i.e. not just providers and consumers of products and services). Typically, an MSP is provided by a “keystone” firm owning the platform, while complementors use the platform to provide additional offerings (De Reuver et al. 2018). There is consensus in the research community that MSPs are of sociotechnical nature, as they comprise various technical and organizational facets and multiple forms of interaction of the MSP with its dynamic environment on both technical and organizational level (Tiwana et al. 2010).

Consequently, the evolution of an MSP is a complex, dynamic process, which is not fully understood yet (Staykova and Damsgaard 2017). The lifecycle of an MSP typically comprises three major phases: the first phase is about the platform’s design based on a technological innovation; during the second phase, the platform is adopted and used by different user groups; the third phase then comprises platform scaling and growth activities (Staykova and Damsgaard 2015). While current research has been focusing mainly on the adoption and use of MSPs, the design phase – and especially the (very) early stages of the MSP emerging – are still relatively unexplored. This is somewhat surprising, as Gawer (2014) and de Reuver et al. (2018), for example, consider the nascence (or “genesis”) of MSPs a very promising and worthwhile area of research.

MSPs facilitate the establishment of business ecosystems, which are formed by the users interacting on the platform. Researchers have examined a number of case studies on MSPs in which a keystone firm owns and governs the platform (Ondrus et al. 2015; Tan et al. 2015); so these are “keystone-driven MSPs”. However, the platform landscape is becoming more and more diverse, with other, more complex governance and ownership structures being observable in different domains. De Reuver et al. (2018) have found that in many cases there is no single platform provider, but that the platform is jointly designed and “shaped” by multiple actors. In this context, Tiwana et al. (2010) point to the importance of distinguishing platforms owned by a single firm from platforms characterized by some form of “shared ownership”. Shared ownership materializes in multiple organizational forms, among them the alliance. Gawer (2009), for example, identified some MSPs from the supply chain management domain that are “shared among firms that are part of a formal alliance”. Such “alliance-driven MSPs”, which are characterized by shared ownership and governance (e.g. a joint-venture company or industry association), as well as decentral platform governance models have been neglected by academic research so far (De Reuver et al. 2018).

Therefore, the paper has been motivated by two research gaps: first, the limited understanding and knowledge of the genesis of MSPs; and second, the lack of research regarding MSPs based on shared ownership. As for the latter, the paper focuses on alliance-driven MSPs, given the many alliance-driven MSPs being launched at present in various domains. Three prominent examples can be found in the mobility sector alone: Caruso,Footnote 1 a data-brokering platform for the automotive aftermarket; NEVADA,Footnote 2 a joint initiative under the umbrella of the VDA (German Association of the Automotive Industry) for sharing car-generated data; and HERE,Footnote 3 a geodata service provider jointly owned by automotive OEMs, their suppliers, and technology companies.

Research questions and approach

The paper addresses three research questions addressing the (very) early stages of the platform design phase:

  • RQ #1: How do alliance-driven MSPs come into existence and evolve?

In contrast to MSPs owned by a single organization, alliance-driven MSPs require specific governance mechanisms (De Reuver et al. 2018; Tiwana et al. 2010) to be established. Of particular interest are the decision-making processes taking place among the different actors during the early stages of the platform’s lifecycle. Another area of interest refers to the different roles that the various stakeholders (i.e. users, owners, others) may assume during this phase.

This directly leads to the second research question:

  • RQ #2: How do the different stakeholder groups use certain governance mechanisms during the early phase of an alliance-driven MSP’s lifecycle?

It must be noted that these governance mechanisms, which mainly aim at designing and building the platform, have to be distinguished from instruments used for regulation, which aim at fostering and controlling the adoption and use of the platform. Discussing the regulatory function of digital platforms in general, Boudreau and Hagiu (2009) found that specific research is needed with regard to instruments that go beyond pricing mechanisms. Thus, the third research question is:

  • RQ #3: How are regulatory instruments designed to foster the adoption and use of an alliance-driven MSP?

In this context, platform boundary resources are useful for studying both governance mechanisms and regulatory instruments. For conceptualizing platform boundary resources, the paper follows Ghazawneh and Henfridsson (2010). It defines boundary resources as resources that facilitate relationships and interactions between different actors and user groups. The paper thereby takes up demands from de Reuver et al. (2018), for example, who suggest to focus on MSPs’ boundary resources for studying the multifold interactions between MSP actors during the different platform lifecycle phases.

The International Data SpacesFootnote 4 (IDS) initiative is a joint effort of various international research institutes and industrial enterprises aiming at establishing a decentralized platform for secure and trusted data sharing. As a multi-sided data platform, the IDS represents an extreme case (Ridder 2017; Yin 2014) of an MSP, as the keystone actor here is not a single firm (e.g. a technology company) but a non-for-profit association forming an alliance of multiple organizations that may assume one or more roles on the platform (such as data provider, data consumer, research organization, software/service provider, auditing firm). Furthermore, the platform’s focus on facilitating trusted data exchange and maintaining data sovereignty presents a research opportunity that allows examining a boundary resource (i.e. data) that is different from the ones investigated in previous studies. Data sharing and data exchange facilitated through an MSP needs to be governed, which calls for a comprehensive set of regulatory instruments.

The research activities carried out in this case study were guided by the principles of Action Design Research (ADR) (Sein et al. 2011). More specifically, the ADR approach pursued comprised multiple ADR cycles (i.e. project phases), each of which consists of four steps: 1) problem formulation; 2) building, intervention, and evaluation; 3) reflection and learning; and 4) formalization of learning (Sein et al. 2011). Thus, the case study is characterized by extensive interaction and collaboration between researchers and practitioners (Baskerville 1999), which allows for immediate creation and transfer of knowledge within the situational environment of the MSP’s emergence.

The remainder of the paper is structured as follows: this introductory section is followed by an analysis of related work in the field of multi-sided platforms; the third section then outlines the research design applied and the research process conducted; the results of the case study are presented in the fourth section; the fifth section then discusses the case study findings and puts them in perspective with existing literature and theory; the paper concludes with a summary of the case study, its contribution to the body of scientific knowledge, remarks on the study’s limitations, and an outlook to future research opportunities.

Related work

Constituents of an MSP

MSPs are sociotechnical constructs; they are both technical platforms and market intermediaries. Thus, describing an MSP requires both a technical architecture and an ecosystem architecture (Dal Bianco et al. 2014). The technical architecture consists of modules and components some of which remain stable during the platform’s lifecycle, while other vary over time (Baldwin and Woodard 2009). For communication between components and for interaction between users, application programming interfaces (APIs) are used. APIs also allow third parties (i.e. complementors) to provide additional services (Ghazawneh and Henfridsson 2015).

The various actors engaging with each other on the platform constitute a business ecosystem (Gawer and Cusumano 2014; Schreieck et al. 2016). The platform owner provides the platform as a service to different user groups (i.e. sides) and to complementors. Many MSPs are provided and owned by a single entity, which is referred to as the “keystone firm”. However, recent research has taken up on “multi-actor settings” (De Reuver et al. 2018), as more and more MSPs are based on such an approach. Apparently, control mechanisms differ from case to case. Governance instruments must be in place to coordinate the agents that together provide and own the platform.

Besides such an “internal” governance framework (i.e. the one that is concerned with the group of collective platform owners), a second governance framework is needed, which coordinates interaction between the platform owners and the various users of the platform as well as the complementors. That governance framework specifies decision-making rights with regard to using the platform and the services offered via interfaces (Boudreau and Hagiu 2009; Staykova and Damsgaard 2015; Tiwana et al. 2010). Furthermore, this second governance framework also defines platform access rights and, thus, specifies the platform’s degree of openness (De Reuver et al. 2018; Ondrus et al. 2015).

Recent studies have advanced the understanding and knowledge of governance concepts and interaction patterns on such platforms by 1) examining the rules and instruments guiding governance and interaction activities, and 2) taking a boundary resource perspective on the topic. Regarding the former, Tiwana et al. (2010) specified governance and interaction patterns by introducing concepts such as leadership, ownership, and platform rules as elementary platform design constituents. Further research in this area seems useful though, as there is a demand to study not only mechanisms for regulation of MSPs, but also mechanisms for MSP adoption and use (i.e. mechanisms that go beyond the establishment of pricing instruments) (Boudreau and Hagiu 2009).

Lifecycle of an MSP

Previous research on the emergence and evolution of MSPs reached consensus in the sense that – at a high level of abstraction – the lifecycle of an MSP comprises three phases. Henfridsson and Bygstad (2013), for example, identified an evolution path of MSPs going from “innovation” to “adoption” to “scaling”. Tan et al. (2015) looked at the ecosystem and the different sides that are attracted to a digital platform, finding that typically a platform matures from a two-sided model without interaction between the sides to a two-sided model with interaction to eventually an MSP model. Taking up on these findings, Tan et al. (2016) examined IT affordance and related activities, leading to the evolution of the ecosystem along the three phases.

The second phase of the lifecycle (i.e. platform adoption and use) has been the subject of investigation of a number of studies. For example, network effects and pricing concepts have been used as theoretical lenses to study the success or failure of MSPs (Evans 2003; Evans and Schmalensee 2013; Weyl 2010). Regarding the preceding (i.e. the design) phase, less research has been conducted, mainly taking an innovation or engineering view (Tan et al. 2016; Tura et al. 2018). Tiwana et al. (2010), for example, studied the relationships between different platform constituents (such as governance and architecture) during this phase. However, detailed insights as to how an MSP comes into existence and evolves during the very early stages of the design phase are missing so far. Given the growing importance of MSPs in the market, more research is needed in this regard (Gawer 2014). This demand is supported by widely accepted insights from the software and systems engineering domain that early design activities – such as conducting a requirement analysis – have the biggest impact on a system’s success or failure (Hofmann and Lehner 2001).

Data as a boundary resource of an MSP

As far as the boundary resources are concerned, Henfridsson and Bygstad (2013) argue that this concept is helpful for studying patterns of interaction between the various groups and agents on a digital platform. Boundary resources are resources through which different agents create relationships and interact with each other in order to co-create value (Eaton et al. 2015). Dal Bianco et al. (2014) distinguish between technical and social platform boundary resources. Typical boundary resources are Application Programming Interfaces (APIs) and Software Development Kits (SDKs). Examples for social boundary resources are intellectual property rights and documentation of software services. Furthermore, boundary resources are not stable, but evolve over time. Eaton et al. (2015) coin the notion of “distributed tuning” to describe the process of continuous shaping and reshaping of boundary resources between the different platform actors and users. More recent research has suggested to increasingly look at such boundary resources of digital platforms as a promising subject of analysis (De Reuver et al. 2018).

How organizations can exchange and share data has long since been an important research topic. The need for companies to exchange and share data has been a major motivation for the development of platforms mediating between suppliers and buyers of goods. Early two-sided data exchange solutions were facilitated by technological standards, such as EDIFACT or ANSI X.12. Gawer (2014) within her integrative platform framework identified traditional buyer-supplier relationships for which data is a technical enabler.

Around the turn of the millennium, electronic marketplaces emerged as intermediaries to reduce the complexity of the increasing need of n:m data exchange (Segev et al. 1999; Timmers 1998), in which data from multiple sources (n) can be bundled and utilized in contextualized presentations to multiple users (m). This intermediary function comprised – among other things – the mapping of the different message schemas of the various standardization initiatives that evolved. Motivated by the success of peer-to-peer-networks in the consumer realm, some researchers explored technologies, and even business models, for peer-to-peer based networks for data exchange in the industrial domain. Technological aspects of peer-to-peer data ecosystems, such as context exchange among different world views of organizations (Goh et al. 1999) or automation of data mappings in heterogeneous settings (Jarke et al. 2014), have been investigated since the late 1990s. In 2005, Franklin et al. (2005) noted the growing richness of digital media and proposed that users should be enabled to create their own “data space”, where a free collection of data and media objects could be managed under a user specific network of semantic metadata. In 2010, the notion of the “data lake” was coined (LaPlante and Sharma 2016) and quickly received attention in the practitioners’ community. Furthermore, some researchers investigated the role of data within platform based ecosystems (Immonen et al. 2014; Kontokosta 2013; Moiso and Minerva 2012). More recent research has dealt with the upcoming phenomenon of data platforms, mainly encouraged by the discourse around big data (Bharosa et al. 2019; Demchenko et al. 2014; Immonen et al. 2014). These studies focus mainly on platform architecture technology and data flows.

What extant literature is still lacking, however, are studies of data being the key resource on digital platforms. In particular, viewing data as a boundary resource – in order to gain insight into governance frameworks and regulatory mechanisms on digital platforms – is a topic that has not been addressed by the scientific community. More recent studies have addressed this gap in research though. Schreieck et al. (2016), for example, concluded that more research is needed on “how data is used to govern platform ecosystems in practice”.

In this context, and in response to the research gaps outlined in the three previous subsections, the paper aims at providing detailed insights into the very early stages of the design phase of alliance-driven MSPs, using the concept of the boundary resource and putting a special focus on data being the key resource in such a scenario.

Research design

Research context

The context of the research presented in this paper is provided by the IDS initiative. By proposing a reference architecture model for secure and trusted exchange of data that is applicable in various industries, IDS constitutes a blueprint for multi-sided data platforms. As a non-for-profit organization bundling user requirements and providing use cases for testing the IDS Reference Architecture Model, the International Data Spaces Association (IDSA) collaborates closely with the IDS research project, which is led by Fraunhofer and funded by the German Federal Ministry of Education and Research (BMBF). The IDSA consists of more than 90 member organizations from more than fifteen countries, representing different groups of users and stakeholders of the IDS. The list of members comprises user companies acting as data providers and/or data consumers, software and technology vendors, accounting and auditing firms, and non-for-profit organizations (e.g. other industry associations and research organizations). Fraunhofer, as the leading partner of the research activities, is one of the founding members of the IDSA. IDS stands for an alliance-driven MSP, as IDSA members share ownership of the Reference Architecture Model and the design process.

Generally speaking, single-case study research is appropriate for studying extreme cases (Yin 2014) or if a representative and/or complex case is at hand (Donmoyer 2000). The design of the IDS is both unique and complex: first, in contrast to the majority of similar cases, the IDS was not designed and developed by a single keystone entity, but by an alliance of multiple stakeholder groups; second, with its clear focus on data sharing, the IDS allows viewing data as platform boundary resources. To examine the use and management of data in a single-case study setting has been proven useful in the past. Shanks (1997), for example, argued that strategic data planning is a complex phenomenon that must be studied in its environmental context.

Conceptual framework

Following Ridder’s (2017) categorization of case study designs, the research presented in this paper is exploratory and aims at closing “gaps and holes” in existing theory. With this purpose, case study research requires a conceptual framework which functions as a theoretical lens for data analysis and interpretation (Dul and Hak 2008, p. 36; Yin 2014). Based on the analysis of the related work, the study uses the conceptual framework described in Table 1.

Table 1 Conceptual framework
Full size table

The platform’s ecosystem is formed by the IDS Association; its statutes and rules specify the ecosystem’s governance policy, as they define rights and responsibilities related to the design of the IDS Reference Architecture Model and the use of its implementation. The IDS Reference Architecture Model (Otto et al. 2017; Otto et al. 2018) describes the platform as such. The data shared and exchanged via the IDS represents the boundary resource that creates relationships and facilitates interaction between the various actors using the platform. Regulatory instruments guide the adoption and use of the platform. The study uses the conceptual framework to analyze the early design phase of the IDS.

Research process

Generally speaking, ADR is applicable for sociotechnical design artifacts, as they require – in the various phases of the design process – knowledge from the environment (e.g. for requirement identification and artifact evaluation). The paper reports on a longitudinal study covering 3 years and two design cycles regarding the major artifacts, namely the platform architecture and the ecosystem governance model (see Table 2).

Table 2 Research process overview
Full size table

The four phases of the research process – namely “Rationale and Requirements”, “Institutionalization and Use Cases”, “Architecture Design”, and “Ecosystem Design” – form the structure along which the case is presented in the following chapter.

Data collection and analysis

The design process used empirical data from the field for identifying design requirements, justifying design decisions, and evaluating design instantiations. Data collection took place in three different forms: first, eleven multilateral workshops (MWs, see Appendix Table 12) were organized to create consensus between different user groups representing different markets (data providers, data users, service/software providers etc.); during the workshops, focus groups served as the main method to derive design requirements and evaluate design artifacts (Tremblay et al. 2010); second, bilateral workshops (BWs, see Appendix Table 13) were organized for creating a more detailed understanding of individual requirements (in particular with regard to input from competing actors); third, use case projects (UCs, see Appendix Table 14) served as an environment to test and evaluate the design artifacts (in particular: the individual components of the IDS architecture) in real-world settings.

To document the results of the various multilateral and bilateral workshops, flipcharts and “brown paper” boards were used. After each workshop session, protocols and detailed workshop minutes were sent to the participants to gather feedback and comments.

International Data Spaces: case study results

Project phase #1 – Rationale and requirements

Description

The first phase of the research process was characterized by problem centricity activities, following the concept of entry points for a study in design science research as proposed by Peffers et al. (2007). In a first high-level meeting, stakeholders from selected industries, government, and research agreed that data is increasingly playing an enabler role and turning into a strategic resource in enterprises. Moreover, there was consensus that a platform for data exchange and data sharing had to be driven by the requirements of the platform users, and that data sovereignty of data owners and data providers had to be a central concept of the platform to be developed. Fraunhofer and the BMBF then invited a larger group of stakeholders to a second high-level meeting (see MW1 in Appendix Table 12) in order to confirm the preliminary findings and lay out a roadmap for follow-up activities. In MW1, one participant (the CIO of a large automobile manufacturer) articulated that data security had to be understood as an asset, and that data providers needed to make sure they do not end up only with carrying the cost of data management, but are enabled to take advantage of the benefits of the data economy. Other participants emphasized the need to take a business perspective on the topic, as pursuing a purely technical approach would not be sufficient.

It was decided to establish a task force to collect requirements and identify possible use cases. In MW2, a first set of requirements was collected. Based on state-of-the-art knowledge regarding data space architectures and data exchange platforms, the industry representatives discussed requirements to be met by a multi-sided data platform in an open workshop session (cf. Table 3). The requirements agreed upon by the majority of participants were documented on a flipchart.

Table 3 Initial set of requirements
Full size table

The list of requirements spans a wide range of aspects. It covered both functional requirements, such as integration of components or data flow traceability, and non-functional requirements, such as software component certification or trust.

In addition to the requirements, the task force defined a first set of possible roles relevant for the IDS ecosystem (cf. Table 4). It was agreed that the exchange of data basically should take place between a Data Owner providing the data and a Data User consuming the data, and that an intermediary, called “Broker”, should bring together data supply and data demand by providing search and look-up functionality. Furthermore, it was decided that the Broker should be able to monitor data transactions (without being able to read payload information) and offer value-adding data services (e.g. for data analytics). The list of roles was completed by a Certification Agency making sure that each participant, and each software component used for implementing the IDS reference architecture, complies with IDS requirements.

Table 4 Initial set of roles
Full size table

It should be noted that the list of roles does not include any such role as a “platform operator” or “platform provider”. The task force agreed that – in line with the conceptual design of peer-to-peer networks – no central operator or provider was needed. Instead, it was decided that the IDS Reference Architecture Model should be open to be taken up by any market participant, leading to multiple implementations of the IDS. Finally, the task force decided to refine the requirements and design a first version of the IDS Architecture in three use case domains: logistics, automotive/mobility, and healthcare.

Conceptual analysis

Table 5 gives an overview of the conceptual analysis of the “Rationale and Requirements” phase. All concepts, except for ecosystem governance, were addressed in this very early design phase. With four initial roles being identified, this first project phase already addressed the multi-sidedness of the initiative.

Table 5 Conceptual analysis of Phase 1
Full size table

The identification of requirements referred to two types of requirements: one the one hand, data sharing and data exchange requirements were defined; on the other hand, requirements for the provisioning and use of the platform itself were identified.

Project phase #2 – Institutionalization and use cases

Description

The second phase of the research process mainly focused on the institutionalization of activities and the analysis and implementation of use cases. The former resulted in the foundation of a non-for-profit association, the IDSA. The work within the IDSA is organized in working groups, two of which are “WG Architecture” and “WG Use Cases and Requirements”.

The use case projects provided insights with regard to the data management activities the IDS architecture has to support and the assignment of these activities to the various roles in the business ecosystem (see Table 6).

Table 6 Assignment of data management activities to IDS roles
Full size table

Data management typically comprises three types of activities with regard to the creation, processing, and use of data: data governance, metadata management, and data lifecycle management. Data governance defines a framework of decision-making rights and processes with regard to the definition, creation, processing, and use of data (Khatri and Brown 2010; Weber et al. 2009). Hence, in the IDS context, data governance comprises also usage rights regarding data shared and exchanged via a multi-sided data platform. Metadata management specifies data about data, comprising both syntactical, semantic and pragmatic information (Sen 2004). It is of particular importance in distributed system environments that activities do not rely on a central data storage instance, but instead allow self-organization of different heterogeneous databases (Franklin et al. 2005; Halevy et al. 2006). Data lifecycle management is concerned with the creation, capturing, processing, enrichment, storage, distribution, and use of data (Ofner et al. 2013).

The industrial partners involved in the process extensively discussed questions related to data ownership. They quickly agreed that data owners should be able to specify usage rights with regard to their data by attaching data usage policies to the data itself. An interesting data management requirement came up in BW7, when a representative from a participating logistics service provider demanded that a broker might need to be able to disguise the identity of a data owner when presenting metadata, and/or to anonymize data before providing it to a data user (i.e. the broker should act as a data service provider also).

It was also consensus that each data transaction had to be logged and monitored in order to enable clearing services (in case a data transaction fails, for example) and data provenance.

With regard to metadata management, the participating industrial partners required that metadata should not be limited to syntactical information about data, but also include data ownership information, general usage conditions, prices for data use, and information about where and how the data can be accessed. Furthermore, it was agreed that the broker should provide vocabulary management services to facilitate easy mapping and linking of data (Halilaj et al. 2016).

Regarding the data storage architecture, it was agreed that data owners should keep control over data storage. All industrial partners opposed against any form of central data storage, due to a lack of trust with regard to data access and data usage on the part of third parties which data owners might be unaware of. As a consequence, it was decided that the IDS architecture should not follow a central data storage approach, such as the concept of the data lake (LaPlante and Sharma 2016; Larson and Chang 2016), for example.

Conceptual analysis

Table 7 gives an overview of the conceptual analysis of the “Institutionalization and Use Cases” phase. The focus of this project phase was on the definition of the ecosystem’s governance mechanisms, i.e. the decision-making rights and the data management activities on the platform. These activities allowed for a more detailed specification of the functional requirements to be met by the platform.

Table 7 Conceptual analysis of Phase 2
Full size table

Project phase #3 – Architecture design

Description

Based on the overall rationale of the IDS and the requirements for data management activities, researchers and practitioners working together in WG Architecture designed a first version of the IDS Architecture (cf. Fig. 1).

Fig. 1
figure 1

Initial IDS architecture design (cf. Otto et al. 2016)

Full size image

The central software component of this architecture is the IDS Connector, representing a data endpoint that grants participants access to the IDS (Otto et al. 2017).Footnote 5 The IDS Connector has three key functions: first, it is responsible for the exchange of data between a data provider and a data consumer (this includes request activities, usage control management and enforcement, mapping, and secure data transmission activities); second, it enables secure and trusted execution of software (i.e. it works as an isolated runtime environment that makes sure both data and software inside the Connector is protected against unauthorized access and manipulation from outside); third, it executes trusted software packages (“Data Apps”) that can be retrieved from the IDS App Store.

The App Store was defined in Phase 3 as a new role within the IDS ecosystem. It is responsible for distributing certified Data Apps (i.e. self-contained, self-descriptive software packages that can be deployed inside the IDS Connector). A Data App provides access to data as well as data processing capabilities (Otto et al. 2017).

Information about the data endpoints accessible in the IDS is provided by the Broker, which is responsible for managing a metadata repository (Otto et al. 2017).

Conceptual analysis

Table 8 gives an overview of the conceptual analysis of the “Architecture Design” phase. This phase was dominated by the first cycle of BIE activities (BIE = building, intervention, and evaluation; i.e. the second stage of the ADR process) regarding the core architecture components (i.e. mainly the IDS Connector). While data served as a functional boundary resource in Phase 2, it served as a technical boundary resource in the third phase.

Table 8 Conceptual analysis of Phase 3
Full size table

Project phase #4 – Ecosystem design

Description

Over the course of designing the IDS Reference Architecture Model and its piloting in use cases, it became apparent that the initial architecture design was a good starting point to address the requirements (i.e. use of the IDS Connector; decentral data storage; IDS Broker and IDS App Store as new roles etc.), but obviously was still lacking details needed for implementation. In particular, details about what activities should be performed by which role within the IDS ecosystem had to be defined. In addition, platform activities that were missing in the earlier phases of the research process were identified and specified. One activity of particular importance was identity management to ensure secure authentication and trust among IDS participants. Another task force was established to focus on the design of the business ecosystem. In MW11, the group identified key ecosystem actors and defined an initial set of responsibilities for each of them. Figure 2 shows the first version of the IDS ecosystem design.

Fig. 2
figure 2

IDS ecosystem design

Full size image

In this fourth phase, two additional roles were defined: the Clearing House and the Identity Provider. The Clearing House acts as an intermediary providing clearing and settlement services for all financial and data exchange transactions within the IDS (Otto et al. 2017). The Identity Provider offers services to create, maintain, manage and validate identity information of and for IDS participants.

With the ecosystem’s design becoming more and more mature, questions came up regarding the “roll-out” (i.e. the adoption path) of the IDS. In this context, a task force named “Business Modeling and Exploitation” was established, which came up with a sequence of platform features considered instrumental for the launch and adoption of the IDS (see Table 9).

Table 9 Instruments for adoption and use of the IDS
Full size table

The six main instruments follow a logical order. The first instrument aims at ensuring 1) trust among the different users of the IDS. When trust is achieved, ensuring 2) secure exchange of data and data sovereignty is the next step. These two instruments are required for fostering the emergence of a 3) data ecosystem. For a data ecosystem to run efficiently, 4) interoperability is needed for standardized interaction of ecosystem actors (vocabularies play a key role in this task, as they facilitate the mapping of different data sources and the integration through linked-data representations). On top of data exchange, 5) apps can offer value-adding services using shared data. Finally, 6) data markets emerge on the basis of clearing and billing services (among other things).

Furthermore, domain specific ecosystems were envisaged in different “smart service” domains (e.g. healthcare, mobility, education, or travel). The task force confirmed the decision not to design the IDS Reference Architecture Model for a single provider, but to allow for as much openness as possible to foster rapid market adoption of the IDS.

Conceptual analysis

Table 10 gives an overview of the conceptual analysis of the “Ecosystem Design” phase. The focus of the activities in this phase was on the completion of the platform ecosystem and the regulatory instruments needed to foster adoption and use of the IDS. With regard to the former, the various possible interactions between the ecosystem actors were specified and separated from the technical architecture components. Furthermore, the regulatory instruments form a consensus of the partners in the ecosystem and were developed in the light of IDS rollout and use.

Table 10 Conceptual analysis of Phase 4
Full size table

International Data Spaces: case study discussion

Platform architecture

A multi-sided data platform requires clear data governance rules and data management processes for the platform to successfully evolve. A central platform functionality is metadata management. Metadata must include information about the data owner, about data usage conditions, and about financial aspects (e.g. price of data use). Data provenance (Buneman et al. 2000) is necessary to be able to track the flow of data across multiple nodes of the network (i.e. different actors in the ecosystem).

Another central IDS feature is decentralized data storage. While central approaches, such as data lakes, are of significant value for use cases in which large volumes of data are required (for machine learning purposes, for example), they cannot be considered a reasonable option for critical data goods (which are in the focus of the IDS ecosystem).

In addition, the architecture must allow for distributed usage control including remote policy enforcement (Hilty et al. 2007; Kelbert and Pretschner 2012). Distributed usage control extends the exisiting conceptualization of data governance. The majority of data governance approaches focus on single enterprises and is mainly concerned with defining roles and responsibilities for the management and use of master data (Khatri and Brown 2010; Weber et al. 2009). Distributed usage control, though, can be seen as a means establish data governance in ecosystems.

The results of the IDS case confirm the findings from previous research, e.g. the “network type” of inter-organizational data collaboration observed by van den Broek and van Veenstra (2015), and provide opportunities for future research.

Platform boundary resource

The role of social boundary resources is essential during the early stages of an MSP’s design phase, because technical boundary resources do not exist yet during theses stages, and because multiple stakeholder groups need to find consensus about the purpose of the platform. Dal Bianco et al. (2014) point to the importance of knowledge transfer and education measures as social boundary resources during the adoption phase of a typical MSP. In the case of the IDS, however, social boundary resources comprise mainly the organizational structures of the IDS Association (its working groups, task forces etc.) and the “functional view” of data as described in the use cases.

As far as data is concerned, its dual nature as a boundary resource has to be stressed: From a functional perspective, it serves as a social boundary resource, as it supports the identification and analysis of multilateral use cases; regarding “data in transit” functions, it serves as a technical boundary resource as defined by Gawer (2014) and Schreieck et al. (2016). The IDS case points to the importance of data governance and the coordination of shared data management activities in this respect.

Platform design

The main challenge for an MSP is rapid market entry and fast adoption by a critical mass (Henfridsson and Bygstad 2013). As already mentioned, the lifecycle of an MSP comprises three major phases: innovation, adoption, and scaling (Tan et al. 2015; Tan et al. 2016). In many cases, MSPs are forced to achieve time and adoption advantages with regard to competing MSPs in order to survive. In contrast, one of the biggest hurdles for an alliance-driven MSP is the coordination of the requirements coming from multiple stakeholder groups, as well as the definition of decision-making rights and responsibilities during the early stages of the platform design phase. Thus, adoption – which typically is a key success factor – is not so much of an issue than organizing the innovation process within the alliance. As a consequence, the typical stages which can be observed in an MSP’s lifecycle follow a different sequence and are rather characterized by early adoption and innovation and design activities following at a later stage.

Platform ecosystem

The IDS initiative represents a case in which an ecosystem is designed in a joint effort. This is in accordance with the views of those researchers considering a platform ecosystem as the result of a structured design activity (Immonen et al. 2014; Tian et al. 2008). However, opponents of this perspective see ecosystems emerging around a shared value proposition and argue that, due to a range of exogenous factors, ecosystems can only be planned and design to a very limited extent (Adner 2017). Through the participation of various stakeholder groups in the IDS Association, some of the typical endogenous factors, such as competition or technological obsolescence, could be “internalized”, and thus being controlled to a certain extent. This means that the ecosystems of alliance-driven MSPs might be better “designable” than more common MSP ecosystems fostered by a keystone firm.

Reflecting these findings against research on the emergence and adoption of open-source ecosystems, such as Fiware (Rodriguez et al. 2018), or against the shift of the OPC Foundation towards an open-source model (Palm et al. 2015–2015), is a promising approach to further advance these propositions.

Ecosystem governance

Coordination of a joint innovation process during the early stages of the platform design phase requires extensive interaction and consultation between the different sides involved. This stands in contrast with the emergence of keystone-driven MSPs, which tend to develop interaction between sides during later stages of the platform’s lifecycle (Tan et al. 2015; Tan et al. 2016).

As far as organizational structures are concerned, some similarities between the IDS case and keystone-driven MSPs can be identified – particularly regarding the aspect of platform openness. Openness refers to restrictions regarding the use, development, and commercialization of a platform (Boudreau 2010; Eisenmann et al. 2009). Ondrus et al. (2015) showed that openness typically changes across the lifecycle of an MSP. As a non-for-profit organization, the IDS Association is open to everyone, but nonetheless uses governance mechanisms to align the behavior and interests of its various stakeholders. Openness differs with regard to the stakeholder groups addressed and, thus, can be observed on a provider, a technology, and a user level (Ondrus et al. 2015). Openness is carefully controlled by the platform owner in order to steer the platform’s adoption and use into the desired direction. Typically, openness can be seen on a technology level – as in the IDS case – on platforms that are open for open-source development after a certain level of maturity has been reached, and in order to compete against other platforms in the same market.

Regulatory instruments

In contrast to keystone-driven MSPs, on which pricing is among the main instruments regulating adoption and use of the platform, the design and development phase of the IDS was mainly concerned with instruments other than pricing. The IDS considers trustworthiness of participants and data sovereignty of data owners and data providers as key instruments regulating the adoption and use of the platform. Thus, the IDS alliance considered non-pricing instruments more important than pricing instruments. The latter were envisaged only in terms of providing IDS Data Apps through the IDS App Store – and in facilitating data markets further down the road, which would need clearing of data transactions and billing.

While it is apparent to a certain extent that pricing played no major role during the early IDS design, the findings of the IDS case study confirm the results of previous research. Boudreau and Hagiu (2009), for example, observed a wide array of legal, technological, informational and other instruments for regulating MSPs.

The regulatory instruments in the IDS case were directly derived from the user requirements specified – and, thus, mutually agreed upon by the parties involved. Being an outcome of a task force that was open to all members, these instruments were not imposed by a certain group of members, but represent a consensual ecosystem governance approach. In fact, the structure of the IDS ecosystem is a result of these regulatory instruments, as the instrument’s operationalization required the definition of dedicated roles (e.g. Certification Agency or Clearing House). In contrast to keystone-driven MSPs, all aspects of ecosystem governance – i.e. platform ownership, leadership, and rules (Tura et al. 2018) – have been combined in one organizational entity: the IDS Association. While typical MSPs develop regulatory instruments as the platform is being adopted and used, the IDS case displayed some form of “ex-ante” regulation before the platform was fully developed and implemented.

Conclusion

Summary of results

The IDS case represents a unique and – in many regards – an extreme case of an MSP: first, it has been designed and developed by a multi-stakeholder alliance, and not by a single entity or keystone firm; second, the subject of analysis as presented in this paper is the early platform design phase, and not – as in many other studies – the platform adoption and use phase; and third, through its nature as a multi-sided data platform, the IDS case delivers deep insights regarding the use of data as a platform boundary resource. Table 11 juxtaposes the IDS case as an example of an alliance-driven MSP in contrast to typical keystone-driven cases.

Table 11 Juxtaposition of keystone-driven and alliance-driven MSP design
Full size table

With regard to RQ #1 (i.e. how alliance-driven MSPs come into existence and evolve), the IDS case suggests that the typical evolutionary stages of MSPs do not explain the emergence of alliance-driven MSPs (and their evolution during the early platform design phase). In contrast to the lifecycle of a keystone-driven MSP consisting of 1) the phase of innovation, 2) the phase of adoption, and 3) the phase of scaling, the foundation of the alliance itself is based on adoption in the first place. After the adoption of the platform concept has led to the institutionalization of the alliance, innovation activities start as a consensual process in the second phase of the lifecycle.

Regarding RQ #2 (i.e. how different stakeholder groups use certain governance mechanisms during the early phase of an alliance-driven MSP’s lifecycle), it has to be noted that shared platform ownership differs from other ecosystem based approaches, such as open-source communities. In contrast to such other approaches, alliance-driven MSPs like the IDS rest on a formal institutionalization and demand execution of ownership rights. Thus, governance mechanisms do not follow a hierarchical institutionalization, but require ecosystem coordination. Examples of such governance mechanisms are the statutes and rules of the IDS Association, the organization of working groups and task forces, and the establishment of collaborative processes (e.g. for the development of the IDS Reference Architecture Model). Furthermore, the IDS case suggests a more differentiated conceptualization of MSP ecosystems. Literature predominantly understands MSP ecosystems as being composed of the platform owner and different user groups/sides. The IDS case shows, however, that there is an “inner” ecosystem (formed by the alliance members) and an “outer” ecosystem (composed by the alliance itself and by non-alliance, i.e. non-member, user groups and sides).

As for RQ #3 (i.e. how regulatory instruments are deployed to foster the adoption and use of an alliance-driven MSP), it is this interaction between the inner and the outer ecosystem that is regulated by such instruments. Trust, security, data sovereignty, and interoperability have been major drivers of the IDS initiative, and are therefore also reflected by the design of possible interactions between data users and data providers in the IDS. The IDS case suggests that common or shared interests that lead to the creation of an alliance-driven MSPs do not per se focus on purely economic or even profit maximizing goals of the platform provider. Instead, by searching for a “common denominator” (see Table 5), alliance-driven MSPs are – at least to a certain extent – of an infrastructural nature, which has an impact on the design of the regulatory instruments.

Contribution to the body of knowledge

The IDS case study presented in this paper aims at advancing the body of scientific knowledge with regard to the early stages of an alliance-driven MSP’s design phase. In doing so, it lays a foundation for the conceptual understanding of alliance-driven MSPs as such. The findings from the case study suggest that – in contrast to keystone-driven MSPs – different evolutionary paths can be pursued during the early stages of an MSP’s lifecycle. These findings pave the way for a more differentiated analysis of the evolution of MSPs – which is even more useful as the variety of ownership models for MSPs is likely to grow in the future.

Furthermore, the study is among the few that focus on the early platform design phase. It thereby yields detailed insights regarding the coordinating and consensus-finding activities during these early stages of the lifecycle. In the case of the IDS, adoption of the platform purpose and value proposition took place before the platform itself was designed. Thus, the typical sequence of 1) innovation, 2) adoption, and 3) scaling with regard to MSPs does not apply to the IDS case.

Moreover, the IDS case contributes to the body of scientific knowledge by putting the focus on data as a boundary resource of an MSP. The dual nature of data as both a social and a technical boundary resource requires data governance rules and shared data management processes, which need to be distributed between the different user groups (i.e. platform sides). The strategic nature of data has led to a complex ecosystem structure including specific roles for data provenance and data sovereignty. Moreover, the findings add to the understanding of data governance requirements in inter-organizational data sharing platforms in general.

Besides its contribution to research, the paper may have an impact on the current debate in the practitioners’ community. The IDS case yields in-depth insights regarding the establishment of an alliance-driven MSP. In doing so, it may be useful for current and future endeavors both on a public level – e.g. the European Union’s strategy towards a European Data Space (European Commission 2018) – and on a private level, such as the NEVADA initiative by the VDA (2016).

Limitations and further research opportunities

Limitations of the study stem mainly from its research design. A single-case study can only produce preliminary results with regard to a phenomenon of interest. The findings should be triangulated and validated using additional cases both with regard to alliance-driven and keystone-driven MSPs.

Furthermore, it has to be noted that the IDS case study examined the early stages of the design phase of an alliance-driven MSP only. The IDS initiative is gaining more and more momentum, and use and scaling activities are currently on their way. Thus, the efficacy of the initiative as such, as well as of the regulatory instruments chosen, has yet to be examined.

Further research opportunities exist in multiple areas. For example, the phenomenon of data-centric MSPs is still largely unexplored. Given the growing importance of data as a strategic enterprise resource, and the increasing emergence of commercial data-centric MSP offerings from software and technology providers, there will be an increasing demand for theory analyzing and explaining these phenomenon. Furthermore, the preliminary findings from the IDS case study should be examined further, both from an economic and an engineering perspective. The exploratory analysis of regulatory instruments should be taken further towards investigating the interdependence among these instruments and between them and market oriented instruments (such as pricing). With regard to the design of data-centric MSPs in particular, the data governance rules and data management processes designed in the IDS research project can be considered a promising starting point for more detailed investigations.