Introduction

In recent years, a large number of digital platforms emerged across industries. Digital platforms and their surrounding ecosystem form complex socio-technical systems that build on developing and managing an appropriate IT architecture and governance regime (Bazarhanova et al., 2020; Hein et al., 2020; Tiwana, 2018). In the uprising industrial Internet of Things (IIoT), the concept of digital platforms has received significant attention, leading to the emergence of more than 620 IoT and IIoT platforms by today (Lueth, 2019) and building a market that is growing by more than 26% a year until 2024 (Industry ARC 2019). Such IIoT platforms provide a digital infrastructure to connect industrial devices into digital networks to collect and process the generate data and consequently facilitate data-driven services (Pauli et al., 2020; Petrik & Herzwurm, 2020). Thus, Pauli et al. (2021) define IIoT platforms as middleware systems to support and integrate heterogeneous hardware, on top of which third parties can develop complementary applications. Such applications cover manifold solutions, such as production optimization through asset monitoring and advising, machine health monitoring through anomaly detection, or customer transparency through better traceability.

Addressing a variety of use cases, IIoT platforms differ considerably in terms of their underlying technology stack and architectural setup (Guth et al., 2018; Mineraud et al., 2016). This is partly due to the technical complexity in business-to-business (B2B) environments and the lack of established standards in the IIoT, leading to rather siloed development (Khan et al., 2020). Consequently, the IIoT platform landscape, while revolving around similar business objectives, is scattered. This creates several issues: first, it creates issues for companies that must understand the IIoT platform market to select a vendor that successfully integrates into their existing IT infrastructure. Companies lack a comprehensive scale to organize and guide decisions in the scattered IIoT platform landscape (Hoffmann et al. 2019). Second, it creates issues for complementors that need to understand the internal architecture of platforms when they are synthesizing their code (i.e., application) with platform resources to create new offerings that are competitively faring (Tiwana, 2018). Last, it creates issues for researchers and strategists that seek to understand the interplay of IIoT platforms’ architecture and business models, which are strongly interwoven in the context of digital business, in enabling a competitive advantage (cf. Cennamo, 2021; Zhu & Iansiti, 2012). Research has already put effort into investigating IIoT platforms, focusing on their business model (Hodapp et al., 2019; Petrik & Herzwurm, 2018), analytics framework (Moura et al., 2018), or design criteria (Werner & Petrik, 2019). However, we still miss a unified classification of IIoT platforms’ fundamental building blocks, which we subsume as architectural design options, to enable a transparent evaluation and comparison of existing IIoT platforms. Thus, we ask:

How can IIoT platforms be classified by their architectural features?

To answer this research question, we develop a taxonomy of IIoT platforms’ architectural features following Nickerson et al. (2013) guidelines. Taxonomies are well suited to lay the groundwork for emergent research fields and serve as a first step toward systematizing the fundamental design decisions (Williams et al., 2008). For taxonomy development, we use both the literature and empirical knowledge from 22 IIoT platforms as well as seven semi-structured expert interviews. For taxonomy evaluation, we classify 78 IIoT platforms and, thus, identify and conceptualize five archetypes of IIoT platforms.

Our taxonomy contributes to the descriptive knowledge in this ambiguous research field by explaining the architectural dimensions and prevalent manifestations of digital platforms in the IIoT. Further, we contribute to the prescriptive knowledge by elucidating the interplay between IIoT platforms’ architectural setup and their purpose. Lastly, our results provide a comprehensive overview of architectural dimensions that may guide managers in comparing and selecting a suitable IIoT platform to use as well as developers understanding a platforms’ architecture when developing applications.

Domain background

Digital platforms

Originally viewed as multi-sided markets that enable interactions between different actors, the digital platform concept increasingly captured innovation activities (Gawer & Cusumano, 2014). Today, digital platforms are a pivotal element for technological innovation, as the examples of Apple, Facebook, or Microsoft show. Capturing this essence, Tiwana et al., (2010, p. 675) see digital platforms as the “extensible codebase of a software-based system that provides core functionality shared by the modules that interoperate with it and the interfaces through which they interoperate.” Adding to this view, the network of third-party providers (i.e., complementors) that builds around a digital platform is often referred to as a digital platform ecosystem (Hein et al., 2020; Reuver et al., 2018). We adopt this view and see a digital platform as an extensible technological foundation on top of which third parties can build platform-augmenting applications. Within this view, architecture plays a significant role in the overall design of a digital platform (Spagnoletti et al., 2015; Tiwana, 2018). Generally, the architecture of a system refers to the structure of interactions among subsystems that constitute it (Tiwana, 2018; Ulrich, 1995). The architecture of a digital platform serves thereby as the “conceptual blueprint that describes how the ecosystem is partitioned into a relatively stable platform and a complementary set of modules that are encouraged to vary, and the design rules binding on both” (Tiwana et al., 2010, p. 677). Digital platforms’ varying architecture makes it possible to differentiate between them and determines their respective evolutionary path (Agarwal & Tiwana, 2015; Cennamo, 2018).

Digital platforms bring together three important stakeholders: the platform owner, complementors, and users. The platform owner runs and governs the digital platform. Complementors build on the digital platform and broaden its functionality with applications. The users consume the functionalities provided by the digital platform (van Alstyne et al., 2016).

Industrial Internet of Things

