Day 28 Architecture Design Review: From Quality Attribute Scenarios to an ATAM Case Study

Day 22‑27 covered architecture responsibilities, the 4+1 view, quality‑attribute scenarios, architectural styles, design methods, and evaluation techniques. Day 28 does not introduce new terminology; instead it stitches those six topics into a single reasoning chain that can be used to answer a case‑study question.

Identify architecture‑driving factors
↓
Write measurable quality‑attribute scenarios
↓
Derive and justify architecture decisions
↓
Use ATAM to discover risks and trade‑offs

The chain starts with stakeholders and business goals, then proceeds through four inputs (why the system is built, what it does, how well it must do it, and constraints), transforms important quality requirements into six‑element scenarios, extracts architecture‑driving factors, selects styles, patterns and tactics, produces the 4+1 views, records choices with rationale, benefits and costs, and finally evaluates the solution with SAAM/ATAM/CBAM.

For the "city emergency command platform" case the article lists three stakeholder groups (command staff, emergency‑response departments, and query users) and their concerns, then identifies six driving factors and constraints such as 20 000 concurrent users with 95 % of queries returning within 2 seconds (performance), a 30‑second recovery target after a service instance failure (availability), a 5‑person‑day integration window for new data sources (modifiability), decoupling of offline departments (reliability), data‑must‑stay‑in‑government‑cloud (deployment), and integration with an existing identity platform (technical constraint).

Two complete six‑element scenarios are built:

Performance scenario : stimulus source = 20 000 query users; stimulus = simultaneous event and resource queries; environment = emergency‑peak traffic; product = query service, cache, event database; response = receive, route, query, return results; response metric = 95 % of requests within 2 seconds.

Availability scenario : stimulus source = command‑service instance; stimulus = instance failure; environment = normal operation or incident handling; product = command‑service cluster and traffic entry; response = detect failure, remove instance, shift traffic; response metric = core command restored within 30 seconds.

Four concrete architectural decisions are justified:

Adopt an event‑system / publish‑subscribe style so each department can consume commands independently, reducing coupling but requiring handling of persistence, duplicate consumption, ordering, idempotency and eventual consistency.

Use a data‑centric warehouse style for shared event data, which simplifies querying and auditing but creates a potential performance bottleneck and single‑point‑of‑failure that must be mitigated with replication or clustering.

Introduce a layered architecture with adapters to isolate external data‑source changes from the core command domain, improving maintainability at the cost of extra conversion layers.

Apply availability and performance tactics: multi‑instance deployment, load balancing with health checks and auto‑removal, caching of hot queries, and high‑availability mechanisms for the event database; these increase operational complexity and monitoring overhead.

The 4+1 view description maps the same system to five perspectives: logical view (functional responsibilities), process view (concurrency and communication of alerts and commands), development view (services, adapters and module dependencies), physical view (gateways, service instances, messaging system, database and government‑cloud nodes), and scenario view (e.g., flood‑alert‑to‑command flow) that ties the other views together.

ATAM assessment identifies a performance‑sensitive point (event‑consumer concurrency or DB connection pool size), a trade‑off (synchronous department confirmation improves certainty but can block the workflow), a risk (single shared event database could make the core command unavailable, violating the 30‑second recovery goal), and a non‑risk (adapter‑based data‑source integration meets the 5‑person‑day target). Improvement actions include adding primary‑secondary replication and automatic failover for the event database, replacing synchronous confirmation with reliable event publishing, and validating the solution through fault‑injection, load‑testing and integration tests.

Finally, the article provides a detailed 20‑point scoring rubric, a set of self‑test questions with reference answers, and a checklist of what a candidate must demonstrate to pass the exam.