Direct answer

An IoT platform architecture diagram should show how a physical signal becomes trusted data, durable state, an operational decision, and—when appropriate—a controlled action. Use six responsibility layers: devices, edge, connectivity and ingress, platform services, data and analytics, and business applications. Then add the boundaries that actually determine production behavior: identity, tenancy, control authority, failure isolation, observability, and ownership.

Do not begin with vendor products. Begin with flows and responsibilities. Product choices can be placed inside the diagram after the team agrees on what must happen when a device is offline, an identity is revoked, a broker node fails, data arrives late, or a command is not completed.

Vendor-neutral IoT platform architecture diagram

┌─────────────────────────────────────────────────────────────────────┐
│ Business applications                                               │
│ Operations · workflows · customer APIs · reporting · digital twins │
└───────────────────────────────▲─────────────────────────────────────┘
                                │ business events / commands
┌───────────────────────────────┴─────────────────────────────────────┐
│ Platform services                                                   │
│ Registry · authorization · message routing · state · rules · jobs  │
│ OTA orchestration · tenant policy · audit · observability           │
└──────────────────────▲───────────────────────┬──────────────────────┘
                       │ telemetry / events    │ command intent
┌──────────────────────┴───────────────────────▼──────────────────────┐
│ Connectivity and ingress                                            │
│ MQTT / HTTP / CoAP endpoints · authentication · quotas · buffering │
└──────────────────────▲───────────────────────┬──────────────────────┘
                       │                       │
┌──────────────────────┴───────────────────────▼──────────────────────┐
│ Edge and gateways                                                   │
│ Protocol translation · local buffer · normalization · safe control │
└──────────────────────▲───────────────────────┬──────────────────────┘
                       │ field data            │ bounded control
┌──────────────────────┴───────────────────────▼──────────────────────┐
│ Devices and physical process                                        │
│ Sensors · actuators · firmware · secure identity · local safety     │
└─────────────────────────────────────────────────────────────────────┘

Cross-cutting planes:
  Data: immutable events · current state · time series · business data
  Trust: device identity · tenant boundary · authorization · audit
  Operations: health · backlog · latency · recovery · cost · ownership

Read the upward path as observation: a device samples the physical world, the edge adds context or protocol translation, ingress authenticates and admits traffic, platform services interpret it, and business applications turn it into work. Read the downward path as authority: a user or workflow proposes an action, policy decides whether it is permitted, the platform creates a bounded command, and the device reports the actual outcome.

Devices and edge gateways

The device layer owns sensing, actuation, firmware, protected identity material, and local safety behavior. It must define what happens when connectivity disappears. A safety interlock, hard real-time loop, or deterministic shutdown should not depend on a cloud round trip. The platform may request an operation, but the device or local controller remains responsible for enforcing physical limits.

The edge layer exists when the site needs protocol translation, local buffering, normalization, low-latency decisions, or separation from an unreliable upstream network. It should not become an undocumented second platform. Record which data is authoritative at the edge, how buffered records preserve timestamps and quality, how configuration is versioned, and how local state reconciles after reconnection. Use the edge-versus-cloud boundary guide to make each placement decision explicit.

Connectivity, authentication, and ingress

Connectivity is more than choosing MQTT, HTTP, or CoAP. The ingress boundary terminates transport security, authenticates a principal, applies connection and message quotas, validates protocol limits, and routes traffic without trusting tenant or device identifiers supplied by the client. Gateways, devices, backend services, and operators may all connect through different endpoints and require different policies.

Keep protocol acceptance separate from business acceptance. A successful MQTT PUBACK proves a hop-level exchange; it does not prove that a rule ran, a database committed, or a technician closed an incident. Define message expiry, retry, duplicate handling, dead-letter behavior, and overload policy before the fleet reaches production scale.

Identity, registry, and authorization

A device registry should connect a durable internal identifier to product model, credentials, current owner, lifecycle state, configuration eligibility, and policy version. Device identity proves which principal connected. Ownership says which tenant or operator currently controls the asset. Authorization decides which operation that principal may perform now. These are related facts, not one field.

