Thinking Like an Architect

🌐 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 1 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 chapter overview · Next: The Data Model Is the Bones

The question this module answers: What’s the difference between building and architecting, and what does an architect actually do?

For most of my career, I’ve been a builder.

I started as a developer. I worked in Java and .NET before moving into Salesforce, and I’ve spent years designing systems, writing code, integrating platforms, teaching architects, and reviewing architectures.

But one of the most important lessons I learned along the way is that being a great builder and being a great architect are not always the same thing.

A builder asks:

How do I build this?

An architect has to ask a different set of questions:

Should we build this?

Why are we building it this way?

What are the alternatives?

What happens when this gets bigger?

What happens when it fails?

And what decision are we making today that we’re going to wish we had thought harder about three years from now?

I remember being on a project for a retail business with appointments. I asked: how many appointments a day per store? Then, how many stores do you have? And how many days a week are you open? Quickly, I realized we were going to have millions of appointments in the first year alone. Those are the questions an architect asks at the start of a project.

That change in thinking is what this course is really about.

Click to enlarge

The Person Holding the Blueprint

I’ve used this analogy many times when teaching architects.

Imagine a construction site. There are people pouring concrete, running electrical, installing plumbing, framing walls, and doing dozens of other specialized jobs. They need to be very good at what they do.

But somebody also needs to be holding the blueprint.

That person needs to understand how all those pieces fit together. They need to notice when something happening in one part of the project creates a problem somewhere else.

That’s architecture.

In technology, we sometimes make the mistake of thinking the architect is simply the person who knows the most. That’s not really it. Knowing the platform matters. You need technical depth. But architecture isn’t a trivia contest.

The architect’s job is to make good decisions, sometimes with incomplete information and competing requirements, and understand the consequences of those decisions.

That’s a very different skill.

Don’t Just Take the Requirement

One of the first habits I want architects to develop is simple:

Ask why.

Someone tells you:

We need another object.

Why?

We need this field copied onto the Account.

Why?

We need all of this data stored in Salesforce.

Why?

That doesn’t mean being difficult. It means understanding the actual business requirement instead of immediately implementing the proposed solution.

A requirement often arrives disguised as a design.

“We need a new custom object” isn’t necessarily a requirement. The requirement might actually be “we need to track this information separately.” Those are not the same thing.

Once you understand the real requirement, you can start exploring alternatives. Maybe a new object is exactly the right answer. Maybe the information belongs somewhere that already exists. Maybe Salesforce shouldn’t own that data at all.

The architect has to separate what the business needs from one proposed way of delivering it.

We were working on a sales application, and the customer had multiple approvals, each with an approver and a date. Their first ask was to add Approver 2 and Approver 3, each with a date, as fields on the Opportunity. When we dug deeper, we realized there could be more than two or three. So we moved approvals to a child object. The request was for more fields; the requirement was to track every approval, however many there turned out to be.

Thinking Beyond the Requirement

Two habits follow from asking why, and each gets its own module later in this chapter.

There is usually more than one answer. Salesforce gives us a lot of ways to solve a problem, and some of them are wrong almost immediately. Choosing between the ones that work is the art of trade-offs (module 4).

And the requirements you’re given aren’t all the requirements you have. Nobody says “make sure this works when the nightly load only half succeeds,” but it’s still a requirement. I look at every design through three lenses, build for today, plan for tomorrow, plan for failure (module 5).

Think about someone who hires an architect to design a building. They don’t ask for a fire alarm or a sprinkler system, or for the building to stand up in an earthquake. They expect it as part of the job, without asking. Our world works the same way. Nobody asks for graceful error handling, for logs, or for a way to recover when something fails. It’s up to the architect to know which of those systems belong in the design, and to put them in.

Click to enlarge

Make Your Reasoning Visible

An architect shouldn’t just walk into a room and announce, “This is what we’re doing.”

Your job is also to explain why. I want stakeholders to understand the alternatives we considered and the trade-offs involved. That doesn’t mean giving an executive a 40-page design document. It means being able to explain the same architecture to a developer, to the business, and to an executive: different conversations about the same decision.

And the way to do that is with clear blueprints and instructions, like the person holding the blueprint on the construction site. For a Data Architect, one of the most important of those blueprints is the data model.

If nobody understands why a decision was made, there is a good chance somebody will eventually undo it. And they may have perfectly reasonable reasons for doing so, because nobody ever explained the original decision.

The Architect Doesn’t Need to Build Everything

There’s another transition that can be difficult, especially for people who come into architecture through development.

You don’t have to personally build everything.

I still like understanding how things work at a very technical level, and that foundation matters. But as an architect, your responsibility becomes larger than your own implementation. You don’t have to build everything; you need to know how to give the people who do build it the right direction and the right parameters. That means understanding enough to guide their work, to recognize when a proposed implementation creates an architectural problem, and to move between the details and the bigger picture.

Sometimes that means going deep into a query, an API, or a data model.

Sometimes it means stepping back and asking whether we should be doing any of it in the first place.

And more and more, what’s doing the building isn’t only people. With AI, the architect may be working directly with the tool that generates the objects, the code and the screens. Then the direction, the parameters and the guidelines go to the AI, and giving them well becomes more and more the architect’s responsibility. We’ll come back to that in module 7.

That’s part of the journey from builder to architect.

Your Job Is to Make Decisions

Ultimately, architecture is about decisions.

Some decisions are easy to change. Others aren’t.

A page layout can be changed. A label can be renamed.

But choose the wrong fundamental data model, publish identifiers that dozens of systems begin depending on, or put the master copy of critical data in the wrong place, and changing your mind becomes much more expensive.

Those are architectural decisions. And those are exactly the kinds of decisions this course concentrates on.

As a Data Architect, you’re going to make decisions about how information is structured, where it lives, how it grows, how it moves, who can access it, and how the rest of the enterprise understands it.

The technology matters.

But knowing every Salesforce feature isn’t the goal.

The goal is developing the judgment to know which tool to use, when to use it, what you’re trading away, and what happens next.

That’s thinking like an architect.

And now we can start thinking like a Data Architect.

What an Architect Decides Here

• Whether a request is a real requirement, or one proposed design for it.
• Which questions to ask before anything is built: should we, why this way, what else could we do, what happens when it grows or fails.
• Which decisions are the architect’s to make, and which belong to the people building; and what direction and parameters to give the builders, people or AI.
• How to explain a decision so a developer, the business and an executive each understand it.