Skip to main content

Characteristics Selection: Top-3 Drivers

What This Concept Is​

An architecture characteristic (also called a quality attribute or a non-functional requirement) is a property of the system that shapes the design, not the features. Examples: availability, scalability, performance, operability, observability, security, evolvability, testability, cost, time-to-first-deploy. Characteristics are invisible to the user as nouns but visible in what the system is able (or unable) to do under stress.

Mark Richards and Neal Ford argue that architectures are designed against characteristics, not against features. Your capstone cannot maximize every characteristic; the honest architect picks the top three and accepts trade-offs everywhere else. The job of this concept is: produce a ranked list of characteristics with the top 3 marked as drivers, the middle marked "supported," and the rest marked "non-goal." That file -- typically library/raw/architecture/characteristics.md -- is the lens for every downstream decision in Clusters 3 and 4.

The top-3 list is short for a reason: decisions are only possible under a budget. Four drivers reduce to no drivers; three forces a real rank order. Ford and Richards sometimes call this "explicit top-3 rule" -- the number is not magical, but the discipline of picking is.

Why It Matters Here (In the Capstone)​

If you ask "what matters most for my capstone?" and the answer is "all of it," you cannot make decisions. Every design choice in Clusters 3 and 4 -- style, stack, deployment topology, ADRs -- becomes a toss-up. With top-3 drivers in hand, every decision is evaluated against them, and ADRs write themselves.

The second reason: defending your architecture in week 6 is impossible without drivers. "Why did you pick Postgres?" has no defense if you did not say what you were optimizing for. With drivers, the defense is one sentence: "Operability and simplicity are in my top 3; Postgres is the most operable database I've shipped."

The third reason: characteristics feed directly into the fitness functions (concept 09). A characteristic that cannot be asserted automatically becomes wall-art. One fitness function per driver is a reasonable target, and it forces drivers to be specific enough to be measurable.

Concrete Example(s) -- from a real capstone​

Example A -- inventory service:

Drivers (top 3):

  1. Correctness under concurrency and offline. A lost or double-counted scan breaks the product's value; the whole point is an accurate audit log. User-observable because on-hand numbers must match real stock after an offline shift.
  2. Operability on a solo schedule. Warehouse staff use it in production from week 3; a 2am page is not an option.
  3. Offline availability of the scan path. Wi-Fi drops are routine; scanning must work. User-observable because staff don't stop scanning when the signal dies.

Supported: testability, cost (free tier only), observability (logs enough to triage).

Non-goals: multi-warehouse scale, sub-100ms API latency, formal security compliance.

Example B -- ticketing platform:

Drivers:

  1. Correctness of seat caps (strong consistency). No oversell, ever. The entire product value is that the cap holds.
  2. Time-to-event-day. The capstone is meaningless if it isn't shippable for a Saturday. Schedule is the driver most often omitted, but it is exactly what forces real design pressure.
  3. Availability during a live event window. The two-hour door-scan window cannot go down; outside it, downtime is acceptable.

Supported: operability, cost.

Non-goals: scalability beyond 1000 seats, horizontal scaling, GDPR-grade compliance, payment security (out-of-MVP).

Example C -- finance aggregator:

Drivers:

  1. Data correctness (idempotency, no silent dupes). A double-counted transaction silently destroys the point of the tool.
  2. Privacy / local-only. Personal financial data never leaves the user's machine. This is a characteristic, not a feature, because it rules out whole classes of design (no cloud sync, no managed DB).
  3. Simplicity / time-to-deploy. Solo schedule; everything that is not directly correctness or privacy is a time risk.

Supported: testability (rules engine must be fully testable), observability (a simple import log).

Non-goals: real-time bank API integration, multi-user, high availability, horizontal scaling.

Notice what each list does: three levers, each tied to a specific user-visible behavior, with non-goals written down explicitly. Writing "security is not a driver" is uncomfortable -- and exactly the discipline that makes the architecture defensible. It tells the grader you chose rather than forgot.

