Definition, Criteria, and Significance of Architecture Characteristics

Key Insight

Architecture characteristics are crucial aspects of a software system, independent of its problem domain functionality. While architects may assist with business requirements, a core responsibility involves defining and analyzing these characteristics, which specify operational and design criteria for system success. These are distinct from functional requirements, which detail what an application should do. The term 'architecture characteristics' is preferred over 'nonfunctional requirements' (which is self-denigrating) or 'quality attributes' (which implies after-the-fact assessment), as it accurately describes concerns critical to the architecture and overall system success without diminishing their importance.

An architecture characteristic must meet three criteria: it specifies a non-domain design consideration, influences some structural aspect of the design, and is critical or important to application success. Non-domain considerations define how requirements are implemented and why certain choices were made, such as specifying performance levels or preventing technical debt, which often do not appear in requirements documents. For example, security becomes an architecture characteristic when it necessitates special structural design, like creating a dedicated module for in-application payment processing, contrasting with standard security hygiene for third-party payment processors.

The influence on structural design is a key differentiator, requiring specific architectural considerations to succeed. It is critical that these characteristics are important to application success; architects must choose the fewest necessary, as each adds design complexity. Architecture characteristics can be implicit (rarely in requirements but necessary, e.g., availability, reliability, and security) or explicit (found in requirements documents). These characteristics often interact, leading to trade-offs, highlighting their interconnectedness in system design and the need for architects to uncover implicit ones through domain knowledge during analysis.