Architecture Characteristics

← experimental

Contents

Definition
Categories
Implicit vs Explicit
How Many to Support — Least Worst Architecture
Selecting Characteristics
Governance
How Different Sources Treat It
Related Concepts

Definition

Architecture characteristics (also called "-ilities" or non-functional requirements) are the structural and operational qualities a system must support beyond its domain functionality. They are the criteria by which architecture styles are selected and the targets that Fitness Functions enforce.

A quality attribute must meet three criteria to count as an architecture characteristic:

It specifies a non-domain design consideration (not a business feature).
It influences a structural design decision.
It is critical to the success of the application.

Implicit vs Explicit

Explicit characteristics are stated in requirements or by stakeholders ("the system must handle 10,000 concurrent users"). Implicit characteristics are baseline assumptions that are never stated but are still required — availability, security, and reliability often fall here. Architects must identify both.

Italy-ility — a named illustration of how unique organisational history can produce custom architecture characteristics. A client's architecture team, after a freak communication outage had severed headquarters from Italian branches years earlier, insisted at every design review: "But what if we lose Italy?" The team eventually formalised this as Italy-ility — a compound of availability, recoverability, and resilience specific to this organisation. No standard list of architecture characteristics is ever complete; real architectures accumulate domain-specific "-ilities" that only make sense in context (→ Fundamentals Of Software Architecture Ch 4).

How Many to Support — Least Worst Architecture

Architects should limit characteristics to the fewest that matter most. There are two reasons: (1) every additional characteristic adds design constraints and complexity, and (2) characteristics frequently conflict — security degrades performance (encryption adds overhead), high deployability conflicts with simplicity (pipeline infrastructure has a cost), scalability conflicts with cost.

"Never shoot for the best architecture, but rather the least worst architecture." (→ Fundamentals Of Software Architecture Ch 4)

Too many characteristics produce a generic solution optimised for everything and therefore for nothing. Richards & Ford suggest treating ~7 as an informal ceiling. This principle pairs with the First Law: since everything is a trade-off, optimising for all characteristics simultaneously means accepting the worst of all trade-offs rather than deliberately choosing which trade-offs to make.

Scalability vs elasticity are a commonly conflated pair: scalability is the ability to handle growing sustained concurrent load; elasticity is the ability to respond to sudden burst spikes. A financial reporting system needs scalability at month-end; a ticketing platform for a concert announcement needs elasticity. They are different constraints requiring different architectural approaches.

Selecting Characteristics

Vasa anti-pattern: designing an architecture that supports every possible characteristic produces a generic solution optimised for nothing. The Vasa was a 17th-century Swedish warship that sank on its maiden voyage because excessive armament made it unstable. The architectural equivalent is an over-specified system that satisfies every "-ility" in theory but performs poorly in practice. Solution: select the fewest characteristics that matter most.

Stakeholder collaboration technique: present domain stakeholders with the full list of characteristics and ask them to select the top 3 — not rank all of them. Selection forces genuine prioritisation and surfaces hidden disagreements between business and technical stakeholders. The "eliminate the least important" framing (ask what can be dropped rather than what is most important) is sometimes more productive.

Domain concern → architecture characteristic translation:

Domain concern	Architecture characteristics
Mergers/acquisitions	Interoperability, scalability, adaptability, extensibility
Time to market	Agility + testability + deployability (not just agility)
User satisfaction	Performance, availability, fault tolerance, testability, deployability, agility, security
Competitive advantage	Agility, testability, deployability, scalability, availability, fault tolerance
Time and budget	Simplicity, feasibility

A common mistranslation: "time to market" → "agility." Agility alone is insufficient; testability and deployability are equally required. An agile codebase that cannot be tested or deployed quickly does not reduce time to market.

Litmus test — architecture vs domain characteristic: does the requirement need domain knowledge to implement, or can it be discussed in the abstract regardless of application type? Elasticity is abstract — the same concern applies to banking, catalogue sites, and streaming video. A "reputation index" is not abstract — it requires a domain expert to explain. Abstract requirements → architecture characteristics. Domain-specific requirements → design decisions in the domain layer.

Extraction process:

Read domain requirements and domain context documents.
Listen for domain-concern phrases: "we're expecting rapid growth" → scalability/elasticity; "we can't afford downtime" → availability; "mergers likely" → interoperability/modularity.
Identify implicit characteristics (security, reliability, etc.).
Translate business concerns into architecture "-ilities" using the domain concern table above (time-to-market → agility + testability + deployability; cost reduction → simplicity/testability).

Governance

Once characteristics are identified, they must be measured and protected. Measurement options:

Cyclomatic complexity (structural): McCabe's CC, threshold ≤ 10 per method.
Afferent/efferent coupling (structural): fan-in/fan-out per component.
Fitness functions (automated governance): see Fitness Functions.
Process measures: cycle time, test coverage, deployment frequency.

Open question: The ISO defines formal vocabulary for quality attributes (ISO 25010). FOSA uses its own informal list. Cross-referencing these would clarify which ISO attributes map to FOSA categories and which are omitted.

How Different Sources Treat It

Source	Perspective
Fundamentals Of Software Architecture	Provides explicit taxonomy (operational/structural/cross-cutting); introduces selection and governance techniques; treats as primary input for style selection
Understanding Distributed Systems	Treats non-functional requirements implicitly through the lens of specific problems (consistency, availability, fault tolerance) rather than as a formal taxonomy

Architecture Quantum — scopes which set of characteristics applies to which part of the system
Fitness Functions — the mechanism for governing characteristics over time
Cost As Architectural Force — cost as one of the -ilities; its trade-offs against availability, performance, security
Cap Theorem — the fundamental consistency vs. availability trade-off under partitions
Consistency Models — the spectrum of consistency characteristics
Architecture Styles Comparison — characteristics ratings for all 8 styles