Principles of Industrial IoT Architecture and Protocols

How do you architect IoT solutions that balance real-time operational needs with your broader data strategy?

Rick Bullota—who co-founded ThingWorx (one of the first industrial IoT platforms), helped define Azure IoT strategy at Microsoft, and served as CTO at Wonderware—brings decades of practical experience to this question. His perspective cuts through vendor marketing to focus on what actually matters when you're building systems that must work reliably in industrial environments.

The challenge isn't just technical. You're balancing mission-critical uptime requirements, legacy system integration, cost constraints, regulatory compliance, and the need to enable advanced analytics. Your decisions today will shape your organization's operational capabilities for the next decade.

This guide provides a framework for making those architectural decisions based on what works in real industrial deployments.

‍

‍

The Framework: How to Make IIoT Architecture Decisions

‍

Before choosing any technology, Bullota recommends evaluating what he calls "the ilities"—availability, reliability, scalability, and performance. This framework helps you match architectural patterns to business requirements.

Mission criticality drives placement:The closer you need to be to 100% uptime, the closer you place workloads to the physical hardware. Consider that 80% of PLC code is error handling and safety logic—it's mission-critical and sits directly on the hardware. As you move up the stack and criticality decreases, you gain flexibility in where workloads run.

Performance requirements matter:Video analysis, audio signal processing, and vibration analysis increasingly happen at the edge rather than requiring cloud round-trips. The physics of moving large volumes of data across networks affects your architecture. If you're analyzing high-frequency sensor data, local processing often makes more sense than cloud-based analytics.

Data consumer location is key:Who uses the data most frequently? Bullota's research at his first company revealed that people consuming the most data most frequently are typically co-located with that data source. This suggests keeping high-volume operational data local, with only aggregated or analytical data moving to the cloud.

The hot path versus cold path:Real-time operational data (hot path) often stays at the edge where responses must be immediate. Historical data for analytics and machine learning (cold path) moves to cloud data lakes where your AI tools can access it easily. This separation lets you optimize each path independently.

This framework helps you avoid the trap of assuming everything should go to the cloud or everything should stay on-premise. The answer depends entirely on your specific requirements across these dimensions.

‍

IIoT Edge Computing: Strategic Placement of Workloads

‍

The edge versus cloud question isn't binary. Successful implementations strategically distribute workloads based on requirements.

What stays at the edge:Mission-critical control systems that cannot tolerate network interruptions remain at the edge. Human-machine interfaces (HMIs) and SCADA systems benefit from local deployment—it makes little sense to move data to the cloud just to bring the visualization back. Real-time analytics that drive immediate operational decisions stay close to the source.

What moves to the cloud:Historical data that feeds machine learning models typically moves to cloud data lakes because modern AI tools prefer centralized data. Global analytics that aggregate information across facilities benefit from cloud deployment. Applications where users are distributed across locations rather than co-located with equipment work well in the cloud.

The hybrid reality:Most industrial operations end up with hybrid architectures. Your PLCs and control systems run at the edge. Some analytics and data aggregation happen in on-site data centers. Long-term storage and global analytics leverage cloud infrastructure. The key is having clear principles about what goes where.

Availability architecture:You have two approaches to high availability—hardware-based with redundant power supplies and components, or software-based with multiple instances across hardware. Industrial environments traditionally favor hardware redundancy for critical systems, but increasingly leverage software patterns for less critical workloads.

The goal is matching your architecture to actual operational requirements rather than following technology trends.

‍

IIoT Gateway Selection: Beyond the Hardware

‍

When selecting IoT gateways, the hardware matters less than you might think. As Bullota notes, gateways are increasingly interchangeable commodities. What matters is communication technology support, high availability approach, and software capabilities.

Communication infrastructure first:Your gateway selection starts with communication requirements. Using existing fiber or broadband to the cloud? Standard industrial compute works fine. Implementing 5G private networks or satellite backhaul? That dictates specific hardware choices. The communication layer drives gateway selection more than processing requirements.

Operating system trends:The plant floor was 99% Windows a decade ago. Now Linux is increasingly common on industrial devices. This shift reflects both cost considerations and the cloud-native tooling that runs better on Linux. Your software strategy should inform your hardware choices.

