Cooperative Approaches to Data Sharing and Analysis for Industrial Internet of Things Ecosystems

Abstract

The collection and analysis of industrial Internet of Things (IIoT) data offer numerous opportunities for value creation, particularly in manufacturing industries. For small and medium-sized enterprises (SMEs), many of those opportunities are inaccessible without cooperation across enterprise borders and the sharing of data, personnel, finances, and IT resources. In this study, we suggest so-called data cooperatives as a novel approach to such settings. A data cooperative is understood as a legal unit owned by an ecosystem of cooperating SMEs and founded for supporting the members of the cooperative. In a series of 22 interviews, we developed a concept for cooperative IIoT ecosystems that we evaluated in four workshops, and we are currently implementing an IIoT ecosystem for the coolant management of a manufacturing environment. We discuss our findings and compare our approach with alternatives and its suitability for the manufacturing domain.

1. Introduction

As a global network that enables real-world assets to interconnect, intercommunicate, and interact digitally, the Internet of Things (IoT) is of interest for all industrial domains that deal with physical goods, where manufacturing is prime. IoT technologies allow organizations to automatically generate digital representations of physical objects that can capture their real-world identities, locations, and states (digital objects). The collection, integration, and analysis of such data enable companies to implement new types of services [1]. Examples documented in the literature include predictive maintenance services for machinery and equipment, process mining for determining bottlenecks in complex production environments, fine-tuning of recipes and sequences for process manufacturing [2], optimization of plant availability, energy management, monitoring and analysis of production and logistics processes [3], and new approaches to the management of packaging [4]. The context of most of these scenarios is not an isolated workplace or an individual asset but an environment with a variety of components embedded in large processes. The necessary data for such services can quickly cross company borders [5]. Data are often owned by a multitude of organizations, such as the manufacturing company, provider of (smart) machinery, suppliers of parts and materials, operator of smart sensors, logistics and transport enterprises, possible customers, and more. This entails the necessity for those organizations to cooperate to design innovative, analytics-based business models, such as machinery as a service, production on demand, or asset benchmarking [6,7]. In the academic literature, respective collaborations are discussed under the subject of IoT ecosystems [5]. An IoT ecosystem denotes a community of interacting firms that compete and cooperate using a common set of core assets and digital objects [5].

To date, viable IoT ecosystems have predominantly been created around a focal company that usually also acts as a platform provider and introduces financial, technological, and human resources for state-of-the-art data collection and analytics [8]. The advantage of a large and powerful focal company is that it can represent entire value chains and enforce IoT data provision by leveraging its dominant position [9]. The unprecedented power of such players is a relevant (and justifiable) acceptance barrier to enter such constellations–especially for small and medium-sized enterprises (SMEs). Many SMEs, particularly those active in high-tech manufacturing markets, rely on keeping a technological or a business edge that can be easily lost when critical data get into the wrong hands [10]. To counter the platform providers’ dominance, it has been proposed to include independent data trustees or platform-neutral “data spaces” [11]. Such entities increase reliability and reduce reticence [12]. However, even when neglecting the fact that in doing so, they introduce a level of indirection and complexity that is not conducive to easy implementation of a cross-border analytics scenario for SMEs, they cannot erase the reality of the platform provider remaining in a unique position of power [8]. For these reasons, data sharing applications are a niche segment [13].

An alternative approach is the formation of an IoT ecosystem for SMEs without direct or indirect dependency on a focal company. To facilitate this, it has been proposed to coalesce ecosystems around well-defined and commonly pursued core value propositions in which the capabilities of the various partners are combined [14]. This scenario also entails a rationale for pooling shared resources (i.e., the data and resources needed to implement the IoT analytics solutions) [15] in a joint unit owned by the ecosystem– and not just owned by a single entity of the network or an external enterprise. Several countries have dedicated legal frameworks for founding such bodies, usually under the label cooperative (although the subsumed organizational settings, traditions, legal characteristics, and associated values vary greatly across different countries) [16]. Here, we define a data cooperative as a legally independent business entity owned by a business network or ecosystem that is dedicated to cooperation in the field of data sharing and analysis.

In this paper, we address two research questions:

(1)

Is a data cooperative an appropriate approach to enable the sharing and analysis of IoT data in a business ecosystem?

(2)

Design-oriented follow-up question: What building blocks must be specified to successfully implement a data cooperative for IoT data?

In the following sections, we first provide an overview of related research in the fields of IoT, IoT analytics, and IoT ecosystems. Subsequently, we present the design and results of two series of qualitative and explorative expert interviews in the German cooperative sector, as well as with industrial IoT experts. The results were used to formulate suggestions regarding the relevant building blocks and were consolidated into a data cooperative concept, which was evaluated in four expert workshops. We also present our experiences in a pilot implementation process for a data cooperative in the context of coolant management for manufacturing processes. The paper concludes with a critical reflection of the approach in general and its suitability for the manufacturing domain in particular.

