Connected Product and Service Design · Study deck
IoT Architectures: Model Evidence
Picture a school with a room sensor.
UX Uma is your guide for this deck.
After studying this chapter
Learning objectives
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
Major section
Start Simple
The panel connects the wall sensor, the small hub, and the app, while the person using the app is left unsure where the stale value began.
- The architecture model below gives each handoff an owner and a test.
- A small hub sends the reading.
- An app shows it to the site team.
- A layer is one group of related jobs.
Major section
Start Simple (continued)
An architecture model is a plan that puts each system job in a named box.
- 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.
- This turns a diagram into a tool the team can use.
Major section
Start Simple (continued)
Each need must have an owner at every handoff where it can fail.
- A larger product may need more.
- It might split out data work, device care, business rules, or support.
- More boxes do not make a design safer by themselves.
- Some needs cross every layer.
Major section
Start Simple (continued)
Security controls who may act.
- Privacy sets limits on data use.
- Accessibility helps people use the product in different ways.
- The data path runs from a raw reading to the value on screen.
- The simple story here leaves out exact state rules, message formats, and platform choices.
Major section
Start Simple (continued)
The Practitioner section shows which design records fit each choice.
- Under the Hood shows how layers can hold different versions of the same state.
- The user needs a fresh room value.
- The app owns what the user sees.
- The team must name how old a value may be before the app marks it as stale.
Major section
Architecture Models as Risk Filters
The number of architecture layers should follow the decisions that need owners, not a preferred template.
- 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 classroom weather station may only need device, gateway, and application layers.
Major section
Architecture Models as Risk Filters (continued)
A richer model is justified by decisions it makes clearer, not by the number of boxes it contains.
- A multi-view model is justified when one diagram cannot explain data meaning, deployment placement, identity, operations, and support responsibility at the same time.
- If alert rules move from a gateway to the cloud, latency, outage behavior, privacy boundary, support logs, and update ownership all change.
- The architecture review should also name what the model intentionally leaves out.
Major section
Match Artifacts to Decisions
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.
- Real systems often need mixed views.
Major section
Match Artifacts to Decisions (continued)
If the question is device management, compare LwM2M objects, Matter clusters, vendor device shadows, OTA rollout tooling, and support-console evidence.
- 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.
- A fleet that adds cellular backhaul may need a deployment and cost view.
Major section
Layers Change State Authority
The authoritative source for a live temperature, an alert threshold, a command acknowledgement, a firmware version, a billing event, and a user role may be different systems.
- The architecture model must say which state is authoritative for each user promise.
- MQTT topics need ownership and quality-of-service rules.
- CoAP resources need response-code handling.
Major section
Layers Change State Authority (continued)
Sensor firmware may hold measured state, a gateway may cache state, an MQTT broker may retain the last message, a digital twin may store desired and reported properties, and an app may display a local cache.
- OPC UA nodes carry industrial information-model meaning.
- Architecture boundaries also decide where errors are translated.
- If the model does not preserve cause, timestamp, source, and retry state across those translations, support teams cannot distinguish a bad sensor, a stale retained message, a policy denial, or a delayed cloud write.
Deck summary
Key takeaways
The panel connects the wall sensor, the small hub, and the app, while the person using the app is left unsure where the stale value began.
- An architecture model is a plan that puts each system job in a named box.
- Each need must have an owner at every handoff where it can fail.
- Security controls who may act.
- The Practitioner section shows which design records fit each choice.
Retrieval practice
Recall check 1 of 2
UX Uma says: answer from memory, then check your reasoning.
Q1A privacy rule applies to a sensor, gateway, cloud store, and support export. How should the architecture review handle it?
Show answer
Answer: B Name the rule and owner at each handoff, then test where it could fail.
Retrieval practice
Recall check 2 of 2
UX Uma says: answer from memory, then check your reasoning.
Q2A team is choosing between a simple layered model and an expanded model for a room-monitoring product. Which architecture rationale is strong enough to accept the model?
Show answer
Answer: C Architecture records are useful when they tie model choice to user outcomes, layer responsibilities, data and command paths, cross-cutting ownership, operations evidence, accepted limits, and change conditions.
Print reference
Answers
Answer key.
- B · Name the rule and owner at each handoff, then test where it could fail.
- C · Architecture records are useful when they tie model choice to user outcomes, layer responsibilities, data and command paths, cross-cutting ownership, operations evidence, accepted limits, and change conditions.