The Internet of Things (IoT) integrates technology-enabled physical objects into a global cyber-physical network (Oberländer et al., 2018). It uses recent advances in digital technology such as ubiquitous communication, pervasive computing, or ambient intelligence to connect these objects based on standardized communication protocols. With the help of these technologies, everyday objects turn into so-called smart things (Püschel et al. 2020). Prior research examines the IoT in terms of its architecture, for example, as a layered reference model. This often results in a multi-layer description of services offered at different architectural levels, depending on the business needs, technical requirements, and technologies (Fleisch et al., 2015; Porter & Heppelmann, 2015; Sisinni et al. 2018; Yoo et al., 2010). A common three-layer IoT architecture differentiates the perception, network, and application level (Jing et al., 2014). The perception level controls objects and collects data, the network level enables information exchange of the data, and the application level supports business services by analyzing the data. The application of the IoT concept in an industrial context received particular interest in recent years as it proved to be a prime example of its applicability and its underlying economic potential (Papert & Pflaum, 2017; Wortmann & Flüchter, 2015). Current trends in the manufacturing industry point towards combining traditional production, automation, and computational intelligence into a complex system known as the industrial IoT. The literature describes the IIoT concept with different names such as Industry 4.0, Industrial Internet, or Internet of Production (Boyes et al., 2018; Wortmann & Flüchter, 2015). The terms IoT and IIoT are occasionally also used synonymously (Hanelt et al., 2020; Hodapp & Gobrecht, 2019; Pauli et al., 2021). Sisinni et al., (2018, p. 4725) describe it as being about “connecting all the industrial assets, including machines and control systems, with the information systems and the business processes.” Thus, IIoT leverages the mechanical engineering industry into the digital era (Kiel et al., 2017). Through extraction and utilization of machine data, it is a key enabler for the creation of digital networks in manufacturing processes and ultimately lays the foundation for a smart production system (Pauli et al., 2020; Rehman et al., 2019).

Industrial Internet of Things platforms

IIoT platforms function as a middleware that orchestrates the heterogeneous device landscape in the IIoT and provides a technological infrastructure fostering connectivity and interoperability between smart machines, control systems, and enterprise software systems (Petrik & Herzwurm, 2020). On top of the technological infrastructure, applications provide data-driven services to platform users (Hodapp & Gobrecht, 2019; Pauli et al., 2021). These applications consequently extend the machines’ functionality by collecting and processing the generated data, thus generating additional value. The recent literature on digital platforms has largely abstracted on the technological characteristics of different platforms, treating all technological platforms as a rather homogenous group (Reuver et al., 2018). However, IIoT platforms significantly differ from other kinds of platforms, in particular those studied by the IS community so far. For one thing, IIoT platforms operate in a B2B environment. This entails higher technological complexity due to heterogenous industrial assets and devices, IT infrastructures, and processes compared to business-to- consumer (B2C) markets in which most digital platforms operate (Hein et al., 2019; Pauli et al., 2020). Further, this implies additional actors involved (e.g., developer, machine manufacturer, or sensor manufacturer) for integrating third-party solutions into users’ IT and business processes resulting in higher organizational complexity. For another thing, applications developed on IIoT platforms are often fragmented, addressing only one or few customers, or even being developed by customers for their own use (Pauli et al., 2020). This contradicts digital platforms’ underlying assumption of efficiently serving a heterogenous market and in this way attracting complementors and ignite network effects, respectively. Even though IIoT platforms operate in similar context, they specialize in different service offerings (e.g., equipping devices with digital technology and connecting them to the Internet, managing the machinery for more flexible production, or deriving new insights through analyzing data). To realize these services, they require different architectural features. As a result, the IIoT platform landscape is scattered among different manifestations, making it challenging to compare IIoT platforms with each other and understand the value they can create. Research just recently began investigating IIoT platforms, covering different aspects such as their business model (Endres et al., 2019; Hodapp et al., 2019), frameworks for classification (Moura et al., 2018), design characteristics (Abendroth et al., 2021), or their design criteria (Werner & Petrik, 2019). Regarding the business model, Hodapp et al. (2019) focused on constituent elements of a business model and developed a taxonomy to understand the IoT platform market. Similarly, Endres et al. (2019) explored IIoT business models to identify their IIoT specific components and overall business model archetypes. One of the archetypes they identified is the “IIoT platform business model” which is characterized by data-driven analyses through platforms and the applications on them. Regarding IIoT frameworks, Moura et al. (2018) proposed a framework that is divided into layers responsible for describing and accommodating key elements for IIoT implementation in an organization. Lastly, researchers investigated how IIoT platforms can be set up by elucidating their design criteria (Werner & Petrik, 2019) or the concept of boundary resources (Petrik & Herzwurm, 2019, 2020). However, we still miss a unified classification of architectural features and a understanding how they interact with each other to enable a transparent evaluation and comparison of existing IIoT platforms. We deem this a practical approach to uncover underlying differences of IIoT platforms that research thus far has not demonstrated.

Method

Taxonomy development