2. Related Work and Background

Our research draws heavily from the literature on IoT and smart manufacturing, business intelligence and analytics (BIA), and business and IoT ecosystems. The IoT part introduces concepts for understanding the underlying infrastructure and its connection to the digital (and thereby analytical) world. The data side of the research comes from the BIA literature, which provides insight into building analytical solutions and supporting organizational structures and processes. This includes aspects of the design, implementation, and management of self-contained analytics solutions. Under the term “analytical solution,” we subsume both descriptive (reporting and OLAP, dashboarding) and predictive analytics (mostly with machine learning methods, which themselves are subsumed under the umbrella term artificial intelligence). The areas of business and IoT ecosystems were central to conceptually capturing the economic side of our endeavor and therefore imperative for a holistic view of the subject. Aspects of accounting and pricing turned out to play a central role when data are supposed to be moved to a data cooperative.

We included three academic organizations in our research consortium specializing in the respective fields. Moreover, we included an association for cooperatives to provide the practical and legal background necessary for framing a viable solution.

2.1. Internet of Things and Smart Manufacturing

Unlike “the” Internet, IoT is a concept that is more than a well-defined stack of technologies or protocols. It is usually characterized by its core characteristics [17]: a global digital connectivity of real-world assets via the digital (Internet) sphere, a representation of physical objects as identifiable digital objects, and a capturing of state and possibly location data on the physical objects with (smart) sensors. Sometimes, digital objects can also trigger actions in physical objects.

In the field of IoT, a digital representation of a physical asset consists of three parts: the physical object in the real world, an associated digital object, and the data flow that connects both [18]. Notably, the relevant data differ from classical master or planning data because these include the current states of the real object (and possibly the history of those states), as well as analytical models that capture, describe, and/or predict the dependencies between various measured values and the object environment. The described schema allows the addition of functions to change the state of the digital object, which can, in turn, be transferred to the real object, thereby moving the control of the physical system into the digital realm [5,6,19].

IoT solutions have been used in a wide variety of application domains. In addition to consumer products, IoT has been applied to business applications across various industry sectors, such as energy, health care, and manufacturing [20]. This aspect of IoT is discussed under Industrial IoT (IIoT), with the Industrial Internet Consortium (IIC) as a leading standardization body. For manufacturing, the subject of IIoT is connected to the concept of Industry 4.0, which envisions IIoT-based decentral manufacturing as a fourth industrial revolution [21]. By focusing on aspects of production and logistics, Industry 4.0 standards complement the broader but are less specialized IIC concepts [7].

IIoT/I.4.0-based manufacturing solutions are the building blocks of smart factories [22]. This, in turn, is a pillar of the more general concept of smart manufacturing [23], which the NIST defines as a “fully integrated, collaborative manufacturing system that responds in real time to meet changing demands and conditions in the factory, supply network, and customer needs” [24]. The common theme across these concepts is the vision of agile, decentral-organized manufacturing systems that are not hampered by the established hierarchical systems of the past.

For many established SMEs in the manufacturing sector, such far-fetched visions are not easily attained, given their existing “brownfield” environments that often mix state-of-the-art technologies with decade-old legacy equipment. However, they can very well insert specific IIoT applications into their shop floor environments either by bringing in selected “smart” machinery, buildings, transportation materials, or parts or by retrofitting existing objects [25,26].

A concept for a data cooperative for SME ecosystems needs to be able to navigate such environments [27]. It is, therefore, advisable to formulate it separately from a narrowly defined set of standards, an isolated technology stack, or even a selected platform or product. Therefore, we decided to design our concept in this regard and pursued a technology-agnostic and generalizable concept.

2.2. Business Intelligence and Analytics

Many of the applications discussed under the terms IIoT, smart factory, or smart manufacturing are tied to analytical solutions. Corresponding frameworks like the industrial Internet Reference Architecture by the IIC are designed as blueprints for building the data side of an IIoT solution [28]. This includes locating analytics functionality in overarching (cloud) platforms, cloud-like solutions that offload analytics to the application premises (fog computing) [29], or analytics conducted directly at the point of data origin (edge computing) [30]. Fog and edge computing have become particularly relevant in smart manufacturing environments owing to confidentiality and safety or for dealing with data that need to be processed with a high velocity (e.g., sensor data), or that is challenging to transmit because of its volume (e.g., video and image content) [31].

