The Reversibility Test

🌐 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 3 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 Data Model Is the Bones · Next: Architecture Is the Art of Trade-offs

The question this module answers: How do you tell an architectural decision from an ordinary one?

Architects make a lot of decisions.

But not every decision is an architectural decision.

That’s an important distinction. If we treat every decision as architecture, we’ll spend all our time debating things that are relatively easy to change. If we don’t recognize the decisions that really are architectural, we can make a five-minute decision today that takes five years to unwind.

So how do we tell the difference?

I like to ask a simple question:

How difficult will this decision be to reverse later?

I call this the Reversibility Test.

The harder something is to reverse, and the more other things will depend on it, the more architectural attention it deserves.

Some Decisions Are Cheap to Change

Let’s start with something simple.

We call a field Customer Category. Six months later, the business decides everyone really calls it Customer Segment. We change the label. There may be some documentation to update and a little user training, but this isn’t a major architectural event. We’ll have to live with the original API name, though, because changing that has much larger consequences. So this may just mean dealing with a label change, and the confusion that can come with it.

We made a decision. We changed our minds. We moved on.

Now compare that with a different decision.

We’re creating an identifier for customers. We decide what it means, what format it uses, and which system creates it. Then we publish it.

Salesforce uses it. The data warehouse uses it. The integration platform uses it. The customer portal uses it. Five other applications start storing it. Reports and data pipelines use it. Maybe customers eventually see it.

Three years later, someone says:

We probably shouldn’t have designed the identifier that way.

That’s a very different conversation.

The difference isn’t that one decision is more technical than the other.

The difference is reversibility.

Here’s how that can happen. Say the business has been building its keys from part of the customer’s name plus a number. It works for years, because no one has ever had to change a name. Then, a year or more later, a name does change, and all of a sudden the keys don’t match the pattern the rest of the data expects. This is one of the reasons keys shouldn’t carry any intrinsic meaning.

Architecture Creates Gravity

An architectural decision tends to accumulate things around it. I think of that as gravity.

Choose an object model, and automation gets built around it.

Choose a key, and other systems start storing it.

Choose where master data lives, and integrations start flowing toward and away from it.

Choose a sharing model, and business processes start depending on who can see what.

Choose an integration pattern, and systems start depending on its timing and behavior.

The longer those decisions exist, the more gravity they develop. Eventually, changing the original decision means changing everything that has accumulated around it.

AI feels that gravity too. An AI tool works from what’s already in the system: once a key design element is there, every AI interaction after it treats that element as fact and keeps building on it, and building on it, and building on it. The decision echoes forward through many more decisions, and no human ever goes back to revisit the original one. Every generation adds to the gravity.

That’s why the data model being “the bones” matters. We’re not careful because change is bad. We’re careful because dependencies make change expensive.

Ask Two Questions

When I’m looking at a design decision, I ask two questions:

How hard is this to reverse?

How much will depend on it?

They’re related, but not identical. Something can be technically easy to change but have hundreds of consumers. People used to relabel standard objects for clarity, Account as “Customer”, say. Easy to do. Then another system wanted to use Accounts for Partners, and it couldn’t. Something else may have only a few consumers but need an enormous migration to change, like the API name of an object that’s referenced in many places internally. Nobody outside sees it, but a wrong one keeps confusing the team. Either one deserves attention.

Think about some common data decisions:

• Which Salesforce object represents this business concept?
• What is the unique identifier?
• Which system is the system of record?
• Is this data copied into Salesforce or accessed somewhere else?
• Is this one object or several related objects?
• Who owns the data, and how long do we keep it?
• What are our default access boundaries?
• How does this data move between systems?

Those are very different from deciding where a field appears on a Lightning page. Page design matters too. The cost of being wrong is different.

Click to enlarge

Think About the Blast Radius

Another way to think about reversibility is blast radius: if I change this decision, what else moves?

Suppose something we modeled as a field really needs to become a child object. That’s not just a schema change. What happens to the existing data? To the reports, the integrations expecting that field, the Apex and Flows that reference it, the security, the analytics, an AI agent whose actions depend on the original structure?

The larger the radius, the more carefully we should make the original decision.

That’s also why architects have to look beyond their own part of the system. From inside Salesforce, a change might look easy. From the enterprise, it may affect twelve other systems.

Enterprise Decisions and Salesforce Decisions

A Data Architect thinks at two levels.

Inside Salesforce, we decide objects, relationships, keys, volume, access, automation, and how data behaves on the platform.

