Listen for the Nouns

🌐 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 6 in the chapter Modeling Data for Meaning, chapter 2 of the Data Architect course. Each module stands on its own. Previous: the chapter overview · Next: Draw the Relationships

The question this module answers: How do I find the beginnings of a data model in a business conversation?

One of the things I do on a first call with a client is listen for the nouns.

I’m not talking about the first design session. I’m talking about that initial conversation where I’m still trying to understand the business and what they’re trying to accomplish.

They’re talking. I’m listening.

And I’m listening for words like:

Retail Partner. Recipient. Distribution Center. Manifest. Delivery. Route. Crew. Truck.

Those nouns immediately get my attention, because somewhere in that conversation are the beginnings of my data model.

I don’t wait until I think I completely understand the problem. I start seeing the data while I’m still listening: I hear the nouns, I start to sketch how they relate, and that sketch helps me frame the next conversation. Sometimes, by the end of a first meeting with a client, I already have my own private data model drawn out.

For me, that starts with the nouns.

Forget Salesforce for a Minute

This is where I want you to resist an instinct that’s especially strong if you’ve been a Salesforce admin for a while.

The client says customer, and you think:

Account.

They say person, and you think:

Contact.

They say distribution center, and you’re already wondering whether you need a custom object.

Don’t do that yet.

At this point, I don’t care whether a customer eventually becomes an Account, a Person Account, a custom object, or something else. First I want to understand the business.

That’s the difference between modeling the business and configuring Salesforce. If I start with Salesforce objects, I’ve already constrained my thinking to one implementation. I may end up exactly where I expected, but I want to get there because the business led me there, not because Account and Contact were the first two objects I knew.

So for a few minutes, forget Salesforce. Listen to how the people who actually run the business describe their world.

Sit, Stay, Model

Before we listen to a business, let’s listen to something everybody already understands. When I teach this live, I start with dogs.

Here’s a dog: Marcus owns Bella. Maple Ridge Kennels bred her. She’s a Labrador, and she knows Sit, Stay and Shake.

Listen for the nouns: Marcus, Bella, Maple Ridge Kennels, Labrador, Sit. Those are names, though: the specific things. What I want is the kind of thing each name belongs to. Bella is a Dog. Marcus is an Owner. Maple Ridge Kennels is a Breeder. Labrador is a Breed. Sit is a Trick. Five nouns, five candidate boxes.

Click to enlarge

Then the question I ask of every noun: is it a person doing a job, or a piece of data? Marcus is a person. But owning Bella isn’t a job; it’s a fact about Bella, and sooner or later somebody asks, “Who owns this dog?” So the Owner belongs in the model. The trainer who taught Bella to shake is a person doing a job, and may never need a box, unless the business starts asking who taught which trick.

And notice the word candidate. Is Breed really a box of its own, or just a word written on the dog? Hold on to that question; we’ll answer it when we normalize in module 4.

That’s the whole technique, on something small. Now let’s listen to a real business.

Nouns Give You Candidate Entities

Let’s listen to Steve Trucking, the family-owned company we’ll use throughout this course. It delivers large items (refrigerators, washers, TVs) from big-box retailers’ distribution centers to people’s homes, and installs some of them.

In the first conversation we hear:

• Retail Partner
• Recipient
• Distribution Center
• Manifest
• Delivery
• Route
• Crew
• Truck

That’s already useful. I can start putting boxes on a whiteboard.

So put the nouns in rectangles. That’s all they are at this point: boxes. No lines, no colors, nothing that says Salesforce. Later in the course, shapes and colors will start to mean something. For now, a rectangle is just a thing the business talks about.

Then start to orient them. As you place each box, you want to be thinking about two things: how they relate to each other, and what kind of data they are. Some of it is customer data: the businesses and the people we work with. Some is transactional data, like orders and order items: the things that happen, over and over. And some is reference data, like the products or services a business offers: the things the work depends on.

At Steve Trucking, the Retail Partner and the Recipient are customer data. The Manifest, the Delivery and the Route are transactions. The Distribution Center, the Crew and the Truck are what the work depends on.

Click to enlarge

But there’s an important word here: candidate.

A noun is a clue. It isn’t automatically an entity, and it definitely isn’t automatically a Salesforce object.

When I’m in a discovery session, I’m writing every noun down. Every noun they say, I ask myself one question: is that a person doing a job, or is that a piece of data? A business development manager is a person doing a job. That’s a user, a role, maybe a permission set. Orders, invoices, line items: those are pieces of data. Both matter, but they end up in very different places in the design, and sorting them early saves me from drawing a box for every job title in the org chart.