According to Glass and Vessey (1995, p. 66), taxonomy development refers to a method of “assigning members to categories in a complete and unambiguous way.” Taxonomies are schemes with which specific amounts of knowledge can be structured, analyzed, and organized, thus fostering the understanding of the phenomenon (Glass & Vessey, 1995). Embedded in the field of design science research, taxonomies can contain both descriptive and prescriptive knowledge and represent artifacts in the form of models (Nickerson et al., 2013). In information systems research, taxonomy development is well received and has already been successfully applied in different contexts when exploring emerging research fields such as predictive maintenance business models (Passlick et al., 2021), smart things (Püschel et al., 2020), or agile IT setups (Jöhnk et al., 2017). In line with this exemplary work, we follow the iterative taxonomy development method proposed by Nickerson et al. (2013). This method integrates conceptual and empirical perspectives into one comprehensive method and, thus, fosters the iterative usage of both paradigms. Figure 1 shows the seven-step-structure: (1) determination of a meta- characteristic that reflects the purpose of the taxonomy and its target group, (2) determination of ending conditions, (3) choice of either an empirical-to-conceptual (E2C) or conceptual-to-empirical (C2E) approach, (4) conceptualization of characteristics and dimensions, (5) examination of objects, (6) initial design or revision of the taxonomy, and (7) testing of ending conditions. The taxonomy’s purpose is reflected in its meta - characteristic, which the researcher defines, together with ending conditions, at the beginning of the development process. Several iterations of taxonomy design and revision, choosing either a C2E or an E2C approach, follow. After each approach, the researcher tests the resulting taxonomy against the ending conditions until they are met.

Fig. 1
figure 1

Taxonomy development process as of Nickerson et al. (2013)

Full size image

For step (1), we define our meta-characteristic as follows: Architectural features of IIoT platforms. Thus, our meta-characteristic reflects that we seek to guide both further research and practitioners. For step (2), we determine objective as well as subjective ending conditions of the taxonomy development process (Nickerson et al., 2013). As for the formal correctness of the taxonomy development, we test against the following objective criteria after each iteration: (I) every dimension is unique, (II) every characteristic is unique within its dimension, and (III) at least one object is classified under each characteristic of every dimension. Following Nickerson et al. (2013), we define our subjective ending conditions that taxonomy development is finished after the evaluation sees it to be concise, robust, comprehensive, extensible, and explanatory. Besides, we follow Jöhnk et al. (2017) and (Püschel et al., 2020) in combining mutually exclusive (ME) and non-exclusive (NE) dimensions to allow for a parsimonious taxonomy.

For steps (3) to (7), we alternately conducted two C2E and two E2C iterations. In the first iteration (C2E), we searched relevant literature following the guidelines of Webster and Watson (2002) and vom Brocke et al. (2015). We deliberately decided to start with a C2E iteration to account for the growing amount of literature as a means to initially structure the field. Thus, we considered research on IoT, IIoT, and digital platforms to gain a comprehensive perspective on the emerging phenomenon of IIoT platforms and to populate initial dimensions and characteristics in our taxonomy. We searched the scientific databases ACM Digital Library, AIS Electronic Library, IEEE Xplore Digital Library, and SpringerLink with the following search string: TITLE (“IoT platform*” OR “IIoT platform*” OR “internet of things platform*” OR “industrial internet of things platform*” OR “digital platform*”) AND ABSTRACT (“architecture” OR “taxonomy” OR “classification”). This search string resulted in 281 publications which we subsequently screened regarding information on architectural features of digital or (I)IoT platforms. Screening the results’ titles, abstracts, and – where necessary – full-texts, we reduced the results to 91 remaining relevant publications. We used this knowledge base and additional literature from a forward- and backward search to extract and consolidate architectural features in a table. Drawing on this list in joint discussions, we developed the first increment of our taxonomy consisting of 19 dimensions and related characteristics organized in four overarching layers. Considering that the literature only rarely focuses on IIoT’s specifics compared to the IoT and most architectural features in the literature revolve around security aspects, we decided to continue the taxonomy development process.

In the second iteration (E2C), we sought to back the preliminary insights with empirical evidence. Thus, we examined 22 IIoT platforms for their architectural features. We selected platforms identified through market research (e.g., from Gartner’s Magic Quadrant and practitioner reports) and those mentioned in literature from the first iteration. For instance, Guth et al. (2018) describe architectural features for AWS IoT and Microsoft Azure IoT Hub, among others. Thus, the descriptions and analyses from previous work helped us to confront our emerging taxonomy with existing renowned IIoT platforms. We obtained relevant information for our taxonomy development from platform providers’ technical documentation, websites, whitepapers, and relevant press releases. These insights helped us to identify new architectural dimensions and characteristics as well as to substantiate and improve the existing ones. By the end of the second iteration, our taxonomy consisted of 21 dimensions organized in four layers.

In the third iteration (C2E), we returned to the literature to ground the new observations in prior work. Thereby, we strengthened and verified the findings from the second iteration. Specifically, we searched for theoretical concepts describing our observations of IIoT platforms’ architectural features and dropped or consolidated dimensions and characteristics in line with our meta-characteristic. For instance, while we found information on IIoT platforms’ governance in the second iteration, it does not describe their architectural features in the narrower sense, which is why we removed them from the taxonomy. The third iteration resulted in a taxonomy of 13 dimensions and related characteristics that are organized in four overarching layers.

In the fourth iteration (E2C), we collected and analyzed additional primary data from seven expert interviews (see Table 1). We deemed this iteration necessary to account for IIoT platforms’ novelty and peculiarities in developing and evaluating our taxonomy. Our interviews were semi-structured, following an interview guide to ensure coverage and comparability between the interviews (Myers & Newman 2007). Each interview consisted of four building blocks: introduction (participants, research project, taxonomy research, and clarification of focal terms and concepts), discussing the layers and dimensions of the taxonomy, discussing the characteristics for each dimension in the taxonomy, and overall feedback. We selected interviewees from our industry network (expert sampling) according to their knowledge in the field of IIoT and/or IIoT platforms. Our experts contribute perspectives from different backgrounds and industries to offset potential biases. The interviews lasted between 55 and 78 minutes, and at least two of the authors were present in each interview. We recorded all interviews with the experts’ consent and analyzed them systematically. Thus, all authors engaged in discussing the experts’ feedback and further developing the taxonomy. We incorporated the proposed changes between interviews to discuss the improved taxonomy iteratively.