A schema for the specification of an analytics solution can be drawn from the literature on business intelligence. Since the beginning of the century, integrated approaches for decision support (that include the collection, transformation, and analysis of data) have been applied under the umbrella term business intelligence (BI) [32]. Recurring insight is the need to consider a logical architectural layering of analytical solutions with a data layer that handles the data ingestion, transformation, integration, and storage (including the storage of data histories), a logic layer that includes the actual analytical processing, and an access layer that handles the presentation and distribution of the analysis results [33]. The concrete specification of those layers can be performed with respect to different levels of abstraction from the hardware and the closeness to actual business content. Relevant levels of business specificity encompass:

• The infrastructure level (e.g., data storage based on a cloud-based object store, an independent edge device, or a federated relational database),
• The software level (e.g., a dashboarding solution or an analytics-oriented programming language like Python or Julia), and
• The level of actual business contents (e.g., data models, transformation logic, report design, and applied analytical models).

Eventually, there is a distinction to be made between the provision or development phase (e.g., data modeling, report design, or machine learning (ML) training) and the operation of the service. An analytical solution can be defined by the interplay of services that span those architectural layers, levels of business specificity, and lifecycle phases [34]. Figure 1 illustrates this approach with examples in the domain of smart manufacturing.

Notably, this logic can be applied to define purely local analytics solutions. However, as we strive to support IIoT business ecosystems, we deem it necessary to design all solutions in a way that they remain integrable into overarching cooperative solutions on a platform layer (the local solution acts as a sort of “analytical atom” in this regard [35]).

While the overall structure of this framework has remained stable over the years, the internals of the individual architectural layers have undergone significant changes. Most notably, the data layer now regularly includes Big Data components that can handle high velocity, high volume, and high-variety data for which “classical” BI components like a relational data warehouse or data mart are not designed [36,37]. The logical layer has seen a shift of attention toward more predictive analytical systems owing to the rise of ML [38]. In ML, models are not entered in detail by a modeler or programmer but rather are derived from data [39]. ML has made significant leaps, particularly within the field of artificial neural networks with a multitude of layers, that is, deep learning. Deep learning allows the iterative recognition (or manipulation or even generation) of complex features in unstructured data (images, videos, audio, speech, and text) [40]. This has opened opportunities for the design of a new set of analytical IIoT and smart manufacturing applications. Examples include the analysis of imagery for quality assurance on the shop floor [41,42] or the supervision of compliance with safety regulations [43]. With the inclusion of image and video sensors into an IIoT environment, the requirements explode, which leads to requirements for specific big data infrastructure, software, and content.

Orthogonal to the architecture side, a recurring theme in the analytics literature is the need to complement the discussed systems with a suitable IT governance that defines the structures, processes, rules, and responsibilities for their provision and operation [44,45]. This particularly includes aspects of governance related to data quality and data governance [46]. In that regard, it is significant that, especially in the field of IIoT, analytics is increasingly distributed across a variety of players that each brings different capabilities [47]. The challenge for analytics governance is to bring the capabilities together to provide solutions as compositions of well-defined analytical services that subsume the data, logic, and access layer [34].

2.3. Business and IIoT Ecosystems and Aspects of Accounting

In general, a business ecosystem can facilitate joint value creation by bringing different actors together [48]. We follow Ron Adner’s ecosystem concept, which defines a business ecosystem as a collaborative structure in which value is provided collectively based on a central value proposition [14]. This value proposition also forms the heart of the ecosystem and requires the partners to align their activities and capabilities. Notably, an ecosystem can very well include partners that are competitors outside the joint value generation scenario, which sets the ecosystem apart from more closed forms of business networks. Meanwhile, it goes beyond the loose fog of selfish actors. This sort of selective cooperative setting aligns very well with our data cooperative concept (cf. Section 1). The basic elements to describe such ecosystems are the actors involved, activities and capabilities of the actors, positions of the actors in the ecosystem, and relationships between them (see Figure 2) [14].

The information systems literature distinguishes between different types of business ecosystems, such as platform, innovation, and knowledge ecosystems. In our study, we focus on IIoT ecosystems, which are a subtype of a platform ecosystem [49] in which the member enterprises compete and cooperate based on a common set of IIoT assets that are connected over a platform [5]. An IIoT ecosystem can bind partners from different domains, technologies, and processes [7,50]. This is illustrated in Figure 2.

We understand the formation of a data cooperative as a manifestation of a business ecosystem in the Adner sense that has the purpose of sharing and analyzing data. As we also focus on IIoT data, the data cooperatives we are investigating are also considered variants of an IIoT ecosystem. In this context, the tangible data cooperative is a separate legal entity that incorporates coordination responsibilities for shared resources. Figure 3 shows the resulting typology.

