6 Choosing an IoT Architecture Pattern

6.1 Start With the Decision You Can Defend

Picture a cold-room sensor that must raise a local alarm even when the outside link is down. Managers also want fleet trends in the cloud. Those two needs already suggest different places for fast action and long-term analysis.

Begin with one end-to-end flow. Mark the source, each handoff, the needed response time, the owner, and the safe result when a part fails. Do this before choosing a named reference architecture. Then compare only the patterns that can meet the hard needs.

Test the choice with a link outage, a delayed reading, a failed update, and a change in fleet size. Keep the evidence beside the decision. A reference architecture is a guide, not a finished design. Its boxes do not prove capacity, security, cost, or support at the real site.

Go deeper in two steps. The Practitioner section splits requirements into an Architecture Selection Record. Under the Hood turns the chosen pattern into tests that can prove or reject it.

Use one card per flow. Give the flow a name. Mark its source, receiver, rate, size, time limit, privacy need, and safe failure. Add the team that owns each handoff. Keep hard needs separate from useful wishes.

Now place work only where the flow needs it. Keep a fast safety rule near the machine. Put a fleet trend where the full history can be used. Add a store when a link gap must not lose data. Each box must answer a need on the card.

Test the hardest flow first. Remove the cloud link. Fill a queue. Delay a message. Change the fleet size. Record which claim still holds. Choose the least complex pattern that passes, and write the event that would force a new review.

Architecture selection starts when two plausible designs both seem reasonable. One puts more work at the edge, another centralizes it in the cloud, and a third adds gateways, brokers, or domain services. The right answer depends on the evidence, not on the nicest diagram.

Begin with the decision that will need defending later. Name the latency, reliability, cost, security, privacy, interoperability, and support constraints. Then use the selection framework to show why the chosen reference architecture fits those constraints better than the alternatives.

6.2 Flow Evidence Guides Selection

Architecture selection is not a vote for cloud, edge, gateway, or a favorite reference model. It is a review of what the system must do, where each flow belongs, what must keep working during disruption, and who can prove that the selected pattern is still valid.

A single IoT system can contain several different flows. Periodic telemetry can tolerate delay, but a bounded local-control flow may need to continue when upstream services are unavailable. Diagnostics may need operating records, while analytics can often run centrally after data is buffered. Treating every flow as if it has the same timing, autonomy, and ownership need is the usual source of weak architecture choices.

For example, a campus building system might publish zone temperature telemetry over MQTT every minute, keep actuator setpoints inside a BACnet or Modbus gateway, and send nightly energy summaries to a time-series service. Those flows can share device identity, timestamp conventions, and inventory records, but their placement proof is different: outage logs for local control, buffer-drain evidence for telemetry, schema checks for analytics, and support records for operations. The selection record should keep those proofs separate instead of hiding them under one pattern label. It should also name which deployment inventory changes would invalidate the comparison.

6.3 Split Requirements Before Patterns

The practical move is to split the system by flow before comparing patterns. Telemetry, alerts, commands, configuration, diagnostics, analytics, and user workflows can share infrastructure only where their timing, autonomy, data-quality, and ownership needs are compatible.

One relationship governs split requirements before patterns. The diagram Figure 6.1 states it as: Different flows can use different placement rules inside one architecture. Study Device and Operations.

The route through Figure 6.1 is figure-specific: Device states one concern, Operations names another, and uses summaries closes the scope. That structure supports split requirements before patterns: Different flows can use different placement rules inside one architecture.

Reviewers need the diagram Figure 6.2 before accepting split requirements before patterns. The proposition under review is: Pattern comparison should explain why each flow fits a cloud-centered, gateway or fog, edge-autonomous, or hybrid pattern, and what evidence would force another review. Its visible anchors include Architecture Pattern Fit Comes From Flow Evidence and Cloud-centered.

For split requirements before patterns, the diagram Figure 6.2 uses Architecture Pattern Fit Comes From Flow Evidence as the entry and Cloud-centered as a later checkpoint. Finish at Best when devices. The full reading conveys: Pattern comparison should explain why each flow fits a cloud-centered, gateway or fog, edge-autonomous, or hybrid pattern, and what evidence would force another review.

