Architecture Characteristics

The system qualities an architecture must support beyond its domain functionality, the "-ilities": performance, scalability, availability, security, deployability, testability, and so on. They are the success criteria of an architecture, separate from what the system does.

Why it Matters

An architecture is largely defined by which characteristics it prioritizes. You cannot maximize all of them at once, since many trade against each other, so naming the critical few turns "build a good system" into concrete, rankable design targets. Trying to support everything produces an architecture that serves nothing well.

Signals

• Requirements stated only as features, with no agreed qualities.
• "It must be fast, secure, cheap, and scale infinitely."
• Arguments about structure with no reference to which qualities matter most.

Benefits

Makes architecture decisions explicit and rankable, gives a shared definition of "good enough," and exposes the tradeoffs being made.

Risks

The ivory-tower trap of trying to support every characteristic; gold-plating qualities the system does not need; leaving characteristics implicit so they are discovered only when violated.

Tensions

Characteristics compete, security versus performance, consistency versus availability, simplicity versus configurability, so supporting one often costs another. The art is choosing the few that matter and accepting the rest.

Examples

Prioritizing availability and scalability for a public storefront while deprioritizing strict consistency; choosing testability and deployability for a system expected to change weekly.