Table 1 Overview of the seven expert interviews
Full size table

Cluster analysis and archetype identification

Based on our taxonomy, we seek to identify, conceptualize, and elucidate typical architectural setups of IIoT platforms (i.e., typical combinations of architectural features). This is to understand better the current IIoT platform landscape and guide scholars as well as practitioners in this field. We identified distinct IIoT platform archetypes using cluster analysis. This statistical technique groups objects with similar characteristics and aims for a high degree of homogeneity within each cluster group and a high degree of heterogeneity between cluster groups (Hair et al., 2010).

For this step, we collected data on 78 IIoT platforms that provided real-world cases for cluster analysis. We used the publicly accessible IIoT supplier database of the market research company IoT ONE to obtain a comprehensive list of relevant IIoT platforms (IoT One 2021). Following a structured selection process, this platform sampling approach helped us to gain a larger number of IIoT platforms for classification compared to the taxonomy development phase. At the same time, this approach was detached from any focus and platform selection choices in previous work to increase the transparency and comprehensibility of our cluster analysis.

The IoTONE database contained information on 2,873 companies at the time of the data collection. We narrowed down the search results using the databases’ filter options to select “platform-as-a-service” entries, resulting in a list of 560 elements. Subsequently, we filtered the list by the five available revenue categories (>$10bn, $1bn–$10bn, $100m-$1bn, $10m-$100m, <$10m) to cover IIoT platforms of different sizes, popularity levels, and with different value propositions. We classified every IIoT platform of the revenue categories 1 to 3 (see Table 2) that provided sufficient publicly available information (i.e., technical documentation, whitepaper, press release, website description etc.). For revenue categories 4 and 5, we limited the number of cases that we classified since we aimed at a balanced sample with respect to the different revenue categories. Thus, we deliberately emphasized the comprehensive sampling across revenue categories (i.e., potentially resulting in greater variety regarding the archetypes) over a ‘representative’ sampling that mirrors the relative number of IIoT platforms per revenue category (i.e., potentially resulting in archetype dominance that may not reflect the IIoT platform market). The selected IIoT platforms are listed in Table 5 in the Appendix.

Table 2 Distribution of IIoT Platforms across revenue categories
Full size table

Authors jointly engaged in IIoT platform classification, frequently discussing ambiguities within the research team to allow for alignment in applying the taxonomy. We choose agglomerative hierarchical clustering with the Ward algorithm and Manhattan distance function as our clustering approach for two main reasons. For one thing, Ward algorithm’s characteristic to minimize intra-cluster variation and maximize inter-cluster variation (Strauss & Maltitz, 2017) helps us to delineate clearly distinguishable archetypes, especially considering the plethora of potential platform manifestations from our taxonomy (see Püschel et al. (2020) for an explanation of theoretical manifestations from taxonomies). For another thing, this combination of cluster algorithm and distance function is an established approach in extant research which has proven to be a valid and effective means to cluster taxonomy classifications (cf. Hodapp et al., 2019; Püschel et al., 2016). We coded every characteristic as binary (1: the IIoT platform offers this architectural feature; 0: the IIoT platform does not offer this architectural feature; see Table 6 in the Appendix for a detailed example of the coding process) and normalized the dimensions’ distance as [0;1] to avoid overrating dimensions with more characteristics (Püschel et al., 2016). Thereby, we accounted for both the dimensions’ exclusivity (mutually exclusive or non-exclusive characteristics) and number of characteristics. Agglomerative hierarchical clustering shows solutions for all possible number of clusters. Thus, we used triangulation to choose the optimal number of clusters based on different statistical measures, visual graph interpretation, as well as interpretability and meaningfulness based on our real-world observations (Jick, 1979). Regarding statistical measures, no cluster solution was dominant, but we were able to narrow the sensible number of clusters to a solution between three and nine clusters (e.g., C- Index proposing a four cluster solution). As established visual graph interpretations, we used the dendrogram and the average silhouette width to better understand the agglomeration in our hierarchical clustering. This step showed that the solutions for four, five, six, and seven clusters performed very similarly statistically. Thus, we engaged in joint discussions with all authors to review all four of these cluster solutions for their cluster composition and meaningful interpretation. Considering earlier work on IIoT platforms’ architectural features [blinded for review], we finally decided on the final five cluster solution (see Figure 3 in the Appendix for the dendrogram). Subsequently, we conceptualized the archetypes’ specifics and implications.

Taxonomy of architectural setups of industrial IoT platforms

In the following, we present our final taxonomy (see Fig. 2) and describe the dimensions and characteristics in detail. The taxonomy consists of 13 dimensions encompassing 38 characteristics that we defined according to the pre-specified meta-characteristic. To improve our taxonomy’s comprehensibility and real-world fidelity, we structure the dimensions in four layers, i.e., infrastructure, network, middleware, and application layer.

Fig. 2
figure 2

Taxonomy of IIoT platforms’ architectural features (ME: dimension is mutually exclusive; NE: dimension is non-exclusive)

Full size image

Infrastructure layer

Industrial IoT platforms are created and cultivated on top of digital infrastructures (Constantinides et al., 2018). In the context of IIoT platforms, such digital infrastructure is represented by the smart things that are connected to the platform and the technical resources on which the platform operates. In this layer, we found three relevant dimensions.

