Chapters
- 01 · Map the Teams and Systems
- 02 · Define What Each Handoff Carries
- 03 · Track Waiting, Running, Completed, and Failed
- 04 · Handle Temporary and Permanent Failures
- 05 · Reconcile Systems That Disagree
- 06 · Notify and Escalate to the Right Owner
- 07 · Confirm the Business Outcome
- 08 · Capstone: Follow One Record End to End
12 min · Interactive exercise
Map the Teams and Systems
Name every system and team, give each an owner, and say which system is right when they disagree.
The architectural move that makes everything else in this guide possible is small and easy to skip: keep your own copy of what the other system thinks is true.
Your interface reads local records. One client owns outbound requests to the other system. One component is the only thing permitted to change remote state. That is the whole pattern, and it does three things at once. It removes the remote system's semantics from your interface. It creates one place for retries, correlation, and audit. And it gives you something to compare against, which is what Chapter 5 needs.
Without it, every screen is a live call to somebody else's API, every failure is a blank panel, and there is no way to ask what changed since yesterday because nothing was ever recorded.
One owner per system, and one authority per fact
Every system on the map gets a named owner. The map is not a diagram of boxes and arrows, it is a list of things that can go wrong and the people who will be asked about them.
Then the harder question: for each fact the workflow depends on, which system is authoritative? Not which systems hold it, because all of them hold it. Which one is right when they disagree.
A fact with two authorities is not a fact, it is a future incident. And the answer is often counter-intuitive: the system that displays a value most prominently is frequently not the one that should own it.
Observation without mutation is a real mode
A system can appear on your map in observe-only mode: read, reported on, and never written to. That is not a lesser state or a stepping stone you are embarrassed about. It is how a system earns the right to write.
In a working sequence-orchestration setup, the audiences the system manages and the audiences it merely observes appear on the same board, side by side. Hand-built lists are visible, counted, and reported on, with mutation switched off. That visibility is worth having on its own, and it is also what lets you find out what your writes would have done before they do it.
GTM Lab
Saved locallyCross-System Operating Plan · 0 of 8 sections started
Saved locally to your browser.
Draw the map
Four systems carry this workflow. Give each an owner, then answer the harder question: which one is right when they disagree?
Sample situation
A dashboard with no memory
FIXTURE-LIVE-API-EVERYWHERE- Every panel
- A live call to somebody else’s API
- When the provider is slow
- The page is slow
- When the provider is down
- The page is blank
- "What changed since yesterday?"
- Unanswerable, because nothing was recorded
- What is missing
- A local copy of what the other system thinks is true