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.
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.
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.
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.
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.
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.
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.
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.
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).
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).
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.
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.
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.
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.
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).
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).
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.