Hardware support

Regarding the devices that IIoT platforms allow to be connected to it, we found that some IIoT platforms constrain the connectivity to certified hardware (e.g., proprietary or selected third-party devices) which are approved by the platform owner, while others are hardware-agnostic, meaning they support any hardware as long as it fits the platforms’ rough technical specifications.

Platform hosting

Another differentiation of the infrastructure is how the IIoT platform is hosted. While defining requirements for IIoT platforms, Petrik and Herzwurm (2018) name three ways of how IIoT platforms can be hosted: on-premise, in a cloud, or in a hybrid way using both approaches. We adopt these characteristics and extend them by differentiating between public and private cloud specifications as experts repeatedly pointed out the difference during the interviews.

Data processing

Our taxonomy research process revealed that IIoT platforms process data on different boundaries of the platform. We found that most IIoT platforms process their data on-platform, meaning that depending on the level of platform hosting, this happens on-premise or in the cloud. Many IIoT platforms though also offer to process data on the edge, meaning that processing happens in a local network or within the smart things without all generated data being sent to the IIoT platform. As some IIoT platforms offer a mixture of both approaches, we also included fog as a situation-based data processing characteristic.

Network layer

As connectivity and interoperability of devices and applications are core capabilities of any IIoT platform, we defined a network layer to collect the respective dimensions. Generally, two prominent frameworks can be found in the literature to describe the structure of networks: OSI and TCP/IP model. We used these models to derive two dimensions that describe the network layer of an IIoT platform, similar to the proposed stack-lower and stack-upper layer of Sisinni et al. (2018).

Physical data transportation

These options can be categorized into wired, meaning a cable-bound transmission, and wireless, therefore cable-unbound transmission. While the former represents a homogeneous group of transmission methods, the latter contains heterogeneous groupings of different wireless transmission methods. Therefore, we distinguish wireless transmission methods into three sub-categories: short-range wireless, which includes protocols with high performance but high power consumption and limited range (e.g., WiFi or Bluetooth), cellular, which have high performance, high power consumption, and long range (e.g., 5G or LTE), and low power wide area networks (LPWAN), which have low performance, low power consumption and medium to high range (e.g., SigFox or LoRa).

Logical data transmission

Consequently, we found that IIoT platforms use different protocols to ensure a common data structure for information exchange. We distinguish between internet protocols, which emerged from the conventional internet (e.g., HTTP, XMPP, or Websockets), IoT-specific protocols, which meet specific requirements of the IoT and thus overcome many drawbacks of internet protocols (e.g., MQTT, AMQP, or CoAP), and industry-specific protocols, summarizing existing industry standards to connect machines (e.g., Modbus, CAN, or BACnet).

Middleware layer

Integrating data with applications on the IIoT platform leads to different specifications, which we summarize in the middleware layer. It is responsible for the accumulation and further processing of collected data (e.g., to applications) and consists of all functionalities required by a cyber-physical system. Thus, the layer is integrating the connected hardware to the platform and the software built upon it (Guth et al., 2018).

Data structure

When generating data in the IIoT, data can be collected and streamed in different formats and structures. Some IIoT platforms explicitly state that they can deal with unstructured data, while others can only process structured ones.

Analytics types

Making use of generated data is a central feature of every IIoT platform. We distinguish four types of analytics methods in the domain of IIoT: descriptive analytics, which is the most basic form, and which analyzes historical data to reconstruct events, real-time analytics that focuses on current data to identify events, predictive analytics, which uses both historical and real-time data to predict future events, and prescriptive analytics, which takes the predictive approach even a step further to advise on how to deal with upcoming events.

Analytics technology

Consequently, IIoT platforms use different kinds of technology to analyze data. We found that they can be categorized into basic technologies, such as statistical modeling, and advanced technologies such as machine learning and neural networks.

External integration

IIoT platforms can not only analyze data collected from devices directly connected to the platforms but also include data from external sources. We found that platforms differ in their offerings to integrate other (enterprise) systems. Business integration includes systems that deal with business processes and data from ERP, CRM, or SCM systems, machine integration includes legacy systems that are used in factories such as existing PLC or SCADA systems, and web services integration include internet-based data sources.

Platform source code

The examination of exemplary IIoT platforms revealed that they leverage different approaches to further develop their software. We distinguish between open source, meaning that platforms provide their complete source code to the public, open components, meaning that platforms release single modular parts of the platform source code to the public or leverage components already being open source, and closed source, meaning that platforms keep their source code proprietary.

Application layer

Based on the collected data as well as functionalities provided within the middleware layer, IIoT platforms offer the possibility of integrating applications developed internally or by third parties. We summarize the architectural specifics of this provision in the application layer.

Application Programming Interfaces (APIs)

To integrate not only external systems but also applications, IIoT platforms offer different APIs. While on some platforms we only found standardized APIs which are maintained by the platform owner, we found other cases where platforms offered possibilities to build custom APIs based on predefined syntax and specifications (e.g., via an API Manager).

Application deployment

The empirical analysis of IIoT platforms revealed that platforms use different approaches to deploy applications built internally or by third-party contributors. In most cases, applications are platform-native, meaning that applications have been built with tools provided by and directly running on the platform (e.g., rules engines). In other cases, we found that applications were containerized, meaning that the applications have been developed in an external environment but are deployed on the platform in a containerized environment (e.g., Docker), and in few cases, we found that applications were deployed off-platform, meaning that the applications are developed and hosted on different infrastructure (e.g., Cloud Foundry).

