Skip to main content

Explicit vs Implicit Characteristics, and the Top-Three Rule

What This Concept Is​

Architectural characteristics split into two categories:

  • Explicit characteristics. Written down somewhere - a PRD, a ticket, an SLO. Stakeholders agreed to them. They are visible.
  • Implicit characteristics. Not written down, but still required by the context. Regulated industries implicitly require auditability. Consumer products implicitly require security. A B2B platform implicitly requires availability during the customer's business hours.

Implicit characteristics are the ones that bite. They appear in post-incident reviews as "nobody said it, but of course we needed it." A good architect surfaces them before the incident.

On top of this split, Mark Richards and Neal Ford introduce the top-3 rule: do not let any system optimize for more than three characteristics. Beyond three, tradeoffs become paralyzing and the architecture optimizes for nothing in particular. Three is a forcing function. It requires the team to discard, not just accumulate.

Why It Matters Here​

"What characteristics matter?" is the most common architecture question. Teams fail at it in two symmetric ways:

  • They miss the implicit ones. Ship a system that nominally meets every explicit goal and fails its first audit, regulatory review, or security scan.
  • They refuse to rank. List 12 characteristics, declare them all "critical," and now no decision can be defended against the list.

The top-3 rule solves the second problem. The explicit/implicit distinction solves the first.

Concrete Example​

A payments platform for banks. Explicit list from the PRD:

  1. Performance
  2. Scalability
  3. Availability
  4. Usability

Obvious implicit list the architect adds:

  1. Security (payments)
  2. Auditability (banking + regulation)
  3. Data integrity / consistency (money)
  4. Regulatory compliance (jurisdiction-specific)

Every one of 5-8 is non-negotiable. None of them were in the PRD.

Apply the top-3 rule. The characteristics that will actually shape the architecture are:

  1. Data integrity / consistency. The strongest constraint. Payment systems that accept eventual consistency on balances are either wrong or very sophisticated; neither is a default.
  2. Availability. A payment system that is down during business hours costs revenue and trust.
  3. Auditability. Regulators will ask. Without it, you cannot ship.

Performance and scalability do not disappear - they are addressed by the chosen patterns - but they are not the axes the architecture is optimizing for at the top level. Usability is a product concern, handled by the client teams.

On the same platform, if the PRD had said "low-latency trading" instead of "bank teller transactions," the top 3 would include performance in place of auditability (or elevate it alongside). Same domain, different top 3.

Common Confusion / Misconception​

"If it's important, it goes on the list." Nearly everything is important. The top-3 rule is not "name the most important three"; it is "name the three the architecture must optimize for to exist as the right system at all."

"Implicit characteristics are optional." Implicit characteristics are required; they are just not currently written down. Write them down.

"The top-3 rule is a limit, not a goal." It is both. A list of 3 forces you to have an opinion. A list of 12 is a way of having no opinion.

"You pick the top 3 once and you are done." The top 3 can change as the system, the business, or the regulation changes. Revisit annually or at any major inflection (new market, new scale tier, new integration).

How To Use It​

When given a requirements document:

  1. Produce the explicit characteristic list (Concept 7's routine).
  2. Add implicit characteristics from context: domain (finance, healthcare, consumer), scale (startup vs enterprise), environment (internal vs public), regulatory posture.
  3. Merge into one candidate list. Expect 6-12 entries.
  4. Apply the top-3 rule. Pick 3. Write one sentence of justification per pick.
  5. For every characteristic not on the top-3 list, write one sentence stating the minimum acceptable bar, so nobody thinks "not in top 3" means "unimportant."

Hang the top-3 on the wall (literally or metaphorically). Every architectural decision from that point forward is argued against the top-3.

Check Yourself​

  1. For a healthcare records platform, name three likely explicit characteristics and three likely implicit characteristics.
  2. Why does the top-3 rule fail if you pick three characteristics that do not actually conflict with each other?
  3. When a stakeholder says "we need all of these," what is the useful follow-up question?

Mini Drill or Application​

Pick a system you know. Write:

  • explicit characteristic list (what is written in docs)
  • implicit characteristic list (what the context requires)
  • merged candidate list
  • top 3, with one-sentence justifications
  • minimum-bar statement for each of the remaining characteristics

Then imagine two design alternatives you face soon. For each, state which of the top 3 it optimizes for and which it spends against. If your alternatives do not exercise the top-3 list, the list is not doing its job.

Read This Only If Stuck​