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. |
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.
| 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. |
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.
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.
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, 4, and 19: quality-attribute scenarios 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.
- 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.