Open question: Section 9, The operating discipline: keeping the agreement: "the step most often missing is the supply…"

[anacay]

the step most often missing is the supply review

In my experience the supply review is the step most often missing between the demand review and the executive decision. Is it missing where you work? If you have one, what does supply bring to it?

Author's note 11 on Section 9, The operating discipline: keeping the agreement. Reply below; if this settles into a change to the text, an editor will carry it over with credit (see HOW_IT_GROWS.md).

[dave-dev650]

One of the greatest benefits I've seen from a supply review is insight into systemic constraints. Disk shortages, memory shortages or whatever else is suddenly hard or very expensive to source. Once you have a specific actionable gap from supply it is sometimes possible to flip the system around and engineer demand to fit what is possible. While not necessarily ideal, it may be the difference between getting a product out the door and sitting on your hands and waiting until the world changes to meet your expectations.

[anacay]

Thank you. I’ve experienced this first-hand. Here’s the proposal from this thread.

Change: in Section 9, give the supply review an explicit purpose. It turns systemic supply constraints into demand decisions while there’s still time. For each constraint, such as memory, storage or I/O throughput becoming scarce or expensive, the review records:

which asks it touches, seen across all demand at once, since no single team can see the pattern;
the latest date demand can still change, set by the affected commit points;
the reshaping options: a different machine configuration, a different site, a later or phased date, or design work to use less of the scarce part;
who decides, since reshaping is a product decision the planner frames but doesn’t make;
which changes are temporary, and the signal to revert them once supply returns to normal.

Why: a gap named before a commit point can be reshaped. Named after, it can only be bridged at a premium, or it slips. That timing can decide whether something ships or stalls.

The options pull on each other. A memory shortage can push a design toward flash. Write-heavy flash work then needs newer, more durable drives, which may only sit in certain places. Now location, latency and wear are all in play. Trades can even run backwards: I’ve seen small workloads given extra memory to cache around scarce disk throughput for a couple of quarters, a choice you’d never make in normal times.

This is where a formal capacity planning discipline earns its keep. An SRE brings depth on how systems behave. A TPM brings coordination across teams. A planner trained in the discipline adds what sits between them. They see the pattern across every ask, and time trade-offs against commit points. They frame those trade-offs in terms a team can act on: machines, sites, dates or design. And they formally track, manage and monitor every shortage workaround until it’s reversed, so a temporary fix never becomes a permanent cost. In my experience, that combination is what turns constraints into workable design challenges for teams, rather than denials. It’s a method, and also an art.

Evidence: argued (practitioner experience). The options echo the SRE chapter’s “right consumer, in the right location, at the right time.”

Two questions for anyone who runs a supply review: how far ahead do component constraints usually become visible? And who owns the reshaping decision where you work?

Open for comment until 23 November: 14 days, doubled while there’s one editor. I’ll call it then and record the decision here.