Marketplace

For the provision of applications to platform users, we found that IIoT platforms use different approaches. They either run an internal marketplace, which can be understood like an app-store on a mobile phone, or they make use of an external marketplace, which integrates the app-store of another digital platform (e.g., Eclipse Kura Marketplace) into the IIoT platform, or they have no marketplace at all.

Industrial IoT Platform archetypes

Drawing on our sample of 78 IIoT platforms, we demonstrate the applicability and usefulness of our taxonomy.

Thus, we first derive overarching observations on IIoT platforms’ architectural features (see Table 3).

Table 3 Classification of IIoT platform sample (n = 78)
Full size table

Overall, most platforms are hardware-agnostic (87.2%) and hosted via a public cloud service (96.2%), even though many platforms offer to choose other settings (on-premise 64.1%, private cloud 55.1%, hybrid 37.2%) as well. While almost all IIoT platforms can process data on-platform (97.4%) or on the edge (66.7%), we found that only a minority is capable of situation-based data processing (fog 17.9%). Most IIoT platforms rely on wired (85.9%) or short-range wireless (89.7%) data transportation technologies (cellular 59.0%, LPWAN 67.9%). Further, they use different combinations of protocols (internet 61.5%, IoT-specific 56.4%, industry-specific 71.8%). Note that we only considered this characteristic as existing if the IIoT platform offered more than one protocol to account for the diversity of data transmission. Regarding data analysis, most IIoT platforms can handle structured (91.0%) as well as unstructured (75.6%) data. Further, all IIoT platforms can analyze data descriptively (100%), with that number declining, the more complex analysis gets (real-time 89.7%, predictive 56.5%, and prescriptive 20.5%). Accordingly, our sample shows a fair split between basic analytics technology used (50%) and advanced methods (50%) used. For external integration of data, most IIoT platforms can integrate web services (89.7%, business 65.4%, machine 52.6%). As for source code openness, two-thirds (71.8%) are closed source (open source 7.7%, open components 21.8%). Further, we found a majority of IIoT platforms offering standardized APIs (82.1%) and deploying applications on the platform (94.9%) (containerized 23.1%, off-platform 34.6%). Lastly, more than half (62.8%) of IIoT platforms do not offer a marketplace for applications.

Based on the cluster analysis among the IIoT platforms, we identified five archetypes, which we describe hereinafter. These archetypes indicate typical combinations of IIoT platforms’ architectural features. We emphasize distinctive characteristics per cluster and conceptualize the archetypes with real-world insights. Table 4 provides an overview of the different archetypes as well as their most frequent characteristics per dimension. For non-exclusive dimensions, we included all characteristics that cover more than one-third of the cluster. The Appendix shows to which cluster each platform of the total sample was assigned.

Table 4 Five IIoT platform archetypes
Full size table

Archetype 1 – Allrounder

IIoT Platforms of this archetype typically have strong markedness in many (non- exclusive) characteristics. While they are strong in different platform hosting options, they also offer various network data transportation options and data transmission protocols. Further, they stand out for strong analytics capabilities and external system integration possibilities. As the only cluster, these IIoT platforms strongly leverage external innovations through open components and deploy applications through various ways on the platform, while also maintaining an internal marketplace. IIoT platforms in this cluster offer a full-stack solution to their users. Our data sample shows that these platforms provide comprehensive services and cover a wide range of application scenarios, ranging from device connectivity and monitoring, over data visualizations and prescriptive processes, to over-the-air updates or command execution. Due to the broad coverage across all dimensions, we call this archetype Allrounder. Two prominent examples for this archetype are GE Digitals’ Predix or Siemens’ MindSphere platform. Both platforms provide edge-to-cloud data connectivity, processing, analytics, and distributed application services to support industrial applications to optimize operations, create better quality products, and deploy new business models. Thereby, they leverage the latest big data and machine learning technologies for analytics-driven outcomes. Further, they provide the possibility to self-develop and distribute (via an internal marketplace) application microservices to extend the platforms’ functionalities in analysis, data visualization, case management, and other areas.

Archetype 2 – Device Controller

This archetype comprises IIoT platforms that typically have strong markedness in only a few characteristics. As they strongly focus on public cloud hosting, they also tend towards on-platform data processing. Further, they offer only selected data transportation options and transmission protocols. Most IIoT platforms in this cluster utilize basic analytics technology, leading to less-developed data analysis. However, to connect the platform with other Web Services, it often provides the relevant interfaces. Lastly, most platforms of this archetype do not maintain a marketplace for applications. IIoT platforms in this cluster focus on a narrow use and, thus, provide only necessary functionalities. They can be extended mostly through applications that are built with platform-native tools such as rules engines or low-code/no-code development environments. Due to its strong focus on data transportation in combination with limited data analytics capabilities, leading to pertinent use cases of these platforms, we call this archetype Device Controller. Two examples of this archetype are Airtel IoT and KITE platform. Both platforms have a strong focus on various connectivity technologies, especially in the cellular area, to enable real-time information, analysis, and control over devices for e.g., asset tracking or vehicle telematics. Therefore, the platforms are hosted in public clouds, deploy data analysis purely on-platform, and leverage primarily Internet or IoT-specific protocols. Finally, interfaces for Web-Service integration are offered to allow for further data distribution.

Archetype 3 – Data Hub

