Delivering & Operating: Conway's Law, Migration Steps & Built-Is-Not-Ready · the finale
You've named a constraint, chosen a representation, placed every operation on the consistency spectrum, and bounded blast radius. The system still has to be built, shipped, and run — inside an organisation that doesn't care about your architecture. This finale asks you to deliver one, and then to name the single instinct that has run through the whole course. The grade is in the reasoning — in a delivery sized to bound drift and a readiness made of evidence, not in a flawless launch.
Time: ~60–75 min · Due: before the wrap session · Submit: post your write-up in the cohort channel.
(a) Capstone — run the full method. Take one system you own and run all five modules end-to-end, in a ~350–450 word write-up: name the binding constraint (M1); choose the representation that makes the hot operations cheap and name what you made expensive (M2); place core operations on the consistency spectrum at their weakest tolerable guarantee (M3); choose a partition key that bounds load and blast radius and decide the degradation in advance (M4); then engineer delivery and org — migration step size, launch-readiness evidence, and the authority you don't control (M5). Name every cost.
(b) Delivery audit. Take one system mid-migration or pre-launch and make the five delivery moves below. Place it on the migration spectrum (big-bang ↔ incremental, by step size and drift) and the launch-readiness spectrum (looks-done ↔ provably-ready), then design the programme to bound drift and convert doneness into evidence — naming the missing evidence and the steps that are too big. ~300–400 words.
⚠️ Two systems are off-limits as your submission: the order-management migration audited below (it's the worked demo), and the payroll cutover we audited together in class. Pick something else.
- A system whose architecture and org were mismatched — Conway's Law pulling against the design. What gave: the architecture, or the org chart?
- A launch that looked done but wasn't — it compiled, it demoed, it collapsed. What evidence was missing that would have caught it before exposure?
- A gap between technical and social authority you've seen — where the design put the centre, and where people actually placed their trust.
- The synthesis. Looking back across all five modules, what single instinct shows up in every one? Point to where you saw it in each — your own homework counts.
Reply to one classmate's audit. Find a migration step that's too big (drift will outrun it), a launch resting on belief not evidence, or an architecture/org mismatch — and propose the fix.
Everything below is just these, applied to one delivery. Keep them in front of you:
- Org mirrors architecture (Conway's Law). A system's structure comes to match the communication structure of the org that builds it. So shape the teams to match the seams you want — and enforce the boundaries, don't merely recommend them.
- Built is not ready. Readiness is evidence produced before exposure — load tests, observability, staged rollout — not a feeling. "It compiles" is not "it ships."
- Size migration steps to bound drift. Prefer incremental over big-bang. Each step small enough that the divergence between old and new can't outrun your ability to reconcile it.
- Leverage comes with obligation; technical authority is not social authority. Becoming the source of truth is a standing duty you can't put down — and where you put the centre is not where people place trust. Name the gap.
- Architecture proposes, society disposes — so contain the cutover. Keep a fallback that doesn't depend on the new system. The irreversible switch gets a non-new-system backstop; you reconcile your way across, you don't leap.
Let's run the audit on something that is not your assignment: a retailer replacing a legacy order-management system (OMS) — the aging platform that tracks every order, reservation, and stock movement across a dozen warehouses — with a new one. Watch the moves, then make them on your own system.
1 · Org mirrors architecture (Conway). The legacy OMS is one monolith owned by one big team, and — predictably — the new design keeps drifting back into a monolith, because the org is shaped like one. The move: before cutting code, shape the teams to match the seams you want — a warehouse-fulfilment team, an inventory team, an orders team, each owning a service across a real boundary. And enforce those boundaries (separate deploys, owned interfaces), because a boundary that's only recommended gets erased by the next deadline. Change the org and the architecture follows; leave the org and the architecture reverts.
2 · Built is not ready. The new OMS compiles, demos cleanly, and looks done. That is not readiness. Readiness is evidence produced before exposure: a load test at peak-season volume, observability on every order path before real orders flow, and a staged rollout. The discipline is to produce that evidence while the system is still behind a gate — not to let real customers run the load test for you on launch day.
3 · Size the migration steps to bound drift. Big-bang cutover — flip all twelve warehouses one night — is the tempting, catastrophic option: maximum drift, no way back. Instead, strangler-fig it: migrate one low-volume warehouse first, run it on the new OMS while the other eleven stay on the old, reconcile nightly, then expand one warehouse at a time. Each step is small enough that any divergence between old and new is caught and reconciled before it compounds. Step size is the drift control.
4 · Leverage, obligation & the authority gap. The new OMS becoming the system of record buys leverage — but with it a standing obligation: every downstream report, finance feed, and warehouse screen now depends on it, and you can't put that duty down. And the deeper trap: technically the new OMS is the source of truth, but socially the warehouse leads still trust their old spreadsheets and the legacy reports. Where the architecture put the centre is not where people placed it. Name that gap and close it deliberately — migrate the trust, not just the data — or the rollout dies of quiet non-adoption while every dashboard says green.
5 · Contain the cutover (architecture proposes, society disposes). The consequential, hard-to-reverse act is the cutover itself. So keep a fallback that doesn't depend on the new system: run the legacy OMS in parallel (read-only shadow), reconcile the two, and keep the ability to route a warehouse back to the old system if the new one is wrong or down. The irreversible leap is replaced by a reversible, reconciled crossing — and the security of order-taking never rests solely on the component still proving itself.
Notice what just happened: I shaped the org to the seams and enforced them, refused to call compiled "ready" and demanded evidence before exposure, sized migration steps to bound drift, named the technical-vs-social authority gap, and kept a non-new-system fallback on the irreversible cutover. That's the whole of Part A (option b). Your job is to make those five moves on your system — or, for option (a), to fold this in as the fifth move after running Modules 1–4.
Three things to look for: an org reshaped to mirror the architecture (and boundaries enforced), a launch gate that converts belief into evidence before exposure, and an incremental migration with a reconciled fallback — across which the through-line of the whole course runs. Your audit places your system on the migration and launch-readiness spectrums and names the authority you don't control.
flowchart TD
ORG["Org reshaped to the seams<br/>Conway · boundaries ENFORCED"]
GATE["Launch gate<br/>load test · observability · staged rollout<br/>belief --> EVIDENCE before exposure"]
OLD([Legacy OMS<br/>parallel · reconciled fallback])
NEW([New OMS<br/>one warehouse at a time])
TRUST{{"Authority gap<br/>technical source of truth =/= where trust sits<br/>migrate the trust, not just the data"}}
LIVE([Cutover · consequential · reversible])
ORG --> GATE
GATE --> NEW
OLD -. reconcile + fallback .-> NEW
NEW --> TRUST
TRUST ==> LIVE
style GATE stroke:#F5A623,stroke-width:2px
style TRUST stroke:#C97E12,stroke-width:1.5px
style OLD stroke:#6FCF97,stroke-width:1.5px
Copy this into your doc and replace each blank. Keep it tight — most of the marks are in points 2, 3, and 4. (For option (a) capstone, prepend the Module 1–4 moves and treat this as your Module 5 step.)
SYSTEM (one line): _______________________________________
1. ORG MIRRORS ARCHITECTURE (Conway)
Seams I want vs the org shape today: _______________
How I ENFORCE the boundaries (not recommend): ______
2. BUILT IS NOT READY
Evidence required before exposure: _________________
What's still belief, not evidence: _________________
3. MIGRATION STEP SIZE (bound drift)
Position: big-bang <--------------> incremental
Smallest first step + how I reconcile drift: _______
4. AUTHORITY GAP
Technical source of truth: _________________________
Where people actually place trust: _________________
How I migrate the trust, not just the data: ________
5. CONTAIN THE CUTOVER
Irreversible act: __________________________________
Fallback that does NOT depend on the new system: ___
If you want a diagram, copy the Mermaid block above and relabel it for your system — it renders as a flowchart in your Gist.
Part B — starter prompts (answer in your own words; don't just restate these):
- Find the place where the org chart and the architecture disagreed. One of them won and reshaped the other — say which, and what it cost. That's Conway's Law doing its work whether you planned for it or not.
- Recall a launch that looked done — it compiled, it demoed, the room nodded. Then name the one piece of evidence (a load test, a dashboard, a staged rollout) that, had it existed before exposure, would have turned the surprise into a known.
- Separate where the design put the centre from where people put their trust. Name a system where those diverged — and what it took (or would have taken) to move the trust, not just the data.
- Re-read your five take-homes. In each, what did you do when the system faced a choice between competing goods — speed vs truth, cheap-here vs expensive-there, contained vs convenient? The same instinct is in all five. Name it, and point to it in each.
- Designing the system but not the org. Conway's Law isn't optional. If you don't shape the teams to the seams, the org will reshape the architecture back — name the team boundaries as deliberately as the service boundaries.
- Calling "it compiles" ready. Demos and green builds are belief. Readiness is evidence produced before exposure — if your users are the load test, you skipped the gate.
- A big-bang cutover dressed up as confidence. The step that's too big is the one whose drift you can't reconcile. Size to bound drift; reconcile your way across.
- Assuming the architecture controls where trust goes. It doesn't. Decentralise the tech and a social centre reappears; declare the new system canonical and people keep their spreadsheets. Name the gap and migrate the trust.
- An irreversible cutover with no fallback. If routing back to the old system isn't possible, you haven't contained anything — keep the non-new-system backstop until the evidence is in.
- Shapes the org to the architecture — Conway's Law used on purpose, boundaries enforced not recommended.
- Converts doneness into evidence before exposure — readiness is load tests, observability, staged rollout, not a feeling.
- Sizes migration to bound drift — incremental steps with reconciliation and a reversible fallback.
- Names the authority it doesn't control — the gap between technical and social centre, and a plan to migrate the trust.
- Part B names the through-line: deliberate, constraint-driven choice among competing goods, with every cost named.
That's the course. Five problems, one instinct — you named a constraint, chose what must be cheap, placed each operation at its weakest tolerable guarantee, bounded the blast radius, and delivered it into a world that doesn't care about the design. Bring the system you'd stake your name on the day you ship it.
The whole course in one line: there is no best architecture — only the deliberate, constraint-driven choice of where to sit on each spectrum between competing goods, with every guarantee above the weakest one your problem can tolerate paid for on purpose. Architecture proposes; society disposes; and the engineer's whole discipline is to choose deliberately and know the cost.