Where they are established, cooperatives have stood the test of time and have proven to enable SME business ecosystem settings, for example, in the sectors of agriculture, banking, retail, and manufacturing. The German literature on cooperatives claims that the long-term success of German cooperatives stems from their three guiding principles of self-help, self-administration, and self-responsibility. The principle of self-help states that a cooperative does not receive external support, for instance, from a government body or an external enterprise. The principle of self-administration means that the cooperative is managed by the ecosystem participants in a democratic fashion. Self-responsibility implies that all members of the cooperative have a defined set of rights and responsibilities. The interaction of these principles is seen as the basis for the creation of a space of trust in which the participating partners come together on equal terms [16,51].

One aspect that needs careful consideration when implementing a cooperative is the measurement and sharing of the generated benefits, aspects of accounting and reporting, and the recognition of revenues. While this is not easy for any cooperative scenario, the sharing and utilization of data bring specific challenges. In fact, data sharing initiatives are quickly impeded by issues of acceptance that result from the perceived (un)fairness of the sharing of costs and benefits. The intangible nature of data and the implications of the information paradox–the benefits of the utilization of information are often only measurable ex-post–make the development and coordination of revenue and cost structures in a data cooperative particularly challenging. We assume that this, as well as overall governance, has relevant implications for the acceptance of the endeavor.

3. Research Design and Methodology

The two central research questions are aimed at identifying the role and the relevant building blocks for a novel type of organization: a data cooperative that supports SME ecosystems. The novelty concerns several core aspects of our research: the type of organization, a data cooperative; the configuration of an IIoT ecosystem that is grouped around a central cooperative; the aspect that the members are SMEs that individually mostly lack capital, experience, and analytical resources for extensive analytical initiatives; the aspect of data sharing across enterprise borders for analytical purposes (which is rarely seen outside a few niche scenarios); and the related aspects of governance, acceptance, and accounting in an ecosystem formed by equal SME partners. We conclude that we cannot draw the answers from literature alone. A quantitative study is not possible either, as we cannot even fully understand the relevant aspects to be included in a questionnaire. Our research is, therefore, explorative by definition, and we need to identify the potentially relevant building blocks of a data cooperative, their dependencies, and their interplay, as well as the reasons that support or speak against their inclusion. As such, we strive for hypothesis generation rather than hypothesis testing, and our methodology, both for data gathering and data analysis, is based primarily on the literature on qualitative research [52].

Following a common best practice in qualitative research, we begin by deriving a conceptual framework that structures the areas of insight we are focusing on [53]. We see that the most relevant “unknowns” are not primarily located in the areas of IIoT and analytics technology. While there are open questions on how IIoT analytics services are tailored for a data cooperative (e.g., regarding the degree of the federation, the data models, the inclusion of big data components, etc.), we already know the relevant building blocks and have a schema for specifying them (cf. Section 2.2). The largest knowledge gaps remain in the successful organization of a cooperative, division of roles of the cooperative and surrounding ecosystem, aspects of IT and data governance, accounting and pricing, and in aspects of organization and acceptance for sharing analytical data. Combined with the areas of novelty, this leads to the conceptual framework depicted in Figure 4. This framework guided the design of our interview questionnaire and the analysis of our results.

As there is no existing sample of data cooperatives, we decided to collect data from two unconnected samples with different, complementary perspectives: interview series 1, with existing business networks, and interview series 2, with experts in data sharing and analysis. The first series is concerned with the cooperative approach. For the respective insight, we conducted 14 semi-structured interviews with representatives of German cooperatives from a variety of industries (cf.

Table 1. Overview of the two interview series.

Interview Series 1 with Existing Business Networks	Interview Series 2 with Experts in Data Sharing & Analysis
CO1 Cooperative in the context of a large winery	DS1 Logistics and supply chain with object tracking and analysis
CO2 Cooperative in the trade of bedding supplies	DS2 Streaming IoT data for analysis, fishing industry
CO3 Cooperative in the context of bakeries	DS3 Analytics infrastructure for device coordination; drone hospital deliveries initiative
CO4 Cooperative in the context of energy distribution	DS4 Floor planning for smart factories
CO5 Cooperative in the context of supra-regional banking and finance	DS5 Optimizing plastic injection molding machines
CO6 Cooperative in context of agar products and services	DS6 Port traffic management
CO7 Cooperative in the context of open-source software development	DS7 Port traffic management
CO8 Cooperative in the context of regional banking	DS8 Data analysis for smart factories and smart logistics in retail
CO9 Cooperative in the context of regional banking
CO10 Cooperative in the context of regional banking
CO11 Cooperative in the context of regional banking
CO12 Cooperative in the context of logging and forest management
CO13 Cooperative in the context of wood wholesale
CO14 Cooperative in the context of specialized consulting

Note: Due to the COVID-19 pandemic, all interviews of the second series were conducted in a virtual setting.

, left column). The smallest cooperative we interviewed (CO14) had 12 members, whereas the largest cooperative (CO11) had 43,960 listed members; the mean member number was 13,038; thus, our sample included small, medium, and large cooperatives. Although these are not data cooperatives, there is a large area of overlap with the issues they face, particularly with respect to general questions about the organization of a cooperative, questions on how to deal with resource sharing and pricing, and governing a business ecosystem. Some interviewees also brought in experiences with the provision of general IT services and related questions on IT governance. For data sharing and joint analysis, we interviewed eight members of IIoT projects (with two exceptions all coming from the IIC) that all involved data sharing and data analysis across several enterprises (interview series 2). Unlike in the first interview series, the organizations in the second were mostly large companies [54,55].