IIoT platforms in this cluster show strong markedness in specific characteristics. They are characterized by specifications on data processing and analysis. Consequently, they focus not only on edge and on-platform but also on fog data processing. Their focus is on industry-specific protocols, while different data transportation options are offered. Regarding data analysis, these IIoT platforms provide strong analytics options backed by advanced technologies and comprehensive integration of other company systems. Further, their source code is mostly closed, applications are deployed internally, and they don´t maintain a marketplace for applications. Data Hubs are IIoT platforms that place a specific focus on data-driven insights and decision-making using high-end analytics technology. A widespread use case for this archetype is the linkage of production lines and their optimization. We also found that many platforms offer their own sensors or edge devices in an as-a-service model to make better use of data-gathering. As the platforms of this cluster focus strongly on data collection and analysis, we call this archetype Data Hub. Two examples of this archetype are Foghorn and Foghub. Both platforms concentrate on edge or fog data processing and primarily support a range of industrial protocols to transfer data from (industrial) machines. In addition, they offer extensive possibilities to analyze the data utilizing advanced analytics (i.e., machine learning algorithms). Furthermore, they provide the capability of various integrations, most notably machine integration, and feature only an internal deployment of applications without operating any marketplaces.

Archetype 4 – Service Enabler

This archetype comprises IIoT platforms that combine characteristics of archetypes 2 and 3. They are characterized by a strong focus on platform hosting options, as well as physical data transportation and logical data transmission possibilities, enabling either data processing on the edge or on- platform. Further, they provide strong analytics capabilities, including predictive and partially prescriptive analytics, backed by advanced technologies. Regarding their external integration, Service Enabler platforms rather integrate into web services, leveraging standardized APIs and primarily rely on closed source platform development. Compared to the other archetypes, they build and deploy applications not only internally but also in parts on external infrastructures. Consequently, they often also provide an internal or external marketplace for application distribution. Due to their focus on strong data analytics options and their possible deployment as services within an ecosystem, we call this archetype Service Enabler. Two examples of this archetype are Relayr and Starhubs’ 5G IoT Platform. They not only focus on routine maintenance and remote device access but also on service integration of IoT solutions that is either self-developed or externally deployed and integrated via APIs.

Archetype 5 – Connector

This archetype comprises IIoT platforms with strong markedness in the network layers’ and middleware layers’ characteristics. These IIoT platforms are more critical regarding the connected hardware, with every second platform only supporting certified hardware. Data processing is possible in multiple ways, with a strong focus on fog processing. Data transportation possibilities and logical transmission protocols are widely offered and are supplemented by rich external system integration options. Regarding data analysis, this archetype uses basic technologies and offers only limited analytics types. Applications can be deployed either on or off the platform while using mostly a marketplace. Connectors are IIoT platforms that specialize in integrating devices into their platforms to extract and gather data. They put stronger restrictions on hardware support or only offer standardized APIs to comply with the technological complexity and provide a reliable basis for additional contributions of platform actors. As their focus is on these topics, they rely on other services and solutions to make use of the data and provide advanced analytics tools, which other users can adopt through the marketplace. As the primary goal of the platform of this cluster is to enable network integration of devices to the IoT, we call this archetype Connector. Examples of this archetype are Telits’ deviceWISE and Ciscos’ IoT Control Center. The distinct focus of these two platforms is on extensive connectivity options, as both platforms offer all possible protocols in the dimensions of physical data transportation and logical data transmission. The analytics options are less advanced, as the platforms only offer basic analytics using non-complex analysis methods. However, in the area of external integration options, they again offer a wide variety of capabilities, as both platforms fulfill all possible options in the corresponding dimensions in accordance with their archetype. Furthermore, both platforms allow themselves to be expanded by an internally operated marketplace.

Discussion of cluster results

While exploring the five archetypes and the associated IIoT platforms in detail, we unveiled some specialties that we discuss in the following. Allrounders represent the most holistic archetype, characterized by an extensive list of architectural features that enable a wide range of possible application scenarios. However, this entails increased technical complexity, resulting in higher initial investment for end-users owing to the necessity of external system integrators, which are usually already partnered with Allrounders. IIoT platforms of this archetype are suitable for end-users that pursue a comprehensive approach to their IIoT strategy and require an end-to-end solution. Device Controllers, in contrast, are defined by a lower technical complexity and selection of architectural features. Thus, while they focus on narrow application scenarios that involve device administration and management, they also foster a user-friendly experience and faster implementation. Hence, they are also suitable for smaller companies and applications where the available resources are scarce. Data Hubs are specialized IIoT platforms focusing on advanced data analysis through high-end technology (e.g., artificial intelligence). They often rely on users to provide adequate infrastructure to enable data transmission to the platform and are, thus, particularly suitable for users that already have a multitude of data that they want to exploit. Service Enablers provide advanced data analytics options and IoT solution enablement to enhance business processes. Thereby, self-developed solutions may also be deployed and distributed within the ecosystem of platform participants., thus advancing the functionality of the IIoT platform. Lastly, Connectors focus on connecting heterogeneous devices to their IIoT platform. As they tend to have less developed analytics tools, they rely on third-party developers to provide (individual) solutions via an internal marketplace to the users.

