Reference Architectures · Study deck
Choosing an IoT Architecture Pattern
Picture a cold-room sensor that must raise a local alarm even when the outside link is down.
Blueprint Bina is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Classify system flows (telemetry, commands, alerts, configuration, diagnostics, analytics, workflows) by response target, autonomy need, and ownership before choosing a placement pattern
- Choose the simplest architecture pattern (cloud-centered, gateway/fog, edge-autonomous, hybrid/federated) that satisfies the hardest flow without forcing every flow into the same tier
- Write an architecture selection record naming context, flow groups, chosen pattern, rejected alternatives, validation evidence, and review condition
- Select validation evidence (flow trace, outage drill, boundary test, operations drill, data-quality review) that proves a placement choice still holds
Major section
Start With the Decision You Can Defend
Those two needs already suggest different places for fast action and long-term analysis.
- A reference architecture is a guide, not a finished design.
- Its boxes do not prove capacity, security, cost, or support at the real site.
- Each box must answer a need on the card.
Major section
Flow Evidence Guides Selection
Architecture selection is not a vote for cloud, edge, gateway, or a favorite reference model.
- Beginner Rule Choose the simplest architecture pattern that satisfies the hardest flow, then record what the choice hides and which evidence would require another review.
- A single IoT system can contain several different flows.
Major section
Flow Evidence Guides Selection (continued)
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.
- The selection record should keep those proofs separate instead of hiding them under one pattern label.
Major section
Flow Evidence Guides Selection (continued)
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.
- It should also name which deployment inventory changes would invalidate the comparison.
- Autonomy Need Decide what must continue if connectivity, cloud services, or operators are unavailable.
Major section
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.
- That structure supports split requirements before patterns: Different flows can use different placement rules inside one architecture.
Major section
Split Requirements Before Patterns (continued)
Selection Rule The hardest flow sets the minimum local capability.
- The simplest flow should not force every other flow into the same tier.
- Cloud-Centered Use when devices can report upstream, local action is limited, and disconnected operation has low consequence.
- Its visible anchors include Architecture Pattern Fit Comes From Flow Evidence and: Cloud-centered.
Major section
Split Requirements Before Patterns (continued)
Environmental telemetry can be buffered and uploaded later.
- Gateway or Fog Use when local buffering, protocol translation, filtering, aggregation, or site-level ownership is needed.
- Edge-Autonomous Use when bounded local decisions must continue without waiting for upstream connectivity or remote services.
- Maintenance diagnostics need device health, stale-reading, calibration, and replacement records.
Major section
Split Requirements Before Patterns (continued)
The fields below keep a hybrid or federated design precise enough for another reviewer to challenge.
- Hybrid or Federated Use when several sites, business units, or operational domains need local control plus shared coordination.
- Context: what is sensed, controlled, reported, or operated.
- Rejected alternatives: what was simpler or richer, and why it did not fit.
Major section
Split Requirements Before Patterns (continued)
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.
- Validation evidence: traces, outage drills, boundary tests, inspections, or operating records.
- That keeps a practical hybrid from becoming a vague compromise and gives reviewers a concrete way to challenge the placement.
- Analytics can often sit in central data services because historical aggregation does not block local operation.
Major section
Testable Architecture Selection
The under-the-hood question is not whether the pattern name sounds correct.
- 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.
- The reference model lens should expose the dominant review risk.
Major section
Testable Architecture Selection (continued)
Operations drill: proof that field or support teams can commission, diagnose, update, and retire components.
- 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.
- Outage drill: proof of what continues, buffers, stops, or degrades when connectivity is unavailable.
- A testable selection has pass/fail evidence for each boundary it claims.
Major section
Testable Architecture Selection (continued)
The three labels prevent a one-box testable architecture selection reading.
- Boundary test: proof that a device, gateway, cloud service, or application can change without rewriting unrelated layers.
- Data-quality review: proof that timestamps, freshness, duplicates, summaries, and missing data are represented correctly.
- A compact layer lens may be enough for broad device, network, processing, and application responsibilities.
Major section
Testable Architecture Selection (continued)
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.
- 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.
Deck summary
Key takeaways
Those two needs already suggest different places for fast action and long-term analysis.
- Architecture selection is not a vote for cloud, edge, gateway, or a favorite reference model.
- Periodic telemetry can tolerate delay, but a bounded local-control flow may need to continue when upstream services are unavailable.
- 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.
- The practical move is to split the system by flow before comparing patterns.
Retrieval practice
Recall check 1 of 3
Blueprint Bina says: answer from memory, then check your reasoning.
Q1A building-monitoring system has telemetry, local control, diagnostics, and analytics flows. What should the team do before choosing cloud, gateway, edge, or hybrid placement?
Show answer
Answer: A Mixed IoT systems need flow-by-flow placement: local-control paths may require gateway or edge autonomy, while telemetry, diagnostics, and analytics can often use buffered or central paths.
Retrieval practice
Recall check 2 of 3
Blueprint Bina says: answer from memory, then check your reasoning.
Q2A system has a local equipment-control flow that must continue during upstream outages and a trend-reporting flow that can wait. Which selection is strongest?
Show answer
Answer: A Architecture selection should split mixed requirements by flow and record the pattern, evidence, rejected alternatives, owner, and review condition.
Retrieval practice
Recall check 3 of 3
Blueprint Bina says: answer from memory, then check your reasoning.
Q3Why should an architecture selection record include a review condition?
Show answer
Answer: A Selection records need review conditions because flow, autonomy, data, ownership, operations, and evidence can drift after the original review.
Print reference
Answers
Answer key.
- A · Mixed IoT systems need flow-by-flow placement: local-control paths may require gateway or edge autonomy, while telemetry, diagnostics, and analytics can often use buffered or central paths.
- A · Architecture selection should split mixed requirements by flow and record the pattern, evidence, rejected alternatives, owner, and review condition.
- A · Selection records need review conditions because flow, autonomy, data, ownership, operations, and evidence can drift after the original review.