Common Confusion / Misconceptions​

  • "Everything is a driver." If four things are drivers, none are. The whole point is to pick.
  • "Availability is always a driver." Only if it actually shapes your design. For a solo capstone with a fixed demo window, availability during the demo might be a driver; 24/7 availability usually is not. Pretending it is leaks into the design doc as features (load balancing, multi-region) that your code will not implement.
  • "Drivers are what I like working on." Drivers come from the problem and the risks, not from your preferences. If your top risk is reconnect reliability, responsiveness is a driver even if you would rather work on UI.
  • "I can change the top 3 when convenient." You can, but treat it like a superseding ADR: declare, in writing, that the new set replaces the old, and explain why. Silently drifting drivers is how a design doc becomes self-contradictory.
  • "Schedule / time-to-deploy is not a real characteristic." It is -- at capstone scale it is almost always in the top 3. Pretending otherwise is how capstones die in week 5.

Mapping Characteristics to Decisions​

To test that your top 3 are real, trace each one to at least one concrete downstream decision they will force:

  • Operability -> deploy target, observability stack, choice of stateful vs stateless tier.
  • Simplicity -> number of services, language count, infrastructure dependencies.
  • Correctness / consistency -> datastore choice, transaction boundaries, idempotency scheme.
  • Responsiveness -> sync mechanism (WebSocket vs polling), caching strategy, DB access pattern.
  • Privacy -> where data lives, what leaves the machine, encryption primitives.
  • Security (if a driver) -> authN/authZ choice, secret management, threat model scope.
  • Cost -> provider, free-tier limits, storage class choices.

If a candidate driver cannot point to a concrete decision it will force this semester, downgrade it. Drivers are levers, not values on a poster.

How To Use It (In Your Capstone)​

  1. List every reasonable characteristic -- 10 to 15 options. Be generous in the initial list.
  2. For each, write one sentence: "if this were maximized in my capstone, the user would notice because ___."
  3. Strike out any where you cannot finish the sentence. Those are not characteristics, they are buzzwords.
  4. Of what remains, pick the three most important. Rank them. One of them should almost certainly be schedule / simplicity for a 6-week solo capstone.
  5. Mark the rest as "supported" or "non-goal." Non-goals go in writing, not in subtext.
  6. For each driver, name one downstream decision it will force this semester.
  7. For each driver, sketch the fitness function (concept 09) that will check it. A driver without a fitness function is an aspiration.
  8. Put the top 3 at the top of the design doc -- literally, before the problem statement -- as the lens every subsequent decision uses.

See also (integrative)​

This concept is the capstone-scale application of the full quality-attributes apparatus from S7 M01, feeding forward into S8 M04 scale-reliability when the driver is availability or scalability.

External references (curation-validated this session):

Check Yourself​

  1. What are your top 3 characteristics? State each in one sentence that ties it to a user-observable behavior.
  2. Name one characteristic you marked as a non-goal and explain the trade-off you accepted.
  3. For each top-3 characteristic, name one design decision it will force and one fitness function it enables.
  4. Is schedule / time-to-deploy in your top 3? If not, why not?
  5. If availability is in your top 3, what is your target SLO, and how will you measure it in CI?
  6. Which driver, if violated in week 4, would you stop everything to fix? That ranking answers the "rank order" question that "top 3" alone does not.

Mini Drill or Application (Capstone-scoped)​

  • Drill 1 (20 min). Make three columns: Drivers, Supported, Non-goals. Populate all three with characteristics; be thorough about non-goals.
  • Drill 2 (10 min). For every driver, write the design implication in one sentence. If you cannot, downgrade.
  • Drill 3 (10 min). For every driver, sketch the smallest possible fitness function. This is the handshake with concept 09.
  • Drill 4 (15 min, weekly). Re-open the file at Friday review. Did any driver get violated this week? If yes, fix the code or supersede the driver -- do not drift silently.
  • Drill 5 (kata-style, 5 min x 5). Pick five Architectural Katas at random. For each, name the top 3 in 5 minutes without consulting notes. This builds the reflex you need when a grader asks.

Source Backbone​

Capstone design applies earlier architecture and domain material. These books are the source backbone for the decisions in this module.