While these findings rest upon the platforms’ architectural features, they indicate relevant implications for platforms’ business models and evolution. Previous research already provides some insights regarding typical characteristics (Abendroth et al., 2021) or business model archetypes for IIoT platforms (Hodapp et al., 2019). Comparing our taxonomy to respective dimensions of Abendroth et al. (2021), we find confirmation in selected architectural characteristics (e.g., platform openness, options for extensibility). The “core value propositions” further display stark similarities to our archetypes. Comparing the findings of Hodapp et al. (2019) and ours, we find parallels between archetypes. For instance, Connectors in our sample may contribute to ‘device connectivity enablement’ business models, Device Controller may contribute to “device data storage” business models because they facilitate the integration and monitoring of IIoT devices, and Allrounders, naturally, enable “multi capability” business models. In fact, we even found overlaps in the specific IIoT platforms across architecture and business model clusters. However, despite these overlaps, we argue that the interplay of IIoT platform architecture and business model is less apparent than the archetype labels suggest. As platforms’ architecture constitutes “an information technology artifact´s virtually irreversible DNA” (Tiwana, 2018, p. 829), architecture decisions and investments are more persistent than the business models that are built on this foundation. Hence, IIoT platforms from all archetypes may use their specific architectural configuration to define and advertise individual business models. This may result in IIoT platforms from the same architectural archetype offering different business models. A comprehensive understanding of IIoT platforms’ architectural features is thus beneficial to a better understanding of the actual value they can offer.

Taking a broader perspective, this understanding may also be relevant for broader IS literature on digital platforms. While digital platforms’ conceptualization in two broad types (transaction versus innovation platforms, cf. Gawer and Cusumano (2014)) is helpful to demarcate their general foci, our results extend this notion by taking a closer look at the different architectural configurations of IIoT platforms as specific innovation platform manifestations. Thereby, we show that technological platforms that are currently treated as a homogenous group are in fact very heterogenous which bears important implications for their orchestration. For instance, we see in many of the archetypes that development activities happen within the platform users’ organization for their own use. Schreieck et al. (2019) refer to this as “customers as developers” and show how platform orchestration must change to, among other, account for indirect network effects being not applicable anymore. Understanding such differences thereby also helps to clarify the distinction between B2C and B2B platforms.

Last, considering the different revenue categories in our data sample, we find that Allrounders are typically rather big (over 70% of our Allrounders make at least $1bn), while Data Hubs are often smaller IIoT platforms (almost 60% of our Data Hubs make less than $100 m). Thus, IIoT platforms’ architectural features also help to better understand the antecedents and contingencies of platform evolution (Henfridsson & Bygstad, 2013). For instance, IIoT platforms architecture may constitute the foundation to enable business model changes over time. In addition, IIoT platforms may proceed from one architectural archetype to another over time, also enabling new or extended business models. We leave it to further research to apply our findings and investigate how the five archetypes may complement each other and how they enable the business models that build upon the architectural features.

Conclusion and outlook

Despite IIoT platforms’ increasing importance for businesses, we still miss an understanding of different architectural setups and associated consequences of such digital platforms. Further, selecting the right IIoT platform in the heterogeneous solution landscape has become increasingly challenging for practitioners. To bridge this research gap and address the underlying practical problem, we developed a taxonomy of IIoT platforms’ architectural features. In the development process, we built on empirical data from both analyzing IIoT platforms and conducting semi-structured expert interviews with practitioners involved with the IIoT, as well as conceptual data from the literature on IoT, IIoT, and digital platforms. Our final taxonomy comprises 13 dimensions organized in four layers that help researchers and practitioners to better understand this emerging phenomenon. Further, we identify and conceptualize four IIoT platform archetypes from 78 real-world cases that help us to systematize the IIoT platform landscape and add an architectural perspective to recent discourse.

Thus, our theoretical contribution is threefold. First, our taxonomy adds to the descriptive knowledge in this relatively young research field by structuring and explaining what architectural features constitute prevalent manifestations of IIoT platforms. Thereby, we follow Reuver et al. (2018) recommendation to foster the development of contextualized theories on digital platforms as well as to conduct data-driven research. This may guide not only researchers in the field but also IIoT platform complementors, seeking to understand a platform´s architecture to align their app to the available platform resources (cf. Tiwana, 2018). Second, we offer researchers and practitioners a mutual nomenclature that specifies IIoT platforms’ architectural features. With this, we extend current research, which is largely limited to rather simple category lists built through vague development processes. Third, we elucidate typical architectural setups of IIoT platforms and how this shapes their business logic. We see this as the necessary foundations to better understand the reciprocal interplay of both aspects, i.e. , how architectural design options enable IIoT platform business models and vice versa. From a managerial perspective, our taxonomy and the five archetypes help practitioners in comparing different IIoT platform solutions and enable them to select the one that not only fits the existing IT infrastructure but also provides desired solution capabilities.

We acknowledge some limitations in our research that open promising avenues for further research. Our taxonomy rests on the data used and the sequence of iterations. Although our dataset covers a fair amount of IIoT platforms of different sizes and with different foci in terms of their value proposition, we did not cover the exhaustive sample of the more than 620 available IIoT platforms. Future research may incorporate additional IIoT platforms and conduct further iterations to validate and update our proposed taxonomy and the resulting archetypes. In this regard, we also acknowledge the potential to substantiate our findings with additional qualitative empirical data to better control for potential specifics of platform users from different industries and their implications for platforms’ architectural setup. Further, we did not address potential dependencies between dimensions and characteristics or the architectural success criteria of IIoT platforms. Investigating these aspects may help in the successful design and use of IIoT platforms. Further, it may help to answer some of the fundamental strategy questions such as how to earn a competitive advantage based on a distinct technological architecture (cf. Cennamo, 2021; Schilling, 2003; Zhu & Iansiti, 2012). Lastly, future research may test our archetypes’ external validity to ensure their generalizability and to explore their evolutionary paths (e.g., IIoT platform sizes within and across clusters).