Cloud Computing Architecture Guide

A Repeatable Architecture Brainstorming Method

Goal

Move from an ambiguous prompt to a useful decision without turning brainstorming into service-name recall.

The Method

Structure the problem before drawing the solution:

Frame -> Discover -> Model -> Compare -> Recommend -> Pressure-test
  ^                                                      |
  +---------------- learn and revise ---------------------+

Frame the outcome, stakeholders, system boundary, time horizon, and known assumptions. Discover critical journeys, constraints, quality needs, dependencies, and unknowns. Model responsibilities, flows, state, trust, and failure before products. Compare two or three viable shapes against the important drivers. Recommend one conditionally, with consequences and rejected alternatives. Pressure-test failure, security, operations, cost, and change. Then capture decisions, owners, experiments, and revisit triggers.

The loop is deliberately lightweight. A short discussion may complete it on one page. A risky program may revisit it through several workshops. Structure keeps reasoning visible; it does not prevent creativity.

Example: "Make It Highly Available"

Restate the request: "Protect checkout during common infrastructure failures, with recovery for regional loss." Ask which journeys are critical, what outage and data loss are tolerable, where users and data reside, which dependencies can fail, and what budget and team capability exist.

Model the checkout path and state authority. Compare multi-zone regional operation with a warm regional recovery design and a multi-region active design. Recommend only after the recovery objectives and consistency needs distinguish them. Pressure-test dependency failure, traffic switching, stale state, operator access, and an unrehearsed failback.

The session output is not merely a diagram. It includes an assumed recovery objective awaiting owner approval, a selected baseline, a restore experiment, a dependency risk, and named owners.

Common Mistakes

  • Starting with a polished diagram before agreeing on the problem.

  • Treating assumptions as facts or unknowns as reasons to stop.

  • Comparing products before comparing architecture shapes.

  • Ending with a design but no decision, owner, or validation step.

If Someone Asks You

How do you approach a new architecture problem?

"I frame the outcome and assumptions, discover the constraints, model responsibilities and flows, compare viable options, recommend one with trade-offs, pressure-test it, and capture the decisions and experiments needed next."

What You Should Remember

Structure the problem before drawing the solution.

Questions to Check Your Understanding

  1. What belongs in framing rather than solution design?

  2. What evidence should make the group revisit an earlier step?

  3. Which outputs turn conversation into progress?

Further Study