5 Reference Architectures Across Domains

5.1 Start With the System Someone Must Run

Picture a team that must run a sensor service after the demo ends. Someone must own each alert, update, data path, and repair.

First, write the user task and the few flows that make it work. Then map each job to a clear owner and a check that can prove it.

A broad model can reveal missing work, but it can also hide local needs. A narrow model is easy to read, but it may leave out a key risk.

That is the simple story, but it cannot choose each layer or owner for you. The records later in the chapter show how the local case changes the map.

Use the Practitioner section to turn the model into a testable record. Use Under the Hood to inspect overlays, drift, and hidden bounds in more depth.

Plain check

• Name the user task. Trace one full flow. Mark each owner. Mark each proof point.
• Add the local risks. Add the care tasks. Keep the map small. Reopen it on change.
• Use Practitioner to record. Use deeper boundary checks. Test one lost handoff. Fix the weak owner.

A reference architecture matters when it helps someone operate the system after the demo. Imagine a facilities team that must onboard devices, watch alerts, patch gateways, answer audit questions, and explain why a command did or did not run.

Use application examples to connect architecture patterns to those operating jobs. The point is not to copy a smart-home, factory, healthcare, or city diagram. The point is to see which responsibilities repeat and which evidence must be present before the pattern is trustworthy.

5.2 Model to Application Decision

A reference architecture is a reusable way to discuss responsibilities. An application architecture is the decision record that says how those responsibilities work in a specific building, factory, field deployment, fleet, or shared platform.

The practical move is to start from the application, not from the diagram. Name what the system senses, controls, reports, and maintains. Then choose the smallest reference model that makes device, connectivity, edge, data, application, and operations responsibilities visible.

For a soil-moisture system, the same reference layers mean different things than they do in a smart building. Sparse coverage makes buffering and freshness limits part of the architecture. Technician alerts make ownership and escalation part of the architecture. Battery replacement and sensor calibration make maintenance evidence part of the architecture. The model helps only after those application pressures are named.

The overview record should therefore state the application outcome, the flows that prove it, and the condition that would force the team to revisit the mapping.

That condition prevents silent drift.

Make the model to application decision premise visible in the diagram Figure 5.1: Apply the reference model by framing the application workflow, choosing the smallest useful model, adding domain pressure, assigning layer owners, tracing operating flows, and recording the evidence and reopen trigger. Begin by distinguishing Turn The Reference Model Into An Application Record from Device, network, edge, data.

Before using this part of the method, inspect Figure 5.1 to make model to application decision concrete. The visual is worth pausing on because its caption identifies the intended design point: Apply the reference model by framing the application workflow, choosing the smallest useful model, adding domain pressure, assigning layer owners, tracing operating flows, and recording the evidence and reopen trigger.

Read Figure 5.1 as an ordered review, not as decoration. Start at the first input or condition, follow the arrows through each intermediate responsibility, and finish at the evidence, decision, or operating outcome. In concrete terms, look for Six-step route from application workflow framing through base-model choice, domain pressure, layer ownership, flow tracing, evidence recording, and assumption-based reopening. That sequence explains why Apply the reference model by framing the application workflow, choosing the smallest useful model, adding domain pressure, assigning layer owners, tracing operating flows, and recording the evidence and reopen trigger. Carry the result into the running narrative by recording the claim, boundary, evidence, owner, and next recheck in the architecture record.

5.3 Application Architecture Record

The practitioner task is to turn the model into a concise record that another reviewer can use. The record should be specific enough to test, but small enough to maintain as the system evolves.

Start with a flow inventory. Telemetry, alerting, commands, configuration, diagnostics, updates, and operator workflows often need different placement. One application can legitimately mix local control, gateway buffering, cloud analytics, and enterprise reporting.

Write each flow as a responsibility chain rather than a technology chain. For occupancy-to-HVAC control, the chain might be sensor quality, local occupancy state, climate rule, actuator command, cloud summary, operator override, and incident review. The record should say which links can fail independently and which layer owns the proof for each link.

That chain becomes the review checklist.

Before using this part of the method, inspect Figure 5.2 to make application architecture record concrete. The visual is worth pausing on because its caption identifies the intended design point: Different application domains reuse the same layer vocabulary while changing the response need, data proof, owner boundary, risk trigger, and review evidence.

Read Figure 5.2 as an ordered review, not as decoration. Start with the headings or compared options, scan the rows or panels in their presented order, and finish by checking which evidence or constraint changes the decision. In concrete terms, look for Domain overlay map for applying an IoT reference architecture across smart building, industrial, field monitoring, fleet, and city platform contexts. That sequence explains why Different application domains reuse the same layer vocabulary while changing the response need, data proof, owner boundary, risk trigger, and review evidence. Carry the result into the running narrative by recording the claim, boundary, evidence, owner, and next recheck in the architecture record.