The average interview duration was approximately 70 min. All interviews were fully transcribed, coded, and iteratively condensed to obtain higher-order insights that were transferred to the subject of IIoT data cooperatives (each subject was conducted by a team of two coders). Therefore, a qualitative content analysis was performed [56,57]. We checked the plausibility as well as the consistency of all our results and evaluated and refined them in four workshops with external participants (one with members of the association of cooperatives, two with representatives from cooperatives, and one in a dedicated session of an IIC member meeting). We compiled our findings in a concept for a data cooperative; a bird’s eye view of this concept is depicted in Figure 5.

4. Findings

The following section presents the consolidated results of the interviews and the four evaluation workshops. They form and fill the concept of Figure 5, which also shows the identified macro building blocks. The left-hand side includes building blocks for specifying how a data cooperative is embedded into an IIoT business ecosystem (macro view), namely the goal of the cooperative, roles the cooperative and the members assume, as well as their fundamental services and the service interplay, including a catalog of IIoT analytics services. The right-hand side shows building blocks that organize the internal structure of the cooperative (micro view), namely the specification of the IIoT analytics solutions, IT and data governance, the accounting and pricing system, and measures to ensure trust.

We consider these to be of specific relevance for data cooperatives, and therefore an answer to our second research question. Notably, each of these blocks comes with a set of sub-components for which we identify various design alternatives.

Both interview series support the assumption that a cooperative can facilitate the sustainable provision of joint services based on shared resources, directed at a joint value proposition. First, a cooperative can act as a neutral and trustworthy intermediary that is obligated to work in the interests of the ecosystem (CO14). Second, by formally fixing the rights and responsibilities of the members, it provides an extrinsic obligation to cooperate (CO6, CO10, CO13). In fact, in the shared port management initiative discussed in DS6, the lack of a respective binding agreement with clear roles, rights, and responsibilities, as well as the absence of a central entity for enforcing them, were deemed to be the main reasons for the limited success of the solution. Despite being beneficial for all partners, most did not contribute their data even after agreeing informally to do so during project initiation. Third, as a cooperative has its own legal identity, it is capable of coordinating external suppliers and/or customers, which is crucial for resource pooling and sharing. Examples can be found in the sharing of machinery in the winery sector (CO1), wood distribution channels (CO12), or bakery equipment (CO3). Fourth, the formation of the cooperative also fostered the adherence to the cooperative principles and brought a more intrinsic sense of unity across the members with some expressing pride in participating in a cooperative (CO2, CO3, CO4, CO12) (a participant from CO12 describes it as the “cooperative gene”).

4.1. IIoT Analytics Solutions

As stated above, this building block is taken as given and is not at the center of our interviews. Nevertheless, we elicited the solutions designed in the initiatives of the second interview series with experts in data sharing and analysis (following the three-layer three-level two-phase framework introduced in Section 2.2, Figure 1). Unsurprisingly, given our sample of IIC projects, we found some highly sophisticated IIoT analytics solutions. The fishery solution of DS2 is built utilizing a lightweight, yet highly scalable infrastructure for global data streaming. For the drone setting of DS3, a multi-layered infrastructure is used for complex, deep-learning-based path predictions for drone steering. DS4 applies extensive simulations and optimizations. DS5 builds services based on a variety of state-of-the-art classification and regression algorithms, and DS6 applies image segmentation and object detection to traffic video streams with single-board computers (mostly to handle the insufficient willingness of other network participants to share structured traffic data). In all cases, some degree of data sharing is the basis for the analytics solution, even if most of the organizations are not SMEs.

Finding 1: The results support the conclusion that data sharing is an enabler for state-of-the-art analytics services.

4.2. Goal of the Cooperative

All cooperatives in our study have formulated an explicit goal for cooperation (as required by the German cooperative law), and they can also name benefits for all types of their members. While in two cases, some of those benefits appear rather lofty (“support the region” in CO10, “foster open-source development” in CO7), they can all name tangible (and, in most cases, monetary) benefits, and therefore reasons to fund the cooperative. For example, in CO3, the cooperative can realize economies of scale by concentrating purchases for bakery ingredients; the affiliated bakers and confectioners can thereby immediately profit from lower prices. In CO4, members are supplied with renewable electricity at a cost price. This also sets it apart from some of the IIoT projects in the interview series on joint data sharing and analysis, where the existence of the ecosystem is primarily driven by a government mandate (DS3), the pressures of a focal enterprise (DS7, DS8), or a technical feasibility study with a defined expiration date (DS5, DS6).