For a building monitoring system, local comfort control may need gateway or edge logic because occupants expect bounded local behavior during upstream outages. Environmental telemetry can be buffered and uploaded later. Maintenance diagnostics need device health, stale-reading, calibration, and replacement records. Analytics can often sit in central data services because historical aggregation does not block local operation.

Make the split visible in the record. For each flow, write the tolerated delay, local fallback, data-quality rule, interface owner, and validation artifact. That keeps a practical hybrid from becoming a vague compromise and gives reviewers a concrete way to challenge the placement.

6.4 Testable Architecture Selection

The under-the-hood question is not whether the pattern name sounds correct. It is whether the system can produce evidence that the selected placement still meets response, autonomy, data-quality, ownership, and operations requirements.

Use the diagram Figure 6.3 to ground testable architecture selection visually. Its specific claim is: The review route moves from context and flow evidence to pattern choice, model lens, validation evidence, and a review condition tied to autonomy, data handling, ownership, operations, or evidence changes. Begin with Architecture Selection Is A Review Route and keep hybrid/federated in view.

Locate Architecture Selection Is A Review Route in the diagram Figure 6.3, then compare hybrid/federated with validation evidence, owner, and review trigger. The three labels prevent a one-box testable architecture selection reading. Their relevance to hybrid/federated is: The review route moves from context and flow evidence to pattern choice, model lens, validation evidence, and a review condition tied to autonomy, data handling, ownership, operations, or evidence changes.

The reference model lens should expose the dominant review risk. A compact layer lens may be enough for broad device, network, processing, and application responsibilities. A service-support lens helps when registration, routing, support services, data handling, and applications need clear boundaries. A view-based lens helps when function, information, deployment, and operations views need separate reviewers. A constrained-device lens helps when energy, topology, retry behavior, local storage, or maintenance interval drives the design.

A testable selection has pass/fail evidence for each boundary it claims. If gateway autonomy is the reason for the pattern, the outage drill should show which commands continue, which telemetry queues, how stale readings are labeled, and when upstream reconciliation occurs. If central analytics is the reason, the evidence should show accepted schemas, duplicate handling, late-arriving data policy, and the owner of model or dashboard changes.

The next testable architecture selection step needs Architecture Selection Record Makes The Pattern Testable as a visual checkpoint. At Figure 6.4, 5 Rejected options supplies the relationship to challenge: The selection record keeps context, flow groups, chosen pattern, model lens, rejected alternatives, validation proof, owner, and review trigger visible so an architecture preference becomes a bounded operating claim.

The diagram Figure 6.4 first names Architecture Selection Record Makes The Pattern Testable, then separates 5 Rejected options from A valid record is a bounded operating claim. Carry checkpoints 5 Rejected options and A valid record is a bounded operating claim into testable architecture selection with Architecture Selection Record Makes The Pattern Testable. Their combined proposition is: The selection record keeps context, flow groups, chosen pattern, model lens, rejected alternatives, validation proof, owner, and review trigger visible so an architecture preference becomes a bounded operating claim.

6.5 Summary

IoT architecture selection is a structured review of flows, constraints, owners, and evidence. Start with what the system must do when it is connected, disconnected, controlled locally, reporting upstream, being updated, or being operated in the field. Split flows with different needs, choose the simplest pattern that satisfies the hardest flow, and select the reference model lens that exposes the dominant review risk.

6.6 Key Takeaway

6.7 See Also

Continue with the chapter that supplies the missing evidence for the selection. Use model introductions to clarify boundaries, applications to compare domain adaptations, pitfalls to challenge failure assumptions, and the worked example or lab to prove the chosen route. Preserve the requirements, rejected alternatives, owners, and reopen conditions as you move so later detail strengthens rather than silently replaces the decision.

• Introduction to IoT Reference Models - the model families used to describe architecture responsibilities.
• The Seven-Level IoT Architecture - a layered lens for responsibilities across device, network, processing, and application concerns.
• Reference Architecture Applications - applying architecture choices across realistic domains.
• Common IoT Reference Architecture Pitfalls - failure patterns when selection evidence is weak.