Chapter 04 Flashcards — Architectural Characteristics Defined
flashcards fsa architectural-characteristics quality-attributes ilities
What is an architectural characteristic, and what three criteria must a concern satisfy to qualify as one?
?
An architectural characteristic (also called a software quality attribute or non-functional requirement) describes how a system performs its functions, not what functions it performs. The three criteria that must ALL be satisfied: (1) Non-domain design consideration — it describes a structural concern outside the problem domain; (2) Influences structural design — it actually constrains or guides architectural decisions; without structural consequences it is an implementation detail, not an architectural characteristic; (3) Critical or important to success — it matters enough to shape structural decisions; not every quality concern qualifies.
What is the difference between explicit and implicit architectural characteristics?
?
Explicit characteristics are directly stated in requirements documents or stakeholder conversations — the “-ilities” that clients explicitly mention (e.g., “99.9% availability,” “10,000 concurrent users”). Implicit characteristics are never stated but are still architectural requirements discoverable through domain knowledge and professional judgment (e.g., security for a banking system, reliability for a payment processor, maintainability for any long-lived system). Identifying implicit characteristics is the architect’s responsibility — clients describe business goals, not structural requirements. Failing to identify implicit characteristics because they were not stated is architectural negligence.
Why is ruthless prioritization to a small number of driving characteristics more effective than satisfying all characteristics equally?
?
Because architectural characteristics frequently trade off against each other — performance vs. security, scalability vs. consistency, availability vs. consistency. Trying to maximize all characteristics simultaneously produces an architecture that is mediocre across the board. The iso-quality trap is listing 20+ characteristics at equal priority; this is not prioritization, it is a requirements catalogue. Instead, identify the top 3-5 driving characteristics — the ones that are truly non-negotiable and that most directly shape structural decisions. These become the primary evaluation criteria for architectural style selection.
What is the Iso-quality Trap?
?
The iso-quality trap is the antipattern of listing many architectural characteristics and treating them all as equally important. It is called “iso-quality” because the architect is assigning equal weight to all characteristics, avoiding the hard work of prioritization. The result is that no characteristic actually drives the architecture — the system ends up being designed for all of them weakly rather than a few of them well. Real architectural decision-making requires identifying the small set of driving characteristics that justify structural choices, and consciously accepting trade-offs against lower-priority ones.
What is the difference between availability and continuity as architectural characteristics?
?
Availability is the proportion of time the system is operational and accessible — measured as a percentage uptime (99%, 99.9%, 99.99%). It addresses everyday operational resilience: how often is the system up? Architectural responses: redundancy, failover, health checks. Continuity is the system’s ability to recover from a catastrophic failure or disaster, measured by RTO (Recovery Time Objective — how long to recover) and RPO (Recovery Point Objective — how much data can be lost). Architectural responses: disaster recovery sites, backup strategies, geographic data replication. Availability = everyday uptime; Continuity = disaster survival.
What is the difference between scalability and elasticity?
?
Scalability is the ability to handle increasing load by adding resources — either vertically (more CPU/RAM per node) or horizontally (more nodes). It is a capacity ceiling concern. Elasticity is scalability plus automation — the ability to scale dynamically and automatically in response to changing demand, both up (burst handling) and down (cost reduction). Elasticity requires cloud-native design, auto-scaling groups, containerization, or serverless patterns. All elastic systems are scalable, but not all scalable systems are elastic — a system that requires manual intervention to scale is scalable but not elastic.
What is the difference between performance and scalability as characteristics, and why do they tension?
?
Performance measures the system’s responsiveness to individual operations — latency (response time for a single request) and throughput (requests per unit time under a given load). Scalability measures the system’s ability to maintain acceptable performance as load increases. They tension because: a single powerful database can answer queries faster (lower per-request latency) than a distributed database, but the distributed database handles more total load. Optimizing for single-request performance (caching, co-location) and optimizing for total capacity (horizontal distribution, stateless design) require different structural approaches that can conflict.
What are the key categories in the architectural characteristics taxonomy, and name two examples from each?
?
Three categories: (1) Operational — describes runtime behavior: Availability (uptime percentage), Performance (latency/throughput), Scalability (load capacity), Elasticity (dynamic scaling), Reliability (error-free operation), Recoverability (return to good state). (2) Structural — describes codebase/system organization: Maintainability (ease of modification), Extensibility (add features without modifying existing code), Configurability (reconfigure without code changes), Testability (verify in isolation), Deployability (rapid safe release). (3) Cross-cutting — applies system-wide: Security (protection against malicious attack), Legal (regulatory compliance), Privacy (hide transactions from internal employees), Accessibility (usability for people with disabilities), Archivability (data lifecycle management).
What is the tension between performance and security, and how is it resolved architecturally?
?
Every security layer adds latency: encryption/decryption takes CPU time; authentication checks require token validation; fine-grained authorization requires policy evaluation; TLS handshakes add round-trip time. High-security systems are slower. Resolution: (1) Profile to establish actual performance budget — don’t guess the cost; (2) Apply security selectively at trust boundaries rather than uniformly everywhere; (3) Use hardware acceleration for cryptography where available; (4) Cache authentication decisions at appropriate TTLs; (5) Calibrate security to actual risk profile — a public blog has different requirements than a payment processor. The trade-off must be explicit and documented, not ignored.
What is the tension between scalability and consistency, and what is the CAP theorem’s role?
?
The CAP theorem formalizes this tension: in a distributed system, under a network partition, you must choose between Consistency (all nodes return the same data) and Availability (the system responds even if some nodes cannot communicate). Horizontally scaled distributed systems typically accept eventual consistency as the price of scalability — replicas may temporarily diverge, but will converge. Systems requiring strong consistency (financial transactions, inventory management, booking systems) cannot scale horizontally as easily because coordination costs increase with node count. Architectural resolution: choose consistency model per business domain — eventual consistency where tolerable, strong consistency where non-negotiable.
How does an architect extract architectural characteristics from domain requirements? Describe the process.
?
Four steps: (1) Identify domain capabilities — understand what the system must do without yet thinking about architecture; (2) Detect characteristic signals — look for requirement patterns: scale language (“handle holiday rush”) → Scalability/Elasticity; compliance references (“HIPAA compliance”) → Legal/Security/Privacy; operational expectations (“available 24/7”) → Availability/Continuity; change flexibility (“change promotions without developers”) → Configurability; (3) Add implicit characteristics — apply domain knowledge to add characteristics the stakeholders didn’t mention but any professional would recognize as necessary (security for financial systems, reliability for data processing, maintainability for long-lived systems); (4) Prioritize — identify the top 3-5 driving characteristics that are truly non-negotiable and that most directly constrain structural decisions.
What is agility as a composite architectural characteristic, and what underlying characteristics compose it?
?
Agility is the portfolio of characteristics that together determine how quickly an organization can respond to change — it is not a single measurable characteristic but a composite. Its components: (1) Deployability — can new changes be deployed quickly and safely without downtime? (2) Testability — can changes be verified quickly and confidently through automated tests? (3) Modularity — can parts of the system change independently without cascading effects? (4) Evolvability — can the architecture itself change over time as requirements shift? A high-agility system ships bug fixes in hours, performs A/B tests on individual features, and onboards new developers quickly. Many modern architectural trends (microservices, CI/CD, feature flags, modular monolith) are fundamentally in service of agility.
What requirement patterns signal which architectural characteristics?
?
| Requirement Pattern | Implied Characteristics |
|---|---|
| ”Handle the holiday shopping rush” | Scalability, Elasticity, Performance |
| ”Customers must not see other customers’ data” | Security, Privacy |
| ”Available 24/7 globally” | Availability, Continuity |
| ”Add payment providers without full redeployment” | Extensibility, Configurability |
| ”HIPAA compliance” | Legal, Security, Privacy, Archivability |
| ”Continue operating if payment service is down” | Reliability, Recoverability, Fault Tolerance |
| ”Business team changes promotions without developers” | Configurability |
| ”Support 10 countries with different tax rules” | Localization, Configurability |
What is the Silicon Sandwiches kata characteristic extraction result, and which characteristics were chosen as driving?
?
Business context: Online ordering for a regional sandwich chain, 50 stores, thousands of customers, location-specific menus, franchise reports. Extracted characteristics (implicit + explicit): Availability (orders must work during lunch), Security (PCI-DSS for payments), Scalability (lunch-rush spikes), Configurability (per-store menus), Maintainability (small team, limited ops budget), Reliability (accurate reports). Prioritized driving characteristics: (1) Availability — downtime = lost revenue; (2) Security — PCI-DSS is non-negotiable; (3) Configurability — core product requirement; (4) Scalability — peak demand spikes; (5) Maintainability — team/budget constraint. Rejected as non-driving: Continuity (tolerable brief downtime), Localization (domestic only), Portability (no cross-platform need). These five drive toward a modular monolith rather than microservices.
Why must architects identify implicit characteristics, and what are common examples by domain?
?
Implicit characteristics are those that clients and product managers never state because they assume them as professional baseline requirements — yet they are genuine architectural constraints that must be satisfied. It is the architect’s professional responsibility to identify them. Common examples by domain: Financial systems → Security, Legal compliance, Auditability, Reliability (always, even if unstated); Healthcare systems → Security, Legal (HIPAA), Privacy, Reliability; E-commerce systems → Availability, Scalability, Security (PCI-DSS), Performance; Internal tools → Maintainability, Supportability; Public APIs → Backward compatibility, Versioning, Security. An architect who builds only what is explicitly specified and whose system fails due to missing implicit requirements has committed an architectural failure.
What does configurability mean as an architectural characteristic, and how does it differ from extensibility?
?
Configurability is the system’s ability to be reconfigured for different environments, behaviors, or use cases without code changes — the behavior changes through external configuration. Architectural patterns: externalized config (12-factor app), feature flags, environment-specific manifests, per-tenant settings. Extensibility is the system’s ability to add new functionality without modifying existing code — behavior grows through new additions, not configuration changes. Architectural patterns: plugin architectures, microkernel design, event-driven extension points, open-closed principle implementations. Configurability = vary within designed parameters. Extensibility = add new capabilities the original design did not anticipate.
What is supportability as an architectural characteristic and what architectural mechanisms deliver it?
?
Supportability is the system’s ability to be monitored, diagnosed, and debugged in production — the operational visibility of the running system. A system with high supportability lets operators know when something is wrong, why it is wrong, and how to fix it, without requiring code changes or guesswork. Architectural mechanisms: (1) Logging — structured, searchable, correlated logs at appropriate verbosity levels; (2) Distributed tracing — trace IDs that follow a request across service boundaries; (3) Metrics instrumentation — counters, histograms, gauges exposed to monitoring systems; (4) Health endpoints — standardized HTTP endpoints for liveness and readiness probes; (5) Alerting — thresholds that notify operators before users experience degradation.
How do driving architectural characteristics connect to architectural style selection?
?
The driving characteristics are the primary evaluation criteria when selecting an architectural style (covered in detail in Chapter 19). Each architectural style has a characteristic strength/weakness profile: a layered monolith has strong maintainability but weak scalability and deployability; microservices has strong scalability and deployability but weak performance and reliability (distributed system complexity); event-driven has strong scalability and extensibility but weak testability and simplicity. The architect matches the system’s top 3-5 driving characteristics against each style’s profile and selects the style that best satisfies the driving characteristics — consciously accepting the trade-offs in lower-priority characteristics.
What is the difference between reliability and availability as architectural characteristics?
?
Availability is a time-based measure: what proportion of time is the system operational? (Measured in uptime percentage.) It is primarily about being accessible — the system is either up or down. Architectural responses: redundancy, failover, geographic distribution. Reliability is a correctness measure: does the system perform its functions correctly and without failure under normal operating conditions? (Measured by Mean Time Between Failures — MTBF — or error rate.) It is about behaving correctly, not merely being accessible. Architectural responses: fault tolerance, circuit breakers, input validation, graceful degradation. A system can be highly available (rarely goes completely down) but unreliable (produces incorrect results frequently).
What antipattern occurs when architects optimize for theoretical future requirements without real business justification?
?
Over-engineering for hypothetical scale — adding characteristics (global distribution, five-nines availability, infinite horizontal scalability) for requirements that do not exist and may never exist. This antipattern is expensive because: structural characteristics have real costs — distributed consistency protocols, global CDN deployments, and elastic auto-scaling infrastructure are complex and expensive to build and operate; the added complexity slows current delivery; and the theoretical future requirements may never materialize, making the investment permanently wasted. The correct principle: calibrate characteristics to the real 12-month horizon. “We might need this someday” is not an architectural characteristic — it is speculation that must be validated against actual business planning before it justifies structural investment.
Priority: HIGH — architectural characteristics are the primary input to all architectural style selection decisions; the taxonomy and extraction process are used throughout the remainder of the book