17 IoT Architectures: Model Evidence
17.1 Start With the Decision
Picture a school with a room sensor. The sensor reads the air.
17.2 Route Overview
This is part 1 of 2. Continue with IoT Architectures: Selection Methods.
17.3 Part Objectives
- Trace check your architecture model across its components and failure boundaries.
- Trace layers change state authority across its components and failure boundaries.
17.4 Chapter Roadmap
- Start Simple
- In 60 Seconds
- Check Your Architecture Model
- Minimum Viable Understanding
- Prerequisites
- Architecture Models as Risk Filters
- Match Artifacts to Decisions
- Layers Change State Authority
-
Which part failed when an old reading says the room is safe?
17.5 Start Simple
Picture a school with a room sensor. The sensor reads the air. A small hub sends the reading. An app shows it to the site team. If the app says the room is safe when the reading is old, someone must know which part failed and who must fix it.
An architecture model is a plan that puts each system job in a named box. A layer is one group of related jobs. The plan might give sensing to the device, data transfer to the hub, and the screen to the app. Each box needs an owner. Each handoff needs a test.
Start with the promise made to the user. Then trace the data from the room to the screen. Trace a command back the other way. Ask what still works when the hub or cloud is down. Ask which log shows where the path broke. This turns a diagram into a tool the team can use.
A small product may need only three layers: device, network, and app. A larger product may need more. It might split out data work, device care, business rules, or support. Add a layer only when it gives a real job a clear owner. More boxes do not make a design safer by themselves.
Some needs cross every layer. Security controls who may act. Privacy sets limits on data use. Safety deals with harm. Accessibility helps people use the product in different ways. Each need must have an owner at every handoff where it can fail.
Keep two paths separate. The data path runs from a raw reading to the value on screen. The control path runs from a user’s wish to a real change, such as a valve closing. For both paths, record the source, time, owner, result, and way back from a fault.
The simple story here leaves out exact state rules, message formats, and platform choices. The Practitioner section shows which design records fit each choice. Under the Hood shows how layers can hold different versions of the same state. Use those levels when one plain box could hide a conflict.
Try the room sensor case. The user needs a fresh room value. The device owns the first reading. The hub owns the local link. The app owns what the user sees. The team must name how old a value may be before the app marks it as stale.
Now cut the cloud link. Can the room still show a value on site? Can an alarm still sound? Does the app show that its last value is old? A useful plan answers each point. It does not hide all three inside a box called “application.”
Next, trace a command. A user asks for more fresh air. The app records the wish. A rule checks whether the user may act. The command crosses the network. A controller starts a fan. A new reading shows whether the room changed. Each step has a clear result.
Keep the wish and the real result apart. A sent command does not prove that the fan moved. An app message does not prove that the room changed. The control path needs a reply from the device and a later check from the sensor.
Ask who owns a fault at each step. A dead sensor is not an app fault. A blocked account is not a radio fault. A stale cloud copy is not a fresh room reading. Clear layer names help the help desk send the work to the right team.
Do the same for data care. Who may see the room value? How long may it be kept? Which log shows a change to the rule? Who can delete it? These needs cross the boxes, so the plan must show them on each handoff.
Use three layers while those answers stay clear. Add a data or support layer when one team can no longer own the work as one job. Add a second view when a single stack cannot show both where parts run and where truth lives.
End with a short fit note. Name the user promise. Draw the two paths. List the owners. State what works offline. Mark the risks the plan leaves out. Name the event that will make the team review the plan again.
Read the note as a new team member. Can you find the source of a value? Can you find the owner of a command? Can you tell fresh state from old state? Can you find the safe step after a fault? If any answer is no, the plan needs one more clear label or view.
Do not add a box just to fix a vague name. First state the job in plain words. Then decide whether it belongs to an old layer or needs a new one. The aim is a plan that stays clear as the product grows.
Use a plain key on the drawing. Show devices, links, stores, people, and outside services. Mark the owner beside each one. Use arrows for real data or commands. Do not use an arrow just to mean that two ideas are linked.
Check the plan after a real fault drill. If the team found the cause and owner fast, the view helped. If they had to guess, add the missing path or state. Keep the plan as small as the work allows.
Put the date and owner on the plan. Keep the last fault note with it. Review both when a path or team changes.
An architecture model becomes a UX tool when it tells the team who owns the user-visible promise. Start with the state, command, data, permission, and support boundaries that affect people, then choose the model that makes those responsibilities clear enough to test and change.
17.6 In 60 Seconds
Architecture models help a team decide where device sensing, connectivity, data processing, application behavior, business policy, operations, security, and support responsibilities belong.
The UX review question is not “which architecture diagram looks most complete?” The useful question is whether the chosen model helps the team make user-facing behavior, failure recovery, data responsibility, ownership, and support evidence clearer without adding unnecessary coordination overhead.
17.7 Learning Objectives
By the end of this chapter, you will be able to:
- compare simple layered, expanded layered, and multi-view architecture models for IoT design work
- review whether architecture complexity matches user outcomes, system scope, team boundaries, and operational needs
- define layer responsibilities without hiding ownership, failure, privacy, or support evidence
- identify when cross-cutting concerns require explicit review across layers and views
- write an architecture fit summary with accepted limits, owners, and change conditions
17.8 Minimum Viable Understanding
An IoT architecture model is reviewable only when it names the user outcome, system boundary, participants, layer responsibilities, decision owners, data paths, local/cloud boundaries, operational evidence, security and privacy responsibilities, accepted tradeoffs, and change conditions.
Avoid accepting a model because it is common, formal, simple, or detailed. A model is useful when it improves decisions. It is harmful when it creates vague boxes that no team owns or when it hides important behavior behind a generic layer name.
17.9 Prerequisites
This chapter builds on:
- Design Model Introduction, which introduces why design models matter before implementation.
- Connected Device Fundamentals, which defines device roles and boundaries.
- Layered Network Models, which explains protocol layers behind IoT communication paths.
- IoT Reference Models, which provides broader reference-model vocabulary.
17.10 Architecture Models as Risk Filters
An IoT architecture model should expose the risks that matter for a product decision. A three-layer view may be enough for a small sensor-gateway-app system. A multi-view model is justified when one diagram cannot explain data meaning, deployment placement, identity, operations, and support responsibility at the same time.
The number of architecture layers should follow the decisions that need owners, not a preferred template. Compare the two branches in Figure 17.1 before deciding whether a compact view can expose the product’s real risks.
The Simple branch of Figure 17.1 stops at Perception, Network, and Application, a useful fit for fewer than 100 devices and a single team. The Complex branch retains those foundations but inserts Middleware and caps the stack with Business, making service orchestration and policy visible for multi-team or enterprise deployments. The arrow marked Scale grows is the narrative hinge: add layers only when growing ownership and integration risks need somewhere explicit to live.
The model choice shapes the user experience. If alert rules move from a gateway to the cloud, latency, outage behavior, privacy boundary, support logs, and update ownership all change. If device health is hidden inside an application layer, users may see a stale “online” state while support cannot tell whether the fault is power, radio, gateway, broker, cloud, account, or policy.
Choose the lightest model that can answer the review question. A classroom weather station may only need device, gateway, and application layers. A managed building system may need separate views for edge analytics, tenant identity, role-based access, cloud ingestion, data retention, service desk diagnostics, and facilities handover. A richer model is justified by decisions it makes clearer, not by the number of boxes it contains.
The architecture review should also name what the model intentionally leaves out. A three-layer model can be accepted when it records that firmware updates are manual, alerts are advisory, cloud outage leaves local display working, and support can inspect gateway logs. The same model becomes weak when it hides OTA rollout, audit history, remote command safety, or privacy review behind a generic application layer.
Simple model: use device, communication/gateway, and application layers when responsibilities are clear and the product has few roles. Expanded model: add device management, processing, business policy, analytics, integration, or operations layers only when they own real decisions. Multi-view model: use functional, information, deployment, operational, and risk views when teams need different evidence from the same system. Fit summary: record the chosen model, rejected alternatives, accepted limits, owner, open issue, and trigger for review after scope changes.
17.11 Match Artifacts to Decisions
Use concrete architecture artifacts when they answer a review question. A C4 context or container view can show people, devices, gateways, apps, brokers, cloud services, and external platforms. A UML sequence diagram can test commissioning, command acknowledgement, and rollback timing. A UML or SysML state machine can expose offline, stale, denied, overridden, pending, and recovered states.
Start from the product decision rather than the artifact library. If the question is where alert rules should run, compare gateway rules, AWS IoT Core rules, Azure IoT Hub routing plus Azure Functions, a Kubernetes service, and a mobile-only rule against latency, local fallback, auditability, and ownership. If the question is device management, compare LwM2M objects, Matter clusters, vendor device shadows, OTA rollout tooling, and support-console evidence.
- Pick the decision. Example: Should room alert rules run on the gateway, in AWS IoT Core rules, in Azure IoT Hub routing plus a function, or in the mobile app?
- Pick the artifact. Use AsyncAPI for MQTT topics, OpenAPI for service APIs, JSON Schema for payloads, a deployment diagram for edge/cloud placement, or a responsibility matrix for layer ownership.
- Pick the acceptance check. Test latency, local fallback, data quality, privacy boundary, update path, support diagnosis, and who owns changes after launch.
Real systems often need mixed views. A Matter device may need a cluster/capability view, a fabric and controller ownership view, and a support view. An industrial gateway may need OPC UA information modeling, MQTT topic contracts, network segmentation, and maintenance workflow evidence.
Document the exact evidence that would change the model. A fleet that adds cellular backhaul may need a deployment and cost view. A product that adds tenants may need an identity and authorization view. A healthcare or safety workflow may need audit, consent, fail-safe command, and incident-response views. A useful architecture record gives each future reviewer a clear reason to keep, simplify, or expand the model.
17.13 Continue to the Next Part
Carry this evidence into IoT Architectures: Selection Methods, which begins with Architecture Selection Map.