Architecture Is the Art of Trade-offs

🌐 Also in 28 languages

Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Image generated with AI

Module 4 of 7 in the chapter Thinking Like a Data Architect, the first chapter of the Data Architect course. Each module stands on its own. Previous: The Reversibility Test · Next: Build for Today. Plan for Tomorrow. Plan for Failure.

The question this module answers: When several solutions could work, how does an architect choose, and explain the choice?

If architecture were simply about identifying the correct answer, it would be a lot easier. Learn the platform, learn the patterns, learn the limits, choose the right one, done.

That’s not how real architecture works. The hard decisions usually aren’t between an obviously good solution and an obviously bad one. They’re between several solutions that could work, each with advantages and disadvantages, each moving the architecture in a slightly different direction. That’s where the architect earns their seat at the table.

Many Ways to Solve the Problem

I’ve used a version of this example many times when teaching architects.

There can be many ways to solve a problem in Salesforce. I sometimes put a number on it, say ten, but that’s an analogy, not a count. Many of the options have issues from the start: they run into a platform constraint, miss a critical requirement, or create a security or performance problem we can’t accept. We can set those aside quickly. Some others work today but will have issues when the data grows. They’re technically functional, but they won’t hold up under the growth we already know is coming.

What’s left is a small number of options that can support your needs going forward, and now it gets interesting. Each of them might work, scale and satisfy the requirements. So which one is correct? Maybe all of them. The architect’s job is to understand the differences.

Even something as simple as a picklist works today and can have issues as the data grows. A picklist is easy for users. But ask where the values come from, and how many there can be. Picklists work best with fewer than about 20 values. Occasionally we go up to 50, like US states, and rarely past 100, like countries, and those get unwieldy. So for every picklist, know the upper bound. And changing a picklist’s values is a metadata change, not a data change.

Use a lookup instead, and the user interface gets a little more complex. But the list can keep growing with no upper bound, and new values can arrive from an integration. That’s a trade-off against usability. That’s the balance.

Click to enlarge

Optimal Doesn’t Mean Perfect

I use the word optimal carefully. An optimal architecture isn’t one where every individual decision is perfect; that architecture probably doesn’t exist. It’s one where the overall solution is balanced.

Suppose Solution A gives the best performance but is expensive and hard to maintain. Solution B costs less and is easier to operate but gives up some performance. Solution C is more flexible for the future but adds complexity today. Which is optimal? I can’t answer from those facts alone. I need to know the business, the requirements and the priorities, and which constraints are real and which are preferences. Architecture is contextual. That’s why the pattern that was right for one customer can be completely wrong for the next.

And your job as a Data Architect is to balance these decisions. You’ll make dozens of them yourself, or with your team. Know which ones those are, and know when a decision has a bigger impact, on cost, time or functionality, and needs to go up to the key decision makers.

A Suboptimal Decision Can Be Part of an Optimal Architecture

This is one of the most important ideas in this chapter. Sometimes I will knowingly make a suboptimal decision in one part of the architecture because it makes the whole solution better.

Maybe I duplicate a small amount of data, because removing the duplication would create unnecessary integration complexity. Maybe I choose a simpler data model, because the theoretically cleaner one would make reporting and everyday use much harder. Maybe I accept a small performance cost, because the alternative adds infrastructure the organization isn’t ready to operate.

Look at any one of those in isolation and you’d say it’s not optimal. Correct. But architecture isn’t about optimizing every component on its own; it’s about optimizing the system. A locally suboptimal decision can be part of a globally optimal architecture, as long as we understand the trade-off we’re making. What’s dangerous is making the trade-off without knowing you’re making it.

Know What You’re Trading Away

Whenever someone tells me “this is the best solution,” my next question is “best at what?” Fastest? Cheapest? Simplest? Most scalable, most secure, most flexible? Easiest to operate, fastest to deliver, least dependent on specialized skills? There’s almost always another dimension where the answer isn’t “best.” That’s the trade-off. I want to know what we’re getting, and I also want to know what we’re giving up.

Take two options for a large set of enterprise data. One copies the data into Salesforce, which makes Salesforce-native capabilities easier to use, but now we’re responsible for moving it, storing it, synchronizing it, securing another copy and dealing with latency. The other leaves the data where it is and accesses it when needed. We’ve removed some duplication, but now availability, query performance, network dependencies and the remote system’s capabilities matter more. Neither description tells us which to choose. It tells us what questions to ask.

Requirements Aren’t All Equal

Trade-offs also force us to see that not every requirement carries the same weight.

Someone says, “The data needs to be available instantly.” Okay, what does instantly mean? One second, ten seconds, a minute? And why? Maybe it’s fraud detection, where seconds matter. Maybe someone just doesn’t like waiting for the nightly load. Those are very different requirements, and the architect keeps asking until we know which one we have.

