Identifying architecture characteristics
Two systems with exactly the same features can need completely different architectures. A ticket site that sells a stadium out in ten minutes and a hospital records system might both "store data and show it on screens", but one must survive a burst of 200,000 people and the other must never leak a record or lose one for 25 years. Those qualities, not the features, decide the architecture. This module is about finding them, and about the hardest part: choosing only the few that matter most.
1. The idea
An architecture characteristic (often called a quality attribute, or an "-ility") is something the system must do well that isn't a feature. To count, it has to meet three tests:
- It isn't about the domain. "Calculate the seat price" is a feature; "answer within 200 ms at the 99th percentile" is a characteristic.
- It influences the structure. If you could meet it with ordinary good code, it's a design concern. If it needs a particular style, separate deployment or special infrastructure, it's architecture.
- It's critical to success. Every characteristic adds complexity, so only the ones the business truly depends on make the list.
Characteristics come from three places: explicit requirements ("support 60,000 buyers at once"), domain concerns said in business language ("we're planning acquisitions"), and implicit expectations that nobody says out loud because they're assumed, like security and basic availability.
The three families
| Family | Examples | Question it answers |
|---|---|---|
| Operational | Availability, performance, scalability, elasticity, reliability, recoverability, fault tolerance | How well does it run? |
| Structural | Extensibility, maintainability, configurability, portability, testability, deployability | How easy is it to change? |
| Cross-cutting | Security, privacy, accessibility, usability, legal and regulatory, archivability, auditability | What must hold everywhere? |
A standard checklist: ISO/IEC 25010:2023
When you gather candidates, it helps to run down a standard list so nothing obvious is missed. The ISO/IEC 25010 product quality model is the common one. Its 2023 edition has nine characteristics: it added safety, renamed usability to interaction capability and portability to flexibility, and added scalability, inclusivity and resistance (to attack) as sub-characteristics.
| Characteristic | Sub-characteristics |
|---|---|
| Functional suitability | Completeness, correctness, appropriateness |
| Performance efficiency | Time behaviour, resource utilisation, capacity |
| Compatibility | Co-existence, interoperability |
| Interaction capability | Learnability, operability, user error protection, user engagement, inclusivity, user assistance, self-descriptiveness, appropriateness recognisability |
| Reliability | Faultlessness, availability, fault tolerance, recoverability |
| Security | Confidentiality, integrity, non-repudiation, accountability, authenticity, resistance |
| Maintainability | Modularity, reusability, analysability, modifiability, testability |
| Flexibility | Adaptability, scalability, installability, replaceability |
| Safety | Operational constraint, risk identification, fail safe, hazard warning, safe integration |
Use it as a prompt, not a target: walk the list with stakeholders, keep the few that are critical and shape the structure, and drop the rest to "implicit".
2. How it works
Here's a real-style brief. Press Play to watch each phrase turn into a characteristic, then watch the list get cut to the three that decide the architecture.
Translating business concerns
Stakeholders rarely say "elasticity". They say things about the business, and you translate. Common translations:
| They say | Usually means |
|---|---|
| "We're planning mergers and acquisitions" | Interoperability, extensibility, scalability |
| "We need to get to market fast" | Agility, testability, deployability (and simplicity) |
| "Customers must love using it" | Performance, availability, usability |
| "We must beat competitors to new features" | Agility, testability, deployability, extensibility |
| "The budget and deadline are fixed" | Feasibility, simplicity |
| "We're in a regulated industry" | Security, auditability, archivability, privacy |
Some characteristics are composites: "agility" isn't measurable on its own, so break it into testability, deployability and modularity, which are. And some are easily overlooked: feasibility (can we build it in the time, with these people?), simplicity, and data integrity often matter more than the fashionable ones.
3. Try it yourself
The characteristics worksheet
Pick a scenario and read its brief. Tap a characteristic once to make it a candidate (gold), twice to put it in your top three (★), three times to clear. Then check your choices against an architect's reasoning.
4. Trade-offs
More characteristics vs a simpler system
Every characteristic you support adds structure, infrastructure or process. A system designed to be maximally everything ends up complex and good at nothing. Aim for the least worst architecture, not the best one.
Explicit vs implicit
Implicit characteristics (security, basic availability) still have to be met, but they rarely drive the structure. Promote one to the top three only when the brief makes it unusually demanding.
Characteristics fight each other
Security slows performance; elasticity complicates data integrity; extensibility adds indirection that hurts simplicity. Name the conflicts when you choose, so nobody is surprised later.
Whole system vs per part
Characteristics rarely apply to the whole system equally. If the seat-sale part needs elasticity and the venue-admin part doesn't, they may belong in different deployable units (Module 09).
5. In real projects
Run it as a workshop, not a questionnaire. Asking stakeholders "which of these 30 qualities do you need?" gets "all of them". Instead, gather candidates from the requirements and business goals, then ask them to rank: "if we can only guarantee three, which three?"
Question the requirements. "Real-time" may mean "within a minute". "Global" may mean "two countries this year". Ask what happens to the business if the target is missed: the answer tells you whether it's critical or just nice. Watch for limiting assumptions too: a team that assumes "it has to be one database" or "it has to be synchronous" never considers the options that would meet a characteristic cheaply.
Keep the list visible. Write the top three at the top of the design document and every decision record, so each decision can be checked against them.
Say it in the interview
- "What's an architecture characteristic?" A quality the system needs that isn't a feature, that shapes the structure, and that the business depends on. Scalability, elasticity, availability and testability are common ones.
- "How do you find them?" From explicit requirements, from business concerns that I translate, and from implicit expectations like security. Then I narrow them to the top three that will drive the design.
- "Why only three?" Every characteristic adds complexity and they conflict with each other. Choosing three makes the trade-offs explicit and keeps the architecture as simple as the problem allows.
- Listing every -ility as "important".
- Jumping to "microservices on Kubernetes" before naming a single characteristic.
- Treating scalability and elasticity as the same thing.
6. Remember it
How this hook works: what "not a feature, shapes the structure, can't live without it" means
What the slogan means, phrase by phrase
- "Not a feature"
- It's about how well, not what: no business rule in it.
- "shapes the structure"
- It needs a style, a deployment boundary or infrastructure, not just good code.
- "can't live without it"
- Missing it would hurt the business badly enough to justify the complexity.
Why this picture fits: the three tests are a filter. Most candidates fail at least one, and what's left is short enough to design for.
The story → the concept
| Buying a vehicle | The architecture |
|---|---|
| "It carries people" | A feature (every option has it) |
| Seats, speed, terrain, running cost | Characteristics |
| Can't be fast, huge, rugged and cheap | Characteristics conflict |
| Pick three for your trips | The top three |
The trap it saves you from
The "generic architecture": built to be everything, expensive to build, and good at nothing in particular.
7. Common mistakes
8. Design exercise (30 minutes)
- Mine a brief (10 min). Take the requirements for a system you know. Underline every phrase that implies a characteristic and name it.
- Translate the business (10 min). Write down two business goals of that product and translate each into characteristics with the table above.
- Cut to three (10 min). From all candidates, choose the top three. For each one you drop, write one sentence on why the business can live with less of it.
9. Self-check quiz
"Code must follow our naming conventions." Why isn't this an architecture characteristic?
How should you use the ISO/IEC 25010 list of quality characteristics?
"Most tickets sell in the first ten minutes." Which characteristic does that imply?
"The budget and launch date are fixed." What does that translate to?
The business wants "agility". What do you do with it?
Why limit the list to about three?
10. Go deeper
| Resource | Time | Why |
|---|---|---|
| Fundamentals of Software Architecture, 2nd edition (Richards and Ford) | book | Chapters 4–5 define and identify architecture characteristics. |
| ISO/IEC 25010:2023 explained (arc42 quality model) | 20 min | The nine characteristics and their sub-characteristics, with definitions and examples. |
| Architectural Katas (Neal Ford) | practice | Short briefs to practise finding characteristics on. |