Finding 2: It is advisable for a cooperative to formulate an explicit purpose and identify tangible benefits for all members.

All cooperatives interviewed in the first interview series are based on a joint value proposition that can only be achieved cooperatively. This is obvious for cooperatives that are built primarily to achieve economies of scale by bundling purchasing or sales activities like the bakery cooperative in CO3 or the procurement of beds in CO2. Interestingly, the latter also provides a means for cooperative design and financing of the beds. The CO14 cooperative focuses on the joint development of surface technology.

Finding 3: The cooperative has to be formed by the members to realize a cooperative value proposition.

4.3. Roles of the Cooperative and Members

Based on the first series of interviews with existing business networks, it was possible to derive a catalog of roles that are potentially relevant for the cooperative and the ecosystem, which we also consider fitting for an IIoT data cooperative. Unsurprisingly, the number of roles in the various cases and their distribution varies widely as a result of the different industries in which cooperatives are active. We observed a continuum of options between centralized models in which the cooperative takes over a wide set of roles and fully decentralized models in which the cooperative is only active as a coordinator between the members and external service providers. While we have no clear decision rule so far as to when to centralize and when to decentralize, we see the decentral model more in small ecosystems that can only carry a more lightweight cooperative.

Finding 4: A cooperative plays a coordinative role. It can also play a variety of additional roles, especially in larger ecosystems.

The coordinator’s role can manifest in various forms. In CO3, the cooperative coordinates the construction of new bakeries and is thereby the interface to architects, civil engineers, and investors. Most cooperatives are entrusted with tasks of procuring or trading goods for their members, such as cooperatives in CO6, CO12, and CO13 in product distribution, e.g., power saws (CO12). Some also handled the production of, for instance, the winery of CO1. For a data cooperative, this would imply the procurement of not only IT services (hardware, software, development, operations) but also the procurement distribution of information products.

Finding 4a: Next to coordination, the procurement and distribution of goods is a common role for a cooperative.

We also find some roles connected to the provision of financial services and not just for cooperatives in the banking sector. The identified roles include the capital provision, investment management (CO2, CO5, CO8), insurance (CO5), payment processing (CO5), and deposit protection (CO3, CO5). In DS2, data sharing is directly linked to the handling of loans (depending on the data of the fish).

Finding 4b: A cooperative can also provide, or coordinate financial services.

Moreover, large ecosystems sometimes come with a complex hierarchy of additional organizational bodies, such as member representation (CO1) or strategy formation (CO8 and CO11). In the latter case, a “second-order” cooperative was founded by a large number of smaller cooperatives. From a more long-term perspective, such settings might be interesting for the data cooperative world.

In the CO3 interview, the cooperative was found to also have a consulting role with a focus on legal questions. The CO7 cooperative offers education and training services for complex open-source solutions in the field of real-time data streaming.

Finding 4c: A cooperative can act as a consultant for the ecosystem members.

Some IT-related roles were also found in the interviews, most importantly an infrastructure provider (CO1, CO3, CO5, CO6, CO7, CO9, and CO12). In these cases, there is a separate data center that is available through the cooperative (in fact, the infrastructure provider here is a joint subsidiary of the cooperatives). An application provider was identified in CO12, and a data analyst was active in CO1. In the CO5 and CO9 interviews, a data provider appeared in the form of an organization that provided data for analyses.

In the evaluation workshops, the participants voiced strong concerns against the suggestion to insert an IT provider as an additional member of the ecosystem; the IT-related roles are seen either as located within the cooperative itself or at least as being coordinated by the cooperative. An IT provider is regarded as coming into a position with too much power, thereby destroying the balance of and trust in the ecosystem.

Finding 4d: A cooperative can become an infrastructure and application provider. It is not advisable to include an IT provider as a member of the ecosystem to take over these roles.

For data cooperatives, the set of roles derived from the interviews can be complemented with:

• roles for the management of the IIoT infrastructure,
• data analysis (the provision and operation of analytics services on the different layers and business specificity levels), and
• data governance (such as data stewards, data scientists, data analysts, data engineers, and owners, as documented in the data governance literature).

4.4. Services and Their Interplay

A common theme in our findings is that each of the identified roles is tasked with the provision of a distinct set of goods and services. Most of these are defined in a formal binding manner in a service catalog that delineates the specified requirements. The exchange of goods and services is also tied to financial transactions: mostly to a defined price. Examples of such services were given in interviews CO2 and CO4; in interview CO2, the procurement and sale of goods in various forms were named a service, while in interview CO4, it was the physical provision of energy.

