Cloud Computing Architecture Guide

Discovering Context, Constraints, and Quality Attributes

Goal

Convert vague preferences into bounded, testable needs while making uncertainty visible.

Ask About Outcomes Before Components

Start with stakeholders, critical journeys, business impact, data sensitivity, regulation, geography, workload shape, dependencies, deadlines, team skills, and cost boundaries. "Scalable," "secure," and "global" are prompts for discovery, not usable requirements.

A quality-attribute scenario makes a desired quality concrete:

Stimulus + environment -> affected system -> expected response + measure

For example: "During a regional product launch, authenticated shoppers in Australia and New Zealand should load the catalog within the agreed percentile latency while checkout retains its error budget." The owner must still supply the numbers, but the form reveals what needs measurement.

Availability needs a critical journey and time window. Recovery needs outage and data-loss tolerances. Security needs a threat, protected asset, and required response. Operability needs detection and restoration expectations. Cost needs a demand unit and acceptable spend behavior.

Prioritize and Record Confidence

Qualities conflict. Strong consistency across distant regions can increase latency and reduce availability during partition. Dedicated isolation can improve blast-radius control while increasing cost and fleet work. Ask who can resolve the conflict and which outcome is non-negotiable.

Record assumptions with owner, confidence, impact if wrong, and validation method. Low-confidence, high-impact assumptions should create discovery spikes or reversible designs. Avoid invented precision: an unsupported "99.99%" is decoration, not a requirement.

Example: "Global and Fast"

Discovery identifies users in three regions, a latency-sensitive product browse journey, regulated customer records that must remain in one jurisdiction, and an order workflow that may show a pending state. The team measures current latency, confirms residency with legal owners, and tests edge delivery for static content. The design can now separate global presentation from regional state rather than assume every tier must be active everywhere.

Common Mistakes

  • Asking only technical questions and missing business impact.

  • Treating every quality as top priority.

  • Inventing exact targets without an owner or evidence.

  • Hiding uncertain constraints in diagram annotations.

  • Committing deeply before testing a high-impact assumption.

If Someone Asks You

What questions do you ask before designing the architecture?

"I ask who needs what outcome, which journeys and data matter, under what load and failure conditions, with what security, recovery, geography, skills, deadline, and cost limits. I turn vague qualities into measurable scenarios and record important unknowns as validation work."

What You Should Remember

Constraints create the decision frame; unknowns create the validation plan.

Questions to Check Your Understanding

  1. What makes a quality attribute testable?

  2. Who should resolve a conflict between two business qualities?

  3. How should a low-confidence, high-impact assumption affect the design?

Further Study