Need → boundary → architecture → flows → requirements → communication families → revision.
Final debrief · course map
How to design a connected system
you can defend.
The course was not a catalogue of technologies. It was one design loop: turn an operational need into a system, make its exchanges explicit, qualify its guarantees, and revise the design when evidence changes.
Read this map from left to right.Each block is a question to reopen when a connected system changes.
The whole course in one line
One system. Five moves.
01MissionWhat must happen?
→
02ArchitectureWho is responsible for what?
→
03CommunicationHow do exchanges work?
→
04GuaranteesWhat is actually assured?
→
05RevisionWhat changes when assumptions fail?
Four missions
The same campus system, seen from four responsibilities.
Interaction → choreography → responsibilities → protocols → shared meaning → delivery semantics.
Device / nearby / edge / cloud placement follows latency, data, energy, resilience and operating constraints.
Expose assumptions, trace failures, revise the design and make the residual risk explicit.
Design reasoning map
Six questions to reopen on any connected system.
Do not memorize the boxes. Reuse the questions.
01
START FROM THE MISSION
What must the system actually do?
Look for
observation · command · maintenance · actors · constraints · operating context
Common trap
Starting from technologies.
02
STRUCTURE THE SYSTEM
Which roles exist, and where are they placed?
Look for
device · gateway · platform · direct / gateway-centred / hybrid · local / edge / cloud
Common trap
Drawing boxes without responsibilities.
03
MAKE COMMUNICATION EXPLICIT
How do the exchanges behave?
Look for
initiator · receiver · request/response · publish/subscribe · blocking · timing · choreography
Common trap
Confusing topology with choreography.
04
COMPOSE RESPONSIBILITIES
Which problem is solved at each level?
Look for
link · adaptation · network · transport · application exchange
Thread ≠ MQTTTCP ≠ Wi-Fi
Common trap
Comparing technologies that solve different responsibilities.
05
CHECK MEANING + GUARANTEES
Do systems understand the same thing, and what is actually guaranteed?
Look for
syntax · semantics · delivery scope · duplicates · disconnects · message delivery · physical effect
Common trap
Saying “reliable” without saying reliable for what.
06
REVISE THE DESIGN
What changed, and why must the architecture change?
Look for
broken assumption · requirement under pressure · affected responsibility · design change · residual risk
Common trap
Adding components without causal justification.
If you remember only six things
Keep the reasoning, not the catalogue.
These six statements are the shortest version of the course.
- 01Start from the mission, not from technologies.
- 02Separate structure, communication and guarantees.
- 03A technology only makes sense relative to its responsibility.
- 04Protocol interoperability is not semantic interoperability.
- 05A guarantee is meaningful only if its scope is explicit.
- 06A good architecture can be revised when assumptions fail.
Transfer check
Can the reasoning survive a different system?
Answer before opening the engineering anchor.
01MQTT works correctly, but two services still interpret the same payload differently. What failed?
Engineering anchor
Protocol transport can be correct while semantic interoperability is absent. Reopen the shared data model, units, identifiers and meaning.
02A command is retried after an acknowledgement is lost. What must be questioned before claiming “reliable command”?
Engineering anchor
Define the object and scope of the guarantee. Message delivery, operation execution and physical effect are different claims; duplicate effects may require durable operation identity and deduplication.
03A service must keep operating during temporary backhaul loss. What part of the design must reopen?
Engineering anchor
Revisit architecture, placement and communication together: what must remain local, what can buffer, which dependency failed and what degraded behaviour is acceptable?
Field guide essentials
Eight terms worth carrying into the next system.
Interaction patternHow participants exchange information at service level.
ChoreographyHow exchanges unfold over time.
ResponsibilityThe precise problem a mechanism solves.
StackA composition of mechanisms across distinct responsibilities.
Semantic interoperabilityShared meaning, not just compatible bytes or protocols.
Delivery scopeExactly what is guaranteed, and where.
Design changeThe structural change justified by new evidence.
Residual riskWhat remains possible after the mitigation.
Final takeaway
A connected system is defendable when its structure, exchanges, guarantees and revisions are justified from evidence.
Technology names are evidence only after the design question is clear.
Return to mission dossier →