Identifying and ranking architectural characteristics

Evolutionary architecture protects the important qualities of a system while it changes, using fitness functions. That only works if you know which qualities are important. This page covers that first step: identifying and ranking architectural characteristics (often called the “-ilities” or non-functional requirements).

What counts as an architectural characteristic

Richards & Ford (Fundamentals of Software Architecture) describe an architectural characteristic as something that:

1. is a non-domain design consideration: it’s about how the system works, not what it does;
2. influences the structure of the architecture: it needs special design attention;
3. is critical or important to the system’s success.

A requirement like “calculate tax for an order” is domain functionality. “Calculate it within 100 ms during peak sales” adds a characteristic (performance) that shapes the design.

Categories

Category	Concerned with	Examples
Operational	How the system behaves when running	Availability, performance, scalability, elasticity, recoverability, reliability
Structural	How the code and components are organised	Modularity, maintainability, extensibility, deployability, testability, portability
Cross-cutting	Concerns that span both	Security, auditability, privacy, legal/compliance, accessibility, usability

There’s no definitive list. ISO/IEC 25010:2023 defines a formal product quality model (nine top-level characteristics, each with subcharacteristics). It’s useful as a checklist, but teams usually work with their own vocabulary.

Composite characteristics

Some “characteristics” are really several. Agility isn’t measurable directly, but deployability, testability, and modularity are. Break composites down until each part can be measured.

Where characteristics come from

Richards & Ford describe three sources.

1. Domain concerns

Stakeholders talk in business terms, so the architect has to translate. Some typical translations:

Stakeholder concern	Likely characteristics
“We need to move faster than competitors”	Deployability, testability, modularity (agility)
“We’re expanding into the EU”	Data residency (compliance), latency, localisation
“We’re regulated and audited annually”	Auditability, security, data retention
“We’re planning acquisitions”	Interoperability, extensibility, scalability
“Time and budget are tight”	Simplicity, feasibility
“Customers abandon slow checkouts”	Performance, availability

2. Requirements (explicit characteristics)

Some characteristics are stated outright: “support 10,000 concurrent users”, “recover within 1 hour”. These are explicit characteristics. Read requirements looking for numbers, scale, deadlines, and regulations.

3. Implicit domain knowledge (implicit characteristics)

Many characteristics are never written down because stakeholders take them for granted. A payments system needs security and data integrity whether or not anyone says so; a healthcare system needs privacy; almost everything needs reasonable availability. These implicit characteristics are where an architect’s domain experience matters most.

Ranking: keep the list short

Every characteristic you support adds design effort and complexity, and many conflict with each other. Richards & Ford advise keeping the list as short as possible, and say to aim for the least worst architecture rather than one that optimises everything.

Common conflicts:

Improving…	…often costs
Security (encryption, inspection, extra hops)	Performance, simplicity
Availability (multi-region, redundancy)	Cost, consistency, simplicity
Elasticity (scale to zero, burst)	Performance consistency (cold starts), cost predictability
Evolvability (many independent quanta)	Operational cost, simplicity
Portability (avoiding cloud-specific services)	Speed of delivery, use of managed services

A practical technique, described in this summary of the method, is a worksheet:

1. List candidate characteristics from all three sources, capped at a small number (around seven).
2. Keep a separate list of implicit characteristics most systems need; promote one only if it needs special attention here.
3. Ask stakeholders to choose the top three. Those drive the architecture; the others are supported but don’t shape decisions.

Asking for a forced ranking is the useful part. It surfaces disagreements between stakeholders early, when they’re cheap to resolve.

Characteristics apply per quantum

Different architecture quanta can have different characteristics. If one part of the system needs very high availability and the rest doesn’t, that’s a reason to make it a separate quantum, rather than making the whole system meet the strictest requirement. This is one of the main reasons the choice of style matters.

From characteristic to fitness function

A characteristic isn’t protected until it’s measurable. For each driving characteristic:

1. Define it for this system. “Availability” might mean 99.9% for an internal tool and 99.99% for a payments API. Ambiguous terms cause arguments later.
2. Make it objective. Turn it into a statement with a number or a pass/fail rule.
3. Decide where it’s checked (PR, pipeline, production) and who owns it.
4. Record the decision in an ADR, including what you chose not to optimise for.

Characteristic	Vague	Objective
Performance	“Fast”	p95 latency < 300 ms at 500 requests per second
Deployability	“Easy to release”	Any service can be deployed to production in < 1 hour, without coordinating with other teams
Recoverability	“Resilient”	Restore from loss of one AZ in < 15 minutes, verified by a quarterly FIS experiment
Auditability	“Auditable”	Every production change is traceable to a commit and an approver; CloudTrail is on in every account

Running a characteristics workshop

This is a natural tool for an enterprise architect introducing evolutionary architecture:

• Invite business stakeholders and the engineering team.
• Collect concerns in business language first; translate them together.
• Fill in the worksheet, then force a top three.
• Agree what each top characteristic means in numbers.
• Leave with an ADR and a list of fitness functions to build.
• Revisit it when the business context changes: characteristics evolve too.

Worked example: an AWS platform

The scenario: a regulated organisation building a shared AWS platform (landing zone) for about 40 product teams, with an EU expansion planned.

Candidates

Source	Concern	Characteristic
Domain	“Teams wait weeks for environments”	Self-service / deployability
Domain	“We’re audited every year”	Auditability, security
Domain	“We’re expanding into the EU”	Data residency (compliance)
Domain	“Cloud costs are a surprise every month”	Cost visibility
Requirement	“Support 200 accounts within two years”	Scalability (of the platform)
Implicit	Shared networking and identity must not go down	Availability (of shared services)
Implicit	The platform will change for years	Evolvability

A reasonable top three

1. Security and auditability. Regulation makes this non-negotiable, and it’s hard to retrofit.
2. Self-service. The main reason the platform exists is to speed teams up.
3. Evolvability. The platform’s lower layers are the hardest to change, so the ability to change it safely is worth designing for.

Data residency, cost visibility, availability, and scalability are still supported, but they don’t drive the design: residency through an SCP region restriction, cost through tagging and budgets, and so on.

Turned into fitness functions (see fitness functions on AWS):

• Security/auditability: CloudTrail and Config are on in every account (Control Tower detective controls); no IAM policy grants *:* (Access Analyzer checks in PR).
• Self-service: a new account with baseline networking is provisioned in under one hour with no manual tickets (measured from Account Factory requests).
• Evolvability: 90% of workloads are on a supported version of each golden-path module; every guardrail is in source control and deployed by pipeline.
• Data residency (supporting): an SCP denies all regions outside the approved list.

Key takeaway

Identifying characteristics is where business conversations turn into architecture. The ranking matters more than the list: forcing a top three makes trade-offs explicit, and each top characteristic should end up as an ADR and at least one fitness function. For a platform, expect security, self-service, and evolvability to come up almost every time.

Sources

• Mark Richards, Neal Ford, Fundamentals of Software Architecture, chapter on identifying architectural characteristics (O’Reilly): the three sources, explicit and implicit characteristics, keeping the list short.
• Dan Lebrero, Fundamentals of Software Architecture summary: examples of translating domain concerns.
• How to identify architectural characteristics: three sources and a top-3 selection process (besthub.dev): the worksheet and top-three selection. A secondary source.
• ISO/IEC 25010:2023, Systems and software quality models: the formal product quality model.