Software capabilities matter more:The real differentiation comes from software—the protocols supported, the edge processing capabilities, the management tools, and the integration options. Focus your evaluation on these capabilities rather than comparing processor specifications.

‍

How to Select an IIoT Protocol Selection

‍

Protocol selection remains one of the most complex aspects of industrial IoT architecture because you're rarely choosing protocols—you're managing the protocols your legacy systems already use.

The last mile problem:At the device level, you're dependent on what the sensor, PLC, or historian supports. Every PLC vendor has proprietary protocols. Every software system has its own APIs. This "Tower of Babel" at the edge constrains your architecture whether you like it or not.

Protocol translation layers:Most implementations add translation layers that convert proprietary protocols to something more standardized. You might use OPC or OPC UA as a bridge protocol, then translate again for your cloud system. Often you're also converting technical identifiers from control systems into friendlier names for digital twins or analytics platforms.

Cloud vendor fragmentation:Despite standards like MQTT, cloud vendors implement these protocols differently. The protocols become mere packet transport mechanisms rather than semantically consistent standards. This means integration work even when using "standard" protocols.

The abstraction principle:The solution is abstraction—design your applications to abstract away specific protocol details. This lets you swap underlying implementations without rewriting application logic. Think abstractly about requirements: "I need to store and retrieve time series data" rather than "I need to use Protocol X."

This approach reduces coupling to specific vendors and protocols, giving you flexibility as your architecture evolves.

‍

IIoT Communication Patterns: Request-Response Versus Publish-Subscribe

‍

Choosing between request-response and publish-subscribe patterns significantly impacts your architecture's efficiency and scalability.

When request-response works:Traditional request-response patterns work well for discrete actions—setting values, querying historians, or invoking specific operations. Many legacy devices only support this model, so you're constrained by what they offer.

The efficiency case for pub-sub:Publish-subscribe is far more efficient for real-time telemetry and event-driven applications. Consider 500 people viewing the same temperature sensor. In request-response, that's 500 queries every 10 seconds, loading your source system unnecessarily. With pub-sub, you read once and broadcast to all subscribers.

Broker advantages:Implementing a broker in the middle provides several benefits beyond efficiency. It aggregates data from multiple sources, creating a 360-degree view of assets and processes. It provides a security layer for source systems that have little or no native security. It enables caching so high-frequency data doesn't overwhelm upstream systems.

Cloud architecture considerations:Pub-sub requires persistent connections, which creates complexity in cloud environments designed for stateless request-response patterns. Implementing MQTT and similar protocols at cloud scale requires different architectural patterns than traditional web applications. Factor this complexity into your cloud vendor selection.

For most industrial IoT applications, a hybrid approach works best—pub-sub for high-volume telemetry and events, request-response for discrete control actions and queries.

‍

IIoT Security: Building Defense in Depth

‍

Security in industrial IoT requires multiple layers because many source systems have little to no native security capabilities.

The fundamental don'ts:Never use default passwords. Never hard-code passwords in applications. Avoid protocols without encryption or access controls. Never expose industrial systems with public IP addresses. Don't disable certificate verification just because managing certificates is difficult. These seem obvious but remain common vulnerabilities.

Physical security matters:Air gaps and physical access controls are your first defense. If someone can easily plug an Ethernet cable from the IT network into the plant control network, you have a fundamental security problem. Physical wiring and network segmentation create essential boundaries.

Connection architecture:Use exclusively outbound connections from industrial facilities to the cloud. This is far more secure than allowing inbound connections. Firewall technology combined with outbound-only architectures significantly reduces attack surface.

Broker as security layer:An intermediate broker or middleware provides application-level security that source systems lack. If you architect it so the only way to access source systems is through the broker, it becomes an effective application firewall with granular access controls based on roles and functions.

Certificate management:Proper certificate management is non-negotiable despite its complexity. Yes, updating certificates on edge devices is difficult. But certificate verification protects against man-in-the-middle attacks. Invest in the infrastructure to manage this properly rather than disabling security features.