I like requirements that survive questions: how much, how many, how fast, how often, for whom, and what happens if we don’t? “Fast” isn’t an architecture requirement. “95 percent of customer updates must be available to the service agent within 30 seconds” is much closer to one. Now we can evaluate trade-offs.

Constraints Change the Answer

Sometimes the architecture isn’t constrained by technology at all. It’s constrained by money, people, time, licensing or organizational maturity.

An architecture that’s technically excellent but needs an operations team the company doesn’t have isn’t a good architecture. A capability that solves the problem elegantly but needs licensing the customer won’t buy isn’t the solution either. And the perfect three-year transformation doesn’t help a company that has to launch in eight weeks.

None of that means we abandon good architecture because of a deadline. It means we understand what we’re compromising, why, and what consequences we’re accepting, and ideally how we’ll get from today’s compromise to tomorrow’s architecture.

The Architect Needs a Picture of “Optimal”

Here’s an interesting tension. I’m telling you there often isn’t one perfect answer, and I also want you to carry a picture in your head of what an optimal solution looks like. Those aren’t contradictory. You need a reference point.

When I look at a data model, I want to know what I’d build if I could optimize for the requirements without unnecessary constraints. Then, as real constraints push us away from that design (we flatten part of the model, duplicate some data, defer an integration, accept a temporary manual process), I’m not making random compromises. I know which direction I’m moving away from optimal, and why. That’s the art of architecture, and the instinct takes practice.

Draw It

One of the best ways to understand a trade-off is to draw it. Architecture diagrams aren’t decorations for a slide deck; they’re thinking tools. If we’re choosing between two approaches, draw both. Where does the data live, and where does it move? What owns it? Where are the boundaries, and where is security enforced? What happens when something fails, and what changes as volume grows?

A diagram forces ambiguity into the open, and it gives everyone the same picture to point at.

I learned how much that matters on a project with a utility. Review after review, I found myself explaining the same concepts again and pulling the conversation back to the original design. So I changed how I ran those meetings: every review started with the data model on the screen. Not the detailed one with every field. A summary model: an account has contacts, this record has children, here’s where the work hangs. The room was mostly executives, and it took a couple of minutes.

Because it was the same people meeting after meeting, the diagram became our shared language. People started using its names. The repeated questions faded, and the meetings got much easier. I call it grounding the meeting: a simple diagram, shown every time, was worth far more than it cost to make.

The goal isn’t artistic perfection. Sometimes it’s a detailed diagram for engineers, sometimes five boxes and six arrows for an executive. The goal is clarity.

Explain the Trade-off

A good architect lays it out in order: here are the options we considered, here’s what each gives us, here’s what each costs us, here’s the option I recommend, and here’s why.

Notice that the recommendation comes after the trade-offs. I don’t want architecture to become “I’ve done this before, trust me.” Experience matters enormously; it helps you recognize patterns faster and see problems earlier. But your experience should improve your reasoning, not replace it. Our job isn’t just to understand the architecture. It’s to help the organization understand the decision, especially when the people making the final call aren’t architects.

Think Correct. Think Fast.

You won’t always have three weeks to analyze every option. Sometimes you’ll have three minutes. A requirement changes in a meeting, someone names a constraint you didn’t know about, or an executive asks, “What if we need this in Europe next year?”

I’ve used the phrase Think Correct. Think Fast. Speed doesn’t come from skipping the thinking. It comes from having done enough thinking before the moment arrives: you’ve learned the patterns, you know the platform, you’ve seen failures, you know which questions to ask and which decisions are hard to reverse. That’s why we work through scenarios throughout this course. The more decisions you analyze, the faster you recognize the shape of the next one.

I had a customer who needed form entry. But there were many forms, and the questions could change over time. I quickly recognized the need for a survey data model, a pattern we’ll come back to later in the course. Because I recognized the pattern and the solution, I was able to bring in a more complete data model, one that handled the requirements still to come, not just the ones in front of us.

Architecture Is About Balance

As we go deeper into data architecture, you’ll meet choices where I resist giving you a simple rule. Normalize or flatten? Copy the data or federate it? Synchronous or asynchronous? Standard object or custom? Archive it or keep it online?

There are principles, patterns and limits, and sometimes clearly wrong answers. But often the architect’s job is to find the right balance for this system, this business and this moment.

Know what optimal looks like. Understand the constraints. Identify the viable options. Make the trade-offs visible. Then make the decision.

That’s not indecision. That’s architecture.

What an Architect Decides Here

• Which options are viable, and which are wrong now or will go bad in a year.
• What each viable option gains and gives up, measured against requirements that survive questions.
• Which constraints are real and which are only preferences.
• Which option to recommend, after laying out the trade-offs, and how to explain it.