18 IoT Architectures: Selection Methods
18.1 Start With the Decision
After choosing a model family, the team still needs a repeatable way to justify that choice.
18.2 Route Overview
This is part 2 of 2. Review IoT Architectures: Model Evidence for the preceding evidence.
18.3 Learning Objectives
- Trace architecture selection map across its components and failure boundaries.
- Validate worked review: shared facility platform with a concrete scenario and pass criteria.
18.4 Chapter Roadmap
- Architecture Selection Map
- Start With Architecture Work To Be Done
- Simple Layered Model
- Expanded Layered Model
- Multi-View Reference Thinking
- Layer Boundary Review
- Cross-Cutting Concerns
- Architecture Fit Checks
- Architecture Fit Summary
- Architecture Responsibility Record
- Worked Review: Room Monitoring Product
- Worked Review: Shared Facility Platform
- Common Findings
- Review Checklist
- Knowledge Check
- Matching Quiz
- Ordering Quiz
- Summary
- Key Takeaway
- Concept Relationships
- What’s Next
18.5 Architecture Selection Map
After choosing a model family, the team still needs a repeatable way to justify that choice. Figure 18.1 turns the chapter’s architecture questions into a decision chain that can be reviewed when the system changes.
Begin Figure 18.1 with User Outcome and System Scope; they define the value and estate that the model must explain. Model Choice then leads to Layer Boundaries, where owners, state, and paths become explicit, while Cross-Cutting Concerns prevents security and privacy from being trapped in one box. 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. System scope: devices, gateways, apps, sites, services, users, teams, and external systems. Model choice: simple layered model, expanded layered model, multi-view reference model, or a documented hybrid. Layer boundaries: what each layer owns, passes through, stores, transforms, and exposes. Cross-cutting concerns: security, privacy, identity, safety, reliability, accessibility, compliance, and support. Operational evidence: monitoring, logs, update path, replacement path, ownership transfer, and incident workflow. Record and change conditions: accepted limits, owners, open issues, and conditions after system or organization change.
18.6 Start With Architecture Work To Be Done
Architecture is not a decoration for a document. It is a tool for coordinating decisions.
Review:
what decisions the model is supposed to support. which teams, roles, or stakeholders need the model. what user-facing behavior depends on architectural boundaries. whether the model separates real responsibilities or invents artificial handoffs. whether the model can explain failure, support, update, replacement, and decommissioning behavior. whether the model is short enough to stay current as the system changes.
If a diagram cannot help a team answer “who owns this behavior?” or “what happens when this boundary fails?”, it is not yet useful enough for acceptance.
18.7 Simple Layered Model
A simple layered model is often enough when the system has a clear physical-device layer, a clear communication or gateway layer, and a clear application layer.
Review:
what belongs in the physical device boundary: sensing, actuation, firmware, power state, local control, and physical safety. what belongs in the communication boundary: local links, gateway behavior, buffering, translation, routing, and connectivity state. what belongs in the application boundary: user interface, rules, dashboards, reports, account policy, and data presentation. what crosses each boundary and in which format. which behavior continues locally if the application or cloud path is unavailable. whether support can separate device, gateway, network, account, and application causes.
A simple model is not a weak model. It is strong when the responsibility boundaries match the actual product and are easy for developers, users, installers, and support teams to understand.
18.8 Expanded Layered Model
An expanded layered model adds explicit responsibilities such as middleware, device management, business policy, analytics, integration, or operations when those responsibilities are large enough to need separate ownership.
Review:
why the extra layer exists and which decisions it owns. whether the layer performs work or only repeats another layer’s responsibility. whether device management, identity, data processing, rules, analytics, reporting, and business policy have clear owners. how errors move between layers without losing cause. how update, rollback, provisioning, and replacement workflows cross layers. whether adding the layer improves maintainability more than it increases coordination burden.
Extra layers should be earned by real complexity: multiple teams, multiple user roles, multi-site operation, heterogeneous device fleets, regulated records, enterprise integration, or operational workflows that would otherwise be mixed into one unclear application layer.
18.9 Multi-View Reference Thinking
Some systems cannot be reviewed well from one stack diagram. They need several views of the same system.
Useful views include:
- Functional view: services, commands, workflows, rules, user actions, and operator actions.
- Information view: data model, units, timestamps, quality, retention, lineage, and meaning.
- Deployment view: devices, gateways, networks, regions, sites, redundancy, and physical constraints.
- Operational view: monitoring, incident response, update workflow, support workflow, replacement, and decommissioning.
- Risk view: security, privacy, safety, accessibility, compliance, and misuse boundaries.
Multi-view thinking is useful when one team talks about services, another about data meaning, another about hardware placement, and another about operations. It is excessive when the views repeat the same information without improving a decision.
18.10 Layer Boundary Review
Layer names are only useful when the boundary is testable.
Review each boundary with these questions:
What enters this boundary? What leaves this boundary? What state is stored here? What decision is made here? What is intentionally not owned here? What evidence proves the boundary behaved correctly? What failure message or support signal appears when it does not? What change requires reviewing this boundary again?
Ambiguous boundaries create duplicated logic, inconsistent state, and confusing support paths. A clear boundary should make implementation and support simpler, not only the diagram cleaner.
18.11 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.
Review:
where identity is created, checked, stored, rotated, and revoked. where privacy notice, consent, retention, sharing, and deletion are enforced. where safety or critical local behavior remains available during outages. where accessibility requirements affect device setup, app feedback, physical controls, and alerts. where monitoring, logs, and support evidence are generated and correlated. where firmware, configuration, model, or policy updates are staged and rolled back.
A model that places “security” or “privacy” in one box is usually incomplete. Cross-cutting concerns need owners at every boundary they cross.
18.12 Architecture Fit Checks
Use fit checks to avoid both under-engineering and over-engineering.
A simple model may be too thin when:
device provisioning, updates, support, and replacement have no owner. many users, sites, teams, or external systems need different views of the same data. data quality, lineage, retention, or compliance rules are unclear. application code is absorbing device management, business policy, and operations all at once. support cannot tell which layer caused a user-visible issue.
An expanded or multi-view model may be too heavy when:
extra layers have no unique decisions. every change requires several teams to coordinate without a user-facing benefit. documents describe ideal layers but implementation bypasses them. teams debate box ownership more than tested behavior. the model cannot be updated after real design changes.
The right model is the lightest one that still assigns responsibility, preserves evidence, and supports recovery.
18.13 Architecture Fit Summary
Before deciding how Chosen model shapes architecture fit summary, inspect Figure 18.2 beside monitoring, logs, incidents. 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.
In the diagram, check Chosen model and monitoring, logs, incidents separately in Figure 18.2; together they make iot architecture fit summary record: eight fields to preserve when a model is accepted auditable. For architecture fit summary, Chosen model supplies visible evidence; monitoring, logs, incidents constrains the decision. In Figure 18.2, retain Chosen model beside monitoring, logs, incidents so architecture fit summary remains explicit.
Outcome and scope: user result, device roles, sites, users, services, teams, and external systems. Chosen model: simple layered, expanded layered, multi-view, or documented hybrid. Layer responsibilities: what each layer owns, transforms, stores, exposes, and explicitly does not own. Decision owners: where rules, state authority, identity, policy, and support decisions are made. Data and control paths: command, telemetry, alert, update, log, and fallback paths. Cross-cutting concerns: security, privacy, identity, safety, accessibility, reliability, and lifecycle ownership. Operational evidence: monitoring, logs, incidents, updates, replacement, transfer, and decommissioning evidence. Decision and change condition: accepted tradeoff, owner, known limit, open issue, and condition that reopens review.
The record should be concise enough to update whenever the device mix, user role, deployment site, gateway behavior, cloud boundary, team ownership, support workflow, or regulatory expectation changes.
18.14 Architecture Responsibility Record
Use reference architectures as explanation tools, not templates to copy:
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.
The architecture summary should name which view answered the question, which view was intentionally skipped, and what evidence would require a richer architecture model.
18.15 Worked Review: Room Monitoring Product
A small product monitors conditions in rooms and shows status in a mobile app. It has sensors, a gateway, a cloud service, and one user-facing app.
Architecture evidence to request
- the user outcome and the minimum device, gateway, and app behavior needed to support it
- what runs on the sensor, what runs on the gateway, and what runs in the application
- what happens if the gateway is offline, the app is unavailable, or the cloud path is delayed
- where state age, device health, alert rules, and user permissions are owned
- how support separates sensor power, local link, gateway, internet, cloud, and account issues
- how sensor replacement preserves room meaning and alert history
Likely review action
Approve a simple layered model if the sensor, gateway, and application responsibilities are explicit and the gateway/app outage behavior is visible. Hold the decision if alert rules or support evidence are hidden behind the generic word “cloud.”
Change condition
Rerun the review when alert rules move between gateway and cloud, device roles change, room assignment changes, user roles expand, or support evidence changes.
18.17 Common Findings
The model is chosen because it is familiar, not because it fits the decisions the team must make. 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. Security and privacy appear as one box instead of responsibilities across every boundary. The diagram shows data flow but not command, update, alert, log, or fallback paths. Support cannot distinguish device, gateway, cloud, account, policy, and application causes. Extra layers create handoffs without reducing implementation or support complexity. The architecture record lacks an owner, known limit, open issue, or change condition.
18.18 Review Checklist
Before accepting an architecture model, confirm that the record includes:
user outcome, system scope, device roles, user roles, team roles, and external systems. selected model and why simpler or richer alternatives were rejected. layer responsibilities, non-responsibilities, state ownership, and decision ownership. command, telemetry, alert, update, log, local, cloud, and fallback paths. cross-cutting responsibilities for security, privacy, identity, safety, accessibility, reliability, observability, and lifecycle. operational evidence for monitoring, support, incidents, updates, replacement, transfer, and decommissioning. user-facing failure and recovery behavior at each important boundary. accepted tradeoff, owner, known limit, open issue, and change condition.
18.19 Knowledge Check
18.20 Matching Quiz
18.21 Ordering Quiz
18.22 Summary
IoT architecture models help teams assign responsibility for devices, gateways, applications, data, policy, operations, security, privacy, support, and lifecycle behavior. The right model is not the most detailed one. It is the lightest model that still makes important decisions explicit and reviewable.
Strong architecture records show why a model fits the current system, what each layer or view owns, how commands and data cross boundaries, what works locally, how failures are diagnosed, and what change requires another review.
18.23 Key Takeaway
Architecture choices should connect users, devices, services, data flows, failure modes, and support responsibilities in one reviewed model.
18.24 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. 8 Facets of IoT Design reviews user-visible and platform-visible design dimensions that span architecture layers. Design Thinking for IoT validates whether architecture decisions support real user needs. IoT Design Patterns and Components applies implementation patterns inside the chosen architecture. Edge, Fog, and Cloud Computing explains deployment options that often shape architecture boundaries.
18.25 What’s Next
Continue to Reference Architecture Responsibility Record to review reusable architecture templates and reference views in more detail.
18.26 Continue Your Route
This final part closes the route from Architecture Selection Map through What’s Next. Return to IoT Architectures: Model Evidence or continue from the ux-design module index.