Programmes rarely fail at the end. They fail in week two — when the architecture was assumed rather than examined — and spend the remaining months discovering it expensively.
Three failure patterns discovery would have caught
A time-boxed architecture discovery is the correction: a short, structured examination of the systems, constraints and assumptions a programme depends on, run before the team scales up. It is the cheapest sprint a programme ever runs, on one condition — that it is contractually bound to produce decisions, not documents.
The patterns repeat across organisations:
- The load-bearing assumption. A programme plans around an integration that turns out to be batch-only, rate-limited, or contractually closed. The fact was discoverable in a day; it surfaced in month four, embedded in a design that assumed the opposite.
- The inherited constraint. The new capability must live inside an estate with fixed operational realities — a database that cannot take the load, a security boundary that forbids the planned data flow. Nobody inspected the estate; everyone designed the greenfield version.
- The undecided decision. Two teams proceeded on two different understandings of the architecture, because the decision they both depended on was never explicitly made. Both were productive; the programme was not.
Each pattern has the same shape: a question that was cheap to answer early and expensive to answer late.
When discovery is necessary — and when it's stalling
Discovery earns its time-box when at least one of these is true: the programme depends on systems nobody on the team has opened; a technical assumption, if wrong, would invalidate the plan; multiple architectural options are genuinely live and the choice shapes the budget; or the estate's constraints are undocumented and the people who know them are scarce.
Discovery is stalling — not diligence — when the questions are already answerable, when it is being used to defer a decision someone doesn't want to make, or when a second discovery is proposed because the first one's answers were unwelcome. The test: name the question this discovery answers. If nobody can, build instead.
What to inspect
A discovery is an examination with a target list, not a general survey:
- The systems the plan touches — their real interfaces, data quality, throughput and failure behaviour, from their code and operators rather than their documentation.
- The constraints that bound the design — security boundaries, compliance requirements, operational capacity, existing contracts, team skills.
- The dependencies between decisions — which choices are reversible, which lock the programme in, and which order they must be made in.
- The critical assumption — every programme has one; discovery's first job is to name it and test it, with a spike if reading is not enough.
Outputs that count
A discovery is finished when it has produced four things: architecture decision records for the choices that were made, with the reasoning that made them; target options with honest costs — usually two or three, each with its risks priced in, rather than one glossy recommendation; a risk register of what was found, ranked by what it would cost to be wrong about; and the critical assumption validated or refuted, with evidence.
What a discovery is not finished by: a description of the current state, however thorough. A current-state map is an input to the decisions, not the deliverable.
The anti-pattern: analysis as output
The failure mode of discovery is well known — weeks become months, and the result is a ninety-page document that describes everything and decides nothing. It happens for a predictable reason: describing is safe, deciding is exposed. A document can be admired; a decision can be wrong.
The correction is structural, not motivational: every discovery workstream is named after the decision it serves. "Assess the integration landscape" invites geology. "Decide whether the order flow can run through the existing ESB" invites an answer.
Time-boxing rules and an exit checklist
Rules that keep discovery honest: we typically time-box discovery to two to four weeks, extended only where the decision itself requires more evidence — never by drift; staff it senior and small; require a mid-point read-out of preliminary answers, which surfaces stalling early; and book the decision meeting for the final day before the discovery begins, so the deadline has an audience.
Exit checklist — discovery is done when: the critical assumption has evidence either way; every decision on the critical path has an ADR or an owner and a date; the options carry costs a sponsor can compare; the risk register would embarrass nobody in six months; and the team that builds next can say, in one page, what they are building first and why.
A programme that starts this way spends its first sprint building the right thing. The alternative spends month four discovering what week zero could have told it.