Across the enterprise, we ask broader questions. Where does Customer actually live? Who owns Product? Which system creates an Order? What is our authoritative identifier? Which information gets copied between systems, and which stays where it is?

The two levels have to connect. I’ve seen Salesforce implementations where the internal model made perfect sense on its own but didn’t fit the enterprise around it. That’s not enough. Salesforce structures need to be represented at the enterprise level, and enterprise decisions need to flow back into Salesforce.

Architecture is two-way traffic.

Click to enlarge

Slow Down the Expensive Decisions

One danger in technology is that the easiest decisions to implement can look like the easiest decisions to make. They aren’t the same thing.

Creating another custom object is easy. Creating another field is easy. Connecting another API is getting easier, and AI makes all of it easier still.

But ease of implementation tells us almost nothing about the cost of the architectural decision.

Before a difficult-to-reverse decision, slow down long enough to ask: What problem are we actually solving? What alternatives did we consider? What are we assuming? What happens as volume grows, and as the business changes? What else will depend on this? What happens if we’re wrong?

We don’t need six months of review every time we create an object. We do need thought in proportion to the cost of getting it wrong. If it’s an object for a single department or subsystem, you can move more quickly. If it’s reference data, a key customer object, or something used across systems, take the time to think it through.

Write Down Why

There’s another problem with important decisions: people forget why they were made.

Someone looks at an architecture three years later and asks, “Why would anybody design it this way?” Sometimes the answer is that it was a bad design. That happens. But sometimes there was a very good reason: a platform limitation that no longer exists, a regulatory requirement, another system that couldn’t support the preferred approach, a trade-off knowingly accepted to meet a deadline.

If we only record what we decided and not why, the next architect has no way of knowing.

For significant decisions, write it down. It doesn’t need to be a 50-page document. A useful decision record can be very small:

Context: What problem are we solving?

Options: What realistic alternatives did we consider?

Decision: What did we choose?

Consequences: What do we gain, and what are we giving up?

Owner: Who is accountable for this decision?

Review: What reason or date should make us revisit it?

The value isn’t the document. The value is preserving the reasoning.

And when a decision changes, don’t erase the original. Supersede it. The decision that was right in 2027 might not be right in 2030, because volumes, the business, Salesforce and our understanding all change. What I want to keep is the story: here was the context, here was the decision and why, here’s what changed, and here’s what we’re deciding now. That’s far more valuable than pretending we always knew the answer.

Click to enlarge

Beyond the exam: AI shortens the time from decision to dependency. An AI tool can propose a data model in seconds, then create the objects, the automation, the integration code and the user interface on top of it. A questionable decision used to take months of development before much depended on it; now the dependencies arrive almost at once. So review the decisions underneath the output, not just the output. AI can help: it can list options, challenge assumptions and draft the decision record. But the architect still decides, and the harder the decision is to reverse, the more that human judgment matters.

Know Which Decisions Matter

One of the skills I want you to develop is knowing where to spend your attention.

Don’t turn every configuration choice into an architecture summit.

But don’t casually make a decision the organization will live with for the next decade.

Ask:

How difficult will this be to reverse?

How much will depend on it?

If the answers are very difficult and a lot, you’ve probably found an architectural decision.

Click to enlarge

Slow down. Understand the requirement. Explore the alternatives. Make the trade-offs visible. Make the decision. And write down why.

The goal of architecture isn’t to make decisions that can never change.

The goal is to recognize the decisions where changing your mind is going to be expensive.

What an Architect Decides Here

• Which decisions are architectural: hard to reverse, with a lot depending on them.
• How much attention each decision gets, in proportion to the cost of being wrong.
• Which decisions get written down, with their context, options, consequences, owner and review point.
• How the Salesforce decisions line up with the enterprise’s.

Explore

• Object Relationships Overview (opens in a new tab), Salesforce Help (checked 2026-10-09; re-checked 2026-10-12): in a master-detail relationship the detail’s access and ownership follow the master, and deleting a master deletes its details.
• Considerations for Object Relationships (opens in a new tab), Salesforce Help (checked 2026-10-09; re-checked 2026-10-12): a lookup converts to master-detail only when every record has a value in it; converting changes the sharing model (to Controlled by Parent), and the relationship type decides which standard report types are available.
• Roll-Up Summary Field (opens in a new tab), Salesforce Help (checked 2026-10-09; re-checked 2026-10-12): roll-up summaries exist only on master-detail relationships, and must be deleted before a master-detail can become a lookup.