Governance Is Designed Into the Org

🌐 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 Data Quality and Governance, chapter 5 of the Data Architect course. Each module stands on its own. Next: Keeping Bad Data Out

The question this module answers: What does data governance mean for an architect, and who does what?

When people hear data governance, they think of meetings: committees, policies, standards, a document explaining who’s supposed to do what with the data. All of that may be part of a governance program. As an architect, I’m interested in a different question: where is the policy enforced?

If the policy says only Finance may change a field, what enforces that? If it says the ERP owns the legal customer record, what stops someone in Salesforce from changing it? If it says crews see a Recipient’s address only for their own stops, only on the day, what actually makes that true? If it says keep this for seven years, what archives or removes it after seven? A policy without an enforcement point is mostly a wish. Governance becomes architecture when those decisions are built into the system.

Governance Is Never Finished

Let me get this out of the way early: you don’t finish governance. I’ve seen it run in ebbs and flows. A company puts real attention on data quality, and things improve. Attention moves elsewhere, and quality slips. A new integration comes online, a business unit changes its process, someone imports a file, the company acquires another one, an agent starts writing records, and the problem changes again. The goal isn’t a mythical state where every record is perfect forever. It’s to keep the data trustworthy enough for the business and keep the worst of the bad data out. That’s ongoing work.

When Salesforce stands mostly alone, governance means cleaning data in one place. When it’s one node in the landscape from chapter 4, it gets harder, and more necessary. Now the customer lives in Salesforce, the ERP, the warehouse, partner systems, Data 360. Who owns it? Who can change it? Which copy is authoritative, which attributes may move, how long are they kept, and who answers when they’re wrong? Those aren’t configuration questions. They’re governance questions that become configuration.

Record Owner Isn’t Data Owner

Start with the word owner, because Salesforce makes it confusing. Open an account and you see an Owner: a sales rep, say. Does the rep own the customer data? Not necessarily. On Salesforce, a record on an object with an owner is owned by a user or a queue; the owner gets full access, and the owner drives assignment and sharing through the role hierarchy and sharing rules (Sharing and Record Access Features (opens in a new tab)). That’s record ownership: a platform mechanism.

The data owner is something else: the person or function accountable for the data as a business asset. Finance may own the legal customer information, Operations the delivery status, HR the employee data. Salesforce even gives you somewhere to record that: the Data Owner classification field on each field (Data Classification Metadata Fields (opens in a new tab)).

At Steve Trucking, a Retail Partner’s account may be owned by the sales executive who manages that partner. But the partner’s legal identity is governed by Finance and mastered in the finance ERP. Sales, service, operations and the partner portal all need the account; none of that means the sales executive should change the partner’s legal identity once Finance has established it. I’ve seen teams look at the Owner field and assume they’ve solved data ownership. They haven’t. Record assignment isn’t business accountability.

Owner, Steward, Custodian

Three governance roles, three different jobs.

The data owner sets the policy. They answer what the data means, who may create and change it, how accurate it must be, how long it’s kept, who may see it, which system is authoritative, and what happens when it’s wrong. The architect shouldn’t invent those answers. That’s one of my firmest positions: owners set policy; architects enforce it. If Finance says the legal name can only change through the ERP process once the customer is active, that’s a governance decision. Making it mechanically true is my job.

The data steward keeps it working. The steward is close to the day-to-day health of the data: watching quality signals, investigating duplicates, resolving exceptions, coordinating fixes, maintaining definitions, spotting the process that keeps producing bad data. Two more jobs sit with the steward. When two teams disagree about what a field means, who owns it or who may see it, the steward brings the dispute to the owner and sees the decision through. And the steward builds data literacy: helping the people who enter and use the data understand what it means and why the rules exist. A steward needs more than a name on a chart. They need time, visibility, a process, and the authority to get problems fixed. Otherwise “data steward” becomes somebody’s eighth responsibility, looked at once a quarter.

The custodian runs the system. Admins, platform teams, security teams: whoever operates the technology that stores and processes the data. The owner says only these roles may see it; the custodian operates the controls that make it so. The names matter less than making each accountability clear, and in a small organization one person may wear two hats.

How the Program Runs

Governance programs tend to come in three shapes. Centralized: one team writes the policies and standards for every domain. It’s consistent, and it can become a bottleneck, far from the people doing the work. Federated (decentralized): each domain, such as finance, sales or operations, governs its own data within a few shared rules. It’s close to the work, and definitions drift apart between domains. Hybrid: a small central team owns the standards and the shared definitions, and the domain owners and stewards run their own data. Most enterprises I’ve seen end up somewhere in the hybrid. For the architect, the shape answers one practical question: who signs off a policy before I enforce it, and where do the shared definitions live?