For physical services, it was simple to identify the related financial transactions. Sometimes, accompanying services for the exchange of data and information were given. An interviewee of CO3 mentioned the provision of data from coffee machines. In interview CO8, the exchange of analyses in relation to benchmarking between different banks was mentioned as a supporting service. Notably, for data- and information-related services, the interviewees had difficulties in clearly stating the financial side. Future research should focus on the interplay between digital services and associated financial transactions.

Finding 5: Defining and tying financial transactions to nonphysical data-based services is identified as a challenge.

4.5. IT and Data Governance

Our results on IT and data governance mirror the findings of those on the roles and services. There is a continuum of options between a strong cooperative and a more decentral handling of governance-related questions. This particularly applies to the IT strategy definition (CO2, CO5, CO9, CO10, CO11), responsibility for the process and product development (CO2, CO3, CO4, CO5, CO6, CO7, CO8, CO10, CO11, CO12, CO13), formulation of a binding and formal code of conduct (CO10, CO7, CO6, CO2, CO3, CO8, CO12, CO13, CO4, CO14), centrality of defining data access rights (DS1, DS4, DS8), and standardization of data quality requirements (DS8). A prominent factor that seems to influence the degree of centrality seems to be the competition between the ecosystem members. The more competition there is, the more it is deemed necessary to have strong and formal governance that is handled by the cooperative (CO2, CO8, CO13, DS7).

Finding 6: Competition between ecosystem members demands a central and formally defined IT and data governance.

Furthermore, consistent with the coordinative role of a cooperative, the cooperative is seen as an interface of the ecosystem to external IT or analytics providers (CO2, CO3, CO4, CO6, CO7, CO8, CO10, CO11, CO12).

Finding 7: The data cooperative can act as an interface between the business ecosystem and external IT or analytics providers.

We identify the definition of verifiable data integrity requirements (DS2), setting the visibility of the data for the different members (CO5, CO11, DS1), automation of data quality tests (DS7), and a classification of data according to relevance and confidentiality (DS7) as data governance measures that seem to be advisable in a data sharing cooperative.

Finding 8: The data cooperative should be responsible for a variety of central data management tasks.

4.6. Accounting and Pricing System

Our findings indicate that a transparent cost accounting and pricing system for cooperative goods and services is central to their viability and acceptance. For example, as the interviewees of CO11 and CO9 pointed out, regular and detailed reporting on costs and pricing (decisions) supports transparency. CO14 states that a common standard for costing and pricing supports the creation of commitment. In CO10 and CO5, it is stated that if a trusted unit sets the respective standards (e.g., a state regulator or an elected committee of member representatives), this fosters clarity and transparency and thus the acceptance of the cooperative. In the same vein, it is stated in CO10 that democratic and participatory decision-making on pricing is of particular importance.

Finding 9: A transparent costing and pricing system can improve perceived fairness and thus influence the acceptance of the cooperative.

Such a pricing system can become very complex, as it needs to accommodate different companies that are active in different markets and because it needs to consider a variety of soft factors. This is particularly evident in CO1 where a “grape price” is calculated based on a highly complex formula. Such challenges need to be dealt with pragmatically, and this implies that some degree of imbalance needs to be anticipated and accepted. Here, a particular adjusting screw comes into play: the membership fee for the cooperative. Such a fee is mostly used to cover the overhead costs of the cooperative administration, but it can also be used to cover costs that are hard to distribute fairly or impossible to be traced to individual members of the cooperative. By contrast, the costs of self-contained and well-defined dedicated services usually can be better connected to their consumption (S8).

Finding 10: A suitable costing and pricing system should reflect inequalities and asymmetries among members of a cooperative.

4.7. Measures to Ensure Trust

We found that trust in the cooperative, in general, and data sharing with the cooperative, in particular, are results of most of the discussed measures, particularly those in the blocks “IT and data governance,” and “accounting and pricing”. Naturally, trust is difficult in larger ecosystems that involve competitors. The less intrinsic trust there is, the more important become formally specialized governance and well-defined pricing mechanisms.

However, we find that some measures are mainly motivated by the need to build trust. An occurring theme in that regard is measured to increase transparency in how data are handled (DS8). More specific measures include the pseudonymization or anonymization of data (CO3, CO8, DS2) and/or generated results/information, and the certification of the cooperative and/or the infrastructure and application providers (CO2, DS8).

Finding 11: Pseudonymization, anonymization, and certification can foster trust.

In Figure 6, the described findings are summarized.

5. Pilot Implementation in the Realm of Smart Manufacturing

