Chapter 4: Architectural Characteristics Defined
fsa architectural-characteristics quality-attributes ilities fitness-functions
Status: Notes complete
Overview
Chapter 4 defines and systematizes one of the most important concepts in the book: architectural characteristics — the non-functional requirements (the “-ilities”) that architecture must satisfy. While most software documentation focuses on functional requirements (what the system does), architectural characteristics define the quality constraints within which the functionality must operate. This chapter covers: (1) the precise definition of architectural characteristics and the three criteria a concern must meet to qualify; (2) a comprehensive taxonomy of characteristics organized by category; (3) the distinction between explicit and implicit characteristics; (4) the concept of composite characteristics — trade-off groups that architects use to reason about combinations; (5) how to extract architectural characteristics from domain requirements; and (6) the critical principle that identifying and prioritizing a small number of driving characteristics is more effective than attempting to satisfy all characteristics equally. The chapter’s core argument: architecture is not primarily about structural patterns — it is about identifying which qualities matter most and making structural choices that optimize for them.
What Are Architectural Characteristics?
The authors define architectural characteristics (also called software quality attributes or non-functional requirements) as the aspects of a system that describe how the system performs its functions, not what functions it performs.
The three criteria that must ALL be satisfied for a concern to qualify as an architectural characteristic:
Criterion 1: Specifies a Non-Domain Design Consideration
The characteristic must describe a structural concern that is not part of the problem domain. “Calculate interest on savings accounts” is a domain requirement — it describes what the system does. “The interest calculation must complete within 200ms for 99th percentile requests” is an architectural characteristic — it describes how well the system must perform a domain function.
Criterion 2: Influences Some Structural Aspect of the Design
The characteristic must have structural consequences. It must actually constrain or guide architectural decisions. A characteristic that can be met regardless of architecture is not an architectural characteristic — it is an implementation detail.
Example: “The system must use UTF-8 encoding” is an implementation detail. “The system must support 50,000 concurrent users” is an architectural characteristic because satisfying it requires specific structural choices (horizontal scaling, load balancing, stateless services, etc.).
Criterion 3: Is Critical or Important to Application Success
Not every quality concern is an architectural characteristic. The characteristic must matter enough to shape structural decisions. The authors emphasize the iso-quality trap: listing 30 architectural characteristics and treating them all as equal priority is worse than identifying 5 that truly drive architecture. In practice, characteristics in tension with each other (e.g., performance vs. security, scalability vs. consistency) mean that trying to maximize all of them produces an architecture that is mediocre across the board.
Explicit vs. Implicit Characteristics
Explicit Characteristics
Explicit characteristics are directly stated in requirements documents, RFPs, or stakeholder conversations. They are the “-ilities” that clients or product managers explicitly mention:
- “The system must be available 99.9% of the time”
- “The system must scale to support 10,000 concurrent users”
- “All payment data must be encrypted at rest and in transit”
- “The system must be deployable without downtime”
Explicit characteristics are the starting point, but they are never sufficient. Most business stakeholders do not know how to express architectural characteristics — they describe business outcomes, not structural requirements.
Implicit Characteristics
Implicit characteristics are never stated in requirements documents but are still architectural requirements that the system must satisfy. They are discovered through domain knowledge, industry standards, and common sense.
The authors give a critical example: if a client asks you to build an online banking system and never mentions security, does that mean security is not an architectural characteristic? No — security is an implicit characteristic that any reasonable banking system must have. Failing to identify it because it wasn’t stated is an architectural failure.
Common implicit characteristics:
- Availability — most user-facing systems must be available during business hours without explicit SLA statements
- Reliability — most systems that process data must not silently lose or corrupt that data
- Security — any system handling personally identifiable information or financial data has implicit security requirements
- Maintainability — systems the organization intends to operate for years have implicit maintainability requirements, even if “maintainability” never appears in the requirements
The Architect’s Responsibility
The authors make clear: identifying implicit characteristics is the architect’s responsibility, not the client’s. Clients and product managers describe business goals. Architects must translate those goals into structural constraints, including the unstated ones that any reasonable professional would recognize as necessary. An architect who builds only what is explicitly specified, and whose system fails because of missing implicit requirements, has failed architecturally.
Taxonomy of Architectural Characteristics
The authors organize architectural characteristics into three broad categories. This taxonomy is not exhaustive — new characteristics emerge as technology and industry evolve — but it covers the most common and architecturally significant ones.
Operational Characteristics
Operational characteristics describe how the system behaves at runtime — its performance, availability, and operational behavior under real conditions.
Availability
The proportion of time the system is operational and accessible. Measured as a percentage uptime over a defined period.
- 99% (two nines): ~87.6 hours downtime/year
- 99.9% (three nines): ~8.76 hours downtime/year
- 99.99% (four nines): ~52 minutes downtime/year
- 99.999% (five nines): ~5.26 minutes downtime/year
Architectural implications: redundancy, failover mechanisms, health checks, graceful degradation, geographic distribution.
Continuity
The system’s ability to recover from a catastrophic failure or disaster. Measured by Recovery Time Objective (RTO — how long to recover) and Recovery Point Objective (RPO — how much data can be lost).
Architectural implications: backup strategies, disaster recovery sites, data replication, runbooks.
Performance
The system’s response to operations, typically measured as latency (response time for a single request) and throughput (requests handled per unit time).
Architectural implications: caching strategies, database indexing, asynchronous processing, CDN usage, database connection pooling.
Recoverability
The system’s ability to recover to a known good state after a failure. Related to but distinct from continuity — continuity is about disaster recovery; recoverability is about everyday failure recovery.
Architectural implications: transaction management, rollback capabilities, idempotent operations, compensating transactions.
Reliability / Safety
The system’s ability to perform its required functions under stated conditions for a specified period without failure. For safety-critical systems, also encompasses freedom from dangerous failures.
Architectural implications: fault tolerance, circuit breakers, fallback mechanisms, chaos engineering.
Robustness
The system’s ability to handle error conditions, invalid inputs, and unexpected situations gracefully — without crashing or producing incorrect results.
Architectural implications: input validation, defensive programming, graceful degradation, error handling strategies.
Scalability
The system’s ability to handle increasing load by adding resources. Two forms:
- Vertical scaling (scale up): add more resources to existing nodes (more CPU, RAM)
- Horizontal scaling (scale out): add more nodes
Architectural implications: stateless service design, database sharding, message queues, load balancing.
Elasticity
The system’s ability to scale dynamically in response to changing demand — both up (burst handling) and down (cost reduction during low demand). Elasticity is scalability + automation.
Architectural implications: cloud-native design, containerization, auto-scaling groups, serverless functions.
Structural Characteristics
Structural characteristics describe properties of the codebase and system structure — how the system is organized internally and how it can evolve.
Configurability
The system’s ability to be reconfigured for different environments or use cases without code changes.
Architectural implications: externalized configuration (12-factor app principle), feature flags, environment-specific deployment manifests.
Extensibility
The system’s ability to add new features or functionality without modifying existing code.
Architectural implications: plugin architectures, microkernel design, event-driven extension points, interfaces and abstractions.
Installability
The ease with which the system can be installed on required platforms.
Architectural implications: packaging (containers, installers), dependency management, versioning.
Leverageability / Reuse
The degree to which common components can be reused across the system or across multiple systems.
Architectural implications: shared library management, API design, component versioning.
Localization
The system’s ability to adapt to different locales — languages, date formats, currency formats, regulatory requirements.
Architectural implications: internationalization (i18n) frameworks, locale-aware data models, translation management.
Maintainability
The ease with which the system can be modified to fix defects, improve performance, or adapt to a changed environment.
Architectural implications: modularity (Chapter 3 is essentially the foundation of maintainability), test coverage, documentation, code quality metrics.
Portability
The system’s ability to run on multiple platforms or environments without modification.
Architectural implications: abstraction over platform-specific APIs, containerization, standard data formats.
Supportability
The system’s ability to be monitored, debugged, and diagnosed in production.
Architectural implications: logging, distributed tracing, metrics instrumentation, health endpoints, alerting.
Upgradeability
The system’s ability to be upgraded from one version to a newer version without downtime or data loss.
Architectural implications: database migration strategies (blue-green, expand-contract), backward compatibility, versioned APIs.
Cross-Cutting Characteristics
Cross-cutting characteristics apply across many or all parts of the system — they cannot be localized to a single component.
Accessibility
The system’s usability by people with disabilities — compliance with WCAG standards.
Architectural implications: UI component library choices, keyboard navigation support, screen reader compatibility.
Archivability
The ability to archive or delete data after a defined period — regulatory compliance for data retention.
Architectural implications: data lifecycle management, soft-delete strategies, archival storage tiers.
Authentication
The system’s ability to verify the identity of users and services.
Architectural implications: identity provider integration (OAuth, SAML), session management, credential storage.
Authorization
The system’s ability to determine what authenticated users are permitted to do.
Architectural implications: role-based access control (RBAC), attribute-based access control (ABAC), policy engines.
Legal
Compliance with applicable laws and regulations — GDPR, HIPAA, PCI-DSS, CCPA, etc.
Architectural implications: data residency requirements, right-to-erasure implementations, audit logging, encryption mandates.
Privacy
The system’s ability to hide transactions from internal employees — beyond legal compliance, operational privacy.
Architectural implications: data minimization, access controls, anonymization/pseudonymization.
Security
Protection against malicious attacks and unauthorized access at all levels.
Architectural implications: encryption at rest and in transit, input validation, secret management, vulnerability scanning, dependency auditing.
Usability / Achievability
The ease with which users can accomplish their goals using the system.
Architectural implications: API design, UI/UX patterns, response time targets that affect user perception.
Trade-offs Between Characteristics
The authors emphasize that architectural characteristics are frequently in tension with each other. A critical architectural skill is recognizing which tensions exist for a given system and making explicit trade-off decisions about them.
Common Tensions
Performance vs. Security
Every security layer (encryption, authentication checks, authorization evaluation) adds latency. High-security systems with strong encryption, multi-factor authentication, and fine-grained authorization are slower. The architect must decide how much latency the security overhead is worth.
Scalability vs. Consistency
The CAP theorem formalizes this: in a distributed system, you cannot simultaneously have perfect consistency and perfect availability under network partition. Horizontally scaled distributed systems typically accept eventual consistency as the price of scalability. Systems requiring strong consistency (financial transactions, inventory management) cannot scale as easily.
Performance vs. Scalability
A single powerful database can serve many queries faster than a distributed database (lower latency per query), but a distributed database handles more total load (higher throughput under scale). Optimizing for single-request performance and optimizing for total capacity require different architectural approaches.
Availability vs. Consistency
Systems designed for maximum availability (e.g., active-active multi-region) typically sacrifice strong consistency. Active-active databases cannot guarantee that all nodes see the same write simultaneously.
Security vs. Usability
Every security mechanism (login steps, MFA, session timeouts, CAPTCHAs) adds friction for users. High security systems are harder to use. The architect must calibrate security to the actual risk profile — a banking application has different requirements than a public blog.
Extensibility vs. Performance
Plugin architectures, event buses, and abstraction layers that enable extensibility add runtime overhead compared to direct, coupled implementations. The indirection that makes a system flexible makes it slightly slower.
Maintainability vs. Performance
The most maintainable code is often not the most performant. Caches that improve performance add state that must be managed. Inlined computations that avoid abstraction overhead reduce readability and testability.
The Trade-off Table Pattern
For significant architectural decisions, the authors recommend using a structured trade-off table that makes the tensions explicit:
Example: Choosing between SQL and NoSQL for an e-commerce catalog
Characteristic | SQL (PostgreSQL) | NoSQL (MongoDB) | Winner
─────────────────────┼─────────────────┼─────────────────┼────────
Scalability | Moderate | High | NoSQL
Consistency | Strong (ACID) | Eventual | SQL
Query flexibility | High (joins) | Limited | SQL
Schema evolution | Difficult | Easy | NoSQL
Performance at scale | Degrades | Consistent | NoSQL
Operational maturity | High | Moderate | SQL
Team expertise | High | Low | SQL
Decision: Use PostgreSQL for order management (consistency critical).
Use MongoDB for product catalog (schema flexibility + scale more important).
Extracting Characteristics from Domain Requirements
One of the most important skills Chapter 4 develops is characteristic extraction — translating business requirements into architectural characteristics. The process:
Step 1: Identify Domain Capabilities
Read the requirements document or interview stakeholders to understand what the system must do. Do not yet think about architecture — understand the business.
Step 2: Look for Characteristic Clues
Certain requirement patterns are characteristic signals:
| Requirement Pattern | Implied Characteristics |
|---|---|
| ”The system must handle the holiday shopping rush” | Scalability, Elasticity, Performance |
| ”Customers must not see other customers’ data” | Security, Privacy |
| ”The system must be available 24/7 globally” | Availability, Continuity |
| ”Adding a new payment provider must not require a full redeployment” | Extensibility, Configurability |
| ”The system must support HIPAA compliance” | Legal, Security, Privacy, Archivability |
| ”The system must continue operating if the payment service is down” | Reliability, Recoverability, Fault Tolerance |
| ”The business team must be able to change promotions without developer involvement” | Configurability |
| ”The system must support 10 countries with different tax rules” | Localization, Configurability |
Step 3: Identify Implicit Characteristics
Apply domain knowledge to identify required characteristics that stakeholders did not mention. For every type of system, certain characteristics are implicit:
- Financial systems: Security, Legal, Auditability, Reliability — always
- Healthcare systems: Security, Legal (HIPAA), Privacy, Reliability — always
- E-commerce systems: Availability, Scalability, Security (PCI-DSS), Performance — always
- Internal tools: Maintainability, Supportability — always
- Public APIs: Backward compatibility, Versioning, Security — always
Step 4: Prioritize — Identify the Driving Characteristics
This is the most important step. The authors argue strongly that architects must identify the top 3-5 driving characteristics — the ones that are truly non-negotiable and that most directly shape structural decisions.
Why not prioritize all characteristics equally? Because:
- Characteristics frequently trade off against each other — you cannot simultaneously maximize all of them
- Every additional characteristic you optimize for adds architectural complexity
- Architects who list 15 “top priority” characteristics are not prioritizing — they are avoiding hard choices
- Structural decisions must serve the driving characteristics; trying to serve all characteristics equally produces architectures that serve none of them well
The prioritized driving characteristics become the primary criteria for evaluating architectural style options (covered in Chapter 19).
Composite Characteristics: Agility
The authors introduce composite characteristics — named groups of underlying characteristics that architects commonly reason about together. The most important composite characteristic is agility.
Agility is not a single measurable characteristic — it is a portfolio of characteristics that together determine how quickly an organization can respond to change:
Agility = f(Deployability, Testability, Modularity, Evolvability)
Deployability: Can new changes be deployed quickly and safely?
Testability: Can changes be verified quickly and confidently?
Modularity: Can parts of the system change independently?
Evolvability: Can the architecture itself change over time?
A system with high agility can: ship a bug fix in hours rather than weeks; perform A/B tests on individual features; extract a component into a service when scaling needs change; onboard new developers quickly because the codebase is understandable.
Agility is particularly important in competitive markets where time-to-market and feature velocity are primary business drivers. Many modern architectural trends (microservices, CI/CD, trunk-based development, feature flags) are fundamentally in service of agility.
Other composite characteristics the authors reference:
Reliability as a composite of: Availability + Recoverability + Continuity + Robustness
Operability as a composite of: Supportability + Maintainability + Configurability + Upgradeability
ISO Standard Characteristics (Reference)
The authors reference the ISO 25010 quality model as a standard taxonomy, while noting that their own taxonomy is more architect-oriented and practice-focused. The ISO 25010 model organizes quality characteristics into:
- Functional suitability: Completeness, correctness, appropriateness
- Performance efficiency: Time behavior, resource utilization, capacity
- Compatibility: Co-existence, interoperability
- Usability: Appropriateness recognizability, learnability, operability, accessibility
- Reliability: Maturity, availability, fault tolerance, recoverability
- Security: Confidentiality, integrity, non-repudiation, accountability, authenticity
- Maintainability: Modularity, reusability, analyzability, modifiability, testability
- Portability: Adaptability, installability, replaceability
The ISO taxonomy is comprehensive but less actionable. The authors’ taxonomy is organized around architectural decision-making.
The Silicon Sandwiches Kata: Characteristic Extraction Example
The authors apply characteristic extraction to the Silicon Sandwiches kata:
Business Context: Online ordering system for a regional sandwich chain, 50 stores, thousands of customers, store managers update menus, franchise owners view reports.
Stated Requirements:
- Customers order online
- Stores receive orders
- Menus vary by location
- Reports for franchise owners
Extracting Characteristics:
| Requirement / Context | Implied Characteristic | Explicit or Implicit? |
|---|---|---|
| Online ordering | Availability (must work during lunch rush) | Implicit |
| Payment processing | Security (PCI-DSS compliance) | Implicit |
| Thousands of customers at lunch | Scalability, Performance | Implicit |
| 50 stores, location-specific menus | Configurability | Explicit |
| Franchise reporting | Reliability (reports must be accurate) | Implicit |
| Startup budget | Cost-effectiveness (limits complexity) | Implicit |
| Small team | Maintainability (team can’t manage complex infra) | Implicit |
Prioritized Driving Characteristics:
- Availability — orders must work during business hours; a downed system loses revenue
- Security — payment processing requires PCI-DSS compliance
- Configurability — per-location menus are a core product requirement
- Scalability — must handle lunch-rush demand spikes without performance degradation
- Maintainability — small team, limited operational overhead budget
Rejected as non-driving (not that they don’t matter, but they don’t drive architecture):
- Continuity: the business can survive a few hours of downtime
- Localization: domestic-only operation, single language
- Portability: no cross-platform requirement
These five driving characteristics directly inform the structural decision: a modular monolith (or simple service-based) architecture, not microservices — which would add operational complexity that neither the team size nor the budget can absorb.
Comparison Tables
Operational Characteristics Quick Reference
| Characteristic | Key Metric | Primary Architectural Response |
|---|---|---|
| Availability | Uptime % (nines) | Redundancy, failover, health checks |
| Performance | Latency (p50, p99) | Caching, async processing, indexing |
| Scalability | Requests/second at target latency | Stateless services, horizontal scaling |
| Elasticity | Scale-up/down speed | Cloud-native, auto-scaling |
| Reliability | MTBF / error rate | Circuit breakers, retries, fallbacks |
| Recoverability | RTO / RPO | Backup, transaction management |
Structural Characteristics Quick Reference
| Characteristic | What It Enables | Primary Architectural Response |
|---|---|---|
| Maintainability | Long-term evolution | Modularity, clean interfaces, test coverage |
| Extensibility | Feature addition without modification | Plugin patterns, event extension points |
| Configurability | Environment/behavior variation without deployment | Externalized config, feature flags |
| Testability | Confidence in changes | Dependency injection, component isolation |
| Deployability | Rapid, safe release | CI/CD, independent deployment units |
Common Characteristic Tensions
| Tension | Why It Exists | Architectural Resolution |
|---|---|---|
| Performance vs. Security | Security layers add latency | Profile and calibrate; apply security at trust boundaries |
| Scalability vs. Consistency | Distribution requires coordination | Choose consistency model per domain (eventual vs. strong) |
| Availability vs. Consistency | Active-active = eventual | Use CQRS, saga patterns for eventual consistency |
| Extensibility vs. Performance | Abstraction adds overhead | Apply extensibility selectively to expected change points |
| Agility vs. Performance | Optimization reduces generality | Separate hotpaths from general architecture |
Common Antipatterns
The Iso-quality Trap: Listing 20+ architectural characteristics and treating them as equally important. This is not architecture — it is a requirements catalogue. Real architectural decision-making requires ruthless prioritization to a small set of driving characteristics.
Treating Performance as the Only Characteristic: Some architects default to optimizing all decisions for performance, ignoring maintainability, security, and agility. The result is a highly performant system that is slow to change, unsafe, and expensive to operate. Performance must be calibrated to actual requirements, not maximized universally.
Ignoring Implicit Characteristics: Building a financial system without security because “the client didn’t ask for it” is professional negligence. Domain expertise is required to identify implicit characteristics — it is not the client’s responsibility to specify them.
Conflating Functional Requirements with Architectural Characteristics: “The system must calculate interest” is not an architectural characteristic. It is a functional requirement. “The interest calculation must process 10,000 accounts per hour” is an architectural characteristic. The conflation leads to architectures that satisfy business logic but lack structural quality.
Optimizing for Theoretical Future Requirements: Adding characteristics for scale, performance, or extensibility the system will never need. “We might need to support 10 million users someday” is not a reason to build a globally distributed system for a startup with 100 users. Characteristics are real constraints with real structural costs — optimize for the actual horizon.
Key Takeaways
- Architectural characteristics are non-domain, structural, and critical: All three criteria must be met. If it doesn’t constrain structure, it is not an architectural characteristic.
- Implicit characteristics are the architect’s responsibility: Clients describe business goals; architects identify the unstated structural requirements that any reasonable professional would recognize as necessary.
- The taxonomy provides vocabulary, not a checklist: The goal is not to satisfy all characteristics — it is to identify which ones drive architecture for this system.
- Prioritize ruthlessly — identify 3-5 driving characteristics: Characteristics in tension mean you cannot maximize all of them. Driving characteristics are the primary evaluation criteria for architectural style decisions.
- Extract characteristics from domain requirements systematically: Look for requirement patterns (scale language, compliance references, operational expectations) that signal architectural characteristics.
- Common tensions are predictable and must be resolved explicitly: Performance vs. security, scalability vs. consistency, availability vs. consistency — these tensions have known patterns and require explicit, documented trade-off decisions.
- Agility is a composite characteristic: Deployability, testability, modularity, and evolvability together determine organizational agility — the ability to respond to change. It is a common implicit characteristic for competitive-market systems.
- Characteristics determine architectural style: The driving characteristics for a system are the primary input to architectural style selection (Chapter 19). A system prioritizing agility + scalability points toward different styles than one prioritizing consistency + security.
- Calibrate to real requirements, not theoretical extremes: Adding five-nines availability or globally-distributed scalability without corresponding business requirements is gold-plating. Structural characteristics have real costs.
- The Silicon Sandwiches example shows the full process: Identify domain capabilities → detect characteristic signals → add implicit characteristics → prioritize driving characteristics → let driving characteristics guide structural decisions.
Related Resources
- ch02-architectural-thinking — trade-off analysis is the core skill for resolving characteristic tensions
- ch03-modularity — modularity directly enables maintainability, testability, and deployability
- ch05-identifying-architectural-characteristics — extends characteristic extraction with more domain case studies
- ch06-measuring-fitness-functions — characteristics become measurable fitness functions
- ch19-choosing-architecture-style — driving characteristics are the primary architectural style selection criteria
Last Updated: 2026-05-29