Test knowledge. Know the three ways to run a governance program, centralized, federated (decentralized) and hybrid, and what each means for who sets policy and where the shared definitions live.

Make the RACI Earn Its Place

A RACI (who’s Responsible, Accountable, Consulted and Informed) helps, but not a giant spreadsheet made because governance “requires one.” I want it answering architecture questions, starting with the three from chapter 4 (The Four Questions Behind the Categories): where is the data created, where is it edited, and where is it referenced? Those are often different systems. Take a product: the ERP creates it, Salesforce references it, the portal shows it, the warehouse analyzes it. Now the business changes what “active product” means. Where does the change start, who approves it, how does it spread, and which copies are read-only? If you can’t answer, you don’t have governance yet. You have copies. A good RACI exposes exactly that ambiguity.

Governance Has to Become Mechanical

The business says only Finance may change the legal customer name. I don’t want the architecture answer to be “we’ll cover it in training.” Training helps; it isn’t enforcement. Maybe it’s field-level access, a validation rule, a field only the integration writes, or a controlled process instead of direct edits. The mechanism depends on the requirement, but there has to be one:

Governance policy	Owner decides	Possible enforcement point
The ERP owns the legal customer identity	Finance	Integration-only fields, permissions, validation
Only people with a need see personal data	Privacy, security	Sharing, permissions, field access
Customer identifiers are unique	Business owner	Unique External ID, duplicate rules
Governed records aren’t created by hand	Data owner	Permissions, automation, integration
Sensitive data has a set retention period	Privacy, legal	A retention or deletion process
Important changes must be provable	Compliance	Field history, audit trail
The source of data stays identifiable	Data owner	A source field, lineage metadata

I say possible enforcement point on purpose. This isn’t a feature-picking table. It’s the order of thinking: what’s the policy, who owns it, and what in the architecture makes it true?

Click to enlarge

Owners set policy; architects enforce it.

Don’t Rely on Good Behavior

“Never change the ERP customer ID.” Everyone knows it, until someone does: by accident, through a data load, through automation, through an integration, through an agent. If changing it would damage enterprise data, “please don’t” isn’t the control. Build the control. Trust, but verify. People, integrations, automation and AI all make mistakes, so the architecture should assume that eventually something will try what the policy forbids. What happens then?

Governance Crosses System Boundaries

Back to the landscape. The ERP owns the customer; Salesforce, the warehouse and a customer data platform hold copies; a partner gets some of it. Which system does the policy apply to? All of them. Salesforce may correctly block a legal-name change while an integration lets a downstream system overwrite it. Salesforce may delete personal data the warehouse still holds. A field classified as sensitive in Salesforce may land in an unclassified text field elsewhere. Governance can’t stop at the edge of the org, because the data doesn’t. That’s why chapter 4 came first: the landscape tells you how far governance has to reach.

Govern Enough, Not Everything

The opposite failure is just as real. We discover governance matters, so we lock everything down: no one can create, every change needs approval. The data is governed, and nobody can do their job. Governance means the appropriate control for the data: tight for some, light for others. Some records can be created freely, some need approval; some fields almost anyone can edit, some only the integration. The next module gets practical about exactly that.

And because governance is never finished, enforcement needs feedback. Are duplicates rising? Are required fields filling up with garbage? Are integrations failing, users finding workarounds, exceptions growing, stewards spending all day on one problem? Those signals tell you whether the design is working, and sometimes that the control, or the policy, needs to change.

Beyond the exam: what AI changes. Governance has a new consumer: the agent. The data owner still decides what may be used and for what; the architect still makes it enforceable. What changes is speed and scale. An agent reads, combines and acts on governed data far faster than a person, so a policy that exists only in a document protects even less.

What an Architect Decides Here

• Who is accountable for each important data domain, and how that differs from record ownership.
• Who stewards the data and who operates it as custodian.
• Where important data is created, edited, referenced and mastered across the landscape.
• What enforcement point makes each important policy mechanically true.
• How the architecture shows whether governance is working, or starting to slip.

When I hear a governance requirement, I translate it. “The ERP owns this.” “Only these people can see this.” “We need to prove who changed this.” “Keep this for seven years.” Each time: show me the enforcement point. The architect doesn’t decide the policy. We design the system that enforces it. That’s where governance stops being a document and becomes architecture.

Explore

• Salesforce Help, Sharing and Record Access Features (opens in a new tab), checked 2026-10-14.
• Salesforce Help, Data Classification Metadata Fields (opens in a new tab), checked 2026-10-14.