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.

selection
iotclass.org

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
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 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.
iotclass.org

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.
iotclass.org

Major section

Flow Evidence Guides Selection

Architecture selection is not a vote for cloud, edge, gateway, or a favorite reference model.

  • Beginner RuleChoose 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.
  • 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.
Architecture selection inputs list system context, flow classes, response target, disconnected work, data handling and operations. Each row asks for evidence about sensing, alert or command traffic, local or delayed response, buffering and support before choosing a deployment pattern.
Architecture selection inputs list system context, flow classes, response target, disconnected work, data handling and operations. Each row asks for evidence about sensing, alert or command traffic, local or delayed response, buffering and support before choosing a deployment pattern.
iotclass.org

Major section

Flow Evidence Guides Selection (continued)

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.
  • It should also name which deployment inventory changes would invalidate the comparison.
Architecture selection inputs list system context, flow classes, response target, disconnected work, data handling and operations. Each row asks for evidence about sensing, alert or command traffic, local or delayed response, buffering and support before choosing a deployment pattern.
Architecture selection inputs list system context, flow classes, response target, disconnected work, data handling and operations. Each row asks for evidence about sensing, alert or command traffic, local or delayed response, buffering and support before choosing a deployment pattern.
iotclass.org

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.
  • Device logic keeps a local action and safe state close to the physical event.
  • The paths in the Different flows can use different placement rules inside one architecture diagram show why one IoT system may use several placement rules.
  • The simplest flow should not force every other flow into the same tier.

Why it matters

Analytics can often sit in central data services because historical aggregation does not block local operation.

Different flows can use different placement rules inside one architecture.
Different flows can use different placement rules inside one architecture.
iotclass.org

Major section

Split Requirements Before Patterns (continued)

The paths in Figure: Different flows can use different placement rules inside show why one IoT system may use several placement rules.

  • A gateway can buffer telemetry and make site decisions while cloud services hold history, summaries, and analytics.
  • Selection RuleThe hardest flow sets the minimum local capability.
  • Environmental telemetry can be buffered and uploaded later.
Different flows can use different placement rules inside one architecture.
Different flows can use different placement rules inside one architecture.
iotclass.org

Major section

Split Requirements Before Patterns (continued)

A cloud report can arrive later without blocking a time-sensitive local response, and a buffered event can replay after a link returns.

  • Cloud-CenteredUse when devices can report upstream, local action is limited, and disconnected operation has low consequence.
  • Gateway or FogUse when local buffering, protocol translation, filtering, aggregation, or site-level ownership is needed.
  • Edge-AutonomousUse when bounded local decisions must continue without waiting for upstream connectivity or remote services.
iotclass.org

Major section

Split Requirements Before Patterns (continued)

Edge autonomy needs outage logs showing local control continues without upstream access.

  • Hybrid or FederatedUse when several sites, business units, or operational domains need local control plus shared coordination.
  • The comparison in Figure: Pattern comparison should explain why each flow fits asks which flow sets the hardest requirement.
  • Context: what is sensed, controlled, reported, or operated.
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 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.
iotclass.org

Major section

Split Requirements Before Patterns (continued)

Cloud-centered placement fits reporting with limited local action and low outage cost; its evidence includes schema checks for analytics.

  • Gateway or fog work can buffer, translate, or filter data near a site, with drain tests for queued telemetry.
  • Hybrid or federated placement adds boundary tests and interface owners across sites.
  • A building may use more than one pattern for comfort control, telemetry, maintenance, and history.
  • Maintenance diagnostics need device health, stale-reading, calibration, and replacement records.
iotclass.org

Major section

Split Requirements Before Patterns (continued)

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.

  • The fields below keep a hybrid or federated design precise enough for another reviewer to challenge.
  • Rejected alternatives: what was simpler or richer, and why it did not fit.
  • Validation evidence: traces, outage drills, boundary tests, inspections, or operating records.
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.
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.
iotclass.org

Major section

Testable Architecture Selection

The under-the-hood question is not whether the pattern name sounds correct.

  • The route in Figure: The review route moves from context and flow links site facts to design choice and tests; note when to review it again.
  • Outage drill: proof of what continues, buffers, stops, or degrades when connectivity is unavailable.
  • The route in the 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 diagram links site facts to design choice and tests; note when to review it again.
  • The three labels prevent a one-box testable architecture selection reading.

