Analyzing Architecture Tradeoffs

Why You Can't Have Everything (And That's Okay)

Apr 20, 2026

There’s a ship at the bottom of Stockholm’s harbor that every software architect should know about.

It’s called the Vasa. And it sank on its maiden voyage, in front of thousands of spectators, without ever leaving the harbor.

In the 1620s, the King of Sweden was at war with Poland and hemorrhaging money. He wanted a naval advantage, fast. So he commissioned the finest shipbuilder in the land to build something no one had ever seen before: a warship over 200 feet long, two gun decks with 64 cannons, and the capacity to carry 300 soldiers safely across open water to enemy shores. Grander than anything afloat.

The ship’s architect — a capable man by any measure — did what capable people do when asked to do everything: he tried to do everything. He built it exactly to specification. Every requirement was met. It fired its gun salute, tipped sideways as water flooded the open lower gun ports, and sank. The architect had died a year before the launch, so he never saw his creation go down with it.

Mark Richards tells this story in the O’Reilly Software Architecture Fundamentals course, and it lands every time because it’s not really about a 17th century warship. It’s about what happens when an architect tries to satisfy every stakeholder without making hard choices.

The Stakeholder Choir

Here’s a scenario that will feel painfully familiar.

You’re the architect on a project. In a single week, you hear this from four different people:

User support team: “We need lightning-fast response time to keep up with the backlog of calls.”

Operations director: “Over time, we expect the entire company to be using this system — not just the few users on it now.”

CIO, at the end of the quarterly meeting: “By the way, we’re planning to acquire several new businesses in the next five years.”

Project sponsor, Friday afternoon: “Oh — and the budget and timeline are very tight.”

Each of these is a legitimate concern. Translated into architectural characteristics, you’re now looking at performance, scalability, extensibility, agility, maintainability, and feasibility — all on the same project, all from real stakeholders who expect their concerns to be addressed.

This is the moment where architects earn their title, or don’t.

Because here’s the uncomfortable truth that no one in the requirements meeting will say out loud: some of these characteristics are fundamentally at odds with each other. Performance and scalability can pull in opposite directions. High availability costs real money. Tight timelines kill extensibility. You cannot fully maximize all of them simultaneously, any more than the Vasa’s architect could make a ship that was simultaneously lightweight, heavily armed, and stable in open water.

The difference between a great architect and an average one isn’t the ability to design a system that satisfies everything. It’s the wisdom to know what to sacrifice, the skill to explain why, and the tools to make that decision defensible.

Two Methods That Help You Think It Through

The course introduces two structured approaches for analyzing architecture tradeoffs. Neither is a silver bullet, but both give you a language and a process for having conversations that would otherwise devolve into politics and gut feelings.

ATAM — Architecture Tradeoff Analysis Method

ATAM takes three inputs: your proposed architecture, the business drivers behind it, and the quality attributes (your “ilities” — scalability, availability, reliability, and so on). Run it through the process, and what you’re supposed to get out the other side is a validated, stakeholder-approved architecture.

The process goes roughly like this:

Preparation is where all the relevant parties get in the same room (or virtual space), align on roles, goals, logistics, and expectations. Housekeeping, essentially, but important housekeeping.

Evaluation Phase 1 is where it gets interesting. Stakeholders start throwing scenarios at you. What if this data center fails? Can we still process orders at the same response time? What happens to throughput when we’re at peak load? The architect has to defend the architecture against these scenarios — and this is where the real tradeoffs surface. High performance and high availability are often like oil and water. You might be able to get one or split the difference in different parts of the system, but you rarely get both fully.

After Phase 1, the architect goes away, patches the holes that were exposed, and comes back for Evaluation Phase 2, where the scenarios are refined further, tradeoffs get more explicitly documented, and the architecture moves toward sign-off.

Here’s what Richards is honest about: the traditional ATAM process doesn’t work perfectly in the real world. It assumes all stakeholders can be in the same room at the same time with a complete architecture ready for review. That almost never happens. Stakeholders are distributed. Some are only interested in specific aspects. Some have agendas that eat meeting time.

So his guidance is this: focus on the goals of ATAM, not the process itself.

Those goals are worth repeating because they’re genuinely useful regardless of what process you follow:

Have an architecture presentation. Most shops don’t. If you can’t show someone the architecture in five minutes or forty-five, you don’t really understand it yourself — and you definitely can’t get stakeholder alignment on something no one can see.
Validate assumptions and assess tradeoffs. Without some kind of structured dialogue, you end up defending your own assumptions to yourself. You need someone to push back, challenge scenarios, and force you to think through failure modes you’d rather not consider.
Identify and mitigate risks. This is the piece most architects skip. You do the tradeoff analysis, but then don’t document what it means for risk. That conversation needs to happen explicitly.
Get stakeholder buy-in. Including from the developers. The architecture doesn’t work if the people building it don’t understand it or don’t believe in it.

CBAM — Cost-Benefit Analysis Method

The second approach, CBAM, takes a different angle. Instead of asking “which characteristics trade off against each other,” it asks: what does each level of quality cost, and is that cost worth the benefit?

Richards gives a concrete example. You want a six-nines architecture — 99.9999% availability, which translates to about 31.5 seconds of unplanned downtime per year. Achievable? Yes. But it’s going to cost around $12 million. If your budget is $6 million, you can’t get there.

So you ask a different question: what can $6 million actually buy? Maybe a five-nines architecture (about five minutes of downtime per year). Maybe four nines (about eight hours). Both are orders of magnitude better than most systems in the wild. Is the delta between four nines and six nines worth doubling your budget? That’s a business decision, not a technical one — but the architect needs to frame it clearly enough that the business can actually make it.

CBAM is particularly useful when you have stakeholders who are used to treating architectural decisions as free. Nothing is free. High availability costs money. Scalability costs money. Extensibility costs time and complexity. Making those costs explicit, and pairing them with quantified benefits, turns an abstract conversation into a real one.

The Skill Underneath the Methods

What both ATAM and CBAM are really giving you is a scaffold for a conversation that’s difficult to have without one.

Because the deeper skill here — the one that takes years to develop — is the ability to sit with competing requirements and not panic. To resist the temptation to promise everything and build the Vasa. To look at “lightning-fast response time” and “plan to acquire several new businesses” and “tight budget” in the same requirements document and say: these are real constraints, they pull in different directions, and here is how I’m going to make an explicit, defensible choice about which ones take priority in which parts of the system.

That’s not a failure of architecture. That’s architecture.

The Vasa sank because its architect tried to give the King everything he asked for without pushing back on the physical impossibility of the combination. The ship’s requirements were contradictory. No one asked the hard question early enough: what does this ship actually need to do, and which of these demands can it realistically meet at the same time?

Software systems sink the same way — quietly, over time, under the weight of accumulated promises that were never meant to coexist.

One Last Thing Worth Saying

If you work in the Microsoft ecosystem — Azure, Power Platform, Dynamics — these tradeoffs show up constantly, just with different labels.

Do you want your Power Automate flows to be fast or robust? Do you want your Azure API Management layer to be highly available or cost-optimized? Do you want your Dataverse schema to be perfectly normalized or easy to query? Every platform decision is an architecture decision, and every architecture decision carries a tradeoff.

The frameworks — ATAM, CBAM, or whatever version of them you adapt for your context — aren’t about generating paperwork. They’re about making sure that when you look back at a decision six months later, you can explain why it was the right call given what you knew, what you prioritized, and what it cost.

That’s the difference between architecture and guessing.

And it’s what keeps your ship off the bottom of the harbor.

Thirsty Explorer

Discussion about this post

Ready for more?