Deriving Your Real Architectural Drivers

Introduction: The Danger of Vague Goals

In our last post, you were put in the shoes of the architect at CityPulse, caught in a classic conflict between speed and scale. It’s tempting to jump right into a debate about solutions—Monolith vs. Microservices!—but you know that’s putting the cart before the horse.

Why? Because the terms “speed” and “scalability” are still too vague. They are labels for a problem, not a description of it. To make a professional decision, you can’t compare solutions against generic concepts; you must evaluate them against the specific, concrete risks within your business domain. Before you can open the toolbox, you have to map the territory.

This post is about that critical, and often-skipped, next step: conducting a “just enough” analysis of the business problem to derive the real architectural drivers you need to design for.

From Risk to Requirement: A Practical Method

So, how do you get from a vague fear to a concrete requirement? You start by mapping the critical business workflow to find the points of highest risk. For CityPulse, the entire business risk is concentrated in the ticket purchasing flow during a flash sale.

So how do you turn a vague goal like “scalability” into a concrete engineering target? You need a tool to structure your thinking. The best tool for this is the Quality Attribute Scenario (QAS).

(For a complete reference on the most common QAs and a deeper look at the QAS Canvas, check out our full deep-dive guide here.)

It’s a simple story format that forces you to be specific. As the architect, you’d walk through it like this:

“First, who is the Source of the problem? It’s a large number of concurrent users. What is the Stimulus they’re creating? They are all attempting to purchase tickets at once. What is the Environment? The system is under a flash sale, which is otherwise a normal operating condition. What Response do we need? The system must process the purchases successfully. And finally, what is the Response Measure—the number that defines success? Let’s say we need to handle 1,000 purchases per second.”

By following that simple narrative structure, you’ve created a concrete, testable requirement:

“A large number of concurrent users (Source) attempt to purchase tickets (Stimulus) during a flash sale (Environment). The system must process at least 1,000 purchases per second (Response Measure).”

You can apply this same thinking to the other drivers, turning vague goals into a professional specification.

Now You Know the Real Problem

This changes everything. You’re no longer debating vague concepts. You now have a precise, measurable, and prioritized set of engineering targets derived directly from the business risks. You’ve translated the story into a specification.

You know you need a system that can handle high transactional throughput on a small part of its workflow, with high reliability, while ensuring the rest of the site remains performant—and it all has to be built in three months.

Now, and only now, are you ready to make your first, most fundamental architectural decision. You need to choose the Architectural Style that will define the entire structure of your system. In our next post, we will analyze the three primary candidate styles—the Monolith, Microservices, and the Event-Driven approach—and see how they stack up against these specific, measurable drivers.

Further Reading

• Software Architecture in Practice, 3rd Edition by Len Bass, Paul Clements, and Rick Kazman. This is the canonical source for Quality Attribute Scenarios.
• “Documenting Quality Attributes” - a detailed look at Quality Attribute Scenarios from the Software Engineering Institute (SEI).