Module 1: Architecture Fundamentals & Quality Attributes: Case Studies
These case studies force architectural thinking into observable claims. Do not answer with "scalable", "secure", or "clean." Translate every quality into a scenario, a tradeoff, a test, and a decision that would be expensive to reverse.
How To Use These Case Studies
- Name the quality attribute before naming a technology.
- Write a measurable scenario: source, stimulus, environment, response, and response measure.
- Identify the tradeoff with at least one competing quality.
- Produce the artifact.
- Decide what evidence would make the architecture claim believable.
Case Study 1: "Scalable" Checkout Without A Scenario
Scenario: A retail team says the new checkout system must be scalable. One proposal adds queues, one adds read replicas, one adds Kubernetes autoscaling, and one proposes a simpler monolith with a measured load target.
Source anchor: The SEI Quality Attribute Workshops material uses quality-attribute scenarios and utility trees to turn broad quality goals into concrete, prioritized architectural concerns.
Module concepts:
- quality attribute scenario
- utility tree
- architectural characteristic
- tradeoff
- measurable response
Wrong Approach
"Scalable" becomes a technology shopping list. Nobody defines the stimulus, load, environment, or response measure.
Better Approach
Write the scenario first:
Source: shoppers during seasonal sale
Stimulus: 4,000 checkout attempts per minute
Environment: one availability zone impaired
Response: accept valid checkout requests without duplicate orders
Measure: p95 under 900 ms, error rate below 0.2%, no oversell
Only after that can the team compare queues, transactional design, caching, autoscaling, and graceful degradation.
Tradeoff Table
| Choice | Gain | Cost |
|---|---|---|
| queue checkout work | absorbs bursts | delayed confirmation and retry design |
| scale synchronous checkout | immediate response | harder dependency capacity planning |
| reserve inventory first | prevents oversell | more abandoned reservations |
| degrade recommendations | protects core checkout | lower secondary feature value |
Failure Mode
The team "scales" the wrong path. Product search survives the sale while checkout fails.
Required Artifact
Create a utility tree with three checkout quality attributes and two measurable scenarios under each.
Project / Capstone Connection
Every capstone architecture section should include at least three quality scenarios, not just a list of -ilities.
Case Study 2: Diagram That Hides The Real Risk
Scenario: A design review shows three boxes: "Web App", "Service", and "Database". The diagram is technically true but useless for assessing deployment, ownership, runtime calls, or failure boundaries.
Source anchor: The C4 model defines hierarchical diagrams for system context, containers, components, and code, plus supporting dynamic and deployment diagrams.
Module concepts:
- views and viewpoints
- C4 model
- architecture communication
- diagram purpose
- stakeholder-specific evidence
Wrong Approach
One generic boxes-and-lines diagram is used for every conversation.
Better Approach
Choose the view by question:
Executive question:
system context and external dependencies
Developer question:
container/component boundaries and ownership
SRE question:
deployment view, zones, health checks, failover path
Security question:
trust boundaries and data flows
Tradeoff Table
| Diagram | Gain | Cost |
|---|---|---|
| context | shows scope | hides implementation |
| container | shows deployable/runnable units | can omit internal design |
| component | helps code ownership | can become stale quickly |
| deployment | exposes runtime risk | less useful for domain modeling |
Failure Mode
The architecture looks simple because the diagram hides queues, batch jobs, admin tools, and cross-region calls.
Required Artifact
Redraw the same system as context, container, and deployment views. Add a caption saying what each view deliberately omits.
Project / Capstone Connection
Capstone diagrams should be review artifacts, not decoration.
Case Study 3: Fitness Function For A Modifiability Claim
Scenario: A team claims the system is "easy to change" because it has clean code. Six months later, every change to pricing requires edits in checkout, billing, email templates, reporting, and support tooling.
Source anchor: Thoughtworks' Building Evolutionary Architectures material emphasizes fitness functions as executable checks for architectural characteristics.
Module concepts:
- evolutionary architecture
- fitness function
- modifiability
- architectural drift
- automated governance
Wrong Approach
"Easy to change" is judged by code style or developer confidence.
Better Approach
Turn the claim into checks:
Characteristic: pricing-rule modifiability
Fitness functions:
pricing module has no dependencies on UI or email packages
all pricing decisions pass through PricingPolicy
pricing test suite runs under 2 minutes
changed pricing rule does not require database migration
Tradeoff Table
| Choice | Gain | Cost |
|---|---|---|
| informal modularity | fast early work | drift is invisible |
| dependency checks | catches boundary breaks | requires tooling and exceptions |
| architecture tests in CI | continuous evidence | can become noisy |
| manual review only | nuanced judgment | inconsistent enforcement |
Failure Mode
The architecture characteristic exists only in a slide deck. Code keeps drifting because nothing makes the decision executable.
Required Artifact
Write three fitness functions for one quality attribute in your project. At least one must be automatable in CI.
Project / Capstone Connection
Capstone quality claims should include evidence: tests, dashboards, rules, or review gates.
Case Study 4: Availability Target That Ignores Dependencies
Scenario: A product owner asks for 99.9% availability for an API. The API depends on a payment provider, a fraud service, email, a database, and object storage. The team measures only the web server uptime.
Source anchor: The AWS Well-Architected Reliability Pillar frames reliability around workload behavior, dependency failure, recovery, and measurable objectives. See AWS Well-Architected Reliability Pillar.
Module concepts:
- availability
- dependency analysis
- graceful degradation
- error budgets
- recovery objective
Wrong Approach
Availability is reduced to "is the process running?"
Better Approach
Write an availability scenario per user outcome:
Operation: place order
Dependencies: database, payment provider, inventory, fraud
Allowed degradation: email receipt can be delayed
Not allowed: duplicate charge, silent order loss
Measure: successful order confirmation rate
Recovery: reconcile ambiguous payments within 15 minutes
Tradeoff Table
| Choice | Gain | Cost |
|---|---|---|
| hard dependency on all services | simple logic | low availability |
| degrade noncritical features | preserves core outcome | more fallback paths |
| async side effects | faster response | eventual consistency and monitoring |
| local cache | survives read dependency failures | staleness risk |
Failure Mode
The API endpoint is up while the user outcome is down.
Required Artifact
Create a dependency failure matrix for one core workflow.
Project / Capstone Connection
Capstone reliability should be measured by user outcomes, not server uptime alone.
Case Study 5: Reversibility As An Architecture Characteristic
Scenario: A team wants to adopt a proprietary managed workflow engine. It could accelerate delivery, but the workflows will become hard to migrate once business logic is encoded in vendor-specific definitions.
Source anchor: AWS architecture guidance on decision making is a useful anchor for decisions whose reversibility, blast radius, and coordination cost make them architecturally significant.
Module concepts:
- reversibility
- architectural significance
- coupling
- option value
- decision cost
Wrong Approach
"The managed service is faster, so use it."
Speed matters, but architecture cares about how expensive the decision becomes to reverse.
Better Approach
Score the decision:
Reversible? partly
Data migration? yes
Workflow migration? hard
Skill lock-in? medium
Operational savings? high
Escape hatch? export workflow definitions, isolate engine adapter
Tradeoff Table
| Choice | Gain | Cost |
|---|---|---|
| managed engine | fast delivery and less ops | vendor coupling |
| open-source engine | more control | more operations burden |
| custom orchestrator | perfect fit | high build/maintenance cost |
| adapter boundary | preserves options | extra abstraction to maintain |
Failure Mode
The team treats a one-way-door decision like a two-way-door experiment.
Required Artifact
Write a reversibility note with exit cost, migration path, and the earliest date to revisit the decision.
Project / Capstone Connection
Every major capstone technology choice should include a reversibility paragraph.
Source Map
| Source | Use it for |
|---|---|
| SEI Quality Attribute Workshops | scenarios, utility trees, quality-attribute prioritization |
| C4 model | context/container/component/code diagrams and supporting views |
| Thoughtworks: Building Evolutionary Architectures | fitness functions and automated architecture governance |
| AWS Well-Architected Reliability Pillar | workload reliability, dependencies, recovery objectives |
| AWS CAF decision making | decision framing and governance |
Completion Standard
- At least three case-study artifacts are completed.
- At least one quality attribute is written as a measurable scenario.
- At least one architecture diagram is redrawn for two different audiences.
- At least one fitness function is executable.
- At least one decision includes a reversibility analysis.