Mapping Domains and Stakeholders

In the last unit you settled a single term and named one owner for it. But a definition fight is almost never just two people in a room. Behind every disputed number sits a whole crowd: people who create the data, people who live off it in their daily work, and people who quietly worry about whether it's safe to use at all. This unit zooms out from the one term to the bigger picture, so that before anyone changes data, you can name everyone the change touches. Get this right and you stop the most common own-goal in governance: someone "fixes" data and accidentally breaks three teams downstream.

When a data problem lands on your desk, your first move is to name the data domain it lives in. A data domain is just a big bucket of related data organized around one business subject. The common ones are customer, product, supplier, employee, and finance. Naming the domain matters because each one quietly feeds a set of business processes, and those processes are what actually break when the data is wrong.

Think about how this plays out. The customer domain feeds onboarding, marketing outreach, and support. The product domain feeds order fulfillment, pricing, and most reporting. The supplier domain feeds procurement and paying invoices on time. The employee domain feeds hiring and payroll, and the finance domain feeds the monthly close. So when someone says "the product hierarchy looks off," you immediately know that fulfillment, pricing, and reporting are all in the blast radius. The domain is your map of who could get hurt.

Once you've named the domain, zoom in on the single dataset in question and ask who's standing around it. There's a predictable cast, and you'll meet each of these roles in much more depth in the next course. For now, you just need to recognize them. Producers create or supply the data, like the front-line staff typing in new records. Consumers use it to do their jobs, run dashboards, or make decisions. The owner is the one person accountable for what the data means and for the big calls about it. The steward handles the day-to-day coordination and quality issues. The custodian manages the technical home where the data lives and keeps it secured. And the risk partner weighs the compliance, privacy, or security angle when the data is sensitive.

The whole point is that no single team owns all of this, even when one person feels like they do.

• Ryan: I'm just updating the product list this afternoon, it's my data.
• Natalie: Before you do, who actually relies on that list after you change it?
• Ryan: Well, the order team uses it to ship, and finance rolls it into pricing.
• Natalie: Right, those are your consumers. And whoever stores and secures it is the custodian. Change it with no heads-up and shipping breaks tomorrow.
• Ryan: Okay, so I should at least tell them first.

Notice the move Natalie made: she didn't argue about who "owns" the data. She just asked who relies on it, and the cast revealed itself.