Why it matters

The three labels prevent a one-box testable architecture selection reading.

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 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.
iotclass.org

Major section

Testable Architecture Selection (continued)

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.

  • Boundary test: proof that a device, gateway, cloud service, or application can change without rewriting unrelated layers.
  • Operations drill: proof that field or support teams can commission, diagnose, update, and retire components.
  • The reference model lens should expose the dominant review risk.
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 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.
iotclass.org

Major section

Testable Architecture Selection (continued)

A view-based lens helps when function, information, deployment, and operations views need separate reviewers.

  • 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.
  • A testable selection has pass/fail evidence for each boundary it claims.
Different flows can use different placement rules inside one architecture.
Different flows can use different placement rules inside one architecture.
iotclass.org

Major section

Testable Architecture Selection (continued)

A service-support lens helps when registration, routing, support services, data handling, and applications need clear boundaries.

  • A constrained-device lens helps when energy, topology, retry behavior, local storage, or maintenance interval drives the design.
  • 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.
Architecture selection inputs list system context, flow classes, response target, disconnected work, data handling and operations. Each row asks for evidence about sensing, alert or command traffic, local or delayed response, buffering and support before choosing a deployment pattern.
Architecture selection inputs list system context, flow classes, response target, disconnected work, data handling and operations. Each row asks for evidence about sensing, alert or command traffic, local or delayed response, buffering and support before choosing a deployment pattern.
iotclass.org

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.
  • Treating every flow as if it has the same timing, autonomy, and ownership need is the usual source of weak architecture choices.
  • The practical move is to split the system by flow before comparing patterns.
  • The paths in Figure: Different flows can use different placement rules inside show why one IoT system may use several placement rules.
iotclass.org

Retrieval practice

Recall check 1 of 4

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?

APick the cloud, gateway, or edge pattern the team has delivered most often on past projects.
BClassify each flow by response target, outage behavior, data handling, owner, proof, and placement.
CDraw one reference diagram first, then force telemetry, alerts, diagnostics, and analytics into it.
DWait for implementation to reveal the hardest flow, then adjust owners and interfaces later.
Show answer

Answer: B 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.

iotclass.org

Retrieval practice

Recall check 2 of 4

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?

AMove both flows to the cloud because trend reports already tolerate delayed processing.
BPut every feature at the edge because one control path needs local autonomy.
CSkip the decision record because mixed placement is too complex to review.
DKeep control local, buffer telemetry, and send trend reports upstream when connectivity returns.
Show answer

Answer: D Architecture selection should split mixed requirements by flow and record the pattern, evidence, rejected alternatives, owner, and review condition.

iotclass.org

Retrieval practice

Recall check 3 of 4

Blueprint Bina says: answer from memory, then check your reasoning.

Q3A battery field node has sparse links, local storage, and long service gaps. Which model lens best exposes its main review risk?

AUse broad layers that conceal battery, retry, and field-service limits.
BUse a constrained-device lens for energy, topology, retries, storage, and service.
CUse only a provider service list without weak-link behaviour.
DUse every model lens without naming the device's main review gap.
Show answer

Answer: B Those are the pressures that can break the field design.

iotclass.org

Retrieval practice

Recall check 4 of 4

Blueprint Bina says: answer from memory, then check your reasoning.

Q4Why should an architecture selection record include a review condition?

ABecause review conditions prove the original architecture pattern was always incorrect.
BBecause every IoT system must eventually migrate into a cloud-centered pattern.
CBecause reference model lenses remove the need for traces, drills, and operating records.
DBecause flow behavior, autonomy, ownership, operations, or validation evidence can drift after selection.
Show answer

Answer: D Selection records need review conditions because flow, autonomy, data, ownership, operations, and evidence can drift after the original review.

iotclass.org

Print reference

Answers

Answer key.

  1. B · 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.
  2. D · Architecture selection should split mixed requirements by flow and record the pattern, evidence, rejected alternatives, owner, and review condition.
  3. B · Those are the pressures that can break the field design.
  4. D · Selection records need review conditions because flow, autonomy, data, ownership, operations, and evidence can drift after the original review.
iotclass.org