5.4 Boundaries, Overlays, and Evidence Drift

The hard part of applying a reference architecture is that one deployed component may carry several logical responsibilities. A gateway might validate measurements, buffer outages, run local rules, translate protocols, enforce identity, and forward evidence. The review should follow responsibilities, not just boxes.

Domain overlays make those responsibilities visible. A smart building overlay highlights comfort and safety behavior. An industrial overlay separates monitoring from control authority. A field-monitoring overlay exposes power, sparse connectivity, late data, and maintenance intervals. A fleet overlay handles mobile coverage and event confidence. A city platform overlay separates shared services from departmental ownership.

Concrete deployments show why the overlay distinction matters. A smart-home deployment typically routes light bulbs, locks, and appliances through a single hub or gateway that bridges Zigbee, Z-Wave, Bluetooth, and similar short-range protocols onto the home Wi-Fi network; the overlay pressure is that few accepted industry standards govern that hub, so poor release and patching practice becomes an architecture risk rather than a vendor detail. A city-platform overlay adds structure at the opposite scale: service domains such as electrical power, traffic control, and emergency or medical services reach a shared IP core network through border routers, a firewall, and an intrusion-prevention system before landing in a data center or cloud and an operations center that several departments share. The industrial overlay is a different pressure again. Industrial IoT (IIoT) sits at the intersection of consumer IoT and Industry 4.0-style automation, cyber-physical systems, and smart-factory practice. Where consumer IoT optimizes for individual convenience with limited machine-to-machine traffic, IIoT is built around operational efficiency, safety, and security, with extensive machine-to-machine communication and application areas that sit inside a facility rather than in a consumer's hand. That is why an industrial overlay separates monitoring from control authority in a way a smart-home overlay usually does not need to.

Evidence drift happens when one of those overlays changes without a matching architecture review. A dashboard may gain command authority, a gateway may start making local decisions, a data pipeline may drop quality flags, or a support team may inherit a workflow it did not design. The under-the-hood record should preserve the logical responsibility even when the physical component stays the same, so reviewers can see when a new behavior has crossed an old boundary.

That separation is what lets one gateway remain acceptable while one of its responsibilities needs a new test.

Before using this part of the method, inspect Figure 5.3 to make boundaries, overlays, and evidence drift concrete. The visual is worth pausing on because its caption identifies the intended design point: The base model stays useful only when the application overlay names the pressure that changes placement, evidence, ownership, and the condition for reopening the review.

Read Figure 5.3 as an ordered review, not as decoration. Start at the first input or condition, follow the arrows through each intermediate responsibility, and finish at the evidence, decision, or operating outcome. In concrete terms, look for Application architecture adaptation flow showing the base model, domain pressure, placement choice, flow proof, layer evidence, and reopen trigger. That sequence explains why The base model stays useful only when the application overlay names the pressure that changes placement, evidence, ownership, and the condition for reopening the review. Carry the result into the running narrative by recording the claim, boundary, evidence, owner, and next recheck in the architecture record.

Before using this part of the method, inspect Figure 5.4 to make authority drift concrete. The visual is worth pausing on because its caption identifies the intended design point: An evidence record keeps the application architecture reviewable by tying local requirements, owners, boundary decisions, validation evidence, residual risk, and reopen triggers to the drift checks that appear as requirements, owners.

Read Figure 5.4 as an ordered review, not as decoration. Start at the first input or condition, follow the arrows through each intermediate responsibility, and finish at the evidence, decision, or operating outcome. In concrete terms, look for Application architecture evidence record linking the application frame, layer owner, boundary and authority decision, flow validation, residual risk, and reopen trigger while checking boundary, evidence, terminology, and authority drift. That sequence explains why An evidence record keeps the application architecture reviewable by tying local requirements, owners, boundary decisions, validation evidence, residual risk, and reopen triggers to the drift checks that appear as requirements, owners. Carry the result into the running narrative by recording the claim, boundary, evidence, owner, and next recheck in the architecture record.

5.5 Summary

Reference architecture applications turn a reusable model into a reviewable design record. The model supplies layer vocabulary, but the application frame supplies purpose, users, response needs, data handling, operating context, and failure behavior. A useful review adds the domain overlay, assigns layer owners, traces the important flows, and records the evidence that proves each boundary is working.

5.6 Key Takeaway

5.7 See Also