We are currently implementing our concept in the domains of manufacturing, IIoT financing, and crafts. The objective of all cases is to establish sustainable data cooperatives for sharing and analyzing IIoT data. The manufacturing initiative has progressed the farthest, and we use it to illustrate how our concept can be applied in a real-world setting.

The manufacturing initiative is focused on data- and analytics-enabled coolant management. It currently comprises a manufacturing company, provider of coolant management equipment, and supplier of cooling lubricants. A common goal is to enable more efficient and effective coolant management. In general, coolant management is not only costly but also directly affects production quality and processes (the production needs to be stopped for coolant replacement), as well as causing potential health hazards (risk of toxic fumes).

The manufacturer wants to outsource as much of the coolant management as possible (including reporting tasks needed for compliance reasons), a task the lubricant provider is willing to take over as it wants to diversify its services. The equipment provider delivers innovative smart machinery (with a battery of sensors) and hopes to develop both its products and the market. The cooperative value proposition of the data cooperative is enabling a “cooling lubricant as a service” setting.

At the core are both descriptive and prescriptive monitoring and analysis services that are supposed to be managed mostly on a cooperative platform (although there are local “analytical atoms” needed as well for questions of the immediate coolant steering). The initiative started with basic reporting scenarios but has already explored more complex IIoT analytics services (e.g., the prediction of the time the coolant becomes problematic, the optimization of coolant recipes, or image analysis for coolant supervision).

In the current form, the data (including the data transformations and an expandable data model) and the logic and access components run in separate cloud environments for reasons of licensing, but the architecture is not final. All analyses require data from all partners who also provide different real objects: cleaning systems, manufacturing halls, machining centers, lubricants, and tanks. With the maturity of the pilot system, aspects of governance gain relevance; the consortium is currently exploring what level of confidentiality is needed for what data source and how to deal with data quality issues. This also leads to questions of pricing, as we found a plethora of tasks that need to be defined, assigned, and dealt with on the accounting side; for example, the installation and maintenance of the sensors, the ongoing correction of measurement errors, issues of data integration, requirements elicitation, model validation, and more.

To expand the database, better models and design further-reaching services are planned, as well as manufacturers of production equipment and/or insurance companies in the ecosystem. It is also possible to add further manufacturers and potentially lubricant suppliers, although this would immediately require stricter governance, accounting, and trust-building mechanisms, as the complementary nature of the current consortium would be lost.

6. Discussion and Outlook

In this paper, we present our concept for a data cooperative that we consider an enabler for SMEs to harness the vast potential of IIoT analytics despite limitations in capital, expertise, and IT resources. The idea is to draw together the capabilities of an SME ecosystem and concentrate them in a data cooperative that also acts as a legal entity owned by the SMEs. Our findings support the assumption that this is a viable solution to foster data sharing among SMEs and to enable innovative analytics solutions, which provide a preliminary answer to our first research question. We see this as a practical contribution and a theoretical one, as it fleshes out the body of knowledge on business ecosystems and data sharing. In addition, our concept also shows the relevant building blocks of a data cooperative (and thus provides an answer to research question 2). This not only expands our practical contribution but also highlights relevant research areas.

We consider data cooperatives to be of particular relevance for IIoT scenarios, especially for smart manufacturing scenarios. Manufacturing brings an innate need to combine various assets when producing physical goods, which are often owned by different partners. This is, even more, the case for highly specialized SMEs. Furthermore, there is a growing set of use cases for IIoT analytics in the field of smart manufacturing that can be made accessible using this approach.

As for alternatives, we consider the element of trust as an essential trait of a cooperative and, therefore, as an advantage over competing approaches. Data sharing in a cooperative is not done over anonymous interfaces open to a wide market but rather within a defined ecosystem of cooperating partners, none of whom is allowed the role of a focal player or a dominating platform provider. However, some alternative ideas to foster data sharing can complement our approach. For example, new solutions for data space provision (e.g., the EU GaiaX project) might supply a cooperative with an interesting technological basis and the possibility to facilitate the connection of multiple data cooperatives.

As discussed in Section 5, we are currently exploring our approach in the first pilot implementation. Backed by our evaluation activities, feedback from a large number of interested SMEs, and support of an association of cooperatives, we are confident that we have identified the relevant building blocks and that they will help us reach the actual legal basis of several cooperatives. Nevertheless, we acknowledge the limitations of our qualitative design. The variety of insight that arose during the derivation of the framework admittedly needs further quantitative scrutiny. We see this as a natural consequence of the novelty of our subject, as well as the scope of our research. We aim to provide a comprehensive and applicable concept, rather than test the isolated hypothesis.

Although our results are not as consolidated as we would like them to be, given the pilot status of the projects and the limitation in numbers, we consider it a solid conceptual basis for the organizational design of data cooperatives for SMEs. We are striving to constantly expand our knowledge base, include new experiences, and welcome inputs from all sides.