UX Design · Study deck
IoT Architectures: Selection Methods
After choosing a model family, the team still needs a repeatable way to justify that choice.
UX Uma is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Trace architecture selection map across its components and failure boundaries.
- Validate worked review: shared facility platform with a concrete scenario and pass criteria.
- trace architecture selection map across its components and failure boundaries
- 'validate worked review: shared facility platform with a concrete scenario and pass criteria'
Major section
Architecture Selection Map
The chain finishes with: Operational Evidence, a: Decision Record, and a: Change Condition, so the selected architecture remains a revisable argument rather than a permanent drawing.
- User outcome: what the architecture must help deliver, protect, explain, or recover.
- Layer boundaries: what each layer owns, passes through, stores, transforms, and exposes.
Major section
Cross-Cutting Concerns
Security, privacy, identity, safety, accessibility, reliability, observability, and lifecycle management do not fit neatly into one layer.
- They must be reviewed across the model.
- A model that places "security" or "privacy" in one box is usually incomplete.
- Cross-cutting concerns need owners at every boundary they cross.
Major section
Architecture Fit Summary
Together,: Chosen model and monitoring, logs, incidents frame the architecture fit summary claim: iot architecture fit summary record: eight fields to preserve when a model is accepted.
- For architecture fit summary,: Chosen model supplies visible evidence; monitoring, logs, incidents constrains the decision.
- Layer responsibilities: what each layer owns, transforms, stores, exposes, and explicitly does not own.
Major section
Architecture Responsibility Record
Three-layer view: device, network, and application layers are enough when the review question is basic responsibility split.
- Five-layer view: perception, transport, processing, application, and business layers help when analytics, operations, and governance are part of the decision.
- Multi-view model: user journey, data flow, trust boundary, operations, and support views expose different failures in the same system.
- Cross-cutting concerns: security, privacy, accessibility, reliability, observability, and lifecycle ownership should appear across layers, not in one isolated box.
Major section
Worked Review: Shared Facility Platform
A shared facility platform combines sensors, controllers, gateways, dashboards, maintenance tools, and reports for several roles across multiple spaces.
- which roles need user, operator, support, and management views.
- whether device management, data quality, business reporting, and operational support need separate ownership.
- Change condition: Rerun the review when new roles, sites, device classes, external systems, data-retention rules, update workflows, or support tooling are added.
Major section
Common Findings
Layer names are clear, but ownership, state authority, and failure behavior are not.
- Device management is hidden inside the application layer without operational evidence.
- Business reporting depends on data whose meaning, quality, or retention is not owned.
- Extra layers create handoffs without reducing implementation or support complexity.
- The architecture record lacks an owner, known limit, open issue, or change condition.
Major section
Concept Relationships
Design Model Introduction explains why design models should guide decisions before implementation.
- Reference Architecture Responsibility Record expands reusable architecture views and templates after model selection is clear.
- Design Thinking for IoT validates whether architecture decisions support real user needs.
- Edge, Fog, and Cloud Computing explains deployment options that often shape architecture boundaries.
Deck summary
Key takeaways
The chain finishes with: Operational Evidence, a: Decision Record, and a: Change Condition, so the selected architecture remains a revisable argument rather than a permanent drawing.
- Security, privacy, identity, safety, accessibility, reliability, observability, and lifecycle management do not fit neatly into one layer.
- Together,: Chosen model and monitoring, logs, incidents frame the architecture fit summary claim: iot architecture fit summary record: eight fields to preserve when a model is accepted.
- Three-layer view: device, network, and application layers are enough when the review question is basic responsibility split.
- A shared facility platform combines sensors, controllers, gateways, dashboards, maintenance tools, and reports for several roles across multiple spaces.
Retrieval practice
Recall check
UX Uma says: answer from memory, then check your reasoning.
Q1A team chooses a five-layer IoT model, but the review shows that the middleware layer has no unique owner, no stored state, no decisions, and no support evidence. What is the strongest review response?
Show answer
Answer: B Architecture models are useful when their layers or views assign real responsibility and evidence.
Print reference
Answers
Answer key.
- B · Architecture models are useful when their layers or views assign real responsibility and evidence.