Requirements tell you what a system must do. Architecture characteristics tell you how well it must do it, and under what conditions — the -ilities like scalability, availability, and testability.

These are the true shapers of structure. Two systems with identical features but different characteristics (one needing five-nines availability, one needing none) will have radically different architectures. Miss a driving characteristic and the structure is wrong no matter how clean the code.

Richards and Ford give three criteria for something to qualify as an architecture characteristic: it specifies a non-domain consideration, it influences structure, and it is critical or important to success.

They group characteristics into three families. Operational characteristics concern runtime behaviour: availability, performance, scalability, elasticity, recoverability. Structural characteristics concern code quality and internal shape: modularity, maintainability, testability, configurability. Cross-cutting characteristics fit neither box cleanly: security, accessibility, privacy, authentication.

Characteristics can be explicit (stated in requirements) or implicit (never written down but essential — availability is rarely requested yet almost always required). And they compose: 'agility' is really a composite of testability, deployability, and modularity.

Stakeholders for a trading platform ask for 'fast, reliable, secure, scalable, maintainable, elastic' — everything.

The architect's job is not to deliver all of them maximally. Characteristics interact and compete: pushing elasticity (space-based patterns, in-memory grids) can hurt maintainability; hardening security can hurt performance. Optimizing for every characteristic yields a design that is mediocre at all of them and monstrously complex.

So the architect limits the driving characteristics — ideally to a handful, often no more than seven. Here they might land on performance, scalability, and elasticity as the true drivers (it is a trading platform), treating the rest as important but secondary. Fewer drivers, simpler and more coherent architecture.

Characteristics are the criteria against which every pattern (FND-04) is judged: microservices buy scalability and deployability at the cost of overall performance and simplicity; layered buys simplicity at the cost of scalability.

They are also the output of architectural thinking (FND-02): the architect translates business drivers into a small set of driving characteristics, then chooses structure to satisfy them. Getting the few right characteristics matters more than covering many.