Lesson 0043 · Initiative Lead · Module 2
Find the Architecture Drivers
“Fast, scalable, secure, maintainable” is not a set of requirements. Architecture begins when a quality has a situation, a response, and a number.
Mission tie-in: every architecture is good for some conditions and poor for others. Drivers make those conditions explicit enough to design and test.
Knowledge: the few requirements that shape the system
Most requirements do not change the architecture. A new return reason may add a rule inside an existing boundary. A requirement to keep accepting requests while the carrier is unavailable changes data ownership, failure handling, and workflow shape. Architecture drivers are the small set of functional needs, quality attributes, constraints, and risks with enough force to shape the structure.
Turn vague “non-functional requirements” into quality-attribute scenarios with six parts:
- Source: who or what causes the condition?
- Stimulus: what happens?
- Environment: under which operating condition?
- Artifact: what part of the system is affected?
- Response: what must the system do?
- Measure: how will you know it did so?
| Quality | Scenario | Design pressure |
|---|---|---|
| Availability | When the carrier is unavailable for 30 minutes during peak, accept eligible requests and create 99% of labels within 15 minutes after recovery. | Persist intent; idempotent retry; visible pending state. |
| Performance | At 40 requests/second, show an eligibility decision within 800 ms at p95, excluding label creation. | Separate decision from slow vendor; measure the boundary. |
| Security | If one customer changes an order identifier, disclose no other customer's order or return data in every environment. | Object-level authorization; negative tests; audit trail. |
| Modifiability | When policy adds one eligibility rule, one engineer can release it within one day without changing carrier or UI adapters. | Cohesive policy module; stable result contract. |
| Operability | When label failures exceed 2% for five minutes, on-call can identify carrier impact and disable label attempts within ten minutes. | Vendor metric, alert, flag, runbook. |
A quality-attribute scenario works because it is a discriminator. By the time you are choosing an architecture, every candidate already satisfies the functional requirements; what separates them is behavior under conditions. An adjective cannot separate two designs—“scalable” is true of both, so it cannot inform a choice and cannot later be violated. A scenario with a stimulus, an environment, and a measure can rank the candidates before they are built and can fail after they are. That is the whole trick: you are not writing requirements, you are manufacturing the ability to be wrong.
The second effect is social. A scenario moves the argument from people to conditions. “Your design is over-engineered” and “yours won't scale” are unresolvable; “which scenario pays for this queue?” and “what happens to the 800 ms target when the carrier is slow?” resolve in minutes, because both sides can now point at the same sentence.
Scenarios stop helping in three situations. When the measure cannot be obtained before the decision must be made, a scenario is a wish—treat it as an assumption and buy evidence with a spike. When the number is invented to look rigorous, it is worse than an honest gap: an unsourced p95 will be defended by someone in six months as though it came from a customer. And when the dominant risk is problem uncertainty rather than solution uncertainty, no latency scenario helps; you cannot tune a system nobody has agreed to want.
Prioritize five to seven drivers, not fifty. Rank by business impact, uncertainty, and architectural reach. If two drivers conflict—800 ms response and a live carrier confirmation—write the trade-off rather than letting an engineer discover it mid-sprint. Here the team returns eligibility quickly and makes label creation a separately observable state.
Separate constraints from preferences. “Orders remain in the existing platform during the pilot” is a constraint. “Use Kafka because we already know it” is a proposed decision. Treating preferences as facts is how architecture becomes cargo cult.
Every selected driver needs an evidence mechanism: load test, architecture fitness function, contract test, recovery exercise, security test, cost alert, or production measure. A requirement that cannot fail a check will eventually lose to a feature that can pass a demo.
How the lead actually narrowed it
Week 4. Twenty-three “requirements” arrive in a shared document, contributed by four groups who have never had to reconcile them. The lead does not start writing scenarios. She applies one filter to each line: name two designs that would respond to this differently. Nineteen fail the filter. They are real needs—audit logging, sensible error messages, a metrics dashboard—but every plausible architecture handles them the same way, so they are backlog items, not drivers.
The alternative she rejects is a full structured architecture evaluation with all fifteen stakeholders. It would be defensible and it would cost two days plus the calendar to convene it, against a seven-person, ten-week pilot. She takes the scenario form and drops the ceremony: five scenarios, one hour, the four people who carry the consequences.
Sam, from security, wants a scenario for every category in the team's threat checklist. The lead keeps one—object-level authorization on order identifiers—and moves the rest into a review checklist attached to the design. The reason is stated out loud so it can be argued with: a driver must change the structure, and most of that checklist changes only the code. Sam's dissent is recorded; if a scenario in that list later forces a boundary, it is promoted.
The conflict that matters shows up immediately. The 800 ms eligibility target and “confirm the label with the carrier before responding” cannot both hold: the four-hour spike in lesson 0046 measured the carrier sandbox at 1.9 s p95 and 6.4 s p99. Rather than let an engineer discover this in week eight, the driver table writes the trade explicitly—eligibility answers fast, label creation becomes a separately observable state. That one sentence is why the availability scenario exists, why the ADR is decidable at all, and why the rollout in lesson 0049 has a “pending label” gate to watch.
| Vague claim | Missing decision | Make concrete |
|---|---|---|
| “Highly available” | Which operation may degrade? | Failure, duration, response, recovery target. |
| “Scalable” | Scale of what, by when? | Load shape, growth horizon, response measure. |
| “Secure” | Against which abuse? | Actor, asset, trust boundary, forbidden result. |
| “Easy to change” | Which likely change? | Change case, person, elapsed effort, blast radius. |
- Non-functional requirements are the operations team's list.
- They are the primary shapers of structure. Functional requirements mostly fit inside whatever structure you pick; qualities are what make one structure right and another expensive. Treating them as a late checklist is how a system gets built twice.
- More drivers means more rigour.
- A list of twenty unranked drivers has no priority, so in practice the engineer's own preference becomes the tie-breaker. Prioritization is the artifact; the list is just its input.
- A driver is satisfied when the design addresses it.
- It is satisfied when a check can fail. “Addressed” is a claim; a load test, fitness function, or production measure is evidence. Systems pass reviews and fail production precisely in this gap.
- Constraints are just requirements we haven't pushed back on.
- Some are negotiable and some are not; the point of labelling them is to know which. Pushing hard on a genuine constraint—“the order system stays authoritative”—burns the credibility you will need for the fake one.
When this is the wrong move
Skip formal scenarios when the initiative's dominant risk is whether anyone wants the thing: write assumptions and buy user evidence instead, because a latency target for an unvalidated product is precision in the wrong place. Skip them for genuinely short-lived work—a two-week internal migration tool does not need a modifiability scenario. And refuse to write one when the honest answer to “what is the measure?” is “nobody knows”: record the unknown, name the spike that would settle it, and leave the row empty rather than filling it with a number the team will later defend.
Skill: make the driver measurable
Which requirement can drive architecture?
Why prioritize only a few drivers?
“Use the existing order platform” is a:
Practice: write the five scenarios
For your initiative, select the five qualities with the greatest combined impact, uncertainty, and structural reach. Write source, stimulus, environment, artifact, response, and measure for each. Add one evidence mechanism and one owner. Delete every generic “scalable” or “secure” statement left over.
In the lab and the capstone. The lab's phase-4 checkpoint turns one of these scenarios into outcome telemetry and a rollout gate that fails as a test rather than as an opinion. The worked artifact is the driver table in the strong capstone packet—each row there names an evidence mechanism and an owner, and each is referenced later by an ADR or a rollout stage. Compare with the weak version, whose qualities are adjectives with no environment, no measure, and therefore nothing a design review can disagree with.
Reveal: the architecture-driver test
A driver is ready when two plausible architectures would respond differently to it, the team can explain why it matters to the outcome, and a check can prove whether the chosen design meets it. If no decision or test changes, it is context—not a driver.
- In two sentences, explain to a new lead why “name two designs that would differ” is a better filter for a driver than “is this important?”.
- Take the loudest quality claim on your current initiative. Write its six parts, then say which design decision this week it would change.
- Predict the failure: if a team ships with five adjectives instead of five scenarios, what is the first production surprise, and who will be blamed for a target nobody ever wrote down?
Your win
You can identify the few requirements that should shape a system and turn vague qualities into scenarios that guide design, tests, and operations.
Read and watch deeper
- Software Architecture in Practice, Bass, Clements & Kazman — ch. 3 and 13: the six-part quality-attribute scenario, and architecturally significant requirements.
- Documenting Software Architectures, Clements et al. — the quality-attribute scenario as a precise design input.
- The Elephant in the Architecture, Cartwright — justify cross-functional requirements with business value.
- Quality Attribute Workshops (QAW), Third Edition, Barbacci et al. — SEI technical report CMU/SEI-2003-TR-016: how to elicit and refine scenarios with stakeholders.
- Reference: Initiative Playbook · driver table, and fitness function.
Ask your agent-teacher to attack each quality statement with “under what condition, which response, and how measured?” until no adjective survives alone.