Revocation must reach brokers, API gateways, caches, active sessions, and support tooling within a known window. Ownership transfer must remove old access before new control is enabled. The architecture diagram should show where those decisions are made and where they are enforced. Start with the device identity architecture and make every enforcement point visible.

Messaging, state, rules, and jobs

Messaging carries observations and intent between components. It should preserve a stable device message contract that distinguishes telemetry, events, commands, acknowledgements, and outcome state. Topic routing is not a substitute for a schema, and a queue is not a device state model.

A device shadow stores a useful current-state projection when devices are intermittent, but it must expose desired state, reported state, version, timestamp, and uncertainty. Immutable events belong in an event log or durable stream. High-volume measurements belong in storage designed for their write and query pattern. Do not put all three behind one generic “IoT database” box.

A rule engine should produce explainable events or jobs rather than directly scattering side effects across services. Long-running work needs an owner, retry policy, idempotency key, timeout, compensation or cancellation behavior, and an outcome record. Commands to physical systems additionally need authorization, expiry, acknowledgement, and verification.

Data, analytics, and business applications

Separate operational state from analytical history and business records. Operational state answers “what should the platform do now?” Time-series history answers “what happened over an interval?” Business data answers “which customer, asset, contract, ticket, or shipment does this affect?” Retention, correction, access, and recovery requirements differ across those stores.

Business applications should consume domain events and governed APIs instead of depending on broker internals or raw device payloads. This boundary keeps a dashboard redesign from changing firmware and keeps a protocol migration from rewriting every workflow. It also makes tenant isolation testable from device identity through storage and export; the multi-tenant isolation guide covers that end-to-end path.

Control plane and data plane

Draw the data plane and control plane separately. The data plane carries telemetry, events, state updates, commands, and acknowledgements. The control plane provisions identities, policies, schemas, device configuration, firmware releases, quotas, routing, and observability. Mixing them makes routine configuration changes indistinguishable from production traffic and makes emergency access difficult to audit.

Give control-plane changes versioning, approval, rollout, rollback, and evidence. A policy deployment that can disconnect the fleet deserves the same blast-radius controls as a firmware release. Administrative APIs should not bypass tenant boundaries or device-level authorization merely because they are operated by internal staff.

Failure boundaries and production review

Annotate every stateful component with its owner, source of truth, recovery objective, capacity limit, and degraded behavior. Test broker node loss, identity-service latency, downstream backpressure, storage unavailability, regional network failure, edge backlog replay, duplicate commands, and devices returning after long offline periods. A box labeled “high availability” is not evidence.

Capacity dimensions must remain separate: concurrent connections, authentication rate, publishes per second, routed deliveries, persistent sessions, stored state, queued backlog, time-series writes, command latency, and recovery time. Use the IoT platform capacity guide before assigning node counts or vendor limits.

The minimum useful review asks:

  1. Where is each identity authenticated and each action authorized?
  2. Which component owns current state, immutable history, and business truth?
  3. What continues locally when cloud connectivity fails?
  4. How are late, duplicate, invalid, or unauthorized messages handled?
  5. How does a command expire, receive acknowledgement, and prove outcome?
  6. Which tenant boundary is enforced at every shared component?
  7. How are configuration, policy, schema, and firmware changes rolled back?
  8. Which metrics prove backlog, latency, error, recovery, and operating cost?

Run the IoT architecture review checklist after the diagram has named these responsibilities. Continue with the IoT platform architecture learning path when the team needs to design each capability in depth.

Primary sources

The Microsoft Azure Architecture Center presents a baseline IoT flow from things through cloud gateways, processing, storage, and applications. The AWS Well-Architected IoT Lens organizes production review around design principles and operational trade-offs. NISTIR 8259A defines device cybersecurity capabilities that must remain visible across identification, configuration, data protection, interface access, software update, and cybersecurity-state awareness.

Use those sources as review inputs, not as a product shopping list. The final architecture must reflect the physical process, safety obligations, network conditions, fleet lifecycle, tenant model, recovery targets, and operating team that actually exist.