Now, some of those nouns will be people. At Steve Trucking, that’s the Recipient waiting for the refrigerator, the people at the Retail Partner who send the manifest, and the Crew: the drivers and helpers on the truck. These are roles, and a role may not seem like data. But when people act on data, or are related to it, they need to be represented in the data themselves. Who delivered this? Who signed for it? Who sent the manifest? So many roles, sometimes all of them, end up in the model too.

Listen to how Steve Trucking talks, and you’ll notice something. They never just say “customer.” There are two kinds of customer. The Retail Partner is the big-box retailer Steve Trucking delivers for: it sends the manifest and pays per delivery. The Recipient is the person the refrigerator is delivered to. The Recipient bought it from the store and may never have heard of Steve Trucking.

If I’d written one box called Customer, I’d have blended two completely different things.

Maybe Distribution Center is important enough to have its own record, history, relationships and attributes.

Maybe another noun turns out to be nothing more than an attribute of something else.

That’s what we’re trying to discover. We’re not creating objects yet. We’re building our understanding of the business.

Now Listen for the Relationships

The nouns give me a place to start. Then I listen to how the business connects them.

A Retail Partner operates Distribution Centers.

A Retail Partner sends a Manifest for each DC and delivery day.

A Manifest lists Deliveries.

A Delivery goes to a Recipient.

A Route is a day’s run of about ten Stops.

A Crew of two runs a Truck.

Now something is happening. I’m no longer looking at a list of nouns. I’m starting to see a model.

Click to enlarge

This is also where questions start appearing.

Can a Retail Partner have more than one distribution center?

Is a delivery the same thing as a stop?

Can one stop deliver to two Recipients?

Is a crew always the same two people?

Do we care which crew had which truck last month, or only which truck they’re driving today?

Notice what we’re doing. We’re not asking Salesforce questions yet. We’re asking business questions. And those answers will eventually drive the Salesforce design.

Your First Model Doesn’t Need to Be Perfect

I don’t expect the first boxes I draw to survive unchanged. In fact, I’d be suspicious if they did.

The point of the first model isn’t to be right. The point is to give us something concrete enough to discover where we’re wrong.

Put Delivery, Route, Crew and Truck on the board and people can react to them.

“Actually, a delivery isn’t always one item. It might be a washer, a dryer and the haul-away of the old ones.”

Good. Tell me more.

“We don’t assign a crew to a delivery. We assign the crew to a route.”

Great. What’s on the route?

“And if there’s an install, the crew can’t close the stop until the checklist and the photos are done.”

Now we’re learning something important.

A diagram has turned a vague conversation into something we can challenge. That’s one of the reasons I like modeling early. I’m not trying to impress the room with a beautiful diagram. I’m trying to learn faster.

The model is part of the conversation.

This Is Your Conceptual Model

There’s a formal name for what we’ve started building: a conceptual data model.

At this level, I’m interested in the important things the business cares about and how they relate. I’m not worried yet about standard versus custom objects, field API names, lookup versus master-detail, required fields, indexes, automation, Apex or Flows. Those things matter, and we’ll get there. But if we decide them before we understand what we’re modeling, we’re solving the wrong problem first.

The conceptual model should make sense to the people in the room who don’t know Salesforce. That’s a useful test. If I need to explain what Delivery__c means before the operations manager can read my diagram, I’ve moved into the implementation too soon.

I want them looking at the model and saying:

“Yes, that’s how our business works.”

Or, even better:

“No, that’s not how it works.”

Because now I have something to fix.

The Same Technique Works When Nobody Is Talking

This isn’t just something I use in client discovery. It also works when the “client” is a document.

When I’m working through a requirements document, I’m doing much the same thing. What are the important business concepts? What relationships are being described? What appears repeatedly? What has its own lifecycle, needs to be identified on its own, or needs history? What’s being created, changed, assigned, transferred, scheduled or retired?

These are the same things I listen for in that first meeting. On a page, those clues turn paragraphs of requirements into a model I can reason about, and into better questions for the next conversation.

A model isn’t just something you produce after you’ve solved the problem. It’s one of the tools you use to solve the problem.

What an Architect Decides Here

By the end of this first pass, I’m trying to decide:

• Which nouns represent meaningful candidate entities.
• Which different words represent the same business concept, and which one word hides two (like “customer”).
• Which concepts need a record and a lifecycle of their own.
• How the major concepts relate to each other.
• What questions the business needs to answer before I can model them confidently.

I am not deciding the Salesforce implementation yet. First we need to understand the business well enough to draw it. And once we have the nouns on the board, the next thing I want to understand is the lines between them.

Beyond the exam: what AI changes. Give an AI tool a requirements document and it will find the nouns, propose entities and sketch relationships in seconds. Use it to accelerate discovery, but don’t outsource understanding: it can’t know that “customer” means two different things at Steve Trucking unless the business tells you. Put its first model in front of the people who run the business and ask, “Is this really how your business works?”