⌘ The Architecture Reference

Fnd characteristics · Foundations · Intermediate

Identifying Architecture Characteristics

How architects uncover the driving -ilities from domain concerns, explicit requirements, and implicit domain knowledge — without over-specifying.

Fnd characteristics Intermediate ⏱ 4 min read Complete

🩺 Analogy

A good doctor doesn’t just treat the symptom you describe — they ask about your history and read between the lines to find the real problem. Identifying characteristics is the same diagnostic skill: stakeholders hand you symptoms (“make it reliable,” “millions of users”), and the architect translates them into measurable engineering criteria.

Three sources

Characteristics come from three places:

graph TD
S1["Domain concerns<br/>(business goals)"] --> C["Driving<br/>characteristics"]
S2["Explicit requirements<br/>(stated numbers)"] --> C
S3["Implicit / holistic<br/>domain knowledge"] --> C
C --> T["Stakeholders pick<br/>top three"]
  1. Domain concerns — translate business goals into “-ilities.” Mergers and acquisitions imply interoperability and extensibility; time-to-market implies agility, testability, and deployability; competitive advantage implies scalability and availability. Note that time to market = agility + testability + deployability — don’t fixate on one ingredient.
  2. Explicit requirements — stated user counts and scale numbers (“millions of users” decodes to scalability).
  3. Implicit / holistic domain knowledge — what the requirements don’t say. 1,000 students won’t register evenly across 10 hours; they’ll swarm the first and last 10 minutes, so design for the elastic burst.

Decode business language into engineering terms

Architects and stakeholders speak different languages. A small translation table goes a long way: “I needed it yesterday” → time to market (agility); “lightning fast” → performance; “zero downtime” → availability. The architect’s job is translation — converting business speak into identifiable and measurable characteristics.

A subtle but critical distinction: scalability (many concurrent users) versus elasticity (handling sudden bursts). A hotel-booking system is scalable but not elastic; a concert-ticket or mealtime-rush system needs elasticity.

graph TD
subgraph Scalability["Scalability — steady growth"]
  L1["Load rises gradually"] --> S1["Add capacity over weeks"]
end
subgraph Elasticity["Elasticity — sudden burst"]
  L2["Ticket drop: 0 to 50k in seconds"] --> S2["Auto-scale in seconds, then shrink"]
end

Pick a top three, don’t rank everything

The top-three technique

Don’t try to prioritise the full list — that’s a fool’s errand stakeholders will never agree on. Instead, have them choose the top three characteristics, in any order. This builds consensus and fuels the trade-off conversation, while keeping the list short.

A useful inverse exercise: ask which characteristic you could cull. The answer is usually an explicit one (implicit characteristics tend to support general success), which sharpens the team’s understanding of what truly drives the design.

The litmus test: domain or characteristic?

When a candidate quality appears, ask: does understanding it require domain knowledge? If yes, it’s a domain requirement. If it’s an abstract concern like elasticity or auditability that applies regardless of the business, it’s an architecture characteristic. For ambiguous cases (a “reputation index” → auditability?), confirm with a subject-matter expert.

⚠️ Over-specifying is as harmful as under-specifying

“There are no wrong answers in architecture, only expensive ones.” The Generic Architecture anti-pattern tries to support everything and collapses; the Ivory Tower Architect decides in isolation. Collaborate with developers, product managers, ops, and domain analysts — never decide alone.

Worked example: Silicon Sandwiches

A franchised sandwich chain wants online ordering for millions of users. The architect decodes: “millions” → scalability; mealtime bursts → elasticity (implicit); per-location promotions and directions → customizability; overseas expansion → internationalization (mostly design); franchising → cost/feasibility constraints. Implicit characteristics surfaced: availability, reliability, and security (third-party payment needs only standard hygiene).

💡 Key insight

Keep the list short and collaborate. The fewer characteristics you commit to, the simpler and cheaper the architecture — and the easier it is to evolve when unknown unknowns surface.

See also

When to use it — and when not

✅ Reach for it when

  • At the start of a project, when turning vague business goals into engineering criteria
  • When you need consensus on which qualities matter most without ranking a long list
  • When distinguishing a domain requirement from a true architecture characteristic

⛔ Think twice when

  • When you would over-specify by trying to support everything (the Vasa)
  • When you try to rank a full list — pick a top three instead
fnd-characteristicsArchitecture Characteristics (the -ilities)

What an architecture characteristic is, the three-part test that qualifies one, and the categories of -ilities a system must support.

fnd-characteristicsMeasuring and Governing Characteristics

How to turn vague -ilities into objective measures, and how to govern them over time with fitness functions so the architecture doesn't decay.

fnd-componentsIdentifying Component Boundaries

An iterative process for discovering components, the entity trap to avoid, and how the architecture quantum decides monolith vs distributed.

Check your understanding

Score: 0 / 4

1. What are the three sources for deriving characteristics?

Characteristics come from translating domain concerns, reading explicit requirements, and applying implicit/holistic domain knowledge.

2. Why have stakeholders pick the top three characteristics rather than rank the whole list?

Picking the top three (in any order) builds consensus and fuels trade-off discussion without an impossible ranking exercise.

3. What is the difference between scalability and elasticity?

A hotel-booking system is scalable but not elastic; a concert-ticket system needs elasticity for the burst when tickets drop.

4. A characteristic that requires deep domain knowledge to understand is probably…

The litmus test: if it needs domain knowledge it is domain; an abstract concern like elasticity is a characteristic.

Comments

Sign in with GitHub to join the discussion.