Industrial security requires defense in depth because no single measure is sufficient when dealing with decades-old equipment and mission-critical operations.

‍

IIoT Platform Selection: Evaluating Cloud Vendors and Third-Party Solutions

‍

Selecting an IoT platform involves more than comparing feature lists. You're choosing infrastructure that will constrain or enable your capabilities for years.

Core evaluation criteria:Geographic coverage matters—do they have data centers near your facilities for acceptable latency? Do they understand industrial use cases or are they designed for consumer IoT? Are they priced appropriately for massive industrial data volumes? Cloud ingress costs can be surprisingly high. What unique capabilities do they offer around analytics or other areas?

The multi-cloud reality:You're likely already running a multi-cloud environment even if unintentionally. Salesforce for CRM, hosted SAP for ERP, specialized analytics platforms—these are different clouds. Your IoT platform needs to integrate with this reality. Consider how platforms handle multi-cloud data integration.

Microsoft's industrial presence:Historically, Microsoft has maintained a stronger presence in industrial environments, partly due to Windows' dominance on the plant floor. This doesn't make Azure the automatic choice, but it's a consideration when evaluating ecosystem maturity.

Third-party platform value:Third-party platforms sitting on top of cloud infrastructure can provide valuable abstraction. They've already solved the portability problems and protocol integrations. The tradeoff is another vendor relationship, but they may enable faster deployment and reduce cloud vendor lock-in.

Existing IT relationships:Often the cloud vendor decision has already been made at the IT level. Your organization may have deep relationships with one cloud vendor. This constrains your options but also provides economies of scale and simplified governance. Work within this constraint rather than fighting it.

The platform decision is rarely purely technical—it involves existing relationships, organizational capabilities, and long-term strategic considerations.

‍

Avoiding Cloud Vendor Lock-In: The Abstraction Strategy

‍

Lock-in happens gradually, then suddenly. When you've accumulated petabytes of industrial data in one cloud, the gravity of that data makes migration extremely difficult and expensive.

Abstraction as insurance:Design your applications around abstractions rather than cloud-specific services. Define your requirements abstractly—"I need to store and retrieve time series data"—then implement against that abstraction. This lets you swap implementations without rewriting application logic.

Extensibility for evolution:New capabilities emerge constantly. Your architecture should make it easy to adopt new services without major refactoring. This requires planning for extensibility from the start—defining clean interfaces between components.

Third-party intermediaries:Platforms that abstract away cloud-specific implementations provide valuable insurance against lock-in. They've already done the work to support multiple cloud backends. The downside is you can't use cloud-specific features directly, but for many use cases the portability is worth it.

The distributed cloud problem:Even staying with one cloud vendor, multi-region deployments create complexity. How do you deploy applications consistently across regions? How do you create a holistic view of data distributed globally? Cloud vendors could do better here—this remains a difficult problem.

Regulatory and practical considerations:You may need different clouds in different regions due to regulatory requirements or practical considerations. China might require different cloud infrastructure than North America or Europe. Design for this reality from the start rather than retrofitting later.

Lock-in is partially inevitable given the scale of industrial data, but thoughtful abstraction and extensibility give you options when requirements change.

‍

Conclusion

Industrial IoT architecture isn't about choosing between edge and cloud, or between one cloud vendor and another. It's about making thoughtful decisions based on your specific requirements across availability, reliability, performance, and cost.

The most successful implementations follow clear principles: keep mission-critical workloads close to the hardware, abstract away vendor-specific implementations, design for the security threats that actually exist in industrial environments, and remember that 90-98% of industrial systems remain on-premise for good reasons.

Your role as a data leader is to establish the architectural principles that guide these decisions, then build the abstractions and governance that let you evolve as technology and business requirements change. The specifics of today's architecture will change. The principles that drove those decisions should remain sound.

The organizations succeeding with industrial IoT aren't necessarily using the newest technologies or the most sophisticated platforms. They're matching architectural patterns to real requirements, abstracting appropriately to maintain flexibility, and building on solid foundations of security and reliability. That's the framework that delivers value regardless of which vendors and technologies you choose.

‍

‍