The industrial IoT platform market is crowded and loud: every vendor claims edge-to-cloud, digital twins, and AI. Yet the platform decision is one of the most consequential and expensive choices in a digitalization program — platforms are adopted for a decade, and migrating between them is a project in itself. This article cuts through the marketing with a functional view: what an IIoT platform actually does, what the architecture options are, and how to evaluate candidates against the plant's real use cases.
What an IIoT Platform Does
An IIoT platform is the software backbone between the plant and the applications that use its data. The functional layers:
- Connectivity — device/gateway onboarding, protocol support (MQTT/Sparkplug, OPC UA, Modbus, vendor protocols), and connection management at scale.
- Device and asset management — device registry, configuration, firmware updates, and the asset hierarchy (site → line → machine → point) that organizes everything else.
- Data management — ingestion, time-series storage, quality and context handling, and data access (APIs, SQL, export).
- Application services — dashboards, rules/alerts, analytics, and integration interfaces (REST, webhooks, connectors).
- Administration and security — identity, roles, multi-tenancy, audit, and the security controls that make the platform trustworthy.
The depth of each layer varies enormously between products — from lightweight dashboards-in-a-box to full industrial data platforms with edge runtimes.
Architecture Options
| Architecture | Strengths | Weaknesses |
|---|---|---|
| SaaS (multi-tenant cloud) | Fast start, zero infrastructure, provider-managed security and updates. | Data leaves the plant (legal/sovereignty checks), recurring cost, provider lock-in. |
| Private cloud / self-hosted | Data control, custom integration depth. | You operate it: updates, security, scaling — a small IT department in itself. |
| Edge-first platform | Data processed at the plant, cloud optional; low latency, resilience to connectivity loss. | More engineering; the edge is part of the OT surface (see the cloud/edge security article). |
| Hybrid (edge + cloud) | The industrial standard: edge for collection/control-adjacent processing, cloud for scale and analytics. | Two environments to operate; integration quality decides the outcome. |
The evaluation should be anchored in the target architecture — where the data must live, who operates what, and how the platform fits the plant's OT security model — before comparing feature lists.
Evaluation Criteria That Matter
- Protocol and integration depth — native Sparkplug B? OPC UA client/server? Fieldbus gateways? The integration cost with the installed base is the platform's largest hidden price.
- Data model quality — can the platform represent the plant's asset hierarchy and data context (units, quality, timestamps), or is it a flat tag bucket? Context is what makes the data usable later.
- Openness — export capability (all data and configuration, documented), APIs, and the absence of proprietary locks: assess the exit cost as seriously as the entry cost.
- Security posture — the platform's security model (identity, encryption, audit), its certifications, and its fit with the plant's IEC 62443 zoning.
- Operational model — who runs it (vendor, plant IT, automation), the update cadence, and the support terms; a platform without an operational owner is a ghost.
- Cost model — per-device, per-message, per-user, or bundled; model the bill on the plant's real data volume (see the cloud integration article for the cost drivers).
- Ecosystem — the application ecosystem (analytics, visualization, industry solutions) and the community; the platform's ecosystem is its long-term value.
The Evaluation Process
- Define the use cases first — the three to five concrete applications (remote monitoring of site X, OEE analytics, alarm notification) with their data needs; the use cases are the platform's acceptance test.
- Shortlist on architecture — filter by the target architecture and the integration profile; five candidates is enough.
- Run a pilot with real data — connect one real asset (or a simulator) with the actual protocol, build the use case dashboard, and test the operational details: onboarding, alerts, data export.
- Score against the criteria with evidence — a weighted scorecard filled from the pilots, not from sales calls; include the exit-cost question.
- Reference calls — talk to plants of similar size and industry running the platform for 2+ years; ask about the operational reality, not the features.
Common Mistakes
- Choosing by dashboard beauty — dashboards are the cheapest layer to build; data access and integration are the expensive ones.
- Platform-first, use-case-later — the classic: buy the platform, then search for problems; the result is an expensive dashboard museum.
- Ignoring the operational cost — the platform's monthly cost is the visible part; the integration, training, and operations effort is usually larger.
- Lock-in by neglect — no data export tested, no configuration export, and the platform becomes the plant's memory with no way out.
Summary
IIoT platform selection is architecture first, features second: decide where the data lives and who operates it, then evaluate integration depth, data model quality, openness, security, operations, and cost against concrete use cases with a real pilot. The platform is a decade-long partner — choose it like a hiring decision, with evidence, references, and an exit plan.